HTTP 요청/응답

 

처음 백엔드 공부를 시작했을 때는 HTTP를 그냥 “요청 보내고 응답 받는 프로토콜” 정도로 이해했다.
URL에 GET, POST가 붙는다는 건 알았지만,
왜 때로는 요청이 실패하고, 어떤 구조로 데이터가 전달되며,
세션이 왜 필요한지를 깊게 고민해 본 적은 없었다.

 

하지만 프로젝트를 하면서 클라이언트와 백엔드 사이의 흐름이 막히거나 꼬일 때마다
“이건 결국 HTTP 구조를 제대로 이해하지 못해서 생긴 문제다”라는 걸 자주 느꼈다.

 

그래서 이번엔 단순 개념 암기가 아닌,
“왜 이런 구조를 가졌을까?”,
“실제 프로젝트에서 발생하는 HTTP 문제를 어떻게 대처할 것인가?” 를 중심으로 HTTP를 다시 들여다봤다.

 

---

 

HTTP는 상태를 기억하지 못한다

HTTP는 stateless, 즉 상태를 기억하지 못하는 프로토콜이다.
클라이언트가 요청을 하나 보낸 후, 다시 두 번째 요청을 보낼 때 서버는 그게 같은 사용자라는 걸 전혀 모른다.

 

이걸 처음 알게된 건 장바구니 예제 기능을 만들던 때였다.

“왜 사용자가 넣은 상품을 서버가 기억하지 못하지?”
“왜 로그인 해도 다시 새로고침하면 로그아웃된 것처럼 되지?”

이 질문에 대한 답은 세션(Session)이었다.

 

HTTP 자체는 요청과 응답만 오가는 구조고,
사용자 상태를 유지하기 위해선 별도로 서버에서 사용자를 식별하고 상태를 저장할 방법이 필요했던 것이다.

그래서 백엔드는 클라이언트에게 세션 ID를 발급하고, 그걸 기준으로 요청을 구분한다.

처음에는 단순해 보였지만,

• 세션이 만료되면 어떻게 될지?
• 세션을 너무 오래 유지하면 어떤 문제가 생길지?
• 분산 서버에서는 세션을 어떻게 공유할지?

등 실제로 생각할 게 많았다.
결국 stateless라는 특성 하나에서, 인증 구조, 보안, 서버 메모리 관리까지 연결된다는 걸 알게 되었다.

다음 글에서 위에서 했던 세션 관련 고민들에 대해 정리해보려 한다.

 

---

 

HTTP 요청, 응답 코드

<데이터를 전달하는 방식>

HTTP는 결국 클라이언트와 서버가 통신하는 언어다.
그 언어에는 어떤 구조가 있는지, 어떻게 데이터를 전달할 수 있는지 아는 건 필수이다.

• 요청 메서드: GET, POST, PUT, DELETE 등의 행동
• URI: 어떤 자원을 요청할지 나타내는 주소
• 요청 매개변수(Query) vs 요청 본문(Body):
  단순 검색 키워드는 매개변수로, 로그인/회원가입처럼 민감하거나 복잡한 데이터는 본문으로

예전에 GET 요청에 로그인 정보를 실수로 넣은 적이 있었다.
URL에 그대로 이메일, 비밀번호가 노출되는 상황을 보고 요청 매개변수로 값을 넣을 때는 주의해야 겠다는 생각을 했었다.
이후 “데이터의 종류에 따라 어떻게 전달해야 하는가?”를 훨씬 신중하게 다루게 되었다.

 

<응답코드>

서버에서 응답이 올 때 200, 404, 500 같은 숫자는 단순히 성공/실패만을 의미하지 않는다.
서버가 클라이언트에게 상황을 설명하는 방식이다.

• 2xx → 요청이 잘 처리됨
• 4xx → 요청 자체에 문제가 있음 (예: 인증 누락, 잘못된 파라미터)
• 5xx → 서버 쪽 문제 (예: DB 연결 실패, 예외 미처리)

개발 초기에 500만 계속 뜨던 시절엔,
그게 클라이언트 탓인지 서버 탓인지 구분도 어려웠다.
지금은 응답 코드를 보고 어느 계층의 문제인지 빠르게 파악할 수 있고,
직접 ResponseEntity로 명확한 응답 구조를 설계하려고 노력하고 있다.

 

---

 

URI와 URL의 차이

처음엔 URL과 URI의 차이를 몰랐다.
하지만 API를 설계하면서 이걸 정확히 구분할 수 있어야 했다.

• URL: 서버와 포트까지 포함된 위치 정보
  http://localhost:8080
• URI: URL에 경로(/cards, /users/1)까지 포함한 자원의 식별자

RESTful하게 API를 만들려면
하나의 자원을 명확히 식별할 수 있는 경로를 설계해야 하고,
이게 결국 URI 설계로 이어진다.

 

앞으로 HTTP 요청,응답 관련 설계를 할 때 다음과 같은 질문들을 스스로에게 던져보려 한다.

• 이 요청은 왜 실패했는가? (응답 코드 기반 분석)
• 어떤 데이터는 쿼리로, 어떤 데이터는 바디로 보내야 하는가?
• 상태를 유지해야 할 기능인가, 아닌가?
• 이 기능에서 세션이 필요한 이유는 무엇인가?

이런 질문을 자연스럽게 던지고 답할 수 있을 때,
HTTP를 암기한 것이 아니라 내것으로 소화한 것이라고 생각한다.

 

---

 

마치며

HTTP는 더 이상 단순히 인터넷의 요청과 응답이 아니다.
내가 만든 서비스가 사용자와 소통하는 방식이고, 그 흐름 하나하나에 보안, 성능, 사용자 경험까지 달려있다.

 

이제는 HTTP를 정확히 이해하고 다룰 줄 아는 것 자체가 개발자의 기본기라고 생각한다.
앞으로는 HTTP/2, HTTP/3 같은 성능 개선 기반 구조도 함께 살펴보며,
더 깊이 있는 백엔드 개발자로 성장하고 싶다.