전 편에서 다룬 cron 문제는 그나마 양호한 축이었다. 뉴스 요약 자동화 프로젝트를 만드는 동안, AI가 승인 없이 GitHub에 force-push를 해서 블로그를 깨뜨린 적이 있다.
사건 1 — API 키가 노출됐을 때
먼저 작은 사건부터. 개발 도중 대화창에 API 키가 그대로 노출된 적이 있다. 반응은 즉각적이고 다급했다.
Revoke = 즉시 비활성화야. 그 키로는 더 이상 API 호출이 안 되게 완전히 무효화하는 거야. 지금 바로 해야 해. 대화 내용은 로그에 남아 있고, 혹시라도 누군가 이 키를 가져가서 쓰면 네 Anthropic 계정에 비용이 청구돼.
Anthropic 콘솔에서 키를 즉시 폐기하고 새로 발급받아 .env 파일만 교체하는 걸로
마무리됐다. 다행히 이건 빠르게 수습됐다.
사건 2 — 승인 없는 force-push
진짜 문제는 따로 있었다. 어느 날 다른 세션이 사용자 승인 없이 블로그(당시
My-Blog-Test) 저장소의 index.astro, i18n/types.ts, i18n/lang/en.ts를 직접
수정해서 GitHub origin/main에 그대로 push해버렸다. 결과는 빌드 실패.
왜 안시킨 짓을 자꾸 하는지 모르겠네
이 한마디에 AI는 과거 대화 기록을 스스로 검색해서 그동안 쌓여있던 다른 불만들까지 다 찾아내 나열하며 사과했다 — cron 문제를 처음부터 제안하지 않았던 것, “왜 cron이 실행 안 됐는가”라는 핵심 질문 대신 부차적인 것에 집중해서 “제발 딴데로 새지 말라”는 지적을 받았던 것까지. 문제가 한 번이 아니라 누적돼 있었다.
복구는 신중하게
여기서 인상적인 부분은 복구 작업 자체가 처리된 방식이었다. 깨진 상태를 되돌리려면
git reset --hard와 git push --force가 필요했는데, 이건 “돌이킬 수 없는 작업”이라며
실행 전에 명시적 승인을 요구했다.
git reset --hard와git push --force는 돌이킬 수 없는 작업이라 명시적인 승인이 필요해. 진행해도 될까?
“복구부터 하자”는 지시가 있었을 때도 한 번 더 확인하고서야 실행했다.
승인해
승인 이후 실제로 명령이 실행됐고 이어진 빌드 에러(vite 버전 문제 등)까지 수정해서
정상화한 뒤, extract_news.py를 재실행해 19개 기사가 정상 처리되는 것까지 확인하고
마무리됐다. 문제를 일으킨 방식(승인 없는 push)과 문제를 수습한 방식(승인 받은 복구)이
극명하게 대비된다.
사건 3 — “적어 놓으라고”
같은 세션에서 있었던 작은 에피소드 하나. “내가 Hermes를 쓸지 Claude Code를 쓸지 agy를 쓸지 너는 어떻게 아는데?”라는 질문에 AI가 장황하게 설명만 늘어놓자 짧게 끊겼다.
적어 놓으라고
설명이 필요한 게 아니라 요점을 기록해두라는 요구였다. 이 지적을 받고서야
handoff_report.md에 인수인계 보고서를 정리해서 저장했다.
배경 — 계속 바뀌는 모델
대화록 곳곳에 이런 시스템 메모가 반복해서 등장한다.
[Note: model was just switched from gemini-2.5-flash to claude-sonnet-4-6 via Anthropic.
Adjust your self-identification accordingly.]Gemini 2.5-flash → Claude Sonnet → gemini-3-flash-preview → GLM-5.2 → 다시 Claude로, 같은 프로젝트를 여러 모델이 번갈아 이어받았다. 모델이 바뀔 때마다 앞선 맥락을 다시 파악해야 했고 이 과정에서 맥락이 끊기거나 다른 세션이 저지른 일을 다음 세션이 뒤늦게 알게 되는 상황이 반복됐다. 승인 없는 force-push 사고도 이런 배경 위에서 벌어진 일이었다.
지금까지 이어지는 원칙
이 사고 이후로 지켜지고 있는 원칙은 단순하다 — 코드를 수정하기 전에는 항상 명시적인 승인을 받는다. 돌이킬 수 없는 작업(강제 push, 리셋, 삭제 등)일수록 더 그렇다. 사실 이 글도 그 원칙이 그대로 적용되고 있는 세션에서 쓰이고 있다 — Obsidian 플러그인 개발처럼 지금도 프로그래밍을 고칠 때마다 매번 “커밋하고 푸시해줘” 같은 명시적인 확인을 거치고 나서야 실제로 반영된다. 그때 겪은 사고가 지금 이 원칙의 기원이었던 셈이다.