에이전트 개수는 자산이 아니라 부채로 시작한다 — 개발조직에 옮길 것과 비어 있는 여섯 자리

첫 편이 서른 개를 펼쳤고 두 번째 편이 그 서른 개가 어떻게 쓰였는지를 봤다. 남은 질문은 하나다. 이 중 무엇을 실제로 가져다 쓰는가.

이 글은 그 답을 세 갈래로 나눠 낸다. 개발기술 부서 4종을 자세히 보고, 나머지 부서의 에이전트 중 개발조직 실무로 옮길 수 있는 것과 참고만 할 것을 가르고, 마지막으로 이 세트에 아예 자리가 없는 영역 여섯 개를 짚는다. 원 자료는 무엇이 없는지를 아는 것이 있는 것을 아는 것만큼 값이 있다고 적는다.

이 시리즈가 30종 중 개발기술 4종만 자세히 보는 이유는 단순하다. 이 카테고리가 다루는 것이 Claude Code로 짓는 개발 워크플로이고, 일곱 부서 중 거기 해당하는 것이 개발기술 하나다. 나머지 여섯 부서(영업·마케팅·고객지원·인사노무·재무회계·기획전략)의 부서별 상세는 이 시리즈에서 다루지 않는다 — 첫 편의 카탈로그가 30종 전부를 한 줄씩 담고 있으니 전체 지형은 거기서 보면 된다.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이다. 임계값·기준 수치는 그 시점의 것이며 조직과 스택에 따라 달라진다.

아래의 정량 기준(에러율 5%, OKR 0.7, 캐파 80%, 도입 순서의 5개·+10개, 회고 2주)은 원 자료가 제시한 기준선이며 이 글이 측정하거나 특정 조직에서 관측한 값이 아니다.

용어 정리

첫 편의 용어표에서 이 글이 쓰는 행만 추렸다. 본문이 한글로 풀어 쓰더라도 원 자료의 표에 영문 약어로 등장하는 것은 남겼다. ★를 붙인 마지막 행(few-shot)은 첫 편의 용어표에 없고 두 번째 편이 더한 행이다.

개발기술 4종

부서 안의 위임 흐름은 이렇다.

네 에이전트를 잇는 화살표는 넷이고, 그중 하나(deploy-manager → debug-assistant)만 거꾸로 간다. 롤백이 일어났을 때 원인 분석으로 되돌아가는 경로다. 첫 편이 부서 횡단 파이프라인에서 「순환 구조가 있어야 개선 루프가 생긴다」고 본 것과 같은 형태가 부서 안에도 들어가 있다.

에이전트 요약

네 행 모두 「명시된 안전장치」 칸이 비어 있지 않다는 점이 눈에 띈다. 앞 편이 본 30종 준수 현황에서 외부 발송 앞 승인 게이트는 3 / 30이었고 그 셋은 sales-followup·cs-responder·expense-processor였다 — 개발 4종은 거기 들어 있지 않다. 대신 이 넷의 안전장치는 사람 승인이 아니라 임계값과 순서로 걸려 있다. 에러율 5% 초과 시 자동 롤백, fix 전에 실패 테스트 먼저, 코드와 문서는 같은 PR. 두 표를 이렇게 대 보는 것은 이 글의 정리다.

특징적인 프롬프트 설계 기법

• 심각도 등급이 곧 게이트다. BLOCKER/CRITICAL은 의무, SUGGESTION/NIT는 선택으로 명시하고, 리뷰 말미에 "머지 가능?" 결론을 강제한다. 리뷰 결과가 애매하게 끝나는 것을 막는다.
• 행동 경계를 역할 정의에 새긴다. "의료 영상 판독의 — 직접 치료하지 않는다"라는 비유로 "고치지 말고 짚어라"를 각인했다. 비유가 권한 제약으로 기능하는 사례다.
• 추론 과정을 예시로 완주해서 보여 준다. 5 Whys를 실제 결제 버그에 적용해 Why 1부터 5까지 답까지 써 두었다. 결과가 아니라 사고 경로를 few-shot으로 준 것이다.
• 해결책을 3층으로 분리한다. 즉시 패치(5분) / 근본 수정(1시간) / 재발 방지(테스트·체크리스트·메트릭). 장애 대응의 시간 축을 산출물 구조에 반영했다.
• 자동 판정 임계를 배포에 건다. "에러율 5% 초과 또는 응답 시간 2배 → 자동 롤백". 사람이 지켜보지 않아도 되게 만드는 조건을 숫자로 못박았다.
• 부정 규칙을 명시한다. "금요일 오후 배포 금지", "DB 마이그레이션은 별도 PR", "되돌릴 수 없는 배포 금지". 조직 운영 규범을 에이전트에 이식한 형태다.
• 문서 부채를 구조로 막는다. "코드만 머지하고 문서는 나중 → 영원히 안 함"이라는 진단과 함께 "같은 PR에 포함"을 규칙화했다.

두 번째 항목이 이 일곱 중 가장 옮기기 쉬운 기법이다. 비유 한 줄이 권한 제약으로 기능한다는 것은 정의서에 ## 권한 절을 따로 만들지 않고도 행동 범위를 좁힐 수 있다는 뜻이고, 앞 편이 본 대로 30종 전부가 역할 정의를 비유로 시작하므로 자리도 이미 있다.

개발조직으로 옮길 것

30종 전부가 개발조직에 그대로 유효하지는 않다. 1인 기업 전제가 강한 것(급여·기장·SNS 운영)은 조직 규모가 커지면 전용 시스템이 대체한다. 아래는 원 자료가 개발조직 리더의 실무에 그대로 옮길 수 있는 것만 고른 목록이다.

열 행의 「응용 아이디어」 열은 하나같이 사람 팀이 미리 정해 두고 반복해서 따르는 틀을 목적지로 지목한다 — 옮기는 것이 에이전트가 아니라 그 에이전트가 강제하던 틀이라는 뜻이고, 이렇게 읽는 것은 이 글의 정리다. 목적지를 그대로 옮기면 이렇다: 팀 리뷰 규약(code-reviewer) · 포스트모템 템플릿(debug-assistant) · 배포 파이프라인 규약(deploy-manager) · 팀 컨벤션(doc-updater) · 온콜 정책(escalation-router) · 팀 운영 루틴(performance-reviewer) · JD와 질문 세트(recruiter) · 팀 대시보드 설계(kpi-analyst) · 기술 기획 문서의 필수 항목(product-strategist) · 분기 계획 포맷(roadmap-planner). 열 중 열이다.

참고만 하고 그대로 쓰지 않을 것

표의 「이유」 열은 첫 행에 틀렸을 때의 책임(법·요율)과 함께 기업 규모에서는 전용 시스템이 담당한다는 것을, 둘째 행에 1인 기업 운영 전제를, 셋째 행에 이미 그 일을 하는 제품(CRM)이 있다는 것을 적는다. 사유가 행마다 하나씩 갈리지는 않는다 — 「대신 하는 시스템·제품이 있다」는 첫 행(전용 시스템)과 셋째 행(CRM 제품)에 함께 나온다. 앞 절 서두는 급여·기장·SNS 운영을 묶어 「1인 기업 전제가 강한 것」이라 불렀는데, 급여·기장은 첫 행이고 SNS 운영은 둘째 행이다. 표가 「1인 기업」이라고 적어 둔 것은 둘째 행이다 — 산문과 표의 배정이 갈리는 자리다. 그런데 뒤의 두 행에는 재사용 가능한 부분이 단서로 남는다 — 둘째 행은 「다만 임계값 테이블 설계 방식은 다른 도메인에 이식 가능」이고, 셋째 행은 「6차원 가중 스코어링 구조만 다른 판정 업무에 재사용」이다. 버리는 것은 도메인이고 남기는 것은 판정 구조다. 세 행을 이렇게 갈라 읽는 것은 이 글의 정리다.

스키마 자체의 재사용

원 자료가 개별 에이전트보다 값이 크다고 본 것은 스키마 쪽이다 — 개별 에이전트보다 정의서 공통 스키마를 사내 표준으로 삼는 것이 가치가 크다는 것이다. 원문은 이 자리에서 앞 편이 다룬 스키마 절을 절 번호로 가리키는데, 이 글에서는 그 편으로 가는 링크로 바꿔 두었다.

팀원이 각자 에이전트를 만들 때 다음 3가지만 강제해도 품질이 크게 균질해진다는 것이 원 자료의 주장이다.

• tools는 필요한 것만 — 기본값으로 전체 권한을 주지 않는다
• ## 산출물 예시에 완성본 1건 — 골격만 두면 출력이 매번 달라진다
• ## 경계 (위임) 필수 — 없으면 에이전트가 무한히 영역을 넓힌다

세 항목이 앞 편의 준수 현황표에서 받은 성적이 갈린다는 점을 붙여 읽어야 한다. 둘째(완성 산출물 예시)와 셋째(경계 섹션 존재)는 둘 다 30 / 30이었고, 첫째(도구 권한 축소)만 5 / 30이었다. 세 가지를 강제하자는 제안에서 실제로 강제가 필요했던 것은 첫 번째 하나였다는 뜻이다 — 이 대조는 이 글의 정리다. 나머지 둘은 강제하지 않아도 템플릿이 복제해 줬다.

파이프라인 조합 패턴

원 자료는 단독 호출보다 조합을 강조한다. 여기서 뽑아낼 수 있는 재사용 가능한 패턴은 세 가지다.

세 패턴 중 앞의 둘은 한 건을 처리하는 방법이고 셋째만 다음 건이 덜 들어오게 하는 방법이다. 선별형과 게이트형은 입력이 100건이면 100번 돌고, 승격형만 100번째에 유입 자체를 줄인다.

승격형이 가장 과소평가된 패턴이다. 개별 처리를 아무리 자동화해도 총량은 줄지 않는다. 반복을 감지해 자산으로 올려야 유입 자체가 줄어든다.

단계적 도입 순서

원 자료가 제시한 도입 순서는 "핵심 5개 → 10개 추가 → 나머지"다. 이 순서 자체보다 왜 한 번에 다 깔지 않는가가 요점이다.

네 행 중 마지막 행만 「개수」 칸이 비어 있다. 앞의 셋이 무엇을 얼마나 설치하는가를 정하는 행이라면 회고 행은 설치한 것을 도로 줄이는 행이라 개수를 적을 자리가 없다.

한 번에 전부 설치하면 트리거 키워드가 겹쳐 호출 정확도가 떨어진다. 에이전트 개수는 자산이 아니라 부채로 시작한다는 관점이 이 순서의 근거다.

근거가 조직론이 아니라 기술적 이유라는 점이 이 표에서 볼 것이다. 에이전트를 한꺼번에 늘리지 말라는 이유가 "팀이 감당 못 한다"가 아니라 "트리거 키워드가 겹쳐 라우팅이 틀린다"다. 이 카테고리의 잠재 경로는 개수의 제곱으로 는다 편이 같은 현상을 개수 구간별로 훨씬 자세히 다룬다.

같은 「한 번에 다 하지 않는다」를 조직 층위에서 다룬 글로는 AI 전환 실행 항목이 있다. 같은 이야기가 아니라 층위가 다른 이야기다 — 이쪽은 파일 몇 개를 설치할지를 개수로 끊고 근거가 트리거 키워드 충돌이며, 저쪽은 조직 프로그램의 실행 순서를 일수로 끊고 근거가 기준선 없는 파일럿은 성과를 증명하지 못한다는 것이다. 겹치는 것은 점진성 하나뿐이다 — 두 글을 이렇게 대 보는 것은 이 글의 정리다.

비어 있는 여섯 자리

30종은 1인 기업~10인 스타트업 기준으로 설계됐다. 개발조직 관점에서 보면 비어 있는 자리가 뚜렷하다.

여섯 행의 「왜 필요한가」 열이 전부 같은 형태로 적혀 있다는 점이 이 표에서 가장 눈에 띈다 — 30종 안의 다른 에이전트나 부서를 지목하고 「거기까지 하고 멈춘다」고 적는다. 여섯을 하나씩 배정하면 code-reviewer(보안 리뷰) · debug-assistant(테스트 설계) · doc-updater(아키텍처 결정) · 재무 4종(인프라 비용) · kpi-analyst(데이터 품질) · escalation-router(온콜·인시던트 지휘)로, 여섯 중 여섯이다. 이 배정과 그 관찰은 이 글이 표를 읽어 한 것이다.

그 바로 아래에서 원 자료는 이 여섯을 다른 축으로 묶는다.

이 공백들은 우연이 아니다. 모두 "혼자서는 감당할 수 없어 조직이 커진 뒤에야 필요해지는" 영역이다.

즉 이 세트는 조직 규모에 대한 가정이 설계에 박혀 있다. 템플릿을 그대로 쓰지 않고 조직 단계에 맞춰 재구성해야 하는 이유가 여기 있다.

여섯을 조직 규모로 묶는 이 판정은 원 자료의 것이고, 이 글은 그것을 승계하지도 반박하지도 않는다. 위 표에서 확인되는 것은 여섯 행이 전부 30종 내부의 다른 에이전트나 부서를 기준으로 서술됐다는 사실까지다.

두 번째 행은 첫 편에서 이미 한 번 쓰였다. 이 카테고리의 다른 글에 실린 7부서 30에이전트 표와 이 시리즈의 카탈로그가 같은 세트가 아니라는 근거가 정확히 이 문장이다 — 그쪽 표에는 개발 부서 넷 중 하나가 「테스트」인데, 이쪽 원 자료는 30종 중 테스트를 만드는 에이전트가 없다고 적는다.

시리즈를 닫으며

세 편을 관통하는 것은 하나다. 에이전트 세트의 값어치는 개수가 아니라 형식에 있다.

첫 편은 서른 개를 한 장의 표로 펼쳤고, 거기서 나온 것은 개수가 아니라 권한을 좁힌 자리와 좁히지 못한 자리(Bash 한 구멍)였다. 두 번째 편은 그 서른 개가 공유하는 스키마를 봤고, 형식은 30 / 30으로 복제되는데 안전장치는 복제되지 않는다는 것을 확인했다. 그리고 이 글에서 개발조직으로 옮기기로 한 열 가지는 전부 에이전트가 아니라 그 에이전트가 강제하던 틀이었다.

마지막 표는 그 서른 개의 바깥을 적는다. 비어 있는 여섯 자리는 무엇을 더 만들지의 목록이기 이전에, 가진 세트의 경계가 어디까지인지를 적어 둔 문서다. 앞 편이 본 대로 경계 섹션이 실재하지 않는 이름을 지목했을 때 에이전트는 실패하거나 스스로 처리해 버린다. 세트 전체에도 같은 것이 필요하다 — 없는 것을 없다고 적어 두면, 그 요청이 들어왔을 때 사람에게 온다.