폼 제출 한 번으로 서버에 Docker 앱을 배포하는 n8n 워크플로우 — Hostinger 공식 템플릿, 셀프호스팅과 유료 VPS 둘 다 필요

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 사용자가 폼에서 원하는 Docker 앱 스택과 배포할 VPS를 고르기만 해도 n8n이 Hostinger API를 호출해 실제 서버에 컨테이너를 띄우고, 그 결과를 이메일 리포트로 보내주는 자동화를 만들 수 있습니다. 다만 이 템플릿은 커뮤니티 노드를 쓰는 셀프호스팅 n8n과 유료 Hostinger VPS 계정이 둘 다 있어야 재현할 수 있다는 점을 먼저 짚고 시작합니다.

이 템플릿 하나로 보여줄 수 있는 것

이 시리즈에서 지금까지 다룬 템플릿 대부분은 n8n 안에서 데이터가 오가는 자동화였습니다. 문서를 읽고, 메시지를 분류하고, 채팅에 답하는 식으로요. 이 템플릿은 다릅니다. n8n이 트리거가 되어 실제 서버 인프라를 프로비저닝합니다. "n8n으로 뭘 만들어봤나요?"라는 질문에 "서버에 컨테이너를 직접 띄워봤습니다"라고 답할 수 있는 템플릿은 이 시리즈에서 이번이 처음입니다.

짧은 문장이지만 안에 들어간 역량은 세 가지입니다.

• 폼 기반 셀프서비스 설계 — 사용자가 화면에서 고른 선택지가 그대로 API 호출 파라미터가 되도록 앞단을 설계해본 경험
• 외부 인프라 API 오케스트레이션 — 배포 요청을 보내고, 비동기로 진행 상태를 폴링하고, 성공과 실패를 각각 다른 경로로 처리해본 경험
• 운영 결과를 사람이 읽을 보고서로 조립하는 감각 — 서버 여러 대에서 나온 결과를 하나의 이메일로 정리해 "무슨 일이 있었는지" 한눈에 보이게 만든 경험

세 번째가 특히 실무에 가깝습니다. 자동화가 어려운 지점은 대개 트리거나 API 호출이 아니라, 여러 갈래로 흩어진 결과를 사람이 읽고 바로 판단할 수 있는 한 장의 보고서로 모으는 부분이기 때문입니다.

이 템플릿은 무엇인가

먼저 분명히 해둘 게 있습니다. 이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Deploy curated Docker app stacks to a Hostinger VPS via forms and email라는 이름으로 공개된 템플릿입니다. 카테고리는 DevOps로 등록돼 있습니다.

이 템플릿은 이 시리즈에서 소개한 다른 템플릿들과 제작자 성격이 다릅니다. "CREATED BY" 항목에 적힌 이름이 개인 커뮤니티 제작자가 아니라 Hostinger, 즉 이 워크플로우가 의존하는 VPS 호스팅 서비스를 직접 운영하는 회사의 공식 브랜드 계정입니다. 실제 서버에 명령을 실행하고 컨테이너를 띄우는 자동화라는 점을 생각하면, 이 출처가 개인 취미 프로젝트가 아니라 해당 인프라를 만든 회사가 자기 API 사용법을 보여주려고 직접 공개한 레퍼런스 구현이라는 사실은 신뢰도 판단에 참고할 만합니다.

공식 페이지의 Quick overview는 이 템플릿의 동작을 이렇게 요약합니다. 폼으로 원하는 앱 스택과 알림받을 이메일을 입력받고, Hostinger API로 조회한 보유 VPS 목록 중 배포 대상을 다시 폼으로 고르게 한 뒤, 선택된 스택을 개별 Docker Compose 프로젝트로 나눠 해당 VPS에 배포하고, 앱별로 포트·컨테이너 상태·생성된 크레덴셜을 정리한 배포 요약을 이메일로 보낸다는 설명입니다. n8n 설치나 폼·이메일 노드의 기본 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿 고유의 흐름과 진입장벽에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works" 7단계를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 폼이 두 번 등장합니다. 첫 번째 폼은 Developer, Hobbyist, Freelancer, AI/LLM 중 하나로 앱 스택을 고르고 결과를 받을 이메일을 입력받습니다. 두 번째 폼은 그사이 Hostinger API로 조회한 보유 VPS 목록 중 실제로 배포할 서버를 고르게 합니다.
• Task — 선택된 스택을 앱 단위 아이템으로 쪼개고, 각 앱에 필요한 Docker Compose 콘텐츠와 시크릿 값을 무작위로 생성합니다. 그다음 앱마다 개별적으로 Hostinger API를 호출해 Compose 프로젝트를 만들고, 짧게 대기했다가 배포별 진행 상태를 폴링해 성공과 실패로 갈립니다. 성공한 앱은 컨테이너 목록과 포트·상태를 조회하고, 실패한 앱은 최근 Docker 프로젝트 로그를 가져와 각각 사람이 읽을 블록으로 정리합니다.
• Target — 앱별로 만들어진 블록을 하나로 모아, 처음 폼에 입력된 이메일 주소로 SMTP를 통해 배포 리포트를 전송합니다.

캔버스 미리보기 카드에는 Send Email, If, Edit Fields(Set) 세 노드가 아이콘으로 보이고 "+6개 더"라는 표시가 붙어 있습니다. Hostinger API를 호출하는 노드는 커뮤니티 노드라 미리보기에 아이콘이 뜨지 않지만, 공식 설명 전체가 이 API 호출을 중심으로 짜여 있어 워크플로우의 핵심입니다. 이 페이지가 공개한 정보는 여기까지이고, 그 이상의 세부 파라미터(정확한 폴링 주기, Compose 콘텐츠 생성 로직 등)는 확인되지 않아 이 글에서 다루지 않습니다.

만들기

공식 Setup 섹션이 다루는 항목은 네 가지입니다. 그 앞뒤로 취준생이 실제로 준비해야 할 순서를 채워서 정리하면 이렇습니다.

1. 셀프호스팅 인스턴스인지 먼저 확인하기

지금 쓰는 n8n이 클라우드 요금제라면 이 템플릿은 이 구조 그대로는 못 돌립니다. 커뮤니티 노드를 쓰기 때문입니다. 아직 셀프호스팅 환경이 없다면, 이 시리즈에서 클라우드로도 동작하는 다른 편으로 포트폴리오를 먼저 채워두고, 셀프호스팅 환경을 마련한 뒤 이 템플릿으로 돌아오는 순서를 권합니다.

2. Community Nodes에서 Hostinger API 노드 설치하기

Settings → Community Nodes에서 패키지명 n8n-nodes-hostinger-api를 입력하고 Install을 누릅니다.

3. Hostinger VPS 계정과 API 키 준비하기

이 템플릿은 실제로 요금이 발생하는 유료 VPS 계정이 있어야 재현할 수 있습니다. Hostinger 공식 사이트(hostinger.com/vps-hosting)에는 2026년 8월 기준 가장 저렴한 VPS 플랜(KVM 1, vCPU 1개·RAM 4GB·스토리지 50GB NVMe SSD)이 프로모션가로 월 6.49달러부터 안내되어 있습니다. 다만 프로모션가는 약정 기간과 결제 시점에 따라 달라질 수 있으니, 실제 계정을 만들기 전에 공식 사이트에서 다시 확인하는 게 안전합니다. VPS를 만든 뒤에는 VPS 계정 접근 권한을 가진 API 키를 발급해 n8n에 Hostinger API 크레덴셜로 등록합니다.

4. SMTP 이메일 크레덴셜 연결하기

배포 리포트를 보낼 SMTP 계정을 크레덴셜로 등록합니다. 공식 문서는 폼에 제출된 알림 이메일을 발신·수신 양쪽에 관련된 방식으로 사용한다고 설명하고 있어, 실제로 리포트를 받을 이메일 주소를 폼 테스트 단계에서 정확히 입력해야 합니다.

5. 배포 전 마지막 점검

공식 문서는 대상 VPS에 Docker가 사용 가능한 상태인지, 그리고 이 템플릿이 배포하고 포트를 여는 컨테이너들이 자신의 보안 요구사항에 맞는지 확인하라고 명시하고 있습니다. 처음 시도한다면 실제 서비스용 VPS가 아니라 테스트 전용으로 새로 만든 VPS에서 먼저 폼 제출부터 이메일 도착까지 한 번 돌려보는 순서를 권합니다.

주의할 점 · 제약

공식 문서에 적힌 제약과 이 템플릿 특유의 성격을 그대로 옮기면 이렇습니다.

• 진입장벽이 이중입니다. 커뮤니티 노드(n8n-nodes-hostinger-api)를 쓰기 때문에 셀프호스팅 n8n이 필요하고, 여기에 더해 Hostinger VPS와 API 키라는 유료 호스팅 계정까지 있어야 합니다. 이 시리즈의 다른 템플릿은 대부분 무료 API나 트라이얼로 재현할 수 있지만, 이 템플릿은 인프라 자체를 실제로 돈을 내고 갖고 있어야 처음부터 시도할 수 있는 몇 안 되는 예외입니다.
• SMTP 메일함도 별도로 필요합니다. 배포 리포트를 발송할 SMTP 계정이 없으면 마지막 단계가 동작하지 않습니다.
• 생성된 크레덴셜이 이메일 본문에 그대로 담깁니다. 공식 설명에 따르면 성공 시 상태 블록에 포트·컨테이너 상태와 함께 "생성된 크레덴셜"이 포함됩니다. 뒤집어 말하면, 이 자동화를 그대로 쓰면 새로 만들어진 앱의 접속 정보가 암호화되지 않은 이메일 본문으로 발송된다는 뜻입니다. 실제로 쓰려면 이메일 대신 더 안전한 채널로 크레덴셜을 전달하도록 마지막 단계를 바꾸는 걸 권합니다.
• Docker 가용성과 포트 노출은 사용자 책임입니다. 공식 문서가 명시적으로 "대상 VPS에 Docker가 있는지, 이 컨테이너들을 배포하고 포트를 여는 것이 자신의 보안 요구사항에 맞는지" 확인하라고 적어둔 만큼, 이 워크플로우는 검증 없이 실행하면 그대로 서버에 반영되는 구조입니다.

포트폴리오·면접 포인트

포트폴리오에는 세 장이면 흐름이 보입니다. 스택과 이메일을 입력하는 첫 번째 폼, VPS를 선택하는 두 번째 폼, 그리고 실제로 도착한 배포 리포트 이메일입니다. 여기에 Hostinger 콘솔에서 컨테이너가 뜬 화면까지 더하면 "폼 제출이 실제 서버 상태 변화로 이어졌다"는 흐름이 완성됩니다.

면접에서는 "이 자동화에서 가장 위험한 지점이 뭐라고 생각하나요?"라는 질문이 나올 수 있습니다. 답은 앞서 짚은 크레덴셜 노출입니다. 배포 성공 시 생성된 접속 정보가 암호화되지 않은 이메일로 발송되는 구조이니, 실제 운영에 쓰려면 크레덴셜 전달 채널부터 바꿔야 한다고 답하면 됩니다. 이 답을 할 수 있으면 "템플릿을 그대로 가져다 쓴 사람"이 아니라 "인프라 자동화의 위험 지점을 스스로 찾아낸 사람"이라는 인상을 줍니다.

다음 액션

여기까지 왔다면 셀프호스팅 인스턴스 운영과 외부 API 오케스트레이션을 모두 다뤄본 셈입니다. 다음 단계는 새로운 템플릿을 더 찾기보다, 지금까지 이 시리즈에서 본 패턴들 — 폼 기반 입력, 비동기 상태 폴링, 성공·실패 분기, 결과 리포트 조립 — 을 자신의 개인 프로젝트에 그대로 옮겨보는 것입니다. 예를 들어 이 템플릿의 Hostinger API 자리에 자신이 관리하는 다른 서비스의 API를 넣어보면, 템플릿 하나를 따라 만든 경험이 임의의 인프라 자동화를 설계할 수 있는 역량으로 넓어집니다.