모델 내장 멀티에이전트 오케스트레이션의 통제점 설계

샘 올트먼이 2026년 7월 말 워싱턴 D.C.에서 상원의원과 재무·상무 당국자에게 시연한 차세대 모델 Astra의 핵심은 성능 수치보다 구조에 있었다. 다수의 에이전트가 장기간 협업해 난제와 고급 수학 문제를 다루는 기능이 모델 패밀리 자체의 기능으로 제시됐다. 애플리케이션 계층에서 프레임워크와 프롬프트로 구현하던 작업 분해와 인계가 모델 내부로 옮겨가는 변화다.

명칭은 잠정적이다. GPT-6, GPT-5.7, Sol·Terra·Luna와 병렬한 별도 계열 가운데 어떤 이름으로 출시될지는 정해지지 않았다. 다만 조직이 다뤄야 할 문제는 명확하다. 오케스트레이션 구현을 벤더에 맡길수록 하네스 유지보수 부담은 줄지만, 의사결정의 근거와 개입 지점도 벤더 구현 뒤로 이동한다.

모델에 넘기는 범위가 통제 수준을 정한다

목표만 전달해 전체 과정을 맡길지, 단계 목록을 제공한 뒤 실행만 위임할지는 업무마다 달라야 한다. 위임 수위가 높아질수록 조직이 확인할 수 있는 실행 과정의 범위는 줄어든다.

먼저 모델 내부 판단에 남기지 않을 결정을 정한다. 외부 시스템 쓰기, 비용이 발생하는 호출, 사용자 대면 산출물의 확정은 통제 비용이 낮은 애플리케이션 계층에 두는 편이 낫다. 프롬프트로 행동을 제한하는 것만으로는 충분하지 않다. 허용하지 않을 도구를 노출하지 않아야 실행 자체를 막을 수 있다.

벤더 내장 오케스트레이션은 분해와 역할 배정, 인계 로직을 직접 구현하지 않아도 된다는 장점이 있다. 모델 내부 상태를 활용하는 인계 효율과 프레임워크 버전 추종 비용의 감소도 기대할 수 있다. 반면 어느 역할이 어떤 근거로 결정을 내렸는지, 단계별 비용이 어디에 발생했는지, 특정 단계만 교체하거나 중단할 수 있는지는 벤더가 노출하는 인터페이스에 좌우된다.

⤢✕

최종 답변만 남겨서는 실패를 설명할 수 없다

역할 식별자와 단계 구분자는 벤더가 제공하는 형태 그대로 로그에 보존해야 한다. 최종 응답만 저장하면 실패를 재현할 근거가 사라진다. API 명세에서 역할별 산출물을 별도 필드로 받을 수 있는지도 확인할 필요가 있다. 단일 텍스트로만 반환된다면 귀속 분석에 사용할 입력 자체가 없다.

에이전트 사이에 오간 중간 결과에는 식별자를 붙여 기록한다. 오류는 인계 과정의 정보 손실에서 발생하는 경우가 많으며, 인계 지점을 볼 수 없으면 원인 분석은 추측에 머문다. 이 데이터에는 개인정보나 비밀 정보가 담길 수 있으므로 저장 전 마스킹 규칙도 함께 마련해야 한다.

계획서, 부분 결과, 수정 이력은 최종 응답과 분리해 저장한다. 장시간 실행에서는 중간 산출물이 재개와 검증의 유일한 근거가 된다. 동시에 보존 기간과 용량 상한을 사전에 정해야 한다. 중간 산출물은 최종 결과보다 훨씬 빠르게 누적된다.

도구 호출 시각, 입력 요약, 결과 코드, 재시도 횟수는 표준 스키마로 모은다. 벤더가 형식을 바꾸더라도 매핑 계층만 수정할 수 있도록 자체 스키마를 두는 방식이다. 이 기록은 요청 단위가 아니라 과제 단위로 묶어야 한다. 수 시간짜리 실행에서는 요청 단위 로그만으로 전체 과정을 복원하기 어렵다.

비용도 과제와 역할 단위로 나눠 집계한다. 모델 내부에서 몇 개의 에이전트가 몇 회 호출됐는지 보이지 않으면 청구액을 업무별로 배분할 수 없다. 과제별 예산 상한과 초과 시 중단 경로도 필요하다. 내부 오케스트레이션은 사용자가 예상하지 못한 반복을 만들 수 있다.

승인과 취소를 모델 바깥에 남긴다

승인이 필요한 행동 앞에는 정지점을 둔다. 정지점 없는 자율 실행은 되돌릴 수 없는 부작용을 만든 뒤에야 발견될 수 있다. 비동기 실행에서는 취소 요청이 실제로 실행을 멈추는지 검증해야 한다. 취소 신호가 무시되는 사례가 흔하기 때문이다.

통제점은 위임한 계층이 아니라 위임하지 않은 계층에만 배치할 수 있다. 그래서 도구 노출 범위가 실질적인 통제 수단이 된다. 프롬프트로 금지한 행동보다, 애초에 접근할 수 없는 도구가 더 강한 경계가 된다.

채택 전 병행 운영에서 확인할 항목

실패 비용이 낮고 결과 검증이 쉬운 업무부터 내장 오케스트레이션을 적용한다. 조사, 요약, 초안 작성은 사람이 결과를 바로 판정할 수 있어 불투명성의 부담이 작다. 반대로 규제 대상 판단이나 외부 계약에 영향을 주는 업무에서는 위임 범위를 좁게 유지한다.

기존 자체 하네스를 즉시 폐기하지 말고, 동일 과제를 양쪽에서 실행하는 기간을 둔다. 비교 근거 없이 전환하면 품질 변화를 사후에도 설명하기 어렵다. 병행 유지 비용의 상한과 종료 조건도 처음부터 정해야 한다. 조건이 없으면 병행 운영은 무기한 부채가 된다.

계약 검토에서는 역할 구분자 제공 여부, 트레이스 보존 기간, 비용 분해 수준을 확인한다. 발표 자료가 아니라 API 명세와 약관을 기준으로 봐야 한다. 관측 기능이 없으면 채택하지 않는 기준을 명문화할 필요가 있다. 채택 뒤에 요구하면 협상력이 없다.

실패는 인계 손실, 계획 오류, 도구 실행 실패, 종료 조건 미달로 분류하는 체계를 먼저 둔다. 이런 분류가 없으면 모든 실패가 “모델이 못 함”으로 수렴한다. 비결정적 실행에서는 동일 입력을 다시 실행하는 절차를 문서화해야 하며, 재실행은 검증의 최소 단위가 된다.

프롬프트, 도구 정의, 평가셋은 벤더 중립 형식으로 보관한다. 오케스트레이션 자체를 옮기기 어렵더라도 이 자산은 이관할 수 있다. 자체 하네스로 되돌아가는 경로의 소요 기간도 산정해야 한다. 그 산정치가 곧 벤더 종속 위험의 크기다.

위임 범위와 관측 수준은 분기 단위로 재검토한다. 벤더 기능이 빠르게 바뀌므로 초기 판단은 곧 낡는다. 오케스트레이션 위임 결정과 근거는 아키텍처 결정 기록으로 남겨야 다음 세대 교체 때 같은 논쟁을 반복하지 않는다.

내장 방식과 자체 하네스가 갈리는 지점

구분	모델 내장 오케스트레이션	자체 하네스 구축
초기 개발 부담	낮음	높음
내부 동작 가시성	벤더 제공 수준에 종속	전면 통제
비용 귀속 정밀도	낮음	단계별 산정 가능
개입 지점 배치	제한적	자유
벤더 종속	강함	약함
개선 속도	벤더 릴리스에 연동	자체 일정

내장 방식은 분해와 인계 로직을 직접 구현하지 않아 착수가 빠르고 모델 개선을 바로 반영할 수 있다. 대신 장애가 발생했을 때 어느 단계에서 무엇이 잘못됐는지는 벤더가 제공하는 정보만으로 파악해야 한다. 자체 하네스는 단계별 로그와 중단점을 둘 수 있어 원인 규명과 비용 배분에 유리하지만, 프레임워크 유지, 재시도 정책, 상태 저장을 조직이 직접 맡는다. 탐색적 업무는 내장 방식에 맡기고 감사 대상 업무는 자체 하네스에 남기는 구성이 개발 부담과 통제 비용의 균형점이 될 수 있다.

벤더가 제공하는 에이전트 팀은 모델 내부 상태를 공유하므로 인계 손실이 적고 역할 설계의 시행착오를 줄일 수 있다. 그러나 조직의 업무 구조에 맞게 역할 정의를 바꾸기 어렵고, 잘못된 분해를 교정할 수단도 제한적이다. 직접 역할을 구성하면 도메인 지식을 역할 정의에 반영하고 특정 역할만 다른 모델로 교체할 수 있다. 대신 분해 품질은 설계자의 역량에 좌우되며 인계 형식을 직접 규격화해야 한다. 도메인 특수성이 강한 업무일수록 직접 구성의 이득이 커지고, 범용 조사와 정리 업무에서는 벤더 구성이 앞선다.

단일 모델을 여러 번 호출하는 방식은 구현이 단순하고 각 호출을 독립적으로 검증하거나 재시도할 수 있으며 비용 예측도 쉽다. 멀티에이전트 팀은 역할 분업으로 복합 과제의 정확도를 높일 수 있지만 호출 수가 비선형으로 늘어 비용이 증가하고, 에이전트 간 의견 충돌을 조정해야 하는 새로운 실패 모드가 생긴다. 과제가 단일 문맥에 담기고 단계 의존이 얕다면 다중 호출이 적합하다. 병렬 조사와 상호 검증이 실제로 필요한 과제에서만 팀 구성의 추가 비용을 회수할 수 있다.

아키텍처와 거버넌스에서 남는 과제

오케스트레이션 위치를 정하는 일은 계층 배치 문제다. 애플리케이션 계층의 관심사가 플랫폼 계층으로 이동하면 결합도는 낮아질 수 있지만, 관측 인터페이스는 계약의 일부가 되어야 한다.

벤더 평가는 기능 제공 여부를 넘어 관측과 감사 정보의 제공 수준까지 포함해야 한다. 기능은 대체할 수 있어도 감사 자료의 부재는 사후에 보완하기 어렵다. 종속성 완화 방안도 문서상의 대안만으로는 충분하지 않다. 이관에 수개월이 걸린다면 실질적인 대안이 아니다.

사람의 개입 지점은 프로세스 정의에 명시해야 한다. 자율 실행 비율이 높아질수록 승인 지점의 위치가 내부통제의 골격이 된다. 실패 분류 체계 역시 개선 활동의 전제다. 귀속되지 않는 실패는 반복되고, 개선의 우선순위도 정할 수 없다.

오케스트레이션이 플랫폼 기능이 된 뒤

오케스트레이션이 모델 기능으로 편입되는 흐름이 이어지면 에이전트 프레임워크의 역할은 실행 조율에서 관측·통제 계층으로 이동한다. 기업 채택에서는 벤더가 제공하는 실행 트레이스와 역할 단위 비용 분해가 선결 조건으로 요구되는 방향이다.

정부 검토 절차를 거친 뒤 공개되는 모델이 늘면 출시 일정의 예측 가능성은 낮아지고, 병행 운영 기간을 설계하는 일은 상시 과제가 된다. 위임 범위를 도구 노출로 강제하는 설계도 프롬프트 기반 제약을 대체하는 표준 패턴으로 정착할 가능성이 있다.

Astra 시연이 드러낸 변화는 특정 모델의 성능보다 오케스트레이션의 위치가 바뀐다는 점이다. 작업 분해와 인계가 모델 내부로 들어가면 개발 부담은 줄지만 실패 원인과 비용 귀속의 근거도 함께 사라질 수 있다. 채택의 조건은 성능만이 아니라 벤더가 제공하는 트레이스와 계측의 수준이어야 하며, 승인과 중단 지점은 애플리케이션 계층에 남겨야 한다.