AIREITERClaude가 "almost done thinking" 상태에 있고 뭔가 고장 난 건지 궁금하다면 — 고장 난 게 아닙니다. 이 상태는 Claude가 extended thinking(추론 모드) 중이라는 뜻입니다: 글을 쓰기 시작하기 전에 답변을 계획하고 있는 것입니다. 몇 초, 심지어 20–30초 정도 걸리는 것은 정상입니다. 정상적이지 않은 것은 아무 응답 없이 몇 분씩 기다리는 것입니다. 이것들은 서로 다른 두 가지 문제이며, 이 가이드는 이를 구분하고 각각에 대한 해결책을 알려줍니다.
"거의 생각을 마쳤다"는 것이 실제로 의미하는 바
"거의 다 생각했어요"는 Claude가 확장 추론 단계를 실행하는 동안 표시하는 라벨입니다. 모델은 토큰 단위로 바로바로 응답하는 대신, "thinking" 토큰 예산을 사용해 계획을 세운 다음 보이는 답변을 생성합니다. 이는 Claude Code의 "thinking with high effort"와 Claude 앱의 추론 표시기 뒤에 있는 것과 동일한 메커니즘입니다.
가장 명확하게 이해하는 방법은 이 표현이 오류가 아니라 진행 신호라는 것입니다. r/ClaudeCode 스레드에서 말하듯, 확장 추론 일시 중지는 "서버 문제가 아니라 실행 전에 Claude가 계획하는 것"입니다. 따라서 claude almost done thinking이 보이면, 모델은 작업 중인 것이며 — 유일한 질문은 그것이 너무 오래 작업하고 있는지 여부입니다.
대략적인 기준선은 다음과 같습니다:
몇 초에서 약 30초의 사고 시간 → 특히 어려운 추론이나 코딩 작업에서는 정상입니다.
출력 없이 몇 분이 반복됨 → 뭔가 잘못된 것입니다. 아래 수정 방법으로 건너뛰세요.
왜 이렇게 오래 걸리는지(또는 아예 멈춰 버리는지)
느려짐과 실제 멈춤은 서로 다른 원인을 가집니다. 느린 경우에는 다음 세 가지가 원인입니다:
확장적 사고 깊이. 빠른 조회에서는 Claude가 작업에 필요한 것보다 더 많은 추론 노력을 기울이는 경향이 있을 수 있습니다. 질문에 굳이 필요하지 않은데도 그것에 대해 열심히 "생각"합니다.
순차적 도구 호출. 에이전트식 사용(Claude Code)에서는 벽시계 기준 시간의 대부분이 모델의 추론이 아니라 도구 호출에 쓰입니다. Claude Code 지연 시간에 대한 한 분석에서는 각 파일 읽기, 검색, 또는 테스트 실행이 동기식 왕복으로 대략 300–800ms 걸리는 것으로 측정했으며, 기본적으로 병렬로 실행되지 않는다고 지적합니다. 따라서 탐색적 호출이 열두 번 이상 발생하는 모호한 프롬프트는 실제 작업이 시작되기 전에 이러한 왕복 시간을 10초 이상으로 누적시킵니다.
컨텍스트 비대화. 전체 대화 기록이 매 턴마다 모델에 다시 전송됩니다. 세션이 채워질수록 응답은 느려지고 품질은 떨어집니다. 동일한 분석에서는 세션이 컨텍스트 창의 대략 60%를 넘어서면 눈에 띄는 속도 저하가 발생한다고 관찰했지만, 정확한 지점은 달라질 수 있습니다(대화 깊숙이 묻힌 세부 사항에서 나타나는 "중간에 잊어버리는" 효과입니다).
진짜 멈춤(hang)은 별도의 장애입니다. 추적된 Claude Code 이슈(#32526)에서는 새 세션이 "thinking"에서 멈추고 절대 출력을 생성하지 않으며 — 오류도 없고, 단순한 "hello"에 대해서도 마찬가지이며 — 이전에 열려 있던 세션은 계속 정상적으로 작동한다고 설명합니다. 그 보고는 무거운 설정에서 나왔습니다: 많은 PreToolUse 훅, 여러 MCP 서버, 80개 이상의 등록된 스킬, 그리고 커스텀(Bedrock) 제공자였습니다. 당신의 경우에도 한 토큰도 반환하지 않는다면, 그것은 느린 것이 아니라 멈춤으로 간주하세요.
해결 방법
빠른 해결 방법(먼저 시도해 보세요)
대화를 삭제하고 새로 시작하려면
/clear를 사용하세요 — 컨텍스트 비대화를 해결하는 가장 빠른 방법입니다.컨텍스트를 요약하고 줄이려면
/compact를 사용하세요. 설계상 손실이 발생하므로, 중요한 내용은 먼저 파일에 저장해 두세요.세션을 다시 시작하거나, 아직 응답하는 더 오래된 세션으로 돌아가세요 — 멈춤 현상에 대해 대부분의 사용자가 택하는 우회 방법입니다.
노력 수준을 제어
가장 간과되기 쉬운 속도 조절 요소는 노력입니다. Claude는 기본적으로 높은/최대 추론을 사용하려는 경향이 있으며, 작업에 맞게 노력을 조정하면 일상적인 작업에서는 품질 저하 없이 속도를 크게 높일 수 있습니다. 실전 치트시트:
작업 | 노력 | 이유 |
|---|---|---|
빠른 조회, 요약, 서식 지정 |
| 깊은 추론이 필요하지 않음; 거의 즉시 |
표준 코딩, 초안 작성 |
| 균형 잡힘 |
아키텍처, 어려운 디버깅, 수학 |
| 기다릴 가치가 있음 |
불투명성이 신경 쓰인다면(Claude는 기본적으로 사고 과정을 숨깁니다), Claude Code는 사고 요약을 표시하여 적어도 무엇을 하고 있는지 볼 수 있게 해줍니다.
정말로 멈춰 있을 때, 단지 느린 것이 아니라
출력이 전혀 없다면, 그것은 깊이 문제가 아니라 hang입니다:
시작 로드를 줄이세요 — 추가
PreToolUsehooks, 사용하지 않는 MCP servers, 그리고 skills를 일시적으로 비활성화한 다음 세션을 다시 여세요.provider를 확인하세요 — custom model IDs와 gateways(Bedrock 및 유사한 것들)는 여러 hang 보고서에서 나타납니다.
다음과 함께 실행하세요
--verbose실제로 무엇을 하는지 보려면: file reads가 길게 이어지면 tool-call 문제를 가리키고, tool calls 없이 첫 응답이 느리면 latency 또는 context를 가리킵니다.
고급: API에서 사고를 제어하기
앱은 생각에 대한 제어를 제한적으로만 제공합니다. API는 그 제어를 직접 제공합니다 — 그리고 예측 가능한 지연 시간이 필요하다면 이것이 실질적인 해결책입니다. 위의 치트 시트와 같은 노력 수준은 API 매개변수이며, 확장된 thinking을 완전히 끌 수도 있습니다:
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
thinking={"type": "adaptive"}, # Claude가 얼마나 생각할지 결정
output_config={"effort": "low"}, # low | medium | high | max — 깊이를 제한
# 또는, 확장된 thinking을 완전히 건너뛰려면:
# thinking={"type": "disabled"},
messages=[{"role": "user", "content": "..."}],
)현재 Claude 모델(Opus 4.6 이상)에서는 고정된 토큰 예산을 설정하지 않고 effort level을 설정합니다(low는 빠른 작업용, max까지), 또는 extended thinking을 완전히 비활성화합니다. 이는 앱이 숨기고 있는 동일한 조절 수단이지만, 이제 사용자가 제어하는 매개변수로 노출된 것입니다. (현재 기준은 공식 extended-thinking 문서를 참고하세요 — 매개변수 이름은 SDK 버전마다 달라질 수 있으므로, 사용 중인 버전을 확인하세요.)
Anthropic 호환 엔드포인트라면 어떤 것이든 이 호출을 수행할 수 있습니다 — 공식 API든, 아니면 AIReiter 같은 호환 미러든지요. 위의 요청은 변경 없이 그대로 작동합니다. 어떤 것을 사용하느냐보다 중요한 것은 핵심입니다: thinking 제어는 API 계층에 있고, 앱에서는 이를 노출하지 않는다는 점입니다.
Claude가 "더 나빠지고" 있나요?
이것은 대부분의 "why is claude almost done thinking forever" 검색 뒤에 숨어 있는 질문이며, 솔직한 답은: 보통은 영구적인 문제가 아니라는 것입니다. 체감되는 회귀의 상당 부분은 default behavior changes — 서버 측 thinking budgets 조정, 또는 업데이트에서 배포된 보수적인 기본값 — 에서 비롯되며, 모델이 더 멍청해진 것이 아닙니다. 이에 대해 커뮤니티에서 많은 갑론을박이 있지만, 반복되는 결론은 같습니다: experience는 통제권을 되찾는 순간 회복됩니다 — effort level을 설정하고, 부풀어 오른 세션을 정리하고, structured prompts를 제공하세요. 이번 주에 Claude가 더 나빠진 것처럼 느껴진다면, 고장났다고 결론내리기 전에 먼저 이 세 가지를 바꾸세요.
자주 묻는 질문
"거의 다 생각함"은 무슨 뜻인가요?
이는 Claude가 확장 추론 모드로, 답변을 작성하기 전에 계획을 세우고 있다는 뜻입니다 — 정상적인 진행 상태이며, 오류가 아닙니다. 이것이 문제가 있음을 나타내는 것은 결국 해결되지 않을 때뿐입니다.
Claude가 생각하는 데 왜 이렇게 오래 걸리나요?
세 가지 일반적인 원인: 높은 기본 노력 수준, 에이전틱 세션에서 느린 순차적 도구 호출(각각 약 300–800ms), 그리고 비대해진 컨텍스트 윈도우입니다. 노력 수준을 낮추고, 도구 호출 횟수를 줄이며, 컨텍스트를 지우는 것이 모두 도움이 됩니다.
Claude가 생각하는 데에 막히는 경우가 있나요?
예 — 느림과는 다릅니다. 새 세션이 "thinking" 상태에서 멈추고 출력이 전혀 돌아오지 않을 수 있으며, 이는 대개 복잡한 hook/MCP/skill 설정이나 사용자 지정 provider와 관련이 있습니다. 세션을 재시작하거나 정상적으로 작동하는 세션으로 돌아가세요.
Claude가 응답을 끝내지 않아요 — 어떻게 해야 하나요?
멈춘 것으로 간주하세요: /clear를 실행하거나 다시 시작하고, 시작 시 로드를 줄이며, 제공업체를 확인하세요. 완전히 멈춘 것이 아니라 느리기만 하다면, 노력 수준을 낮추고 컨텍스트를 줄이세요.
Claude가 더 빨리 생각하게 할 수 있나요?
예. 일상적인 작업에는 effort를 low/medium으로 설정하고, 세션은 짧게 유지하세요. 완전한 제어가 필요하면 더 낮은 effort 수준이나 extended thinking을 비활성화한 상태로 API를 호출하세요.