Claude의 지능을 제대로 쓰는 법

에이전트 프레임워크를 만들다 보면 빠지는 함정이 있습니다. Claude가 이미 할 수 있는 일을 위해 도구를 새로 만들고, Claude가 스스로 관리할 수 있는 것을 하네스에서 대신 관리하고, Claude의 능력이 올라가도 예전에 만든 우회 코드를 그대로 두는 것입니다. Anthropic의 Lance Martin이 쓴 이 글은 이 함정에서 벗어나는 세 가지 패턴을 제시합니다.

원문: Harnessing Claude's Intelligence (2026-04-02, Anthropic)

"키운 것이지 만든 것이 아니다"

글은 Anthropic 공동 창립자 Chris Olah의 통찰에서 시작합니다. 생성형 AI 시스템은 "만들어진 것이 아니라 키워진 것(grown more than they are built)"이라는 겁니다. 전통적 소프트웨어는 설계대로 동작하지만, AI 모델은 훈련을 통해 능력이 발현됩니다. 그래서 어제는 필요했던 우회 코드가 오늘은 성능을 깎는 죽은 무게(dead weight)가 됩니다.

예를 들어, Claude Sonnet 4.5에는 컨텍스트 한계에 가까워지면 작업을 조기 종료하는 "컨텍스트 불안(context anxiety)"이 있었습니다. 그래서 하네스에 컨텍스트 리셋 로직을 넣었습니다. 그런데 Opus 4.5에는 이 문제가 사라졌습니다. 리셋 로직이 오히려 성능을 방해하는 병목이 된 겁니다.

이런 일이 반복되니까, 지속적으로 "이 구조가 아직 필요한가?"를 물어야 합니다.

패턴 1: Claude가 이미 아는 것을 활용하라

첫 번째 패턴은 놀라울 정도로 단순합니다. 커스텀 도구를 만들기 전에, Claude가 이미 가진 도구로 충분한지 확인하라.

Claude 3.5 Sonnet이 SWE-bench Verified에서 49%(당시 최고)를 달성했을 때, 사용한 도구는 딱 두 개였습니다: bash 도구와 텍스트 편집기. 파일 시스템 탐색, 코드 수정, 테스트 실행을 전부 이 두 가지로 했습니다.

이 두 도구의 조합에서 더 복잡한 패턴이 자연스럽게 나타납니다: - Agent Skills: bash로 스킬 파일을 읽고 실행 - 프로그래매틱 도구 호출: bash 스크립트로 여러 도구를 연쇄 실행 - 메모리 도구: 파일 시스템에 컨텍스트를 저장하고 읽기

도구의 전문화보다 범용 도구의 조합 능력이 더 중요하다는 겁니다.

패턴 2: "내가 그만할 수 있는 건 뭔가?"

이 패턴이 글의 핵심입니다. 세 가지 하위 패턴으로 나뉩니다.

Claude에게 자체 오케스트레이션을 맡겨라

전통적인 에이전트는 모든 도구 결과를 Claude의 컨텍스트 윈도우로 돌려보냅니다. 테이블 하나의 특정 열만 보고 싶어도 전체 테이블이 컨텍스트에 들어갑니다. 토큰 낭비이고 지연 시간도 늘어납니다.

해결책: 코드 실행 도구를 줘서 Claude가 결과를 필터링하게 하라. Claude가 코드를 작성하고, 도구를 호출하고, 결과를 필터링한 뒤, 필요한 부분만 컨텍스트에 가져옵니다. "코드 실행의 출력만 Claude의 컨텍스트 윈도우에 도달합니다."

BrowseComp에서 Opus 4.6에 출력 필터링 능력을 주자 정확도가 **45.3% → 61.6%**로 16.3%p 올랐습니다.

Claude에게 자체 컨텍스트 관리를 맡겨라

수작업 시스템 프롬프트는 확장성이 없습니다. 모든 가능한 작업에 대한 지침을 미리 넣으면 "어텐션 예산"을 낭비하고, 드물게 쓰는 안내에 토큰을 쏟게 됩니다.

세 가지 해결책: - Skills 프레임워크: 짧은 YAML 설명만 컨텍스트에 두고, 필요할 때 전체 내용을 파일에서 읽기 - 컨텍스트 편집: 오래된 도구 결과나 사고 블록을 선택적으로 제거 - 서브에이전트: 격리된 작업을 위해 새 컨텍스트 윈도우 생성

BrowseComp에서 서브에이전트 사용 시 단일 에이전트 대비 2.8% 향상이 관찰되었습니다.

Claude에게 자체 컨텍스트 영속화를 맡겨라

컨텍스트 윈도우 한계를 넘는 작업에는 메모리 시스템이 필요합니다. 여기서 Claude의 자체 판단력이 중요합니다.

컴팩션(요약)의 모델별 성능 변화:

같은 컴팩션 메커니즘인데, 모델이 "무엇을 기억하고 무엇을 버릴지" 판단하는 능력이 올라가면서 성능이 2배 가까이 뛰었습니다.

메모리 폴더 방식도 있습니다. Claude가 파일에 컨텍스트를 저장하고 나중에 선택적으로 읽는 것입니다. BrowseComp-Plus에서 Sonnet 4.5의 정확도가 **60.4% → 67.2%**로 올랐습니다.

포켓몬 예시

글에서 가장 인상적인 부분입니다. 포켓몬 게임을 시키면:

Sonnet 3.5: 메모리를 NPC 대화 녹취록처럼 사용합니다. 14,000 스텝 후 31개 파일(캐터피 관련 중복 포함)을 가지고도 두 번째 마을에 있었습니다.

Opus 4.6: 같은 스텝 수에서 10개의 정리된 파일에 전술적 학습 내용을 기록하고, 체육관 배지 3개를 획득했습니다. 파일 내용: "Bellsprout Sleep+Wrap 콤보: Sleep Powder 전에 BITE로 빠르게 처치."

메모리를 어떻게 쓰느냐가 무엇을 기억하느냐보다 중요합니다.

패턴 3: 경계를 신중하게 설정하라

캐시 적중률을 극대화하라

Messages API는 무상태(stateless)입니다. 매 턴마다 전체 컨텍스트를 다시 보내야 합니다. 캐시된 토큰은 기본 입력 토큰의 10% 비용이므로 캐시 전략이 비용을 좌우합니다.

선언적 도구는 UX/보안/관찰성을 위해 사용하라

Bash 도구는 범용적이지만 하네스에는 커맨드 문자열만 노출됩니다. 전용 도구는 타입이 있는 인수를 제공해서 하네스가 가로채고, 게이트하고, 렌더링하고, 감사할 수 있습니다.

전용 도구로 승격해야 하는 경우: - 보안 경계: 되돌리기 어려운 작업 (외부 API 호출, 파괴적 연산) - 되돌림 검사: 최근 변경된 파일 덮어쓰기 방지 - 사용자 표시: 모달, 선택지, 확인 다이얼로그 - 관찰성: 구조화된 로깅, 트레이싱, 리플레이

하지만 "이 작업을 도구로 승격할지 여부는 지속적으로 재평가해야 한다"고 합니다. Claude Code의 auto 모드처럼, 두 번째 Claude가 bash 명령의 안전성을 검증하면 전용 도구의 필요성이 줄어듭니다.

이 글이 전달하는 메시지는 Advisor Strategy나 Claude Managed Agents와 같은 맥락에 있습니다.

"에이전트 프레임워크는 모델의 능력이 올라갈수록 얇아져야 한다."

하네스가 하는 일을 Claude에게 넘길수록 성능이 올라갑니다. 도구 결과 필터링을 넘기면 +16.3%p, 서브에이전트를 넘기면 +2.8%, 메모리 판단을 넘기면 43%→84%. 하네스의 역할은 Claude를 대신하는 것이 아니라, Claude가 잘 작동할 수 있는 경계를 설정하는 것입니다.

그리고 "내가 그만할 수 있는 건 뭔가?"라는 질문은 에이전트 개발자만의 것이 아닙니다. 프롬프트 엔지니어링에서도, 컨텍스트 엔지니어링에서도, 하네스 엔지니어링에서도 같은 질문이 유효합니다. 모델이 발전하면 어제의 해결책이 오늘의 병목이 됩니다. 지속적으로 가지치기하는 것이 좋은 에이전트 설계의 핵심입니다.