회원 관리 — 결제에 필요한 최소 회원 모델은?

핵심 요약

• 회원 모델은 결제를 위한 임시 입력값이 아니라, 주문·구독·취소·환불을 묶는 식별 단위​​예요. 여기가 모호하면 같은 고객의 이력이 갈라져요.
• 필수로 먼저 정할 것: canonical 식별자(email·phone·외부 회원번호 중 무엇을 기준으로 묶을지) · 중복 체크 시점 · 자체 로그인 연결 방식​.
• 자체 로그인 시스템이 있으면 커머스 login-token으로 세션을 연결해요. 이미 식별된 고객을 체크아웃에 이어 붙이는 용도.
• 비회원 결제를 많이 받는 서비스라도 "재결제·환불·영수증 재발행"이 가능한 최소 식별 정보​​는 반드시 받아둬야 해요.

이런 상황이라면

결제와 주문을 커머스 API로 붙이려는 PM예요. 자체 로그인 시스템은 이미 있고, 회원 정보는 내부 DB에 있어요. 개발자분이 물어요.

"커머스 쪽에도 고객을 등록해야 할까요? 우리 DB에만 있으면 안 되나요?"

문서를 보니 커머스에는 customer.register, check-exist, login-token 같은 API가 있어요. 자체 로그인이 있는데 커머스에 회원을 다시 등록하는 게 이중 관리인지, 아니면 둘을 어떻게 연결하면 되는지 감이 안 와요. 비회원 결제도 일부 있는데 그것도 어떻게 처리할지 정해야 해요.

이 글은 결제·주문·구독에 필요한 회원 모델의 최소 범위와, 자체 로그인 시스템이 있을 때 어떻게 연결할지 정리해요.

1회원 모델은 "결제를 위한 입력값"이 아니라 "주문 묶음의 기준"

많은 팀이 회원 정보를 결제창에 넘길 입력값​​으로만 봐요. 그러나 실제로는 다음 전부의 기준이 돼요.

• 주문 묶음​: 같은 고객의 여러 주문을 하나로 묶는다 (주문 이력·재구매 패턴)
• 구독 계약​: 구독은 고객 ID 기준으로 관리돼요
• 취소·환불​: 환불 계좌·이력 추적에 필요
• 영수증 재발행​: 세금계산서·현금영수증 재발행 시 고객 식별
• CS 대응​: 고객이 문의할 때 이력을 찾는 기준
• 마케팅​: 재구매 유도, 쿠폰 발급 대상 특정

회원 모델이 느슨하면 같은 고객의 이력이 여러 개로 쪼개져요​. "어제 주문한 A와 오늘 주문한 A가 다른 고객으로 인식"되는 상태.

2필수로 먼저 정할 3가지

① Canonical 식별자

고객을 묶는 기준 필드를 하나​​로 정해요.

B2C 쇼핑몰·SaaS: 이메일이 표준. 한국 특화 서비스·배송 중심​: 전화번호가 더 안정적. 자체 로그인 시스템 있음​: 외부 회원번호를 canonical로, 이메일·전화는 보조.

② 중복 체크 시점

가입 시점에만 체크​: 표준적이지만 소셜 로그인·게스트 주문에서 느슨할 수 있어요. 매 주문·결제 시 체크​: check-exist API를 체크아웃 전에 호출해 동일 canonical 식별자를 가진 고객이 있는지 확인.

비회원 결제를 자주 받는 서비스는 매 주문 시 체크 패턴이 안전해요. 같은 이메일·전화로 주문한 게스트를 같은 고객으로 묶어요.

③ 자체 로그인과의 연결 방식

자체 로그인이 있으면 커머스 login-token으로 세션 연결​​해요.

흐름​:

1. 우리 서버에서 고객이 로그인
2. 우리 서버가 커머스 login-token API 호출 (외부 회원번호 전달)
3. 토큰을 받아 프론트에 전달
4. 프론트가 체크아웃 SDK에 토큰을 넘겨 호출

이 구조면 우리 회원 시스템이 주도권​​을 가지고, 커머스는 "이미 식별된 고객"으로 인식해요.

3모델링 옵션별 장단점

옵션 A. 자체 회원 시스템만, 커머스는 결제 API만

구조​: 자체 DB에 회원, 결제 API로 주문 시점마다 고객 정보 넘김. 장점​: 이중 관리 없음, 회원 데이터 주권이 우리에게 있음. 단점​: 주문·구독 이력을 커머스 쪽에서 조회·운영할 수 없음. 관리자 페이지가 없으므로 자체 관리 UI 구축 필요.

옵션 B. 자체 회원 + 커머스 customer 동기화

구조​: 자체 DB가 원장. 결제·주문 시점에 커머스 customer에 자동 등록. 장점​: 커머스 관리자에서 주문·구독 이력 조회 가능. 회원 데이터 주권 유지. 단점​: 동기화 로직 필요. 회원 수정 시 양쪽 업데이트.

옵션 C. 커머스 customer가 원장

구조​: 회원 시스템을 커머스 쪽에 두고, 관리자 페이지에서 직접 관리. 장점​: 자체 회원 시스템을 짜지 않아도 됨. 초기 개발 비용 최저. 단점​: 회원 정보가 커머스에 묶임. 다른 서비스에서 공유 불편.

옵션 D. 하이브리드 (자체 + 커머스, 분리된 목적)

구조​: 자체는 서비스 로그인·프로필, 커머스는 결제·주문 관련 필드만. 장점​: 역할 분리가 명확. 단점​: 동기화 로직이 가장 복잡.

대부분의 팀​: 옵션 B (자체 회원 + 커머스 customer 동기화)가 중간 지점이에요.

4비회원 결제 처리

비회원 결제를 허용하는 서비스라도 재결제·환불·영수증 재발행​​을 위한 최소 식별 정보는 받아둬야 해요.

비회원 결제 시 필수 수집

• 이메일 (영수증·알림용)
• 전화번호 (배송·CS용, 선택적)
• 선택 수집 동의 (개인정보 처리방침에 명시)

비회원 고객 관리

• 같은 이메일·전화로 재주문하면 같은 게스트 고객으로 통합
• 나중에 회원 가입하면 기존 비회원 이력을 회원에 병합​​하는 기능 제공
• 비회원 결제 시 영수증 조회·취소 요청은 주문 번호 + 이메일 인증​​으로 제공

5자주 놓치는 지점 3가지

Canonical 식별자를 바꾸기가 매우 어려워요

처음에 이메일을 기준으로 잡았다가 6개월 뒤 전화번호로 바꾸려 하면 기존 회원 이력 병합이 거의 불가능​​하예요. 중복·누락·이관 과정에서 데이터 손상이 발생해요. 초기 설계에 1주일 쓰더라도 확정하고 시작해요.

회원 탈퇴 시 주문 이력 처리

회원 탈퇴 요청이 들어오면:

• 회원 정보 삭제 (개인정보)
• 주문·결제 이력은 법적 보존 기간 동안 유지 (전자상거래법 기준 5년)
• 구독이 진행 중이면 해지 처리 먼저

탈퇴 = 전체 삭제가 아니라 개인정보만 마스킹/삭제, 거래 이력은 보존​​이 정석이에요.

이메일·전화번호 변경 시 이력 유지

고객이 이메일을 바꾸면 기존 이력과 연결이 끊기지 않도록 처리해요. 보통 내부 회원번호(UUID 등)를 불변 키로 두고, 이메일·전화는 변경 가능한 필드로 관리해요.

다음 단계

회원 모델이 정해졌다면 체크아웃 플로우와 주문 관리를 이어서 정해요.

추천 콘텐츠

주문 상태는 어디까지 우리가 관리해야 하나요? 주문 테이블을 자체 관리할지 커머스에 위임할지.

상품 관리 — 직접 짤까, 맡길까? 카탈로그의 단일 소스 결정.

체크아웃 플로우 설계 장바구니 → 주문 → 결제 흐름.

바로 참고할 문서

• 개발 문서​: 고객 이해하기 — 등록·중복체크·로그인 토큰
• 도입 문의​: 도입 문의