Lance Martin이 말하는 Claude 성능 개선법: 프롬프트 감사, 캐싱, 평가, 과적합 피하기

Martin은 비용과 품질을 보통 상충 관계로 본다고 말했습니다. 성능을 높이려면 더 많이 써야 하고, 비용을 줄이면 성능을 희생해야 한다는 인식입니다. 어떤 평가에서든 모델들은 그가 파레토 프론티어라고 부른 곡선을 이룹니다.

그러나 많은 애플리케이션은 실제로 이 프론티어 위에 있는 것이 아니라 그 안쪽에 놓여 있다고 그는 말했습니다. 그 원인은 사소한 설정 오류이며, 이를 고치는 방법을 보여주겠다고 했습니다.

그는 고객들에게서 이런 패턴을 반복해서 보았다고 말했습니다. 몇 가지 간단한 변경만으로 성능이 좋아지고 비용도 줄어들었다는 것입니다.

그는 다섯 가지 주제를 제시했고, 나머지 시간은 질의응답 형식으로 진행하겠다고 말했습니다. 첫 번째 주제는 프롬프트 감사였습니다.

Martin은 Claude Code에서 checkup prompt audit 명령을 실행할 수 있고, Claude API에도 prompt audit 기능이 있다고 말했습니다. 두 방식 모두 같은 기술을 기반으로 하며, Claude Code 작업 디렉터리의 스킬, 도구, 프롬프트 등을 감사합니다.

그의 시연에서는 마이그레이션만으로도 비용이 조금 줄고 성능이 약간 좋아졌습니다. 그 위에 프롬프트 감사를 실행하자 성능과 비용이 모두 추가로 개선되었다고 설명했습니다.

그는 이것이 명령이 검증 의식과 부스터를 제거했기 때문이라고 보았습니다. 그런 요소들이 Opus 5.5가 과도한 토큰을 쓰게 만들고 있었다는 것입니다. 또한 프론티어 모델을 혼란스럽게 하던 상충하는 프롬프트도 정리되었다고 말했습니다.

그는 Anthropic이 내부적으로 이 명령을 적극 사용하고 있으며 많은 고객이 좋아한다며 실행을 권했습니다. API를 통해서도, Claude Code 설정에서도 실행할 수 있다고 했습니다.

Martin은 Claude API의 build eval 명령을 언급했습니다. 데이터가 어디에 있든 상관없이 사용할 수 있고, 어떤 트레이싱 솔루션이든 가리킬 수 있다고 말했습니다. Claude Code에서는 스킬로도 쓸 수 있습니다.

그는 문제, 관심사, 원시 트레이스가 주어지면 이 스킬이 데이터를 보여주고 평가 방식을 보여주며, 채점기와 기준을 사용자와 함께 점검하면서 평가 세트를 만드는 과정을 안내한다고 설명했습니다. 관련 블로그 글도 언급했습니다.

좋은 평가의 기준으로 그는 세 가지를 들었습니다. 프론티어에서 개선 여지가 있어야 하고, 분산이 낮아야 하며, 더 많이 생각하거나 모델이 커질수록 점수가 예상대로 올라가야 한다는 것입니다.

힐 클라이밍은 Claude가 사람의 개입 없이 평가 결과를 보고 자율적으로 개선해 나가는 과정입니다. Martin은 최신 Claude 모델이 이 일을 매우 잘한다고 말했습니다. 좋은 평가만 만들면 Claude가 그 위에서 개선을 이어갈 수 있다는 것입니다.

다만 잘못될 수 있는 일이 많으며, 특히 평가 자체에 과적합되는 것이 문제라고 경고했습니다. 예를 들어 어떤 벤치마크 과제에 OCR이 필요하고 하네스가 이를 풀기 위해 OCR 도구를 추가했다면, 운영 환경에서는 그 도구가 없으므로 개선 효과가 사라진다고 설명했습니다. 평가의 분포에 맞춰져 버렸기 때문입니다.

그는 또 다른 흔한 사례로, 평가 예시에 특유한 표현에 맞춰 프롬프트를 조정하는 경우를 들었습니다. 힐 클라이밍에서 가장 큰 도전 과제가 바로 이 과적합이라고 말했습니다.

그는 실패 사례도 소개했습니다. 힐 클라이밍 후 평가 점수는 아주 좋아 보이지만 운영 환경에서는 성능이 전혀 좋아지지 않아, 토큰과 비용만 많이 낭비되는 경우입니다. 힐 클라이밍 명령은 평가를 테스트 세트와 학습 세트로 나눠 이를 줄이려 하지만 완벽하지 않으므로, 사람이 결과를 감사하고 무슨 일이 일어나고 있는지 이해해야 한다고 강조했습니다.

Martin은 힐 클라이밍을 비용 절감에도 적용할 수 있다고 말했습니다. 비용을 줄이라고 지시하면, 성능이 최소한 동등하면서 확실히 비용을 줄이는 구성을 찾습니다. 노력 수준, 모델 선택, 프롬프트를 탐색합니다.

고객 지원 벤치마크 예시에서 그는 Opus 4.8 high와 기본 프롬프트로 시작했습니다. 힐 클라이머는 모델과 노력 수준의 조합을 탐색하며, 성능 저하 없이 라운드를 거듭할수록 비용을 계속 줄이는 조합을 유지했습니다. Opus 5 low로 옮기자 성능이 크게 좋아지고 비용은 조금 줄었습니다.

이후 힐 클라이머는 자율적으로 5 low를 시도했는데, 성능은 약간 떨어졌지만 비용은 크게 줄었습니다. 그다음 프롬프트를 조정해 성능을 회복했습니다. 그 결과 비용은 약 90% 줄었고 성능은 눈에 띄게 좋아졌다고 말했습니다.

평가가 포화되어 성능이 더 이상 중요하지 않을 때도 이 방식이 통한다고 했습니다. 성능은 고정한 채 비용만 줄이라고 힐 클라이머에게 지시하면 된다는 것입니다.

Martin은 Claude Managed Agents가 Claude에게 비밀 정보에 직접 접근하도록 하지 않는다고 말했습니다. 비밀 정보는 다이어그램 상단의 도구 상자에 있는 볼트에 보관됩니다.

볼트 덕분에 Claude는 API 키나 비밀 정보를 참조할 수는 있지만 실제로 볼 수는 없습니다. 며칠씩 작업하는 에이전트에게 민감한 비밀 정보를 직접 접근하게 하는 것은 조금 섬뜩한 일이라고 말했습니다. 또한 에이전트가 몇 시간, 며칠, 어쩌면 몇 주씩 작동하게 되면서 신뢰성과 보안이 더 중요해진다고 덧붙였습니다.

평가 설계가 얼마나 자동화될 수 있는지 묻자, Martin은 Claude가 상당히 도움이 된다고 답했습니다. 사람들은 평가 설계에 훨씬 더 많은 시간을 쓰고 있으며, 주로 Claude가 효과적으로 힐 클라이밍할 수 있는 과제를 명시하는 데 시간을 쓴다고 했습니다.

그는 Hamel의 피드백을 소개했습니다. Hamel은 스킬이 먼저 사용자에게 데이터를 보여주며 안내해야 한다고 말했고, Martin도 동의하며 스킬을 수정하겠다고 했습니다. 고객 지원 예시에서 Claude는 트레이스를 훑어 실패 사례를 표시하는 데 능했는데, 이는 오프라인 로그를 훑는 온라인 평가자처럼 작동한 것이라고 설명했습니다.

그는 중간 단계가 중요하다고 말했습니다. 평가를 만들기 전에 Claude가 먼저 뷰어에 원시 데이터를 보여줘야 하며, 이를 추가하는 풀 리퀘스트를 올려 두었다고 했습니다. 예시를 평가 세트에 올리는 일은 여전히 사람이 한다고 덧붙였습니다.

Martin은 Claude가 반복되는 작업을 알아채고 이를 스킬로 만들자고 제안하는 데 능하다고 말했습니다. 그는 이런 일을 늘 한다며, 워크플로를 스킬로 바꾸라고 Claude에게 말하기만 하면 된다고 했습니다.

평가의 경우 흔한 방식은 상용구 텍스트가 있는 기존 스킬을 두고, 평가에서 더 좋은 성능을 내도록 Claude에게 개선을 요청하는 것입니다. 문서에서 추출한 Claude API 스킬 예시를 들었는데, 함정이 많아서 처음에는 평가 점수가 낮았다고 합니다. 그 출발점 덕분에 Claude가 스킬을 수정할 수 있었습니다.

Martin은 분포(distribution)란 평가에서 샘플링한 사례들이 실제 운영 환경에서 중요한 것을 대표하도록 만드는 것이라고 설명했습니다.

그는 적대적 샘플링을 경계하라고 했습니다. 특정 모델 계열이 실패하는 사례만 골라 담는 방식입니다. 모델은 들쭉날쭉하므로 Sonnet 5가 실패하는 예시를 Opus 5는 풀 수도 있고, 한 모델의 약점에 맞춘 평가는 모델을 업그레이드하면 맞지 않게 됩니다.

그래서 그는 한 모델의 실패 사례에서만 뽑지 말고, 제1원리로 보아 어렵거나 흥미로운 사례, 자신의 직관과 운영 데이터에서 얻은 사례를 우선 포함시키라고 권했습니다.

또한 0에서 10까지의 임의 척도로 채점하면 기준이 모호할 수 있고, 두 결과를 짝지어 비교하는 방식이 더 효과적일 수 있다고 말했습니다. 예를 들어 각 웹페이지를 0~5점으로 매기기보다 두 웹페이지 중 어느 쪽이 나은지 묻는 방식입니다.

Martin은 힐 클라이머가 수렴한다는 보장이 없으며, 자신도 멈춰 서는 경우를 자주 봤다고 말했습니다. 이를 해결하기 위해 그들은 대비책을 만들었습니다. 여러 라운드 동안 정체되면 남은 실패 사례를 군집화해 왜 실패하는지 알아내는 방식입니다.

그는 마지막 20%는 흔히 잘못된 채점 예시나 모호한 지시문이라서, 클라이머가 Claude가 더 잘할 수 없어서가 아니라 평가 구조가 나빠서 멈춰 있는 것이라고 말했습니다. 자신의 실행에서도 두 번째 단계가 멈췄고, 사례를 군집화하자 모호한 사례가 여럿 발견되어 다시 쓰였다고 했습니다.

또한 Claude는 UI와 시각화 화면을 만드는 데 매우 뛰어나므로, 맞춤형 문제라면 데이터를 들여다볼 앱을 저렴하게 만들 수 있다고도 말했습니다.

Martin은 effort 설정이 Claude가 얼마나 깊이 생각할지를 정한다고 설명했습니다. 낮은 effort는 덜 생각하게 하고, 올리면 더 깊이 생각하게 합니다. 그는 처음부터 max effort로 시작하면 토큰을 매우 많이 쓰므로, 더 작지만 똑똑한 모델을 낮은 effort로 시작해 필요할 때 올리는 편이 현명하다고 경고했습니다.

그는 Sonnet 5를 high effort로 쓰면 생각에 많은 토큰을 쓰지만, 더 똑똑한 모델을 낮은 effort로 쓰면 토큰이 적게 든다는 직관을 제시했습니다. 따라서 근본적으로 더 지능적인 모델을 낮은 effort로 쓰는 편이, 더 저렴한 모델을 높은 effort로 쓰는 것보다 토큰 효율이 좋고 결과적으로 더 저렴할 수 있습니다.

예산에 대해서는 힐 클라이밍용으로 예산을 정하면 스킬이 라운드별로 예산을 관리한다고 말했습니다. 또한 마지막 20%가 풀 수 없는 문제인 것처럼 잘못 설계된 평가는, 풀리지 않는 문제에 토큰을 많이 낭비하게 된다고 경고했습니다.

Martin은 생성형 UI 평가의 예를 들었습니다. 짝지은 판정기가 설정 A와 B 중 어느 것이 나은지 비교하고, 여러 번의 시행 결과를 모아 Elo 점수로 집계하는 방식입니다.

그는 떠올리지 못한 다른 예도 많지만, 사람들은 검색 작업, 글쓰기 작업, 트레이스 분류, 트레이스가 좋은지 나쁜지 판단하는 일에 LLM-as-judge를 늘 사용한다고 말했습니다.

또한 힐 클라이밍의 동기는 자동 연구(auto research)에서 왔다고 설명했습니다. 모델은 자기 교정에 매우 뛰어나므로, 명확하고 검증 가능한 목표가 있는 잘 구조화된 문제가 주어지면 그 목표에 맞춰 개선할 수 있다는 것입니다.

예시에서 Martin은 비용과 성능을 함께 최적화했습니다. 그는 Claude에게 여러 목표를 말해 주면 Claude가 이를 측정하고 고려한다고 말했습니다. 비용, 성능, 속도를 함께 측정하는 것은 합리적인 조합이었습니다.

그는 목표가 늘어날수록 Claude가 여러 목표를 동시에 조정해야 하므로 힐 클라이밍이 어려워진다고 말했습니다. 그래도 할 수는 있으며, 한 번에 하나씩 바꾸며 순차적으로 진행하는 방법도 있다고 덧붙였습니다.

그는 프롬프트 최적화가 시도하기 가장 간단하고 종종 매우 효과적인 방법이라고 말했습니다. 또한 최신 프런티어 모델이 어떤 안티패턴을 더 이상 필요로 하지 않는지는 정확히 알기 어렵지만, Opus 4.5 같은 모델에는 여전히 어느 정도 지침이 필요할 수 있다고 덧붙였습니다.

Martin은 이 과정이 학습(training)과 철학적으로 비슷하다고 말했습니다. 모델에 보상이나 목표를 주면 모델이 시스템을 수정해 그것을 개선한다는 점에서입니다. 학습에서 쓰는 학습/검증 분할 같은 관행도 여기에 적용됩니다.

차이는 이것이 모델 배포 후 프롬프트나 스킬을 실행 중에 수정하는 것이라서, 학습식 원칙을 자신의 도메인에 적용할 수 있다는 점입니다.

Claude가 평가받고 있다는 것을 아는지에 대한 질문에는, 이는 학습 과정에서 이미 다뤄진 우려라고 답했습니다. 다만 이 맥락에서는 더 큰 우려가 과적합이라고 말했습니다. Claude가 평가를 받고 있다는 것을 알 수도 있지만, 평가 분포에 따라 목표를 우회하는 방법, 즉 운영 환경에는 적용되지 않는 프롬프트 트릭을 찾아낼 수 있다는 것입니다.

Martin은 에이전트를 만들 때는 보통 다중 턴 평가가 필요하다고 말했습니다. 인프라 부담, 발생하는 실패, 신호를 얻기까지 걸리는 긴 시간 때문에 더 어렵다는 것입니다.

그는 평가 구축 명령이 트레이스를 살펴보고 특정 트레이스를 평가 세트로 올리는 데 도움을 줄 수 있다고 말했습니다. 채점에는 여러 철학이 있으며, 평가자가 전체 궤적을 볼 수도 있고 에이전트의 최종 결과만 볼 수도 있습니다.

컨텍스트 엔지니어링에 대해서는, 신뢰성의 핵심은 두뇌와 손을 분리하는 것이라고 말했습니다. 컨텍스트 객체가 하네스와 독립되어 있어서 하네스가 그 컨텍스트를 조회할 수 있다는 것입니다. 그들도 자신들의 작업에서 이 아이디어를 쓰고 있다고 했습니다.

모델이 계속 좋아지는 동안 평가를 어떻게 수정해야 하는지 묻자, Martin은 모델이 나아지면 도표처럼 평가 점수도 올라가야 한다고 답했습니다. 오르지 않는다면 평가 구조를 다시 의심해 봐야 한다는 것입니다.

그는 모델은 평가를 매우 빠르게 포화시키므로 새롭고 더 어려운 평가를 계속 만들어야 하며, 오늘날 최고 모델을 도전하게 만드는 평가를 만드는 일이 실제로 어렵다고 말했습니다.

그의 핵심은, 오래전에 만든 평가가 있다면 점수가 오르는 것을 봐야 하고, 그렇지 않다면 평가 자체를 의심해야 한다는 것이었습니다.