테크커런트

요약 한 줄
쿠키는 브라우저가 들고 다니는 작은 메모, 세션은 서버가 기억하고 쿠키(JSESSIONID)로 찾아오는 저장공간입니다. 로그인/장바구니는 보통 “세션”으로, “아이디 기억하기”는 “쿠키”로!
 

목차

1. 쿠키 vs 세션 한눈 비교
2. 쿠키: 브라우저가 저장하는 메모
3. 세션: 서버가 관리하는 사용자 상태
4. 로그인 흐름(쿠키·세션 조합) 실전 이해
5. 보안 옵션(HttpOnly/Secure/SameSite) 핵심
6. 서블릿/톰캣 기준 코드 예제
7. 빈출 질문 & 실수 모음
8. 체크리스트(면접/시험 대비)

1) 쿠키 vs 세션 한눈 비교

구분                                       쿠키(Cookie)                                                                                           세션(Session)

포인트: “민감한 정보는 쿠키에 절대 직접 저장하지 말고, 세션에 저장하고 식별용 세션ID만 쿠키로!”

2) 쿠키: 브라우저가 저장하는 메모

• 구성: name=value; Path=/; Domain=.example.com; Max-Age=2592000; Secure; HttpOnly; SameSite=Lax
• 수명
  • 세션 쿠키: 브라우저 종료 시 삭제(수명 미지정)
  • 영속 쿠키: Max-Age/Expires 지정
• 도메인/경로: 전송 범위를 최소화하면 노출면을 줄여 보안↑
• 보안 옵션
  • HttpOnly: JS로 접근 차단(XSS 완화)
  • Secure: HTTPS에서만 전송
  • SameSite: 크로스사이트 전송 제어(Lax 기본 추천, 제3자 필요 시 None; Secure)

3) 세션: 서버가 관리하는 사용자 상태

• 생성: 로그인 성공 → HttpSession에 사용자 정보를 저장
• 식별: 컨테이너가 발급한 랜덤한 세션ID를 쿠키(JSESSIONID)로 클라이언트에 심음
• 유지: 요청마다 JSESSIONID로 세션을 찾아서 상태를 이어감
• 만료: 유휴 시간 초과 or 명시적 invalidate()
• 확장: 서버 다중대응 시 스티키 세션 또는 외부 세션 저장소(예: Redis) 고려

4) 로그인 흐름(쿠키·세션 조합)

1. 사용자가 로그인 폼 제출 → 서버에서 인증 성공
2. HttpSession에 loginUser 저장, 세션ID 발급 → Set-Cookie: JSESSIONID=...
3. 이후 요청에서 브라우저는 JSESSIONID를 자동 전송 → 서버는 해당 세션으로 사용자 식별
4. “아이디 기억하기”는 별도 쿠키(rememberId)로 저장(민감정보 X)

5) 보안 옵션 핵심 정리

• 항상 HttpOnly + Secure(HTTPS 전제)
• SameSite=Lax 기본. 외부 리다이렉트/결제 등 크로스사이트 필요 시 SameSite=None; Secure
• 세션 고정 방지: 로그인 성공 시 세션 재발급(invalidate 후 새 세션)
• 쿠키 범위 최소화: Path, Domain 축소
• 민감정보(토큰·개인정보) 쿠키 값에 직접 저장 금지(서버 세션 or 안전 저장소 사용)

6) 서블릿/톰캣 기준 코드 예제

6-1. 세션 사용 (로그인 성공 시)

// 로그인 검증 이후
HttpSession session = req.getSession();               // 없으면 생성
session.setAttribute("loginUser", user);              // 사용자 객체/ID 등
session.setMaxInactiveInterval(30 * 60);             // 30분 비활성 시 만료

// 필요 시 세션 고정 방지: 새 세션 발급
session.invalidate();
HttpSession newSession = req.getSession(true);
newSession.setAttribute("loginUser", user);

6-2. 로그아웃

HttpSession session = req.getSession(false); // 있으면 가져오고, 없으면 null
if (session != null) {
    session.invalidate();                    // 세션 파기
}
resp.sendRedirect("/");                      // 홈으로

6-3. “아이디 기억하기” 쿠키

import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;
import jakarta.servlet.http.Cookie;

// 로그인 폼에서 remember 체크 시
String userId = req.getParameter("userId");
Cookie remember = new Cookie("rememberId",
        URLEncoder.encode(userId, StandardCharsets.UTF_8));
remember.setPath("/");                // 필요한 최소 경로
remember.setMaxAge(60 * 60 * 24 * 30);// 30일
remember.setHttpOnly(true);           // JS 접근 차단
remember.setSecure(true);             // HTTPS에서만
resp.addCookie(remember);

6-4. SameSite 설정(서블릿 표준 속성 미지원 시 헤더로)

// Some containers still need manual header for SameSite
String cookie = "rememberId=" + URLEncoder.encode(userId, StandardCharsets.UTF_8)
        + "; Max-Age=2592000; Path=/; HttpOnly; Secure; SameSite=Lax";
resp.setHeader("Set-Cookie", cookie);

6-5. 쿠키 읽기

Cookie[] cookies = req.getCookies();
if (cookies != null) {
    for (Cookie c : cookies) {
        if ("rememberId".equals(c.getName())) {
            String id = java.net.URLDecoder.decode(c.getValue(), StandardCharsets.UTF_8);
            // 폼 기본값으로 채우기 등 활용
        }
    }
}

7) 빈출 질문 & 실수 모음

• Q. 세션은 어디 저장되나요?
  A. 기본은 서버 메모리(컨테이너). 규모가 커지면 외부 저장소/세션 클러스터링.
• Q. 쿠키에 토큰/JWT 넣어도 되나요?
  A. 가능하나 HttpOnly+Secure+SameSite를 지키고, 만료·회수 전략 및 XSS/CSRF 대비 필수.
• Q. 로드밸런싱에서 세션이 사라져요!
  A. 스티키 세션(같은 서버로 라우팅) 또는 공유 세션 저장소를 사용하세요.
• 실수1: 쿠키에 개인정보/권한을 평문으로 저장
• 실수2: HttpOnly/Secure 빠짐
• 실수3: 로그인 시 세션 재발급 미흡(세션 고정 취약점)
• 실수4: SameSite 미설정으로 외부 연동 시 쿠키 전송 안 돼서 로그인 깨짐

8) 체크리스트(면접/시험 대비)

• 쿠키/세션 차이 10초 안에 설명 가능?
• JSESSIONID 역할 & 세션 재발급 타이밍 이해?
• HttpOnly/Secure/SameSite 각각의 의미/기본값/언제 쓰는지?
• 분산 환경에서 세션 유지 전략(스티키 vs 저장소) 장단점?

썸네일/타이틀 이미지

• 파일: session_cookie_title.png
• 컨셉: 쿠키 캐릭터가 “세션” 메모를 브라우저에게 전달하는 귀여운 낙서 스타일
• 티스토리 글 상단에 업로드 후 대표 이미지로 설정하세요.

📖 본문

1. 크리티컬 렌더링 패스란?

브라우저가 HTML, CSS, JavaScript를 해석하고,
**사용자가 볼 수 있는 화면(Pixel)**으로 만드는 전체 과정을 말합니다.
즉, “코드를 → 화면”으로 바꾸는 여정이죠.

2. 단계별 과정

① HTML 파싱 → DOM 생성

• 브라우저가 HTML 파일을 위에서부터 한 줄씩 읽음
• 태그를 구조화하여 DOM(Document Object Model) 트리로 만듦

② CSS 파싱 → CSSOM 생성

• <link> 또는 <style> 태그의 CSS를 해석
• CSS 규칙을 트리 구조로 만들어 CSSOM 형성

③ Render Tree 생성

• DOM + CSSOM 결합 → 렌더 트리(Render Tree) 생성
• 실제 화면에 보여질 요소와 스타일 정보만 포함

④ 레이아웃(Layout)

• 각 요소의 크기와 위치 계산
• 반응형이라면 화면 크기에 맞춰 재계산

⑤ 페인팅(Paint)

• 색상, 그림자, 이미지 등을 픽셀 단위로 채움

⑥ 합성(Composite)

• 여러 레이어를 합쳐 최종 화면을 그림

3. 중요한 점 — 렌더링 속도에 영향을 주는 요소

• CSS와 JS 로드 순서
  • CSS가 늦게 로드되면 렌더링이 지연됨
  • JS는 DOM 파싱을 멈추게 할 수 있음 (defer, async 활용)
• 이미지 용량
  • 용량이 크면 페인팅에 시간 많이 걸림
• 리플로우 / 리페인트 최소화
  • DOM 구조나 스타일 변경이 많으면 속도 저하

4. 브라우저 렌더링 흐름 그림

HTML → DOM 생성
CSS → CSSOM 생성
DOM + CSSOM → Render Tree 생성
Render Tree → Layout(크기·위치 계산)
Layout → Paint(색칠)
Paint → Composite(합성)

📌 정리 표

단계                                                                                   설명

📖 본문

1. 사용자가 URL 입력

브라우저 주소창에 https://example.com 을 입력하면, 브라우저는 "이 주소의 컴퓨터(IP)를 찾아야겠다!" 라고 생각합니다.

2. DNS 조회

도메인(example.com)은 그냥 이름일 뿐, 실제로는 IP 주소를 알아야 서버를 찾을 수 있습니다.

• 브라우저 → DNS 서버에 “example.com IP 뭐야?”
• DNS 서버 → “192.0.2.1 입니다!”

3. TCP 연결 (3-Way Handshake)

브라우저와 서버가 "안전하게 데이터 주고받자" 하고 약속을 맺습니다.

1. 브라우저 → 서버: “나 연결할래(SYN)”
2. 서버 → 브라우저: “좋아, 연결하자(SYN+ACK)”
3. 브라우저 → 서버: “알았어(ACK)”

4. HTTP 요청 보내기

브라우저가 서버로 HTTP Request를 전송합니다.

• 요청 방식: GET / POST
• 요청 헤더: 브라우저 정보, 쿠키, 데이터 형식 등
• 요청 바디(POST일 경우): 폼 데이터, JSON 등

5. 서버 처리

서버는 요청을 받아 다음 작업을 합니다.

1. URL 분석 → 라우터로 경로 매칭
2. 필요한 데이터(DB 조회 등) 준비
3. HTML, JSON, 이미지 등 응답 데이터 생성

6. HTTP 응답 보내기

서버는 브라우저에 HTTP Response를 보냅니다.

• 응답 상태 코드: 200(성공), 404(없음), 500(오류) 등
• 응답 헤더: 데이터 타입(Content-Type), 길이, 캐시 정보 등
• 응답 바디: HTML, CSS, JS, 이미지 등 실제 화면에 필요한 데이터

7. 브라우저 렌더링

브라우저는 받은 HTML을 해석하고,

• CSS 적용
• JS 실행
• 이미지 로드
  를 거쳐 최종 화면을 사용자에게 보여줍니다.

🔍 전체 흐름 그림

[사용자]
   ↓ URL 입력
[브라우저]
   ↓ DNS 조회
[DNS 서버]
   ↓ IP 전달
[브라우저]
   ↓ TCP 연결
[서버]
   ↓ 요청 처리
[브라우저]
   ↓ 렌더링
[사용자]

단계                                                                                                            설명

📡 “404야, 내 마음도 Not Found다...”

✅ HTTP 상태코드란?

서버가 클라이언트의 요청에 대해 어떤 결과를 돌려줬는지 알려주는 숫자 코드입니다.

예를 들어...

• "응, 잘 받았어!" → 200 OK
• "어..? 너 누구?" → 401 Unauthorized
• "뭐라는 거야?" → 400 Bad Request

🎯 상태코드는 크게 5가지로 나뉩니다

🔵 2xx: 성공했어요!

🟡 3xx: 어이쿠! 이리로 와요~

🔴 4xx: 너가 잘못했어 (Client Error)

⚫ 5xx: 서버가 잘못했어요 (Server Error)

😂 코드별 상황극 예시

[404 Not Found]
👉 너 걔 봤어?
👤 누구?
👉 내 미래.

[403 Forbidden]
👉 사장님, 이 폴더 좀 볼게요.
👤 ...너 권한 없어. 꺼져.

🔐 상태코드, 실무에선 이렇게 써요!

• API 응답에 반드시 상태코드 명확히 반환
• 정상 처리: 200 또는 201
• 예외 처리: 400, 401, 403, 500 등 구분
• 프론트와 협업 시 명확한 상태 정의 문서 공유 필요

RESTful API는 웹 개발자라면 반드시 알아야 할 핵심 기술입니다.

✅ REST란 무엇인가요?

**REST(Representational State Transfer)**는 2000년에 로이 필딩(Roy Fielding)이 논문에서 처음 제안한 아키텍처 스타일입니다.
쉽게 말해, 웹에서 자원을 HTTP 방식으로 다루는 표준화된 방법이라고 생각하시면 됩니다.

📌 REST의 6가지 핵심 제약조건

🧭 RESTful API란?

REST 원칙을 따르는 API를 말합니다. 즉, HTTP 메서드와 URL을 이용해 자원을 CRUD 방식으로 처리하는 것이죠.

🚀 RESTful API 예제

가상의 블로그 게시글(Post)에 대한 API를 설계한다고 가정해볼게요.

🔄 RESTful 하지 않은 API 예시

GET /getPosts
POST /createPost

• ❌ 이런 방식은 RESTful하지 않습니다.
• ✅ RESTful 방식은 명사 중심 URI와 HTTP 메서드를 적절히 사용하는 것이 핵심입니다.

💡 RESTful API 설계 시 팁

• URI에는 동사 대신 명사 사용
• URI는 소문자 사용
• 언더스코어(_)보단 하이픈(-) 사용 권장
• 응답 상태 코드 (200, 201, 400, 404 등) 정확히 설정
• 예외 응답은 JSON 형태로 일관되게 처리

🛠️ RESTful API 구현 프레임워크

• Spring Boot (Java)
• Express (Node.js)
• Flask / Django REST Framework (Python)
• FastAPI (Python, 최신 트렌드)
• Laravel (PHP)

🔷 쿠키(Cookie)란?

• 정의: 사용자의 브라우저에 저장되는 작은 데이터
• 주 용도: 로그인 유지, 사용자 설정 저장
• 특징
  • 클라이언트(브라우저)에 저장됨
  • 서버가 Set-Cookie 헤더로 설정
  • 매 요청마다 자동으로 서버에 함께 전송됨
  • 보안에 취약할 수 있음 (노출 가능성)

Set-Cookie: sessionId=abc123; Path=/; HttpOnly

🔷 세션(Session)이란?

• 정의: 서버가 사용자 정보를 서버 메모리 또는 DB에 저장하고 식별하는 방식
• 주 용도: 인증 정보 저장 (로그인 상태)
• 특징
  • 서버에서 관리됨
  • 사용자는 식별자(sessionId)만 쿠키로 보유
  • 상대적으로 안전하지만 서버에 부담이 있음

🔷 토큰(Token)이란?

• 정의: 인증 정보를 포함한 문자열(주로 JWT 형식)을 클라이언트가 보관
• 주 용도: API 인증 (특히 모바일, SPA 등)
• 특징
  • 주로 JWT 형태로 인코딩된 정보 포함
  • 클라이언트가 보관 (쿠키나 로컬스토리지)
  • Stateless 구조 (서버가 상태 저장 안 함)
  • 보안 주의: XSS, 탈취 방지 필요
  •  

Header.Payload.Signature (JWT 구조 예시)

🔷 쿠키 vs 세션 vs 토큰 비교

🔷 실무 예시

• 쿠키: 자동 로그인, 장바구니, 테마 설정 등
• 세션: Spring MVC 로그인 처리 시 사용 (HttpSession)
• 토큰: Spring Security + JWT, OAuth 인증 등에서 사용

✅ 마무리

쿠키, 세션, 토큰은 각각의 목적과 장단점이 있으며,
웹 서비스의 규모, 보안 요건, 확장성에 따라 적절히 선택해야 합니다.
특히, SPA + 모바일 API 환경에서는 토큰 기반 인증(JWT)이 주로 사용됩니다.

웹 개발에서 클라이언트와 서버 간 통신은 대부분 HTTP 메서드를 통해 이루어집니다.
특히 GET, POST, PUT, PATCH, DELETE는 REST API 설계의 핵심이라고도 할 수 있죠.

이 글에서는 각 메서드의 역할, 차이점, 사용 시 주의사항을 모두 정리해드립니다.

✅ GET

• 목적: 데이터 조회
• 특징:
  • URL 쿼리 파라미터 사용 (/users?name=kim)
  • 데이터 변경 없음
  • 캐시 가능, 브라우저 주소창에서 사용 가능
• 사용 예시: 게시글 목록 조회, 유저 정보 조회 등

✅ POST

• 목적: 데이터 생성 (Create)
• 특징:
  • Body에 JSON, form 데이터 전송
  • 서버 상태를 변경함
  • 재요청 시 중복 생성 주의
• 사용 예시: 회원가입, 글 작성, 댓글 등록

✅ PUT

• 목적: 리소스 전체 수정 (Update All)
• 특징:
  • 존재하지 않는 리소스는 새로 생성할 수도 있음
  • 전송 시 전체 필드 필요
• 사용 예시: 게시글 전체 수정

✅ PATCH

• 목적: 리소스 일부 수정 (Update Partial)
• 특징:
  • 변경되는 필드만 Body에 포함
  • 서버 상태를 부분적으로 변경
• 사용 예시: 유저 닉네임만 변경, 게시글 제목만 수정

✅ DELETE

• 목적: 리소스 삭제
• 특징:
  • 지정된 리소스를 제거
  • 요청 본문은 일반적으로 사용하지 않음
• 사용 예시: 게시글 삭제, 회원 탈퇴

🧠 전체 요약 비교표

웹사이트 주소 앞에 붙는 http://와 https://의 차이, 알고 계신가요?
둘 다 인터넷 통신 규약이지만, 보안 측면에서 큰 차이가 있습니다.

🔍 HTTP란?

• HTTP는 HyperText Transfer Protocol의 약자입니다.
• 인터넷에서 데이터를 주고받는 기본적인 프로토콜입니다.
• 하지만 암호화되지 않기 때문에 보안에 취약합니다.
• 예: http://example.com

🔒 HTTPS란?

• HTTPS는 HTTP + SSL(Secure Socket Layer) 혹은 TLS(Transport Layer Security)입니다.
• 모든 데이터를 암호화해서 주고받기 때문에 도청, 변조, 스니핑 방지에 탁월합니다.
• 예: https://example.com

✅ HTTP vs HTTPS 차이점 정리

🛡 HTTPS의 보안 원리 간단 설명

1. 클라이언트가 서버에게 접속 요청
2. 서버가 공개키 포함된 인증서 전송
3. 클라이언트가 공개키로 세션키 암호화 후 전송
4. 서버가 비공개키로 복호화해 세션키 획득
5. 이후부터는 세션키 기반 대칭키 암호화 통신

즉, 누구도 중간에서 내용을 훔쳐볼 수 없도록 안전한 터널을 만드는 것이 HTTPS입니다.

📌 결론

• HTTP는 보안이 없다.
• HTTPS는 정보를 암호화하여 안전하게 만든다.
• 웹사이트를 운영하거나 이용하는 사람 모두 HTTPS를 사용하는 것이 현대 웹의 기본 상식입니다.