"think" 도구: 복잡한 도구 사용 상황에서 Claude가 멈춰 서서 생각할 수 있게 하기

Claude의 복잡한 문제 해결 능력을 지속적으로 개선하는 과정에서, 특히 효과적인 접근법 하나를 발견했습니다. 바로 복잡한 작업 수행 중 구조화된 사고를 위한 전용 공간을 만들어 주는 "think" 도구입니다.

이 간단하지만 강력한 기법은—아래에서 자세히 설명하겠지만—Claude의 새로운 "확장 사고" 기능과는 다른 개념입니다(확장 사고 구현 세부 사항 참고). 이 기법을 적용한 결과, Claude의 에이전트 도구 활용 능력에서 눈에 띄는 개선을 확인할 수 있었습니다. 정책 준수, 일관된 의사결정, 다단계 문제 처리 등 다양한 영역에서 효과가 나타났으며, 구현 부담도 최소 수준입니다.

이 글에서는 검증된 벤치마크 결과를 바탕으로, 다양한 애플리케이션에서 "think" 도구를 구현하는 방법과 개발자를 위한 실용적인 가이드를 공유합니다.

"think" 도구란?

"think" 도구는 Claude가 최종 답변에 도달하는 과정에서 전용 공간을 갖춘 추가 사고 단계를 거칠 수 있도록 해주는 기능입니다.

확장 사고와 비슷해 보이지만, 실제로는 다른 개념입니다. 확장 사고는 Claude가 응답 생성을 시작하기 전에 수행하는 사고 과정입니다. 확장 사고에서 Claude는 행동에 옮기기 전에 계획을 깊이 검토하고 반복적으로 다듬습니다. 반면 "think" 도구는 응답 생성이 시작된 이후, 다음 단계로 넘어가기 전에 필요한 정보가 모두 확보되었는지 점검하기 위해 잠시 멈추고 생각하는 단계를 추가합니다. 이 기능은 도구 호출이 길게 이어지거나, 사용자와 여러 단계에 걸친 긴 대화를 나눌 때 특히 유용합니다.

따라서 "think" 도구는 사용자 쿼리만으로는 응답에 필요한 모든 정보를 확보할 수 없고, 외부 정보(예: 도구 호출 결과에 포함된 정보)를 처리해야 하는 경우에 더 적합합니다. "think" 도구를 통한 추론은 확장 사고만큼 포괄적이지는 않으며, 모델이 새롭게 발견한 정보를 처리하는 데 초점을 맞춥니다.

비순차적 도구 호출이나 단순한 지시 수행 같은 간단한 도구 사용 시나리오에는 확장 사고를 권장합니다. 또한 코딩, 수학, 물리학처럼 도구 호출 없이 작업하는 경우에도 확장 사고가 유용합니다. 반면 "think" 도구는 복잡한 도구를 호출해야 하거나, 긴 도구 호출 체인에서 출력을 꼼꼼히 분석해야 하거나, 세부 가이드라인이 많은 정책 중심 환경을 탐색해야 하거나, 이전 단계를 기반으로 순차적 의사결정을 내려야 해서 실수 비용이 큰 경우에 더 적합합니다.

다음은 τ-Bench에서 가져온 표준 도구 명세 형식을 사용한 구현 예시입니다:

{
  "name": "think",
  "description": "Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.",
  "input_schema": {
    "type": "object",
    "properties": {
      "thought": {
        "type": "string",
        "description": "A thought to think about."
      }
    },
    "required": ["thought"]
  }
}

τ-Bench 성능 결과

"think" 도구의 성능은 τ-bench(tau-bench)를 사용해 평가했습니다. τ-bench는 실제 고객 서비스 시나리오에서 모델의 도구 활용 능력을 테스트하기 위해 설계된 종합 벤치마크로, "think" 도구가 평가 표준 환경에 포함되어 있습니다.

τ-bench는 다음과 같은 Claude의 능력을 평가합니다:

• 시뮬레이션된 사용자와의 현실적인 대화 수행
• 복잡한 고객 서비스 에이전트 정책 가이드라인의 일관된 준수
• 다양한 도구를 활용한 환경 데이터베이스 접근 및 조작

τ-bench의 주요 평가 지표는 pass^k입니다. 이 지표는 주어진 작업에 대해 k번의 독립 시행이 모두 성공할 확률을 측정하며, 전체 작업에 대해 평균을 냅니다. 일반적인 LLM 평가에서 흔히 사용되는 pass@k 지표(k번 시행 중 최소 1회 성공 여부를 측정)와 달리, pass^k는 일관성과 신뢰성을 평가합니다. 이는 정책 준수의 일관성이 필수적인 고객 서비스 분야에서 매우 중요한 특성입니다.

성능 분석

평가에서는 다음과 같은 여러 구성을 비교했습니다:

1. 기본 구성 ("think" 도구 없음, 확장 사고 모드 없음)
2. 확장 사고 모드 단독 사용
3. "think" 도구 단독 사용
4. "think" 도구 + 최적화된 프롬프트 (항공 도메인)

벤치마크의 "항공"과 "리테일" 고객 서비스 도메인 모두에서, Claude 3.7이 "think" 도구를 효과적으로 활용했을 때 극적인 성능 향상을 보였습니다:

• 항공 도메인: "think" 도구에 최적화된 프롬프트를 결합한 구성이 pass^1 지표에서 0.570을 달성했습니다. 기본 구성의 0.370 대비 54%의 상대적 향상입니다.
• 리테일 도메인: "think" 도구 단독 사용만으로 0.812를 기록하여, 기본 구성의 0.783을 상회했습니다.

항공 도메인에서 가장 우수한 성능은 "think" 도구에 최적화된 프롬프트를 결합했을 때 나타났습니다. 이 프롬프트는 고객 요청을 분석할 때 활용할 추론 방식의 예시를 제공합니다. 아래는 최적화된 프롬프트의 예시입니다:

## Using the think tool

Before taking any action or responding to the user after receiving tool results, use the think tool as a scratchpad to:
- List the specific rules that apply to the current request
- Check if all required information is collected
- Verify that the planned action complies with all policies
- Iterate over tool results for correctness 

Here are some examples of what to iterate over inside the think tool:
<think_tool_example_1>
User wants to cancel flight ABC123
- Need to verify: user ID, reservation ID, reason
- Check cancellation rules:
  * Is it within 24h of booking?
  * If not, check ticket class and insurance
- Verify no segments flown or are in the past
- Plan: collect missing info, verify rules, get confirmation
</think_tool_example_1>

<think_tool_example_2>
User wants to book 3 tickets to NYC with 2 checked bags each
- Need user ID to check:
  * Membership tier for baggage allowance
  * Which payments methods exist in profile
- Baggage calculation:
  * Economy class × 3 passengers
  * If regular member: 1 free bag each → 3 extra bags = $150
  * If silver member: 2 free bags each → 0 extra bags = $0
  * If gold member: 3 free bags each → 0 extra bags = $0
- Payment rules to verify:
  * Max 1 travel certificate, 1 credit card, 3 gift cards
  * All payment methods must be in profile
  * Travel certificate remainder goes to waste
- Plan:
1. Get user ID
2. Verify membership level for bag fees
3. Check which payment methods in profile and if their combination is allowed
4. Calculate total: ticket price + any bag fees
5. Get explicit confirmation for booking
</think_tool_example_2>

특히 흥미로운 점은 각 접근법 간의 성능 차이입니다. "think" 도구에 최적화된 프롬프트를 결합한 구성은 확장 사고 모드 대비 크게 앞섰습니다(확장 사고 모드의 성능은 프롬프트 없이 "think" 도구만 사용한 경우와 비슷한 수준이었습니다). "think" 도구를 단독으로(프롬프트 없이) 사용해도 기본 구성보다 성능이 향상되었지만, 최적화된 프롬프트를 결합한 구성에는 미치지 못했습니다.

"think" 도구와 최적화된 프롬프트의 결합이 큰 격차로 최고 성능을 기록한 것은, 벤치마크의 항공 정책 파트가 높은 복잡도를 갖고 있어 "think" 방법에 대한 예시를 제공했을 때 모델이 가장 큰 효과를 얻었기 때문으로 보입니다.

리테일 도메인에서도 각 접근법의 구체적인 영향을 파악하기 위해 다양한 구성을 테스트했습니다.

"think" 도구는 별도의 프롬프트 없이도 pass^1 기준 0.812라는 가장 높은 점수를 기록했습니다. retail 정책은 airline 도메인에 비해 탐색 난이도가 눈에 띄게 낮아, Claude가 추가 지침 없이 사고 공간만 확보해도 성능이 향상되었습니다.

τ-Bench 분석에서 얻은 핵심 인사이트

상세 분석을 통해 "think" 도구를 효과적으로 활용하는 데 도움이 되는 몇 가지 패턴을 발견했습니다.

1. 어려운 도메인에서는 프롬프팅이 매우 중요합니다. "think" 도구를 단순히 추가하는 것만으로도 성능이 어느 정도 개선될 수 있지만, 최적화된 프롬프트와 함께 사용하면 어려운 도메인에서 훨씬 더 큰 폭의 성능 향상을 얻을 수 있습니다. 반면, 비교적 쉬운 도메인에서는 "think" 도구를 사용할 수 있게 해주는 것만으로도 충분한 효과를 볼 수 있습니다.
2. 시행 간 일관성 향상. "think" 도구를 사용한 성능 개선 효과는 k=5까지의 pass^k에서도 유지되었으며, 이는 해당 도구가 Claude의 엣지 케이스와 비정형 시나리오 처리 능력을 효과적으로 높여주었음을 시사합니다.

SWE-Bench 성능

Claude 3.7 Sonnet의 SWE-bench 평가에도 유사한 "think" 도구를 추가하여, 최고 수준의 점수인 0.623 달성에 기여했습니다. 적용된 "think" 도구 정의는 아래와 같습니다.

{
  "name": "think",
  "description": "Use the tool to think about something. It will not obtain new information or make any changes to the repository, but just log the thought. Use it when complex reasoning or brainstorming is needed. For example, if you explore the repo and discover the source of a bug, call this tool to brainstorm several unique ways of fixing the bug, and assess which change(s) are likely to be simplest and most effective. Alternatively, if you receive some test results, call this tool to brainstorm ways to fix the failing tests.",
  "input_schema": {
    "type": "object",
    "properties": {
      "thought": {
        "type": "string",
        "description": "Your thoughts."
      }
    },
    "required": ["thought"]
  }
}

실험 결과("think" 도구 포함 n=30, 미포함 n=144), "think" 도구의 단독 효과로 평균 1.6%의 성능 향상이 확인되었습니다(Welch의 t 검정: t(38.89) = 6.71, p < .001, d = 1.47).

"think" 도구를 사용해야 할 때

평가 결과를 바탕으로, Claude가 "think" 도구로부터 가장 큰 효과를 얻는 시나리오를 다음과 같이 정리했습니다.

1. 도구 출력 분석. 이전 도구 호출의 출력을 신중하게 처리한 뒤 행동해야 하고, 접근 방식을 되돌려야 할 수도 있는 경우
2. 정책 중심 환경. 세부 가이드라인을 따르고 규정 준수 여부를 검증해야 하는 경우
3. 순차적 의사결정. 각 행동이 이전 행동에 기반하며, 실수의 비용이 큰 경우(주로 다단계 도메인에서 발생)

구현 모범 사례

"think" 도구의 효과를 극대화하기 위해, τ-bench 실험에서 도출한 다음 구현 사례를 권장합니다.

1. 도메인 특화 예시를 활용한 전략적 프롬프팅

가장 효과적인 접근법은 "think" 도구를 언제, 어떻게 사용할지 명확한 지침을 제공하는 것입니다. τ-bench airline 도메인에 사용된 프롬프트가 좋은 예입니다. 실제 사용 사례에 맞춘 예시를 함께 제공하면 모델의 "think" 도구 활용 효과가 크게 높아집니다.

• 추론 과정에서 기대하는 상세 수준
• 복잡한 지시사항을 실행 가능한 단계로 분해하는 방법
• 일반적인 시나리오를 처리하기 위한 의사결정 트리
• 필요한 정보가 모두 수집되었는지 확인하는 방법

2. 복잡한 지침은 시스템 프롬프트에 배치

실험 결과, "think" 도구에 대한 지침이 길거나 복잡한 경우 도구 설명 자체에 넣는 것보다 시스템 프롬프트에 포함하는 것이 더 효과적이었습니다. 이렇게 하면 더 넓은 맥락이 제공되어 모델이 사고 과정을 전체적인 행동에 더 잘 통합할 수 있습니다.

"think" 도구를 사용하지 않아야 할 때

"think" 도구가 상당한 성능 향상을 가져올 수 있지만, 모든 도구 사용 시나리오에 적합한 것은 아니며 프롬프트 길이와 출력 토큰 증가라는 비용이 수반됩니다. 구체적으로, 다음과 같은 경우에는 "think" 도구의 효과가 없는 것으로 확인되었습니다.

1. 비순차적 도구 호출. Claude가 작업 완료를 위해 단일 도구 호출이나 여러 병렬 호출만 수행하면 되는 경우, "think" 도구 추가로 인한 개선 효과는 거의 없습니다.
2. 단순한 지시 수행. Claude가 준수해야 할 제약 조건이 많지 않고, 기본 동작만으로 충분히 좋은 결과를 내는 경우에도 추가적인 "think" 사용으로 인한 이점은 거의 없습니다.

시작하기

"think" 도구는 기존 Claude 구현에 간단히 추가할 수 있으며, 몇 단계만 거치면 의미 있는 성능 개선을 얻을 수 있습니다.

1. 에이전트 기반 도구 사용 시나리오에서 테스트하세요. Claude가 현재 정책 준수나 긴 도구 호출 체인에서의 복잡한 추론에 어려움을 겪는, 난이도가 높은 사용 사례부터 시작하세요.
2. 도구 정의를 추가하세요. 사용 중인 도메인에 맞게 커스터마이즈한 "think" 도구를 구현하세요. 최소한의 코드만 필요하며, 더 구조화된 추론이 가능해집니다. 또한 도구를 언제, 어떻게 사용할지에 대한 지침과 도메인에 적합한 예시를 시스템 프롬프트에 포함하는 것도 고려해 보세요.
3. 모니터링하고 개선하세요. Claude가 실제로 도구를 어떻게 사용하는지 관찰하고, 더 효과적인 사고 패턴을 유도하도록 프롬프트를 조정하세요.

이 도구의 가장 큰 장점은 성능 측면에서 추가에 따른 부작용이 거의 없다는 것입니다. Claude가 직접 사용하기로 결정하지 않는 한 외부 동작에 영향을 미치지 않으며, 기존 도구나 워크플로와도 충돌하지 않습니다.

결론

이번 연구를 통해 "think" 도구가 긴 도구 호출 체인에서 정책 준수와 추론이 필요한 복잡한 작업에서 Claude 3.7 Sonnet의 성능을 크게 향상¹시킬 수 있음을 확인했습니다. "think"가 모든 상황에 적합한 범용 솔루션은 아니지만, 적절한 사용 사례에서는 최소한의 구현 복잡도로 상당한 효과를 제공합니다.

여러분이 "think" 도구를 활용하여 Claude로 더 뛰어나고, 안정적이며, 투명한 AI 시스템을 구축해 나가시길 기대합니다.

1. τ-Bench 결과는 Claude 3.7 Sonnet에서의 "think" 도구 개선 효과에 초점을 맞추었지만, 실험 결과 Claude 3.5 Sonnet (New)도 동일한 구성에서 성능 향상을 달성할 수 있었습니다. 이는 이러한 개선 효과가 다른 Claude 모델에도 일반화될 수 있음을 시사합니다.