카페24 주문은 바뀌었는데 ERP·운영 화면은 왜 한참 뒤인가요?
주문이 결제·배송·취소로 바뀔 때마다 카페24 관리자 화면은 바로 바뀝니다. 그런데 ERP, 물류, 자체 운영 대시보드, 알림용 목록처럼 카페24 밖 화면은 하루 한 번 엑셀로 맞추거나, 몇 분마다 주문 목록을 다시 조회하는 방식으로 버티는 몰이 많습니다. 손님은 이미 ‘배송중’이라고 말하는데 외부 화면은 아직 ‘입금완료’로 남아 있으면, CS와 출고 판단이 어긋납니다.
카페24 기본 기능만으로는 외부 시스템에 주문 상태를 실시간으로 밀어 주지 않습니다. 앱으로 일부 알림이 되는 경우도 있지만, 우리 쪽 DB·ERP 필드·운영 규칙까지 맞는 경우는 드뭅니다. 이번 사례의 몰은 배치 조회로는 지연이 커지고, 조회를 너무 자주 돌리면 API 호출 부담과 중복 반영이 걱정이었습니다. 과제는 ‘실시간’이라는 말만 붙이는 것이 아니라, 주문 상태가 바뀌는 순간을 우리 서버가 받아 검증한 뒤 운영·외부 화면에 같은 내용으로 남기는 것이었습니다.
- 카페24 주문 상태와 외부·운영 화면이 자주 어긋남
- 배치·수작업으로는 배송·취소 CS가 늦게 따라옴
- 기본·앱만으로 우리 쪽 DB·ERP까지 맞추기 어려움
- 잦은 목록 조회는 호출 부담·중복 반영 위험
카페24 주문 상태 변경을 웹훅으로 받아 외부에 안전하게 맞출 수 있나요?
접근의 핵심은 스킨이나 브라우저에서 주문 API를 돌리지 않고, 카페24가 보내는 주문 관련 웹훅(이벤트가 생기면 우리 서버 주소로 알려 주는 방식)을 별도 서버가 받는 것이었습니다. 서버는 요청을 검증한 뒤 주문번호·상태·배송 정보처럼 필요한 값만 읽고, 우리 DB나 ERP에 ‘지금 상태’를 갱신했습니다. 웹훅만으로 세부 품목이 부족하면, 그때만 주문 상세 API를 한 번 더 조회해 보강했습니다.
같은 알림이 두 번 오거나 순서가 뒤바뀌는 경우를 대비해, 이벤트 식별자·주문번호·처리 시각을 기준으로 이미 처리한 건은 건너뛰도록 했습니다. 외부 반영이 실패하면 재시도 큐에 남기고, 운영자가 성공·실패·스킵을 화면에서 볼 수 있게 했습니다. 토큰과 웹훅 검증용 비밀값은 서버에만 두고, 권한은 주문 조회·웹훅 수신에 필요한 범위로 줄였습니다.
웹훅으로 주문 상태를 맞출 때 특히 무엇을 조심했나요?
‘실시간’을 완전 동시 일치로 약속하지 않았습니다. 웹훅은 이벤트 직후 알림에 가깝고, 네트워크 지연·재전송이 있어 초 단위 무오차는 어렵습니다. 대신 결제·배송·취소처럼 CS에 바로 영향을 주는 상태부터 반영하고, 운영 문장으로는 ‘거의 실시간에 가깝게 따라간다’고 목표를 잡았습니다. 입금 전·부분 취소·교환처럼 상태가 복잡한 구간은 규칙을 먼저 적어 두고, 1차에서는 자주 쓰는 상태 전이만 열어 검수를 짧게 잡았습니다.
웹훅이 끊기거나 서버 점검이 있을 때를 대비해, 짧은 기간의 누락 주문을 목록 조회로 메우는 보완 배치를 같이 두었습니다. 웹훅만 믿으면 장애 구간의 주문이 통째로 비고, 조회만 믿으면 지연이 커집니다. 둘을 섞되, 같은 주문을 두 번 ERP에 넣지 않도록 처리 여부를 서버에 남겨 두었습니다. 검수에서는 결제→배송→취소 순으로 바꿔 가며 외부 화면이 같은 순서로 따라오는지, 같은 웹훅을 두 번 보냈을 때 한 번만 반영되는지를 돌렸습니다.
- 주문 상태 변경 웹훅을 별도 서버가 수신·검증
- 필요 시 주문 상세 API로 품목·금액 보강
- 중복 알림은 한 번만 처리(멱등)·실패 재시도
- 누락 대비 짧은 보완 조회와 운영 로그 화면
주문 상태 어긋남 CS가 줄면 출고·응대는 어떻게 달라지나요?
카페24에서 배송·취소가 바뀌면 외부·운영 화면에도 곧이어 반영되어, 손님이 말하는 상태와 내부 목록이 크게 어긋나는 일이 줄었습니다. 출고·CS는 엑셀을 다시 받기 전에 당일 상태를 보고 움직일 수 있었고, ‘아직 안 바뀌었다’는 내부 확인 전화도 짧아지는 경우가 많습니다.
한계도 분명합니다. 카페24 기본만으로 외부에 주문 상태를 실시간 푸시하지 않으며, 웹훅은 완전 실시간이 아니라 거의 실시간에 가깝습니다. 모든 상태·모든 예외를 한 번에 맞추면 검수와 비용이 커지고, ERP 필드가 카페24와 1:1이 아니면 매핑 규칙이 먼저입니다. 재고·POS 웹훅 사례나 주문 API 개요 글과 맞닿아 있지만, 이번 사례는 주문 상태 변화를 운영·외부 화면에 빠르게 맞추는 쪽에 초점을 두었습니다. 포인트 자동 지급·알림톡 문구까지 한 번에 넣기보다, 상태 반영과 실패 재처리를 1차로 고정하는 편이 일정에 유리했습니다.
- 카페24와 외부·운영 화면의 주문 상태 지연 감소
- 중복·실패를 운영자가 추적·재처리 가능
- 이후 알림·정산 자동화로 확장 가능한 구조
옴니어스24는 이 웹훅·주문 상태 연동에서 무엇을 맡았나요?
옴니어스24는 ‘실시간으로 맞춰 주세요’만 듣고 전면 연동을 키우지 않습니다. 어떤 상태가 바뀌면 어디에 반영해야 하는지, 배치로도 되는지, 웹훅이 꼭인지부터 정리합니다. 기본·수작업·하루 한 번 조회로 버티면 그쪽을 쓰고, 지연이 CS로 바로 오면 웹훅·별도 서버·멱등·재시도 범위를 나눕니다.
비슷한 요구가 있으시면 지금 상태가 어긋나는 화면(ERP·자체 관리·알림), 최근 지연된 주문 한 건, 꼭 맞춰야 하는 상태 이름만 알려 주셔도 상담이 빨라집니다.
주문 웹훅 사례 다음에 보면 좋은 글·페이지
주문 API로 무엇을 가져오는지 보려면 주문 데이터 개요에서, 별도 서버가 왜 필요한지는 API·서버 글에서, 재고 쪽 웹훅은 품절·POS 사례에서 이어서 볼 수 있습니다. 수정 중 연동이 끊길 때 주의점은 판매 중단 여부 글도 참고하세요.
서비스·진행 방식·FAQ에서 범위를 나누는 이야기도 볼 수 있고, 문의 페이지에 현황만 남겨 주셔도 됩니다. 맞출 화면·상태·지연이 감당되는지 기준으로 안내해 드립니다.