TL;DR

• 세션(session)은 여러 메시지나 요청을 같은 상호작용으로 묶고 그 범위에 적용할 상태(state)를 찾게 한다.
• 세션을 하나의 기억 단위로 볼 수는 있지만 정확히는 어떤 기억을 이어 쓸지 정하는 논리적 범위로 보는 편이 정확하다.
• 연결(connection)은 상태 정보를 운반하는 통신 경로다.

세션: 여러 요청에 상태를 잇는 논리적 범위

세션은 시간적으로 떨어진 여러 메시지나 요청을 하나의 연속된 상호작용으로 묶는다. 시스템은 세션을 기준으로 이전에 저장한 상태를 찾아 다음 요청에 적용한다. 상태는 사용자 신원, 인증 정보, 대화 기록, 선택한 옵션, 진행 중인 작업처럼 다음 동작에 영향을 주는 값이다.

세션을 대화의 기억 단위라고 이해해도 방향은 맞다. 다만 세션이 기억을 직접 저장한다고 볼 필요는 없다. 세션은 어느 기억을 조회할지 정하는 범위나 키이며 실제 데이터는 프로세스 메모리·Redis·데이터베이스·클라이언트 등에 저장될 수 있다.

세션·상태·연결의 차이

개념	역할	대화 시스템의 예
세션(session)	여러 상호작용을 같은 흐름으로 묶는다	chat-42가 어느 대화의 연속인지 식별한다
상태(state)	다음 동작에 영향을 주는 값을 보존한다	이전 메시지, 사용자 설정, 진행 단계
연결(connection)	요청과 응답을 실제로 운반한다	TCP 연결 또는 HTTP/3의 QUIC 연결
저장소(storage)	상태 데이터를 물리적으로 보관한다	프로세스 메모리, Redis, PostgreSQL

세션과 연결의 수명은 일치할 필요가 없다. 하나의 HTTP 연결이 끝난 뒤 새 연결을 열어도 같은 세션 식별자를 보내면 이전 상태를 이어 쓸 수 있다.

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버 (세션 chat-42 상태 보유)

    Note over C,S: 연결 A
    C->>S: 요청 (session=chat-42)
    S-->>C: chat-42 상태 조회 후 응답
    Note over C,S: 연결 A 종료

    Note over C,S: 연결 B (새 연결)
    C->>S: 요청 (session=chat-42)
    S-->>C: 같은 상태 조회 후 응답

대화에서는 세션이 기억의 범위를 정한다

사용자가 첫 메시지에서 이름을 알려주고 다음 메시지에서 "내 이름이 뭐였지?"라고 물었다고 하자. 애플리케이션은 두 메시지가 같은 세션에 속한다는 사실을 이용해 이전 대화 기록을 찾는다. LLM API가 요청 자체로는 무상태(stateless)라면 애플리케이션이 그 기록을 다음 요청에 다시 포함한다.

따라서 대화의 지속성은 보통 다음 두 단계로 만들어진다.

1. 세션이 적용할 대화 기록의 범위를 식별한다.
2. 애플리케이션이 그 기록을 저장소에서 읽어 모델 요청에 넣는다.

모델이 세션을 기억하지는 않는다. 호스트 애플리케이션이 세션에 연결된 기록을 복원해 모델에 제공할 뿐이다.

무상태는 기억이 없다는 뜻이 아니다

무상태(stateless) 여부는 어느 계층을 말하는지 밝혀야 한다. HTTP 자체가 요청 사이의 애플리케이션 상태를 관리하지 않아도 서버는 세션 ID로 이전 상태를 조회할 수 있다. 명시적 ID나 핸들은 상태 의존성을 드러내는 수단이며 그것을 보낸다고 애플리케이션까지 무상태가 되는 것은 아니다. RFC 9110 §3.3.

웹에서는 쿠키가 세션 식별자를 운반한다

서버 저장형 웹 세션에서는 애플리케이션이 세션 식별자를 발급하고 브라우저가 그 값을 다시 보내 같은 세션에 묶는다. 쿠키(cookie)는 이 식별자를 운반하는 대표적 수단이다. 서버가 Set-Cookie: session=chat-42로 설정하면 브라우저는 전송 조건이 맞는 이후 요청의 Cookie 헤더에 실어 되돌려준다.

노트 개념	웹 대응
세션 식별자(범위·키)	쿠키에 담긴 세션 ID (session=chat-42)
상태(state)	로그인 여부, 장바구니, 권한, 사용자 설정
연결(connection)	개별 HTTP·TCP 연결 (요청마다 새로 열릴 수 있다)
저장소(storage)	서버측 세션 스토어 (메모리, Redis, DB)

쿠키는 세션 식별자를 나르는 여러 통로 중 하나다. 다른 헤더로 식별자를 전달해도 세션은 유지할 수 있다. 위 표는 클라이언트가 ID만 보관하고 상태는 서버에 두는 방식이다. 서명 쿠키에 상태를 담는 클라이언트 저장형 세션도 있으며 자세한 차이는 쿠키 - 브라우저가 기억하고 되돌려보내는 키-값에서 다룬다.

로그인부터 인증까지의 요청·응답 흐름

서버는 로그인 자격증명을 확인한 뒤 세션을 생성하거나 ID를 갱신하고 이후 요청에서 쿠키의 ID로 상태를 찾는다. 아래 chat-42는 설명용 값이다. 실제 인증 ID는 예측하기 어렵게 생성하고 HTTPS·쿠키 보안 속성·만료 정책을 적용해야 한다. OWASP Session Management.

sequenceDiagram
    participant B as 브라우저
    participant S as 서버
    participant DB as 세션 저장소(Redis/DB)

    Note over B,DB: ① 로그인 (세션 생성)
    B->>S: POST /login (아이디·비밀번호)
    S->>S: 자격증명 확인 성공
    S->>DB: 세션 저장 (session=chat-42 → 사용자)
    S-->>B: 200 OK · Set-Cookie: session=chat-42

    Note over B,DB: ② 이후 요청 (쿠키 자동 전송)
    B->>S: GET /me · Cookie: session=chat-42
    S->>DB: session=chat-42 조회
    DB-->>S: 사용자 = Nico
    S-->>B: 200 OK · welcome Nico

이 예시에서는 상태가 서버에 있고 브라우저는 세션 ID만 들고 다닌다. 연결이 새로 열려도 세션이 만료·취소되지 않았고 권한 검사를 통과하면 같은 상태를 이어 쓸 수 있다.

구분 기준

• 연결이 끊겼다고 세션이 반드시 끝나는 것은 아니다.
• 세션이 존재한다고 하나의 네트워크 연결이 계속 열려 있는 것은 아니다.
• 세션은 상태를 연결하는 범위이고 Redis는 상태를 저장하는 구현 선택지다.
• 무상태 프로토콜에서도 대화 기록이나 장기 작업 상태를 명시적으로 전달해 기억을 이어갈 수 있다.
• 쿠키는 세션 식별자를 운반하는 수단이지 세션 자체는 아니다.

Connections

• 쿠키 - 브라우저가 기억하고 되돌려보내는 키-값 — 웹에서 세션 식별자를 실어 나르는 클라이언트 측 저장·운반 수단이다.
• 토큰과 JWT - 조회 없이 검증되는 자격증명 — 참조 토큰과 서명형 JWT의 검증·상태 관리 차이를 다룬다.
• Model Context Protocol 2026-07-28 사양은 핸드셰이크와 프로토콜 세션을 없앤다 — 암묵적 프로토콜 세션을 요청별 문맥과 명시적 상태 핸들로 바꾼 사례다.
• MCP 전송은 stdio와 Streamable HTTP 중에 고른다 — 세션과 구분해야 하는 실제 통신 연결의 선택지를 다룬다.
• SSE (Server-Sent Events) — 서버가 HTTP 연결을 유지하며 이벤트를 보내는 전송 방식이다.

Related MOCs

• MOCs - Computer Science(CS)