들어가며

최근 프로젝트를 진행하면서 문득 이런 생각이 들었습니다. "성능 최적화는 언제나 개발자 몫인가?" 라는 의문이었죠.

기획서에는 분 단위 데이터 갱신이라고 적혀있고, 디자인에는 화려한 애니메이션과 고해상도 이미지들이 가득한데, 정작 성능에 대한 고려는 개발 단계에서야 시작되는 경우가 대부분입니다.

물론 성능 최적화의 기술적 구현은 개발자의 역할이 맞습니다. 하지만 정말 좋은 성능은 기획과 디자인 단계부터 함께 고민할 때 나온다는 것을 여러 프로젝트를 통해 깨달았습니다.

이번 글에서는 실제 프로젝트에서 겪었던 사례들을 바탕으로, 각 단계에서 성능을 함께 고려했을 때 얼마나 더 나은 결과를 만들 수 있는지 공유해보고자 합니다.

 

현실: 성능 이슈가 시작되는 지점들

1. 기획 단계에서 놓치기 쉬운 성능 포인트

케이스 1: 무한스크롤 설계 시 고려사항

"사용자가 계속 스크롤하면서 콘텐츠를 볼 수 있게 무한스크롤로 해주세요. 데이터는 한 번에 100~500개씩 가져오면 될 것 같아요."

이런 요구사항에서 함께 고민해볼 점들:

• DOM 노드가 계속 쌓여서 메모리 사용량이 증가할 수 있어요
• 한 번에 가져올 데이터 개수에 따른 API 응답 시간 차이
• 가상 스크롤링 도입 시 더 나은 사용자 경험 제공 가능

케이스 2: 실시간 업데이트 주기 설정

"대시보드에서 모든 데이터가 실시간으로 업데이트되면 좋겠어요. 1분마다 새로고침해서 항상 최신 상태를 보여주세요."

이때 함께 검토하면 좋은 것들:

• 1분마다 여러 API 호출로 인한 서버 부하
• 불필요한 리렌더링으로 인한 성능 저하
• 사용자가 실제로 1분 단위 업데이트가 필요한지에 대한 검토

케이스 3: 차트 데이터에 대한 고려

기획자: "차트 데이터의 일 데이터는 분 단위로 그려졌으면 좋겠어요"

이런 상황에서 함께 고민해볼 점:

• 실제 차트 영역은 너비 50px로 분 단위로 그려질 필요가 없는 작은 영역
• 작은 영역에 분 단위 데이터 호출 및 그리기로 성능 저하
• 사용자가 실제로 필요로 하는 데이터의 세분화 수준

 

2. 디자인 단계에서 함께 고려하면 좋은 성능 요소

케이스 1: 시각적 임팩트와 로딩 속도의 균형

디자이너가 만들어주는 멋진 디자인들:

• 4K 해상도의 히어로 이미지 (5MB)
• 반응형에 따라 모두 다른 이미지 사용
• 페이지당 20개 이상의 고해상도 이미지
• 웹폰트 5-6개 사용
• 복잡한 그라데이션과 그림자 효과

결과적으로는: 페이지 로딩 시간 8초, Lighthouse 성능 점수 30점

이때 함께 논의하면 좋을 대안들:

• 디바이스별 적절한 이미지 해상도 설정
• 핵심 시각 요소와 부가적 요소의 로딩 우선순위
• 웹폰트 최적화 전략

케이스 2: 애니메이션 효과 최적화

css

/* 디자인에서 요구한 애니메이션들 */
.card {
  transition: all 0.3s ease;
  box-shadow: 0 4px 20px rgba(0,0,0,0.1);
  backdrop-filter: blur(10px);
  /* ... 복잡한 CSS 효과들 */
}

.card:hover {
  transform: translateY(-10px) scale(1.05) rotate(2deg);
  box-shadow: 0 20px 40px rgba(0,0,0,0.3);
  filter: brightness(1.1) contrast(1.2);
}

이런 경우 함께 검토해볼 점들:

• 60fps를 보장하기 어려운 복잡한 애니메이션
• GPU 가속을 고려한 transform 사용 방식
• 불필요한 리페인트/리플로우 최소화 방법

 

소통에서 시작되는 해결책

개발자 입장에서 느끼는 어려움

"이 디자인대로 구현하면 성능이 안 좋을 것 같은데요..."라고 말하면 돌아오는 대답들

"다른 사이트들도 다 이렇게 하는데 괜찮던데요?"
"이 정도는 괜찮을 것 같은데.. 이미 컨펌 다 되서 이렇게 되어야 해요"

이런 상황들이 반복되면서, 성능이 단순히 "개발 스킬"의 문제로만 인식되는 경우가 많습니다.

 

기획자와 디자이너가 가진 합리적인 이유들

물론 기획자와 디자이너도 나름의 합리적인 판단 기준이 있습니다.

• 사용자 경험을 위해 더 풍부한 인터랙션을 원함
• 경쟁사 대비 차별화된 시각적 임팩트 필요
• 성능 제약사항에 대한 구체적인 가이드라인 부족

다만 이런 요구사항들이 성능에 미치는 영향에 대한 정보 공유가 부족한 것이 핵심 문제인 것 같습니다.

 

해결방안: 함께 만드는 성능 최적화

1. 기획 단계에서 성능을 고려한 설계

데이터 설계 시 성능 고려사항

❌ 성능 고려가 부족한 기획
- 사용자 목록을 한 번에 1000개씩 로딩
- 실시간 업데이트를 위해 몇 초 간격으로 전체 데이터 갱신

✅ 성능을 고려한 기획
- 페이지네이션 또는 가상 스크롤링 도입
- 변경된 데이터만 부분 업데이트
- 사용자 행동 패턴 분석 후 적절한 업데이트 주기 설정

기능 복잡도와 성능의 균형점 찾기

• 모든 기능을 한 페이지에 넣지 않고 적절한 정보 계층화
• 초기 로딩 시 필수 기능만 노출, 추가 기능은 점진적 로딩
• 사용자 시나리오별 우선순위 설정

 

2. 디자인 단계에서 성능 친화적 접근

이미지 최적화를 고려한 디자인 가이드라인

✅ 성능 친화적 디자인 가이드라인

이미지:
- 히어로 이미지: 최대 1920px 너비, 100KB 이하
- 썸네일: 300px 너비, 20KB 이하
- WebP 포맷 고려한 대체 디자인 준비

폰트:
- 웹폰트 최대 2-3개 패밀리
- 필요한 웨이트만 선택적 로딩

애니메이션:
- transform과 opacity 위주의 애니메이션
- duration 0.3초 이하 권장
- 동시 애니메이션 요소 5개 이하

CSS 성능을 고려한 디자인 시스템

• 복잡한 그림자 대신 간단한 border 활용도 고려
• 그라데이션과 solid color의 적절한 조합
• backdrop-filter 사용 시 성능 영향 검토

 

3. 협업 프로세스 개선 방안

성능 체크리스트 도입

기획 단계:

- [ ]  API 호출 횟수와 빈도가 적절한가?
- [ ]  초기 로딩 시 필수 데이터만 포함되었는가?
- [ ]  사용자 플로우상 성능 병목 지점은 없는가?

디자인 단계:

- [ ]  이미지 총 용량이 페이지당 1MB 이하인가?
- [ ]  웹폰트 개수가 3개 이하인가?
- [ ]  애니메이션이 GPU 가속을 활용할 수 있는가?

정기적인 성능 리뷰 문화

• 스프린트 시작 전 성능 임팩트 검토
• 프로토타입 단계에서 성능 측정
• 배포 전 Core Web Vitals 체크

 

마치며

이런 경험들을 겪으면서 느낀 점은, 성능이라는게 결국 개발자 혼자 해결할 수 있는 영역이 아니라는 거였습니다.

물론 코드 레벨에서의 최적화는 개발자가 담당해야 하는 부분이 맞아요. 하지만 근본적인 성능 개선은 기획 단계에서 적절한 데이터 구조를 설계하고, 디자인 단계에서 성능을 고려한 UI를 만들 때 훨씬 효과적으로 달성할 수 있더라고요.

"나중에 개발자가 알아서 빠르게 만들겠지"라는 생각보다는, 처음부터 각자 단계에서 성능을 한 번씩 생각해보면 어떨까 싶어요. 그러면 개발자도 성능 최적화에만 매달리지 않고 더 의미 있는 기능 개발에 집중할 수 있을 거고, 결과적으로는 모든 팀원이 만족할 수 있는 결과물이 나올 것 같습니다.

 

참고 문헌

• Core Web Vitals 가이드
• 웹 성능 최적화 체크리스트
• 이미지 최적화 모범 사례
• CSS 애니메이션 성능 가이드