구모델 시대의 버릇이 신모델에서는 비용만 태운다

claudeprompt-engineeringcost-optimization

안녕하세요! 재니미입니다.

지난 글에서는 프롬프트 캐시를 다뤘습니다. 이번엔 캐시가 아니라 프롬프트 자체에 낀 군더더기, 안티패턴 이야기입니다.

지금 프롬프트에 남아있는 지시 중 상당수는 더 이상 존재하지 않는 모델의 버릇을 고치려고 넣은 것입니다. 예전 모델은 검증을 건너뛰거나 대충 답하는 실수가 잦았고, 그걸 막으려고 “다시 확인해라”, “철저히 하라” 같은 지시를 프롬프트에 박아뒀습니다. 그런데 신모델은 그런 걸 이미 알아서 웬만큼 잘합니다. 문제는 그 지시가 프롬프트에 그대로 남아 있다는 겁니다. 신모델은 시키는 대로 문자 그대로 실행하느라, 안 해도 될 일을 하면서 토큰을 더 씁니다.

이 글은 Anthropic 공식 글 Reducing cost and improving performance with the Claude Platform을 읽고 정리한 것입니다. 벤치마크 수치는 전부 원문 출처이며, 별도 표기 없는 한 직접 재현한 결과가 아닙니다.

흔한 안티패턴 여섯 가지

안티패턴 문제
“다시 한번 확인해라” (double-check) 리터럴하게 재검증 절차를 수행해서 토큰을 낭비합니다
“최대한 철저히” 강조 불필요한 세부사항, 도구 호출이 늘어납니다
고정된 절차·스크래치패드 강제 모델의 기본 추론과 중복됩니다
구식 실패 사례를 예제로 제시 그 실패 패턴을 오히려 모방합니다
서로 모순되는 규칙 더 엄격한 해석 쪽으로 쏠려 품질이 떨어집니다
오래된 설정값 신모델이 거부해서 API 오류가 납니다

하나씩 풀어보면 이렇습니다.

  • “다시 한번 확인해라”(“verify twice before responding”): 예전 모델은 실수가 잦아서 재검증 지시를 넣어야 했습니다. 신모델에 이 지시를 그대로 두면, 예를 들어 환불 처리 같은 반복 작업에서 같은 주문 조회를 매번 두 번씩 실행하면서 토큰만 낭비합니다.
  • “최대한 철저히”(“be maximally thorough”): “철저히”라는 말 한마디가 “가능한 모든 걸 다 찾아봐라”로 해석되면서, 몇 줄이면 충분한 답을 위해 지식베이스를 수십 번 검색하게 만듭니다.
  • 고정된 절차·스크래치패드 강제: “생각을 스크래치패드에 단계별로 적어라” 같은 지시입니다. 예전엔 모델이 스스로 단계를 안 밟는 경우가 많아서 강제로 시켰지만, 신모델은 이미 비슷한 추론을 내부적으로 하기 때문에 겉으로 또 한 번 적어내느라 토큰이 중복 소모됩니다.
  • 구식 실패 사례를 예제로 제시: “이렇게 답하면 안 된다”며 과거 실패 사례를 예시로 보여주면, 모델이 그 예시의 패턴 자체를 오히려 따라 하는 역효과가 날 수 있습니다.
  • 서로 모순되는 규칙: 시간이 지나며 규칙이 계속 덧붙다 보면 서로 부딪히는 지시가 남습니다. Anthropic 사례에서는 모순된 환불 규칙 때문에 Opus 5가 마땅히 줘야 할 환불 네 건을 보류한 적이 있습니다.
  • 오래된 설정값: 이전 모델에서 쓰던 thinking 관련 설정처럼 지금은 폐지된 값을 그대로 두면, 신모델 API가 그 값을 아예 거부해서 요청 자체가 실패합니다.

전부 “예전 모델이 이랬으니 이렇게 막아두자”는 흔적입니다. 문제는 그 모델이 이제 없다는 것입니다.

지우는 법: prompt-audit

Claude Code에서 /claude-api prompt-audit를 실행하면 작업 디렉토리의 프롬프트·스킬·도구 설명·애플리케이션 코드·CLAUDE.md 같은 설정 파일까지 스캔해서 위 패턴을 찾아 제거해줍니다. 어디에 문제가 있는지 알려주기만 하는 게 아니라 실제로 지워준다는 점이 핵심입니다.

실제로 이만큼 차이 났다

Anthropic이 공개한 고객 지원 벤치마크에서, Opus 4.8에서 Opus 5로 옮기며 prompt-audit를 적용한 결과입니다.

비용 정확도
안티패턴 그대로 기준 기준
prompt-audit 적용 후 -14.6% +5.3%p

비용이 줄면서 정확도까지 올랐습니다. 원인은 중복된 검증 절차, 불필요한 지식베이스 검색, 구식 thinking 설정으로 인한 API 거부, 서로 부딪히던 규칙들이었습니다. 전부 지우기만 해도 되는 종류였습니다.

다음 편은 캐시도 프롬프트도 아니고, effort 레벨 자체를 얼마나 태울지의 문제입니다.

감사합니다.

참고 자료