왜 오케스트레이션 게이트인가
Claude Code 메인 세션의 직접 편집을 훅으로 막고 구현을 서브에이전트와 Codex로 넘긴 이유
Claude Code로 iOS 카메라 앱을 만들 때는 기능 하나에도 파일 여러 개와 테스트를 함께 고쳐야 했다. 세션 하나가 요구를 듣고 코드를 읽은 뒤 구현, 테스트, 결과 보고까지 맡았다. 작업이 끝난 대화에는 수백 줄의 diff와 버린 코드, 테스트 로그가 남았다.
그 뒤부터 앞에서 정한 설계 규칙을 다시 설명해야 하는 일이 잦았다. 어느 파일이 어떤 책임을 갖는지, 왜 그 자리에 로직을 뒀는지를 앞에서 정해놓고도 뒤에서 다르게 짜는 식이다. 계측한 수치는 없다. 긴 세션의 후반부에서 그런 일이 반복됐다고 기억한다.
초반의 판단 근거를 후반부 대화에서 다시 찾고 적용하기가 어려워졌다.
토큰 배분 규칙
당시 내 구독 환경에서 Claude 토큰에는 사용 한도가 있었고, OpenAI Codex CLI는 별도 구독이라 추가 토큰 비용을 신경 쓰지 않아도 됐다. 보일러플레이트 생성은 두 도구 모두 맡길 수 있었지만 별도 규칙이 없을 때는 주로 Claude가 처리했다.
이 차이를 기준으로 배분 규칙을 정했다. 당시 정책 문서에는 이렇게 적었다.
Claude tokens are the scarce resource; Codex tokens are effectively
unmetered. Route accordingly.
대량 코드 생성, 보일러플레이트, 기계적 리팩터링, 테스트 스캐폴딩은 Codex가 맡는다. Claude 워커는 Codex를 쓸 수 없거나 촘촘한 반복 수정이 필요한 작업을 맡고, 어려운 설계 판단과 리뷰는 추론에 강한 모델로 보낸다.
직접 처리할 범위도 같이 적었다. 파일 한두 개를 고치는 사소한 편집, 오타와 문구 수정, 설정값 하나 바꾸기, 읽기만 하는 질문이다. 그 밖은 전부 위임 대상이다. 파일 세 개 이상이 걸리거나 대략 50줄을 넘는 변경, 테스트 작성, 리팩터링, 오래 생각해야 하는 일이 여기 들어간다.
메인 세션에서는 요청을 나누고 각 작업을 맡길 대상을 정한다. 메인 세션이 직접 구현을 시작하면 그 판단을 뒤늦게 되돌리기 어려웠다.
CLAUDE.md에서 훅으로
이 원칙을 먼저 CLAUDE.md에 적었다. 큰 구현을 위임하라는 지침은 자주 지켜졌지만, 메인 세션이 이미 읽은 파일을 직접 고치는 경우도 있었다. CLAUDE.md는 세션에 제공되는 지침이지 도구 호출을 차단하는 설정은 아니다.
그래서 지침을 훅으로 옮겼다. Claude Code는 도구를 실행하기 직전에 PreToolUse 훅을 부른다. 훅 스크립트가 종료 코드 2를 돌려주면 해당 도구 호출을 막고 stderr의 내용을 모델에 전달한다. 편집 횟수와 크기를 이 훅에서 검사했다.
첫 판의 규칙은 세 줄이었다.
- 메인 세션의 코드 파일 편집은 요청당 두 번까지. 문서와 설정 파일은 세지 않는다.
- 한 번에 100줄이 넘는 코드 쓰기는 차단한다. 큰 구현을 쪼개지 않고 밀어 넣는 경로를 막는다.
- 서브에이전트는 제한 없이 쓴다. 워커 안에서 난 편집은 세지 않는다.
한도에 걸린 메인 세션은 거부 사유로 이 문장을 받는다.
Main-session code-edit limit (2) reached this request. Delegate the
remaining changes to Codex (/codex:rescue) or the default-worker subagent.
Do not retry this edit directly or via Bash.
처음 이 메시지가 떴을 때 세션은 Task 도구로 워커를 띄웠다. 이후에도 차단 메시지에 위임 방법을 적어 둔 경우에는 세션이 그 방법을 선택했다. 거부 이유와 함께 실행할 위임 방법을 제공한 셈이다.
내가 확인한 세션에서는 게이트를 켠 뒤 큰 작업이 워커와 Codex로 넘어갔다. 메인 세션의 대화에 구현 과정이 쌓이는 속도도 이전보다 느려졌다. 별도의 계측값은 남기지 않았으므로 이 변화는 운영 중 관찰한 범위에 한정한다.
게이트는 규칙에 걸린 호출만 막았다. 코드 파일을 다른 확장자로 저장하면 카운터를 빠져나간다. 셸로 파일을 쓰는 경로는 두 번째 훅이 따로 검사했지만 우회 경로가 남았다. 이 구현의 목표는 보안 경계가 아니었다. 메인 세션의 반복 편집에 마찰을 주고 위임 방법을 제시하려 했다. 내 작업에서는 요청당 두 번이라는 한도가 그 행동을 바꾸는 데 충분했다.
참고
Comments
아직 댓글이 없습니다. 첫 댓글을 남겨주세요.
검토 대기 중