권한은 프론트매터로 좁히고 통합은 Bash 한 구멍으로 — 30개 에이전트 카탈로그

에이전트 하나를 잘 만드는 법과, 서른 개를 한 벌로 설계하는 법은 다른 문제다. 서른 개가 되면 이름이 겹치고, 권한이 제각각이 되고, "이건 누가 하는 일인가"가 문서 어디에도 적혀 있지 않은 상태가 된다.

이 시리즈는 원 자료가 대조 대상으로 삼은 7개 부서 30개 에이전트 정의서 한 벌을 자료로 세 편에 걸쳐 그 문제를 본다. 첫 편인 이 글은 카탈로그다 — 서른 개가 각각 무엇을 입력받아 무엇을 내놓고, 어떤 모델과 어떤 도구를 받았는지를 한 장의 표로 펼친다. 두 번째 편은 그 서른 개가 공유하는 정의서 스키마와 거기서 드러난 품질 편차를, 마지막 편은 그중 개발조직에 옮길 것과 옮기지 않을 것을 다룬다.

이 글에서 가장 오래 남는 관찰을 먼저 적어 둔다. 도구 권한은 프론트매터에서 명시적으로 좁혔는데, 외부 시스템 통합은 전부 Bash라는 한 구멍으로 몰려 있다. 권한 축소와 감사(audit) 가능성이 같은 것이 아니라는 사실이 서른 개를 한꺼번에 펼쳐 놓았을 때 드러난다.

이 글이 옮긴 원 자료의 작성 기준일은 2026-07-26이다. 에이전트 이름·도구 목록·모델 등급은 그 시점의 것이며 버전에 따라 바뀐다.

아래의 부서 편성과 개수, 모델·도구 배분, 사람 검수 등급은 원 자료가 정의서 30종을 대조해 적은 값이며 이 글이 운영해 얻은 실적이 아니다.

용어 정리

시리즈 세 편이 공유하는 어휘다. 이어지는 두 편은 여기서 자기 글이 쓰는 행만 추려 다시 싣는다.

에이전트 운영 용어

프레임워크 약어

원 자료가 부서별로 묶어 둔 업무 프레임워크 약어들이다.

지표·회계 약어

세 표를 합치면 8 + 18 + 11 = 37행이다. 둘째 표가 가장 길다. 판단 축에 이름을 붙이는 습관은 다음 편에서 스키마 항목으로 다시 나온다.

한눈에 보기 — 7개 부서 30개 에이전트

30개 에이전트는 7개 부서로 나뉘며, 영업·마케팅만 5개이고 나머지 5개 부서는 각 4개다. 사업 초기에 접점이 가장 많은 두 부서에 인원을 더 배치한 조직도와 같은 구성이라는 것이 원 자료의 설명이다.

분포 요약

네 축 중 부서별 개수와 도구 배분은 아래 카탈로그 표를 그대로 집계한 값과 맞는다. 모델 배분은 이 표에서 대조되지 않는다 — 카탈로그에 model 열이 없어서이고, opus 10 : sonnet 20의 근거는 다음 편이 옮긴 30행 전량 대조표에 있다. 마지막 행은 카탈로그와 맞지 않는다 — 원 자료가 이 행에 「(§2 기준 참조)」라는 단서를 직접 붙여 두었고 그 §2가 아래 「전체 카탈로그」 절이다. 단서를 「카탈로그의 검수 열을 보라」로 읽으면 값이 맞아야 하는데, 세어 보면 다른 값이 나온다. 카탈로그 표를 실은 뒤 이 절 아래에서 따로 다룬다.

개수가 같다고 같은 세트는 아니다

이 카테고리에는 7부서 30에이전트 표가 하나 더 있다. 잠재 경로는 개수의 제곱으로 는다 편의 「조직 규모별 편성 모델」 절에 실린 표다. 총계가 30으로 같고 부서별 배분도 같다(5 + 5 + 4×5 = 30).

그런데 두 표는 같은 세트가 아니다. 표기부터 갈린다 — 그쪽은 한글 기능명(카피라이팅, 발행 일정…)이고 이 글의 카탈로그는 영문 에이전트 ID(copywriter, seo-strategist…)다. 열 구성도 3열(부서 / 에이전트 수 / 구성) 대 7열이다.

구성이 갈리는 자리를 세 곳 짚으면 이렇다.

결정적인 것은 첫 행이다. 이 글이 옮긴 원 자료는 마지막 편이 다루는 절에서 이렇게 적는다 — "30종 중 테스트를 만드는 에이전트가 없다. debug-assistant가 「fix 전 실패 테스트」를 요구하지만 작성 주체가 없음". 다른 글의 표에는 개발 부서 넷 중 하나가 「테스트」다. 두 표가 같은 조직도의 두 판본이라면 이 문장이 성립하지 않는다.

개수 일치를 동일성의 증거로 읽지 않는 것, 이렇게 대 보는 것 자체가 이 글의 정리다. 확인되는 것은 총계가 같고 구성이 다르다는 사실까지이며, 둘 중 어느 편성이 옳은지는 이 글이 가리지 않는다.

전체 카탈로그

사람 검수 필요도 판정 기준 — 원 자료는 정의서 본문에 명시된 승인 게이트·면책·임계값을 근거로 3단계로 분류했다.

세 등급의 기준이 「업무가 어려운가」가 아니라 **「틀렸을 때 어디까지 나가는가」**로 적혀 있다는 점이 이 표의 성격이다. 등급을 매기는 축이 난이도가 아니라 파급 범위라고 읽는 것은 이 글의 정리다.

「한 줄 역할」 열에 숫자가 들어간 행이 눈에 띈다 — 6차원 100점, 7단계 파이프라인, 8섹션 제안서, 8종·4단계·감정 3축, 6대 영역으로 점검하고 4단계 등급. 판단 축의 개수를 역할 문장에 박아 두는 이 습관이 다음 편에서 스키마 항목으로 다시 나온다.

검수 필요도 — 요약값과 카탈로그를 세어 본 값이 다르다

앞 절 분포 요약표의 마지막 행은 사람 검수 필요도를 상 12종 · 중 15종 · 하 3종으로 적는다. 원 자료가 그 행에 **「(§2 기준 참조)」**라는 단서를 직접 붙여 두었고, 그 §2가 위 카탈로그 절이다. 단서를 「카탈로그의 검수 열을 보라」로 읽으면 그 값은 30행의 마지막 열을 센 결과와 맞아야 한다.

세어 보면 다르다. 위 30행의 마지막 열을 그대로 집계하면 상 11 · 중 17 · 하 2다. 합은 양쪽 다 30이라 합계 검산만으로는 드러나지 않는다.

전수 배정은 이렇다.

이 집계는 이 글이 카탈로그 30행의 마지막 열을 센 결과다. 요약표의 값과 카탈로그의 값 중 어느 쪽이 의도된 것인지는 이 글이 가리지 않는다.

외부 연동은 프론트매터에 드러나지 않는다

원 자료가 30개를 대조해 적은 관찰은 이렇다 — "30개 정의서 중 MCP 서버를 선언한 것은 하나도 없다." 외부 시스템 연동은 전부 다음 두 경로로 처리된다는 것이 원 자료의 서술이다.

• Bash 도구로 CLI·스크립트를 호출 (메일 발송, 문서 변환, 배포 명령)
• 본문 산문에 "여기서 DB에 INSERT한다" 식으로 절차만 기술하고, 실제 접속은 실행 환경에 위임

즉 이 템플릿 세트는 도구 권한을 프론트매터로 좁히고, 통합은 Bash 한 구멍으로 몰아넣은 설계다. 권한 축소는 명시적이지만 감사(audit) 관점에서는 Bash가 사실상 만능 통로라는 약점이 남는다.

정의서 본문에서 참조된 외부 시스템을 모으면 다음과 같다. 프론트매터에는 드러나지 않고 산문에만 등장한다는 점이 위 약점을 뒷받침한다.

일곱 행 중 프론트매터의 도구 목록에 고유한 이름이 붙는 것은 웹 검색 한 행뿐이다 — WebSearch를 받은 seo-strategist·competitor-monitor 둘이다. 나머지 여섯 행에는 Read·Write·Edit·Bash·Grep 다섯 중 대응하는 이름이 없다. 카탈로그의 도구 칸에 슬래시 뒤로 붙은 표기(/ DB, / 메일·캘린더, / CI·호스팅 CLI)는 도구 선언이 아니다 — 그 열의 머리글이 애초에 필요한 도구/외부연동이고, 슬래시 뒤는 연동 대상을 적어 둔 자리다. 일곱 행을 이렇게 1 : 6으로 가르는 것은 이 글의 정리다.

부서 횡단 파이프라인

원 자료는 단일 부서 시나리오 14개 외에 부서를 가로지르는 조합 3개를 제시한다. 한 업무 흐름이 여러 부서 에이전트를 순차로 통과하는 구조다.

세 행의 「통과 부서」 열을 보면 둘째 행만 시작과 끝이 같은 부서(기획)다. 나머지 둘은 일직선이다.

이 조합에서 읽어 낼 점은 두 가지라는 것이 원 자료의 정리다.

• 인계 지점이 곧 실패 지점이다. 파이프라인이 끊기는 곳은 대부분 부서 경계다. 각 정의서의 경계(위임) 섹션이 이 지점을 문서화하는 장치다.
• 순환 구조가 있는 파이프라인만 학습한다. 출시 → 문의 → 기획으로 되돌아오는 흐름이 있어야 다음 사이클이 개선된다. 일직선 파이프라인은 개선 루프가 없다.

원 자료는 병렬 실행보다 순차 실행을 권고한다. 상위 모델 여러 개를 동시에 돌리는 부담과, 앞 단계 산출물이 뒷단계 입력이 되는 의존성 때문이다.

첫 항목이 이 시리즈의 복선이다. 경계(위임) 섹션이 인계 지점을 문서화하는 장치라면, 그 섹션이 지목한 이름이 실재하지 않을 때 파이프라인은 정확히 그 자리에서 끊긴다. 30종에서 그 일이 실제로 얼마나 일어났는지가 다음 편의 절반이다.

다음 편으로

이 글은 카탈로그였다. 서른 개가 무엇을 입력받아 무엇을 내놓는지(30행 표), 모델과 도구를 어떻게 배분받았는지(opus 10 : sonnet 20, 도구 변형 3종), 외부 시스템에 어떻게 닿는지(연동 표면 7종과 Bash 한 구멍)까지다.

카탈로그를 펼쳐 놓았을 때만 보이는 것이 두 가지 있었다. 하나는 권한을 좁힌 것과 감사 가능한 것이 다르다는 점이고, 다른 하나는 요약값과 원자료 표가 어긋난 자리가 합계 검산을 통과한 채 남아 있었다는 점이다. 둘 다 정의서 한 개만 열어 봐서는 나오지 않는다.

다음 편은 서른 개가 공유하는 정의서 스키마로 들어간다 — 프론트매터 4필드와 본문 7섹션이 무엇이고, 그 형식이 100% 균질한데도 안전장치는 왜 편차가 큰지, 그리고 경계 섹션이 지목한 이름 중 실재하지 않는 것이 몇 개였는지까지다.