카페24 쇼핑몰과 3PL 물류대행·송장을 자동 연동한 사례

쇼핑몰 주문량이 늘어나면 주문을 물류대행업체(3PL)에 전달하고, 출고 후 송장번호를 다시 쇼핑몰에 입력하는 작업이 큰 부담이 될 수 있습니다.

처음에는 엑셀로 주문을 내려받아 물류업체에 전달하고, 출고가 끝나면 송장번호를 다시 쇼핑몰 관리자에 입력하는 방식으로 운영할 수 있습니다.

하지만 주문량이 많아지면 문제가 생깁니다.

이번 사례에서는 카페24 쇼핑몰의 주문을 3PL 물류대행업체로 자동 전달하고, 출고 후 발급된 송장번호를 다시 카페24 주문에 자동으로 등록하는 시스템을 구축했습니다.

카페24 쇼핑몰과 3PL을 연동하면 다음과 같은 업무를 자동화할 수 있습니다.

다만 3PL 업체마다 API와 주문 전달 방식이 다르기 때문에 실제 사용하는 물류업체의 연동 방식부터 확인하는 것이 중요합니다.

3PL은 쇼핑몰 대신 상품의 보관, 포장, 출고, 배송 등의 물류 업무를 처리하는 제3자 물류대행 서비스입니다.

쇼핑몰에서 주문이 발생하면 쇼핑몰 운영자가 직접 상품을 포장하는 대신 3PL 물류센터에서 상품을 출고합니다.

일반적인 흐름은 다음과 같습니다.

고객 주문 → 카페24 주문 발생 → 3PL에 출고 요청 → 상품 포장·출고 → 송장 발급 → 카페24 주문에 송장 등록

이 과정에서 사람이 엑셀을 다운로드하고 다시 업로드하거나 송장번호를 직접 입력하면 주문량이 많아질수록 관리가 어려워집니다.

가능합니다.

다만 단순히 카페24 스킨을 수정하는 방식보다는 카페24와 3PL 사이에서 주문 데이터를 전달하는 별도의 연동 시스템을 사용하는 경우가 많습니다.

예를 들어 고객이 상품을 결제하면 연동 서버가 해당 주문을 확인합니다.

그 후 필요한 정보를 3PL에서 사용하는 형식으로 변환해서 전달합니다.

예를 들어 다음과 같은 정보가 전달될 수 있습니다.

카페24에서 사용하는 주문 데이터와 3PL에서 요구하는 데이터 형식이 다를 수 있기 때문에 중간에서 데이터를 변환하는 과정이 필요합니다.

카페24 쇼핑몰 화면에서 3PL API를 직접 호출하는 방식은 보안과 안정성 측면에서 적합하지 않은 경우가 많습니다.

특히 API 인증정보나 토큰 같은 중요한 정보를 고객이 보는 브라우저에 노출해서는 안 됩니다.

따라서 일반적으로는 다음과 같은 구조를 사용합니다.

카페24 → 연동 서버 → 3PL

연동 서버가 카페24 주문을 확인하고 3PL에서 요구하는 형식으로 변환한 뒤 전송합니다.

반대로 출고 후 송장번호를 받을 때는 다음과 같은 구조가 됩니다.

3PL → 연동 서버 → 카페24

이렇게 하면 카페24와 3PL 사이의 데이터를 안전하게 중계하면서 전송 결과와 오류도 관리할 수 있습니다.

3PL 연동에서 매우 중요한 부분입니다.

예를 들어 연동 프로그램이 같은 주문을 두 번 확인하면 동일한 주문이 3PL에 두 번 전달될 수 있습니다.

이 문제가 실제 출고로 이어지면 중복 출고가 발생할 수 있습니다.

그래서 연동 서버에 이미 전송한 주문인지 확인하는 기록을 남깁니다.

예를 들어,

주문번호 202609160001 → 3PL 전송 완료

와 같이 기록합니다.

같은 주문이 다시 들어오면 이미 전송한 주문인지 확인하고 다시 보내지 않도록 처리합니다.

이러한 방식을 일반적으로 중복 처리 방지 또는 멱등 처리라고 합니다.

복잡하게 생각할 필요 없이, 핵심은 같은 주문을 여러 번 받아도 실제 출고 요청은 한 번만 발생하도록 만드는 것입니다.

주문 연동에서는 취소 시점도 중요합니다.

예를 들어 고객이 오후 2시에 주문을 취소했는데, 이미 오전에 3PL로 출고 요청이 전달되었을 수 있습니다.

이 경우 쇼핑몰에서는 취소되었지만 물류센터에서는 출고 준비가 진행되고 있을 수 있습니다.

따라서 주문 상태만 확인하는 것이 아니라 현재 물류 진행 단계를 함께 관리해야 합니다.

예를 들어 다음과 같이 구분할 수 있습니다.

카페24 주문 → 3PL 전송 전 → 3PL 전송 완료 → 출고 준비 → 출고 완료 → 송장 발급

출고 요청 전에 취소된 주문이라면 3PL로 보내지 않습니다.

이미 3PL에 전달된 이후라면 물류업체의 취소 API가 있는지 확인하고, 취소 가능한 단계인지 판단해야 합니다.

이미 출고된 이후라면 자동 취소가 아니라 반품이나 회수 절차가 필요할 수 있습니다.

따라서 취소를 어디까지 자동 처리할 것인지를 개발 전에 정하는 것이 중요합니다.

가능합니다.

3PL에서 상품이 출고되면 물류 시스템에서 송장번호가 발급됩니다.

연동 시스템은 이 송장번호를 받아 카페24의 해당 주문에 배송정보를 등록합니다.

예를 들어,

주문번호 202609160001

에 대해 3PL에서

CJ대한통운 / 123456789012

라는 정보가 전달되었다면 카페24 주문에 해당 배송사와 송장번호를 등록하도록 처리할 수 있습니다.

그러면 고객은 카페24 쇼핑몰의 마이페이지나 주문조회 화면에서 배송정보를 확인할 수 있습니다.

관리자 역시 같은 주문에서 송장번호를 확인할 수 있습니다.

네. 이 부분도 운영 규칙으로 정해야 합니다.

예를 들어 3PL에서 송장번호가 먼저 발급되고 실제 상품 출고는 몇 시간 뒤에 이루어질 수도 있습니다.

따라서 다음 중 어떤 방식으로 처리할지 정해야 합니다.

방식 1

송장번호가 발급되면 카페24에 송장번호만 등록합니다.

방식 2

송장번호가 발급되면 배송 상태도 함께 변경합니다.

방식 3

실제 출고 완료를 확인한 후 송장번호와 배송 상태를 변경합니다.

어떤 방식이 맞는지는 3PL의 실제 물류 처리 과정과 쇼핑몰 운영 정책에 따라 달라집니다.

가능하지만 난이도가 높아질 수 있습니다.

예를 들어 한 주문에 상품이 3개 있는데 상품 A는 먼저 출고하고 상품 B와 C는 나중에 출고할 수 있습니다.

이 경우 하나의 주문에 송장번호가 여러 개 생길 수 있습니다.

또한 다음과 같은 상황도 발생할 수 있습니다.

따라서 처음부터 모든 경우를 자동화하기보다는 한 주문 = 한 번 출고 = 한 송장처럼 단순한 구조부터 시작하는 방법도 있습니다.

부분 출고와 복수 송장이 실제로 필요하다면 2단계 개발 범위로 확장할 수 있습니다.

기존에는 다음과 같은 작업이 필요할 수 있습니다.

카페24 주문 확인 → 엑셀 다운로드 → 3PL 전달 → 출고 확인 → 송장 확인 → 카페24에 송장 입력

연동 후에는 다음과 같은 흐름으로 바꿀 수 있습니다.

카페24 주문 → 자동 3PL 전송 → 3PL 출고 → 송장 자동 반영

운영자는 모든 주문을 직접 처리하는 대신 전송 실패나 오류가 발생한 주문을 확인하는 방식으로 업무를 바꿀 수 있습니다.

또한 고객이 배송 관련 문의를 했을 때 카페24 주문에서 송장번호를 바로 확인할 수 있어 CS 업무도 줄어들 수 있습니다.

단순히 주문을 보내고 송장번호를 받는 것만 구현해서는 부족합니다.

실제 운영에서는 다음 부분이 중요합니다.

1. 주문 전송 기준

어떤 상태의 주문을 3PL에 보낼 것인지 정해야 합니다.

2. 상품 매핑

카페24 상품번호와 3PL 상품번호가 다르면 서로 연결할 기준이 필요합니다.

3. 중복 전송 방지

같은 주문이 두 번 출고 요청되지 않도록 해야 합니다.

4. 실패 재처리

API 오류나 네트워크 문제로 전송에 실패했을 때 다시 처리할 수 있어야 합니다.

5. 취소 처리

3PL로 전달하기 전 취소와 전달 후 취소를 구분해야 합니다.

6. 송장 반영

3PL에서 받은 송장번호를 정확한 카페24 주문에 연결해야 합니다.

7. 부분 출고

복수 송장이나 부분 출고가 필요한지 미리 확인해야 합니다.

8. 로그 관리

언제 어떤 주문을 전송했고 성공했는지, 실패했는지 기록하는 것이 좋습니다.

그렇지는 않습니다.

하루 주문량이 적고 엑셀로 처리해도 업무에 큰 문제가 없다면 굳이 자동 연동 시스템을 만들 필요는 없습니다.

반대로 다음과 같은 상황이라면 자동화를 검토할 수 있습니다.

결국 중요한 것은 주문량과 현재 물류 업무에 비해 자동화 비용이 적절한지입니다.

네.

3PL 업체마다 제공하는 연동 방식이 다를 수 있습니다.

예를 들어,

등 여러 방식이 사용될 수 있습니다.

API를 제공하는 업체라면 실시간 또는 일정 주기의 자동 연동을 구성하기 편리합니다.

API가 없다면 파일을 이용한 자동화 등 다른 방법을 검토해야 합니다.

따라서 개발을 시작하기 전에 사용 중인 3PL 업체의 API 문서나 주문·출고 파일 양식을 먼저 확인하는 것이 좋습니다.

옴니어스24는 단순히 3PL 연동이라는 요구만 보고 개발 범위를 정하지 않습니다.

먼저 현재 물류 업무가 어떻게 진행되는지 확인합니다.

예를 들어,

등을 확인합니다.

하루 한 번 엑셀로 처리해도 충분한 쇼핑몰이라면 기존 방식을 유지하는 것이 더 적합할 수 있습니다.

반대로 주문량이 많아지고 엑셀 작업과 수기 송장 입력이 반복된다면 카페24 API + 별도 서버 + 3PL 연동을 이용한 자동화를 검토할 수 있습니다.

처음부터 재고, 정산, 알림톡까지 모두 연결하기보다는 주문 전송 → 출고 → 송장 반영 → 중복 방지처럼 실제로 가장 많이 사용하는 업무부터 자동화하는 방식으로 범위를 나눌 수 있습니다.

카페24와 3PL 연동의 핵심은 주문을 자동으로 물류센터에 전달하고, 출고 후 송장번호를 다시 쇼핑몰 주문에 자동으로 연결하는 것입니다.

주문량이 많아 엑셀 작업과 수기 송장 입력이 반복된다면 자동화를 통해 물류 운영과 CS 업무를 줄일 수 있습니다.

다만 3PL마다 연동 방식과 취소·출고 규칙이 다르기 때문에, 현재 사용하는 물류업체의 방식과 필요한 자동화 범위를 먼저 확인하는 것이 중요합니다.