개발 slecs

gov 분류기를 정책 기준에 맞게 상위 모델로 교체한 이유

목차

classification 모델을 Haiku에서 Sonnet으로 변경했다. 간단해 보이는 한 줄 변경이지만, 뒤에 정책 준수와 실제 운영 사이의 갈등이 있었다.

정책과 현실의 괴리

우리 조직은 judgment 관련 작업에 대해 "≥Sonnet 정책"을 정의해놨다. 즉, 최종 판단을 내리거나 영향력 있는 결정에 사용되는 모델은 Sonnet 이상의 성능을 보장해야 한다는 기준이다. 이건 말 그대로 정책이었는데, gov 도메인의 classifier는 여전히 Haiku로 운영 중이었다.

왜 이런 갭이 생겼을까? 대부분의 경우 비용 때문이다. Haiku는 토큰 비용이 저렴하고 응답 속도가 빠르다. 초기에 모델을 선택할 때 "충분히 작동하는데?"라고 생각했고, 폭증하는 트래픽 속에서 효율성을 우선했던 거다. 하지만 정책이 정해지고 본격적으로 감시하기 시작하니 이 기술 부채가 명확히 보였다.

모델 선택의 트레이드오프

일반적으로 classifier를 구성할 때 마주하는 결정이다:

고려 사항 Haiku Sonnet
정확도 중상 높음
토큰 비용 낮음 중간
응답 시간 빠름 중간
정책 준수
복잡한 맥락 처리 제한적 우수

Haiku로도 대부분의 케이스를 "충분히" 분류할 수 있다. 하지만 "충분히"와 "정책 준수"는 다르다. 특히 gov 도메인은 민감도가 높아서, 한두 건의 오분류가 신뢰도에 미치는 영향이 크다.

의사결정 측면에서 이 변경은 "선택"이 아니라 "필수"였다. 정책이 존재하는 이상, 그걸 따르지 않으면 기술 부채가 아니라 정책 위반이 된다. 팀원들이 정책을 신뢰할 수 없게 되는 문제도 있다.

구현과 고려사항

# gov/classifier.py 패턴
# Before: model="claude-3-5-haiku-20241022"
# After: model="claude-3-5-sonnet-20241022"

모델만 바꾼 것 같지만, 실제로는 몇 가지를 함께 검토해야 한다:

  • 비용 영향 분석: 일일 비용이 얼마나 증가하는가? 사용량에 비례해서 계산
  • 응답 시간: Sonnet이 조금 느려도 deadline이 있는가? 배치 vs 실시간 처리
  • 정확도 개선 검증: 실제로 Sonnet이 얼마나 나아졌는지 테스트 데이터로 확인
  • 롤아웃 전략: 한 번에 전체 전환할 것인가, 점진적 전환(canary)을 할 것인가?

우리는 이 정책이 정해진 이상, 합리적인 비용 범위 내에서는 준수하는 게 맞다고 판단했다. 나중에 정말 비용이 심각하면 그때 다시 논의해도 된다. 하지만 처음부터 정책을 무시하고 나중에 "이제 맞춥시다"라고 하는 건 신뢰 문제다.

배운 점들

첫째, 정책은 처음부터 "실행 가능한" 수준에서 정의해야 한다. 이상적인 기준만 높게 놓고, 실제로는 구현이 안 되면 정책 자체가 형식화된다. 역으로, 정책이 정해졌다면 그걸 준수하기 위한 로드맵을 함께 커뮤니케이션하는 게 중요하다.

둘째, 모델 선택은 단순 성능/비용 비교가 아니라 "어디에 사용되는가"라는 맥락에서 결정해야 한다. 계산이 non-blocking 배경 작업이라면 조금 느려도 괜찮다. 하지만 judgment처럼 최종 결정에 영향을 미치는 작업이라면 품질 우선이 맞다.

셋째, 기술 부채는 쌓일수록 정책화된다. 처음엔 "일단 Haiku로 하고 나중에"라는 타협이, 언젠가 "이건 정책을 어기고 있다"는 부담으로 변한다. 따라서 초기에 기준을 명확히 하고, 그 범위 내에서 시작하는 게 중요하다.

이번 변경은 작은 모델 업그레이드지만, 뒤에는 정책 준수, 의사결정, 팀 신뢰가 섞여 있다.


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

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

댓글 0

첫 댓글 달아줘.