🤖
3527 in / 1927 out / 5454 total tokens
에이전트 7개에 프로젝트 컨텍스트, 정체성, 행동 원칙, 절대 규칙을 몽땅 박아넣었다. 기존엔 '기존 패턴을 따라라', '체크리스트를 확인해라' 같은 모호한 지시만 있었다. 이걸 구체적인 프로젝트 배경과 불변조건으로 전면 교체했다.
왜 이렇게 했냐면, 이전 구조가 너무 추상적이었다. Coder 에이전트는 '정확한 실행'이 핵심인데 행동 지시가 창의적 판단과 헷갈리게 되어 있었다. QA는 공정성 체크리스트 항목을 나열만 했지, 왜 그걸 검사해야 하는지 프로젝트 맥락이 없었다. Scout는 skills 참조가 아예 누락되어 있어서 guidelines, backend, frontend 룰 파일을 읽지 못하고 있었다. 7개 에이전트가 각자 다른 맥락을 가지고 일하고 있었던 셈이다.
각 에이전트에 추가된 핵심 섹션은 세 가지다. 첫째, 프로젝트 컨텍스트. LAMDiceBot이 뭔지, 어떤 기술 스택을 쓰는지, 배포가 어떻게 되는지를 명시했다. 'main 브랜치 = 실서버 (즉시 반영)' 같은 정보는 에이전트가 코드 수정 시 얼마나 신중해야 하는지 결정하는 핵심 제약이다. 둘째, 정체성. Coder는 '창의적 판단이 아니라 정확한 실행', Scout는 '수정하지 않고 정찰만', Reviewer는 '결론을 먼저 말할 것' 등 역할을 명확히 했다. 셋째, 절대 규칙 (MUST/NEVER). 프론트엔드 프레임워크 금지, 서버 측 난수 생성 강제, CSS 변수 시스템 준수 같은 것들이다.
새로 만든 CodexPlanner 에이전트도 눈여겨볼 만하다. Claude와 Codex가 대등한 입장에서 계획을 토론하는 구조다. subagent_type: codex:codex-rescue를 사용하고, allowed-tools: Bash만 줬다. 코드를 수정하지 않고 오직 계획 토론만 하는 역할이다. 기존 Scout-Coder-Reviewer 파이프라인 앞단에 '계획 검증' 단계를 하나 더 넣은 셈이다. 이건 게임 개발에서 레벨 디자이너가 프로토타입을 기획자와 교차 검증하는 것과 비슷한 패턴이다. 한쪽 시각에만 의존하면 블라인드 스팟이 생기니까.
Scout에 누락된 skills 참조 추가한 것도 중요하다. 이전엔 .claude/rules/guidelines.md, backend.md, frontend.md를 Scout가 안 읽고 있었다. 정찰 에이전트가 코딩 컨벤션도 모르고 코드베이스를 돌아다니고 있었던 거다. 이건 게임 엔진 프로젝트에서 렌더링 파이프라인 규칙도 모르는 채로 셰이더 코드를 리뷰하는 것과 같다.
변경 규모는 +257 -53으로, 절대량은 크지 않지만 구조적 의미가 크다. 모든 에이전트가 동일한 프로젝트 컨텍스트를 공유하게 되었다. 이전엔 에이전트마다 서로 다른 가정을 가지고 일했고, 그 결과가 충돌하면 내가 중간에서 조율해야 했다. 이제는 최소한의 공유 맥락이 코드로 명시되어 있다.
다음 할 일은 이 불변조건들이 실제로 지켜지는지 QA 에이전트가 자동 검증하는 체크리스트를 만드는 거다. 지금은 규칙을 '읽어라'라고만 했지, 위반 시 어떻게 할지는 안 정했다.
에이전트에게 '잘 해라'라고 말하는 건 쓸데없고, '이건 절대 하지 마라'라고 명시하는 게 진짜다.