에이전트 프로젝트의 비용 청구서가 예상보다 훨씬 클 때, 대부분의 팀은 모델 자체를 의심한다. 더 저렴한 모델로 바꾸거나, API 호출 횟수를 줄이는 방향을 먼저 찾는다. 그런데 실제 원인은 모델 선택이 아니라 설계 결정에 있는 경우가 많다. 어떤 판단에 어떤 모델을 붙였느냐의 문제다.
에이전트가 작동하는 과정을 들여다보면, 최종 결과물을 만들어내는 추론보다 그 전에 이뤄지는 잔잔한 분기 판단이 훨씬 많다. 다음 도구를 선택하거나, 입력값의 유효성을 확인하거나, 요청을 어느 서비스로 보낼지 결정하는 일들이다. 이 판단들은 복잡한 추론이 필요하지 않다. 그런데 많은 팀이 이 분기 하나하나에도 프론티어 LLM을 호출한다. 결과적으로 비용과 응답 시간은 불필요하게 늘어나고, 정작 복잡한 판단이 필요한 지점에서는 예산이 부족해진다.
에이전트 내부의 판단은 같은 종류가 아니다
요구사항을 설계하는 단계에서 팀이 먼저 해야 할 일은 에이전트가 수행하는 판단 목록을 쓰고, 각 판단의 성격을 구분하는 것이다. 크게 두 종류로 나뉜다.
첫 번째는 분기형 판단이다. 입력이 유효한가, 이 요청은 A 경로인가 B 경로인가, 조건이 충족됐는가처럼 선택지가 좁고 맥락 해석보다 판별이 중요한 경우다. 정답의 범위가 명확하고, 실수의 영향도 대개 한 단계 안에서 교정할 수 있다.
두 번째는 추론형 판단이다. 사용자의 의도를 파악하거나, 여러 정보를 종합해 계획을 세우거나, 예외 상황에 대응하는 경우다. 선택지가 열려 있고, 맥락을 폭넓게 읽어야 하며, 판단 오류가 미치는 영향이 크다.
이 구분이 중요한 이유는, 두 판단에 필요한 모델의 조건이 전혀 다르기 때문이다. 분기형 판단에는 빠른 응답과 낮은 비용이 지배적인 기준이다. 추론형 판단에는 깊은 이해와 유연한 대응이 우선이다. 같은 모델로 두 가지를 처리하면 어느 쪽도 최적이 되지 않는다.
경량 모델이 적합한 조건
경량 모델은 파라미터 수가 적고 응답이 빠르며 호출 비용이 낮다. 프론티어 LLM 대비 응답 속도와 비용에서 유리하지만, 긴 문맥을 처리하거나 복잡한 추론을 이어가는 데는 한계가 있다.
경량 모델을 우선 고려할 수 있는 상황은 다음과 같다.
- 판단의 선택지가 미리 정의되어 있고, 그 범위가 변하지 않는다.
- 같은 유형의 판단이 에이전트 실행 중 반복적으로 발생한다.
- 판단 결과가 다음 단계의 입력으로 바로 연결되어 응답 지연이 전체 성능에 직접 영향을 준다.
- 오판이 발생하더라도 다음 단계에서 감지하거나 수정할 수 있는 구조다.
반대로, 판단의 경계가 모호하거나 사용자 표현이 불규칙하게 바뀌는 경우에는 경량 모델의 정확도가 빠르게 낮아질 수 있다. 특히 자연어로 들어오는 분류 작업을 경량 모델에 넘길 때는 학습 데이터의 범위와 오분류율을 먼저 검토해야 한다.
프론티어 LLM이 남아야 할 자리
프론티어 LLM의 강점은 긴 맥락 이해, 처음 보는 상황에 대한 대응, 복잡한 조건을 동시에 고려한 추론이다. 비용과 응답 시간이 높은 만큼, 이 특성이 결과의 질을 실질적으로 좌우하는 판단에만 배치하는 것이 합리적이다.
프론티어 LLM을 유지해야 할 상황은 다음과 같다.
- 사용자의 의도가 문자 그대로가 아닌 맥락에서 파악되어야 한다.
- 여러 조건이 얽혀 있고, 판단 오류가 전체 워크플로에 영향을 미친다.
- 출력이 사용자에게 직접 전달되거나, 이후 단계에서 교정이 어렵다.
- 예외 케이스의 비율이 높아, 사전에 규칙으로 커버하기 어렵다.
이 조건들은 설계 단계에서 미리 명시할 수 있다. 요구사항 문서에 각 판단 노드마다 "이 판단의 입력 범위는 어디까지인가", "오판의 영향 범위는 어디까지인가", "이 판단은 반복되는가, 아니면 케이스마다 다른가"를 적어두면, 모델 배치 결정이 감에서 기준으로 바뀐다.
확신도를 라우팅 신호로 쓰는 방법
모델 라우팅을 설계할 때 유용한 개념이 하나 있다. 모델이 자신의 판단에 얼마나 확신하는지를 수치로 표현하는 **확신도(confidence)**를 경로 전환 조건으로 사용하는 방식이다.
아이디어는 단순하다. 경량 모델이 높은 확신도로 답한 판단은 그대로 처리하고, 확신도가 임계값 아래로 떨어지면 프론티어 LLM이나 사람에게 넘긴다. 이렇게 하면 쉬운 판단은 빠르고 싸게 처리하면서, 실제로 어려운 케이스만 비싼 모델이 다룬다.
단, 이 방식이 제대로 작동하려면 확신도 수치 자체가 신뢰할 수 있어야 한다. 많은 LLM은 확신도를 물으면 실제 정확도와 무관하게 높은 값을 돌려주는 경향이 있다. 확신도를 라우팅 조건으로 쓰려면, 해당 모델의 확신도가 실제 정확도와 통계적으로 얼마나 일치하는지를 먼저 검증해야 한다. 이 검증 없이 임계값을 설정하면, 오히려 잘못된 판단이 높은 확신도로 자동 처리되는 상황이 생긴다.
임계값 자체는 프로젝트의 리스크 허용 수준에 따라 다르게 설정한다. 판단 오류의 비용이 클수록 임계값을 높이고, 처리량과 속도가 더 중요한 상황에서는 낮출 수 있다. 이 값은 초기에 정한 뒤 고정하는 것이 아니라, 운영 중 실제 오류율을 보면서 조정해야 한다.
요구사항 단계에서 설계팀이 먼저 결정할 것
모델 라우팅 설계는 구현 단계보다 요구사항 단계에서 시작하는 것이 낫다. 나중에 모델을 바꾸는 것보다 처음부터 판단 유형별로 역할을 나눠두는 것이 수정 비용이 적다.
요구사항 단계에서 명확히 해두어야 할 항목은 다음과 같다.
판단 목록과 유형 분류. 에이전트가 수행하는 모든 판단을 나열하고, 분기형인지 추론형인지를 팀이 합의한 기준으로 구분한다. 이 단계에서 의견이 나뉘는 판단이 있다면, 그 판단은 설계 리스크가 높다는 신호다.
오류 허용 범위. 각 판단이 틀렸을 때 영향이 어디까지 미치는지를 정의한다. 자동 교정이 가능한 단계인지, 사용자에게 직접 전달되는지, 이후 단계를 오염시키는지를 구분하면 모델 선택의 우선순위가 달라진다.
입력 가변성. 같은 판단이라도 입력이 얼마나 다양하게 들어오느냐에 따라 경량 모델의 적합성이 달라진다. 구조화된 입력이 보장되는 판단과 자연어로 들어오는 판단은 같은 모델로 처리하기 어렵다.
운영 중 측정 계획. 판단 정확도, 확신도 분포, 프론티어 LLM으로 전환되는 비율을 배포 후에도 추적할 수 있도록 로깅 구조를 요구사항에 포함한다. 이 데이터가 없으면 나중에 임계값을 조정할 근거가 없다.
이 설계가 맞지 않는 상황
모델 라우팅이 항상 정답은 아니다. 에이전트 내부 판단의 대부분이 추론형이거나, 판단 유형을 사전에 정의하기 어려운 도메인이라면 라우팅 계층을 추가하는 것이 오히려 복잡성만 늘릴 수 있다.
또한 라우팅 설계 자체에도 유지 비용이 따른다. 경량 모델과 프론티어 LLM의 두 가지 모델을 운영하면 평가, 버전 관리, 오류 디버깅이 모두 두 배 가까이 복잡해진다. 팀의 규모와 운영 역량이 이 복잡성을 감당할 수 있는지를 미리 따져봐야 한다.
판단 유형이 뚜렷하게 나뉘고, 반복 호출이 많으며, 비용과 응답 속도가 실제 제약이 되는 프로젝트에서 이 설계가 의미를 가진다. 조건이 맞지 않으면 처음부터 프론티어 LLM 하나로 단순하게 유지하는 것이 더 나을 수 있다.
