본인인증 정보 저장 범위 확대

결제 플랫폼에 연동된 본인인증 PG(제주)에서 제공하는 응답값을 전부 활용하지 못하고 있었다. 이번 작업은 기존에 저장하던 이름, 휴대폰에 더해 생년월일·통신사·내외국인 여부 3개 필드를 새로 저장하도록 시스템을 확장한 거다.

배경: 왜 이 정보들이 필요했나

본인인증이라는 프로세스는 이미 고객의 신원을 검증하는 과정이다. PG에서 인증을 거쳐 응답받는 데이터는 사실 상당히 풍부한데, 우리는 그 중 일부만 활용하고 있었다. 놓친 게 뭐였는가:

• 생년월일 → 고객의 실제 나이를 알 수 있음. 상품별 연령 제한(주류, 성인 전용), 맞춤 마케팅, 통계 분석
• 통신사 → 고객이 어느 통신사를 쓰는지. 타겟 프로모션, 고객군 분류, 통신사 제휴 이벤트
• 내외국인 여부 → 법적·규제 준수. 국내인만 거래 가능한 상품, 외국인 고객 특별 처리

단순히 "있으면 좋을 정도"가 아니라, 비즈니스 요구사항으로 올라왔다. 고객층이 다양해졌고, 규제 환경이 바뀌면서 이 정보들이 필요해진 거다. 그래서 결정했다: 이미 얻고 있는 데이터를 버릴 이유가 없다. 저장하고 활용하자.

작업 범위: 어느 계층을 수정했나

가장 중요한 포인트: IdentityAuthResult가 중심 역할을 한다. 이 객체를 먼저 확장하면, 하위 모든 계층이 자연스럽게 따라간다.

PG 응답 (JSON/XML)
    ↓
[IdentityAuthResult 역직렬화]  ← 새 필드 추가
    ↓
회원 서비스 계층
    ↓
DB INSERT/UPDATE

마이그레이션 스크립트 ALTER_20260615_member_identity_fields.sql을 함께 배포하는 게 중요했다. 기존 고객들이 재인증할 때 이 필드들이 쌓일 수 있도록 데이터베이스 스키마를 먼저 준비해야 하기 때문이다. 애플리케이션만 배포하면 응답값이 들어올 곳이 없다.

테스트 코드와의 동기화: Mock CI 충돌

"mock CI 충돌 수정"은 이 작업의 숨겨진 부분이다.

기존에 테스트 코드에서 IdentityAuthResult를 mock 객체로 만들 때:

// Before (과거)
IdentityAuthResult mockResult = new IdentityAuthResult();
mockResult.setName("홍길동");
mockResult.setPhone("01012345678");
// 3개 필드는 신경 쓰지 않음

그런데 이번에 3개 필드를 추가하니:
- 필드 초기화 로직이 바뀌었거나
- 특정 필드가 검증 제약을 받았거나
- 어디선가 이 필드를 참조하는 로직이 추가되었거나

해서 기존 mock 객체 생성이 깨진 거다. 테스트가 빌드에 실패하거나 런타임에 NPE를 던졌을 거다.

이를 해결하려면 mock 팩토리나 테스트 픽스처를 수정해야 한다:

// After (수정)
IdentityAuthResult mockResult = new IdentityAuthResult();
mockResult.setName("홍길동");
mockResult.setPhone("01012345678");
mockResult.setBirthDate("19900101");
mockResult.setTelecom("SKT");
mockResult.setNationality("DOMESTIC");

배운 점: 데이터 모델을 변경할 때는 반드시 테스트 코드도 함께 고려해야 한다. 특히 mock 객체를 사용하는 테스트가 많으면 파급력이 크다. 이런 의도치 않은 CI 실패를 방지하려면:
- 신규 필드를 추가할 때 필수/선택을 명확히 하기
- 테스트 헬퍼 함수를 중앙 집중식으로 관리하기
- CI 단계에서 모든 테스트가 통과하는지 확인 후 배포하기

다중 PG 환경에서의 고민

이 작업을 하면서 중요한 아키텍처 질문이 생겼다: 모든 PG가 같은 필드를 제공하는가?

답은 아니다. 결제 플랫폼은 보통 여러 PG와 연동되는데, 각 PG마다 제공하는 응답 필드가 다르다. 제주 PG는 3개를 모두 제공하지만, 다른 PG는 생년월일만 제공할 수도 있고, 통신사를 안 줄 수도 있다.

이 경우를 어떻게 처리할까? nullable 처리가 필수다. 필드는 모델에 존재하지만, 특정 PG에서는 null로 들어올 수 있다.

또한 문서화도 함께 가야 한다. PG별로 어느 필드를 제공하는지, 어느 필드는 필수이고 어느 필드는 선택인지를 명확히 기록해야 한다. 그렇지 않으면 나중에 "왜 null이 들어오지?" "왜 이 필드가 없어?" 같은 버그 리포트가 쌓인다. 특히 팀원들이 새로운 PG를 추가할 때 참고할 가이드가 된다.

회고 & 다음 단계

이 작업은 작아 보이지만 실은 여러 교훈을 남겼다:

• 데이터 모델 확장의 순서: 모델 → DB → 비즈니스 로직 순서로 진행하는 게 자연스럽다. 역순이면 나중에 모순이 생긴다.
• 테스트 코드 자동화: mock 객체 생성을 헬퍼 함수로 중앙화하면, 필드 추가 시 수정 포인트가 줄어든다.
• PG 차이 관리: 필드별 PG 지원 매트릭스를 문서화하면 향후 신규 PG 추가나 버그 추적이 쉬워진다.
• 마이그레이션 스크립트의 명확성: ALTER_20260615_member_identity_fields.sql 같이 날짜와 목적을 함께 적으면 나중에 추적이 쉽다.

다음에 비슷한 응답값 확장 작업이 나올 때, 이 체크리스트를 기반으로 진행하면 더 체계적으로 할 수 있을 것 같다.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.