요약
30초 요약 — 오늘 바꿀 다섯 가지
Opus 5는 Opus 4.8용으로 쓰던 프롬프트로도 그냥 잘 작동합니다. 다만 몇 가지 습관은 이제 도움이 안 되거나, 오히려 손해입니다. 바꿀 것만 추리면 다섯 가지입니다.
- 01"다시 확인해줘"를 지우세요 Opus 5는 시키지 않아도 스스로 검증합니다. 또 시키면 과하게 검증하느라 시간과 비용만 늘고, 지워도 품질은 그대로입니다.
- 02답이 길다면 길이를 말로 정해주세요 기본 답변이 이전보다 깁니다. '생각 강도'를 낮춰도 답 길이는 확실히 줄지 않습니다. 길이는 따로 요청해야 합니다.
- 03일은 처음에 통째로 맡기고, 범위는 못 박으세요 복잡한 일일수록 전체 요구사항을 처음에 다 받고 끝까지 진행할 때 가장 잘합니다. 대신 요청하지 않은 일까지 벌일 수 있으니 범위를 분명히 하세요.
- 04검토를 맡길 땐 "중요한 것만"이라고 하지 마세요 정말 그것만 골라 말할 수 있습니다. 일단 전부 받은 다음, 거르는 건 다음 단계에서 하세요.
- 05"하지 마"보다 원하는 스타일의 예시를 보여주세요 금지하는 지시보다, 원하는 말투의 예시를 보여주는 쪽이 더 잘 먹힙니다.
1부
무엇이 좋아졌나
원문: Capability improvements
원문이 밝히는 Opus 5의 정체성은 복잡한 개발 작업과 기업 업무용이고, 특히 오래 걸리는 작업을 스스로 끝까지 끌고 가는 데 강점이 있습니다. 그래서 아래 항목 중 몇 가지는 원래 코딩을 기준으로 한 이야기입니다. 해당하는 곳마다 표시해 두었으니, 그 부분은 "이런 성격이구나" 정도로 읽으셔도 됩니다.
Opus 4.8과 비교해 프롬프트와 직접 관련된 변화는 일곱 가지입니다. "그래서 나한테 뭐가 달라지나"를 기준으로 정리했습니다.
1. 긴 작업을 끝까지 해냅니다
원문 기준으로는 어려운 코딩 작업에서 가장 강합니다 — 여러 파일에 걸친 기능, 큰 폭의 리팩터링, 처음부터 끝까지 만들어야 하는 일 같은 것들입니다. 중간에 빈칸이나 "여기는 나중에" 같은 자리표시를 남기지 않고 작업을 완결합니다. 그리고 전체 요구사항을 처음에 다 받고 그냥 놔뒀을 때 가장 잘합니다. 한 줄씩 나눠 시키는 것보다, 원하는 걸 한 번에 정리해 주고 기다리는 편이 낫다는 뜻입니다.
한 번에 끝나는 간단한 수정도 잘하지만, 그런 쉬운 일에서는 이전 모델과의 차이가 작습니다. 덩치 크고 복잡한 일일수록 갈아탄 보람이 있다는 뜻입니다.
2. 코드 검토와 버그 찾기가 정확해졌습니다
찾아내는 양도 많고, 찾아낸 것 중 헛다리인 비율도 낮습니다. 낮은 설정에서도 정확도가 유지되기 때문에, 빠르게 한 번 훑고 나중에 꼼꼼히 다시 보는 방식이 잘 통합니다.
검토를 시키면서 "중요한 것만 알려줘", "보수적으로 봐줘"라고 적으면, 그 말을 문자 그대로 따라 정말 적게 보고할 수 있습니다. 전부 보고하게 한 다음, 거르는 건 별도의 단계로 분리하세요.
3. 낮은 설정으로도 충분합니다
'생각 강도(effort)'를 낮게 두면 훨씬 적은 비용과 시간으로도 품질이 잘 유지됩니다. 기본값인 '높음'에서 시작하되, 직접 써 보고 품질이 유지되는 선에서 낮은 설정을 비용과 응답 속도의 주 조절 장치로 적극 쓰라는 것이 공식 권고입니다. 까다로운 개발·자동화 작업에서만 최고 설정으로 올리면 됩니다. 이전 모델에서 쓰던 설정값을 그대로 가져왔다면, 한 번 다시 비교해 보시길 권합니다.
※ '생각 강도'는 API로 연결해 쓰거나 개발 도구를 쓸 때 조절하는 설정입니다. 챗봇 창에서만 쓰신다면 이 항목은 넘어가셔도 됩니다.
4. 이미지와 화면을 잘 읽습니다
차트, 문서, 도표를 이해하고, 화면 디자인을 보고 그대로 재현하는 능력이 강해졌습니다. 이전 모델을 쓰며 만들어 둔 우회 요령이 있다면 이제 필요 없을 수 있으니 한 번 확인해 보세요. 이미지를 잘라 보고 다시 확인하는 도구를 쓸 수 있을 때 가장 잘하고, 그게 생각 강도를 올리는 것보다 비용 대비 효과가 좋습니다.
5. 아주 긴 자료를 통째로 넣을 수 있습니다
한 번에 다룰 수 있는 분량이 100만 토큰이고, 이것이 기본값이자 최대값입니다. 토큰은 AI가 글을 세는 단위로, 아주 긴 문서 여러 개를 한꺼번에 넣어도 된다는 뜻입니다. 게다가 그 분량 끝까지 지시 따르기와 도구 사용, 추론의 품질이 일정하게 유지됩니다. 요약해서 조금씩 넣지 말고, 자료를 통째로 주세요.
6. 문서와 표를 잘 만듭니다
수식이 들어간 여러 장짜리 스프레드시트를 만들고 다룰 수 있고, 구조가 잡힌 발표 자료도 만듭니다. 따라야 할 서식이나 템플릿이 있다면 프롬프트에 함께 넣어 주세요.
7. 여러 AI를 동시에 부리는 일도 잘합니다
작업을 나눠 맡기고 결과를 다시 검토하게 하는 방식이 잘 돌아가고, 서로 작업을 덮어쓰는 사고도 드뭅니다. 다만 비용이 걱정된다면 위임을 제한해야 합니다 — 4부에서 다룹니다.
2부
말이 길어졌습니다 — 길이를 정해주는 법
Opus 5는 기본 답변이 이전 Opus 모델들보다 깁니다. 여기서 가장 많이들 헷갈리는 지점이 하나 있습니다.
'생각 강도'를 낮춰도 답이 짧아진다는 보장은 없습니다
원문: Response length and verbosity
생각 강도(effort) 설정은 얼마나 오래 생각하는지를 조절하는 것이지, 얼마나 많이 말하는지를 조절하는 게 아닙니다. 강도를 낮추면 속으로 생각하는 양은 줄어들 수 있지만, 눈에 보이는 답변 길이가 확실하게 줄지는 않습니다. 답을 짧게 받고 싶다면 짧게 해달라고 직접 말해야 합니다. 짧은 한 줄이면 충분히 잘 듣습니다.
핵심만 간결하게 답해주세요. 단서나 주의사항은 짧게 줄이고, 답변의 대부분을 본론에 써주세요. 설명을 요청하면 우선 요약해서 알려주고, 자세한 설명은 따로 요청할 때만 해주세요.
Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.
지시사항이 긴 경우에는, 위 문구를 앞쪽에 두고 맨 끝에 짧은 알림을 한 번 더 넣으라고 원문은 권합니다.
<말투 선호> 답변은 적당히 간결하게 유지해주세요. </말투 선호>
<tone_preference> Keep outputs reasonably concise. </tone_preference>
일하는 중에 말이 많아졌습니다
원문: User-facing progress updates
여러 단계를 스스로 처리하는 작업에서 Opus 5는 지금 뭘 하려는지 자주 알려줍니다. 메시지 하나하나가 이전 모델보다 긴 경우가 많습니다. 중계방송이 부담스럽다면, 어떤 리듬으로 알려줬으면 하는지 직접 설명해 주면 됩니다.
시작하기 전에 무엇을 할 것인지 한 문장으로만 말해주세요. 작업 중에는 중요한 것을 발견했거나 방향을 바꿀 때만 짧게 알려주세요. 끝나면 결과부터 말해주세요 — 첫 문장이 "무슨 일이 있었는지" 또는 "무엇을 찾았는지"에 대한 답이어야 하고, 자세한 내용은 그 뒤에 덧붙여주세요.
Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.
반대로 더 많이 알려주게 하거나 말투를 바꾸고 싶을 때도 같은 방법을 씁니다. 그리고 여기에 중요한 원칙이 하나 있습니다 — "이렇게 하지 마"라고 금지하는 것보다, 원하는 말투의 예시를 직접 보여주는 쪽이 대체로 더 효과적입니다. 원문은 이 이야기를 '진행 상황을 알려주는 방식'에 한정해서 하고 있습니다. 편집자 주 — 경험상 이건 Opus 5 말고 다른 AI에게 말을 걸 때도 잘 통합니다.
만들어 주는 문서도 길어졌습니다
원문: Written deliverable length
대화가 긴 것과 별개로, 파일로 만들어 주는 결과물(보고서, 정리 문서, 요약본)도 이전 모델보다 긴 경우가 많습니다. 분량 기준을 함께 알려주세요.
문서 분량은 그 일에 필요한 만큼만 맞춰주세요. 다뤄야 할 내용은 충분히 다루되, 형식적인 항목이나 중복되는 요약, 상투적인 문구로 분량을 채우지 마세요.
Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.
3부
이제 빼야 할 지시들
이 가이드에서 가장 실질적인 부분입니다. 좋은 뜻으로 넣어 둔 지시가 Opus 5에서는 오히려 낭비가 되는 경우가 있습니다.
"마지막에 꼭 검증해줘"를 지우세요
원문: Task scope and over-verification
Opus 5는 시키지 않아도 스스로 자기 작업을 검증합니다. 그래서 "중요한 작업은 마지막에 검증 단계를 넣어라", "검증은 별도의 AI에게 시켜라" 같은 지시가 프롬프트에 들어 있으면, 본래 하던 검증 위에 시킨 검증이 겹쳐 과하게 검증하게 됩니다. 공식 문서의 표현을 그대로 옮기면, 그 지시를 지우면 낭비되는 토큰이 줄고 품질 손실은 없습니다. 따로 검증 단계를 끼워 넣도록 짜둔 옛날 설정이 있다면 그것도 마찬가지입니다.
시키지 않은 일까지 할 수 있습니다
Opus 5는 작업 범위를 스스로 넓히기도 합니다. 요청하지 않은 단계를 더하거나, 이 일이 원래 어떠해야 하는지 스스로 판단해 움직입니다. 범위가 좁고 분명한 일이라면, 어디까지가 부탁인지 못 박아 주세요.
요청한 것을, 요청한 범위까지만 해주세요. 일상적인 판단은 직접 내리되, 요청을 다르게 해석하면 결과물이 크게 달라지는 경우에만 물어봐 주세요. 요청이 잘못됐거나 더 나은 방법이 있다면 한 문장으로 알려주고, 그대로 작업은 이어가 주세요 — 임의로 범위를 줄이거나 늘리거나 바꾸지 마세요. 맡은 일은 끝까지 마치고, 부탁한 범위를 명백히 넘어서는 일은 하지 마세요.
Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.
"한 번 더 검토해줘"도 마찬가지입니다
원문: Self-correction
Opus 5는 자기 실수를 스스로 잘 잡아내고 고칩니다. 그래서 "답변을 다시 확인해줘", "대답하기 전에 재검토해줘" 같은 지시는 이미 하고 있는 일을 또 시키는 셈이라 비용만 늘고 결과는 나아지지 않습니다.
한편 Opus 5는 앞서 한 말을 정정하는 설명을 이전보다 자주 합니다. 고객에게 그대로 보이는 서비스라면 이게 지저분해 보일 수 있습니다. 정말 중요한 정정만 남기고 싶다면 이렇게 적어 주세요.
앞서 한 말을 정정할 때는, 그 오류가 상대의 코드나 판단, 결론을 바꿀 경우에만 정정해주세요. 정정은 간단명료하게 말하고 바로 하던 일을 이어가세요. 아무것도 달라지지 않는 사소한 실수는 그냥 고치고 넘어가면 됩니다.
Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.
4부
자동화를 쓰는 분들을 위한 설정
개발·자동화 도구를 직접 다루는 경우에만 해당여기서부터는 AI에게 여러 하위 작업을 맡기거나, API로 직접 연결해 쓰는 경우의 이야기입니다. 챗봇 창에서만 쓰신다면 부록으로 건너뛰셔도 됩니다.
작은 일까지 나눠 맡기지 않게 하세요
원문: Controlling subagent spawning
Opus 5는 이전 모델보다 일을 하위 AI에게 더 쉽게 나눠 맡깁니다. 진짜로 독립적이고 덩치 큰 작업이라면 이득이지만, 작은 일까지 나누면 비용과 시간이 배로 듭니다. 어떤 경우에 나눠 맡길지 명시하거나, 아예 개수 상한을 걸어 두세요.
하위 작업으로 나눠 맡기는 건, 서로 완전히 독립적이고 동시에 진행할 수 있는 큰 작업일 때만 하세요 — 예를 들면 여러 파일에 걸친 광범위한 조사 같은 경우입니다. 직접 몇 번 만에 끝낼 수 있는 일은 나누지 말고, 자기 작업을 검증하거나 재확인하는 용도로도 쓰지 마세요. 하나로 끝낼 수 있으면 여럿 대신 하나만 쓰고, 개수는 최소한으로 유지하세요.
Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.
'생각하기'는 끄지 마세요
원문: Running with thinking disabled
Opus 5는 생각하기(thinking)가 기본으로 켜져 있고, 끄는 것은 생각 강도가 높음 이하일 때만 가능합니다. 그리고 껐을 때 가끔 두 가지 문제가 나타납니다.
- 도구 호출이 그냥 글자로 나옵니다. 실제로 실행되어야 할 명령이 사용자에게 보이는 텍스트로 쓰이고, 대화는 정상적으로 끝나지만 그 명령은 실행되지 않습니다. 자동으로 돌아가는 작업에서는 이 잘못 새어 나온 텍스트가 대화 기록에 남아 이후 차례까지 영향을 줍니다. 검색처럼 도구를 많이 쓰는 작업에서 특히 자주 나타납니다.
- 내부 태그가 답변에 섞여 나옵니다. 원래 보이면 안 되는 내부 표시가 그대로 노출될 수 있습니다. 시스템 지시에 "생각하지 마라", "추론하지 마라" 같은 규칙이 있다면 지우세요 — 그런 지시가 오히려 태그 노출을 늘립니다.
두 문제의 근본 해법은 생각하기를 켜 둔 채로 생각 강도를 낮춰 비용을 조절하는 것입니다. 대부분의 작업에서 생각하기를 켜고 강도를 낮춘 쪽이, 비슷한 비용으로 생각하기를 끈 것보다 낫습니다.
그래도 반드시 꺼야 하는 경우라면, 두 문제를 한꺼번에 줄이는 문구가 있습니다. 참고로 내부 태그를 이름으로 콕 집어 금지하는 지시는 오히려 효과가 떨어지니, 아래처럼 일반적인 표현을 쓰세요.
도구를 사용할 때는 먼저 짧게 한 문장 말해도 됩니다. 사용자가 요청한 것을 표현할 수 있는 도구가 없다면, 추측하지 말고 없다고 말해주세요. 내부용이나 시스템용 XML 태그는 답변에 포함하지 마세요.
When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.
Opus 4.8에서 넘어오는 경우, 생각하기가 기본으로 켜진 점과 생각하기를 끌 때 강도가 '높음'으로 제한되는 점이 달라진 부분입니다. 기존 Opus 4.8 프롬프트는 대체로 손대지 않아도 잘 작동합니다.
부록
문구 모음 — 복사해서 쓰세요
위에서 나온 문구를 두 덩어리로 묶었습니다. 앞의 것은 늘 켜 두어도 되는 세팅이고, 뒤의 것은 범위가 좁고 분명한 일에만 쓰는 문구입니다. 원문이 범위 제한 문구를 "좁은 작업"에 한정해 권하고 있어서, 둘을 나눠 두었습니다. 각 문구의 영어 원문은 본문의 해당 항목에 있습니다.
핵심만 간결하게 답해주세요. 단서나 주의사항은 짧게 줄이고, 답변의 대부분을 본론에 써주세요. 설명을 요청하면 우선 요약해서 알려주고, 자세한 설명은 따로 요청할 때만 해주세요. 앞서 한 말을 정정할 때는, 그 오류가 제 판단이나 결론을 바꿀 경우에만 정정해주세요. 사소한 실수는 그냥 고치고 넘어가면 됩니다. 문서를 만들어 줄 때는 분량을 그 일에 필요한 만큼만 맞춰주세요. 형식적인 항목이나 중복 요약으로 분량을 채우지 마세요.
요청한 것을, 요청한 범위까지만 해주세요. 일상적인 판단은 직접 내리되, 요청을 다르게 해석하면 결과물이 크게 달라지는 경우에만 물어봐 주세요. 요청이 잘못됐거나 더 나은 방법이 있다면 한 문장으로 알려주고, 그대로 작업은 이어가 주세요. 맡은 일은 끝까지 마치고, 부탁한 범위를 명백히 넘어서는 일만 하지 마세요.
반대로, 지워야 할 문구
- "마지막에 꼭 검증 단계를 넣어줘"
- "답변을 다시 확인해줘", "대답하기 전에 재검토해줘"
- "생각하지 마", "추론 과정 없이 답해" — 오히려 내부 태그 노출을 늘립니다
- 검토를 맡길 때의 "중요한 것만", "보수적으로" — 정말 적게 보고할 수 있습니다