Claude Code의 위험한 프롬프트 패턴 10선 | 하면 안 되는 지시와 안전한 대안

“대충 전달되겠지”라고 생각하며 프롬프트를 작성하고 있지는 않으신가요? Claude Code는 지시를 문자 그대로 실행합니다. 모호한 지시·위험한 지시는 의도치 않은 결과를 낳습니다.

이 글에서는 실제 사고로 이어진 위험한 프롬프트 패턴 10선과 각각의 안전한 대안 표현을 해설합니다. 읽은 후 “아, 이 패턴 쓰고 있었네”라고 느꼈다면 지금 바로 바꾸세요.

---

패턴 1: “전부 읽어서 전체를 이해해”

왜 위험한가

❌ "이 리포지토리를 전부 읽고 이해한 다음 구현해"

수백 개의 파일을 가진 리포지토리에서 실행하면 컨텍스트가 폭발합니다. 수만 토큰을 소비하고 Prompt is too long 에러로 처리가 멈춥니다. 읽는 도중에 멈추면 불완전한 상태에서의 구현으로 이어집니다.

또한 .env나 비밀 키를 포함한 파일이 있다면, 그것들도 모두 컨텍스트에 로드됩니다.

안전한 대안

✅ "src/api/ 디렉토리의 구조를 확인하고, auth 관련 파일만 읽어"
✅ "먼저 package.json과 README만 읽어서 프로젝트 개요를 파악해"
✅ "인증 관련 파일을 Grep으로 찾은 다음 읽어"

포인트: 읽을 범위를 명시적으로 좁힌다. Claude Code는 지정이 없으면 광범위하게 읽으려고 합니다.

---

패턴 2: “에러가 나면 자동으로 리트라이해”

왜 위험한가

❌ "외부 API 호출에서 에러가 나면 자동으로 리트라이해서 성공할 때까지 계속해"

외부 서비스가 다운 중이라면 무한 루프로 API를 계속 호출합니다. 1시간에 수만 번 호출, 과금이 수십만 원에서 수백만 원으로 불어나는 사고가 실제로 발생했습니다. 특히 야간 배치에서 모르는 채로 아침까지 돌아가는 사례가 많습니다.

안전한 대안

✅ "에러가 나면 최대 3번 리트라이해.
   1번째는 1초 후, 2번째는 4초 후, 3번째는 16초 후에 재시도.
   3번 실패하면 에러 로그를 남기고 처리를 멈춰"

✅ "리트라이에는 다음 코드를 사용해:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

패턴 3: “프로덕션 DB에 직접 접속해서 확인해”

왜 위험한가

❌ "DATABASE_URL의 프로덕션 DB에 접속해서 유저 수를 확인하고 수정해"

“확인만” 하려 했지만 그 후의 수정 쿼리가 프로덕션 DB에 실행되는 리스크가 있습니다. 또한 SELECT 다음에 실수로 DELETE나 UPDATE가 이어지면 프로덕션 데이터가 사라집니다. 프로덕션 DB 접속은 의도 범위를 초과한 조작을 유발하기 쉽습니다.

안전한 대안

✅ "개발 DB (DATABASE_URL_DEV)에 접속해서 유저 수를 확인해.
   프로덕션에는 접속하지 마"

✅ "쿼리만 생성하고 실행은 하지 마.
   확인 후 내가 실행할게"

✅ CLAUDE.md에 명기:
"프로덕션 DATABASE_URL에 대한 쿼리 실행은 금지.
 스테이징에서 확인 후, 유저 승인 후에만 실행 가능"

---

패턴 4: “이 API 키를 사용해서 〇〇해”라며 키를 프롬프트에 붙여넣기

왜 위험한가

❌ "QIITA_TOKEN=abc123def456을 사용해서 Qiita에 포스팅해"
❌ "sk-ant-api03-xxxxx를 사용해서 Anthropic API를 호출해"

프롬프트에 쓴 내용은 대화 히스토리로 저장됩니다. 서브 에이전트에 위임할 때도 그대로 전달됩니다. 로컬 .claude/ 하위 로그에 남아 백업 툴이나 코드 공유로 의도치 않게 외부로 나갈 가능성이 있습니다.

안전한 대안

✅ ".env의 QIITA_TOKEN을 사용해서 scripts/qiita-publish.mjs를 실행해"
   ← 토큰 값은 .env에만 존재, 프롬프트에는 변수명만 쓴다

✅ 스크립트 측에서 환경변수에서 읽기:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN이 설정되어 있지 않습니다");

---

패턴 5: “충돌을 해소해서 프로덕션에 푸시해”

왜 위험한가

❌ "main 브랜치와 충돌하고 있어. 해소하고 프로덕션에 푸시해"

“충돌 해소”의 수단으로 git push --force가 선택되는 경우가 있습니다. 팀 멤버의 커밋이 사라지는 리스크가 있습니다. 또한 “프로덕션에 푸시해”는 CI/CD를 거치지 않고 직접 푸시될 가능성도 있습니다.

안전한 대안

✅ "main과의 충돌을 확인하고, 머지 전략을 제안해.
   실제 머지와 푸시는 내가 승인한 다음 실행해"

✅ CLAUDE.md에 명기:
"git push --force는 금지.
 force가 필요한 경우 --force-with-lease를 사용하고, 유저에게 확인을 받아"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

패턴 6: “오래된 파일을 전부 삭제해서 깔끔하게 해”

왜 위험한가

❌ "dist/와 .cache/와 오래된 로그 파일을 전부 삭제해서 깔끔하게 해"

“오래된”의 정의가 모호하기 때문에 필요한 파일까지 삭제되는 리스크가 있습니다. 특히 .cache/ 계열은 OS·툴 고유의 중요 데이터를 포함하는 경우가 있습니다. 또한 여러 디렉토리를 한 번에 지정하면 rm -rf dist .cache logs/가 되어, 의도치 않은 경로에 영향을 미치는 경우도 있습니다.

안전한 대안

✅ "site/dist/ 디렉토리의 내용물만 삭제해.
   디렉토리 자체는 남겨. 다른 디렉토리는 건드리지 마"

✅ "삭제하기 전에 삭제 대상 파일 목록을 표시해서 확인시켜.
   승인하면 삭제해"

---

패턴 7: “승인을 전부 자동으로 OK해서 한꺼번에 실행해”

왜 위험한가

❌ "중간의 확인은 전부 스킵해서, 한 번에 마지막까지 실행해"
❌ "--dangerously-skip-permissions 옵션을 붙여서 실행해"

승인 플로우는 안전 장치입니다. 스킵하면 Claude Code가 “가장 효율적”이라고 판단한 방법으로 처리를 진행합니다. 그게 rm -rf나 force push나 프로덕션 DB 쓰기라도 확인 없이 실행됩니다.

안전한 대안

✅ "이 태스크의 절차를 먼저 목록으로 써줘.
   승인하면 1스텝씩 실행해서, 각 스텝에서 결과를 확인해"

✅ 자동화가 필요한 경우 신뢰할 수 있는 조작만 allow에:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

패턴 8: “마이그레이션을 최신으로 맞춰서 DB를 정리해”

왜 위험한가

❌ "마이그레이션 파일이 어질러져 있어. 정리해서 최신 상태로 만들어"

“정리”의 해석으로 오래된 마이그레이션 파일을 삭제하는 동작이 일어날 수 있습니다. 마이그레이션 히스토리가 사라지면 새로운 환경에서의 셋업이나 롤백이 불가능해집니다. 또한 migrate reset 계열의 커맨드가 실행되면 프로덕션 데이터가 사라질 위험이 있습니다.

안전한 대안

✅ "마이그레이션 파일 목록을 표시하고, 중복이나 문제가 있으면 지적만 해.
   변경은 가하지 마"

✅ "미실행 마이그레이션을 확인하고, 실행 예정인 SQL을 표시해.
   승인하면 실행해"

✅ CLAUDE.md에 명기:
"마이그레이션 파일은 삭제하지 않는다.
 ALTER/DROP을 포함하는 마이그레이션 실행은 반드시 유저 확인을 받는다"

---

패턴 9: “패키지를 전부 최신으로 해”

왜 위험한가

❌ "npm 패키지가 오래됐어. 전부 최신 버전으로 업데이트해"

npm update나 npm install 패키지@latest는 메이저 버전을 올리는 경우가 있습니다. Breaking changes가 포함된 경우, 로컬 빌드는 통과해도 프로덕션 배포 후에 서비스가 멈출 수 있습니다. 의존성의 연쇄 파괴도 일어나기 쉽습니다.

안전한 대안

✅ "npm outdated를 실행하고, 업데이트 가능한 패키지 목록을 보여줘.
   메이저 버전이 올라가는 건 따로 확인할게"

✅ "보안 취약점이 있는 (npm audit으로 검출된) 패키지만 업데이트해"

✅ "react와 next.js만 최신 마이너 버전으로 업데이트해.
   메이저 버전은 올리지 마"

---

패턴 10: “테스트는 나중에 해도 되니까 먼저 배포해”

왜 위험한가

❌ "테스트는 나중에 쓸 테니까, 지금은 배포를 먼저 해"
❌ "CI가 느려서 --no-verify로 스킵해서 push해"

테스트와 CI는 “느린” 게 아니라 “지켜주는” 것입니다. 스킵한 결과, 프로덕션에서 처음으로 버그가 발견되는 게 최악의 패턴입니다. --no-verify는 git hooks를 포함해 전부 무효화하기 때문에 시크릿 스캔이나 lint도 건너뜁니다.

안전한 대안

✅ "테스트를 먼저 작성하고, 통과하면 배포해.
   테스트 커버리지가 불충분해도 주요 경로만이라도 OK"

✅ "CI가 느린 원인을 조사해서, 캐시를 활용해 빠르게 해줘.
   스킵은 하지 마"

✅ CLAUDE.md에 명기:
"--no-verify는 금지.
 CI를 스킵하는 수단을 일체 사용하지 않는다"

---

정리: 안전한 프롬프트 작성의 3원칙

원칙 1: 범위를 명시한다 “전부”, “모두”, “전체”는 위험 단어입니다. 읽을 범위·변경할 범위·삭제 대상을 구체적으로 지정하세요.

원칙 2: 확인 스텝을 남긴다 “실행해” 앞에 “확인해”, “제안해”, “목록을 보여줘”를 끼워 넣으세요. 특히 프로덕션에 영향을 미치는 조작에서는.

원칙 3: 비밀 정보를 프롬프트에 쓰지 않는다 API 키·패스워드·접속 문자열은 .env에 두고, 프롬프트에는 변수명만 씁니다.

위험 단어	안전한 대안
”전부 읽어"	"〇〇 디렉토리만 읽어"
"자동으로 리트라이해"	"최대 3번 리트라이해, 실패하면 멈춰"
"프로덕션 DB에 접속해"	"개발 DB에서 확인해, 프로덕션은 내가 실행할게"
"전부 삭제해서 깔끔하게"	"〇〇만 삭제해, 먼저 목록을 보여줘"
"한꺼번에 실행해"	"먼저 절차를 확인시켜줘, 승인 후 진행해”

Claude Code는 지시에 충실할 뿐이며, 악의는 없습니다. 위험한 건 모호한 지시를 내리는 쪽입니다. 구체적이고 범위가 명확한 지시를 쓰는 습관이 사고를 막는 최단경로입니다.

관련 기사

• Claude Code에서 발생한 프로덕션 장애 7사례와 완전 복구 절차
• Claude Code 보안 대책 완전 가이드
• Claude Code 권한 설정 완전 가이드

참고 자료

• Claude Code 공식 보안 가이드
• OWASP LLM Application Security