AI가 데이터베이스를 삭제했다: 7분 복구 계획

Ailoot 사용에 관한 실용적인 정보는 문서에서 확인할 수 있습니다.

첫 1분에 할 일: 중지, 당황하지 않기#

이런 일이 생기면 가장 먼저 에이전트를 중지하세요. 에이전트의 작업을 직접 되돌리려 하지 말고, “전부 복구해”라고 지시하지도 말고, 새 프롬프트를 실행하지도 마세요. 에이전트가 이후에 수행하는 각 작업이 데이터가 아직 저장되어 있을 수 있는 디스크 블록을 덮어쓸 수 있습니다.

1. 에이전트의 터미널 닫기

   삭제 완료를 기다리지 말고 Ctrl+C로 위험 명령을 즉시 중단하세요. 에이전트 중지가 자식 명령, 원격 작업, DB 쿼리를 멈춘다는 보장은 없습니다. 실제 쓰기를 찾아 취소하고 계속 파괴하면 종료를 강화하세요. 유용한 파일을 열고 있는 무관 프로세스는 유지하세요.

2. 노트북을 재부팅하지 마세요

   삭제 데이터의 복구는 저장소, 데이터베이스, SSD discard/TRIM, 후속 쓰기에 달려 있습니다. 바이트가 남았다고 가정하지 말고 해당 볼륨 쓰기를 최소화하세요.

3. 열려 있는 프로세스를 종료하지 마세요

   삭제 파일을 연 무관 프로세스는 파일 디스크립터 복구를 위해 보존하세요. 파괴적 쓰기에는 해당하지 않습니다. 열린 핸들을 지키려고 삭제를 계속 실행하지 마세요.

4. 화면 녹화 시작하기

   정확한 시간, 경로, 화면 명령 출력을 기록하세요. 녹화·로그는 손상 볼륨이 아닌 별도 검증 기기에 저장하고 복구 전에 tracked·untracked·ignored 파일과 Git 메타데이터를 보존하세요.

복구 성공이나 소요 시간은 보장되지 않습니다. 보존한 사본에서 다음 검사를 진행하세요.

2–3분: 무엇이 잘못됐는지 정확히 기록하기#

새 터미널 창을 여세요. 에이전트가 실행 중인 창이 아니라 다른 창을 열어야 합니다. 다음 세 명령을 순서대로 실행하세요.

1. git 저장소에서 정확히 무엇이 변경됐는지 기록하기:

git status
git log --since="30 minutes ago" --all --oneline

삭제된 추적 파일은 인덱스나 커밋에 남을 수 있습니다. 복원은 남은 수정을 덮을 수 있으므로 먼저 미추적·무시 파일을 포함한 현재 트리를 보존하고 별도 사본에서 검사·복구하세요.

2. 어떤 에이전트 프로세스가 실행 중인지 확인하기:

ps aux | grep -i claude
ps aux | grep -i cursor

이름 일치만으로 판단하지 말고 실제 위험한 쓰기 프로세스를 확인해 중지와 정지를 검증하세요. 유용한 열린 파일이 있는 무관 프로세스는 보존하세요. 정상 종료가 실패하고 파괴가 계속되면 강제 종료가 필요할 수 있습니다.

3. 에이전트 세션 기록 저장하기:

Claude Code는 JSONL 세션을 ~/.claude/projects/에 저장합니다. Cursor는 ~/.cursor/에 저장합니다. 지금 바로 복사본을 만드세요.

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

/external/incident-evidence/는 별도 검증 장치의 기존 증거 디렉터리로 바꾸세요. 손상 볼륨에 쓰거나 기존 증거를 덮어쓰지 마세요. 이 폴더에는 에이전트와 나눈 대화가 그대로 들어 있습니다. 에이전트가 실행한 명령, 응답, 실행 순서를 확인할 수 있습니다. 사고를 조사하고 에이전트의 문맥에서 삭제된 파일을 복구할 가능성을 살펴볼 때 가장 중요한 자료입니다(4단계 참조).

4분: git reflog—가장 좋은 복구 기회#

git reflog는 보존 기간 동안 로컬 참조 이동을 기록합니다. 만료·정리는 다르고 도달 불가 객체가 제거될 수 있으므로 모든 과거 커밋의 보장 아카이브가 아닙니다. 다음은 별도 기기의 보존 사본에서 실행하세요.

1단계. 기록 보기:

git reflog --all

다음과 같은 목록이 표시됩니다.

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

에이전트가 손상을 일으키기 전의 지점을 찾으세요. 각 항목은 해당 시점의 저장소 상태를 담은 “스냅샷”입니다.

2단계. 별도 작업 트리로 복구:

저장소와 생존 파일을 별도 기기에 복사한 뒤 보존 사본에서 실행하세요. 확인한 정확한 SHA와 미사용 브랜치·목적지를 쓰세요.

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

../recovery-check를 보존한 미커밋 파일과 비교한 뒤 복사하세요. 손상 트리를 reset하지 않습니다. 연결 worktree는 복사 저장소의 Git 객체를 공유하므로 복구 공간이지 독립 백업은 아닙니다. 공식 git-worktree 문서를 보세요.

reflog까지 정리된 경우(에이전트가 git gc를 실행한 경우):

git fsck --lost-found

이 명령은 어떤 브랜치에도 연결되지 않은 “분실된” 커밋과 블롭(파일 객체)을 찾습니다. .git/lost-found/commit/과 .git/lost-found/other/에 나타납니다. 여기서 파일을 복원하려면:

git cat-file -p <SHA1-blob> > recovered-file.ext

git reflog가 도움이 되지 않는 경우:

• 파일이 커밋이나 스태시 없이 작업 트리에만 있었음 → reflog로 찾을 수 없음
• 표준 gc.reflogExpire 기간인 90일이 지났고 git gc가 실행됨
• 저장소 전체가 삭제됨(rm -rf .git)—이 경우 Time Machine이나 스냅샷이 필요함

5분: 백업에서 데이터베이스 복원하기#

DROP DATABASE, DROP TABLE 또는 DELETE FROM ... WHERE ...(WHERE 절 없이)로 데이터베이스가 삭제됐습니다. 어떻게 해야 할까요?

1단계. 제공업체가 PITR을 제공하는지 확인하기:

2단계. 기존 인스턴스가 아닌 새 인스턴스에 복원하기:

실행 중인 데이터베이스 위에 복원하지 마세요. 백업에서 새 인스턴스를 만든 다음 애플리케이션이 새 인스턴스를 사용하도록 전환하세요. 문제가 생기면 DNS를 다시 전환할 수 있습니다.

3단계. PITR이 활성화되지 않았다면 가장 최근 스냅샷 사용하기:

# AWS RDS, 스냅샷 목록:
aws rds describe-db-snapshots --db-instance-identifier my-db

# 스냅샷에서 복원:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Supabase 관련 주의사항—2026년에 많은 사용자가 겪은 문제입니다. PITR을 활성화하면 일일 백업 생성이 중단됩니다. 직관에 어긋나는 동작으로, 백업이 하나도 없는 상황이 생길 수 있습니다. Dashboard → Database → Backups에서 PITR이 활성화되어 있는지, 복원할 스냅샷이 있는지 확인하세요.

6분: Time Machine, lsof, 디스크 스냅샷#

macOS—Time Machine:

# 스냅샷 목록:
tmutil listbackups

# 최신 백업에서 파일 복원:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine은 매시간 스냅샷을 만들고, 시간별 스냅샷은 하루, 일별 스냅샷은 일주일, 주별 스냅샷은 무기한 보관합니다. 노트북이 Time Capsule이나 외장 드라이브에 연결되어 있었다면 프로젝트를 매시간 단위로 복구할 수 있습니다.

Linux—파일은 삭제됐지만 프로세스가 계속 열어 둔 경우:

# 프로세스가 계속 열어 둔 “삭제된” 파일 모두 찾기:
sudo lsof | grep deleted

# 다음과 같은 줄이 표시됩니다:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# /proc/PID/fd/N에서 파일을 바로 복사:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

프로세스가 종료되지 않았다면 성공 확률은 약 95%입니다. ext4, xfs, btrfs에서 작동합니다.

macOS—lsof를 사용하는 방법:

lsof | grep deleted

파일 복사는 더 어렵습니다(/proc/가 없음). 하지만 lldb로 할 수 있습니다.

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

디스크 전체 스냅샷(Linux, 최후의 수단):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

파티션 전체가 이미지로 저장됩니다. 그런 다음 extundelete 또는 photorec를 사용해 복구하세요. 복구 가능성은 삭제 후 디스크에 얼마나 많은 데이터가 기록됐는지에 따라 달라집니다. 아무것도 기록되지 않았다면 80–90%입니다. 이미 한 시간 동안 실행 중이었다면 20–30%입니다.

7분: 백업이 없는 경우#

방법 1—제공업체 지원팀:

AWS, Yandex Cloud, Google Cloud, DigitalOcean은 고객 측 재난이 발생한 뒤에도 내부 저장소에서 주기적으로 데이터를 복구합니다. 유료 요금제라면 특히 그렇습니다. 지원 티켓을 열고 정확한 사고 시각과 상태 스크린샷을 제공하세요. 자체 자동 백업을 보관하는 대형 제공업체에서 성공할 가능성이 가장 높습니다. 성공 확률은 40–60%이며 응답까지 24–72시간이 걸립니다.

방법 2—S3 버전 관리:

파일이 S3(또는 Yandex Object Storage)에 있었고 버전 관리가 활성화되어 있었다면 모든 버전이 물리적으로 존재합니다. 단지 “삭제됨”으로 표시되어 있을 뿐입니다.

# AWS—버전 목록:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# 버전 복원:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

중요한 주의사항: Claude Code는 세션을 영구 보관하지 않습니다. 오래된 JSONL 파일은 몇 주 뒤 자동으로 삭제됩니다. 재난에 대비해 JSONL 기록을 한 달치 보관하려면 간단한 cron 작업으로 ~/.claude/projects/를 매주 외장 드라이브에 복사하세요.

# crontab에 매주 일요일 03:00에 추가:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

무료이며, “모든 게 사라지고 백업도 없고 reflog도 비어 있는” 상황에서 도움이 됩니다.

이런 일이 다시 일어나지 않도록 하는 7가지 규칙#

1. 파괴적인 작업 전에는 Plan Mode를 사용하세요. Claude Code에서:

claude --plan

에이전트가 작업을 시작하기 전에 계획을 세웁니다. 계획을 읽다가 DROP TABLE users가 보이면 취소하면 됩니다. Plan Mode가 없으면 에이전트가 스스로 판단해 몇 밀리초 만에 실행합니다. 자세한 내용은 Claude Code Plan Mode 가이드를 참조하세요.

2. 추가 경고 장치로 hook 사용. stdin 이벤트 JSON을 읽고 인식한 위험에 종료 코드 2를 반환하는 PreToolUse를 시험하세요. 아래 전체 예시는 Bash·Write·Edit을 다루지만 간접 동작을 놓칠 수 있어 보안 경계는 아닙니다. DB 권한과 sandbox를 제한하세요. 공식 문서의 계약을 확인하세요.

설정에 관한 자세한 내용은 2026 Claude Code Hooks 가이드를 참조하세요.

3. 에이전트용 읽기 전용 DB 사용자. DROP, TRUNCATE, DELETE 권한이 없는 별도 사용자를 만드세요.

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

에이전트가 실제로 쓰기 작업을 해야 할 때는 수동으로 다른 사용자로 전환하세요. 읽기 전용 사용자는 일상 작업(데이터 분석, 보고서, 대시보드)에 충분합니다.

4. 검토한 변경 사항을 Git에 기록하세요. .claude/settings.json의 PostToolUse hook은 Write와 Edit 후에 알림을 출력할 수 있습니다.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'diff를 검토하고 합의한 파일만 직접 커밋하세요.' >&2"
          }
        ]
      }
    ]
  }
}

이 예시는 알림만 출력하며 파일을 스테이징하거나 커밋하지 않습니다. diff를 검토하고 합의한 파일만 직접 커밋하세요. reflog는 커밋하지 않은 변경 사항을 저장하지 않습니다.

5. 실험용 샌드박스 프로젝트. 실제 고객 데이터가 들어 있는 프로젝트에서 에이전트를 작업하게 하지 마세요. 프로젝트 복사본과 합성 데이터를 넣은 별도의 ~/sandbox-projects/ 폴더를 만드세요. 새 프롬프트, 에이전트 또는 MCP 서버를 시험할 때 사용하세요. 무언가 잘못돼도 피해가 없습니다.

6. restic으로 매시간 디스크 스냅샷 만들기.

# 설치:
brew install restic  # macOS
sudo apt install restic  # Linux

# 저장소 만들기:
restic init --repo /external/backups

# 현재 프로젝트 백업:
restic --repo /external/backups backup ~/projects

# 매시간 cron 예약:
crontab -e
# 추가:
0 * * * * restic --repo /external/backups backup ~/projects

시간별 백업 7일분과 일별 백업 4주분을 보관하므로 과거 어느 시점으로든 돌아갈 수 있습니다. 무료이며 설정에 10분이면 됩니다.

7. Claude Code JSONL 세션 보관. 위에서 언급했지만 별도의 규칙으로 다시 강조합니다. ~/.claude/projects/를 외장 드라이브에 매주 rsync하도록 예약하세요. 무료이며 crontab에 한 줄이면 됩니다.

위험한 명령을 차단하는 사전 제작 hook#

기존 hook을 덮어쓰지 말고 .claude/settings.json에 병합하세요.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

.claude/hooks/check-risk.py를 만드세요.

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

공식 이벤트를 stdin에서 읽고 tool_input.command나 tool_input.file_path를 확인해 일치 시 2를 반환합니다. Write·Edit 모두 검사합니다. 무해한 허용·차단 fixture를 시험하고 Python과 스크립트의 실제 시작을 검증하세요.

어휘 검사라서 플래그 순서, 스크립트, 별칭, 조합 명령, 다른 도구, 간접 쓰기를 놓치고 무해한 인용도 막을 수 있습니다. OS·DB 권한을 부여·회수하지 않습니다. 운영 키를 환경 밖에 두고 읽기 전용 DB·강제 sandbox를 사용하며 hook 설정을 보호하세요. 공식 입력·종료 코드를 확인하세요.

의도한 예외 동작은 검토 후 제한된 계정으로 에이전트 밖에서 실행하세요. 셸 환경 변수는 문서화된 hook 비활성화 인터페이스가 아니며 일반 터미널은 hook 적용 대상이 아닙니다.

AI에 권한을 줄 때와 주지 말아야 할 때#

Anthropic은 --dangerously-skip-permissions 플래그(YOLO 모드라고도 함)를 “신뢰할 수 있는 환경”을 위한 옵션으로 문서화합니다. 하지만 2026년의 현실에서 이는 대형 사고로 직행하는 길입니다. 에이전트가 허가를 요청하지 않아도 되면 다음 일을 합니다.

• 확인 없이 모든 Bash 명령 실행
• 허락을 구하지 않고 파일 쓰기
• YOLO를 상속하며 이를 되돌릴 방법이 없는 하위 에이전트 호출

세 번째 항목이 가장 교묘합니다. 주 에이전트를 YOLO로 시작하면 하위 에이전트도 YOLO가 되며 설정을 덮어쓸 수 없습니다. 프롬프트 하나만으로 병렬 에이전트 10개가 연쇄적으로 시스템에 어떤 작업이든 할 수 있습니다.

규칙:

대안—정밀 권한 설정. .claude/settings.json에서:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

에이전트는 허용되는 작업과 허용되지 않는 작업을 확인할 수 있습니다. 매번 “예” 또는 “아니요”를 클릭할 필요 없이 에이전트는 빠르게 작업하고 사용자는 경계를 통제할 수 있습니다.

다음 단계: 저장해 둘 7분 체크리스트#

체크리스트: “AI가 삭제했어요—어떻게 해야 하죠?”

1. 실제 파괴적 쓰기를 즉시 멈추고 자식·원격 작업 정지를 검증
2. 재부팅하지 말고 삭제 파일을 연 무관 프로세스를 유지
3. 별도 검증 기기에 사고 시각과 명령 증거 기록
4. 생존 파일, Git 메타데이터, 관련 세션 로그를 같은 별도 기기에 복사
5. 보존 저장소 사본의 git reflog --all에서 검증 SHA를 별도 worktree로 복구
6. git으로 해결되지 않으면 git fsck --lost-found
7. 데이터베이스: PITR(AWS/Yandex/Supabase) 또는 최신 스냅샷
8. 파일: Mac에서는 Time Machine, Linux에서는 lsof
9. 최후의 수단: 제공업체 지원 + S3 버전 관리
10. 복구 후 이 가이드의 7가지 예방 규칙 설정하기

다음 단계—체계적인 보호:

• Claude Code의 Plan Mode—에이전트가 파괴적인 작업 전에 계획을 세우도록 합니다
• Claude Code의 Hooks—위험한 명령을 차단하는 바로 사용 가능한 템플릿
• Claude Code에서 변경 사항 되돌리기—/rewind, git, 표준 롤백 방법 5가지를 자세히 소개
• Claude Code 보안 검토—정기적인 코드 보안 점검

Ailoot 열기.