AI가 그럴싸한 거짓말을 하는 이유 — 할루시네이션, Claude Code 작업 중 제가 실제로 잡는 신호들

2026년 08월 22일

0 Views

AI가 그럴싸한 거짓말을 하는 이유 — 할루시네이션, Claude Code 작업 중 제가 실제로 잡는 신호들

AI가 자신 있게 틀린 답을 하는 핵심 이유는 ‘진실을 조회’하는 시스템이 아니라, 주어진 문맥에서 가장 그럴듯한 다음 말을 예측하는 시스템이기 때문입니다. 저는 Claude Code로 워드프레스 자동 발행 파이프라인을 손보던 중, 존재하지 않는 플러그인 훅 이름을 너무 자연스럽게 제안받고 한참을 날린 적이 있습니다.

AI 코딩 에이전트 작업 전, 내 프로젝트에 맞는 검증 체크리스트를 먼저 만들어보세요.

특히 코드, API 문서, 요금제, 최신 버전처럼 사실 확인이 필요한 영역에서는 할루시네이션이 생산성을 올리는 척하다가 디버깅 비용을 키웁니다. 다행히 완전히 없애지는 못해도, 작업 흐름 안에 검증 루프를 넣으면 꽤 많이 줄일 수 있습니다.

먼저 내 프롬프트를 바꾸기보다 검증 루프부터 넣어보세요.
아래 예시처럼 “근거 확인 → 실행 → 실패 로그 재입력” 순서로 돌리면 AI 답변의 위험도가 확 내려갑니다.

제가 실제로 맞닥뜨린 상황: 그럴듯한 훅 이름 하나

셋업은 단순했습니다. Warp 터미널에서 Claude Code를 열고, 블로그 글을 JSON으로 받아 WordPress REST API에 넘기는 작은 자동화 스크립트를 고치고 있었습니다. 중간에 “발행 직전 썸네일 문구를 검사하는 워드프레스 훅을 추가해줘”라고 요청했더니, AI가 실제로 있을 법한 훅 이름과 샘플 코드를 만들어냈습니다.

문제는 그 훅이 공식 문서에 없었다는 점입니다. 코드 모양은 맞고, 네이밍도 워드프레스스럽고, 설명도 친절했습니다. 그래서 더 위험했습니다. 에러는 바로 터지지 않았고, 제가 기대한 타이밍에 함수가 호출되지 않아서 시간을 먹었습니다.

왜 이런 일이 생기나

AI 모델은 “정답 데이터베이스”처럼 동작하지 않습니다. 질문, 이전 대화, 코드 조각을 보고 다음에 올 법한 문장을 계산합니다. 그러다 문맥이 비어 있거나, 라이브러리 버전이 애매하거나, 사용자가 원하는 답의 형태가 너무 명확하면 빈칸을 그럴싸하게 메우려는 쪽으로 기웁니다.

그래서 AI가 그럴싸한 거짓말을 하는 이유 — 할루시네이션을 한 줄로 정리하면 이렇습니다. “모르는 것을 모른다고 멈추는 능력보다, 이어 말하는 능력이 먼저 작동하기 때문”입니다.

코딩 에이전트에서 더 자주 보이는 패턴

Claude Code, Cursor, Codex, Gemini를 써보면 거짓말의 모양이 조금씩 다르지만, 위험한 구간은 비슷했습니다. 최신 SDK 옵션, 존재하지 않는 CLI 플래그, deprecated된 API, 실제 프로젝트에 없는 파일 경로를 확신 있게 말할 때가 많았습니다.

예를 들어 “n8n에서 특정 노드의 내부 필드를 이렇게 바꾸면 된다”는 식의 답은 특히 조심합니다. n8n, Zapier, Make 같은 자동화 도구는 UI와 요금제, 노드 스펙이 자주 바뀌기 때문에 모델이 배운 시점과 현재 화면이 다를 수 있습니다.

헷갈릴 때 보는 비교표

AI 답변이 틀렸다고 해서 모두 같은 문제는 아닙니다. 아래처럼 구분하면 다음 행동이 빨라집니다.

상황	겉으로 보이는 신호	바로 할 일
할루시네이션	근거 링크 없이 존재하지 않는 함수, 옵션, 문서를 단정	공식 문서나 실제 명령어로 존재 여부 확인
버전 차이	예전 방식은 맞지만 현재 버전에서 실패	package.json, CLI 버전, 릴리스 노트 확인
일반 버그	개념은 맞지만 프로젝트 맥락을 잘못 적용	실패 로그와 파일 구조를 다시 제공
프롬프트 누락	AI가 가정한 환경이 내 환경과 다름	OS, 런타임, 폴더 구조, 제한 조건을 명시

제가 쓰는 검증 루프: 답을 믿기 전에 실행부터

요즘 저는 터미널 중심으로 작업하면서 AI에게 “정답”보다 “검증 가능한 다음 명령”을 요구합니다. 말로 긴 설명을 받기보다, 실패하면 로그가 남는 작은 단위로 쪼개는 편이 훨씬 안전했습니다.

구체적인 프롬프트 예시

가령 Cursor나 Claude Code에서 새 API 연동 코드를 받을 때 저는 이렇게 묻습니다.

이 코드가 현재 프로젝트에서 동작하는지 확인하는 최소 명령어를 먼저 제안해줘.
존재 여부를 확인해야 하는 함수, 패키지, 환경변수를 체크리스트로 분리해줘.
확실하지 않은 부분은 추측이라고 표시해줘.

이렇게 요청하면 AI가 바로 완성 코드를 밀어붙이기보다, 확인해야 할 지점을 분리하는 경우가 많습니다. 그래도 100% 안전하진 않아서, 저는 이어서 npm test, npm run build, curl 같은 실제 실행 결과를 다시 넣습니다.

제가 놓쳤던 흔한 실수

가장 많이 손해 본 실수는 “AI가 자세히 설명했으니 맞겠지”라고 넘긴 겁니다. 설명이 길수록 신뢰도가 올라가는 느낌이 들지만, 실제로는 틀린 전제를 길게 포장한 것일 수 있습니다.

또 하나는 공식 문서 확인을 AI에게만 맡기는 습관입니다. Perplexity나 Gemini로 근거를 찾는 방식은 도움이 되지만, 결제, 보안, 배포, 데이터 삭제처럼 민감한 작업은 결국 원문 문서를 열어 확인해야 합니다.

FAQ

할루시네이션을 완전히 없앨 수 있나요?

현실적으로는 어렵습니다. 대신 “모르면 모른다고 말해줘”, “근거 없는 추측은 표시해줘”, “실행 가능한 검증 명령을 먼저 줘”처럼 작업 방식을 바꾸면 피해를 줄일 수 있습니다.

검색 기능이 붙은 AI를 쓰면 안전한가요?

검색이 붙으면 근거 확인에는 유리하지만, 검색 결과를 잘못 해석하거나 오래된 글을 최신처럼 말할 수 있습니다. 공식 문서, 릴리스 노트, 실제 실행 결과를 함께 봐야 합니다.

코딩 에이전트에게 파일 수정을 맡겨도 괜찮을까요?

가능합니다. 다만 Git 브랜치를 나누고, 변경 파일을 작게 제한하고, 테스트 명령을 통과한 뒤 머지하는 흐름이 안전합니다. 저는 AI가 만든 코드는 사람이 리뷰한다는 전제를 유지합니다.

지금 바로 해볼 체크리스트

AI 답변에서 함수명, 옵션명, 요금제, 정책처럼 검증 가능한 명사를 표시한다.
공식 문서 또는 실제 CLI 명령으로 존재 여부를 확인한다.
실패 로그를 그대로 다시 넣고, AI에게 추측과 사실을 분리하게 한다.
큰 수정은 Git 브랜치에서 작게 나누고 테스트 후 반영한다.

오늘 하나만 바꾼다면, “완성 코드를 줘” 대신 “검증 가능한 가장 작은 다음 단계부터 줘”라고 물어보세요. AI를 덜 믿자는 이야기가 아니라, 더 오래 같이 일할 수 있게 안전장치를 붙이자는 이야기입니다.

오늘도, 코딩할 용기.

AI가 그럴싸한 거짓말을 하는 이유 — 할루시네이션, Claude Code 작업 중 제가 실제로 잡는 신호들