Your Old Prompts Are Making Claude Worse - Lance Martin, Anthropic

한 줄 핵심

최신 Claude를 제대로 쓰려면 오래된 프롬프트 습관을 버리고, 프롬프트 감사·캐시·평가 설계·힐 클라이밍을 통해 성능을 높이면서 비용과 신뢰성을 함께 최적화해야 한다.

시간별 요약

1. 0:00
   소개 이번 영상은 frontier 모델을 더 잘 쓰기 위한 몇 가지 단순하지만 효과적인 방법을 다룬다. 핵심은 성능과 비용을 둘 중 하나만 보는 대신, 실제로는 더 나은 지점이 많다는 점을 짚는 것이다.
2. 0:27
   대부분은 frontier에 있지 않다 많은 애플리케이션은 비용-성능 Pareto frontier 위가 아니라 그 안쪽에 있어, 약간의 설정 오류만 고쳐도 더 싸고 더 좋아질 수 있다. 실제 사례에서도 사소한 오구성만 바로잡아 성능 개선과 비용 절감을 동시에 얻는 경우가 반복된다.
3. 1:32
   프롬프트를 점검하라 프롬프트는 코드처럼 기술 부채를 쌓으며, 예전의 think step-by-step, verification ritual, boosters는 최신 frontier 모델에는 오히려 불필요하거나 해로울 수 있다. 상충 규칙이나 과도한 검증 지시는 비용을 올리고 성능을 떨어뜨릴 수 있으므로, Claude Code의 prompt audit로 이런 안티패턴을 제거하는 것이 유용하다.
4. 3:49
   프롬프트 점검이 만들어내는 효과 고객 지원 티켓 평가에서 구형 프롬프트를 최신 모델로 옮길 때 안티패턴이 섞이면 성능과 비용이 함께 비효율적일 수 있지만, prompt audit를 적용하면 추가적인 성능 향상과 토큰 절감이 나타난다. 검증 의식과 충돌 규칙을 제거하는 것만으로도 토큰 사용이 줄고 결과가 좋아질 수 있다.
5. 5:30
   프롬프트 캐시를 활용하라 멀티턴 에이전트는 같은 컨텍스트를 반복해서 쓰므로, 프롬프트 캐시를 적극적으로 사용해야 중복 비용을 줄일 수 있다. 다만 캐시는 strict prefix match이기 때문에 prefix가 조금만 바뀌어도 무효화되므로, 프롬프트 구조를 안정적으로 설계하고 hit rate를 지속적으로 확인해야 한다.
6. 7:43
   비용을 최대 72%까지 줄인 사례 내부 벤치마크에서 기본 하네스가 캐시를 제대로 활용하지 못한 경우, prompt cache 점검만으로 비용을 최대 72%까지 줄이면서 성능 변화는 거의 없었다. 즉, 캐시 최적화는 사실상 공짜에 가까운 비용 절감 수단이며, API 애플리케이션에서는 특히 중요하다.
7. 8:45
   Claude가 오를 수 있는 평가를 설계하라 좋은 평가란 모델과 thinking을 올릴수록 점수가 자연스럽게 상승하고, frontier에서도 아직 개선 여지가 있으며, 분산이 낮아야 한다. 모호한 과제가 많으면 평가가 이미 포화되어 있어, 아무리 힐 클라이밍을 해도 생산 환경에 도움이 되지 않을 수 있다.
8. 11:47
   과적합 없이 힐 클라이밍하기 평가가 잘 설계되면 Claude는 그 평가 위에서 자율적으로 개선점을 찾아갈 수 있지만, 벤치마크에 과적합할 위험이 크다. 이를 막기 위해 train/test 분리, 테스트 세트 비공개 유지, 학습-테스트 성능 비교를 통해 과적합 신호를 조기에 감지해야 한다.
9. 14:57
   66%였던 skill을 개선한 예시 Claude API skill은 문서에 기반해 있어야 하며, 초기에는 평가 점수가 66%에 불과했지만, 문서와 skill text를 반복적으로 수정하는 힐 클라이밍으로 크게 개선됐다. 텍스트 기반 표면은 수정이 쉽고 결과와의 연결도 분명해, prompt나 skill 개선에 특히 잘 맞는다.
10. 16:30
    비용을 위한 힐 클라이밍: 90% 절감 힐 클라이밍은 성능 개선뿐 아니라 비용 절감에도 쓸 수 있으며, 성능을 유지하거나 더 높이면서 모델·effort·프롬프트 구성을 탐색하게 할 수 있다. 예시에서는 비용을 90% 줄이면서 성능도 개선됐고, 더 강한 모델을 낮은 effort로 쓰는 조합이 종종 더 저렴하고 효율적이라는 직관이 확인됐다.
11. 18:53
    여러 날 돌아가는 에이전트를 위한 하네스 모델이 수시간에서 수일 단위로 일할 수 있게 되면서, 장기 자율 실행을 견디는 하네스 설계가 중요해졌다. 신뢰성, 복구 가능성, 보안이 핵심 과제가 되며, 단순 채팅이나 자동완성 수준을 넘어서는 새로운 운영 구조가 필요하다.
12. 20:21
    관리형 에이전트: 머리와 손을 분리하기 Manage Agents의 핵심은 에이전트의 '두뇌'인 하네스와 '손'인 sandbox를 분리하는 것이다. 세션 로그, sandbox, orchestrator, vault를 분리해 복구 가능성과 보안을 높이고, 비밀정보에 직접 접근하지 못하게 하면서도 장시간 작업을 안정적으로 수행하게 만든다.
13. 23:04
    요약 핵심은 프롬프트 감사, 프롬프트 캐시 활용, 장기 작업을 견디는 하네스, 그리고 평가와 힐 클라이밍의 결합이다. 이 네 가지를 잘 맞추면 Claude에게 긴 작업을 맡긴 뒤 나중에 돌아와 눈에 띄게 개선된 결과를 볼 수 있다.
14. 24:25
    Q&A: 평가 설계는 얼마나 자동화할 수 있는가 Claude는 traces를 훑어 문제 사례를 찾고, 평가 후보를 추려내는 데 매우 유용하지만, 사람이 먼저 무엇이 중요한지 정하고 데이터를 직접 보는 단계가 여전히 필요하다. 힐 클라이밍은 인간 피드백을 포함한 평가 신호로도 가능하며, prompts와 skills처럼 텍스트 기반 표면이 가장 다루기 쉽다.
15. 30:04
    Q&A: 열린 과제 채점하기 모호한 과제는 규칙이 명확한 binary rubric, 여러 모델의 교차 검증, 반복 측정, pairwise comparison으로 더 안정적으로 평가할 수 있다. 또한 평가 데이터는 특정 모델의 실패만 모은 편향된 분포보다, 생산에서 실제로 중요한 사례를 first principles로 고르는 편이 낫다.
16. 39:24
    Q&A: 낮은 effort에서 더 강한 모델이 더 싼 이유 효과적인 기본 전략은 더 강한 모델을 낮은 effort로 시작하는 것이며, 이는 종종 약한 모델을 높은 effort로 쓰는 것보다 토큰 효율이 좋다. effort는 hard cap이 아니라 생각 강도를 조절하는 신호이므로, 복잡한 문제에서만 더 많이 쓰고 단순한 문제에서는 과도한 생각을 피하는 편이 낫다.
17. 55:41
    Q&A: 매우 긴 작업에서 힐 클라이밍하기 변경 자체가 오래 걸리는 문제는 힐 클라이밍을 훨씬 어렵게 만들며, 그래서 장기 복구와 안정성이 되는 하네스가 더 중요해진다. 긴 멀티턴 작업에서는 traces를 바탕으로 평가를 만들고, 여러 단계의 결과나 최종 산출물을 함께 채점하는 구조가 유용하다.

실무 인사이트

• 가장 먼저 할 일은 새 모델에 맞지 않는 구식 프롬프트 패턴을 제거하는 것이며, 종종 이것만으로도 성능과 비용이 동시에 개선된다.
• 장기 에이전트는 모델 성능보다도 캐시 hit rate, 복구 가능성, 보안 설계가 총비용과 안정성을 좌우하므로 하네스 수준에서 관리해야 한다.
• 평가가 부실하면 힐 클라이밍은 생산 성능이 아니라 평가만 최적화하므로, 먼저 평가를 '오를 수 있게' 만드는 작업에 시간을 써야 한다.