232명의 AI 전문가를 한 폴더에: '디 에이전시(The Agency)'로 읽는 멀티 에이전트 아키텍처의 모든 것

들어가며: 레딧 글 하나가 별 12만 개가 되기까지

2025년 가을, 한 개발자가 레딧 r/ClaudeAI에 짧은 글을 올렸다. "AI 에이전트를 '만능 도우미' 하나로 쓰지 말고, 각자 전문 분야가 뚜렷한 전문가 캐릭터로 나눠서 써보면 어떨까?"

반응은 폭발적이었다. 첫 12시간 만에 50개가 넘는 요청이 달렸다. 그 스레드는 곧 하나의 GitHub 저장소가 되었고, 몇 달 뒤 그 저장소 — msitarzewski/agency-agents, 별명 "The Agency(디 에이전시)" — 는 별 12만 개(122,355개), 포크 2만 개를 모은 이 분야의 대표적 오픈소스가 되었다.

숫자만 보면 그냥 "인기 있는 프롬프트 모음집" 같다. 하지만 그 안을 열어보면 이야기가 달라진다. 이 저장소는 사실상 멀티 에이전트 시스템(multi-agent system)을 어떻게 설계하고, 어떻게 프로덕션에서 무너지지 않게 만드는가에 대한, 10,000줄이 넘는 살아있는 교과서다.

이 글은 세 가지를 다룬다.

1. 왜 AI를 '만능 하나'가 아니라 '전문가 팀'으로 나누는 개념이 나왔는가 (역사와 논문)
2. 에이전트 하나는 무엇으로 이루어져 있는가 (해부학)
3. 그 에이전트들이 팀으로 움직일 때의 아키텍처 — 이 글의 심장부

가볍게 읽되, 끝까지 읽으면 "멀티 에이전트 시스템 아키텍트"가 실제로 무슨 고민을 하는지 손에 잡히도록 구성했다.

---

1. 디 에이전시란 무엇인가

한 줄로 요약하면 이렇다.

디 에이전시는 뚜렷한 성격·전문성·검증된 산출물을 가진 232개의 AI 에이전트 정의를, 16개 '부서(division)'로 조직해 놓은 오픈소스 저장소다.

각 에이전트는 하나의 마크다운(.md) 파일이다. 그 파일 하나가 "프론트엔드 개발자"나 "펜테스터"나 "레딧 커뮤니티 매니저"라는 AI 인격체 한 명의 취업 명세서인 셈이다. Claude Code에서는 ~/.claude/agents/에 복사만 하면, 대화 중에 "프론트엔드 개발자 모드로 전환해줘"라고 부를 수 있다.

16개 부서는 실제 회사 조직도를 그대로 옮겨온 듯하다.

여기서 눈여겨볼 이름들이 있다. "Whimsy Injector(엉뚱함 주입기)", "Reality Checker(현실 점검관)" 같은 이름은 농담이 아니다. 이 프로젝트의 철학이 바로 여기 있다.

---

2. 왜 '만능 하나'가 아니라 '전문가 팀'인가

디 에이전시의 README는 자신을 이렇게 정의한다.

"일반적인 'AI 프롬프트'와 다르게 — ❌ '개발자처럼 행동해줘' 같은 두루뭉술한 프롬프트가 아니라, ✅ 성격과 프로세스를 갖춘 깊은 전문화다."

이게 왜 중요한지는 LLM의 실제 실패 방식을 알면 이해된다. 하나의 프롬프트에 "리서치도 하고, 분석도 하고, 글도 쓰고, 검토도 해"라고 다 넣으면 세 가지 문제가 생긴다.

인간 조직이 왜 분업하는지 생각해보면 직관적이다. 한 사람이 회계·디자인·영업·법무를 다 하면 어느 것도 최고 수준이 못 된다. 전문가를 나누면 각자 깊어지고, 조율만 잘하면 팀 전체가 개인의 합보다 강해진다. 디 에이전시는 그 인간 조직의 논리를 AI에 그대로 적용한다.

그런데 — 이 아이디어는 2025년에 갑자기 튀어나온 게 아니다. 뿌리는 40년 전으로 거슬러 올라간다.

---

3. 역사: '여러 마음이 모여 하나의 지능'이라는 오래된 꿈

3.1 마빈 민스키의 '마음의 사회' (1986)

멀티 에이전트의 사상적 뿌리는 MIT의 전설적 학자 마빈 민스키(Marvin Minsky)의 1986년 책 『마음의 사회(The Society of Mind)』다. 민스키의 핵심 주장은 도발적이었다.

"지능은 단 하나의 똑똑한 메커니즘에서 나오지 않는다. 각자는 멍청하지만 특정 일만 하는 수많은 작은 '에이전트'들이 모여, 그 상호작용에서 마음이 창발(emerge)한다."

혼자서는 아무것도 못 하는 작은 부품들이 협력하면 지능이 된다는 이 발상은, 오늘날 "전문 에이전트를 조합해 복잡한 일을 해낸다"는 멀티 에이전트 철학과 정확히 같은 뼈대다.

3.2 분산 AI, 블랙보드, 그리고 BDI (1970s~1990s)

민스키가 철학을 제시했다면, 엔지니어들은 이를 실제 시스템으로 만들려 했다.

• 블랙보드 아키텍처 (1970s) — 카네기멜런의 음성인식 시스템 Hearsay-II는 여러 전문 모듈("지식원")이 하나의 공유 칠판(blackboard)에 각자 아는 것을 써가며 문제를 함께 푸는 구조였다. 공유 상태를 통한 협업 — 오늘날 멀티 에이전트의 '공유 메모리'와 판박이다.
• BDI 에이전트 (1990s) — Bratman의 철학을 Rao·Georgeff가 형식화한 Belief-Desire-Intention 모델. 에이전트가 믿음(Belief)·욕구(Desire)·의도(Intention)를 갖고 자율적으로 행동한다는 개념으로, '에이전트'라는 소프트웨어 개념을 학문적으로 정립했다.
• 멀티 에이전트 시스템(MAS) 이라는 학문 분야 자체가 이 시기에 자리 잡았다(Wooldridge의 교과서가 대표적). 다만 당시 에이전트는 '똑똑한 언어 이해'가 불가능했다. 규칙 기반이었고, 좁은 도메인을 벗어나면 무력했다.

즉 개념과 아키텍처는 30년 전에 이미 있었다. 없었던 것은 딱 하나 — "자연어로 추론하고 계획할 줄 아는, 충분히 똑똑한 개별 에이전트"였다. 그걸 LLM이 채웠다.

3.3 폭발의 해, 2023

2022년 말 ChatGPT, 2023년 GPT-4가 등장하자 잠자던 개념이 순식간에 깨어났다.

특히 2023년 4월의 스탠퍼드 '스몰빌(Smallville)' 논문은 결정적이었다. Joon Sung Park 등이 발표한 Generative Agents: Interactive Simulacra of Human Behavior(UIST 2023)는 25명의 AI 주민이 며칠에 걸쳐 관계를 맺고, 누구도 시키지 않은 밸런타인 파티를 스스로 조직하는 모습을 보여줬다.

이 논문의 진짜 유산은 시뮬레이션 자체가 아니라, 그것을 가능하게 한 기억 아키텍처였다. 관찰(observation) → 점수 기반 검색(retrieval) → 주기적 성찰(reflection)이라는 3단 기억 구조는, 이후 CrewAI의 메모리 시스템을 비롯한 거의 모든 장기 실행 에이전트의 원형이 되었다.

정리하면: 민스키가 꿈을 꾸고(1986), 엔지니어들이 골격을 세우고(1970~90s), LLM이 개별 에이전트를 똑똑하게 만들자(2023), 30년 묵은 개념이 실무 기술로 폭발했다. 디 에이전시는 이 흐름의 가장 실용적인 결정체 중 하나다.

---

4. 에이전트 하나의 해부학

아키텍처로 들어가기 전에, 에이전트 파일 하나가 무엇으로 채워지는지 봐야 한다. 디 에이전시가 "그냥 프롬프트 모음"과 다른 이유가 여기 있다. 모든 에이전트 파일은 6개 요소를 갖춘다.

핵심은 성격(personality)이다. 저장소가 자랑하는 캐릭터들의 실제 대사를 보자.

왜 성격을 부여할까? 이건 감성 마케팅이 아니라 엔지니어링 기법이다. "3~5개의 문제를 반드시 찾아라", "시각적 증거를 요구하라" 같은 뚜렷한 페르소나는 곧 강한 행동 제약(behavioral constraint)이다. 두루뭉술한 "코드 리뷰해줘"보다, 캐릭터를 입은 지시가 LLM의 출력을 훨씬 일관되게 묶어준다. 성격은 프롬프트 엔지니어링의 압축된 형태인 것이다.

---

5. 아키텍처 심층: 팀을 프로덕션에서 무너지지 않게 설계하기

여기가 이 글의 심장부다. 에이전트 232명을 갖는 것보다 훨씬 어려운 문제는 "이들을 어떻게 하나의 신뢰할 수 있는 시스템으로 엮느냐"다.

디 에이전시에는 이 질문만 전담하는 에이전트가 있다 — 🕸️ Multi-Agent Systems Architect(멀티 에이전트 시스템 아키텍트). 이 파일은 그 자체로 훌륭한 아키텍처 교과서다. 그의 좌우명부터 보자.

"데모는 거짓말을 하고, 프로덕션은 진실을 말한다. 다섯 개 에이전트를 실패 처리 없이 사슬로 엮어놓고 '완성됐다'고 말하는 순간, 그건 아직 아키텍처가 아니다."

이 아키텍트는 AI 에이전트 팀을 분산 시스템(distributed system)과 똑같이 취급한다. 모든 에이전트는 언젠가 타임아웃되고, 환각을 일으키고, 옆 에이전트와 모순되는 답을 낸다고 가정하고 설계한다. 핵심을 다섯 개의 위상(topology) 패턴부터 하나씩 뜯어보자.

5.1 다섯 가지 위상(Topology) 패턴

멀티 에이전트를 조립하는 방법은 무한해 보이지만, 실무에서 반복되는 골격은 다섯 가지다.

패턴 1 — 순차 사슬(Sequential Chain)

가장 단순하다. 각 단계가 앞 단계의 출력에 의존하는 선형 작업에 적합하다.

• 언제 쓰나: 자연스러운 선형 진행(리서치→초안→검토→발행), 디버깅 단순함이 지연시간보다 중요할 때
• 실패 모드: 에이전트 하나가 죽으면 전체 파이프라인이 멈춘다. 그리고 C는 A의 추론 과정을 볼 수 없어, 홉(hop)을 거칠수록 맥락이 소실된다
• 설계 규칙: 에이전트 간에는 산문이 아니라 구조화된 출력을 넘겨라. 사슬 길이는 5개를 넘기지 마라 — 그 이상은 품질이 급격히 떨어진다

패턴 2 — 병렬 팬아웃/팬인(Parallel Fan-Out / Fan-In)

같은 입력을 여러 관점에서 동시에 처리한다. 하나의 계약서를 법률·재무·기술 팀이 동시에 검토하는 식이다.

• 언제 쓰나: 하위 작업이 서로 독립적이고 동시 실행 가능할 때, 지연시간 단축이 중요할 때
• 실패 모드: 한 에이전트가 죽으면 부분 결과만 온다. 신서사이저는 "전부 도착 / 일부 도착 / 하나도 없음"을 모두 명시적으로 처리해야 한다
• 설계 규칙: 팬아웃하는 에이전트들은 진짜로 독립적이어야 한다(공유 가변 상태 금지). 병렬 폭은 7개를 넘기지 마라 — 종합 품질이 무너진다

패턴 3 — 계층형: 오케스트레이터-서브에이전트(Hierarchical)

이것이 2026년 현재 사실상의 표준이다. 별도 절에서 자세히 다룬다.

• 언제 쓰나: 작업이 복잡하고 하위 작업이 미리 정해지지 않아 동적 분해가 필요할 때
• 실패 모드: 오케스트레이터가 병목이 되고, 그 프롬프트 복잡도가 무한히 커진다. 서브에이전트들이 각자 목표는 달성했는데 서로 모순되는 답을 낼 수 있다
• 설계 규칙: 오케스트레이터는 작업 원장(task ledger)을 유지해야 한다 — 무엇을, 누구에게, 상태는, 결과는. 서브에이전트 출력은 전문(全文)이 아니라 요약으로 받아 컨텍스트 폭발을 막는다

패턴 4 — 평가자-최적화자 루프(Evaluator-Optimizer)

품질을 점수로 잴 수 있는 작업에 강력하다. 글쓰기·코드처럼 첫 시도가 완벽하지 않은 결과물을 반복 개선한다.

• 실패 모드: 평가 기준이 불가능하거나 모순되면 무한 루프. Generator와 Evaluator가 같은 맹점을 공유하면 개선 없이 뱅뱅 돈다
• 설계 규칙: 하드 종료 조건(최대 3회)을 반드시 걸어라. 점수가 2회 연속 정체되면 탈출해 사람에게 넘겨라. Generator와 Evaluator는 다른 모델이거나 다른 프롬프트여야 한다

패턴 5 — 메시/피어 네트워크(Mesh)

전문가 패널의 토론을 시뮬레이션한다. 아무 에이전트도 혼자서는 최종 결정을 내릴 충분한 맥락이 없을 때 쓴다.

• 실패 모드: 최고 복잡도. 순환 의존, 합의 교착, 서로의 출력을 읽으며 컨텍스트가 기하급수적으로 폭발. 디버깅이 지옥이다
• 설계 규칙: 아키텍트의 조언은 단호하다 — "프로덕션에서 옳은 선택인 경우가 거의 없다. 먼저 계층형을 기본값으로 삼고, 메시를 정당화할 수 있을 때만 써라." 반드시 중재자 에이전트와 종료 조건(최대 라운드)을 둬라

5.2 조용한 살인자, 컨텍스트 예산(Context Budget)

위상을 골랐다면 다음 벽은 컨텍스트다. 아키텍트가 가장 강조하는 문제다. 5개짜리 순차 사슬에서 컨텍스트는 이렇게 눈덩이처럼 불어난다.

컨텍스트 예산이 고갈되면 무슨 일이 벌어지나? 환각, 지시 무시, 그리고 초반의 핵심 맥락이 잘려나가는 조용한 truncation. 프로덕션 장애의 대표적 원인이다. 아키텍트의 절대 규칙 중 하나가 여기서 나온다.

"필수 컨텍스트를 절대 조용히 잘라내지 마라. 압축해도 필수 필드가 안 들어가면 멈추고 사람에게 에스컬레이션하라 — 조용한 truncation은 프로덕션 무언(silent) 실패의 주범이다."

대응 전략은 네 가지다: ① 요약 압축(각 에이전트가 200토큰 이하 요약을 함께 생산), ② 구조화된 상태 객체(공유 스키마에서 각자 필요한 필드만 읽고 씀), ③ 외부 메모리 스토어(긴 산출물은 벡터DB에 두고 필요한 것만 조회), ④ 컨텍스트 체크포인트(마일스톤마다 이전 상태를 요약으로 압축).

5.3 실패는 예외가 아니라 설계 대상이다

아키텍트는 실패를 분류(taxonomy)부터 한다. 각 실패마다 탐지법과 복구법이 다르기 때문이다.

여기서 소프트웨어 공학의 고전 기법들이 그대로 소환된다. 회로 차단기(Circuit Breaker) — 특정 에이전트의 실패율이 임계치를 넘으면(예: 5회 중 3회) 회로를 OPEN으로 바꿔 그 에이전트를 잠시 호출하지 않고, 쿨다운 뒤 HALF-OPEN으로 한 번 시험 호출한다. 그리고 모든 프로덕션 에이전트는 폴백 사슬을 갖는다.

설계 원칙: 시스템은 항상 무언가는 내놓아야 한다. 구조화된 '저하 모드' 응답이라도, 아무 말 없는 무언 실패보다 낫다.

5.4 최소 권한과 프롬프트 인젝션 방어

분산 시스템의 또 다른 교훈 — 최소 권한(least privilege). 각 에이전트는 자기 역할에 필요한 도구·데이터에만 접근한다. 아키텍트는 아예 도구 접근 매트릭스를 그린다.

핵심 규칙: "스코프 토큰은 에이전트 간에 절대 전달하지 않는다." 그리고 웹페이지·문서·이메일 같은 외부 콘텐츠는 적대적(hostile)으로 취급한다. 프롬프트 인젝션 방어를 위해 콘텐츠 처리와 지시 처리를 분리하고, 전용 '살균(sanitizer)' 에이전트가 신뢰할 수 없는 콘텐츠에서 구조화된 데이터만 뽑아 하류로 넘긴다. 출력은 스키마로 검증한다 — 주입된 지시문은 유효한 JSON을 만들지 못하기 때문이다.

5.5 사람은 언제 개입해야 하는가 (HITL)

마지막 아키텍처 조각은 인간 개입 게이트(Human-in-the-Loop)다. 아키텍트가 짚는 함정은 미묘하다.

• 과잉 개입: 사람을 끊임없이 부르면 → 사람이 기계적으로 승인 도장만 찍게 되고 → HITL은 안전장치가 아니라 연극이 된다
• 과소 개입: 사람이 엣지 케이스를 영영 못 보면 → 시스템은 근거 없는 자신감을 쌓고 → 정작 중요한 순간에 파국적으로 실패한다

그래서 게이트는 되돌릴 수 없는 행동(대량 이메일 발송, 레코드 삭제), 큰 파급(100명 이상/1만 달러 이상 영향), 낮은 신뢰도(신뢰 점수 0.7 미만), 규제 노출(법률·의료·금융 조언)일 때만 건다. 나머지는 통과시키되 비동기로 표본 검토(sampling)한다.

---

6. 실전: 4주 만에 MVP 만들기

이론이 실제로 어떻게 굴러가는지, 저장소의 워크플로 예제 중 '스타트업 MVP' 시나리오를 보자. 원격 팀용 회고(retrospective) SaaS를 4주 만에 출시하는 과제다. 이것은 계층형 + 순차 + 평가자 게이트를 조합한 실전 파이프라인이다.

여기서 Reality Checker가 각 마일스톤을 통과시키는 게이트 역할을 한다는 점이 핵심이다. 앞서 본 HITL·평가자 패턴이 실제 워크플로에 녹아 있다. 에이전트 간에는 산문이 아니라 이전 에이전트의 산출물을 구조화해서 붙여넣기([paste Backend Architect output])로 넘긴다 — 5.1에서 본 "구조화된 출력을 넘겨라" 규칙 그대로다.

이 조합은 무한히 변주된다. 저장소는 마케팅 캠페인(콘텐츠+트위터+인스타+레딧+애널리틱스), 엔터프라이즈 기능 개발, 스마트 캠퍼스 디지털 트윈(GIS+3D+GeoAI+QA) 같은 시나리오도 제공한다.

---

7. 2026년, 이 기술은 어디에 서 있나

2025년 내내 업계는 뜨겁게 싸웠다. "멀티 에이전트, 만들어야 하나 말아야 하나?"

제목만 보면 정반대다. 하지만 두 글을 뜯어보면 놀랍게도 같은 결론으로 수렴한다. Cognition이 반대한 것은 '맥락을 공유하지 못하는 병렬 피어(mesh) 에이전트'였고, Anthropic이 성공한 것은 '리드가 격리된 서브에이전트에게 위임하는 계층형'이었다. 둘 다 5.1의 메시(패턴 5)는 피하고, 계층형(패턴 3)을 택하라고 말하고 있었던 것이다.

그리고 2026년 3월, 논쟁은 사실상 끝났다. Cognition은 "Devin이 이제 Devin들을 관리한다(Devin can now Manage Devins)"를 출시했다 — 코디네이터가 작업을 나눠, 각자 격리된 VM에서 도는 Devin에게 할당하고 결과를 취합한다. 그 정당화 논리("컨텍스트가 쌓이면 집중력이 떨어지고 각 하위작업의 품질이 나빠진다")는 Anthropic이 2025년에 했던 격리(isolation) 논증과 정확히 같다.

2026년의 합의: Anthropic, Cognition, OpenAI가 모두 같은 지점에 도착했다 — 오케스트레이터 + 격리된 서브에이전트. 이것이 바로 디 에이전시의 아키텍트가 처음부터 "기본값으로 계층형을 써라"고 말한 그 구조다.

바로 이 지점에서 디 에이전시의 진짜 가치가 드러난다. 이 저장소는 논쟁의 결론을 오픈소스로 구현해 놓은 부품 창고다.

• 상호운용성: 같은 에이전트 정의가 Claude Code, Cursor, Codex, Gemini CLI, Copilot, Windsurf, Aider 등 14개 이상의 도구에서 그대로 돈다. 마크다운이라는 공통 포맷 덕분이다
• 투명성: 블랙박스 SaaS가 아니라 포크하고 뜯어고칠 수 있는 평문 마크다운
• 커뮤니티 규모: 한국어 번역판(agency-agents-ko)을 포함해 7개 언어로 번역·현지화되어 있다. 184개 에이전트가 한국어로 제공된다

2026년, 개별 LLM은 이미 충분히 똑똑하다. 이제 경쟁의 무게중심은 "얼마나 똑똑한 모델인가"에서 "여러 에이전트를 얼마나 잘 조율하는 아키텍처인가"로 옮겨갔다. 디 에이전시는 그 아키텍처를 배우고, 훔치고, 조립하기에 가장 좋은 교재 중 하나다.

---

8. 마치며: 부품이 아니라 설계를 훔쳐라

디 에이전시를 처음 보면 "AI 캐릭터 232개 모음집"으로 보인다. 하지만 진짜 보물은 에이전트 개수가 아니다.

• 에이전트 하나의 해부학 — 성격은 감성이 아니라 압축된 행동 제약이다
• 다섯 가지 위상 패턴 — 순차·병렬·계층형·평가자-최적화자·메시, 그리고 "기본값은 계층형"이라는 뼈아픈 교훈
• 분산 시스템의 규율 — 컨텍스트 예산, 실패 분류학, 회로 차단기, 폴백 사슬, 최소 권한, HITL 게이트

민스키가 1986년에 "작은 마음들이 모여 지능이 창발한다"고 썼을 때, 그는 40년 뒤 이 아이디어가 별 12만 개짜리 GitHub 저장소가 되리라곤 몰랐을 것이다. 하지만 그의 통찰은 정확했다. 지능은 하나의 거대한 두뇌가 아니라, 잘 조율된 전문가들의 협업에서 나온다.

코어닷투데이는 실제 프로덕션에서 이 원칙을 매일 마주한다. 고객사의 AI 시스템을 설계할 때, 우리가 가장 많이 하는 질문은 "어떤 모델을 쓸까?"가 아니라 "이 일을 몇 개의 에이전트로 나누고, 실패하면 어디로 떨어뜨릴까?"다. 디 에이전시의 아키텍트가 던지는 바로 그 질문이다.

"데모는 거짓말을 하고, 프로덕션은 진실을 말한다."

이 한 문장을 기억한다면, 당신은 이미 좋은 멀티 에이전트 시스템 아키텍트의 첫 관문을 통과한 것이다.

---

참고 자료

• msitarzewski/agency-agents — The Agency (GitHub, MIT)
• Multi-Agent Systems Architect 에이전트 정의
• Anthropic — How we built our multi-agent research system
• Anthropic — Building Effective Agents
• Cognition — Don't Build Multi-Agents
• Park et al. — Generative Agents: Interactive Simulacra of Human Behavior (2023)
• Marvin Minsky — The Society of Mind (1986)
• 한국어 번역판 — agency-agents-ko