에이전트를 22개까지 늘렸다가 17개로 줄인 이야기 — AI 코딩 에이전트 정리와 운영 원칙

에이전트는 왜 계속 늘어나는가

Claude Code로 프로젝트를 여러 개 굴리다 보니 서브에이전트가 계속 늘었습니다. 필요할 때마다 하나씩 만들었더니 22개가 됐습니다. 지난달에 17개로 줄였습니다. 그런데 접을 때 왜 접는지를 안 적어놨습니다. 3개월 뒤에 아카이브 폴더를 열어보니 왜 접었는지 알 수가 없었습니다…

AI 코딩 도구를 여러 프로젝트에 적용하다 보면 서브에이전트와 자동화 스크립트가 자연스럽게 늘어납니다. 처음에는 각각의 역할이 분명합니다. 테스트를 돌리는 에이전트, 코드를 검토하는 에이전트, 문서를 갱신하는 에이전트처럼 필요에 맞춰 하나씩 추가합니다. 문제는 추가하는 순간보다 정리해야 하는 순간에 드러납니다.

새 에이전트를 만드는 일에는 즉각적인 보상이 있지만, 없애는 일에는 확신이 필요합니다. 혹시 나중에 다시 쓸지 모른다는 생각 때문에 사용하지 않는 항목이 남고, 결국 이름과 역할을 기억하는 비용이 작업 자체의 비용을 넘어섭니다.

22개에서 17개로 줄일 때 보이는 핵심 문제

에이전트 수를 줄이는 일은 단순한 파일 삭제가 아닙니다. 각 에이전트가 어떤 문제를 해결하려고 만들어졌는지, 현재도 그 문제가 존재하는지, 다른 도구와 역할이 겹치는지를 확인해야 합니다. 특히 과거의 결정 이유가 기록되어 있지 않으면 같은 에이전트를 몇 달 뒤 다시 만들 가능성이 커집니다.

정리할 때 확인할 네 가지 질문

1. 최근 사용 시점: 마지막으로 실제 작업에 호출된 날짜가 언제인가?
2. 고유한 역할: 다른 에이전트나 일반 스크립트로 대체할 수 없는가?
3. 입출력 계약: 입력과 결과 형식이 명확하고 재현 가능한가?
4. 유지 비용: 모델 변경이나 프로젝트 구조 변경 때 계속 수정해야 하는가?

만들 때부터 폐기 경로를 설계하라

가장 실용적인 해법은 에이전트를 추가할 때부터 폐기 조건을 함께 적는 것입니다. 이름, 목적, 입력, 출력, 소유 프로젝트만 적는 것으로는 부족합니다. 어떤 상황에서 이 에이전트를 없애거나 다른 도구로 합칠지까지 기록해야 목록이 살아 있는 운영 문서가 됩니다.

name: test-reviewer
purpose: 변경된 테스트와 회귀 위험을 검토
owner: project-alpha
created: 2026-07-27
retire_when:
  - review workflow가 CI 기본 단계로 통합됨
  - 30일 동안 호출 기록이 없음
review_every: 30d

이처럼 폐기 조건을 선언적으로 적어 두면 정리 작업이 감정이나 기억에 의존하지 않습니다. 호출 기록과 조건을 비교해 후보를 만들고, 실제 삭제 전에는 마지막 사용자와 대체 경로만 확인하면 됩니다.

17개가 22개보다 나은 이유

에이전트 수가 적다고 항상 좋은 것은 아니지만, 역할의 경계가 선명해지면 전체 시스템의 예측 가능성이 높아집니다. 어떤 에이전트를 호출해야 할지 판단하는 시간이 줄고, 서로 다른 에이전트가 같은 파일을 동시에 수정하는 충돌도 줄어듭니다.

• 탐색 비용 감소: 이름과 설명만 보고 적절한 도구를 고를 수 있습니다.
• 맥락 품질 향상: 각 에이전트에 전달되는 규칙과 예시를 더 구체화할 수 있습니다.
• 실패 분석 단순화: 문제가 생겼을 때 원인 후보가 적어집니다.
• 변경 전파 예측: 프로젝트 구조가 바뀌어도 수정할 지점이 명확합니다.

실전 운영 체크리스트

에이전트 목록을 한 번 정리한 뒤에는 주기적인 점검을 자동화하는 편이 좋습니다. 매달 한 번 모든 항목을 대상으로 아래 순서를 반복하면 다시 22개로 불어나는 일을 막을 수 있습니다.

1. 호출 로그에서 지난 30일 사용량을 집계합니다.
2. 역할이 겹치는 에이전트를 묶어 하나의 계약으로 합칠 수 있는지 봅니다.
3. 각 항목의 폐기 사유와 대체 경로를 기록합니다.
4. 삭제 대신 먼저 아카이브하고, 일정 기간 뒤 복구 요청이 없는지 확인합니다.
5. 정리 결과와 판단 근거를 changelog에 남깁니다.

마무리 — 줄이는 기술이 곧 운영 기술이다

AI 에이전트 시스템의 성숙도는 얼마나 많이 만들었는지가 아니라, 왜 남겼고 왜 없앴는지를 설명할 수 있는지로 드러납니다. 22개를 17개로 줄인 경험에서 얻는 핵심은 특정 숫자가 아닙니다. 추가와 폐기를 같은 수준의 설계 행위로 다루고, 결정의 이유를 다음 달의 나에게 전달하는 습관입니다.

핵심 요약

• 에이전트는 필요할 때보다 정리할 때 운영 비용이 드러납니다.
• 추가 시점에 역할, 사용 기한, 폐기 조건을 함께 기록해야 합니다.
• 호출 로그와 역할 중복을 기준으로 정기적인 아카이빙을 수행하세요.

---

📰 원본 출처 · https://news.hada.io/topic?id=31873 (#N=31873)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.