함께 배우는 수업 · 컴퓨터/정보
웹 동작 원리와 HTTP / REST API
브라우저 주소창에 URL을 입력했을 때 일어나는 전체 네트워크·렌더링 과정과 HTTP 프로토콜의 무상태성(Stateless), 메서드 멱등성(Idempotency), 상태 코드, REST API 설계를 학습합니다.
이 수업에서 해 볼 일
- HTTP 요청의 목적과 상태 코드를 문맥에 맞게 해석한다
먼저 알면 좋은 것: TCP/IP 4계층과 IP 주소 및 포트 번호(80, 443) · 클라이언트(브라우저) - 서버 요청(Request)/응답(Response) 구조 · JSON 데이터 포맷과 URL(Uniform Resource Locator) 구조
오늘의 목표
가입 없이 시작할 수 있어요. 설명을 읽고, 함께 연습한 뒤, 처음 보는 문제에서 직접 확인합니다.
1. 브라우저에 URL을 입력하면 일어나는 일 (면접 최빈출 시나리오)
사용자가 브라우저에https://www.example.com/posts를 입력하고 엔터를 치면 화면이 뜨기까지 다음 5단계가 순차적으로 일어납니다:
1. URL 파싱 및 DNS 조회 (Domain Name System):
- 브라우저가 프로토콜(https), 도메인(www.example.com), 경로(/posts)를 분리합니다.
- 사람이 읽는 도메인 이름을 컴퓨터가 찾아갈 수 있는 IP 주소(예: 93.184.216.34)로 변환하기 위해 브라우저 캐시 ➔ OS(hosts) 캐시 ➔ 공유기/ISP 로컬 DNS 서버 ➔ 루트/TLD/권한 있는 DNS 서버 순으로 질의하여 IP를 획득합니다.
2. TCP 3-Way Handshake 및 TLS 암호화 협상:
- 획득한 IP 주소와 HTTPS 기본 포트(443번, HTTP는 80번)로 TCP 3-Way Handshake를 수행해 연결을 수립하고, 이어서 TLS Handshake로 서버 인증서를 검증하고 대칭 세션키를 교환합니다.
3. HTTP Request 전송 및 서버 처리:
- 브라우저가 HTTP 요청 메시지(Start Line + Headers + Body)를 서버로 보냅니다. 웹 서버(Nginx 등)와 WAS(Node.js, Spring, Django)가 비즈니스 로직과 DB 조회를 수행합니다.
4. HTTP Response 수신:
- 서버가 상태 코드(200 OK)와 함께 HTML, CSS, JS 또는 JSON 응답 본문을 브라우저로 돌려보냅니다.
5. 브라우저 렌더링 파이프라인 (Critical Rendering Path):
- HTML을 파싱해 DOM 트리를 만들고, CSS를 파싱해 CSSOM 트리를 만든 뒤 둘을 합쳐 렌더 트리(Render Tree)를 구성하고, 각 요소의 위치·크기를 계산하는 레이아웃(Layout/Reflow)과 픽셀을 색칠하는 페인팅(Paint)을 거쳐 화면에 출력합니다.HTTP의 2대 특징은 '비연결성(Connectionless)'과 '무상태성(Stateless)'입니다. 서버가 클라이언트의 이전 요청 상태를 기억하지 않기 때문에 서버를 수십 대로 쉽게 확장(Scale-out)할 수 있으며, 로그인 유지가 필요할 때는 쿠키(Cookie)·세션(Session)이나 JWT 토큰을 헤더에 담아 보냅니다.2. HTTP 메서드(CRUD)와 멱등성(Idempotency), 상태 코드
- HTTP 주요 메서드와 멱등성(Idempotency): - 멱등성이란 동일한 요청을 1번 보내든 100번 반복해서 보내든 서버의 리소스 상태가 똑같이 유지되는 성질입니다 (네트워크 오류 시 안전하게 자동 재시도 가능한지 판단하는 기준!).| HTTP 메서드 | 역할 (CRUD) | 요청 Body 유무 | 안전성 (Safe) | 멱등성 (Idempotent) |
|---|---|---|---|---|
| GET | 리소스 조회 (Read) | 없음 (Query String 사용) | O (서버 상태 변경 안 함) | O (멱등) |
| POST | 신규 리소스 생성 (Create) | 있음 | X | X (호출할 때마다 중복 생성됨!) |
| PUT | 리소스 전체 덮어쓰기 수정 | 있음 | X | O (몇 번을 덮어써도 결과 동일) |
| PATCH | 리소스 일부 필드만 수정 | 있음 | X | X (증감 연산 등 구현에 따라 비멱등) |
| DELETE | 리소스 삭제 (Delete) | 없음 | X | O (이미 지워진 결과 상태는 동일) |
200 OK (조회/작업 성공), 201 Created (POST 생성 성공), 204 No Content (성공했으나 응답 본문 없음).
- 3xx (리다이렉션): 301 Moved Permanently (영구 주소 이전), 304 Not Modified (브라우저 캐시 재사용).
- 4xx (클라이언트 측 잘못): 400 Bad Request (파라미터/문법 오류), 401 Unauthorized (인증 안 됨 - 로그인 필요), 403 Forbidden (인가 실패 - 로그인은 했으나 관리자 권한 없음), 404 Not Found (URL 리소스 없음).
- 5xx (서버 측 장애): 500 Internal Server Error (서버 코드 예외 발생), 502 Bad Gateway, 503 Service Unavailable (서버 과부하/점검).예제로 살펴보기
쇼핑몰 회원 번호가 42번인 사용자의 정보를 '조회', '이메일 주소만 일부 변경', '회원 탈퇴(삭제)'하는 RESTful API의 (HTTP 메서드 + URI 경로)를 각각 설계하고, 로그인하지 않은 사용자가 마이페이지에 접근했을 때와 일반 회원이 관리자 페이지에 접근했을 때 반환해야 할 HTTP 상태 코드를 구분하시오.- 1) RESTful API 설계 (URI에는 동사 대신 복수형 명사
/users를 사용하고 행위는 HTTP 메서드로 표현합니다): - 42번 회원 조회:GET /users/42- 42번 회원의 이메일만 부분 수정:PATCH /users/42(Body:{"email": "new@example.com"}) - 42번 회원 탈퇴(삭제):DELETE /users/422) 401 vs 403 상태 코드 구분: - 로그인하지 않은(신원 미확인, Unauthenticated) 사용자의 마이페이지 접근:401 Unauthorized- 로그인은 했으나 관리자 권한이 없는(권한 부족, Unauthorized access) 일반 회원의 관리자 페이지 접근:403 Forbidden
3. RESTful API 설계 원칙과 쿠키(Cookie) vs 세션(Session) vs JWT
- RESTful API 핵심 설계 규칙: 1. URI는 리소스(자원)만 나타내므로/getUsers나 /deleteOrder처럼 동사를 쓰지 않고 소문자 복수형 명사(/users, /orders/15/items)로 계층 관계를 표현합니다.
2. 리소스에 대한 행위(CRUD)는 오직 HTTP 메서드(GET, POST, PUT, PATCH, DELETE)로만 표현합니다.
- 웹 인증(Authentication) 3대 방식 비교:
- 쿠키 (Cookie): 브라우저 로컬에 저장되는 작은 텍스트 조각으로, 매 요청마다 자동으로 서버에 전송되지만 탈취·변조 위험이 있습니다(HttpOnly, Secure 옵션 필수).
- 세션 (Session): 민감한 로그인 상태를 서버 메모리나 Redis DB에 저장하고 브라우저에는 난수로 된 세션 ID만 쿠키로 발급합니다. 보안성이 높고 강제 로그아웃이 쉬우나 서버 메모리를 차지합니다.
- JWT (JSON Web Token): 사용자 정보(Payload)에 서버 비밀키로 전자서명(HMAC/RSA)을 한 토큰을 클라이언트에 발급합니다. 서버가 별도 저장소를 둘 필요가 없는 완전한 Stateless 구조라 MSA 분산 서버 환경에 유리하지만, 한 번 발급된 토큰은 만료 전까지 강제 무효화하기 어렵다는 단점이 있어 짧은 Access Token과 긴 Refresh Token을 조합해 사용합니다.JWT 토큰의 Payload(내용물)는 암호화된 것이 아니라 단순 Base64 인코딩된 텍스트이므로 누구나 디코딩해서 눈으로 읽을 수 있습니다(위변조만 불가능할 뿐!). 따라서 JWT Payload에는 비밀번호나 주민등록번호 같은 민감 정보를 절대 넣으면 안 됩니다.참고 근거와 확인 범위
- MDN · Overview of HTTP ↗
클라이언트·서버와 HTTP 요청·응답의 구조
설명·예제·문제 구성 및 오류 수정 책임: 프리런. 위 자료는 표시한 주제를 확인하거나 더 읽기 위한 근거이며, 외부 기관의 공식 수업이나 감수본을 뜻하지 않습니다.
참고 자료 연결 점검: 2026-11-02. 제작 방식·검수 범위와 수정 기록에서 확인 범위를 볼 수 있습니다. 오류는 상단의 의견 보내기 또는 contact@freelearn.io로 알려 주세요.