고객 알림, 경매 참여, 낙찰 이후 결제, 서비스 운영은 하나의 이용 경험입니다. 키덜트 수집품 라이브커머스 B사에서 개발·클라우드·고객 메시징·결제를 함께 구축하고 출시 이후 QA와 운영으로 이어갔습니다.
경매형 라이브커머스를 만들 때 방송 화면만 완성됐다고 서비스를 시작할 수는 없습니다. 고객은 방송이 열린다는 사실을 알아야 하고 참여한 거래는 결제로 이어져야 합니다. 운영팀은 그 과정에서 어떤 일이 일어났는지 확인할 수 있어야 합니다.
B사는 키덜트 수집품을 다루는 라이브커머스를 새로 준비하고 있었습니다. 개발 결과물과 함께 서비스가 올라갈 환경, 고객에게 나갈 알림, 돈이 오가는 경로가 같은 출시 일정에 필요했습니다.
IXC가 맡은 일은 각각의 솔루션을 설치하는 데서 끝나지 않았습니다. 서로 다른 기능이 고객에게는 하나의 서비스로 작동하도록 연결하는 일이었습니다.
네 가지 작업에는 하나의 출시 일정이 있었습니다
개발, 인프라, 메시징, 결제를 각각 잘 구축하는 것도 중요합니다. 그러나 개별 작업이 완료됐다는 사실이 전체 이용 흐름의 완성을 뜻하지는 않습니다.
고객 알림에 필요한 기능이 아직 앱에 없을 수 있고 결제 결과를 받더라도 서비스가 다음 상태로 넘어가지 않을 수 있습니다. 이런 연결 지점은 각 부분을 따로 볼 때보다 전체 흐름을 함께 볼 때 드러납니다.
B사에서는 클라우드 환경과 배포 경로를 개발 일정에 맞춰 준비하고 메시징 연동과 결제 구축을 같은 일정 안에서 진행했습니다. 환경 전환에는 되돌릴 조건도 정리했습니다.
이 방식은 담당 회사의 수를 줄이는 데 그치지 않습니다. 변경에 필요한 조건과 선후 관계를 한 일정 안에서 함께 다룹니다.
고객 알림은 설치가 아니라 운영의 시작점까지 만들었습니다
고객 메시징은 SDK 연동과 채널 설정, 기본 캠페인 구성을 함께 진행했습니다. 방송과 고객의 접점을 만들고 운영자가 이후 캠페인을 확장할 수 있는 출발점을 준비한 것입니다.
알림 기능은 메시지를 전송할 수 있다는 사실만으로 완성되지 않습니다. 어떤 상황에 누구에게 연락할지, 고객이 메시지를 받은 뒤 어디로 이동할지까지 운영의 맥락이 있어야 합니다.
다만 시스템 연동과 캠페인 성과는 구분해야 합니다. 채널을 연결했다고 고객이 더 많이 돌아온다고 단정할 수는 없습니다. 고객 반응을 살펴 메시지의 대상과 내용을 조정하는 일은 운영에서 이어집니다.
이 프로젝트의 구축 범위는 그 운영이 시작될 수 있도록 기본 구조를 갖추는 데까지였습니다.
결제 성공보다 먼저, 결제의 상태를 정했습니다
결제에서는 승인과 취소, 부분 환불의 상태를 정의한 뒤 연동했습니다. 같은 요청의 중복 처리를 줄이기 위한 고유 식별 기준과 재시도 규칙을 마련하고 테스트 환경에서 실패 경로도 확인했습니다.
결제의 예외를 생각해 보면 상태 정의가 왜 필요한지 드러납니다. 요청을 보낸 뒤 응답을 받지 못했을 때, 서비스는 성공과 실패 중 어느 쪽으로 처리해야 할까요? 무조건 다시 요청하거나 주문을 실패로 표시하는 것으로는 충분하지 않습니다.
같은 요청을 반복해도 거래가 중복 반영되지 않도록 하는 성질을 멱등성이라고 합니다. 이름보다 고객이 의도한 한 번의 거래가 시스템에서도 그 거래로 추적되는지가 중요합니다.
결제 연동에서는 결제창을 열 수 있는지뿐 아니라 예상대로 응답하지 않는 상황에서 서비스가 어떤 상태를 남기는지를 함께 봐야 합니다.
포인트도 별개의 숫자로 남겨두지 않았습니다
B사에는 포인트 충전·관리 기능도 추가했습니다. 결제와 포인트라는 두 종류의 거래를 연결된 기록으로 관리하는 구성이었습니다.
포인트 잔액은 화면에 표시되는 숫자이지만 운영에서는 그 숫자가 왜 그렇게 됐는지 설명할 수 있어야 합니다. 충전한 내역과 사용한 내역을 따로 이해해야 고객 문의에도 대응할 수 있습니다.
이번 구축에서는 결제와 포인트 거래의 연결을 다뤘습니다. 거래가 발생했을 때 서로 어떤 기록을 참조해야 하는지 정리해 구매 과정과 포인트 관리가 동떨어진 기능으로 남지 않도록 했습니다.
거래 기능이 늘어날수록 버튼의 종류보다 거래 기록의 연결을 먼저 생각해야 합니다.
출시 이후에도 검증과 운영이 이어졌습니다
서비스는 출시 후 운영 단계로 넘어갔고 클라우드 운영과 릴리스 QA를 이어갔습니다. 구축을 마친 뒤의 변경도 같은 서비스 맥락에서 다루는 방식입니다.
라이브커머스에서는 한 부분의 수정이 다른 부분의 이용 흐름과 만나게 됩니다. 따라서 기능별 완료 여부뿐 아니라 변경 뒤에도 고객 경험이 연결되는지 확인할 필요가 있습니다.
이 프로젝트에서는 다양한 기술을 사용하는 일보다 그 관계를 함께 다루는 일에 무게를 뒀습니다. 고객 접점을 만드는 메시징, 거래를 처리하는 결제, 서비스를 올리는 클라우드, 변경을 확인하는 QA가 하나의 운영 대상으로 연결됐습니다.
방송을 볼 수 있는 서비스에서, 고객을 안내하고 거래를 이어가며 계속 개선할 수 있는 서비스까지. B사의 구축 범위는 그 전체 흐름에 있었습니다.