AI 에이전트가 자꾸 헛소리한다면? 얇은 오케스트레이터 패턴으로 해결한 실전 사례

왜 만능 에이전트는 프로덕션에서 무너지는가

AI 에이전트를 실무에 붙이다 보면 누구나 같은 함정에 빠집니다. "하나의 똑똑한 에이전트에 모든 도메인 지식을 넣자." 데모에서는 잘 돌아갑니다. 그런데 프로덕션에 올리면 환각(Hallucination)이 터지기 시작하죠.

메타(Meta)의 데이터 파이프라인 팀도 똑같은 길을 걸었습니다. 추천 시스템의 데이터 컬럼 온보딩 자동화를 위해, 3개 저장소·3개 언어·최대 6단계 파이프라인을 아우르는 단일 에이전트를 만들었습니다. 결과는 참담했습니다. 에이전트가 A 서브시스템의 필드 명명 규칙을 B 서브시스템에 갖다 붙이거나, 다른 데이터 소스용 코드 생성 패턴을 엉뚱한 곳에 적용하는 '컨텍스트 오염(Context Contamination)'이 발생한 겁니다.

핵심 원인은 프롬프트가 아니었습니다. 아키텍처였어요. 컨텍스트 임계치를 넘어서면 지식을 더 넣을수록 성능이 오히려 떨어집니다. 실제로 Mount Sinai의 연구에 따르면, 태스크를 격리한 멀티에이전트 구조는 80개 태스크 배치에서 65.3% 정확도를 유지한 반면, 단일 에이전트는 16.6%까지 추락했습니다. 토큰 사용량도 최대 65분의 1로 줄었고요.

여기서 얻은 교훈은 명확합니다. "에이전트에게 일을 덜 시켜야 한다." 이 글에서는 메타가 실제로 적용한 '얇은 오케스트레이터(Thin Orchestrator)' 패턴을 뜯어봅니다. 근거자료는 Meta Engineering 블로그에서 확인하실 수 있어요.

구조: 결정론적 라우터 + 14명의 전문가

메타가 만든 시스템의 핵심은 두 계층 분리입니다.

1) 오케스트레이터: 도메인 작업을 '0'으로

1,300줄짜리 오케스트레이터는 20개 이상의 워크플로우를 14개 전문 에이전트로 라우팅합니다. 이 녀석은 코드를 추론하지도, 설정을 생성하지도, 코드베이스에 손대지도 않습니다. 그냥 라우터예요.

모든 요청에 대해 고정된 7단계 프로토콜을 따릅니다.

1. 대상 서브에이전트의 지시 파일 읽기
2. 타깃 존재 여부 확인 (중복 방지)
3. 사용자로부터 필수 필드 수집
4. 추론 가능한 값 자동 탐색 (저장소 타입, 기존 설정)
5. 신뢰성 게이트 체크 (활성 경고, 필수 리뷰어)
6. 서브에이전트에 전체 컨텍스트와 함께 위임
7. 결과 처리 및 에러 서피싱, 성공 확인

1~5단계와 7단계는 **결정론적(Deterministic)**입니다. LLM 추론은 오직 6단계에서만, 그것도 격리된 서브에이전트 안에서만 일어납니다. 이게 포인트예요.

2) 서브에이전트: 격리된 도메인 전문가 14명

각 서브에이전트는 완전한 도메인 전문가이며, 자기 컨텍스트만 봅니다. 스키마 관리 에이전트는 설정 레지스트리를 알고, 파퓰레이션(Population) 에이전트는 10개 데이터 소스별 코드 생성법을 알며, 검증 에이전트는 빌드 시스템과 품질 체크를 압니다. 아무도 전체 그림을 보지 못합니다. 이건 버그가 아니라 기능입니다.

워크플로우 템플릿: 새 에이전트 대신 새 순서

여기서 진짜 아키텍처 인사이트가 나옵니다. "무엇을 해야 하는가"와 "각 단계를 어떻게 수행하는가"를 분리한 거죠. 오케스트레이터는 워크플로우 템플릿으로 단계 순서를 정의합니다.

컬럼 온보딩:   Schema → Validation → Population → Testing
이벤트 온보딩: Schema → Population → Validation → Testing → Event Processing
파이프라인 마이그레이션: Assessment → Planning → Population → Validation → Monitoring

각 템플릿은 동일한 14개 서브에이전트 풀을 다른 순서로 재사용합니다. 파이프라인 마이그레이션이라는 완전히 새로운 유스케이스가 필요했을 때, 메타는 새 에이전트를 만들지 않았습니다. 기존 에이전트를 다르게 배열한 새 워크플로우 템플릿만 작성했죠. 에이전트 코드 신규 0줄, 프로덕션 기능은 풀 스펙입니다.

서브에이전트 표준 구조

15번째 서브에이전트는 1번째와 구조적으로 동일합니다. 이게 확장성의 핵심이에요.

- Knowledge sources: 런타임에 로드할 도메인 파일 (보통 수천 토큰)
- Pre-gathering checklist: 위임 전 오케스트레이터가 수집할 항목
- Step-by-step workflow: 도메인별 실행 계획
- Discovery patterns: 모노레포에서 관련 코드 패턴 찾는 법
- Troubleshooting: 흔한 실패에 대한 에러→해결 매핑

지식 파일은 빌드 타임이 아니라 런타임에 온디맨드로 로드됩니다. 25개 이상의 지식 파일을 워크플로우 도메인별로 관리하고, 파일이 업데이트되면 다음 세션에서 자동으로 최신 버전을 씁니다. 오케스트레이터는 건드릴 필요가 없죠.

결과와 주의사항

정량적 성과

왜 이게 통하는가

얇은 오케스트레이터가 작동하는 이유는 아키텍처 경계와 연산 경계를 일치시키기 때문입니다.

• 결정론적 결정은 결정론적으로 유지: "어떤 서브에이전트가 이걸 처리하지?"는 라우팅 결정이지 추론 태스크가 아닙니다. 여기에 LLM을 쓰지 마세요.
• 컨텍스트 격리: 데이터 소스 A의 파퓰레이션 에이전트는 소스 B의 패턴을 절대 못 봅니다. 잘못된 걸 환각할 수가 없어요.
• 실패 격리: 서브에이전트가 실패하면 오케스트레이터가 재시도하거나 에스컬레이션합니다. 실패가 오케스트레이터 상태나 다른 서브에이전트 컨텍스트를 오염시키지 않습니다.
• 레이어별 독립 개선: 더 좋은 모델은 14개 서브에이전트를 동시에 개선합니다. 지식 파일 업데이트는 즉시 반영됩니다.

⚠️ 주의사항 (비판적 시각)

이 패턴이 만능은 아닙니다. 다음 상황에서는 재검토가 필요해요.

• 워크플로우가 단순할 때: 단일 에이전트로 충분한 태스크에 14개 서브에이전트를 두는 건 과설계입니다. 오케스트레이션 오버헤드만 늘어나죠.
• 도메인 경계가 유동적일 때: 서브에이전트 간 지식 공유가 빈번해야 하는 태스크라면, 격리가 오히려 병목이 됩니다.
• 결정론적 라우팅 규칙 유지 비용: 라우팅 로직이 복잡해지면 그 자체가 유지보수 부담이 됩니다. 워크플로우 템플릿이 지나치게 많아지면 관리가 어려워져요.

한국 개발 생태계에서의 적용 맥락

국내 SI·스타트업 환경에서 특히 주의할 부분이 있습니다. 많은 팀이 "일단 만능 에이전트 하나 만들고 프롬프트로 튜닝"하는 접근을 시도하는데, 이건 PoC 단계에서만 유효합니다. 프로덕션 전환 시점에 반드시 아키텍처를 재설계해야 해요. 특히 사내 시스템이 여러 개로 쪼개져 있는 레거시 환경에서는 서브에이전트 경계를 '시스템 경계'에 맞추는 게 실무적으로 가장 효과적입니다. 또한 국내 팀은 보통 인력이 적어 14개 서브에이전트를 한 번에 다 만들기 어려우니, 가장 자주 깨지는 도메인 2~3개부터 서브에이전트로 분리하고 나머지는 단일 에이전트로 두는 점진적 접근을 권합니다.

실무 적용 가이드와 다음 단계

메타의 사례에서 바로 가져갈 수 있는 원칙 5가지를 정리합니다.

1. 라우팅과 추론을 분리하세요. 오케스트레이터가 도메인 결정을 내리고 있다면, 그건 일을 너무 많이 하는 겁니다. 라우팅은 키워드 매칭·의도 분류·필드 수집 등 결정론적으로 처리하고, 모든 도메인 추론은 격리된 서브에이전트로 밀어넣으세요.
2. 서브에이전트는 구조적으로 균일하게 설계하세요. 지식 소스·필수 입력·실행 단계·에러 처리를 모두 동일 구조로 맞추면, 새 기능 추가가 아키텍처 변경이 아니라 템플릿 작업이 됩니다.
3. 확장은 새 에이전트가 아니라 워크플로우 템플릿으로. 새 유스케이스가 생기면 먼저 물으세요. "기존 에이전트를 다르게 배열할 수 있나?" 재사용이 안 된다면 에이전트가 유스케이스에 과하게 결합된 겁니다.
4. 지식은 빌드 타임이 아니라 런타임에 로드하세요. 오케스트레이터에 지식을 임베드하면 모든 업데이트에 재배포가 필요합니다.
5. 결정론/확률 경계를 명시적으로 그으세요. 모든 컴포넌트에 대해 "이건 라우팅 결정인가, 추론 태스크인가?"를 물으세요. 오케스트레이터는 한쪽, 서브에이전트는 다른 쪽에 있어야 합니다. 섞지 마세요.

가장 강력한 논거는 대안의 실패 모드입니다. 무거운 오케스트레이터가 환각을 일으키면 에러가 다운스트림 전체로 퍼집니다. 잘못된 에이전트로 라우팅하고, 잘못된 필드를 모으고, 신뢰성 체크를 건너뛰죠. 얇은 오케스트레이터는 라우팅과 신뢰성 단계가 LLM 추론에 의존하지 않기 때문에 환각의 여지가 거의 없습니다. 창의성은 다운스트림, 즉 격리된 도메인 스코프 컨텍스트에서 발휘됩니다.

함께 보면 좋은 글

• 복잡한 광고 미디어 플랜, 멀티 에이전트 아키텍처로 정복하기 — 멀티 에이전트를 실무 도메인에 적용한 또 다른 사례
• 90일 걸리던 인프라 구축, 몇 시간으로 줄인 산탄데르의 플랫폼 엔지니어링 전략 — 플랫폼 엔지니어링 관점에서 본 자동화 전략

다음 단계 학습 방향

• 에이전트 오케스트레이션 프레임워크 비교: LangGraph, CrewAI, AutoGen 등이 이 패턴을 어떻게 구현하는지 살펴보세요.
• 결정론적 라우팅 설계: 의도 분류기를 LLM 없이 만드는 방법(임베딩 기반 클러스터링, 룰 엔진)을 학습하세요.
• 평가(Eval) 파이프라인: 서브에이전트별 정확도를 측정하는 평가 체계 없이는 이 아키텍처를 운영할 수 없습니다. 다음 학습 우선순위로 강력 추천합니다.