들어가며이전 글에서는 지도 마커의 생성과 갱신, React 렌더링을 살펴봤다. 이번에는 서비스에 처음 들어왔을 때의 로딩 성능을 개선해보기로 했다.처음에는 비교적 단순하게 생각했다.사용하지 않는 이미지를 정리하고, 이미지 용량을 줄이고, 페이지별로 코드 스플리팅을 적용하면 되지 않을까?다만 랜딩 페이지는 변경될 예정이었기 때문에 거기에서 사용하는 이미지는 일단 건드리지 않기로 했다. 그래서 이번에는 코드에서 줄일 수 있는 부분부터 찾아봤다.페이지 코드를 나누고, 설치 안내와 로드뷰 라이브러리를 필요한 시점에 불러오도록 바꿨다. 마지막에는 네이버 지도 SDK 다운로드도 메인 번들과 함께 시작하도록 변경했다.이 정도 했으면 로딩 성능에도 차이가 있겠지 싶었다.그런데 막상 측정해보니 Lighthouse 점수는..

들어가며 우리 서비스는 지도 위에 주변 주차장을 마커로 표시한다. 처음에는 모든 주차장을 큰 마커로 표시해서, 주차장이 밀집된 곳에서는 마커가 서로 겹치는 문제가 있었다.이전 글에서는 이 문제를 해결하기 위해 줌 레벨에 따라 일부 주차장은 대표 마커로, 나머지는 작은 점으로 표시하는 LOD를 적용했고, 그래도 화면에 점이 많이 남아 있어서 주차장을 요청하는 범위도 화면 중앙으로 줄이는 과정을 담았다.당시 CPU 4배 스로틀링, Fast 4G 조건의 측정에서는 dropped frame으로 집계한 이벤트가 111개에서 16개로 감소했다. 처음에는 LOD도 렌더링 성능 개선에 영향을 줬다고 생각했다. 그런데 다시 코드를 보니 의문이 생겼다.큰 마커를 작은 점으로 바꾸기는 했지만, 점 마커도 네이버 지도 SDK..

들어가며우리 서비스에 진입하면 제일 먼저 보이는 홈페이지는 첫 번째 이미지와 같았다. 클러스터링도 적용되어있지 않았고, 그냥 모든 주차장을 전부 마커로 표시했다. 이 글에서 첫 화면에서 두 번째 화면으로 개선한 과정을 이야기해보고자 한다. 첫 화면은 환공포증에 걸릴것만 같은 모습이다.우리 팀은 프로젝트를 막 시작할 때 주차장 도메인 서비스중 가장 큰 서비스인 '모두의 주차장' 을 타겟으로 잡았다.모두의 주차장의 홈페이지 모습은 다음과 같다. 정보들이 한 눈에 들어오지도 않을 뿐더러, 너무 난잡하다.우리가 해결하고자한 여러 불편함들중에 신경써서 해결해야할 부분으로 홈페이지에서의 마커 UI·UX를 꼽았다. 문제 해결 과정화면에 주차장 정보들을 보여주긴 해야하는데, 모두의 주차장은 펫말형식으로 전부 표시해버리..

나는 대화를 할 때 경청을 상당히 중요하게 생각한다.어릴 때 어느 어른께서(선생님이셨는지 부모님이셨는지는 기억이 안 난다) 남이 말할 때는 고개를 끄덕이며 경청하는 태도를 보여야 한다고 하셨다.그 말이 나에게는 상당히 크게 와닿았고, 어릴 때부터 누군가와 대화를 할 때면 때로는 좀 과하게 고개를 끄덕이며 듣곤 했다.일종의 “나는 당신의 이야기를 경청하고 있어요.“라는 비언어적 표현인 셈이다.그러면서 동시에 더블링을 자주 섞는다.상대방이 말을 하면 “나는 당신의 말을 잘 듣고 있어요.“라는 것을 더욱 강조하면서 상대방이 말을 하는 것에 더 재미를 느끼도록 말이다.예를 들어 상대방이 “저는 어제 OO 영화를 보고 왔는데 재밌더라고요.“라고 하면 나지막이 “아 주인공이 OO인 영화요? 그거 재밌다고 하더라고요..

들어가며나에게 있어 '성능 개선' 은 고수들만 할 수 있는 어려운 작업이다.성능 개선에 관해서 1도 몰랐던 나의 입장에서 학습하며 적용한 내용들을 정리해보고자 한다. 본격적인 얘기를 하기 전에, 성능 지표에 관한 키워드 정리부터 해보자. LCP Largest Contentful Paint의 약자로, 화면 안에서 가장 큰 콘텐츠가 표시되기까지 걸린 시간을 말한다.CSR에서는 첫 html 파일이나 첫 이미지 파일 등이 해당 될 수 있겠다. Layout Shift페이지가 로딩되거나 동작하는 중에 텍스트, 이미지, 버튼 등의 위치가 예상치 못하게 움직이는 현상을 말한다.예를 들어 버튼을 누르려는 순간 위에 이미지가 나타나면서 버튼이 아래로 밀리는 현상이 바로 Layout Shift이다. CLSCumulative..

들어가며기술 요구사항 충족을 위해 API 응답 데이터 타입 가드를 진행했는데, 반영하자마자 타입 가드의 중요성을 바로 느끼는 경험을 하게 되었다.무슨 경험을 했는지는 글의 마지막에서 소개하겠다. API 응답데이터 타입 가드를 하려다가 이런 생각이 들었다.이미 서버 응답 타입을 interface로 전부 정의해두고 있는데, 이걸 그대로 이용해서 실제 응답도 검증할 수 있지 않을까?예를 들어 이런 타입이 있었다.export interface Destination { destinationId: string; name: string; address: string; roadAddress: string | null; latitude: number; longitude: number; provider: 'N..