Web Development 시각적으로 이해하기

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

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

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

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

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

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

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

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

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

CSP(Content Security Policy)는 웹 페이지가 로드할 수 있는 리소스의 출처와 유형을 서버가 HTTP 헤더로 명시하여, 브라우저가 그 범위 밖의 스크립트·스타일·이미지 등을 차단하게 하는 보안 메커니즘입니다. XSS(교차 사이트 스크립팅) 공격의 피해를 줄이는 가장 강력한 방어 수단 중 하나입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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