이론 정리
기능 구현

axios vs fetch_이제는 fetch를 써보는게 어떨까?

axios vs fetch_이제는 fetch를 써보는게 어떨까?

최근 프론트엔드 컨퍼런스에서 흥미로운 발표를 들었다.

"axios → native fetch"— NAVER FINANCIAL FE 발표 중

처음엔 단순한 도구 변경처럼 들렸지만, 내용을 곱씹고 직접 프로젝트에 적용해보면서 나도 자연스레 같은 선택을 하게 되었다.결론부터 말하면, 이제는 새로운 프로젝트라면 fetch를 먼저 고려해야 하는 시대다.

하지만 그 전에 한 가지 의문이 들었다.


왜 axios가 그렇게 널리 쓰였을까?

✅ 1. fetch가 없던 시절, axios는 대안 그 자체였다

axios는 2014년에 등장했다. 당시 브라우저에는 fetch API가 없었고, 유일한 선택지는 XMLHttpRequest였다.하지만 XMLHttpRequest는 콜백 기반에다 사용성도 나빴다. 이런 상황에서 Promise 기반으로, 코드가 간결하고 직관적인 axios는 단숨에 대안으로 떠올랐다.

✅ 2. 개발자 경험(DX)이 탁월했다

axios는 다음과 같은 기능들을 내장했다:

axios

fetch

JSON 자동 파싱

.data

res.json() 수동 호출

에러 자동 처리

✅ HTTP 400~500도 catch로 빠짐

res.ok 직접 검사 필요

인터셉터

✅ 내장 지원

❌ 직접 wrapper 필요

요청 취소

✅ CancelToken 지원

❌ AbortController 직접 사용

기본 설정 (baseURL 등)

✅ 지원

❌ 없음

초보자든 고급 개발자든 누구나 쉽게 사용할 수 있었고, 특히 인증 처리, 에러 로깅 등에서 인터셉터 기능은 매우 강력했다.

✅ 3. Vue/React 커뮤니티에서 사실상 표준이었다

Vue, React, Angular가 급속히 성장하던 2015~2020년 사이에 대부분의 튜토리얼, 예제, 블로그가 axios를 기본으로 채택했다.이건 단순한 기능을 넘어 생태계의 디폴트로 굳어졌던 흐름이다.


그런데, 왜 이제는 fetch인가?

✅ 1. Node.js 18+ 환경에선 fetch가 기본 내장된다

  • Node 18부터는 브라우저와 동일한 방식으로 fetch 사용 가능

  • Next.js도 Node 18+를 기본으로 사용하므로 별도 설치 필요 없음

  • 서버/클라이언트 코드 통일성 확보

✅ 2. Edge Runtime에서는 axios가 동작하지 않는다

  • Next.js의 Edge Functions, Middleware 등에서는 axios가 내부적으로 Node API에 의존하기 때문에 작동하지 않음

  • 반면 fetch는 Web API에 가까워, V8 기반 런타임에서 기본 제공됨

✅ 3. axios의 breaking changes는 실무에서 부담이다

  • 예: axios@0.x1.x로 넘어갈 때 다수의 API 변경과 동작 방식 변경

  • 기업 코드베이스에서 이런 변화는 서비스 전체에 영향을 줄 수 있음

✅ 4. fetch는 Next.js와 더 깊게 통합된다

Next.js는 자체적으로 fetch에 최적화 옵션을 붙일 수 있도록 설계되어 있음.예를 들어 ISR 설정은 아래와 같이 간단하게 가능:

await fetch('/api/posts', {
	cache: 'no-store',
	next: { revalidate: 3600 } 
});

이 내용은 다른 포스트에서 자세히 다뤄보겠습니다.

이건 axios로는 절대 할 수 없는 통합 기능이다.


fetch는 정말 axios를 대체할 수 있을까?

예전에는 부족했던 기능들도 이제는 wrapper를 통해 대부분 해결할 수 있다.예:

async function apiFetch(url: string, options?: RequestInit) {   
	const res = await fetch(url, {
	     ...options,
	     headers: {
	        ...options?.headers,
	        Authorization: `Bearer ${getAccessToken()}`,     
	        },   
	    });
	    if (!res.ok) throw new Error('API Error');   
    return res.json(); 
}

→ 이런 식으로 fetch에 인터셉터 기능을 부여하고, JSON 파싱을 묶으면 실무에서 충분히 axios 수준의 DX를 구현할 수 있다.


나의 선택은?

나는 현재 Next.js 기반의 블로그/포트폴리오 프로젝트를 개발 중이며 다음 스택을 사용하고 있다:

  • Next.js (App Router)

  • Node.js 18

  • TanStack Query

  • JWT 인증 (HttpOnly 쿠키 기반)

  • fetch 기반 API Layer

axios를 쓰지 않고도 충분히 안정적이고 일관된 개발 경험을 만들 수 있었다.특히 TanStack Query와의 궁합이나, SSR 캐싱 전략과의 통합이 매우 유리했다.


정리

항목

fetch

axios

기본 내장 여부

✅ Node 18+

❌ 설치 필요

Edge Runtime 지원

❌ 불가

Next.js 호환성

✅ 우수

⚠️ 제한적

개발자 경험 (DX)

✴️ wrapper 필요

✅ 우수

인터셉터 지원

❌ 직접 구현

✅ 내장

번들 크기

✅ 작음

❌ 상대적으로 큼


결론: 새로운 프로젝트라면 fetch부터 고려하자

이제 fetch는 단순한 "브라우저 내장 API"가 아니라, Node.js 런타임과 프레임워크에서 전략적으로 사용되는 표준 API다.만약 Next.js 13+나 14 기반의 프로젝트를 새로 시작한다면,axios를 습관적으로 설치하기 전에, fetch 기반 구조를 먼저 고려해보는 것을 강력히 추천한다.

필요하다면 fetch 위에 자신만의 wrapper를 얹자.이제 fetch는 더 이상 원시적인 대안이 아니라, 유연하고 강력한 현대의 기본값이다.