OpenClaw 운영 일지 - 에이전트가 DB 레코드를 통째로 삭제하다

들어가는 말

2026년 4월 21일에 작성하는 두번째 운영 일지다. 직전에 썼던 'OpenClaw 운영 일지 - 기본 모델 및 fallbacks 연동 모두 실패' 포스트의 연장선이다. 지금은 제거한 'step-3.5-flash'라는 모델이 붙은 에이전트가 회사의 수익 기록을 쌓고 있는 DB 레코드를 통째로 삭제해 버렸다. 아주 심플하지만 매우 심각한 상황이다.

문제 상황

다양한 루트로 들어오는 수익을 매일 DB에 기록해서 이를 웹 대시보드로 볼 수 있게 해 놨다. 귀여울 정도로 소액이라 부끄러우니까 굳이 클릭해서 숫자를 확인하지는 마시길 바란다.

대부분은 광고 수익이다. 이 블로그에는 구글 AdSense, 카카오 AdFit, 쿠팡 파트너스 광고를 붙였다. 그리고 무료 iOS앱에 AdMob 광고를 붙였다. 광고 외에 크몽 출간한 전자책 판매 수익이 있다. 쿠팡 파트너스를 제외한 나머지 항목들 모두 에이전트가 웹에서 데이터를 수집해서 DB에 데이터를 입력하는 것까지 자동으로 돌아가고 있다. 미처 캡처를 못했는데 저 대시보드의 숫자가 최근 이틀을 빼놓고 모두 0으로 표시됐다. 실제로 에이전트가 DB 데이터를 삭제한 것이다.

사고 수습

다시 눈물을 머금고 얼마 안 남은 추가 사용량을 소모하며 Claude 모델을 사용했다. 민감하고 복잡한 작업이 될 것 같아 Sonnet이 아닌 Opus 4.6을 붙였다. 아래 이미지는 데이터 복구 및 재발 방지 대책 수립까지 마친 뒤의 Claude 추가 사용량 현황이다. 공짜로 받은 $200 크레딧이 바닥을 보이고 있다.

원인 분석

Opus 모델을 붙인 에이전트가 말하길.. Step 3.5 Flash 모델이 붙었던 과거의 자신이 특정 날짜의 Coupang 중복 제거 과정에서 WHERE 조건 실수로 대량 삭제한 것으로 보인다고 했다. step-3.5-flash 모델이 붙어있었다면 SQL 조건을 잘못 생성했을 가능성이 높았다는 것이다.

데이터 복구

물론 직접 AdSene, AdMob 대쉬보드에 접속해서 다시 데이터를 긁어오는 것이 가장 확실한 복구 방법이다. 하지만 내가 하기엔 너무 귀찮고 힘든 작업이다. 그렇다고 에이전트한테 시키자니 시간도 오래 걸리고 토큰이 과도하게 소모될 것이 분명했다. 다행히 DB 데이터가 날아가기 전에 브라우저에 띄워 둔 웹 대쉬보드가 있었다. 이걸 전부 캡쳐해서 에이전트에게 전달했다.

에이전트가 스크린샷 이미지의 숫자를 인식해서 이를 그대로 DB에 넣기만 하면 되니 복구 작업이 상대적으로 간단해졌다. 여기에 더해서 최선 데이터는 아니지만, 웹 대시보드의 소스 코드를 관리하는 git 저장소에 SQLite 바이너리가 들어가 있었다.

에이전트가 설명하기를.. SQLite 바이너리를 git에 넣으면 repo 사이즈가 커지고 diff도 안 되기 때문에 잘못된 구현 방식이다. 근데 지금은 이게 오히려 복구 수단이 됐으니 아이러니한 상황이다.

실행에 옮기기 전에 복구 가능 여부를 확인했다. 내가 에이전트에게 전달한 웹 대시보드 스크린샷과 git 저장소의 SQLite 바이너리를 통해 완전 복구가 가능하다는 진단이 나왔다.

에이전트에 바로 작업을 지시했고 무사히 DB 데이터가 복구됐다.

재발 방지 대책 수립

복구보다 더 중요한 건 이런 일이 재발되면 안 된다는 것이다. Opus 4.6을 붙인 에이전트에게 재발 방지 대책 수립까지 요청했다.

git 저장소에는 SQLite 바이너리가 아닌 SQL 텍스트 덤프를 올리고, 바이너리는 로컬 백업에 사용하기로 했다.

앞으로 매일 반복 수행되는 크론이 '수집 → 백업 → 커밋'을 한 사이클로 돌리게 된다. 복잡한 사고나 추론이 필요 없는 단순 작업이라 성능이 낮은 모델이 붙어도 문제없이 수행될 것으로 예상한다.

이에 더해서 옆에서 보고 있던, GPT 5.4가 붙은 에이전트가 'dry-run'도 적용하는 걸 제안했다. 뭔지 물어서 물어봤더니 친절히 설명까지 해주셨다. 진짜로 지우기 전에 먼저 "뭐가 지워질지 미리 보여만 주는 모드"라고 한다. 이것까지 적용했다. 끝.