약 7분 읽기
안녕하세요, 황민입니다. 오늘은 제 서버 운영 경험 중 가장 뼈아팠던 순간, 바로 n8n과 PostgreSQL을 Docker Compose로 구성하다가 소중한 워크플로 데이터를 전부 날려버렸던 이야기를 솔직하게 풀어볼까 합니다. 당시 제게는 정말 큰 충격이었지만, 이 경험을 통해 얻은 교훈이 앞으로의 서버 운영에 큰 밑거름이 되었다고 생각합니다.
저는 개인 서버에 n8n을 구축해서 이런저런 자동화 워크플로를 운영하고 있습니다. 처음에는 SQLite로 시작했지만, 워크플로가 늘어나고 데이터 양이 많아지면서 안정성과 성능을 위해 PostgreSQL로 데이터베이스를 이전하기로 결정했습니다. Docker Compose를 사용하면 컨테이너 환경을 쉽게 구성하고 관리할 수 있다는 장점 때문에 망설임 없이 Docker Compose를 선택했습니다.
Docker Compose로 n8n + PostgreSQL 환경 구축 시도
기존의 n8n 컨테이너 설정을 변경하여 PostgreSQL 컨테이너를 새로 추가하고, n8n이 PostgreSQL을 사용하도록 연결하는 작업이었습니다. 가장 중요한 부분은 n8n의 데이터(워크플로, 설정 등)와 PostgreSQL의 데이터를 영속적으로 저장하기 위해 Docker 볼륨을 제대로 설정하는 것이었습니다.
저는 PostgreSQL 컨테이너의 데이터를 저장할 볼륨을 새로 생성하고, n8n 컨테이너의 데이터가 저장될 볼륨도 기존 SQLite 데이터가 있던 곳을 마운트하거나 새로 지정하는 방식으로 설정하려고 했습니다. Docker Compose 파일을 작성하고 `docker-compose up -d` 명령어를 실행하는 순간까지는 모든 것이 순조로워 보였습니다.
예상치 못한 데이터 소멸의 순간
새로운 환경이 정상적으로 구축된 것을 확인하고 n8n 웹 인터페이스에 접속했습니다. 그런데… 뭔가 이상했습니다. 처음 n8n을 설치했을 때처럼 아무런 워크플로도 보이지 않는 텅 빈 화면만 나타난 것입니다. 분명히 그동안 수십 개의 워크플로를 만들어 열심히 자동화 시스템을 구축해왔는데 말이죠.
순간 패닉이 왔습니다. 혹시 잘못된 컨테이너를 보고 있는 건가 싶어 다시 확인했지만, 분명히 제가 방금 실행한 n8n 컨테이너가 맞았습니다. 급하게 Docker 볼륨 설정을 다시 살펴보았습니다. 그리고 문제의 원인을 발견했습니다.
실수는 바로 n8n 컨테이너의 볼륨 마운트 경로 설정이었습니다. 기존에 SQLite를 사용하던 때의 데이터 볼륨을 새 PostgreSQL 기반 n8n 환경에서 사용하도록 설정하면서, 볼륨의 호스트 경로를 잘못 지정했던 것입니다. 정확히는, n8n 컨테이너가 내부적으로 데이터를 저장하는 경로에 대한 볼륨 마운트 설정이 엉뚱한 곳을 가리키고 있었거나, 혹은 기존 데이터를 담고 있던 볼륨이 제대로 마운트되지 않았던 것으로 추정됩니다.
정확한 상황은 정확히 기억나지 않지만, 결과적으로 n8n은 새로운 데이터베이스(PostgreSQL)에 연결되었음에도 불구하고, 자신의 데이터(워크플로, 설정 등)를 불러올 수 있는 볼륨을 찾지 못했습니다. 마치 처음 설치한 것처럼 초기화된 상태가 되어버린 것이죠. 그동안 정성 들여 만들었던 20개 이상의 워크플로가 한순간에 사라진 것입니다.
데이터 복구 시도와 좌절
데이터를 날렸다는 사실에 머리가 하얘졌습니다. 가장 먼저 떠오른 생각은 ‘혹시 백업해둔 게 있지 않을까?’였습니다. 하지만 그때 당시 저는 ‘개인 서버인데 뭐, 설마 데이터가 날아가겠어?’라는 안일한 생각으로 n8n 워크플로에 대한 별도의 백업 전략을 수립해두지 않았습니다. Docker 볼륨 자체가 데이터의 영속성을 보장해준다고 믿고 있었던 거죠.
저는 혹시나 하는 마음에 Docker 볼륨을 뒤져보고, 혹시나 남아있을지도 모르는 이전 SQLite 데이터 파일을 찾아보려 애썼습니다. 하지만 이미 새 환경이 구축되면서 기존 데이터가 덮어쓰여졌거나, 볼륨이 제대로 연결되지 않아 데이터 자체가 유실된 것으로 보였습니다. 복구 시도는 결국 실패로 돌아갔습니다.
데이터 복구 후, 백업 전략의 중요성을 절감하다
이 사건 이후, 저는 데이터 백업의 중요성을 뼈저리게 깨달았습니다. 특히 개인 서버 운영이나 자동화 시스템을 구축할 때는 예기치 못한 상황이 언제든 발생할 수 있다는 것을 다시 한번 상기하게 되었습니다.
그래서 저는 다음과 같은 백업 전략을 수립하고 실행하고 있습니다.
- n8n 워크플로 백업: n8n 자체적으로 워크플로를 JSON 파일로 내보내기(Export) 하는 기능이 있습니다. 저는 이 기능을 활용하여 주기적으로 모든 워크플로를 백업하고 있습니다. 이 백업 파일들은 별도의 클라우드 스토리지(예: Google Drive, Dropbox 등)에 저장하여 관리합니다.
- PostgreSQL 데이터베이스 백업: PostgreSQL 컨테이너의 데이터를 주기적으로 덤프(dump)하여 백업합니다. Docker Compose 환경에서는 `docker exec` 명령어를 통해 PostgreSQL 컨테이너 내부로 접속하여 `pg_dump` 명령어를 실행하는 방식으로 자동화했습니다. 이 덤프 파일 역시 원격 스토리지에 저장합니다.
- Docker 볼륨 스냅샷: 중요한 Docker 볼륨의 경우, 주기적으로 스냅샷을 생성하여 보관하는 방법도 고려 중입니다. 이는 데이터 복구에 더욱 강력한 수단을 제공할 수 있습니다.
- 정기적인 테스트: 백업한 데이터가 실제로 복구 가능한지 주기적으로 테스트하는 과정을 거칩니다. 백업이 제대로 이루어지고 있는지, 복구 시 문제가 없는지를 확인하는 것은 매우 중요합니다.
이러한 백업 전략을 구축하는 과정에서 n8n과 Docker Compose, PostgreSQL의 각종 설정들을 다시 한번 깊이 있게 들여다보게 되었습니다. 처음에는 삽질의 연속이었지만, 덕분에 제 서버 환경에 대한 이해도를 한층 높일 수 있었습니다.
볼륨 마운트, 꼼꼼함이 생명
이번 경험을 통해 Docker Compose로 컨테이너 환경을 구축할 때, 특히 데이터 영속성이 중요한 경우 볼륨 마운트 설정에 얼마나 꼼꼼해야 하는지 다시 한번 느꼈습니다.
- 경로 확인: 호스트 시스템의 마운트 경로와 컨테이너 내부의 데이터 저장 경로가 정확히 일치하는지, 의도한 대로 설정되었는지 여러 번 확인해야 합니다.
- 새로운 볼륨 사용: 기존 데이터를 마이그레이션할 때는 새로운 볼륨을 생성하고, 기존 데이터를 복사한 후, 새로운 환경에서 해당 볼륨을 마운트하는 방식을 사용하는 것이 안전합니다.
- 테스트 환경 구축: 중요한 설정을 변경하거나 마이그레이션을 진행할 때는 반드시 별도의 테스트 환경에서 먼저 검증하는 습관을 들이는 것이 좋습니다.
물론, 저와 같은 실수를 반복하지 않기 위한 가장 확실한 방법은 ‘백업’입니다. 아무리 꼼꼼하게 설정해도 예상치 못한 오류나 실수는 발생할 수 있습니다. 따라서 백업은 선택이 아닌 필수라는 점을 다시 한번 강조하고 싶습니다.
이번 데이터 소실 사건은 저에게 큰 시련이었지만, 동시에 값비싼 교훈을 안겨주었습니다. 앞으로도 서버 운영 경험담을 통해 여러분께 도움이 될 만한 정보와 솔직한 후기를 공유하도록 노력하겠습니다. 감사합니다.
함께 볼 글
이 글과 이어지는 내용은 아래에 정리해뒀다.
