최근에 회사에서 아래와 같은 요청사항이 들어왔다.
'상세페이지를 들어가는데 많이 느린 것 같아요'
그렇다. 항상 미루고있던 숙제같은 성능개선의 요구사항을 받았던 것이다. CS가 들어오기 전에 개발팀에서 자체적으로 개선해서 고객들이 불편함을 느끼지 못하게 하는게 최선이지만 기능을 추가하거나 이전 백로그들을 처리하는데 급급하다보니 챙기지 못했던 것 같다.
그러나 이제는 미룰수 없다.
그치만, 이번 요청사항은 기존에 받아왔던 기능 추가 같은 "명확한" 요구사항과는 조금 다른 느낌의 요구사항이였다. 어떤 상세페이지를 들어가는데 많이 느리다는 상대적이고 얼마나 빠르게 해야되는지 또한 모호하다. 그리고 개선 사항의 기준이 없다면 개선된 후에도 빨라졌는지 느낌으로 QA을 할 수 밖에 없는... 대참사가 벌어질 것 같았다.
그렇기 때문에 상세페이지 라우팅이 빨라진 "느낌" 보다는 정확한 "수치"를 통해서 개선 사항을 증명, 확신해야겠다는 생각을 들었다. 그때 떠올랐던 것은 얼마전에 인프런에서 진했던 인프콘 강연 중에 <디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기 - 배휘동> 강연 내용이였다. 그 강연 중에서는 디버깅하는 과정을 아래와 같이 5단계로 나누고, 해결해 나가는 과정으로 정의한다.
- 문제 정의
- 정상 작동 정의
- 최소 재현 환경 구축하며 관찰
- 차이를 발생 시키는 다양한 원인 탐색
- 가설 설정 및 검증
이번 디버깅 과정을 강연에서 나온 5가지 단계로 나눠서 어떻게 해결했었는지 나눠서 이야기 해보려한다.
1. 문제 정의
우선, "상세페이지를 들어가는데 많이 느린 것 같아요" 라는 요구사항은 정확한 문제가 아니라고 생각했다. 조금 더 구체적이고 근본적인 문제상황은 "Nextjs로 만들어져 있는 프로덕트의 상세페이지로 라우팅할때 html을 받아오는 시간이 오래걸린다." 라고 더 자세하게 문제를 정의할수 있었다. 이 문제 상황이 자세하고 구체적이라고 판단한 이유는 html을 받아오는 시간을 개발자 도구의 network tab에서 측정할 수 있기 때문이었다. 또 다른 후보로는 상세페이지의 LCP(Largest Contentful Paint) 가 너무 오래걸린다 정도로 생각해볼 수 있었다. 이 역시 페이지 단위로 light house로 LCP를 측정할 수 있기 때문에 "측정 가능한" 문제 정의라고 할 수 있겠다.
2. 정상 장동 정의
업계 표준과 사용자 경험, 그리고 다른 라우팅페이지들의 평균을 고려했을때 HTML 로딩은 1초 이내가 적정선이라고 판단하였다.놀랍게도 고치기 전에는 2.72s의 응답속도로 엄청나게 느린 것을 볼 수 있었다.
3. 최소 재현 환경 구축하며 관찰
이 부분은 이미 재현이 되고 있는 현상이라서 따로 재현 환경을 구축할 필요가 없었다.
4. 차이를 발생 시키는 다양한 원인 탐색
개발 환경에서 상세페이지 로딩을 테스트하며, Network 탭을 통해 병목 구간을 관찰했다. 여러 요인 중 SSR 로직에서의 지연이 주요 원인으로 의심되었다.역시나 확인해보니 해당 상세페이지의 데이터 페칭과정에서 api call을 7개나 부르고 있었고 그 7개의 api call 중에 특히나 오래걸리는 API가 존재할 것이라는 가설을 세워서 디버깅하였다.
5. 가설 설정 및 검증
Next.js의 SSR 처리 과정을 심층 분석한 결과, 데이터 페칭 과정에서의 비효율적인 쿼리와 불필요한 중복 요청이 있음을 발견되었다. 그 API를 제거하고 SSR시점이 아닌 CSR시점에서 부르도록 옮겼더니 2.7s 걸리던 HTML 응답속도가 80ms로 현저하게 개선된 것을 알 수 있었다.
조금 더 백그라운드를 설명하자면 API 중에 게시물이 인기게시물인지 아닌지를 판단하는 api가 존재하는데 조회수를 디비에서 조회하는데 조회수가 많이 쌓이다보니 점점더 백엔드 응답속도가 느려진... 백그라운드가 있었다. (이 부분은 추후에 백엔드에서 개선해서 업데이트 나간 상태이다.)
마무리
이러한 체계적인 접근을 통해, "느낌"이 아닌 "수치"로 검증 가능한 성능 개선을 달성할 수 있었습니다. html 응답속도 뿐아니라 앞서 말했던 LCP와 같은 수치들도 같이 높여서 더 부드러운 UX 만들어야겠다는 생각을 하는 계기가 되었다. 또한 Nextjs 에서 무분별하게 SSR을 쓰는 것이 성능에 안좋을 영향을 끼칠 수 있다는 것도 느끼면서 SSR 시점에서는 seo 데이터나 빠르게 보여줘야할 정보를 가진 api 등 SSR시점에서 필요한 api 데이터 페칭만 해야겠다는 생각을 했다.
