https://github.com/teeeam3/payment-assignment
GitHub - teeeam3/payment-assignment: 결제 도메인 프로젝트입니다
결제 도메인 프로젝트입니다. Contribute to teeeam3/payment-assignment development by creating an account on GitHub.
github.com
TIL: 결제 시스템 리팩토링 및 RestClient 도입기
1. 오늘의 트러블슈팅ㅠㅠ
[문제 상황]
기존 RestTemplate 기반의 코드가 가독성이 떨어지고, AI 시뮬레이션 결과 외부 API(포트원) 응답의 Snake Case 필드와 자바의 Camel Case 필드 간 매핑이 어긋나 데이터가 null로 들어오는 문제 발생할수도 있다는 문제점을 인식
[해결 과정]
데이터 매핑 해결: @JsonProperty 어노테이션을 사용하여 외부 API 규격(merchant_uid)과 내부 변수명(paymentId)을 정확히 일치시킴.
안정성 강화: try-catch 블록을 활용하여 DB 작업 실패 시 포트원 API를 호출해 결제를 강제 취소하는 보상 트랜잭션 로직 구현.
최신화: RestTemplate 대신 Spring Boot 3.2+ 최신 표준인 RestClient로 전환하여 코드 가독성 확보.
2. 기술 비교: RestTemplate vs RestClient vs PortOne SDK
| 비교 항목 | RestTemplate (기존) | RestClient (나의 선택) | PortOne SDK (대안) |
| 특징 | 전통적인 동기 방식 HTTP 클라이언트 | 현대적인 Fluent API 스타일 HTTP 클라이언트 | 포트원에서 제공하는 라이브러리 |
| 장점 | 레거시 코드에서 널리 사용됨 | 가독성이 압도적이며 설정이 직관적임 | 내부 로직을 몰라도 API 호출이 쉬움 |
| 단점 | 코드가 장황하고 유지 관리 모드 진입 | 없음 (Spring 공식 권장 사양) | 라이브러리 의존성이 생기고 커스텀이 어려움 |
| 선택 이유 | - | "유연성": 직접 API를 호출하므로 SDK보다 제어권이 높고, 최신 표준을 따름 | - |
왜 RestClient ?
RestTemplate은 HttpEntity를 만들고 복잡한 파라미터를 넘겨야 하지만, RestClient는 uri().header().body().retrieve()처럼 마치 문장을 읽듯이 코드를 짤 수 있고, 특히 에러 핸들링(onStatus)이 체이닝 안에 포함되어 로직이 매우 깔끔해진다.
PortOne SDK 를 사용할까도 생각해보았지만, Spring 공식 권장 사양이기도 하고, 내부로직을 확인할수 있다 없다의 부분과, 범용으로 사용하기에는 RestClient가 좀더 좋다고 판단하였다.
아래는 스프링 공식 문서 내용!
https://spring.io/blog/2023/07/13/new-in-spring-6-1-restclient
New in Spring 6.1: RestClient
Spring Framework 6.1 M2 introduces the RestClient, a new synchronous HTTP client. As the name suggests, RestClient offers the fluent API of WebClient with the infrastructure of RestTemplate. Fourteen years ago, when RestTemplate was introduced in Spring Fr
spring.io
https://www.baeldung.com/spring-boot-restclient
장단점이 기술되어있는 내용
A Guide to RestClient in Spring Boot | Baeldung
A quick and practical guide to Spring Boot RestClient.
www.baeldung.com
3. 포트원 연동 핵심 개념 정리
merchant_uid: 우리가 발행한 고유 ID (paymentId). 우리 DB와 포트원을 잇는 핵심 고리.
imp_uid: 포트원이 발행한 고유 ID. 포트원 내부 식별자.
보상 트랜잭션 (Compensating Transaction):
분산 시스템(우리 서버 & 포트원 서버)에서 한쪽이 실패했을 때 전체 상태를 되돌리는 작업. 결제 시스템에서는 "자동 취소" 로직이 이에 해당함.
4. 오늘의 회고
단순히 기능만 돌아가는 코드가 아니라, 예외 상황에서도 돈이 잘못 나가지 않도록 안전 장치(보상 트랜잭션)를 만드는 법을 배웠다. 또한 최신 기술인 RestClient를 적용하며 코드의 가독성이 시스템의 유지보수에 얼마나 큰 영향을 주는지 체감할 수 있었던 하루였다.
결론: 너무 급한마음에 블로그만 쫒아가다가, 왜 이걸 사용해야하는지 장단점이 무엇인지도 확인하지 않고 채택한것이 너무 멍청한 짓거리였다 ㅠㅠ
제공되는 샘플 코드를 좀더 분석하고 포트원의 가이드 라인과 그에 적당한 기술스택을 선택할수 있는 유연한 개발자가 되어야겠다
'spring_2기[본캠프] > 과제' 카테고리의 다른 글
| [과제] 결제 시스템 Day5 (0) | 2026.02.11 |
|---|---|
| [과제] Standard Spring Task 4 (0) | 2026.02.10 |
| [과제] 결제 시스템 Day4 (0) | 2026.02.09 |
| [과제] 결제 시스템 Day3 (0) | 2026.02.06 |
| [과제] Standard Spring Task 3 (0) | 2026.02.06 |