도커 볼륨을 통째로 날렸다 — AI는 경고했고, 지운 건 나였다
Docker.raw를 지워 로컬 postgres가 전멸한 뒤, 복구 대신 공용 인프라를 새로 세운 기록
프로젝트 세 개의 dev 환경이 맥미니 한 대에 전부 도커로 올라가 있다. 그 도커가 아예 안 뜨길래 비대해진 Docker.raw를 지웠는데, 지우면 볼륨도 같이 간다는 답을 듣고도 그렇게 했다. 어차피 개발용 데이터니 괜찮을 거라고 생각했다.
하려던 것
어제 맥미니에서 도커가 아예 안 떴다. 데몬이 응답을 안 하고 재시작해도 그대로였다. 프로젝트 세 개의 dev 환경이 전부 도커 위에 있어서 아무것도 못 하는 상태가 됐다.
디스크를 보니 Docker.raw가 비대해져 있었다. 도커 데스크톱이 쓰는 가상 디스크 이미지 파일이다.
어떻게 시켰나
AI에게 물었다. 이걸 지우면 볼륨도 같이 지워지느냐고.
답은 “지워진다”였다. 명확한 답이었다. 그리고 나는 지웠다.
지금 와서 로그를 다시 봐도 AI가 틀린 말을 한 건 없다. Docker.raw는 볼륨을 포함한 전체 파일시스템이고, 지우면 그 안의 모든 게 사라진다. 나는 그 답을 듣고도 “응, 삭제해”라고 승인했다. 도커를 살리는 게 급했고, 로컬 DB의 데이터는 어차피 개발용이니 괜찮을 거라고 생각했다.
어디서 막혔나
로컬 postgres가 전멸했다.
“어차피 개발용”이라는 판단이 틀린 지점은 이거였다. 개발용 데이터가 없어도 되는 게 아니라, 다시 만드는 데 시간이 든다. 백필해둔 공시 데이터, 손으로 넣어둔 테스트 계정, 스키마 마이그레이션이 쌓인 상태 — 이게 프로젝트 세 개 분량이었다.
더 나쁜 건 왜 그렇게 커졌는지 모른 채로 지웠다는 것이다. 원인을 안 보고 증상을 지웠으니 같은 일이 또 날 수 있다.
어떻게 풀었나
복구는 포기했다. 대신 구조를 바꿨다.
“이제 도커 띄워줘 다시”
공용 로컬 인프라 자체는 새로 만든 게 아니다. 열흘 전에 이미 세워 뒀다. 공시 요약 서비스는 그날 바로 옮겼고, 의정활동 트래커는 사고 전날에 옮겨 온 참이었다. 이동이 진행 중이었을 뿐, 나머지는 여전히 각자 postgres를 띄우고 있었다.
사고가 그 이동을 끝냈다. 프로젝트마다 각자 postgres를 띄우던 걸 그만뒀고, postgres 하나를 세 프로젝트가 스키마로 나눠 쓰는 쪽으로 정리했다. 데이터베이스를 따로 파지 않고 스키마로 가른 건 운영이 Supabase라 그쪽과 모양을 맞추려던 것이다.
이게 왜 나은가.
- 컨테이너 수가 준다. 볼륨도 준다. 관리 대상이 줄면 사고 면적도 준다
- 어디에 무슨 데이터가 있는지가 한 군데로 모인다. 이번 사고에서 제일 답답했던 게 “뭐가 날아갔는지”를 세 프로젝트 뒤져가며 확인한 거였다
- 포트나 볼륨 이름이 프로젝트마다 제각각이던 것도 같이 정리됐다
이 사고가 없었으면 그 이동은 한참 더 끌었을 거다. 옮길 이유는 진작 있었는데 급하지 않았다.
배운 점
- AI가 “지워집니다”라고 답했어도 지운 건 나다. 위험을 정확히 알려줬는데 내가 급해서 넘어갔다. 답이 맞았느냐와 결정이 맞았느냐는 다른 문제다.
- 어차피 개발용 데이터라는 판단을 조심하라. 없어도 되는 게 아니라 다시 만드는 데 시간이 드는 거다. 그 시간을 계산해보고 결정해야 한다.
- 원인을 안 보고 증상을 지우면 재발한다.
Docker.raw가 왜 커졌는지는 지금도 모른다. - 사고 후에는 복구보다 구조 변경이 나을 때가 있다. 되살리는 데 쓸 시간을 재발 방지에 쓰는 쪽이 남는 게 많다.
- 사고는 없던 구조를 만들어 주지 않는다. 미뤄둔 이동을 끝내게 할 뿐이다. 공용 인프라는 열흘 전부터 있었고 나는 옮기다 말고 있었다.
- 파괴적인 작업 앞에서는 “이거 지우면 뭐가 같이 지워지지?”를 실행 전에 물어보는 습관이 결국 제일 싸다. 이번엔 물어보고도 넘어갔지만.