WebClient vs RestTemplate: 외부 API 호출 클라이언트 선택

배경

카카오테크캠퍼스 최종 프로젝트에서 에브리타임 API와 연동해야 했다. 안정적이고 유연한 HTTP 클라이언트가 필요했다.

Spring 진영에서 HTTP 클라이언트로 쓸 수 있는 선택지는 크게 두 가지다.

• RestTemplate
• WebClient

RestTemplate의 문제

Spring 공식 문서에 다음과 같은 내용이 있다.

As of 5.0, the non-blocking, reactive WebClient offers a modern alternative to the RestTemplate with efficient support for both sync and async, as well as streaming scenarios. The RestTemplate will be deprecated in a future version and will not have major new features added going forward.

정리하면:

• RestTemplate은 더 이상 새로운 기능이 추가되지 않는다
• 향후 deprecated 될 예정이다
• WebClient가 공식 권장 클라이언트다

그래서 WebClient를 선택했다

시스템 전반을 WebFlux로 바꿀 생각은 없었고, 단순히 외부 API 호출만 효율적으로 하면 됐다.

결정

• 서비스 전반은 Spring MVC 기반으로 개발
• 외부 API 호출은 WebClient로 통일

이렇게 해두면, 나중에 비동기 처리나 스트리밍 같은 요구가 생겼을 때 확장하기가 상대적으로 편하다. 미리 길을 열어두는 선택에 가깝다.

트레이드오프

장점

• Spring 공식 권장 클라이언트 채택
• Connection pool, Timeout, Retry 설정이 유연하다
• 나중에 비동기/리액티브 방식으로 확장 가능하다

단점

• spring-webflux 모듈을 추가해야 해서 WebFlux 관련 의존성이 함께 들어온다
• 대부분의 호출이 block() 기반이면 논블로킹의 장점을 충분히 활용하긴 어렵다(결국 동기 호출과 크게 다르지 않다)
• 팀원들이 WebClient의 리액티브 API를 추가로 학습해야 할 수 있다

리스크

• block() 호출 패턴이 많아지면 성능적 이점이 제한적일 수 있다
• WebFlux 의존성 추가로 일부 런타임에서 예상치 못한 충돌 가능성이 있다

정리

• 익숙함만 보면 RestTemplate이 편하지만, 앞으로 지원 방향까지 보면 WebClient 쪽이 더 자연스러웠다
• WebClient를 쓴다고 자동으로 성능이 좋아지진 않는다. block() 사용 방식이나 타임아웃, 재시도, 풀 설정이 더 중요했다
• 이런 결정은 시간이 지나면 맥락이 사라지기 쉬워서, 팀에서는 ADR로 남겨두는 게 도움이 됐다

---

프로젝트: 카카오테크캠퍼스 3기 최종 프로젝트(대학생 맞춤형 일정 관리 서비스) 관련 링크

• GitHub(Backend): kakao-tech-campus-3rd-step3/Team12_BE
• GitHub(Frontend): kakao-tech-campus-3rd-step3/Team12_FE