부록 B. 자주 막히는 상황 트러블슈팅

Claude를 오래 쓰다 보면 꼭 한 번은 이런 순간이 온다. 분명 어제까지는 일을 잘하던 녀석이 오늘은 엉뚱한 소리를 한다. 아까 넣은 PDF는 읽지도 못하고, 회의록은 절반만 정리하고, 숫자는 맞는지 불안하고, 답변은 갑자기 짧아진다. 이쯤 되면 사람은 두 갈래로 나뉜다. 하나는 "역시 AI는 아직 멀었네" 하고 닫아버리는 사람이다. 다른 하나는 "아, 지금은 고장난 게 아니라 조정이 필요한 구간이구나" 하고 다루는 사람이다.

실무에서 차이를 만드는 쪽은 늘 두 번째다. AI 활용이 '재미'에서 '습관'으로 넘어가려면, 잘될 때보다 막힐 때를 다룰 줄 알아야 한다. 잘 되는 날은 누구나 쓴다. 하지만 막히는 날에도 다시 궤도에 올리는 사람만 계속 쓴다.

이 부록은 바로 그 순간을 위한 응급처치 매뉴얼이다. 원칙은 간단하다. 문제를 감정으로 보지 말고 증상으로 본다. "왜 이렇게 멍청해졌지?"가 아니라 "지금은 품질 문제인가, 문서 문제인가, 시스템 문제인가?"를 먼저 묻는다. 그러면 꽤 많은 문제가 생각보다 빨리 풀린다.

막혔을 때 가장 먼저 할 일

트러블슈팅은 복잡해 보이지만, 실제 순서는 단순하다.

• 지금 문제를 출력 품질 문제, 입력 자료 문제, 시스템 문제 중 어디에 속하는지 먼저 나눈다.

• 한 번에 다 고치려 하지 말고, 새 채팅 / 더 짧은 요청 / 더 작은 파일로 범위를 줄인다.

• 고친 뒤에는 곧바로 다시 큰 작업을 넣지 말고, 작은 테스트 질문으로 회복 여부를 확인한다.

많은 사람이 여기서 반대로 한다. 긴 채팅에 긴 파일을 더 얹고, 더 긴 설명을 붙이고, 한 번에 해결하려 든다. 그러면 Claude가 좋아지는 게 아니라 상황이 더 흐려진다.

빠른 진단표

아래 표는 자주 만나는 증상과 가장 빠른 첫 조치를 정리한 것이다.

표는 응급처치다. 이제 상황별로 조금 더 자세히 보자.

결과물이 갑자기 두루뭉술해질 때

이건 Claude가 갑자기 나빠졌다기보다, 대개 작업이 퍼졌다는 뜻이다. 요청이 넓거나, 한 채팅 안에서 주제가 너무 많이 섞였거나, 원하는 산출물의 모양이 흐려졌을 가능성이 크다. Claude는 모호한 요청에 대해 아주 정중한 평균값을 내놓는 데 꽤 능하다. 문제는 평균값이 실무에서는 제일 쓸모 없다는 점이다.¹

이럴 때는 새로 설명하려 하지 말고, 작업 기준을 다시 잠근다. 특히 아래 네 가지가 빠졌는지 보면 된다. 지금 왜 이 일을 하는지, 무엇이 완료 상태인지, 무엇을 하면 안 되는지, 어떤 형식으로 받아야 하는지다.

예를 들어 그냥 "좀 더 구체적으로 써줘"라고 하지 말고 이렇게 바꾼다.

방금 결과는 너무 일반적이었다. 다시 작성하되, 대상은 임원 보고용이고, 핵심 수치 5개와 리스크 3개만 남겨줘. 추측은 빼고, 7문장 이내로 작성해줘.

이 한 번의 재브리핑만으로도 품질이 확 달라지는 경우가 많다. 핵심은 더 길게 말하는 것이 아니라, 판단 기준을 더 선명하게 주는 것이다.

형식이 자꾸 엇나갈 때

내용은 얼추 맞는데 늘 모양이 틀리는 경우가 있다. 나는 표가 필요한데 문단이 오고, 메일 초안이 필요한데 보고서가 오고, 5줄 요약이 필요한데 장문의 에세이가 온다. 이럴 때 사람은 "AI가 말을 안 듣네"라고 느끼지만, 실제로는 형식을 너무 늦게 지정했을 가능성이 크다.

Claude는 내용만 만드는 기계가 아니다. 형식까지 설계해줘야 바로 쓸 수 있는 결과가 나온다.¹ 그러니 요청 마지막에 형식을 덧붙이지 말고, 처음부터 형식부터 못 박는 편이 좋다.

아래 내용을 바탕으로 작성하되, 결과는 '제목 1개 + 본문 5문장 + 마지막 행동 요청 1문장' 형식으로 줘.

혹은 더 노골적으로 써도 된다.

설명하지 말고 바로 붙여 넣을 수 있는 공지문 형태로 작성해줘.

형식이 자꾸 어긋난다면 Claude를 고치려 하지 말고, 출력 그릇을 먼저 지정하라. 실무에서는 내용보다 그릇이 먼저다.

문서를 넣었는데 엉뚱한 답을 할 때

긴 문서를 읽히면 가끔 이런 일이 생긴다. 분명 자료 안에 있는 내용인데 못 찾거나, 반대로 없는 내용을 있는 듯 말한다. 특히 문서가 길고, 질문이 추상적이고, 답변까지 길게 요구하면 이런 현상이 심해진다.

이럴 때 좋은 해결법은 "답을 바로 내라"가 아니라 "근거를 먼저 찾아라"로 순서를 바꾸는 것이다. Anthropic은 긴 문맥에서 특정 정보를 더 잘 끌어내려면, 먼저 가장 관련 있는 문장을 찾게 하는 식의 유도 문장이 도움이 된다고 설명한다.²

실무에서는 이렇게 쓰면 된다.

답을 바로 요약하지 말고, 먼저 이 질문과 가장 관련 있는 문장 3개를 원문 표현에 가깝게 찾아줘. 그다음 그 문장만 근거로 요약해줘.

이 한 단계가 왜 중요하냐면, Claude가 '해석'부터 하지 않고 '근거 확인'부터 하게 만들기 때문이다. 특히 계약서, 보고서, 회의록처럼 단어 하나가 의미를 바꾸는 문서에서 효과가 크다.

문서 기반 작업에서 답이 이상하면, 브리핑을 더 길게 쓰기 전에 먼저 물어보자. "근거를 보고 있는가?" 대부분의 문제는 여기서 갈린다.

긴 PDF가 안 읽히거나 처리에 실패할 때

이건 실무자들이 가장 자주 겪는 좌절이다. 100페이지가 넘는 PDF를 올렸는데 요약이 엉성하거나, 문서 일부만 읽은 것 같거나, 붙여 넣기 단계에서부터 길이 제한에 걸린다. 이유는 크게 세 가지다. 문서 자체가 스캔 품질이 낮거나, 입력 방식이 비효율적이거나, 이미 대화 이력이 너무 길어진 경우다.³⁴

먼저 확인할 것은 문서 품질이다. 스캔 PDF는 사람이 보기엔 멀쩡해도 AI 입장에서는 글자층이 엉켜 있을 수 있다. 이럴 때는 OCR을 먼저 거치거나, 중요한 페이지를 따로 이미지나 텍스트로 분리하는 편이 낫다. 그리고 긴 문서는 오래 이어진 채팅방보다 새 대화에서 시작하는 쪽이 훨씬 안정적이다.⁴

붙여 넣기에서 자꾸 막힌다면, 붙여 넣기로 버티지 말고 파일 업로드를 우선하라. 웹 입력창의 실제 문자 제한이 모델의 최대 컨텍스트보다 더 먼저 걸릴 수 있기 때문이다.⁴ 또 처음부터 "전부 요약"을 시키지 말고, 먼저 구조 파악을 시키는 것이 안전하다.

이 PDF를 먼저 읽고 장별 구조, 핵심 장 3개, 숫자 확인이 필요한 섹션을 정리해줘. 요약은 아직 하지 마.

이렇게 문서 지도를 먼저 만든 뒤, 중요한 장만 다시 파고드는 편이 훨씬 덜 무너진다.

덧붙여, 200K 안쪽으로 보이는 PDF도 실제 처리 과정에서 바로 실패했다는 사용자 보고가 있다.⁵ 그러니 "이 정도면 들어가야 하는데?"라는 감각만 믿지 말고, 막히면 과감히 쪼개는 쪽으로 가는 게 낫다. 실무에서는 이론상 최대치보다 재현 가능한 안정성이 더 중요하다.

숫자, 날짜, 고유명사가 불안할 때

Claude가 글을 잘 쓰는 것과 숫자를 안전하게 옮기는 것은 별개의 문제다. 특히 보고서, 계약서, 회의록에서 숫자와 날짜는 문장보다 훨씬 더 위험하다. 분위기는 맞는데 숫자 하나 틀리면 문서 전체를 다시 검토해야 한다.

이 문제의 가장 좋은 해결법은 추출과 해석을 분리하는 것이다. 한 번에 "핵심 수치 뽑고 의미까지 설명해줘"라고 하면, 편하지만 검증 포인트가 흐려진다. 대신 두 번에 나눈다. 먼저 원문 기반 추출, 그다음 의미 해석이다.

1단계: 이 문서에서 핵심 수치, 날짜, 담당자 이름만 표로 뽑아줘. 각 항목 옆에 페이지나 섹션 근거를 붙여줘.
2단계: 방금 표만 바탕으로 의미를 해석해줘. 표에 없는 내용은 추정이라고 표시해줘.

이렇게 하면 사람이 검토하기 쉬워진다. 특히 임원 보고, 고객 제안서, 채용 문서처럼 고유명사 오류가 치명적인 문서에서 좋다. Claude를 믿지 말라는 뜻이 아니라, 믿는 방식을 바꾸라는 뜻이다.

답변이 중간에 끊기거나 너무 짧을 때

잘 쓰다가 갑자기 끝나는 답변은 생각보다 흔하다. 원인은 대개 단순하다. 한 번에 요구한 출력이 너무 길거나, 대화 이력과 첨부 자료가 이미 무거운 상태라 남은 여유가 적은 것이다.³⁴

이럴 때 제일 흔한 실수는 "계속 써줘"만 반복하는 것이다. 물론 이어 쓰기도 되지만, 더 좋은 방법은 애초에 출력 구조를 둘로 나누는 것이다. 개요와 본문, 요약과 상세본, 표와 해설을 따로 받는 식이다.

예를 들어 이렇게 바꾼다.

먼저 전체 개요만 보여줘. 내가 확인하면 각 섹션을 순서대로 확장해줘.

혹은 이미 끊겼다면 이렇게 요청한다.

방금 답변의 마지막 H2부터 이어서 작성하되, 앞부분은 반복하지 말고 남은 섹션만 마저 써줘.

긴 산출물일수록 한 번에 끝내려는 욕심이 오히려 실패 확률을 높인다. 실무에서는 끊기지 않는 긴 답 하나보다, 검토 가능한 짧은 덩어리 셋이 더 낫다.

갑자기 멈추거나 "Something went wrong"가 뜰 때

이건 사용자 입장에서 제일 억울한 오류다. 내가 뭘 잘못했는지도 모르겠고, Claude는 아무 말 없이 멈춘다. 이런 경우는 대체로 세 부류다. 서비스 측 일시적 문제, 브라우저나 앱 상태 문제, 혹은 너무 긴 세션이나 과한 입력으로 인한 응답 실패다.⁶

우선 감정적으로 더 세게 입력하지 말자. 같은 요청을 더 길게 다시 던지는 건 보통 상황을 나아지게 하지 않는다. 순서는 이렇다. 먼저 새로고침, 같은 요청의 짧은 버전 재시도, 새 채팅에서 다시 실행, 그래도 안 되면 잠시 기다렸다 재시도다. 서비스 상태가 흔들리는 구간에서는 몇 분 뒤 멀쩡해지는 경우가 많다.⁶

이럴 때 유용한 습관이 하나 있다. 중요한 작업은 항상 요청문을 별도 메모에 보관해두는 것이다. 그러면 세션이 날아가도 감정까지 같이 날아가지는 않는다. 사람을 지키는 것은 기술보다 백업 습관이다.

속도가 너무 느릴 때

Claude가 느려지는 순간은 대개 예고가 있다. 채팅이 길어졌고, 파일이 많아졌고, 질문도 복합적이 됐다. 여기에 무거운 모델까지 쓰고 있으면 체감 속도가 확 떨어진다.

이때는 고성능 모델을 탓하기 전에 작업 방식을 가볍게 만드는 편이 낫다. 서로 다른 일을 한 채팅에서 계속하지 말고, 주제가 바뀌면 새 채팅으로 옮긴다. 파일도 "다 보라"보다 "이 파일의 3장만 보라"가 빠르고 안정적이다. 그리고 초반 탐색은 빠른 모델로 하고, 최종 초안이나 검토만 더 강한 모델로 넘기는 식으로 역할을 나누면 훨씬 덜 답답하다.

느린 Claude를 억지로 밀어붙이는 것보다, 가벼운 Claude를 다시 만드는 쪽이 빠르다. 실무자는 모델을 이기지 않는다. 흐름을 설계한다.

같은 채팅에서 오래 일했더니 품질이 떨어질 때

처음에는 날카롭다가, 한 시간쯤 지나면 갑자기 산만해지는 느낌이 있다. 이건 꽤 정상적인 현상이다. 대화가 길어질수록 초반 지시와 중간 결정이 뒤로 밀리고, 중요하지 않은 잡맥락도 같이 남기 때문이다. 사람으로 치면 회의록이 아니라 잡담까지 다 들고 회의실에 다시 들어가는 셈이다.

이럴 때는 미련 없이 새 채팅을 여는 것이 좋다. 다만 그냥 새로 시작하면 아까운 정보가 날아가니, 넘겨야 할 것만 짧게 압축한다.

지금까지 결정된 사항만 10줄로 정리해줘. 다음 채팅에서 이어서 쓸 수 있게, 목표·제약·남은 작업만 남겨줘.

이 요약을 새 채팅 첫 메시지에 붙이면 된다. 이것만 잘해도 "처음엔 잘했는데 나중에 흐려지는 문제"가 크게 줄어든다. 채팅은 저장창고가 아니라 작업대라는 감각을 갖는 것이 중요하다.

Claude Code나 도구 연동에서만 막힐 때

웹에서는 괜찮은데 Claude Code, 설치, CLI, 연동에서만 막히는 경우도 있다. 이건 대화 기술 문제가 아니라 환경 문제일 가능성이 높다. 공식 문서에서 가장 흔한 증상으로 꼽는 것은 설치 후 claude 명령이 안 잡히는 경우, 설치 스크립트가 HTML을 반환하는 경우, TLS/SSL 문제, 프록시나 인증서 문제, 그리고 여러 설치본이 충돌하는 경우다.⁷

실무자 입장에서는 세부 명령어를 다 외울 필요는 없다. 대신 감만 잡으면 된다. 명령이 안 되면 PATH, 설치가 중간에 깨지면 네트워크나 권한, 회사망에서만 안 되면 프록시나 인증서를 의심한다는 식이다.⁷ 특히 사내망에서 도구 연동이 안 될 때는 개인 실수보다 보안 정책이 원인인 경우가 많다. 이때는 혼자 붙잡고 씨름하기보다 IT 팀과 바로 이야기하는 편이 더 빠르다.

그래도 안 풀리면 이렇게 좁혀라

여기까지 했는데도 해결이 안 되면, 이제는 감으로 때리지 말고 재현 가능한 문제로 바꿔야 한다. 가장 좋은 방법은 문제를 최소 단위로 줄이는 것이다.

• 파일을 빼고 같은 질문만 던져본다.

• 질문을 빼고 파일 구조 파악만 시켜본다.

• 원래 채팅이 아니라 새 채팅에서 같은 작업을 해본다.

• 긴 자료 대신 일부 페이지나 일부 문단만 넣어본다.

• 같은 작업을 다른 모델이나 다른 도구로도 한 번 돌려본다.

이렇게 하면 원인이 대체로 보인다. 질문이 문제인지, 파일이 문제인지, 세션이 문제인지, 서비스 상태가 문제인지가 구분된다. 실무에서 중요한 것은 "왜 완벽히 안 되는지"를 철학적으로 이해하는 것이 아니라, "어디서부터 무너지는지"를 실용적으로 찾는 것이다.

1분 복구 프로토콜

정말 급할 때는 아래 순서만 기억해도 된다.

첫째, 새 채팅을 연다. 오래된 맥락을 버리는 것만으로 절반은 회복된다.

둘째, 요청을 절반으로 줄인다. 요약이면 구조 파악부터, 분석이면 근거 추출부터, 문서면 전체보다 핵심 장부터 시작한다.

셋째, 형식을 먼저 고정한다. 표인지, 메일인지, 1페이지 메모인지부터 지정한다.

넷째, 검증 항목을 따로 뺀다. 숫자, 날짜, 이름은 마지막에 한 번 더 확인시킨다.

다섯째, 안 되면 5분 쉰다. 서비스 측 문제는 의외로 기다림이 가장 빠른 해결책일 때가 있다.⁶

이 다섯 단계는 멋있지 않다. 하지만 실무에서는 멋진 비법보다 이런 평범한 복구 루틴이 훨씬 오래 간다.

막힘을 줄이면, AI는 습관이 된다

AI를 잘 쓰는 사람은 늘 대단한 프롬프트를 외운 사람이 아니다. 막혔을 때 덜 당황하는 사람이다. 두루뭉술하면 브리핑을 다시 잠그고, 문서가 무너지면 구조부터 다시 잡고, 세션이 흐려지면 새 채팅으로 갈아타고, 숫자가 불안하면 검증 단계를 따로 둔다. 이 몇 가지를 몸에 익히면 Claude는 갑자기 더 똑똑해진다기보다, 훨씬 더 다루기 쉬운 도구가 된다.

그리고 바로 그 지점에서 AI 활용은 이벤트를 끝내고 습관으로 들어온다. 신기해서 한두 번 써보는 단계가 아니라, 막혀도 다시 켤 수 있는 단계 말이다. 실무에서는 그 차이가 생각보다 크다. 잘되는 날보다, 잘 안 되는 날에도 다시 쓰게 되는 사람이 결국 더 멀리 간다.

참고

¹Prompting best practices - Claude API Docs

²Long context prompting for Claude 2.1

³Claude Not Working? Beginner FAQ for Common Errors & Fixes

⁴How to Fix Character Limit Errors When Pasting Long Documents into Claude

⁵BUG: PDF Reading Fails Under 200k Token Limit · anthropics/claude-code

⁶Claude Not Responding? Complete Troubleshooting Guide [2026]

⁷문제 해결 - Claude Code Docs