n8n 쇼핑 어시스턴트 승인 템플릿 — AI가 고른 상품, 세 번 확인받아야 주문이 나간다

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, GPT-4.1-mini 쇼핑 어시스턴트가 상품을 추천하고, 사용자가 상품 선택을 확인하고, 구매를 승인하고, 주문이 실제로 처리됐는지까지 확인하는 세 번의 관문을 전부 통과해야 최종 주문 상태가 Slack 채널에 올라오는 구매 승인 구조를 설계할 수 있습니다.

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

"쇼핑 챗봇도 만들어봤어요"라고 말하면 면접관이 곧바로 되묻는 질문이 있습니다. "AI가 마음대로 결제하면 어떡하죠?" 이 시리즈에서 앞서 다룬 이메일 승인 템플릿은 이 질문에 비교적 단순하게 답할 수 있었습니다. 승인자가 메일 한 통에 답하면 그걸로 끝이었고, 확인 지점도 방식도 하나였습니다. 이번 템플릿은 다릅니다. 상품을 고르는 순간, 구매를 확정하는 순간, 주문이 실제로 처리됐는지 확인하는 순간까지 서로 다른 세 지점에 관문을 세워두고, 그때마다 워크플로우가 멈춰서 외부 신호가 돌아올 때까지 기다립니다.

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

• 비동기 승인 체인 설계 — 조건 분기 하나로 끝내지 않고, 서로 다른 리스크 지점(상품 선택·결제·사후 확인)마다 별도의 대기 지점을 둔 경험
• 웹훅 재개(resume webhook) 활용 — 워크플로우를 사용자 응답이나 외부 시스템 콜백이 올 때까지 멈춰두고, 나중에 그 신호로 다시 깨우는 패턴을 다뤄본 경험
• AI 에이전트의 구조화된 출력 파싱 — 자유 텍스트 답변이 아니라 "답변/상품 후보/구매 의도"로 나뉜 JSON을 받아 그대로 분기 로직에 쓴 경험

이 세 가지가 중요한 이유는 하나의 승인 지점이 모든 리스크를 다 막아주지 않는다는 데 있습니다. 상품을 잘못 골랐는지, 결제를 실제로 원했는지, 결제가 진짜로 처리됐는지는 서로 다른 순간에 서로 다른 방식으로 확인해야 하는 질문입니다. 이 구조는 쇼핑뿐 아니라 여행 예약, 대출 신청, 환불 처리처럼 "되돌리기 어려운 액션 앞에 확인 단계가 여러 번 필요한" 업무 전반에 그대로 적용됩니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Run a human-approved shopping assistant with GPT-4.1-mini, product APIs and Slack라는 이름으로 공개된 템플릿이고, 제작자는 자동화 에이전시 Oneclick AI Squad입니다. 카테고리는 Support Chatbot과 AI Chatbot으로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 대화형 쇼핑 어시스턴트를 만드는 워크플로우입니다. OpenAI가 대화를 맡고, HTTP로 연결된 상품 카탈로그 검색 API가 실시간 상품 데이터를 공급하고, 체크아웃·주문 API가 사용자의 명시적 승인을 거쳐 실제 주문을 접수한 뒤, 최종 주문 상태를 Slack 채널에 게시합니다.

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

다만 미리 짚어둘 게 있습니다. 이 템플릿은 진짜 상품 카탈로그 검색 API와 진짜 체크아웃·주문 API가 이미 있다는 전제 위에 서 있습니다. 개인이 이런 API를 처음부터 갖춰 끝까지 실행해보기는 현실적으로 어려워서, 이 글은 "직접 실습"보다 "비동기 승인 체인을 어떻게 설계하는지 배우는 설계 학습용"으로 읽는 편을 권합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works" 6단계를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다. 이 템플릿의 핵심은 Task 안에 웹훅 재개(resume webhook) 대기 지점이 세 번 등장한다는 점입니다.

• Trigger — Chat Trigger가 사용자의 쇼핑 요청을 받으면 시작됩니다. 공식 문서는 수동 테스트 실행으로도 시작할 수 있다고 안내합니다.
• Task — OpenAI(GPT-4.1-mini) 에이전트가 단기 기억과 함수 호출을 이용해 상품 카탈로그 검색 API를 호출, 실시간 가격·재고를 확인한 뒤 최대 3개 상품을 추천합니다. 이 응답을 파싱해 답변, 상품 후보 목록, 구매 의도(선택 상품·수량) 세 부분으로 나눕니다. 구매 의도가 없으면 답변만 돌려주고 끝나지만, 구매 의도가 있으면 첫 번째 웹훅 재개 지점에서 사용자의 상품 선택 확인을 기다립니다. 확인되면 두 번째 웹훅 재개 지점에서 명시적인 구매 승인을 기다린 뒤, 승인이 나면 체크아웃 API에 상품·수량·고객 정보·결제 수단·배송지를 담아 주문을 제출합니다.
• Target — 세 번째 웹훅 재개 지점에서 비동기 주문확인 콜백을 기다린 뒤, 주문 상태를 정리해 Slack 채널에 게시하는 것으로 흐름이 끝납니다.

만들기

공식 페이지의 Setup 안내는 3단계로 짧게 정리돼 있습니다. 각 단계가 실제로 무엇을 준비하라는 뜻인지 풀어서 정리했습니다.

1. 크리덴셜 네 개 준비하기

공식 안내는 OpenAI, Slack, 그리고 상품 카탈로그 검색 API와 체크아웃·주문 API 각각에 대한 HTTP Header Auth 크리덴셜을 추가하라고 명시합니다. 즉 이 템플릿을 실제로 돌리려면 OpenAI·Slack 계정 외에, 헤더 인증 방식을 쓰는 상품 API와 주문 API 두 곳에 접근 권한이 이미 있어야 합니다.

2. 설정값을 실제 환경에 맞게 채우기

공식 문서가 명시한 설정값 목록은 카탈로그·주문 API의 base URL, 통화, 고객 ID, 기본 배송 주소, 결제 수단 ID, 최대 예산, 알림을 받을 Slack 채널입니다. 템플릿을 가져온 직후에는 이 값들이 자리표시(placeholder) 상태이므로, 캔버스에서 해당 노드들을 찾아 실제 값으로 바꿔야 워크플로우가 의미 있게 동작합니다.

3. 세 개의 resume webhook URL을 실제 접점에 연결하기

n8n의 Wait 노드는 외부에서 특정 웹훅 URL로 요청이 들어올 때까지 워크플로우 실행을 멈춰두고, 요청이 오면 그 데이터를 가지고 실행을 이어가는 재개(resume) 방식을 지원합니다. 이 템플릿은 이 방식을 상품 선택 확인, 구매 승인, 주문확인 콜백 세 곳에 각각 적용합니다.

공식 안내는 이 세 웹훅 URL을 각각 복사해, 상품 선택·구매 승인 단계는 채팅 UI의 버튼에, 주문확인 단계는 사용 중인 쇼핑몰이나 결제 공급자의 주문 상태 콜백에 연결하라고 설명합니다. 즉 이 배선 작업은 템플릿 안에서 자동으로 끝나지 않고, 자신의 채팅 UI와 결제 시스템 쪽에서 직접 만들어야 하는 부분입니다.

주의할 점 · 제약

공식 문서에 적힌 준비물과, 직접 재현할 때 부딪히기 쉬운 지점을 나누면 이렇습니다.

• 실제 상품 카탈로그 API와 체크아웃 API가 있어야 끝까지 돌려볼 수 있습니다 — 두 API 모두 HTTP Header Auth로 실제 엔드포인트에 연결돼 있어야 상품 검색과 주문 접수가 실제로 동작합니다. 이런 시스템이 없다면 이 템플릿은 "직접 실습"이 아니라 "비동기 승인 체인이 어떻게 짜여 있는지 배우는 설계 학습용"으로 읽는 편이 현실적입니다.
• resume webhook 세 개를 직접 배선해야 합니다 — 웹훅 URL을 복사해 채팅 UI 버튼과 결제 공급자의 콜백에 연결하는 작업은 템플릿이 대신 해주지 않습니다. 자신의 채팅 프런트엔드와 결제 시스템이 이미 있어야 이 배선이 의미를 가집니다.
• AI 대화 모델이 GPT-4.1-mini로 고정돼 있습니다 — 다른 모델로 바꾸려면 AI Agent 노드를 직접 수정해야 합니다.
• 최종 알림 대상이 Slack 채널로 고정돼 있습니다 — 다른 채널(이메일, 다른 메신저)로 바꾸려면 마지막 노드를 교체해야 합니다.

포트폴리오·면접 포인트

이 템플릿은 실제 카탈로그·체크아웃 API가 없어도 설계 구조만으로 포트폴리오에 담을 수 있습니다. 상품 카탈로그 API 자리에 구글시트나 더미 JSON을, 체크아웃 API 자리에 로그만 남기는 노드를 넣어 세 번의 승인 대기 지점이 실제로 순서대로 작동하는 걸 보여주면 됩니다. 실물 쇼핑몰이 없어도 "왜 승인을 한 번이 아니라 세 곳으로 나눴는지"를 설명할 수 있으면 충분합니다.

면접에서는 "왜 승인을 세 번이나 나눴나요?"라는 질문이 나올 수 있습니다. 답은 이렇게 정리할 수 있습니다. 상품을 잘못 골랐는지, 사용자가 결제를 정말로 원했는지, 결제가 실제로 처리됐는지는 서로 다른 시점에 확인해야 하는 서로 다른 질문이기 때문에, 승인 지점 하나로 뭉뚱그리면 어느 단계에서 문제가 생겼는지 구분할 수 없다는 답입니다. 이렇게 답할 수 있으면 웹훅 URL을 복사·붙여넣기 할 줄 안다는 인상을 넘어, 리스크 지점을 나눠서 설계할 줄 안다는 인상을 줍니다.

다음 액션

다음 편에서는 여러 하위 에이전트를 오케스트레이터가 조율해 주식 리포트를 만들어내는, 이 시리즈에서 가장 복잡한 구조를 가진 템플릿을 다룹니다. 이번 편이 "사람의 승인을 기다리는 지점을 어떻게 나눠 설계하는지"를 보여줬다면, 다음 편은 "여러 AI 에이전트가 서로 다른 역할을 나눠 맡을 때 무엇을 오케스트레이터에 맡기고 무엇을 서브 에이전트에 맡기는지"를 보여줍니다.