왜 당신의 서브 에이전트(sub-agent)는 당신과 동일한 메모리를 로드하지 않는가 (그리고 어떻게 당신 몰래 main 브랜치에 커밋하는가)

부모라면 하지 않았을 커밋

5월 18일 늦은 오후. 나는 6개의 파일로 구성된 자동 전송 작업(autosend chantier)을 서브 에이전트(sub-agent)에게 위임했다. 브리프(Brief) 내용은 다음과 같았다: 15줄 내외, 'phase 0'로 명명, 모든 INSERT 명령 이전에 감사(audit) 명령 실행. 45분 후, 보고서가 도착했다: main 브랜치에 커밋됨. 나는 git log --oneline -5를 실행했고, 기본 브랜치(default branch)에 기능 커밋(feature commit)인 3756e63이 있는 것을 발견했다. 브랜치도, PR(Pull Request)도 없었다. 30분 동안 체리픽(cherry-pick) 작업을 해야 했다.

열흘 전에도 동일한 유형의 사고가 있었다. 5월 14일, 이전의 git checkout이 조용히 취소되는 바람에 나의 커밋이 잘못된 브랜치로 들어갔다. 나는 그날 밤 feedback_git_branch_check_avant_commit.md라는 규칙을 작성했다: "중요한 커밋을 하기 전에는 반드시 git branch --show-current를 실행할 것". 나는 기계적으로 이 규칙을 참조한다. 하지만 3756e63을 푸시한 서브 에이전트는 이 규칙을 읽은 적이 없었다.

부모의 메모리가 전달되지 않는 이유

나의 멘탈 모델(mental model)이 틀렸다. 나는 내가 참조하는 사용자 범위 메모리(user-scope memory) — 120개의 피드백 파일들 — 가 위임된 에이전트들에게 _상속(inheritance)_을 통해 내려가는 계층 구조를 상상했다.

현실은 더 냉혹하다. 서브 에이전트는 자신만의 컨텍스트 샌드박스(context sandbox) 내에서 작동한다. 에이전트는 내가 작성한 브리프(brief)와 아마도 작업 디렉토리(working directory)에 연결된 프로젝트 범위 규칙(project-scope rules)의 일부를 전달받지만, 부모의 사용자 범위 인덱스(user-scope index)는 받지 못한다. 이행성(transitivity)은 존재하지 않는다. 내가 핵심적인(load-bearing) 것으로 취급하는 규칙 — 즉, 위반 시 사고를 유발하는 규칙 — 은 내가 브리프에 직접 포함(inline)시키지 않는 한, 위임된 에이전트에게는 운영상 존재하지 않는 것이나 다름없다.

이러한 비대칭성은 단독으로는 보이지 않는다. 부모가 메모리를 로드하면 시스템은 유지된다. 하지만 내가 작업을 위임하는 순간 이는 구조적 결함(structural hole)이 되며, 위임이 많아질수록 이러한 유형의 사고가 발생할 확률은 높아진다. 에이전트의 메모리는 상속을 통해 전달되지 않는다. 명시적인 브리핑(briefing)을 통해 전달되거나, 아니면 전혀 전달되지 않는다.

모든 피드백이 동일한 무게를 갖는 것은 아니다

모든 피드백을 매번 브리프에 직접 포함(inlining)하는 것은 호출할 때마다 인덱스를 재구축하는 것이라고 반론할 수 있다. 이는 타당한 지적이며, 내가 제안한 규칙은 그런 방식을 요구하는 것이 아니다.

내 피드백의 대부분은 동등하지 않다. 어떤 것들은 언어 선호도, 커밋 서명(commit signature), 타이포그래피 취향과 같이 일반적(generic)이다. 다른 것들은 위반 시 사고를 유발하는 **구조적 불변량 (structural invariant)**을 담고 있다: 각각의 사소하지 않은 커밋 전에는 브랜치를 확인하라, 최신 카운트 확인 없이 대량 삭제(bulk DELETE)를 하지 마라, 계약 테스트(contract test) 전에는 반드시 DB를 실질적으로 감사(audit)하라. 기준은 단 한 문장이다. 만약 부모(parent)가 해당 피드백을 건너뛰었을 때 우리가 피하고자 하는 사고가 발생했을 것이라면, 그 피드백은 하중을 견디는 (load-bearing) 것이다. 부모에게 지불할 가치가 있는 검색 비용(retrieval cost)은 대리인(delegate)에게 지불할 가치가 있는 브리핑 비용(briefing cost)이다.

R9 수정안

나는 툴킷(toolkit) v0.7에 이 수정안을 작성했다:

R9 수정안 — 브리프(brief)는 부모가 이 작업을 위해 하중을 견디는 것으로 취급하는 사용자 범위(user-scope)의 피드백을 인라인(inline)으로 포함하거나(또는 경로 참조해야 한다). 서브 에이전트(Sub-agents)는 부모의 ...를 전이적으로 상속받지 않는다.

세 가지 사례가 반복된다. Git을 다루는 에이전트: 브랜치 확인 피드백을 인라인으로 포함한다. 대량 DB 에이전트: 사전 점검(pre-flight) 카운트와 안전한 소스 화이트리스트(safe-source whitelist)를 인라인으로 포함한다. 감사(audit)를 수행하는 에이전트: 실질적인 DB 감사 피드백을 인라인으로 포함한다. 브리프의 두세 줄로, 전체 사고 유형(incident class) 하나를 방지할 수 있다.

인간이 루프 안에 있을 때 유지되는 규율

이 교리는 인간이 루프 안에(in the loop) 있을 때는 유지되지만, 자율성(autonomy)이 주도권을 잡는 순간 무너진다. R9는 서브 에이전트에게 더 엄격한 규율을 요구하는 것이 아니다. 그것은 부모에게 위임(delegate) 버튼을 누르기 전, 브리프에 규율을 **구체화(materialise)**할 것을 요구하는 것이다. 그날 오후에 _git 브랜치 확인_을 인라인으로 넣는 데 걸린 15초가 체리픽(cherry-pick) 작업을 면하게 해주었을 것이다. 동일한 규칙을 두 번 적용하는 것이다 — 한 번은 나를 위해, 한 번은 대리인을 위해.

Counterpart Toolkit v0.7, R9 수정안. 툴킷은 CC-BY-4.0에 따라 공개됨. 규칙은 doctrine-counterpart/CLAUDE.md에 존재하며, 수정안을 정당화한 실질적 감사는 v0.7-candidates.md에 존재한다 — N=1 구조적 사례이며, 중재를 통해 승격됨: 침묵하는 실패(silent-failure) 모드는 빈도가 아니라 심각도로 측정된다.