새 코딩 모델로 바꾸는 일은 설정 한 줄을 고치는 작업처럼 보이지만 실제로는 작은 배포에 가깝다. 모델 식별자뿐 아니라 컨텍스트 처리, 비용, 프롬프트 반응, 도구 사용 방식까지 달라질 수 있기 때문이다. 데모 한 번이 좋아 보인다는 이유로 팀의 기본값을 바꾸면 어느 변화가 품질을 높였고 어느 변화가 오류를 만들었는지 추적하기 어렵다.
안전한 교체에는 네 가지가 필요하다. 성공 기준을 먼저 고정하고, 실제로 호출한 모델과 공급자를 기록하고, 첫 답변이 아닌 완료 비용을 비교하고, 되돌릴 수 있게 단계적으로 배포하는 일이다.
1. ‘더 좋다’를 측정할 성공 기준으로 바꾼다
교체 목표는 한 문장으로 쓴다. “복잡한 버그의 재요청 횟수를 줄인다”와 “코드 리뷰에서 놓치는 치명적 결함을 줄인다”는 서로 다른 시험이 필요하다. 정확도, 처리 시간, 사람의 수정량처럼 관찰 가능한 지표를 정하고 합격선을 붙인다. Anthropic도 평가 설계 공식 문서에서 성공 기준을 구체적이고 측정 가능하게 정의한 뒤 테스트 사례로 검증하라고 안내한다.
대표 업무는 우리 팀의 실제 로그에서 고른다. 예를 들어 버그 수정, 작은 기능 구현, 코드 리뷰, 문서 질의를 섞어 여섯~열 개의 사례를 만들 수 있다. 각 사례에는 시작 상태, 허용 파일, 완료 조건, 통과할 테스트를 남긴다. 모델마다 같은 저장소 상태와 같은 요청을 써야 비교 결과가 설명 가능해진다.
2. 별칭이 아니라 실제 모델과 공급자를 기록한다
별칭은 편하지만 고정 버전이 아니다. Claude Code의 opus와 sonnet 별칭은 공급자와 조직의 허용 모델 정책에 따라 해석이 달라질 수 있다. Anthropic API는 전체 모델명, Bedrock은 ARN, Foundry는 배포명, Google Cloud는 버전명을 기록하고 Claude Code 버전과 실행 날짜를 붙인다. 공급자별 식별 방식과 별칭 표는 Claude Code 모델 설정 문서에서 확인할 수 있다.
운영에서 별칭을 쓰더라도 변경 기록은 남긴다. 적용 날짜, 이전 모델, 새 모델, 변경 책임자, 원복 명령을 최소 항목으로 둔다. “어제는 됐는데 오늘은 왜 달라졌나”를 모델 변화와 프롬프트 변화로 나눠 볼 수 있다.
3. 컨텍스트 크기보다 완료 비용을 비교한다
컨텍스트 창이 커졌다고 저장소 전체를 한 번에 넣는 방식이 최선은 아니다. 관련 없는 파일이 늘면 중요한 제약을 찾기 어려워지고 입력 비용도 커진다. 먼저 관련 파일과 위험 지점을 찾게 한 뒤 승인한 자료만 구현 단계에 넘긴다. 탐색과 수정을 분리하면 모델별 비교에서도 입력 조건을 일정하게 맞추기 쉽다.
비용은 한 요청의 입력·출력 토큰으로 끝나지 않는다. 재시도, 도구 호출, 대화 압축, 병렬 작업, 사람이 다시 고친 시간까지 합친 ‘완료 비용’을 본다. Anthropic API는 시험 당일 Claude Platform 가격 문서를 저장하고, Bedrock·Google Cloud는 해당 공급자의 공식 요금표를 따로 남긴다.
4. 한 번에 하나만 바꾸고 원복 경로를 남긴다
새 모델과 새 프롬프트, 새 권한을 동시에 켜면 장애 원인을 분리할 수 없다. 먼저 소수 사용자나 낮은 위험의 저장소에 모델만 바꾸고 같은 작업 로그로 비교한다. 합격선을 넘은 뒤 기능을 하나씩 추가한다. Claude Code라면 claude --model <공급자별 식별자> 형태의 원복 명령과 담당자를 배포 전에 정한다.
모델은 계속 제공된다는 보장이 없다. Anthropic의 모델 수명주기 안내는 폐기 전에 대체 모델을 충분히 시험하고, 공급자별 종료 일정이 다를 수 있다고 설명한다. 따라서 원복 모델의 지원 상태도 함께 확인해야 한다.
교체 전 체크리스트
- 목표·지표·합격선이 한 문장으로 정리됐는가
- 전체 모델명·도구 버전·공급자·실행 날짜를 기록했는가
- 재시도와 사람의 수정까지 포함한 완료 비용을 비교했는가
- 소규모 배포, 원복 명령, 변경 책임자를 준비했는가
좋은 모델 교체는 새 기능을 많이 켜는 일이 아니다. 같은 대표 업무에서 이전보다 나아졌음을 재현하고, 문제가 생겼을 때 빠르게 돌아갈 수 있게 만드는 일이다.