카페24 주문이 외부에 두 번 나가거나 빠지면 왜 막히나요?
주문을 외부 업무 시스템으로 넘기는 몰에서는 화면이 얼마나 빨리 바뀌는지보다 주문이 빠지지 않고 한 번만 전달되는지가 더 중요했습니다. 같은 주문이 두 번 넘어가면 중복 작업이 생기고, 전달에 실패한 주문을 놓치면 운영자가 뒤늦게 관리자 화면과 외부 기록을 대조해야 합니다. 이번 과제는 완전 실시간을 약속하는 일이 아니라, 주문 알림을 빠짐없이 관리하고 중복과 실패를 확인할 수 있는 전달 흐름을 만드는 일이었습니다.
이 작업은 카페24expert 채널로 의뢰됐습니다. 카페24 기본 기능이나 일반 앱만으로는 해당 몰이 사용하는 외부 형식에 맞춰 주문 내용을 바꾸고, 실패한 건을 일정한 규칙으로 다시 보내며, 이미 성공한 주문을 건너뛰는 과정까지 한 흐름으로 관리하기 어려웠습니다. 그래서 카페24가 외부 시스템으로 바로 보내게 하지 않고, 두 시스템 사이에서 전달 상태를 관리할 별도 서버가 필요했습니다.
- 주문 알림이 겹쳐도 같은 작업이 두 번 생기지 않아야 함
- 외부 시스템이 잠시 멈춰도 실패한 주문을 잃지 않아야 함
- 외부에서 요구하는 주문 항목과 형식으로 바꿔야 함
- 운영자가 주문별 성공·대기·실패 상태를 확인할 수 있어야 함
주문 웹훅을 왜 별도 서버가 받아 전달하도록 구성했나요?
웹훅은 주문이 생기거나 바뀌면 카페24가 미리 정한 서버 주소로 알려 주는 방식입니다. 이를 외부 시스템에 바로 연결하면 외부가 요구하는 인증 방식이나 주문 형식이 달라질 때 대응하기 어렵고, 중복 알림과 재시도 기록도 한곳에서 관리하기 어렵습니다. 별도 서버가 먼저 받으면 카페24 쪽 알림과 외부 전달을 분리할 수 있어, 한쪽이 잠시 멈춰도 받은 주문을 남겨 두고 다시 처리할 수 있습니다.
서버는 먼저 카페24에서 온 요청이 맞는지 약속된 확인 정보로 살펴봅니다. 확인을 통과한 요청에서는 주문번호와 변경 내용 등 필요한 정보만 골라 외부 시스템이 이해하는 형식으로 바꾼 뒤 전달합니다. 웹훅 내용만으로 상품·품목 상세가 부족한 경우에는 그때만 주문 조회 API를 이용해 필요한 내용을 보강했습니다. API 접속에 쓰는 권한값은 쇼핑몰 화면이나 고객의 브라우저에 두지 않고 서버에서만 사용했습니다.
같은 알림이 다시 들어오면 주문번호와 알림 식별 정보를 함께 확인해 이미 성공한 건은 건너뛰었습니다. 외부 시스템이 응답하지 않거나 요청을 거절하면 바로 버리지 않고 대기열에 남겨 다시 보내며, 시도 시각과 결과는 로그로 기록했습니다. 앱이 쓸 수 있는 권한 범위는 주문 조회와 해당 작업에 필요한 수준으로 줄였습니다. 결제·취소·중복 알림·외부 거절 상황을 테스트몰에서 먼저 확인한 뒤, 실몰의 권한값과 기록을 분리해 적용했습니다.
같은 주문 알림이 두 번 오면 무엇을 기준으로 건너뛰나요?
주문번호만 보고 모두 같은 건으로 판단하면 결제 뒤에 들어온 취소나 변경까지 놓칠 수 있습니다. 따라서 주문번호에 알림 식별 정보와 변경 종류를 함께 사용해 처리 단위를 나눴습니다. 해당 단위가 이미 외부 전달 성공으로 기록돼 있으면 다시 보내지 않고, 새로운 변경이라면 별도 건으로 처리했습니다. 이는 같은 알림이 두 번 와도 한 번만 처리하기 위한 장치입니다.
외부 전달이 실패하거나 결과가 불분명하면 어떻게 하나요?
외부 시스템이 잠시 멈춘 경우에는 실패 횟수와 마지막 응답을 남기고, 바로 연속 호출하지 않도록 간격을 두어 다시 보냅니다. 반복해서 실패한 건은 운영자가 확인할 수 있는 상태로 분리해야 원인 수정 뒤 다시 처리할 수 있습니다. 다만 외부에서는 주문을 받았지만 성공 응답만 돌아오지 않은 경우처럼 결과가 불분명할 수 있습니다. 이런 상황까지 고려하려면 받는 쪽도 주문번호와 알림 식별 정보를 확인해 같은 건을 다시 처리하지 않도록 맞추는 것이 좋습니다.
- 카페24 주문 웹훅을 별도 서버에서 먼저 수신하고 출처 확인
- 필요한 주문 정보만 골라 외부 시스템 형식으로 변환
- 성공한 알림은 기록을 확인해 중복 전달 차단
- 실패한 요청은 대기열·재시도·운영 로그로 관리
주문 전달을 서버에서 관리하자 운영은 무엇이 달라졌나요?
주문 알림을 받는 단계와 외부로 보내는 단계를 나누면서, 외부 시스템의 일시적인 장애가 곧바로 주문 누락으로 이어지지 않게 됐습니다. 운영자는 주문별로 전달 성공 여부와 재시도 상태를 확인할 수 있고, 이미 성공한 알림이 다시 왔을 때는 같은 작업을 반복하지 않게 됐습니다. 화면을 빠르게 갱신하는 사례와 달리, 이번 구성의 중심은 전달 기록을 남기고 실패한 주문을 다시 처리할 수 있게 만드는 것이었습니다.
주문 건수가 적고 외부 전달이 자주 필요하지 않다면 엑셀로 내려받아 확인하는 방식이 비용과 운영 면에서 더 단순할 수 있습니다. 웹훅도 네트워크나 점검 상황의 영향을 받으므로 완전한 무오차 전달을 약속할 수는 없습니다. 중요한 주문은 짧은 범위를 다시 조회해 웹훅 기록과 맞춰 보는 보완 절차를 둘 수 있으며, 자동 재시도 횟수와 운영자 확인 시점도 몰의 업무 방식에 맞춰 정해야 합니다.
- 중복 알림과 새로운 주문 변경을 구분해 처리
- 외부 장애 때 실패한 주문을 남기고 다시 전달
- 성공·대기·실패 기록을 바탕으로 운영자가 후속 조치
옴니어스24가 카페24expert에서 주문 연동을 어떻게 맡았나요?
옴니어스24는 카페24expert에 등록된 카페24 파트너이며, 이번 작업도 Expert 채널로 의뢰된 사례입니다. 카페24 API 개발에 특화해 웹훅 수신, 주문 조회, 외부 전달 사이의 역할을 나누고 왜 별도 서버가 필요한지부터 정리합니다. 접속에 쓰는 비밀값과 권한값은 쇼핑몰 화면에 두지 않고, 앱이 쓸 수 있는 권한 범위는 필요한 만큼만 설정합니다. 여기에 전달 로그와 재시도 기록을 남기고 테스트몰과 실몰의 권한값·자료를 분리해 전문적으로 안전한 진행을 지향합니다.
상담 전에는 어떤 주문 변화가 전달 대상인지, 외부 시스템이 받아야 할 주문 항목과 형식은 무엇인지, 중복으로 판단할 기준과 실패 후 운영자가 할 일을 준비하면 좋습니다. 개인 정보를 가린 주문 예시, 외부 시스템의 응답 예시, 테스트몰 사용 가능 여부도 함께 정리하면 자동 처리 범위와 수동 확인 범위를 더 분명하게 나눌 수 있습니다.
주문 웹훅 전달 사례 다음에 보면 좋은 글·페이지
주문 상태가 외부 화면에 늦게 따라오는 문제가 중심이라면 실시간 반영 사례를 먼저 볼 수 있습니다. 별도 서버가 필요한 일반적인 이유는 API·별도 서버 글에서, 조회할 수 있는 주문 정보의 범위는 주문 API 개요에서 이어서 확인할 수 있습니다. 상품 수량을 매장 시스템과 맞추는 과제라면 재고 웹훅으로 진행한 카페24expert 사례가 더 가깝습니다.
실제 의뢰를 검토할 때는 서비스 안내에서 가능한 개발 범위를 살펴보고, 카페24expert 의뢰 내용에는 전달 대상과 실패 처리 기준을 적어 두는 것이 좋습니다. 문의할 때 현재 수작업 순서, 외부 시스템이 받기를 원하는 주문 예시, 테스트 가능 여부를 함께 남기면 필요한 API 권한과 별도 서버 범위를 구체적으로 확인할 수 있습니다.