부서 이름을 지우면 같은 5단계가 남는다 — 7부서 30에이전트의 공통 골격

부서 하나를 자동화하는 일과, 일곱 부서를 한 벌로 설계하는 일은 다른 문제다. 부서마다 따로 만들면 계약이 제각각이 되고, 같은 실패를 부서마다 다시 겪고, "이건 사람이 봐야 하는가"의 기준선이 부서마다 다른 곳에 그어진다.

이 시리즈는 원 자료가 다룬 일곱 개 부서 서른 개 에이전트 한 벌을 자료로 세 편에 걸쳐 그 문제를 본다. 첫 편인 이 글은 골격이다 — 부서 이름을 지우고 남는 것, 즉 일곱 파이프라인이 공유하는 다섯 단계와 그 위에 얹히는 열 개의 설계 패턴이다. 2편은 마케팅·영업·고객지원·인사 네 부서의 각론을, 3편은 재무·법무·경영지원 세 부서와 새 업무를 에이전트로 쪼개는 절차를 다룬다.

이 글에서 가장 오래 남는 관찰을 먼저 적어 둔다. 부서 이름을 지우면 일곱 개 파이프라인이 같은 다섯 단계로 겹친다. 부서별 각론이 달라 보이는 것은 같은 칸에 다른 이름이 들어가 있기 때문이고, 새 업무를 만났을 때 채워야 할 칸은 언제나 그 다섯이다.

용어 정리

시리즈 세 편이 공유하는 어휘 서른네 개다 — 원 자료 용어표의 서른세 개에 이 글이 「품질 루프」를 더했다. 원 자료는 이 목록을 한 표에 두고 마지막 열로 어느 부서에서 쓰이는지를 가리켰는데, 세 편으로 나뉘면서 그 열이 가리키던 절 번호가 무효가 된다. 아래에서는 이 글이 쓰는 행과 나머지를 갈라 싣고, 앞쪽 표에만 이 글 기준의 쓰임을 적었다.

이 글이 쓰는 용어

원 자료 용어표의 나머지

아래 열여섯 개는 이 글의 본문에서는 쓰이지 않는다. 원 자료가 부서별 각론에 배정한 어휘이며, 여기에 색인으로 둔다.

7개 부서 30개 에이전트 지도

원 자료는 7개 부서를 각각 "N인 팀 → N개 에이전트"로 치환한다. 부서별 인원수가 곧 에이전트 수는 아니며, 하나의 결정 단위가 하나의 에이전트가 된다.

총계가 30인 세 번째 표다

이 지도를 읽기 전에 짚어 둘 것이 있다. 이 블로그에 총계 30인 7부서 에이전트 표가 이미 두 번 실렸고, 위 지도는 그 둘과 같은 세트가 아니다.

셋 다 합계가 30이고 부서 수도 일곱으로 같은데, 일곱 개의 이름과 배분이 서로 다르다. C에만 법무부가 있고, C에는 개발 부서가 없다. 배분도 갈린다 — A·B는 다섯 부서가 4이고 두 부서가 5인데 그 두 부서가 마케팅·영업인 반면, C에서 5를 받은 두 부서는 마케팅과 경영지원이고 영업은 4다.

A와 B가 서로 다른 세트라는 것은 카탈로그 편의 「개수가 같다고 같은 세트는 아니다」 절이 이미 표기·열 구성·구성이 갈리는 자리 세 곳을 대 보아 밝혀 두었다. 이 글이 더하는 것은 셋째 판본이 있다는 사실 하나다 — 총계 30을 동일성의 증거로 읽으면 세 개의 서로 다른 조직도가 하나로 뭉개진다. 어느 편성이 옳은지는 이 글도 가리지 않는다. 확인되는 것은 세 표가 같은 조직도의 세 판본이 아니라는 사실까지다.

부서별 병목과 배울 설계 요소

각 부서가 자동화로 해결하려는 병목과, 그 부서 설계에서 가장 배울 점을 한 줄로 정리한다.

오른쪽 열이 이 시리즈의 목차 역할을 한다 — 2편이 위 네 행을, 3편이 아래 세 행을 각각 파이프라인 단위로 편다.

실습 환경의 공통 전제

일곱 개 부서 실습 폴더는 모두 가상 회사 "감마컴"(50인 B2B IT 컨설팅) 컨텍스트를 공유한다. 부서마다 폴더 하나, 폴더마다 CLAUDE.md 하나, .claude/agents/ 아래 에이전트 정의 파일이 놓인다.

마지막 행이 뒤에 나오는 권한·격리 설계의 전제다. 부서 간 직접 호출을 막아 두었기 때문에 부서를 넘는 업무는 반드시 오케스트레이터를 거친다.

부서 이름을 지우면 같은 5단계가 남는다

부서 이름을 지우고 보면 7개 파이프라인은 같은 5단계를 반복한다.

검수·게이트에서 갈라지는 두 화살표가 이 골격의 핵심이다. 기준 미달이면 생성 단계로 되돌아가고(품질 루프), 위험이 감지되면 사람으로 빠진다(HITL). 같은 골격이 부서마다 어떤 이름으로 나타나는지 대조하면, 새 업무를 만났을 때 어느 칸을 채워야 할지 바로 보인다.

서른다섯 칸에 빈 곳이 없다 — 일곱 부서가 다섯 단계를 모두 채운다. 부서 각론이 서로 달라 보이는 것은 같은 칸에 다른 이름이 들어가서다.

이 표와 이 글 전체에 나오는 임계값은 원 자료가 실습용으로 정한 값이며 이 글이 측정하거나 검증한 값이 아니다. 품질 점수 70, 신뢰도 0.85, ICP 100점 척도, 100만원 검토선, 뒤에 나오는 월 50건·100건 규모선과 재시도 3회가 모두 여기에 해당한다. 원 자료 작성 기준일은 2026-07-26이다.

I/O 계약 — 없으면 팀이 아니라 고립된 도구 N개

원 자료가 "파이프라인이 깨지는 가장 흔한 이유"로 든 항목이다. 계약이 없으면 N개 에이전트는 협업하는 팀이 아니라 고립된 도구 N개가 된다.

네 원칙의 오른쪽 열이 서로 다른 실패 모드를 가리킨다 — 1은 연쇄 붕괴, 2는 오인식, 3은 무해해 보이는 공회전, 4는 정지 또는 폭주다.

좋은 계약과 나쁜 계약

영업부 챕터가 제시한 대조표다. 표현만 다를 뿐 API 설계에서 말하는 스키마 규율과 같다.

마지막 행이 앞 셋의 전제다 — 서로의 내부 로직을 모르는 상태여야 타입·필수필드·버전을 계약으로 강제할 이유가 생긴다는 것이 이 글의 정리다.

트리거는 셋뿐이다

에이전트를 "언제 깨울 것인가"의 선택지는 셋뿐이다. 원 자료의 권고는 수동으로 시작해 안정화 후 전환이다.

주의점 열이 위에서 아래로 갈수록 무거워진다 — 수동의 대가는 지연이지만, 이벤트의 대가는 무한 루프이고 스케줄의 대가는 아무도 모르는 사이의 방치다.

도구 조합이 곧 역할의 정의다

마케팅 5인 예시의 도구 배분표다. 도구 조합이 곧 역할의 정의라는 것이 요점이며, 과잉 부여는 보안 사고와 토큰 비용 양쪽에서 손해다. 원 자료는 이 원칙에 YAGNI라는 이름을 붙인다.

읽기·쓰기 두 행만 다섯 역할 전부에서 필수이고, 나머지 네 행이 역할을 갈라 놓는다.

퍼블리셔가 웹 검색을 갖지 않는 이유가 설계의 핵심이다.

앞 단계의 에디터가 이미 팩트 체크를 끝냈으므로, 퍼블리셔의 일은 형식 변환뿐이다.

역할 경계가 명확하면 필요한 도구도 자동으로 좁혀진다.

권한·격리의 실행 형태

실습 폴더의 권한 설정은 "허용 목록 + 거부 목록"으로 되어 있다. 조직에 도입할 때 그대로 옮겨 쓸 수 있는 최소 골격이다.

거부 세 행이 각각 다른 것을 막는다 — 첫째는 컨텍스트 격리, 둘째는 자격증명, 셋째는 원 자료의 표현대로 파괴적·외부 전송 행위다. 앞의 도구 매트릭스가 "무엇을 쥐여줄 것인가"라면 이 표는 "쥔 도구로 어디까지 닿게 할 것인가"다.

사람 개입(HITL) 4등급

부서를 관통하는 개입 강도는 네 단계로 나뉜다. 어디까지 자동화하고 어디서 멈출지를 정하는 기준선이 이 구분이다. 원 자료가 이 절에 붙인 제목은 「HITL 3등급」이지만 실린 등급은 A~D 넷이고 원 자료의 요약 절도 「4등급을 나눈다」로 적는다 — 이 글은 표를 따라 4등급으로 적었다.

두 번째 열의 기준이 A→D로 갈수록 "되돌릴 수 있는가"에서 "책임이 누구에게 남는가"로 옮겨간다. A와 B의 경계는 대외 노출 여부다.

이 네 등급은 강도의 눈금일 뿐, 어떤 업무를 어느 눈금에 놓을지는 별도의 판정이 필요하다. 그 판정을 여섯 개 축으로 세운 표가 3편에 있다 — 새 업무를 후보로 올려 A~D 중 하나에 배치하는 절차가 거기서 이어진다.

파이프라인 복구 4종

7개 부서에서 반복 등장한 복구 장치다.

네 항목이 모두 파이프라인 단계 사이의 복구 장치다. 앞 단계로 되돌리거나(품질 루프), 다른 수단으로 갈아타거나(폴백 체인), 간격을 벌려 다시 걸거나(지수 백오프), 범위를 줄여 내보낸다(우아한 저하). 대화 이력이 길어져 품질이 떨어지는 문제나 도구 출력이 잡음이 되어 모델이 헤매는 문제는 이 표에 없다 — 원 자료 전문에서 「compaction」·「압축」·「도구 출력」·「대화 이력」·「Context」를 훑으면 컨텍스트 관리 맥락의 히트가 0이다(「압축」 2건은 온보딩 문서와 판단 규칙을 줄인다는 뜻이고, 「Context」 1건은 용어표의 「컨텍스트 격리」 행이다). 원 자료가 붙인 제목은 「실패 처리 패턴 4종」이고, 그 범위를 파이프라인 복구로 좁혀 읽는 것은 이 글의 정리다.

루프 자체가 무너지는 방식은 열 가지로 따로 정리돼 있다. 위 네 항목과 겹치는 자리는 재시도 축 — 그쪽 글의 「상태 없는 재시도」·「제한된 재시도」가 이 표의 품질 루프와 지수 백오프에 걸린다 — 이고, 컨텍스트·관찰·캐시 축은 그쪽에만 있다. 마지막 행의 "캐시"가 데이터 캐시를 가리킨다는 점도 함께 읽어 두는 편이 좋다 — 그쪽 글의 캐시는 프롬프트 접두사 캐시이고, 같은 단어가 다른 것을 가리킨다.

규모에 맞는 구조부터 고른다

재무부 챕터가 제시한 선택표다. 처음부터 복잡한 구조를 만들지 말라는 경고가 붙어 있다.

구현 복잡도와 실패 격리가 같은 방향으로 움직인다 — 격리를 얻으려면 복잡도를 지불해야 하고, 그 지불이 정당해지는 지점을 건수로 표시한 것이 마지막 열이다.

원 자료의 권고는 명확하다. 처음부터 완벽한 4인조를 만들지 말 것.

단일형으로 먼저 돌아가게 하고, 병목이 드러난 지점부터 쪼갠다.

규모에 맞지 않는 분업은 토큰 비용과 디버깅 난도만 올린다.

왜 쪼개는가 — 분해의 다섯 가지 이득

경영지원부 챕터가 정리한 격리의 이점이다. 소프트웨어의 관심사 분리(SoC) 원칙을 에이전트에 옮긴 것이다.

첫 행의 컨텍스트 순도가 서브에이전트 컨텍스트 격리의 직접적 효과다. 다만 앞 절의 선택표가 말하듯 이 다섯 가지 이득이 언제나 분업 비용보다 큰 것은 아니다.

다음 편으로

이 글은 골격이었다. 부서 이름을 지우면 남는 다섯 단계(5×7 대조표), 그 위에 얹히는 계약·트리거·권한·게이트·복구·구조 선택·분해 원리, 그리고 이 블로그에 실린 총계 30인 세 표가 같은 세트가 아니라는 사실까지다.

골격만 놓고 보면 알 수 없는 것이 두 가지 있다. 하나는 다섯 단계 중 어느 칸이 부서마다 가장 무거운가이고, 다른 하나는 네 등급 중 어느 등급이 실제로 코드에서 강제되는가다. 둘 다 부서 각론을 열어야 나온다.

2편은 마케팅·영업·고객지원·인사 네 부서로 들어간다 — 순차와 병렬을 어디서 가르는지, 리드 점수를 100점으로 어떻게 나누는지, 자동 응답과 사람 이관을 가르는 신뢰도 임계치가 어디에 그어지는지, 그리고 인사부가 왜 "무엇을 자동화할까"가 아니라 "무엇을 자동화하지 않을까"부터 정하는지까지다.