700줄 모놀리스 문제를 해결하기 위해 에이전트 컨텍스트를 세 개의 계층으로 분할하기

지속적인 자율 에이전트를 구축할 때 흔히 발생하는 문제는 다음과 같습니다: 에이전트 컨텍스트가 하나의 파일에서 시작하지만 700줄 이상으로 확장되며, 정체성 규칙, 현재 전략, 도구 참조, 가격 업데이트, 게시 절차 등이 혼합됩니다. 이 모놀리스는 관리하기 어려워집니다—이번 주에 집중할 내용을 편집하는 것이 '절대 이렇게 하지 마라' 규칙과 같은 파일에 있어 주저와 오류를 초래합니다. 6개 에이전트 시스템을 구축하는 팀이 이 문제를 정확히 겪었습니다: 2주차까지 런처가 인수 제한에 도달하고 세션이 침묵 오류로 실패했습니다.

세 계층 분할

해결책은 에이전트 컨텍스트를 관심사 유형과 변경 빈도에 따라 세 가지 별도 파일로 분리하는 것이었습니다:

• CLAUDE.md - 정체성: 에이전트가 누구인지, 엄격한 규칙, 성격. 거의 변경되지 않음. 캐시 가능.
• BRIEFING.md - 미션: 지금 집중할 내용, 현재 전략, 가격, 목표. 주간 변경.
• PLAYBOOK.md - 운영: 작업을 기계적으로 수행하는 방법: 절차, CLI 명령어, 도구 참조. 도구 변경 시 변경.

하나의 정보는 정확히 하나의 계층에 존재합니다. 도구 참조가 PLAYBOOK에 있으면 BRIEFING에는 없습니다. 중복은 침묵 모순을 초래합니다.

이 아키텍처가 작동하는 이유

실용적인 편집: 모두가 어떤 파일을 편집해야 할지 압니다. 무엇에 집중할까요? BRIEFING. 어떻게 게시할까요? PLAYBOOK. 절대 이렇게 하지 마라? CLAUDE.md. 추측하거나 700줄을 뒤적일 필요가 없습니다.

기술적 효율성: 에이전트가 재시작될 때(자주 발생함), 정체성은 안정적으로 유지됩니다. 동일한 CLAUDE.md가 모든 세션에서 사용되어 캐시 계층이 거의 무료 캐시 히트로 동일한 프롬프트 접두사를 볼 수 있게 합니다. BRIEFING과 PLAYBOOK은 첫 시작 시 도구 호출을 통해 도착합니다—에이전트가 실질적인 작업을 시작하기 전에 이를 읽으므로 중복되지 않습니다. 스폰 인수는 PLAYBOOK이 2000줄 이상으로 성장하더라도 영원히 작게 유지됩니다.

규율: 모놀리스는 어디에나 어떤 내용이든 허용합니다. 이 명세는 강제로 질문하게 합니다: 이것은 캐릭터, 미션, 아니면 메커니즘에 관한 것인가? 그 질문에 답하는 것이 시스템에 대한 사고 방식을 바꿉니다.

주입 패턴

패턴 A (단순): 스폰 시 세 파일을 모두 읽고 연결하여 주입합니다. 총 크기가 스포너 인수 제한에 맞으면 작동합니다.

패턴 B (지속적 에이전트): 스폰 시 CLAUDE.md만 주입합니다. CLAUDE.md에는 명령이 포함됩니다: 첫 번째 작업으로 BRIEFING.md와 PLAYBOOK.md를 읽으세요. 에이전트는 작업을 시작하기 전에 먼저 도구 호출로 미션 및 운영 문서를 로드합니다. 플레이북이 성장하더라도 스폰 프롬프트는 작게 유지됩니다. 이는 재시작하는 에이전트의 기본값입니다.

팀은 패턴 B를 사용합니다. 매 세션마다 에이전트가 깨어나서 BRIEFING을 읽고, PLAYBOOK을 읽은 후 실행합니다. 매번 새로운 컨텍스트, 캐시된 정체성, 인수 제한 걱정 없음.

구현 후 결과

• 편집이 몇 분이 아닌 몇 초 걸림—관련 없는 것을 망칠 두려움 없음.
• 세션 간 BRIEFING 편집이 바로 작동함—에이전트가 다음 재시작 시 새로운 BRIEFING을 읽음.
• PLAYBOOK이 2000줄 이상으로 성장했지만 런치 불안감 제로.
• 새 에이전트 온보딩이 더 빠름—채울 명확한 골격이 있음.

이 접근 방식은 혁명적이지 않습니다—에이전트 컨텍스트에 적용된 관심사 분리일 뿐입니다. 하지만 모놀리스 문제를 겪은 후에는 이 방법이 구조적으로 문제를 해결합니다. 재시작하는 자율 에이전트를 구축하는 팀에게 이 아키텍처는 알아둘 가치가 있습니다.