에이전트를 22개까지 늘렸다가 17개로 줄인 이야기

Claude Code로 프로젝트를 여러 개 굴리다 보니 서브에이전트가 계속 늘었습니다. 필요할 때마다 하나씩 만들었더니 22개가 됐습니다. 지난달에 17개로 줄였습니다. 그런데 접을 때 왜 접는지를 안 적어놨습니다. 3개월 뒤에 아카이브 폴더를 열어보니 왜 접었는지 알 수가 없었습니다. 다섯 개 중 사유가 적혀 있는 건 한 개뿐이었습니다. 만든 사람이 저 혼자인데도 그랬습니다. 왜 22개까지 갔나 늘릴 때는 이유가 항상 분명합니다. 필요하니까 만듭니다. 문제는 반대편입니다. 접을 때는 "혹시 나중에 쓸까" 가 계속 걸립니다. 쓸모가 없다는 확신이 안 서니까 그냥 둡니다. 그렇게 22개가 됐습니다. 지금 와서 보면 늘어난 원인은 하나였습니다. "이건 에이전트가 아니라 도구여야 하는데"를 판단하는 게이트가 없었습니다. 반복 작업인데 절차가 고정되어 있고 맥락 판단이 필요 없다면, 그건 에이전트가 아닙니다. 스킬이나 스크립트로 만들면 됩니다. 토큰을 안 쓰고, 재현성이 100%이고, 세션이 바뀌어도 안 잊어버립니다. 이 게이트가 없으면 전부 에이전트가 됩니다. 접은 다섯 개 역산해보니 처분이 네 종류로 갈렸습니다. 이 구분이 중요했습니다. 하나는 애초에 에이전트가 아니어야 했습니다. 콘텐츠 작성을 맡던 것이었는데, 절차가 완전히 고정되어 있었습니다. 스킬 두 개로 대체하고 접었습니다. 이건 복원 금지로 못 박아뒀습니다. 안 그러면 언젠가 누가 다시 만듭니다. 셋은 다른 것과 역할이 겹쳤습니다. 보안 점검은 코드 감사와, 크론 감시는 헬스 체크와, 기획은 실행과 겹쳤습니다. 전부 같은 영역에 같은 권한이었습니다. 여기서 얻은 기준이 하나 있습니다. 두 에이전트가 같은 영역·같은 권한에서 겹치면, 분리를 유지하는 비용(관리 부하, 위임 판단 지연)이 이득을 넘습니다. "둘 다 필요하긴 하다"는 감각이 오래 발목을 잡았는데, 필요한지가 아니라 분리해둘 값어치가 있는지를 물었어야 했습니다. 하나는 그냥 아무도 안 쓰고 있었습니다. 해당 기능 트래픽이 70일 동안 0건이었습니다. 이건 폐지가 아니라 휴면으로 처리했습니다. 서비스가 재개되면 그대로 복원합니다. 숫자를 적을 때 배운 것 22 → 17을 문서에 적으면서 한 가지를 깨달았습니다. 이 숫자가 파일 개수가 아닙니다. 운용 중인 에이전트 수입니다. 디렉토리 밖에 정의가 있는 것도 하나 있어서, 파일만 세면 21과 16이 나옵니다. 그래서 문서 맨 앞에 이 숫자가 무엇을 ...