실제 성능 개선 2025

고객과 최종 사용자는 그 어느 때보다 더 즉각적인 상호작용을 요구합니다. Google과 같은 기업이 검색 결과에서 성능을 주요 순위 요인으로 삼는 것처럼, 성능은 여전히 성공의 핵심 요소입니다. Akamai는 사이트 성능 향상에 대규모 투자를 진행해 왔습니다. Akamai의 개선 사항과 새로운 기능을 활용하면 실제 고객에게 최적의 앱 성능을 제공할 수 있습니다.

이 블로그 게시물에서는 Akamai 개선 사항이 고객의 CWV(Core Web Vital) 지표에 미친 긍정적인 영향을 보여드리겠습니다. 특히 2025년에는 CWV가 SEO 순위 신호로서 실제 성능을 평가하는 사실상의 표준이 되었습니다. Akamai가 CWV를 사용하는 이유는 연결 상태, 위치, 브라우저, 디바이스와 관계없이 현대적인 애플리케이션을 사용하는 실제 사용자에 초점을 맞추기 때문입니다.

다음으로, 이러한 최적화가 애플리케이션 성능을 개선하는 데 어떻게 활용될 수 있는지 소개하겠습니다. 여기에는 Akamai가 도입한 최적화뿐 아니라, 사이트와 앱 가속화를 위해 Akamai 설정에 추가할 수 있는 기능과 제어 항목도 포함됩니다.

그럼 시작해 보겠습니다.

Akamai가 지난 1년간 도입한 성능 개선 사항은 실제 사용자에게 측정 가능한 영향을 주고 있습니다. Google은 CrUX(Chrome User Experience Report)를 통해 이를 확인했습니다. CrUX는 Google이 제공하는 공개 데이터셋으로, 웹사이트의 성능과 로딩 시간 측면에서 실제 사용자의 경험에 대한 인사이트를 제공합니다.

Google은 실제 사용자로부터 동의를 받고 데이터를 수집해 시뮬레이션이나 실험실 기반 테스트가 아닌 기본적인 사용자 상호작용을 반영하는 지표를 추적하고 집계합니다.

Akamai의 새로운 기능을 통해 LCP(Largest Contentful Paint) 및 INP(Interaction to Next Paint)와 같은 사용자 중심 KPI(Key Performance Indicator)은 물론 기술적이지만 여전히 인기 있는 TTFB(Time to First Byte)에서도 더 나은 결과를 확인했습니다. 이러한 웹 바이탈 지표가 긍정적으로 개선된 몇 가지 웹사이트를 살펴보겠습니다.

참고: 다음 그림은 모든 웹사이트의 데이터셋 내 역사적 CrUX 데이터를 시각화할 수 있는 우수한 툴인 treo.sh에서 캡처한 스크린샷입니다.

그래프 상단의 녹색 부분은 LCP가 2.5초 미만인 요청의 비율을 나타냅니다. 또한 3개월 전과 비교했을 때, 2월 이후 "우수한"(녹색) 사용자 경험을 제공받는 사용자가 20% 증가했습니다(LCP 2.5초 미만).

이 사이트는 이전에는 종종 "개선 필요"(주황색) 구간에 머물러 Google 검색 결과에서 페널티를 받을 가능성이 있었지만, 이제는 녹색 구간에 안정적으로 자리 잡으며 사용자 만족도가 크게 향상되었습니다.

보안 중심의 한 은행은 INP(Interaction to Next Paint)에서 인상적인 개선을 이뤘습니다(그림 2). 이 은행은 자체적으로 개선 작업을 진행했을 뿐 아니라, 최근 몇 달간 출시된 Akamai Bot Manager 자바스크립트 최적화 기능의 효과도 함께 누렸습니다. 그 결과 INP는 약 55%에서 87% 이상으로 개선되어, INP가 200밀리초 미만인 "우수한" 사용자 경험을 제공하는 비율이 지속적으로 증가했습니다.

TTFB(Time To First Byte)는 CWV에는 포함되지 않지만 LCP와 밀접한 상관관계가 있어 중요한 추적 지표로 간주됩니다.

한 이커머스 웹사이트는 이미 빨랐지만 지난 8개월 동안 플랫폼 개선을 통해 더욱 빨라졌습니다(자세한 내용은 "어떤 부분을 개선했나요?" 섹션 참조). 그림 3에서 볼 수 있듯, Akamai 플랫폼 배포 이후 해당 웹사이트에서 우수한 TTFB 경험을 한 사용자의 비율이 지속적으로 증가했습니다.

여행 업계의 또 다른 고객은 기존에 낮은 TTFB 수치를 기록하며 Akamai의 성능 최적화 기능을 사용하지 않고 있었습니다. 그러나 Akamai 성능 팀이 권장한 모범 사례를 적용한 후, 한 달 남짓한 기간 동안 TTFB가 3초에서 0.6초로 개선되었습니다(그림 4).

느린 웹사이트만 빨라진 것이 아닙니다. Akamai를 사용하면 이미 매우 빠른 웹사이트도 더 빨라질 수 있습니다. 그림 5에 표시된 월 수백만 방문자를 기록하는 이커머스 사이트는 최근 P75에서 LCP 500밀리초 장벽을 마법 같이 돌파했으며, INP는 50밀리초, CLS(Cumulative Layout Shift)는 0.00의 완벽한 점수를 기록했습니다.

Akamai 플랫폼을 사용하면 향상된 가동 시간과 최상위 성능을 갖춘 성숙하고 고도로 확장 가능한 사이트를 구축할 수 있습니다. 타협이나 양보 없이 뛰어난 성과만 확보할 수 있습니다.

여기까지 읽으셨다면 다른 CDN(Content Delivery Network)과의 성능 비교를 기대했을 수도 있습니다. 그러나 특히 2025년 현재, 이러한 비교를 객관적으로 진행하기는 어렵습니다.

주요 이유 중 하나는 실제 사용자 CWV 지표가 CDN 속도뿐만 아니라, 사이트마다 크게 달라질 수 있는 프론트엔드·백엔드 프로그래밍과 특정 CDN 설정에 영향을 받기 때문입니다. 게다가 어떤 플랫폼에서도 빠른 웹사이트와 느린 웹사이트 모두 구축할 수 있습니다. 

대안으로는 TTFB와 같은 저수준 지표를 사용할 수 있습니다. 겉보기에 이 지표는 CDN 간에 쉽게 비교할 수 있을 것처럼 보입니다. 각 CDN에서 단일 오브젝트를 다운로드하고 연결 설정 및 요청 시간을 측정하기만 하면 끝나니까요. 

하지만 이러한 결과를 수집하는 것은 실제로 매우 간단하더라도, HTTP/3(및 HTTP/2)와 다중 오브젝트 연결이 일반화된 오늘날에는 점점 의미가 없어지고 있습니다. 스트림 우선순위 지정이나 대역폭 공유와 같은 고급 기능을 통해 이러한 연결을 효율적으로 (재)사용하는 것이 초기 연결 설정보다 최종 사용자 경험 및 LCP 같은 지표에 훨씬 더 중요하기 때문입니다.

또한 TTFB 측정 방식에 영향을 미치는 103 Early Hints, Early Data (0-RTT), DNS HTTPS 기록, Speculation Rules API 등 다른 기술들도 많습니다(이 내용은 "어떤 부분을 개선했나요?" 섹션에서 자세히 논의할 것입니다).

결과적으로, 한쪽은 해당 기능 중 하나도 활성화되지 않은 상태이고 다른 한쪽은 활성화된 상태인 두 개의 CDN에서 두 개의 단일 오브젝트에 대한 TTFB를 측정할 때 CDN의 실제 성능과 무관한 극단적으로 다른 결과가 나올 수 있습니다(그림 1-5 참조).

이 주장을 입증하기 위해, Akamai에서 벗어나면 TTFB가 크게 개선될 것이라는 벤치마크 예측을 지나치게 신뢰했던 고객 사례를 소개합니다(그림 6). 이 고객은 2024년 8월 초에 다른 솔루션으로 전환했지만 불행히도 공개 CrUX 데이터가 즉시 악화되었습니다.

Akamai는 과거의 벤치마크 기술에 의존하지 않고, 고객의 CWV 데이터를 통해 실제 사용자에게 미친 영향을 입증합니다. 과장된 약속에 현혹되지 마세요. 대신 세계 최대 사이트들의 CWV를 확인하세요. 이들 사이트는 대부분 Akamai를 사용하며 탁월한 성능을 유지하고 있을 가능성이 매우 높습니다.

지난 12개월 동안 Akamai가 진행한 개선 사항이 어떤 인상적인 결과를 가져오는지 확인했습니다. 이제 그 개선 사항이 구체적으로 무엇인지 살펴보겠습니다. Akamai는 다음과 같은 분야에서 개선을 진행했습니다.

• 플랫폼
• Akamai Image & Video Manager
• 보안 솔루션
• 실제 사용자 모니터링 및 옵저버빌리티

Akamai의 핵심은 최종 사용자에게 더 가까운 곳에서 더 많은 워크로드를 처리하는 고도로 분산된 플랫폼입니다. 이러한 광범위한 플랫폼을 통해 전례 없는 규모로 개선을 구축할 수 있습니다.

콘텐츠를 실제 사용자에게 최대한 빠르게 전달하기 위해 최근에 적용된 개선 사항은 다음과 같습니다.

• 103 Early Hints
• Early Data (0-RTT)
• 오리진까지 TLS 1.3
• Speculation Rules API
• DNS 최적화
• 반증폭 한계

캐시 불가능한 리소스나 캐시 미스 경우, Akamai 엣지 서버는 오리진 서버와 통신해야 합니다. 이 경우 클라이언트 브라우저와 Akamai 엣지 서버 간의 연결은 응답이 도착할 때까지 유휴 상태로 유지됩니다.

Early Hints를 통해 브라우저는 이 대기 시간을 활용해 지정된 리소스(예: 상위 CSS 스타일 시트, 웹 폰트, 로고, 중요한 자바스크립트)를 사전 로드하거나 써드파티 도메인 또는 서브도메인과 사전 연결할 수 있습니다. Akamai는 이러한 힌트에 대해 완전한 엣지 제어를 제공해 렌더링 경험(LCP)을 크게 가속하는 데 도움을 드립니다.

Early Data는 TCP(Transmission Control Protocol)의 HTTP/2 및 QUIC의 HTTP/3에 모두 적용되는 강력한 신규 기능입니다. 브라우저는 이 기능을 통해 대부분의 Akamai 엣지 연결에서 전체 네트워크 RTT(Round-Trip Time)를 절약할 수 있습니다.

또한 Early Hints와 같은 다른 옵션과도 잘 결합되어 데이터를 사용자의 브라우저에 가능한 한 빨리 전달할 수 있습니다. Akamai는 이 강력한 기능의 내재된 보안과 성능 간 균형을 세밀하게 설정할 수 있도록 지원합니다.

Akamai는 지속적 연결을 최대한 활용하지만 때로 엣지에서 오리진 서버로 새로운 TCP 연결을 구축해야 할 경우가 있습니다. TLS 1.3 지원을 추가해 TLS 1.2에서 필요한 추가 RTT를 피했습니다. 이러한 지연 시간 혜택을 활용하려면 오리진을 올바르게 설정해야 합니다.

새로운 Speculation Rules API를 활용해 미래의 내비게이션을 사전 로드하거나 사전 렌더링해 다중 페이지 애플리케이션의 속도를 높일 수 있습니다. 이 API는 사용자가 다음에 접속할 가능성이 있는 페이지를 사전 렌더링할 때 거의 즉각적인 로드 시간을 제공합니다.

Akamai는 Speculation Rules를 최종 사용자에게 전달하기 위한 다양한 옵션을 제공해 LCP 및 CLS와 같은 중요한 KPI에 큰 영향을 미칠 수 있습니다.

Akamai DNS 팀은 차세대 애니캐스트 DNS 아키텍처의 첫 번째 단계를 출시했습니다. 이 프로그램은 Megacloud라는 이름으로 진행 중이며, 22개의 독립 클러스터 중 8개가 이미 전환을 완료했습니다.

Megacloud는 각 애니캐스트 네트워크를 더 많은 위치에서 발표합니다. 이 전환은 공격에 대한 안정성을 해치지 않도록 복잡하고 신중하게 진행되고 있으며, 그 결과 모든 백분위수와 지역에서 애니캐스트 DNS 조회 속도가 향상되었습니다.

일반적으로 QUIC의 핸드셰이크는 네트워크에서 1 RTT만으로 완료됩니다. 그러나 Akamai는 특정 업계 보안 요구사항(RFC 9000)을 엄격히 준수해 왔기 때문에, 실제로는 많은 QUIC 연결이 2 RTT를 필요로 했으며, 이는 HTTP/3 연결에도 그대로 적용되었습니다.

Akamai는 이 문제를 해결하기 위해 QUIC의 반증폭 한계를 RFC에 따라 3에서 7로 높이고 연결을 구축하는 데 RTT 하나만 사용해 HTTP/3의 성능을 최대한 활용할 수 있게 되었습니다.

선명한 이미지는 현대 웹의 필수 요소입니다. 우수한 LCP를 위해 이미지가 빠르게 로드해야 할 때 Image & Video Manager의 두 가지 새로운 기능이 도움을 줄 것입니다.

• SharpYUV Chroma Subsampling: Akamai가 제공하는 두 가지 현대적인 이미지 형식인 AVIF 및 HEIF는 이제 SharpYUV 버전의 Chroma Subsampling을 사용해 더 나은 색상 표현과 압축 효율성을 제공합니다.

• Cache+: 이 새로운 애드온으로 Akamai Cloud Wrapper를 사용해 Image & Video Manager 파생 파일을 캐싱할 수 있습니다. Cloud Wrapper 내부에 전용 캐시 공간을 제공하므로 캐시 제거 정책 및 캐시 유지 기간을 보다 자유롭게 관리할 수 있습니다. 불필요한 재처리를 줄이고 이미지가 캐시에 더 오래 유지되도록 해, 요청 건수가 적은 롱테일 미스가 감소하면서 성능이 향상됩니다.

대부분의 고객은 보안에서 타협하길 원하지 않습니다. 하지만 그렇다고 성능을 신경 쓰지 않는 것은 아닙니다.

지난 12개월 동안 Akamai는 Akamai Bot Manager 및 Akamai Content Protector같은 보안 솔루션의 엣지 및 클라이언트 측 로직을 최적화했습니다. 클라이언트 측 라이브러리에는 다음과 같은 일반적인 자바스크립트 최적화가 적용되었습니다.

• 긴 작업을 작은 조각으로 분할
• 사용되지 않는 코드 제거
• 더 빠른 라이브러리로 전환
• 구형 코드를 더 빠른 버전으로 대체

이러한 최적화를 통해 전송되는 바이트 수가 줄어들어 핵심 경로의 혼잡이 완화되고, 자바스크립트 파싱 및 컴파일 시간이 단축되었습니다. 또한, 보안 솔루션이 TBT(Total Blocking Time) 및 INP(Interaction to Next Paint) 지표에 미치는 영향이 크게 감소했습니다(예: 그림 2 참조).

성능 지표와 다양한 최적화가 지표에 미치는 영향을 이해했습니다. 이제 다음과 같이 질문할 수 있습니다. "어떻게 측정할까요?" 특히 여러 클라우드 공급업체, 다양한 서비스, CDN을 사용할 때 엔드투엔드 가시성을 확보하기가 어려울 수 있습니다.

다행히 이러한 특정 운영 문제를 해결하기 위한 Akamai mPulse RUM(Real User Monitoring) 솔루션과 CDN 옵저버빌리티 등의 솔루션이 있습니다.

• CWV 원인 분석 대시보드: 사이트가 느리다는 것을 아는 것과 느린 이유를 알아내는 것은 다릅니다. 이 문제를 해결하기 위해 여러 새로운 mPulse 위젯을 제공합니다. 위젯은 CLS 문제의 원인을 파악하고, 가장 심각하고 자주 발생하는 INP 원인을 식별하고, LCP 요소를 분류하는 데 도움을 줍니다.

• 새로운 지표 및 타이머: mPulse에 다양한 흥미로운 타이머와 차원이 추가되었습니다. 일반적인 가시성 간극을 제거하고 RUM 노이즈를 줄이고, 가장 관련성 높은 데이터로 심층 분석에 도움을 줍니다. 여기에는 Frustrationindex, Page CDN Cache Status, 네 가지 새로운 Front-End Timers, BFCache 정보가 포함됩니다.

• UNO(Unattributed Navigation Overhead): 새로운 타이머는 다른 타이머에서 고려되지 않은 내비게이션의 "알 수 없는" 및 "추가" 시간 구간을 누적합니다. 여기에는 브라우저 지연, 디스크 접속 시간, 크로스-오리진 제한으로 인해 숨겨진 시간 등이 포함될 수 있습니다. 이 지표는 간극을 메우고 놓칠 수 있는 문제를 발견하는 데 도움을 줍니다.

• Akamai DataStream 2가 업데이트되어 성능에 관심 있는 사용자를 위한 추가 데이터 포인트를 포함합니다.

  • TLS 초기 데이터 및 103 Early Hints 필드 지원
  • Akamai EdgeWorkers 지원
  • TrafficPeak 대상 지원

• Breadcrumbs: 새로운 Breadcrumbs 기능으로 콘텐츠 전달 시 성능에 영향을 미치는 조건과 오류 상태를 실시간으로 확인할 수 있습니다.

• CMCD(Common Media Client Data): 비디오, 음악, 게임 등 콘텐츠를 스트리밍하는 디바이스에서 성능 데이터와 사용 지표를 수집하는 것은 스트리밍 성능을 측정하는 데 필수입니다. 식별 및 방어:

  • 버퍼링 이벤트
  • 느린 시작 시간
  • 재생 품질 문제
  • 오류율
  • 처리량

Akamai는 지난 12개월 동안 현대 애플리케이션을 더 빠르게 만들기 위해 여러 개선 사항을 도입했습니다. 이는 단순히 이론상만이 아니라 실제 사용자에게도 적용됩니다. 이러한 변경 사항의 영향은 CrUX 데이터에서 반복적으로 명확히 나타나며 CWV 결과의 상당한 개선으로 이어져 최종 사용자 경험과 Google 검색 엔진 순위를 모두 향상시킵니다.

Akamai는 많은 개선 사항에 만족하지만, 보안, 확장성, 가용성을 고려하면서 추가 밀리초를 절감할 수 있는 기회가 항상 존재합니다.

향후 몇 주, 몇 달, 몇 년에 걸쳐 순차적으로 더 많은 최적화를 적용할 예정입니다. 더 빠른 미래를 기대하며 계속 주목하시기 바랍니다.