실수로 인한 느림 vs 설계로 인한 느림: 웹 성능 프레임워크

실수로 인한 느림 vs 설계로 인한 느림.

Core Web Vitals를 수정하거나 이에 대해 논의하기 위해 저를 고용한다면, 어느 시점에서 실수로 인한 느림 대 설계로 인한 느림에 대해 이야기하는 것을 듣게 될 것입니다. 저는 이것이 중요한 구분이라고 생각하며, 이 글에서는 이것이 Core Web Vitals를 개선하는 데 어떻게 도움이 되는지 설명하겠습니다.

최종 검토자: Arjen Karel, 2026년 3월

누군가 Core Web Vitals에 대한 상담 및 수정을 요청할 때는 항상 문제가 있습니다. 느림은 항상 안티 패턴에서 비롯됩니다. 예를 들어 '지연 로드된 Largest Contentful Paint 이미지', '크고 최적화되지 않은 이미지', '슬라이더', '차단하는 JavaScript' 등이 있습니다.

안티 패턴을 도입하는 데는 많은 것이 필요하지 않습니다. 때로는 플러그인을 설치하거나 모범 사례를 잠시 잊는 것만으로도 안티 패턴이 생성될 수 있습니다.

저는 이러한 안티 패턴을 '실수로 인한 느림'과 '설계로 인한 느림'으로 분류하는 것을 좋아하는데, 이를 수정하는 방식이 완전히 정반대이기 때문입니다.

2025 Web Almanac에 따르면 모바일 오리진의 48%만이 세 가지 Core Web Vitals를 모두 통과합니다. 제 경험상, 이러한 실패의 대부분은 몇 시간 만에 고칠 수 있는 '실수로 인한 느림' 문제에서 비롯됩니다.

실수로 인한 느림

저는 '실수로 인한 느림' 안티 패턴을 아주 좋아합니다. 페이지를 느리게 만드는 무언가를 했고 실수를 저질렀습니다. 이렇게 하는 훨씬 더 빠른 방법이 있다는 것을 몰랐습니다. 걱정하지 마세요. 저는 실수를 고칠 수 있습니다.

따라서 이러한 '실수'를 분류하는 것은 의미가 있습니다. 이는 개발 팀에 보낼 수 있는(또는 제가 직접 고칠 수 있는) 수정하기 쉽고 영향력이 큰 개선 사항 목록을 제공합니다. 보통 논의가 거의 필요하지 않습니다. 이러한 안티 패턴을 개선하는 것은 모든 면에서 합리적입니다. 수정되면 Core Web Vitals가 개선될 것입니다.

제가 매일 접하는 안티 패턴의 몇 가지 예입니다. 무엇이 문제이고 그 이유를 설명하면 보통 '아, 이게 페이지를 느리게 만들 줄 몰랐어요'라는 반응을 얻습니다.

1. 지연 로드되지 않은 이미지

가장 일반적인 안티 패턴은 지연 로드되지 않은 이미지입니다. 지연 로드되지 않은 이미지는 페이지 로딩 초기 단계에서 다운로드 대기열에 추가됩니다. 이는 네트워크 및 CPU 리소스를 사용합니다. 보이지도 않는 이미지에 귀중한 리소스를 할당하는 것은 이치에 맞지 않죠? 오프스크린 이미지 지연에 대해 자세히 알아보세요.

정반대의 실수도 마찬가지로 흔합니다. LCP 이미지 지연 로딩입니다. 약 15%의 사이트가 이렇게 하며, 이는 페이지에서 가장 중요한 이미지를 더 빨리 로드하는 대신 더 느리게 만듭니다.

2. 타사 폰트

웹 폰트는 훌륭합니다. 페이지의 모양과 느낌을 사용자 정의하고 향상시킵니다. 안타깝게도 Google Fonts와 같은 타사 제공업체를 사용하면 특정 상황에 맞게 폰트를 최적화하지 못합니다.

타사 폰트는 렌더링을 차단하는 추가 스타일시트와 웹 서버에 대한 새로운 연결(원본 서버에 대한 매우 빠른 연결이 이미 있음에도 불구하고)을 필요로 하며, 실제 사용하는 것보다 더 많은 폰트를 브라우저에 추가할 가능성이 높습니다.

폰트를 자체 호스팅하고, 이를 미리 로드하며, 각 폰트 파일에 사용자 정의 폰트 로딩 전략을 할당하는 것이 훨씬 더 합리적입니다. 그것이 바로 또 다른 빠른 개선입니다!

3. 타사 스크립트

타사 스크립트 자체에는 아무런 문제가 없지만, 페이지에 추가되는 방식 때문에 많은 문제를 일으킵니다. 저는 실제로 전체 페이지를 차단하는 중요하지 않은 타사 스크립트(예: Facebook 추적 픽셀, 소셜 미디어 버튼, 평가 위젯 등)를 자주 접합니다.

브라우저가 더 중요한 작업을 완료할 때까지 이러한 스크립트를 지연시키고 예약하는 것은 비교적 쉽고 합리적입니다. 결과적으로 사이트에서 중요한 것은 아무것도 변경하지 않았으며, 여전히 똑같이 보이고 훨씬 더 빠르게 로드됩니다. 단지 일이 처리되는 순서를 바꿨을 뿐입니다.

4. 배경 이미지

Core Web Vitals 관점에서 배경 이미지는 별로 의미가 없습니다. 배경 이미지는 기본 지연 로딩을 지원하지 않으며, 반응형이 아니고, 타이밍과 우선순위를 제어할 수 없습니다.

몇 가지 간단한 수정을 통해 이러한 배경 이미지를 지연 로드하고, 반응형으로 만들며, 우선순위를 조정할 수 있는 일반 이미지로 변환할 수 있습니다. 이는 확실히 Largest Contentful Paint를 개선할 것입니다.

5. 대용량 스타일시트

스타일시트는 렌더링을 차단합니다. 즉, 브라우저가 스타일시트를 로드하는 동안 페이지는 빈 상태로 유지됩니다. 이를 해결하기 위해 할 수 있는 일이 많습니다. 예를 들어, 사용하지 않는 스타일을 제거하거나, 스타일시트를 분할하거나, 브라우저 캐싱을 개선하거나, Critical CSS를 추가할 수 있습니다.

스타일시트를 개선하고 나면 Largest Contentful Paint와 First Contentful Paint가 극적으로 개선될 것입니다!

설계로 인한 느림

설계로 인한 느림은 걱정해야 할 부분입니다. 페이지를 느리게 만드는 구조적인 선택을 했습니다. 이는 대개 좋은 해결 방법이 없을 정도로 페이지의 보이는 부분을 수정하는 UX 디자인 선택이나 JavaScript 코드와 관련이 있습니다.

'설계로 인한 느림'의 문제점은 작은 변경을 통해 즉시 고칠 수 없다는 것입니다. 더 많은 계획과 핵심 사이트 기능의 재작성이 필요합니다.

제가 가장 먼저 해야 할 일은 의도를 파악하는 것입니다: 왜 이렇게 했나요? 어떤 점을 고려했고 정확히 무엇을 달성하고자 했나요? 그런 다음 해당 매개변수 내에서 더 나은 대안을 찾습니다!

다음은 가장 일반적인 '설계로 인한 느림' 실수의 몇 가지 예입니다.

1. 슬라이더

슬라이더는 보통 다음과 같이 작동합니다. 페이지가 렌더링될 때 JavaScript가 페이지에 슬라이더를 주입합니다. 이 JavaScript가 없으면 페이지는 완전히 다르게 보일 것입니다. 이는 더 긴 Largest Contentful Paint, 아마도 Layout Shift, 그리고 높은 확률로 Interaction to Next Paint (INP) 문제를 야기할 것입니다.

빠른 해결책은 없습니다. JavaScript를 지연시키면 페인트 지표는 개선되지만 슬라이더가 지연되고 Layout Shift가 발생합니다. 슬라이더 스크립트를 중요하게 만들면 Layout Shift는 해결되지만 페인트 지표가 느려집니다.

해결책은 페이지를 점진적으로 향상시키는 것입니다. 먼저 슬라이더가 JavaScript 없이 렌더링되는지 확인한 다음, 페이지를 향상시키고 이미 있는 슬라이더 이미지를 전체 슬라이더로 변환합니다.

재미있는 점은 방문자의 약 1%만이 실제로 슬라이더를 클릭한다는 것입니다. 제가 이것을 설명하면 10번 중 9번은 사이트 소유자가 즉시 슬라이더를 제거할 것을 제안합니다. 그렇기 때문에 이러한 슬라이더의 의도와 고려 사항에 대해 묻는 것이 중요합니다. 보통은 '그냥 거기에 있었기' 때문입니다.

2. 제품 확대

제품 확대는 다음과 같이 작동합니다. 일반적인 웹숍에서 제품 이미지 위로 마우스를 가져가면 제품의 일부를 확대할 수 있습니다. '제품 확대'는 보통 슬라이더와 같은 문제를 가집니다. JavaScript 코드의 일부가 이미지를 가져와 숨긴 다음, 확대/축소 가능한 이미지로 페이지에 다시 씁니다. 이는 더 긴 Largest Contentful Paint, 아마도 Layout Shift, 그리고 높은 확률로 Interaction to Next Paint (INP) 문제를 야기할 것입니다.

슬라이더와의 차이점은 제품 소유자가 "아, 이 기능을 그냥 제거하세요"라고 말하지 않는다는 것입니다. 그것은 중요하며 전환율을 높입니다.

해결책은 슬라이더 수정과 동일합니다. 확대 스크립트는 원본 이미지를 숨기지 않고 제품 이미지 기능을 확장해야 합니다. 안타깝게도 확대 기능은 대개 쉽게 수정되지 않으며, 제대로 작동하게 하려면 약간의 작업이 필요합니다.

3. 인라인 jQuery / 인라인 JavaScript 종속성

인라인 jQuery는 '실수로 인한 느림'으로 시작되었지만 시간이 지나면서 악화된 문제입니다. 제가 살펴보는 사이트의 약 50%가 이 문제로 어려움을 겪고 있습니다. W3Techs에 따르면 jQuery는 여전히 모든 웹사이트의 약 70%에서 실행되고 있으므로, 이는 곧 사라지지 않을 것입니다. 인라인 스크립트는 이전 스크립트(주로 jQuery)에 의존하기 때문에 더 이상 jQuery를 지연할 수 없습니다. 이로 인해 모든 페인트 지표가 지연됩니다.

수정은 간단합니다. 이 스크립트들을 외부 스크립트로 이동하기만 하면 됩니다. 이제 jQuery와 사용자 정의 스크립트를 모두 지연시킬 수 있습니다.

그렇다면 왜 이것을 '설계로 인한 느림' 범주에 넣었을까요? 의도와 고려 사항에 대해 물어보면 보통 '아, 모르겠어요'라는 대답을 듣습니다. 그리고 그것이 진짜 문제입니다. JavaScript 작동 방식에 대한 지식이 부족합니다. 저는 이 실수가 미래에 반복될 것이라고 확신할 수 있습니다. 이는 해결책이 수정과 동일하지 않음을 의미합니다. 저는 개발 팀에 JavaScript 종속성과 타이밍에 대해 교육해야 할 것입니다.

4. 대형 (히어로) 이미지

설계로 인한 또 다른 느림 문제는 큰 이미지입니다. 일부 사이트는 많은 풀 사이즈 이미지로 '청중을 놀라게' 할 필요가 있습니다. 포스터를 판매한다고 상상해 보십시오. 방문자에게 고품질의 큰 이미지를 제공하고 싶을 것입니다. 이러한 이미지는 아무리 최적화하더라도 더 작은 이미지보다 다운로드하는 데 항상 더 많은 시간이 걸립니다.

이 시점에서 (이미지가 모두 최적화되었다고 가정할 때) 제가 할 수 있는 유일한 일은 조정할 여지가 있는지 확인하는 것입니다. 정말로 4k 이미지가 필요한가요, 아니면 Full-HD로도 충분할까요? 실용적인 기술에 대해서는 느린 히어로 이미지를 수정하는 방법을 참조하세요.

5. 대화형 지도

제가 자주 접하는 또 다른 문제는 대화형 지도입니다. 페이지에 대화형 지도가 있을 때 이 페이지의 전체 의도는 방문자가 지도와 상호 작용하도록 만드는 것입니다. 당연히 해당 지도를 로드하는 데 시간이 걸릴 것입니다.

이것을 피할 방법은 없습니다. 우리는 약간의 느림을 수용해야 할 것입니다. 하지만 우리가 할 수 있는 일들이 있습니다. 지도가 가장 높은 우선순위로 로드되도록 할 수 있습니다. 일반적으로 이러한 페이지는 초기 JavaScript 실행에 최적화되어 있지 않습니다. 이 경우에는 잘못된 선택이었습니다. 스크립트가 가능한 한 빨리 다운로드되고 실행되어야 합니다! 저는 PageSpeed를 잃지 않고 Google Maps를 삽입하는 방법에 대한 전체 가이드를 작성했습니다.

6. 느린 API

느린 API로 인해 발생하는 설계로 인한 느림 문제는 주로 React, Next.js 또는 Angular와 같은 SPA 사이트에서 볼 수 있습니다. 느린 API는 일반적으로 사용자 상호 작용 후에 구성 요소가 너무 늦게 렌더링되기 때문에 큰 Layout Shifts를 발생시킵니다. 이와 같은 문제에는 대개 다중 팀 접근 방식이 필요합니다.

Core Web Vitals와 관련하여 실수로 인한 느림과 설계로 인한 느림을 구분하는 것은 유용할 수 있습니다. 실수로 인한 느림은 대개 쉽게 고쳐지는 반면, 설계로 인한 느림은 보다 철저한 다차원적 접근이 필요합니다. '실수로 인한 느림' 문제를 분류하고 수정한 후에는 Real User Monitoring을 설정하여 영향을 추적하세요. 현장 데이터는 귀하의 수정이 실제 방문자의 경험을 실제로 개선했는지 알려줍니다. 그러면 남은 것이 그것뿐이기 때문에 데이터에서 '설계로 인한 느림' 문제가 명확하게 돋보일 것입니다.