프롬프트 최적화 방법 — 확인하라는 말을 빼면 좋아집니다

프롬프트를 한 번 잘 만들어두면 계속 쓰게 됩니다. 그런데 모델이 좋아지면서 예전에 도움이 되던 문구가 이제는 손해가 되는 경우가 생겼습니다. 공식 가이드가 아예 "이런 지시는 빼라"고 지목하는데, 이유가 명쾌합니다 — 모델이 이미 알아서 하는 일을 또 시키면 두 번 하게 된다는 겁니다. 빼면 토큰이 줄고 품질은 그대로랍니다. 어떤 문구가 해당되는지 정리했습니다.

📌 30초 요약

• "검증해라"는 빼세요 — 이미 합니다. 시키면 두 번 합니다.
• "다시 확인해라"도 같습니다 — 값만 늘어납니다.
• ⚠️ "심각한 것만 보고해"라고 하면 진짜로 덜 찾아옵니다.
• 답을 짧게 하려면 강도가 아니라 말로 시켜야 합니다.
• ⚠️ 작은 일도 나눠 맡겨 값이 뜁니다 — 상한을 두세요.
• 금지보다 좋은 예시가 더 잘 통합니다.

"확인해라"를 빼면 좋아집니다

가장 뜻밖이면서 바로 써먹을 수 있는 대목입니다. 프롬프트에 "중요한 작업은 마지막에 검증 단계를 넣어라"거나 "별도로 검토를 시켜라" 같은 문구가 있다면 — 지우라고 합니다.

➖ 빼면 줄고, 품질은 그대로

이유는 모델이 시키지 않아도 자기 작업을 검증하기 때문입니다. 여기에 지시까지 더하면 원래 하던 것 위에 한 겹이 더 얹혀 과잉이 됩니다. 문서 표현대로 그 지시를 없애면 낭비되는 토큰이 줄어들고 품질 손실은 없습니다. "답하기 전에 다시 확인해라" 같은 자기 점검 지시도 마찬가지고요 — 이미 스스로 실수를 잡아 고치는데, 시키면 비용만 늘고 결과는 나아지지 않습니다. 예전에 만들어둔 프롬프트 패턴에 이런 문구가 들어 있다면, 한 번 지워보고 결과를 비교해볼 만합니다.

같은 이유로 도구 쪽에 붙여둔 검증 단계도 점검 대상입니다. 예전 모델을 기준으로 짜둔 "작업 후 검토" 절차가 그대로 남아 있으면 똑같이 두 번 하게 되거든요. 하나 더, 작업 범위를 스스로 넓히는 경향도 있어서 좁은 일을 시킬 때는 "요청한 범위만, 끝까지"를 명시하라고 권합니다.

짧게 하려면 말로 시켜야 합니다

답이 길다고 느껴서 생각 강도를 낮추는 분이 많은데, 문서가 이 오해를 정면으로 짚습니다. 강도는 "얼마나 생각하는지"를 조절할 뿐 "얼마나 말하는지"가 아닙니다. 강도를 낮추면 생각하는 양은 줄지만 보이는 답이 짧아진다는 보장은 없습니다. 길이를 줄이려면 따로 말로 시켜야 합니다.

줄이고 싶은 것	써야 할 손잡이
생각하는 양·값	강도 낮추기
대화에서 보이는 답 길이	짧게 쓰라는 지시문
작업 중 중계 멘트	언제 말할지를 지정
파일로 쓰는 문서 분량	길이 기준을 따로 명시
정정 멘트	"바뀌는 게 있을 때만"

여기서 놓치기 쉬운 게 대화 답 길이와 파일로 저장하는 문서 길이가 별개라는 점입니다. 대화만 짧게 시켜두면 보고서는 여전히 깁니다. 그리고 작업 중에 "이제 뭘 하겠습니다"를 자주 말하는 편이라, 언제 말할지를 아예 정해주라고 권합니다 — 첫 도구를 쓰기 전에 한 문장, 중간엔 중요한 발견이나 방향 전환 때만, 끝나면 결과부터. 하지 말라는 지시보다 원하는 모습을 예시로 보여주는 편이 잘 통한다는 조언도 붙어 있습니다.

"보수적으로"라고 하면 진짜로 덜 합니다

코드 검토를 시킬 때 흔히 쓰는 문구가 있습니다 — "심각한 것만 알려줘", "보수적으로 판단해". 잡소리를 줄이려는 의도죠. 그런데 모델이 그 지시를 곧이곧대로 따라 실제로 덜 보고합니다.

문서의 권고는 반대입니다 — 전부 보고하게 하고, 거르는 건 별도 단계에서 하라는 것. 애초에 찾아낸 것 대부분이 진짜 문제라 헛것이 적기 때문에, 굳이 앞단에서 입을 막을 이유가 없다는 얘기입니다. 게다가 강도를 낮춰도 정확도가 유지돼서, 작업 중엔 가볍게 한 번 훑고 나중에 꼼꼼히 한 번 더 보는 식으로 나눌 수 있습니다.

알아서 나눠 맡기다 값이 뜁니다

일을 여러 갈래로 쪼개 나눠 맡기는 것도 이전보다 적극적입니다. 크고 서로 독립적인 일이면 이득이지만, 작은 일까지 나누면 값과 시간이 배로 듭니다. 그래서 어떤 경우에 나눌지를 명시하거나, 몇 개까지 띄울지 상한을 걸라고 권합니다.

권장 문구가 구체적입니다 — 여러 파일을 넓게 훑는 것처럼 크고 진짜로 나뉘는 일에만 맡기고, 몇 번의 도구 호출로 끝낼 일은 직접 하고, 특히 자기 작업을 재확인하는 용도로는 쓰지 말 것. 하나로 끝날 일에 여러 개를 띄우지 말라는 조건도 붙습니다. 앞서 나온 "검증 지시를 빼라"와 같은 맥락이죠. 도구를 쓰는 환경이라면 개수와 깊이를 숫자로 못 박는 설정도 따로 있습니다.

자주 묻는 질문 (FAQ)

Q. 그럼 기존 프롬프트를 다 갈아엎어야 하나요?

아닙니다. 문서도 이전 모델용 프롬프트가 그대로도 잘 동작한다고 먼저 밝힙니다. 손볼 만한 건 위에 나온 몇 가지 습관뿐이에요. 우선순위를 매기자면 — ①검증·재확인 지시 삭제 ②길이 지시 추가 ③"보수적으로" 문구 제거 ④나눠 맡기기 상한 순서입니다. 코딩용 프롬프트 기본기는 여전히 유효하니 거기에 이 네 가지만 얹으시면 됩니다.

Q. 값을 아끼려면 뭐부터 손대야 하나요?

강도를 낮추는 게 1순위입니다. 문서가 낮은 단계와 중간 단계를 적극적으로 쓰라고 하는데, 품질이 유지되는 범위에서 토큰과 시간이 크게 줍니다. 특히 이전 모델에서 쓰던 기본값을 그대로 가져왔다면 다시 재보라고 권합니다. 반대로 생각을 아예 끄는 건 권하지 않습니다 — 끄면 도구 호출이 새는 문제가 있어서, 낮은 강도로 켜두는 편이 비슷한 값에 결과가 낫습니다.

Q. 꼭 꺼야 하는 사정이 있다면요?

완화 지시문 하나로 두 증상을 함께 잡는 방법이 안내돼 있습니다. 뼈대는 셋입니다 — ①도구를 쓰기 전에 한마디 해도 된다고 허락해주고 ②맞는 도구가 없으면 억지로 부르지 말고 그렇다고 말하게 하고 ③내부용 표시를 답에 넣지 말라고 적는 것. 여기서 재미있는 조언이 하나 있는데, 특정 표시를 이름으로 콕 집어 금지하면 오히려 덜 효과적이라 일반적인 표현으로 쓰라고 합니다.

🧾 정직하게 밝혀둘 것

• ★특정 세대 모델에 대한 안내입니다. 모든 AI에 일반화되는 규칙이 아니며, 다른 모델이나 다른 회사 제품에는 그대로 적용되지 않습니다.
• 직접 A/B로 재보지 않았습니다. "빼면 토큰이 줄고 품질은 그대로"는 공식 문서의 서술이고, 얼마나 줄어드는지 수치는 제시되지 않았습니다.
• ★문서가 권하는 실제 지시문은 영어 예시로 제시돼 있습니다. 이 글은 그 취지를 우리말로 옮긴 것이라, 그대로 복사해 쓰실 거면 원문 예시를 보시는 편이 정확합니다.
• ★설정 이름·환경 변수·옵션명은 전부 풀어서 적었습니다. 숫자로 상한을 거는 설정은 특정 버전 이상에서만 되니 원문을 확인하세요.
• 모델 성능에 대한 서술은 제조사 문서 기준입니다. 독립적인 검증 자료가 아닙니다.

✨ 정리하면

좋아진 만큼 빼야 할 것도 생깁니다. 이미 알아서 하는 일을 또 시키면 두 번 하고, "보수적으로"라고 하면 정말 덜 찾아옵니다. 답 길이는 강도가 아니라 말로 줄이고, 나눠 맡기기엔 상한을 거세요. 오래 쓰던 프롬프트가 있다면 검증 지시 한 줄부터 지워보시길 권합니다. 프롬프트 기본기는 프롬프트 패턴 7가지와 코딩 프롬프트 작성법, 생각을 끌 때 생기는 문제는 생각을 끄면 새는 것, 값을 통으로 잡는 흐름은 AI 지출 관리 허브에 모아뒀습니다.

※ 출처: Claude Opus 5 프롬프트 작성 공식 가이드(2026년 8월 27일 열람). 특정 세대 모델을 대상으로 한 안내이며, 모델이 바뀌면 권장 사항도 달라집니다. 실제로 프롬프트를 고치기 전에는 원문의 예시 문구를 함께 확인하시길 권합니다.