
최근 프론트엔드 컨퍼런스에서 흥미로운 발표를 들었다.
"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 자동 파싱 | ✅ | ❌ |
에러 자동 처리 | ✅ HTTP 400~500도 | ❌ |
인터셉터 | ✅ 내장 지원 | ❌ 직접 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.x
→1.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는 더 이상 원시적인 대안이 아니라, 유연하고 강력한 현대의 기본값이다.