모델이 또 바뀌면, 우리 서비스는 괜찮을까?
모델 교체가 일상이 된 시대, 갈아타기 쉬운 구조를 만드는 분리 원칙과 하루 만에 끝내는 교체 절차.
지난 2년 동안 여러분의 서비스에서 쓰는 모델은 몇 번이나 바뀌었나요?
대부분의 팀은 "쓰던 모델이 갑자기 느려져서", "더 싼 게 나와서", "구버전 종료 안내를 받아서" 모델을 바꿉니다.
문제는 그때마다 며칠이 통째로 사라진다는 점입니다.
모델 이름이 코드 여기저기에 박혀 있고, 프롬프트는 개발자 노트북에만 있고, 바꾼 뒤에 품질이 좋아졌는지 나빠졌는지 판단할 기준이 없기 때문입니다.
지금의 현실은 단순합니다. 모델은 계속 바뀝니다. 그래서 작은 팀에게 더 중요한 질문은 "어떤 모델이 최고인가"가 아니라 "모델이 바뀌어도 우리 서비스가 흔들리지 않는가"입니다.
왜 지금 모델 교체를 준비해야 할까요?
모델 교체는 이제 예외 상황이 아니라 정기적으로 찾아오는 유지보수 작업이기 때문입니다.
공급사는 새 버전을 내놓으면서 구버전을 언젠가 정리하고, 가격표와 응답 속도도 함께 조정합니다.
준비된 팀은 반나절이면 끝내고, 준비 안 된 팀은 기능 개발을 멈추고 며칠을 씁니다.
- 구버전 종료: 특정 모델 버전이 더 이상 제공되지 않으면 선택의 여지 없이 옮겨야 합니다.
- 가격·속도 변화: 같은 작업을 더 싸게 처리할 수 있는 소형 모델이 계속 나옵니다.
- 기능 차이: 툴 호출, 구조화 출력(JSON), 긴 컨텍스트, 이미지 입력 지원 여부가 모델마다 다릅니다.
- 장애 대비: 한 공급사에 장애가 나면 대체 경로가 없는 서비스는 그대로 멈춥니다.
- 업무별 최적 모델: 요약은 저렴한 모델, 코드 리뷰는 고성능 모델처럼 나눠 쓰는 편이 총비용에 유리합니다.
무엇을 분리해 두면 갈아타기가 쉬워질까요?
거창한 아키텍처가 아니라 "바뀔 것"과 "안 바뀔 것"을 나눠 두는 정리 작업이면 충분합니다.
아래 다섯 가지만 해두면 모델 교체는 설정 한 줄 수정 수준으로 내려옵니다.
- 호출 지점을 한 곳으로: 모델을 부르는 코드를 파일 하나(또는 함수 하나)로 모읍니다.
나머지 코드는 "요약해줘" 같은 기능만 호출합니다. - 모델 이름은 설정으로: 코드가 아니라 환경변수나 설정 파일에 둡니다.
기능별로 다른 모델을 지정할 수 있게 합니다. - 프롬프트는 파일로 분리: 버전 관리되는 텍스트 파일에 두고, 누가 언제 왜 고쳤는지 남깁니다.
- 출력 형식을 고정: 결과를 자유 문장이 아니라 정해진 JSON 구조로 받습니다.
모델이 바뀌어도 뒷단 코드는 그대로 돕니다. - 모든 호출을 기록: 입력, 출력, 모델명, 토큰 수, 응답 시간을 로그로 남깁니다.
이 로그가 나중에 평가셋의 재료가 됩니다.
예를 들면 이런 모습입니다
5인 규모 온라인 편집숍이 문의 자동응답을 운영한다고 해봅시다.
처음에는 개발자가 백엔드 코드 세 군데에 모델 이름을 직접 적었습니다.
정리 후에는 answer_inquiry() 함수 하나만 남기고, 모델명은 설정 파일에, 프롬프트는 prompts/cs_reply.txt에 두었습니다.
그리고 실제 문의 로그에서 배송 지연·교환·사이즈 문의 등 30건을 골라 정답 예시와 함께 평가셋으로 만들었습니다.
다음번 모델 교체 때 이 팀이 할 일은 설정 한 줄을 바꾸고 30건을 돌려 비교하는 것뿐입니다.
실제로 갈아탈 때는 어떤 순서로 하나요?
"바꾸고 잘 되나 보자"는 방식이 가장 위험합니다.
후보를 좁히고, 같은 문제로 비교하고, 일부 트래픽부터 흘려보내는 3단계 순서를 지키면 하루 안에 안전하게 끝낼 수 있습니다.
- 후보 2개만 고릅니다.
가격대와 기능(툴 호출·구조화 출력 지원)이 우리 용도에 맞는지부터 확인합니다. - 평가셋으로 나란히 비교합니다.
20~50건이면 충분하고, 정답률뿐 아니라 응답 시간과 호출당 비용도 함께 봅니다. - 프롬프트를 조금 손봅니다. 같은 프롬프트가 모델마다 다르게 반응하는 건 정상입니다.
지시 순서와 예시 개수를 조정해 보세요. - 일부 트래픽부터 새 모델로 보냅니다.
하루 이틀 정도 실패율, 사람이 개입한 비율, 고객 재문의율을 지켜봅니다. - 롤백 스위치를 남깁니다. 설정 한 줄로 이전 모델로 돌아갈 수 있어야 진짜 준비된 상태입니다.
다만 과도한 추상화는 경계하세요.
모든 공급사에 똑같이 동작하는 최소 공통 기능만 쓰다 보면, 프롬프트 캐싱이나 특정 모델의 강력한 툴 호출 같은 이점을 스스로 포기하게 됩니다.
현실적인 목표는 "어디서든 똑같이 돌아가는 코드"가 아니라 "한 곳에 잘 최적화하되, 하루면 나갈 수 있는 문을 만들어 두는 것"입니다.
모델은 앞으로도 계속 바뀝니다.
바뀔 때마다 흔들리는 서비스와, 설정 한 줄로 옮겨가는 서비스의 차이는 기술력이 아니라 이 작은 정리 습관에서 갈립니다.
오늘 코드에서 모델 이름을 몇 군데에 적어 두었는지부터 세어보세요.