개요

Claude Opus 4.6/4.7 / 4.8이나 GPT 5.5에서는 각 사가 제시하는 권장 프롬프트(Prompt) 형식이 상당히 다릅니다. 이 기사에서는 공식 문서와 관련 논문을 바탕으로, 각 모델별 프롬프트 작성 방식을 정리합니다.

먼저 결론

잘 모르겠다면 우선 Opus 4.6을 선택해 두면 실패할 확률은 적을 것이라 생각합니다.

다만 Opus 4.6 이전과 그 이후의 모델(4.7/4.8/GPT 5.5) 사이에서는 프롬프트 처리의 성질이 확연히 달라지므로, 그 점을 향후 의식하는 것이 더 높은 퍼포먼스를 내는 데 도움이 될 것입니다.

먼저 결론 2

Opus 4.6 이전과 그 이후의 모델 사이에서 기존의 상식이 완전히 바뀌었습니다.

부족한 컨텍스트(Context) 정보를 추론(Inference)으로 보완하던 것이 4.6 이전의 방식입니다.

이는 장점이기도 했지만, 단점이기도 했습니다.

지시한 것 이외의 능력까지 파악하려다 보니, 지시 이행 성능(Instruction Following)의 저하로 이어지기도 했습니다.

이를 개선한 것이 4.7이나 5.5입니다.

진화한 방향성은 상당히 다르지만, 두 모델에 공통적으로 말할 수 있는 점은 "기존의 프롬프트 작성 방식은 통하지 않게 된다"는 점입니다.

인터넷이나 X(구 Twitter)에서 Opus 4.7은 성능이 떨어졌다는 말이 자주 나오는 것은, 이러한 권장 프롬프트 형식의 변화 때문인 경우가 크며, 이를 인지하지 못한 채 사용하고 있는 사람들이 많기 때문인 것으로 보입니다.

• Anthropic
• OpenAI

앞으로도 이 두 회사의 모델을 계속 사용한다면, 기존의 "알아서 잘해줘"형 프롬프트뿐만 아니라, 새로운 작성 방식에 익숙해지는 것이 좋을 것 같습니다.

Opus 4.6: 기존의 상담형 프롬프트가 잘 통함

Opus 4.6은 기존 Claude다운 "함께 고민해 주는" 느낌이 강한 모델입니다.

예를 들어, 다음과 같은 의뢰입니다.

이 구현, 좀 수상하니 확인해 주세요.
필요하다면 테스트 관점도 포함해서 수정 방안을 제안해 주세요.

이러한 작성 방식에서도 이전의 대화 내용이나 전후 문맥을 보고 의도를 보완해 주는 경우가 많습니다. 무엇이 필요한지를 모델 내부에서 추론을 거듭하고 추측함으로써 더 나은 답변을 이끌어내려 합니다. 이는 매우 편리한 점입니다.

코드 리뷰, 설계 상담, 기사 구성, 사양 검토(Wall-hitting)와 같은 모든 작업에서 이러한 모호함을 포함한 채로 상담할 수 있습니다. AI에 익숙하지 않은 사람에게는 이 방식이 더 유용할 것입니다.

반면, 단점도 있습니다. 의도를 보완해 준다는 것은, 사용자가 명시하지 않은 범위까지 그 해석의 의도를 확장할 가능성이 있다는 뜻입니다.

이 테스트 주변을 정리해 줘

라고 부탁했을 때, 오래된 fixture뿐만 아니라 명명 규칙(Naming)이나 주변 설계까지 건드릴 수도 있습니다.

rules나 hooks로 행동을 제약할 수는 있겠지만, 불확정성과 관련되는 것은 분명합니다.

Opus 4.7 / 4.8: 사양 명시형에 가까움

Opus 4.7에서 크게 변한 것은 지시의 해석입니다.

Anthropic의 Migration guide에서는 Opus 4.7에 대해 다음과 같이 설명하고 있습니다.

Claude Opus 4.7 interprets prompts more literally and explicitly than Claude Opus 4.6.

(Claude Opus 4.7은 Claude Opus 4.6보다 프롬프트를 문자 그대로, 그리고 더 명확하게 해석한다)

나아가

• 적혀 있지 않은 요구사항을 추측하지 않는다
• 특정 항목에 대한 지시를 다른 항목으로 멋대로 일반화하지 않는다

와 같은 설명도 있습니다.

흔히 Opus 4.6과 4.7을 비교하며 "답변 내용이 무미건조/차가워졌다", "성능이 저하되었다"라고 말하는 사람들도 있지만, 이는 이러한 변경점을 의식하지 않고 사용하기 때문에 퍼포먼스를 제대로 활용하지 못하고 있는 것이라 생각됩니다.

모호한 보완보다는 견실함을 중시하는 사상으로 시프트(Shift)했다고 할 수 있지 않을까요?

어쨌든, 이러한 상세 내용은 Claude Code 공식에서 제공하는 마이그레이션 가이드의 [파괴적 변경(Breaking Changes)] 항목에 자세히 적혀 있습니다.

Opus 4.7(4.8)의 권장 프롬프트에 대하여

특정 함수의 수정을 지시하고 싶을 때.

4.7(4.8)에서는 다음과 같은 작성 방식이 더 적합합니다.

대상:
- 대상 함수의 경로 및 위치
요건:
...

「적당히」와 같은 모호함에 의존하는 것이 아니라,

그 시점의 스코프 (Scope), 요건 (Requirements), 제약 (Constraints), 수락 조건 (Acceptance Criteria) 등을 상세하게 작성하는 것이 포인트입니다.

역으로 말하면, 위와 같이 상세하게 작성하지 않을 거라면 Opus 4.6이 더 낫습니다.

GPT 5.5: 목표 설정형

GPT 5.5에 대해 OpenAI의 문서에서 특히 중요한 것은 outcome-first prompts입니다.

OpenAI의 설명에 따르면, GPT 5.5는 명확한 목표로부터 작업을 진행하고, 제약을 유지하며, 제품의 의도를 구체적인 다음 단계로 변환하는 데 능숙하다고 합니다.

즉, 목표 설정만은 어떻게든 해야 한다는 것입니다.

경로상의 세부적인 사항 등은 AI가 판단하게 하는 것이 더 잘 풀린다는 사상입니다.

오히려 정확한 절차가 필요한 경우를 제외하고는, 세세한 step-by-step 프로세스 지시는 줄이는 것이 권장됩니다.

GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path.

(GPT-5.5는, 프롬프트로 결과(Outcome)를 명확히 제시하고, 모델이 효율적인 해결책을 선택할 수 있는 여지를 남겨둘 때 가장 효과를 발휘합니다)

예를 들면 다음과 같습니다.

Goal:
회계 로직을 처리하기 위한 함수를 완성한다.
Success criteria:
...

이는 Opus 4.7 / 4.8을 위한 「대상, 제약, 수락 조건을 엄격하게 작성하는」 프롬프트와 비슷하지만, 초점이 약간 다릅니다.

Claude 4.7 / 4.8용은 작업 범위나 금지 사항을 상당히 명시합니다.

GPT 5.5용은 달성해야 할 상태를 정의하고, 그곳으로 가는 경로는 모델에 맡기는 방식입니다.

GPT 5.5에 대해서는 「이 순서로 이렇게 해줘」보다는,

「최종적으로 무엇이 충족되어야 성공인가」를 목표로 제시하는 것이 적합합니다.

이 차이는 상당히 큽니다.

구체적인 예시

여기서는 엔지니어를 위해 작은 예시로 살펴보겠습니다.

주제는 HTTP의 Retry-After 헤더를 다루는 함수입니다.

Retry-After는 사양상 크게 다음 두 가지 종류가 있습니다.

Retry-After: 120
Retry-After: Wed, 21 Oct 2015 07:28:00 GMT

숫자라면 초 단위로, HTTP-date라면 현재 시각과의 차이로 취급한다는 작은 구현입니다.

단, 실무에서는 잘못된 값, 빈 문자열, 음수, 과거 일시 등의 처리도 필요합니다.

기존 코드를 다음과 같이 둡니다.

function parseRetryAfter(value: string | null): number | null {
if (!value) return null;
return Number(value);
...

이 동일한 태스크라도 모델마다 전달 방식을 바꾸는 것이 좋아 보입니다.

Opus 4.6용: 상담형

이 Retry-After 헤더의 파싱 처리가 조금 불안합니다.
function parseRetryAfter(value: string | null): number | null {
if (!value) return null;
...

4.6에서는 모호함을 남겨두고 상담하는 형태가 사용하기 쉽습니다.

여러 번의 채팅을 통해 조금씩 컨텍스트 (Context)를 모음으로써 정밀도를 높이게 합니다.

프롬프트에 모호함이 남아 있더라도, AI에 익숙하지 않은 사람에게는 오히려 그 편이 품질을 향상시킵니다.

Opus 4.7 / 4.8용: 사양 명시형

다음 함수만 수정해 주세요.
대상:
- parseRetryAfter 함수만
...

4.7 / 4.8에서는 모호한 기대를 분위기로 파악하게 하기보다, 조건을 명시하는 것이 적합합니다.

특히 4.7은 공식적으로 「더 literal (직역적인/문자 그대로의)」하다고 설명되어 있습니다.

즉, 이쪽에서 쓰지 않은 암묵적인 기대는 이전보다 포착되지 않을 가능성이 있습니다.

GPT 5.5용: 목표 설정형

Goal:
Retry-After 헤더를 안전하게 다룰 수 있는 작은 유틸리티를 완성한다.
Context:
...

(여기까지 상세히 쓸 필요는 없다고 생각합니다만) GPT 5.5에서는 구현 절차를 상세히 지정하기보다, 목표와 성공 조건을 전달하는 것이 공식 권장 사항에 가깝습니다. 최선의 경로는 모델 스스로가 생각할 것입니다.

요약

현재 시점에서 자신의 작업 내에서 고민이 된다면 Opus 4.6을 선택하는 것이 상당히 현실적입니다.

모호한 상담에 강하며, 페어 프로그래밍 (Pair Programming) 방식으로 다루기 쉽기 때문입니다.

우선 아이디어를 던져보고 (Wall-hitting), 도중에 인간이 방향을 수정하는 방식의 사용법에 적합합니다.

다만, 앞으로도 계속 4.6을 사용할 수 있다는 보장은 없습니다.

새로운 모델일수록 다음과 같은 방향으로 기울고 있습니다.

• 지시 사항을 더욱 명시적으로 해석함
• 작업의 범위 (Scope)나 제약 사항을 중시함
• 도구 사용 (Tool Use)이나 장시간 작업을 전제로 함
• 목표와 성공 조건으로부터 자율적으로 진행함

이는 AI 측이 똑똑해졌기 때문에 인간이 아무것도 쓰지 않아도 된다는 방향이 아닙니다.

오히려, 인간 측에서 업무를 전달하는 방식을 잘 구조화할 필요가 생겨나고 있는 것처럼 보입니다.

"적당히 잘 고쳐줘"만으로 끝나는 시대에서,

무엇을 달성하고 싶은가
무엇을 변경해도 되는가 (변경해서는 안 되는가)
무엇을 완료 기준으로 삼을 것인가
...

를 명시하는 시대로 넘어가고 있는 것일지도 모릅니다.

그렇다고는 해도 이 기사는 어디까지나 프롬프트 (Prompt)에 관한 이야기입니다.

규칙 기반 (Rule-based)으로 문서를 정비하고 스펙 주도 개발 (Spec-driven development)로 이행할 수 있다면 당연히 이야기가 달라지겠지만... 본 기사는 프롬프트를 다룬 기사이므로, 이 부분에 대한 이야기는 생략하겠습니다.

비고

여기까지 써놓고 하는 말입니다만,

일상적인 태스크의 대부분은 Sonnet 4.6으로 성능 면에서 충분합니다.

Cursor를 사용하고 계신 분의 경우

Auto나 Composer 2.5로도 충분히 문제없을 것입니다.

오히려 모델은 AI 에이전트 (AI Agent)의 5가지 구성 요소 중 하나의 요소일 뿐이므로

너무 고비용 모델에 집착하기보다

다른 요인 (하네스, Harness)을 정비하는 것이 결과적으로 퍼포먼스를 향상시키는 사례도 많다고 생각합니다.

(그리고 개인적인 취향입니다만 Gemini 3.1 Pro나 Gemini 3.5 Flash도 평범하게 좋은 모델이라 추천합니다. 가성비가 좋거든요.)

훌륭한 하네스를 갖춘 양질의 모델은, 열악한 하네스를 갖춘 뛰어난 모델보다 우수하다.

참조

Discussion