n8n AI 재고관리 자동화 — 수요예측부터 자동 발주서, ERP·DB 이중 기록까지 뜯어보기

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 재고와 판매 속도를 주기적으로 읽어 OpenAI가 재주문 여부를 예측하고, 그중 필요한 상품만 걸러 발주서를 자동으로 만든 뒤 ERP와 데이터베이스 두 곳에 동시에 기록하는 재고관리 자동화 구조를 설계할 수 있습니다.

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

면접에서 "재고관리 자동화도 해보셨어요?"라는 질문을 받으면, 이 템플릿은 "판매 속도와 재고 흐름을 합쳐 AI에게 수요를 예측시키고, 재주문이 필요한 상품만 걸러 발주서를 자동으로 만든 다음, 같은 발주 내역을 ERP와 데이터베이스 양쪽에 남기도록 설계했습니다"라고 답할 재료를 줍니다.

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

• AI 수요예측 설계 — 숫자 데이터를 모델에 넣어 자유 텍스트가 아니라 점수·판단·신뢰도 같은 정형화된 판단 결과를 받아본 경험
• 조건 필터링으로 낭비 줄이기 — 전체 데이터가 아니라 실제로 조치가 필요한 항목만 뒤로 넘겨 이후 단계(문서 생성·API 호출)의 낭비를 없앤 경험
• 문서 자동 생성 — 판단 결과를 사람이 실제로 쓰는 발주서 형태(수량·공급사·총액)로 조립해본 경험
• 이중 기록 설계 — 같은 이벤트를 운영 시스템과 분석용 저장소 양쪽에 서로 다른 목적으로 남겨본 경험

이 네 가지는 재고관리뿐 아니라 영업 리드 우선순위 매기기, 이상 거래 탐지, 예산 집행 승인처럼 "판단 → 걸러내기 → 문서화 → 기록"으로 이어지는 업무 자동화 전반에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 AI-driven inventory management with OpenAI forecasting & ERP integration라는 이름으로 공개된 템플릿이고, 제작자는 자동화 에이전시 Oneclick AI Squad입니다. 카테고리는 Document Extraction과 AI Summarization으로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 창고 재고와 판매 속도를 모니터링해 수요를 예측하고, 발주서를 자동으로 만들어 공급사에 전달한 다음, 거래 내역을 ERP와 데이터베이스 시스템에 기록하는 워크플로우입니다. 제작자는 소매·유통, 제조업, 제약, FMCG·공급망, 자동차·전자 업종에 이 구조가 맞는다고 소개합니다. 공식 페이지 끝에는 제작사에 문의해 맞춤 자동화를 만들라는 영업성 안내도 붙어 있는데, 이 글은 그 부분을 다루지 않고 워크플로우의 설계 구조만 정리합니다.

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

다만 미리 짚어둘 게 있습니다. 이전 템플릿들은 구글시트나 슬랙처럼 계정만 있으면 바로 붙일 수 있는 무료 도구로 재현이 가능했지만, 이 템플릿은 창고 재고 시스템, 판매 데이터 시스템, 공급사 API, 실제 ERP(SAP·Oracle·Netsuite)까지 네 개의 외부 시스템이 이미 있다는 전제 위에 서 있습니다. 개인이 이 시스템들을 처음부터 갖춰 그대로 재현하기는 현실적으로 어려워서, 이 글은 "직접 실습"보다 "판단 순서를 배우는 설계 학습용"으로 읽는 편을 권합니다.

구조 — Trigger / Task / Target

공식 문서의 워크플로우 프로세스를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — Schedule Trigger가 정해진 주기(공식 문서 기본값은 6시간, 조정 가능)마다 실행되며 시작됩니다.
• Task — 재고 데이터와 판매 속도를 각각 가져와 하나의 JSON으로 합친 뒤 OpenAI GPT에 보내 수요를 예측합니다. 응답을 파싱해 수요점수·재주문 필요 여부·신뢰도를 추출하고, 재주문이 필요하다고 표시된 항목만 남겨 발주서(품목·수량·공급사·총비용)를 만들고 공급사 API로 전송합니다.
• Target — 확정된 발주 내역은 ERP(SAP/Oracle/Netsuite)와 별도 SQL 데이터베이스(Postgres/MySQL) 두 곳에 동시에 기록되고, 발주 ID·공급사·비용·예측 근거가 담긴 요약 메일이 발송됩니다.

공식 템플릿 카드의 노드 미리보기에는 Send Email, HTTP Request, Postgres 노드가 포함돼 있고 그 외 5개가 더 있다고 표시됩니다. 전체 구조는 12단계로 설명되는데, 전부 나열하면 지루한 나열이 되니 설계 의도가 가장 뚜렷한 네 가지 — AI 수요예측, 재주문 필터링, 자동 발주서 생성, ERP·DB 이중 기록 — 만 깊이 봅니다.

AI 수요예측 — 숫자를 합쳐서 판단으로 바꾼다

공식 문서에 따르면 이 단계는 재고 데이터와 판매 속도 데이터를 각각 가져와 하나의 JSON으로 합친 다음, 그 통합 데이터를 OpenAI GPT에 보내 수요를 예측하게 합니다. 모델은 자유 텍스트 설명이 아니라 수요점수, 재주문 필요 여부, 신뢰도(confidence level)라는 세 가지 정형 값을 돌려주도록 설계돼 있습니다.

이 구조의 핵심은 "예측"과 "판단"을 분리하지 않고 한 번의 모델 호출에 같이 담았다는 점입니다. 수요가 얼마나 될지와 그래서 재주문이 필요한지를 모델이 함께 답하게 하면, 다음 단계는 그 답을 다시 해석할 필요 없이 곧바로 걸러내는 일만 하면 됩니다.

재주문 필터링 — 모델의 답을 그대로 믿지 않고 한 번 더 거른다

AI 응답을 곧장 다음 단계로 넘기지 않고, 먼저 응답을 파싱해 원래 재고 데이터셋과 다시 결합하는 단계를 거칩니다. 그런 다음에야 재주문이 필요하다고 표시된 항목만 골라내는 필터링 단계(공식 표현으로 Filter: Reorder Needed)를 통과시킵니다.

n8n의 필터링 계열 노드는 조건에 맞는 항목이 하나도 없으면 뒤 단계를 실행하지 않고 조용히 끝나는 성질을 갖습니다. 이 템플릿에 그대로 적용하면, 재주문할 상품이 하나도 없는 주기에는 발주서도 만들어지지 않고 알림 메일도 나가지 않는다는 뜻입니다. 재고가 전부 넉넉한 사이클에 빈 발주서가 만들어지지 않는 건 이 성질 덕분입니다.

자동 발주서 생성 — 만들고 끝이 아니라 응답까지 확인한다

필터를 통과한 항목만으로 발주서를 만듭니다. 품목 상세, 수량, 공급사 정보를 담고 총비용까지 계산하는 문서 생성 단계입니다. 이어서 이 발주서를 공급사 API 엔드포인트로 전송하는데, 공식 문서는 이 단계에서 성공·실패 응답을 검증한다고 명시합니다.

전송하고 끝내는 게 아니라 응답을 확인하는 이 한 단계가 중요합니다. 공급사 API가 오류를 돌려줬는데도 확인 없이 다음 단계(ERP 기록)로 넘어가면, 실제로는 전달되지 않은 발주가 시스템에는 "정상 처리"로 남는 불일치가 생깁니다. 응답 검증은 이 불일치를 막는 최소한의 안전장치입니다.

ERP·DB 이중 기록 — 같은 이벤트를 서로 다른 목적으로 두 번 남긴다

확정된 발주서는 두 곳에 나뉘어 기록됩니다. 하나는 ERP(SAP·Oracle·Netsuite 중 사용 중인 시스템)로, 발주 내역과 예측 지표를 타임스탬프와 함께 남깁니다. 다른 하나는 PostgreSQL이나 MySQL 같은 SQL 데이터베이스로, 발주 데이터·공급사 응답·AI 예측 지표를 감사(audit)와 분석용으로 저장합니다. 마지막으로 발주 ID, 공급사, 비용, 예측 근거를 담은 요약 메일이 발송되며 한 사이클이 끝납니다.

두 저장소의 역할이 다릅니다. ERP는 회사의 실제 운영 시스템이 인정하는 "정본" 기록이고, SQL 데이터베이스는 그 정본을 매번 ERP에서 다시 조회하지 않고도 예측 정확도나 발주 패턴을 분석할 수 있게 해주는 별도 사본입니다. 같은 사실을 두 번 쓰는 게 중복이 아니라, 운영과 분석이라는 서로 다른 목적에 맞게 나눠 쓴 설계입니다.

만들기

공식 Setup 안내를 따라가되, 앞서 말한 대로 그런 시스템이 없다면 아래 단계는 "실행할 절차"가 아니라 "각 단계가 왜 필요한지 이해하는 자료"로 읽으면 됩니다.

1. 실행 주기 정하기

Schedule Trigger의 간격을 정합니다. 공식 문서는 6시간 또는 하루 단위로 조정 가능하다고 안내합니다. 간격이 조밀할수록 뒤의 OpenAI 호출도 그만큼 잦아져 비용이 늘어나므로, 재고 회전이 그렇게 빠르지 않다면 넉넉하게 잡는 편이 안전합니다.

2. 재고·판매·공급사 시스템 연결

재고, 판매, 공급사 각 단계의 노드에 API 크리덴셜을 넣습니다. 시스템마다 인증 방식(Authorization 헤더 또는 API 키)이 다를 수 있다고 공식 문서는 안내합니다. 템플릿에는 실제 엔드포인트 대신 자리표시(placeholder) URL이 들어 있어서, 실제로 쓰려는 시스템의 진짜 주소로 바꿔야 동작합니다.

3. OpenAI 크리덴셜 연결과 프롬프트 조정

OpenAI API 키를 연결합니다. 계절성이나 프로모션처럼 예측에 추가로 반영하고 싶은 요소가 있으면 프롬프트를 직접 수정하라고 안내돼 있습니다.

4. ERP 엔드포인트를 실제 값으로 교체

ERP 기록 단계의 placeholder URL을 실제 SAP·Oracle·Netsuite 엔드포인트로 바꾸고, 발주번호·날짜·비용 같은 필드가 그 시스템의 스키마와 맞는지 확인합니다.

5. 데이터베이스 연결과 테이블 준비

PostgreSQL 또는 MySQL 크리덴셜을 연결하고, purchase_orders 테이블이 미리 존재해야 합니다. 정확한 컬럼 구성은 캔버스의 스티키 노트에 스키마로 안내돼 있다고만 공식 문서에 적혀 있어서, 이 글이 가진 소스에는 세부 컬럼 목록까지는 나오지 않습니다. 실제로 쓰려면 n8n 캔버스를 열어 스티키 노트를 직접 확인해야 합니다.

6. 이메일 알림 설정

SMTP 크리덴셜(Gmail, Outlook 또는 그 외 커스텀 서버)을 연결하고, 발주 완료 요약을 받을 수신자를 워크플로우 알림 설정에 등록합니다.

주의할 점 · 제약

공식 문서와 준비물(Prerequisites) 항목에 적힌 제약 중 실제로 부딪히기 쉬운 것들을 추립니다.

• 실제 ERP 연동이 필요합니다 — placeholder URL을 실제 SAP·Oracle·Netsuite 엔드포인트로 바꾸는 게 전제이므로, 이런 시스템에 접근 권한이 없으면 ERP 기록 단계는 그대로 동작하지 않습니다. 이 시리즈의 다른 템플릿보다 혼자 재현하기 어려운 이유가 여기에 있습니다.
• 네 개의 외부 API가 전부 placeholder 상태입니다 — 재고, 판매, 공급사, ERP 네 시스템 모두 실제 엔드포인트로 교체해야 하는데, 공식 문서에는 각 시스템의 요청·응답 형식까지는 나와 있지 않습니다.
• 데이터베이스 스키마가 캔버스 안에만 있습니다 — purchase_orders 테이블의 정확한 컬럼은 스티키 노트에 있다고 안내될 뿐, 이 글이 근거로 삼은 공식 페이지 텍스트에는 실려 있지 않습니다.
• OpenAI 호출 비용이 실행 주기에 비례합니다 — 스케줄이 촘촘할수록 예측 호출도 잦아지므로, 조정 가능한 값은 사실상 실행 간격 하나입니다.
• 필요한 준비물이 많습니다 — 공식 문서는 재고·판매·공급사·ERP 시스템 접근 권한, 유효한 OpenAI API 키, SQL 데이터베이스, SMTP 크리덴셜, 그리고 HTTP·AI·Filter·Email·Database 노드를 다루는 n8n 인스턴스를 전제 조건으로 명시합니다.

포트폴리오·면접 포인트

실제 ERP 계정이 없어도 이 구조를 포트폴리오에 담을 방법은 있습니다. ERP 기록 단계를 구글시트 같은 무료 도구로 바꿔치기하고, "ERP·DB 이중 기록"이라는 설계 의도(운영용 정본과 분석용 사본을 분리한다)만 그대로 재현하면 됩니다. 실물 시스템이 없어도 왜 두 곳에 나눠 기록하는지 설명할 수 있으면 충분합니다.

공식 문서의 응용 아이디어(Modification Options) 중에는 발주서를 공급사에 보내기 전에 사람이 승인하는 단계를 추가하는 방법도 나와 있습니다. 지금 구조는 조건을 통과하면 바로 발주까지 자동으로 넘어가는데, 여기에 승인 단계 하나를 끼워 넣으면 "완전 자동화"와 "사람이 최종 확인하는 반자동화" 사이의 트레이드오프를 직접 설계해본 경험이 됩니다.

면접에서는 "왜 ERP랑 DB에 똑같은 내용을 두 번 기록했나요?"라는 질문이 나올 수 있습니다. "ERP는 회사가 인정하는 운영상의 정본이고, DB는 그 정본을 매번 조회하지 않고도 예측 정확도나 발주 패턴을 분석할 수 있게 만든 별도 사본이라 목적이 다르다"고 답할 수 있으면, 템플릿을 그대로 베낀 사람과 구조를 이해한 사람이 갈립니다.

다음 액션

다음 편에서는 AI의 판단 없이 정규식만으로 특정 메시지를 걸러내는, 훨씬 가벼운 자동화 패턴을 다룹니다. 이번 편이 "숫자를 모델에 넣어 판단을 만들어내는" 쪽이었다면, 다음 편은 "이미 정해진 형식의 메시지를 규칙으로 정확히 잡아내는" 정반대 접근입니다. 두 편을 같이 보면 언제 AI를 쓰고 언제 규칙만으로 충분한지 판단하는 기준이 생깁니다.