모델 변경과 프롬프트 변화
모델 ID만 최신으로 바꿨는데 결과가 더 나빠지는 경험을 했다면, 버그가 아니다. 프롬프트를 그대로 둔 게 문제다.
2026년 상반기에 나온 Claude Opus 4.8과 GPT-5.5는 약속이라도 한 듯 같은 방향으로 진화했다. 그리고 두 회사 모두 공식 문서에서 비슷한 말을 한다 — “예전 프롬프트는 이제 오히려 방해가 된다.”
이 글의 테제는 하나다. 과정을 일일이 지시하던 시대가 끝났다. 이제는 목적지와 제약만 정의하고, 과정은 모델에게 맡긴다. 그게 안 되는 사람은 더 똑똑해진 모델에서 더 나쁜 결과를 받는다.
두 모델이 향한 같은 방향
먼저 큰 그림. 두 모델의 공식 가이드를 나란히 놓으면 거의 같은 문장이 나온다.
- OpenAI (GPT-5.5): “목적지를 묘사하라. 모델이 갈 길을 일일이 포장하지 마라(describe the destination, don’t pave every step).”
- Anthropic (Opus 4.8): “이 모델은 이전 어떤 Opus보다 지시를 문자 그대로(literally) 따른다. 모든 항목에 적용되는 규칙이면 그렇다고 말하고, 제안이 아니라 구현을 원하면 그렇다고 말하라.”
표현은 다르지만 본질은 같다. 모델이 충분히 똑똑해지면, 과정을 지시하는 말은 도움이 아니라 노이즈가 된다. 예전 모델은 길을 잃지 않게 손을 잡아줘야 했다. 지금 모델은 손을 잡으면 오히려 끌려다닌다.
Opus 4.8: 다이얼이 프롬프트를 대체한다
Opus 4.8은 4.7 위에 쌓은 모델이다. 기본 1M 토큰 컨텍스트, 최대 128k 출력, 가격은 4.7과 동일($5/$25 per M). 벤치마크 숫자보다 중요한 건 제어 방식이 바뀌었다는 것이다.
effort가 핵심 다이얼이 됐다. 기본값은 모든 표면(API·Claude Code)에서 high. 그런데 이 모델은 effort를 엄격하게 지킨다. low·medium에서는 “시킨 것만” 하고 알아서 더 해주지 않는다. Anthropic의 권고는 보수적이다 — 코딩·에이전트 작업은 xhigh로 시작하고, 나머지는 high, 측정으로 품질이 유지되는 게 확인되면 그때 낮춰라. 예전엔 “철저하게 분석해줘” 같은 말로 노력의 양을 조절했다면, 이제는 파라미터로 조절한다.
Adaptive thinking이 유일한 사고 모드다. budget_tokens로 사고량을 숫자로 박는 건 이제 400 에러다. 대신 thinking: {type: "adaptive"}를 켜면 모델이 턴마다 “지금 생각이 필요한가?”를 스스로 판단한다. 단순 조회엔 바로 답하고, 복잡한 문제엔 추론한다. 같은 effort에서 4.7보다 낭비되는 사고 토큰이 줄었다. 참고로 temperature·top_p·top_k도 여전히 지원하지 않는다(400). 샘플링을 만지던 습관 대신 프롬프트로 행동을 유도해야 한다.
그 외 실무에서 체감되는 변화들:
- 문자 그대로 따른다(literalness). 특히 낮은 effort에서 더 그렇다. 모호하게 두면 모호하게 처리한다. “필요하면 도구를 써”가 아니라 “언제, 왜 이 도구를 써야 하는지”를 명시해야 한다.
- 도구 호출을 덜 빼먹는다. 4.7에서 “분명히 도구를 써야 하는데 안 쓴다”는 불만이 있었는데, 그게 개선됐다.
- Mid-conversation 시스템 메시지. 긴 대화 중간에
role: "system"을 끼워 넣어 지시를 갱신할 수 있다. 전체 시스템 프롬프트를 다시 안 보내도 되니 앞쪽 프롬프트 캐시가 살아 있다. - 정직성. 코드 결함을 못 보고 넘어갈 확률이 전작 대비 약 4배 낮다. 코드 리뷰를 시킬 때 체감되는 부분이다.
- Dynamic workflows(Claude Code 리서치 프리뷰). 수백 개 서브에이전트를 병렬로 돌려 코드베이스 마이그레이션 같은 대규모 작업을 처리한다.
GPT-5.5: 공식 가이드가 명시한 6가지 변화
OpenAI는 더 직접적이다. GPT-5.5 프롬프트 가이드는 “예전 프롬프트를 다시 써야 한다”며 6가지를 짚는다.
- 결과 중심으로. “먼저 분석하고, 그다음 분해하고, 그다음 실행해”가 아니라 “문제를 설명하고 최소 수정 경로를 제시하는 실행 가능한 계획을 내놔”라고 쓴다.
- 과정 명세를 줄여라. 통제 가치가 없는 단계는 노이즈다. 가이드는 5가지 노이즈를 지목한다 — 일반적 절차 나열, ALWAYS/NEVER 같은 절대어, 페르소나 반복 선언, 장식적 출력 요구, 하드코딩된 도구 순서.
- 성공 기준을 명시하라. 완료 조건이 암묵적이면 강한 모델도 입력마다 결과가 출렁인다. “핵심 요구를 다 다뤘는가, 결론이 근거로 뒷받침되는가, 형식이 맞는가, 막힌 지점을 나열했는가”를 명시한다.
- reasoning effort를 재평가하라. 무조건 최고로 두지 마라. GPT-5.4에서
high가 필요했던 작업이 5.5에선medium이면 충분할 수 있다. 분류·추출은low부터. - 도구 경계는 유지하되 군더더기는 빼라. 보안·데이터·비용 관련 규칙, 확인 요구, 실패 복구, 중단 조건은 남긴다. 중복된 절차 단계만 지운다.
- 출력 계약을 정의하라. 일반적 포맷팅이 아니라 실제 사용 시나리오에 맞춰 필드·타입·검증 규칙을 구조화한다.
여기에 더해 가이드가 “이제 버리라”고 한 옛 습관들:
- 역할극은 한물갔다. “당신은 20년 경력의 카피라이터입니다”는 GPT-4 시절엔 필요한 발판이었지만, 지금은 모델이 본 요청에 도달하기 전에 해석해야 할 모호함만 더한다.
- “단계별로 생각해”는 도움이 안 된다. GPT-5.5는 구조적 추론을 네이티브로 한다. 이 문구를 빼면 오히려 결과가 좋아진다.
- Few-shot이 역효과다. 잘 정의된 작업은 zero-shot 성능이 충분히 강하다. 예시를 넣으면 모델이 그 스타일·구조에 닻을 내려 다양성이 줄어든다.
- 제약 반복하지 마라. 한 번 명확히 말하면 된다.
- 시스템 프롬프트 = 행동, 유저 턴 = 작업. 페르소나·포맷·제약은 시스템에, 구체적 과제는 유저 턴에.
가이드가 든 예시가 모든 걸 요약한다:
1
2
3
4
5
6
[Old] "당신은 B2B 카피라이터 전문가입니다... 콜드 이메일을 쓰세요...
기억하세요, 목표는 미팅을 잡는 것이지 파는 게 아닙니다..."
[New] "마케팅 VP에게 보낼 콜드 이메일을 작성하라.
목표: 20분 디스커버리 콜 예약. 길이: 120단어 이내.
포함: 구체적 페인포인트 1개."
역할극을 지우고, 목표 반복을 빼고, GPT-5.5가 확실히 따르는 정밀한 명세를 더했다. 그리고 GPT-5.5는 기본적으로 간결·직설적이다. 고객 응대처럼 따뜻함이 필요한 곳에선 그 톤을 명시적으로 요구해야 한다.
왜 이렇게 바뀌었나
이게 핵심이다. 두 회사가 동시에 같은 말을 하는 데는 이유가 있다.
예전 프롬프트 테크닉의 90%는 모델의 약점을 보완하는 보철물이었다. “단계별로 생각해”는 모델이 추론을 건너뛰던 시절의 처방이었다. 역할극은 모델에게 맥락의 무게를 실어주는 트릭이었다. Few-shot은 모델이 작업을 이해 못 할까 봐 깔아주던 본보기였다. 절차 나열은 모델이 중간에 길을 잃을까 봐 깔아준 레일이었다.
모델이 그 약점을 극복하면, 보철물은 남아서 방해한다. GPT-5.5 가이드의 표현을 빌리면 “과도한 명세는 검색 공간을 좁힌다(over-specification shrinks search space).” 모델이 1000가지 좋은 해법을 찾을 수 있는데, 내가 깔아둔 5단계 절차가 그걸 1가지 평범한 경로로 가둬버린다. 결과는 더 똑똑한 모델에서 더 기계적인 답.
그래서 제어의 무게중심이 옮겨갔다. “과정에 대한 산문 지시”에서 “결과+제약 정의 + 구조화된 파라미터”로. Opus의 effort/adaptive thinking 다이얼이 정확히 이 자리를 차지한다. 예전엔 프롬프트 문장으로 노력의 양을 조절했지만, 이제는 다이얼로 조절하고 프롬프트는 목적지를 가리키는 데만 쓴다.
이건 블로그 #14에서 다룬 “에이전트 엔지니어링”의 연장선이다. 모델이 올라갈수록 사람이 설계하는 건 모델 내부가 아니라 그 바깥의 계약 — 목표, 제약, 성공 기준, 도구 경계 — 으로 옮겨간다.
그래서 어떻게 바꿔야 하나
기존 프롬프트를 두 모델 중 하나로 옮긴다면, 이 순서로 손본다.
1. 지운다 (둘 다 공통)
- “단계별로 생각해”, “심호흡하고”, “전문가처럼” 같은 주문(呪文)
- “당신은 N년 경력의 ___입니다” 역할극 도입부
- 통제 가치 없는 절차 나열, 하드코딩된 도구 순서
- 같은 제약의 반복 진술
- 잘 정의된 작업에 붙은 few-shot 예시 (스타일을 강제하려는 의도가 아니라면)
2. 더한다 (둘 다 공통)
- 결과물과 성공 기준을 맨 앞에 한 문단으로
- 출력 계약: 형식·필드·길이를 구체적 숫자로 (“짧게”가 아니라 “120단어 이내”)
- 도구 경계: 언제/왜 쓰는지, 확인이 필요한 파괴적 작업, 중단 조건
3. 다이얼을 잡는다 (모델별)
- Opus 4.8: effort를 능동적으로 실험하라. 코딩은
xhigh에서 시작해 측정 후 내린다. 추론이 필요하면thinking: {type: "adaptive"}를 켠다.temperature만지던 코드는 제거. - GPT-5.5: reasoning effort를 재평가하라. 옛 모델에서
high였던 게medium으로 충분한지 실제 샘플로 테스트. 분류·추출은low부터.
4. 재측정한다 모델 업그레이드는 “ID만 바꾸는 작업”이 아니다. effort·thinking·캐싱·프롬프트 동작을 다시 베이스라인 잡는 작업이다. 바뀐 프롬프트를 스테이징에서 돌려보고, 예전 출력과 나란히 비교한 다음 배포한다.
마무리
재밌는 역설이 하나 있다. 모델이 똑똑해질수록 프롬프트는 짧고 비어 보인다. 화려한 역할극과 정교한 단계 지시가 사라진 자리에는 “무엇을, 어떤 제약 안에서, 어떤 기준으로”만 남는다.
좋은 프롬프트가 정교한 마법 주문처럼 보이던 시절은 끝나가고 있다. 이제 좋은 프롬프트는 잘 쓴 업무 지시서를 닮았다. 목적지를 분명히 하고, 제약을 명시하고, 나머지는 유능한 사람에게 맡기는 것. Opus 4.8과 GPT-5.5가 우리에게 요구하는 건 더 정교한 프롬프트 기술이 아니라, 더 명확한 사고다.
참고: Anthropic — What’s new in Claude Opus 4.8, Introducing Claude Opus 4.8, OpenAI — GPT-5.5 prompting guide
추가 정리
핵심 요약
모델이 바뀌면 프롬프트도 바뀌어야 한다. 최신 모델일수록 단순한 자연어 지시보다 effort, tool policy, output contract, context structure 같은 제어 요소가 중요해진다.
보충 해설
프롬프트는 더 이상 문장력만의 문제가 아니다. 모델이 얼마나 깊게 생각해야 하는지, 어떤 도구를 언제 써야 하는지, 어떤 형식으로 답해야 하는지, 어떤 기준으로 멈춰야 하는지를 명시해야 한다. 모델 변경 후 품질이 떨어졌다면 프롬프트가 이전 모델의 행동 방식에 맞춰져 있는지 확인해야 한다.