웹을 처음 배우면 HTML, CSS, JavsScript부터 떠올리기 쉽다.
그런데 이번 이론 파트를 관통하는 핵심은 기술 목록이 아니라 구조였다.
웹은 "페이지를 보는 것"이 아니라,
클라이언트가 요청하고 서버가 응답하는 통신 과정이다.
이 관점에서 보면 URL·API·DB는 개별 기술이 아니라 하나의 흐름 안에 놓인 구성 요소다.
1. 웹은 대화 구조 위에 세워진다
Client ↔ Server
웹에는 항상 두 주체가 있다.
- Client: 요청(request)을 보내는 쪽
- Server: 응답(response)을 반환하는 쪽
이 관계는 절대적인 역할이 아니라 상황에 따라 바뀔 수 있다.
서버도 다른 서버에 요청을 보내는 순간 클라이언트가 될 수 있다.
브라우저는 화면이 아니라 해석기다
브라우저는 서버에서 받은 코드를 그대로 "보여주는" 게 아니라,
해석해서 화면으로 번역(렌더링) 한다.
- 서버 → HTML/CSS/JS 같은 리소스 전달
- 브라우저 → 코드를 읽고 화면을 구성
즉, 웹을 이해한다는 건 "화면"이 아니라 "요청·응답·해석"의 흐름을 이해하는 것이다.
위치를 알아야 요청할 수 있다
IP
인터넷에 연결된 장치가 가지는 고유한 숫자 주소.
DNS
숫자(IP)를 사람이 읽기 쉬운 이름(도메인)으로 바꿔주는 시스템.
URL
서버 어디에 있는 무엇을 요청할지 지정하는 상세 주소.
여기서 URL은 단순한 문자열이 아니라 요청을 구체화하는 구조다.
음식점 비유로 보면 URL은 "주소"라기보다 "주문서"에 가깝다.
- Host → 건물(가게) 주소
- Path → 몇 번 방 / 어떤 메뉴판
- Query → 추가 옵션(조건)
- Anchor → 내부 특정 위치
URL은 자원을 지정하고 조건을 붙인다
Path Parameter
예시:
/user/123
/products/5- 경로에 포함되는 값
- 특정 자원을 직접 지칭
- 보통 "필수 정보"에 가깝다
"이 대상 하나를 주세요."
Query Parameter
예시:
/products?category=shoes
/search?keyword=react&page=2?key=value형태- 필터링/정렬/조건 추가
- 보통 "선택 옵션"에 가깝다
"이 조건에 맞는 것들을 주세요."
Path vs Query를 구분하면 보이는 것
/users/1→ 1번 유저라는 자원 요청/users?age=20→ 20살 유저 검색 조건
Path는 "대상", Query는 "조건".
이 구분은 URL을 구조적으로 이해하는 기준이 된다.
서버는 기억한다
Database
요청과 응답이 반복되면 서버는 데이터를 저장해야 한다.
DB는 단순 저장이 아니라, 데이터의 구조·보안·동시성을 고려하는 시스템이다.
관계형 vs 비관계형
- 관계형(RDBMS): 테이블 기반, 관계 설정, SQL로 질의
- 비관계형(NoSQL): 유연한 구조, 대규모/실시간 데이터에 유리
대부분의 서비스는 중요한 데이터(회원/결제 등)는 관계형에 안정적으로 둔다.
프로그램은 규칙에 따라 대화한다
API
클라이언트가 서버 기능을 사용할 수 있게 해주는 공식 창구.
서버 내부 구현을 몰라도 "정해진 규칙대로 요청"하면 결과를 받을 수 있다.
JSON
클라이언트-서버가 데이터를 주고받을 때 널리 쓰는 형식.
사람이 읽기 쉽고, 다양한 언어에서 공통으로 사용된다.
웹은 점점 애플리케이션이 된다
CSR
예전에는 페이지 이동마다 화면 전체를 다시 받아오는 방식이 일반적이었다.
하지만 최근 웹은 필요한 데이터만 추가로 요청해 화면을 갱신한다.
웹은 문서 중심에서 애플리케이션 중심으로 진화하고 있다.
