“프롬프트를 잘 쓰면 AI를 잘 쓰는 것”이라고 믿고 지시문을 점점 길게 다듬어 왔다면, 최신 모델에서는 그 습관이 오히려 발목을 잡는다. 앤트로픽이 Claude Opus 5용 프롬프트 가이드를 내놓으면서 한 말이 재미있다. 5세대 모델에서 프롬프트 최적화는 “대부분 빼기 작업(subtraction exercise)”이라는 것이다. 그동안 애써 채워 넣은 안전장치들이 이제는 비용과 품질을 갉아먹는 짐이 됐다.
- 똑똑해질수록 프롬프트는 짧게. 예전 모델이 실수할까 봐 넣던 지시가 신형 모델에서는 과잉 동작을 부른다.
- Opus 5는 알아서 한다. 시키지 않아도 스스로 검증하고, 작업을 나누며, 기본 응답도 길어졌다. 옛 지시는 이 성향과 충돌한다.
- 습관 6가지를 Before/After로. 검증 지시 삭제, 위임 상한 설정, 규칙 대신 판단 위임 등을 바꾼다.
프롬프트는 이제 뺄셈이다. 5세대 AI 모델에서 프롬프트 최적화란 지시를 더 채우는 게 아니라, 옛 모델을 지키려고 넣었던 규칙을 덜어내는 작업이다. 아래에서 실제로 무엇을 지워야 하는지 하나씩 본다.
왜 똑똑한 AI일수록 프롬프트를 빼야 할까
핵심은 간단하다. 모델이 잘하는 일을 사람이 프롬프트로 한 번 더 시키면, 모델은 그걸 “두 번 하라”는 뜻으로 받아들인다. 예전 모델은 검증을 잘 못 해서 “다시 확인해줘”를 붙여야 했다. Opus 5는 시키지 않아도 스스로 점검하기 때문에, 같은 지시가 이제는 불필요한 재검증을 일으켜 시간과 비용만 늘린다.
비유하자면 팀에 새로 들어온 신입에게는 “이거 하고, 저것도 확인하고, 끝나면 나한테 보고해”라고 하나하나 챙겨야 했다. 그 사람이 몇 년 지나 베테랑이 되면 잔소리는 오히려 방해가 된다. 큰 방향만 주고 맡기는 게 낫다. Claude Opus 5로 넘어오면서 벌어진 일이 딱 이렇다. 여기서 하네스(harness, AI를 실제로 굴리는 실행 환경과 도구 묶음)라는 말이 자주 나오는데, 요즘IT가 정리한 것처럼, 요즘은 모델 자체 성능보다 이 하네스와 프롬프트를 어떻게 짜느냐가 결과를 더 크게 가른다. 이 관점은 좋은 AI 사용법은 프롬프트가 아니라 시스템이라는 이야기와도 맞닿아 있다.
그래서 지금 손봐야 할 건 화려한 프롬프트 기술이 아니라, 예전에 몸에 밴 방어적인 습관들이다. 크게 두 묶음으로 나눠서 본다. 하나는 “AI를 못 믿어서 덧붙이던 지시”, 다른 하나는 “길이와 사고량을 잘못 다루던 습관”이다.
습관 1~3: ‘AI를 못 믿어서’ 넣던 지시를 지운다
이 세 가지는 모두 “모델이 실수할 것”이라는 전제에서 나왔다. 이제 그 전제가 틀렸다.
습관 1. 검증·재확인 지시를 지운다. 예전에는 “작성한 뒤 반드시 다시 검토하고 오류가 없는지 확인한 다음 답해줘”를 습관처럼 붙였다. Opus 5는 이 지시가 없어도 자기 검증을 한다. 앤트로픽 가이드는 명시적 검증 지시가 과잉 검증을 유발한다고 본다. 지워도 품질은 그대로고 토큰만 아낀다.
- Before: “코드를 작성한 뒤 반드시 다시 한 번 검토하고, 오류가 없는지 재확인한 다음 답해줘.”
- After: “이 코드를 작성해줘.”
습관 2. 무조건 위임하게 두지 말고 상한을 둔다. Opus 5는 이전보다 작업을 하위 에이전트(subagent, 큰 작업을 쪼개 따로 처리하는 보조 AI)로 적극적으로 나눈다. 그래서 “필요하면 얼마든지 나눠서 처리해”라고 열어두면 위임이 폭주해 통제가 안 된다. 위임할 상황을 못 박거나 개수 상한(cap)을 정해준다. 자기 검증용으로 하위 에이전트를 쓰게 하는 것도 피한다.
- Before: “필요하면 하위 에이전트를 얼마든지 만들어서 작업을 나눠 처리해.”
- After: “이 작업은 직접 처리하고, 하위 작업으로 나눌 때는 최대 2개까지만.”
습관 3. “절대 하지 마”를 판단 위임으로 바꾼다. 규정형 지시를 Opus 5는 문자 그대로 따른다. 코드 리뷰에서 “고위험 이슈만 보고하고 나머지는 언급하지 마”라고 하면, 애매한 문제를 알아서 빼버려 과소 보고가 난다. 전부 보고하게 한 뒤 위험도로 걸러내는 편이 안전하다.
- Before: “고위험 이슈만 보고하고 나머지는 절대 언급하지 마.”
- After: “발견한 이슈를 전부 보고하고, 위험도가 높은 것부터 정리해줘.”
습관 4~6: 길이와 사고량은 내가 직접 조절한다
여기서 자주 헷갈리는 게 effort(모델이 얼마나 깊이 생각할지를 정하는 설정)다. effort를 길이 조절 손잡이로 오해하면 계속 어긋난다.
습관 4. 응답 길이는 프롬프트로 직접 지시한다. effort는 사고량을 조절할 뿐 응답 길이가 아니다. effort를 높인다고 답이 알아서 짧아지거나 길어지지 않는다. 게다가 Opus 5의 기본 응답은 이전보다 길어졌다. 간결하게 받고 싶으면 그렇게 대놓고 말해야 한다.
- Before: (effort만 조절하면 분량도 알아서 맞겠지)
- After: “핵심만 3문장으로 요약해줘.”
습관 5. thinking은 켜두고 effort를 낮춘다. 비용을 아끼려고 thinking(모델이 답하기 전에 스스로 정리하는 사고 과정)을 아예 꺼버리는 경우가 많다. 그런데 thinking을 끄면 도구 호출이 일반 텍스트로 새거나 <thinking> 같은 내부 태그가 그대로 노출되는 부작용이 생긴다. 공식 권장은 thinking을 끄지 말고 effort를 낮게(low) 두어 비용을 관리하는 것이다.
- Before: “생각 과정 없이 바로 답만 해.” (thinking 비활성화)
- After: thinking은 켜두고 effort를 low로 설정.
습관 6. effort 기본값을 지금 작업에 맞춰 다시 잡는다. 예전 모델 감각으로 늘 high effort에 두던 습관을 점검할 때다. 앤트로픽은 high에서 시작해 low·medium으로 낮춰보며 결과를 비교하라고 권한다. 낮은 effort가 품질을 유지하면서 토큰과 지연을 크게 줄이는 경우가 많다. 실제로 Opus 5는 낮은 effort에서도 코드의 실제 버그를 한 번에 잘 찾아낸다. 빠른 1차 훑기는 낮은 effort로, 정밀 점검만 높은 effort로 나누는 전략이 잘 통한다.
- Before: 어떤 작업이든 항상 최고 사고량(high effort).
- After: high로 시작해 low·medium으로 낮춰보고 내 작업 기준으로 비교.
그래서 프롬프트를 어떻게 바꾸면 될까
한 문장으로 줄이면, 모델을 못 믿어서 넣던 방어 지시를 지우고 길이·사고량만 내가 직접 잡으면 된다. 여섯 가지를 한눈에 비교하면 이렇다.
지시를 걷어낸 자리는 구조로 채운다. 앤트로픽이 권하는 배치는 시스템 프롬프트에는 제품 지침만, 세부 규칙은 아래 계층으로 내리는 것이다. 제품이 지켜야 할 원칙은 시스템 프롬프트에, 프로젝트 설정은 가볍게, 팀의 판단이 담긴 노하우는 스킬(Skill)에, 깊은 스펙은 코드 레퍼런스에 둔다. 모든 걸 시스템 프롬프트 하나에 욱여넣던 습관을 버리라는 뜻이다.
왜 이 변화가 진짜 중요한가
프롬프트를 짧게 쓰라는 건 단순히 글자를 줄이라는 얘기가 아니다. AI를 다루는 기본기가 “얼마나 꼼꼼히 시키느냐”에서 “얼마나 잘 맡기느냐”로 옮겨갔다는 신호다. 예전에는 좋은 프롬프트가 곧 자세한 프롬프트였다. 지금은 모델이 알아서 할 일을 믿고 비우는 판단력이 실력이 된다.
한 가지 짚을 점은 있다. “짧게”가 “대충”은 아니다. 무엇을 원하는지는 오히려 더 또렷하게 밝혀야 한다. 길이·사고량·위임 범위처럼 모델이 스스로 정하면 어긋나는 부분은 이제 사람이 명시적으로 못 박아야 한다. 방어적 잔소리는 빼되, 원하는 결과의 경계는 더 분명하게 그린다.
정리
바뀐 원칙은 셋이다. 모델이 스스로 하는 검증·위임·판단에 대한 지시는 지운다. 응답 길이는 effort가 아니라 프롬프트로 직접 요청한다. thinking은 켜두고 effort를 낮춰 비용을 잡는다.
세 가지가 한 방향을 가리킨다는 게 핵심이다. 옛 모델을 지키려고 쌓은 규칙이 신형 모델에서는 비용과 품질 손실로 되돌아온다는 것. 그래서 지금 할 일은 새 프롬프트 기술을 배우는 게 아니라, 그동안 채워 넣은 지시 중 무엇을 지울 수 있는지 되짚어보는 것이다. 오늘 쓰던 프롬프트 하나를 열어 “이 문장은 모델이 알아서 하는 일 아닌가”를 물어보는 데서 시작하면 된다.
