코덱스 사용 중 스레드 프로젝트 40개 사라져…가드레일 필요성 재확인

저녁 6시 25분, 프로젝트가 통째로 사라지다

저녁 6시 25분, 한 참가자가 코덱스(Codex)를 쓰던 중 갑자기 모든 프로젝트가 사라져 버렸다며 당혹스러운 심경을 전했다.

"워... 코덱스가 갑자기 모든 프로젝트를 다 없애 버렸어요...;;"

1분 뒤 이 참가자는 피해 규모를 구체적으로 밝혔다. 스레드로 관리하던 프로젝트 40개가 한꺼번에 사라졌다는 것이었다.

"40개 스레드 프로젝트가 통쨰로 사라졌어요 ㄷㄷ"

당황한 기색은 쉽게 가라앉지 않았다. 20분 가까이 지난 뒤에도 이 참가자는 이 문제를 어디에 신고해야 할지 몰라 방에 다시 물었다.

"이거 어디다 신고해야해요?!"

SQLite 꼬임과 가드레일 권고

소식을 접한 다른 참가자는 원인으로 코덱스 내부에서 프로젝트 목록을 관리하는 SQLite 데이터베이스가 꼬였을 가능성을 짚었다. 또 다른 참가자는 자신도 과거 비슷한 사고를 겪은 적이 있다며, rm -rf나 git reset --hard처럼 되돌릴 수 없는 명령이 잘못 실행되는 상황을 막는 가드레일과 훅을 미리 걸어 두라고 권했다. 다행히 이 참가자가 작업 내용을 깃허브에 백업해 둔 덕분에, 완전히 되돌릴 수 없는 최악의 상황까지는 피할 수 있었다는 반응이 뒤따랐다.

로컬 상태의 취약함이 드러난 사고

이번 사고가 눈길을 끄는 이유는 단순한 버그 제보를 넘어, 에이전틱 코딩 도구들이 로컬에 저장하는 프로젝트 상태 자체가 얼마나 취약할 수 있는지를 보여줬기 때문이다. 40개라는 규모는 단발성 실수라기보다 프로젝트 목록을 관리하는 데이터베이스 계층 전체가 손상됐을 가능성을 시사하며, 이는 사용자 한 명의 입력 실수보다 도구 쪽의 구조적 결함일 가능성에 무게를 싣는다. SQLite 꼬임이라는 추정이 나온 것도 이런 맥락에서다.

동시에 방에서 나온 조언들은 문제의 원인 규명 못지않게 재발 방지 쪽에 초점이 맞춰져 있었다. 파괴적인 명령을 사전에 차단하는 가드레일과 훅을 걸어 두라는 권고는, 도구 자체의 안정성을 마냥 신뢰하기보다 사용자 쪽에서도 방어선을 겹겹이 쳐 두어야 한다는 경험칙을 보여준다.

백업 습관이 갈랐을 명암

이 화제에는 참가자 14명, 발화 41건이 모였다. 규모는 크지 않았지만 데이터 손실이라는 소재 자체가 무거워 방의 관심이 빠르게 집중됐다. 무엇보다 이번 사고에서 피해를 최소화한 결정적 요인은 결국 깃허브 백업이었다는 점이 확인된다. 만약 백업이 없었다면 40개 프로젝트의 작업 이력이 영구히 사라졌을 수도 있었던 상황이다.

이는 에이전틱 코딩 도구를 매일 쓰는 사용자라면 도구 자체의 안정성과는 별개로, 버전 관리 시스템에 정기적으로 커밋하고 푸시하는 습관을 갖추는 것이 사실상 최후의 안전망이라는 점을 다시 확인시켜 준다. 가드레일·훅 도입 권고 역시, 도구가 완벽해지기를 기다리기보다 사용자 스스로 사고 가능성을 전제하고 대비하는 태도가 이 생태계에서는 실용적인 선택이라는 점을 보여준다.