Claude Code로 프로젝트를 여러 개 굴리다 보니 서브에이전트가 계속 늘었습니다.

필요할 때마다 하나씩 만들었더니 22개가 됐습니다.

지난달에 17개로 줄였습니다.

그런데 접을 때 왜 접는지를 안 적어놨습니다.

3개월 뒤에 아카이브 폴더를 열어보니 왜 접었는지 알 수가 없었습니다.

다섯 개 중 사유가 적혀 있는 건 한 개뿐이었습니다.

만든 사람이 저 혼자인데도 그랬습니다.

왜 22개까지 갔나

늘릴 때는 이유가 항상 분명합니다. 필요하니까 만듭니다.

문제는 반대편입니다. 접을 때는 "혹시 나중에 쓸까" 가 계속 걸립니다.

쓸모가 없다는 확신이 안 서니까 그냥 둡니다. 그렇게 22개가 됐습니다.

지금 와서 보면 늘어난 원인은 하나였습니다.

"이건 에이전트가 아니라 도구여야 하는데"를 판단하는 게이트가 없었습니다.

반복 작업인데 절차가 고정되어 있고 맥락 판단이 필요 없다면, 그건 에이전트가 아닙니다.

스킬이나 스크립트로 만들면 됩니다. 토큰을 안 쓰고, 재현성이 100%이고, 세션이 바뀌어도 안 잊어버립니다.

이 게이트가 없으면 전부 에이전트가 됩니다.

접은 다섯 개

역산해보니 처분이 네 종류로 갈렸습니다. 이 구분이 중요했습니다.

하나는 애초에 에이전트가 아니어야 했습니다.

콘텐츠 작성을 맡던 것이었는데, 절차가 완전히 고정되어 있었습니다.

스킬 두 개로 대체하고 접었습니다. 이건 복원 금지로 못 박아뒀습니다.

안 그러면 언젠가 누가 다시 만듭니다.

셋은 다른 것과 역할이 겹쳤습니다.

보안 점검은 코드 감사와, 크론 감시는 헬스 체크와, 기획은 실행과 겹쳤습니다.

전부 같은 영역에 같은 권한이었습니다.

여기서 얻은 기준이 하나 있습니다.

두 에이전트가 같은 영역·같은 권한에서 겹치면,

분리를 유지하는 비용(관리 부하, 위임 판단 지연)이 이득을 넘습니다.

"둘 다 필요하긴 하다"는 감각이 오래 발목을 잡았는데,

필요한지가 아니라 분리해둘 값어치가 있는지를 물었어야 했습니다.

하나는 그냥 아무도 안 쓰고 있었습니다.

해당 기능 트래픽이 70일 동안 0건이었습니다.

이건 폐지가 아니라 휴면으로 처리했습니다. 서비스가 재개되면 그대로 복원합니다.

숫자를 적을 때 배운 것

22 → 17을 문서에 적으면서 한 가지를 깨달았습니다.

이 숫자가 파일 개수가 아닙니다. 운용 중인 에이전트 수입니다.

디렉토리 밖에 정의가 있는 것도 하나 있어서, 파일만 세면 21과 16이 나옵니다.

그래서 문서 맨 앞에 이 숫자가 무엇을 세는 숫자인지부터 적었습니다.

그리고 git ls-tree로 검증한 결과를 같이 넣었습니다.

안 그러면 나중에 누가 파일을 세보고 "안 맞는데요"에서 끝납니다.

숫자를 적을 때는 정의와 검증 방법을 같이 적어야 하더군요.

접을 때 지키기로 한 것

이번에 데인 걸로 규칙 네 개가 생겼습니다.

폐지 시점에 사유를 파일에 적는다. 안 적으면 3개월 뒤 역산해야 합니다. 실제로 그랬습니다.

삭제하지 않고 rename으로 옮긴다. 내용이 100% 보존돼서 원본 그대로 복원됩니다.

복원 금지 항목을 명시한다. 안 적으면 언젠가 누군가 되살립니다.

복원 절차에 "흡수처에서 중복 역할 제거"를 넣는다. 이걸 빼면 되살렸을 때 둘이 같은 일을 합니다.

같이 정리한 것들

이 김에 4년치 규칙을 묶어서 공개했습니다. 몇 개만 적어봅니다.

몰래 우회 금지

에이전트가 제약에 부딪혔을 때 뚫지 않고 보고하게 만드는 규칙입니다.

정당한 차단이면 그 단계만 보류하고 나머지를 계속 진행합니다.

오판으로 보이는 차단이어도 임의로 우회하지 않습니다. 근거를 정리해서 올리고 확인을 받습니다.

그리고 차단이 규칙 자체의 결함을 드러냈다면, 그 결함을 고치는 것까지가 대응입니다.

사실 이 규칙 자체가 그렇게 생겼습니다. 차단을 겪고 나서 만들었습니다.

FAIL을 PASS로 쓰지 않는다

지시로 종결하는 건이라도 실측 상태를 그대로 적고 재오픈 조건을 남깁니다.

보고는 Before/After 실측 수치로 하고, 잔여와 리스크를 성과보다 먼저 씁니다.

에이전트는 기본적으로 성공 보고를 하려는 압력을 받습니다. 규칙으로 막지 않으면 계속 그럽니다.

자율성을 정량 임계값으로 정의

"수정 허용/금지" 이분법 대신, 분석형 에이전트가 스스로 고칠 수 있는 범위를 숫자로 정했습니다.

1파일만

5줄 미만

상위 등급 파일 아님

임팩트 점수 임계값 미만

모두 충족(AND) 이고, 하나라도 걸리면 상신합니다.

그리고 마지막 조항이 핵심입니다 — 애매하면 위임 요청. 기본값이 보수적이어야 규칙이 안 무너집니다.

판정과 집행의 분리

검증·조사는 읽기 전용 서브에이전트로 병렬 팬아웃하고,

파일·DB 집행은 오케스트레이터가 중앙에서 직렬로 처리합니다.

공유 파일을 여러 에이전트가 동시에 수정하면 반드시 깨지기 때문입니다.

대가는 있습니다. 대규모 작업에서 중앙 직렬은 병목입니다.

느려지는 걸 알면서도 충돌보다는 낫다고 판단한 결과입니다.

저장소

마크다운 파일 몇 개입니다. 설치할 게 없습니다.

템플릿을 .claude/agents/ 아래에 두고 필요한 부분만 채우시면 됩니다.

하나의 정답이라기보다, 이 환경에서 4년간 작동한 방식입니다.

팀 규모나 프로젝트 성격에 따라 안 맞을 수 있습니다.

늘리는 이야기는 많은데 줄이는 이야기는 잘 없더군요.

비슷하게 에이전트가 불어나고 계신 분들에게 참고가 되면 좋겠습니다.