Claude Code에서 아첨을 막는 네 가지 프롬프트

Claude Code에서 AI 아첨이란?#

심리학에는 오래전부터 이를 가리키는 말이 있었습니다. 아첨입니다. 대화를 이어 가려고 상대가 듣고 싶어 하는 말을 하는 아첨꾼처럼 행동하는 것이죠. 대규모 언어 모델이 등장하면서 이 용어는 AI 연구 분야에 들어왔고, Anthropic은 공식 분석에서 모델이 빠른 동의를 위해 정확성을 자주 희생한다고 공개적으로 인정했습니다.

코딩에서는 이런 식으로 나타납니다. Claude Code에 이렇게 씁니다. “authMiddleware의 이 오류를 고쳐 줘. 매직 링크가 작동하지 않아.” 아첨꾼은 추가 설명을 묻지 않습니다. 로그를 요청하지도 않습니다. 사용하는 라이브러리 버전도 묻지 않습니다. 빠르게 도움을 주도록 학습되었기 때문에 곧바로 해결책을 제시합니다. 그 해결책은 import, 오류 처리, 주석까지 갖춰 제대로 보일 겁니다. 하지만 Claude가 단편적인 맥락을 짜 맞춰 만들어 낸, 다른 사람의 문제에 대한 해결책일 뿐입니다.

원인은 Claude가 아닙니다. 요청을 표현하는 방식이 원인입니다. “어떻게 고치면 돼?”라고 물으면 이미 고칠 수 있다고 전제한 셈입니다. 아첨꾼은 그 틀을 받아들여 “수정안”을 내놓습니다. 실제 문제가 아키텍처나 라이브러리 버전에 있거나, 설명한 증상이 전혀 다른 근본 오류의 결과일 수도 있는데 말이죠.

아첨을 부르는 요청인지 확인하는 간단한 방법이 있습니다. “정확히 무엇이 고장 났지?”라는 질문에 세 문장으로 답할 수 없다면 아직 해결할 준비가 되지 않은 겁니다. 먼저 진단해야 합니다. 해결은 그다음입니다. 바로 이 지점에서 4단계 주기가 시작됩니다.

사례 연구: 한 시간 동안 커밋 8개를 되돌리다#

2026년 4월의 구체적인 사례입니다. src/lib/auth/에서 매직 링크 인증을 작업하고 있었습니다. 증상은 토큰이 검증되지만 세션이 저장되지 않는 것이었습니다. 사용자가 이메일의 링크를 클릭해 사이트에 도착한 뒤 5초가 지나면 다시 /login으로 보내졌습니다.

Claude Code를 열고 이렇게 입력했습니다. “매직 링크를 사용한 뒤 세션이 저장되지 않아. src/lib/auth/를 살펴보고 고쳐 줘.” Claude는 확인 질문 세 개를 한 뒤 곧바로 계획을 내놓았습니다. “콜백 핸들러를 업데이트하고, JWT 직렬화기를 다시 작성하고, Redis에 명시적으로 저장하도록 추가하고, 미들웨어의 경쟁 상태를 수정하겠습니다.” 그럴듯하게 들렸습니다. 계획을 승인했습니다.

18분 뒤, 파일 14개에 걸친 diff가 생겼습니다. 매직 링크는 여전히 작동하지 않았습니다. 그런데 이제 refresh token도 작동하지 않았고, 비밀번호 로그인도 고장 났으며, 결제 경로에는 이상한 500 오류가 생겼습니다. 테스트도 실패했습니다. 변경 사항을 되돌리기 시작했습니다.

git reset --hard origin/main으로 커밋 8개를 되돌렸습니다. 한 시간의 작업이 물거품이 됐습니다. 유용한 내용을 잃지 않고 올바르게 되돌리는 방법을 알고 싶다면 Claude Code에서 변경 사항 되돌리기 가이드에서 따로 설명했습니다.

제대로 조사하기로 했습니다. src/lib/auth/magic-link.ts:42를 열어 직접 읽고, 로그를 열고, Redis를 확인했습니다. 20분 뒤 문제를 찾았습니다. 한 줄의 문제였습니다. set-cookie 헤더에 SameSite=lax 속성이 빠져 있었고, Safari가 이메일 도메인에서 사이트로 리디렉션될 때 쿠키를 거부하고 있었습니다. JWT도, Redis도, 미들웨어도 아니었습니다. 한 줄이었습니다.

Claude에 문제를 고쳐 달라고 했을 때 브라우저 로그는 전혀 확인하지 않았습니다. Safari에 관한 맥락도 없었습니다. 학습 데이터에서 가장 흔한 답이 “세션이 저장되지 않음 = 직렬화 문제”라는 패턴이었기 때문에 그에 따라 가설을 세웠습니다. 아첨꾼은 통계적으로 그럴듯하지만 제 작업과는 아무 관계가 없는 해결책을 내놓았습니다.

교훈을 규칙으로 정리했습니다. “어떻게 고치면 돼?”라고 묻지 말고, 항상 “사실을 확인해”라고 요청할 것. 이제 이 규칙을 실제 작업 주기로 정리하기만 하면 됐습니다.

아첨은 어디서 비롯될까: 출시 당시의 Opus 4.8과 2026년 5월#

4월에는 Anthropic이 별도의 엔지니어링 사후 분석에서 Claude Code의 캐싱 버그로 모델이 턴 사이에 추론을 “잊어버린” 원인을 살펴봤습니다.

모델이 추론의 흐름을 잊어버리면 패턴을 바탕으로 답을 “추측”하기 쉬워집니다. 다시 말해 아첨 성향이 더욱 강해질 수 있습니다.

4.8 출시 이후 어떻게 해야 할까요? 더 “쉬운” 모델을 선택하지 마세요. 4.7로 돌아가지도 마세요. 사실에 맞춰 프롬프트를 조정하세요. 모델이 더 쉽게 동의하므로 “사실 확인”을 더 분명하게 요구해야 합니다. Opus 4.8에서 무엇이 바뀌는지 아직 정확히 파악하지 못했다면 Claude Code에서 Opus 4.8 리뷰에서 자세히 비교했습니다.

4단계가 필요한 경우와 시간 낭비인 경우#

구체적인 예를 들어 보겠습니다. 환영 이메일의 문구 수정은 바로 진행하면 됩니다. 사이트에 새 CTA 버튼을 추가하는 작업에는 주기 없이 Plan Mode를 사용합니다. 프로젝트를 MySQL에서 Postgres로 마이그레이션한다면 4단계 주기가 필요합니다. 로컬에서 재현할 수 없는 프로덕션의 이상한 500 오류라면 “먼저 최소 재현 예제를 만들어 보자”라는 추가 “0단계”와 함께 4단계 주기를 사용합니다.

주기를 사용할 때 흔히 저지르는 실수는 사소한 작업에도 적용하는 것입니다. 그러면 속도가 떨어지고 사람들은 이 방법론을 금세 꺼리게 됩니다. 오류의 비용이 15분 계획의 비용보다 클 때 주기가 필요합니다.

주기를 도입하기 전에 네 가지 프롬프트가 모두 단일 Plan Mode 세션 안에서 작동한다는 점을 기억하세요. 이 모드를 처음 사용한다면 먼저 Claude Code의 Plan Mode 가이드를 읽고 돌아오세요.

1단계. 해결책을 금지하고 Claude가 사실을 확인하게 하기#

가장 중요한 단계입니다. 첫 번째 반응인 “해결책은 이렇습니다”를 여기서 차단합니다. 프롬프트:

다음과 같은 문제가 발생했습니다: [증상].

이제 당신의 임무는 사실을 확인하는 것입니다. 해결책,
아이디어, 조언은 모두 금지합니다. 다음 내용만 작성하세요.
- 관찰한 내용(증상을 정확히 표현)
- 재현 절차(최소 시나리오)
- 확인할 수 있는 데이터(로그, 버전, 환경)
- 누락된 데이터(수집해야 할 항목)

엄격한 중단 조건: 해결책을 제안하지 말고 진단 내용만
기록하세요. 제안하고 싶은 내용이 있다면,
대신 저에게 질문을 작성하세요.

이 프롬프트가 하는 일입니다. 해결책을 명시적으로 금지하면 Claude는 지름길을 택할 수 없습니다. 네 가지 항목을 채워야 합니다. 내가 무엇을 보는지, 어떻게 재현하는지, 무엇을 알고 있는지, 무엇을 모르는지입니다. 마지막 항목이 가장 중요합니다. “라이브러리 버전, 로그 내용, 증상이 프로덕션에서 발생하는지 여부를 모른다”라는 답이 나오는 경우가 많습니다. 이것이 다음 단계로 넘어갈 실마리입니다.

1단계의 함정. 증상을 너무 모호하게 표현하면(“인증이 작동하지 않아”) Claude는 여전히 추측을 끼워 넣습니다. 해결책은 프롬프트에 있습니다. 정확한 증상을 한 문장으로 설명하고 최소 세 단계의 시나리오를 제시하세요. 그렇게 할 수 없다면 무엇이 고장 났는지 아직 정확히 이해하지 못한 것이며, Claude의 답변도 어차피 쓸모없을 것입니다.

2단계. 기억 속 환각 대신 인터넷에서 선례 찾기#

두 번째 반응인 “기억을 바탕으로 해결책을 지어내기”를 차단합니다. 프롬프트:

진단이 확정되었으니 인터넷에서 유사한 문제의 해결
선례를 찾아보세요.

서로 다른 접근법을 최소 3개 제시하세요. 각 접근법에 대해:
- 1차 출처 링크(issue, 글, 문서)
- 접근법에 대한 간략한 설명
- 우리 상황에 대한 장단점
- 알려진 함정

링크로 확인하지 않은 자체 지식에 기반한 링크는
금지합니다. 선례를 찾을 수 없다면
그 사실을 명확히 말하세요.

실제 효과입니다. Claude가 바깥에서 검증 가능한 접근법을 찾아옵니다. GitHub 이슈와 문서 링크가 나타납니다. 선례를 찾지 못했다면 작업이 이례적이거나 증상이 잘못 표현되었다는 신호입니다. 1단계로 돌아가세요.

제대로 작동하지 않는 부분입니다. Claude가 존재하지 않는 링크를 인용할 수 있습니다. 실제로 issue 4291이 다른 내용을 다루는데 “저장소 X의 issue 4291이 있습니다”라고 하는 경우처럼 환각이 일어날 수 있습니다. CLAUDE.md에 “인용하기 전에 항상 WebFetch로 링크를 열어 보라”라는 명시적 규칙을 넣으세요. 자세한 내용은 CLAUDE.md를 올바르게 설정하는 가이드를 참조하세요.

3단계. 위험을 미리 파악한 상세 계획을 plans/에 작성하기#

이제 Plan Mode가 의도한 대로 작동합니다. 프롬프트:

2단계에서 가장 나은 방법을 골라 plans/YYYY-MM-DD-fix-[name].md
파일에 상세한 계획을 작성하세요.

- 수정할 구체적인 파일(전체 경로와 줄 번호)
- 추가할 내용과 제거할 내용
- 작성할 테스트와 통과해야 할 기존 테스트
- 두세 단계 앞의 위험(사용자에게 무엇이 잘못될 수 있는지)
- 문제가 생겼을 때의 롤백 계획

모든 단계를 체크박스 [ ]로 만드세요. 파일은 화면 한 개에 들어가야 합니다.
계획이 200줄을 넘으면 단계별로 나누세요.

결과입니다. 계획은 채팅의 임시 메모가 아니라 산출물이 됩니다. 2주 뒤에 읽거나, 다른 에이전트에게 넘기거나, /goal 명령의 조건으로 활용할 수 있습니다. Claude Code의 대화보다 계획 파일이 오래 남습니다.

핵심은 두세 단계 앞의 위험을 미리 파악하는 것입니다. 이는 부작용이 없는 낙관적인 계획이라는 또 다른 아첨 패턴을 차단합니다. Claude에게 위험을 명시적으로 나열하라고 하면 일반적인 계획에서 말없이 넘겼을 문제도 찾아냅니다.

4단계. 계획 자체를 점검해 아첨에 따른 가정을 찾아내기#

마지막 필터입니다. 프롬프트:

이제 필수 자체 점검을 수행하세요. 계획을 솔직하게 다시 읽으세요.

다음 항목으로 확인하지 않은 채 근거 없이 지어낸 부분이 있나요?
- 읽은 코드
- 2단계에서 인용한 문서
- 2단계의 선례

있다면 명확하게 표시하고 수정하거나 삭제하세요.

또한 다음 사항을 확인하세요.
- 아직 package.json에 설치되지 않은 라이브러리를
  언급하는지
- 제가 지정하지 않은 환경 변수를 언급하는지
- 계획의 단계가 구체적이지 않고
  일반적인 표현으로 설명되어 있는지

이 프롬프트가 하는 일입니다. Claude가 자신의 추론을 다시 점검해야 합니다. 저자가 약 50개 주기로 구성한 표본에서는 4단계에서 계획 항목이 적어도 두세 개 수정됩니다. 3단계에서 아첨꾼이 슬쩍 끼워 넣으려 한 내용을 4단계가 잡아낸 것입니다.

네 단계를 마치면 계획을 승인할 준비가 됩니다. “커밋 8개를 되돌려야 하면 어떡하지?”라는 걱정 없이 구현을 시작할 수 있습니다.

왜 2단계나 7단계가 아니라 정확히 4단계일까?#

Anthropic이 공식 문서에서 Claude를 안내하는 방식에 따라 이유를 살펴보겠습니다.

문서에서는 Explore, Plan, Implement, Commit의 4단계 워크플로를 권장합니다.

제가 만든 4단계 주기는 아첨을 막기 위해 Plan 단계를 특화한 것입니다. Anthropic의 네 단계 중 하나를 네 개의 세부 단계로 확장합니다. 해결책 금지, 선례 찾기, 계획 작성, 자체 점검입니다. 이렇게 상세한 계획을 만든 뒤 Implement와 Commit 단계로 넘깁니다.

네 단계 중 하나라도 건너뛰면 어떤 문제가 생기는지 살펴보겠습니다.

표를 보면 분명합니다. 각 단계가 고유한 오류 유형을 차단합니다. 단계마다 다른 범주를 잡아내므로 네 단계가 모두 필요합니다. 두 단계면 충분할 만큼 작업이 작아 보인다면 정말 작은 작업이므로 Plan Mode 자체가 필요하지 않습니다.

plans/, /goal 명령, 다음 단계가 맞물리는 방식#

주기는 다음 요소로 이루어진 시스템 안에서 작동합니다.

1. Plan Mode 활성화(Claude Code에서 Shift+Tab 두 번).
2. 계획을 저장할 저장소의 plans/ 폴더.
3. 선택 사항으로, 긴 계획을 자율적으로 구현하는 /goal 명령.

먼저 plans/ 폴더에 대해 알아보겠습니다. 3단계가 끝나면 단계와 체크박스가 포함된 plans/2026-05-27-fix-magic-link.md 파일이 생깁니다. 하나의 산출물입니다. 일주일 뒤 파일을 열면 해당 접근법을 선택한 이유가 떠오릅니다. 3개월 뒤 비슷한 작업을 찾아 재사용할 수 있습니다. 6개월 뒤에는 동료에게 보여 주어 작업을 파악하는 데 걸리는 2주를 아껴 줄 수도 있습니다. plans/ 폴더는 Claude Code에서 “세컨드 브레인”이라는 개념의 일부입니다.

이제 /goal에 대해 알아보겠습니다. 네 단계를 마치고 계획을 승인한 뒤 Plan Mode를 종료하고 다음을 입력합니다.

/goal plans/2026-05-27-fix-magic-link.md의 모든 단계를 수행하고,
test/auth의 모든 테스트를 통과시키세요. 그렇지 않으면 30턴 후 중단하세요

로컬 Claude Code 세션에서는 터미널을 실행한 채 컴퓨터를 깨어 있게 유지하고 네트워크 연결을 확보하세요. 지원되는 깨어 있기 구성을 명시적으로 마련하지 않았다면 노트북을 닫지 마세요. 돌아와 세션 기록에서 완료, 턴 한도, 권한 요청, 오류를 확인하세요. 목표가 설정돼도 호스트가 잠들면 진행은 보장되지 않습니다. 4단계 주기 없이 /goal을 사용하면 쓸모없는 반복에 토큰을 낭비합니다. 4단계 주기가 있으면 /goal이 완성된 계획을 테스트 통과까지 진행합니다.

이제 무엇을 하면 좋을까요? Claude Code를 막 시작했다면 다음에 만나는 사소하지 않은 작업에서 주기를 시험해 보세요. 오타 수정이 아닙니다. 파일 3개 이상을 건드리거나 동작을 완전히 이해하지 못한 작업을 말합니다. 위 프롬프트를 복사한 다음 자신의 세부 내용을 채우세요. 롤백 비율이 어떻게 달라지는지 확인할 수 있습니다.

이미 Plan Mode를 사용하고 있다면 저장소에 plans/ 폴더를 추가하세요. 파일명 형식을 정해 두면 좋습니다. YYYY-MM-DD-feature-name.md. 한 달 뒤에는 파일이 20–30개, 6개월 뒤에는 100개가 넘을 겁니다. 이렇게 프로젝트의 세컨드 브레인이 만들어집니다. 살아 있는 의사 결정 기록이죠. 프롬프트를 작성하기 전에 컨텍스트를 관리하는 방법을 더 알아보고 싶다면 Claude Code의 컨텍스트 엔지니어링을 별도의 방법론으로 다뤘습니다.

Plan Mode와 plans/를 모두 사용하고 있다면 자율 작업 하나에 /goal을 시험해 보세요. 보통 직접 하면 30–40분 걸릴 작업을 고르세요. 4단계 주기로 처리하고 계획을 저장한 다음 /goal을 시작하고 로컬 터미널과 컴퓨터를 깨어 있게 두세요. 컴퓨터가 꺼진 동안 작업하려면 먼저 원격 또는 클라우드 실행 경로를 명시적으로 설정하고 실제로 그곳에서 실행 중인지 확인하세요.