[과제] 결제 시스템 Day7

https://github.com/teeeam3/payment-assignment

GitHub - teeeam3/payment-assignment: 결제 도메인 프로젝트입니다

 

외부 결제 API 연동 및 데이터 정합성 해결

1. 문제 상황 (Problem)

상품명 노출 오류: 결제창에 서버에서 가공한 '상품명 외 n건'이 아닌, 프론트엔드에서 임의로 조합한 '주문+주문번호'가 노출됨.

결제창 에러: 주문 번호가 36자 UUID로 생성되어, 외부 PG사(이니시스)의 결제 ID 제한(40자)을 초과하여 결제창이 열리지 않음.

데이터 미반영: 서버에서 데이터를 정상적으로 저장했음에도 불구하고, 응답 DTO에 해당 필드가 누락되어 클라이언트 UI에서 확인할 수 없음.

2. 해결 과정 (Solution)

DTO 구조 개선: CreateOrderResponse 및 OrderSummaryResponse에 orderName 필드를 추가하여 서버에서 가공된 데이터를 프론트엔드로 전달할 수 있는 통로를 확보함.

주문 번호 체계 변경: 36자 UUID 대신 jnanoid 라이브러리를 도입. 충돌 위험은 낮추면서 길이는 12자 내외로 압축된 안전한 주문 번호를 생성하여 PG사 제약 사항을 통과함.

비즈니스 로직 보강: 모든 상품 아이템이 추가된 후 orderName을 생성하고 금액을 계산하도록 엔티티 내부 로직 순서를 조정하여 데이터 일관성을 확보함.

3. 오늘의 핵심 교훈 (Takeaway)

엔티티와 DTO의 분리: 데이터베이스 저장만큼이나 클라이언트에게 보내는 '응답 규격(DTO)'을 정확히 정의하는 것이 시스템의 완성도를 결정함을 체감함.

외부 시스템의 제약 준수: 외부 API 연동 시 기술 명세서(데이터 길이, 형식 등)를 사전에 철저히 검토해야 예기치 못한 런타임 에러를 방지할 수 있음.

NanoID의 효율성: 무거운 UUID보다 제어가 쉽고 가독성이 좋은 식별자가 실무 결제 시스템에서 더 나은 선택지가 될 수 있음을 배움.