33. 모델 이전(migration) 시 프롬프트 점검

이 장은 6부의 마지막이자, 이 안내서 전체를 관통해 온 한 가지 주제 — 모델은 변하고, 한 모델의 정답이 다른 모델에선 다를 수 있다(1·9장) — 를 실무 절차로 매듭짓습니다.

왜 모델을 바꾸면 점검이 필요한가

새 모델이 나오거나, 비용·성능을 위해 다른 모델로 갈아탈 때가 옵니다. 이때 흔한 착각은 "잘 쓰던 프롬프트니 새 모델에서도 잘 되겠지"입니다. 하지만 9장에서 봤듯, 한 모델에서 최적이던 프롬프트가 다른 모델에선 불필요하거나 역효과일 수 있습니다.

flowchart TB
    old["기존 모델용<br/>프롬프트 (검증됨)"] --> move["새 모델로 이전"]
    move --> q{"그대로 통할까?"}
    q -->|단정 금물| test["평가 세트로<br/>새 모델에서 재검증"]
    test --> adjust["차이 나는 부분만<br/>조정"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class old,move,adjust step
    class q dec
    class test good

무엇이 달라질 수 있나

⚠️ 흔한 실수·미신: "더 좋은(최신) 모델이니 모든 면에서 더 나을 것"이라는 가정은 위험합니다. 전반적으로 강력해도, 특정 프롬프트·특정 작업에서는 기존 모델보다 못한 결과가 나올 수 있습니다. 특히 기존 모델에 맞춰 미세 튜닝된 프롬프트일수록, 새 모델에서 그 튜닝이 안 맞을 수 있습니다. "전반적 향상 ≠ 모든 작업 향상"입니다.

안전한 이전 절차

평가(23장)가 여기서 진가를 발휘합니다. 평가 세트가 있으면 이전이 추측이 아니라 측정이 됩니다.

1. 평가 세트 준비. 대표 입력 + 기대 결과(23장). 없다면 지금이 만들 때입니다.

2. 기존 모델 기준선 기록. 현재 프롬프트를 기존 모델에 돌려 점수를 기록(비교 기준).

3. 새 모델에 그대로 돌리기. 프롬프트를 바꾸지 말고 먼저 새 모델에 같은 평가 세트를 돌립니다. 어디서 차이가 나는지 봅니다.

4. 차이 진단. 떨어진 항목이 어떤 유형인지 봅니다 — 형식 문제? 사실성? 분량? 거부? (위 표 참고)

5. 겨냥한 조정. 차이 나는 부분만 새 모델에 맞게 고칩니다. 예: 추론 모델로 옮겼으면 "단계별로" 제거(9장), 기본 간결 모델이면 "자세히" 추가(19장).

6. 재측정·반복. 조정 후 다시 평가. 기준선을 회복·초과할 때까지(30장 한 번에 하나).

[이전 점검 시트 예]
항목          기존모델   새모델(그대로)  새모델(조정후)
형식 준수율    95%        70% ⚠️         93%
분류 정확도    90%        88%            91%
분량 준수      90%        60% ⚠️         88%
→ 형식·분량에서 조정 필요했음

💡 팁: 새 모델 공식 문서의 프롬프팅 가이드와 마이그레이션 노트를 먼저 읽으세요. 제공자들은 보통 "이전 모델 대비 무엇이 달라졌고 무엇을 조정하라"를 안내합니다. 9장에서 본 "추론 모델엔 단계 지시 빼라" 같은 것이 거기 있습니다. 이 한 번의 읽기가 시행착오를 크게 줄입니다.

이전은 프롬프트를 단순화할 기회

흥미로운 역설: 새(더 똑똑한) 모델로 옮기면, 종종 프롬프트를 덜어낼 수 있습니다. 기존 모델을 위해 덧붙였던 보조 지시·과한 예시·단계 유도가 새 모델에선 불필요할 수 있기 때문입니다(3·17장 "더 똑똑한 모델일수록 덜 처방적").

🧪 직접 검증법: 이전하면서, 기존 프롬프트의 보조 장치(추가 예시, "단계별로", 과한 제약)를 하나씩 빼보며 평가하세요. 빼도 점수가 유지되면 그건 새 모델에 불필요한 군더더기였던 것입니다. 이전은 프롬프트를 군살 없이 다듬을 좋은 기회입니다.

운영 관점 — 이전을 상시 대비

🔧 개발자 노트: 모델 이전은 일회성 사건이 아니라 상시 대비할 운영 과제입니다 — ① 프로덕션은 특정 모델 스냅샷에 고정해 갑작스러운 동작 변화를 막고(22장), ② 평가 세트를 상시 유지해 새 모델이 나올 때 즉시 비교 가능하게, ③ 프롬프트를 버전 관리(30장)해 모델별 버전을 추적, ④ 이전 시 점진적 롤아웃(일부 트래픽부터)으로 위험 분산. "새 모델로 한 번에 전체 전환"은 검증되지 않은 변화에 베팅하는 것입니다.

안내서 전체를 관통한 주제의 매듭

1장에서 "마법 주문은 모델이 바뀌면 무력화된다"고 했고, 9장에서 "단계별로 생각해"의 반전을 봤고, 23장에서 "평가가 변화의 안전망"이라 했습니다. 이 모든 것이 한 곳으로 모입니다.

이 분야에 영원한 정답은 없다. 영원한 것은 원리(2장의 직관)와 검증(23장의 평가)이다.

기법은 모델과 함께 변하지만, "모델은 다음 토큰을 잇고, 컨텍스트가 전부이며, attention은 유한하다"는 원리는 남고, "내 작업에서 측정하라"는 검증의 자세는 어떤 모델에서도 유효합니다. 이 두 가지를 가지면, 다음에 어떤 모델이 나와도 스스로 다룰 수 있습니다.

📌 핵심: 특정 모델의 특정 기법을 외우는 사람은 모델이 바뀌면 길을 잃습니다. 원리를 이해하고 검증할 줄 아는 사람은 어떤 모델 앞에서도 적응합니다. 이 안내서가 전자가 아닌 후자를 목표한 이유입니다.

이 장에서 배운 것

• 잘 쓰던 프롬프트도 새 모델에서 그대로 통한다는 보장은 없다. 한 모델의 최적이 다른 모델엔 불필요·역효과일 수 있다.
• 달라질 수 있는 측면: 단계적 사고 필요성, 기본 분량, 지시 해석, 설정 권장값, 형식 준수, 거부 경향, 토큰·비용.
• "전반적 향상 ≠ 모든 작업 향상." 특히 기존 모델에 튜닝된 프롬프트일수록 재검증이 필요하다.
• 안전한 이전 절차: 평가 세트 준비 → 기존 기준선 → 새 모델에 그대로 → 차이 진단 → 겨냥 조정 → 재측정. 공식 마이그레이션 노트를 먼저 읽는다.
• 더 똑똑한 모델로의 이전은 프롬프트를 단순화할 기회다. 영원한 정답은 없고, 영원한 것은 원리와 검증이다.

✍️ 확인 문제

1. "최신 모델로 바꿨으니 기존 프롬프트가 다 더 잘 작동할 것"이라는 가정의 위험을, 9장의 사례를 들어 설명해보세요.

1. 모델 이전 시 평가 세트가 왜 "추측을 측정으로" 바꿔주는지, 안전한 이전 절차의 단계를 들어 설명해보세요.

1. (실습) 당신이 자주 쓰는 프롬프트 하나를 새 모델로 옮긴다고 가정하고, 이 장의 6단계 절차를 어떻게 적용할지 구체적으로 계획해보세요. (없다면 23장의 평가 세트부터)

다음 → 부록 (작성 예정)
이전 ← 32. 안전과 민감정보 주의 · 목차