Thin Orchestrator: Meta가 에이전트 하나를 14개로 나눠 3~4일 작업을 1시간 안에 끝낸 구조

Meta는 에이전트를 똑똑하게 만드는 대신 일을 나눴습니다. 경로를 정하는 오케스트레이터는 규칙만 따르게 하고 도메인 판단은 서로 맥락을 섞지 않는 하위 에이전트 14개에 맡겼습니다. 따라 하려면 업무를 단계로 쪼갠 템플릿, 단계별 지식 파일, 위임 전에 멈춰 세우는 게이트를 먼저 만들어야 합니다.

요약

Meta 엔지니어링 팀은 추천 시스템에 새 데이터 칼럼을 올리는 일(칼럼 온보딩)을 에이전트에게 맡겼습니다. 이 일은 코드 저장소 3곳, 프로그래밍 언어 3개, 최대 6단계 파이프라인에 걸쳐 있습니다. Python 설정이 C++ 코드 생성을 이끌고 그 코드가 데이터 처리 서비스와 분석 시스템까지 이어지는 config-as-code(설정을 코드로 관리하는 방식) 구조입니다. 처음에는 설정 스키마, 코드 생성 규칙, 라우팅 규칙, 검증 요건, 데이터 소스 10여 곳의 패턴을 모두 아는 단일 에이전트를 만들었습니다. 데모에서는 잘 돌았지만 운영에서는 환각을 일으켰습니다. 지식이 일정량을 넘자 한 하위 시스템의 필드 이름 규칙을 다른 시스템에 쓰는 식으로 개념이 섞였습니다.

팀은 이 문제를 프롬프트가 아니라 구조의 문제로 봤습니다. 다른 단일 에이전트 방식은 과제마다 프롬프트를 손으로 다듬어야 70~80% 성공했고 그렇지 않으면 10~20%에 그쳤기 때문입니다. 새 구조에서는 약 1,300줄짜리 결정론적 오케스트레이터가 20개가 넘는 워크플로를 받아 전문 하위 에이전트 14개에 나눠 줍니다. 오케스트레이터는 의도 분류, 필드 수집, 신뢰성 점검, 위임만 하고 코드에는 손대지 않습니다. 그 결과 칼럼 하나의 설정 준비가 사람 손으로 3~4일, 이전 config 방식으로 약 1일 걸리던 것이 1시간 미만으로 줄었습니다. 시스템이 만든 변경의 약 3분의 2는 사람이 크게 고치지 않고 반영됩니다. 아래에서는 이 구조를 다섯 가지 장치로 나눠 보고 직접 만들 때 필요한 기술·현업 디테일을 덧붙입니다.

핵심 메커니즘

Single Agent Overload: 지식을 한 에이전트에 몰아넣을 때 생기는 섞임

모든 도메인 지식을 한 에이전트의 맥락에 넣으면, 어느 선을 넘는 순간부터 지식이 늘수록 결과가 나빠집니다. 에이전트가 비슷해 보이는 규칙을 엉뚱한 곳에 갖다 쓰기 때문입니다. Meta의 단일 에이전트는 한 데이터 소스용 코드 생성 패턴을 다른 데이터 소스에 적용했습니다. 이 상태에서는 성공률이 과제마다 프롬프트를 얼마나 손봤는지에 따라 70~80%와 10~20% 사이를 오갑니다. 규칙이 서로 비슷하지만 섞이면 안 되는 하위 시스템이 여럿인 업무라면 이 신호를 먼저 의심합니다. 가상 예시를 들면, 국내 제조사가 공장 세 곳의 BOM 변경 규칙을 한 에이전트에 넣으면 A 공장의 품번 체계를 B 공장 변경 요청에 쓰는 일이 생길 수 있습니다.

Thin Orchestrator: 경로만 정하고 도메인 일은 하지 않는 조율기

Thin Orchestrator는 요청을 받아 어느 하위 에이전트에게 넘길지만 정하는 조율기입니다. 정해진 7단계를 그대로 밟습니다. 먼저 하위 에이전트의 지시 파일을 읽고 대상이 이미 있는지 확인합니다. 이어 필수 입력값을 모으고 추론 가능한 값은 자동으로 찾습니다. 경고나 필수 리뷰어가 걸려 있는지 신뢰성 게이트로 확인한 뒤 맥락을 담아 위임합니다. 마지막으로 결과를 받아 오류를 드러내거나 성공을 확인합니다. 이 중 LLM이 추론하는 곳은 6단계 위임 하나이고 그것도 격리된 하위 에이전트 안에서 일어납니다. 하위 에이전트를 고르는 일은 추론이 아니라 라우팅이므로 LLM을 쓰지 않는다는 것이 Meta의 원칙입니다. 그래서 오케스트레이터는 잘못된 경로로 보내거나 점검을 건너뛰는 환각을 일으킬 여지가 거의 없습니다. 업무 종류가 여럿이고 각각 다른 전문 지식이 필요한 곳에 맞습니다. 업무가 하나뿐이고 단계가 짧다면 이 층을 따로 둘 이유가 적습니다.

Specialist Subagent: 자기 지식만 아는 전문 하위 에이전트

하위 에이전트는 자기 도메인 지식만 불러와 일하는 전문가입니다. Meta가 이름을 밝힌 것은 셋입니다. 설정 레지스트리를 아는 스키마 관리 에이전트, 데이터 소스 10곳 각각의 코드 생성법을 아는 population(데이터 채우기) 에이전트, 빌드 시스템과 품질 점검을 아는 검증 에이전트입니다. 14개 모두 지식 소스, 사전 체크리스트, 단계별 절차, 모노레포 탐색 패턴, 오류와 해결법 매핑이라는 같은 다섯 칸 구조를 씁니다. 구조가 같으니 새 하위 에이전트를 만드는 일이 처음부터 짜는 개발이 아니라 틀을 채우는 작업이 됩니다. 맥락이 격리돼 있어 데이터 소스 A를 맡은 에이전트는 B의 패턴을 볼 수 없으니 섞어 쓸 수도 없습니다. 한 에이전트가 실패해도 오케스트레이터가 재시도하거나 사람에게 올리며 다른 에이전트의 맥락은 그대로 남습니다.

Workflow Template: 같은 에이전트를 다른 순서로 부르는 상태 기계

워크플로 템플릿은 무엇을 어떤 순서로 해야 하는지를 정한 결정론적 상태 기계입니다. 각 단계를 어떻게 하는지는 하위 에이전트가 맡습니다. 칼럼 온보딩은 Schema → Validation → Population → Testing 순서이고 이벤트 온보딩은 끝에 Event Processing이 붙습니다. 템플릿이 단계 순서를 고정하므로 LLM이 고를 수 있는 선택지가 좁아집니다. Meta는 파이프라인 이전이라는 새 업무를 Assessment → Planning → Population → Validation → Monitoring 템플릿 하나로 추가했고 새 에이전트 코드는 한 줄도 쓰지 않았습니다. 새 업무가 들어오면 에이전트를 새로 만들기 전에 기존 에이전트의 순서만 바꿔서 될지부터 봅니다. 순서만 바꿔서 안 된다면 에이전트가 특정 용도에 너무 묶여 있다는 신호입니다.

Runtime Knowledge Loading: 지식을 코드에서 떼어 실행 시점에 싣기

도메인 지식은 오케스트레이터 안에 넣지 않고 25개가 넘는 지식 파일로 나눠 하위 에이전트가 실행될 때만 불러옵니다. 파일 하나는 보통 수천 토큰 분량이고 워크플로 도메인별로 정리돼 있습니다. 지식 파일을 고치면 오케스트레이터를 다시 배포하지 않아도 다음 세션부터 반영됩니다. 같은 파일을 여러 플랫폼 구현이 함께 씁니다. 이렇게 층을 나누면 각 층을 따로 개선할 수 있습니다. 더 나은 모델로 바꾸면 14개 하위 에이전트가 한꺼번에 좋아지고 지식 파일을 고치면 바로 반영되고 템플릿을 더하면 에이전트를 건드리지 않고 기능이 늘어납니다. 규칙이 자주 바뀌는 업무일수록 효과가 큽니다.

통념과 다른 주장

저자가 든 사례

사례 1. 데이터 칼럼 온보딩

상황	한 일	결과	연결
칼럼 하나를 올리려면 저장소 3곳, 언어 3개, 최대 6단계를 사람이 맞춰야 했고 3~4일 걸림. 단일 에이전트는 운영에서 환각	결정론적 오케스트레이터와 하위 에이전트 14개, Column Onboarding 템플릿으로 재구성	설정 준비 1시간 미만(이전 config 방식은 약 1일). 변경의 약 3분의 2가 큰 사람 수정 없이 반영	Thin Orchestrator, Specialist Subagent

사례 2. 파이프라인 이전

상황	한 일	결과	연결
파이프라인 이전이라는 새 업무가 필요해짐	에이전트는 그대로 두고 Assessment → Planning → Population → Validation → Monitoring 템플릿을 새로 씀	새 에이전트 코드 없이 운영 기능 확보. 소요 기간은 원문에서 밝히지 않음	Workflow Template

기술 디테일: 같은 구조를 직접 만든다면

아래 필드명, 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. Meta가 밝힌 구조를 실제로 돌릴 때 필요한 것을 정리했습니다.

Thin Orchestrator의 라우팅을 코드로 만들려면 LLM 프롬프트가 아니라 설정 파일과 규칙으로 씁니다. 의도는 키워드와 정규식으로 분류하고 둘 이상 걸리거나 하나도 안 걸리면 LLM으로 넘기지 말고 사용자에게 되묻습니다. 워크플로마다 required_fields를 두고 빠진 값은 4단계 자동 탐색(예: 저장소에서 기존 칼럼 정의 검색)으로 채운 뒤 그래도 비면 되묻습니다. 5단계 게이트는 활성 경고나 필수 리뷰어가 있으면 위임하지 않고 멈춥니다. 오케스트레이터 로그에는 단계 번호, 고른 템플릿, 고른 하위 에이전트, 게이트 결과를 한 행씩 남깁니다.

{
  "workflow": "column_onboarding",
  "intent_keywords": ["칼럼 추가", "add column", "new feature column"],
  "template": ["schema", "validation", "population", "testing"],
  "required_fields": ["column_name", "data_source", "dtype", "owner_team"],
  "auto_discover": {"data_source": "repo_search:feature_registry"},
  "gate": {"block_if": ["active_warning", "required_reviewer_missing"]},
  "on_subagent_fail": {"retry": 1, "then": "escalate_to_owner"}
}

하위 에이전트 14개를 같은 틀로 찍어 내려면 에이전트마다 명세 파일 하나를 둡니다. 칸은 Meta의 다섯 칸을 그대로 씁니다. knowledge에는 불러올 지식 파일 경로를, checklist에는 오케스트레이터가 모아 와야 할 필드를, steps에는 절차를, discovery에는 저장소 검색 패턴을, troubleshooting에는 자주 나는 오류 메시지와 해결법을 적습니다. 지식 파일은 하나에 3,000~5,000토큰 정도로 자르고 다른 하위 에이전트의 지식 파일은 경로 목록에 넣지 않습니다. 출력은 diff와 함께 changed_files, assumptions, open_questions를 담은 JSON으로 강제하고 temperature는 0으로 둡니다. open_questions가 하나라도 있으면 오케스트레이터가 성공으로 처리하지 않고 사람에게 넘깁니다.

구조를 바꾼 효과를 숫자로 확인하려면 평가 하네스를 먼저 만듭니다. 템플릿마다 사람이 정답 diff를 만든 골든 과제 10건, 모두 30건을 준비하고 과제마다 3회씩 돌립니다. 채점은 빌드 통과 여부, 필수 필드 일치, 사람이 고친 줄 수 세 가지로 합니다. 같은 과제의 세 번 결과가 서로 다르면 그 하위 에이전트의 지식 파일이나 체크리스트가 모자란 것으로 보고 따로 표시합니다. 모델을 바꾸거나 지식 파일을 고칠 때마다 30건을 다시 돌려 이전보다 나빠진 과제가 없을 때만 배포합니다.

실패하는 경우	대응 (가상 예시)
의도가 두 워크플로에 동시에 걸림	LLM으로 고르지 않고 사용자에게 선택지를 보여 되묻기
하위 에이전트가 다른 데이터 소스 규칙을 씀	지식 파일 경로를 명세에 고정, 다른 소스 파일은 목록에서 제외
같은 과제인데 실행마다 diff가 다름	3회 실행 비교, 불일치 과제는 지식 파일 보강 대상으로 등록
리뷰어가 필요한 변경인데 바로 반영됨	5단계 게이트를 우회하는 경로를 막고 우회 1건이면 배포 중단
하위 에이전트 실패가 반복됨	재시도 1회 뒤 담당 팀에 넘기고 오류 메시지를 troubleshooting에 추가

현업 실행 디테일: 누가, 언제, 무엇을

자기 조직의 반복 엔지니어링 업무나 백오피스 업무에 이 구조를 붙인다면 역할부터 나눕니다. 아래 표와 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
플랫폼 오너(데이터 플랫폼·업무 팀장)	첫 대상 업무 선정, 템플릿 단계 순서 승인, 확대 여부 판정
에이전트 엔지니어(1~2명)	오케스트레이터, 게이트, 평가 하네스 구축과 운영
도메인 담당(하위 에이전트당 1명)	지식 파일 작성·갱신, 오류와 해결법 매핑 관리
리뷰어	시스템이 낸 변경 검토, 고친 줄 수 기록

시작 전 준비물은 네 가지입니다. 최근 처리한 같은 종류의 작업 기록 20~30건과 그 결과물, 단계마다 누가 무엇을 확인했는지 적은 업무 흐름도, 시스템·소스별 규칙 문서, 현재 소요 시간 측정값입니다. 특히 소요 시간은 시작 전에 재 둬야 나중에 Meta의 3~4일 → 1시간 미만 같은 비교를 할 수 있습니다.

기간	할 일	산출물
1~2주	업무를 단계로 쪼개고 단계별 필요 지식 나누기, 골든 과제 작성	템플릿 초안, 지식 파일 목록, 골든 과제 30건
3~4주	오케스트레이터와 하위 에이전트 2~3개 구축, 게이트 연결	동작하는 첫 템플릿, 평가 결과
5~6주	사람 작업과 병행 운영, 매일 diff 비교	불일치 목록, 지식 파일 수정 이력
7~8주	판정 회의, 두 번째 템플릿 후보 선정	판정 보고서, 다음 템플릿

확인 질문은 이렇게 준비합니다. 이 업무에서 서로 섞이면 안 되는 규칙 묶음은 몇 개입니까? 어떤 단계는 규칙으로 정할 수 있고 어떤 단계에 사람의 판단이 필요합니까? 반드시 사람 리뷰어가 봐야 하는 변경은 무엇입니까? 지식 파일은 누가 고치고 얼마나 자주 바뀝니까? 새 업무가 생기면 기존 단계의 순서만 바꿔서 처리할 수 있습니까?

진행 판정 기준은 업무마다 다시 정하되 출발점은 셋입니다. 준비 시간이 기존 대비 50% 이하일 것, 시스템 변경의 50% 이상이 큰 수정 없이 반영될 것, 게이트 우회가 0건일 것입니다. Meta가 밝힌 약 3분의 2 반영률은 오래 다듬은 운영 수치이므로 첫 판정 기준은 그보다 낮게 잡습니다.

AX 적용 제언. 국내 기업이 가져갈 것은 에이전트 개수가 아니라 나누는 기준입니다. ERP 마스터 등록, 신규 거래처 등록, 데이터 파이프라인 변경처럼 여러 시스템에 걸치고 규칙이 비슷하지만 섞이면 안 되는 업무가 첫 대상으로 좋습니다. 먼저 업무를 단계로 쪼개 순서는 템플릿으로 고정하고 판단이 필요한 단계만 하위 에이전트로 만듭니다. 지식 파일은 IT가 아니라 그 규칙을 아는 현업 팀이 주인이 되게 합니다. 첫 템플릿에서 만든 하위 에이전트를 두 번째 업무에 재사용할 수 있는지가 이 구조가 제대로 섰는지 보는 시험입니다.

원문 사례

항목	내용
기사	TechTarget, James Alan Miller, 「What CIOs are learning as AI agents take on real workflows」
이 노트가 읽은 1차 자료	Meta Engineering 블로그, Plawan Rath·Akhil Jindal·Ashwini Verma, 2026.10.19
대상 업무	추천 시스템 데이터 칼럼 온보딩. 저장소 3곳, 언어 3개, 최대 6단계 파이프라인
처음 설계	모든 지식을 넣은 단일 에이전트. 데모에서 동작, 운영에서 환각
비교 기준	다른 단일 에이전트 방식: 수작업 프롬프트 있을 때 70~80%, 없으면 10~20% 성공
새 설계	결정론적 오케스트레이터 약 1,300줄, 워크플로 20개+, 하위 에이전트 14개, 지식 파일 25개+, 데이터 소스 10개+
결과	칼럼 설정 준비: 사람 3~4일 → 이전 config 방식 약 1일 → 1시간 미만. 변경 약 3분의 2가 큰 수정 없이 반영
확장	파이프라인 이전을 새 템플릿만으로 추가, 새 에이전트 코드 없음
인용 연구	Mount Sinai 사전 공개 논문: 80개 과제 묶음에서 멀티 에이전트 65.3% vs 단일 16.6%, 토큰 최대 65분의 1
다음 계획	템플릿·지식 파일 추가로 새 파이프라인 도메인 확장, 지식 개선 제안 자동화(변경은 항상 사람 검토)

핵심 개념

config-as-code

시스템 설정을 코드 파일로 관리해 버전 관리와 자동 생성을 하는 방식입니다.

deterministic

같은 입력이면 늘 같은 결과를 내는 처리입니다. 이 노트에서는 LLM 없이 규칙으로 도는 부분을 말합니다.

reliability gate

위임 전에 경고나 필수 리뷰어 같은 조건을 확인해 일을 멈춰 세우는 점검 단계입니다.

monorepo

여러 프로젝트의 코드를 저장소 하나에 모아 관리하는 방식입니다.

context isolation

에이전트마다 자기 일에 필요한 지식만 보게 해 다른 도메인 규칙이 섞이지 않게 하는 설계입니다.

state machine

정해진 단계와 다음 단계로 넘어가는 조건을 미리 고정해 둔 흐름입니다.

내 메모

TODO: 내 생각 추가

이 노트는 TechTarget 기사 「What CIOs are learning as AI agents take on real workflows」(James Alan Miller)에서 소개된 Meta 사례를 다룹니다. 기사 페이지를 열지 못해 그 사례의 1차 자료인 Meta Engineering 블로그 「The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do」(Plawan Rath·Akhil Jindal·Ashwini Verma, 2026.10.19)를 읽고 썼습니다. 그래서 기사에 함께 실린 Lendi, Trust Bank 싱가포르 사례와 기자의 해설은 이 노트에 담지 않았습니다. 요약, 핵심 메커니즘의 Meta 내용, 통념과 다른 주장, 사례, 원문 사례 표는 Meta가 공개한 내용을 AX Review가 다시 정리했습니다. Meta 블로그의 표현을 빌리면 “No single component carries the full weight.”입니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전문은 기사 페이지와 Meta Engineering 블로그(engineering.fb.com)에서 볼 수 있습니다.