#36에서 모델 이사를 다뤘을 때의 전제는 “이사는 가끔 오는 이벤트”였다. #40에서 Opus 5 프롬프트 마이그레이션을 정리할 때도 마찬가지였다 — 큰 모델이 나왔으니 한 번 옮기자는 얘기. 그런데 이 전제가 틀렸다면 어떻게 되나. 이사가 이벤트가 아니라 주기라면, “어떻게 옮기나”보다 앞서는 질문이 생긴다. 애초에 무엇을 갖고 무엇을 버릴 것인가.
이번 글의 테제는 한 문장이다. 프롬프트와 하네스는 빌린 모델 위에 지은 인테리어라 모델과 함께 감가상각되고 남는 자산은 eval·스키마·spec이다. 투자를 후자로 옮기는 것이 “모델이 바뀌어도 살아남는 개발”의 전부다.
수명부터 재보자 — 감가상각 주기 1년
3사의 deprecation 페이지를 놓고 계산해보면:
- Anthropic: Claude Opus 4는 출시 후 약 13개월, Sonnet 3.7은 정확히 12개월 만에 retire됐다. 공개 모델의 통지 의무는 최소 60일.
- OpenAI: GA 모델의 통지 의무는 최소 6개월. gpt-5-chat과 gpt-5-codex는 1년을 못 채우고 종료됐고 모델만이 아니라 API 표면 자체도 이사 대상이다 — Assistants API가 2026년 8월에 통째로 내려간다.
- Google: preview 모델은 2.5개월 만에 종료된 사례가 있고 GA는 12~16개월. 특히 아픈 건 임베딩 모델 종료다. text-embedding-004가 올해 1월에 내려갔는데, 임베딩 모델의 은퇴는 프롬프트 수정이 아니라 인덱스 전체 재구축을 강제한다.
정리하면 GA 모델의 실수명은 12~16개월. 프롬프트 자산의 감가상각 주기가 사실상 1년이라는 뜻이다. 그리고 3사가 같은 방향으로 수렴 중이라는 것도 수치만큼 중요하다. temperature·top_p 같은 샘플링 파라미터를 없애고(Opus 4.7+에서는 400 에러다), assistant prefill을 막고 thinking/effort 체계로 통일하고 있다. 더 흥미로운 건 3사 모두 마이그레이션 자동화 에이전트를 내놨다는 사실이다 — Anthropic의 /claude-api migrate, OpenAI Codex의 마이그레이션 스킬, Google Antigravity. “모델 교체 = 프롬프트 재작업”을 벤더 스스로 제품으로 인정한 셈이다.
이사는 더하기가 아니라 빼기다
마이그레이션이라고 하면 새 모델에 맞춰 뭔가를 더 써넣는 그림을 떠올리기 쉬운데, 2026년의 벤더 문서들은 반대를 말한다. Anthropic의 Opus 5 프롬프팅 문서는 “답을 다시 확인하라” 같은 검증 지시를 제거하라고 권고한다. 모델의 자체 행동과 중첩돼 비용만 늘고 품질은 안 오른다는 것이다. Fable 5 문서는 더 직설적이다 — “이전 모델용으로 개발된 스킬은 지나치게 처방적이어서 출력 품질을 떨어뜨릴 수 있다.” OpenAI도 같은 얘기를 수치로 한다. GPT-5.6 프롬프트 가이드의 내부 테스트에서 군살을 뺀 프롬프트가 평가 점수를 10~15% 올리면서 토큰은 41~66%를 줄였다. GPT-5.5 때는 아예 “기존 프롬프트 스택을 이관하지 말고 백지 베이스라인에서 다시 시작하라“고 권고했다.
이유는 단순하다. 프롬프트의 상당 부분은 태스크 명세가 아니라 그 시점 모델의 약점을 메우는 보정 코드다. 단계별로 생각하라는 지시, 반드시 검증하라는 지시, ALWAYS와 NEVER로 도배된 규칙 — 전부 구모델이 못 하던 것을 시키는 목발이었다. 모델이 그걸 스스로 하게 되는 순간 목발은 짐이 된다. 한 실무자의 표현을 빌리면, “구모델의 약점을 보완하려고 지은 비계가, 신모델의 강점을 누리지 못하게 막는 바로 그 물건이 된다.”
실제 사고 사례도 7월에 나왔다. Every의 성숙한 다단계 에이전트 워크플로가 Opus 5에서 조기 종료와 과잉 검증으로 무너진 리뷰가 올라왔는데, 결론 문장이 이 글의 논지 그대로다 — “모델이 더 강해져도, 전임자에 맞춰 설계된 시스템 안에서는 더 나빠질 수 있다.” 다른 분석에서는 22단계짜리 정교한 마이그레이션 프롬프트를 준 경우와 목표·제약만 준 경우를 비교했는데, 후자가 이겼다. 모델이 사용자의 틀린 3단계까지 충실히 따라주는 게 문제였다.
한 가지 덜 알려진 각도 — 이건 보안 문제이기도 하다. Promptfoo의 실측에서 GPT-4o를 4.1로 올리기만 했는데 prompt injection 저항이 94%에서 71%로 떨어졌다. 신모델이 “지시를 더 문자 그대로 따르도록” 학습된 것이 원인이다. 능력 향상이 곧 공격면이 된 경우로, 모델 교체를 보안 이벤트로 취급해야 하는 이유다.
이름이 생겼다 — Model Drifting
프롬프트가 모델 간에 이식되지 않는다는 건 학계에선 꽤 쌓인 얘기다. 원점 격인 2023년 FormatSpread 연구는 프롬프트 포맷 변형만으로 정확도가 최대 76%p 벌어진다는 것과 함께 더 중요한 문장을 남겼다 — “포맷 성능은 모델 간 상관이 약하다.” 한 모델에서 좋은 포맷이 다른 모델에서 좋을 이유가 없다는 뜻이다. 작년 10월에는 in-context 예시의 구분자 한 글자로 MMLU 점수가 ±23% 흔들린다는 후속이 나왔다. 공정하게 말하면 반론도 있다 — 민감도의 상당 부분은 모델 결함이 아니라 평가 방법의 아티팩트라는 분석인데, LLM-as-Judge로 채점을 바꾸면 분산이 크게 준다. 민감도 전부가 모델 탓은 아니라는 단서는 달아두자.
그래도 방향은 분명하고 작년 12월에 이 현상은 이름을 얻었다. PromptBridge 논문이 한 모델용으로 최적화한 프롬프트를 다른 모델에 옮기면 성능이 무너지는 현상을 “Model Drifting”이라고 명명하고 소량의 캘리브레이션 데이터로 프롬프트를 대상 모델에 맞게 변환하는 프레임워크를 제안했다. 프롬프트 이식 실패가 정식 연구 대상이 됐다.
에이전트로 올라가면 층이 하나 더 생긴다. 하네스(#35)다. 올해 5월의 한 포지션 페이퍼는 제목부터 도발적인데 — “하네스를 공개하지 않고 에이전트를 비교하지 말라” — 장기 태스크에서는 하네스가 유발하는 성능 분산이 모델이 유발하는 분산을 초과하고 하네스에 따라 모델 순위가 역전되는 사례까지 제시한다. 다른 실험은 스캐폴딩 컴포넌트를 쌓을수록 상호 간섭으로 오히려 나빠질 수 있고 최적 조합이 모델 크기에 따라 다르다는 것을 보였다. METR조차 평가 인프라의 스캐폴드를 교체했더니 같은 모델의 점수가 유의미하게 달라졌다고 적었다. 성능은 모델-하네스 조합의 속성이라는 얘기가 반복해서 나오고 있다.
그리고 “더 좋은 모델”이라는 말 자체를 의심해야 한다. ReCatcher 연구에서 GPT-4o는 전반적으로 3.5-turbo보다 낫지만 missing import 처리 같은 특정 축에서는 최대 50% 후퇴했다. 상위 호환은 없다. 모델 교체는 회귀 테스트 대상이다.
무엇을 소유할 것인가
여기까지가 문제라면, 답의 방향을 제일 잘 압축한 문장은 올해 6월에 나왔다. “모델은 빌린 것이다. eval은 내 것이다(The model is rented. The eval is owned).” Adnan Masood의 글인데, 논지는 이렇다. 모델은 누구나 같은 값에 빌려 쓰는 임차물이라 경쟁력이 아니고 자사 데이터와 비즈니스 로직으로 만든 eval 체계 — “우리 도메인에서 좋음이 무엇인지”의 정의 — 만이 모방 불가능한 자산이다. Forbes의 같은 달 칼럼도 같은 지점을 짚는다 — “프롬프트 하나, 모델 업데이트 하나로 체인 전체가 조용히 무너진다.” 그 조용한 붕괴를 소리 나게 만드는 장치가 eval이다.
이게 관념론이 아니라는 걸 보여주는 회사 사례가 7월에 나왔다. Ploy AI의 GPT-5.6 마이그레이션기인데, 이 팀은 4개월간 신모델이 나올 때마다 자사 eval을 돌렸고 어떤 모델도 기존 구성을 못 이겨서 안 옮겼다. GPT-5.6이 처음으로 이기자 그때 옮겼다 — 판단 근거는 자기 eval suite였다. 디테일 하나가 특히 교훈적이다. 첫 실행에서 나온 실패의 3분의 1은 모델 탓이 아니라 하네스의 낡은 가정 탓이었다. 그래서 이 팀의 마이그레이션 절차는 Step 0이 “평가 도구 자체 검증”이다. eval 실무를 어떻게 세우는지는 #32와 평가 파이프라인 가이드에서 다뤘으니 여기선 반복하지 않는다. 요지는 하나 — eval은 품질 개선 도구이기 전에 마이그레이션 보험이다.
시장도 같은 방향으로 움직였다. 올해 1월 ClickHouse가 프롬프트 관리·평가 플랫폼 Langfuse를 인수했고, 2월 Braintrust가 8천만 달러 시리즈 B를 받았다. 프롬프트·eval 인프라가 데이터 인프라 회사가 인수할 만큼 자산으로 취급되기 시작했다.
eval 옆에 놓을 자산이 둘 더 있다. 하나는 계약(contract)이다. structured output 스키마, 도구 정의, 출력 검증기 — 모델과 무관하게 코드 레벨에서 강제되는 것들. 프롬프트로 형식을 애원하는 대신 스키마로 강제하면, 그 계약을 통과하는지 자체가 신모델 적합성 테스트가 된다. 다른 하나는 spec이다. GitHub Spec Kit이 스타 12만을 넘겼고 AWS Kiro는 올해 상반기에 spec 기능을 고도화하면서 밑의 모델을 Sonnet 5, GPT-5.6, Opus 5로 연달아 갈아끼웠다. 명세는 그대로 두고 모델만 교체하는 흐름이 이미 제품 형태로 돌아가고 있다. 요구사항이 소스고 코드와 프롬프트가 산출물이라면, 산출물의 감가상각은 두렵지 않다.
프롬프트를 컴파일하다
한 발 더 나가면, 프롬프트를 사람이 다시 쓰는 것조차 그만둘 수 있다. DSPy의 관점이 그것이다 — 프롬프트는 소스 코드가 아니라 컴파일 결과물이고 소스는 태스크 시그니처와 평가 지표다. 모델이 바뀌면 재컴파일하면 된다. 이 관점의 최적화 엔진이 작년에 크게 발전했는데, GEPA는 실행 기록에 대한 자연어 성찰로 프롬프트를 진화시켜서 가중치를 건드리는 강화학습(GRPO)을 평균 6%, 최대 20% 앞섰다. rollout은 35분의 1만 쓰면서.
실무 사례도 있다. DSPy 공식 사례 페이지에 올라온 것 중 이 글의 주제에 정확히 맞는 건 AWS다 — 큰 모델용 프롬프트를 작은 Nova 모델로 옮기면서 성능을 유지해야 했는데, 손으로 다시 쓰는 대신 재컴파일로 해결했다. 앞서 본 3사의 마이그레이션 자동화 에이전트, PromptBridge의 캘리브레이션 변환, DSPy·GEPA의 재컴파일 — 도구는 다르지만 전부 같은 그림이다. 프롬프트 적응을 사람 손에서 파이프라인으로 옮기는 것.
실전: 모델 종속부를 싸게 만드는 여섯 가지
- 동결된 eval 베이스라인 없이 모델을 바꾸지 않는다. 평가셋 하나를 고정하고 현재 구성의 성적을 기록해둔다. 이게 없으면 마이그레이션은 감으로 하는 전면 재작성이 되고, 있으면 diff 보고 깨진 케이스만 고치는 기계적 작업이 된다.
- 프롬프트를 코드에서 분리하고 버전을 붙인다. 프롬프트가 코드 문자열에 박혀 있으면 모델 교체가 코드 배포가 된다. (프롬프트 버전 × 모델 버전) 조합으로 eval 결과를 기록하면 롤백과 A/B가 공짜가 된다.
- 형식은 프롬프트가 아니라 계약으로 강제한다. structured output 스키마, 도구 시그니처, 코드 레벨 검증기. 모델이 바뀌어도 계약은 안 바뀌고 계약 통과 여부가 적합성 테스트가 된다.
- 마이그레이션의 첫 질문은 “뭘 지우나”다. 검증 지시, ALWAYS/NEVER 규칙, 단계별 절차 — 구모델용 목발부터 걷어내고 최소 프롬프트로 베이스라인을 잡은 뒤에 필요한 것만 되살린다. 단, 안전·컴플라이언스 규칙은 명시적으로 보존한다.
- 정확도만 재지 않는다. 토큰 수(Opus 5는 토크나이저 변경만으로 최대 35% 증가), 지연, 거부율, 도구 호출률, 그리고 injection 저항까지. 한 축이 오르고 다른 축이 내려앉는 게 기본값이다.
- deprecation 캘린더를 CI에 넣는다. 은퇴 예정 모델 ID를 자동 감사하고 교체는 canary→단계 롤아웃으로. Bedrock·Vertex 같은 재판매 경로는 별도 캘린더가 돈다는 것도 잊지 말 것.
관전 포인트
비계 무용론의 극단에는 “하네스는 90일짜리 산출물”이라는 표현까지 나와 있다. Browser Use 창업자는 “덜 지을수록 잘 돌아간다”고 썼고 You.com CTO는 2024년식 오케스트레이션이 이제 부채라고 말한다. Anthropic이 Fable 5 발표에서 굳이 “보조 도구를 얹어도 못 깨던 Pokémon을 최소 하네스로 깼다”고 자랑한 것도 같은 서사다. 반대편에서 프레임워크 진영은 하네스(제어)와 컴퓨트(실행)를 분리하는 식으로 — 모델을 갈아끼워도 하네스가 살아남게 — 구조로 응답하는 중이다. 어느 쪽이 이기든, “모델에 밀착한 코드일수록 수명이 짧다”는 전제는 양쪽이 공유한다.
프론트엔드가 좋은 비유다. 브라우저는 계속 바뀌고 아무도 그걸 불평하며 개발을 멈추지 않는다. 버틸 수 있는 이유는 테스트 매트릭스와 표준 계약이 있어서다. LLM 개발도 같은 지점으로 가고 있다 — 모델은 런타임이고 런타임은 원래 갈아탄다.
다음 모델 발표가 나는 날, 두 부류의 팀이 있을 것이다. 프롬프트를 열어놓고 어디가 깨질지 짐작하는 팀과, eval을 돌리고 diff를 읽는 팀. 그 차이는 그날 만들어지는 게 아니라 오늘 만들어진다.