하루 자동 루틴을 4개 서브플로우로 나눠 설계:n8n 구현가이드
지금 단계에서는 “한 번에 완전 자동화”보다, 작동하는 최소 루틴부터 살리는 설계가 맞습니다. n8n은 트리거, 데이터 정제, 분기, API 호출 순서가 명확해야 돌아가므로, 먼저 하루 자동 루틴을 4개 서브플로우로 나눠 설계하는 것이 안정적입니다.
하루 루틴 설계
하루 자동 루틴은 보통 상품 후보 수집 → 필터링/점수화 → 마켓 등록 → 성과 점검 및 정리의 4단계로 끊는 게 가장 관리하기 쉽습니다. 특히 n8n에서는 한 워크플로우 안에 모든 걸 몰아넣기보다, Schedule 또는 Webhook으로 시작하는 분리된 플로우를 만들고 데이터는 Google Sheets나 DB를 중간 저장소로 두는 방식이 디버깅에 유리합니다.
- 05:00 상품 후보 수집: 아마존 URL/ASIN/카테고리 후보 생성.
- 05:20 상품 정보 수집: 제목, 가격, 옵션, 리뷰 수, 브랜드 등 추출.
- 05:40 필터링 및 금칙어 제거: 판매 불가 키워드, 브랜드, 카테고리 제외.
- 06:00 판매가 계산: 수수료, 배송비, 환율, 목표 마진 반영.
- 06:20 상품 등록용 데이터 변환: 쿠팡/네이버 포맷 맞춤.
- 06:40 등록 API 호출 또는 업로드 파일 생성.
- 17:00 성과 점검: 유입 0, 판매 0, 오류 상품 체크 후 삭제 후보 분리.
- 17:20 신규 후보로 교체 등록.
n8n 워크플로우
현재 미동작이라면, 먼저 아래처럼 4개 워크플로우로 쪼개는 것이 좋습니다.
1) 후보 수집 워크플로우
- Schedule Trigger
- Set
- OpenAI/Gemini용 프롬프트 생성
- LLM 호출
- Code
- Google Sheets 또는 Airtable 저장
이 플로우의 목적은 “오늘 어떤 카테고리에서 어떤 상품 URL 후보를 모을지” 결정하는 것입니다. LLM이 직접 아마존 실데이터를 보장해 주는 구조는 약하므로, 실전에서는 LLM은 후보 키워드/후보 URL 패턴 제안용으로 쓰고, 실제 상품 정보는 HTTP Request + 스크래핑 API나 외부 데이터 API로 가져오는 편이 안정적입니다.
2) 상품 상세 수집 워크플로우
- Webhook 또는 Execute Workflow
- Read from Sheets
- Split In Batches
- HTTP Request
- Code
- IF
- DB 저장 크롤링이 자주 막히므로, n8n에서 HTTP Request 노드로 외부 스크래핑 엔드포인트를 호출하고 결과 JSON을 받는 패턴이 많이 쓰입니다. 이 단계에서 title, price, rating, reviewCount, availability, imageUrls, brand, category, asin 같은 필드를 표준 스키마로 정규화해야 다음 단계가 안 꼬입니다.
3) 등록 준비 워크플로우
- Trigger
- DB Read
- Code로 마진 계산
- IF로 최소 마진 필터
- LLM으로 제목/옵션/설명 정리
- Set으로 마켓 포맷 변환
- HTTP Request 또는 CSV 생성
n8n은 JSON 흐름이 강점이므로, 여기서 “원본 상품 데이터”와 “마켓 등록 데이터”를 분리 컬럼으로 관리해야 수정이 쉬워집니다. 등록이 바로 안 되면 처음부터 API 직행하지 말고, 먼저 등록용 CSV/시트 출력이 제대로 나오는지 확인한 뒤 API 연결로 넘어가는 편이 실패를 줄입니다.
4) 정리/삭제 워크플로우
- Schedule Trigger
- 판매/유입 데이터 읽기
- IF
- Code로 점수 계산
- 삭제 후보 시트 저장
- 승인 후 삭제 API 또는 상태 변경
처음부터 자동 삭제까지 걸면 사고가 날 수 있으니, 1차는 “삭제 후보 시트 생성”, 2차는 사람이 확인 후 승인, 3차부터 반자동 삭제로 가는 게 안전합니다.
노드 순서 예시
가장 먼저 살려야 할 최소 동작 워크플로우는 아래 형태입니다.
- Schedule Trigger
- Set: today, targetCategory, targetMargin, maxProducts 설정
- OpenAI 또는 Gemini 호출: 후보 키워드/후보 URL 리스트 생성
- Code: 응답을 배열로 정리
- Google Sheets Append: 후보 저장
- Split In Batches
- HTTP Request: 상품 정보 수집 API 호출
- Code: 응답 정규화
- IF: 금칙어/브랜드/최소 마진 필터
- OpenAI 또는 Gemini 호출: 한국어 상품명/요약 생성
- Code: 판매가 계산
- Sheets 또는 DB 저장
- HTTP Request: 마켓 등록 API 호출 또는 등록 파일 생성
이 구조는 “LLM은 판단·문장화”, “HTTP Request는 실데이터”, “Code는 계산·정규화”로 역할을 분리하는 형태라서 n8n에서 가장 덜 고장납니다.
GPT 프롬프트 예시
GPT는 후보 발굴, 제목 정제, 카테고리 매핑, 금칙어 점검 쪽에 쓰는 게 좋습니다. 실시간 가격/재고 소스 역할로 쓰면 불안정합니다.
1) 후보 상품 URL 기획 프롬프트
당신은 해외구매대행 상품 소싱 어시스턴트다.
목표는 한국 마켓에서 판매 가능한 아마존 상품 후보를 찾기 위한 검색 후보군을 만드는 것이다.
조건:
- 카테고리: 자동차용품
- 특징: 리뷰 수가 너무 적지 않고, 반복 수요 가능성이 있으며, 브랜드 인지도가 있거나 기능이 명확한 상품
- 제외: 식품, 의약외품, 위험물, 성인용품, 상표권 분쟁 가능성이 높은 상품
- 출력: JSON 배열만 출력
- 각 항목 필드: keyword_en, keyword_ko, search_intent, expected_price_band, reason
출력 예시:
[
{
"keyword_en": "...",
"keyword_ko": "...",
"search_intent": "...",
"expected_price_band": "20-50 USD",
"reason": "..."
}
]
2) 상품명 정제 프롬프트
당신은 쿠팡/네이버 업로드용 상품명 편집자다.
입력된 아마존 상품 정보를 보고 한국 마켓용 상품명을 작성하라.
규칙:
- 과장 표현 금지
- 특수문자 남용 금지
- 브랜드명 + 핵심 기능 + 사용 대상 + 수량 순서 우선
- 45자 이내 3개 버전 제안
- JSON만 출력
입력 데이터:
상품명: {{ $json.title }}
브랜드: {{ $json.brand }}
카테고리: {{ $json.category }}
핵심기능: {{ $json.features }}
수량/옵션: {{ $json.variant_summary }}
3) 판매 금지/주의 판별 프롬프트
당신은 해외구매대행 상품 검수 담당자다.
아래 상품이 한국 오픈마켓 업로드 시 주의가 필요한지 판단하라.
판단 기준:
- 의약품/건강기능식품 오인 가능성
- 인증 필요 가능성
- 위험물 가능성
- 성인용품 여부
- 유명 브랜드 상표권 분쟁 가능성
출력:
{
"risk_level": "low|medium|high",
"should_upload": true,
"reasons": ["..."],
"warning_tags": ["..."]
}
Gemini 프롬프트 예시
Gemini는 긴 입력 컨텍스트를 읽고 분류·요약하는 데 활용하기 좋으니, 상품 상세 설명 정리와 카테고리 묶음 분석에 적합합니다. 다만 n8n에서 어떤 모델을 붙이든 출력 형식은 반드시 JSON 강제형으로 설계해야 합니다.
1) 카테고리 묶음 분석 프롬프트
역할:
당신은 아마존 해외구매대행 카테고리 분석가다.
목표:
입력된 상품 후보 목록을 검토하고 한국 마켓에 등록하기 좋은 우선순위를 정한다.
평가 기준:
- 한국 소비자 이해도
- 직관적 기능성
- 계절성
- 리뷰 수/검증 가능성
- 위험도
- 예상 마진
반드시 JSON 배열만 출력하라.
필드:
asin, title, priority_score, margin_score, risk_score, upload_priority_reason
2) 상세페이지 요약 프롬프트
당신은 이커머스 상세페이지 요약 편집자다.
아마존 원문 설명을 한국 소비자가 빠르게 이해할 수 있도록 요약하라.
규칙:
- 의료 효능처럼 보이는 표현 제거
- 4개 bullet 포인트로 요약
- 각 bullet 22자 이내
- 사실 기반 표현만 사용
- JSON 출력
입력:
title: {{ $json.title }}
description: {{ $json.description }}
features: {{ $json.features }}
3) 카테고리 매핑 프롬프트
당신은 상품 카테고리 매핑 엔진이다.
입력된 상품을 아래 국내 마켓 카테고리 후보 중 하나로 매핑하라.
후보:
{{ $json.market_categories }}
상품 정보:
{{ $json.title }}
{{ $json.features }}
{{ $json.category }}
출력:
{
"best_category": "...",
"confidence": 0.0,
"reason": "..."
}
n8n 구현 팁
지금 “워크플로는 미동작”이라면, 보통 원인은 5가지입니다.
- Trigger는 되는데 다음 노드 입력 필드 매핑이 비어 있음.
- LLM 응답이 텍스트인데 다음 노드가 JSON을 기대함.
- HTTP Request 응답 구조가 배열이 아니라 객체인데 Split In Batches를 잘못 씀.
- Code 노드에서 return 형식이 n8n item 배열 형식이 아님.
- 한 플로우 안에 너무 많은 책임을 넣어 어느 단계에서 죽는지 파악이 안 됨.
특히 Code 노드는 최종적으로 보통 이런 형식으로 반환해야 다음 노드가 잘 받습니다.
return items.map(item => {
return {
json: {
...item.json,
status: "ready"
}
};
});
또한 LLM 뒤에는 거의 항상 Code 또는 Set 노드를 하나 더 둬서 응답을 강제로 정규화해야 합니다. “모델이 알아서 JSON으로 주겠지”라고 두면 다음 노드에서 자주 멈춥니다.
추천 디버깅 순서
지금은 거대한 자동화보다, 아래 순서로 하나씩 살리는 게 맞습니다.
- Manual Trigger로 시작하는 테스트 워크플로우 하나 생성.
- Set 노드에서 가짜 상품 1개 JSON 수동 입력.
- Code 노드에서 판매가 계산만 먼저 성공.
- 그다음 LLM 노드 붙여 제목 정제만 확인.
- 그다음 HTTP Request 붙여 외부 데이터 1건만 수집.
- 마지막에 Sheets 저장 또는 등록 API 연결.
이렇게 해야 어디서 깨지는지 보입니다. n8n은 “전체 설계”보다 “각 노드의 입출력 JSON 확인”이 디버깅의 핵심입니다.
원하시면 다음 답변에서 바로
1) n8n 노드별 실제 연결 순서,
2) Code 노드용 자바스크립트 예제,
3) GPT/Gemini를 넣은 실제 JSON 워크플로우 초안
형태로 더 구체화해 드리겠습니다.
