n8n으로 판매 보고서 자동화 워크플로우 설계하기

Nathan은 매주 데이터 웨어하우스에서 판매 데이터를 꺼내 상태별로 나누고, 계산하고, 팀에 알리는 일을 손으로 반복해왔다. 주문 ID, 주문 상태, 주문 금액, 담당자 이름 — 이 네 가지 정보만 있으면 되는 단순 반복 작업인데도 매주 시간을 잡아먹는다. n8n으로 이 흐름을 워크플로우 하나에 담으면 어떻게 설계해야 하는지를 정리한다.

무엇을 자동화해야 하는가

요구사항을 정리하면 여섯 단계로 나뉜다. 데이터 웨어하우스에서 주문 ID·상태·금액·담당자 이름을 가져오고, 주문 상태(Processing 또는 Booked)에 따라 데이터를 나누고, Booked 상태 주문의 총 금액을 계산하고, 그 결과를 회사 Discord 채널에 알리고, Processing 상태 주문의 세부 정보는 Airtable에 입력하고, 이 전체 과정이 매주 월요일 아침 자동으로 돌게 스케줄링한다. 외부 서비스는 Discord(팀 알림)와 Airtable(Processing 주문 관리) 두 곳과 연동해야 한다.

⤢✕

스케줄 트리거에서 시작해 데이터를 가져오고, Router로 상태별로 갈라진 뒤 각각 다른 목적지(Airtable과 Discord)로 흘러가는 구조다.

워크플로우를 구축한다

1단계, 데이터 가져오기. Schedule Trigger와 HTTP Request 노드로 시작한다. Request Method는 GET, Response Format은 JSON으로 두고 데이터 웨어하우스 API 엔드포인트에 필요한 인증 정보를 설정한다. 응답은 이런 형태다.

{
  "orders": [
    {
      "id": "ORD-001",
      "status": "Booked",
      "amount": 1500.0,
      "employee": "John Doe"
    },
    {
      "id": "ORD-002",
      "status": "Processing",
      "amount": 750.5,
      "employee": "Jane Smith"
    }
  ]
}

2단계, Airtable 삽입 준비. Airtable 노드의 Operation을 Insert로, Base ID와 Table 이름을 지정하고 저장할 필드를 매핑한다. 자격 증명 설정과 테이블 구조·필드 이름 일치 여부는 미리 확인해야 한다.

3단계, 상태별 필터링. Router 또는 IF 노드로 조건부 로직을 처리한다. Data Type은 String, Value 1은 {{$json["status"]}}, Operation은 Equal, Value 2는 "Processing" 또는 "Booked"로 설정해 두 상태를 갈라 각각 다른 후속 노드로 연결한다.

4단계, Processing 주문 필드 설정. Set 노드로 id, status, amount, employee, followup_date 등 Airtable에 맞는 필드 구조를 만든다. 현재 날짜 기준 후속 조치 날짜 같은 필드도 이 단계에서 추가한다.

5단계, Booked 주문 합계 계산. Function 노드에서 JavaScript로 처리한다.

// 모든 Booked 주문의 합계 계산
let total = 0;
for (item of items) {
  total += item.json.amount;
}

// 결과 반환
return [
  {
    json: {
      total_booked: total,
      count: items.length,
      week: new Date().toISOString().slice(0, 10),
    },
  },
];

합계, 건수, 날짜를 한 번에 요약 정보로 만든다.

6단계, 팀 알림. Discord 노드가 웹훅 URL로 포맷팅된 메시지를 보낸다. 메시지 형식은 이런 식이다.

주간 판매 보고서 (2023-06-05)
----------------------------
Booked 주문: 15건
총 금액: $12,345.67

7단계, 스케줄링. Schedule Trigger의 Trigger Interval을 Weeks, Weeks Between Triggers를 1, Trigger on Weekdays를 Monday, Trigger at Hour를 9 AM, Trigger at Minute을 0으로 맞추면 수동 개입 없이 매주 같은 시간에 보고서가 나간다.

8단계, 활성화와 검증. 전체 워크플로우를 테스트 실행하고 모든 노드의 출력을 확인한 뒤 'Active' 토글을 켠다. 활성화 전 오류 처리와 알림 메커니즘까지 점검하고, 출력이 의도한 대로 만들어지는지 검증하는 것이 마지막 단계다.

설계 시 놓치기 쉬운 기준

각 노드가 명확한 단일 기능만 수행하도록 쪼개고, 복잡한 로직은 여러 작은 단계로 나누는 모듈성을 지키면 이후 재사용이 쉬워진다. 외부 서비스 연결이 실패할 가능성을 염두에 두고 중요 지점에 오류 처리와 대체 경로를 넣는 복원력도 빠뜨리기 쉽다. 각 노드에 설명을 남기고 복잡한 함수에 주석을 다는 유지보수성, 그리고 데이터 소스나 목적지가 늘어나고 데이터양이 증가할 상황을 미리 고려하는 확장성 — 이 네 가지를 기준으로 잡으면 요구사항이 바뀌어도 워크플로우 전체를 다시 짜지 않아도 된다.

필드 이름 변경이나 구조 재구성은 Set 노드로, 복잡한 변환 로직은 Function 노드로, 중첩된 데이터는 JSON 노드로 처리한다. 조건부 처리는 단순 분기면 IF, 다중 조건이면 Router, 복잡한 로직이면 Function을 쓴다. 대량 데이터를 다룰 때는 Split In Batches로 나누고, 불필요한 데이터는 최대한 초기에 걸러내고, 반복적인 API 호출은 속도 제한을 염두에 둔다.

이 설계로 얻는 것

수동으로 하던 주당 3~4시간의 작업이 사라지고, 자동화된 계산과 데이터 처리가 사람이 만드는 오류를 줄이며, 동일한 형식과 정확한 시간에 보고서가 전달된다. 이후 Discord 외에 SMS나 모바일 앱 알림을 추가하거나, 시간 경과에 따른 판매 데이터 추세를 분석하거나, 과거 데이터 기반 판매 예측 모델을 붙이는 방향으로 확장할 수 있다.

데이터 수집·필터링·계산·알림·스케줄링이라는 패턴 자체는 판매 보고서에 국한되지 않는다. 같은 구조를 다른 반복 업무 자동화에도 그대로 옮겨 쓸 수 있다.

무엇을 자동화해야 하는가

워크플로우를 구축한다

설계 시 놓치기 쉬운 기준

이 설계로 얻는 것

함께 읽기