안녕하세요 하루들입니다!
하루들은 우리끼리 통하는 일상을 네컷만화로 나누는 서비스예요. 만화를 만들고, 다시 찾아보고, 누군가에게 보여주는 경험에서 가장 중요한 건 결국 만화 자체인데요.
화면에 제목과 버튼이 먼저 나타나더라도, 정작 그림이 보이지 않으면 이야기를 읽을 수 없어요.
그런데 실제로 사용자에게서 이미지가 너무 늦게 뜬다는 피드백을 받았어요. 만화를 보러 들어왔는데 이미지를 기다리는 시간이 길었던 거죠. 저희는 이 기다림부터 줄여보기로 했어요.
이번 글에서는 하루들의 이미지 로딩을 어떻게 살펴봤고, 어떤 기준으로 이미지 형식과 크기를 바꾸었는지 이야기해보려고 해요.
성능을 개선한다고 하면 먼저 점수나 로딩 시간을 떠올리기 쉬워요. 하지만 저희는 그전에, 사용자가 어떤 순간에 기다리고 있는지부터 정하고 싶었어요.
이번에 고른 흐름은 네컷만화 상세 화면에서 목록으로 돌아오는 과정이에요. 만화 한 편을 보고 돌아왔다면, 다음에 볼 만화도 바로 고를 수 있어야 하니까요.
예전에 홈 화면에 있던 이 목록은 지금은 "네컷 모아보기" 탭으로 옮겨져 있어요. 측정 기준도 아래와 같이 정했답니다.
목록 이동 버튼을 누른 순간부터, 목록 위쪽 썸네일 3개가 모두 표시될 때까지.
단순히 화면이 나타나는 순간이 아니라, 실제로 만화를 알아보고 고를 수 있는 순간을 기준으로 삼은 거예요. 썸네일은 화면에 완전히 보이는 3개를 기준으로 했어요.
모바일에서 만화를 확인하는 상황을 고려해, 다음 조건으로 측정했어요.
도구: PC의 Chrome 개발자도구
화면: iPhone SE 프리셋
네트워크: Slow 4G
CPU: 4배 느림
개선 전에는 같은 흐름으로 3번 측정했어요. 썸네일 3개가 모두 나타날 때까지 약 24.00초, 23.16초, 23.15초가 걸렸고, 중앙값은 약 23.2초였어요.
다음 만화를 고르기까지 수십 초를 기다려야 했던 거예요.
저희는 이 시간을 3회 측정 중앙값 기준 3초 이하로 줄이는 것을 목표로 잡았어요. 빠르게 느껴지는지 막연하게 판단하기보다, 개선 후에 같은 행동을 다시 측정하고 목표에 도달했는지 확인하고 싶었거든요.
원인을 찾을 때는 Chrome의 Network와 Performance를 함께 봤어요.
Network: 이미지가 얼마나 많이, 얼마나 오래 전송되는지 확인
Performance: 버튼을 누른 뒤 실제 화면에 이미지가 나타나는 순간을 확인
이미지를 다 받아오는 시간과 사용자가 볼 수 있는 시간은 다를 수 있으니까요.
Network에서 정상적으로 받아온 이미지 4개를 살펴보니, 각각의 요청에 약 20~30초가 걸렸어요. 목록으로 돌아올 때도 이미지가 다시 전송되고 있었고요.
저희는 먼저 이미지 하나를 보여주는 데 필요한 데이터부터 줄여보기로 했어요.
기존에는 목록과 상세 화면 모두 1024×1024 PNG 이미지를 사용하고 있었어요. 만화를 크게 펼쳐보는 화면과, 여러 편 중 하나를 고르는 작은 썸네일이 같은 이미지를 받아오고 있었던 거죠.
하지만 두 화면에서 이미지가 하는 역할은 달랐어요.
목록: 그림을 알아보고 어떤 만화인지 고를 수 있어야 해요.
상세: 대사와 그림의 선까지 읽을 수 있어야 해요.
그래서 모든 화면에 같은 원본을 보내는 대신, 용도에 맞는 이미지를 따로 만들기로 했어요.
백엔드에서는 cwebp를 사용해 PNG를 WebP로 변환하고, 목록용과 상세용 이미지를 각각 생성하도록 바꿨어요. 프론트엔드에서도 화면에 맞는 이미지를 사용하도록 적용했습니다.
용도 | 변경 전 | 변경 후 |
|---|---|---|
목록 썸네일 | 1024×1024 PNG | 240×240 WebP |
만화 상세 | 1024×1024 PNG | 960×960 WebP |
물론 용량만 줄일 수는 없었어요. 하루들에서 이미지가 핵심이어서 빠르게 뜨더라도 화질 저하로 인해 만화를 읽기 어려워지면 의미가 없으니까요.
이미지 크기를 정할 때는 화면에 표시되는 크기와 DPR을 함께 고려했어요. DPR은 화면에서 사용하는 픽셀과 실제 화면 픽셀 사이의 비율이에요.
예를 들어 DPR 2에서는 화면에 390px 너비로 보여줄 이미지에 780px 정도의 해상도가 필요하다고 볼 수 있어요. 상세 화면의 최대 표시 크기가 390×390 CSS px라서, 그보다 여유 있는 960×960px을 선택했어요.
목록은 당시 표시 너비가 약 130px이었어요. 여기서는 대사를 자세히 읽기보다 화질지 좋지 않더라도 그림을 알아보고 만화를 선택하는 역할이 더 중요하다고 봤어요.
그래서 240×240px을 후보로 두고 실제 표시 크기에서 원본과 변환본의 화질, 용량을 비교했어요. 모든 화면에 가장 선명한 이미지를 보내기보다, 그 화면에서 필요한 역할을 유지하는 쪽으로 기준을 세운 거예요.
상세 이미지의 화질은 팀원들에게도 의견을 물었어요. 원본과 WebP를 나란히 놓고 의도적으로 비교하지 않는 이상 차이를 느끼기 어렵다는 의견을 받았어요.
이를 바탕으로 원본의 화질을 그대로 유지하기보다, 만화를 읽는 데 지장이 없는 수준에서 전송량과 기다리는 시간을 줄이기로 했어요.
아래는 같은 만화의 원본 PNG와 상세용 960px WebP예요.
원본 1024×1024 PNG
상세용 960×960 WebP
변경 후에는 이미지 전송량과 목록 표시 시간을 다시 확인했어요. 먼저 결과를 정리하면 다음과 같아요.
확인한 항목 | 개선 전 관찰 | 개선 후 관찰 |
|---|---|---|
표본 이미지당 평균 전송량 | 약 1,102kB | 약 13.1kB |
목록 이미지 개별 요청 시간 | 약 20~30초 | 3회 모두 1초 이내 |
목록 복귀 후 썸네일 3개 표시 | 중앙값 약 23.2초 | 중앙값 약 3.23초 |
확보한 PNG 6장과 WebP 썸네일 4장의 전송량을 비교했어요. 서로 다른 표본의 평균을 비교한 값이지만, 확보한 표본에서는 이미지당 평균 전송량이 약 98.8% 작았어요.
목록의 정상 이미지 4개를 대상으로 요청 시간도 3회 확인했어요. 개선 후에는 측정한 모든 이미지 요청이 1초 이내에 완료됐어요. 앞서 약 20~30초가 걸렸던 요청과는 차이가 컸죠.
같은 기준으로 3번 측정한 결과 약 3.18초, 3.25초, 3.23초가 걸렸어요. 중앙값은 약 3.23초였고요.
처음 정한 3초 목표보다는 약 0.23초 길었어요. 이미지 요청은 1초 안에 끝났지만, 사용자가 기다리는 전체 시간은 아직 목표에 도달하지 못한 거예요.
서비스에 남아 있는 서로 다른 만화 두 편을 비교했어요.
PNG: 요청 시간 약 10.77초, 전송량 약 1,402.1kB (3회 측정 중앙값)
WebP: 요청 시간 약 0.94초, 전송량 약 54.9kB (1회 관찰)
이미지를 가볍게 만든 뒤에도 목록으로 돌아올 때 월간 목록 조회 API는 매번 한 번씩 호출되고 있었어요.
만화를 새로 만들거나 삭제하지 않았다면 같은 목록을 다시 보여줘도 되는데, 데이터를 다시 기다리고 있었던 거예요.
그래서 다음에는 같은 달의 조회 결과를 재사용하는 캐싱을 검토하려고 해요. 다만 무조건 저장된 데이터를 쓰는 것은 아니에요.
새로 조회해야 하는 상황도 함께 정해야 해요.
만화가 새로 생성되거나 삭제됐을 때
이미지 URL이 만료됐을 때
아직 이 캐싱은 적용하지 않았어요. 적용한 뒤에는 같은 조건과 요청을 차단하지 않은 정상 목록에서 다시 측정할 계획이에요.
이번 작업을 하면서 하루들에서 중요한 성능은 화면이 나타나는 속도만이 아니라, 사용자가 만화를 실제로 볼 수 있을 때까지의 시간이라는 걸 다시 느꼈어요.
이 경험을 기준으로 측정하니, 큰 이미지의 전송 부담과 목록 데이터를 다시 기다리는 문제를 나눠서 볼 수 있었고요.
이미지 요청이 빨라진 것만으로 처음 세운 목표를 달성한 건 아니었어요. 앞으로도 같은 질문을 기준으로, 남은 시간을 줄여가려고 해요.
목록으로 돌아와 만화를 고를 수 있기까지, 얼마나 기다리는가?
일상을 네컷만화로 나누는 즐거움이 기다림에 가려지지 않도록, 하루들을 계속 다듬어갈게요. 그 과정도 함께 공유하겠습니다!
