티스토리 뷰

STUDY

웹의 상태 관리 변천사 1편 : HTTP Stateless와 Cookie의 탄생

ebson 2026. 3. 5. 16:41

 

HTTP는 왜 Stateless로 설계되었을까

웹의 상태 관리가 시작된 이유

 

오늘날의 웹 애플리케이션은 로그인, 장바구니, 사용자 개인화 같은 다양한 기능을 자연스럽게 제공합니다. 그러나 웹이 처음 등장했을 당시에는 이러한 기능을 전혀 고려하지 않은 단순한 구조였습니다. 초기 웹은 문서를 전달하는 시스템에 가까웠으며, 오늘날 우리가 사용하는 서비스형 애플리케이션과는 성격이 상당히 달랐습니다.

 

이러한 차이를 이해하려면 먼저 HTTP 프로토콜의 설계 철학을 살펴볼 필요가 있습니다. HTTP는 기본적으로 Stateless 프로토콜로 설계되었습니다. 이 설계는 초기 인터넷 환경과 웹의 사용 목적을 고려하면 상당히 합리적인 선택이었습니다.

 

하지만 웹이 점점 애플리케이션 형태로 발전하면서 상황이 달라졌습니다. 사용자 경험을 제공하려면 사용자 상태를 유지하는 기능이 필요해졌고, 이를 해결하기 위해 등장한 대표적인 기술이 바로 Cookie입니다.

 

이번 글에서는 HTTP의 Stateless 철학에서 시작해 웹에서 상태 관리가 왜 필요해졌는지, 그리고 Cookie가 어떤 방식으로 이를 해결하려 했는지를 정리해 보겠습니다.

 

 

HTTP의 Stateless 설계 철학

 

HTTP는 기본적으로 요청(Request)과 응답(Response) 구조로 동작하는 프로토콜입니다. 클라이언트가 서버에 요청을 보내면 서버는 그 요청에 대한 응답을 반환합니다. 그리고 그 요청 처리가 끝나면 연결은 종료됩니다.

 

여기서 중요한 특징이 바로 Stateless입니다. Stateless는 말 그대로 각 요청이 서로 독립적이며 이전 요청의 상태를 서버가 기억하지 않는다는 의미입니다.

 

이러한 설계는 여러 측면에서 장점이 있습니다.

 

먼저 서버 구조가 단순해집니다. 서버가 각 클라이언트의 상태를 유지할 필요가 없기 때문에 요청을 처리하는 로직이 비교적 간결해집니다. 또한 서버 확장성 측면에서도 유리합니다. 요청 간에 상태가 공유되지 않기 때문에 어떤 서버가 요청을 처리하더라도 문제가 발생하지 않습니다.

 

초기 인터넷 환경에서는 이러한 특성이 매우 중요한 요소였습니다. 네트워크 환경이 지금보다 훨씬 불안정했고 서버 자원도 제한적이었기 때문에 가능한 한 단순한 구조가 필요했습니다.

 

또한 초기 웹은 정적 문서 제공 시스템에 가까웠습니다. 사용자는 웹 브라우저를 통해 HTML 문서를 요청하고 서버는 해당 문서를 반환하는 방식이었습니다. 이 과정에서는 특별히 사용자 상태를 기억할 필요가 없었습니다.

 

이러한 배경을 고려하면 HTTP가 Stateless로 설계된 것은 당시 상황에서 매우 자연스러운 선택이었다고 볼 수 있습니다.

 

 

초기 웹 아키텍처

 

초기 웹의 구조를 떠올려 보면 오늘날의 웹 서비스와는 상당히 다른 모습입니다.

 

초기의 웹 서버는 주로 정적 파일을 제공하는 역할을 했습니다. 사용자가 특정 URL을 요청하면 서버는 해당 경로에 있는 HTML 문서를 그대로 반환했습니다. 사용자는 이 문서를 브라우저에서 읽고 필요한 경우 다른 링크를 클릭해 또 다른 문서를 요청했습니다.

 

이러한 구조에서는 서버가 사용자를 식별하거나 상태를 기억할 필요가 거의 없었습니다. 요청이 들어오면 문서를 반환하고 처리가 끝나면 연결을 종료하면 됩니다.

 

이 방식은 문서 중심의 웹에서는 매우 효율적이었지만, 웹이 점점 서비스 플랫폼으로 발전하면서 여러 가지 한계가 드러나기 시작했습니다.

 

 

웹 애플리케이션에서 상태가 필요한 이유

 

웹이 단순한 문서 시스템에서 서비스 플랫폼으로 발전하면서 가장 먼저 등장한 요구사항 중 하나가 사용자 상태 관리였습니다.

 

대표적인 사례가 로그인 기능입니다.

 

사용자가 로그인에 성공했다면 이후 요청에서는 해당 사용자가 인증된 상태라는 사실을 서버가 인식해야 합니다. 그러나 HTTP가 Stateless이기 때문에 서버는 이전 요청의 결과를 자동으로 기억하지 않습니다.

 

장바구니 기능 역시 마찬가지입니다. 사용자가 상품을 하나씩 담는 과정에서 서버는 현재 장바구니에 어떤 상품이 들어 있는지 계속 기억해야 합니다. 그렇지 않으면 매 요청마다 장바구니 상태가 초기화되어 버립니다.

 

사용자 개인화 기능도 비슷한 문제를 갖습니다. 추천 상품이나 사용자 설정 같은 정보는 특정 사용자의 이전 행동이나 설정을 기반으로 동작합니다. 이러한 기능을 구현하려면 서버가 사용자 상태를 어느 정도 인지하고 있어야 합니다.

 

결국 웹이 애플리케이션 형태로 발전하면서 다음과 같은 요구가 자연스럽게 등장했습니다.

 

서버가 특정 사용자를 식별하고 그 사용자의 상태를 유지할 수 있어야 한다는 요구입니다.

 

그러나 HTTP 자체는 이러한 기능을 제공하지 않았습니다. 그래서 HTTP 위에서 상태를 유지하기 위한 여러 가지 방식이 고민되기 시작했습니다.

 

 

Cookie의 등장 배경

 

이 문제를 해결하기 위해 등장한 기술이 바로 Cookie입니다.

 

Cookie는 1990년대 중반 Netscape에서 처음 도입된 개념으로 알려져 있습니다. HTTP 프로토콜 자체를 변경하지 않으면서도 클라이언트 측에 상태 정보를 저장할 수 있도록 하는 방식이었습니다.

 

기본적인 아이디어는 비교적 단순합니다.

 

서버가 클라이언트에게 작은 데이터를 전달하고, 브라우저가 이를 저장한 뒤 이후 요청에서 다시 서버로 전달하도록 하는 방식입니다. 이렇게 하면 서버는 해당 데이터를 통해 사용자를 식별하거나 상태를 추적할 수 있습니다.

 

이 방식은 HTTP의 Stateless 특성을 유지하면서도 상태 관리 기능을 구현할 수 있다는 점에서 현실적인 해결책으로 받아들여졌습니다.

 

이후 Cookie는 웹에서 사용자 상태를 관리하는 기본적인 메커니즘으로 자리 잡게 되었습니다.

 

 

Cookie의 동작 원리

 

Cookie의 동작 방식은 HTTP 헤더를 통해 이루어집니다.

 

서버는 응답을 보낼 때 Set-Cookie 헤더를 포함할 수 있습니다. 이 헤더에는 브라우저가 저장해야 할 정보가 포함됩니다.

 

브라우저는 이 정보를 로컬에 저장합니다. 이후 동일한 도메인에 요청을 보낼 때 브라우저는 자동으로 Cookie 헤더를 요청에 포함시킵니다.

 

이 과정을 통해 서버는 해당 요청을 보낸 사용자를 식별할 수 있습니다.

 

예를 들어 로그인 과정에서 서버가 특정 세션 식별자를 Cookie로 내려주면, 이후 요청마다 브라우저가 해당 값을 함께 전달하게 됩니다. 서버는 이 값을 통해 사용자를 확인하고 로그인 상태를 유지할 수 있습니다.

 

이 방식은 비교적 단순하지만 웹 애플리케이션에서 매우 중요한 역할을 하게 되었습니다.

 

 

Cookie 보안 속성

 

Cookie가 널리 사용되기 시작하면서 보안 문제도 함께 등장했습니다. 이에 따라 여러 가지 보안 옵션이 추가되었습니다.

 

대표적인 속성으로는 HttpOnly, Secure, SameSite 등이 있습니다.

 

HttpOnly 속성은 JavaScript에서 Cookie에 접근하지 못하도록 제한합니다. 이 속성은 특히 XSS 공격 상황에서 Cookie 탈취를 방지하는 데 도움이 됩니다.

 

Secure 속성은 HTTPS 연결에서만 Cookie가 전송되도록 제한합니다. 이를 통해 네트워크 상에서 Cookie가 평문으로 노출되는 위험을 줄일 수 있습니다.

 

SameSite 속성은 Cross-Site 요청에서 Cookie가 전송되는 방식을 제어합니다. 이 속성은 특히 CSRF 공격을 완화하기 위한 목적으로 사용됩니다.

 

이러한 옵션들은 Cookie 기반 인증을 보다 안전하게 사용할 수 있도록 돕는 기능입니다.

 

 

Cookie 기반 인증의 한계

 

Cookie는 웹에서 상태를 관리하는 데 중요한 역할을 했지만 몇 가지 한계도 존재합니다.

 

대표적인 문제 중 하나가 CSRF(Cross-Site Request Forgery)입니다.

 

브라우저는 동일한 도메인 요청에 대해 자동으로 Cookie를 포함시키기 때문에 공격자가 사용자의 브라우저를 이용해 의도하지 않은 요청을 보내도록 유도할 수 있습니다. 이 문제는 오랫동안 웹 보안에서 중요한 이슈로 다뤄져 왔습니다.

 

또한 Cookie 자체에 중요한 정보를 저장할 경우 보안 문제가 발생할 수 있습니다. 따라서 일반적으로는 Cookie에 최소한의 식별 정보만 저장하는 방식이 권장됩니다.

 

이러한 한계 때문에 웹 애플리케이션에서는 Cookie를 직접 인증 정보로 사용하기보다는 서버 측 상태 관리 방식(Session)과 함께 사용하는 경우가 많았습니다.

 

 

정리하며

 

HTTP는 처음부터 상태를 관리하기 위해 설계된 프로토콜이 아니었습니다. 오히려 단순한 문서 전달을 목표로 한 Stateless 구조가 핵심 설계 철학이었습니다.

 

하지만 웹이 점점 애플리케이션 형태로 발전하면서 로그인, 장바구니, 개인화 같은 기능이 필요해졌고, 이를 구현하기 위해 여러 가지 상태 관리 방식이 등장하게 되었습니다.

 

그 출발점에 있었던 기술이 바로 Cookie입니다.

 

Cookie는 클라이언트 측에 상태 정보를 저장하는 방식을 통해 HTTP의 Stateless 특성을 유지하면서도 사용자 상태를 관리할 수 있는 방법을 제공했습니다.

 

물론 Cookie만으로 모든 문제가 해결된 것은 아니었습니다. 보안 문제나 확장성 이슈가 존재했고, 이러한 한계를 해결하기 위해 이후에는 Session 기반 인증 방식이 널리 사용되기 시작했습니다.

 

다음 글에서는 이러한 흐름을 이어서 서버가 상태를 관리하는 방식인 Session 기반 인증이 어떻게 등장했고 왜 널리 사용되게 되었는지를 정리해 보려고 합니다.

'STUDY' 카테고리의 다른 글

웹의 상태 관리 변천사 3편 : JWT, OAuth 2.0 그리고 Token 기반 인증  (0) 2026.03.05
웹의 상태 관리 변천사 2편 : Session 아키텍처와 서버 상태 관리  (0) 2026.03.05
LLM 시대에도 변하지 않는 기초: Engineer가 TCP/IP와 HTTP를 알아야 하는 진짜 이유 2편 - TCP/IP 4 Layer vs OSI 7 Layer  (0) 2026.03.03
LLM 시대에도 변하지 않는 기초: Engineer가 TCP/IP와 HTTP를 알아야 하는 진짜 이유 1편 - 브라우저에 www.google.com을 입력하면 벌어지는 일  (0) 2026.03.03
분산 트랜잭션 환경에서 Spring Batch 재처리와 Saga 패턴 정리  (1) 2026.02.27