코어 웹 바이탈 LCP 개선을 통한 검색 엔진 최적화(SEO) Part 1: Google Search Console, Next.js

Do not index

안녕하세요. 오토피디아에서 프론트엔드 개발을 맡고 있는 유서경입니다. 올해 2월 초에 회사에 입사하여 벌써 두 달이 넘는 시간이 흘렀는데요, 이번 글에서는 저의 첫 프로젝트였던 SEO 개선을 위한 모바일 버전 LCP 향상에 대해 이야기해보려 합니다. 이 글은 자연 검색 유입을 늘리기 위해 구글에서 측정하는 코어 웹 바이탈 중 하나인 LCP를 단기간에 집중적으로 개선한 과정을 단계적으로 구성하였습니다. 또한, 비교적 최근 도입된 메트릭인 “LCP를 어떻게 효율적으로 개선해야할까?”에 대해 저와 비슷한 고민을 하시는 개발자 분들께 도움이 될 것이라 생각합니다. 프로젝트를 맡고 3주 동안 발생한 사건을 시간 순으로 전개하는 방식으로 글을 작성하였으니 신입 개발자를 체험하고 회상하는 느낌으로 재미있게 읽어주시길 바랍니다.

들어가며 0. 프로젝트 온보딩 0.1 프로젝트 개요: SEO는 왜 필요한가요?0.2 프로젝트 목표: 정량적 개선 지표 파악하기 1. 공식 문서가 떠먹여주는 LCP 개선 방법 코어 웹 바이탈(Core Web Vitals)LCP(Largest Contentful Paint)1.1 구글 개발팀이 직접 알려주는 LCP 개선 방법 1.2 Lighthouse가 떠먹여주는 웹 성능 개선안 2. 닥터차 웹 성능 개선하기: 사례를 중심으로 2.1 Resource load delay 줄이기: LCP는 누구인가?2.2 Resource load time 줄이기: 이미지 최적화 2.3 Element render delay 줄이기: Tree shaking 적용 Tree shaking 2.4 폰트 최적화 Third-party에서 Local로 폰트 제공 폰트 포맷 최적화 내부 cdn을 사용하여 폰트를 캐싱하도록 변경 3. 개선 결과 확인하기 3.1 어떤 데이터로 결과를 확인해야 할까요?3.2 It ain't over till it's over 1부를 마치며 참고자료

들어가며

💡

이 글은 크게 아래 3 가지 주제에 대해 다룹니다. 1. 코어 웹 바이탈 LCP 개선을 통한 SEO 향상으로 자연 유입 사용자를 늘리기 2. Google Search Console에서 LCP를 모니터링하고 Lighthouse를 사용하여 개선하기 3. Vercel Analytics를 사용하여 필드 데이터를 확인하고 구글에서 집계하는 필드 데이터를 찾아가기

자주 등장하는 키워드이므로 한 번씩 눈에 담아보시는걸 추천드립니다.

자연 유입 고객, SEO 향상

코어 웹 바이탈, LCP

이미지 최적화, JS 번들 최적화, 폰트 최적화

Lighthouse, PageSpeed Index, Vercel Analytics

0. 프로젝트 온보딩

사내에서는 SEO 고도화라고 명명된 본 프로젝트는 닥터차 웹의 Google Serach Console 내 모바일 코어 웹 바이탈 개선을 위해 LCP 지표를 향상하는 것을 목표로 하고 있습니다. 이 섹션에서는 프로젝트의 개요부터 정량적 목표를 설정한 과정을 잘게 쪼개서 설명해보겠습니다.

0.1 프로젝트 개요: SEO는 왜 필요한가요?

웹 서비스는 출시 이전 개발 과정도 고되지만 출시 이후 사용자를 모으기 위한 과정은 더 큰 노력이 필요합니다. 오토피디아의 닥터차 서비스는 어떻게 고객들을 모으고 있을까요? 오토피디아에서는 [사진 1]과 같은 대시보드에서 다양한 경로로부터 유입된 고객들에 대한 정보를 확인할 수 있으며, 놀랍게도 이번 1 분기 기준으로 약 70%(사진 1의 짙은 파란색과 분홍색 영역)가 자연 유입 고객🌱입니다. 자연 검색 유입(Organic search)란 광고를 통해 유저 클릭 당 비용이 발생하는 방법이 아닌 자연 검색으로 유입되는 층을 말합니다. 이 유입량을 높이기 위해서는 우리가 익히 들어왔던 시멘틱하게 웹사이트 구조를 만들거나 높은 품질의 콘텐츠를 제공하여 검색 엔진 최적화(SEO)를 이뤄내야 합니다. 본 프로젝트에서는 그 방법들 중 하나인 모바일 사용선 개선을 최우선 목표로 하고 있습니다.

0.2 프로젝트 목표: 정량적 개선 지표 파악하기

자연 유입 지표를 확인하기 위해 여러 매체에서 지원하는 리포팅 툴들이 있지만, 이번 프로젝트는 Google Search Console을 기준으로 진행하였습니다. 실제 닥터차 서비스 유입 고객의 절반 이상[사진 1]이 네이버 자연 유입 고객이지만, 구글이 더 명확한 가이드라인과 지표를 제안하고 있다고 판단하였고 구글 기준으로 SEO를 개선한다면 네이버, 다음 등 타 매체의 자연 유입량도 함께 증가할 것으로 기대하고 있습니다.

사진 2. 닥터차 웹의 Google Search Console 페이지 경험 개요

현재 닥터차 웹의 자연 유입 지표는 어떨까요? 구글에서는 2021 년 중순부터 Google Search Console의 페이지 경험을 자연 검색 순위 지정 시스템의 일부로 사용하고 있습니다. 페이지 경험은 코어 웹 바이탈 측정 항목(LCP, FID, CLS 등)과 모바일 사용 편의성 그리고 URL 보안을 기준으로 평가됩니다. 닥터차 웹은 데스크톱에서 99.9%가 우수하지만 안타깝게도 대부분의 모바일 URL에서는 좋지 않은 페이지 경험을 보이고 있습니다[사진 2].

사진 3. Google Search Console: 코어 웹 바이탈 > 모바일 > LCP 문제

불행 중 다행인 것은 Google Search Console에서는 LCP라는 단 하나의 문제[사진 3]만을 개선 사항으로 여기고 있다는 점입니다. 그러나 영향을 받은 URL이 약 9천개에 달하기 때문에 빠른 개선이 필요하였고 모바일에서도 데스크톱과 같은 우수한 페이지 경험을 갖게하는 것을 프로젝트의 목표로 설정하게 되었습니다.

💡

프로젝트 정량적 목표: 모바일 URL 페이지 경험 99.9%를 우수하게 만들기

1. 공식 문서가 떠먹여주는 LCP 개선 방법

이제 모바일 페이지 경험 개선을 위해 닥터차 웹의 LCP를 0.1 초만 향상하면 된다는 단순한 목표로 귀결되었습니다. LCP는 무엇일까요? LCP는 구글이 페이지 경험을 측정하는 코어 웹 바이탈 측정 항목 중 하나입니다.

코어 웹 바이탈(Core Web Vitals)

코어 웹 바이탈(Core Web Vitals)이란 웹페이지의 로딩 속도, 모바일 친화성, 보안, 시각적 안정성 등 사용자 경험을 정량적으로 측정하는 지표입니다. 공식문서에도 나와있듯이 이 지표는 필드에서 사용자가 실제 경험한 결과를 기반으로 기록되며, 이 사실은 글의 뒷 부분에서 아주 중요하게 다루게 됩니다.

사진 4. 코어 웹 바이탈 측정의 3가지 메트릭(출처: https://web.dev/i18n/ko/vitals/)

LCP(Largest Contentful Paint)

사진 5: LCP 측정 기준(출처: https://youtu.be/fWoI9DXmpdk?t=70)

LCP는 세 가지 코어 웹 바이탈 중 비교적 최근 만들어진 메트릭으로 페이지 내 가장 큰 렌더링 요소(이미지/텍스트)의 렌더링 시간을 측정합니다.

측정 시작점: 페이지 처음 로드 시작 시점

측정 범위: Viewport 내의 블록

좋은 LCP란? 75번째 백분위 수 이내의 유저에게 2.5초 이하[사진 5]

LCP는 웹사이트의 메인 콘텐츠의 로딩 속도를 기준으로 “이 서비스가 유용한가?”를 판단한다고 합니다.

구글은 대표성, 정확성, 안정성 등 여러 속성을 만족하는 메트릭을 제작하려 노력하고 있고 아래 영상에서 개발자의 성능 측정 메트릭에 대한 굉장히 재밌는 이야기를 들어볼 수 있습니다.

출처: https://youtu.be/ctavZT87syI?t=734 : Lessons learned from performance monitoring in Chrome | Annie Sullivan | performance.now() 2019 — 출처: https://youtu.be/ctavZT87syI?t=734 : **Lessons learned from performance monitoring in Chrome | Annie Sullivan | performance.now() 2019**

1.1 구글 개발팀이 직접 알려주는 LCP 개선 방법

LCP는 비교적 최근 도입된 지표 중 하나로 Google Chrome Developers에 따르면 이 조건을 충족하는 웹사이트는 드물며 많은 개발자들이 어려워하는 성능 지표라고 합니다. 따라서 구글에서는 이 지표와 개선 방법에 대해 아주 친절히 설명해주고 있으며 영상과 글을 함께 참고하시길 바랍니다.

사진 6. 4단계로 나눈 LCP 측정(출처: https://web.dev/optimize-lcp/)

간단하게 말하자면 LCP 측정은 4단계로 나뉘며 구글에서는 아래의 해결 방법을 2 → 4 → 3 → 1 의 순서로 적용해보기를 권하고 있습니다. (참고로 1,3 단계보다 2,4 단계를 개선하는 편이 더 간단하다고 합니다.)

Time to first Byte: 브라우저가 페이지 렌더링에 필요한 추가 리소스를 찾음

해결 방법

HTML 페이지를 가능한 빨리 전달하기 위해 CDN 사용, 서버 하드웨어 업그레이드 등으로 네트워크 속도 향상

가장 달성하기 어렵지만 즉각적으로 영향을 주는 단계

Resource load delay: 브라우저가 필요한 리소스를 로딩

해결 방법

불필요한 로딩 딜레이를 줄이기 위해 LCP 요소를 pre-loading하거나, 가능한 같은 origin에서 리소스를 제공하여 네트워크 딜레이 줄이기

Resource load time: LCP 리소스가 스스로 로딩

해결 방법

가능한 LCP 리소스 크기를 줄이기: 이미지 크기 및 포맷 최적화, 캐시 사용, CDN을 사용한 네트워크 거리 단축

Element render delay: LCP 리소스가 사용자 화면에 렌더링

해결 방법

JS 파일 사이즈 최적화로 JS 로딩 시간을 줄이거나, SSR/SSG를 통한 서버측 렌더링으로 LCP 요소를 로드하고 곧바로 렌더링

1.2 Lighthouse가 떠먹여주는 웹 성능 개선안

이제 개선 방법을 어느정도 알았으니 LCP를 직접 측정하여 적용해보는 단계입니다. Chorme devTools에서도 지원하는 Ligthouse를 사용하면 쉽고 빠르게 웹 리포트를 확인할 수 있습니다. 프로젝트 시작정이 닥터차 웹사이트는 [사진 7]과 같이 웹 성능(Performance)을 제외하고 상당히 좋은 점수를 가지고 있습니다.

그러나 Google Search Console의 페이지 경험과 동일하게 Lighthouse에서도 LCP가 상당히 높게 나타나 개선이 필요해보입니다[사진 8]. 개인적으로 Lighthouse를 사용하면서 가장 좋았던 경험은 하단 OPPERTUNITIES에서 개선 방법에 대해 자세히 설명해주고, 심지어 Next.js 프레임워크를 사용하는 경우 더 구체적인 솔루션을 제시해준다는 점이었습니다. 이제 우리는 구글이 잘 떠먹여준 해결 방안들을 바탕으로 코드를 고치러가면 됩니다.

2. 닥터차 웹 성능 개선하기: 사례를 중심으로

사진 9. LCP 개선이 필요한 URL의 Lighthouse 점검 결과 목록

저는 구글의 가이드라인을 바탕으로 Lighthouse가 제안하는 개선점들의 우선순위를 매겨 순차적으로 해결하는 방식을 사용했습니다. Lighthouse의 결과는 네트워크 상황과 같은 가변적 외부 요인에 따라 상이한 리포트를 제공합니다. 따라서 반복 실험을 통해 [사진 9]와 같은 리스트를 얻었고 중요도, 발생 빈도 그리고 구글 가이드라인을 바탕으로 순서를 매겨 해결해나갔습니다.

💡

[사진 6]을 함께 참고하면서 글을 읽으신다면 이 파트를 더 면밀히 이해하실 수 있습니다.

2.1 Resource load delay 줄이기: LCP는 누구인가?

먼저 구글에서 제안한 가장 쉽고 빠른 방법인 LCP 요소를 미리 로딩하는 방법을 적용해보겠습니다. 현재 문제가 되는 페이지에서 LCP 요소는 누구일까요? 닥터차 웹사이트에서는 고객이 남긴 문의사항 길이에 따라 LCP 요소가 변경됩니다. [사진 10]의 좌측처럼 문의사항이 긴 경우에는 텍스트로, 우측처럼 문의사항이 짧은 경우에는 이미지가 LCP 요소로 선정됩니다. LCP 요소가 텍스트인 경우 리소스 로딩 시간 자체가 존재하지 않으므로 LCP 지표에서는 유리하지만, 실제 웹사이트에서 뷰포트 내 가장 큰 요소를 텍스트로 유지하는 것은 상당히 까다로운 일입니다. 따라서 비교적 LCP가 높게 형성되는 이미지 LCP 요소에서는 [사진 11]의 개선안처럼 이미지 프리로딩(pre-loading)을 적용해볼 수 있습니다.

사진 11. Lighthouse의 Preload Largest Contentful Paint image

Next.js에서는 next/image에 priority 속성을 추가하면 간단하게 높은 우선순위로 해당 이미지를 프리로딩하여 리소스 로드 지연 시간을 줄일 수 있습니다.

HTML attribuites: rel="preload" fetchpriority="high" as=image 와 같은 효과

Lazy loading 자동 비활성화

import Image from "next/image";

<Image
  src={src}
  ...
  priority //추가된 속성
/>

눈여겨볼 만한 점은 우리가 웹 성능 개선을 위해 흔히 사용하고 있는 lazy loading은 LCP에 역효과를 야기하므로 뷰포트 내의 이미지에는 적용하지 말아야 한다는 것입니다. 또한, 뷰포트 크기에 따라 가변적으로 LCP 요소가 선정되므로 가능성이 있는 여러 개의 이미지에 모두 프리로딩을 적용해주어야 합니다.

적용 결과

그 결과 LCP 요소가 다른 리소스에 비해 늦게 로딩되는 것을 방지할 수 있고 아래 사진과 같이 리소스 자체의 load delay(#2)를 줄일 수 있습니다. 그러나 이미지 리소스가 커서 #2 영역을 줄여도 #3 영역인 JS 파일 로딩과 겹칠 경우, LCP 감소에 직접적인 영향을 주지는 못하여 극적인 효과를 기대할 수는 없습니다.

사진 6의 #2 줄이기 (출처: https://web.dev/optimize-lcp/)

2.2 Resource load time 줄이기: 이미지 최적화

사진 12. Lighthouse의 Serve images in next-gen formats

2.1의 문제 해결은 LCP 이미지 리소스 자체의 크기를 줄여야 LCP 감소 효과를 확인할 수 있습니다. 따라서 JS 로딩시간 단축([사진 6]의 #4)을 우선으로 제안하고 있으나, Next.js를 사용하면 아주 간편하게 이미지 최적화가 가능하므로 저는 이 단계를 우선적으로 개선하였습니다. 닥터차 웹에서는 몇몇 이미지를 next/image 가 아닌 <div> 의 background-image로 처리하고 있었고 이 부분들을 모두 변경하고 자동 이미지 최적화를 간편하게 적용하였습니다. Next.js에서는 이미지 포맷 및 캐싱 등 이미지와 관련된 최적화를 자동으로 제공하고 있습니다.

적용 결과

그 결과 LCP 요소의 자체 로드 시간이 줄어들면서 LCP가 감소 효과를 얻을 수 있게 되었습니다.

사진 6의 #3 줄이기 (출처: https://web.dev/optimize-lcp/)

2.3 Element render delay 줄이기: Tree shaking 적용

사진 13. Lighthouse의 Reduce unused JavaScript

이전까지의 단계는 아주 단순한 코드로 LCP를 개선할 수 있었습니다. 이제는 JS 파일 크기를 줄이기 위해 사용하지 않는 JS를 감지하고 제거할 차례([사진 6]의 #4)입니다. 놀랍게도 [사진 13]에서 붉은색 빗금 영역이 모두 미사용 JS로 감지된 상황이었습니다. 개인적으로 번들링에 대한 개념이 취약하여 이 단계가 가장 어려웠고 아직까지도 개선 여지가 많다고 생각합니다.

Tree shaking

우리의 사랑스러운(❤️) Next.js에서는 Webpack Bundle analyzer를 사용하면 번들링 결과를 쉽게 확인할 수 있고, 이를 tree shaking의 지표로 이용할 수 있습니다. Tree shaking이란 외부 모듈 사용 시 필요한 것만 가져오는 것을 이야기합니다. 저는 TOAST UI에서 작성한 글을 참고하였고 CommonJS 형식의 라이브러리의 경우 웹팩의 tree shaking을 사용하기 위해서는 다른 import 구문을 사용해야 한다고 합니다. 해당 방법을 적용하여 모든 페이지에서 공통으로 로드되는 앱(_app) 페이지의 JS 번들 사이즈를 635KB에서 522KB로 약 17.8% 감소시켰습니다.

그 외에도 Next.js를 사용한다면 Dynamic Import를 사용하여 외부 라이브러리를 lazy loading하는 방법도 존재합니다. 이 방법도 굉장히 유용하지만 현재 단계에서는 페이지 별로 각각 적용해야하므로 우선적으로 공통 앱(_app) 페이지 개선을 위해 tree shaking을 먼저 적용하였습니다.

적용 결과

JS 파일의 크기를 줄이면 아래 사진처럼 LCP를 대폭 개선할 수 있습니다. 물론 하나의 페이지를 렌더링하기 위해 여러 JS 파일이 로드되므로 앱(_app) 페이지 최적화로 완전하게 지연을 해소할 수는 없습니다.

사진 6의 #4 줄이기(가) (출처: https://web.dev/optimize-lcp/)

따라서 웹사이트에 SSR이나 SSG를 적용하여 미리 만들어진 페이지를 제공하면 극적으로 LCP가 감소됩니다. 닥터차 웹은 Next.js 프레임워크를 사용하여 SSR을 적용하기에 매우 편리했고, 이 부분은 프론트엔드 개발을 함께 담당해주시는 소령님이 담당하여 개선해주셨습니다.

사진 6의 #4 줄이기(나) (출처: https://web.dev/optimize-lcp/)

2.4 폰트 최적화

Third-party에서 Local로 폰트 제공

사진 15. Lighthouse의 Eliminate render-blocking resources

이제 대부분의 개선 사항을 해결하였다고 생각(해치웠나..?)하여 프로젝트를 마무리하려던 중 새로운 개선 사항이 발생했습니다. 그 원인은 프로젝트 진행 과정에서 닥터차 웹의 일부 브라우저에서 폰트 미적용 버그가 발생했고, 이를 해결하기 위해 외부 환경에서 폰트를 로딩하는 스크립트를 추가했기 때문이었습니다. Lighthouse에서는 next/script 사용을 추천하였으나 폰트는 스크립트로 제공되지 않으므로 폰트를 다운받아 로컬에서 직접 관리하는 방법을 선택하였습니다. Next.js 버전 13 이후는 @next/font로 손쉽게 관리할 수 있지만 닥터차 웹은 아직 버전 12를 사용하고 있으므로 public 폴더와 globalcss 파일에서 관리하는 방법을 적용하였습니다.

폰트 포맷 최적화

사진 16. Lighthouse의 Avoid enormous network payloads

슬프게도 이 해결책은 로컬 폰트 파일이 너무 커서 네트워크에 막대한 페이로드를 발생한다는 다른 문제를 불러왔습니다. 이 문제는 기존 ttf 확장자보다 크기 최적화가 되어있는 최신 글꼴 형식인 woff2를 우선적으로 로드하여 어느정도 해결할 수 있습니다. 여전히 닥터차 웹에서는 해당 경고가 발생하지만 red → yellow light로 바뀌었다는 점과 서드파티보다는 로컬 관리가 낫다는 점을 고려하여 포맷 최적화를 적용하기로 하였습니다.

97.01%의 환경에서 woff2 형식을 지원하며 그 외 환경은 ttf 형식으로 지원하게 됩니다.

내부 cdn을 사용하여 폰트를 캐싱하도록 변경

재밌게도 폰트 관련 이슈는 생각보다 많은 꼬리 질문들을 야기했습니다. 본 내용으로 사내 런치톡을 발표할 기회가 있었고 “폰트 리소스의 캐싱”에 대한 새로운 관점이 있었습니다. 비교적 대용량의 리소스를 매번 가져오는 것은 불필요하므로, 내부 cdn에 폰트 파일들을 업로드하였고 폰트 캐싱을 통해 더 나은 성능 최적화를 이룰 수 있었습니다.

3. 개선 결과 확인하기

3.1 어떤 데이터로 결과를 확인해야 할까요?

사진 17-1. 개선 완료 후 Lighthouse의 리포트 - 해결되었는데

사진 17-2. 개선 완료 후 Lighthouse의 리포트 - 아니었습니다.

자, 이제 개선이 완료되었으니 LCP가 감소되어 Google Search Console에서 닥터차 웹의 모바일 URL을 “좋음”으로 평가하고 있는지 확인하면 저의 첫 프로젝트가 마무리됩니다. 그런데 이 지표는 어떻게 확인해야 할까요?먼저 Lighthouse에서 이 결과를 확인하면 [사진 17 - 1]과 [사진 17 - 2]와 같이 꽤 큰 차이가 발생하는 것을 볼 수 있으며, 실제로는 성능 점수가 Red - Green light를 오갈 정도로 편차가 상당히 컸습니다. 구글에서 제공하는 PageSpeed Index 역시 마찬가지였습니다.

그럼에도 불구하고 실험 데이터가 전반적으로 낮아졌기 때문에 SEO가 개선되었을 것으로 기대하였지만, 개선 사항이 순차적으로 배포되어도 Google Search Console의 변화는 없었고 실제로 개선되었는지 파악할 방도가 없었습니다. 이 부분이 제가 프로젝트를 진행하며 가장 혼란스웠던 단계였지만 함께 프로젝트에 참여하신 승수님, 케빈과 함께 아래와 같은 해결 과정을 도출할 수 있었습니다.

Lighthouse(실험 데이터)에서 오류가 없더라도 실제 필드 데이터를 기반으로 페이지 경험을 측정하는 Google Search Console에서는 다른 병목 현상을 지닐 수 있습니다.

Google Search Console은 지난 28 일간의 데이터를 모니터링하므로 현재 개선 사항이 반영되려면 시간이 필요합니다.

실제 사용자 데이터를 기반의 코어 웹 바이탈을 측정할 수 있는 Vercel Analytics를 결제하여 현재 필드 데이터로 닥터차 웹의 LCP 지표를 확인하여 현재 개선 사항에 대한 즉각적인 모니터링이 가능합니다.

따라서 현 닥터차 웹의 LCP를 모니터링하기 위해 Vercel Analytics를 결제하였고 실제 사용자를 통해 집계되는 필드 데이터를 얻을 수 있었습니다. 아래 [사진 18]의 결과를 확인하면 LCP가 약 1.7 초로 구글에서 좋은 LCP로 판단하는 2.5초 이내를 잘 만족함을 확인할 수 있습니다. Vercel에서는 데스크톱의 LCP를 1.6 초로 더 타이트하게 잡았지만 구글에서는 2.5초로 모바일과 동일하게 책정하므로 큰 문제가 되지 않습니다. 또한 모든 코어 바이탈이 초록불로 닥터차 웹은 상당히 좋은 성능으로 평가되었습니다.

3.2 It ain't over till it's over

이 글이 Part 1이 된 이유는 Vercel의 필드 데이터를 확인했음에도 불고하고 시간이 지나도 Google Search Console 상의 개선이 일어나지 않았기 때문입니다. 사실 2.6초였던 LCP가 2.8초로 오히려 나빠져 저를 충격에 빠뜨리고 있었습니다.. 🤯 추후 발행될 Part 2에서는 실제 “구글이 집계하는 필드 데이터”를 찾아가는 여정이 진행될 예정입니다. 지표 개선 뿐만이 아니라 지표 모니터링에 대해서도 제대로 파악해야 한다는 것을 프로젝트를 하며 가장 많이 느끼고 있습니다.

1부를 마치며

만족스러운 Vercel Analytics 데이터를 끝으로 3 주 동안의 저의 첫 프로젝트가 마무리(🥳)될 줄 알았으나… 2부에서 구글의 웹 바이탈 지표를 더 파헤쳐보는 시간을 가질 예정입니다. 그럼에도 불구하고 Vercel에서 모바일 기준으로는 거의 만점에 가까운 결과(🥳)를 얻었다는 점에서 큰 성취감을 느꼈습니다. 프로젝트 초입의 필드 데이터가 없어 종료 후 데이터와 직접 비교하여 웹 성능이 얼마나 좋아졌는지 정량적으로 확인하지 못하는 점은 상당히 아쉽습니다.

아직 프로젝트가 종료되지는 않았지만 입사 후 첫 프로젝트를 함께 해주신 오토피디아 동료분들께 감사의 말씀을 올립니다. 초기 프로젝트의 목적과 방향성을 잘 잡아준 케빈, 개선 결과가 나타나지 않아 헤매고 있을 때 길잡이가 되어준 승수님, 그리고 닥터차 웹 레포에서 모르는 코드가 있을 때 친절히 알려준 소령님, 대니, 반석님께 감사합니다. 또한, 이 글을 런치톡에서 발표하였을 때 한 마음으로 더 나은 방향성에 대해 함께 고민해주신 메이커 직군 여러분들도 감사드립니다. 긴 글 읽어주셔서 감사드리며 신입 개발자의 첫 프로젝트의 성공적인 마무리를 함께 응원해주시며 다음 글을 기다려주시면 더욱 감사하겠습니다.