Zapier, Make, n8n으로 Open Badges 자동화하기 (노코드 레시피)

트레이닝 프로그램, 유료 코스, 등급이 나뉜 이메일 리스트를 운영하고 있다면, 누군가 과정을 완료하거나 구매하거나 자격을 충족하는 순간은 대개 어딘가에 이미 기록되어 있어요 — 폼 응답, Stripe 결제, Mailchimp 태그 같은 것들이죠. 배지는 그 이벤트에 따라 자동으로 발급되는 게 당연해 보이지만, 실제로는 거의 그렇게 되지 않아요. 대부분의 도구에서 “크레덴셜 발급”은 기본 액션이 아니고, 일회성 자동화를 위해 커스텀 웹훅 수신 서버를 만드는 건 지나친 일이거든요.

바로 이럴 때 Zapier, Make, n8n이 필요해요. 세 플랫폼 모두 Badges Ninja API를 직접 호출할 수 있어요 — 플러그인도, 미들웨어 서버도, 코드 배포도 필요 없어요. 아래는 오늘 바로 복사해서 쓸 수 있는 실제 작동 레시피 세 가지와, 배지가 조용히 발급 실패하지 않도록 제대로 처리해야 할 API 키 관리 및 오류 재시도 동작이에요.

무엇을 연결하는 건가요

모든 레시피는 같은 구조를 따라요. 트리거 → (선택) 수신자 조회 → /awards로 HTTP POST. /awards 엔드포인트가 실제로 수신자에게 배지를 발급하는 곳이에요 — 기존 badgeId를 지정하면 자체 검증 URL, QR 코드, PDF 인증서를 가진 고유하고 검증 가능한 수여 기록이 생성돼요. 아직 배지를 만들지 않았다면 API 퀵스타트를 참고하세요. 이 자동화들을 실행하려면 먼저 배지 ID가 필요해요.

세 플랫폼 모두 인증 방식은 동일해요. 대시보드에서 생성한 키를 담은 X-Api-Key 헤더를 사용해요. 자동화 플랫폼은 임의의 REST API에 대한 OAuth 흐름을 잘 처리하지 못하기 때문에, 여기서는 API 키가 적합한 선택이에요 — 장기간 유효하고, 계정에 범위가 지정되며, Zap이 오작동할 경우 클릭 한 번으로 취소할 수 있어요.

먼저 API 키를 만드세요

대시보드에서 설정 → API 키를 열고 키 생성을 클릭한 다음, 용도를 알 수 있는 이름을 붙이세요 — key1이 아니라 zapier-course-completions 같은 식으로요. 이 이름 짓기는 보기보다 중요해요. 6개월 뒤 어떤 자동화가 오작동할 때, 우연히 같은 키를 공유하는 다른 세 개의 연동을 망가뜨리지 않고 그 키만 취소하고 싶을 테니까요.

키는 생성 직후 한 번만 전체가 표시돼요. 즉시 자동화 플랫폼의 안전한 자격 증명 저장소로 복사하세요 — Zapier의 “Connection”, Make의 “Connection”, 또는 n8n의 credential에요. Zap/시나리오/워크플로 안의 일반 텍스트 필드에는 절대 넣지 마세요.

레시피 1: Typeform → Badges Ninja (코호트 완료 폼)

사용 사례: 코호트가 과정을 마치고 짧은 “완료했어요” 폼을 작성하는 경우예요 (또는 자기 주도형 트랙의 마지막 단계로 폼을 보내는 경우도 해당돼요).

Zapier에서:

1. 트리거: Typeform — New Entry, 완료 폼으로 범위를 한정해요.
2. 액션: Webhooks by Zapier — POST.
3. URL: https://api.badges.ninja/awards
4. 헤더: X-Api-Key: bws_<your key>, Content-Type: application/json
5. 데이터 (Typeform 필드에서 매핑):

{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

이게 Zap의 전부예요. 폼이 실제 완료 시에만 실행된다면 Filter 단계는 필요 없어요 — 하지만 일반 문의 폼이라면, 웹훅이 실행되기 전에 숨겨진 필드나 응답 값을 확인하는 Filter by Zapier 단계를 추가해서 스팸이나 테스트 제출로 배지가 발급되지 않도록 하세요.

레시피 2: Stripe → Badges Ninja (구매 = 크레덴셜)

사용 사례: 유료 인증 시험, 프리미엄 코스 등급, 또는 배지가 구매 항목의 일부인 멤버십 플랜이에요.

Zapier에서:

1. 트리거: Stripe — New Charge (구독의 경우 New Invoice Payment Succeeded).
2. 필터: 결제 금액이 크레덴셜이 부여되는 상품의 정확한 가격과 일치하는지 확인해요 — Stripe 계정이 하나의 웹훅으로 여러 상품을 처리한다면 이 부분이 중요해요.
3. 액션: Webhooks by Zapier — POST를 https://api.badges.ninja/awards로, 헤더는 위와 동일해요.
4. 데이터: charge.billing_details.email과 charge.billing_details.name을 recipient.email / recipient.name에 매핑해요.

발급을 결제 이벤트와 연결하는 것의 좋은 점은, 자연스럽게 멱등성에 가까워진다는 거예요. Stripe 결제 ID는 고유하니까, 웹훅 재시도로 Zap이 다시 실행될까 걱정된다면 /awards를 호출하기 전에 해당 결제 ID를 이미 처리했는지 확인하는 Storage by Zapier 단계를 추가하세요.

레시피 3: Mailchimp 태그 → Badges Ninja

사용 사례: 구독자가 마일스톤에 도달했을 때 — 웨비나 참석, 드립 시퀀스 완료, 세 명 추천 등 — 수동으로 (또는 다른 자동화를 통해) 태그를 붙이고, API를 직접 다루지 않고도 그 태그가 배지 발급을 트리거하게 하고 싶은 경우예요.

Zapier에서:

1. 트리거: Mailchimp — New Tag Added to Subscriber, 특정 태그(예: webinar-attended)로 필터링해요.
2. 액션: Webhooks by Zapier — POST를 https://api.badges.ninja/awards로.
3. 데이터: subscriber.email_address와 subscriber.merge_fields.FNAME + LNAME을 수신자 필드에 매핑해요.

이 패턴은 세일즈 SPIFF, 커뮤니티 마일스톤, 이벤트 참석 같은 인정 프로그램에서 인기가 많아요. 팀 내 누군가가 이미 연락처에 태그를 붙이는 습관을 갖고 있고, 그 습관에서 배지가 자연스럽게 따라 나오길 원하는 경우죠.

오류와 재시도 처리하기

자동화 플랫폼은 배지 데이터에 대해 트랜잭션을 보장하지 않으므로, 진짜 통합에 기대하는 것과 같은 수준의 규율을 갖춰야 해요.

• 응답 코드를 확인하세요. 200은 수여가 생성됐다는 뜻이고, 4xx는 대개 잘못된 badgeId나 형식이 틀린 이메일을 의미해요 — 이건 Zap의 설정 오류이지, 무작정 재시도할 일이 아니에요. 5xx는 재시도해도 안전해요.
• Zapier: 실패한 Zap 실행은 전체 요청/응답과 함께 Zap History에 남아요. 일시적인 실패에는 Auto-Replay를 켜두되, 반복되는 실패에는 이메일/Slack 알림을 설정해서 조용히 고장 난 Zap이 석 달치 배지 누락으로 이어지지 않게 하세요.
• Make: 시나리오는 네이티브 Error Handler 경로를 지원해요 — HTTP 모듈에 Resume 또는 Rollback 지시자를 붙이고, 지속되는 실패는 그냥 버리지 말고 알림 모듈로 라우팅하세요.
• n8n: 셀프 호스팅이든 클라우드든 더 세밀한 제어가 가능하니, HTTP Request 노드를 Error Trigger 워크플로로 감싸고, 실패한 페이로드를 가벼운 대체 저장소(Airtable, Google Sheets)에 기록해서 나중에 수동으로 재실행할 수 있게 고려해보세요.

세 플랫폼 모두에서, “초록불로 실행됐으니 성공했겠지”라는 함정을 피하세요. 잘못 설정된 웹훅 단계(잘못된 URL, 헤더 누락)에서 나온 200처럼 보이는 응답도 Badges Ninja 쪽에서는 실패할 수 있어요. 새 자동화를 도입한 첫 달에는 매주 대시보드의 수여 목록을 확인해보세요.

Make.com 대응 방법

Make의 비주얼 시나리오 빌더는 위의 Zapier 단계와 거의 그대로 대응돼요.

1. 트리거 모듈 — Typeform / Stripe / Mailchimp 감시 모듈, Zapier 트리거와 동일해요.
2. HTTP → Make a Request 모듈 — 메서드는 POST, URL은 https://api.badges.ninja/awards, Headers 테이블에서 헤더 설정 (X-Api-Key, Content-Type: application/json), 본문은 트리거에서 매핑한 변수를 담은 raw JSON이에요.
3. Stripe 금액 확인이나 Typeform의 “실제 완료” 검증을 위해 모듈 사이에 선택적으로 Filter를 넣어요.

Make의 장점은 가시성이에요 — 시나리오 에디터가 각 단계의 실제 JSON 페이로드를 켜기 전에 보여주기 때문에, Zapier의 더 선형적인 단계별 테스트 뷰보다 잘못된 필드 매핑을 디버깅하기가 훨씬 빨라요.

n8n 대응 방법

셀프 호스팅으로 운영하고 싶거나, 이미 스택의 다른 부분을 n8n으로 자동화하고 있다면 n8n이 가장 잘 맞아요.

1. 트리거 노드 — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (모두 내장 노드예요).
2. HTTP Request 노드 — 메서드는 POST, URL은 https://api.badges.ninja/awards, 인증은 Header Auth로 설정하고 X-Api-Key는 노드에 하드코딩하지 않고 n8n credential로 저장해요. JSON 본문은 트리거 노드의 출력을 참조하는 표현식으로 구성해요.
3. IF 노드 (선택) — 위와 같은 완료/금액 검증을 HTTP Request 노드 앞에 배치해요.

n8n의 credential은 암호화되어 있고 여러 워크플로에서 재사용할 수 있으므로, Badges Ninja 자동화를 두 개 이상 계획하고 있다면 이 방식이 더 깔끔해요. credential을 한 번 설정하면 배지 발급이 필요한 모든 워크플로에서 재사용할 수 있어요.

네이티브 앱 대신 범용 웹훅 단계를 쓰는 이유

Zapier, Make, n8n 모두 앱 마켓플레이스가 있고, 범용 HTTP/웹훅 모듈보다 먼저 “Badges Ninja” 앱을 검색하고 싶은 게 본능이에요. 그 검색은 건너뛰세요 — 이 정도로 작은 REST API(발급자 생성, 배지 생성, 수여 생성, 그게 다예요)라면, 범용 웹훅 단계로 10분 안에 라이브로 돌릴 수 있고, 서드파티 앱 관리자가 API 변경 속도를 따라잡는지에 의존할 필요도 없어요. 전용 앱은 필요 없는 추상화 레이어를 하나 더 추가할 뿐이에요 — 결국 같은 badgeId, recipient.email, recipient.name 필드를, JSON 본문 대신 폼을 통해 채우게 될 뿐이니까요. API 레퍼런스는 5분이면 다 읽을 만큼 짧고, 한번 읽고 나면 원시 HTTP 방식이 실제로 덜 취약하다는 걸 알게 될 거예요 — Badges Ninja API 변경과 여러분의 자동화가 계속 작동하는 것 사이에 앱스토어 승인 절차가 끼어들 일이 없으니까요.

실서비스로 전환하기 전에 테스트하세요

위의 모든 플랫폼은 실제 트리거 이벤트를 기다리지 않고 단일 테스트를 실행할 방법을 제공해요.

• Zapier — 트리거 단계에서 “Test”로 샘플 레코드를 가져온 다음, 웹훅 액션에서 “Test”로 실제 요청을 딱 한 번 실행해요. Zap을 켜기 전에 대시보드에 수여 기록이 나타나는지 확인하세요.
• Make — 샘플 번들로 시나리오를 수동으로 한 번 실행하고(“Run once” 버튼), HTTP 모듈의 출력 버블에서 실제 응답 본문을 확인해요.
• n8n — HTTP Request 노드에서 테스트 입력 데이터로 “Execute Node”를 사용하면 에디터 안에서 요청과 응답을 바로 볼 수 있어요.

첫 테스트 실행에서 확인할 가치가 있는 두 가지가 있어요. 하드코딩한 badgeId가 실제로 여러분이 생각하는 그 배지가 맞는지(중복된 Zap의 오래된 ID가 흔한 실수예요), 그리고 수신자 이메일 필드가 실제 주소를 가져오고 있는지, 매핑 오타 때문에 {{email}} 같은 자리표시자가 해석되지 않은 채 남아있지는 않은지예요. 두 실수 모두 자동화 플랫폼의 “성공” 표시에서는 보이지 않아요 — HTTP 호출은 어느 쪽이든 200을 반환하니까요 — 그래서 유일하게 믿을 만한 확인 방법은 대시보드에서 수여 기록을 열어 수신자가 예상한 사람인지 확인하는 거예요.

배지 중복 발급 방지하기

위의 모든 트리거 소스는 실제 환경에서 같은 이벤트에 대해 한 번 이상 실행될 수 있어요 — Stripe는 타임아웃 시 웹훅을 재시도하고, Typeform은 연결이 느릴 때 중복 제출될 수 있고, Mailchimp 자동화는 태그가 제거됐다가 다시 추가되면 재실행될 수 있어요. 배지 발급이 멱등하지 않다면, 수신자가 같은 크레덴셜을 두 번 받게 되는 상황이 생기고, 이는 허술해 보이고 고객 지원 문의로 이어져요.

가장 깔끔한 방어책은 생성 전 조회 단계예요. /awards POST 전에 Search 액션(Zapier라면 GET 요청을 통한 “Find Award”, 또는 Make/n8n의 동등한 HTTP GET)을 추가해서 자체 수여 기록을 조회하세요 — API를 직접 조회하고 싶지 않다면, 같은 Zap이 성공적인 수여 직후에 기록하는 가벼운 구글 시트나 Airtable 로그로도 충분해요. 해당 수신자 + 배지 조합의 기록이 이미 존재한다면, 다시 발급하는 대신 아무 작업도 하지 않는 분기로 넘어가세요. 5분이면 추가할 수 있는 이 작업이, 믿고 맡길 수 있는 자동화와 계속 지켜봐야 하는 자동화의 차이를 만들어요.

노코드로는 부족할 때

이 레시피들은 단일 이벤트 트리거를 잘 처리해요. 하지만 하나의 CSV 내보내기에서 수백 개의 배지를 발급하게 되면 — 코호트 전체 졸업, 컨퍼런스 참석자 명단, 대량 CE 학점 갱신 같은 경우 — 자동화 플랫폼은 건너뛰고 대량 배지 업로드를 직접 사용하세요. 배치 도중에 일시 정지하고 재개할 수 있고 브라우저 탭을 닫아도 유지되는데, 이건 노코드 웹훅 루프가 대량 처리에서 우아하게 다루지 못하는 부분이에요.

---

첫 검증 가능한 크레덴셜을 발급할 준비가 되셨나요? badges.ninja에서 무료로 시작하기 — 비주얼 디자이너, 공개 검증 페이지, PDF 인증서, Open Badge v2.0 출력. 신용카드가 필요 없어요.