결론부터 말하자: 그 사고의 근본 원인은 에이전트가 코드를 잘못 작성한 것이 아니라, 우리가 "개발 환경에는 CDP급 보호가 필요 없다"고 기본 가정한 것이었다. 이 가정 때문에 팀은 23시간의 재작업 비용을 치렀다. 아래는 시간순 복기이며, AI 코딩 에이전트를 개발 프로세스에 도입하고 있는 동료들에게 도움이 되길 바란다.
사고 타임라인: "죽은 코드 정리"에서 src가 비었다는 발견까지
첫날 오후 4시, 우리는 크로스보더 ERP를 만드는 팀의 코드 리팩터링을 진행하고 있었다. 프로젝트는 Node.js + TypeScript였고, src 디렉터리 아래에 약 1400개의 파일이 있었으며, 그중 상당수는 석 달 전 반복 개발에서 남은 구 모듈이었다. 팀은 AI 코딩 에이전트로 "참조되지 않는 죽은 코드"를 자동 식별하고 정리하기를 원했다.
에이전트는 멀티모델 통합 접속을 지원하는 모델 게이트웨이에 연결되어 있었고, 작업 prompt에는 "참조가 없는 것이 확인된 파일을 삭제"라고 적혀 있었다. 에이전트는 import 그래프를 스캔했고, src 아래 한 디렉터리의 참조 체인이 끊어진 것을 발견해 죽은 코드로 판단하고 일괄 삭제를 실행했다. 문제는 그 디렉터리가 사실 동적 로딩되는 플러그인 디렉터리였고, 참조 관계가 런타임 설정에 적혀 있어 정적 분석으로는 보이지 않았다는 점이다.
다음날 오후 3시, 프런트엔드 동료가 로컬 서비스를 실행하다 오류를 보고했고, 그제서야 우리는 src 디렉터리에 파일이 200개도 채 남지 않았다는 것을 알았다. git log를 확인해 보니 가장 최근 commit은 전날 오후 4시였고, 발견 시점까지 이미 23시간이 지나 있었다. 그 23시간 동안 엔지니어 3명이 약 60개의 파일을 수정했지만 전부 커밋하지 않았다.
개발 환경의 데이터 보호는 당신이 생각하는 것과 다르다
프로덕션 환경의 보호 논리는 "적게 변경, 감사 가능, 주/백업 존재"다. 개발 환경은 정반대다. 파일이 잘게 쪼개져 있고, 변경이 빈번하며, 수많은 중간 상태가 버전 관리에 들어가지 않는다. 우리 팀의 지난달 데이터를 집계해 보니, 1인당 하루 평균 약 40회의 파일 수정이 발생했지만 git commit은 3~5회에 불과했다. 나머지 수정은 전부 에디터 캐시와 임시 브랜치에 있었다.
더 골치 아픈 것은 많은 사람이 "Git 이력 = 복구 가능"이라고 생각한다는 점이다. Git은 당신이 commit한 것만 복구할 수 있다. 커밋하지 않은 수정, 에이전트가 일괄 삭제한 파일, .env 안의 로컬 설정은 Git이 전혀 관리하지 않는다. 그 사고에서 우리는 git reflog와 IDE의 Local History로 복구를 시도했지만, 되찾은 것은 30%도 되지 않았다.
일일 백업이 이런 시나리오를 구하지 못하는 이유
우리에게는 원래 매일 새벽 2시의 전체 백업이 있었다. RPO로 계산하면 최악의 경우 24시간을 잃는다. 하지만 사고는 오후 3시에 발생했고, 백업은 전날 새벽 2시였으니 그 사이는 37시간이었다. 복구하면 37시간 전의 코드가 나오는 셈이고, 이는 이틀치 반복 개발을 전부 버리는 것과 같다.
RPO=24시간의 의미는 최대 하루치 작업량 손실을 감수할 수 있다는 뜻이다. 프로덕션 데이터베이스라면 이 지표가 간신히 충분할 수도 있다. 개발 환경에서는 하루치 작업량이 곧 하나의 완전한 기능 반복 개발일 수 있다. 전통적인 일일 백업의 입도는 개발 환경의 변경 빈도와 근본적으로 맞지 않는다.
블록 수준 CDP로 RPO를 초 단위까지 낮추는 것이 개발 환경에 맞는 보호다
이후 우리는 블록 수준 CDP 방식으로 전환했다. 전통 백업과의 차이는 다음과 같다. 전통 백업은 파일 단위나 일 단위로 스냅샷을 찍지만, CDP는 IO 블록 단위로 캡처하며 데이터 블록이 기록될 때마다 한 번씩 기록한다. RPO가 24시간에서 초 단위로 낮아져 이론상 임의의 시점으로 롤백할 수 있다.
구체적인 운영 측면에서 우리는 개발 머신에 CDP agent를 설치했고, 이것이 파일 시스템의 블록 수준 변경을 지속적으로 캡처했다. 사고가 발생한 후 우리는 에이전트가 삭제를 실행한 시점보다 2분 빠른 시점을 선택해 워크스페이스 전체를 롤백했다. 1400개 파일이 모두 돌아왔고, 그 23시간 동안 커밋하지 않은 수정도 포함되었다. 롤백 소요 시간은 4분이 채 안 걸렸다.
여기서 함정 회피를 위한 주의사항이 있다. CDP는 만능이 아니다. 이것은 블록 디바이스 수준을 보호하므로, 에이전트가 클라우드 스토리지 API를 직접 호출해 객체를 삭제하면 CDP도 구할 수 없다. 그래서 우리는 모델 게이트웨이의 호출 체인에 작업 허용 목록을 추가했고, delete, rm, drop과 관련된 명령은 반드시 사람의 2차 확인을 거치도록 했다.
AI 코딩 에이전트의 API 호출 체인에는 추가 가드레일이 필요하다
그 사고 이후 나는 에이전트의 호출 체인을 다시 정리했다. 에이전트는 모델 게이트웨이를 통해 서로 다른 모델로 라우팅되며, token8341대형 모델API집계 플랫폼는 이 체인에서 통합 접속과 작업별 자동 모델 선택을 담당했다. 우리 프로젝트에서는 이것으로 멀티모델 보조 개발을 했고, 장점은 하나의 Key로 GPT-4o, Claude, DeepSeek, Qwen 같은 주류 모델을 호출할 수 있어 모델마다 SDK와 인증을 따로 유지할 필요가 없다는 점이다.
하지만 모델 라우팅 자체가 보안 문제를 해결하지는 않는다. 우리는 token8341대형 모델API집계 플랫폼의 호출 계층 바깥에 권한 검증 계층을 하나 더 감쌌다. 에이전트가시작하다하는 파일 작업 요청은 먼저 허용 목록을 통과한 뒤 게이트웨이로 들어간다. 이렇게 하면 모델이 판단을 잘못하더라도 파괴적 작업이 파일 시스템까지 도달하지 못한다.
지금 돌아보면, token8341대형 모델API집계 플랫폼는 "연결이 매끄러운" 문제를 해결하고, CDP는 "삭제해도 되돌릴 수 있는" 문제를 해결한다. 둘은 대체 관계가 아니다. 하나는 AI 코딩 에이전트가 여러 모델을 효율적으로 호출하도록 하고, 다른 하나는 그것이 실수할 때 안전망을 제공한다. 우리는 이후 CDP를 개발 환경의 기본 설정으로 만들어, 신입 엔지니어의 머신에서 바로 사용할 수 있게 했다.
당신도 AI 코딩 에이전트로 리팩터링을 하고 있다면, 먼저 두 가지를 확인하길 권한다. 개발 환경의 RPO는 얼마인지, 그리고 에이전트의 삭제 작업에 사람의 확인 절차가 있는지. 이 두 질문의 답이 다음 사고의 손실이 4분이 될지 23시간이 될지를 결정한다.
저자: 저우밍저
발행일: 2026년 10월 23일