“Fetch/XHR”, 화면에 보이는 데이터 대체 어디서 가져온 걸까?

들어가며

웹사이트를 개발하다 보면 이상하게 궁금해지는 순간이 있다.

화면에는 분명 데이터가 표시되고 있는데, HTML 소스를 열어봐도 그 데이터가 보이지 않는다.

상품 목록도 그렇고 게시글 목록도 그렇다. 버튼을 눌렀더니 새로운 내용이 나타나는데 페이지 전체가 새로고침되는 것도 아니다.

그렇다면 이 데이터는 어디서 온 걸까?

이럴 때 가장 먼저 확인해볼 만한 곳이 바로 Chrome 개발자 도구의 Network 탭에 있는 Fetch/XHR이다.

개발자 도구를 어느 정도 사용해봤다면 Network 탭은 익숙할 것이다. 그런데 Network에 표시되는 요청이 너무 많다 보니 처음에는 무엇을 봐야 할지 헷갈리기도 한다.

이럴 때 Fetch/XHR 필터를 사용하면 서버와 주고받는 API 요청만 골라서 확인하기가 훨씬 편해진다.

Fetch/XHR이란 무엇일까?

먼저 Fetch와 XHR부터 알아보자.

웹페이지에서 서버의 데이터를 가져오거나 서버에 데이터를 전달할 때 브라우저와 서버 사이에는 HTTP 요청이 발생한다.

요즘 웹 애플리케이션에서는 JavaScript의 fetch() API를 사용하는 경우가 많다.

예를 들어 이런 코드가 있다고 해보자.

fetch('/api/products')
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });

페이지가 /api/products에 요청을 보내고 서버가 JSON 형태의 상품 데이터를 돌려주는 구조다.

예전부터 많이 사용했던 방식으로는 XMLHttpRequest, 줄여서 XHR이 있다.

const xhr = new XMLHttpRequest();

xhr.open('GET', '/api/products');

xhr.onload = () => {
  console.log(xhr.responseText);
};

xhr.send();

Fetch와 XMLHttpRequest는 구현 방식은 다르지만 개발자 도구에서는 둘 다 서버와 데이터를 주고받는 요청을 확인하는 데 중요한 역할을 한다.

그래서 Network 탭에서 Fetch/XHR 필터를 선택하면 이러한 요청을 중심으로 확인할 수 있다.

개발자 도구에서 Fetch/XHR은 어디에 있을까?

Chrome에서 개발자 도구를 열어보자.

보통 다음 순서로 들어가면 된다.

F12
↓
Network
↓
Fetch/XHR

또는 페이지에서 마우스 오른쪽 버튼을 누르고 검사를 선택해도 된다.

Network 탭을 처음 열면 문서, 이미지, CSS, JavaScript, 폰트 등 상당히 많은 요청이 한꺼번에 표시된다.

여기서 Fetch/XHR을 선택하면 목록이 확 줄어드는 것을 볼 수 있다.

이게 생각보다 중요하다.

예를 들어 쇼핑몰 페이지에서 상품 목록을 불러오는 요청을 찾는다고 해보자.

Network 탭에는 이미지 요청이 수십 개, CSS 파일과 JavaScript 파일도 여러 개 나타날 수 있다.

그런데 Fetch/XHR을 선택하면 실제 데이터를 가져오는 API 요청이 눈에 띄기 시작한다.

화면을 새로고침하고 확인해보자

Fetch/XHR을 제대로 확인하려면 단순히 Network 탭을 열어놓는 것보다 직접 동작을 발생시켜보는 것이 좋다.

예를 들어 다음과 같은 기능이 있다고 생각해보자.

상품 목록
[ 다음 페이지 ]

Network 탭에서 Fetch/XHR을 선택한 상태로 다음 페이지 버튼을 눌러본다.

그러면 새로운 요청이 하나 나타날 가능성이 높다.

예를 들어 다음과 같이 보일 수 있다.

GET /api/products?page=2

이 요청을 클릭하면 서버와 어떤 데이터를 주고받았는지 자세하게 확인할 수 있다.

이 방법은 정말 많이 사용한다.

버튼을 눌렀을 때 어떤 API가 호출되는지 궁금하다면 Network → Fetch/XHR을 열어놓고 직접 버튼을 눌러보는 것이다.

Headers에서는 무엇을 볼까?

Fetch/XHR 요청을 하나 클릭하면 오른쪽 또는 아래쪽에 상세 정보가 표시된다.

가장 먼저 볼 만한 부분이 Headers다.

여기에는 요청 URL과 HTTP 메서드, 상태 코드, 요청 헤더 등의 정보가 들어 있다.

예를 들어 다음과 같은 요청이 있을 수 있다.

Request URL
https://example.com/api/products?page=2

Request Method
GET

Status Code
200

여기서 Request URL을 보면 실제로 어떤 주소로 요청했는지 알 수 있다.

Request Method에서는 GET인지 POST인지 등을 확인할 수 있다.

그리고 Status Code는 요청이 정상적으로 처리됐는지 판단할 때 중요한 단서가 된다.

예를 들어 200이라면 일반적으로 정상 응답을 의미하고, 404라면 요청한 리소스를 찾지 못했다는 의미다.

500 계열이라면 서버 측에서 문제가 발생했을 가능성을 확인해야 한다.

Payload를 보면 보낼 데이터를 확인할 수 있다

POST나 PUT 같은 요청에서는 Payload도 상당히 중요하다.

예를 들어 로그인 요청을 보낸다고 해보자.

POST /api/login

Payload에는 서버로 전달하는 데이터가 들어갈 수 있다.

{
  "email": "user@example.com",
  "password": "********"
}

개발할 때는 이 부분을 확인하면 프론트엔드가 서버에 실제로 어떤 값을 전달하고 있는지 알 수 있다.

특히 검색이나 필터 기능을 디버깅할 때 유용하다.

예를 들어 사용자가 검색창에 노트북이라고 입력했는데 서버에서 엉뚱한 결과가 나온다면 Payload나 Query String Parameters를 확인해볼 수 있다.

keyword=노트북
page=1
sort=popular

프론트엔드에서 생각했던 값과 실제 서버에 전달된 값이 다른 경우도 있기 때문에 이런 식으로 하나씩 확인하면 원인을 찾기가 쉬워진다.

Response가 가장 중요한 경우도 많다

Fetch/XHR을 보는 가장 큰 이유 중 하나는 Response다.

서버에서 어떤 데이터를 반환했는지 직접 확인할 수 있기 때문이다.

예를 들어 API 응답이 다음과 같다고 해보자.

{
  "success": true,
  "data": [
    {
      "id": 101,
      "name": "노트북"
    },
    {
      "id": 102,
      "name": "키보드"
    }
  ]
}

화면에 표시되는 상품 이름이나 가격이 HTML에 존재하지 않더라도 Response 안에 들어 있다면 서버에서 API를 통해 받아온 데이터일 가능성이 높다.

이런 구조를 이해하면 요즘 웹사이트가 어떻게 동작하는지도 조금씩 보이기 시작한다.

페이지를 처음 열었을 때 모든 데이터를 HTML에 넣어두는 것이 아니라, JavaScript가 API를 호출하고 받은 JSON 데이터를 화면에 그려주는 방식이다.

Preview와 Response의 차이도 알아두자

Fetch/XHR 요청을 클릭하면 Preview와 Response가 함께 제공되는 경우가 많다.

Response는 서버에서 전달받은 원본 응답 내용을 확인하는 데 적합하다.

반면 Preview는 브라우저가 JSON 같은 구조화된 데이터를 조금 더 보기 편하게 보여주는 형태다.

JSON 데이터가 길다면 Preview가 편할 때도 있고, 실제 응답 문자열 자체를 확인해야 한다면 Response가 더 유용하다.

둘 다 한번씩 눌러보면 차이를 금방 이해할 수 있다.

API가 호출되지 않는다면?

여기서 개발자들이 자주 하는 실수가 있다.

Fetch/XHR 필터를 선택해놓고 아무것도 나오지 않는다고 해서 무조건 API가 없는 것은 아니다.

Network 기록은 기록을 시작한 이후 발생한 요청을 보는 것이 기본이기 때문이다.

따라서 페이지가 이미 로딩된 뒤 Network 탭을 열었다면 처음 발생했던 요청이 목록에 없을 수도 있다.

이럴 때는 Network 탭을 연 상태에서 페이지를 새로고침해보자.

Network
↓
Fetch/XHR
↓
새로고침

그리고 필요한 버튼이나 메뉴를 다시 눌러보면 된다.

또한 Fetch/XHR이 아닌 다른 유형의 요청일 수도 있기 때문에 필요하다면 All로 바꿔서 전체 요청을 확인하는 것도 좋다.

Fetch/XHR은 API 디버깅에 특히 유용하다

개발하면서 가장 많이 활용하게 되는 부분은 역시 API 디버깅이다.

예를 들어 프론트엔드에서 다음과 같은 문제가 발생했다고 해보자.

"분명 서버에서는 데이터가 있다고 하는데
화면에는 아무것도 안 나온다."

이때 무작정 JavaScript 코드만 들여다보는 것보다 Network → Fetch/XHR부터 확인하면 빠르게 범위를 좁힐 수 있다.

먼저 요청이 발생했는지 확인한다.

그다음 상태 코드를 본다.

그리고 Request URL과 Parameters를 확인한다.

마지막으로 Response를 확인한다.

요청 발생 여부
      ↓
Request URL
      ↓
Parameters / Payload
      ↓
Status Code
      ↓
Response
      ↓
화면 출력 코드

이 순서로 확인하면 어디에서 문제가 발생했는지 찾기가 훨씬 수월하다.

CORS 오류도 Network에서 확인할 수 있다

Fetch 요청을 사용하다 보면 CORS 문제를 만나는 경우도 있다.

특히 프론트엔드와 API 서버의 도메인이 서로 다른 환경에서 개발할 때 자주 발생한다.

콘솔에는 CORS 관련 오류가 표시되고, Network에서는 요청 또는 Preflight 요청을 확인할 수 있다.

이때 단순히 “API가 안 된다”고 생각하지 말고 Network에서 실제 요청이 어떻게 진행됐는지를 보는 것이 좋다.

OPTIONS 요청이 먼저 발생했는지, 응답 헤더에 필요한 CORS 관련 정보가 있는지 등을 확인하면서 원인을 좁혀갈 수 있다.

Copy as cURL도 알아두면 편하다

Fetch/XHR 요청을 분석하다 보면 실제 요청을 그대로 재현해보고 싶을 때가 있다.

이때 Network 요청을 마우스 오른쪽 버튼으로 클릭하면 Copy → Copy as cURL 같은 기능을 사용할 수 있다.

이 기능을 이용하면 브라우저에서 발생한 HTTP 요청을 cURL 명령 형태로 복사할 수 있다.

개발 환경에서 API 요청을 재현하거나 서버 응답을 확인할 때 상당히 편리하다.

다만 여기에는 쿠키나 인증 정보 같은 민감한 헤더가 포함될 수 있으므로 복사한 내용을 다른 사람에게 그대로 공유하는 것은 주의해야 한다.

마무리

Chrome 개발자 도구의 Network → Fetch/XHR은 단순히 API 주소를 확인하는 기능으로만 생각하기에는 활용도가 꽤 높다.

화면에 표시되는 데이터가 어디에서 왔는지 확인할 때도 사용할 수 있고, 버튼을 눌렀을 때 어떤 API가 호출되는지 추적할 수도 있다.

특히 개발 중에 API가 정상적으로 호출되고 있는지, 서버에 어떤 값이 전달됐는지, 서버가 어떤 데이터를 반환했는지 확인하는 데 매우 유용하다.

처음에는 Network 탭에 수많은 요청이 쏟아져서 조금 복잡하게 느껴질 수 있다.

하지만 Fetch/XHR → 요청 선택 → Headers → Payload → Response 순서로 하나씩 살펴보는 습관을 들이면 생각보다 어렵지 않다.

웹사이트의 화면만 보고 있으면 보이지 않던 데이터 흐름이 Network 탭에서는 그대로 드러난다.

그래서 개발자 도구를 공부하고 있다면 Fetch/XHR은 꼭 한번 직접 눌러볼 만하다.

특히 “이 화면의 데이터는 어디에서 가져오는 거지?”라는 궁금증이 생겼다면, 소스 코드를 먼저 뒤지는 것보다 Network의 Fetch/XHR부터 확인해보는 것이 의외로 빠른 해결책이 될 수 있다.