주소창에 google.com을 입력하면 단순히 페이지가 열리는 것처럼 보이지만, 그 안에서는 수십 단계의 네트워크·브라우저·운영체제 레벨 프로세스가 연속적으로 일어난다. 이 과정을 이해하면 웹의 전반적인 동작 원리를 완벽히 파악할 수 있다. 1. 도메인 이름 해석 (DNS Lookup)브라우저는 먼저 사용자가 입력한 문자열이 검색어인지 URL인지 구분한다. google.com처럼 도메인 형식을 띠면 자동으로 https://google.com/ 형태로 완성한다.이때 브라우저는 HSTS(HTTP Strict Transport Security) 정책을 참고해, 이전에 HTTPS로 접속한 기록이 있으면 HTTP 대신 HTTPS를 우선 사용한다. 그다음 브라우저는 도메인을 실제 서버의 IP 주소로 변환하기 위해 ..

클라이언트(브라우저)로부터 들어오는 HTTP 요청을 가장 먼저 받아 처리하는 첫 관문이다. 쉽게 말하면, 사용자와 애플리케이션 서버(Node.js, Spring 등) 사이의 중간 관리자 역할을 한다. 1. 정적 파일(Static Files) 제공웹 서버는 HTML, CSS, JS, 이미지, 폰트 같은 정적 리소스를 직접 클라이언트에 전달한다. 이때 별도의 애플리케이션 로직이 필요하지 않아 속도가 매우 빠르다./public/index.html/assets/style.css/images/logo.png이런 파일들은 Nginx나 Apache가 즉시 응답하므로 Node.js 같은 서버는 부담을 덜 수 있다. 2. 리버스 프록시(Reverse Proxy)웹 서버는 클라이언트 요청을 내부 애플리케이션 서버로 전달하..

프론트엔드 개발자라면 한 번쯤 겪었을 그 문제 CORS Error. 이번 글에서는 CORS(Cross-Origin Resource Sharing)의 개념부터 원리, 해결 전략까지 깔끔히 정리해본다. 1. CORS란?CORS (Cross-Origin Resource Sharing) 은 브라우저가 보안을 위해 다른 출처(origin)의 리소스 요청을 제한하는 정책이다.즉, 브라우저는 자신이 실행 중인 웹 페이지와 다른 도메인으로의 요청을 기본적으로 차단한다. 이는 XSS(Cross-Site Scripting) 나 CSRF(Cross-Site Request Forgery) 같은 보안 공격을 방지하기 위한 핵심 메커니즘이다. 2. “출처(Origin)”란 무엇인가?하나의 Origin(출처) 은 다음 세 가지로 ..

웹 개발을 하다 보면 로그인, 인증, 사용자 정보 보호와 관련된 문제를 반드시 마주하게 된다. 기존에는 쿠키와 세션으로 상태를 관리했지만, 특히 SPA(Single Page Application)나 API 기반 서비스에서는 서버에 상태를 저장하지 않고도 안전하게 인증과 정보 교환을 처리할 필요가 있다. 바로 이때 등장하는 것이 JWT(Json Web Token)다.JWT를 이해하면 다음과 같은 장점을 활용할 수 있다:서버에 상태를 저장하지 않고도 사용자를 인증할 수 있다.클라이언트와 서버 간 정보를 안전하게 전달할 수 있다.SPA나 모바일 앱 등 비동기 통신 환경에서 편리하게 사용 가능하다.즉, 현대 웹과 앱 개발에서 JWT는 필수 기술이다. 1. JWT의 구조JWT는 헤더(Header), 페이로드(Pa..

웹 개발의 흐름은 곧 렌더링 방식의 역사라고 해도 과언이 아니다.오늘날의 React, Next.js, Vue, Nuxt.js 같은 프레임워크는 SPA, CSR, SSR, 그리고 Hybrid Rendering이라는 철학 위에 세워져 있다.이번 글에서는 이 네 가지 개념의 관계와 진화 과정을 한눈에 이해할 수 있도록 정리해본다. 1. SPA의 등장 배경초기의 웹은 정적 HTML 문서로 구성되어, 사용자가 페이지를 이동할 때마다 서버가 완성된 HTML을 새로 내려주는 방식(SSR) 을 사용했다. 이 방식은 단순했지만, 페이지 전환 시마다 전체 새로고침이 발생(리로드)하여 깜빡이는 현상이 있어 사용자 경험(UX)이 끊기고, 매번 서버로부터 전체 문서를 받아오므로 네트워크 낭비가 있어 대규모 애플리케이션 구성에 ..

웹 개발을 하다 보면 z-index를 설정했음에도 겹치는 요소의 순서가 예상과 다르게 나타나는 경우가 있다. 이런 현상의 핵심 원인은 CSS의 stacking context에 있다. 1. 부모 요소의 stacking contextz-index는 같은 stacking context 내에서만 비교된다.부모 요소에 position: relative|absolute|fixed|sticky 와 z-index가 설정되어 있으면 그 부모 안에서만 자식들의 z-index가 적용된다. 즉, 자식 요소들의 z-index가 같더라도 부모 stacking context가 다르면 부모 요소의 순서에 따라 겹침 순서가 달라질 수 있다. 부모의 z-index 가 더 높으면, 자식들의 z-index 도 같이 높아진다고 이해하면 된다..