프로덕션에 에이전트를 올려본 팀이라면, 월말 청구서를 보고 한 번쯤 멈칫했을 겁니다. 데모는 완벽했는데 트래픽이 붙자 비용 곡선이 기능 곡선보다 가파르게 올라갑니다. (저도 처음에는 “토큰값이 이렇게 무섭구나” 하며 단가표만 들여다봤습니다.) 원인을 추적해 보면 대부분 같은 자리에 도착합니다. 단순한 분류 하나, 형식 변환 하나, 의도 파악 하나까지 — 모든 호출을 가장 비싼 프런티어 모델로 보내고 있었던 거죠. 똑똑한 모델을 쓰면 안전할 거라는 직관. 오늘은 이 직관이 왜 틀렸는지, 그리고 비용이 어디서 진짜로 결정되는지 이야기해보겠습니다.
비용은 모델이 아니라 호출 패턴에서 샌다
에이전트는 사용자의 요청 한 번을 처리하기 위해 모델을 수십 번 호출합니다. 계획을 세우고, 도구를 고르고, 중간 결과를 요약하고, 출력 형식을 검증합니다. 이 호출들은 난이도가 천차만별인데, 많은 팀이 전부 동일한 최상위 모델로 보냅니다. 프런티어 모델은 강력합니다. 다만 그 강력함에는 단가와 지연이 함께 따라옵니다. 진짜 문제는 에이전트 워크로드의 압도적 다수가 그 강력함을 필요로 하지 않는다는 데 있습니다. (의도 분류에 175B 모델을 쓰는 건, 못 하나 박으려고 굴착기를 부르는 격입니다.)
숫자로 보면 더 선명합니다. 7B급 소형 모델을 서빙하는 비용은 70-175B급 대형 모델 대비 약 10-30배 저렴하고, GPU·클라우드·전력 비용을 최대 75%까지 줄일 수 있다는 보고가 이어집니다. 같은 기능을 유지하면서도 비용 구조 자체를 바꿀 여지가 그만큼 크다는 뜻입니다. 그런데 왜 다들 가장 비싼 경로만 고집할까요?
안전해 보이는 과잉 설비의 함정
여기엔 두 가지 오해가 겹쳐 있습니다.
첫째는 공학적 오해입니다. 도널드 커누스는 1974년 논문에서 “섣부른 최적화는 모든 악의 근원”이라는 문장을 남겼습니다. 흔히 최적화를 미루라는 뜻으로 인용되지만, 커누스가 말한 ‘premature’는 ‘너무 이른’이 아니라 ‘정보 없이’에 가깝습니다(Knuth, 1974). 핵심은 측정 없는 의사결정을 경계하라는 것이죠. 그런데 모든 호출을 최상위 모델로 보내는 설계는 정확히 같은 실수를 반대 방향으로 저지릅니다. 어떤 호출이 무거운 추론을 필요로 하는지 측정하지 않은 채 “일단 제일 센 걸로”라고 결정해 버리는, 정보 없는 과잉 설비. 최적화의 반대편에도 똑같이 섣부름이 존재합니다.
둘째는 심리적 오해입니다. 가장 강한 모델을 깔아두면 실패를 막을 수 있다는 안도감인데, 행동경제학에서 말하는 손실 회피에 가깝습니다. 드물게 발생하는 어려운 케이스의 실패가 두려워, 흔하게 발생하는 쉬운 케이스 전부에 보험료를 과하게 무는 셈이죠. 합리적인 트레이드오프가 아니라 불안의 가격입니다.
프레드 브룩스의 구분을 빌리면, 우리가 진짜 다뤄야 할 것은 본질적 복잡성(essential complexity)입니다. 어떤 작업이 정말로 어려운가를 식별하는 일이죠. 모든 걸 한 모델에 떠넘기는 건 그 식별을 회피하는, 우발적 복잡성의 전가일 뿐입니다.
이종 아키텍처와 라우팅
대안은 의외로 단순합니다. 모델을 한 종류로 통일하지 말고, 작업 난이도에 따라 계층을 나누는 것. 이를 이종(heterogeneous) 에이전트 아키텍처라고 부릅니다.
- 고빈도·단순 작업(분류, 추출, 형식 변환): 소형 언어모델(SLM) 또는 결정론적 코드
- 표준 작업(요약, 일반 대화): 중간 모델
- 복잡한 추론(계획 수립, 모호한 판단): 프런티어 모델
핵심 패턴은 라우터입니다. 들어온 요청의 난이도를 먼저 값싸게 판별하고, 쉬운 것은 SLM으로, 어려운 것만 대형 모델로 올려보냅니다. 코드로 보면 구조는 이렇게 단순합니다.
def route(task):
difficulty = classifier(task) # 값싼 사전 판별
if difficulty == "simple":
return slm.run(task) # 분류·추출·형식 변환
if difficulty == "standard":
return mid_model.run(task) # 요약·일반 대화
return frontier_model.run(task) # 계획·모호한 판단NVIDIA 연구진은 「Small Language Models are the Future of Agentic AI」에서 세 가지를 논증합니다. 소형 모델은 에이전트가 요구하는 다수의 작업에 이미 충분히 강력하고, 에이전트 시스템에 본질적으로 더 적합하며, 더 경제적이라는 것입니다(Belcak et al., NVIDIA, 2025). 또 하나 자주 쓰이는 구조는 Plan-and-Execute 패턴입니다. 비싼 모델이 전략(계획)만 세우고, 실행은 저렴한 모델이 반복 수행하는 방식이죠. 똑똑한 한 번에 값싼 여러 번. 이 분리만으로 비용을 최대 90%까지 줄였다는 사례가 보고됩니다. 실제로 한 이커머스 플랫폼은 문의의 75%를 SLM이 처리하도록 라우팅해 비용을 90% 절감하고 응답 속도는 3배 빨라졌습니다.
이 설계가 낯설게 느껴질 수 있지만, 사실 우리가 늘 해오던 일의 재현입니다. 예전에 대규모 실시간 데이터 처리 서비스를 만들 때, 모든 요청을 매번 무거운 연산 경로로 보내지 않으려고 앞단에 Redis 캐시 계층을 뒀습니다. 자주 반복되는 값은 캐시가 즉시 받아내고, 캐시가 모르는 것만 무거운 처리로 내려보냈죠. 응답 지연이 눈에 띄게 줄었습니다. 또 다른 프로젝트에서는 얼굴 인식 기반 입장 시스템을 만들면서, 들어오는 모든 프레임을 인식 서버로 보내는 대신 특징점 유사도로 먼저 값싸게 걸러 불필요한 호출 자체를 잘라냈습니다. 지금의 모델 라우팅은 이 원리를 LLM 호출에 그대로 옮긴 것뿐입니다. (새로운 건 도구이지 원리가 아닙니다.)
물론 트레이드오프가 있습니다. 라우터 자체가 새로운 복잡성이고, 분류를 틀리면 품질이 떨어집니다. 모델을 여러 개 운영하면 평가·모니터링·버전 관리 부담도 늘어납니다. MCP나 A2A 같은 프로토콜 표준화, LangGraph·CrewAI 같은 오케스트레이션 프레임워크의 성숙이 이 부담을 낮춰주고는 있지만 공짜는 아닙니다. 경량화로 얻는 비용 절감과 라우팅으로 떠안는 운영 복잡성을 같은 저울에 올려야 합니다.
결론
결국 좋은 에이전트 설계는 가장 똑똑한 모델을 고르는 일이 아니라, 어떤 작업에 어떤 모델이면 충분한지를 측정하는 일입니다. 비용은 단가표가 아니라 호출 경로의 설계에서 결정됩니다. 가장 비싼 모델을 모든 곳에 까는 것은 안전이 아니라, 측정을 회피한 대가를 매달 청구서로 치르는 일입니다. 여러분의 에이전트 로그를 한번 열어보시기 바랍니다. 그 호출들 중 정말로 프런티어 모델이 필요했던 건 몇 퍼센트였을까요? 커누스의 표현을 빌리면, 우리가 집중해야 할 곳은 언제나 그 결정적인 3%입니다.
참고 자료
- Donald E. Knuth, “Structured Programming with go to Statements,” ACM Computing Surveys, 1974
- Peter Belcak et al. (NVIDIA Research), “Small Language Models are the Future of Agentic AI,” arXiv:2506.02153, 2025
- Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” 1986 (『맨먼스 미신』 수록)
- “Small Language Models 2026: Cut AI Costs with Enterprise SLM Deployment,” Iterathon, 2026
- “7 Agentic AI Trends to Watch in 2026,” MachineLearningMastery, 2026
무료로 시작하기 
