잠재 경로는 개수의 제곱으로 는다 — 확장 구간별 운영 모델과 반복 실패 4가지

앞 편까지는 에이전트가 몇 개 안 될 때의 이야기였다. 개수가 늘면 성격이 다른 문제가 나온다. 하나하나는 멀쩡한데 묶음이 안 돌아가는 종류다.

이 시리즈의 마지막 편은 그 지점을 다룬다. 무엇이 먼저 깨지는지(라우팅), 왜 비용이 개수보다 빨리 오르는지(컨텍스트 전파), 왜 장애 하나를 잡는 데 걸리는 시간이 몇 배가 되는지(체인 추적). 그리고 그 셋을 넘긴 다음에 반드시 오는 질문 — "그래서 효과가 얼마였나" — 에 답하는 방법까지다.

첫 편이 합격선 5축에서 확장성을 「하나 더 붙이는 데 얼마나 걸리느냐」로 정의했다. 이 글은 그 시간이 왜 늘어나는지, 그리고 늘어나기 전에 무엇을 갈아타야 하는지를 구간별로 본다.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이다. 임계값·비용 배율·모델 등급 구분은 그 시점의 것이며 버전과 요금제에 따라 바뀐다.

아래의 정량 수치(비용 배수, 오류율, MTTR, 캐시 히트율별 금액 등)는 원 자료가 제시하거나 옮긴 값이며 이 글이 측정한 값이 아니다. 수치가 나오는 자리마다 출처와 기준일을 따로 붙였다.

용어 정리

첫 편의 용어표에서 이 글이 쓰는 행만 추렸다.

12개를 넘으면 반드시 나타나는 세 증상

세 행의 「메커니즘」 열이 왜 개수에 비례하지 않는가를 각각 설명한다. 경로는 조합이라 제곱에 가깝게 늘고, 비용은 에이전트끼리 주고받는 양이 붙어서 늘며, 디버깅은 체인 길이가 곱해진다. 에이전트를 3배 늘렸을 때 셋 다 3배로 끝나지 않는 이유다.

「대응」 열도 한 방향이다. 셋 다 정보를 한곳에 모으는 조치다 — 경계를 정의 파일 한 곳에, 컨텍스트를 허브 한 곳에, 호출 기록을 감사 로그 한 곳에.

위 수치는 원 자료가 제시하거나 옮긴 값이며 이 글이 측정한 값이 아니다 — 경로 공식 N(N-1)/2와 그 계산값(45·435), 오류율 5% → 45%, 비용 5개 월 $12 → 15개 월 $89(7.4배), MTTR 15분 → 4시간. 금액은 사용하는 모델·요금제·작업량에 따라 달라진다. 원 자료 작성 기준일은 2026-07-26이다.

두 개의 반패턴이 지목된다. **"에이전트 설명을 모호하게 쓰는 것"**과 **"나중에 로그 달아야지"**다. 후자에 대한 원 자료의 답은 간명하다. 나중은 없다.

두 반패턴이 각각 첫 행과 셋째 행의 원인이라는 점을 붙여 읽으면 순서가 보인다. 설명을 모호하게 쓰면 경로가 겹치고, 로그를 미루면 그 겹침이 만든 오라우팅을 추적할 수단이 없다.

규모 구간별 운영 모델

아래 표는 원 자료가 실제 확장 운영 데이터를 에이전트 개수 구간으로 재구성한 것이다. 일반론으로 세운 모델이 아니라 특정 운영 이력에서 뽑아 구간별로 다시 묶은 값이라는 뜻이다.

「병목」 열이 구간마다 다른 층으로 옮겨간다는 것이 이 표의 핵심이다. 처음엔 병목이 없고, 다음엔 분배 정확도가, 그다음엔 규칙 관리 부담이, 그다음엔 돈과 추적이, 마지막엔 상태 일관성이 병목이 된다. 앞 구간의 대응책이 다음 구간의 병목을 만든다는 점도 눈에 띈다 — 키워드 매칭으로 오라우팅을 잡으면 그 키워드 자체가 다음 구간의 관리 부담이 된다.

앞 편이 다룬 「키워드 교집합은 공집합이어야 한다」는 규칙이 유효한 구간이 두 번째 행까지라는 뜻이기도 하다. 세 번째 행부터는 사람이 관리할 키워드 수가 먼저 무너진다.

라우팅 방식의 진화만 따로 떼면 흐름이 선명하다.

각 전환의 교훈은 다음과 같다.

• 수동 라우팅은 에이전트 10개 초과에서 붕괴한다. 예외가 없다.
• 키워드는 문자열 매칭일 뿐이다. 의미 기반 분류는 모델만 할 수 있다.
• 키워드 라우팅 도입 시 평균 라우팅 시간이 8초에서 1초로, 수동 선택은 70% 감소했다.
• 분류기 전환 시 정확도가 15%p 올라 오라우팅이 3분의 1로 줄었다.

네 항목 중 앞의 둘은 한계를 말하고, 뒤의 둘은 갈아탄 뒤의 변화를 말한다. 갈아타는 판단을 「지금 불편한가」가 아니라 「개수가 몇인가」로 하라는 것이 앞 두 항목의 요지다 — 수동 라우팅은 10개에서 붕괴하고, 키워드 매칭은 아무리 잘 써도 의미를 못 본다.

위 네 항목의 수치는 원 자료가 옮긴 값이며 이 글이 측정한 값이 아니다 — 8초 → 1초, 수동 선택 70% 감소, 정확도 15%p 상승, 오라우팅 3분의 1. 위 표의 라우팅 정확도 95%+, 30개 × 5개 = 150개도 같다. 원 자료 작성 기준일은 2026-07-26이다.

부서 증설 순서 — 돈 버는 곳부터

일곱 행의 순서가 수익 기여 열만으로 결정되지 않는다는 점을 봐야 한다. 영업이 「최고」인데 2번인 것은 난이도가 마케팅보다 높기 때문이고, 고객지원이 「보호」로 3번인 것은 매출을 만들지는 않아도 지키기 때문이다. 마지막 행은 두 열이 최악의 조합이라 순서가 아니라 범위로 답이 나온다 — 초안까지만이다.

원칙은 **"CFO보다 영업팀을 먼저 뽑는 이유와 같다. 돈이 들어와야 관리할 것이 생긴다"**로 요약된다. 다음에 만들 에이전트를 정할 때는 매트릭스 어느 칸인지부터 확인한다.

재사용과 거버넌스

에이전트를 매번 새로 만들면 6개월 뒤 같은 역할이 12가지 버전으로 흩어진다. 대응은 중앙 공유 라이브러리다.

다섯 행 중 셋째가 특히 실용적이다. 앞의 둘이 분산을 금지한다면 셋째는 분산을 허용하되 자리를 정한다. 오버라이드를 아예 막으면 사람들이 저장소 밖에서 복제하기 시작하므로, 새는 곳을 없애는 대신 새는 곳을 한 군데로 지정하는 설계다.

넷째 행의 「비용등급 선언」이 앞 편들에서 본 JD 필드의 확장이다. 모델 이름을 코드에 박지 않고 등급만 선언해 두면, 모델을 갈아탈 때 정의 파일만 고치면 된다.

거버넌스는 권한 매트릭스 + 감사 로그 + 체크포인트 3종 세트다.

네 등급이 단조 증가하지 않는다는 점이 중요하다. L1에서 L3까지는 권한이 넓어지지만 L4에서 다시 읽기 전용으로 좁아진다. 등급은 「할 수 있는 일의 양」이 아니라 「다루는 데이터의 민감도」로 매겨져 있고, 민감도가 최고인 자리에서는 쓰기를 아예 빼는 것이 답이기 때문이다.

감사 로그는 JSON Lines로 시각 / 세션 / trace / 에이전트 / 도구 / 동작 / 결과 7개 필드를 남긴다. trace ID가 있어야 오케스트레이터에서 하위 에이전트까지 체인 전체를 되짚을 수 있다. 보존 정책은 일반 90일, 민감 데이터 365일이 제시된다.

체크포인트는 3개 이상 파일 동시 변경 / 민감 등급 작업 완료 / 단계 전환 시점에 건다. 체크포인트 없이 긴 파이프라인을 돌리면 실패 시 처음부터 다시 해야 한다.

90일·365일 보존 정책과 체크포인트 발동 기준(3개 이상 파일), 감사 로그 7개 필드는 원 자료가 제시한 기준선이며 이 글이 측정하거나 규정에서 확인한 값이 아니다. 실제 보존 기간은 적용받는 법규와 내부 정책에 따라 달라진다. 원 자료 작성 기준일은 2026-07-26이다.

비용 최적화

네 축이 비용이 발생하는 서로 다른 자리를 하나씩 맡는다. 첫째는 단가(어떤 모델을 쓰는가), 둘째와 넷째는 같은 입력을 다시 보내지 않는 것, 셋째는 애초에 보내는 양을 줄이는 것이다. 셋째가 앞 절 「12개를 넘으면」 표의 둘째 행에 대한 직접 대응이기도 하다.

소형 : 중형 : 대형 모델의 대략적 비용 배율은 1 : 3 : 5로 제시된다. 반패턴은 판단이 필요한 작업을 소형 모델에 맡기는 것이다. 틀린 답을 빠르게 내놓기 때문에 결과적으로 더 비싸다.

캐시 히트율에 따른 비용 시나리오(동일 작업량 기준 예시)는 0% $1,500 / 60% $780 / 90% $385로, 캐싱 설계가 곧 비용 설계임을 보여준다.

위 수치는 원 자료가 제시하거나 옮긴 값이며 이 글이 측정한 값이 아니다 — 절감률 70% 이상, 비용 배율 1 : 3 : 5, 캐시 TTL 5분, 히트율별 금액 0% $1,500 / 60% $780 / 90% $385. 모델 등급별 단가와 캐시 정책은 벤더와 요금제에 따라 다르고 시간이 지나면 바뀐다. 원 자료 작성 기준일은 2026-07-26이다.

앞 편이 운영 전환 목록의 한 행으로 남겨 두었던 **"자동화 코드를 짜기 전에 비용 모니터링부터 설정한다"**가 이 절의 전제다. 위 네 축은 전부 쓰고 있는 양이 보일 때 손댈 수 있는 것들이다. 어느 에이전트가 얼마를 쓰는지 모르면 모델을 3분할할 기준 자체가 없다.

다음 에이전트를 정하는 절차

확장은 감이 아니라 절차로 결정한다. 네 단계면 끝난다.

1단계의 판단 기준이 재사용 절의 「단일 책임」과 같은 문장이라는 점을 봐야 한다. 새 에이전트를 정하기 전에 기존 에이전트의 경계부터 점검하게 되어 있고, 여기서 설명이 안 되는 것이 나오면 그것부터 분리하는 것이 다음 작업이 된다.

2단계는 첫 편의 5열 워크시트를 다시 꺼내는 자리다. 확장 단계에서도 후보 선정 기준은 처음과 같다.

배치 전에 반드시 던져야 할 질문은 하나다. "이것이 수익에 얼마나 기여하는가?" 이 질문을 건너뛰면 만들기 쉬운 것부터 만들게 되고, 그 결과 자동화 개수는 늘지만 효과는 정체된다.

한 가지 예고도 남아 있다. 50개를 넘어서면 새 병목은 라우팅이 아니라 에이전트 간 정보 동기화가 된다. 각자 다른 시점의 상태를 보고 판단하는 상황이 생기기 때문에, 공유 메모리와 컨텍스트 아키텍처를 다시 설계해야 한다. 라우팅을 해결했다고 확장이 끝나지 않는다.

성과 측정과 증명

확장까지 마쳐도 "그래서 효과가 얼마였나"에 답하지 못하면 조직 안에서 예산을 얻지 못한다.

증명의 3종 세트

셋 중 하나만 있으면 각각 이론 · 마술 · 자랑에 그치고, 세 개가 합쳐질 때 설득력이 최대가 된다는 것이 원 자료의 정리다. 셋이 서로를 보완하는 방향도 다르다 — 문서는 무엇인지, 시연은 진짜인지, 지표는 얼마나인지에 답한다.

문서 8섹션 구조

산출물 문서의 표준 구조는 다음과 같다. 그대로 사내 자동화 프로젝트 문서 템플릿으로 쓸 수 있다.

여덟 섹션의 순서가 읽는 사람이 판단하는 순서를 따른다 — 이렇게 읽는 것은 이 글의 정리다. 1·2번에서 계속 읽을지를 정하고, 3·4번에서 나에게 필요한지를 정하며, 5번에서 실제로 돌려 보고, 6·7번에서 믿을지를 정하며, 8번이 쓸 수 있는지를 정한다. 1번에 숫자를 넣으라는 요령이 여기서 나온다 — 7번까지 읽어야 숫자가 나오면 대부분 그 전에 닫는다.

5번의 「반드시 사전 테스트」는 첫 편의 문서화 축 합격선과 같은 조건이다. 만든 사람이 아닌 제3자가 실행에 성공해야 통과다.

위 두 표의 수치(3종 세트의 30초, 8섹션의 100줄·3~5개)는 원 자료가 제시한 작성 기준선이며 이 글이 측정한 값이 아니다. 원 자료 작성 기준일은 2026-07-26이다.

시연 원칙 — 첫 10초의 법칙

동작을 보여주는 자리에서는 첫 10초 안에 핵심 결과나 자동화가 도는 장면을 보여준다. 보는 사람은 그 안에 계속 볼지를 결정한다.

이 표는 DO와 DON'T가 행 단위로 짝지어져 있지 않다 — 예컨대 둘째 행은 DO가 길이를, DON'T가 순서를 말한다. 여덟 항목을 하나씩 배정하면 순서 3 · 길이 2 · 덜어내기 3으로 갈린다.

셋을 더하면 3 + 2 + 3 = 8로 표의 여덟 항목이 남김없이 배정된다. 이렇게 갈라 읽고 이름 붙이는 것은 이 글의 정리다 — 원 자료는 이 표를 DO / DON'T 두 열로만 두고 항목을 따로 분류하지 않는다. 이 원칙은 사내 데모나 경영진 보고에도 그대로 적용된다. 결과를 먼저, 과정은 뒤에 두는 순서다.

10초·1~3분·3분은 원 자료가 제시한 시연 기준선이며 이 글이 측정한 값이 아니다. 원 자료 작성 기준일은 2026-07-26이다.

ROI 계산 — 추정이라도 숫자로 쓴다

계산 절차는 단순하다. 시간 절감을 금액으로 환산하고 투자 비용과 비교한다.

지표 표의 형태는 다음과 같이 잡는다.

세 행 중 가운데 행의 「개선율」 칸이 숫자가 아니라 **「측정 방식 변경」**이라는 점이 이 표에서 가장 실용적인 부분이다. 수동일 때는 놓친 것을 셀 방법이 없었고 자동화 후에야 세어졌으므로, 두 값은 애초에 비교 가능한 쌍이 아니다. 그 칸에 무리하게 개선율을 적는 대신 비교 불가라고 적어 두는 것이 정직한 처리다.

위 표의 값(20분/일 → 3분/일, -85%, 주 2~3건, 12건/주, 약 6.2시간)은 원 자료가 지표 표의 형태를 보이려고 든 예시이며 관측된 실적이 아니다. 원 자료 작성 기준일은 2026-07-26이다.

주의할 점은 시간 절감만이 지표가 아니라는 것이다. 자동 처리 건수("주간 리포트 245건 자동화"), 감지 건수("오류 알림 12건/주")도 유효한 지표다. 또한 정확한 숫자보다 측정된 추정이 낫다는 원칙이 반복된다.

"아마 30% 줄었을 것 같다"보다 "이전 2시간, 현재 1시간 20분, 약 33% 단축"이 설득력에서 비교가 되지 않는다.

숫자가 없으면 지금 바로 한 번만 측정하면 된다. 1회 측정으로도 충분하다.

두 문장이 붙어 있는 것이 요점이다. 앞 문장만 읽으면 정밀한 측정 체계가 필요해 보이지만, 뒤 문장이 1회 측정으로 충분하다고 선을 낮춘다. 측정이 없는 상태와 1회 측정한 상태의 차이가, 1회와 100회의 차이보다 크다.

피드백을 받는 방법

성과를 공유했을 때 유용한 피드백을 얻으려면 질문의 형태가 중요하다. 이 대비표는 코드리뷰 요청·설계 리뷰에도 그대로 적용된다.

세 행의 오른쪽 열이 전부 선택지를 좁히거나 자기 판단을 먼저 밝힌다. 비유가 명확하다. 의사에게 "몸이 아파요"라고 하는 것과 "오른쪽 무릎이 3주째 아픕니다"라고 하는 것의 차이다. 범위를 좁히고 본인의 판단 근거를 먼저 밝히는 질문이 좋은 피드백을 만든다.

전체를 되짚으면

원 자료는 전 과정을 여덟 구간으로 되짚으며 끝난다. 여덟 구간이 하나의 방향으로 이어진다.

「주제」 열을 위에서 아래로 읽으면 다루는 대상이 계속 한 층씩 올라간다 — 도구(0 터미널 기초 · 1 도구 입문)에서 시작해 규칙(2 규칙 문서), 연동(3 도구 연동), 위임(4 서브에이전트·스킬), 협업(5 멀티에이전트), 조직(6 부서 단위 조직)을 거쳐 마지막에 자기 문제(7 캡스톤)로 돌아온다. 이렇게 읽는 것은 이 글의 정리다. 그 전환의 가운데 지점을 「패러다임 전환」 열이 한마디로 적어 두었다 — 4번 행의 **「실행자에서 디렉터로」**다.

조직 규모별 편성 모델

도입 주체의 규모에 따라 출발 지점이 다르다. 이 세 유형은 "우리 조직이라면 몇 명부터 시작하는가"를 판단하는 기준이 된다.

다만 실제 성공 사례의 공통점은 5개 이하로 시작했다는 것이다. 위 표는 목표 편성이지 착수 편성이 아니다. 이 단서가 붙지 않으면 표의 7·12·20이 첫날 만들 개수로 읽히는데, 셋 중 둘(12·20)은 앞 절에서 본 라우팅 붕괴선(「수동 라우팅은 에이전트 10개 초과에서 붕괴한다」)을 처음부터 넘는 수다. 7만 그 선 아래이고, 그마저 「5개 이하로 시작」과는 어긋난다. 표의 편성 규모를 붕괴선에 대 보는 것은 이 글의 정리다 — 원 자료는 이 표에 「목표 편성이지 착수 편성이 아니다」라는 단서까지만 달았다.

부서 단위로 확장했을 때의 7부서 30에이전트 매핑은 다음과 같다. 조직도를 그대로 옮긴 형태다.

일곱 부서 중 마케팅·영업만 5개이고 나머지 다섯은 각 4개다(5+5+4×5=30). 더 배정된 두 부서가 앞의 「부서 증설 순서」 표에서 1·2번을 차지한 두 부서와 정확히 일치한다. 두 표를 이렇게 겹쳐 읽는 것은 이 글의 정리다 — 원 자료가 이 표에 붙인 말은 「조직도를 그대로 옮긴 형태다」 한 줄이고, 왜 두 부서만 5개인지는 이 표 안에서 설명되지 않는다. 「증설 순서」 표가 그 두 부서의 근거 열에 적어 둔 말은 「즉각 매출 기여」(마케팅)·「ROI가 가장 명확」(영업)이다.

위 두 표의 개수(7·12·20, 부서별 5·4)는 원 자료가 제시한 편성 예시이며 관측된 운영 규모가 아니다. 30개라는 총계도 7부서 배분의 결과이지 권장 목표치가 아니다 — 원 자료 스스로 바로 위에 「5개 이하로 시작했다」는 단서를 붙였다. 원 자료 작성 기준일은 2026-07-26이다.

성공 사례의 공통 패턴 다섯

다섯 중 앞의 셋이 시작 시점에 하는 것이고 뒤의 둘이 하는 동안 계속하는 것이다. 1·2번이 같은 말을 대상과 개수로 나눠 한 것이라는 점도 눈에 띈다 — 무엇을 자동화할지를 좁히고(범위), 몇 개를 만들지를 좁힌다(개수).

반복 실패 패턴 넷

반복 실패 패턴 네 가지는 조직에 무엇이든 도입할 때 공통으로 적용된다.

네 패턴은 대부분의 조직이 이 순서대로 같은 벽에 부딪힌다는 것이 원 자료의 서술이다. 「예방」 열도 순서를 따라간다 — 앞의 둘은 재는 장치를 먼저 붙이는 것(시간 측정, 비용 알림)이고, 뒤의 둘은 완성을 기다리지 않고 미리 갈아타는 것(30% 시점, 3개 초과 시점)이다.

넷째 행의 「3개 초과」가 이 글의 첫 절과 이어진다. 조건문 체인이 실제로 못 견디는 지점은 훨씬 뒤지만, 갈아타는 작업 자체가 개수에 비례해 비싸지므로 아직 싼 시점에 갈아타라는 것이 3이라는 낮은 값의 의미다.

30% 시점과 3개 초과는 원 자료가 제시한 설계 임계이며 이 글이 측정한 값이 아니다. 둘 다 특정 조직의 이력이 아니라 갈아타는 시점을 정하는 기준으로 쓰인다. 원 자료 작성 기준일은 2026-07-26이다.

두 갈래 — 적용과 공개

원 자료는 학습 이후의 경로를 두 가지로 제시하면서, 조직에 적용할 때도 같은 구분이 유효하다고 적었다.

두 경로는 앞에서 본 재사용 절의 확장이다. 실무 적용이 자기 조직 안에서 도는 반복이라면, 공개 기여는 그 중앙 라이브러리의 경계를 조직 밖으로 한 칸 넓힌 것이다.

실무 적용 경로의 핵심은 반복 횟수다. 일주일에 3회 이상 돌려봐야 설계 감각이 생긴다. 자료로 읽은 것과 자기 업무에서 돌려본 것은 전혀 다른 경험이며, 첫 에이전트가 실패하는 것은 설계가 덜 된 것이지 도구의 문제가 아니다.

첫 행의 조건 두 개(매주 30분 이상 쓰는 업무, 일주일에 3회 이상 실행)가 첫 편의 대상 선정 기준과 같은 형태라는 점을 봐야 한다. 그쪽은 회수 가능성을 재려고 반복 빈도를 셌고, 이쪽은 설계 감각이 붙는 속도를 재려고 같은 것을 센다.

30분·3회는 원 자료가 제시한 기준선이며 이 글이 측정한 값이 아니다. 원 자료 작성 기준일은 2026-07-26이다.

시리즈를 닫으며

네 편을 관통하는 것은 하나다. 경계를 문서에 적어 두는 것이 확장의 전제다.

첫 편은 무엇을 자동화 대상으로 삼을지의 경계를 워크시트와 두 도구로 그었고, 합격선을 5축 루브릭으로 못박았다. 두 번째 편은 에이전트 하나의 경계를 5필드 JD로, 에이전트 사이의 경계를 키워드 교집합 공집합으로 그었다. 세 번째 편은 장애의 경계를 3계층으로 좁히고 예방 칸을 반드시 문서에 반영하게 했다. 그리고 이 글은 그 모든 경계가 개수에 밀려 무너지는 지점과, 무너지기 전에 갈아타는 순서를 봤다.

세 증상이 12개 근처에서 한꺼번에 나오는 이유도 같다. 잠재 경로가 제곱으로 늘고 컨텍스트가 체인을 타고 전파되는 것은 경계가 명시되지 않았을 때 벌어지는 일이다. 경계가 정의 파일에 적혀 있으면 경로는 조합이 아니라 매핑이 되고, 컨텍스트는 전파되는 대신 허브에 머문다.

마지막으로 남는 것은 증명이다. 여기까지 해도 「그래서 효과가 얼마였나」에 답하지 못하면 다음 예산이 나오지 않는다. 그 답은 정밀한 측정 체계가 아니라 한 번의 측정에서 시작한다.