웹 플랫폼 핵심 개념 지도: URL에서 렌더링과 보안까지

웹 개발2026년 8월 15일글: 홍서진, Duolabs35분 읽기blog model-openai-gpt-5 technical-note web-development web-platform web-platform-core-concepts

웹 개발을 프레임워크 이름으로만 배우면 기술이 바뀔 때마다 지식도 함께 낡아 보입니다. 하지만 브라우저가 주소를 해석하고, 서버와 통신하고, 문서를 파싱하고, 픽셀을 그리는 기본 과정은 훨씬 천천히 바뀝니다. React, Vue, Svelte와 Next.js도 이 과정 위에서 서로 다른 개발 방식을 제공합니다.

이 문서는 웹 페이지 하나가 열리고 상호작용하기까지 만나는 핵심 개념을 한 장의 지도처럼 정리합니다. 각 항목은 짧게 설명하지만, 서로 어떤 순서와 경계로 연결되는지를 놓치지 않는 것이 목적입니다.

웹은 주소로 자원을 찾는 분산 문서 시스템입니다

웹 플랫폼: 브라우저가 구현하는 HTML, CSS, JavaScript와 Web API의 집합입니다. 특정 프레임워크보다 아래에 있으며 웹 애플리케이션이 실행되는 공통 기반입니다.
클라이언트와 서버: 클라이언트는 자원을 요청하고 서버는 요청을 처리해 응답합니다. 한 프로그램이 상황에 따라 두 역할을 모두 맡을 수도 있습니다.
사용자 에이전트: 사용자를 대신해 웹 자원에 접근하는 소프트웨어입니다. 일반적으로 브라우저를 뜻하지만 검색 로봇과 보조 기술도 사용자 에이전트가 될 수 있습니다.
자원: HTML 문서, 이미지, API 응답처럼 URL로 식별할 수 있는 대상입니다. 같은 URL의 표현이 시간과 요청 조건에 따라 달라질 수도 있습니다.
URL: 자원의 위치와 접근 방법을 나타냅니다. 스킴, 호스트, 포트, 경로, 쿼리와 프래그먼트로 구성됩니다.
스킴: URL 앞부분의 https, http 같은 접근 방식을 지정합니다. 웹 페이지는 보안과 API 사용 조건 때문에 일반적으로 HTTPS를 사용합니다.
호스트와 도메인: 호스트는 요청이 향할 네트워크 이름입니다. 도메인은 사람이 관리하기 쉬운 계층형 이름이며 DNS를 통해 주소로 해석됩니다.
포트: 한 호스트 안에서 네트워크 서비스를 구분하는 번호입니다. HTTP와 HTTPS에는 기본 포트가 있어 URL에서 생략할 수 있습니다.
경로: 호스트 내부에서 자원을 구분합니다. 파일 경로처럼 보이더라도 실제 서버 파일 구조와 일치할 필요는 없습니다.
쿼리 문자열: ? 뒤에 검색, 필터와 페이지 같은 요청 매개변수를 표현합니다. 순서와 중복 키의 의미는 애플리케이션 계약이 정합니다.
프래그먼트: # 뒤에 문서 내부 위치나 클라이언트 상태를 나타냅니다. 일반적인 HTTP 요청에는 전송되지 않고 브라우저에서 처리됩니다.
오리진: 스킴, 호스트와 포트의 조합입니다. 브라우저 보안 정책이 서로 신뢰할 수 있는 문맥인지 판단하는 핵심 경계입니다.
사이트: 등록 가능한 도메인을 중심으로 묶은 더 넓은 경계입니다. SameSite 쿠키처럼 오리진보다 넓은 정책에서 사용됩니다.
탐색: 주소 입력, 링크 클릭과 History API 호출로 활성 문서가 바뀌는 과정입니다. 네트워크 요청뿐 아니라 세션 기록과 문서 수명주기도 함께 바뀝니다.

주소 입력 뒤에는 네트워크와 HTTP가 이어집니다

DNS: 도메인 이름을 IP 주소와 다른 레코드로 해석합니다. 브라우저, 운영체제와 재귀 DNS 서버의 캐시가 조회 시간을 줄입니다.
IP 주소: 네트워크에서 호스트나 인터페이스를 식별합니다. 하나의 도메인이 위치와 장애 대응 정책에 따라 여러 주소를 돌려줄 수 있습니다.
라우팅: 패킷이 출발지에서 목적지까지 여러 네트워크를 통과할 경로를 선택합니다. 애플리케이션은 보통 이 과정을 직접 제어하지 않지만 지연과 장애의 영향을 받습니다.
TCP: 순서와 재전송을 제공하는 연결 지향 전송 프로토콜입니다. HTTP/1.1과 HTTP/2는 일반적으로 TLS 아래의 TCP 연결을 사용합니다.
QUIC: UDP 위에서 암호화된 연결과 다중 스트림을 제공하는 전송 프로토콜입니다. HTTP/3의 기반이며 한 스트림의 손실이 다른 스트림을 직접 막지 않도록 설계됐습니다.
TLS: 서버 신원 확인, 키 교환과 암호화를 통해 전송 구간을 보호합니다. HTTPS는 HTTP를 TLS 연결 위에서 사용합니다.
인증서: 공개키와 도메인 이름을 연결하고 인증 기관의 서명으로 신뢰 사슬을 만듭니다. 브라우저는 이름, 유효 기간과 서명 경로를 검증합니다.
HTTP: 자원에 대한 요청과 응답의 의미를 정의하는 애플리케이션 프로토콜입니다. 연결 방식과 메시지 의미를 분리해 여러 전송 버전에서 같은 메서드와 상태 코드를 사용합니다.
HTTP 메서드: GET, POST, PUT, PATCH, DELETE처럼 요청 의도를 나타냅니다. 안전성과 멱등성은 재시도와 캐시 가능성을 판단하는 기준이 됩니다.
안전한 메서드: 서버 상태를 변경하지 않는 읽기 목적의 메서드입니다. GET이 실제 구현에서도 안전해야 프리페치와 크롤링이 예상치 못한 변경을 만들지 않습니다.
멱등성: 같은 요청을 여러 번 실행해도 최종 상태가 한 번 실행한 것과 같다는 성질입니다. 네트워크 오류 뒤의 안전한 재시도 설계에 중요합니다.
상태 코드: 응답 결과를 1xx부터 5xx까지의 범주로 표현합니다. 본문만 보지 않고 리디렉션, 클라이언트 오류와 서버 오류를 기계적으로 구분하게 합니다.
헤더: 콘텐츠 형식, 캐시, 인증과 조건부 요청 같은 메타데이터를 전달합니다. 같은 이름이 요청과 응답에서 서로 다른 역할을 가질 수 있습니다.
메시지 본문: HTML, JSON, 이미지와 파일 같은 실제 표현을 담습니다. 메서드와 상태 코드에 따라 본문이 없거나 의미가 제한될 수 있습니다.
미디어 타입: text/html, application/json처럼 본문의 형식을 설명합니다. 파일 확장자보다 HTTP의 Content-Type이 처리 방법을 결정하는 직접적인 신호입니다.
콘텐츠 협상: 클라이언트가 언어, 압축과 표현 형식의 선호를 보내고 서버가 적절한 표현을 선택하는 과정입니다. 캐시는 어떤 요청 헤더가 응답을 바꾸는지 알아야 합니다.
압축: 텍스트 자원의 전송 크기를 줄입니다. 전송 시간은 줄지만 압축과 해제에 CPU 비용이 들고 이미 압축된 이미지에는 이득이 작습니다.
리디렉션: 서버가 다른 URL로 이동하라고 알리는 응답입니다. 영구성과 메서드 보존 여부가 상태 코드마다 다르므로 로그인과 API에서 구분해야 합니다.
연결 재사용: 여러 요청이 같은 연결을 공유해 핸드셰이크 비용을 줄입니다. HTTP/2와 HTTP/3는 한 연결에서 여러 스트림을 함께 처리할 수 있습니다.

상태와 캐시는 HTTP의 비용을 바꿉니다

무상태성: HTTP 요청 하나는 원칙적으로 필요한 의미를 스스로 담습니다. 로그인 상태와 장바구니는 쿠키, 토큰과 서버 저장소를 이용해 별도로 연결합니다.
쿠키: 서버가 브라우저에 작은 값을 저장하고 조건에 맞는 요청에 다시 보내게 합니다. 도메인, 경로, 만료와 보안 속성이 전송 범위를 제한합니다.
세션: 서버에 상태를 저장하고 쿠키의 식별자로 연결하는 방식입니다. 식별자 유출과 서버 측 만료, 여러 인스턴스 사이의 공유 전략을 고려해야 합니다.
캐시: 이전 응답을 재사용해 네트워크와 서버 작업을 줄입니다. 브라우저 캐시, 공유 프록시와 CDN은 서로 다른 범위에서 같은 HTTP 규칙을 해석합니다.
신선도: 저장된 응답을 서버 확인 없이 재사용할 수 있는 기간입니다. Cache-Control의 max-age 같은 지시어로 정합니다.
재검증: 캐시된 표현이 아직 유효한지 서버에 조건부로 묻습니다. 바뀌지 않았다면 본문 없이 304 Not Modified로 응답할 수 있습니다.
ETag: 서버가 표현 버전을 식별하기 위해 주는 검증자입니다. 콘텐츠 해시와 비슷하게 만들 수 있지만 생성 규칙은 서버 구현에 달려 있습니다.
Last-Modified: 자원의 마지막 수정 시각을 이용하는 검증자입니다. 시간 정밀도와 실제 변경 의미 때문에 ETag보다 구분력이 약할 수 있습니다.
Vary: 어떤 요청 헤더가 응답 표현을 바꾸는지 캐시에 알립니다. 잘못 설정하면 다른 언어나 인코딩의 응답이 섞이거나 캐시 효율이 급격히 떨어집니다.
CDN: 여러 지역의 엣지에서 정적 자원과 캐시 가능한 응답을 제공합니다. 원본 서버 부하와 사용자까지의 왕복 시간을 줄이지만 무효화와 캐시 키 설계가 필요합니다.
서비스 워커 캐시: 애플리케이션 코드가 요청을 가로채고 Cache Storage의 응답을 선택할 수 있게 합니다. HTTP 캐시와 별개이므로 갱신 규칙을 직접 책임져야 합니다.

HTML은 문서의 의미와 구조를 만듭니다

HTML: 콘텐츠의 구조와 의미를 표현하는 마크업 언어입니다. 요소 선택은 기본 동작, 접근성 트리와 검색 해석에 영향을 줍니다.
요소와 속성: 요소는 문서의 구성 단위이고 속성은 요소의 상태와 추가 정보를 나타냅니다. 가능한 값과 동작은 요소별 계약으로 정해집니다.
시맨틱 HTML: 모양이 아니라 의미에 맞는 요소를 사용합니다. 제목, 내비게이션, 버튼과 폼의 의미가 브라우저와 보조 기술에 전달됩니다.
HTML 파서: 바이트로 받은 마크업을 토큰화하고 오류 복구 규칙에 따라 트리를 만듭니다. 잘못 닫힌 태그도 일정한 규칙으로 처리되므로 원본 문자열과 DOM 구조가 다를 수 있습니다.
DOM: 문서를 메모리의 노드 트리로 표현하는 객체 모델입니다. JavaScript는 DOM API로 구조, 속성과 텍스트를 읽고 바꿉니다.
노드 트리: 문서, 요소, 텍스트와 주석 노드의 부모 자식 관계입니다. 이벤트 전파와 선택자 탐색도 이 구조를 기준으로 동작합니다.
문서 수명주기: 파싱, 대화 가능 상태와 전체 자원 로드 같은 단계가 있습니다. 실행 시점이 중요한 스크립트는 DOMContentLoaded와 load의 차이를 알아야 합니다.
스크립트 로딩: 일반 스크립트는 파싱을 멈출 수 있고 defer, async와 모듈 스크립트는 다운로드와 실행 순서를 다르게 조정합니다.
폼: 입력, 선택과 제출을 위한 브라우저 기본 계약입니다. 이름과 값이 데이터 집합을 만들고 메서드와 인코딩 방식에 따라 서버로 전송됩니다.
제약 조건 검증: required, 입력 타입과 패턴 같은 선언으로 기본 유효성 검사를 제공합니다. 서버 검증을 대체하지 않지만 일관된 사용자 피드백의 첫 단계가 됩니다.
이미지와 반응형 자원: srcset, sizes와 picture는 화면 조건에 맞는 이미지 후보를 브라우저가 선택하게 합니다. CSS로 축소하는 것과 실제 전송 크기를 줄이는 것은 다릅니다.
오디오와 비디오: 브라우저가 미디어 재생, 자막과 제어 인터페이스를 제공합니다. 코덱 지원과 자동 재생 정책은 사용자 에이전트마다 다를 수 있습니다.
iframe: 한 문서 안에 별도의 탐색 문맥을 삽입합니다. 오리진 경계와 sandbox, 권한 정책을 이용해 포함된 콘텐츠의 능력을 제한할 수 있습니다.
Shadow DOM: 컴포넌트 내부 DOM과 스타일의 경계를 만듭니다. 완전한 보안 격리가 아니라 캡슐화와 스타일 범위 관리를 위한 기능입니다.
Custom Elements: 이름과 수명주기 콜백을 가진 사용자 정의 HTML 요소를 등록합니다. Shadow DOM, 템플릿과 함께 Web Components를 구성합니다.

CSS는 규칙을 계산해 레이아웃과 픽셀로 바꿉니다

CSS: 선택자와 선언으로 문서의 표현을 정의하는 스타일 언어입니다. 여러 출처의 규칙이 충돌할 때 캐스케이드가 최종 값을 정합니다.
선택자: 어떤 요소에 규칙을 적용할지 지정합니다. 구조에 과도하게 의존한 선택자는 마크업 변경 비용과 특이성 경쟁을 키웁니다.
캐스케이드: 출처, 중요도, 레이어, 특이성과 선언 순서를 비교해 이긴 값을 고릅니다. CSS의 이름에 들어 있는 핵심 동작입니다.
특이성: 경쟁하는 선택자의 우선순위를 계산합니다. 더 긴 선택자가 항상 이기는 것이 아니라 ID, 클래스와 타입 선택자의 조합으로 비교합니다.
상속: 일부 계산값이 부모에서 자식으로 전달됩니다. 텍스트 관련 속성은 주로 상속되지만 크기와 배치 속성은 대체로 상속되지 않습니다.
사용자 지정 속성: --name 형태의 값을 선언하고 var()로 참조합니다. 상속과 캐스케이드를 따르므로 디자인 토큰과 문맥별 테마에 사용할 수 있습니다.
박스 모델: 콘텐츠, 패딩, 테두리와 마진으로 요소의 사각 영역을 계산합니다. box-sizing은 선언한 크기에 어느 영역까지 포함할지 바꿉니다.
일반 흐름: 별도 배치 방식을 지정하지 않았을 때 블록과 인라인 콘텐츠가 놓이는 기본 규칙입니다. 레이아웃 문제를 풀 때 기준점이 됩니다.
포지셔닝: relative, absolute, fixed, sticky로 일반 흐름과 다른 기준에서 요소를 배치합니다. 포함 블록과 스크롤 컨테이너가 기준을 결정합니다.
Flexbox: 한 축을 중심으로 항목의 크기, 정렬과 남는 공간을 배분합니다. 컴포넌트 내부의 행과 열 배치에 적합합니다.
Grid: 행과 열의 두 축으로 영역을 정의하고 항목을 배치합니다. 페이지와 복합 컴포넌트의 큰 구조를 표현하기 좋습니다.
반응형 디자인: 화면과 입력 환경이 달라도 콘텐츠와 기능을 유지하도록 레이아웃을 조정합니다. 고정된 기기 목록보다 사용 가능한 공간과 콘텐츠를 기준으로 설계합니다.
미디어 쿼리: 뷰포트 크기, 색상 체계와 입력 장치 같은 사용자 환경 조건에 따라 규칙을 적용합니다.
컨테이너 쿼리: 뷰포트가 아니라 컴포넌트를 담은 컨테이너의 크기와 스타일을 기준으로 변형합니다. 재사용 컴포넌트가 배치 위치에 맞춰 스스로 적응하게 합니다.
쌓임 맥락: 요소가 앞뒤로 그려지는 독립적인 계층을 만듭니다. 큰 z-index만으로 다른 쌓임 맥락의 요소를 넘어설 수는 없습니다.
CSSOM: 파싱된 스타일시트와 CSS 규칙을 객체로 표현합니다. DOM과 함께 렌더링 계산의 입력이 됩니다.
스타일 계산: 각 요소에 적용될 선언을 찾고 상속과 캐스케이드를 거쳐 계산값을 만듭니다.
레이아웃: 요소의 크기와 위치를 계산합니다. DOM이나 스타일 변경이 기하 정보에 영향을 주면 일부 레이아웃을 다시 계산할 수 있습니다.
페인트: 배경, 글자, 테두리와 그림자를 그리기 위한 명령을 만듭니다. 레이아웃이 바뀌지 않아도 시각 속성 변경으로 다시 발생할 수 있습니다.
합성: 여러 렌더링 레이어를 최종 화면으로 조합합니다. 변형과 투명도 애니메이션은 조건에 따라 레이아웃과 페인트 없이 합성 단계에서 처리될 수 있습니다.

JavaScript는 이벤트 루프 위에서 문서와 API를 연결합니다

ECMAScript: JavaScript 언어의 문법과 실행 의미를 정의하는 표준입니다. DOM, Fetch와 스토리지는 언어 자체가 아니라 브라우저가 제공하는 Web API입니다.
JavaScript 엔진: 소스 코드를 파싱하고 바이트코드나 기계어로 실행합니다. 최적화 컴파일과 가비지 컬렉션은 엔진 구현에 속합니다.
실행 컨텍스트: 코드가 평가될 때 변수 환경, 현재 함수와 this 같은 실행 정보를 담습니다. 함수 호출은 새 컨텍스트를 호출 스택에 올립니다.
호출 스택: 현재 실행 중인 함수의 중첩 순서를 관리합니다. 동기 함수가 끝나야 아래 호출로 돌아갈 수 있습니다.
힙과 가비지 컬렉션: 객체는 동적으로 할당된 메모리에 저장되고 더 이상 도달할 수 없으면 회수 대상이 됩니다. 이벤트 리스너와 전역 참조는 예상보다 오래 객체를 살려 둘 수 있습니다.
스코프와 클로저: 스코프는 이름을 찾을 수 있는 범위이고 클로저는 함수가 생성될 때의 렉시컬 환경을 유지하는 성질입니다.
프로토타입: 객체가 다른 객체에서 속성과 동작을 위임받는 연결입니다. class 문법도 내부적으로 이 모델 위에서 동작합니다.
모듈: 파일 단위로 값을 내보내고 가져오는 의존성 경계를 제공합니다. 정적 import는 브라우저와 빌드 도구가 실행 전에 그래프를 분석하게 합니다.
이벤트 루프: 작업, 사용자 입력, 네트워크 콜백과 렌더링 기회를 조정합니다. 이벤트 루프 자체가 운영체제 스레드와 일대일로 대응한다는 뜻은 아닙니다.
태스크: 이벤트 전달, 타이머와 파싱 같은 작업 단위입니다. 한 태스크가 오래 실행되면 같은 이벤트 루프의 입력과 렌더링이 기다립니다.
마이크로태스크: 현재 태스크가 끝난 뒤 다음 태스크 전에 처리되는 작업입니다. Promise 반응이 대표적이며 계속 추가하면 렌더링 기회를 지연시킬 수 있습니다.
Promise: 미래의 완료 값이나 실패를 표현하고 비동기 연산을 연결합니다. 작업을 별도 스레드로 옮기는 기능이 아니라 결과 전달 규약입니다.
async와 await: Promise 기반 흐름을 순차 코드처럼 작성하게 합니다. await는 함수의 나머지를 중단해 마이크로태스크로 이어가지만 전체 이벤트 루프를 막지는 않습니다.
이벤트 전파: 이벤트가 캡처 단계로 내려가 대상에 도달한 뒤 버블 단계로 올라옵니다. 위임은 이 경로를 이용해 여러 자식의 이벤트를 공통 조상에서 처리합니다.
Web API: 네트워크, 시간, 문서, 장치와 저장소에 접근하는 브라우저 인터페이스입니다. 지원 여부뿐 아니라 권한, 보안 문맥과 사용자 동작 조건을 확인해야 합니다.

브라우저 API는 네트워크, 저장소와 백그라운드 작업을 엽니다

Fetch API: HTTP 요청과 응답을 Promise와 스트림 중심으로 다룹니다. HTTP 오류 상태가 자동으로 Promise 거부가 되지는 않으므로 상태를 확인해야 합니다.
Streams API: 큰 데이터를 작은 청크로 읽고 변환하며 목적지로 전달합니다. 전체 응답을 메모리에 올리기 전에 처리를 시작할 수 있습니다.
WebSocket: 한 연결에서 서버와 클라이언트가 양방향 메시지를 주고받습니다. 재연결, 인증 갱신과 흐름 제어는 애플리케이션이 설계해야 합니다.
Server-Sent Events: 서버에서 브라우저로 텍스트 이벤트를 지속적으로 보냅니다. 단방향 갱신이 충분할 때 HTTP 기반의 단순한 선택지가 됩니다.
WebRTC: 브라우저 사이의 실시간 음성, 영상과 데이터 통신을 위한 API 집합입니다. 시그널링과 NAT 통과, 미디어 품질 제어가 함께 필요합니다.
Web Worker: DOM과 분리된 실행 문맥에서 JavaScript 작업을 처리합니다. 메인 스레드와는 메시지 또는 이전 가능한 객체로 데이터를 교환합니다.
Service Worker: 페이지와 네트워크 사이에서 요청, 캐시와 푸시 이벤트를 처리하는 이벤트 기반 워커입니다. HTTPS와 별도의 설치 및 활성화 수명주기를 요구합니다.
IndexedDB: 브라우저에 구조화된 데이터를 비동기로 저장하는 트랜잭션형 데이터베이스입니다. 큰 오프라인 데이터와 인덱스 조회에 적합합니다.
Web Storage: localStorage와 sessionStorage에 문자열 키와 값을 저장합니다. 동기 API이므로 큰 데이터나 빈번한 작업에는 적합하지 않습니다.
History API: 세션 기록을 이동하거나 새 항목을 추가합니다. 클라이언트 라우팅은 URL과 화면 상태, 서버의 직접 접근 응답을 함께 맞춰야 합니다.
URL API: URL을 문자열 연결 대신 구조화된 객체로 파싱하고 변경합니다. 상대 URL 해석과 쿼리 매개변수 처리를 일관되게 할 수 있습니다.
권한 API: 카메라, 위치 같은 기능의 권한 상태를 조회합니다. 실제 요청은 사용자 동작과 브라우저 정책에 따라 별도 승인이 필요할 수 있습니다.
Page Visibility API: 문서가 사용자에게 보이는지 알려 줍니다. 숨겨진 탭의 애니메이션, 폴링과 미디어 작업을 줄이는 데 사용할 수 있습니다.

렌더링 방식과 성능은 사용자에게 보이는 시간으로 판단합니다

CSR: 브라우저가 JavaScript를 실행해 화면의 대부분을 구성하는 방식입니다. 상호작용은 유연하지만 초기 HTML, 실행 비용과 오류 시 대체 경로를 고려해야 합니다.
SSR: 요청 시 서버가 HTML을 만들어 전송합니다. 첫 콘텐츠를 일찍 보여 줄 수 있지만 서버 실행 비용과 클라이언트 상태 연결이 생깁니다.
정적 생성: 빌드나 갱신 시점에 HTML을 미리 만들어 제공합니다. 변경 빈도가 낮은 콘텐츠에 유리하며 새 데이터가 반영되는 시점을 명확히 해야 합니다.
하이드레이션: 서버가 만든 HTML에 클라이언트 JavaScript의 상태와 이벤트를 연결합니다. 서버와 클라이언트 출력이 다르면 불일치와 재렌더링이 발생할 수 있습니다.
점진적 향상: 기본 HTML 기능을 먼저 제공하고 CSS와 JavaScript로 경험을 강화합니다. 일부 자원 실패와 다양한 사용자 환경에서도 핵심 작업을 남깁니다.
코드 분할: 필요한 시점과 경로별로 JavaScript 묶음을 나눕니다. 초기 전송량은 줄지만 요청 수, 중복 의존성과 로딩 상태 관리가 늘 수 있습니다.
지연 로딩: 화면 밖 이미지와 아직 필요하지 않은 코드를 나중에 가져옵니다. 핵심 콘텐츠까지 늦추지 않도록 우선순위를 구분해야 합니다.
리소스 힌트: preload, preconnect와 dns-prefetch로 앞으로 필요한 자원의 우선순위나 연결 준비를 브라우저에 알립니다. 과도한 힌트는 실제 핵심 자원과 경쟁합니다.
핵심 렌더링 경로: HTML, CSS와 JavaScript가 DOM, CSSOM, 레이아웃과 페인트로 이어지는 경로입니다. 첫 화면에 필요한 작업을 줄이면 사용자가 콘텐츠를 더 빨리 봅니다.
LCP: 뷰포트의 주요 콘텐츠가 표시되는 시간을 측정하는 Core Web Vital입니다. 서버 응답, 자원 우선순위와 렌더링 지연이 함께 영향을 줍니다.
INP: 사용자 상호작용 뒤 다음 화면이 표시될 때까지의 응답성을 측정합니다. 긴 태스크와 복잡한 렌더링 작업이 값을 악화시킬 수 있습니다.
CLS: 예상하지 못한 레이아웃 이동의 누적 정도를 측정합니다. 이미지 크기 예약과 동적 콘텐츠 삽입 위치가 중요합니다.
Long Task: 메인 스레드를 오래 점유해 입력 처리를 늦추는 작업입니다. 큰 작업을 나누거나 워커로 옮길 후보를 찾는 신호가 됩니다.
Performance API: 탐색, 자원, 사용자 정의 구간의 시간을 브라우저에서 측정합니다. 실험실 수치와 실제 사용자 환경의 분포를 함께 봐야 합니다.
RUM: 실제 사용자의 브라우저에서 성능과 오류를 수집합니다. 기기, 네트워크와 지역의 차이를 반영하지만 개인정보와 표본 편향을 관리해야 합니다.

보안은 오리진과 실행 능력의 경계를 지키는 일입니다

동일 출처 정책: 서로 다른 오리진의 문서와 스크립트가 민감한 데이터를 자유롭게 읽지 못하게 제한합니다. 브라우저 보안 모델의 기본 경계입니다.
CORS: 서버가 다른 오리진의 브라우저 코드에 응답 읽기를 허용하는 HTTP 헤더 규약입니다. 서버 간 요청을 막는 방화벽이나 인증 방식은 아닙니다.
프리플라이트: 실제 교차 출처 요청 전에 OPTIONS로 메서드와 헤더 허용 여부를 확인합니다. 모든 CORS 요청에 발생하는 것은 아닙니다.
CSP: 문서가 실행하거나 불러올 수 있는 스크립트, 스타일과 프레임의 출처를 제한합니다. XSS 피해를 줄이는 방어층이지만 안전한 출력 처리 자체를 대신하지 않습니다.
XSS: 신뢰하지 않은 입력이 HTML이나 JavaScript 실행 문맥에 들어가 공격자 코드가 실행되는 취약점입니다. 문맥별 출력 인코딩과 안전한 DOM API가 기본 방어입니다.
CSRF: 브라우저가 자동으로 보내는 인증 정보를 이용해 사용자가 원하지 않은 상태 변경 요청을 만들게 합니다. SameSite 쿠키, CSRF 토큰과 요청 출처 검증을 조합합니다.
SRI: 외부 자원의 해시를 문서에 적어 받은 파일이 기대한 내용인지 검증합니다. CDN이나 외부 호스트에서 스크립트와 스타일을 가져올 때 공급망 변조를 탐지합니다.
Trusted Types: 문자열이 위험한 DOM 실행 지점으로 직접 들어가는 경로를 정책 객체로 제한합니다. 적용 전 기존 코드의 삽입 지점을 파악해야 합니다.
Secure Context: HTTPS처럼 인증되고 암호화된 문맥에서만 민감한 Web API를 제공하는 기준입니다. 카메라, 클립보드와 서비스 워커가 대표적으로 영향을 받습니다.
쿠키 보안 속성: Secure는 HTTPS 전송만, HttpOnly는 스크립트 접근 제한, SameSite는 교차 사이트 전송 조건을 정합니다. 각 속성은 다른 위협을 줄입니다.
클릭재킹: 투명하거나 위장한 프레임으로 사용자의 클릭을 다른 페이지에 전달하는 공격입니다. CSP의 frame-ancestors 같은 정책으로 포함 가능한 부모를 제한합니다.
샌드박스: iframe과 다운로드된 코드의 실행 능력을 제한된 목록으로 줄입니다. 필요한 권한을 하나씩 열어 주는 방식이 안전합니다.
교차 출처 격리: COOP와 COEP 같은 헤더로 다른 출처 문맥과의 프로세스 및 자원 공유 조건을 강화합니다. 고해상도 공유 메모리 기능을 안전하게 쓰기 위한 전제가 되기도 합니다.
권한 정책: 포함된 문서와 하위 프레임이 카메라, 위치와 전체 화면 같은 기능을 사용할 수 있는 범위를 정합니다.

접근성과 국제화는 별도 기능이 아니라 플랫폼 계약입니다

접근성 트리: DOM과 스타일에서 사용자가 인식할 이름, 역할, 상태와 관계를 만들어 보조 기술에 전달합니다. 화면에 보이는 모양과 접근성 트리는 같지 않을 수 있습니다.
키보드 접근: 모든 핵심 기능을 포인터 없이 탐색하고 실행할 수 있어야 합니다. 자연스러운 탭 순서와 보이는 포커스가 함께 필요합니다.
포커스 관리: 현재 입력을 받을 요소와 이동 순서를 제어합니다. 모달, 동적 화면 전환과 오류 발생 뒤에는 포커스를 의미 있는 위치로 옮겨야 합니다.
접근 가능한 이름: 버튼과 입력이 보조 기술에 어떤 이름으로 전달되는지 정합니다. 보이는 텍스트, label, 대체 텍스트와 ARIA 속성이 계산에 참여합니다.
ARIA: 기본 HTML로 표현하기 어려운 역할, 상태와 관계를 보완합니다. 잘못된 ARIA는 의미 없는 요소보다 더 혼란스러울 수 있어 기본 요소를 먼저 사용합니다.
대체 텍스트: 이미지를 볼 수 없을 때 같은 목적과 정보를 전달합니다. 장식 이미지는 읽지 않게 하고 기능 이미지는 동작을 설명해야 합니다.
색 대비: 글자와 인터페이스 요소를 배경에서 구분할 수 있게 합니다. 색만으로 상태를 전달하지 않는 것도 함께 확인합니다.
동작 감소: 사용자의 prefers-reduced-motion 설정에 맞춰 불필요한 이동과 확대 효과를 줄입니다. 핵심 상태 변화까지 숨기지는 않아야 합니다.
WCAG: 웹 콘텐츠 접근성을 인식 가능성, 운용 가능성, 이해 가능성과 견고성의 원칙으로 정리한 국제 표준입니다. 성공 기준은 A, AA와 AAA 수준으로 나뉩니다.
국제화: 여러 언어와 문화권을 지원할 수 있도록 코드와 데이터 구조를 설계하는 일입니다. 번역을 실제로 적용하는 현지화와 구분합니다.
유니코드: 여러 문자 체계에 코드 포인트를 부여하는 표준입니다. 사용자가 보는 한 글자가 여러 코드 포인트로 구성될 수 있어 문자열 길이와 정규화에 주의해야 합니다.
로케일: 언어와 지역에 따른 날짜, 숫자, 통화와 정렬 규칙의 묶음입니다. 문자열을 직접 조립하기보다 국제화 API의 형식 규칙을 사용합니다.
양방향 텍스트: 왼쪽에서 오른쪽으로 쓰는 문자와 오른쪽에서 왼쪽으로 쓰는 문자가 한 문서에 섞일 때 표시 순서를 계산합니다. 문서 방향과 격리 마크가 데이터 혼동을 줄입니다.

호환성과 검증은 배포 뒤에도 이어집니다

브라우저 호환성: 표준에 포함됐다는 사실과 모든 사용자 환경에서 사용할 수 있다는 사실은 다릅니다. 지원 범위와 실제 대상 브라우저를 함께 확인합니다.
기능 탐지: 브라우저 이름을 추측하지 않고 필요한 API와 문법의 존재를 검사합니다. 새 기능이 없을 때의 대체 흐름을 결정하는 기준이 됩니다.
폴리필: 오래된 환경에 새 API와 비슷한 동작을 코드로 제공합니다. 모든 문법과 성능 특성을 완전히 재현할 수 있는 것은 아닙니다.
점진적 배포: 변경을 일부 사용자나 경로에 먼저 노출해 오류와 성능 영향을 관찰합니다. 클라이언트 캐시 때문에 서버 코드보다 롤백이 느릴 수 있습니다.
소스 맵: 변환되고 압축된 코드 위치를 원본 소스와 연결합니다. 오류 분석에 유용하지만 공개 범위와 원본 노출 정책을 정해야 합니다.
브라우저 개발자 도구: DOM, 스타일, 네트워크, 성능, 저장소와 접근성 트리를 관찰합니다. 추측보다 실제 브라우저가 계산한 결과를 확인하는 출발점입니다.
단위 테스트: 함수와 작은 모듈의 규칙을 빠르게 검증합니다. 실제 브라우저 레이아웃과 네트워크 경계까지 보장하지는 않습니다.
통합 테스트: DOM, API와 저장소처럼 여러 경계가 함께 동작하는지 확인합니다. 테스트 대역이 실제 플랫폼 의미를 지나치게 단순화하지 않았는지 봐야 합니다.
E2E 테스트: 실제 브라우저에서 사용자 흐름 전체를 실행합니다. 신뢰도는 높지만 실행 시간과 실패 원인 분석 비용도 커집니다.
접근성 검사: 자동 규칙 검사와 키보드, 스크린 리더의 수동 검증을 함께 사용합니다. 자동 도구만으로 문맥과 사용성을 모두 판단할 수는 없습니다.
합성 모니터링: 정해진 위치와 환경에서 주기적으로 시나리오를 실행합니다. 장애를 일정하게 비교하기 좋지만 실제 사용자 분포를 모두 반영하지는 않습니다.
오류 수집: 브라우저 예외, 처리되지 않은 Promise 거부와 자원 실패를 문맥과 함께 기록합니다. 사용자 정보와 입력값이 로그에 섞이지 않도록 수집 범위를 제한해야 합니다.

한 번의 페이지 탐색에서 개념들이 만나는 순서

URL 입력
  -> DNS 조회
  -> TCP 또는 QUIC 연결
  -> TLS 검증
  -> HTTP 요청과 캐시 확인
  -> HTML 스트리밍과 파싱
  -> CSS, JavaScript, 이미지 추가 요청
  -> DOM과 CSSOM 구성
  -> 스타일 계산, 레이아웃, 페인트, 합성
  -> JavaScript 이벤트와 Web API 실행
  -> 사용자 입력, 네트워크 갱신, 다시 렌더링

이 흐름이 중요한 이유는 문제가 보이는 위치와 원인이 생긴 위치가 다르기 때문입니다. 버튼이 늦게 반응할 때 서버가 느린 것인지, 긴 JavaScript 태스크가 입력을 막는 것인지, 스타일 변경이 큰 레이아웃을 유발한 것인지 먼저 나눌 수 있어야 합니다. CORS 오류도 네트워크 연결 실패가 아니라 브라우저가 응답 읽기를 제한한 결과일 수 있습니다.

처음 공부한다면 이 순서가 좋습니다

URL, DNS, HTTP 요청과 응답을 익혀 브라우저와 서버의 경계를 이해합니다.
HTML과 시맨틱 요소로 문서 구조를 만들고 기본 폼 동작을 확인합니다.
CSS의 캐스케이드, 박스 모델, 일반 흐름, Flexbox와 Grid를 순서대로 연결합니다.
JavaScript의 스코프, 객체, 함수, 모듈과 비동기 흐름을 익힙니다.
DOM 이벤트, Fetch, 저장소와 History API로 문서와 외부 상태를 연결합니다.
렌더링 경로와 Core Web Vitals를 실제 개발자 도구의 측정값으로 확인합니다.
동일 출처 정책, CORS, CSP, 쿠키와 입력 처리를 하나의 신뢰 경계로 봅니다.
키보드, 접근성 트리와 국제화를 구현 마지막이 아니라 구조 설계 단계에 포함합니다.

특정 프레임워크는 4단계 이후에 올리는 편이 이해하기 쉽습니다. 프레임워크가 대신 처리하는 DOM 변경, 라우팅, 데이터 요청과 하이드레이션을 플랫폼 개념으로 다시 설명할 수 있다면 도구가 바뀌어도 판단 기준이 남습니다.

이 문서는 독립적인 심화 글의 허브입니다

이후의 심화 글은 순서 없이 각 문서만 읽어도 이해되도록 작성하고 web-platform-core-concepts 태그로 연결합니다. 새 글이 발행되면 이 문서의 관련 개념에도 직접 링크를 추가합니다.

먼저 확장하기 좋은 주제는 다음과 같습니다.

URL과 오리진: 주소 하나가 보안 경계가 되는 과정
HTTP 캐시: Cache-Control, ETag와 Vary의 실제 역할
브라우저 렌더링: DOM에서 레이아웃과 합성까지
이벤트 루프: 태스크, 마이크로태스크와 렌더링 기회
CORS: 단순 요청과 프리플라이트를 구분하는 방법
쿠키 보안: SameSite, Secure와 HttpOnly의 차이
웹 성능 측정: LCP, INP와 CLS를 원인으로 연결하는 법
웹 접근성: 시맨틱 HTML에서 접근성 트리까지