n8n에서 만든 워크플로우는 어디에 저장될까? Docker 볼륨을 처음 확인해봤어요.

 

n8n에서 만든 워크플로우는 어디에 저장될까? Docker 볼륨을 처음 확인해봤어요

지난 편에서는 X MINI를 실제로 재부팅한 뒤 Docker와 n8n이 다시 올라오는지 확인해봤습니다.

Debian이 다시 부팅되고, Docker 서비스가 살아 있는지 확인하고, n8n 컨테이너 상태도 살펴봤어요.

마지막에는 Firefox에서 localhost:5678로 다시 접속해 기존 워크플로우가 그대로 보이는지도 확인했습니다.

그런데 여기에서 새로운 궁금증이 하나 생겼습니다.

“n8n에서 지금까지 만든 워크플로우는 도대체 어디에 저장돼 있는 걸까?”

컴퓨터를 재부팅했는데 그대로 남아 있다는 건 어딘가에는 저장돼 있다는 뜻이잖아요.

그런데 n8n은 Docker 컨테이너 안에서 실행되고 있습니다.

그렇다면 컨테이너 안에 저장되는 걸까요?

컨테이너를 지우면 지금까지 만든 워크플로우도 같이 없어지는 걸까요?

이번에는 프로그램을 하나 더 설치하는 대신, Docker에서 데이터를 어떻게 보관하는지부터 조금 알아보기로 했습니다.

디지털 장난감 26편 핵심
Docker 컨테이너와 실제 데이터 저장 공간은 같은 것이 아니라는 점을 처음 이해하고, n8n의 워크플로우와 설정을 안전하게 보관하기 위해 Docker 볼륨과 폴더 구조가 왜 필요한지 살펴본 기록입니다.

n8n 워크플로우와 설정이 컨테이너와 분리된 저장 공간에 어떻게 보관되는지 Docker 볼륨 구조를 살펴봤습니다.
출처: 독타의 디지털 장난감

처음에는 컨테이너 안에 다 들어 있는 줄 알았어요

Docker를 처음 사용할 때는 컨테이너를 하나의 작은 프로그램 상자처럼 생각했습니다.

n8n 컨테이너를 실행하면 그 안에 n8n 프로그램도 있고, 제가 만든 설정과 워크플로우도 같이 저장되는 줄 알았어요.

그래서 재부팅 뒤에도 n8n 화면이 그대로 열리고 기존 워크플로우도 보이는 걸 보고 처음에는 별다른 생각을 하지 않았습니다.

그런데 Docker를 조금 더 찾아보니 컨테이너는 계속 유지되는 영구 저장 공간이라기보다, 필요하면 만들고 지우고 다시 만들 수 있는 실행 환경에 가까웠습니다.

“그럼 실수로 n8n 컨테이너를 지우면 지금까지 만든 것도 같이 없어지는 건가?”

블로그 자동화를 계속 만들 생각이라면 그냥 넘어갈 문제는 아닌 것 같았습니다.

컨테이너와 데이터는 따로 생각해야 했어요

Docker를 쓰면서 처음 헷갈렸던 것 중 하나가 이 부분이었습니다.

컨테이너가 프로그램을 실행한다고 해서, 데이터를 반드시 컨테이너 안에만 저장할 필요는 없었습니다.

컨테이너 = 프로그램이 돌아가는 공간
볼륨 = 프로그램이 사용하는 데이터를 따로 보관하는 공간

처음에는 굳이 이렇게 나눠야 하나 싶었습니다.

그런데 컨테이너를 업데이트하거나 다시 만들 수 있다는 걸 생각하니 이유가 조금 보였어요.

프로그램이 들어 있는 상자는 필요하면 새것으로 바꾸더라도, 그동안 만든 데이터까지 같이 버리면 안 되잖아요.

그래서 데이터는 컨테이너와 분리해 보관하는 방식이 필요했습니다.

Docker Volume이라는 말을 처음 제대로 봤어요

여기서 나온 게 Docker Volume이었습니다.

처음 봤을 때는 또 새로운 용어 하나가 추가됐다는 생각부터 들었어요.

Docker, 이미지, 컨테이너, 포트에 이어 이번에는 볼륨까지 나왔습니다.

그런데 제 상황에 맞춰 생각하니 조금 쉬워졌어요.

n8n을 계속 사용하면서 만드는 건 단순히 프로그램 실행 화면만이 아닙니다.

• 워크플로우를 만들고
• Google Sheets 연결 정보를 설정하고
• Schedule Trigger를 만들고
• 각종 노드 설정을 저장합니다

이런 데이터가 컨테이너를 다시 만들 때마다 사라지면 곤란합니다.

그래서 이런 데이터를 컨테이너 바깥의 별도 저장 공간에 두고, n8n 컨테이너에서 그 공간을 연결해서 사용하는 방식이라고 이해했습니다.

제가 처음 이해한 Docker 구조

• Image — 컨테이너를 만들기 위한 기본 재료, 예: n8n 이미지
• Container — 실제로 실행되는 프로그램 환경, 예: 지금 돌아가는 n8n
• Volume — 컨테이너와 별도로 데이터를 보관하는 저장 공간, 예: n8n 워크플로우 보관

docker volume ls 명령으로 Docker가 관리하고 있는 볼륨 목록을 확인했습니다.

용어를 한꺼번에 외우려고 하면 어려웠는데, 실제로 지금 쓰고 있는 n8n에 대입하니 조금 이해가 됐습니다.

n8n은 어떤 데이터를 계속 가지고 있어야 할까

n8n을 며칠 사용해보니 단순히 프로그램만 실행되면 되는 게 아니었습니다.

제가 만든 워크플로우가 있고, 각 워크플로우의 노드 설정이 있고, 외부 서비스 연결과 관련된 설정도 있습니다.

앞으로 자동화가 많아지면 실행 기록이나 여러 설정도 더 쌓일 겁니다.

이런 것들은 n8n 프로그램 자체와는 성격이 조금 달랐어요.

프로그램 버전은 나중에 바뀔 수 있습니다.

컨테이너도 새 버전으로 다시 만들 수 있고요.

하지만 제가 만든 작업 내용은 계속 남아 있어야 합니다.

프로그램은 바뀌어도, 내가 만든 데이터는 남아 있어야 한다.

이걸 생각하니 프로그램과 데이터 분리라는 말이 조금 와닿기 시작했습니다.

폴더를 어떻게 정리할지도 고민됐어요

Docker를 계속 사용하려면 프로그램만 설치하는 것보다 폴더 구조도 정리해두는 게 좋을 것 같았습니다.

처음에는 테스트니까 아무 데서나 실행해도 큰 문제가 없었어요.

그런데 앞으로 n8n뿐 아니라 다른 서비스도 하나씩 추가할 수 있습니다.

그러면 나중에는 이런 식으로 구분하는 게 더 편할 것 같았어요.

docker
  └ n8n
  └ portainer (예정)

앞으로 서비스가 늘어날 것을 생각해 Docker와 n8n 관련 폴더 구조도 함께 정리해봤습니다.

각 서비스마다 설정 파일과 데이터 위치를 구분해두면 나중에 백업할 때도 어디를 봐야 하는지 훨씬 알기 쉬울 것 같았어요.

Windows에서 파일을 아무 폴더에나 저장하다 보면 나중에 찾기 어려워지는 것처럼, 서버에서도 처음부터 조금 정리해두는 게 필요하겠다는 생각이 들었습니다.

볼륨과 폴더 연결은 비슷해 보여도 조금 달랐어요

Docker 데이터를 보관하는 방법을 보다 보니 Volume 말고도 호스트의 실제 폴더를 컨테이너에 연결하는 방식이 있었습니다.

이 부분은 처음에는 조금 헷갈렸습니다.

둘 다 결국 컨테이너 바깥에 데이터를 보관하는 것처럼 보였거든요.

제가 이해한 수준에서는 이렇게 생각하기로 했습니다.

• Docker가 관리하는 저장 공간을 사용하는 방법이 있고
• Debian의 특정 폴더를 직접 연결해서 사용하는 방법도 있다

어느 방식이 무조건 좋다고 단정하기보다는, 어떤 데이터를 어떻게 관리할 것인지에 따라 선택하는 것 같았습니다.

지금은 처음 배우는 단계라서 복잡한 구조를 만들기보다, n8n 데이터를 컨테이너와 분리해서 보관해야 한다는 개념부터 이해하는 게 더 중요했습니다.

docker inspect의 Mounts 항목을 확인해 n8n 컨테이너와 데이터 저장 공간이 어떻게 연결돼 있는지 살펴봤습니다.

컨테이너를 지우는 것과 데이터를 지우는 건 같지 않아야 했어요

이번에 가장 중요하게 느낀 부분은 이거였습니다.

서버를 운영하다 보면 컨테이너를 다시 만드는 일은 생길 수 있습니다.

버전을 올릴 수도 있고, 설정을 바꿀 수도 있고, 문제가 생겨 컨테이너만 새로 만들어야 할 수도 있겠죠.

그럴 때마다 워크플로우를 처음부터 다시 만든다면 너무 불편할 겁니다.

그래서 이상적인 구조는 컨테이너는 다시 만들 수 있지만 데이터는 그대로 남는 것 이라고 이해했습니다.

컨테이너는 바뀔 수 있어도, 데이터는 남아 있어야 한다.
재부팅은 컨테이너가 그대로 있을 수 있지만, 컨테이너를 삭제하면 이야기가 달라진다. 그래서 데이터 저장 구조를 알아야 했다.

이 한 문장으로 생각하니 Docker Volume을 왜 쓰는지 조금 이해됐습니다.

25편에서는 재부팅 뒤에도 n8n이 살아나는지가 중요했다면, 이번에는 그보다 한 단계 더 큰 문제를 생각하게 됐어요.

앞으로 백업도 결국 이 데이터가 기준이 될 것 같아요

Docker Volume을 알아보다 보니 자연스럽게 백업 생각도 났습니다.

지금은 테스트용 워크플로우 몇 개뿐이지만, 나중에 실제 블로그 자동화가 들어가면 얘기가 달라질 것 같아요.

여러 블로그의 작업 흐름, Google Sheets 연결, 각종 자동화 설정, 프롬프트와 작업 규칙까지 들어가게 되면 다시 만드는 데 시간이 꽤 걸릴 겁니다.

그때는 프로그램 자체보다 이 데이터를 백업하는 게 훨씬 중요하겠죠.

원래는 Docker를 설치하면 프로그램을 쉽게 실행할 수 있다는 점만 보고 시작했는데, 이제는 조금씩 운영 쪽으로 생각이 바뀌고 있습니다.

설치 → 실행 → 자동 시작 → 데이터 보존 → 백업

다음에는 화면으로 한번 보고 싶어졌어요

Docker를 계속 터미널에서 확인하다 보니 명령어도 조금씩 늘어나고 있습니다.

docker ps, 서비스 상태 확인, 컨테이너 정보 확인, 볼륨 확인.

하나씩은 어렵지 않은데, 컨테이너가 더 늘어나면 매번 명령어만으로 관리하는 게 조금 불편할 수도 있겠다는 생각이 들었어요.

그러다 원래 살펴보려고 했던 도구 하나가 다시 눈에 들어왔습니다.

Portainer.

Docker 컨테이너와 이미지, 볼륨 같은 걸 웹 화면에서 볼 수 있게 해주는 관리 도구라고 합니다.

다음에는 X MINI Docker에 Portainer를 올려서 지금까지 터미널에서 하나씩 확인했던 컨테이너와 볼륨이 화면에서는 어떻게 보이는지 살펴보려고 합니다.

※ 본 글은 X MINI N100 Debian Docker 환경에서 n8n 데이터와 Docker 컨테이너의 저장 구조를 이해하기 위해 Volume과 폴더 관리 개념을 살펴본 기록입니다. 실제 데이터 위치와 구성은 Docker 실행 방식 및 n8n 설치 설정에 따라 달라질 수 있습니다.