웹 요청 방식 비교 분석 Form vs Fetch API - 네트워크 계층과 브라우저 처리 관점의 차이

dyeon-dev·2025년 9월 19일

목차
1. 개요 - 무엇이 다른가?
2. 요청(Request) 생성 방식
3. 응답(Response) 처리 방식
4. 브라우저 동작과 UX
5. 네트워크 계층 관점 요약
6. 결론

1. 개요 - 무엇이 다른가?

단순 HTML <form> 전송 방식과 fetch API 전송 방식은 기능적으로는 "서버로 HTTP 요청을 보낸다"는 점에서 같지만, 네트워크 계층 동작 방식과 브라우저 처리 관점에서 중요한 차이가 있다.

핵심 차이점
◦ 요청 생성 주체: 브라우저 자동 생성 vs 개발자 직접 제어
◦ 응답 처리 방식: 브라우저의 페이지 전환 vs 자바스크립트 코드 처리
◦ 사용자 경험(UX): 전체 페이지 새로고침 vs 부분적 동적 업데이트

이 두 방식의 근본적인 차이점을 가지고 자세히 알아보겠다.

2. 요청(Request) 생성 방식

브라우저와 서버가 통신하기 위해서는 HTTP 스펙에 맞는 요청과 응답을 해야한다.
먼저 브라우저에서는 표준 헤더가 담긴 요청을 서버에게 보낸다.
이때 요청 방식에 따라 브라우저에서 작동하는 방식과 직접 제어하는 방식으로 나뉜다.

HTML Form

브라우저가 자동으로 HTTP 요청 메시지를 구성한다.
- method="GET"이면 Query String
- method="POST"이면 application/x-www-form-urlencoded 기본 인코딩
기본적으로 브라우저가 표준 헤더(Content-Type, Accept) 등을 자동 세팅한다.
개발자가 세밀하게 헤더나 요청 바디를 통제하기 어렵다.

fetch API

개발자가 요청을 직접 제어한다.
HTTP 메서드, 헤더, 바디(JSON, FormData, Blob 등)를 자유롭게 지정 가능하다.
쿠키/인증 정보를 포함할지(credentials 옵션) 등 네트워크 계층의 동작을 선택적으로 제어할 수 있다.

3. 응답(Response) 처리 방식

서버는 브라우저에게 받은 요청에 따른 응답을 해준다.
이때 브라우저의 응답은 서버에서 페이지를 직접 던져주면서 새로 로드되거나,
비동기 객체를 사용하여 페이지가 새로 로드되지 않고 자바스크립트에서 세부적인 컨트롤이 가능한 방식으로 나뉜다.

HTML Form

서버 응답(HTML, Redirect 등)은 브라우저가 새 페이지로 로드하거나 리다이렉트 처리한다.
즉, 브라우저 렌더링 파이프라인에 직접 연결 → 응답은 자동으로 화면 전환으로 이어진다.
응답을 자바스크립트 코드로 가공할 수는 없다.

fetch API

응답이 Promise<Response> 객체로 전달된다.
응답 본문을 response.json(), response.text() 등으로 직접 파싱해 사용자가 원하는 로직으로 처리할 수 있다.
화면 전환은 자동으로 일어나지 않으며, SPA 방식에서 필요한 UI만 갱신이 가능하다.

HTML Form 방식이 자바스크립트 개입이 어려운 이유

<form>의 전송 결과는 브라우저 렌더링 파이프라인으로 바로 들어간다.
(응답 본문 = 새 페이지로 렌더링)
응답 데이터를 JS 코드에서 직접 가공하거나 조건에 따라 분기 처리하는 것은 불가능하다.
따라서 "조건에 따라 다른 페이지로 보낸다" 같은 로직은 서버에서 결정해야 한다.

HTML Form 전송 + Redirect 처리 흐름

Form 전송 후 서버가 3xx 상태 코드(302 Found, 303 See Other 등)를 응답하면,
브라우저는 자동으로 Location 헤더에 지정된 URL로 이동한다.
이 과정에서 개발자가 중간에 자바스크립트로 개입할 수 없다.
즉, 리다이렉트를 서버가 제어해야 한다.

HTTP/1.1 302 Found
Location: /home  → 브라우저는 /home 자동 이동된다!

메서드 변환: 302/303이면 보통 GET으로 전환
전형적 PRG(Post/Redirect/Get) 패턴에 적합

fetch Redirect 처리 (브라우저 기준)

fetch는 응답이 JS로 전달되고, 서버가 3xx 응답을 보내면 브라우저 fetch가 내부적으로 그 리다이렉트를 따라가서 최종 응답까지 자동으로 받아온다.

const res = await fetch("/login", { method: "POST" }); // follow(기본)
if (res.redirected) {
  // 필요하면 여기서 직접 네비게이션
  window.location.href = res.url;
}

기본값 redirect: "follow"으로 자동 추적하고, 중간의 3xx 응답은 JS에 노출되지 않고, Promise는 최종 응답으로 resolve 된다.
브라우저에선 보안 때문에 헤더(Location)를 노출하지 않는다. 바디도 접근 불가하다.
페이지 네비게이션은 일어나지 않는다. 단지 네트워크 레벨에서 추가 요청을 수행해 최종 리소스를 받아올 뿐이고, 화면 전환은 location.href 등으로 직접한다.

4. 브라우저 동작과 UX

위의 응답에 따라 브라우저의 동작 과정이 달라지고 사용자 경험까지 달라지게 된다.

HTML Form

기본 동작: 요청을 보내고 응답에 따라 페이지 리로드(Full reload)
사용자는 새로고침(깜빡임) 경험을 겪는다.
History API와 결합하지 않으면 SPA 같은 UX를 만들기 어렵다.

fetch API

요청-응답이 백그라운드 비동기 처리.
페이지 전환이 일어나지 않음 → 기존 화면 상태 유지 가능.
부분 렌더링이나 동적 업데이트에 유리.

5. 네트워크 계층 관점 요약

구분	HTML Form	fetch API
요청 생성	브라우저가 자동 조립 (제한적 제어)	개발자가 완전 제어 가능
응답 처리	브라우저가 페이지로 렌더링	JS 코드에서 직접 가공
네트워크 연결	쿠키/세션 자동 포함	`credentials` 옵션으로 통제
UX 영향	전체 페이지 리로드	페이지 유지 + 부분 업데이트

6. 결론

HTML Form: 전통적인 MPA (Multi-Page Application) 패턴에 적합하며, 서버가 렌더링을 주도하고 브라우저가 자동으로 처리하는 방식.
Fetch API: 현대적인 SPA (Single-Page Application) 패턴의 핵심으로, 클라이언트(개발자 코드)가 요청과 응답을 세밀하게 제어하는 방식.

두 방식은 동일한 HTTP 계층을 사용하지만, '응답 처리 주체'와 '화면 갱신 방식'에서 본질적인 차이를 보인다.