Claude Code 위험한 프롬프트 피하기: 자동 push와 테스트 생략 막기

Claude Code에 “전부 고치고, 알아서 push하고, 테스트는 나중에 해”라고 지시하면 빠르게 보일 수 있습니다. 하지만 파일을 수정하고, 셸 명령을 실행하고, git을 다루고, 문서를 확인할 수 있는 도구에서는 그 한 문장이 리뷰 통제권을 잃는 출발점이 될 수 있습니다.

이 글은 불안을 키우려는 글이 아니라 예방을 위한 글입니다. 2026년 6월 3일 기준으로 Claude Code 공식 문서의 permission mode, /permissions, settings.json, common workflows를 확인했고, 위험한 표현을 실무에서 바로 붙여 넣을 수 있는 안전한 프롬프트로 바꿨습니다.

flowchart LR
  A["요청 작성"] --> B["조사만 허용"]
  B --> C["계획 리뷰"]
  C --> D["작게 수정"]
  D --> E["테스트와 diff 확인"]
  E --> F["push/deploy는 사람이 판단"]

위험한 프롬프트란

여기서 위험하다는 말은 악의적이라는 뜻이 아닙니다. 범위, 권한, 완료 기준이 모호한 상태에서 Claude Code에 강한 작업을 맡기는 요청을 말합니다. 초보자에게 쉽게 말하면, 권한 경계란 에이전트가 파일을 수정하거나 명령을 실행하거나 프로젝트 밖으로 나가기 전에 사람에게 확인해야 하는 선입니다.

Claude Code는 프로젝트 파일을 읽고 검색하고, 코드를 수정하고, 테스트를 실행하고, git을 사용할 수 있습니다. 공식 문서는 로컬 세션에서 Claude Code가 사용자의 파일과 터미널 권한 안에서 작업할 수 있다고 설명합니다. 그래서 좋은 프롬프트는 허용할 작업뿐 아니라 금지할 작업도 함께 적어야 합니다.

위험한 표현	안전한 대체 표현
전부 고쳐	대상 파일과 제외 파일을 지정하고 먼저 계획을 요청
끝나면 push해	diff와 테스트 결과를 요약하고 push는 내가 판단
테스트는 건너뛰어	최소 확인 명령을 제안하고 실행 불가 시 이유 설명
운영 DB에서 확인해	dev/staging만 사용하고 운영 SQL은 생성만 하기
승인 전부 생략해	Plan mode로 조사하고 승인된 단계만 하나씩 진행
오래된 것 지워	삭제 후보를 먼저 나열하고 승인 후에만 삭제
전부 latest로 올려	보안 수정, minor update, major update를 분리
조사해서 구현해	공식 출처를 제시하고 조사 결과와 수정안을 분리

최신 문서에서 확인한 권한 경계

Claude Code의 permission mode는 채팅에 “안전하게 해”라고 쓴다고 바뀌지 않습니다. CLI에서는 Shift+Tab 또는 --permission-mode로 바꾸고, IDE와 Desktop에서는 모드 선택기를 사용하며, 지속 설정은 settings.json에 둡니다.

2026년 6월 3일 기준 공식 문서의 주요 모드는 다음과 같습니다. default는 읽기 외 작업 전에 확인합니다. acceptEdits는 파일 수정과 일반적인 파일 시스템 작업을 자동 승인합니다. plan은 읽기, 탐색, 계획 제안에 적합합니다. auto는 백그라운드 안전성 검사를 포함한 연구 프리뷰입니다. dontAsk는 사전 승인되지 않은 도구를 거부합니다. bypassPermissions는 격리된 컨테이너나 VM에서만 고려해야 합니다.

/permissions는 Allow, Ask, Deny 규칙을 보여줍니다. Deny가 우선하므로 팀에서는 force push, .env 읽기, 운영 배포 명령을 차단하는 쪽이 안전합니다. 공유 규칙은 .claude/settings.json에, 개인 실험은 .claude/settings.local.json에 두는 것이 좋습니다.

최소 settings.json

아래 예시는 출발점입니다. 프로젝트에 맞게 명령 이름만 조정하세요.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

핵심은 절제입니다. Bash(*) 같은 넓은 허용은 승인 레이어를 얇게 만듭니다. npm run test와 git diff처럼 반복 가능한 확인만 미리 허용하면 속도와 리뷰 가능성을 함께 얻을 수 있습니다.

유스케이스 1: 버그 수정

위험한 요청은 “로그인 쪽 전부 고치고 동작하면 push해”입니다. 범위가 너무 넓고 원격 작업이 수정과 묶여 있습니다.

목적: 로그인 직후 세션이 만료되는 버그를 수정한다.
범위: src/auth/**, src/session/**, tests/auth/** 만 대상으로 한다.
금지: git push, deploy, 운영 DB 접근, .env 읽기.
진행:
1. 관련 파일을 읽고 가능한 원인을 최대 3개 제시한다.
2. 변경 계획을 제안하고 내 승인을 기다린다.
3. 승인 후 가장 작은 유효 변경을 적용한다.
4. npm run test -- auth 를 실행하고 실패가 있으면 요약한다.
5. 마지막에 git diff 요약과 남은 리스크를 보고한다.

이렇게 쓰면 Claude Code가 조사, 수정, 검증에 집중하면서 리뷰 지점은 유지됩니다. 작은 버그 수정에 불필요한 전체 재작성도 줄일 수 있습니다.

유스케이스 2: 리팩터링

위험한 요청은 “오래된 구현을 정리하고 필요 없는 파일은 삭제해”입니다. 오래된, 정리, 필요 없음은 사람 사이에서도 해석이 갈리는 말입니다.

목적: billing 모듈의 중복 validation을 정리한다.
수정 가능 범위: src/billing/validators.ts 와 해당 테스트.
수정 금지: migrations/**, prisma/**, public/**, package-lock.json.
삭제 규칙: 삭제 후보만 나열한다. 승인 없이 삭제하지 않는다.
검증: npm run test -- billing 과 npm run lint 를 실행한다.
출력: 변경 이유, 호환성 영향, 추가할 테스트를 짧게 보고한다.

리팩터링에서는 대상보다 제외 목록이 더 중요할 때가 많습니다. migration, lockfile, 생성 파일은 겉보기만으로 불필요하다고 판단하기 어렵습니다.

유스케이스 3: 배포 전 확인

위험한 요청은 “CI가 느리니 건너뛰고 운영에 배포해”입니다. --no-verify는 lint뿐 아니라 secret scan과 hook까지 건너뛸 수 있습니다.

목적: 릴리스 전 짧은 준비 점검을 수행한다.
허용 명령: git status, git diff, npm run test -- --runInBand, npm run build.
금지 명령: git push, deploy, --no-verify, npm publish.
판단 기준:
- 테스트 또는 build가 실패하면 즉시 중지한다.
- 실패 로그는 마지막 80줄만 요약한다.
- 상태를 가능 / 수정 필요 / 판단 보류로 보고한다.

배포는 고객, 결제, 검색 인덱스, 캐시, 지원 업무와 연결됩니다. Claude Code에는 근거 준비를 맡기고 최종 릴리스 작업은 사람이 명시적으로 판단해야 합니다.

유스케이스 4: 조사와 문서 업데이트

위험한 요청은 “최신 정보를 찾아서 알아서 문서에 반영해”입니다. 외부 정보는 바뀌므로 출처와 편집 범위를 분리해야 합니다.

목적: Claude Code permission mode 설명을 업데이트한다.
출처: 공식 문서를 우선하고 마지막에 URL을 나열한다.
금지: 공식 문서에서 확인되지 않은 기능을 단정하지 않는다.
진행:
1. 현재 글과 공식 문서의 차이를 표로 만든다.
2. 수정안만 제안하고 실제 편집 전에는 기다린다.
3. 편집 후 오래된 링크와 description 길이를 확인한다.

조사 작업에서는 Claude Code를 먼저 출처 확인자와 diff 정리 담당으로 두고, 그다음 작성자로 쓰는 편이 안전합니다.

구체적인 실패 사례

첫째, 무제한 재시도입니다. “성공할 때까지 재시도”는 장애 상황을 비용 증가와 rate limit 압박으로 키울 수 있습니다. 최대 횟수, 대기 시간, 중단 조건을 명확히 적어야 합니다.

둘째, secret입니다. 실제 API key를 프롬프트에 붙여 넣으면 대화 기록, 로컬 로그, subagent 전달에 남을 수 있습니다. 값은 환경 변수나 secret manager에 두고, 프롬프트에는 변수명만 적습니다.

셋째, 의존성 업데이트입니다. “모든 패키지를 latest로”는 breaking change가 있는 major version을 끌어올 수 있습니다. npm outdated로 목록을 만들고, 보안 수정과 일반 업데이트, major 업데이트를 분리해 리뷰합니다.

넷째, cleanup과 migration입니다. “DB 파일 정리”는 migration 이력 삭제로 해석될 수 있습니다. 먼저 목록만 요청하고, 운영 데이터에 영향을 주는 작업은 SQL 생성 단계에서 멈추는 것이 안전합니다.

리뷰 체크리스트

영향이 큰 프롬프트 끝에 붙여 넣으세요.

안전 확인:
[ ] 대상 파일과 제외 파일을 명시했다
[ ] git push / deploy / publish 를 금지하거나 승인제로 했다
[ ] 운영 DB, 운영 API, 비용 발생 작업을 차단했다
[ ] .env, private key, 개인정보 읽기를 차단했다
[ ] 편집 전 Plan mode 또는 계획 제시를 요청했다
[ ] test, lint, build 중 최소 하나를 포함했다
[ ] 실패 시 중지하고 로그를 요약하도록 했다
[ ] 마지막에 diff, 실행 명령, 남은 리스크를 보고하게 했다

이 규칙을 매번 다시 쓰기보다 재사용 가능한 템플릿이 필요하다면 상품 목록에 프롬프트 팩과 체크리스트를 정리해 두었습니다. 팀 도입에서는 CLAUDE.md, 권한 설정, 리뷰 게이트, 온보딩 연습을 실제 저장소 기준으로 Claude Code 교육 및 도입 상담에서 설계할 수 있습니다.

관련 글

• Claude Code에서 발생한 실제 운영 장애 7가지와 복구 절차
• Claude Code 보안 모범 사례 완전 가이드
• Claude Code 권한 설정 완전 가이드
• Claude Code 승인 흐름과 샌드박스 설계

공식 링크

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

실제로 시도한 결과: Masa의 운영에서는 Plan mode로 시작하고, 변경 범위를 두세 파일에서 다섯 파일 정도로 제한하고, push/deploy를 사람이 판단하도록 남긴 것이 가장 효과적이었습니다. 위험한 프롬프트를 피하는 것은 Claude Code를 느리게 만드는 일이 아니라, 인계를 정확하게 만들어 더 빠르고 편하게 리뷰하기 위한 일입니다.