n8n Stripe 웰컴 이메일 만들기 — 결제 완료 순간 RAG로 개인화하기

n8n.io 공식 템플릿 마켓플레이스에 공개된 워크플로우를 가져오면, Stripe 결제가 완료되는 순간 Pinecone 벡터DB에서 해당 요금제 정보를 검색해 개인화된 HTML 웰컴 이메일을 Gmail로 자동 발송하고, 고객 정보와 갱신일을 구글시트에 기록하는 SaaS 온보딩 자동화를 만들 수 있습니다.

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

포트폴리오에 "n8n 자동화 몇 개 만들어봤어요"라고만 쓰면 다음 질문은 거의 항상 "그중에 실제 비즈니스 이벤트로 시작하는 것도 있나요?"입니다. 이 템플릿은 그 질문에 구체적으로 답할 수 있게 해줍니다. "고객이 결제를 마치는 순간 그 이벤트를 받아서, 요금제에 맞는 내용으로 개인화한 웰컴 이메일을 자동으로 보내는 온보딩 자동화를 만들어봤습니다."

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

• 결제 이벤트 기반 트리거 설계 — 스케줄이나 수동 실행이 아니라, 실제 비즈니스 이벤트(결제 완료)가 발생하는 순간 워크플로우가 시작되도록 구성한 경험
• RAG를 챗봇이 아닌 실무 로직에 적용 — 벡터DB 검색을 대화형 질의응답이 아니라, 이메일 본문에 들어갈 정보를 조회하는 용도로 쓴 경험
• 여러 서비스를 하나의 파이프라인으로 엮기 — 결제(Stripe), 검색(Pinecone), 생성(OpenAI), 발송(Gmail), 기록(Google Sheets)까지 다섯 개 서비스의 크리덴셜을 연결해 하나의 흐름으로 통합한 경험

이 세 가지는 결제 웰컴 이메일뿐 아니라 신규 가입 온보딩, 플랜 업그레이드 안내, 결제 실패 알림처럼 "특정 비즈니스 이벤트가 일어나면 그 맥락에 맞는 메시지를 자동으로 만들어 보낸다"는 유형의 자동화 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Send personalized SaaS welcome emails with Stripe, Pinecone, GPT-4o, and Gmail이라는 이름으로 공개된 템플릿이고, 제작자는 Ruth Aju입니다. 카테고리는 CRM과 AI RAG로 등록돼 있습니다.

공식 페이지는 이 템플릿의 대상을 "결제부터 웰컴 이메일까지 수작업 없이 고객 온보딩을 자동화하고 싶은 SaaS 창업자·개발자"로 명시하고 있습니다. 결제 처리와 이메일 발송을 따로따로 관리하던 초기 SaaS 팀이, 두 과정 사이의 수작업(요금제 확인, 이메일 작성, 발송, 기록)을 워크플로우 하나로 대체하는 그림입니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

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

• Trigger — Stripe Trigger가 결제 완료 이벤트를 받으면서 흐름이 시작됩니다. 지금까지 이 시리즈에서 다룬 트리거는 스케줄, 웹훅, 채팅, 구글드라이브 감시처럼 "시간이 됐거나 파일이 바뀌었을 때"였는데, 결제라는 실제 금전 이벤트가 트리거인 건 이번 편이 시리즈 전체에서 처음입니다. 사람이 아무 조작을 하지 않아도 고객이 결제하는 바로 그 순간 워크플로우가 움직인다는 뜻입니다.
• Task — 결제 금액을 요금제 등급으로 변환하고, Stripe 결제 정보에서 고객 이름·이메일 같은 데이터를 추출합니다. 그다음 AI Agent가 Pinecone에서 해당 요금제의 상세 정보를 검색해, 그 내용을 근거로 갱신일까지 자동 계산한 개인화 HTML 이메일을 만듭니다. 여기서 눈여겨볼 지점은 벡터DB 검색이 챗봇의 답변 생성이 아니라 이메일에 들어갈 "사실 정보"를 가져오는 데 쓰인다는 점입니다. RAG를 "질문에 답하는 용도"로만 알고 있었다면, 이 템플릿은 같은 검색 구조를 "메시지를 채우는 재료"로 쓰는 다른 응용을 보여줍니다.
• Target — 완성된 이메일은 Gmail로 발송되고, 동시에 고객 정보와 구독 정보는 Google Sheets에 기록됩니다. 결과물이 하나가 아니라 "고객에게 가는 것"과 "팀 내부에 남는 것" 두 갈래로 나뉘는 구조입니다.

공식 페이지에는 노드 미리보기로 Stripe Trigger, Edit Fields(Set), Google Sheets를 포함해 "+7 more"라고만 나와 있어, 전체 노드 수는 열 개 안팎으로 추정됩니다. 이 글은 공식 텍스트에 명시된 흐름까지만 다루고, 미리보기에 나오지 않은 나머지 노드의 정확한 이름이나 파라미터는 추측하지 않습니다. 정확한 구성은 템플릿을 직접 임포트해 캔버스에서 확인하는 게 가장 확실합니다.

만들기

공식 Setup 단계는 총 5개입니다. 순서는 그대로 두고 각 단계에서 무엇을 준비해야 하는지를 풀어씁니다.

1. Stripe 계정 연결 — checkout.session.completed 이벤트

Stripe 계정을 n8n에 연결하고, Stripe Trigger 노드가 checkout.session.completed 이벤트를 구독하도록 설정합니다. 이 이벤트는 결제(체크아웃)가 정상적으로 끝났을 때 발생하는 이벤트라서, 이 템플릿은 결제가 Stripe Checkout 흐름으로 이뤄지는 걸 전제로 합니다.

2. Pinecone에 요금제 정보를 청크로 저장

Pinecone 계정을 만들고, 요금제별 상세 정보(플랜 이름, 가격, 포함 기능 등)를 미리 청크 단위로 나눠 저장해둡니다. 이 단계가 이 템플릿에서 가장 중요합니다. 워크플로우 자체는 Pinecone에서 정보를 "검색"만 할 뿐, 요금제 지식베이스를 채워 넣는 작업은 자동화 대상이 아니라 사람이 미리 해둬야 하는 준비 작업입니다. 이 지식베이스가 비어 있으면 AI Agent가 검색할 내용이 없어 이메일 개인화도 되지 않습니다.

3. OpenAI 크리덴셜 — AI Agent와 Embeddings 노드용

AI Agent 노드와 Embeddings 노드 모두 OpenAI 크리덴셜을 씁니다. 템플릿 이름에 GPT-4o가 들어가 있는 것도 이 AI Agent가 사용하는 모델을 가리킵니다. 임베딩과 답변 생성을 서로 다른 서비스로 나누지 않고 OpenAI 한 곳으로 통일했다는 점이, 앞서 다룬 RAG 챗봇 템플릿(구글드라이브+Gemini+Pinecone 조합)과 다른 부분입니다.

4. Gmail을 발송 계정으로 연결

이메일을 실제로 보낼 Gmail 계정을 n8n에 연결합니다. 생성된 HTML 웰컴 이메일이 이 계정을 통해 고객에게 전달됩니다.

5. 구글시트 준비 — 컬럼 6개

구글시트를 하나 만들고 헤더 행에 아래 6개 컬럼을 정확히 맞춥니다.

컬럼	용도
Name	고객 이름
Email	고객 이메일
Amount	결제 금액
Tier	판정된 요금제 등급
Renewal Date	AI Agent가 계산한 갱신일
Status	구독 상태

공식 문서에 시트 스키마가 이 여섯 컬럼으로 명시돼 있어서, 시트를 준비할 때 컬럼명과 순서를 그대로 따르면 워크플로우 임포트 후 매핑 작업이 줄어듭니다. 이 시트가 곧 갱신 시점을 관리하는 최소한의 고객 데이터베이스 역할을 합니다.

주의할 점 · 제약

공식 문서와 요구사항(Requirements)에 적힌 내용을 그대로 옮기면 이렇습니다.

• 다섯 개 서비스 계정이 모두 필요합니다 — Stripe, Pinecone(요금제 지식베이스 업로드 완료 상태), OpenAI, Gmail, Google Sheets까지 준비해야 동작합니다. 이 시리즈에서 다룬 템플릿 중 연결해야 할 서비스 개수가 많은 축에 속합니다.
• 요금제 지식베이스는 자동으로 채워지지 않습니다 — 2번 설정 단계에서 다뤘듯, Pinecone에 요금제 정보를 청크로 넣는 작업은 워크플로우 실행 전에 사람이 끝내둬야 하는 준비 작업입니다. 워크플로우를 그대로 가져오기만 해서는 개인화된 이메일이 나오지 않습니다.
• 결제 흐름이 Stripe Checkout이어야 합니다 — 트리거가 구독하는 이벤트가 checkout.session.completed로 고정돼 있어서, 다른 방식으로 결제를 처리하고 있다면 이벤트 설정을 그 방식에 맞게 다시 확인해야 합니다.
• 갱신일 이후의 동작은 문서에 없습니다 — 공식 설명은 갱신일을 계산해 구글시트에 기록하는 데까지만 다룹니다. 갱신일이 다가왔을 때 알림을 보내거나 후속 이메일을 발송하는 동작은 이 템플릿의 범위 밖입니다. 필요하다면 이 시트를 소스로 하는 별도의 스케줄 워크플로우를 이어붙이는 확장이 됩니다.

포트폴리오·면접 포인트

포트폴리오에는 테스트 결제 한 건을 Stripe 테스트 모드로 흘려보냈을 때 도착하는 웰컴 이메일 캡처와, 같은 시점에 구글시트에 한 줄이 채워지는 장면 두 개를 같이 넣으면 됩니다. 요금제가 다른 테스트 결제를 두세 번 만들어서 이메일 내용이 요금제마다 다르게 생성되는 걸 보여주면, 단순히 템플릿 문구를 채워 넣은 게 아니라 실제로 RAG 검색 결과에 따라 내용이 바뀐다는 걸 증명할 수 있습니다.

면접에서 "RAG를 어디에 써봤나요?"라는 질문에 챗봇 사례만 나오는 지원자가 많습니다. 이 템플릿을 직접 만들어봤다면 "질문에 답하는 챗봇이 아니라, 결제 이벤트가 들어왔을 때 벡터DB에서 요금제 정보를 검색해 이메일 본문을 채우는 데 RAG를 썼다"고 답할 수 있습니다. 검색 결과를 대화가 아니라 비즈니스 로직의 한 단계로 쓴 경험은, RAG 개념을 챗봇 이상으로 이해하고 있다는 인상을 줍니다.

다음 액션

다음 편에서는 웹훅 중복 실행을 막는 멱등성(idempotency) 게이트 패턴을 다루는 템플릿으로 넘어갑니다. 오늘 워크플로우의 트리거도 결국 Stripe가 보내는 웹훅이라는 점에서 이어지는 주제이기도 합니다. 웹훅은 네트워크 재시도 같은 이유로 같은 이벤트가 중복 전달될 수 있는데, 그때 같은 고객에게 웰컴 이메일이 두 번 나가지 않게 막는 장치가 바로 다음 편의 주제입니다.