성능 최적화의 함정 - Core Web Vitals 개선하다가 사용자 경험이 나빠진 케이스

Lighthouse 점수가 60점에서 95점으로 올라갔다. Core Web Vitals도 모두 “Good” 등급을 받았다. 하지만 사용자 불만은 오히려 증가했다. “앱이 이상해졌어요”, “기능이 작동하지 않아요”라는 피드백이 쏟아졌다. 이 글은 성능 점수에만 집중하다가 사용자 경험을 망친 실패의 기록이다.

시작: 성능 최적화 프로젝트

왜 성능 최적화를 시작했나

2025년 8월, 우리 웹사이트의 Lighthouse 점수가 60점이었다. 특히 성능 점수가 낮았다. “성능을 개선하면 사용자 경험이 좋아질 거야”라고 생각하며 성능 최적화 프로젝트를 시작했다.

목표는 명확했다:

• Lighthouse 성능 점수: 60 → 90 이상
• LCP: 4초 → 2.5초 이하
• FID: 300ms → 100ms 이하
• CLS: 0.25 → 0.1 이하

초기 성공

처음 한 달은 순조로웠다. 간단한 최적화만으로도 점수가 올라갔다.

1주차: 이미지 최적화

• WebP 포맷으로 변환
• 이미지 크기 최적화
• Lazy loading 적용
• 결과: Lighthouse 점수 60 → 75

2주차: 코드 스플리팅

• 동적 임포트 적용
• 라우트 기반 코드 스플리팅
• 결과: Lighthouse 점수 75 → 85

3주차: 번들 최적화

• Tree shaking 강화
• 불필요한 의존성 제거
• 결과: Lighthouse 점수 85 → 90

성공하는 것 같았다.

첫 번째 함정: 과도한 코드 스플리팅

모든 것을 스플리팅하다

점수가 올라가자 더 욕심이 생겼다. “모든 것을 스플리팅하면 더 빨라질 거야”라고 생각했다.

// 모든 컴포넌트를 동적 임포트
const Button = lazy(() => import('./Button'));
const Input = lazy(() => import('./Input'));
const Modal = lazy(() => import('./Modal'));
// ... 수십 개의 컴포넌트

작은 컴포넌트까지 모두 스플리팅했다. 번들 크기는 줄었지만, 문제가 생겼다.

사용자 경험 악화

문제 1: 깜빡임 현상

• 컴포넌트가 로드될 때마다 깜빡임 발생
• 사용자가 불편함을 느낌

문제 2: 로딩 상태의 부재

• 작은 컴포넌트도 로딩 시간이 필요
• 로딩 인디케이터가 없어서 사용자가 혼란스러움

문제 3: 네트워크 요청 증가

• 작은 컴포넌트마다 네트워크 요청 발생
• 느린 네트워크에서는 오히려 느려짐

사용자 피드백

“앱이 깜빡거려요.” “버튼을 눌렀는데 반응이 없어요.” “이전 버전이 더 나았어요.”

성능 점수는 올랐지만, 사용자 경험이 나빠졌다.

두 번째 함정: 과도한 이미지 최적화

모든 이미지를 WebP로

이미지 최적화도 과도하게 진행했다. 모든 이미지를 WebP로 변환하고, 품질을 최대한 낮췄다.

이전:

• JPEG 품질: 85
• 이미지 크기: 원본 유지

최적화 후:

• WebP 품질: 60
• 이미지 크기: 50% 축소

파일 크기는 줄었지만, 이미지 품질이 떨어졌다.

사용자 불만

“이미지가 흐릿해요.” “사진이 이상해 보여요.” “이전 버전이 더 선명했어요.”

성능 점수는 올랐지만, 시각적 품질이 떨어졌다.

세 번째 함정: 폰트 최적화의 부작용

폰트 로딩 최적화

FOIT (Flash of Invisible Text)를 방지하기 위해 font-display: swap을 적용했다. 하지만 예상치 못한 문제가 생겼다.

문제:

• 폰트가 로드되기 전에 시스템 폰트가 표시됨
• 폰트가 로드되면 레이아웃이 변경됨
• CLS 점수는 좋아졌지만, 사용자는 깜빡임을 느낌

사용자 경험 악화

“텍스트가 깜빡거려요.” “폰트가 바뀌는 게 거슬려요.”

네 번째 함정: 기능 제거

“불필요한” 기능 제거

성능을 위해 “불필요한” 기능들을 제거했다.

제거한 기능:

• 애니메이션 효과
• 호버 효과
• 트랜지션 효과
• 일부 시각적 피드백

“성능이 더 중요해”라고 생각했다.

사용자 불만

“앱이 밋밋해요.” “반응이 없어요.” “이전 버전이 더 살아있었어요.”

성능은 좋아졌지만, 사용자 경험이 나빠졌다.

다섯 번째 함정: 캐싱의 부작용

과도한 캐싱

성능을 위해 모든 것을 캐싱했다.

// 모든 API 응답 캐싱
const cache = new Map();
const CACHE_TIME = 24 * 60 * 60 * 1000; // 24시간

async function fetchData() {
  const cached = cache.get('data');
  if (cached && Date.now() - cached.timestamp < CACHE_TIME) {
    return cached.data;
  }
  // ...
}

사용자 불만

“데이터가 업데이트가 안 돼요.” “새로운 정보가 안 보여요.” “캐시를 지워야 하나요?”

성능은 좋아졌지만, 데이터의 신선도가 떨어졌다.

전환점: 사용자 피드백의 충격

사용자 불만 집계

3개월이 지나면서 사용자 불만이 집계되었다.

이전:

• 사용자 만족도: 4.2/5.0
• 이탈률: 15%
• 지원 티켓: 주당 10개

최적화 후:

• 사용자 만족도: 3.5/5.0
• 이탈률: 25%
• 지원 티켓: 주당 30개

성능 점수는 올랐지만, 사용자 만족도는 떨어졌다.

내 충격

“내가 뭘 잘못했을까?”라는 생각이 들었다. 성능을 개선했는데 왜 사용자들이 불만을 표시할까?

반성과 개선

문제의 원인

문제의 원인을 분석했다:

1. 점수에만 집중: Lighthouse 점수에만 집중하고 실제 사용자 경험을 간과
2. 과도한 최적화: 모든 것을 최적화하려다가 오히려 나빠짐
3. 사용자 테스트 부재: 실제 사용자에게 테스트하지 않고 점수만 확인
4. 균형 부재: 성능과 사용자 경험의 균형을 잃음

개선 방향

1. 사용자 중심 접근

• 점수보다 실제 사용자 경험에 집중
• 실제 사용자에게 테스트
• 피드백 수집 및 반영

2. 균형잡힌 최적화

• 모든 것을 최적화하지 않고 필요한 부분만
• 성능과 사용자 경험의 균형
• 점진적 개선

3. 측정 지표 다양화

• Lighthouse 점수뿐만 아니라 실제 사용자 메트릭
• 이탈률, 체류 시간, 전환율 등
• 정성적 피드백도 중요

개선된 버전

되돌린 것들

과도하게 최적화한 것들을 되돌렸다:

코드 스플리팅:

• 큰 컴포넌트만 스플리팅
• 작은 컴포넌트는 번들에 포함

이미지 최적화:

• WebP 사용하되 품질 유지
• 중요한 이미지는 고품질 유지

폰트 로딩:

• font-display: optional 사용
• 레이아웃 변경 최소화

기능 복원:

• 애니메이션 효과 복원
• 시각적 피드백 복원

결과

Lighthouse 점수:

• 이전: 60점
• 과도한 최적화: 95점
• 균형잡힌 최적화: 85점

사용자 만족도:

• 이전: 4.2/5.0
• 과도한 최적화: 3.5/5.0
• 균형잡힌 최적화: 4.5/5.0

점수는 약간 낮아졌지만, 사용자 만족도는 오히려 올라갔다.

배운 점들

1. 점수보다 사용자 경험이 중요하다

Lighthouse 점수는 참고용일 뿐이다. 실제 사용자 경험이 더 중요하다. 점수가 높아도 사용자가 불만을 느끼면 의미가 없다.

2. 과도한 최적화는 독이 된다

모든 것을 최적화하려고 하지 말라. 필요한 부분만 최적화하고, 사용자 경험을 해치지 않는 선에서 진행하라.

3. 균형이 중요하다

성능과 사용자 경험의 균형이 중요하다. 성능만 추구하면 사용자 경험이 나빠질 수 있다.

4. 실제 사용자에게 테스트하라

개발자 환경에서만 테스트하지 말고, 실제 사용자에게 테스트하라. 실제 사용자의 피드백이 가장 중요하다.

5. 점진적 개선이 중요하다

한 번에 모든 것을 최적화하지 말고, 점진적으로 개선하라. 각 변경사항의 영향을 측정하고, 사용자 피드백을 수집하라.

다른 개발자들에게

성능 최적화를 진행한다면

성능 최적화를 진행하는 개발자들에게 조언한다:

1. 사용자 중심 접근: 점수보다 실제 사용자 경험에 집중
2. 균형잡힌 최적화: 모든 것을 최적화하지 말고 필요한 부분만
3. 실제 사용자 테스트: 개발자 환경뿐만 아니라 실제 사용자에게 테스트
4. 점진적 개선: 한 번에 모든 것을 바꾸지 말고 점진적으로
5. 다양한 지표: 점수뿐만 아니라 다양한 지표 확인

실패를 두려워하지 말라

과도한 최적화로 실패할 수 있다. 하지만 그 실패를 통해 균형을 배울 수 있다. 실패를 두려워하지 말고, 사용자 피드백을 받아들이라.

결론: 균형의 중요성

성능 최적화는 중요하다. 하지만 그것이 전부는 아니다. 사용자 경험, 기능성, 시각적 품질 등 모든 것을 고려해야 한다.

Lighthouse 점수가 95점이어도 사용자가 불만을 느끼면 실패다. 점수가 85점이어도 사용자가 만족하면 성공이다.

균형이 중요하다. 성능과 사용자 경험의 균형, 최적화와 기능의 균형, 점수와 실제 경험의 균형.

이 경험이 다른 개발자들에게 도움이 되기를 바란다. 점수에만 집중하지 말고, 실제 사용자 경험에 집중하라.