duck blog
Published on

HTTP/2 실무 현실 점검하기 (2편): 백엔드와 프론트엔드 개발자가 실제로 확인하는 방법

Authors
  • avatar
    Name
    Deokgoo Kim
    Twitter

1편에서 HTTP/2의 탄생 배경과 핵심 기술들을 살펴보았습니다. 이제 실무에서 정말 중요한 질문에 답해보겠습니다.

"우리 서비스는 HTTP/2를 제대로 활용하고 있을까?"

멀티플렉싱과 서버 푸시를 지원한다고 해서 자동으로 성능이 향상되는 것은 아닙니다. 실제로는 설정 실수나 잘못된 최적화로 인해 HTTP/1.1보다 느려지는 경우도 있습니다.

이번 편에서는 실무에서 바로 사용할 수 있는 HTTP/2 확인 및 최적화 방법들을 단계별로 알아보겠습니다.

1. 브라우저 개발자 도구로 HTTP/2 확인하기

Chrome DevTools 활용법

Network 탭 기본 확인: 가장 간단한 방법은 Chrome DevTools의 Network 탭입니다.

// 개발자 도구 > Network 탭에서 확인할 포인트들
1. Protocol 컬럼: h2 (HTTP/2), h3 (HTTP/3), http/1.1 표시
2. Connection ID: 같은 서버로의 요청들이 동일한 Connection ID를 가지는지
3. Priority: 리소스 우선순위가 올바르게 설정되었는지

HTTP/2 Push 확인:

// Performance 탭에서 Server Push 확인
1. Performance 탭 열기
2. 페이지 새로고침하며 녹화
3. Network 섹션에서 "Push" 라벨 확인
4. 푸시된 리소스의 타이밍 분석

실무 팁: Connection 병목 진단 HTTP/1.1에서는 도메인당 6개 연결 제한이 있었지만, HTTP/2는 단일 연결로 멀티플렉싱을 수행합니다.

Firefox Developer Tools의 고유 기능

Firefox는 HTTP/2 디버깅에 유용한 고유 기능들을 제공합니다.

// about:networking 페이지 활용
1. 주소창에 "about:networking" 입력
2. HTTP/2 탭에서 활성 연결 상태 확인
3. 스트림 상태와 우선순위 정보 확인
4. HPACK 압축 통계 확인

2. 백엔드 서버 HTTP/2 설정 점검

Nginx HTTP/2 설정 확인

기본 설정 체크리스트:

# /etc/nginx/sites-available/your-site
server {
    listen 443 ssl http2;  # http2 키워드 필수

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # HTTP/2 Push 설정 (선택사항)
    location = /index.html {
        http2_push /css/main.css;
        http2_push /js/app.js;
    }
}

설정 확인 명령어:

# Nginx 설정 테스트
sudo nginx -t

# HTTP/2 지원 여부 확인
curl -I --http2 https://yourdomain.com

# SSL/TLS 및 HTTP/2 상세 확인
openssl s_client -alpn h2 -connect yourdomain.com:443

Apache HTTP/2 설정 확인

# httpd.conf 또는 .htaccess
LoadModule http2_module modules/mod_http2.so

# Virtual Host 설정
<VirtualHost *:443>
    ServerName yourdomain.com

    # HTTP/2 활성화
    Protocols h2 http/1.1

    # SSL 설정
    SSLEngine on
    SSLCertificateFile /path/to/cert.crt
    SSLCertificateKeyFile /path/to/key.key
</VirtualHost>

Node.js (Express) HTTP/2 설정

const http2 = require('http2');
const fs = require('fs');

// HTTPS/HTTP2 서버 생성
const server = http2.createSecureServer({
  key: fs.readFileSync('path/to/key.pem'),
  cert: fs.readFileSync('path/to/cert.pem')
});

// Express와 HTTP/2 연동 시 주의사항
const express = require('express');
const app = express();

server.on('stream', (stream, headers) => {
  // HTTP/2 스트림 처리
  stream.respond({
    'content-type': 'text/html',
    ':status': 200
  });

  stream.end('<h1>HTTP/2 Server</h1>');
});

// 서버 시작
server.listen(443, () => {
  console.log('HTTP/2 서버가 443 포트에서 실행 중입니다.');
});

3. 프론트엔드 HTTP/2 최적화 확인

리소스 우선순위 최적화

HTTP/2에서는 리소스 우선순위 설정이 성능에 큰 영향을 미칩니다.

<!-- Critical CSS 우선순위 높게 설정 -->
<link rel="preload" href="/css/critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

<!-- 비중요 CSS 우선순위 낮게 설정 -->
<link rel="preload" href="/css/non-critical.css" as="style" media="print" onload="this.media='all'">

<!-- JavaScript 모듈 우선순위 -->
<link rel="modulepreload" href="/js/app.js">

실무에서 확인해야 할 우선순위 설정:

Server Push 최적화

Server Push는 잘못 사용하면 오히려 성능을 저하시킬 수 있습니다.

// 올바른 Server Push 사용 예시
// 1. Critical CSS만 푸시
// 2. 브라우저 캐시 상태 확인 후 푸시
// 3. 푸시할 리소스 크기 제한 (< 10KB 권장)

// 실무에서 자주 하는 실수
// ❌ 모든 CSS/JS 파일을 푸시
// ❌ 이미 캐시된 리소스를 푸시
// ❌ 큰 파일을 푸시 (번들 전체 등)

도메인 샤딩 제거

HTTP/1.1 시대의 최적화 기법인 도메인 샤딩(Domain Sharding)은 HTTP/2에서는 오히려 성능을 저하시킵니다.

<!-- HTTP/1.1 시대의 도메인 샤딩 (이제는 제거해야 함) -->
<!-- ❌ 잘못된 방식 -->
<img src="https://img1.yourdomain.com/photo1.jpg">
<img src="https://img2.yourdomain.com/photo2.jpg">
<script src="https://js.yourdomain.com/app.js"></script>
<link href="https://css.yourdomain.com/style.css">

<!-- ✅ HTTP/2에 최적화된 방식 -->
<img src="https://yourdomain.com/images/photo1.jpg">
<img src="https://yourdomain.com/images/photo2.jpg">
<script src="https://yourdomain.com/js/app.js"></script>
<link href="https://yourdomain.com/css/style.css">

4. 성능 측정 및 비교

실제 성능 차이 측정하기

WebPageTest 활용:

# WebPageTest API를 통한 자동화된 테스트
curl -X POST "https://www.webpagetest.org/runtest.php" \
  -d "url=https://yourdomain.com" \
  -d "k=YOUR_API_KEY" \
  -d "location=ec2-us-east-1" \
  -d "runs=3" \
  -d "fvonly=1"

Lighthouse를 통한 성능 분석:

# CLI를 통한 Lighthouse 실행
npx lighthouse https://yourdomain.com --output=json --output-path=./report.json

# HTTP/2 specific 점검 사항
npx lighthouse https://yourdomain.com --only-categories=performance --output=html

성능 지표 해석

중요한 성능 지표들:

// 1. Time to First Byte (TTFB)
// HTTP/2: 일반적으로 100-200ms 개선

// 2. First Contentful Paint (FCP)
// 리소스 우선순위 최적화로 10-30% 개선 가능

// 3. Largest Contentful Paint (LCP)
// Server Push 활용으로 15-25% 개선 가능

// 4. Cumulative Layout Shift (CLS)
// 폰트 로딩 최적화로 개선

5. 실무에서 놓치기 쉬운 함정들

CDN과 HTTP/2 설정

CloudFlare 설정 확인:

// CloudFlare에서 HTTP/2 활성화 후 확인사항
1. SSL/TLS 탭에서 "Full (strict)" 설정 확인
2. Speed 탭에서 "HTTP/2" 활성화 확인
3. "HTTP/3 (with QUIC)" 실험적 기능 고려

AWS CloudFront 설정:

{
  "DistributionConfig": {
    "HttpVersion": "http2",
    "Origins": [{
      "DomainName": "yourdomain.com",
      "OriginProtocolPolicy": "https-only"
    }]
  }
}

혼합 콘텐츠 문제

HTTP/2는 HTTPS에서만 동작하므로, 혼합 콘텐츠 문제가 발생할 수 있습니다.

레거시 브라우저 대응

// HTTP/2 지원 여부 확인
function supportsHTTP2() {
  // Service Worker를 통한 HTTP/2 지원 감지
  if ('serviceWorker' in navigator) {
    return fetch('/test-endpoint', { method: 'HEAD' })
      .then(response => {
        // HTTP/2 응답 헤더 확인
        return response.headers.get('alt-svc') !== null;
      })
      .catch(() => false);
  }
  return false;
}

// 폴백 처리
supportsHTTP2().then(supported => {
  if (!supported) {
    // HTTP/1.1 최적화 적용
    console.log('HTTP/1.1 폴백 모드');
  }
});

마무리

HTTP/2 실무 점검의 핵심은 측정과 확인입니다. 단순히 서버에서 HTTP/2를 활성화했다고 해서 자동으로 성능이 향상되는 것은 아닙니다.

실무 체크리스트 요약:

  1. 브라우저 개발자 도구로 Protocol과 Connection ID 확인
  2. 서버 설정에서 HTTP/2 활성화 및 SSL/TLS 설정 검증
  3. 리소스 우선순위 최적화 및 불필요한 Server Push 제거
  4. 도메인 샤딩 제거와 단일 도메인으로 통합
  5. 성능 측정 자동화로 지속적인 모니터링
  6. 혼합 콘텐츠 제거와 레거시 브라우저 대응

HTTP/2는 올바르게 설정하고 활용한다면 웹 성능을 크게 개선할 수 있는 강력한 기술입니다. 하지만 잘못된 설정이나 HTTP/1.1 시대의 최적화 기법을 그대로 사용한다면 오히려 성능이 저하될 수 있습니다.

정기적인 성능 측정과 최적화를 통해 HTTP/2의 진정한 잠재력을 발휘해보시기 바랍니다.

Subscribe to the newsletter