이전 글에서 모아동 동아리 상세페이지의 활동사진 탭 전환 시 이미지 로딩 지연 문제를 구조적으로 개선했었습니다!
탭 클릭 시 컴포넌트를 새로 마운트하지 않고, 미리 마운트한 상태에서 display만 전환하도록 바꾼 방식 덕분에 체감 UX는 확실히 좋아진 것을 확인할 수 있었어요!
다만, 단순히 좋아졌다로 끝나기 보다 수치적으로 설명할 수 있다면 훨씬 객관적인 증명이 될 것 같았습니다.
코드 리뷰를 통해서도 Lighthouse 기준으로 LCP before/after 수치를 한 번 측정해서 비교해보는게 개선 효과를 수치적으로 보여줄 수 있을 것 같다는 좋은 조언을 받았습니다!
처음 들어봤는데, 저도 이 작업을 좀 더 수치적으로 설명하고 싶었기 때문에 너무 좋은 조언이었고 바로 시도해보기로 했습니다!
다만,,, 이 질문에 답하려다 예상보다 많은 고민과 시행착오를 겪게 되었네요...ㅎ
이번 글은 그 고민과 시행착오들에 대해 이야기해보려 합니다. 그리고 어떻게 해결해나갔는지까지...한 번 작성해보도록 할게요
처음 시도한 방법 : Lighthouse
가장 먼저 시도하게 된 도구는 Lighthouse 였습니다. 저는 처음 사용해보는데, 웹 성능을 이야기할 때 가장 흔히 언급되는 도구인 것 같습니다. 리뷰를 통해서도 추천받았기 때문에 사용해보고자 했습니다.
다만, 측정을 시작하자마자 이상한 점이 보였습니다. LCP(Largest Contentful Paint)에 활동사진 이미지가 잡힐 것이라 기대한 것과는 다르게 상세페이지의 다른 이미지만 LCP로 측정되고 있었기 때문입니다.
처음에는 "내가 뭔가 잘못 측정하고 있나?"라는 의문이 들었습니다... 단순히 이미지가 화면에 나타나는 속도와 관련된 지표일 줄 알고 개선 후가 개선 전보다 빠르게 보이니... 성능이 좋아질 것이라고 막연히 생각했던 것 같아요
이미지처럼... 수치가 측정되는데, 개선 후 측정 결과는 61로 더 높은 수치를 확인해볼 수 있었습니다. 제 생각과 다르기도 했고, 어떻게 좋아진 것을 보여줄 수 있을지 모르겠어서...계속 찾아본 결과
이번 개선은 초기 페이지 로딩에 대한 것이 아니라, 페이지가 이미 열린 후, 탭 전환 시의 렌더링 속도를 개선한 작업이었기 때문이었습니다.
찾아보니, Lighthouse는 기본적으로 "페이지 최초 진입 시 사용자에게 처음 보이는 화면"을 기준으로 성능을 측정하는 것이었어요
그리고 LCP 역시 초기 화면에서 실제로 보이는 요소만을 대상으로 삼는 것이어서...
활동사진 탭의 경우, 초기 화면에 보이지 않는 부분이고, 최종 개선된 구현에서도 display:none 상태로 미리 마운트되어 있어서...
DOM에 존재하지만 보이지 않는 요소이기 때문에 개선 전과 후 모두 활동사진은 LCP 후보가 될 수 없는 것 같았습니다.
따라서... 이때 Lighthouse로 이 개선을 비교하는 것은 큰 의미가 없겠다고 생각했습니다.
두 번째 시도 : Performance 탭
그 다음으로 떠올린 방법은 Chrome DevTools의 Performance 탭이었습니다. 이전에 시도한 결과를 통해... 지금 개선을 비교할 때 필요한 것은 페이지 최초 로딩 부분이 아니라, 탭 전환 부분을 측정해야 했기 때문에 가능한 방법으로 찾았습니다.
이 도구는 사용자 이벤트 이후의 렌더링, 네트워크 요청, 메인 스레드 작업을 모두 볼 수 있어서
"탭 클릭 -> 이미지 표시"라는 흐름을 분석하기에 더 적합해 보였습니다.
하지만... 실제로 측정을 해보니 또 다른 어려움이 있었습니다...ㅜ
페이지 진입 시점부터 모든 과정이 한 타임라인에 찍혀서 처음 해보는 저에게는 뭐가 뭔지 알아보는 것부터...어려웠습니다.
이런식으로 보이고 탭 클릭 이후만 정확히 잘라서 보기가 힘들었어요
무엇보다도 개선된 최종 구현에서는 탭 클릭 이전에 컴포넌트와 이미지의 마운트가 진행되기 때문에 탭 클릭 시에도 새로운 렌더링이 거의 발생하지 않아서 이 도구에서도 "개선 전과 명확히 비교할 수 있는 이벤트"를 찾기 어려웠습니다.
이렇게...두 도구를 사용해보면서 "이 작업을 어떻게 측정할 수 있을까?", "측정해서 유의미한 결과를 얻을 수 있나?"라는 고민에 빠졌습니다.
LCP는 오히려 나빠질 수 있다
Lighthouse는 초기 로딩 성능을 측정하기 위한 도구였고,
Performance 탭은 분석 도구이지, 비교 지표를 위한 도구는 아니었습니다.
그리고 이번 개선은 의도적으로 초기 비용을 늘리고, 상호작용 UX를 개선한 구조였죠
이 작업을 도구를 통해 활동사진 로딩 속도가 개선된 것을 증명하려고 하니 어려웠던 것 같습니다.
단순히, 성능이 좋아지도록 한 것이 아니기 때문에...
수치가 안 좋아진 것이 어떻게 유의미한 결과를 보여줄 수 있을까? 같은 생각을 했는데... 이게 잘못된 생각이었습니다.
이번 개선은 상세페이지 진입 시 활동사진 이미지까지 함께 마운트되기 때문에 이미지 네트워크 요청을 앞당겨 초기 네트워크/렌더링 비용이 증가하는 부분이 있었습니다.
즉, 초기 성능 지표인 LCP가 악화되는 것은 자연스러운 구조였습니다. 이 결과 자체가 이번 개선의 결과를 증명해주고 있는 것인데,
다른 개선 작업과 달리, 의도적으로 성능을 악화시켜서 즉각적인 UX 반응을 얻어냈기 때문에 어떻게 측정해야할지 생각하는 것이 어려웠던 것 같습니다.
결국 선택한 측정 방식은?
그래서 지금까지 시도한 이 도구들을 이용하면 된다고 판단했습니다. 지금까지는 도구들을 사용하면서도 "더 악화된 결과를 가지고 어떤걸 증명할 수 있지?"라는 생각과 활동사진 로딩 시간을 측정할 수 없으니 그 부분에 빠져서 제대로 생각하지 못 했던 것 같네요
Lighthouse
이 도구를 이용해서 초기 성능 지표가 개선 이후에 악화된 것을 확인할 수 있는데,
그걸로도 증명할 수 있겠다라는 것을 깨달았습니다.
이미지 로딩 속도가 빨라진 반면, 이를 위해 상세페이지 진입 시 보이지 않는 활동사진 컴포넌트가 미리 마운트되어 있어 초기에 비용이 많이 드는 것은 의도된 결과였습니다. 따라서 아래와 같이 수치로 성능을 확인해볼 수 있는데,
Largest Contentful Paint (LCP)
[1차 시도]
- 개선 전 : 47.5s
- 개선 후 : 60.4s
[2차 시도]
- 개선 전 : 47.6s
- 개선 후 : 60.5s
[3차 시도]
- 개선 전 : 47.5s
- 개선 후 : 60.3s
개선 전은 47.5s, 개선 후는 60.4s로 거의 고정적인 수치 패턴을 확인할 수 있었습니다.
여러 차례 측정 결과, 개선 이후 LCP는 일관되게 증가했기 때문에, 이 수치만을 보면 개선 후 LCP 값이 증가하여 성능이 안 좋아졌다고 오해할 수 있지만, 아래에서 프레임 관련 개선을 보면 사용자 UX 측면에서는 훨씬 개선된 것을 확인할 수 있습니다.
그리고 LCP에 원래는 활동사진이 포함된다고 생각했는데, 상세페이지의 동아리 대표 이미지가 LCP의 대상이었습니다.
그래서 이 측정값이 이 작업에서는 의미가 없을 것이라고 생각했지만,
이는 개선 후 탭 전환 시 이미지가 빨리 보이도록 한 것을 고려한 것으로
활동사진 이미지들은 페이지 진입 시점에 미리 로드하여 초기 네트워크 요청 수가 증가했기 때문에 LCP의 대상인 동아리 대표 이미지의 로딩이 뒤로 밀리게 되면서 악화된 결과였습니다.
오히려 의도한 트레이드오프 결과가 그대로 수치에 드러난 것이며 이를 통해 의도한 대로 개선되었다는 것을 확인할 수 있습니다.
Performance 탭
수치를 비교하기 위한 것이 아니라 구조 변화에 대해 설명하기 위해 활용할 수 있었습니다.
개선 후에는 탭 클릭 시 추가적인 렌더링/네트워크 요청이 사라졌기 때문에, 그 흐름을 통해 알 수 있었습니다.
타임라인에서 탭 클릭 이벤트 위치를 찾아서 비교해봤습니다. 먼저 Network 트랙 이벤트를 확인해봤습니다.
개선 전을 확인해보면, 상세페이지 진입 후 활동사진 탭을 클릭한 이후 이미지 요청이 발생하는 것으로 확인할 수 있습니다.
.jpg, .png 파일들이 새로 등장되면서 탭 클릭 시점에 <img>가 생성되어 그때 그때 네트워크 요청이 발생하는 것입니다.
반대로 개선 후를 확인해보면, 상세페이지 진입 시에 이미 <img>가 생성되어 마운트되어 있기 때문에, 활동사진 이미지 네트워크 요청이 발생하지 않습니다. 탭 클릭이 된 시점에는 새로운 이미지 요청이 없는 것을 확인해볼 수 있었습니다.
다음으로는 Frames 트랙을 살펴보았습니다.
개선 전을 확인했을 때, 탭 클릭 이후 프레임 밀도가 증가한 모습을 볼 수 있습니다.
화면이 한 번에 뜨지 않고 활동사진이 로딩되는 것에 시간이 걸려 단계적으로 완성되는 것입니다.
그래서 사용자 입장에서는 빈 영역이 보이면서 이미지가 하나씩 뜨는 것 같은 체감 지연이 발생했다는 것을 알게되었어요
반면, 개선 후에는 프레임 변화가 거의 없는 것을 확인해볼 수 있습니다.
프레임 변화가 거의 없으며, 이미 완성된 화면을 탭 클릭 시점에 보여주기만 하도록 개선한 것이기 때문이었습니다.
눈으로 직접 렌더링 과정을 확인하며 프레임 단위로 살펴보니 신기했습니다.
체감 UX
지금까지는 위의 도구를 이용하여 성능으로 검사를 하지않고, 영상을 통한 비교만을 하여 보여줬습니다.
위의 2가지 도구를 이용해서 훨씬 근거있는 설명이 되겠지만,
그래도 역시 실제 사용자 경험에서의 변화가 가장 중요한 결과이기 때문에,
눈으로 보이는 UX가 크게 개선된 부분을 보여줄 수 있는 것이 역시나 가장 큰 증명이 되는 것 같습니다.
아래의 링크에서 이전 작업 글을 보시면, 크게 개선된 것을 영상으로도 확인할 수 있을 겁니다!
[모아동] React 탭 전환 시 이미지 로딩이 느린 이유와 UX 개선 방법
작년 8월부터 합류하여 개발하고 있던 모아동 프로젝트에서 이번에 이미지 최적화 작업을 시도하게 되었습니다이 프로젝트는 현재 아래의 링크를 통해 확인해볼 수 있습니다! 모아동모아 동아
suhyun113.tistory.com
이번 과정을 통해 Lighthouse, Performance 등의 도구를 처음 사용해봐서 신기했습니다.
잘 모르는 도구를 사용하다보니, 수많은 시행착오를 겪고 잘못 생각하고 시도하고 있었기에 생각보다 많이 돌아서간 느낌이지만,,,
모든 성능 개선이 지표 개선으로 이어지는 것은 아니다라는 것도 알게되었습니다.
수치가 있다면 당연히 신뢰성을 좀 더 높일 수 있는 근거가 되겠지만, 수치 그 자체보다도 왜 이런 선택을 했고 사용했는지를 항상 설명할 수 있는게 중요한 것 같습니다. 단순히 개발을 하는 것이 아니라 이 방식을 왜 도입했고, 그 이유를 적절히 설명할 수 있어야 다른 사람들도 납득시킬 수 있고 더 개선할 수 있는 것 같습니다.
'프로젝트 > 모아동' 카테고리의 다른 글
| [모아동] 앱 버전 관리를 위해 WebView 라우트를 분리한 이유와 구현 방법 (0) | 2026.02.06 |
|---|---|
| [모아동] 웹에서는 괜찮았는데 앱에서는 깨졌다 - WebView와 앱 버전의 문제 (1) | 2026.02.01 |
| [모아동] React 탭 전환 시 이미지 로딩이 느린 이유와 UX 개선 방법 (0) | 2026.01.29 |