네트워크 주니어 성능 최적화 면접

먼저 브라우저 개발자 도구의 Network 탭에서 각 리소스의 로딩 시간과 Waterfall 차트를 확인합니다. TTFB(Time To First Byte)를 통해 서버 응답 속도를 측정하고, 리소스의 크기와 개수를 파악하여 과도한 요청이 있는지 확인합니다. Latency와 Download 시간을 구분하여 네트워크 지연인지 대역폭 문제인지 판단합니다. 또한 Chrome의 Lighthouse나 WebPageTest 같은 도구로 전체적인 성능 점수와 개선 제안사항을 확인할 수 있습니다.

Cache-Control의 주요 디렉티브로는 max-age(캐시 유효 시간), no-cache(재검증 필수), no-store(캐시 금지), public/private(공유 캐시 허용 여부)가 있습니다. 버전 해시가 포함된 정적 파일(app.abc123.js)은 max-age=31536000, immutable로 장기 캐싱하고, HTML 파일은 no-cache로 설정하여 매번 재검증하도록 합니다. API 응답 중 자주 변하지 않는 데이터는 max-age=300 정도로 짧은 캐싱을 적용하고, 민감한 개인정보는 no-store, private로 설정합니다. ETag나 Last-Modified 헤더를 함께 사용하면 304 Not Modified 응답으로 대역폭을 절약할 수 있습니다.

HTTP/1.1의 Keep-Alive는 하나의 TCP 연결을 재사용하여 매 요청마다 3-way handshake를 수행하는 오버헤드를 줄입니다. 하지만 HOL(Head of Line) Blocking 문제로 인해 한 번에 하나의 요청만 처리되고 이전 응답이 완료되어야 다음 요청을 보낼 수 있습니다. HTTP/2의 멀티플렉싱은 하나의 TCP 연결에서 여러 스트림을 동시에 처리하여 HOL Blocking을 해결하고, 요청 우선순위 지정도 가능합니다. 이를 통해 리소스가 많은 웹페이지에서 로딩 시간을 크게 단축할 수 있습니다.

CDN은 전 세계에 분산된 서버 네트워크로, 원본 서버의 콘텐츠를 엣지 서버에 캐싱하여 사용자와 가까운 위치에서 제공하는 서비스입니다. 물리적 거리가 가까워지면 네트워크 지연(Latency)이 줄어들고, 원본 서버의 부하가 분산되어 가용성이 향상됩니다. 이미지, CSS, JavaScript 같은 정적 리소스나 동영상 스트리밍 콘텐츠를 CDN에 배포하면 효과적입니다. 또한 CDN은 DDoS 공격 방어와 HTTPS 적용에도 유리하며, 글로벌 서비스에서는 필수적인 인프라입니다.

gzip이나 brotli 압축은 텍스트 기반 파일의 크기를 60~80% 줄여서 네트워크 전송 시간을 단축하고 대역폭 비용을 절감합니다. HTML, CSS, JavaScript, JSON, XML 같은 텍스트 파일에 압축을 적용하면 효과적이며, 특히 반복되는 패턴이 많은 파일일수록 압축률이 높습니다. 반면 이미 압축된 이미지(JPEG, PNG)나 동영상 파일은 추가 압축 효과가 거의 없고 CPU 낭비만 발생합니다. 웹서버에서 Accept-Encoding 헤더를 확인하고 Content-Encoding 헤더로 압축 방식을 알려줍니다.

각 도메인마다 처음 접근 시 DNS 조회가 필요하며 이는 보통 20~120ms의 지연을 발생시킵니다. 외부 CDN, 폰트, 분석 도구 등 여러 도메인을 사용하면 DNS 조회가 누적되어 초기 로딩이 느려집니다. dns-prefetch 링크 태그를 사용하면 브라우저가 미리 DNS 조회를 수행하여 실제 리소스 요청 시 지연을 줄일 수 있습니다. preconnect는 DNS 조회뿐 아니라 TCP 연결과 TLS 핸드셰이크까지 미리 수행하여 더 큰 성능 개선을 제공하지만, 리소스를 더 많이 사용하므로 중요한 도메인에만 적용해야 합니다.

Round Robin은 요청을 순차적으로 각 서버에 균등하게 분배하는 방식으로 구현이 간단하고 서버 성능이 동일할 때 적합합니다. Least Connection은 현재 연결 수가 가장 적은 서버에 요청을 보내는 방식으로, 요청 처리 시간이 다양할 때 효과적입니다. IP Hash는 클라이언트 IP를 해싱하여 항상 같은 서버로 라우팅하므로 세션 유지가 필요한 경우에 적합합니다. Weighted 방식을 추가하면 서버 성능에 따라 가중치를 부여하여 더 정교한 분산이 가능합니다. Health Check를 통해 장애 서버를 자동으로 제외하는 것도 중요합니다.

먼저 JSON 응답에 불필요한 필드를 제거하고 필요한 필드만 선택적으로 반환하는 Field Filtering을 적용합니다. 응답 데이터에 gzip 압축을 적용하여 전송 크기를 줄이고, 대량 데이터는 페이지네이션이나 커서 기반 페이징으로 분할 전송합니다. GraphQL을 도입하면 클라이언트가 필요한 데이터만 요청할 수 있어 Over-fetching을 방지할 수 있습니다. HTTP/2를 사용하여 여러 API 요청을 동시에 처리하고, 자주 조회되는 데이터는 Redis 같은 캐시를 적용하여 DB 조회를 줄입니다. 응답 시간 모니터링을 통해 느린 API 엔드포인트를 지속적으로 개선합니다.

먼저 하나의 WebSocket 연결로 여러 채널을 구독하는 멀티플렉싱 방식을 적용하여 연결 수를 줄입니다. 메시지를 개별 전송하지 않고 짧은 시간 동안 배칭하여 한 번에 전송하면 네트워크 오버헤드가 감소합니다. Redis Pub/Sub이나 메시지 큐를 사용하여 여러 서버 간 메시지를 효율적으로 분산하고, 불필요한 연결은 Idle Timeout으로 정리합니다. Heartbeat 간격을 적절히 조정하여 네트워크 트래픽을 줄이고, 서버 확장 시 WebSocket 세션을 Sticky Session으로 관리하거나 Redis에 세션 정보를 저장합니다. 클라이언트 수가 매우 많다면 Socket.io 클러스터링이나 전용 메시징 서비스 도입을 고려합니다.

먼저 WebP나 AVIF 같은 최신 이미지 포맷을 사용하여 파일 크기를 30~50% 줄이고, 실제 표시 크기에 맞게 이미지를 리사이징하여 불필요하게 큰 원본을 전송하지 않습니다. Lazy Loading을 적용하여 뷰포트에 보이지 않는 이미지는 나중에 로드하고, srcset과 sizes 속성으로 반응형 이미지를 제공하여 디바이스에 최적화된 크기를 전달합니다. 이미지 스프라이트나 SVG를 활용하여 HTTP 요청 수를 줄이고, CDN에 이미지를 배포하여 지리적으로 가까운 곳에서 제공합니다. 중요한 히어로 이미지는 preload로 우선 로딩하고, 나머지는 우선순위를 낮춥니다.