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

어떤 부모도 허용하지 않았을 커밋

5월 18일, 늦은 오후. 나는 서브 에이전트(sub-agent)에게 첫 연락 자동 발송(autosend) 작업을 위임했다. 6개의 파일을 수정해야 하는 작업이었다. 브리프(brief)는 15줄 정도로 짧았고, '단계 0(phase 0)'을 명시했으며, 모든 INSERT 작업 이전에 감사(audit) 명령을 수행하도록 목록화했다. 45분 후 돌아온 결과는: main 브랜치에 커밋됨(committed to main). 나는 두 번 다시 읽었다. git log --oneline -5를 실행했고 3756e63을 찾아냈다. 브랜치도, PR(Pull Request)도, [workaround-assumed] 태그도 없이 기본 브랜치에 바로 박혀 있는 기능(feature) 커밋이었다. 마치 아무 일도 없었던 것처럼, 30분 동안 체리픽(cherry-pick)과 리셋(reset), 그리고 소급 PR을 진행해야 했다.

정말 화가 나는 점은, 이런 종류의 사고를 불과 열흘 전에 이미 겪었다는 것이다. 5월 14일, 이전의 git checkout이 두 작업 사이에서 조용히 취소된 후 나의 커밋이 잘못된 브랜치로 전송된 적이 있었다. 나는 그날 저녁 바로 규칙을 작성했다: feedback_git_branch_check_avant_commit.md. 두 문장으로 구성된 내용이었다: "사소하지 않은 모든 커밋을 하기 전에는 git branch --show-current를 입력할 것". 그 이후로 나는 기계적으로 이 규칙을 확인한다. 하지만 3756e63을 푸시한 서브 에이전트는 이 규칙을 한 번도 읽지 않았다.

부모의 메모리가 전달하지 못하는 것

나의 멘탈 모델(mental model)이 틀렸다. 나는 내가 확인하는 사용자 범위(user-scope)의 메모리—이 글을 쓰는 시점에 확인한 120개의 피드백—가 위임된 에이전트들에게 _상속(inheritance)_을 통해 내려가는 계층 구조를 상상했다. 마치 서브 에이전트를 호출하는 것이 이미 열려 있는 도구 상자를 건네주는 것이며, 그 안에 내 규칙들이 들어있는 것처럼 말이다.

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

혼자 작업하는 동안에는 이 비대칭성이 보이지 않는다. 부모(parent)가 자신의 메모리를 로드하고 규칙을 적용하면 시스템은 유지된다. 하지만 위임(delegation)이 시작되는 순간 이는 구조적 결함이 되며, 위임이 반복될수록 사고의 유형(class of incident)이 발생할 확률은 높아진다. 에이전트의 메모리는 상속(inheritance)을 통해 전달되지 않는다. 그것은 명시적인 브리핑(briefing)을 통해 전달되거나, 아니면 전혀 전달되지 않는다.

모든 피드백의 무게가 같은 것은 아니다

물론, 모든 피드백을 매번 브리프(brief)에 인라인(inline)으로 포함하는 것은 매 호출마다 전체 인덱스를 재구축하는 것과 같으며, 어떤 서브 에이전트(sub-agent)도 2,000단어에 달하는 브리프를 주의 깊게 읽지 않을 것이라는 반론이 있을 수 있다. 그 반론은 타당하며, 규칙 또한 그것을 요구하지 않는다.

내 피드백의 대부분은 동등하지 않다. 어떤 것들은 일반적이다. 예를 들어 프랑스어를 선호한다거나, 나의 커밋 서명(commit signature), 타이포그래피 취향 같은 것들이다. 반면 다른 피드백들은 위반 시 즉각적 혹은 지연된 사고를 유발하는 **구조적 불변량 (structural invariant)**을 담고 있다: 중요한 커밋(non-trivial commit) 전에는 반드시 브랜치를 확인할 것, 최근의 사전 확인 카운트(pre-flight count) 없이 대량 삭제(bulk DELETE)를 수행하지 말 것, 모든 계약 테스트(contract test) 전에 하드웨어 DB를 감사할 것 등이다. 이런 것들은 결코 건너뛰지 않는다. 기준은 한 문장으로 요약된다: 만약 부모가 해당 규칙을 건너뛰었을 때 피하려던 사고가 발생했을 것이라면, 그 피드백은 해당 작업에 대해 부하를 견디는 (load-bearing) 요소이다. 부모에게 복구 비용이 가치가 있다면, 그것은 위임받은 자에게도 브리핑할 가치가 있는 비용이다.

R9 수정안, 그 텍스트 내용

나는 툴킷(toolkit) 0.7 버전에서 다음과 같이 수정안을 제시했다:

R9 amendment — The brief must inline (or path-reference) the
user-scope feedbacks the parent treats as load-bearing for
this task. Sub-agents do not transitively inherit the parent's
...

세 가지 적용 사례가 있습니다. Git을 다루는 에이전트: 브랜치 체크 (branch-check) 피드백을 인라인 (inline)화 합니다. 대량 DB 작업 (bulk DB operations)을 다루는 에이전트: 사전 점검 카운트 (pre-flight count)와 안전한 소스 화이트리스트 (whitelist of safe sources)를 인라인화 합니다. 감사를 다루는 에이전트: 하드웨어 DB 감사 피드백을 인라인화 합니다. 두세 줄의 브리프 (brief)만으로 전체 유형의 사고를 방지할 수 있습니다.

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

이 교리 (doctrine)는 인간이 루프 안에 (in the loop) 있을 때는 유지되지만, 자율성 (autonomy)이 주도권을 잡는 순간 무너집니다. R9 수정안은 서브 에이전트 (sub-agent)에게 더 규율 있게 행동하라고 요구하는 것이 아닙니다. 그것은 환상에 불과합니다. 대신, 부모 에이전트가 위임 (delegate) 버튼을 클릭하기 전에 브리프 (brief) 안에 자신의 규율을 구체화 (materialize) 할 것을 요구합니다. 만약 그날 오후 브리프에 _git 브랜치 체크 (check git branch)_를 인라인화하는 데 15초만 할애했더라면, 30분간의 체리 픽 (cherry-pick) 작업을 아낄 수 있었을 것입니다. 동일한 규칙이 두 번 적용됩니다. 한 번은 나를 위해, 한 번은 수임자를 위해.

Counterpart Toolkit v0.7, R9 수정안. CC-BY-4.0 하의 공개 툴킷. 규칙은 doctrine-counterpart/CLAUDE.md에 존재하며, 수정안의 근거가 된 하드웨어 감사는 v0.7-candidates.md에 존재합니다 — 구조적 N=1, 중재 시 승격: 침묵하는 실패 (silent failure) 모드는 빈도가 아니라 심각도로 측정됩니다.