서론 (Intro)

한 데모에서 "모든 것을 수행하는" 하나의 에이전트는 하나의 프롬프트(Prompt), 하나의 API 호출, 하나의 멘탈 모델(Mental Model)로 구성되어 매우 경제적으로 보입니다. 아무도 이를 매일 수천 개의 엣지 케이스(Edge Case)로 테스트하지 않으며, 단 두 줄의 질문에 답하기 위해 40개의 무관한 지침을 파싱하며 소모되는 토큰(Token) 비용을 지불하지도 않습니다. 하지만 실제 운영 환경(Production)에서 동일한 설계는 팀이 처음으로 겪게 될 실제 장애의 원인이 됩니다. 아래는 모놀리식 에이전트(Monolithic Agent)가 실제 트래픽을 마주했을 때 나타나는 네 가지 실패 모드(Failure Modes)입니다. (특정 고객의 사례 연구가 아닌 예시를 위한 합성된 내용입니다.)

아무도 안전하게 수정할 수 없는 시스템 프롬프트 (The system prompt that nobody can safely edit)

"제품 질문에 답변하기"로 시작했다가, 기능 요청이 추가될 때마다 결제, 환불, 기술적 문제 해결, 그리고 세 가지 서로 다른 고객 세그먼트를 위한 톤 가이드라인을 포함하는 4,000단어 분량의 시스템 프롬프트(System Prompt)로 성장한 고객 지원 에이전트를 상상해 보십시오. 41번째 엣지 케이스(Edge Case)를 위한 새로운 지침을 추가하면, 모델이 12번째 엣지 케이스를 처리하는 방식이 조용히 변하게 됩니다. 왜냐하면 두 케이스 모두 동일한 호출 내에서 동일한 어텐션 예산(Attention Budget)을 두고 경쟁하기 때문입니다. 관심사 간의 격리(Isolation) 없이 오직 근접성(Proximity)만 존재하기 때문에, 어느 줄이 성능 저하(Regression)를 일으켰는지 지목할 수 있는 사람은 아무도 없습니다.

모든 요청이 사용하지 않는 기능에 대한 비용을 지불함 (Every request pays for capabilities it doesn't use)

모든 것을 수행하는 단일 에이전트는 단순히 데이터베이스 조회(Database Lookup)만 필요한 요청에 대해서도, 환불 정책 예외 사항에 대한 신중한 추론(Reasoning)이 필요한 요청과 동일한 토큰(Token) 비용을 청구합니다. 예를 들어, 한 팀의 가장 단순하고 볼륨이 큰 의도인 "내 주문 상태가 뭐야?"라는 요청이 어쨌든 전체 모놀리식 프롬프트(Monolithic Prompt)를 거쳐 처리된다고 가정해 봅시다. 이는 단 5줄의 함수로 아주 적은 비용에 처리할 수 있는 작업에 대해, 매 호출마다 프리미엄 추론(Reasoning) 비용을 지불하는 셈입니다.

하나의 잘못된 지침이 하류의 모든 것을 저하시킴 (One bad instruction degrades everything downstream)

단일 구조의 에이전트(monolithic agent)는 라우팅 (routing), 작업 실행 (task execution), 그리고 포맷팅 (formatting)을 단 한 번의 추론 패스 (inference pass)로 처리하기 때문에, 행동의 한 부분에서 미묘한 드리프트 (drift)가 발생하면 이를 가둘 경계가 없습니다. 예를 들어, 관련 없는 프롬프트 수정 이후 환불 질문에 대해 더 많이 확답을 피하기 시작한다면, 이를 제어할 수 있는 경계가 없습니다. 오작동하는 '컴포넌트 (component)' 자체가 에이전트 전체이기 때문에, 사용자에게 도달하기 전에 이를 잡아낼 수 있는 이음새가 존재하지 않습니다.

테스트는 엔지니어링이 아닌 확률 게임이 됩니다

단일 목적의 함수 (single-purpose function)를 사용할 때는 테스트를 작성하고, 입력을 알고, 출력을 검증 (assert)합니다. 하지만 4,000단어에 달하는 모든 것을 수행하는 프롬프트의 경우, "테스트"란 종종 동일한 대화를 수십 번 실행하며 실패율이 허용 가능한 임계값 (threshold) 아래로 유지되기를 바라는 것을 의미합니다. 그것은 테스트 스위트 (test suite)가 아닙니다. 그것은 일기 예보입니다.

다목적 에이전트는 단 하나의 결정이 아닙니다. LLM이 추론 시점에 내리는 20개의 결정이며, 그중 어느 것도 감시하는 존재가 없습니다.

이러한 모든 실패 모드 (failure modes)는 동일한 근본 원인에서 비롯됩니다. 바로 라우팅 (routing), 작업 실행 (task execution), 그리고 상태 관리 (state management)를 하나의 비결정론적 (non-deterministic) 호출로 통합하고, 모델이 매번, 영원히, 일관되게 이를 해결해 주기를 바라는 것입니다. 모델이 나빠서가 아니라, 단일 추론 패스 (inference pass)라는 것이 애초에 그러한 것을 보장하도록 설계되지 않았기 때문에 그렇게 되지 않을 것입니다.

통합하지 말고 라우팅하세요

해결책은 더 똑똑한 프롬프트가 아닙니다. 언어 모델의 판단으로부터 진정으로 이득을 얻는 것과 그렇지 않은 것을 분리하는 것입니다. 작은 분류기 (classifier)가 의도 (intent)를 결정합니다. 특화된 단일 목적 함수들이 각각 격리된 작업을 처리하며, 이 중 여러 개는 LLM이 전혀 필요하지 않을 수도 있습니다. 결정론적 코드 (deterministic code)가 라우팅 (routing), 상태 (state), 그리고 최종 포맷팅 (formatting)을 담당합니다. 이 부분들은 창의성이 아니라 실제로 예측 가능성 (predictability)을 원하는 영역입니다. 각 조각은 자체적으로 유닛 테스트 (unit test)를 수행할 수 있을 만큼 충분히 작으며, 이것이 바로 단일 구조 (monolith)가 결코 제공할 수 없었던 속성입니다.

당신에게 그 경계는 어디입니까? "프롬프트에 지침을 하나 더 추가하자"는 생각이 실용적인 선택을 넘어, 새벽 2시에 디버깅을 하고 있을 문제로 변하는 시점은 언제입니까?