Engineering2026-03-29 · 9 min 읽기

에이전트 오케스트레이션이 진짜 병목이다: 모델보다 먼저 설계할 것들

에이전트 시스템의 한계는 모델 성능보다 오케스트레이션에 먼저 드러납니다. 워크플로우, 툴 권한, 폴백, 평가를 어떻게 아키텍처로 묶어야 하는지 정리합니다.

요즘 AI 얘기는 대부분 모델 이야기로 시작합니다. 하지만 실전에서는 모델보다 먼저 무너지는 지점이 있습니다. 오케스트레이션입니다.

에이전트를 붙였는데도 결과가 안정적이지 않다면, 문제는 대개 모델 지능이 아니라 아래 네 가지입니다.

즉, 에이전트 시스템은 모델 경쟁이 아니라 운영 설계 문제입니다.

1) 에이전트가 늘수록 모델보다 흐름이 중요해진다

단일 챗봇은 입력과 출력만 보면 됩니다.
하지만 에이전트는 중간 단계가 많습니다.

이 흐름이 조금만 헐거워도 품질이 흔들립니다.
모델이 좋아도, 흐름이 나쁘면 시스템은 여전히 불안정합니다.

그래서 에이전트 설계는 처음부터 순차형, 병렬형, 핸드오프형, 승인형 같은 오케스트레이션 패턴으로 봐야 합니다.

Model Context Protocol(MCP)은 툴 연결을 표준화하는 데 도움이 됩니다.
연결이 표준화되면 에이전트가 다양한 도구를 더 일관되게 다룰 수 있습니다.

하지만 여기서 흔한 착각이 있습니다.

"MCP를 붙였으니 아키텍처 문제는 끝났다"

아닙니다.

MCP는 연결 방식을 정리할 뿐이고, 다음 문제는 여전히 남습니다.

즉, MCP는 인프라의 일부이지, 운영 정책 자체는 아닙니다.

에이전트가 강해질수록 툴 권한은 더 민감해집니다.
읽기 전용 툴과 쓰기 가능 툴을 같은 층으로 다루면 사고가 납니다.

권장 방식은 간단합니다.

핵심은 툴 권한을 기능 목록으로 보지 않는 것입니다.
권한은 모델의 능력이 아니라 시스템의 정책입니다.

에이전트 시스템에서 가장 자주 놓치는 부분이 폴백입니다.

실패는 예외가 아니라 정상입니다.
그래서 미리 아래 경로를 준비해야 합니다.

폴백이 있으면 시스템은 느려질 수는 있어도 갑자기 무너지지는 않습니다.

에이전트는 테스트가 어렵습니다.
그래서 더 먼저 평가 루프를 만들어야 합니다.

최소한 아래는 있어야 합니다.

특히 "한 번 잘 됐다"는 의미가 없습니다.
에이전트는 반복 가능해야 시스템입니다.

에이전트를 도입할 때 순서는 보통 이렇습니다.

이 순서를 거꾸로 하면 대부분 데모로 끝납니다.

에이전트 시대의 핵심은 더 똑똑한 모델을 찾는 게 아닙니다.
오케스트레이션, 권한, 폴백, 평가를 먼저 설계하는 것입니다.

MCP든 다른 툴 프레임워크든, 연결은 시작일 뿐입니다.
진짜 차이는 그 위에 어떤 운영 규칙을 얹느냐에서 납니다.