장시간 Claude Code 에이전트, '참모장' 패턴으로 컨텍스트 한계 넘는다

Claude Code로 장시간 자율 코딩을 돌리는 팀들이 하나의 세션에 모든 역할을 몰아넣지 않고, 조정 세션과 실행 세션을 분리하는 오케스트레이션 패턴을 쓰기 시작했다. 'Chief of Staff(참모장)'라고 부르는 이 구조에서 한 세션은 작업을 배분하고 결과를 검증하며, 별도의 세션들이 실제 구현을 맡고, 상태는 어떤 세션의 컨텍스트 창 안이 아니라 외부의 영속 보드에 저장된다.

문제의식은 명확하다. 단일 AI 코딩 세션은 한 시간 정도는 쓸 만하지만 그 뒤로 품질이 떨어진다. 이유는 세 가지다. 첫째, 컨텍스트는 유한하고 손실을 동반한다. 긴 세션은 압축되고, 몇 시간 전의 중요한 세부 사항이 요약으로 뭉개지면서 원래의 구체성을 잃는다. 둘째, 자기 보고가 현실과 어긋난다. "테스트 통과"라는 말은 방금 관찰한 사실이 아니라 의도와 기억을 보고하는 것에 가깝고, 세션이 길어질수록 그 간극이 벌어진다. 셋째, 배운 것이 축적되지 않는다. 2시간째에 뼈아프게 얻은 교훈도 다음 세션이 읽을 수 있는 곳에 적어두지 않으면 사라진다. 여기에 에이전트를 더 투입하면 문제는 해결되지 않고 배가된다. 신뢰할 수 없는 보고자가 여럿이 될 뿐, 그 사이를 조정하는 주체는 없기 때문이다.

해법은 기술이 아니라 조직론에서 온다. 한 에이전트가 계획하고 검사하며, 나머지가 일을 하고, 공유 상태가 어느 단일 컨텍스트 창 바깥에 존재하는 형태다. 이 형태 자체는 이미 여러 이름으로 알려져 있다. 오케스트레이터-워커(또는 슈퍼바이저, 계층형 오케스트레이션), 코디네이터-구현자-검증자(CIV), 금융·운영에서 온 메이커-체커, Git의 분산 워크플로에 문서화된 통합 관리자(integration manager), 그리고 Claude Code 자체의 서브에이전트 문서가 쓰는 팀 리드와 팀원 모델이 모두 같은 말을 한다. 'Chief of Staff'는 이 글의 저자들이 붙인 별칭일 뿐, 확립된 용어가 아니다.

조정 세션, 일명 '오버와치(overwatch)'의 책임은 구체적이다. 영속 큐에서 정해진 순서로 작업을 꺼내 배분하고, 조정자의 판단 없이도 더 약한 모델이 따라갈 수 있는 브리프를 작성하며, 실행 세션이 실행했다고 주장한 명령을 직접 다시 돌려 검증하고, 트랜스크립트가 아니라 실제로 반영된 diff를 읽는다. 세션이 끝나기 전에 교훈을 영속 아티팩트에 기록하고, 표류하는 세션은 작업을 빼앗지 않은 채 방향만 바로잡는다. 반대로 하지 않는 일도 분명하다. 구현 코드를 직접 쓰지 않는다. 조정자가 코딩을 시작하는 순간 검증을 멈추게 되고, 패턴은 과부하 걸린 단일 세션으로 퇴화한다.

이를 실무에 적용하려면 세 가지가 필요하다. 도구는 교체 가능하지만 역할은 그렇지 않다. 먼저 Claude Code가 세션 자체를 제공한다. 도구 사용, 파일 편집, 셸 접근, 세션 간 메시징이 여기에 해당하며, 세션마다 컨텍스트 창이 분리되는 것이 핵심이다. 한 세션의 혼란이 다른 세션을 오염시키지 않는 격리가 곧 기능이다. 다음으로 cmux가 터미널 워크스페이스를 관리하고 커맨드라인에서 구동되어 스크립트화할 수 있다. 마지막으로 Plan Desk가 MCP를 통해 에이전트에 노출되는 기획 보드 역할을 한다.

cmux로 실행 세션을 띄울 때는 함정이 있다. `--command`는 워크스페이스의 셸에 텍스트를 보낼 뿐, 에이전트를 시작하지 않는다. `claude`를 명시적으로 호출해야 하며, 그냥 지시문만 던지면 셸이 그것을 실행하지 못하는데도 런처는 성공했다고 보고한다. 또 하나는 프롬프트를 짧게 유지하고 파일을 가리키게 하는 것이다. 긴 명령 문자열은 실행이 불안정한 반면, 커밋된 브리프를 가리키는 짧은 프롬프트는 견고하고 검토와 재실행이 가능하다.

Plan Desk 같은 영속 상태 저장소는 많은 팀이 건너뛰는 구성요소이며, 건너뛴 다중 에이전트 구성이 밤을 넘기지 못하는 이유이기도 하다. 세션은 일회용이지만 보드는 아니다. 보드에는 프로젝트, 목표, 의존성 엣지를 가진 태스크, 태스크에 연결된 설계 문서, 사람의 지시와 에이전트의 추론이 남는 코멘트가 담긴다. 태스크는 빌드 계약처럼 쓴다. 문제 정의, 액션 아이템, 인터페이스, 검증 계약, 비목표까지 포함해 실행 세션이 상위 문서를 읽지 않고도 작업을 끝낼 수 있을 만큼 구체적이어야 한다. 상태는 작업과 원자적으로 함께 전환된다. 시작하는 순간 in_progress, 검증되는 순간 done이며, 세션 끝에 몰아서 갱신하지 않는다.

작업 루프는 이렇게 돈다. 보드에서 막히지 않은 다음 태스크를 가져오고(PULL), 손대기 전에 연결된 설계 문서를 읽고(READ), 검증기를 먼저 돌려 실패해야 통과하는 레드 게이트를 세우고(RED GATE), 실행 세션에 브리프를 넘기거나 직접 만들고(DELEGATE), 주장된 모든 명령을 재실행해 종료 코드로 판정하고(PROVE), 결과를 관찰한다(OBSERVE). 한 번에 하나의 작업, 하나의 디스패치, 하나의 커밋이 원칙이다.

한국 개발자에게 이 패턴이 주는 실질적 변화는 검증을 파이프라인의 1급 시민으로 끌어올린다는 점이다. 에이전트의 보고는 지시가 아니라 증거로 다루고, 세션 간 메시지처럼 지연·보류·만료될 수 있는 채널 대신 커밋된 파일이나 보드 카드처럼 반드시 도착하는 영속 채널에 쓴다. 타임박스는 작업을 어디서 자를지가 아니라 얼마나 자주 보고할지를 정하는 장치다. 가장 값비싼 오류는 실제로 하지 않은 일에 대해 성공을 보고하는 검사에서 나온다는 경고도 새겨둘 만하다.

다만 전제를 분명히 해야 한다. 'Chief of Staff'라는 이름은 이 글의 편의적 은유일 뿐 학계나 업계의 표준 용어가 아니다. 같은 표현은 캘린더·인박스·우선순위를 관리하며 전문 에이전트에 일을 넘기는 개인 비서형 에이전트를 가리키는 데도 널리 쓰인다. Anthropic의 쿡북에 있는 참모장 에이전트가 그런 유형이며, 이 글은 그와 다른 문제, 즉 코딩 루프를 다룬다.