온라인 결제에서 시작된 하나의 질문

온라인 결제 기능이 포함된 서비스를 설계하다 보면 반드시 마주하게 되는 지점이 있습니다. 바로 본인 인증 데이터는 어디에 저장하고, 어떤 도메인이 책임져야 하는가라는 문제입니다. 겉으로 보기에는 단순히 인증 기능을 추가하는 것처럼 보일 수 있지만, 실제로는 데이터 구조와 시스템 경계를 다시 정의해야 하는 설계 이슈에 가깝습니다.

전자금융 관련 법규에 따라 결제를 제공하려면 사용자는 반드시 본인 인증 절차를 거쳐야 합니다. 이 과정에서 생성되는 CI(Customer Identification) 값은 단순 참고 정보가 아니라, 사용자 식별과 결제 한도 관리, 이상 거래 탐지, 사고 대응 정책의 기준이 되는 핵심 데이터입니다. 이 값을 어디에서 관리할 것인지는 기능 구현의 문제가 아니라 구조 설계의 문제입니다.

 

기존 구조: 개인정보의 분산 관리

하나의 가상 커머스 앱을 예로 들어보겠습니다. 이 서비스는 회원 가입 시 본인 인증을 요구하지 않습니다. 사용자는 이름과 이메일, 직접 입력한 휴대폰 번호만으로 가입할 수 있습니다. 콘텐츠 탐색이나 상품 조회는 자유롭게 이용할 수 있습니다. 다만, 간편결제를 처음 사용하는 시점에는 본인 인증을 수행합니다. 이때 CI 값, 생년월일, 통신사 인증을 거친 휴대폰 번호가 생성됩니다. 문제는 이 데이터가 간편결제 시스템의 데이터베이스에 저장된다는 점입니다. 반면 회원 시스템에는 아이디, 이름, 이메일, 사용자가 입력한 휴대폰 번호가 저장됩니다.

결과적으로 동일한 사용자를 식별하는 정보가 두 개의 시스템에 나뉘어 관리됩니다. 기능적으로는 동작하지만, 데이터 관점에서는 여러 문제가 발생합니다. 개인정보가 분산되어 보안 정책 적용이 복잡해지고, 암호화 방식 변경이나 파기 정책 수정 시 중복 작업이 발생합니다. 데이터 정합성 역시 관리하기 어려워집니다. 무엇보다 데이터 소유권이 모호해집니다.

도메인 재정의: 본인 인증 정보는 누구의 데이터인가

이 구조를 다시 바라보면 하나의 질문이 생깁니다. 본인 인증 정보는 결제 도메인의 데이터일까요, 회원 도메인의 데이터일까요?

인증이 결제 과정에서 발생한다고 해서 그 데이터가 결제 도메인에 속한다고 단정할 수는 없습니다. CI, 생년월일, 인증된 휴대폰 번호는 특정 결제 트랜잭션에 종속된 정보가 아니라, 사용자의 신원을 정의하는 정보입니다. 그렇다면 이 데이터는 회원 도메인에 속하는 것이 더 자연스럽습니다.
이 판단을 기준으로 구조를 재정의합니다. 본인 인증은 결제 시스템에서 수행하되, 데이터의 저장과 관리 책임은 회원 시스템이 가지도록 설계합니다. 이는 단순히 저장 위치를 바꾸는 작업이 아니라, 데이터 소유권을 재배치하는 구조 전환입니다.

사용자 경험은 그대로 유지한다

구조를 바꾼다고 해서 사용자 흐름까지 변경할 필요는 없습니다. 회원 가입 시 본인 인증을 추가하면 가입 전환율이 떨어질 수 있기 때문에, 기존 정책은 유지합니다. 사용자는 여전히 간단히 가입할 수 있고, 간편결제를 최초로 사용하는 시점에만 본인 인증을 수행합니다. 즉, 접근성은 유지하고 데이터 저장 구조만 변경하는 전략입니다. 사용자 경험은 그대로 두고, 내부 구조를 재설계하는 방식입니다.

 

전화번호 신뢰도 문제와 정책 결정

여기서 중요한 이슈가 하나 등장합니다. 기존 회원 시스템에 저장된 휴대폰 번호는 사용자가 직접 입력한 값입니다. 검증되지 않은 데이터일 가능성이 있습니다. 반면 본인 인증 과정에서 획득한 휴대폰 번호는 통신사 인증을 거친 값입니다. 신뢰도가 훨씬 높습니다.

두 번호가 다를 경우 어떻게 처리해야 할까요?
정책은 다음과 같이 설정합니다. 기존 번호와 인증 번호가 동일하면 그대로 저장합니다. 만약 다르다면 사용자에게 업데이트 여부를 안내합니다. 사용자가 동의하면 인증된 번호로 갱신하고, 동의하지 않으면 간편결제 이용을 제한합니다. 이 방식은 데이터 신뢰도를 확보하면서도 사용자에게 선택권을 부여하는 균형 있는 접근입니다.

 

데이터 구조의 확장

이제 회원 시스템의 데이터 구조가 변경됩니다. 기존에는 아이디, 이름, 이메일, 휴대폰 번호 정도만 관리했다면, 이제 여기에 CI 값을 암호화하여 저장하고, 생년월일과 내·외국인 여부 같은 인증 기반 속성을 추가합니다. 휴대폰 번호 역시 인증 기준으로 관리됩니다.
이는 단순 컬럼 추가가 아닙니다. 회원 도메인의 책임 범위를 확장하는 작업입니다. 앞으로 인증 기반 서비스가 추가되더라도 회원 도메인 안에서 일관성 있게 확장할 수 있는 기반이 마련됩니다.

 

프로세스 설계: API 중심의 연계

구조가 정해지면 데이터 흐름을 정의해야 합니다.

사용자가 간편결제에서 본인 인증을 완료하면, 간편결제 시스템은 CI와 생년월일, 인증된 휴대폰 번호를 확보합니다. 이후 회원 시스템의 저장 API를 호출하여 해당 데이터를 전달합니다. 회원 시스템은 내부적으로 기존 휴대폰 번호와 인증 번호를 비교합니다. 일치하면 인증 정보를 저장하고 종료합니다. 불일치하면 오류를 반환합니다. 간편결제 시스템은 이 오류를 받아 사용자에게 업데이트 여부를 묻습니다. 동의 시 수정 API를 호출하여 최종적으로 정보를 반영합니다. 이 흐름은 데이터 정합성과 사용자 경험을 동시에 고려한 설계입니다.

API 설계의 중요성

이 구조를 안정적으로 구현하려면 API 정의가 명확해야 합니다. 어떤 파라미터를 전달하는지, 성공과 실패의 기준은 무엇인지, 실패 사유는 어떻게 구분하는지까지 구체적으로 정의해야 합니다. 예를 들어 “휴대폰 번호 불일치”, “일치하는 회원 없음”, “이미 인증 완료된 회원”과 같은 오류 코드를 사전에 정의해야 합니다. 이런 정의가 없으면 개발 단계에서 해석 차이가 발생하고, 정책이 시스템에 제대로 반영되지 않을 수 있습니다.

정책 → 데이터 → 프로세스 → API로 이어지는 연결이 명확해야만 설계가 구현으로 자연스럽게 이어집니다.

이 사례의 본질

이 사례는 단순한 본인 인증 연동이 아닙니다. 데이터 도메인을 재정의하고, 데이터 소유권을 명확히 하며, 개인정보를 단일 시스템에서 책임지도록 구조를 정렬하는 작업입니다.
데이터를 어디에 저장할 것인가를 결정하는 순간, 그것은 단순한 구현 문제가 아니라 플랫폼 구조를 결정하는 설계가 됩니다. 본인 인증 정보를 회원 도메인으로 통합하는 작업은 기능 추가가 아니라 데이터 중심 설계의 전환입니다. 이 차이를 이해하는 순간, 기획은 화면이나 기능 정의를 넘어서 시스템 구조를 설계하는 영역으로 확장됩니다.