CLAUDE.md를 마지막으로 처음부터 끝까지 읽은 게 언제인가. 팀에서 에이전트를 실제로 운영하다 보면, 이 파일은 어느 순간부터 아무도 전체를 읽지 않는 문서가 된다. 각자 자기 섹션을 찾아서 규칙을 추가하고, PR을 올리고, 리뷰어는 "이 규칙 맞다"고 승인한다. 그렇게 6개월이 지나면 서로 충돌하는 두 규칙이 조용히 공존하고, 에이전트는 파일 순서상 먼저 나오는 쪽을 묵묵히 따른다. 나머지 규칙은 사실상 죽어 있다.
dev.to에 올라온 "Harness Debt"는 이 현상에 이름을 붙인다. 하네스 부채(Harness Debt). 기술 부채의 코드 버전이 아니라, 에이전트를 조종하는 규칙 문서 자체가 쌓아가는 부채다. 형태는 네 가지다. 서로 모르는 채 추가된 모순 규칙, 참조 대상이 사라진 고아 규칙, 왜 만들었는지 아무도 기억 못 하는 근거 없는 규칙, 코드베이스는 바뀌었는데 규칙은 그대로인 시대착오 규칙. 이 네 가지가 복리로 쌓인다. 한 규칙이 추가될수록 다음 규칙이 기존 것과 충돌할 확률이 올라간다.
더 까다로운 건 이 부채가 신호 없이 쌓인다는 점이다. 하네스에는 실패하는 테스트가 없다. CI 파이프라인이 고아 참조를 잡아주지 않는다. "이 규칙이 마지막으로 발동된 게 언제야?"를 알려주는 메트릭도 없다. 팀이 신뢰하는 문서 안에서 부채가 쌓이기 때문에, 그 신뢰 자체가 탐지를 막는다. 각 규칙은 추가될 때 개별 심사를 통과했다. 심사 질문은 "이 규칙이 좋은가"였지, "기존 파일과 충돌하지 않는가"가 아니었다. 리뷰 비용은 로컬하고, 부채 비용은 글로벌하다. 이 미스매치가 부채 생산 메커니즘이다.
처방은 생각보다 단순하다. 분기에 한 번, 2시간짜리 감사(audit). 파일을 처음부터 끝까지 읽는다. 스키밍이 아니라 읽기다. 모든 파일 경로·함수명·툴 참조를 코드베이스와 grep으로 대조한다. 각 규칙에 대해 "최근 6개월 안에 발동된 적 있나"를 확인한다. 조용한 규칙이 있다면 이유를 따진다—에이전트가 잘 따르고 있어서인지, 아니면 애초에 의미를 잃었는지. 그리고 각 규칙마다 한 줄짜리 출처 주석을 달아둔다. "analytics 모듈 import 경로 오류 이후 추가." 세 문단 설명도, 썩어가는 PR 링크도 필요 없다. 다음 유지보수자가 "이 사고가 아직도 가능한가"를 판단할 수 있으면 충분하다.
그런데 규칙 문서 관리만으로 충분한가. 팀 규모가 커지고 멀티에이전트 구조를 도입하는 순간, 문제는 한 차원 올라간다. dev.to의 또 다른 글 "The decision-making layer your multi-agent Claude Code stack is missing"은 다른 진단을 내놓는다. 대부분의 멀티에이전트 스택에는 플래너 LLM과 N개의 서브에이전트가 있지만, 그 앞에서 '어떻게 생각할 것인가'를 결정하는 계층이 없다는 것이다.
이 글이 제안하는 구조의 핵심은 Cynefin 분류를 모든 작업의 첫 번째 라우팅 결정으로 삼는 것이다. 문제가 명확(Clear)한지, 복잡하지만 분석 가능(Complicated)한지, 불확실성이 지배하는(Complex)인지, 아니면 혼돈(Chaotic)인지를 먼저 판단하고, 그 분류에 따라 태스크 분해 전략이 달라진다. Complex 문제에 기능 단위 분해를 적용하면 에이전트는 잘못된 모양의 태스크 트리를 만들고, 팀은 그 결과를 보면서 "왜 이렇게 나왔지?"를 반복한다. 플래너가 자유롭게 태스크 트리를 생성하도록 두는 건, CLAUDE.md에 모순 규칙을 방치하는 것과 같은 구조적 방치다.
두 글이 함께 가리키는 지점은 결국 하나다. 에이전트가 실패할 때, 그 원인은 대부분 모델 바깥—규칙 문서의 부패, 의사결정 계층의 부재—에 있다. 규칙이 충돌하면 에이전트는 틀린 행동을 자신 있게 한다. 태스크 분류 없이 플래너를 돌리면 에이전트는 잘못된 방향으로 빠르게 달린다. 두 경우 모두 에이전트는 아무 잘못이 없다. 구조가 에이전트를 실패하게 만들고 있다.
여기서 AI가 대체할 수 없는 영역이 드러난다. "AI Won't Replace Humans"의 표현을 빌리자면, 자동화되는 건 타이핑이지 결정이 아니다. CLAUDE.md의 어떤 규칙이 지금도 유효한지, 이번 태스크가 Complex인지 Complicated인지를 판단하는 건 에이전트가 할 수 없다. 에이전트는 그 판단의 결과물을 실행하는 존재다. 새벽 2시 프로덕션 장애 전화를 받는 건 에이전트가 아니라 팀 리드이고, 규칙 문서가 썩어있을 때 책임을 지는 것도 팀이다.
테크 리드로서 지금 당장 할 수 있는 두 가지가 있다. 첫째, 이번 분기 안에 CLAUDE.md를 처음부터 끝까지 읽어라. 모순을 찾고, 고아를 제거하고, 출처가 없는 규칙에 한 줄짜리 주석을 달아라. 규칙을 추가하는 것보다 삭제하는 결정이 더 어렵지만, 내가 추가한 규칙을 지우는 기준은 하나다—"이 규칙을 지금 삭제하면 다음 PR에서 같은 실수가 재현되는가." 테스트나 린트가 잡아준다면, 그 규칙은 이미 발판(scaffolding)이 됐고 제거해도 된다. 둘째, 멀티에이전트 워크플로우를 도입했거나 계획 중이라면, 플래너가 태스크 트리를 만들기 전에 문제의 성격을 분류하는 단계를 넣어라. 이 단계 없이 에이전트를 병렬로 늘리면 잘못된 방향으로 빠르게 달리는 에이전트만 늘어난다.
에이전트 거버넌스는 도구를 켜는 순간이 아니라, 규칙 문서를 정원처럼 가꾸는 루틴과 의사결정 계층을 설계하는 구조에서 완성된다. AI-First 팀의 기술 부채는 코드에만 쌓이지 않는다. 에이전트를 조종하는 문서와 계층 설계에도 똑같이 쌓인다. 그리고 그걸 관리하는 건 여전히, 사람의 일이다.