Claude의 지능을 제대로 활용하는 법

Anthropic의 공동창업자 Chris Olah는 Claude와 같은 생성형 AI 시스템은 만들어지는 것이 아니라 자라나는 것이라고 말합니다. 연구자들은 성장의 방향을 잡아주는 조건을 설정하지만, 어떤 구조나 능력이 발현될지는 항상 예측할 수 있는 게 아닙니다.

여기서 Claude 기반 서비스 구축의 어려움이 생깁니다. 에이전트 하네스(agent harness)에는 Claude가 스스로 할 수 없는 것에 대한 가정이 녹아 있는데, Claude가 점점 더 유능해질수록 그 가정들은 금세 낡아버립니다. 이 글처럼 공유되는 내용도 주기적으로 다시 검토할 필요가 있습니다.

이 글에서는 Claude의 발전하는 지능에 발맞추면서도 지연 시간과 비용의 균형을 유지하는 세 가지 패턴을 소개합니다. Claude가 이미 알고 있는 것을 활용하고, 더 이상 하지 않아도 되는 것이 무엇인지 파악하고, 에이전트 하네스의 경계를 신중하게 설정하는 것입니다.

1. Claude가 아는 것을 활용하라

서비스를 구축할 때는 Claude가 잘 이해하는 도구를 중심으로 설계하길 권합니다.

2024년 말, Claude 3.5 Sonnet는 bash 도구와 파일을 조회·생성·편집하는 텍스트 에디터 도구만으로 SWE-bench Verified에서 당시 최고 수준인 49%를 달성했습니다. Claude Code도 바로 이 도구들을 기반으로 합니다. Bash는 에이전트 개발을 위해 설계된 것이 아니지만, Claude가 능숙하게 다룰 줄 아는 도구이며 시간이 지날수록 더 잘 활용하게 됩니다.

Claude가 이 범용 도구들을 조합해 다양한 문제를 해결하는 패턴을 만들어내는 것을 확인할 수 있었습니다. 예를 들어 에이전트 스킬(Agent Skills), 프로그래밍 방식의 도구 호출(programmatic tool calling), 메모리 도구(memory tool)는 모두 bash와 텍스트 에디터 도구의 조합으로 구현됩니다.

2. '무엇을 그만해도 될까?'를 질문하라

에이전트 하네스에는 Claude가 스스로 할 수 없는 것에 대한 가정이 내포되어 있습니다. Claude가 더 유능해질수록 그 가정들을 다시 검증해야 합니다.

Claude가 스스로 행동을 조율하도록 하라

흔히 있는 가정 중 하나는, 다음 행동을 결정하기 위해 모든 도구 결과를 Claude의 컨텍스트 윈도우(context window)로 다시 전달해야 한다는 것입니다. 하지만 도구 결과를 토큰으로 처리하는 것은 느리고 비용도 많이 드는 데다, 단순히 다음 도구로 넘기거나 결과의 일부만 필요한 경우라면 불필요한 작업입니다.

예를 들어, 특정 컬럼 하나를 분석하기 위해 대용량 테이블을 읽는 경우를 생각해보면, 테이블 전체가 컨텍스트에 올라오고 Claude는 필요 없는 모든 행에 대한 토큰 비용을 치러야 합니다. 하드코딩된 필터를 도구 설계에 적용해 이를 해결할 수도 있지만, 근본적인 문제는 남습니다. Claude가 더 잘 판단할 수 있는 오케스트레이션 결정을 에이전트 하네스가 대신 내리고 있다는 점입니다.

Claude에게 코드 실행(code execution) 도구(예: bash 도구 또는 언어별 REPL)를 제공하면 이 문제를 해결할 수 있습니다. Claude가 직접 코드를 작성해 도구 호출과 그 사이의 로직을 표현할 수 있기 때문입니다. 하네스가 모든 도구 호출 결과를 토큰으로 처리하는 것이 아니라, Claude가 컨텍스트 윈도우를 거치지 않고 어떤 결과를 넘기고, 필터링하고, 다음 호출로 파이핑할지 스스로 결정합니다. 컨텍스트 윈도우에는 코드 실행의 최종 출력만 도달합니다.

오케스트레이션 결정권이 하네스에서 모델로 넘어오게 됩니다. 코드는 Claude가 행동을 조율하는 범용적인 수단이기 때문에, 코딩 능력이 뛰어난 모델은 곧 범용 에이전트로서도 강력한 성능을 발휘합니다. 실제로 이 패턴을 적용했을 때 코딩과 무관한 평가에서도 Claude는 좋은 성과를 보였습니다. 에이전트의 웹 브라우징 능력을 측정하는 벤치마크인 BrowseComp에서, Opus 4.6에게 자체 도구 출력을 필터링하는 기능을 부여하자 정확도가 45.3%에서 61.6%로 상승했습니다.

Claude가 스스로 컨텍스트를 관리하도록 하라

태스크별 컨텍스트는 bash나 텍스트 에디터 도구 같은 범용 도구의 활용 방식을 결정합니다. 시스템 프롬프트는 태스크별 지침을 담아 수작업으로 작성해야 한다는 가정이 흔히 존재합니다. 하지만 프롬프트에 지침을 미리 채워 넣는 방식은 다양한 태스크에 적용하기 어렵습니다. 토큰이 추가될수록 Claude의 어텐션 예산이 소모되고, 거의 사용되지 않는 지침까지 미리 불러오는 것은 낭비입니다.

Claude에게 스킬(skills)에 접근하는 기능을 부여하면 이 문제를 해결할 수 있습니다. 각 스킬의 YAML 프론트매터에는 스킬 내용을 간략히 설명하는 짧은 설명이 담겨 컨텍스트 윈도우에 미리 로드됩니다. 태스크에 스킬이 필요한 경우, Claude가 파일 읽기 도구를 호출해 전체 스킬 내용을 점진적으로 불러올 수 있습니다.

스킬이 Claude에게 컨텍스트 윈도우를 직접 구성할 자유를 준다면, 컨텍스트 편집(context editing)은 그 반대입니다. 오래된 도구 결과나 thinking 블록처럼 낡아버리거나 더 이상 필요 없는 컨텍스트를 선택적으로 제거하는 방법입니다.

서브에이전트(subagents)를 활용할 때, Claude는 특정 태스크를 분리해 처리하기 위해 새 컨텍스트 윈도우로 분기해야 하는 시점을 점점 더 잘 판단하고 있습니다. Opus 4.6에서는 서브에이전트 생성 능력이 향상되어 BrowseComp 결과가 단일 에이전트 최고 성능 대비 2.8% 개선되었습니다.

Claude가 스스로 컨텍스트를 유지하도록 하라

장기 실행 에이전트는 단일 컨텍스트 윈도우의 한계를 초과할 수 있습니다. 일반적으로 메모리 시스템은 모델 외부의 검색 인프라에 의존해야 한다고 가정합니다. 우리는 Claude가 어떤 내용을 저장할지 스스로 선택할 수 있도록 간단한 방법을 제공하는 데 많은 노력을 기울여 왔습니다.

예를 들어, 컴팩션(compaction)은 Claude가 장기 태스크에서 연속성을 유지하기 위해 이전 컨텍스트를 요약할 수 있게 해줍니다. 여러 버전을 거치면서 Claude는 무엇을 기억해야 할지 더 잘 판단하게 되었습니다. 에이전트 검색 태스크인 BrowseComp에서 Sonnet 4.5는 컴팩션 예산을 얼마나 주든 43%에 머물렀지만, Opus 4.5는 동일한 설정으로 68%까지, Opus 4.6는 84%까지 성능이 향상되었습니다.

메모리 폴더(memory folder)도 또 다른 접근 방식입니다. Claude가 컨텍스트를 파일로 저장하고 필요할 때 다시 읽어올 수 있도록 합니다. 에이전트 검색에 이 방식을 활용하는 것을 확인했습니다. BrowseComp-Plus에서 Sonnet 4.5에 메모리 폴더를 제공하자 정확도가 60.4%에서 67.2%로 향상되었습니다.

포켓몬과 같은 장기 게임은 Claude의 메모리 폴더 활용 능력이 얼마나 발전했는지 잘 보여줍니다. Sonnet 3.5는 메모리를 일지처럼 활용해, 실제로 중요한 정보보다 NPC(non-player character, 비플레이어 캐릭터)가 한 말을 그대로 기록했습니다. 14,000 스텝 이후에도 여전히 두 번째 마을에 머물렀고, 애벌레 포켓몬에 관한 거의 중복된 파일 두 개를 포함해 총 31개의 파일이 쌓여 있었습니다.

caterpie_weedle_info:
- Caterpie and Weedle are both caterpillar Pokémon.
- Caterpie is a caterpillar Pokémon that does not have poison.
- Weedle is a caterpillar Pokémon that does have poison.
- This information is crucial for future encounters and battles.
- If our Pokémon get poisoned, we should seek healing at a Pokémon
  Center as soon as possible.

이후 모델들은 전술적 메모를 작성하기 시작했습니다. Opus 4.6는 같은 스텝 수에서 파일 10개를 디렉토리별로 정리했고, 체육관 배지 3개를 획득했으며, 자신의 실패에서 추출한 학습 파일까지 보유하고 있었습니다.

/gameplay/learnings.md:
- Bellsprout Sleep+Wrap combo: KO FAST with BITE before Sleep
  Powder lands. Don't let it set up!
- Gen 1 Bag Limit: 20 items max. Toss unneeded TMs before dungeons.
- Spin tile mazes: Different entry y-positions lead to DIFFERENT
  destinations. Try ALL entries and chain through multiple pockets.
- B1F y=16 wall CONFIRMED SOLID at ALL x=9-28 (step 14557)

3. 경계를 신중하게 설정하라

에이전트 하네스는 UX, 비용, 보안을 강제하기 위해 Claude 주변에 구조를 제공합니다.

캐시 히트를 최대화하는 컨텍스트 설계

Messages API는 무상태(stateless)입니다. Claude는 이전 턴의 대화 히스토리를 볼 수 없습니다. 따라서 에이전트 하네스는 매 턴마다 새 컨텍스트와 함께 과거의 모든 행동 기록, 도구 설명, 지침을 함께 묶어 Claude에게 전달해야 합니다.

프롬프트는 지정된 브레이크포인트(breakpoints)를 기준으로 캐싱됩니다. 즉, Claude API는 브레이크포인트까지의 컨텍스트를 캐시에 기록하고, 이전 캐시 항목과 일치하는지 확인합니다.

캐시된 토큰의 비용은 기본 입력 토큰의 10% 수준이기 때문에, 에이전트 하네스에서 캐시 히트를 최대화하기 위한 몇 가지 원칙을 소개합니다.

UX, 관찰 가능성, 보안 경계를 위한 선언적 도구 활용

Claude는 애플리케이션의 보안 경계나 UX 구조를 항상 파악하고 있지는 않습니다. Claude는 도구 호출을 내보내고, 하네스가 이를 처리합니다. bash 도구는 Claude에게 광범위한 프로그래밍 방식의 실행 권한을 부여하지만, 하네스 입장에서는 모든 행동이 동일한 형태의 커맨드 문자열로만 전달됩니다. 특정 행동을 전용 도구로 격상하면, 하네스는 타입이 지정된 인수를 통해 해당 행동을 가로채거나, 승인하거나, 렌더링하거나, 감사할 수 있는 행동별 훅(hook)을 갖게 됩니다.

보안 경계가 필요한 행동은 전용 도구의 자연스러운 후보입니다. 되돌리기 어려운 행동인지 여부가 좋은 판단 기준이 되며, 외부 API 호출처럼 번복하기 어려운 행동에는 사용자 확인 단계를 추가할 수 있습니다. edit 같은 쓰기 도구에는 스탈니스 검사(staleness check)를 포함해, Claude가 마지막으로 읽은 이후 변경된 파일을 덮어쓰지 않도록 할 수 있습니다.

도구는 사용자에게 행동을 보여줄 때도 유용합니다. 예를 들어 모달로 렌더링해 질문을 명확하게 표시하거나, 여러 선택지를 제공하거나, 사용자 피드백이 올 때까지 에이전트 루프를 멈추는 데 활용할 수 있습니다.

마지막으로, 도구는 관찰 가능성 측면에서도 유용합니다. 행동이 타입이 지정된 도구로 표현될 때, 하네스는 로깅, 추적, 재현이 가능한 구조화된 인수를 얻게 됩니다.

특정 행동을 전용 도구로 격상할지에 대한 결정은 지속적으로 재검토해야 합니다. 예를 들어 Claude Code의 자동 모드(auto-mode)(게시 시점 기준 리서치 모드)는 bash 도구에 보안 경계를 추가합니다. 두 번째 Claude가 커맨드 문자열을 읽고 안전 여부를 판단하는 방식입니다. 이 패턴은 전용 도구의 필요성을 줄여줄 수 있으며, 사용자가 전반적인 방향을 신뢰하는 태스크에만 적용하는 것이 좋습니다. 물론 특정 고위험 행동에는 전용 도구가 여전히 제 역할을 합니다.

앞으로의 방향

Claude의 지능은 끊임없이 발전하고 있습니다. Claude가 할 수 없다고 가정했던 것들은 능력이 크게 도약할 때마다 다시 검증해야 합니다.

이런 패턴은 반복해서 나타납니다. 장기 태스크용으로 개발한 에이전트에서, Sonnet 4.5는 컨텍스트 한도가 가까워지면 조기에 작업을 마무리하려 했습니다. 이른바 '컨텍스트 불안' 현상을 해결하기 위해 컨텍스트 윈도우를 초기화하는 리셋 기능을 추가했습니다. 그런데 Opus 4.5에서는 그 행동 자체가 사라져 있었습니다. 이를 보완하려고 만들었던 컨텍스트 리셋이 에이전트 하네스의 불필요한 짐이 된 것입니다.

이런 불필요한 요소를 제거하는 것이 중요한 이유는, 그것이 Claude의 성능을 병목시킬 수 있기 때문입니다. 시간이 지날수록 애플리케이션의 구조와 경계는 이 질문을 기준으로 계속 정리해 나가야 합니다. 지금 내가 하지 않아도 되는 것은 무엇인가?

여기서 소개한 모든 도구와 패턴을 직접 활용해보려면 claude-api 스킬을 확인해보세요.

감사의 말

Claude Platform 팀 기술 스태프 멤버 Lance Martin이 작성했습니다. 다룬 주제들에 대해 유익한 논의를 나눠준 Thariq Shihipar, Barry Zhang, Mike Lambert, David Hershey, Daliang Li에게 깊이 감사드립니다. 편집 검토와 피드백을 제공해준 Lydia Hallie, Lexi Ross, Katelyn Lesse, Andy Schumeister, Rebecca Hiscott, Jake Eaton, Pedram Navid, Molly Vorwerck에게도 감사드립니다.