12. 틀릴 때, 멈출 때, 애매할 때: 한계·안전·문제 해결
Claude를 오래 쓰다 보면 꼭 한 번은 이런 순간이 온다. "분명 그럴듯한데 뭔가 이상하다." "아까는 기억하던 걸 왜 지금은 모를까?" "답이 중간에 끊겼네?" "이거 내 개인정보를 그냥 넣어도 되나?"
초보자는 이런 순간에 두 갈래로 나뉜다. 한쪽은 "AI는 원래 다 틀려" 하며 아예 멀어진다. 다른 한쪽은 반대로 너무 믿어서, 그럴듯한 답을 곧바로 복사해 메일로 보내고, 보고서에 넣고, 코드에 붙인다.
둘 다 아쉽다. Claude를 잘 쓰는 사람은 완벽한 답을 받는 사람이 아니라, 애매할 때 멈추고 확인하는 사람이다. 결국 차이는 기능보다 습관에서 난다.1
이번 장에서는 Claude가 틀릴 때, 맥락을 놓칠 때, 답이 중간에 멈출 때, 제한에 걸릴 때, 그리고 개인정보를 다룰 때 어떻게 대응해야 하는지 차근차근 정리해 보겠다. 핵심은 단순하다. 중요한 일일수록, 한 번 더 검증하자.
Claude가 틀리는 이유부터 이해하자
먼저 마음을 편하게 먹자. Claude가 틀린다고 해서 내가 사용을 잘못한 것만은 아니다. 언어 모델은 원래 "가장 그럴듯한 다음 답"을 만들어 내는 방식으로 작동한다. 그래서 정보가 부족하거나, 질문이 모호하거나, 너무 구체적인 사실을 요구받으면 빈칸을 억지로 메우듯 답할 때가 있다. 이것이 흔히 말하는 환각이다.1
초보자가 자주 겪는 오류는 대체로 네 가지다.
없는 사실을 있는 것처럼 말하는 경우
내가 준 문서에 없는 내용을 끼워 넣는 경우
긴 대화에서 앞부분 조건을 잊는 경우
답을 너무 자신 있게 말해서 맞는 것처럼 보이게 하는 경우
무서운 점은, 틀린 답이 대개 엉성하게 틀리지 않는다는 것이다. 오히려 문장도 자연스럽고 논리도 그럴듯해서 더 위험하다. 그래서 Claude를 쓸 때는 "자연스럽다 = 맞다"라고 생각하면 안 된다.
예를 들어 이렇게 물으면 위험하다.
2024년 우리 업계 평균 광고 전환율이 몇 퍼센트야? 바로 숫자만 알려줘.
이 질문은 숫자를 강하게 요구한다. Claude는 확신이 부족해도 숫자를 내놓고 싶은 유혹을 받는다. 반면 이렇게 바꾸면 훨씬 안전해진다.
2024년 업계 평균 광고 전환율을 알고 싶어. 확실한 근거가 없으면 모른다고 말해줘. 가능하면 출처가 확인 가능한 범위만 설명해줘.
짧은 차이 같지만, 이 한 문장이 헛답변을 많이 줄여 준다.1
가장 먼저 익혀야 할 안전 문장: "모르면 모른다고 말해줘"
Claude를 쓸 때 초보자에게 가장 먼저 권하고 싶은 습관은 이것이다.
확실하지 않으면 추측하지 말고 모른다고 말해줘.
공식 문서도 바로 이 방법을 가장 기본적인 환각 완화 전략으로 소개한다.1
많은 사람이 AI에게는 당당한 말투를 원하지만, 실제로는 그 반대가 더 안전하다. 특히 다음 상황에서는 반드시 이 문장을 붙이는 편이 좋다.
날짜, 수치, 법규, 가격, 통계처럼 정확성이 중요한 질문
최신 정보가 중요한 질문
내가 올린 문서 안에서만 답해야 하는 질문
사람 이름, 회사명, 논문명, 제품 버전처럼 틀리기 쉬운 고유명사 질문
실전 예시를 보자.
잘못된 질문:
이 PDF 보고서 기준으로 우리 회사 해지율 원인을 3가지 단정해서 말해줘.
더 안전한 질문:
이 PDF 안에 실제로 근거가 있는 내용만 바탕으로 해지율 원인을 정리해줘. 문서에 근거가 부족한 부분은 추측하지 말고 "문서만으로는 판단 어려움"이라고 표시해줘.
이렇게 하면 Claude가 아는 척하는 빈도가 줄고, 대신 어디까지 확실한지 경계선을 보여 주기 쉬워진다.
문서 작업에서는 "답변 먼저"보다 "근거 먼저"가 안전하다
문서, PDF, 회의록, 계약서, 보도자료처럼 주어진 자료를 바탕으로 답해야 하는 작업에서는 질문 순서를 바꾸는 것만으로 품질이 크게 좋아진다.1
많은 초보자는 이렇게 묻는다.
이 문서 요약해줘.
물론 이것도 가능하다. 하지만 중요한 문서라면 이렇게 바꾸는 편이 더 낫다.
먼저 질문과 관련된 핵심 문장을 직접 찾아줘. 그다음 그 문장에 근거해서 요약해줘. 문서에 없는 내용은 추가하지 말아줘.
혹은 더 구체적으로 이렇게 요청할 수 있다.
아래 질문에 답하기 전에, 문서에서 가장 관련 있는 문장을 3개 먼저 뽑아줘. 그 문장으로 답이 가능한지 판단한 뒤, 가능할 때만 답해줘.
이 방식이 좋은 이유는 간단하다. Claude가 먼저 근거를 붙잡고 나서 설명하게 만들기 때문이다. 공식 문서도 긴 문서 작업에서는 직접 인용이나 인용 기반 검증을 활용하면 환각을 줄일 수 있다고 권한다.1
실전 예시를 하나 만들어 보자.
질문: 이 제안서에 따르면 납기 지연의 가장 큰 원인은 무엇이야?
요청: 먼저 관련 문장을 그대로 찾아줘. 그다음 그 문장만 바탕으로 한 문장으로 답해줘. 명확한 근거가 없으면 없다고 말해줘.
이렇게 하면 답이 느려질 수는 있어도, 훨씬 믿을 만해진다. 중요한 문서일수록 빠른 답보다 근거 있는 답이 낫다.
"내가 준 자료 안에서만 답해"라고 경계선을 그어주자
Claude는 친절하다. 문제는 가끔 너무 친절하다는 것이다. 내가 문서를 올려 줬는데도 자기 일반 지식을 섞어 더 풍성하게 답하려고 한다. 글은 좋아 보이지만, 바로 그 지점이 위험할 수 있다.
예를 들어 계약 검토, 사내 규정 확인, 면접 평가표 정리, 병원 안내문 요약 같은 작업에서는 바깥 지식이 오히려 방해가 된다. 이럴 때는 분명하게 선을 그어야 한다.
제공한 문서 안의 정보만 사용해 답해줘. 일반 지식으로 보완하지 마.
또는 이렇게 말해도 좋다.
답변의 각 항목이 문서 어디에서 왔는지 같이 표시해줘. 문서에서 찾지 못한 내용은 제외해줘.
이 한 줄은 "풍부한 답변"보다 "감사 가능한 답변"을 만들 때 특히 강력하다. 초보자일수록 이 차이를 빨리 익히는 게 좋다. AI 사용에서 진짜 실력은 많이 아는 것이 아니라, 무엇을 섞지 않게 할지 아는 것이기 때문이다.
맥락 손실은 고장이 아니라 구조적인 현상이다
길게 대화하다 보면 Claude가 아까 한 말을 잊어버린 것처럼 느껴질 때가 있다. 사실 이건 꽤 자연스러운 현상이다. 모델은 한 번에 다룰 수 있는 맥락 창이 한정되어 있고, 대화가 길어질수록 오래된 정보의 비중이 약해질 수 있다. 특히 큰 파일, 긴 문서, 여러 번의 수정 요청이 쌓이면 초반 조건이 흐려지기 쉽다.2
초보자가 알아두면 좋은 신호는 이렇다.
분명히 말한 조건을 다시 묻는다.
이미 제외하기로 한 방식을 다시 제안한다.
같은 질문에 앞뒤가 다른 답을 한다.
방금 전 대화의 핵심 표현을 놓친다.
이럴 때 많은 사람이 더 길게 설명한다. 그런데 의외로 더 좋은 해결책은 새 대화를 시작하고 핵심만 다시 주는 것이다.
예를 들어 긴 대화가 꼬였을 때는 이렇게 정리하자.
새로 시작할게. 지금까지의 핵심만 반영해줘. 목표: 블로그 글 초안 작성 독자: 초보자 톤: 친절하고 쉬운 설명 반드시 포함: 예시 3개 제외: 과장된 마케팅 문구
이 조건을 먼저 한 줄씩 확인한 뒤 초안을 써줘.
이 방식은 마치 흐트러진 책상을 한 번 정리한 뒤 다시 공부를 시작하는 것과 비슷하다. 괜히 종이 더미를 뒤지기보다, 필요한 노트만 펼치는 편이 빠르다.
맥락을 잃지 않으려면 "대화를 길게"보다 "작업을 작게" 쪼개자
초보자는 종종 한 대화 안에 모든 걸 밀어 넣으려 한다. 예를 들면 이런 식이다.
사업 아이디어 정리해줘. 시장조사도 해줘. 발표 자료도 만들어줘. 투자자용 요약도 써줘. 로고 문구도 추천해줘.
이건 사람에게 맡겨도 한 번에 엉킨다. Claude도 마찬가지다. 작업이 많을수록 한 단계씩 나누는 게 좋다.
더 나은 흐름은 이렇다.
1단계:
내 사업 아이디어를 한 문단으로 정리해줘.
2단계:
방금 정리한 아이디어 기준으로 타깃 고객을 3개로 나눠줘.
3단계:
첫 번째 타깃 고객 기준으로 5장짜리 발표 개요를 만들어줘.
이렇게 하면 Claude가 지금 무엇에 집중해야 하는지 분명해진다. 맥락 손실을 줄이는 가장 쉬운 방법은 기억력을 탓하는 것이 아니라, 대화의 부담을 줄이는 것이다.
또 하나 좋은 방법은 중간 요약이다. 긴 작업을 하다가 20~30분쯤 지나면 이렇게 말해보자.
지금까지 결정된 내용을 6줄 이내로 요약해줘. 다음 대화에서 이어 붙일 수 있게 핵심만 남겨줘.
그러면 새 대화를 시작할 때 그 요약을 붙여 넣고 자연스럽게 이어 갈 수 있다.
답이 중간에 멈췄을 때는 당황하지 말고 원인을 나눠보자
Claude의 응답이 중간에 끊기는 경우는 크게 두 가지다. 하나는 단순히 출력이 길어서 잘린 경우이고, 다른 하나는 흐름상 더 필요한 입력을 기다리거나 세션이 매끄럽지 않게 끝난 경우다. API에서는 이런 상황을 stop_reason으로 확인할 수 있고, 대표적으로 자연 종료인 end_turn, 출력 제한에 걸린 max_tokens 같은 값이 있다.3
웹이나 앱을 쓰는 일반 사용자라면 기술 용어를 다 외울 필요는 없다. 대신 대응만 알면 된다.
가장 쉬운 복구 문장은 이렇다.
방금 답변이 중간에 끊겼어. 이어서 같은 형식으로 마저 써줘.
혹은 더 안전하게 이렇게 말할 수 있다.
방금 답변에서 어디까지 썼는지 한 줄로 요약하고, 그다음부터 이어서 써줘.
이 문장이 좋은 이유는 Claude가 앞부분을 짧게 재확인하고 이어 가게 만들기 때문이다.
실전 예시를 보자. 발표 자료 초안을 받다가 5장 중 3장까지만 나왔을 때는 이렇게 말하면 된다.
1~3장은 잘 받았어. 같은 톤과 형식으로 4~5장만 이어서 써줘. 중복 없이 써줘.
요약 작업이 끊겼다면 이렇게 요청할 수 있다.
방금 PDF 요약이 끊겼어. 이미 말한 내용은 반복하지 말고, 남은 핵심만 bullet 5개 이내로 이어서 정리해줘.
중요한 건 "다시 처음부터"보다 "어디서 끊겼는지 지정해서 이어 달라"고 말하는 것이다.
출력 제한에 자주 걸린다면, 답을 짧게 나누어 받자
초보자는 종종 "가능한 한 자세히"라고 쓰고, 동시에 한 번에 너무 많은 걸 요청한다. 그 결과 답이 길어지고 중간에 잘릴 가능성도 높아진다.
예를 들어 이렇게 묻는 대신,
이 책 전체 홍보 전략을 상세하게 모두 작성해줘.
이렇게 나누는 편이 낫다.
먼저 전체 전략을 7개 항목으로 개요만 써줘.
그리고 다음 턴에서,
3번 항목만 자세히 확장해줘. 예시까지 넣어줘.
이 방식은 답변 품질도 좋아지고, 내가 검토할 수 있는 단위도 작아진다. Claude를 오래 쓸수록 알게 되지만, 한 번에 엄청난 결과물을 받는 것보다 작은 완성본 여러 개를 받는 편이 실제로 더 빠르다.
조금 더 나아가 API나 Claude Code를 쓰는 사람이라면, 응답이 max_tokens 때문에 잘릴 수 있다는 점을 기억하면 좋다. 이 경우에는 더 높은 출력 한도를 주거나, 요청 자체를 더 작은 단위로 나누는 것이 기본 대응이다.3
제한 초과, 사용량 초과, 너무 무거운 작업은 어떻게 풀까
Claude를 쓰다 보면 "지금은 너무 길다", "파일이 너무 많다", "사용 제한에 가까워졌다" 같은 느낌의 장벽을 만날 수 있다. 이때 중요한 건 억지로 밀어붙이지 않는 것이다.
초보자에게 가장 실용적인 해결책은 세 가지다.
첫째, 범위를 줄인다. 문서 10개를 한꺼번에 넣지 말고 2개씩 나눈다. 코드 폴더 전체를 읽히지 말고 관련 파일만 준다.
둘째, 결과 형식을 줄인다. "자세한 분석 보고서" 대신 "핵심 5개 요약"부터 받는다.
셋째, 새 세션으로 넘긴다. 이전 세션에서 나온 핵심 요약만 들고 다음 세션에서 이어 간다.2
예를 들어 긴 시장조사를 하다가 제한에 걸렸다면 이렇게 전환할 수 있다.
지금부터는 범위를 줄일게. 경쟁사 5개 전체 말고 상위 2개만 비교해줘. 표로 짧게 정리해줘.
코드 작업이라면 이렇게 바꾸는 식이다.
전체 프로젝트 분석 대신 로그인 기능과 관련된 파일만 기준으로 설명해줘.
이건 후퇴가 아니라 전략이다. 큰 짐은 나눠 들어야 덜 떨어뜨린다.
개인정보는 "필요한 만큼만" 넣는 습관이 핵심이다
Claude는 편리하지만, 그렇다고 아무 정보나 다 넣어도 되는 것은 아니다. 특히 주민등록번호, 계좌번호, 카드번호, 개인 연락처, 급여 정보, 의료 정보, 고객 명단, 비밀 계약서 같은 민감한 내용은 매우 신중해야 한다. Anthropic도 소비자용 제품에서 민감한 정보를 입력할 때는 주의하라고 안내하고 있고, 개인정보 및 모델 개선 설정은 사용자가 직접 조정할 수 있다고 설명한다.45
초보자에게 가장 쉬운 원칙은 이것이다.
실명 대신 역할을 쓰고, 실제 숫자 대신 예시 숫자를 쓰고, 원문 전체 대신 필요한 부분만 요약해서 넣자.
예를 들어 이렇게 바꾸면 훨씬 안전하다.
나쁜 예:
김민수 고객은 1988년생이고 휴대폰 번호는 010-1234-5678인데, 이 민원 메일 답장 써줘.
좋은 예:
고객에게 보내는 민원 답장을 써줘. 고객 이름과 연락처는 빼고, 환불 지연에 사과하면서 다음 처리 일정을 안내하는 톤으로 작성해줘.
또는 계약 검토를 부탁할 때도 원문 전체를 던지기보다 이렇게 바꾸는 편이 좋다.
아래 계약 조항 형식을 참고해서, 해지 조항이 너무 불리한지 확인할 때 어떤 문장을 봐야 하는지 체크리스트만 만들어줘.
즉, 판단 기준은 Claude에 묻고, 민감한 사실은 내 손에 남겨두는 것이 기본이다.
설정도 한 번 확인해두자
개인용 Free, Pro, Max 계정에서는 대화나 코딩 세션을 모델 개선에 사용할지 여부를 사용자가 선택할 수 있다. 관련 설정은 Data & Privacy 쪽에서 조정할 수 있고, 허용하지 않으면 일반적으로 더 짧은 보존 정책이 적용된다. 반면 Team, Enterprise, API 같은 상업용 제품은 기본 정책이 다르며, Claude Code 쪽은 계정 유형에 따라 데이터 사용과 보존 규칙이 달라진다.56
이 문장을 어렵게 느낄 필요는 없다. 초보자가 기억할 것은 두 가지다.
내 계정이 개인용인지, 업무용인지 먼저 구분하자.
중요한 작업을 시작하기 전에 개인정보 및 데이터 사용 설정을 한 번 확인하자.
Claude Code를 쓰는 사람이라면 한 가지 더 기억할 점이 있다. 공식 문서에 따르면 세션 재개를 위해 로컬에 대화 기록이 일정 기간 저장될 수 있다. 즉, 서버 쪽 정책만 볼 게 아니라 내 컴퓨터에 남는 흔적도 생각해야 한다.6
그리고 대화 공유 링크나 연결된 커넥터도 가끔 점검하는 것이 좋다. 공유 링크는 링크를 가진 사람이 볼 수 있고, 커넥터는 연결된 외부 서비스 접근 범위를 넓힐 수 있으니, 더 이상 필요 없는 연결은 끊어 두는 편이 안전하다.7
결과 검증은 귀찮아도, 결국 시간을 아껴준다
이 장의 핵심은 여기다. Claude를 위험하게 쓰는 사람은 "대답을 받는 것"에서 끝난다. Claude를 잘 쓰는 사람은 "대답을 확인하는 것"까지 한다.
검증은 거창할 필요가 없다. 초보자에게는 아래 네 단계만 있어도 충분하다.
사실 확인: 날짜, 숫자, 이름, 링크, 법 조항은 따로 다시 본다.
근거 확인: 문서 기반 답변이면 근거 문장이 실제로 있는지 본다.
범위 확인: 내가 준 자료 안에서만 답했는지 본다.
실행 전 확인: 메일 발송, 보고서 제출, 코드 반영 전 한 번 더 읽는다.
예를 들어 메일 작성에서는 이렇게 검증할 수 있다.
이 메일 초안에서 사실 주장, 일정, 금액이 들어간 문장만 따로 뽑아줘.
그러면 내가 확인해야 할 문장만 빠르게 볼 수 있다.
문서 요약에서는 이렇게 말하면 좋다.
각 핵심 주장 옆에, 그 주장을 뒷받침하는 원문 문장을 붙여줘.
의사결정용 비교표에서는 이렇게 요청해 볼 수 있다.
표 안에서 확실한 사실과 해석이 섞인 부분을 구분해서 다시 써줘.
코드라면 더 중요하다. Claude가 만든 코드는 그럴듯해도 바로 실행하면 안 된다. 다음처럼 확인하자.
이 코드에서 확실하지 않은 부분, 환경에 따라 달라질 수 있는 부분, 직접 테스트해야 하는 부분을 나눠서 표시해줘.
이 질문은 아주 강력하다. Claude가 스스로도 애매한 지점을 드러내게 만들기 때문이다.
"한 번 더 확인하는 프롬프트"만 따로 저장해도 실력이 오른다
초보자에게 특히 추천하는 것은 검증용 프롬프트 모음집을 만드는 것이다. 매번 새로 생각하지 말고, 자주 쓰는 확인 질문을 따로 저장해 두자.
예를 들면 이런 문장들이다.
이 답변에서 추측이 섞인 부분을 표시해줘.
확실한 사실과 해석을 구분해서 다시 써줘.
내가 준 자료에 없는 내용이 있으면 빼줘.
각 주장마다 근거를 붙여줘.
이 내용 중 내가 직접 확인해야 하는 항목만 따로 뽑아줘.
반대 가능성이나 예외가 있다면 같이 적어줘.
이런 질문을 붙이는 순간 Claude는 "멋진 문장 생성기"에서 "검토를 돕는 보조자"로 바뀐다. 그리고 바로 여기서 사용 수준이 한 단계 올라간다.
애매할수록 이 5문장을 먼저 써보자
마지막으로, 실제로 가장 많이 도움이 되는 복구 문장만 추려 보자.
첫째.
확실하지 않으면 추측하지 말고 모른다고 말해줘.
둘째.
내가 제공한 문서 안의 정보만 사용해 답해줘.
셋째.
답하기 전에 관련 근거 문장을 먼저 찾아줘.
넷째.
방금 답변이 중간에 끊겼어. 어디까지 했는지 한 줄로 확인하고 이어서 써줘.
다섯째.
이 답변에서 내가 직접 검증해야 하는 부분만 따로 표시해줘.
이 다섯 문장만 잘 써도, 초보자의 실수 상당수는 피할 수 있다.
안전하게 쓰는 사람의 마지막 습관
Claude를 쓸수록 느끼게 된다. 진짜 차이는 화려한 기능을 얼마나 많이 아느냐가 아니다. 의심해야 할 순간에 의심하는가, 중요한 일을 보내기 전에 멈추는가, 민감한 정보를 줄이려 노력하는가, 답을 근거와 함께 보려 하는가에서 차이가 난다.
정리해 보자. Claude가 틀릴 수 있다는 사실은 약점이 아니라 사용 설명서다. 틀릴 수 있으니 근거를 요청하고, 잊을 수 있으니 요약하며 새로 시작하고, 멈출 수 있으니 작게 나누어 이어 받고, 민감할 수 있으니 정보를 줄이고, 그럴듯할 수 있으니 검증한다.
이 습관이 생기면 Claude는 더 이상 "맞을 때만 유용한 도구"가 아니다. 틀릴 가능성까지 관리하면서 써도 충분히 강력한 도구가 된다. 그리고 초보자에서 숙련자로 넘어가는 기준도 바로 여기 있다. 질문을 잘하는 것에서 끝나지 않고, 결과를 책임 있게 다루는 것. 그것이 Claude를 오래, 안전하게, 실전에서 잘 쓰는 사람의 방식이다.
참고
1Reduce hallucinations - Claude API Docs
2Claude Code Context Window: How to Stop Losing Context Mid-Session
4I would like to input sensitive data into my chats with Claude. Who can view my conversations?
5How Do You Use Personal Data in Model Training?
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.