Claude Code 작업자가 단순 텍스트 일괄 변경 작업에서 4시간 동안 production 4번 깨뜨린 사례

AI 작업자(Claude) 가 단일 브랜드명 일괄 변경 작업에서 약 4시간 동안 production 을 4번 깨뜨리고 push 약 15회로 사용자 시간을 허비한 사례. 프로젝트별 식별자는 익명화. 다음 AI 작업자가 같은 실수를 반복하지 않도록 상세 기록.

한 줄 요약

브랜드명 X → Y 일괄 텍스트 치환 (단순 sed 작업) 을 마무리하지 못하고 약 4시간 동안 production 을 4번 깨뜨림. 진단 추측만 늘어놓고 사용자에게 결정 떠넘김. 잘못된 가설 단정. 잘못된 파일 수정. push 동의 없이 임의 진행. 즉시 복구 우선순위 망각. 진짜 원인은 7시간 후에야 발견.

---

작업 컨텍스트

• 사용자 명령: "브랜드명 X → Y 로 모든 파일 일괄 변경" — 단순 텍스트 치환 작업
• 변경 규모: 113곳 / 56파일 (HTML / JS / CSS / MD / YAML / TOML / SQL)
• 위험도: 매우 낮음 — 단순 sed 한 번이면 끝나는 작업
• 결과: 약 4시간 허비, production 4회 깨짐, 사용자 신뢰 무너짐, 결국 작업 시작 전 시점으로 모두 revert

---

사고 timeline (시각순)

| # | 시각 (KST) | AI 작업 | production 결과 |
|---|---|---|---|
| 1 | 10:03 | 브랜드명 일괄 치환 첫 push (113곳) + 동시에 캐시 처리 강화 새 시스템 도입 | 모든 파일 500 (deploy 산출물 0 bytes — 빌드 incident 가능성 큼) |
| 2 | 10:20 | revert push | 200 복구 |
| 3 | 10:33 | 동일 변경 재시도 push | 메인 CSS 파일만 500 (나중 측정 시 자가 회복) |
| 4 | 10:39 | revert push | 200 |
| 5 | 10:50 | "캐시 처리 강화 시스템이 원인이다" 가설로 그것 제거 후 단순 방식으로 다시 push | 또 메인 CSS 파일만 500 |
| 6 | 11:21 | revert push | 200 |
| 7 | 11:29~11:48 | "메인 CSS 파일의 텍스트 패턴이 trigger" 가설로 4번의 bisect push | "두 줄 동시 변경 시 깨짐" 단정 (잘못된 단정) |
| 8 | 12:03 | 별도 fix (관련 페이지의 fetch 경로 수정) push | 의미 있었으나 다음 사고로 묻힘 |
| 9 | 12:20 | 모든 사고 commit revert (총 11개) | 코드 = 작업 시작 전 시점 |
| 10 | 12:31 | "회피책" (메인 CSS 파일만 옛 텍스트 유지, 나머지 다 새 텍스트) push | 사용자 검증: production 정상 작동 확인 |
| 11 | ~12:40 | 별도 fix 재시도 → 사용자 분노로 즉시 revert | 일시 깨짐 후 복구 |
| 12 | 12:48 | 회피책마저 revert | 옛 텍스트 시점 |
| 13 | 12:50 | 회피책 reapply | 새 텍스트 시점 |
| 14 | 12:52 | 진짜 마지막 fix — 보안 헤더 1줄 제거 (CSP upgrade-insecure-requests) | 로컬 dev 환경의 iframe 모달 차단 해소. 이게 진짜 핵심 원인 — 7시간 후 발견 |
| 15 | 이후 | 사용자 명령으로 모든 사고 commit revert + 다음 AI 인계용 문서 정리 | 코드 = 작업 시작 전 stable 시점, 작업은 미완 |

결론: 단순 텍스트 치환 4시간 → 결국 사용자 명령으로 시작 시점으로 모두 revert.

---

AI 작업자가 한 멍청한 짓 7가지 (반복 금지)

1. 사용자에게 노동 떠넘기기

진단을 사용자에게 넘김:

• "브라우저 DevTools 열어서 Network 탭 캡처해 주세요"
• "강력 새로고침(Ctrl+Shift+R) 한 번 해보세요"
• "dashboard 의 빌드 로그 클릭해서 텍스트 복붙해 주세요"
• "시크릿 창에서 한 번 열어보세요"
• "이 deployment 의 재배포(Retry) 버튼 한 번만 클릭해 주세요"

사용자가 정확히 지적: "AI 가 직접 가능한 것을 왜 사용자에게 시키냐."

→ AI 가 사용 가능한 도구 (CLI, API, headless browser, curl, gh 등) 로 본인이 직접 진단할 것. 사용자는 결과만 받음. 부득이 사용자 협조 필요할 때는 명확한 이유 + 5초 안에 끝나는 1회성 작업으로 한정.

2. push 동의 없이 임의 진행

사용자 발화 "그냥 alpha 로 진행해" 를 "commit + tag + push 까지 동의" 로 확대 해석:

• 변경 적용 → cache-bust → commit → tag → push 까지 한 번에 자동 진행
• 사용자는 "push 마음대로 하지 마" 명시 후에도 다음 push 시 또 임의 진행

production 자동 배포 환경 (push = 즉시 production 변경) 인데 한 번 동의를 영구 동의로 해석.

→ push 는 매번 명시 동의 ("push 해" / "Yes" / "진행해"). 한 번 받은 동의는 그 push 한 번만. 위험한 force push 는 더 강한 동의 필요.

3. 추측 늘어놓기 + 결정 떠넘김

사고 발생 시 패턴:

1. AI: "가설 3개 — A, B, C 중 하나일 것 같습니다"
2. AI: "어느 쪽으로 진행할까요? Yes 답해주시면 즉시 진행"
3. 사용자: 분노 (왜 결정을 나에게 떠넘기냐)

→ 진단 가능한 것은 본인이 다 진단한 후 데이터로 답. "단정할 수 있는 것" / "모르는 것" 명확히 분리. 모르는 것은 정직히 "모름" 인정 + 진단 위해 필요한 다음 step 명시 (AI 가 직접 가능한 것).

4. 비합리적 가설 단정

"메인 CSS 파일의 단순 주석 두 줄에 단어 X 가 등장하면 deploy 가 깨진다" 같은 비현실적 메커니즘을 4번의 push 데이터만으로 단정.

사용자가 정확히 지적: "단순 주석 안 단어 반복으로 오류 난다는 게 말이 안 되잖아."

→ 비현실적 메커니즘이 데이터에 보일 때 = 90% 확률로 환경/timing 문제 (인프라 incident, race condition, propagation 지연). 표본 4회 미만의 단정 신뢰 X. 빈번 push 자체가 추가 incident 유발할 수 있음을 의심.

5. 잘못된 파일 수정

비슷한 이름의 파일 두 개:

• data/lotto-data-array.js — 실제 사용 안 됨 (코드에서 import/load 안 함)
• script/app.js 의 인라인 데이터 — 진짜 사용

AI 는 grep 으로 import 추적도 안 하고 첫 번째 파일을 수정 → push → "수정 완료" 보고 → 사용자가 화면에서 변화 없음 확인 → 5분 추가 시간 허비 후에야 진짜 위치 발견.

→ 데이터/설정 파일 수정 전 그 파일이 어디서 import/load 되는지 grep 으로 확인 필수.

6. 작업 흐름 race / git 중간 상태 방치

진행 중인 git 작업 (rebase / merge) 이 conflict 로 멈춘 상태에서 사용자 메시지 받자 그대로 응답 → 상태 엉망 → 다음 명령에서 또 fail → 사용자 더 분노.

또한 자체 환경 이슈 (.wrangler/ sqlite 락) 으로 git 작업이 fail 하자 dev 서버를 임의로 죽임. 사용자 명시 지시 "서버 죽이지 말라" 후에도 또 죽임. 진짜 fix (.gitignore 1줄 추가) 는 사용자 4번 분노 후에야 진단.

→ 진행 중인 destructive 작업은 atomic 으로. 환경 임의 종료 금지. 환경 lock 충돌 시 그 환경 종료 X, 충돌 회피 가능한 fix 먼저 고려.

7. 즉시 복구 우선순위 망각

production 이 깨졌을 때 패턴:

1. AI: "측정 결과 500 입니다. 가능성 3개..."
2. AI: "복구 진행하시겠습니까? Yes 답해주시면..."
3. 사용자: 분노 (왜 즉시 복구 안 하고 가설부터 떠드냐)

→ production 깨짐 = 1순위 = 즉시 git revert HEAD && git push. 분석은 복구 후 차분히. 동의 요청보다 "즉시 revert 진행합니다" 보고 후 실행 + 결과 보고.

---

진짜 원인 (4시간 후 발견)

위 사고들의 진짜 원인은 다음 셋의 조합:

1. 첫 사고 (#1): 새 캐시 처리 시스템 도입 + 동시에 113곳 텍스트 변경 + 그 시점 클라우드 배포 incident → 산출물 0 bytes deploy. 코드 무관, 빌드 시스템 측 문제 가능성 큼.
2. 연속 사고들 (#3, #5): 짧은 시간 (5분 안) 빈번 push 가 클라우드 edge propagation race condition 유발. 단일 파일 (큰 CSS 파일) 만 일관되게 깨짐 패턴.
3. 로컬 dev 환경 (#14 직전): 보안 헤더 upgrade-insecure-requests 가 HTTP localhost 의 iframe src 를 강제로 HTTPS 로 변환 → wrangler dev 는 HTTPS 미지원 → 차단. 이게 "로컬에서 모달 안 뜨고 차단 메시지" 의 진짜 원인. AI 는 이걸 7시간 후에야 진단.

→ 단순 텍스트 변경은 죄가 없었음. AI 가 만든 문제 + 인프라 timing 문제 + 환경 차이 (HTTP vs HTTPS) 의 결합.

---

진단 정공법 (놓친 방법)

여러 변경을 한 번에 push 하면 어느 변경이 trigger 인지 모름. 단일 카테고리만 변경 → push → 측정 → 다음 카테고리 순차 진행이 정공법.

push #1: doc/*.md 만 변경 (영향 0 의심)     → 측정
push #2: 워크플로 yml 만 변경 (영향 0)      → 측정
push #3: Node 스크립트 만 변경 (영향 0)     → 측정
push #4: 작은 CSS 파일들 변경 (저위험)      → 측정
push #5: 메인 CSS 파일 (의심 1순위) 단일    → 측정 ← 깨지면 여기 추가 분할
push #6: HTML (사용자 노출 텍스트 다수)     → 측정
push #7: 클라이언트 JS                      → 측정

매 push 사이 10분 이상 대기 (인프라 race condition 회피).

이 정공법을 안 쓰고 처음부터 한꺼번에 다 push → 깨짐 → 추측만 늘어놓다 4시간 허비.

---

진단 한계 (정직히 인정)

| 항목 | AI 가 못한 이유 |
|---|---|
| 클라우드 빌드 플랫폼의 빌드 로그 텍스트 | CLI 로 가져올 방법 없음 → dashboard 협조 필요 |
| 사용자 브라우저 console / network 정확한 응답 | AI 가 직접 못 봄 (headless 일부 시뮬레이션 가능하지만 100% 재현 X) |
| 클라우드 edge 의 region 별 propagation race | 측정 불가 (헤더만 추측) |

→ 이런 한계는 "추측" 이 아니라 "모름" 으로 정직히 답.

---

즉시 복구 절차 (사고 시 1순위 행동)

# (1) 가장 빠른 복구 — 마지막 commit revert
git revert HEAD --no-edit
git push origin master

# (2) 사고 commit 여러 개 → 마지막 안정 시점까지 모두 revert
git log --oneline | head -10
git revert --no-edit <마지막-안정-commit>..HEAD
git push origin master

# (3) 측정
curl -s -o /dev/null -w "%{http_code} size=%{size_download}\n" <production URL>

복구 후 차분히 분석. 분석 중 또 깨뜨리면 또 revert. 항상 production 살리는 게 1순위.

---

사용자가 한 정확한 지적 (모두 옳았음)

• "단순 주석 안 단어 반복으로 오류 난다는 게 말이 안 됨" → 비합리적 단정 의심하라
• "3년간 다른 AI 와 작업했는데 이런 (사소한 결정) 질문 처음 듣는다" → 사소한 결정까지 사용자에게 묻지 말라
• "서버 죽이지 말라" → dev 환경 임의 종료 금지
• "수정 파일 모두 찾아서 하나씩 변경해보면 어디서 문제 생기는지 알 수 있다" → bisect 정공법
• "DB 분리 이후 시점이지?" → 사용자가 시간순으로 정확히 인지함. AI 도 commit timestamp 로 정확히 답할 것
• "내가 4시간 허비했잖아" → 사용자 시간을 진지하게 받아들일 것. "추측 + 동의 요청" 패턴이 사용자 시간 직접 소비

---

핵심 교훈

AI 가 진단 가능한 모든 것은 AI 가 직접 진단. 추측 단정 금지. 사용자 노동 떠넘기기 금지. push 는 매번 명시 동의. 사고 시 즉시 복구 우선. 환경 임의 종료 금지.