oh-my-openagent 병렬 에이전트 동시성 리밋 문제와 해결법

요즘 제 메인 코딩 환경은 OpenCode에 oh-my-openagent를 얹어 쓰는 조합입니다. sisyphus, oracle, metis 같은 특화 에이전트들이 병렬로 돌아가며 코드 분석, 리팩토링, 테스트 작성을 한 번에 처리해주니 생산성이 확 올라갑니다. 아침에 이 조합으로 작업을 시작하면 정말 마법 같습니다.

그런데 매일 오후가 되면 갑자기 작동을 멈춥니다. 에러는 "rate limit" 계열이고, z.ai 대시보드에서 토큰은 50% 이상 남아있습니다. 시간당 토큰 제한도 아닙니다. 분명 리밋 문제인데, 어디서 걸리는 건지 몰랐습니다.

재미있는 건 Claude Code는 같은 시간대, 같은 계정으로 전혀 문제없이 돌아간다는 점이었습니다. 이 단서가 결정적이었습니다.

문제 진단 — 오후에만 작동하지 않는 이유

몇 주간 삽질 끝에 원인을 찾았습니다. 핵심은 동시성 리밋(Concurrency Limit)이었습니다.

oh-my-openagent는 하나의 작업을 처리할 때 여러 에이전트를 동시에 띄웁니다. 예를 들어 코드 변경을 요청하면 sisyphus가 메인 작업을 하는 동시에 oracle이 검증을, metis가 아키텍처 리뷰를 병렬로 수행합니다. 설정상 defaultConcurrency: 2이지만, maxDescendants: 15와 maxDepth: 2가 허용하는 범위 내에서 실제로는 더 많은 요청이 동시에 날아갑니다.

아침 시간대에는 다른 사용자들의 요청이 상대적으로 적어서 이 병렬 요청이 문제없이 처리됩니다. 하지만 오후가 되면 전체 플랫폼 사용량이 늘어나고, oh-my-openagent가 한 번에 뿌리는 여러 개의 동시 요청이 서버 측 동시성 리밋에 부딪히는 것입니다.

반면 Claude Code는 기본적으로 단일 에이전트 구조입니다. 한 번에 하나의 요청만 보내기 때문에 동시성 리밋과 무관하게 작동합니다. 토큰이 남아있는 한 오후에도 문제없죠.

토큰 잔량은 충분한데, 동시에 너무 많은 요청을 보내서 서버 측에서 막히는 것이었습니다. oh-my-openagent의 병렬 에이전트 구조가 이 문제를 만든 겁니다.

동시성 리밋이란?

API 사용량에는 여러 종류의 제한이 있습니다. 대부분의 사용자가 아는 건 토큰 리밋(하루/시간당 사용할 수 있는 토큰 총량)입니다. 하지만 그 외에도 중요한 제한이 있습니다.

토큰 리밋(Token Limit) — 사용 가능한 토큰의 총량. z.ai Pro 코딩플랜의 경우 1억 토큰/5시간.

RPM(Requests Per Minute) — 분당 요청 횟수 제한.

동시성 리밋(Concurrency Limit) — 동시에 처리할 수 있는 요청 수. 이전 요청이 완료되기 전에 새 요청을 보내면 큐에 쌓이거나 거부됩니다.

ZAI 코딩플랜에서 GLM 모델 시리즈는 프로바이더별로 동시성 리밋이 설정되어 있습니다. 이 리밋은 토큰 잔량과 독립적으로 작동합니다. 토큰이 99% 남아있어도, 동시에 5개 요청을 보내고 리밋이 3이라면 2개는 에러가 납니다.

이게 왜 오후에만 문제가 되냐면, 동시성 리밋이 고정된 값이 아니라 서버 부하에 따라 동적으로 조절되는 경우가 많기 때문입니다. 피크 시간대에는 유효 동시성이 낮아지고, oh-my-openagent의 병렬 요청이 그 낮아진 한계를 넘어서는 겁니다.

해결법 — oh-my-openagent.json 설정 최적화

원인을 알았으니 해결은 설정 파일 하나면 됩니다. oh-my-openagent.json에서 background_task 섹션의 동시성 관련 파라미터를 조정합니다.

수정 전 (문제의 설정)

{
  "background_task": {
    "defaultConcurrency": 2,
    "providerConcurrency": {
      "zai-coding-plan": 2
    },
    "maxDepth": 2,
    "maxDescendants": 15,
    "maxToolCalls": 150
  }
}

문제의 핵심은 maxDescendants: 15입니다. 이 값은 하나의 작업에서 파생될 수 있는 하위 에이전트의 최대 수를 의미합니다. depth 2까지 허용하면서 descendant를 15개나 두면, 실제 병렬 요청이 순간적으로 2~4개를 훌쩍 넘어갑니다.

수정 후 (권장 설정)

{
  "background_task": {
    "defaultConcurrency": 1,
    "providerConcurrency": {
      "zai-coding-plan": 1
    },
    "maxDepth": 1,
    "maxDescendants": 5,
    "maxToolCalls": 150
  }
}

각 파라미터 변경 이유를 설명하겠습니다.

defaultConcurrency: 2 → 1 — 기본 동시 실행 수를 1로 낮춰서 순간적인 동시 요청을 최소화합니다.

providerConcurrency["zai-coding-plan"]: 2 → 1 — ZAI 프로바이더에 대한 동시성을 명시적으로 1로 제한합니다. 이게 가장 중요한 설정입니다.

maxDepth: 2 → 1 — 에이전트가 다른 에이전트를 호출하는 깊이를 1단계로 제한합니다. depth 2는 "에이전트가 에이전트를 부르고, 그 에이전트가 또 에이전트를 부르는" 구조라서 요청이 기하급수적으로 늘어날 수 있습니다.

maxDescendants: 15 → 5 — 파생 에이전트 수를 대폭 줄입니다. 15개는 사실상 무제한에 가까운 값이고, 5개면 필수적인 서브 에이전트만 실행됩니다.

maxToolCalls는 150 그대로 유지했습니다. 이건 동시성과 무관하게 전체 작업에서 사용할 수 있는 툴 호출 횟수 제한이므로 줄일 이유가 없습니다.

설정 후 효과와 실사용 팁

설정을 변경한 뒤 오후 시간대에 테스트해보니, 에러 없이 정상 작동합니다. 속도가 느려진 체감은 있지만, 작동이 안 되는 것보다 훨씬 낫습니다.

속도 저하를 최소화하는 팁

단순 작업은 Claude Code 사용 — 파일 하나 수정하거나 간단한 질문 같은 건 Claude Code가 더 빠릅니다. oh-my-openagent는 병렬 에이전트의 이점이 살아나는 복잡한 작업에만 사용하는 게 좋습니다. 대규모 리팩토링, 다중 파일 변경, 아키텍처 설계 같은 경우 말이죠.

시간대 선택 — 오전 9시~11시는 플랫폼 전체 사용량이 적어서 원래 설정(defaultConcurrency: 2, maxDepth: 2)으로 써도 됩니다. 필요하면 시간대별로 설정을 스왑하는 스크립트를 만들어도 좋겠네요.

maxDescendants를 상황에 맞게 조절 — 5는 보수적인 값입니다. 익숙해지면 7~8 정도로 올려보면서 한계점을 직접 찾는 걸 추천합니다.

에이전트 모델 분산도 고려해보세요

현재 설정을 보면 sisyphus, oracle, prometheus, metis, momus, atlas가 전부 glm-5.1을 씁니다. 동시성 리밋은 모델별로 걸리는 경우도 있으니, 검증용 에이전트를 glm-4.5로 내리면 동시성 충돌을 더 줄일 수 있습니다.

"oracle": { "model": "zai-coding-plan/glm-4.5" },
"momus":  { "model": "zai-coding-plan/glm-4.5" }

검증 작업에 5.1이 꼭 필요한 건 아니니, 이 정도 분산만 해도 효과가 있습니다.

정리

oh-my-openagent의 병렬 에이전트는 강력하지만, 그 강력함이 동시성 리밋이라는 숨은 제한과 충돌할 수 있습니다. 특히 오후 피크 시간대에 "토큰은 남았는데 왜 안 되지?"라는 의문이 든다면, 십중팔구 동시성 리밋 문제입니다.

providerConcurrency와 maxDescendants만 손봐도 대부분 해결됩니다.

2026년 4월 현재, oh-my-openagent는 업데이트가 활발하게 이루어지고 있고, 동시성 제어 로직도 점진적으로 개선되고 있습니다. 하지만 당장 실무에서 안정적으로 쓰려면 위 설정 조정이 필수적입니다.