잘하는 에이전트가 좋은 오케스트레이터가 되지 못하는 이유
오케스트레이터란 가장 잘하는 에이전트가 아니라 역할 분리와 위임 설계를 담당하는 레이어다. Karpathy가 정의한 'outsource thinking but not understanding' 원칙과 Grok의 4에이전트 병렬 검증 구조는 환각률 65% 감소를 실측했다.
주제별 글 / 멀티에이전트
멀티에이전트
역할을 나눈 에이전트 팀, 오케스트레이터 설계, 병렬 실행의 명세 관리.
12편, 최신순
에이전트 팀이 단일 최고 모델을 이겼다
조직형 에이전트란 역할과 핸드오프가 명시적으로 설계된 멀티에이전트 구조다. AgentRadio 실험에서 4개 에이전트 팀이 단일 Claude Opus 4.8을 앞섰고, 스탠포드 연구팀은 3만7천 에이전트로 가상 바이오테크를 운영해 신약 후보를 설계했다.
잘하는 에이전트를 오케스트레이터로 쓰지 마라
오케스트레이터란 개별 에이전트의 실행 능력이 아닌 역할 배분과 검증 흐름을 설계하는 계층이다. Grok의 4에이전트 병렬 검증 구조는 환각률을 65% 낮췄고, Karpathy는 '이해는 위임 불가'를 오케스트레이터 설계의 핵심 원칙으로 제시했다.
에이전트 팀이 최고 모델을 이기는 이유
AgentRadio 실측에서 역할 분화된 4개 에이전트 팀이 단독 Claude Opus 4.8을 일관되게 앞섰습니다. 스탠퍼드 3.7만 에이전트 연구와 Grok 환각률 65% 감소 데이터가 같은 결론을 가리킵니다. 경쟁력은 모델 선택이 아니라 역할 설계에서 나옵니다.
병렬 에이전트의 승부는 숫자가 아니라 명세서다
Bun의 64에이전트·600줄 PORTING.md 케이스가 증명한 것. 멀티 에이전트를 잘 쓰는 팀과 못 쓰는 팀의 차이는 에이전트 숫자에 있지 않다.
에이전트를 병렬로 돌리기 전에 써야 할 것
64개 에이전트로 Rust 코드베이스를 11일 만에 재작성한 팀의 실제 시작점은 PORTING.md였다. 병렬 에이전트 설계에서 숫자보다 명세가 먼저인 이유.
에이전트 루프의 두 번째 뇌 — 생성과 검증을 분리해야 하는 이유
에이전트가 자기 출력을 스스로 검증하면 확증 편향이 생긴다. 2Brains 분리형 구조와 LangGraph TBC 패턴이 환각과 비용을 동시에 줄이는 방법을 PM 관점으로 정리했다.
에이전트에게 신원이 생겼다 — 오케스트레이션의 다음 레이어
에이전트가 10개를 넘어가는 순간 PM의 핵심 질문이 바뀐다. NewCore $66M 투자와 구글 딥마인드 AI 제어 로드맵이 같은 방향을 가리키는 것: 에이전트에게도 신원·권한·폐기 설계가 있어야 한다.
에이전트 전쟁의 다음 전선: 모델이 아니라 연결 표준이다
구글·MS의 ARD 에이전트 연결 표준과 LangChain의 파일-퍼스트 durable agent Leve가 같은 주에 공개됐다. 다음 경쟁은 모델 성능이 아니라 연결 표준과 상태 관리 설계에서 갈린다.
Codex와 Claude를 동시에 부리는 PM — 멀티 AI 워크플로우는 어떻게 표준이 되었나
한 PM이 가상 5명 팀을 운영하는 시대가 왔다. Claude Code, OpenAI Codex, Cursor 세 도구가 같은 화면 안에서 서로 다른 자리를 잡게 된 배경을 분석한다.
잘하는 에이전트가 오케스트레이터를 맡으면 생기는 일
멀티에이전트 시스템에서 가장 뛰어난 모델을 오케스트레이터로 쓰는 것은 직관적이지만 위험하다. '최고 직원=최악 관리자' 원칙이 AI 에이전트 설계에서 반복되는 이유와 PM의 처방을 다룬다.
AI 네이티브 PM 실전 시리즈
AI 팀원을 직접 만든다: Claude Code 에이전트 워크플로우 설계 실전
Claude Code의 .claude/agents/ 폴더에 에이전트를 정의하면 PM은 사실상 팀장이 됩니다. 리서처·엔지니어·마케터 에이전트를 병렬로 실행하는 멀티 에이전트 워크플로우를 설계하는 방법.