브라우저의 구조와 웹 스토리지

웹 개발을 하다 보면 “브라우저가 내부적으로 어떻게 동작하는가?” 또는 “데이터는 어디에 저장되는가?” 같은 궁금증이 생긴다. 이번 글에서는 브라우저의 주요 구조와, 클라이언트 측 데이터 저장소인 LocalStorage와 SessionStorage의 차이를 정리해본다.

 

1. 브라우저의 주요 구조

브라우저는 크게 7가지 핵심 구성 요소로 이루어져 있다.

1. 사용자 인터페이스 (User Interface) - 화면에 페이지를 표시하는 영역을 제외한 나머지 부분이다. 주소창, 뒤로가기/앞으로가기 버튼, 북마크, 새로고침 등을 포함한다.
2. 브라우저 엔진 (Browser Engine) - 사용자 인터페이스와 렌더링 엔진 사이에서 명령을 중재하고 흐름을 제어한다.
3. 렌더링 엔진 (Rendering Engine) - HTML, CSS, 이미지 등의 리소스를 화면에 그려주는 핵심 엔진이다.
   
   • HTML과 CSS를 파싱하여 DOM과 CSSOM을 만들고, 이를 기반으로 화면에 렌더링한다.
   • 파이어폭스는 Gecko, 크롬과 사파리는 WebKit 또는 Blink 렌더링 엔진을 사용한다.
   • 문서는 보통 8KB 단위로 전송되어 렌더링 엔진에 의해 점진적으로 표시된다.
4. 통신 (Networking) - HTTP 요청·응답과 같은 네트워크 통신을 담당하며, 브라우저 내부에서는 OS와 독립적인 통신 계층을 통해 구현된다.
5. UI 백엔드 (UI Backend) - 운영체제(OS)의 네이티브 UI 시스템을 사용하기도 한다. 브라우저 내의 버튼, 입력창, 스크롤바 등의 기본 UI 요소를 렌더링한다.
6. 자바스크립트 엔진 (JavaScript Engine) - 자바스크립트 코드를 해석하고 실행한다. 예: Chrome의 V8, Firefox의 SpiderMonkey, Safari의 JavaScriptCore 등이다.
7. 자료 저장소 (Data Storage) - 쿠키, WebStorage(LocalStorage / SessionStorage), IndexedDB 등 클라이언트 측에서 데이터를 저장하는 영역이다. HTML5부터 도입된 이 기능 덕분에 서버에 의존하지 않고 브라우저 안에서 데이터를 영구적으로 저장할 수 있다.

 

2. LocalStorage와 SessionStorage

Web Storage API에는 LocalStorage와 SessionStorage 두 가지 저장 방식이 있다.

둘 다 key-value 형태의 데이터 저장소이지만, 데이터 유지 기간과 접근 범위에서 중요한 차이가 있다.

1. LocalStorage

• 데이터 영구 보관 - 브라우저를 닫거나 PC를 재시작해도 데이터가 유지된다. 직접 삭제(localStorage.clear())하거나, 사용자가 브라우저 캐시를 지우기 전까지 유지된다.
• 도메인 단위 공유 - 동일한 도메인이라면 모든 탭과 창에서 데이터가 공유된다.
• 용량 - 브라우저마다 다르지만 보통 도메인당 약 5~10MB 정도 저장 가능하다.
• 주요 사용 사례
  • 자동 로그인 토큰 저장 (단, 민감 정보는 X)
  • 사용자 테마나 다크모드 설정 유지
  • 장바구니 데이터 저장 (서버 동기화 전 임시 상태 유지)

// 예시
localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");
console.log(theme); // "dark"

2. SessionStorage

• 세션 단위 저장소 - 탭이나 창을 닫는 순간 데이터가 삭제된다. 즉, “현재 세션(브라우저 탭)”에 한정된 임시 저장소이다.
• 독립된 범위 - 같은 도메인이라도 탭마다 별도의 공간이 할당된다.
• 용량 - LocalStorage와 유사하게 약 5MB 수준이다.
• 주요 사용 사례
  • 다단계 입력폼(회원가입 등)에서 임시 데이터 저장
  • 새로고침해도 유지되어야 하는 UI 상태 보존
  • 동일 세션 내 페이지 간 데이터 전달

// 예시
sessionStorage.setItem("step", "2");
const step = sessionStorage.getItem("step");
console.log(step); // "2"

3. LocalStorage vs SessionStorage

구분	LocalStorage	SessionStorage
데이터 유지 기간	브라우저 종료 후에도 유지	브라우저 탭/창이 닫히면 삭제
접근 범위	동일 도메인의 모든 탭/창에서 공유	각 탭/창별로 독립
용량	약 5~10MB	약 5MB
삭제 시점	명시적 삭제 or 캐시 삭제 시	탭/창 종료 시
주요 용도	사용자 환경 설정, 장기 데이터	일시적 세션 데이터, 임시 상태 저장

4. LocalStorage 사용 시 주의점

LocalStorage는 편리하지만, 보안 측면에서 민감한 데이터 저장에는 부적합하다.

• 암호화 없이 저장되므로 누구나 개발자 도구에서 접근 가능하다.
• XSS(교차 사이트 스크립팅) 공격에 노출될 위험이 있음 → 공격자가 스크립트(코드)를 삽입하면 LocalStorage의 데이터에 접근할 수 있다.
• 따라서 JWT 토큰, 비밀번호 등은 절대 저장하지 말고, *HttpOnly 쿠키 또는 **보안 서버 세션을 사용하는 것이 안전하다.

*HttpOnly 쿠키

HttpOnly 쿠키는 자바스크립트에서 접근할 수 없는, 오직 서버 통신을 통해서만 주고받는 쿠키이다.

• document.cookie로 접근 불가능 → 즉, XSS 공격으로 자바스크립트가 쿠키를 훔칠 수 없다.
• 오직 HTTP 요청/응답 헤더를 통해서만 전송된다.
• 서버에서 쿠키를 설정할 때 HttpOnly 속성을 부여한다.

서버에서 쿠키 설정 (Express.js 예시)

res.cookie("token", jwtToken, {
  httpOnly: true,     // JS 접근 불가
  secure: true,       // HTTPS에서만 전송
  sameSite: "Strict", // CSRF 방지
});

클라이언트 측 (React 등) → 자바스크립트에서는 이 쿠키를 직접 읽을 수 없고, 브라우저가 자동으로 요청에 쿠키를 포함시킨다.

// axios 예시
axios.get("/api/user", { withCredentials: true }); // 브라우저가 요청에 자격 증명 정보를 첨부

이렇게 하면 요청 시 서버가 token 쿠키를 자동으로 받아 인증할 수 있다. 즉, 클라이언트 코드가 직접 토큰을 다루지 않아도 된다.

 

**보안 서버 세션 (Secure Server Session)

HttpOnly 쿠키는 브라우저에 세션 ID(Session ID) 를 저장할 때 사용되고, 이 세션 ID는 서버가 관리하는 실제 사용자 데이터와 연결된다. 즉, 브라우저, 서버는 다음과 같은 구조를 갖는다.

[브라우저] ⇄ [HttpOnly 쿠키(Session ID)] ⇄ [서버 세션 저장소]

 

동작 방식은 아래와 같다.

1. 사용자가 로그인하면 서버는 세션 객체를 생성 (예: { id: 123, name: "Jay", role: "user" })
2. 서버는 해당 세션 객체에 대한 고유 ID(Session ID) 를 부여하고,
3. 그 ID를 HttpOnly 쿠키에 담아 클라이언트에게 전송한다.
4. 이후 클라이언트가 요청할 때마다 브라우저가 자동으로 쿠키를 함께 전송하고,
5. 서버는 쿠키의 Session ID를 기반으로 세션 저장소에서 사용자 정보를 찾아 인증을 처리한다.

예시 (Express + express-session)

import express from "express";
import session from "express-session";

const app = express();

app.use(
  session({
    secret: "your-secret-key",
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true, // 자바스크립트 접근 불가
      secure: true,   // HTTPS 전용
    },
  })
);

app.get("/login", (req, res) => {
  req.session.user = { name: "Jay" };
  res.send("세션 저장 완료");
});

app.get("/profile", (req, res) => {
  res.send(req.session.user); // { name: "Jay" }
});

 

장점

• 민감 데이터는 서버에만 존재하게 된다.
• 클라이언트는 세션 ID만 보유하므로 탈취돼도 위험이 최소화 된다.
• 세션 만료 시 자동 로그아웃이 가능하다.

단점

• 서버에 세션 정보를 저장하므로 Redis 같은 중앙 세션 저장소를 함께 사용한다.
• 부하 분산(Load Balancing) 환경에서는 세션 공유 설정이 필요.

Redis 같은 중앙 세션 저장소를 사용하는 부분에 대해 좀 더 설명하자면,

예를 들어, 여러 대의 서버가 부하 분산(Load Balancing)으로 운영될 경우, 사용자가 처음 요청을 보낸 서버와 이후 요청을 처리하는 서버가 다를 수 있다. 이때 각 서버가 세션을 개별적으로 관리하면 인증 정보가 일치하지 않아 로그인 상태가 풀릴 수 있다.

따라서 세션을 중앙 저장소(Redis, Memcached 등)에 저장해 모든 서버가 동일한 세션 데이터를 공유하도록 설정해야 한다.

이를 세션 클러스터링(Session Clustering) 또는 세션 공유(Session Replication) 라고 한다.

 

3. 정리

브라우저는 단순히 페이지를 그리는 도구가 아니라, 렌더링, 스크립트 실행, 네트워크 통신, 데이터 저장까지 아우르는 복합적인 애플리케이션이다. 그중에서도 LocalStorage와 SessionStorage는 클라이언트 측 데이터 관리에 핵심적인 역할을 한다.

• 장기 보존 데이터 → LocalStorage
• 세션 단위 임시 데이터 → SessionStorage

이 원칙만 기억해도, SPA나 React 앱에서 상태 관리 전략을 훨씬 효율적으로 설계할 수 있다.