클로드 코드 마스터-워커 라우팅, 컨텍스트 붕괴를 막을 실제 해법인가

대규모 바이브 코딩을 하다 보면 메인 세션 하나가 설계부터 구현, 테스트까지 다 떠안다가 어느 순간 맥락을 잃는 경험을 하게 된다. 클코단에서는 이 문제를 풀기 위해 마스터 오케스트레이터가 작업을 쪼개고 디렉터리별 워커 에이전트가 나눠 맡는 룰 기반 라우팅 구조가 논의됐다. 이 구조가 클로드 코드가 실제로 지원하는 기능과 얼마나 맞아떨어지는지, 개인 개발자에게도 쓸 만한지 확인했다.

컨텍스트가 무너지는 지점은 어디인가

컨텍스트 저하는 대체로 창의 70~75% 지점부터 시작된다는 게 관련 가이드들의 공통된 설명이다. 완벽한 검색이 이뤄지고 방해 요소가 전혀 없어도, 여러 정보를 동시에 붙들고 추론하는 성능은 표기된 창 크기 안에서부터 이미 떨어지기 시작한다.

증상은 뚜렷하다. 이미 읽은 파일을 다시 읽거나, 여러 메시지 전에 합의한 아키텍처 결정을 스스로 뒤집거나, 답이 짧아지는 대신 헤징과 재진술로 길어지는 식이다. 클코단에서 제기된 "메인 세션에 작업을 몰면 긴 작업에서 컨텍스트 품질이 저하된다"는 문제의식은 이 현상과 정확히 겹친다.

원인은 단순히 토큰이 많아서가 아니다. 앤트로픽은 컨텍스트 오염을 이렇게 설명한다. 대형 파일을 분석하거나 여러 테이블을 조회할 때 관련성과 무관한 중간 결과가 계속 쌓이면서 토큰 예산을 잡아먹는 현상이라는 것이다. 도구를 20개 넘게 붙인 에이전트는 적합한 도구를 고르는 정확도부터 떨어진다는 관찰도 함께 나온다.

클로드 코드에 이미 있는 오케스트레이터-워커 구조

클코단에서 나온 마스터-워커 분리는 사실 새 아이디어가 아니라 클로드 코드의 서브에이전트 구조 그 자체다. 서브에이전트는 독립된 컨텍스트 창과 전용 시스템 프롬프트를 가진 별도의 클로드 인스턴스다. 이를 호출하는 세션이 오케스트레이터가 되어 작업을 배분하고 결과를 조합한다. 서브에이전트가 수십 개 파일을 읽고 방대한 검색을 돌려도 메인 대화창에는 요약만 돌아온다.

앤트로픽이 자사 리서치 기능에 적용한 구조도 같은 뼈대를 쓴다. 리드 에이전트가 질의를 분석해 전략을 세우고 서너 개의 전문 서브에이전트를 병렬로 띄운다. 이후 결과를 종합하고 별도의 인용 에이전트로 출처를 검증한다. 2025년 6월 공개된 앤트로픽 엔지니어링 블로그에 따르면 이 구조는 내부 평가에서 단일 에이전트 오퍼스 4보다 90.2% 높은 성능을 냈지만, 토큰은 일반 대화의 약 15배를 썼다.

클로드 코드 쪽에는 여기서 한 단계 더 나아간 다이내믹 워크플로 기능도 있다. 작업을 설명하면 클로드가 서브에이전트들을 오케스트레이션하는 자바스크립트 스크립트를 직접 짠다. 런타임은 이를 백그라운드에서 실행한다. 클코단이 그린 "마스터가 PRD를 배분하고 워커가 결과를 보고하는" 그림은 이 워크플로 도구가 이미 코드로 구현해 둔 패턴에 가깝다.

PRD와 메모리를 어떻게 넘기는가

룰 기반 라우팅에서 가장 까다로운 지점은 워커가 필요한 맥락만 골라 받는 부분이다. 클로드 코드 공식 문서는 이 역할을 CLAUDE.md와 오토 메모리 두 계층으로 나눠 맡긴다. CLAUDE.md는 사람이 직접 쓰는 규칙이다. 프로젝트·사용자·조직 단위로 범위를 나눌 수 있고, 세션이 시작될 때마다 전체가 로드된다.

오토 메모리는 클로드가 스스로 남기는 학습 노트다. 저장소별로 MEMORY.md라는 색인 파일이 생긴다. 세션을 시작할 때는 이 색인의 첫 200줄 또는 25킬로바이트만 불러오고, 상세 내용은 별도 주제 파일로 분리해 필요할 때만 읽는다. 클코단에서 나온 "지침 전체를 상시 로드하지 않고 참조 주소만 관리한다"는 아이디어와 사실상 같은 설계다.

다만 어긋나는 지점도 있다.

메인 세션의 오토 메모리는 서브에이전트에 자동으로 넘어가지 않는다. 부모 대화를 통째로 이어받는 "포크" 방식이 아닌 이상, 서브에이전트는 자기 몫의 memory 필드를 따로 켜서 독립적으로 기록을 쌓아야 한다. 클코단이 그린 "워커가 작업 시점에 필요한 메모리를 요청한다"는 그림보다는, 워커마다 자기 메모리를 갖고 마스터가 그 결과를 다시 취합하는 쪽에 가깝다.

새 작업이 들어올 때 메모리를 갱신하는 훅 아이디어도 실체가 있다. PreToolUse·PostToolUse 같은 훅은 클로드의 판단과 무관하게 정해진 시점마다 셸 명령을 실행한다. InstructionsLoaded 훅은 어떤 지침 파일이 언제 왜 로드됐는지 기록으로 남긴다. 방에서 나온 설계는 결국 이 훅 체계를 프로젝트 규모에 맞게 세밀하게 짜 맞추는 작업이다.

나눈다고 공짜가 아니다

앤트로픽은 정작 자사 블로그에서 멀티 에이전트 확장에 신중하라고 말한다. 다중 에이전트가 단일 에이전트보다 확실히 나은 경우를, 앤트로픽은 세 가지로 좁혀 제시했다. 컨텍스트 오염이 성능을 갉아먹을 때, 작업을 병렬로 쪼갤 수 있을 때, 전문화가 도구 선택이나 집중도를 높일 때다. 이 조건을 벗어나면 조율 비용이 이득을 앞지른다고도 밝혔다.

비용 차이는 작지 않다.

동일한 작업을 멀티 에이전트로 처리하면 단일 에이전트 대비 토큰을 3~10배 더 쓴다는 게 앤트로픽의 설명이다. 앤트로픽 내부에서도 정교한 멀티 에이전트 구조를 몇 달 걸려 만들었다가, 단일 에이전트 프롬프트를 다듬는 쪽이 동등한 결과를 냈다는 사례가 나왔다고 한다.

실사용 쪽 반응도 신중론에 가깝다. 멀티 에이전트 오케스트레이션은 작업 대부분에는 과한 처방이라는 의견이 많다. 단일 세션으로 기능 하나를 개발하는 편이 여전히 대다수 개인 개발자·소규모 팀에는 맞는다는 것이다. 병렬로 작업량을 늘렸다가 하루 사용량 한도를 예상보다 빨리 써버렸다는 사용기도 심심찮게 나온다. 반대로 서브에이전트를 저가 모델로 돌려 오히려 비용을 줄였다는 사례도 있다. 구조를 어떻게 짜느냐에 따라 결과가 갈린다는 쪽이 더 정확하다.

쪼갤지 말지를 가르는 세 가지 조건

클코단 논의를 이 기준에 대보면 답이 갈린다. 저장소가 이미 디렉터리별로 독립된 서브시스템이고 워커들이 서로 파일을 거의 건드리지 않는다면, 병렬성과 전문화 조건을 동시에 채운다. 반대로 한 사람이 하나의 기능을 처음부터 끝까지 짜는 구조라면, 마스터-워커를 나누는 순간 PRD 작성·핸드오프·메모리 동기화라는 새로운 조율 비용만 얹힌다.

클로드 코드는 서브에이전트·CLAUDE.md·오토 메모리·훅·다이내믹 워크플로까지, 이 설계에 필요한 조각을 이미 대부분 갖고 있다. 방에서 나온 룰 기반 라우팅은 없는 기능을 요구하는 제안이라기보다, 있는 조각을 프로젝트 규모에 맞게 조립하는 설계에 가깝다. 그 조립이 필요한지는 지금 겪는 컨텍스트 붕괴가 정말 병렬화·전문화로 풀리는 문제인지, 아니면 CLAUDE.md 한 줄과 이른 /compact 습관으로도 충분한 문제인지에 달려 있다.