네트워크 계층의 진화

HTTP/1.x 시대의 한계와 극복

초기 HTTP/0.9는 단순한 HTML 문서 교환을 목적으로 설계되었습니다. 요청 라인 하나로 구성되었으며, 응답 헤더조차 존재하지 않았죠. 이런 단순함은 곧 다양한 미디어 타입과 인코딩 체계의 등장으로 한계를 드러냈습니다.

HTTP/1.0이 등장하면서 Key-Value 형태의 메타데이터가 추가되었습니다. Content-Type, Content-Length, Last-Modified 같은 헤더 필드는 브라우저가 다양한 리소스를 적절히 처리할 수 있는 기반이 되었습니다. 하지만 매 요청마다 TCP 연결을 새로 맺어야 하는 구조적 비효율은 여전했습니다.

HTTP/1.1에서는 지속 연결(Persistent Connection)이 기본값으로 채택되었습니다. 단일 TCP 채널상에서 순차적인 요청-응답을 이어가는 방식입니다. 이는 파이프라이닝(Pipelining) 시도로 이어졌으나, Head-of-Line Blocking 문제로 인해 사실상 폐기되었습니다. 동일 도메당 최대 6개의 병렬 연결 제한과 함께, 이 시대의 대안은 도메인 샤딩(Domain Sharding)이었습니다.

HTTP/2: 바이너리 프레이밍과 다중화

HTTP/1.1의 근본적 한계는 TCP 계층의 특성과 밀접하게 연관되어 있습니다. 느린 시작(Slow Start)으로 인한 초기 지연, 다수 연결 간의 대역폭 경쟁, 그리고 파이프라인의 HOL 블로킹이 대표적입니다.

HTTP/2는 바이너리 프레이밍 계층을 도입하여 이를 해결했습니다. 텍스트 기반 메시지를 이진 형태의 프레임(Frame)으로 쪼개고, 각 프레임에 스트림 식별자를 부여함으로써 논리적 다중화를 구현했습니다.

// HTTP/2 다중화의 개념적 이해
// 스트림 ID를 통해 개별 요청-응답 쌍을 구분
const streamMap = new Map();

function processFrame(frame) {
  const { streamId, payload, flags } = frame;
  
  if (!streamMap.has(streamId)) {
    streamMap.set(streamId, new ResponseBuilder());
  }
  
  const builder = streamMap.get(streamId);
  builder.append(payload);
  
  if (flags.END_STREAM) {
    return builder.complete(); // 해당 스트림 조립 완료
  }
}

// 우선순위 기반 스케줄링 예시
class PriorityScheduler {
  constructor() {
    this.queues = {
      high: [],
      normal: [],
      low: []
    };
  }
  
  enqueue(streamId, priority) {
    this.queues[priority].push(streamId);
  }
  
  selectNext() {
    // 높은 우선순위 먼저, 동일 우선순위 내에서는 라운드 로빈
    for (const level of ['high', 'normal', 'low']) {
      if (this.queues[level].length > 0) {
        return this.queues[level].shift();
      }
    }
    return null;
  }
}

HTTP/2의 핵심 혁신은 다음과 같습니다:

• 단일 TCP 연결: 전체 페이지 로드에 하나의 연결만 사용, handshake 오버헤드 최소화
• 양방향 우선순위: 클라이언트의 의도와 서버의 최적화 결정 모두 반영
• 서버 푸시: 클라이언트가 요청하기 전에 예상 리소스를 선제 전송
• HPACK 헤더 압축: 정적/동적 테이블과 허프만 코딩으로 중복 헤더 제거

HTTP/3와 QUIC: 전송 계층의 재설계

HTTP/2의 아이러니는 TCP 기반 HOL 블로킹을 완전히 해결하지 못했다는 점입니다. 단일 TCP 연결 내에서 하나의 패킷 손실이 모든 스트림을 블록시키는 현상은 여전했습니다. 이는 TCP의 바이트 스트림 의미론 때문입니다—TCP는 전체 바이트 스트림의 순서를 보장해야 하므로, 어느 지점에서든 손실이 발생하면 후속 모든 데이터가 대기합니다.

QUIC(Quick UDP Internet Connections)은 UDP 기반으로 TCP의 신뢰성 메커니즘을 사용자 공간에서 재구현한 프로토콜입니다:

// QUIC 연결 설정의 개념적 흐름
// 0-RTT 재개 시나리오
async function establishQuicConnection(config) {
  const connection = new QuicConnection({
    // 1-RTT 핸드셋 (초기 연결)
    // Client Hello + Server Hello + 암호화 매개변수 교환
    
    // 0-RTT: 이전 세션의 티켓으로 즉시 데이터 전송
    earlyData: config.resumptionTicket,
    
    // 스트림 레벨의 독립적 흐름 제어
    streamFlowControl: {
      initialWindow: 65535,
      maxWindow: 16777216
    }
  });
  
  // 개별 스트림의 독립적 처리
  const dataStream = connection.createStream({
    priority: 'high',
    unidirectional: false
  });
  
  // 다른 스트림의 손실이 이 스트림에 영향을 주지 않음
  return { connection, dataStream };
}

QUIC의 설계 철학은 연결 내 스트림 간의 독립성입니다. 각 스트림은 자체적인 순서 번호 체계를 가지며, 특정 스트림에서의 패킷 재전송이 다른 스트림의 데이터 전달을 지연시키지 않습니다. 또한 TLS 1.3이 내장되어 있어 보안 핸드셋이 연결 설정과 통합되며, 0-RTT 재개로 재방문 사용자의 지연 시간을 극도로 단축합니다.

브라우저 보안 모델

동일 출처 정책과 그 외곽

웹 보안의 기본 축은 동일 출처 정책(Same-Origin Policy)입니다. 프로토콜, 호스트, 포트의 삼중 일치를 요구하는 이 정책은 DOM 조작, 쿠키 접근, 네트워크 요청 등 세 가지 영역에서 제약을 가합니다.

현대 웹의 협업 요구는 이 엄격한 정책을 완화하는 메커니즘을 필요로 했습니다:

메커니즘	적용 계층	핵심 개념
CORS	네트워크	서버가 명시적으로 교차 출처 접근 허용
postMessage	DOM	명시적 메시지 채널을 통한 문서 간 통신
CSP	리소스 로드	서버가 허용할 리소스 출처 정의

취약점 공격 유형과 방어

XSS(Cross-Site Scripting)는 공격자가 신뢰할 수 있는 사이트에 악성 스크립트를 삽입하는 공격입니다. 저장형, 반사형, DOM 기반형으로 분류되며, 근본적 방어는 출력 인코딩과 입력 검증의 결합입니다.

// 안전한 HTML 템플릿 처리 (DOMPurify 개념)
class SecureTemplateEngine {
  static escapeHtml(unsafe) {
    const entityMap = {
      '&': '&',
      '<': '<',
      '>': '>',
      '"': '"',
      "'": '''
    };
    return unsafe.replace(/[&<>"']/g, c => entityMap[c]);
  }
  
  // 템플릿 리터럴 태그 함수
  static sanitize(strings, ...values) {
    return strings.reduce((result, str, i) => {
      const value = values[i];
      const sanitized = value != null 
        ? SecureTemplateEngine.escapeHtml(String(value)) 
        : '';
      return result + str + sanitized;
    }, '');
  }
}

// 사용 예
const userInput = "<script>alert('xss')</script>";
const safeHtml = SecureTemplateEngine.sanitize`<div class="comment">${userInput}</div>`;

CSRF(Cross-Site Request Forgery)는 사용자의 인증 상태를 악용하는 공격입니다. 방어의 핵심은 요청의 출처 검증과 예측 불가능한 토큰 부착입니다. SameSite 쿠키 속성은 현대 브라우저에서 이를 자동화하는 강력한 도구입니다.

// CSRF 방어 미들웨어 패턴
const crypto = require('crypto');

class CsrfProtection {
  constructor(options = {}) {
    this.tokenLength = options.tokenLength || 32;
    this.cookieName = options.cookieName || 'csrf_token';
    this.headerName = options.headerName || 'x-csrf-token';
  }
  
  generateToken(req, res) {
    const token = crypto.randomBytes(this.tokenLength).toString('hex');
    // httpOnly 미설정: JS에서 읽어 헤더에 첨부해야 함
    res.cookie(this.cookieName, token, { 
      sameSite: 'strict',
      secure: true 
    });
    return token;
  }
  
  validate(req, res, next) {
    const cookieToken = req.cookies[this.cookieName];
    const headerToken = req.headers[this.headerName];
    
    if (!cookieToken || !headerToken || 
        !crypto.timingSafeEqual(
          Buffer.from(cookieToken), 
          Buffer.from(headerToken)
        )) {
      return res.status(403).json({ error: 'CSRF token mismatch' });
    }
    
    next();
  }
}

샌드박스 아키텍처

현대 라우저는 다중 프로세스 아키텍처를 채택하여 보안과 안정성을 동시에 추구합니다. Chromium 기반 브라우저의 프로세스 구조는 다음과 같습니다:

• 브라우저 프로세스: UI, 네트워크, 파일 접근, 권한 관리
• 렌더러 프로세스: HTML/CSS 파싱, JS 실행, 레이아웃, 페인팅
• GPU 프로세스: 그래픽 가속, 합성 작업
• 네트워크 프로세스: 리소스 요청 처리

핵심은 렌더러 프로세스가 샌드박스 내에서 실행된다는 점입니다. 시스템 콜 필터링, 한 축소, 네임스페이스 격리 등 OS 기술을 활용하여, 렌더러가 직접 파일 시스템이나 네트워크에 접근하지 못하도록 차단합니다. 모든 특권 연산은 브라우저 프로세스를 통한 IPC로 중계됩니다.

사이트 격리(Site Isolation)는 이 개념을 한 단계 발전시킵니다. 원래는 단위로 프로세스를 분리했지만, Spectre/Meltdown 같은 추측 실행 취약점이 등장하면서 출처(origin) 단위의 격리가 필요해졌습니다. 이제는 서로 다른 사이트의 iframe조차 별도의 프로세스에서 실행되어, 프로세스 메모리를 통한 정보 유출을 원천 차단합니다.

렌더링 파이프라인과 성능

작업 스케줄링의 진화

Chromium의 메인 스레드는 다중 큐 스케줄링을 채택했습니다. 초기 단일 큐에서 시작하여, 우선순위 분리, 메시지 타입별 큐 분리를 거쳐, 현재는 동적 우선순위 조정과 기아 방지 메커니즘을 갖춘 복합 시스템으로 발전했습니다.

스케줄러의 핵심 고려사항은 디스플레이 주사율과의 동기화입니다. 60Hz 환경에서 각 프레임은 약 16.67ms 내에 완성되어야 합니다. VSync 신호를 기준으로, 사용자 입력 처리 → 레이아웃 계산 → 인팅 → 합성의 파이프라인이 조율됩니다.

// requestAnimationFrame vs setTimeout의 근본적 차이
class AnimationScheduler {
  constructor() {
    this.usingRaf = true;
    this.animationId = null;
  }
  
  // VSync에 맞춰 정확히 한 프레임에 한 번 실행
  startWithRaf(callback) {
    const loop = (timestamp) => {
      // timestamp는 VSync 시점과 정렬됨
      callback(timestamp);
      this.animationId = requestAnimationFrame(loop);
    };
    this.animationId = requestAnimationFrame(loop);
  }
  
  // 타이머는 VSync와 무관하게 실행되어 프레임 어긋남 발생
  startWithTimeout(callback) {
    const approximateFps = 60;
    const interval = 1000 / approximateFps;
    
    const loop = () => {
      callback(performance.now());
      this.animationId = setTimeout(loop, interval);
    };
    this.animationId = setTimeout(loop, interval);
  }
  
  cancel() {
    cancelAnimationFrame(this.animationId);
    clearTimeout(this.animationId);
  }
}

성능 분석 도구 활용

Chrome DevTools Performance 패널은 렌더링 병목을 진단하는 핵심 도구입니다. 주요 지표의 의미는 다음과 같습니다:

지표	의미	최적화 방향
FP (First Paint)	첫 픽셀 그려짐	크리티컬 렌더링 패스 최적화
FCP (First Contentful Paint)	첫 콘텐츠 요소 표시	텍스트/이미지 로드 우선순위 조정
LCP (Largest Contentful Paint)	최대 콘텐츠 요소 표시	hero 이미지 최적화, 서버 응답 시간 단축
TTFB (Time To First Byte)	첫 바이트 수신 시간	CDN 활용, 서버 처리 최적화
CLS (Cumulative Layout Shift)	누적 레이아웃 변화	크기 명시, 동적 콘텐츠 예약 공간

Performance 패널의 Main 스레드 타임라인을 분석할 때, 각 Task의 세부 과정을 추적하는 것이 중요합니다. Parse HTML → Evaluate Script → Recalculate Style → Layout → Update Layer Tree → Paint → Composite Layers 순으로, 어느 단계에서 시간이 소요되는지 파악해야 합니다.

Long Task(50ms 이상)가 메인 스레드를 독점하면, 사용자 입력에 대한 반응성이 저하됩니다. 이런 경우 Web Worker를 활용한 계산 오프로딩, 또는 Scheduler API를 통한 우선순위 기반 작업 분할을 고려해야 합니다.

네트워크 성능 최적화

DevTools Network 패널의 타임라인은 리소스 로딩의 세부 단계를 보여줍:

• Queuing: 우선순위나 연결 제한으로 인한 대기
• Stalled: 연결 설정 전 지연
• DNS Lookup: 도메인 해석 시간
• Initial Connection: TCP 핸드셋 (HTTPS의 경우 TLS 포함)
• SSL: TLS 협상 시간
• Request Sent: 요청 데이터 전송
• Waiting (TTFB): 서버 처리 및 첫 바이트 대기
• Content Download: 응답 본문 수신

각 단계별 최적화 전략:

// 리소스 우선순위 명시를 통한 로딩 최적화
function optimizeResourceLoading() {
  // 핵심 CSS는 head에, 비동기 로드는 preload 힌트
  const preloadLink = document.createElement('link');
  preloadLink.rel = 'preload';
  preloadLink.href = '/critical.css';
  preloadLink.as = 'style';
  document.head.appendChild(preloadLink);
  
  // 중요 이미지는 fetchpriority로 우선순위 상향
  const heroImg = document.createElement('img');
  heroImg.src = '/hero.webp';
  heroImg.fetchPriority = 'high';
  
  // 덜 중요한 리소스는 지연 로드
  const belowFoldImg = document.createElement('img');
  belowFoldImg.loading = 'lazy';
  belowFoldImg.src = '/below-fold.webp';
}

HTTPS와 신뢰 체계

호화 계층의 설계

HTTPS는 HTTP와 TCP 사이에 TLS(Transport Layer Security) 계층을 삽입한 프로토콜입니다. 현대 TLS 1.3의 핸드셋은 이전 버전 대비 단순화되었습니다:

1. 클라이언트가 지원하는 암호화 스위트, key share를 포함한 ClientHello 전송
2. 서버가 선택한 암호화 스위트, 인증서, key share를 포함한 ServerHello 및 암호화된 확장 전송
3. 클라이언트가 서버 인증서 검증, 대칭키 도출, Finished 메시지 전송

TLS 1.3에서는 키 교환과 인증이 분리되었습니다. 이전의 RSA 교환은 사라지고, Ephemeral Diffie-Hellman만 남았습니다. 이는 Forward Secrecy를 보장하여, 장기 비밀키가 유출되어도 과거 세션이 복원되지 않도록 합니다.

인증서 체인 검증

브라우저는 인증서 체인을 통해 서버 신원을 검증합니다. leaf 인증서 → 중간 CA 인증서 → 루트 CA 인증서 순으로, 각 단계의 서명을 검증하며 신뢰를 전파합니다.

운영체제는 신뢰할 수 있는 루트 CA 인증서를 내장하고 있으며, 브라우저는 이를 기준으로 체인의 최상위를 검증합니다. Certificate Transparency(CT) 로그는 추가적인 보장을 제공하여, 발급된 인증서가 공개적으로 감사 가능하도록 합니다.

개발자 도구의 Security 패널이나 openssl s_client -connect 명령을 통해, 실제로 어떤 인증서 체인이 구성되어 있는지 확인할 수 있습니다. 만료 임박, 약한 서명 알고리즘, 불완전한 체인 등의 문제를 사전에 파악하는 것이 중요합니다.