지난주(8/12) 4주 회고를 쓰면서 "n8n 클라우드는 14일 무료체험이라 챌린지가 끝나면 유료 전환이나 다른 호스팅을 다시 검토해야 한다"를 한계로 적어뒀었다. 오늘은 그 한계를 실제로 뚫은 날이다.
① 오라클 포기 → 구글 클라우드로 전환 — 8/12에 보류했던 Oracle Cloud를 다시 시도했는데, 이번엔 사양 문제도 용량 문제도 아니고 카드 결제 단계에서 아예 막혀버렸다. 더 붙잡지 않고 구글 클라우드(GCP) 무료 티어로 방향을 바꿨다. VM 인스턴스를 만들고 SSH 접속까지는 지난주에 해뒀던 상태였다.
② 이미 깔려 있던 n8n이 알고 보니 죽어 있었다 — Docker가 이미 설치돼 있길래 n8n을 새로 띄우려 했더니 "컨테이너 이름이 이미 사용 중"이라는 에러가 났다. docker ps로 확인해보니 n8n이 4일 전부터 계속 Up 상태로 돌고 있었다 — 즉 설치는 이미 되어 있었던 것. 그런데 브라우저로 접속하면 아무것도 안 떴다.
③ 원인 추적 — 세 번 헛짚고 네 번째에 찾았다 — 이게 오늘의 진짜 알맹이였다.
첫 번째 추측: DB 문제. 로그에
Database connection timed out이 반복되고crash.journal파일과 어중간하게 남은database.sqlite-wal파일이 보였다. 크래시로 DB가 망가진 것으로 판단하고 컨테이너와 볼륨을 통째로 지우고 새로 설치했다. → 그래도 안 됐다.두 번째 추측: 방화벽. 브라우저에서
ERR_CONNECTION_REFUSED가 떠서 GCP 방화벽을 봤더니chorys라는 규칙이 이미 있었는데, 허용 IP가 8/13 당시의 우리집 IP로 고정돼 있었다. 그 사이 IP가 바뀐 것. 고쳤더니 브라우저 증상은 바뀌었지만 여전히 안 열렸다. (오늘 이걸 세 번 고쳤다 — 중간에 와이파이가 바뀌면서 또 달라졌다.)세 번째 추측: n8n이 아예 못 떴다. 로그에
n8n ready on ... port 5678줄이 안 보여서 기동 실패로 의심했는데, 로그 전체를grep으로 훑어보니 그 줄이 분명히 있었다. 내 추측이 틀렸던 것.네 번째 — 진짜 원인.
docker stats를 봤더니PIDS 0이었다. 컨테이너 껍데기는Up으로 멀쩡한데 그 안에서 돌고 있는 프로그램이 0개, 즉 속이 텅 빈 상태였다.free -h로 보니 메모리 964Mi(약 1GB)에 스왑이0B— 완충장치가 하나도 없었다. n8n이 잘 뜬 뒤 시간이 지나면서 메모리가 부족해져 내부 프로세스가 전부 죽어버린 것이었다.
④ 해결: 스왑 1GB 추가 — fallocate로 1GB 스왑 파일을 만들고 /etc/fstab에 등록해서 재부팅해도 유지되게 했다. (디스크 여유가 2.1G뿐이라 2GB는 못 잡고 1GB로.) 컨테이너를 재시작하니 PIDS 20, curl -I에 HTTP/1.1 200 OK — 드디어 살아났다.
⑤ 보안쿠키 벽 — 그런데 브라우저로 들어가니 "secure cookie로 설정돼 있는데 안전하지 않은 URL로 접속했다"며 또 막혔다. n8n이 로그인 쿠키를 https://에서만 주고받도록 기본 설정돼 있어서였다. 도메인을 사서 HTTPS를 붙이는 게 정석이지만, 방화벽으로 이미 내 IP만 들어올 수 있게 막아놨으니 N8N_SECURE_COOKIE=false로 끄고 컨테이너를 재생성했다. (볼륨은 안 지워서 데이터는 유지됐다.)
⑥ 워크플로 재구축 → 텔레그램 발송 성공 — 계정을 만들고 워크플로를 새로 짰다. Schedule Trigger → RSS Read(50건) → Aggregate → Basic LLM Chain(Anthropic) → Telegram. Aggregate에서 Input Field Name이 비어 있어 "출력 필드 이름이 중복된다"는 에러가 났는데, title과 link를 넣어 해결했다. 크리덴셜(Anthropic API 키, 텔레그램 봇 토큰)은 8/12 때와 마찬가지로 서버가 바뀌면 안 넘어와서 새로 입력했다. 결국 텔레그램으로 3섹터 요약이 실제로 도착했다.
⑦ Active가 아니라 Publish였다 — 마지막에 활성화하려고 "Active 토글"을 찾았는데 안 보였다. 알고 보니 요즘 n8n은 그게 Publish로 바뀌어 있었고, 이미 ● Published 상태였다. 공식문서로 확인하니 발행하면 정해둔 시간에 스케줄이 돈다고 명시돼 있었다.
그때그때 느낀 것
안 되는 게 계속 나와서 답답했다. "또 그러는데?..", "이건 또 뭐여.." 소리가 절로 나왔다.
특히 방화벽 IP를 세 번이나 고친 게 허탈했다 — 매번 "이제 되겠지" 했는데 다른 이유로 또 막혔다.
게릿 콜이 짚은 원인이 두 번이나 틀렸을 때(DB 문제, n8n 기동 실패) 좀 불안했는데, 그래도 하나씩 확인해가며 좁혀지는 과정이 나쁘지 않았다.
PIDS 0을 발견하고 "아 안이 텅 비어 있었구나" 하고 딱 맞아떨어진 순간이 제일 시원했다.텔레그램에 요약이 도착한 걸 봤을 때, 지난주 회고에 "한계"라고 적어둔 걸 일주일 만에 지운 셈이라 뿌듯했다.
배운 것 (누적)
Up이라고 다 살아있는 게 아니다.docker ps가Up이어도 컨테이너 속이 텅 빌 수 있다 —docker stats의PIDS가 0이면 안에 돌고 있는 게 없다는 뜻이다. 이게 오늘 진단의 결정적 단서였다.이 증상은 헷갈리게 생겼다: 포트는 열려 있어서(docker-proxy가 잡고 있음) TCP 연결은 되는데, 요청을 보내면
Connection reset by peer가 나고 로그에는 아무것도 새로 안 찍힌다. 요청이 n8n한테 도달조차 못 한 것.메모리 1GB짜리 무료 VM에서 n8n을 돌리려면 스왑이 거의 필수다. 스왑이 0이면 잘 뜬 뒤에도 시간이 지나면서 프로세스가 죽는다.
스왑 크기는 디스크 여유를 먼저 확인하고 정해야 한다 (여유 2.1G에 2G를 잡으면 디스크가 꽉 찬다).
도메인 없이
http://IP:5678로 n8n에 접속하면 secure cookie 때문에 로그인 화면이 막힌다 —N8N_SECURE_COOKIE=false로 끄거나 HTTPS를 붙여야 한다.컨테이너를 지워도 볼륨을 안 지우면 데이터는 살아있다. 환경변수를 바꾸려면 컨테이너 재생성이 필요한데, 이때 볼륨만 건드리지 않으면 안전하다.
GCP 콘솔에는 "VPC 네트워크 → 방화벽"과 "네트워크 보안 → 방화벽 정책"이 따로 있다 — 이름이 비슷해서 헷갈리는데, VM에 바로 적용되는 건 앞엣것이다.
집 인터넷 IP는 자주 바뀐다. 방화벽을 특정 IP로만 열어두면 안전하지만 바뀔 때마다 고쳐야 한다는 유지비가 따라온다.
n8n의 Active 토글이 요즘 버전에선
Publish로 바뀌었다. 그리고 발행한 시점의 버전으로 실행되므로, 워크플로를 수정하면 Publish를 다시 눌러야 반영된다.크리덴셜(API 키·봇 토큰)은 서버를 옮기면 안 넘어온다 — 8/12에 배운 걸 오늘 또 겪었다.
다음 계획
RSS 소스가 한국경제 한 곳뿐이라 배터리 섹터가 자주 비는 문제 → 소스를 2~3개로 늘린다.
내일 9시 이후
Executions탭에서 자동 실행이 실제로 쌓이는지 확인한다.방화벽 IP를 매번 고치는 게 번거로우면, HTTPS를 제대로 붙이는 방법을 알아본다.
