서론

나는 HTTP 클라이언트를 고를 때 axios를 주로 써왔다.

이유는 단순하다. 기본적으로 제공되는 인터셉터 덕분에 요청/응답 레이어를 한 번에 설계할 수 있었고, 그 강점이 체감상 정말 컸다. 실제로 다양한 프로젝트를 경험하며, 반복적으로 필요했던 토큰 주입, 공통 에러 처리, 로깅처럼 “한 번 정해 두면 전역으로 통과시키고 싶은 것”들을 묶기에 axios는 잘 맞았다.

그럼에도 문서나 예제, 최근 예제 코드를 보면 fetch가 여전히 자주 등장한다는 점이 의문이었다. 처음에는 “axios가 더 편하지 않나?” 정도로만 넘겼는데, 실제로 React Native 개발을 진행하면서 고민에 대한 답으로 조금은 가까워져갔다.

본론

웹 프론트에서는 axios가 거의 디폴트에 가까운 선택이었다. 인터셉터로 요청/응답 레이어를 나눠 둔 경험이 쌓이다 보니, 새 프로젝트에서 HTTP 클라이언트를 고를 때 비교표를 펼쳐보는 단계 자체를 건너뛰는 경우가 많았다.

React Native 프로젝트에도 비슷했다. “웹에서 잘 썼으니 여기서도 같겠지” 하는 선에서 fetch와 axios를 나란히 두고 트레이드오프를 적어 본 적은 솔직히 거의 없다. 설치하고 익숙한 인터셉터 구조만 옮기면 금방 돌아가니까, 그 순간의 결정이 선택이라기보다 관성에 가깝다고 느낀다.

돌이켜 보면 그건 나쁜 결정이라고 단정하긴 어렵다. 당시에는 생산성 면에서 합리적인 지름길이었다. 다만 RN은 웹만큼만 변하지 않는다. 런타임·번들러·네이티브 브릿지까지 업그레이드 스토리가 겹치고, 그 위에 axios 버전 축까지 동시에 맞춰야 하는 순간이 오면, 비로소 “공식 문서나 예제에서 fetch가 기본으로 많이 보였던 이유”를 고민하게 된다.

1) 트렌드는 빠르게 돌고, 도구들도 같이 움직인다

프론트엔드는 특성상 정말 시시각각 트렌드가 변한다. 그 말은 곧, 이미 자리 잡은 도구들도 시대의 흐름을 놓치기 싫어서 꾸준히 변화한다는 뜻이다. 문법·보일러플레이트·권장 패턴이 갈아엎어지는 속도도 빠르고, 예제와 튜토리얼도 그 속도를 따라간다.

특히 최근 같은 AI 시대에는 이런 흐름이 더 가속화된다고 느낀다.

정보가 많아지는 만큼 “지금은 이렇게 쓰는 게 자연스럽다”는 말도 더 빨리 갱신되고, 한 번 정해 둔 스택도 조금만 방치하면 남의 레포와 맞지 않는 느낌이 더 빨리 든다.

2) axios는 편하지만, 빠른 템포의 스택과는 버전 이야기가 겹친다

axios의 편리함은 분명하다. 나 역시 인터셉터가 없었으면 같은 패턴을 반복 구현하는 시간이 훨씬 길었을 것이다.

다만 axios는 프로젝트 위에 얹히는 의존성 레이어이기도 하다. React Native처럼 런타임·번들러·네이티브 브릿지까지 포함해 더 빠른 템포로 변하는 환경에서는, RN 쪽 업그레이드 스토리와 axios의 메이저·마이너, peer dependency 이슈가 동시에 걸리는 순간이 생긴다. “라이브러리 하나만 올리면 되는 문제”가 아니라, 여러 축의 버전이 한꺼번에 맞아야 하는 문제로 겹쳐 보인다.

편리함과 별개로, 빠르게 움직이는 생태계 위에서는 그 편리함이 ‘하나 더 맞춰야 할 축’으로 느껴질 수 있다.

이에 "fetch를 많이 쓰는 경향” 을 다시 생각하게 됐다.

3) 자율성이 보장된 fetch는, “큰 변화”가 상대적으로 적다

여기서 말하는 핵심은 단순하다. fetch는 라이브러리 한 개의 릴리스 노트를 따라가는 축이라기보다, 플랫폼, 혹은 브라우저가 제공하는 표준 API에 가깝다. 물론 표준도 영원히 고정은 아니다. 다만 axios 같은 서드파티와 비교하면 변경이 나오는 맥락·속도·범위가 다르고, 큰 그림에서 보면 자주 손대야 하는 ‘제품 레벨의 변화’가 상대적으로 덜 한쪽에 가깝다고 느낀다.

그래서 내가 정리한 문장은 이거다. axios는 편리한 이점에도 불구하고, React Native와 같이 더 빠른 템포로 변하는 것들과는 버전 차이가 계속 발생할 수 있다. 그것과는 다르게 자율성이 보장된 fetch는 큰 변화점이 없는 것이 핵심이다.

여기서 하고 싶은 말은 “axios를 쓰면 안 된다”가 아니다. 나는 여전히 인터셉터가 주는 설계 경험을 높게 본다. 다만 업그레이드 비용까지 포함해 선택해야 하는 환경이라면, 표준 fetch를 기본으로 두고 필요한 레이어만 얹는 쪽이 개발 비용 상에 있어 장기적으로 유리할 수 있다는 관점은 함께 가져가도 좋겠다.

4) 간단한 차이

혹시 나중에 직접 비교할 일이 있을 때를 위해, 차이만 아주 짧게 적어 둔다.

• 개념: fetch는 웹 표준 API, axios는 npm 패키지.
• 인터셉터: axios는 기본 제공. fetch는 보통 래퍼로 같은 패턴을 직접 만든다.
• 에러: fetch는 4xx/5xx도 네트워크 완료면 우선 fulfilled에 가깝게 처리되는 경우가 많아 response.ok 확인이 필요할 때가 있다. axios는 기본 흐름이 비교적 직관적인 편이다.
• 취소·타임아웃: 둘 다 AbortController로 취소 가능. axios는 timeout 옵션이 익숙하고, fetch는 보통 직접 패턴을 얹는 경우가 많다.

이건 “무엇이 더 낫다”의 재료라기보다, 왜 문서마다 예제가 갈리는지를 이해하는 용도로만 쓰면 된다.

결론

나는 axios를 주로 써왔고, 그 이유는 인터셉터의 강점이 컸기 때문이다. 실제로 해당 기술의 다양한 설정들 덕분에, 나는 보다 안정적인 웹을 구축하는 데 큰 도움을 받았다.

그럼에도 여전히 fetch가 많이 사용되어왔다는 지점에 대해 고민했고, 그 고민은 React Native 개발을 하면서 깨닫게 되었다. 특히 axios를 습관처럼 얹었던 나 자신을 돌아보게 된 뒤에는, “왜 예제는 fetch 중심인가”가 단순한 유행이 아니라 환경의 속도와 연결되어 보였다.

따라서 선택은 “기능 비교 한 줄”로 끝나기보다, 우리 팀이 얼마나 자주 스택을 갈아탈지, 의존성을 몇 겹까지 감당할지와 같이 붙는다. 나는 앞으로도 axios를 완전히 버릴 생각은 없다. 다만 빠르게 도는 레이어 위에서는, fetch를 기본 축으로 두는 선택의 의미를 한 번 더 짚고 가겠다.