결제와 주문은 다르다 - 팀원에게 설명했던 이야기

1 분 소요

결제 == 주문? 외주사 코드를 인수하며 마주친 설계 문제와 팀 전체에 설명한 과정

2025년 5월쯤, 현 직장에서 외주사가 개발한 서버를 인수받게 됐다. 서비스는 C2C 거래 마켓으로, 사용자가 직접 상품을 올리고 구매하는 플랫폼이다.

코드를 파악하기 시작하면서 바로 눈에 띄는 문제가 있었고, 곧바로 팀 전체에 설명했다.

외주사 코드에서 결제와 주문이 하나의 개념으로 묶여 있었다. 두 개가 별개의 테이블로 존재하긴 했지만, 주문이 결제 ID를 직접 들고 있는 구조였다. 서로 강하게 의존하고 있어서, 사실상 하나나 마찬가지였다.

언뜻 보면 “어차피 결제하면 주문 아닌가?” 싶을 수 있다. 팀원도 처음엔 그렇게 생각했다.

주문(Order) 은 구매를 확정하는 행위다. 무엇을, 얼마에, 누구에게 살지를 확정하는 것이다.

결제(Payment) 는 그 확정에 대한 대가를 지불하는 행위다. 어떤 수단으로, 얼마를, 언제 냈는지를 담는다.

둘은 일어나는 시점도 다르고, 담고 있는 정보도 다르다.

설령 비즈니스 규칙상 항상 1:1로 처리된다 하더라도, 개념 자체가 다르기 때문에 가급적 분리해야 한다고 생각한다. 주문이 취소되는 이유와 결제가 취소되는 이유는 다르다. 묶어놓으면 필요 이상으로 복잡해진다고 생각한다.

설명한 이유는 단순했다. 주문과 결제의 개념이 명확하게 잡혀 있지 않으면, 이후 디자인 작업에서 그 부분이 섞여 혼선이 생길 거라고 생각했다. 개발 단에서만 분리해놓고 다른 직군이 모르고 있으면, 결국 화면 흐름이나 용어가 뒤엉킨 채로 일이 진행된다.

PM과 프론트엔드 개발자는 이야기를 꺼내자마자 바로 이해했다. 디자이너에게는 조금 더 풀어서 설명이 필요했다.

기술적인 맥락 없이도 이해할 수 있도록, 쿠팡을 예시로 들었다.

쿠팡에서 상품을 장바구니에 담는다. 그리고 “주문하기” 버튼을 누른다 — 이게 주문이다. 무엇을 사겠다는 확정.

그다음 카드로 돈을 낸다 — 이게 결제다. 그 확정에 대한 지불.

이해한 것 같긴 한데 뭔가 아리송한 대답이 돌아왔다. 그래서 반품 케이스를 추가로 붙였다.

쿠팡에서 반품 신청을 해본 적 있지 않냐. 반품 신청하면 바로 환불이 되지 않는다. 상품이 회수되고 검수가 끝난 다음에야 환불이 된다.

즉, 반품 신청은 됐지만 환불은 나중에 일어난다. 둘이 같은 개념이었다면 이런 흐름 자체가 불가능하다.

이렇게 설명하니 디자이너도 바로 이해했고, 이후 화면 설계에서도 주문 흐름과 결제 흐름을 자연스럽게 분리해서 작업해줬다.

기술적으로 더 정확한 예시(결제 실패, 가상계좌 등)도 있지만, 비개발자에게는 직접 경험해본 상황을 예시로 드는 것이 가장 빠르게 와닿는다고 생각한다.

이러한 개념을 팀 전체가 공유하는 건 단순히 개발 설계의 문제가 아니라고 생각한다. 개발, 디자인, 기획이 같은 언어로 이야기할 수 있어야 불필요한 혼선 없이 일이 진행된다고 생각한다.

이번 경우엔 기술 용어 없이 일상적인 비유 하나로 충분히 전달할 수 있었다.

Python(Django) Unittest Performance 개선 (with. seeds)