n8n 모바일결제 트래킹 — WhatsApp 모금 그룹의 M-PESA·Airtel 정산을 정규식으로 자동화하기

n8n.io에 공개된 이 템플릿을 가져오면, WhatsApp 모금 그룹에 결제 문자를 그대로 전달하는 것만으로 M-PESA·Airtel Money 송금 내역이 자동으로 집계되고, "총 얼마 모였어"라고 물으면 그 자리에서 현재까지 걷힌 금액을 돌려받을 수 있습니다.

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

면접에서 "n8n으로 텍스트 데이터도 처리해보셨어요?"라는 질문이 나오면, 이 템플릿은 구체적인 사례로 답할 수 있게 해줍니다. "모금 그룹 채팅에 올라오는 결제 문자를 정규식으로 파싱해서, 사람이 일일이 손으로 더하지 않아도 자동으로 정산되는 흐름을 만들었습니다"라고 말할 수 있습니다.

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

• 메시징 플랫폼 웹훅 연동 — Twilio 같은 외부 메시징 서비스와 왓츠앱을 연결해, 사람이 보낸 채팅 메시지를 워크플로우의 입력으로 받는 경험
• 정규식 기반 텍스트 파싱 설계 — 형식이 일정한 텍스트(SMS 영수증)에서 필요한 값만 규칙적으로 뽑아내고, 이 판단을 굳이 AI에게 맡기지 않는 설계 경험
• 조건 분기와 상태 저장 — Switch 노드로 메시지 유형을 나누고, 그 결과를 Data Table에 쌓았다가 다시 조회·합산해서 응답을 만드는 경험

이 세 가지는 모금 정산뿐 아니라 택배 배송 문자 정리, 카드 결제 알림 집계, 정형화된 알림 문자를 다루는 유형의 자동화 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Track MPESA and Airtel mobile payments in a fundraising WhatsApp group라는 이름으로 공개된 템플릿이고, 제작자는 Mabura Ze Guru입니다. 카테고리는 File Management로 등록돼 있습니다. 결제·메시징을 다루는 워크플로우치고는 다소 의외의 분류지만, n8n.io 마켓플레이스의 카테고리가 항상 내용과 정확히 맞아떨어지는 건 아니라는 정도로 이해하면 됩니다.

제작자가 설명하는 배경은 이렇습니다. 동아프리카, 특히 케냐에서는 왓츠앱 그룹을 통한 모금이 흔한 방식입니다. 참여자들이 각자 돈을 보내고 그 내역을 채팅방에 공유하면, 총무 역할을 맡은 사람이 하나하나 손으로 더해 총액을 관리합니다. 이 수작업은 품이 많이 들 뿐 아니라 실수(빠뜨리거나 중복으로 세는 일)가 생기기 쉽고, 그 실수가 참여자 간 갈등으로 번지기도 합니다. 이 템플릿은 그 수작업을 자동화 대상으로 삼습니다.

여기서 M-PESA와 Airtel Money를 잠깐 짚어두면, 두 서비스 모두 은행 계좌 없이 휴대폰 번호만으로 돈을 주고받는 동아프리카의 모바일머니 서비스입니다. 송금이 끝나면 곧바로 문자메시지(SMS)로 영수증이 오는데, 이 문자 안에 금액·보낸 사람 이름 같은 정보가 정해진 형식의 텍스트로 담깁니다. 이 템플릿은 바로 이 SMS 영수증을 재료로 씁니다. 제작자는 현재는 M-PESA와 Airtel Money 두 가지만 지원한다고 밝히고 있습니다.

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

구조 — Trigger / Task / Target

공식 페이지의 "How it works"는 번호가 매겨진 9개 문장으로 설명돼 있습니다. 이를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 재구성하면 아래와 같습니다. 카드 미리보기에는 Function, If, Merge를 포함해 총 13개 노드로 구성돼 있다고 나와 있는데, If 노드가 정확히 무엇을 검사하는지는 공식 설명에 나오지 않아 아래 다이어그램에는 반영하지 않았습니다.

• Trigger — 기본 입구는 Twilio와 연결된 Webhook으로, 왓츠앱으로 들어오는 메시지를 받습니다. 공식 설명에는 같은 흐름을 웹 채팅으로도 테스트할 수 있다고 나와 있어서, 입력 경로가 하나 더 열려 있는 구조입니다.
• Task — 정규식이 메시지를 결제 문자·합계 요청·초기화 요청·오프토픽 넷 중 하나로 분류하고, Switch 노드가 그 결과에 따라 흐름을 나눕니다. 결제 문자로 분류되면 다시 정규식으로 금액·발신자 등 필요한 값을 뽑아 Data Table("payment_table")에 저장합니다. 합계 요청이나 초기화 요청이면 저장된 데이터를 조회하거나 지우는 쪽으로 갑니다. 결제 주제를 벗어난 메시지만 Gemini 노드가 맡아 응답을 만듭니다. 이후 해당 발신자·그룹의 전체 결제 내역을 다시 불러와 합산하고, Merge 노드가 원본 메시지의 발신·수신 정보를 붙입니다.
• Target — Twilio를 거쳐 왓츠앱으로 답장(결제 확인 또는 현재까지 합계)이 돌아갑니다.

이 워크플로우에서 가장 눈여겨볼 지점은 핵심 로직인 결제 정보 추출에 AI를 전혀 쓰지 않는다는 점입니다. 문장의 의미를 폭넓게 이해해야 하는 오프토픽 메시지 처리에만 Gemini가 등장하고, 정작 금액과 발신자를 읽어내는 자리에는 정규식이 있습니다. M-PESA와 Airtel의 SMS 영수증은 통신사가 정해놓은 고정된 문자열 구조로 오기 때문에, 매번 같은 자리에 같은 형식으로 값이 들어옵니다. 이런 조건에서는 규칙 기반 파싱이 LLM 호출보다 빠르고 저렴하며, 결과도 항상 같은 방식으로 안정적으로 나옵니다. AI가 항상 정답은 아니라는 것을 이 템플릿이 설계로 보여주는 셈입니다.

만들기

이 템플릿의 공식 페이지에는 번호가 매겨진 Setup 섹션이 따로 없습니다. 대신 "How to use"라는 짧은 사용법 문단과 "Requirements" 목록이 있습니다. 아래 단계는 그 둘을 준비 순서대로 데이터팝콘이 재구성한 것이지, n8n이 원래 이렇게 번호를 매겨 안내한 건 아닙니다.

1. Twilio 계정과 왓츠앱 연결

Twilio에서 계정을 만들고 왓츠앱 메시징 기능을 연결합니다. Twilio는 문자·왓츠앱 메시지를 프로그램에서 주고받게 해주는 서비스로, 이 템플릿에서는 참여자가 보낸 결제 문자를 워크플로우로 들여오는 입구 역할을 합니다.

2. 웹훅 URL을 외부에서 접근 가능하게 열기

공식 요구사항에 "접근 가능한 webhook URL"이 명시돼 있습니다. n8n 인스턴스가 외부에서 접근 가능해야 Twilio가 왓츠앱 메시지를 실시간으로 전달할 수 있습니다. n8n cloud라면 기본으로 제공되는 webhook URL을 그대로 쓰면 되고, self-hosted 환경이라면 별도로 외부에서 접근 가능하게 열어둬야 합니다.

3. Data Table("payment_table") 준비

이 템플릿은 예시로 n8n의 Data Table 기능에 payment_table이라는 테이블을 만들어 결제 내역을 저장합니다. Data Table은 워크플로우 안에서 바로 만들고 조회할 수 있는 간단한 표 형태 저장소입니다. 다만 제작자는 실제 운영 환경에서는 SQL 노드로 바꾸는 걸 권장한다고 명시하고 있습니다. 이 예시 구성은 시연용이지 규모가 있는 운영을 그대로 감당하는 구조는 아니라는 뜻입니다.

4. Gemini 크리덴셜 연결(오프토픽 처리용)

결제와 무관한 메시지가 들어왔을 때만 호출되는 보조 노드이므로, 핵심 로직이 아니라 예외 처리용으로 Google Gemini API 크리덴셜 하나만 연결해두면 됩니다.

5. 사용법 — 결제 문자를 그대로 전달하기

설정이 끝나면 총무 역할을 맡은 사람이 할 일은 간단합니다. 참여자에게서 받은 결제 SMS 영수증을 캡처하지 않고 문자 내용 그대로 복사해, 연결된 왓츠앱 번호로 한 통씩 보내면 됩니다. 웹 채팅으로도 같은 방식으로 테스트할 수 있습니다. 이후 메시지가 들어오면 앞서 설명한 정규식 분류 → Switch 분기 → 저장 또는 조회 → 답장까지의 흐름이 자동으로 돌아갑니다.

캠페인 도중 "총 얼마 모였어?"처럼 물으면 지금까지 저장된 결제 내역을 합산한 답이 돌아오고, "캠페인 끝났으니 로그 지워줘"처럼 요청하면 payment_table의 내용이 정리됩니다. 새 모금 캠페인을 시작하기 전에 이전 캠페인의 데이터가 남아 섞이는 걸 막으려면 이 초기화 요청을 쓰면 됩니다.

주의할 점 · 제약

공식 페이지에서 확인되는 제약을 그대로 옮기면 이렇습니다.

• 수정 기능이 없습니다 — 잘못된 결제 정보가 들어가도 개별 항목을 고칠 방법이 없습니다. 실수가 생기면 전체 로그를 지우고 처음부터 다시 시작해야 합니다. 소규모 모금 그룹에서는 크게 부담이 없지만, 참여자가 많고 실수가 잦은 환경이라면 이 제약이 그대로 운영 부담이 됩니다.
• 지원하는 서비스가 두 가지로 한정돼 있습니다 — 제작자는 "현재로서는" M-PESA와 Airtel Money만 지원한다고 밝히고 있습니다. 다른 모바일머니 서비스로 넓히려면 그 서비스의 SMS 형식에 맞는 정규식 규칙을 직접 추가해야 합니다.
• Data Table은 예시용 구성입니다 — 제작자가 프로덕션 환경에는 SQL 노드로 바꾸는 걸 권장한다고 명시하고 있습니다. 참여자 수가 늘거나 여러 캠페인을 동시에 운영한다면 Data Table 그대로 쓰기보다 외부 데이터베이스로 옮기는 편이 안전합니다.
• 정규식이 SMS 형식에 맞춰져 있습니다 — 통신사가 영수증 문구 형식을 바꾸면 기존 정규식이 더 이상 맞지 않아 파싱이 실패할 수 있습니다. 규칙 기반 파싱의 안정성은 입력 형식이 일정하다는 전제 위에 있다는 점도 함께 기억해둘 부분입니다.

포트폴리오·면접 포인트

포트폴리오에는 왓츠앱에 결제 문자를 보내면 자동으로 집계되는 화면과, "총 얼마 모였어?"라는 질문에 합계가 돌아오는 화면 두 장이면 충분합니다. 실제 결제 문자 대신 형식만 맞춘 예시 텍스트를 써도 되니, 개인정보가 담긴 진짜 영수증을 그대로 캡처해 올리지 않도록 주의하면 됩니다.

면접에서는 "결제 정보를 뽑아낼 때 왜 AI를 안 쓰고 정규식을 썼을까요?"라는 질문에 이 템플릿으로 답할 수 있습니다. SMS 영수증처럼 형식이 고정된 텍스트는 매번 같은 자리에 같은 패턴으로 값이 들어오기 때문에, 비용과 지연시간이 있는 LLM 호출보다 규칙 기반 파싱이 더 빠르고 저렴하며 결과도 일관적입니다. 반면 형식을 예측할 수 없는 오프토픽 대화에는 그 유연함이 필요해서 Gemini를 예외적으로 투입한 것이라고 설명하면, "AI를 얼마나 많이 썼는지"가 아니라 "언제 AI를 쓰고 언제 안 쓰는지"를 판단할 수 있다는 인상을 줄 수 있습니다. 같은 발상은 택배 배송 알림 문자나 카드 결제 문자처럼, 국내에서도 형식이 고정된 문자 데이터를 다룰 때 그대로 응용할 수 있습니다.

다음 액션

다음 편에서는 웹사이트에 바로 심는 브랜디드 AI 챗봇 템플릿을 다룹니다. 이번 편이 "정형화된 텍스트는 정규식으로, 나머지는 AI로" 나눴다면, 다음 편은 처음부터 끝까지 AI가 대화를 맡는 구조라 이번 편과 대조해서 보면 각각의 설계가 왜 그런 선택을 했는지가 더 뚜렷하게 보입니다.