Conceptly

Web Development 시각적으로 이해하기

각 개념의 아키텍처를 애니메이션 다이어그램으로 살펴보세요. 카드를 클릭하면 더 깊은 내용을 확인할 수 있습니다.

🌐Browser🍪Cookie🖥️Server
🍪

Cookie

브라우저와 서버 사이에 상태를 유지하는 작은 텍스트 조각

HTTP Cookie는 서버가 브라우저에 저장을 요청하는 작은 텍스트 데이터입니다. 브라우저는 이후 같은 서버로 요청을 보낼 때마다 해당 쿠키를 자동으로 함께 보냅니다. HTTP 프로토콜 자체는 이전 요청을 기억하지 않는 무상태 구조이기 때문에, 쿠키가 없으면 서버는 매 요청이 누구에게서 온 것인지 알 수 없습니다. 쿠키는 이 공백을 메워 로그인 유지, 장바구니 기억, 사용자 설정 보존 같은 상태 기반 웹 경험을 가능하게 합니다. 쿠키에는 이름-값 쌍 외에도 만료 시간, 적용 도메인과 경로, 보안 속성(HttpOnly, Secure, SameSite)이 포함되어 있어 언제, 어디로, 어떻게 전송될지를 세밀하게 제어할 수 있습니다.

💻Client📋Session🗄️Server Store
📋

Session

서버가 사용자별 상태를 유지하는 연결 고리

세션(Session)은 서버가 개별 사용자의 상태를 일정 기간 동안 유지하는 메커니즘입니다. HTTP는 요청마다 독립적이어서 이전 요청의 맥락을 기억하지 않지만, 세션은 고유한 Session ID를 발급하고 그 ID에 연결된 데이터를 서버 측에 보관함으로써 여러 요청에 걸친 연속적인 상호작용을 가능하게 합니다. 사용자가 로그인하면 서버는 세션을 생성하고, 세션 ID를 쿠키로 클라이언트에 전달합니다. 이후 요청에서 브라우저가 이 쿠키를 보내면 서버는 세션 저장소에서 해당 사용자의 상태를 찾아 복원합니다.

📜JavaScript💾Web Storage🌐Browser
💾

Web Storage

브라우저에 키-값 데이터를 저장하는 클라이언트 측 API

Web Storage API는 브라우저에서 키-값 형태의 데이터를 저장할 수 있는 클라이언트 측 저장소입니다. localStorage는 브라우저를 닫아도 데이터가 유지되고, sessionStorage는 탭을 닫으면 삭제됩니다. 쿠키와 달리 서버로 자동 전송되지 않으며, 도메인당 5~10MB의 넉넉한 용량을 갖고 있어 클라이언트에서만 쓰는 데이터를 저장하기에 적합합니다. setItem, getItem, removeItem 같은 간단한 API로 동기적으로 데이터를 읽고 쓸 수 있습니다.

🌐Origin A🛡️CORS🖥️Origin B
🛡️

CORS

다른 출처의 리소스 요청을 제어하는 브라우저 보안 메커니즘

CORS(Cross-Origin Resource Sharing)는 웹 브라우저가 한 출처(origin)에서 로드된 페이지가 다른 출처의 리소스에 접근할 때, 서버가 명시적으로 허용한 경우에만 응답을 전달하도록 제어하는 HTTP 헤더 기반 메커니즘입니다. 출처란 프로토콜, 호스트, 포트의 조합이며, 이 세 가지 중 하나라도 다르면 다른 출처로 간주됩니다.

📄Page🧱CSP📦Resource
🧱

CSP

페이지에서 로드할 수 있는 리소스를 제한하는 보안 정책

CSP는 서버가 응답 헤더에 '이 페이지는 어디에서 온 스크립트·스타일·이미지까지 믿을 것인가'를 적어 두고, 브라우저가 그 범위를 넘는 리소스를 실행하지 못하게 만드는 정책입니다. 입력 검증이 한 군데라도 새면 스크립트가 페이지 안으로 들어올 수 있는데, CSP는 그 코드가 실제로 실행되는 마지막 문에서 한 번 더 막아 줍니다. 그래서 XSS 피해 범위를 줄이는 브라우저 측 방어선으로 읽는 편이 정확합니다.

📄HTML🌳DOM🖥️화면
🌳

DOM

HTML 문서를 프로그래밍 가능한 객체 트리로 표현하는 인터페이스

DOM(Document Object Model)은 브라우저가 HTML 문서를 파싱하여 만드는 트리 구조의 객체 모델입니다. 자바스크립트는 DOM API를 통해 문서의 요소를 조회하고, 추가하고, 수정하고, 삭제할 수 있으며, 이 변경이 화면에 바로 반영됩니다. 웹 페이지가 정적 문서에서 동적 애플리케이션으로 전환되는 기반입니다.

🖥️Server🔑JWT💻Client
🔑

JWT

서버가 상태를 저장하지 않고도 요청자를 식별하는 자기 완결형 토큰

JWT(JSON Web Token)는 사용자 인증 정보를 JSON 형태로 담아 서명한 토큰입니다. Header, Payload, Signature 세 부분이 Base64로 인코딩되어 점(.)으로 이어진 하나의 문자열이 됩니다. 서버는 이 토큰의 서명만 검증하면 별도의 세션 저장소 조회 없이 요청자가 누구인지, 어떤 권한을 갖고 있는지 알 수 있습니다. 토큰 안에 만료 시간(exp), 발급자(iss), 사용자 식별자(sub) 같은 클레임이 들어 있어 토큰 하나가 인증과 인가 정보를 함께 운반합니다. 서명 알고리즘은 HMAC(대칭 키) 또는 RSA/ECDSA(비대칭 키) 중에서 선택할 수 있고, 비대칭 키를 쓰면 발급자와 검증자를 분리할 수 있습니다. 한번 발급된 JWT는 서버 측에서 임의로 무효화하기 어렵기 때문에 만료 시간을 짧게 잡고 Refresh Token을 별도로 운용하는 것이 일반적입니다.

👤User📱App🔐Provider
🔐

OAuth

비밀번호를 넘기지 않고 제3자 앱에 권한을 위임하는 인가 프레임워크

OAuth 2.0은 사용자가 자신의 비밀번호를 제3자 애플리케이션에 직접 알려주지 않고도 특정 리소스에 대한 접근 권한을 위임할 수 있게 해주는 인가(Authorization) 프레임워크입니다. 구글 계정으로 다른 앱에 로그인하거나, GitHub 계정으로 CI 도구에 저장소 접근 권한을 줄 때 뒤에서 동작하는 프로토콜이 OAuth입니다. Resource Owner(사용자), Client(제3자 앱), Authorization Server(인가 서버), Resource Server(보호된 리소스)라는 네 가지 역할을 정의하고, 이들 사이에서 인가 코드와 액세스 토큰이 교환되는 흐름을 규격화합니다. 인증(Authentication)이 아닌 인가(Authorization)에 초점을 맞추고 있으며, 인증까지 표준화한 것이 OAuth 위에 얹어진 OpenID Connect입니다.

💻Client🔗REST API📦Resource
🔗

REST

HTTP 메서드와 URI로 리소스를 다루는 API 설계 스타일

REST(Representational State Transfer)는 웹의 기본 구조인 HTTP 위에서 API를 설계하는 아키텍처 스타일입니다. 각 자원을 고유한 URI로 식별하고, GET·POST·PUT·DELETE 같은 HTTP 메서드로 그 자원에 대해 수행할 동작을 표현합니다. 서버는 요청 사이에 클라이언트 상태를 기억하지 않는 무상태 원칙을 따르며, 응답에는 관련 리소스로의 링크를 포함할 수 있습니다. JSON이 사실상 표준 응답 형식으로 자리잡았고, HTTP 상태 코드로 성공과 실패를 구분합니다. 별도의 프로토콜이나 도구 없이 브라우저, curl, 모바일 앱 어디서든 접근할 수 있다는 점이 REST가 널리 퍼진 배경입니다.

💻Client📊GraphQL🗄️Data
📊

GraphQL

클라이언트가 필요한 데이터를 쿼리로 정확히 요청하는 API 언어

GraphQL은 Facebook이 2015년에 공개한 API 쿼리 언어이자 런타임입니다. 클라이언트가 필요한 필드를 쿼리 문법으로 직접 명시하면, 서버는 그 구조 그대로 응답을 돌려줍니다. 단일 엔드포인트(/graphql)에서 모든 데이터 요청을 처리하며, 스키마로 API의 타입과 관계를 정의합니다. 데이터 조회는 query, 변경은 mutation, 실시간 구독은 subscription으로 구분합니다. 클라이언트가 응답 형태를 제어할 수 있어 과잉 페칭(over-fetching)과 부족 페칭(under-fetching) 문제를 구조적으로 줄입니다.

🌐BrowserSPA🔌API

SPA

페이지 새로고침 없이 동작하는 단일 페이지 웹 애플리케이션

SPA(Single Page Application)는 최초에 하나의 HTML과 JavaScript 번들을 받아 온 뒤, 이후 화면 전환을 서버 요청 없이 클라이언트 측에서 처리하는 웹 애플리케이션 구조입니다. 브라우저 안에서 라우팅과 렌더링을 모두 담당하므로 페이지 이동 시 전체 새로고침이 발생하지 않고, 필요한 데이터만 API로 가져와 화면을 갱신합니다.

🌐Browser🖥️Server📄HTML
🖥️

SSR

서버에서 완성된 HTML을 만들어 보내는 렌더링 방식

SSR(Server-Side Rendering)은 사용자가 페이지를 요청할 때마다 서버에서 데이터를 조회하고 완성된 HTML을 생성해 보내는 방식입니다. 브라우저는 받은 HTML을 바로 표시할 수 있어 초기 콘텐츠가 빠르게 보이고, 검색 엔진도 완성된 마크업을 그대로 읽을 수 있습니다.

📱Web App🗃️IndexedDB🌐Browser DB
🗃️

IndexedDB

브라우저 안에서 구조화된 데이터를 비동기로 다루는 클라이언트 측 데이터베이스

IndexedDB는 브라우저 안에서 구조화된 데이터를 비동기로 저장하고 조회할 수 있게 해주는 클라이언트 측 데이터베이스 API입니다. 단순 문자열만 저장하는 Web Storage와 달리 객체 형태 레코드, 인덱스 검색, 트랜잭션을 지원하므로 오프라인 데이터, 대용량 캐시, 검색 가능한 로컬 상태를 다룰 때 적합합니다.

⌨️User Input💥XSS🌐Victim Browser
💥

XSS

브라우저가 공격자가 주입한 스크립트를 정상 코드처럼 실행하는 웹 취약점

XSS(Cross-Site Scripting)는 공격자가 주입한 스크립트가 피해자의 브라우저에서 해당 사이트의 정상 코드처럼 실행되는 웹 취약점입니다. 원인은 대개 사용자 입력이나 외부 데이터를 HTML·DOM에 안전하지 않게 삽입하는 데 있고, 한 번 실행되면 브라우저 안의 정보 읽기, 화면 변조, 사용자 권한으로의 요청 전송까지 이어질 수 있습니다.

🕸️Attack Page🎭CSRF🖥️Trusted Server
🎭

CSRF

사용자의 브라우저가 가진 인증 상태를 악용해 원치 않는 요청을 보내게 만드는 공격

CSRF(Cross-Site Request Forgery)는 공격자가 사용자의 브라우저에 남아 있는 인증 상태를 이용해, 사용자가 의도하지 않은 요청을 정상 사이트로 보내게 만드는 웹 공격입니다. 특히 세션 쿠키처럼 브라우저가 자동으로 붙이는 인증 방식에서 문제가 되며, 서버는 요청이 로그인된 사용자에게서 왔다는 사실만으로는 그 요청이 정말 사용자의 의도였는지 판단할 수 없습니다.

🌐Web App🔌WebSocket🖥️Realtime Server
🔌

WebSocket

HTTP 이후 연결을 유지한 채 양방향 메시지를 주고받는 실시간 통신 채널

WebSocket은 브라우저와 서버가 한 번 연결을 맺은 뒤 그 연결을 유지하면서 양방향으로 메시지를 주고받는 웹 통신 프로토콜입니다. 시작은 HTTP Upgrade 요청이지만, 전환이 끝나면 매번 새 요청을 만드는 HTTP와 달리 같은 연결 위에서 계속 데이터를 교환할 수 있습니다. 그래서 실시간 상태 변화가 중요한 웹 애플리케이션에서 요청-응답 모델의 한계를 메우는 역할을 합니다.

📄Page🛠️Service Worker☁️Network
🛠️

Service Worker

페이지 바깥에서도 네트워크와 캐시를 가로채며 동작하는 브라우저 백그라운드 워커

Service Worker는 브라우저가 페이지와 별도로 관리하는 JavaScript 워커로, 웹 페이지와 네트워크 사이에서 요청을 가로채고 캐시, 오프라인 응답, 푸시 알림, 백그라운드 동기화 같은 기능을 처리합니다. DOM에 직접 접근하지는 못하지만, 페이지가 열려 있지 않아도 특정 이벤트에 반응할 수 있기 때문에 일반 페이지 스크립트보다 훨씬 앱에 가까운 동작을 가능하게 합니다.

📄SSR HTML💧Hydration🖱️Interactive UI
💧

Hydration

서버가 먼저 보낸 HTML을 클라이언트 JavaScript와 다시 연결해 인터랙션을 살리는 과정

Hydration은 서버가 미리 렌더링해 보낸 HTML을 브라우저의 JavaScript 애플리케이션과 다시 연결해, 이벤트 핸들러와 상태 업데이트를 활성화하는 과정입니다. 화면은 이미 보이지만 아직 상호작용할 수 없는 정적인 마크업을, 사용자가 실제로 클릭하고 입력할 수 있는 인터랙티브 UI로 바꾸는 단계라고 보면 됩니다.

📱User Device🔑WebAuthn🖥️Website
🔑

WebAuthn

비밀번호 대신 공개키 자격 증명으로 사용자를 증명하는 웹 인증 표준

WebAuthn은 브라우저와 인증기가 협력해 공개키 자격 증명으로 사용자를 인증하는 웹 표준입니다. 서버는 공개키만 저장하고, 개인키는 사용자의 장치 안에 남아 있기 때문에 비밀번호를 저장하거나 전송할 필요가 없습니다. 사용자는 보안 키를 터치하거나, 노트북과 휴대폰의 생체인증 또는 PIN으로 본인 확인을 하고, 사이트는 그 서명을 검증해 로그인 여부를 판단합니다. 오늘날 패스키(passkey) 경험의 핵심 기반이 바로 WebAuthn입니다.

🖥️Main Thread👷Web Worker📤Result
👷

Web Worker

메인 스레드와 분리된 곳에서 무거운 JavaScript 작업을 실행하는 브라우저 워커

Web Worker는 웹 페이지의 메인 스레드와 분리된 별도 스레드 비슷한 실행 컨텍스트에서 JavaScript를 돌릴 수 있게 해 주는 브라우저 기능입니다. DOM에는 직접 접근할 수 없지만, 무거운 계산과 파싱을 메인 스레드 밖으로 옮겨 화면 렌더링과 사용자 입력이 계속 부드럽게 반응하도록 도와줍니다.

🌐Browser📡SSE🖥️Server
📡

Server-Sent Events

HTTP 응답을 열어 둔 채 서버가 이벤트를 흘려보내는 단방향 실시간 스트림

Server-Sent Events는 브라우저가 EventSource로 하나의 HTTP 연결을 열어 두고, 서버가 그 응답 안으로 이벤트를 순차적으로 밀어 넣는 단방향 실시간 전송 방식입니다. text/event-stream 포맷을 쓰며, 연결이 닫히지 않는 동안 서버는 data, event, id, retry 같은 필드를 계속 흘려보낼 수 있습니다. 실시간 알림이나 진행률처럼 서버에서 클라이언트로만 정보가 흐르면, 요청을 반복하지 않고도 화면을 즉시 갱신할 수 있게 해 줍니다.

🌐Browser📲PWA🪟Standalone
📲

PWA

설치, 오프라인, 배경 동작을 더한 웹 앱

PWA(Progressive Web App)는 웹 플랫폼 기술로 만든 앱이지만, 설치 가능성, 오프라인 동작, 백그라운드 이벤트, 독립 창 실행 같은 추가 능력을 통해 플랫폼 앱에 가까운 경험을 제공하는 웹 앱입니다. 같은 코드베이스로 여러 기기와 운영체제에 도달하면서도, 지원이 되는 환경에서는 홈 화면 아이콘과 앱 같은 시작 방식을 제공하고, 지원이 약한 환경에서는 일반 웹사이트로 자연스럽게 동작합니다.

💻Browser📡HTTP🖥️Server
📡

HTTP

웹 통신의 기본 요청-응답 프로토콜

HTTP(HyperText Transfer Protocol)는 클라이언트와 서버가 데이터를 주고받는 규약입니다. 브라우저가 URL을 입력받으면 서버에 HTTP 요청을 보내고, 서버는 HTML·JSON·이미지 같은 데이터를 HTTP 응답으로 돌려줍니다. 모든 웹 통신의 가장 바깥 언어입니다. TCP가 데이터를 물리적으로 전달한다면, HTTP는 그 위에서 '무엇을 요청하고 어떤 결과를 받았는지'의 의미를 정의합니다.

💻Browser🔒TLS🖥️Server
🔒

HTTPS

TLS로 암호화된 안전한 HTTP 통신

HTTPS는 HTTP에 TLS(Transport Layer Security) 계층을 얹은 프로토콜입니다. 요청과 응답의 구조는 HTTP와 동일하지만, 데이터가 네트워크를 통과하는 동안 암호화되어 제3자가 내용을 읽거나 변조할 수 없습니다. TLS 이전에 쓰이던 SSL에서 이름이 바뀐 것이지만, 실무에서는 여전히 SSL이라는 표현을 혼용하는 경우가 많습니다.

🌐BrowserCache🖥️Server

HTTP 캐싱

HTTP 헤더 기반 브라우저·프록시 캐시 제어 메커니즘

HTTP 캐싱은 서버의 응답을 브라우저나 프록시에 저장해 두었다가 같은 요청이 다시 올 때 네트워크를 거치지 않고 저장된 응답을 바로 돌려주는 메커니즘입니다. 핵심은 응답 헤더, 특히 Cache-Control에 담긴 지시어를 따라 캐시 계층이 언제 저장하고, 언제 그냥 돌려주고, 언제 서버에 다시 물어볼지를 결정한다는 점입니다.

🔨Build Time📄HTML Files🌐CDN
📄

SSG

빌드 타임에 HTML을 미리 생성하는 정적 렌더링 방식

SSG(Static Site Generation)는 빌드 타임에 HTML 파일을 미리 생성해 두고, 요청이 들어올 때 서버에서 실시간으로 렌더링하는 대신 이미 만들어진 파일을 그대로 반환하는 렌더링 전략입니다. 완성된 HTML은 CDN에 올려 전 세계 엣지에서 서빙할 수 있고, JS 번들이 로드되면 클라이언트에서 Hydration이 일어나 이후 상호작용은 SPA처럼 동작합니다.

🌐Browser✂️Code Splitting📦Lazy Chunk
✂️

Code Splitting

번들을 분리해 초기 로드를 줄이는 성능 패턴

Code Splitting은 빌드 결과물인 JavaScript 번들을 여러 청크로 나누고, 각 청크를 필요한 시점에만 내려받는 성능 최적화 기법입니다. SPA가 앱 전체 코드를 하나의 번들로 묶는 방식의 한계를 극복하기 위해 등장했습니다.

📄HTML🎨CRP🖥️화면 출력
🎨

CRP

브라우저가 HTML을 화면 픽셀로 바꾸는 렌더링 파이프라인

Critical Rendering Path(CRP)는 브라우저가 HTML, CSS, JavaScript를 파싱해 화면에 픽셀을 그리기까지의 단계별 렌더링 파이프라인입니다. HTML Parse → DOM → CSSOM → Render Tree → Layout → Paint → Composite 각 단계를 이해하면 첫 화면이 왜 느린지, 어디를 최적화해야 하는지 파악할 수 있습니다.

📝C/Rust 코드⚙️WebAssembly🌐Browser
⚙️

WASM

브라우저에서 네이티브 수준 성능을 내는 바이너리 실행 형식

WebAssembly(WASM)는 C, C++, Rust 같은 언어로 작성된 코드를 브라우저에서 실행할 수 있는 바이너리 형식의 가상 명령어 집합입니다. JavaScript로는 한계가 있는 고성능 연산 영역을 브라우저 안에서 처리할 수 있게 합니다.

📄HTML 문서🧩Web Component🔒Shadow DOM
🧩

Web Components

프레임워크 없이 만드는 재사용 가능한 캡슐화 UI 컴포넌트

Web Components는 Custom Elements, Shadow DOM, HTML Templates 세 가지 브라우저 표준 API를 조합해 프레임워크 없이 캡슐화된 재사용 UI 컴포넌트를 만드는 기술입니다. 어떤 HTML 환경에서도 동작하는 표준 기반 컴포넌트를 만들 수 있습니다.