Claude Code 서브에이전트(subagents)를 4개에서 8개로 확장했더니 오류율이 0.8%에서 4.3%로 치솟았습니다. 병목 현상은 모델 때문이 아니었습니다.

원인은 페이지네이션 커서(pagination cursors), 중간 집계 값(mid-aggregation values), 필터 체인(filter chains)을 호출 간 인스턴스 메모리에 유지하는 analytics_query라는 상태 유지형(stateful) MCP 도구였습니다. Cloudflare Workers는 각 요청을 사용 가능한 PoP 인스턴스로 라우팅하며, 동일한 인스턴스에 두 번 접속한다는 보장이 없습니다. 서브에이전트가 4개일 때는 충돌이 충분히 드물어 세션이 우연히 고정(sticky)된 상태로 유지되었습니다. 하지만 8개가 되자 분포가 확산되었고, 컨텍스트 누락(context misses)이 비선형적으로 발생했습니다. 오류는 다음과 같았습니다:

Error: Tool call failed — session context not found
  session_id: "sess_7f3a9b"
  worker_instance: "worker-11"
...

세션 ID는 존재했습니다. 하지만 워커(worker)가 일치하지 않았습니다. 상태(State)가 사라진 것입니다.

저는 두 가지 해결책을 병행하여 테스트했습니다. KV 기반 세션 스토리지(전체 컨텍스트를 직렬화(serialize)하고, 호출 시작 시 읽고, 호출 종료 시 쓰는 방식)는 라우팅 문제를 해결했지만 새로운 문제를 만들었습니다. 8개의 동시 실행 서브에이전트 환경에서 KV 쓰기 작업은 제 예상치의 약 16배로 급증했습니다. 부하 상황에서 도구 호출당 p99 지연 시간(latency)은 180ms에서 620ms로 뛰었고, 쓰기 비용만으로도 제 사용량 기준 월 $150를 넘어섰습니다.

Durable Objects(DO)는 이 문제를 깔끔하게 해결했습니다. 세션 ID로 라우팅하면 항상 동일한 DO 인스턴스에 접속하게 됩니다. 즉, 세션 어피니티(session affinity)가 제 코드가 아닌 플랫폼 수준에서 처리됩니다. 동일한 부하에서 p99는 38ms로 떨어졌습니다. 월 비용은 약 $40–60 선에서 안정되었습니다.

아무도 미리 말해주지 않는 트레이드오프(tradeoff)가 있습니다. DO 인스턴스는 유휴(idle) 상태일 때 축출(evicted)되며, 이때 인메모리 상태(in-memory state)가 조용히 사라집니다. 에이전트는 이를 인지하지 못한 채 계속 진행합니다. 이러한 실패 모드는 대시보드에 즉시 나타나는 KV 지연 시간 급증보다 훨씬 조용하고 더 무섭습니다.

6개월 후 제가 정착한 방식은 다음과 같습니다: 활성 세션을 위한 DO 메모리, 각 도구 호출 종료 시의 DO 스토리지 체크포인트(약 월 $10 추가 비용), 그리고 라우팅 인덱스로만 사용하는 KV(읽기 중심이며 비용이 거의 들지 않음)입니다. 세 개의 계층을 사용하지만, 각 계층은 실제로 격리(isolate)할 수 있는 별개의 실패 모드를 가지고 있습니다.

6개의 서브에이전트(subagent) 지점이 저의 변곡점이었습니다. 이 수치 아래에서는 이 문제를 전혀 발견하지 못할 수도 있습니다. 하지만 이 수치를 넘어서면, 세션 충돌(session collision) 계산이 급격히 복잡해집니다.

체크포인트 타이밍 문제(DO 유휴 상태 축출(idle eviction)은 문서에서 제안하는 것보다 예측하기 어렵습니다)와 여러 서브에이전트가 동시에 동일한 세션에 접근할 때 발생하는 현상을 포함한 전체 분석 내용을 riversealab.com에 작성해 두었습니다.

전체 포스트 보기 →