🤔 외부 API 어떤 방식으로 호출할지, RestTemplate vs WebClient

결제 API 연동을 위해 Toss API 호출 방식으로

외부 HTTP 클라이언트 라이브러리인 RestTemplate과 WebClient 중 어떤 방식을 사용할지 고민했습니다.

🤔 RestTemplate과 WebClient 방식 비교

• RestTemplate
  • 블로킹 (동기) 방식 : try-catch 등 예외처리 흐름이 명확함
  • 사용하기 간편함 : 코드가 직관적이고 간단함
  • 낮은 트래픽에 적합
  • 기존 Spring MVC 프로젝트와 쉽게 연동됨
  • Spring 5 이후 권장되지 않음 : WebClient로 대체되는 추세
  • 확장성에 한계 : 요청시 스레드를 점유하기 때문에, 많은 동시 요청에 비효율적
• WebClient
  • 논블로킹 (비동기) 방식 : 스레드를 점유하지 않기 때문에 높은 동시성 처리에 적합함
  • 낮은 리스소 사용 : 스레드 수가 적어도 많은 요청 처리 가능 (event loop 기반)
  • 높은 트래픽에 유리함
  • Spring 5부터 적극 지원됨
  • 코드가 복잡 : 단순 호출도 flapMap, onErrorResume 등으로 구성해야 함
  • 에러처리/디버깅이 복잡함 : 예외 흐름이 콜백 기반이라 기존 방식보다 복잡함

---

✅ 현재 상황에 맞는 선택 : RestTemplate

결제 api는 실시간 대량 요청보다 안정성과 응답에 대한 신뢰도가 더 중요하다고 생각함

현재 시스템은 트래픽이 높지 않고, 결제 요청도 단발성이기 때문에 블로킹 방식의 RestTemplate도 충분하다고 판단하였음

또한, WebClient는 러닝커브가 있고 초기 도입시 복잡한 반면,

RestTemplate은 구현이 단순하고 빠르게 개발이 가능하기 때문에 프로젝트 일정과 개발 효율 측면에서도 적합함!

---

🐣 블로킹 방식이라도 걱정 없는 이유

Spring Boot는 기본적으로 멀티 스레드 환경이기 때문에 

하나의 스레드가 결제 처리 중이더라도, 남은 스레드가 다른 요청을 처리함

즉, 누군가가 결제 중이어도 다른 사용자의 요청은 동시에 처리 가능함

특히 결제 api는 사용 빈도가 낮고, 요청 당 처리 시간이 짧아 스레드의 점유 위험도도 낮음

---

🐣 블로킹 방식의 한계와 추후 개발 계획

혹여나 모든 스레드가 점유된다면, 새로운 요청은 대기하거나 타임아웃 될 수 있음

따라서 향후 사용자 수가 많아지고 트래픽이 증가하면, 논 블로킹 방식으로 리팩토링을 고려하고 있음

WebClient는 요청을 던지고 스레드를 즉시 반환하며, 응답이 오면 이벤트 기반(콜백)으로 처리함

이러한 방식으로 적은 수의 스레드로도 더 많은 요청을 처리하기 때문에 WebClient로의 리팩토링은 유용할 것이라고 생각함

따라서 현재 RestTemplate 기반의 블로킹 방식으로 구현하되,

나중에 WebClient로의 전환이 용이하도록 인터페이스 기반의 아키텍쳐로 설계하였음.