클로드코드 프롬프트, 이것만 바꿔도 엉뚱한 결과가 줄어듭니다

시키지도 않은 파일을 고쳐놓고, 묻지도 않은 걸 만들어놓고, 그러고선 "완료했습니다"라고 합니다. 도구가 멍청해서가 아니라 대개 클로드코드 프롬프트가 애매해서 그렇습니다.

처음 며칠은 감탄합니다. 한국어로 부탁했더니 파일을 정리하고 표를 만들어주니까요. 그러다 어느 순간부터 결과가 미묘하게 어긋나기 시작합니다. 분명 A만 고쳐달라고 했는데 B와 C까지 손을 댔고, 30분 걸려 만든 결과물이 애초에 원하던 게 아니었죠. 저도 그 구간을 한참 헤맸습니다. 그리고 깨달은 건, 고칠 것은 도구가 아니라 지시하는 방식이었다는 겁니다.

설치와 첫 실행이 아직이라면 클로드코드 사용법, 비개발자도 30분이면 끝부터 보고 오시면 됩니다. 이 글은 그다음, "이미 쓰고 있는데 자꾸 엉뚱하다"는 사람을 위한 글이에요.

▲ 노트북에 클로드코드 플랜 모드 터미널이 열려 있고 책상 위에는 범위·출처·본보기·증상 요구사항을 적어둔 메모지 네 장이 놓인 작업 책상 (자체 제작 이미지)

1. 왜 엉뚱한 짓을 하는가 — 원인은 세 가지

먼저 용어 하나. 프롬프트(prompt)는 AI에게 건네는 지시문, 그러니까 "이렇게 해줘"라고 적어 보내는 그 문장 전체를 말합니다. 그리고 클로드코드가 헛발질하는 이유는 거의 이 셋 중 하나예요.

첫째, 내가 아는 걸 상대도 안다고 착각합니다. "지난달 자료 정리해줘"라는 문장에는 어느 폴더인지, 무슨 기준으로 나누는지, 결과를 어떤 형식으로 받고 싶은지가 하나도 없습니다. 사람 동료라면 되물었겠지만, AI는 빈칸을 스스로 그럴듯하게 메워 넣고 진행해버리죠.

둘째, 대화가 길어지면 앞을 잊습니다. 클로드코드는 지금까지 오간 모든 메시지, 읽은 파일, 실행한 명령의 출력을 전부 컨텍스트 창(context window) — 한 번에 기억할 수 있는 작업 기억의 크기 — 에 담아둡니다. 이게 차오를수록 성능이 떨어지고, 앞서 준 지시를 "잊어버린 것처럼" 굴기 시작해요. 파일 몇 개만 훑어도 이 공간은 놀라울 만큼 빨리 찹니다.

셋째, 확인할 방법을 안 줬습니다. 공식 문서의 표현을 빌리면, 클로드는 일이 다 된 것처럼 보일 때 멈춥니다. 결과가 맞는지 스스로 확인할 수단이 없으면 "그럴듯해 보임"이 유일한 종료 신호가 되고, 검산은 고스란히 사람 몫으로 넘어옵니다.

정리하면 이렇습니다. 지시가 막연하고, 문맥이 지저분하고, 채점 기준이 없다. 아래 여섯 가지는 이 셋을 하나씩 걷어내는 방법이에요.

2. 시키기 전에 계획부터 — 플랜 모드

가장 효과가 큰 습관 하나만 고르라면 이겁니다. 플랜 모드(plan mode) — 클로드가 파일을 읽고 조사만 할 뿐, 아무것도 고치지 않는 읽기 전용 상태입니다.

켜는 법은 세 가지 중 편한 걸 쓰면 됩니다.

실행 중에 Shift+Tab을 눌러 모드를 순환시킨다 (상태 표시줄에 현재 모드가 뜹니다)
이번 한 번만 계획을 받고 싶다면 지시문 앞에 /plan을 붙인다
아예 계획 상태로 시작하려면 claude --permission-mode plan으로 실행한다

앤트로픽이 권하는 순서는 훑어보기 → 계획 → 실행입니다. 비개발자 버전으로 옮기면 이렇게 되죠.

(플랜 모드에서)
2026 폴더 안에 뭐가 들어 있는지 먼저 읽어보고,
지난달 카드 명세서가 어떤 형식으로 저장돼 있는지 설명해줘. 아직 아무것도 고치지 마.

(같은 플랜 모드에서)
이 명세서로 월간 지출 요약표를 만들고 싶어.
어떤 파일을 새로 만들고, 어떤 순서로 처리할 건지 계획만 먼저 보여줘.

계획을 받아보면 절반은 여기서 걸러집니다. "아, 얘가 내가 말한 폴더를 다른 폴더로 알아들었네" 하는 순간이 계획 단계에서 잡히거든요. 계획이 마음에 들면 승인하고 실행으로 넘어가고, 아니면 그 자리에서 고쳐 말하면 됩니다. 계획 화면에서 Ctrl+G를 누르면 계획문을 직접 열어 손볼 수도 있고요.

다만 만능은 아닙니다. 공식 문서도 짚어두더군요 — 한 문장으로 설명되는 작업이면 계획 단계는 건너뛰라고. 오타 하나 고치는 데 계획서를 받을 이유는 없으니까요. 계획이 값을 하는 건 여러 파일이 얽힐 때, 방법이 확실치 않을 때, 그리고 결과물을 되돌리기 번거로울 때입니다.

▲ 클로드코드 플랜 모드가 파일을 고치기 전 읽기 전용 상태에서 실행 계획 네 단계를 먼저 제시한 터미널 화면 (자체 제작 이미지)

3. 지시문 다시 쓰기 — 범위·출처·본보기·증상

여기가 이 글의 본론입니다. 같은 일을 시키는데 결과가 갈리는 지점이요.

공식 문서는 좋은 프롬프트의 조건을 네 가지로 정리합니다. 작업 범위를 좁힐 것, 답이 있는 자료를 지목할 것, 따라 할 본보기를 줄 것, 증상과 원하는 결과를 함께 말할 것. 개발 용어가 붙어 있어 낯설어 보이지만, 비개발자의 일로 옮기면 전혀 어렵지 않습니다.

이렇게 말했더니 (❌)	이렇게 바꿨더니 (✅)	뭐가 달라졌나
"이 폴더 정리해줘"	"`영수증/2026-06` 폴더 안의 PDF만 대상으로, 날짜순으로 이름을 바꿔줘. 하위 폴더는 건드리지 마."	범위 — 어디까지가 일감인지 못박음
"이 파일 왜 이렇게 만들었어?"	"`요약본.md`가 만들어진 과정을 이전 대화 기록에서 찾아서 요약해줘."	출처 — 추측 대신 근거를 뒤지게 함
"보고서 하나 만들어줘"	"`지난달_보고서.md`가 내가 쓰는 형식이야. 그 구성과 말투를 그대로 따라서 이번 달 것을 만들어줘."	본보기 — 취향을 설명하는 대신 보여줌
"결과가 이상해"	"합계가 실제보다 3만 원 많이 나와. `합산.py`의 세금 처리 부분을 의심하고 있어. 원인을 찾아서 고치고, 왜 그랬는지 알려줘."	증상 — 어디가 어떻게 틀렸는지

네 줄 중 하나만 더해도 결과가 눈에 띄게 달라집니다. 넷 다 넣으면 대체로 한 번에 끝나고요.

여기에 붙이면 좋은 재료가 몇 개 더 있습니다. 파일 이름 앞에 @를 붙이면(예: @지난달_보고서.md) 클로드가 답하기 전에 그 파일을 먼저 읽습니다. 화면 캡처 이미지는 그냥 복사해서 붙여넣으면 되고, 참고할 웹 문서가 있으면 주소를 그대로 던져주면 됩니다.

반대로 일부러 막연하게 물어야 좋은 순간도 있어요. "이 폴더에서 개선할 만한 게 뭐가 있을까?" 같은 질문은 내가 물어볼 생각조차 못 했던 걸 끌어내줍니다. 탐색할 때는 열어두고, 실행시킬 때는 좁힌다 — 이 구분만 하면 됩니다.

한 가지 더. 규모가 큰 일이라면, 곧장 시키지 말고 거꾸로 인터뷰를 시켜보세요. "이런 걸 만들고 싶은데, 내가 미처 생각 못 한 부분을 질문으로 캐물어줘. 다 정리되면 요구사항 문서로 남겨줘"라고 부탁하는 방식입니다. 질문을 받다 보면 스스로도 몰랐던 조건이 튀어나오죠. 정리된 문서를 들고 새 대화창에서 시작하면, 문맥은 깨끗하고 요구사항은 명확한 상태로 출발할 수 있습니다.

4. 검증 방법을 같이 건네준다

3번까지 했는데도 "다 됐습니다"가 미덥지 않다면, 빠진 건 하나입니다. 채점 기준.

클로드에게 스스로 돌려볼 수 있는 확인 수단을 쥐여주면, 작업–확인–수정 고리가 사람 손을 거치지 않고 알아서 돕니다. 개발자라면 테스트 코드를 주겠지만, 비개발자에게도 대응물이 다 있어요.

숫자 작업이라면 → "합계가 원본 명세서 총액과 일치하는지 대조하고, 두 숫자를 나란히 보여줘."
문서 작업이라면 → "작성한 뒤 원본과 비교해서, 빠진 항목이 있으면 목록으로 알려줘."
화면·디자인이라면 → "결과 화면을 캡처해서 원본과 비교하고, 다른 점을 나열한 다음 고쳐줘."

그리고 마지막에 이 한 줄을 습관처럼 붙입니다. "됐다고만 하지 말고, 확인한 근거를 보여줘." 실행 결과든, 대조한 숫자든, 캡처든. 근거를 읽는 게 직접 재검산하는 것보다 훨씬 빠릅니다.

이 원칙은 결국 하나로 수렴합니다 — 확인할 수 없으면 쓰지 않는다. 그럴듯한 결과물을 그대로 믿고 넘기는 게 실무에서 가장 비싼 실수예요. 카드 명세서를 경비 보고서로 바꾸는 작업(그 과정은 여기)처럼 숫자가 오가는 일이라면 더더욱.

5. 매번 반복하는 말은 CLAUDE.md에 적어둔다

세 번째 대화창에서 똑같은 말을 또 치고 있다면, 그건 프롬프트가 아니라 설정으로 옮겨야 할 내용입니다.

CLAUDE.md는 작업 폴더에 두는 평범한 텍스트 파일이고, 클로드코드가 매 대화 시작 때 자동으로 읽습니다. 만드는 건 어렵지 않아요. 클로드코드 안에서 /init이라고 치면 폴더를 훑어보고 초안을 만들어줍니다. 거기에 내 규칙을 얹으면 됩니다.

무엇을 적느냐가 관건입니다. 공식 문서가 제시하는 기준은 단순해요. 각 줄마다 "이 줄을 지우면 클로드가 실수하게 되는가?"를 물어보고, 아니면 지우라는 겁니다.

넣을 것 — 코드를 읽어서는 알 수 없는 규칙, 내 환경의 특이사항, 자주 밟는 함정, 결과물 형식
뺄 것 — 스스로 알아낼 수 있는 것, 자주 바뀌는 정보, "깔끔하게 작성할 것" 같은 뻔한 말

그리고 구체적으로 씁니다. "보기 좋게 정리할 것"이 아니라 "표는 항상 날짜·항목·금액 순서로", "포맷을 잘 맞출 것"이 아니라 "들여쓰기는 공백 2칸". 검증할 수 있을 만큼 구체적인 문장만 실제로 지켜집니다.

여기서 대부분이 반대 방향으로 실수합니다. 길게 쓰면 잘 지킬 거라고 믿는 것. 사실은 정반대예요. 파일이 길어질수록 중요한 규칙이 잡음에 묻혀 무시당합니다. 공식 문서는 파일 하나당 200줄 이하를 목표로 하라고 권하고, 서로 모순되는 규칙이 있으면 클로드가 그중 하나를 임의로 고른다고도 적어뒀습니다. 규칙을 그렇게 적어뒀는데도 계속 안 지킨다면, 그건 규칙이 약해서가 아니라 파일이 길어서일 가능성이 큽니다.

같은 발상을 노트 정리에 써먹은 이야기는 옵시디언 자동화 후기에 적어뒀습니다. 규칙을 한 번 적어두면 매일 쌓이는 것들이 알아서 제자리를 찾아가죠. 애초에 노트를 옮겨온 과정은 또 다른 이야기고요.

6. 이미 엉뚱한 짓을 했다면 — 되돌리기와 판 갈기

사고는 납니다. 중요한 건 빨리 끊는 거예요. 공식 문서 표현으로는 "일찍, 자주 교정하라."

Esc — 작업 도중에 멈춥니다. 대화 내용은 그대로 남아서, 곧바로 방향을 돌려 말할 수 있어요.
Esc 두 번 (또는 /rewind) — 되감기 메뉴가 열립니다. 이전 시점의 대화와 파일 상태로 되돌릴 수 있습니다. 클로드는 파일을 고치기 전마다 자동으로 스냅숏을 남겨두거든요.
"방금 거 되돌려" — 그냥 말로 부탁해도 됩니다.
/clear — 대화 기억을 통째로 비우고 새 판을 깝니다.

이 중 가장 저평가된 게 /clear입니다. 문서에 이런 지침이 있어요. 같은 문제로 두 번 넘게 교정했다면, 그 대화창은 이미 실패한 시도들로 오염돼 있다. 지우고, 그동안 알아낸 걸 반영한 더 나은 지시문으로 다시 시작하라는 겁니다. 실제로 세 번째 교정보다 새 대화 한 번이 빠릅니다. 서로 관계없는 일을 옮겨갈 때도 마찬가지고요.

되감기 기능에는 조건이 하나 붙습니다. 클로드가 직접 한 변경만 추적한다는 것. 다른 프로그램이 건드린 파일이나, 클로드코드 밖에서 벌어진 일까지 되살려주지는 못합니다. 중요한 폴더에서 작업할 때는 시작 전에 사본을 떠두는 편이 마음 편해요.

터미널에서 이 모든 걸 다루는 게 계속 부담스럽다면, 방향을 바꾸는 것도 방법입니다. 터미널 없이 같은 종류의 일을 시키는 클로드 코워크가 있고, 정해진 절차를 매일 자동으로 돌리는 일이라면 애초에 n8n 쪽이 맞습니다. 셋 중 뭘 골라야 할지 감이 안 온다면 세 도구 비교를 먼저 보시는 게 순서겠네요.

▲ Esc를 두 번 눌러 열린 클로드코드 되감기 메뉴에서 대화와 파일을 이전 체크포인트로 복원하는 터미널 화면 (자체 제작 이미지)

7. 정리 — 보내기 전 5초 체크리스트

여섯 가지를 다 외울 필요는 없습니다. 엔터를 누르기 직전에 이것만 훑어보세요.

범위를 못 박았나 — 어느 폴더, 어느 파일, 어디까지. "건드리지 말 것"도 함께.
되돌리기 어려운 일인가 — 그렇다면 /plan으로 계획부터.
본보기를 줬나 — 원하는 형식의 결과물이 이미 있다면 @로 물려준다.
채점 기준을 줬나 — "확인한 근거를 보여줘"를 마지막 줄에.
세 번째 같은 말인가 — 그렇다면 프롬프트가 아니라 CLAUDE.md로.

여기 적힌 건 전부 "AI를 잘 구슬리는 요령"이 아닙니다. 일을 맡기기 전에 요구사항을 스스로 정리하는 절차죠. 사람 외주에게도 똑같이 필요한 것들이고, 다만 AI는 되물어주지 않으니 먼저 적어줘야 할 뿐입니다. 그래서 프롬프트를 다듬다 보면 부수 효과가 하나 따라옵니다 — 내가 뭘 원했는지 나도 비로소 알게 된다는 것.

공식 문서의 마지막 조언이 인상적이더군요. 이 원칙들은 돌에 새긴 게 아니라 출발점이라고. 결과가 잘 나왔을 때 내가 뭘 다르게 했는지 눈여겨보고, 망했을 때 문맥이 지저분했는지 지시가 막연했는지 되짚어보라는 겁니다. 몇 주만 그렇게 해보면, 어떤 글에도 안 적혀 있는 감각이 손에 붙습니다.

이 글은 정보 제공을 목적으로 하며, 작성 시점(2026년 7월) 기준 정보입니다. 클로드코드의 명령어·모드·기본 동작은 버전 업데이트에 따라 바뀔 수 있으니, 중요한 작업 전에는 공식 문서 원문을 한 번 확인하시길 권합니다. 요금·정책 역시 변동될 수 있습니다. 특정 제품의 사용을 권유하거나 결과를 보장하지 않습니다.

참고한 공식 자료 - 클로드코드 모범 사례(계획·프롬프트·문맥 관리·되돌리기): code.claude.com/docs — Best practices - 승인 모드와 플랜 모드: code.claude.com/docs — Permission modes - CLAUDE.md와 자동 메모리: code.claude.com/docs — Memory - 클로드코드 개요: code.claude.com/docs — Overview

클로드코드 프롬프트, 이것만 바꿔도 엉뚱한 결과가 줄어듭니다 — 비개발자 지시법 6가지