Files
2nd/00_Raw/00_Processed/kiwi.com 마이그레이션 프로젝트.md
T

4.2 KiB

kiwi.com 마이그레이션 프로젝트

📌 Brief Summary

kiwi.com 마이그레이션 프로젝트는 프론트엔드 개발 속도와 성능을 최적화하기 위해 기존의 CSS-in-JS 도구인 styled-components에서 유틸리티 퍼스트(Utility-first) 프레임워크인 Tailwind CSS로 전환한 작업입니다 [1, 2]. 이 프로젝트를 통해 모바일 및 데스크톱 환경 모두에서 Core Web Vitals(FID, INP) 지표가 대폭 개선되었으며 서버 CPU 지연 시간도 크게 단축되었습니다 [3-5]. 그러나 두 라이브러리가 공존하는 과도기 동안의 번들 크기 증가와 유틸리티 클래스의 특이성(specificity) 문제 등 일부 디버깅의 복잡성이 증가하는 단점도 확인되었습니다 [6, 7].

📖 Core Content

  • 마이그레이션의 배경 및 목적: kiwi.com 팀은 긴 작업(long tasks)을 최적화하기 위한 조사 과정에서 styled-components가 프로젝트의 주요 성능 병목 현상을 일으킨다는 사실을 발견했습니다 [1]. 이에 따라 훨씬 뛰어난 성능과 유틸리티 퍼스트 접근 방식을 제공하는 Tailwind CSS로의 전환을 결정했습니다 [1].
  • 단계별 마이그레이션 과정:
    • 1단계 - 계획 수립: React 기반 SPA(Single Page Application) 환경에서 컴포넌트들을 작게 나누고 JIRA 태스크를 통해 독립적으로 정제 및 마이그레이션을 진행했습니다 [8].
    • 2단계 - 초기 설정: 단일 레포지토리(monorepo) 내에서 작업하는 두 팀의 요구를 충족하기 위해 PostCSS를 사용해 두 개의 개별 Tailwind 환경 및 빌드 출력을 구성했습니다 [9]. 이 과정에서 VS Code 플러그인(IntelliSense, Prettier)이 여러 구성 파일을 인식하도록 세부 설정을 조정해야 했습니다 [10].
    • 3단계 - 실행 및 문제 해결: 성능 향상과 캐싱 이점을 얻기 위해 내부 CSS 대신 외부 CSS 방식을 선택했습니다 [11]. 구형 브라우저(Safari iOS 14.5 미만)에서 gap이나 inset 같은 속성을 지원하지 않는 문제를 해결하기 위해 Tailwind의 matchUtilities()를 활용하여 safe-inset, safe-start, safe-space-x와 같은 커스텀 동적 유틸리티 플러그인을 개발해 적용했습니다 [12, 13].
    • 4단계 - 성능 데이터 분석: Tailwind CSS로 전환한 이후 모바일 환경의 홈페이지 기준으로 FID(First Input Delay)는 75.9%, INP(Interaction to Next Paint)는 58.4% 감소하여 웹 성능이 비약적으로 향상되었습니다 [3, 4]. 또한 JavaScript를 통한 스타일 연산이 제거되면서 서버 CPU Wall Time(지연 시간)이 52.91% 줄어들었습니다 [5].
  • 직면한 한계 및 단점 (Trade-offs):
    • 마이그레이션 초기에는 두 라이브러리가 함께 사용됨에 따라 생성되는 CSS 코드의 중복으로 인해 번들 크기가 눈에 띄게 증가했습니다 [6].
    • 여러 요소에 분산된 유틸리티 클래스는 컴포넌트에 직접 스타일이 묶여 있던 styled-components에 비해 스타일 문제의 출처를 역추적하기 어렵게 만들어 디버깅을 복잡하게 만들었습니다 [6].
    • Tailwind의 선언 순서에 의존하는 특이성(specificity) 문제 때문에, 클래스를 동적으로 구성하기 위해 clsx와 같은 JavaScript 라이브러리에 의존해야 하는 등 워크플로우에 추가적인 복잡성이 발생했습니다 [7].

🔗 Knowledge Connections


Last updated: 2026-04-26