Claude가 엉뚱한 결과를 만드는 이유: 프롬프트 3개

서비스를 더 자세히 알아보려면 Ailoot 문서를 참고하세요.

Claude는 왜 엉뚱한 결과를 만들까요?#

“제품 페이지에 필터를 추가해 줘.”라고 씁니다. 머릿속으로는 체크박스 몇 개와 업데이트된 목록을 떠올립니다. Claude는 같은 요청을 듣고 완전한 필터링 엔진을 만들기로 합니다. 자체 상태 저장소, 별도의 입력 지연 로직, URL 동기화, 도우미 함수 열두 개까지 추가합니다. URL 매개변수 몇 개면 충분한데 수백 줄을 작성하는 셈입니다.

이런 경우 결론은 분명합니다. 에이전트가 실수한 것이 아니라 필요 이상으로 큰 문제를 해결했을 뿐입니다. 원하는 결과를 짧고 정확하게 설명하지 않은 것이 원인이었습니다.

핵심 단어는 “의도”입니다. 사용자의 머릿속에는 있지만 Claude에게는 없습니다. Claude는 요청의 글자와 그 요청에 이르기까지의 모든 맥락을 봅니다. 그런 다음 빈틈을 추측으로 메웁니다. 요청이 짧을수록 더 많이 추측하고, 결과는 사용자가 원한 것에서 더 멀어집니다.

Anthropic은 Claude Code 문서에서 이를 분명히 설명합니다.

제 프로젝트에서도 이런 일을 겪었습니다. 인증 화면 하나를 수정해 달라고 했는데 인접한 모듈의 절반에 영향을 주는 diff를 받았습니다. Claude의 잘못은 아니었습니다. 제가 한 줄만 알려 줬고, 나머지는 Claude가 알아서 채웠습니다. 그 뒤로는 오타 수정 이상의 작업이라면 무엇이든 먼저 질문부터 시작합니다. Claude가 저에게 질문하게 합니다.

정말 모델 탓일까요? 가장 뛰어난 모델도 왜 빗나갈까요?#

매주 이전보다 “더 똑똑한” 모델이 등장하고, 그때마다 이제 AI가 몇 마디만 듣고도 마침내 우리를 이해할 것처럼 느껴집니다. 그렇지 않습니다. 더 강력한 모델은 코드를 더 빨리 작성하고 복잡한 로직을 더 잘 다루지만, 여전히 사용자의 생각을 읽지는 못합니다. 작업을 잘못 설명하면 문장은 훌륭하지만 결과는 여전히 틀린 답을 얻게 됩니다.

여기서 얻을 교훈은 간단합니다. 더 잘 추측하게 하려고 최신 모델을 쫓는 것은 막다른 길입니다. 추측할 필요가 없도록 작업을 지시하는 법을 배우는 편이 더 저렴하고 신뢰할 수 있습니다. 이어서 그 방법을 알아보겠습니다.

그릴링이란 무엇이며, AI와의 의도 불일치를 어떻게 해결할까요?#

직관에 어긋나는 이야기처럼 들립니다. 일을 더 빨리 끝내려고 AI를 쓰는데 이제 속도를 늦추고 먼저 질문하게 하라니요. 하지만 코드를 쓰기 전에 질문하는 데 5분을 쓰면 나중에 수정하는 데 드는 1시간을 아낄 수 있습니다.

문제는 Claude에게 설명을 잘못한 것만이 아닙니다. 사용자가 작업을 충분히 생각해 보지 않은 경우도 많습니다. 어떤 사례를 다뤄야 하는지, 경계는 어디인지, 무엇이 가장 중요한지 말입니다. 그릴링은 질문을 통해 이런 내용을 끌어냅니다. 대화가 끝나면 AI가 이해하는 작업 사양뿐 아니라, 마침내 세부 사항까지 명확해진 사용자의 작업도 얻을 수 있습니다.

이것이 컨텍스트 엔지니어링이 작동하는 방식입니다. 주요 작업은 프롬프트를 쓰는 동안이 아니라 그 전에 이뤄집니다. 마법 같은 프롬프트 문구를 찾는 것이 아닙니다. Claude가 추가 설명 없이 이해할 때까지 필요한 내용을 미리 정리하는 것입니다.

Claude가 먼저 질문하게 하려면 어떻게 해야 할까요?#

Anthropic은 이 접근을 허용하는 데 그치지 않고 권장합니다. 문서에는 미리 작성된 프롬프트와 함께 “Claude가 인터뷰하게 하기”라는 섹션이 있습니다. 실용적인 버전은 다음과 같습니다.

[작업에 대한 간략한 설명]을 만들고 싶습니다.

코드를 작성하기 전에 저를 자세히 인터뷰하세요. 구현, 인터페이스, 예외 사례, 위험, 장단점에 관해 질문하세요. 뻔한 질문은 하지 말고, 제가 미처 생각하지 못했을 수 있는 까다로운 부분을 깊이 파고드세요.

한 번에 질문 하나만 하고 제 답변을 기다리세요. 각 질문마다 가장 적절하다고 생각하는 답변을 즉시 제안하세요.

모든 내용을 다룰 때까지 계속하세요. 그런 다음 완전한 사양을 SPEC.md라는 파일에 정리하세요.

이 프롬프트를 형식에 그치지 않고 유용하게 만드는 세부 사항은 세 가지입니다. 첫째, “한 번에 질문 하나만.” AI가 질문 열 개를 한꺼번에 쏟아 내면 부담을 느껴 피상적으로 답하게 됩니다. 둘째, “답변을 제안하세요.” 모든 것을 처음부터 생각해 낼 필요 없이 제안을 받아들이거나 고치면 됩니다. 셋째, “사양을 파일에 정리하세요.” 끌어낸 의도가 사라지지 않는 문서로 남습니다.

Anthropic은 효과를 투입한 시간으로 설명합니다.

인터뷰를 마친 뒤 새 세션을 열고 완성된 사양을 전달하세요. 깨끗한 컨텍스트와 명확한 의도만 있으면 Claude는 첫 시도부터 정확히 해냅니다.

“이게 최선의 계획이라는 걸 증명해 봐” 기법#

그릴링은 의도를 끌어냅니다. 하지만 AI에게는 또 다른 습관이 있습니다. 그럴듯해 보이는 첫 번째 해결책을 붙잡는 것입니다. Anthropic은 이를 “믿되 검증하라”의 간극이라고 부릅니다. Claude는 그럴듯하지만 예외 사례에서 버티지 못하는 구현을 내놓습니다. 해결책은 코드 작성 전에 근거를 요구하는 것입니다.

저는 거의 항상 프롬프트에 “증명해 봐” 섹션을 추가합니다. 정확한 문구는 다음과 같습니다.

코드를 작성하기 전에 비평가의 관점에서 작업을 분석하세요.

해결 방법을 2-3가지 찾으세요. 각 방법이 쓸데없이 복잡성을 더하는 것이 아니라 실제로 내 작업을 해결한다는 점을 증명하세요. 단지 코드를 작성하기 위해 코드를 쓰지 마세요.

그런 다음 하나를 선택하고, 여러 단계 앞까지 생각한 최선의 해결책임을 증명하세요. 프로젝트가 성장하면 무엇이 망가질까요? 지금 우리가 놓치고 있는 것은 무엇인가요?

그제야 구현 방안을 제안하세요.

이 섹션이 없으면 Claude는 처음 찾은 실행 가능한 방안을 내놓습니다. 이 섹션이 있으면 Claude가 스스로 막다른 길을 걸러내고 선택을 설명하며, 파일 하나를 건드리기도 전에 판단 근거를 보여 줍니다. 완성된 코드가 예상대로 작동하지 않는 이유를 한 시간 동안 알아내는 대신, 2분이면 읽을 수 있는 짧은 글을 확인하면 됩니다.

사전 부검: 시작 전에 실패할 이유 10가지를 AI가 찾게 하기#

제가 가장 좋아하는 기법이며 심리적인 효과가 있습니다. AI에게 “잘해 달라”고 하면 성공을 전제로 삼아 허점을 건너뜁니다. 실패를 상상해 보라고 하면 이전에 무시했던 점을 보기 시작합니다. 프롬프트는 짧습니다.

지금으로부터 1년 뒤라고 상상해 보세요. 우리가 계획 중인 프로젝트는 실패했습니다.

실패한 이유 10가지를 적으세요. 시작할 때 무엇을 고려하지 못했나요? 무엇을 과소평가했나요? 어디서 지름길을 택했나요? 어떤 가정이 틀린 것으로 드러났나요?

그런 다음 각 이유를 해결하기 위해 지금 바로 무엇을 고칠 수 있는지 알려 주세요.

계획을 승인하기 전에 이 프롬프트를 실행합니다. 이유의 절반은 말이 안 되는 것으로 드러나지만, 나머지 절반은 일주일 뒤에 실제로 맞닥뜨렸을 함정입니다. 계획 단계에서 해결하면 10분이면 됩니다. 완성된 프로젝트에서 마주치면 조사에 며칠이 듭니다.

조합은 간단합니다. 그릴링은 의도를 끌어내고, “증명해 봐”는 결정을 변호하며, 사전 부검은 허점을 찾습니다. 코드를 작성하기 전에 붙여 넣는 짧은 글 세 가지입니다. 이를 통해 Claude는 서두르는 실행자에서 먼저 생각하는 협력자로 바뀝니다.

컨텍스트가 과부하되면 Claude가 왜 멍청하게 행동할까요?#

아무리 작업을 완벽하게 정의해도 어수선한 컨텍스트에서 작업하면 무너집니다. 작동 방식은 이렇습니다. 새로운 요청을 할 때마다 전체 채팅 기록이 Claude의 작업 컨텍스트에 들어갑니다. 세션이 길어질수록 창은 더 빨리 찹니다. 절반을 넘기지 마세요. 그 이상 차면 AI가 멍청하게 행동하고 대화 초반에 논의한 중요한 내용을 잃기 시작합니다.

제가 가장 큰 좌절을 줄인 규칙은 다음과 같습니다. 작업 하나에 채팅 하나. 함수를 완성했나요? 채팅을 닫고 다음 작업을 위한 새 채팅을 여세요. 물론 한 창에서 모든 일을 처리하는 편이 더 편할 때도 있지만, 컨텍스트를 잃고 주제에서 벗어난 답변을 받게 됩니다.

Anthropic은 이런 실패 유형을 “잡동사니 서랍 세션”이라고 부릅니다. 해결책은 간단합니다. 관련 없는 작업 사이에 /clear를 사용해 창을 비우고, 이전 작업의 잡동사니가 새 작업으로 넘어오지 않게 하세요.

긴 세션을 사용하면서 비용과 AI의 주의력이 어디로 가는지 모르겠다면 Claude Code 토큰이 사용되는 곳에 관한 별도 가이드에서 다룹니다. Claude가 시작할 때마다 읽는 영구 컨텍스트의 기본 사항은 CLAUDE.md 설정하기 가이드에 정리했습니다.

그릴링과 Plan Mode의 차이는 무엇이며 어떻게 함께 사용할까요?#

사람들은 이 두 기법을 혼동하거나 하나만 있으면 된다고 생각하는 경우가 많습니다. 실제로는 작업 과정의 서로 다른 시점에 쓰입니다.

Anthropic은 표준적인 4단계 작업 흐름을 설명합니다. 먼저 Explore(Claude가 조사하고 질문함), 다음 Plan(변경 없이 계획 수립), 이어서 Implement(계획에 따라 코드 작성), 마지막으로 Commit(결과 기록)입니다. 그릴링은 첫 번째 단계에서, Plan Mode는 두 번째 단계에서 이뤄집니다. 두 번째 단계의 전체 설명은 Claude Code의 Plan Mode 가이드를 참고하세요.

Anthropic은 중요한 단서를 덧붙입니다. 작은 작업에 이런 절차를 부담으로 만들지 마세요.

오타 수정, 이름 변경, 한 줄 수정이라면 인터뷰나 계획 없이 바로 작성하면 됩니다. 모호한 작업이나 오류 비용이 큰 작업에서 그릴링이 효과를 발휘합니다. 사소한 작업에는 오히려 속도를 늦출 뿐입니다.

AI가 엉뚱한 일을 하게 만드는 작업 설명 실수 5가지#

흔한 실수를 표로 정리했습니다. 왼쪽은 사람들이 보통 하는 잘못된 방식이고, 오른쪽은 대신 해야 할 일입니다.

AI가 잘못된 답을 했던 마지막 프롬프트를 검토해 보세요. 거의 확실히 이 다섯 가지 실수 중 하나가 작용했을 겁니다. 가장 흔한 실수는 첫 번째입니다. 짧은 문구만 주고 Claude가 나머지를 정확하게 채우기를 기대한 경우입니다. 나머지를 채우기는 했지만 사용자가 생각한 방식은 아니었습니다.

다음 단계: AI가 몇 마디만 듣고도 이해하도록 시스템 만들기#

이 가이드의 프롬프트 세 가지, 즉 그릴링, “증명해 봐”, 사전 부검은 당면한 작업을 처리합니다. 그것만으로도 큰 효과가 있습니다. 한 줄만 바꾸고 싶었는데 14개 파일을 건드리는 diff를 받는 일이 사라집니다.

하지만 그릴링에도 한계가 있습니다. 매번 처음부터 의도를 끌어내려면 시간이 오래 걸립니다. 진정한 변화는 컨텍스트 일부가 항상 마련돼 있을 때 시작됩니다. 프로젝트 지식이 담긴 폴더, Claude가 시작할 때마다 읽는 CLAUDE.md 파일, 스킬에 인코딩한 사용자의 방법론이 그렇습니다. 그러면 AI는 사용자의 업무, 목표, 스타일을 이미 알고 작업에 들어옵니다. 컨텍스트의 절반을 미리 정리해 두었기 때문에 몇 마디만으로도 사용자를 이해합니다.

Anthropic의 최근 분석은 이 작업이 얼마나 남았는지 보여 줍니다. 개발자들은 업무의 약 60%에서 AI를 사용하지만, 작업의 0-20%만 완전히 신뢰할 수 있습니다. 나머지에는 사용자의 이해와 감독, 무엇을 만들어야 하는지 설명하는 능력이 필요합니다. 개발해야 할 능력은 이것이지, 가장 똑똑한 모델을 쫓는 것이 아닙니다.

Ailoot에 대해 알아보세요.