2026년 10월 19일, Meta 엔지니어링 팀은 공식 엔지니어링 블로그에 데이터 파이프라인 에이전트의 아키텍처 개편 과정을 정리한 글을 올렸다. 총괄 층은 약 1300줄 규모의 씬 오케스트레이터(얇은 조율층)가 되어 라우팅과 신뢰성 검사만 맡고 도메인 추론은 전혀 하지 않으며, 20개가 넘는 워크플로를 맥락이 서로 격리된 14개의 전문 서브에이전트에게 배분한다. 개편 후 새 데이터 열의 설정 준비 시간은 수작업 3~4일, 기존 시스템의 약 1일에서 1시간 이내로 줄었다.
전지형 총괄이 먼저 무너진 이유
Meta의 출발점은 대부분의 팀과 같았다. 설정 스키마, 코드 생성 규칙, 검증 요건, 10개가 넘는 데이터 소스의 채우기 방식을 하나의 컨텍스트에 전부 담은 단일 에이전트였다. 데모에서는 잘 됐지만 운영 환경에서는 환각을 일으키기 시작했다. 컨텍스트가 일정 임계점을 넘자 지식을 더할수록 성능이 떨어졌고, 서로 다른 하위 시스템의 명명 규칙과 생성 패턴이 뒤섞였다. 팀의 측정에서 단일 에이전트 방식은 엔지니어가 작업마다 전용 프롬프트를 손수 만들었을 때 성공률 70~80%, 그런 도움 없이는 10~20%까지 떨어졌다. 인용된 예비 연구에서도 같은 양상이 나타났는데, 조율된 멀티 에이전트 시스템은 80개 작업 묶음에서 정확도 65.3%를 유지한 반면 단일 에이전트는 16.6%까지 떨어졌고 토큰 사용량은 최대 65분의 1로 줄었다.
일곱 단계 중 대규모 모델이 쓰이는 단계는 하나뿐
씬 오케스트레이터는 모든 요청에 고정된 7단계 절차를 실행한다. 해당 서브에이전트의 지시 파일을 읽고, 대상이 이미 존재하는지 확인하고, 사용자에게 필수 항목을 받고, 추론 가능한 정보를 자동으로 찾고, 신뢰성 관문을 거친 뒤, 전체 컨텍스트와 함께 서브에이전트에게 위임하고, 결과와 오류를 처리하는 흐름이다. 1~5단계와 7단계는 결정적 처리이며, 대규모 모델 추론이 개입하는 단계는 6단계뿐이고 그마저도 자기 영역 지식만 불러온 격리된 서브에이전트 안에서 일어난다. 모든 서브에이전트는 지식 출처, 사전 수집 체크리스트, 실행 절차, 코드 탐색 패턴, 장애 대응표라는 동일한 구조를 공유한다. 25개가 넘는 지식 파일은 필요할 때 불러오므로, 업데이트는 오케스트레이터를 고치지 않아도 다음 세션부터 자동 반영된다. 서브에이전트가 실패하면 오케스트레이터가 재시도하거나 상위로 넘기며, 실패가 다른 서브에이전트의 컨텍스트를 오염시키지 않는다.
새 시나리오는 새 에이전트가 아니라 템플릿으로 추가
열 온보딩, 이벤트 온보딩, 파이프라인 마이그레이션 세 워크플로는 같은 14개 서브에이전트를 순서만 바꿔 재사용한다. 파이프라인 마이그레이션은 나중에 추가된 완전히 새로운 용도였지만, 팀은 새 에이전트 코드를 쓰지 않고 기존 에이전트를 다른 순서로 배열한 워크플로 템플릿 하나만으로 운영 능력을 갖췄다. 현재 변경 사항의 약 3분의 2는 큰 수작업 수정 없이 그대로 반영된다. Meta가 동종 업계에 주는 조언은 분명하다. 라우팅은 결정적 판단이므로 대규모 모델에게 맡기지 말고, 도메인 추론은 전부 격리된 전문 에이전트에게 내려보내라는 것이다. 이는 이 사이트가 앞서 보도한 Anthropic이 에이전트 규칙을 변호사에게 먼저 자문한 사례와 같은 방향을 가리킨다. 에이전트가 운영 환경에서 통하는지는 단일 모델이 더 똑똑해졌는지가 아니라, 경계와 규칙을 먼저 정했는지에 달려 있다.
