모델 티어링의 환상과 숨은 비용

에이전트를 여러 개 엮어 파이프라인을 돌리다 보면 반드시 나오는 질문이 있습니다. 간단한 작업은 싼 모델에, 어려운 작업은 비싼 모델에 태우면 되지 않느냐. 이른바 모델 티어링입니다.

저는 그렇게 하지 않습니다. 하네스 생성 스킬 내부를 확인해 보신 분은 아시겠지만, 에이전트마다 모델을 선택할 수 있는 유연한 구조임에도 저는 모든 에이전트의 기본 모델을 Opus로 고정했습니다. 테스트와 실무를 거듭할수록 적어도 제 워크로드에서는 이 선택이 가장 합리적이라는 확신이 들었기 때문입니다.

한 번은 반대로 선택했던 적이 있다

과거 지식베이스를 구축하고 AI 시스템을 오픈할 때, 저는 비용 앞에서 다른 선택을 했습니다. ’트레이드오프’라는 이름으로 더 나은 모델을 포기하고, 내부 벤치마크 점수는 12% 낮지만 비용은 94% 저렴한 하위 모델로 전면 교체했죠.

단일 프롬프트에서는 그럴듯하게 동작했습니다. 그런데 다중 에이전트 파이프라인을 타고 트래픽이 늘자 곳곳에서 예상치 못한 오류가 쌓였고, 사용자 불만은 걷잡을 수 없이 커졌습니다.

지금 돌아보면 이 사례는 “티어링이 나쁘다”의 증거라기보다 “당시 제 eval이 워크로드의 임계 구간을 제대로 반영하지 못했다”의 증거에 가깝습니다. 벤치마크 점수는 평균이고, 사용자는 분포의 꼬리에서 실패를 만납니다. 그 꼬리를 측정하는 데 실패한 거죠. 그럼에도 이 경험은 제 의사결정에 강하게 남았고, 그 이유를 아래에 정리합니다.

숨은 비용 세 가지

“간단한 작업은 싼 모델로 돌려 비용을 아껴야 한다.” 합리적으로 들리는 말입니다. 어떤 환경에서는 실제로 합리적입니다. 다만 모델 티어링이라는 프레임에는 계산서에서 자주 누락되는 숨은 비용이 있습니다.

첫째, 분류와 분기 자체가 이미 고급 작업이다

‘어떤 작업이 간단한지’ 판단하고 갈라 보내는 일은 그 자체로 난이도가 높습니다. 라우팅 로직이 조금만 어긋나도 싼 모델은 조용히 실패하고, 에이전트 환경에서는 이 미세한 실패가 다운스트림으로 증폭됩니다.

공정하게 덧붙이면 비용 증폭도 같이 커지므로, 에이전트는 티어링이 유리할 수도 치명적일 수도 있는 양면을 가집니다. 어느 쪽이 이기는지는 워커 실패율을 eval로 얼마나 타이트하게 잡아내는가에 달려 있습니다.

둘째, 품질 보장은 결국 내부 eval의 몫이다

공개 벤치마크는 내 워크로드를 모릅니다. 여기서 한 가지는 분명히 해 둬야 합니다. eval은 티어링의 비용이 아니라 프로덕션 LLM 운영의 기본값입니다. Opus 고정이든 티어링이든 eval은 어차피 필요합니다.

다만 티어링은 감지해야 할 실패 모드의 가짓수를 늘리고, 모델 쌍별 회귀 테스트까지 요구합니다. 같은 eval이 아니라 ’더 촘촘한 eval’이 요구되고, 그 추가분이 ’AI 비용 절감 계산서’에서 빠질 때가 많습니다.

셋째, 실패가 은밀해졌고 탐지에 비용이 든다

기반 모델 역량이 오르면서 실패 모드도 진화했습니다. 예전엔 눈에 띄게 엉뚱한 소리를 했다면, 이제는 그럴듯하고 매끄럽게 틀립니다.

이 문제는 Opus에도 똑같이 적용됩니다. 단일 모델 고정이 은밀한 실패를 없애 주진 않습니다. 다만 실패 원인을 ’모델 × 라우팅 × 폴백’의 조합 공간에서 찾지 않아도 된다는 점은 디버깅 비용을 확실히 줄여 줍니다. 변인 하나를 고정한다는 것 자체의 가치입니다.

라우팅, 폴백, 재시도, eval 확장까지 다 더하면 그냥 가장 좋은 모델 하나로 가는 편이 총소유비용(TCO) 관점에서 더 싸고 더 안정적일 때가 많습니다. 적어도 제 스케일에서는요.

시선을 조직 차원으로 옮기면

최근 Claude Code를 전사적으로 도입하는 기업이 늘면서 내부에서 흥미로운 프레임이 자리잡고 있습니다. “토큰을 많이 쓰는 직원이 유능하다”는 관찰이 먼저 있었고, 여기에 “그렇다면 토큰을 ‘잘’ 쓰는지도 봐야 하지 않느냐, 쉬운 작업을 비싼 모델로 돌리진 않는지 확인하자”는 의견이 붙는 걸 봤습니다. 티어링 효율을 개인 평가 축에 올리자는 이야기입니다.

앞서 썼듯 티어링은 이봉분포·실패 감지·촘촘한 eval이라는 세 조건이 받쳐줘야 성립합니다. 이걸 팀이 아닌 개인에게 요구한다는 건, 각 엔지니어가 자기 업무 분포를 스스로 모델링하고, 자기 손으로 eval을 갖추고, 라우팅 실패를 스스로 감지하라는 뜻입니다. 팀 인프라로도 벅찬 일을 1인당 부과하는 셈이죠. 측정된 ’토큰 효율’은 대체로 ’과업을 축소한 사람이 잘 나와 보이는 지표’로 수렴할 위험이 큽니다.

그래서 더 본질적인 질문은 따로 있다고 봅니다. 토큰으로 무엇을 만들었는가. 어떤 문제를 풀었는가. 어떤 의사결정을 바꿨는가. 어떤 결과물을 배포했는가. 이 질문에서 토큰은 비용이 아니라 도구입니다. Opus를 열 배 쓰고 하루짜리 작업을 한 시간에 끝냈다면, 그 열 배는 절약할 대상이 아니라 지불한 값입니다.

AI가 코드의 절대다수를 작성하고 인간이 그 흐름을 지휘하는 패러다임에서, 엔지니어의 인지적 에너지는 ’문제 해결’과 ’산출물의 품질’에 집중되어야 합니다. 폭발적 생산성은 가장 뛰어난 모델을 믿고 흐름을 끊지 않을 때 나옵니다. 푼돈을 아끼려 이 작업은 하위 모델로, 저 작업은 상위 모델로 끊임없이 분기하게 만드는 설계는, 개인에게 전가된 부업이자 사고의 단절 비용이라는 생각이 듭니다.

오해를 피해 덧붙입니다. 조직 전체의 토큰 예산을 관리할 필요가 없다는 말이 아닙니다. 총비용 상한을 두는 것도, 명백한 극단값을 가려내는 것도 합리적인 관리입니다. 제가 반대하는 건 개인 평가 축에 ’티어링 기술’을 올리는 방향입니다. 평가받는 순간 사람들은 지표를 최적화하고, 그 최적화의 종착지는 ’하위 모델로 끝난 일이 많아 보이는 사람’입니다. 실제로 가치를 만든 사람이 아니라요.

티어링이 정말 이득이 되는 순간

티어링이 잘못된 전략이라는 게 아닙니다. 아래 세 조건이 함께 설 때 티어링은 강력한 도구입니다.

워크로드가 뚜렷한 이봉분포(단순 반복 작업 vs 고도의 추론)를 가질 때
사용자에게 도달하기 전 실패를 감지할 메커니즘이 있을 때
이 둘을 지탱할 eval 인프라가 촘촘할 때

특히 에이전트 루프에서 플래너·크리틱은 상위 모델, 익스큐터는 하위 모델로 나누는 구조는 하네스 엔지니어링의 정석 중 하나입니다. 이 조건을 갖춘 팀에게는 오히려 티어링을 적극 권합니다.

반대로 제가 있는 지점은 이렇습니다. 워크로드는 단봉에 가깝고, 실패 하나의 리콜 비용이 절감 이득을 쉽게 넘어섭니다. 이 조건에서는 가장 좋은 모델 하나로 밀고 나가는 쪽이 TCO 관점에서도 더 싸고 더 안정적이라는 판단입니다.

이 판단이 스케일에 종속된다는 점도 분명히 해 둡니다. 월 수억 호출의 B2C 서비스라면 단위경제가 제품 존속 조건이 되고, 그 계산은 완전히 달라집니다. 제 결론을 보편 원칙으로 읽지 마시고, 지금 제 워크로드에서 판단한 선택으로 읽어 주시면 좋겠습니다.

그래서 저는 지금까지 그래왔고, 당분간도, 가장 좋은 모델을 사용합니다. 그리고 조직에도 같은 질문을 돌려드리고 싶습니다.

현재 직원에게 “얼마나 아꼈는가”를 묻고 있습니까? 아니면 “무엇을 만들었는가, 어떤 문제를 풀었는가, 어떤 의사결정을 바꿨는가”를 묻고 있습니까?