모델이 바뀔 때마다 품질이 좋아질 거라고 기대하지만, 실제 프로덕션에서는 반대 상황이 자주 나옵니다. 더 좋은 모델로 갈아탔는데 응답 형식이 깨지고, 프롬프트가 안 먹히고, 지연시간과 비용이 예상과 다르게 튀는 경우입니다. AWS의 글인 AWS Generative AI Model Agility Solution(https://aws.amazon.com/blogs/machine-learning/aws-generative-ai-model-agility-solution-a-comprehensive-guide-to-migrating-llms-for-generative-ai-production/)이 실무자에게 유용한 이유는 모델 마이그레이션을 “새 모델 테스트”가 아니라 “평가-프롬프트 이식-재평가”라는 운영 프레임워크로 설명하기 때문입니다.
원문은 LLM 마이그레이션 또는 업그레이드를 2일에서 2주 정도의 프로젝트로 정리합니다. 이 범위는 사용 사례 복잡도에 따라 달라진다고 명시돼 있습니다. 중요한 건 기간 숫자보다 접근 방식입니다. 모델 교체를 감으로 하지 말고, 비교 가능한 데이터셋과 명시적인 성공 기준 위에서 하라는 겁니다.
실패 원인은 보통 세 가지입니다.
첫째, 소스 모델이 실제로 어떤 기준에서 합격이었는지 문서가 없습니다. “대충 괜찮았다”만 기억합니다. 둘째, 프롬프트가 특정 모델의 편향과 표현 방식에 과적합돼 있습니다. 셋째, 비용·지연시간·품질을 한 번에 비교하지 않고, 데모 몇 개만 보고 의사결정합니다.
이 상태에서 새 모델을 붙이면 팀 내부에서 늘 같은 말이 나옵니다. “예제 A는 더 좋아졌는데 예제 B는 왜 망가졌지?” 이 질문이 반복되면 이미 늦은 겁니다. 교체 전에 비교 체계를 못 만든 상태였다는 뜻입니다.
원문이 이 문제를 잘 짚는 이유는 마이그레이션의 시작점을 모델 선택이 아니라 데이터 준비에 두기 때문입니다.
새 모델을 붙이기 전에 지금 모델이 어떤 품질과 비용 구조를 갖는지 숫자로 알아야 합니다. 원문은 샘플 데이터에 prompt, input, ground truth, source output, latency, input/output token, 기존 human score나 automated evaluation score까지 담으라고 권합니다.
여기서 핵심은 “평가용 데이터셋”이 단순 테스트 케이스 모음이 아니라는 점입니다. 좋은 평가셋은 실제 운영 분포를 반영해야 합니다.
이 다섯 종류가 최소한 섞여야 합니다. 그렇지 않으면 새 모델이 데모에서는 좋아 보여도 실전에서 무너집니다.
원문은 cost, latency, accuracy, quality를 함께 보라고 합니다. 이게 실무적으로 매우 중요합니다. 많은 팀이 “응답이 더 좋아졌다”만 보고 넘어가는데, 실제 비즈니스에서는 아래 조합으로 의사결정이 갈립니다.
즉 모델 교체는 절대 단일 점수 게임이 아닙니다. 팀마다 우선순위도 다릅니다. 고객지원 자동화라면 지연시간이 중요할 수 있고, 법무 검토라면 정확성과 추적 가능성이 더 중요할 수 있습니다.
그래서 성공 기준은 “최종 점수 상승”이 아니라 “업무별 최소 기준 충족 + 비용/지연시간 허용 범위 유지”로 정의하는 편이 훨씬 낫습니다.
원문이 특히 유용한 부분이 prompt migration입니다. 많은 팀이 같은 프롬프트를 새 모델에 넣고 결과를 비교합니다. 이건 공정한 비교 같지만, 실제로는 새 모델에 불리하거나 반대로 과도하게 유리한 실험이 될 수 있습니다.
모델마다 잘 이해하는 지시 형식, 구조화 방식, 온도 민감도, 긴 컨텍스트 처리 방식이 다릅니다. 따라서 프롬프트 이식은 별도 단계여야 합니다. 원문이 Amazon Bedrock Prompt Optimization과 Anthropic Metaprompt tool 같은 자동화 도구를 언급하는 이유도 여기에 있습니다.
실무적으로는 프롬프트 마이그레이션을 세 단계로 나누면 좋습니다.
이렇게 해야 “모델 차이”와 “프롬프트 차이”를 분리해 볼 수 있습니다.
원문은 use case에 따라 ground truth가 꼭 필요한 경우도 있지만, answer relevancy, faithfulness, toxicity, bias처럼 정답 없이도 볼 수 있는 지표가 있다고 설명합니다. 이건 RAG나 자유서술형 업무에서 특히 중요합니다.
현실에서는 정답셋이 완벽하지 않은 경우가 많습니다. 그렇다고 평가를 느슨하게 두면 더 위험합니다. 대신 인간 평가와 자동 평가를 혼합해야 합니다.
이렇게 나눠야 평가 체계가 업무에 맞아집니다. 같은 모델이라도 업무 성격에 따라 승패가 달라질 수 있기 때문입니다.
원문은 context window, modality, token cost, latency, hosting option, data privacy 같은 항목을 비교하라고 정리합니다. 이건 체크리스트로 매우 좋습니다. 다만 실무에서는 한 줄 더 필요합니다. “우리 실패 패턴에 이 모델이 강한가”입니다.
예를 들어 긴 문서를 많이 넣는 팀은 context window 숫자보다 실제 긴 입력에서의 회복력을 봐야 합니다. 구조화 JSON이 중요한 팀은 생성 품질보다 schema adherence를 먼저 봐야 합니다. 멀티모달이 필요 없는 팀은 그 기능에 돈을 더 낼 이유가 없습니다.
즉 모델 카드의 기능 나열을 보는 것보다, 현재 운영 장애를 줄여주는지 보는 것이 더 실용적입니다.
원문이 말하는 “model agility”의 핵심도 여기 있습니다. 이번 한 번의 교체를 성공시키는 것보다, 다음 교체를 더 싸게 만드는 체계를 만드는 게 중요합니다. 샘플셋, 평가 리포트, 프롬프트 버전, human review 기준이 정리돼 있으면 이후 모델 비교 속도가 빨라집니다.
이 구조가 없으면 매번 새 모델이 나올 때마다 같은 논쟁을 다시 합니다. 결국 특정 벤더나 기존 프롬프트에 묶이게 됩니다. 반대로 비교 파이프라인이 있으면 벤더 락인 완화에도 도움이 됩니다.
지금 팀이 모델 교체를 준비 중이라면 아래 순서가 현실적입니다.
이 과정을 거치면 모델 교체가 감정적인 선호 싸움이 아니라 재현 가능한 운영 의사결정으로 바뀝니다.
LLM 시장은 계속 빨리 움직일 겁니다. 그래서 중요한 건 최고의 모델 하나를 고정하는 능력이 아니라, 업무 품질을 지키면서 교체할 수 있는 체계를 갖추는 능력입니다. AWS 글이 실무적으로 가치 있는 이유도 여기에 있습니다. 프롬프트 최적화 도구나 모델 카탈로그보다 먼저, 평가셋과 성공 기준을 운영 자산으로 만들라는 메시지이기 때문입니다.
좋은 마이그레이션은 새 모델이 더 똑똑하다는 걸 증명하는 작업이 아닙니다. 새 모델로 바꿔도 고객 경험과 운영 지표를 잃지 않는다는 걸 증명하는 작업입니다.
