새 모델로 갈아타기

새 모델 하나를 실제 사용자에게 붙이기까지의 전 과정입니다. 코드 배포는 한 번도 필요하지 않습니다. 시작하기 전에 두 가지가 준비돼 있으면 좋습니다. 판정 기준이 될 대표 성공 지표(성과 증명하기 참고), 그리고 시험 입력으로 쓸 실제 호출 기록입니다.

1. 테스트에서 후보를 거릅니다

테스트에서 지금 운영 중인 옵션을 기준선으로 두고 새 모델을 나란히 올립니다. 시스템 프롬프트는 일단 같게 두고, 입력은 “기록에서 불러오기”로 실제 고객이 보냈던 요청을 채웁니다. 상상해서 지어낸 입력으로는 결과를 믿기 어렵습니다.

“전체 실행”을 누르고 응답 품질은 눈으로, 비용과 응답 속도는 숫자로 비교합니다. 입력을 서너 개 바꿔가며 반복하다 품질이 눈에 띄게 무너지면 여기서 멈춥니다. 그 후보가 실제 사용자를 만날 일은 없습니다.

시험을 통과했으면 “옵션으로 저장”을 누르고 라우팅에서 새 옵션에 10%를 줍니다. 이 순간부터 사용자 열 명 중 한 명이 새 모델의 응답을 받습니다. 같은 사용자가 계속 같은 옵션을 받는 규칙은 라우팅에 정리돼 있습니다.

비교에 두 옵션을 올리고 새 옵션의 에러율이 튀지 않는지, p50 지연시간이 기대한 대로인지만 봅니다. 아직 성과를 판단할 때가 아닙니다.

이상이 보이면 요청에서 모델 필터로 새 모델만 걸러 원인을 확인하고, 심각하면 라우팅에서 새 옵션을 0으로 내립니다. 이것이 롤백이고, 몇 초면 끝납니다.

비교에 두 옵션을 올리면 이 기능의 대표 성공 지표가 기본 비교 기준으로 잡혀 있습니다.

서두르지 않는 것이 중요합니다. 옵션당 사용자 100명이 쌓이기 전에는 비교가 저표본 경고를 띄우고, 경고가 떠 있는 동안의 숫자로는 판정하지 않습니다. 더 빨리 판단하고 싶다면 비율을 올려 표본 수집을 앞당기면 됩니다.

경고가 사라지면 에러율, 성공 지표, 호출당 비용 순서로 봅니다. 전환율이 조금 낮은데 비용이 크게 낮다면, “AI 비용 대비 매출” 지표 하나가 두 값을 한 숫자로 묶어 답을 줍니다.

비율을 올리는 단계와 각 단계에서 확인할 것은 라우팅에 있습니다. 쓰지 않을 옵션은 0으로 내리면 라우팅에서 빠집니다. 삭제할 필요는 없습니다.

프롬프트 변경이든 파라미터 튜닝이든, 무엇을 바꾸든 순서는 이와 같습니다. 전환 전후의 비용 변화는 개요의 30일 추이에서 확인해 팀에 공유하세요.