정의
Axios
HTTP 통신을 쉽게 하기 위해 만들어진 Promise 기반 서드파티 라이브러리
Fetch
브라우저에 내장된 Promise 기반 네이티브 HTTP 요청 API
요청 처리 방식
Axios
| 항목 | Axios | Fetch |
|---|---|---|
| 응답 | 자동으로 JSON 파싱 후 response.data로 반환 | 수동으로 response.json() 호출 필요 |
| 에러 처리 | HTTP 에러 코드(400~500)를 catch로 감지 | HTTP 에러 코드를 성공으로 간주 |
| 응답 구조 | { data, status, headers, config } | Response 객체 |
(Fetch는 **네트워크 레벨 에러**만 `catch`에 잡힌다. 따라서 명시적으로 `if (!res.ok)` 체크를 해야한다)
업로드 & 다운로드 처리
Axios
onUploadProgress,onDownloadProgress를 지원하기 때문에 파일 업로드, 다운로드 진행률을 알 수 있다- FormData 전송할 때 자동으로 헤더와 바운더리를 구성한다
Fetch
- 기본적으로 업로드/다운로드 진행률을 알 수 없기 때문에 수동으로 처리해야한다
Next.js에서는?
Fetch
Next.js의 렌더링 모델(App Router, RSC)는 fetch와 더 긴밀하게 통합되어 있다.
Next.js 공식 문서에서도 나와있듯이 Next.js는 서버의 각 요청이 자동으로 캐싱된다.
fetch(url, { cache: 'force-cache' | 'no-store' }) 처럼 세부 옵션도 지원한다.
심지어 동일한 url로 여러 fetch 요청이 있으면 자동으로 한 번만 실행하고 결과를 공유한다.
또한, Next.js 13부터 적용된 React18의 Streaming SSR에 대해 React Suspense 연동이 가능하다.
따라서 페이지 일부만 먼저 렌더링되도록 해서 사용자 체감 성능을 높힐 수 있다.
Axios
캐시를 수동으로 관리해야하고, 중복 요청 제거 기능이 없다.
또한, Streaming SSR 연동이 불가능하고, Streaming SSR을 지원하지 않는다.
게다가, 성능도 Fetch에 비해 상대적으로 느리다는 단점까지 갖고있다.
느낀점
따로 공부하기 전에는 간단한 HTTP 통신이 아닌 이상, 무조건 fetch가 좋을 것이다 라고 생각했다.
그래서 다음 프로젝트는 Next.js로 프로젝트를 진행할 예정이었는데도 무작정 Axios를 적용할 예정이었다.
하지만 Fetch와 Axios에 대해 찾아보고 블로그로 정리하면서 생각이 달라졌다.
자동 캐싱과 중복 요청 제거, Streaming SSR에 React Suspense 연동 가능, 그리고 런타임 최적화된 빠른 성능까지 Next.js에서는 Fetch를 안 쓸 이유가 없을 거 같았다.
하지만 그럼에도 불구하고, 데이터 업로드와 다운로드 진행률 시각화 측면에서는 Axios가 Fetch보다 우위에 있기 때문에, 상황에 따라 유연하게 HTTP 통신 도구를 사용하는 것이 가장 중요한 거 같다.
