당신의 AI 에이전트가 실패하는 이유: 아무도 해결하지 못하고 있는 라우팅 문제

AI 공개 사항: 이 포스트는 AI의 도움을 받아 작성되었으며, Linksoft Technologies 팀의 검토 및 출판 승인을 받았습니다.

모두가 AI 에이전트(AI agents)를 배포하기 위해 경주하고 있습니다. 속도는 진보라는 환상을 만들어내지만, 그것이 우위를 보장하지는 않습니다. 진짜 비용은 나중에 나타납니다 — 시스템이 부하(load) 상황에서 어떻게 작동하는가 하는 점입니다.

이 세 가지 숫자를 함께 읽어보십시오. 거의 모든 기업이 AI를 실행하고 있습니다. 대부분은 비용 효율성(cost efficiency)이 최우선 과제라고 말합니다. 그리고 그 문제를 실제로 해결할 수 있는 AI 에이전트 아키텍처(AI agent architecture) 계층을 구축한 기업은 거의 없습니다. 이것이 바로 현시점의 결정적인 인프라 격차입니다.

대부분의 전략 문서(strategy decks)에서의 논의는 여전히 잘못된 곳에 머물러 있습니다: 어떤 모델을 선택할 것인가, 어떤 벤더(vendor)를 신뢰할 것인가, 직접 구축할 것인가 아니면 구매할 것인가. 표면적인 수준입니다. 증상만을 쫓고 있습니다. 그 아래에 깔린 구조적인 문제를 완전히 놓치고 있습니다.

실제 규모로 AI를 운영하는 기업들은 더 나은 모델을 실행하는 것이 아닙니다. 그들은 모델 주변에 더 나은 시스템을 실행하고 있습니다. 그것이 대부분의 팀이 여전히 놓치고 있는 차이점이며, 대개 나중에 예산 문제로 나타납니다.

당신에게 비용을 발생시키는 본능

조직이 AI에 진지해질 때, 본능적인 반응은 타당해 보입니다. 사용 가능한 가장 유능한 모델을 사용하는 것입니다. 그것이 추론을 가장 잘하고, 모호함을 가장 잘 처리하며, 글을 가장 잘 쓰기 때문입니다. 그래서 당신은 GPT-4나 Claude Opus, 혹은 벤치마크 표의 최상단에 있는 무엇인가를 기반으로 첫 번째 에이전트를 구축하고, 그것은 작동합니다. 심지어 인상적으로도 작동합니다.

그다음 당신은 그것을 확장(scale)하려고 시도합니다. 바로 그 지점에서 수학적 계산이 불편해집니다.

대규모 프런티어 모델(frontier models)은 복잡성을 위해 구축되었습니다. 하지만 실제 AI 파이프라인(pipeline)의 대부분의 작업은 복잡하지 않습니다. 그것들은 반복적이고, 좁으며, 구조적으로 단순합니다. 모든 것을 수천억 개의 파라미터(parameter)를 가진 모델을 통해 라우팅(route)할 때, 당신은 필요하지 않은 능력, 원치 않는 지연 시간(latency), 그리고 볼륨에 따라 선형적으로 증가하는 토큰 수(token counts)에 대한 비용을 지불하게 됩니다.

Google Research의 Switch Transformers에 관한 연구는 동일한 연산량(compute)으로 사전 학습(pre-training) 효율성을 최대 7배까지 높일 수 있음을 기록했으며, 이는 이러한 이점들이 이론적인 것에 그치지 않음을 증명합니다. 문제는 당신의 오케스트레이션 계층(orchestration layer)이 이러한 이점을 포착할 수 있도록 구축되었느냐 하는 것입니다.

Sequoia Capital의 분석에 따르면, 인프라 투자가 실현된 수익을 극적으로 초과하는 5,000억 달러 규모의 연간 수익 격차가 존재합니다. 모델 라우팅(model routing)을 잘못 설정하는 것은 단순한 효율성의 문제가 아닙니다. 규모가 커지면 이는 마진(margin)의 문제로 변합니다.

아키텍처가 문제입니다

기본적인 접근 방식은 평면적인 파이프라인(flat pipeline)을 생성합니다: 하나의 입력, 하나의 거대 모델, 하나의 출력, 그리고 반복. 라우팅도 없고, 복잡도에 대한 인식도 없습니다. 모든 작업은 무엇을 필요로 하는지와 상관없이 동일하게 취급됩니다.

개념 증명(proof of concept) 단계에서는 이것이 잘 작동합니다. 하지만 규모가 커지면 비용 문제는 더 이상 추상적이지 않게 되며, 그때가 되면 아키텍처는 이미 너무 깊게 자리 잡아서 쉽게 변경할 수 없게 됩니다.

파일럿 단계는 괜찮아 보입니다. 실제 운영(production) 단계에서 문제가 발생하기 시작하며, 이것이 대부분의 확장(scaling) 팀이 빠지는 함정입니다.

AI에서 모델 라우팅(Model Routing)이란 무엇이며 왜 중요한가?

모델 라우팅은 어떤 AI 모델이 어떤 작업을 처리할지 결정하는 오케스트레이션 계층(orchestration layer)입니다. 복잡하고 모호한 요청은 거대 프런티어 모델(frontier models)로 보내고, 단순하고 반복적인 요청은 더 작고 빠르며 저렴한 모델로 보냅니다.

라우팅이 없다면, 모든 작업은 실제로 무엇을 필요로 하는지와 관계없이 동일한 모델로 라우팅됩니다. 당신은 훨씬 적은 비용으로도 동일하게 처리할 수 있는 작업에 대해 프런티어 모델의 가격을 지불하게 됩니다.

규모가 커지면 이는 단순한 효율성의 격차가 아니라 마진(margin)의 문제입니다. 모델 라우팅 (Model routing)은 병원이 모든 환자를 수석 전문의에게 보내는 대신 환자의 복잡도에 맞춰 적절한 의료 단계로 배정하는 것과 마찬가지로, 연산량 (compute)을 복잡도에 맞춤으로써 이 격차를 해소하는 역할을 합니다.

실제 해결책은 어떤 모습인가

병원의 트리아지 (triage, 환자 분류) 시스템을 생각해 보세요. 경미한 부상을 입은 모든 환자를 가장 숙련된 전문의에게 보내지는 않습니다. 전문의의 시간을 그들의 전문 지식이 진정으로 대체 불가능한 사례를 위해 남겨두면서, 사람들을 적절한 수준의 치료 단계에 맞추는 시스템을 갖추고 있습니다.

대형 모델의 연산량 (compute)은 전문의의 시간과 같습니다. 오케스트레이션 계층 (orchestration layer)은 트리아지 시스템입니다. 이것이 없다면 대규모 운영 시 대기열, 낭비, 그리고 감당할 수 없는 비용이 발생하게 됩니다.

"핵심은 단순히 가장 저렴한 옵션을 선택하는 것이 아니라, 워크로드 패턴 (workload patterns)에 부합하는 도구와 서비스의 적절한 조합을 찾는 것입니다."
-- Google Cloud

기업을 위한 효율적인 AI 에이전트 아키텍처 설계 방법

효율적인 기업용 AI 에이전트 아키텍처는 다음과 같이 계층별로 구축됩니다:

Tier 1 경량 모델 (Lightweight model): 좁은 범위의, 대량의, 구조적으로 단순한 작업을 처리합니다.
Tier 2 중간 단계 모델 (Mid-tier model): 중간 정도의 추론 및 혼합된 복잡도의 요청을 처리합니다.
Tier 3 프런티어 모델 (Frontier model): 진정으로 복잡하거나 중대한 사례를 위해서만 예약됩니다.

각 계층에는 정의된 비용, 지연 시간 (latency), 품질 임계값이 있습니다. 이 위에는 어떤 작업이 어디로 가는지, 비용은 얼마인지, 결과는 어떠한지를 추적하는 **관측성 계층 (observability layer)**이 자리 잡고 있어, 라우팅 결정이 한 번 설정되고 잊히는 것이 아니라 지속적으로 조정될 수 있도록 합니다.

대규모 환경에서 AI 에이전트 오케스트레이션 비용을 절감하는 조직은 더 나은 모델을 사용하는 것이 아닙니다. 그들은 모든 단계에서 지출을 필요에 맞추는 아키텍처를 통해, 모델을 중심으로 더 나은 시스템을 운영하고 있는 것입니다.

대부분의 팀이 아직 이것을 구축하지 못한 이유

실력 부족과는 전혀 관계없는 두 가지 이유가 있습니다.

이유 1: 초기 고통(pain)이 눈에 보이지 않습니다.
PoC(Proof of Concept)를 실행할 때는 대규모 모델과 소규모 모델 간의 비용 차이가 추상적으로 느껴집니다. 이 비용 영향이 부인할 수 없고 시스템이 이미 너무 깊숙이 내장되어 있어 쉽게 변경할 수 없는 규모(scale)에 도달했을 때만 명확해집니다.

이유 2: 계층화된 오케스트레이션(Tiered orchestration)을 구축하는 것이 근본적으로 더 어렵습니다.
단순한 작업에 단일 모델을 지정하는 것은 쉽습니다. 하지만 작업을 정확하게 분류하고, 라우팅하며, 엣지 케이스(edge cases)를 처리하고, 여러 모델 전반에 걸쳐 일관성을 유지하는 오케스트레이션 레이어는 심각한 시스템 문제입니다. 제대로 구축하려면 6개월에서 18개월이 걸리는 종류입니다.

에이전트의 현실 점검(Agent Reality Check)

직설적으로 말하자면, 과대광고 주기(hype cycle)가 배포 현실을 상당히 앞질렀습니다. 조직들이 구축하여 '에이전트'라고 부르는 것들 대부분은 자세히 살펴보면 도구 접근 기능만 붙인 정교한 챗봇일 뿐입니다. 이들은 세 가지 특정하고 예측 가능한 방식으로 실패하며, 이 세 가지 모두 모델 품질 문제가 아니라 아키텍처 문제입니다.

바로 이것이 지금 시점이 방향을 전환하기에 적절한 이유입니다. Kubernetes, LangGraph, 격리된 실행 환경(sandboxed execution environments), 그리고 적절한 관측 가능성 도구(observability tooling)를 포함하는 인프라는 이미 존재하며 성숙해지고 있습니다. 지금 구축을 시작하는 기업들은 2년 후에 긴급 재아키텍처를 해야 하는 뒤처진 플레이어가 아니라, 초기~중기 선도 주자가 될 것입니다.

NVIDIA는 에이전틱 시스템 (agentic systems)을 "복잡하고 다단계인 워크플로 (workflows) 전반에서 추론, 계획 및 행동하는 자율적이고 장기 실행되는 에이전트"로 정의합니다. 이 정의는 현재 대부분의 구현 방식이 여전히 얼마나 더 나아가야 하는지를 강조합니다. 이는 후퇴해야 할 이유가 아니라, 이를 실제 시스템 문제 (systems problem)로 취급해야 한다는 신호입니다.

실제로 추적해야 하는 것

올바른 지표를 추적하려면 단순히 벤치마크 점수가 아니라, 라우팅 (routing) 결정과 비즈니스 결과 (business outcomes)를 연결하는 AI 감독 프레임워크 (AI oversight framework)가 필요합니다.

대부분의 AI 비즈니스 사례는 모델 성능 벤치마크를 기준으로 승인되지만, 이는 최적화해야 할 잘못된 수치입니다. 컨테이너 오케스트레이션 (container orchestration), 워크플로 상태 관리 (workflow state management), 샌드박스 실행 (sandboxed execution), 관측성 도구 (observability tooling), 그리고 라우팅 모델 유지보수 (routing model maintenance)를 포함한 실제 비용은 동일한 보고서에 포함되는 경우가 거의 없습니다. 따라서 ROI (투자 대비 수익) 격차가 발생하는 것은 놀라운 일이 아닙니다. 애초에 실제 비용이 완전히 계산되지 않았던 것입니다.

McKinsey는 생성형 AI (generative AI)가 글로벌 경제에 연간 2.6조 달러에서 4.4조 달러를 추가할 수 있으며, 총 생산성 영향은 7.9조 달러에 달할 것으로 추정합니다. 시스템 설계 (system design)를 잘못했을 때 발생하는 비용은 기회와 별개로 발생하는 것이 아니라, 그 기회와 함께 규모가 커질 것입니다.