axios 대신 fetch를 쓴 이유 — Next.js와 더 잘 맞는 선택이었다

🧩 우리는 왜 axios를 쓰지 않았을까?

Next.js 프로젝트를 시작하면서 대부분의 팀은 자연스럽게 axios를 설치합니다.
그만큼 쓰기 편하고, 오래됐고, 정보도 많죠.

하지만 저희는 오히려 기본 내장된 fetch를 직접 감싸서 customFetch로 사용하는 방식을 선택했습니다.
왜일까요?

---

✅ 이유 1. Next.js는 이미 fetch에 최적화돼 있습니다

Next.js는 node-fetch를 내장하고 있으며,
서버에서 실행되는 모든 API 요청을 fetch 기반으로 처리할 수 있습니다.

특히 Next.js 13 이상(App Router)에서는
서버 컴포넌트에서 fetch를 호출하면 자동으로 요청 결과가 캐싱됩니다.
심지어 fetch(url, { cache: 'no-store' }) 같은 세부 옵션도 공식적으로 지원되죠.

반면 axios는 자체적으로 캐싱 기능을 제공하지 않으며,
SSR의 내장 fetch와 달리 자동 최적화가 적용되지 않습니다.

즉, fetch는 Next.js의 동작 방식과 아주 긴밀하게 통합되어 있는 기본 도구입니다.
별도 라이브러리를 추가하지 않고도 캐싱, revalidation, prefetch 등 다양한 최적화를 활용할 수 있죠.

---

✅ 이유 2. axios의 기능이 꼭 필요한 상황이 아니었습니다

axios는 많은 기능을 제공합니다:

• 요청/응답 인터셉터
• JSON 자동 직렬화
• 타임아웃, 취소 토큰
• 브라우저 호환성 등

하지만 대부분은 fetch + 유틸 함수로 충분히 구현 가능합니다.

실제로 저희 서비스는 대부분의 요청이 단순하고,
복잡한 요청/응답 흐름을 구성할 필요도 없었습니다.
오히려 axios를 도입하면서 생기는 번들 크기, 설정 이슈가 더 크게 느껴졌습니다.

그래서 선택했습니다.
필요한 기능만 직접 감싼 fetch를 쓰자.

---

✅ 이유 3. fetch는 기본적으로 양쪽 환경에서 작동합니다

axios도 물론 SSR/CSR 양쪽 환경에서 모두 사용할 수 있습니다.
하지만 fetch는 Next.js의 렌더링 모델(App Router, RSC)에 훨씬 자연스럽게 통합됩니다.

예를 들어:

• 서버 컴포넌트에서는 fetch가 자동으로 캐시되고, revalidation도 적용됨
• 클라이언트 컴포넌트에서는 fetch가 브라우저 내장 API로 사용됨

추가 설정 없이도 하나의 API로 전역에서 사용할 수 있는 장점이 컸습니다.

axios는 브라우저 환경과 Node.js 환경에서의 설정 분기가 필요할 수 있습니다.
fetch는 그 자체로 Universal API 역할을 해냅니다.

---

🧰 그래서 우리는 customFetch를 만들었습니다

기본 fetch는 raw하긴 하지만,
조금만 래핑하면 충분히 일관된 API 요청 구조를 만들 수 있습니다.

// lib/custom-fetch.ts
export async function customFetch<T>(
  input: RequestInfo,
  init?: RequestInit
): Promise<T> {
  const res = await fetch(input, {
    ...init,
    headers: {
      'Content-Type': 'application/json',
      ...(init?.headers || {}),
    },
  });

  if (!res.ok) {
    const errorText = await res.text();
    throw new Error(`[${res.status}] ${errorText}`);
  }

  return res.json();
}

이 구조는 단순하지만,

• 모든 요청에 공통 헤더를 붙일 수 있고,
• 에러 처리를 통일할 수 있으며,
• 타입까지 명확하게 관리할 수 있다는 장점이 있습니다.

---

✨ 사용 예시

import { customFetch } from '@/lib/custom-fetch';

const getUser = async () => {
  const data = await customFetch<User>('/api/user');
  return data;
};

customFetch는 모든 API 요청을 일관된 방식으로 통합할 수 있도록 도와줍니다.
특히 프로젝트가 커질수록 request layer를 미리 분리해두는 습관이 큰 힘이 됩니다.

---

💡 Tip: 환경별로 처리도 가능합니다

예를 들어 next.config.js에서 API_URL을 설정해두고,
SSR/CSR 여부에 따라 다른 도메인을 customFetch 내부에서 분기 처리할 수도 있습니다.

const isServer = typeof window === 'undefined';
const baseUrl = isServer ? process.env.API_URL : '';

await fetch(baseUrl + '/api/endpoint');

---

🧪 링크 드라퍼, 지금 베타 테스트 중입니다

링크 드라퍼는 단순한 저장 툴이 아닙니다.
정리하고, 수정하고, 다시 꺼내보게 만드는 링크 관리 도구입니다.
• 🔗 링크 삭제, 폴더 생성/수정 등을 낙관적으로 처리
• 🧠 링크 의미를 기억하게 만드는 메모 기능
• 🌐 폴더를 친구에게 공유 가능
• ⚡ OG 미리보기 자동 불러오기

👉 🔗 링크 드라퍼 베타 체험하러 가기

피드백은 언제나 환영입니다! 🙌

---

마치며

Next.js 프로젝트에서는 꼭 axios를 써야 하는 건 아닙니다.
오히려 기본 fetch는:

• Next.js의 렌더링 구조와 긴밀하게 통합되어 있고
• 별도 설치 없이 가볍고
• SSR/CSR 모두 자연스럽게 작동합니다.

axios는 여전히 훌륭한 도구입니다.
하지만 우리의 프로젝트 스케일과 목적에 따라,
필요한 만큼만 구성한 fetch 래퍼가 더 단순하고, 명확하며, 안전했습니다.

저희는 customFetch로 그 밸런스를 잡을 수 있었습니다.
그리고 앞으로 더 확장 가능하도록 유연한 구조를 준비 중입니다.