목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 3월 20일 게재된 “The ’think’ tool: Enabling Claude to stop and think in complex tool use situations” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/claude-think-tool
한 줄로 말하면 #
도구를 길게 쓰는 작업 중간에, 클로드에게 ‘잠깐 생각할 빈 종이’ 한 장을 쥐여주는 것만으로 정확도가 크게 오른다.
어떤 문제를 해결하려 했나 #
항공사 고객센터 챗봇을 떠올려봅시다. 손님이 이렇게 말합니다.
“다음 주 출장 항공권 취소하고, 그 돈으로 다른 날짜 항공권을 새로 끊어줘요. 마일리지도 적립되게 해주세요.”
이 한 줄을 처리하려면 클로드는 여러 도구를 차례로 호출해야 합니다. 예약 조회 → 취소 규정 확인 → 환불 가능 여부 판단 → 새 항공편 검색 → 결제 → 마일리지 적립. 도구 하나가 결과를 돌려주면, 그걸 보고 다음 행동을 결정해야 합니다.
문제는 여기서 생깁니다. 클로드가 도구 결과를 받자마자 곧바로 다음 도구를 호출해버리면, 중간에 “이 환불이 회사 정책에 맞나?”, “손님이 요청한 정보가 다 모였나?” 같은 점검을 건너뛰게 됩니다. 그 결과, 정책에 어긋난 조치를 하거나 빠뜨린 정보를 그냥 넘어가버립니다.
사람이 일할 때는 결과를 받을 때마다 잠깐 멈춰서 메모지에 적어가며 생각하잖아요. 클로드에게는 그 메모지가 없었습니다.
해결책: think 도구 #
Anthropic은 놀랍도록 단순한 답을 내놨습니다. “생각만 적는 도구” 를 하나 더 만든 거예요.
1. 어떻게 생긴 도구인가 #
코드로 보면 이렇게 짧습니다.
{
"name": "think",
"description": "생각할 거리를 적는 데 쓰는 도구. 정보를 가져오거나 DB를 바꾸지 않고, 그냥 생각을 로그에 추가만 한다.",
"input_schema": {
"type": "object",
"properties": {
"thought": {
"type": "string",
"description": "생각할 내용"
}
},
"required": ["thought"]
}
}이 도구는 아무것도 하지 않습니다. 외부 API를 부르지도, 데이터베이스를 바꾸지도 않아요. 클로드가 이 도구를 부르면, 적은 내용이 그대로 로그에 남을 뿐입니다.
그런데 이 ‘아무것도 안 하는 도구’가 큰 차이를 만듭니다. 도구 결과를 받은 직후에 think를 호출하게 하면, 클로드는 다음 행동을 정하기 전에 한 번 정리하는 단계를 강제로 거치게 됩니다.
[기존 흐름]
도구 결과 → 즉시 다음 도구 호출 → ...
[think 도구 추가 후]
도구 결과 → think("이 결과로 뭘 해야 하지?") → 다음 도구 호출2. Extended Thinking과는 뭐가 다른가 #
Anthropic에는 이미 Extended Thinking(확장 추론) 이라는 기능이 있습니다. 헷갈리기 쉽지만 둘은 일하는 시점이 다릅니다.
| 구분 | think 도구 | Extended Thinking |
|---|---|---|
| 동작 시점 | 응답을 만드는 도중 | 응답을 시작하기 전 |
| 잘 맞는 작업 | 도구 결과 보고 다음 판단 | 미리 전체 계획 짜기 |
| 대표 예시 | 정책 따져가며 처리하는 고객지원 | 코딩, 수학 문제 풀이 |
쉽게 말하면, Extended Thinking은 출발 전에 지도를 펴고 경로를 다 그리는 것이고, think 도구는 길을 가다가 갈림길에서 잠깐 멈춰 생각하는 것입니다. 도구 호출이 길게 이어지면서 매 단계마다 판단이 필요한 작업에는 think 도구가 더 잘 맞습니다.
3. 시스템 프롬프트에 가이드를 함께 줘야 한다 #
think 도구만 던져준다고 클로드가 알아서 잘 쓰지는 않습니다. 언제, 어떻게 쓸지를 시스템 프롬프트에 함께 적어줘야 효과가 제대로 납니다.
항공사 도메인에서 Anthropic이 사용한 가이드 예시는 이렇습니다.
도구 결과를 받은 후, 행동을 취하거나 사용자에게 응답하기 전에
think 도구를 메모지처럼 사용해서 다음을 점검하세요:
- 이 요청에 적용되는 구체적 규칙 나열
- 필요한 정보가 모두 모였는지 확인
- 계획한 행동이 모든 정책에 부합하는지 검증도구 자체는 단순하게 두고, 사용 방법은 시스템 프롬프트에 길게 적는 것 — 이게 권장되는 패턴입니다.
결과 / 효과 #
항공사 도메인 (τ-bench) #
| 설정 | 점수(pass¹) | 기준 대비 |
|---|---|---|
| 기본 (도구 없음) | 0.370 | 기준 |
| think 도구만 | 0.404 | +9% |
| Extended Thinking | 0.412 | +11% |
| think + 최적화 프롬프트 | 0.570 | +54% |
핵심은 마지막 줄입니다. think 도구를 그냥 붙이는 것보다, 시스템 프롬프트에 사용 가이드를 함께 적은 경우 성능이 확연히 올랐습니다.
소매 도메인 (τ-bench) #
| 설정 | 점수(pass¹) |
|---|---|
| 기본 | 0.783 |
| Extended Thinking | 0.770 |
| think 도구 (가이드 없이) | 0.812 |
소매 쪽은 가이드 없이 think 도구만 붙여도 가장 높았습니다. 도메인마다 최적 설정이 다를 수 있다는 뜻입니다.
소프트웨어 엔지니어링 (SWE-Bench) #
평균 1.6% 개선이라는 작아 보이는 수치지만, 통계적으로 매우 유의미했고 (p < 0.001) Claude 3.7 Sonnet이 0.623이라는 SOTA 점수를 찍는 데 기여했습니다.
언제 쓰고, 언제 쓰지 말아야 하나 #
쓸수록 좋은 도구는 아닙니다. 프롬프트가 길어지고 출력 토큰이 늘어나는 비용이 따라옵니다.
쓰면 좋은 경우:
- 도구 결과를 받아서 다음 행동을 정해야 할 때
- 정책·규칙을 따져가며 처리해야 하는 고객지원
- 단계마다 판단이 누적되는 다단계 작업
굳이 안 써도 되는 경우:
- 도구 호출이 한 번이거나, 서로 독립적이라 병렬로 돌릴 때
- 제약이 별로 없는 단순 지시 수행
핵심 결론 #
클로드가 복잡한 도구 작업을 잘 못한다고 느꼈을 때, 많은 사람은 더 큰 모델을 쓰거나 프롬프트를 길게 다듬는 쪽으로 갑니다. Anthropic이 보여준 답은 다릅니다.
“모델 능력의 문제인 줄 알았는데, 사실은 모델이 멈춰서 생각할 자리가 없는 게 문제였다.”
빈 종이 한 장 쥐여주는 것 — 이게 54% 개선의 비결입니다.
내 작업에 적용한다면 #
think 도구의 핵심은 단계 사이에 멈춰 점검하는 습관을 시스템에 넣는 것입니다. 두 가지 일반적인 작업 흐름에 적용해봅니다.
시나리오 1 — 일반적인 데이터 분석 과정 #
데이터 분석은 단계마다 잘못된 가정이 다음 단계로 그대로 흘러들어가기 쉬운 작업입니다. 모델링까지 가서야 “어, 데이터가 이상한데?“를 깨닫는 일이 흔합니다.
[기존 흐름]
데이터 적재 → 정제 → EDA → 모델링 → 결과 해석
[think 도구 적용 후]
데이터 적재
↓ think("결측치·이상치 분포가 분석 가능한 수준인가? 추가 수집 필요?")
정제
↓ think("분석 의도와 어긋나는 행을 실수로 버리지 않았나?")
EDA(탐색적 데이터 분석)
↓ think("이 변수 관계가 우연인지, 근거 있는 패턴인지 가설을 세웠나?")
모델링
↓ think("성능 수치가 데이터 누수(leakage) 때문은 아닌가?")
결과 해석핵심은 “다음 단계로 넘어가기 전에 한 번 멈추는 습관” 입니다. 숙련된 분석가는 무의식적으로 하는 일이지만, 자동화 파이프라인에 think를 명시적으로 넣어두면 빠뜨리지 않습니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
콘텐츠를 자동으로 수집·생성해서 발행하는 사이트일수록 사람이 안 보는 단계의 검증이 중요합니다. 문제가 터진 뒤 발견하면 이미 수많은 페이지가 잘못 나간 뒤예요.
[기존 흐름]
소스 수집 → 콘텐츠 생성 → 검수 → 배포 → 모니터링
[think 도구 적용 후]
소스 수집
↓ think("출처가 신뢰 가능한가? 이미 발행한 내용과 중복은 아닌가?")
콘텐츠 생성
↓ think("스타일 가이드를 준수했나? 사실관계는 맞는가?")
검수
↓ think("SEO·접근성·법적 문제는 없는가?")
배포
↓ think("문제가 생기면 롤백 가능한 상태로 배포되었나?")
모니터링자동화의 함정은 “잘 굴러간다는 착각” 입니다. think를 단계 사이에 두면 사람이 직접 보지 않아도 매 단계마다 한 번씩 자가 검증이 강제로 일어납니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
