사용자는 기능보다 속도를 기억한다

예전에는 새로운 기능을 만드는 것이 가장 중요한 일이라고 생각했다.

사용자가 원하는 기능을 빠르게 구현하고 배포하는 것이 개발자의 역할이라고 믿었다.

실제로 많은 프로젝트가 기능 중심으로 움직인다.

무엇을 만들 것인가.

어떤 기능을 추가할 것인가.

어떤 화면을 더 제공할 것인가.

그런데 서비스를 운영하면서 의외의 사실을 자주 발견하게 됐다.

사용자들은 생각보다 기능을 자세히 기억하지 않았다.

대신 경험을 기억했다.

같은 기능인데 평가가 달랐다

예전에 같은 기능을 제공하는 페이지가 두 개 있었다.

하나는 데이터를 모두 불러온 뒤 화면을 보여줬고,

다른 하나는 Skeleton UI를 적용하고 필요한 데이터부터 먼저 렌더링했다.

기능은 완전히 같았다.

API도 같았다.

결과도 같았다.

하지만 사용자 반응은 달랐다.

후자의 페이지가 훨씬 빠르다고 느껴졌다.

실제로 측정해보면 차이는 크지 않았다.

하지만 사용자는 기다리는 경험보다 먼저 보여주는 경험에 더 긍정적으로 반응했다.

그때 처음으로 체감 성능이라는 개념을 이해하게 됐다.

성능은 숫자만의 문제가 아니다

Lighthouse 점수나 Core Web Vitals는 중요하다.

LCP, INP, CLS

모두 실제 사용자 경험과 연결되는 지표들이다.

하지만 성능 최적화를 하면서 느낀 것은 숫자가 전부는 아니라는 점이었다.

예를 들어 아래 두 화면이 있다고 생각해보자.

3초 동안 아무것도 안 보임
→ 화면 표시

0.5초 안에 Skeleton 표시
→ 2.5초 후 데이터 표시

실제 로딩 시간은 비슷할 수 있다.

하지만 사용자는 두 번째 화면을 훨씬 빠르다고 느낀다.

왜냐하면 시스템이 응답하고 있다고 느끼기 때문이다.

프론트엔드는 기능보다 경험을 만든다

프론트엔드 개발자로 일하면서 점점 느끼는 것은

우리가 만드는 것은 기능이 아니라 경험이라는 점이다.

버튼을 만드는 것이 아니라 클릭감을 만들고,

목록을 만드는 것이 아니라 탐색 경험을 만들고,

페이지를 만드는 것이 아니라 기다림의 시간을 설계한다.

사용자는 API 응답 시간이 몇 ms인지 모른다.

대신

빠르다 or 답답하다

는 기억한다.

내가 가장 많이 신경 쓰게 된 것들

요즘은 기능 구현이 끝나면 아래 질문을 먼저 하게 된다.

• 첫 화면은 얼마나 빨리 보이는가?
• 로딩 중이라는 사실을 알 수 있는가?
• 클릭 후 반응은 즉시 오는가?
• 사용자가 기다리는 순간이 있는가?

생각보다 작은 차이가 경험을 크게 바꾼다.

<Skeleton />

<Button disabled={isLoading}>
  저장 중...
</Button>

<Image priority />

복잡한 기술은 아니지만 사용자가 느끼는 속도에는 큰 영향을 준다.

마무리

새로운 기능은 언젠가 익숙해진다.

하지만 느린 경험은 오래 기억된다.

돌아보면 사용자들은 우리가 얼마나 어려운 코드를 작성했는지 알지 못한다.

대신 서비스가 빠르고 편했는지는 기억한다.

그래서 요즘은 기능을 구현하는 것만큼

사용자가 어떻게 느낄지 고민하려고 한다.

좋은 프론트엔드는 많은 기능을 가진 서비스가 아니라

기다리지 않게 만드는 서비스에 더 가깝다고 생각한다.