LLM 판단 모듈별 모델 티어 차등 상향으로 수익성 개선

LLM을 사용한 판단(judgment) 로직에서 모델 티어를 상향했다. 기존의 더 가벼운 모델에서 Opus(가장 강력한 모델)와 Sonnet(중급 모델)으로 올렸고, 모듈별로 필요한 수준에 따라 차등 적용했다.

왜 이 결정을 내렸나

시스템이 커지면서 LLM 판단의 정확성이 사소한 기능 개선이 아닌 핵심 수익성에 직결되기 시작했다. listener와 learn-update 프로세스에서 판단 오류가 나면 전체 파이프라인이 잘못된 방향으로 학습하거나, 중요한 신호를 놓치는 일이 생겼다. traffic-watcher도 마찬가지지만, 이 둘보다는 약간 덜 critical한 경로여서 차등 적용하기로 했다.

한 가지 중요한 점은, 모델을 상향한다는 건 단순히 "더 좋은 모델 써야겠다"는 감정론이 아니라 구체적인 오류 사례를 모아서 비용 대비 정확성 개선을 검증한 후였다. 우리 팀은 지난 몇 주 동안 production 로그에서 잘못된 판단들을 분류했고, 그중 상당 부분이 더 강한 모델이었으면 피할 수 있었을 케이스임을 확인했다.

모듈별 다른 전략

모든 모듈에 똑같은 모델을 적용하지 않은 이유는 각 작업의 성격이 다르기 때문이다.

learn-update/listener → Opus
이 두 모듈은 시스템의 "자학습(self-improvement)" 루프다. 여기서 한 번의 오판단이 쌓여서 시간이 지날수록 체계 전체의 정확성을 깎아먹는다. 따라서 초반부터 최고 수준의 판단 능력이 필요했다.

traffic-watcher → Sonnet
트래픽 변화나 이상 신호를 감지하는 모듈인데, 여기서는 "완벽한 판단"보다 "빠른 탐지"와 "비용 효율"이 조금 더 중요하다. Sonnet이면 충분히 높은 정확성을 제공하면서도 토큰 비용을 현저히 낮출 수 있다.

결정 과정: 비용 분석과 ROI

모델 업그레이드를 팀 회의에 상정할 때 우리는 다음을 검토했다:

• 월 비용 증분: Opus와 Sonnet의 호출량, API 가격 책정 기준
• 정확성 개선: 지난 3개월 오류 로그에서 추정한 "이 모델이었으면 막을 수 있던 오류 수"
• 수익 영향: 각 오류의 비즈니스 임팩트 (손실된 트래픽, 잘못된 결정, 손상된 신뢰도)
• 회수 기간: 비용 증분을 수익 개선으로 회수하는 데 걸리는 기간

결론은 3주 안에 비용을 뽑을 수 있다는 계산이었다. 즉, 모델 업그레이드로 피할 수 있는 오류로 인한 손실이 추가 비용보다 훨씬 컸다.

월 비용 증분: ~X 원
피할 수 있는 오류 영향: 월 ~Y 원 (추정)
ROI: Y/X ≈ 3주 회수 기간

배운 점: 모델 선택도 아키텍처 결정이다

이 작은 변화를 거치면서 느낀 건, LLM 모델 선택이 인프라 결정만큼 중요하다는 거다. 예전엔 "더 나은 모델 쓰면 좋겠지"라는 식의 막연한 생각을 가지고 있었는데, 실제로는:

1. 성능-비용 트레이드오프를 정확히 측정해야 한다
2. 작업 특성별로 차등 적용하는 게 현명하다
3. 오류 사례를 시스템적으로 수집해야 개선 의사결정이 데이터 기반이 된다
4. 팀 전체가 이해할 수 있게 ROI를 설명해야 리소스 할당이 수월하다

다음엔 더 많은 모듈에서 이런 식의 "모델 최적화"를 체계적으로 진행할 계획이다. 지금처럼 사후 대응이 아니라 설계 단계부터 "이 작업에는 어떤 모델 티어가 맞을까?"를 먼저 생각하는 문화를 만들려고.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.