🧑🏻💻 Ep.31 | 모델이 바뀌어도 제품이 무너지지 않게
금요일 오후, 사용하던 모델의 새 버전이 나왔습니다. 벤치마크는 더 좋고 가격은 낮았습니다. 팀은 스테이징에서 질문 몇 개를 던져본 뒤 모델 이름을 바꿨어요.
답변은 전보다 자연스러웠습니다. 그런데 쿠폰 승인 화면의 ‘적용 정책’이 가끔 빈칸으로 나왔습니다. 새 모델이 JSON 필드 하나를 생략한 겁니다. 파서는 오류를 내지 않았고, 화면은 빈 값을 그대로 그렸습니다.
모델은 좋아졌는데 제품은 더 위험해졌습니다.
모델 교체는 부품 이름을 바꾸는 설정 작업이 아니라, 동작이 다른 외부 의존성을 옮기는 마이그레이션입니다.
※ 이 글의 배포 장면과 수치는 모델 교체 패턴을 설명하기 위해 재구성한 가상 사례입니다.
1. 익숙한 마이그레이션이라면 어떻게 했을까
결제 API 버전을 바꾼다고 생각해봅시다. 문서만 보고 금요일에 엔드포인트를 통째로 교체하지는 않을 겁니다. 요청·응답 호환성을 확인하고, 샌드박스에서 실제 시나리오를 돌리고, 일부 트래픽부터 옮기고, 되돌릴 방법을 준비합니다.
DB 컬럼을 바꿀 때도 새 컬럼을 먼저 추가하고 양쪽 쓰기를 거쳐 천천히 옮깁니다. 외부 시스템은 우리가 통제하지 못하고, 사소한 차이가 제품의 큰 실패로 이어질 수 있다는 걸 알기 때문입니다.
AI 모델도 같습니다. 같은 프롬프트를 받아도 구조화된 출력, 도구 선택, 거절 방식, 문장 길이가 달라집니다. 제공자가 “호환 가능”이라고 말해도 우리 제품의 중요한 조건까지 같다는 뜻은 아닙니다.
2. 모델 밖에서 지켜야 할 것을 고정한다
승인 화면에 필요한 필드는
action, amount, policy_id, reason 네 개였습니다. 모델에게 “반드시 JSON으로 답해줘”라고 부탁하는 것만으로는 부족했습니다.
응답을 받은 시스템이 스키마를 직접 검사해야 합니다. 필수 값이 없거나, 금액이 허용 범위를 벗어나거나, 허용하지 않은 행동이 들어오면 다음 단계로 넘기지 않습니다. 사용자가 보는 문장은 조금 달라도, 제품이 기대하는 형태와 안전 규칙은 모델 밖에 있어야 합니다.
이때 고정할 것은 JSON만이 아닙니다.
✔️ 어떤 질문을 지원하고 언제 거절하는가
✔️ 어떤 도구를 어떤 조건에서 호출할 수 있는가
✔️ 최대 지연과 요청 비용은 얼마인가
✔️ 근거가 없을 때 어떤 축소 동작으로 가는가
앞에서 만든 제품의 약속을 모델별 프롬프트 속에 흩어놓지 않고 시스템 계약으로 둡니다. 그래야 새 모델이 들어와도 같은 시험을 치를 수 있습니다.3. 배포 묶음을 정확히 이름 붙인다
모델만 바뀌는 경우는 드뭅니다. 새 모델에 맞춰 프롬프트를 다듬고, 출력 스키마 설명을 바꾸고, 검색 결과 개수를 조절하기도 합니다. 어느 변경이 결과를 만들었는지 나중에는 기억나지 않습니다.
그래서 모델 버전, 프롬프트 버전, 검색 설정, 도구 스키마를 하나의 배포 묶음으로 기록합니다. 평가 결과와 운영 지표도 이 묶음에 연결하고요.
모델 B가 문제였다보다 model-b / prompt-18 / retrieval-7 / tools-4 조합에서 policy_id 누락이 관찰됐다가 복구 가능한 정보입니다. 정확한 조합을 알아야 이전 상태로 되돌릴 수 있습니다.💡 롤백은 옛 모델 이름을 기억하는 일이 아니라, 마지막으로 검증된 제품 묶음을 다시 올리는 일입니다.
4. 실제 요청으로 비교하되, 사용자 몰래 복제하지 않는다
평가셋을 통과한 뒤에는 실제 요청의 모양에서도 비교하고 싶어집니다. 운영 요청을 새 모델에도 보내되 결과는 사용자에게 전달하지 않는 방식을 보통 shadow 평가라고 부릅니다.
분포가 다른 질문과 예상하지 못한 출력 차이를 찾는 데 유용합니다. 다만 “사용자에게 보내지 않는다”는 이유로 읽기 전용이라고 생각하면 안 됩니다. 고객 대화가 새 모델이나 다른 제공자에게 전송되는 것 자체가 새로운 데이터 처리입니다.
개인정보 처리 조건, 데이터가 저장되는 지역과 기간, 계약과 비용을 먼저 확인합니다. 비교에 필요 없는 값은 가리고, 새 모델의 도구 호출은 실제 시스템에 연결하지 않습니다. 결과 저장소도 운영 기록과 분리하고 평가 기간이 끝나면 정리합니다.
검증 환경이 또 하나의 영구 고객 데이터 창고가 되면 안 됩니다. 안전한 마이그레이션이 개인정보 경계를 넓히는 핑계가 되어서는 안 되고요.
5. 1%에서 발견되는 것
새 모델을 바로 100%로 보내는 대신 내부 사용자, 일부 상담원, 낮은 위험의 질문부터 엽니다. 이 작은 구간에서 정답률만 보는 건 아닙니다.
필드 누락, 도구 호출 비율, 상담원 수정, 지연, 비용, 이관률을 이전 묶음과 비교합니다. 특히 전체 평균이 아니라 특정 주문 유형과 언어에서만 나빠지는지 봅니다. 사용량이 적은 경계 사례가 평균에 묻힐 수 있으니까요.
확대 조건과 중단 조건은 시작 전에 정합니다. “이상하면 내린다”가 아니라, 필수 필드 누락이 한 건이라도 나오면 중단하는지, 이관률이 기준보다 얼마나 오르면 되돌리는지 합의합니다.
그리고 자동 확대에만 기대지 않습니다. 숫자는 정상인데 상담원이 “근거가 전보다 읽기 어렵다”고 말할 수 있습니다. 정량 평가와 현장 표본을 함께 본 뒤 다음 구간으로 갑니다.
6. 되돌아갈 길도 살아 있어야 한다
새 모델용으로 프롬프트와 스키마를 고친 뒤 옛 모델이 더는 동작하지 않는 경우가 있습니다. 롤백 버튼은 있지만 눌러보지 않은 셈입니다.
이전 배포 묶음이 실제로 뜨는지 정기적으로 확인합니다. 새 모델에서 만든 대화 상태나 캐시가 옛 모델과 호환되는지, 제공자 장애 때문에 새 모델로 옮겼는데 롤백 대상도 같은 장애 영역에 있는지는 따로 봅니다.
외부 제공자를 감싸는 얇은 어댑터도 도움이 됩니다. 제품 코드 전체가 특정 모델의 필드와 오류 형식에 직접 기대지 않게 하는 겁니다. 모든 모델을 완벽히 추상화할 수는 없지만, 우리 제품의 계약과 제공자의 차이를 한곳에서 번역하면 교체 범위가 작아집니다.
✅ 좋은 모델을 고르는 능력만큼 중요한 건, 한 모델을 제품 그 자체로 만들지 않는 능력입니다.
금요일의 필드 누락 뒤 팀은 모델 교체를 배포로 다루기 시작했습니다. 바꾸는 속도는 조금 느려졌지만, 새 모델을 시도하는 일은 오히려 덜 무서워졌습니다. 되돌릴 수 있다는 확신이 있을 때 변화도 더 자주 할 수 있으니까요.
🌱 변화해도 무너지지 않는 시스템을 만드는 곳, 루퍼스
외부 의존성을 바꾸는 일에는 호환성, 관측, 롤백의 감각이 필요합니다. 실제 운영에서 쌓인 설계 경험을 함께 나누고 싶다면 루퍼스에서 시작해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article