사용자가 결제 버튼 앞에서 이탈한다. 장바구니를 채운 사람이, 카드를 꺼내려던 사람이, 그냥 떠난다. 이건 의지의 문제가 아니다. 경로의 문제다. 동시에, 배포할 때마다 수백 KB를 다시 내려받아야 하는 번들이 있다. 코드의 85%는 지난 버전과 같은데도. 이 두 문제는 표면적으로 달라 보이지만, 본질은 하나다. 사용자가 원하는 것에 도달하는 경로에서 불필요한 마찰을 제거하는 것. 비즈니스 레이어에서든, 네트워크 레이어에서든.
결제 흐름에서 22%를 찾아낸 방법
dev.to에 공개된 사례에서 한 팀은 체크아웃 전환율을 22% 끌어올렸다. 가격을 내리거나 프로모션을 건 게 아니었다. 제품도 그대로였다. 바뀐 건 오직 흐름이었다.
문제의 구조는 단순했다. 체크아웃 화면에 필드가 너무 많았고, 텍스트가 흩어져 있었고, 버튼의 의미가 불분명했다. 사용자는 결제하러 온 게 아니라 '결제 흐름을 이해'하는 데 인지 에너지를 쓰고 있었다. 이미 구매 결정을 내린 사람에게 불필요한 사고를 강요하는 구조였다.
팀이 시작한 질문은 명쾌했다. "결제 화면에서 사용자가 해야 할 일이 뭔가?" 답은 하나였다. 결제. 그 하나의 행동을 방해하는 모든 요소를 제거하는 것이 리디자인의 기준이 됐다. Nielsen 휴리스틱과 Apple·Airbnb의 미니멀리즘을 시각적 영감이 아닌 검증된 근거로 삼았고, Figma에서 흐름 단위로 프레임을 분해했다. 모든 요소에 단 하나의 질문을 던졌다. "이게 결제를 돕는가, 아니면 그냥 원래 있던 거라 남아 있는가?"
기술적으로 흥미로운 지점은 따로 있었다. 체크아웃이 서드파티 결제 서비스에 의존하고 있었고, 서버 측 웹훅 처리 지연이 체감 속도를 끌어내리고 있었다. 팀은 백엔드를 건드리지 않았다. 대신 로딩 상태와 JavaScript 타이밍을 정교하게 설계해서 '느린 시스템'을 '빠르게 느껴지는 경험'으로 바꿨다. 실제 응답 속도가 아닌 지각된 속도를 최적화한 것이다. 기다리는 사람이 기다린다는 사실을 잊게 만드는 것, 그게 UX 레이어에서 할 수 있는 성능 최적화다.
실제로 덜 보내는 기술: Compression Dictionary Transport
UX 레이어의 지각 최적화가 한 축이라면, 다른 축은 네트워크 레이어의 실질 최적화다. Chrome 130부터 정식 릴리스된 Compression Dictionary Transport(CDT)는 브라우저가 이미 받은 리소스를 다음 응답의 압축 사전으로 활용하게 한다.
개념은 직관적이다. 교재를 매번 통째로 보내는 대신, 이전 판을 옆에 펴두고 달라진 부분만 훨씬 작게 보내는 방식이다. app.v1.js와 app.v2.js가 80% 이상 겹친다면, v2를 보낼 때 v1을 압축 참조점으로 삼아 전송량을 대폭 줄일 수 있다.
동작 방식은 HTTP 헤더 협상으로 이뤄진다. 서버가 Use-As-Dictionary 응답 헤더로 "이 리소스를 다음 요청의 사전으로 써도 된다"고 알리면, 브라우저는 캐시에 사전을 보관한다. 이후 새 버전을 요청할 때 Available-Dictionary 헤더로 보유한 사전의 SHA-256 해시를 함께 보내고, 서버가 이를 인식하면 dcb(dictionary-compressed Brotli) 또는 dcz(dictionary-compressed Zstandard) 인코딩으로 응답한다. 사전이 없는 브라우저는 기존 Brotli나 Zstandard 경로를 그대로 타므로, 점진적 향상(Progressive Enhancement) 구조를 자연스럽게 만족한다.
velog에 정리된 분석에 따르면, 900KB → Brotli 후 240KB로 줄어든 관리자 번들이 CDT 적용 후 p75 기준 78KB까지 낮아지는 실험 수치도 제시됐다. 같은 파일이지만 이전 버전 대비 달라진 부분만 전송하는 구조가 만들어내는 차이다.
두 최적화가 공유하는 설계 원칙
두 사례를 나란히 놓으면 공통된 설계 철학이 보인다.
첫째, 불필요한 것을 제거하는 것이 가장 강력한 최적화다. 체크아웃에서는 사용자의 주의를 분산시키는 요소를, CDT에서는 이미 전송한 바이트를 다시 보내는 낭비를 제거했다. 기능을 추가한 게 아니라 뺐을 때 수치가 올랐다.
둘째, 지각 최적화와 실질 최적화는 함께 설계해야 한다. 백엔드 지연을 숨기는 로딩 UX가 체감 속도를 바꾸고, CDT가 실제 전송량을 줄인다. 둘 중 하나만으로는 Core Web Vitals의 LCP와 INP를 동시에 잡기 어렵다.
셋째, 변경 가능한 레이어에서 먼저 검증한다. 체크아웃 팀은 백엔드를 건드리지 않았고, CDT도 정적 자산처럼 위험이 낮은 영역에서 작게 시작해 CDN 캐시 키와 fallback을 검증한 뒤 확대하는 순서를 권장한다.
프론트엔드가 놓치기 쉬운 맹점들
CDT를 실무에 적용할 때 주의할 세 가지 함정이 있다. 하나는 CDN이 새 Content-Encoding을 모르는 경우다. 원본 서버가 dcb로 응답해도 CDN이 이를 잘못 캐시하면 사전이 없는 사용자에게 깨진 응답이 전달된다. 캐시 키에 Available-Dictionary와 Accept-Encoding이 충분히 반영됐는지 반드시 확인해야 한다.
또 하나는 측정 착시다. CDT의 이득은 재방문자, 혹은 다음 배포 이후 방문자에게 발생한다. 첫 방문자는 사전이 없으므로 이득이 없다. 전체 전송량 평균으로만 보면 효과가 희석돼 보일 수 있다. 재방문 코호트를 따로 떼어 측정하는 게 핵심이다.
세 번째는 사전 매칭 범위다. match="/*"처럼 넓게 설정하면 의도하지 않은 리소스에 사전이 매칭될 수 있다. 공개되어도 되는 반복 패턴, 즉 공통 템플릿이나 UI 문자열 중심으로 범위를 좁히는 게 안전하다.
전망: 최적화의 무게중심이 이동하고 있다
체크아웃 UX 사례가 말해주는 건 프론트엔드 개발자가 단순히 "기능을 구현하는 사람"에서 "전환율을 설계하는 사람"으로 역할이 확장됐다는 사실이다. 같은 제품, 같은 가격, 같은 마케팅 예산으로 22%를 더 팔 수 있다면, 그 레버는 코드 품질이나 아키텍처가 아니라 사용자 여정의 마찰을 얼마나 정확하게 읽어내느냐에 있다.
CDT는 아직 실험적이고 브라우저 호환성도 제한적이지만, Google Search가 이미 실전에서 전송량 개선을 확인했고 Chrome 130부터 정식 릴리스됐다는 건 의미 있는 신호다. React·Next.js 앱은 번들이 자주 바뀌지만 대부분의 코드는 버전 간에 유지된다. CDT가 Baseline에 오르는 시점이 오면, 이 구조를 미리 이해하고 CDN 설정과 측정 체계를 갖춰둔 팀이 먼저 실질적인 성능 이득을 가져간다.
프론트엔드 최적화의 무게중심은 "무엇을 더할 것인가"에서 "무엇을 줄일 것인가"로 이동하고 있다. 불필요한 필드를 없애고, 중복 바이트를 줄이고, 기다리는 시간을 느끼지 못하게 설계하는 것. 그 세 방향이 지금 전환율과 성능 지표를 동시에 움직이는 실질적인 레버다.