프론트와 백엔드가 요청 & 응답을 주고받을 때

버튼을 누르면 목록이 갱신된다. 그 짧은 순간에 프론트엔드와 백엔드 사이에서는 정해진 순서대로 여러 일이 벌어진다. 이 글은 프론트엔드가 요청을 만드는 지점에서 출발해, 백엔드가 처리하고 응답을 돌려주고, 그 데이터가 다시 화면에 반영되기까지를 따라간다.

평소엔 신경 쓸 일이 없다. fetch 한 줄 쓰면 데이터가 알아서 오니까. 하지만 "요청은 분명 보냈는데 데이터가 안 와요", "로컬에선 되는데 배포하면 CORS 에러요", "왜 똑같은 요청인데 어떨 땐 빠르고 어떨 땐 느리죠?" 같은 문제를 만나는 순간, 이 사이에서 무슨 일이 벌어지는지 모르면 어디를 봐야 할지 감이 안 잡힌다. 그래서 이 흐름을 한 번 제대로 따라가 두면, 디버깅할 때 "지금 어느 단계가 문제지?" 를 짚을 수 있게 된다.

1. 프론트엔드: 요청 만들기

모든 건 프론트엔드 코드 한 줄에서 시작한다. 사용자가 버튼을 누르거나 페이지가 열리는 순간, 자바스크립트가 "이런 데이터를 달라"는 요청을 조립한다.

const res = await fetch("https://api.example.com/users/42", {
  method: "GET",
  headers: {
    "Authorization": `Bearer ${token}`,
    "Accept": "application/json",
  },
});
const user = await res.json();

이 한 줄이 실행될 때 프론트엔드는 뒤에서 이런 일을 한다.

여기서 핵심은 요청과 응답이 동시에 일어나지 않는다는 점이다. fetch를 호출한 순간 자바스크립트는 응답을 기다리지 않고 다음 줄로 넘어간다 — 응답은 나중에 await/then을 통해 도착한다. 이 "기다림"이 있기 때문에 로딩 상태가 필요하고, 응답이 늦거나 실패할 경우까지 프론트가 대비해야 한다. 요청을 "보내고 끝"이 아니라 "보낸 뒤 결과를 받아 처리하는 한 사이클" 로 봐야 하는 이유다.

2. 보내기 전: 브라우저 캐시 확인

요청을 네트워크로 흘리기 전에, 브라우저는 "이거 전에 받은 적 있지 않나?"를 확인한다. 캐시가 살아 있으면 네트워크를 아예 타지 않는다. 가장 빠른 요청은 아예 보내지 않는 요청이기 때문이다. 이 캐시 검사는 프레임워크나 우리 코드와 무관하게 브라우저가 자동으로 한다.

정리하면 캐시는 두 갈래다. 아직 신선하면(fresh) 네트워크 없이 끝, 오래됐으면 (stale) 버리지 않고 "그대로냐"고 한 번 물어보는 재검증. 둘 다 불필요한 데이터 전송을 줄이려는 같은 목적이다. 캐시에 없거나 갱신이 필요하면, 이제 진짜로 백엔드까지 가야 한다.

3. 네트워크 계층 (요약)

프론트와 백엔드 사이에는 물리적인 네트워크가 있다. 요청 한 번 보내려면 이 준비 과정을 거치지만, 프론트 개발자 입장에서는 대부분 자동으로 일어난다. 그래도 한 번 짚고 가는 이유는, 이 계층이 "왜 첫 요청은 느리고 그다음은 빠른지" 를 설명해 주기 때문이다.

4. CORS Preflight (다른 출처일 때)

여기가 프론트↔백 통신에서 가장 자주 막히는 지점이다. 프론트(app.example.com)와 API(api.example.com)의 출처(origin)가 다르기 때문에, 브라우저는 본 요청 전에 "이 요청 보내도 돼?"라고 먼저 물어본다.

먼저 오해부터 풀자. CORS는 브라우저가 강제하는 규칙이지, 보안 그 자체가 아니다. 같은 요청을 서버끼리(예: 백엔드 A가 백엔드 B를 호출)나 Postman으로 보내면 CORS 같은 건 없다. 오직 브라우저만, 자바스크립트가 자기와 다른 출처로 보내는 요청에 대해 이 검사를 건다. 출처(origin)란 프로토콜 + 도메인 + 포트 세 가지의 조합이라, 셋 중 하나만 달라도 "다른 출처"다 — http와 https, example.com과 api.example.com, :3000과 :8080이 전부 별개로 취급된다.

왜 이런 게 있을까? 만약 이 검사가 없다면, 사용자가 악성 사이트에 접속한 순간 그 사이트의 자바스크립트가 사용자의 로그인 쿠키를 실어 은행 API로 마음대로 요청을 날릴 수 있다. CORS는 "이 출처에서 오는 요청을 허용한다"고 서버가 명시한 경우에만 브라우저가 응답을 자바스크립트에 넘겨주도록 막는 안전장치다.

5. 백엔드: 요청 처리

요청이 서버에 도착했다. 보통 로드 밸런서·리버스 프록시를 거쳐 애플리케이션 코드에 닿고, 거기서 여러 관문을 순서대로 통과한다.

여기서 중요한 건 순서다. 이 관문들은 마치 공항 입국 심사처럼 줄지어 있어서, 앞 관문을 통과해야 다음으로 넘어간다. 인증이 라우팅보다 앞에 오는 건 의도된 설계다 — 토큰이 유효하지 않은 요청을 굳이 DB까지 끌고 갈 이유가 없으니, 되도록 일찍 걸러내는 게 서버 자원을 아끼는 길이다. 그래서 잘못된 요청일수록 짧은 경로로, 정상 요청일수록 긴 경로로 처리된다.

6. 백엔드 → 프론트: HTTP 응답

처리가 끝나면 백엔드는 상태 코드 + 헤더 + 본문으로 응답을 돌려준다.

HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=3600
ETag: "def456"
Access-Control-Allow-Origin: https://app.example.com
 
{ "id": 42, "name": "Zaman", "role": "student" }

상태 코드는 프론트엔드가 응답을 어떻게 처리할지 분기하는 기준이 된다. 숫자 하나하나를 외울 필요는 없고, 앞자리로 범주를 읽으면 된다. 2xx는 성공, 3xx는 리다이렉트·캐시 관련, 4xx는 "요청한 쪽 잘못"(없는 주소, 권한 없음, 잘못된 입력), 5xx는 "서버 쪽 잘못". 이 구분이 중요한 이유는, 같은 실패라도 4xx면 프론트가 입력을 고쳐 다시 보내야 하고 5xx면 잠시 후 재시도하거나 에러를 알리는 게 맞기 때문이다. 즉 앞자리만 봐도 대응 방향이 정해진다.

7. 프론트엔드: 응답 처리

응답이 도착했다. 프론트엔드는 이걸 받아 화면에 반영할 준비를 한다. 여기서 초보자가 가장 많이 놓치는 게 "응답이 왔다 ≠ 성공했다" 라는 점이다. 서버가 404나 500을 돌려줘도 그건 엄연히 정상적으로 도착한 응답이다. 그래서 받은 응답을 그냥 화면에 그리는 게 아니라, 상태 코드를 보고 성공·실패를 먼저 가른 다음 처리해야 한다.

if (!res.ok) {
  // 4xx, 5xx 분기 처리
  if (res.status === 401) return refreshTokenAndRetry();
  throw new Error(`요청 실패: ${res.status}`);
}
const user = await res.json(); // 본문 역직렬화
setUser(user); // 상태 갱신
setLoading(false); // 로딩 끄기

8. 화면 반영 (리렌더)

상태가 바뀌면 프론트엔드 프레임워크가 화면을 갱신한다. 전체 페이지를 새로 받는 게 아니라, 바뀐 부분만 다시 그린다.

여기가 SPA(Single Page Application)가 옛날 방식과 갈라지는 지점이다. 전통적인 웹은 데이터가 바뀔 때마다 서버에서 HTML 페이지 전체를 새로 받아 화면을 통째로 다시 그렸다. 깜빡임이 있고 느렸다. SPA는 한 번 받은 화면을 자바스크립트가 들고 있다가, 새 데이터가 오면 그 데이터가 영향을 주는 부분만 골라 고친다. 그래서 "버튼 눌렀더니 목록 한 줄만 슥 바뀌는" 부드러운 경험이 가능해진다. 우리가 1단계에서 fetch로 데이터만(HTML이 아니라 JSON만) 받아온 것도 이걸 위해서였다.

한 장 요약