#Frontend

공통 컴포넌트를 건강하게 기르기 위한 고민

Summary

"공통 컴포넌트는 자산이 아니라 부채일 수 있다?" 카카오페이손해보험의 컴포넌트 생존 전략

무분별한 재사용의 늪에서 벗어나 건강한 디자인 시스템을 구축하기 위한 FE 팀의 치열한 고민과 해법

이 아티클은 공통 컴포넌트가 팀의 생산성을 높이는 도구에서 관리의 짐으로 변하는 과정을 '생애주기'라는 독특한 관점으로 분석합니다. 무조건적인 공통화 대신 컴포넌트의 책임 범위를 고민하고, 때로는 과감한 폐기(Deprecated)를 통해 코드 건강성을 유지하는 실무적인 인사이트를 제공합니다. 단순한 기술 공유를 넘어 프론트엔드 개발자가 가져야 할 제품 설계 철학을 다룹니다.

01비대해진 컴포넌트의 징후인 '사춘기' 패턴 분석과 리팩토링 시점 제안
02섣부른 추상화(DelayRender 사례)를 경계하고 공통화 유지를 결정하는 기준 정립
03템플릿 결합을 결정하는 '그린 라이트'와 '레드 라이트' 체크리스트 제공
04스타일과 로직을 분리해 자유도를 높이는 헤드리스 컴포넌트 기반의 구조적 대안 제시
05공통 컴포넌트의 '죽음'을 실패가 아닌 유지보수 비용 절감을 위한 의도적 선택으로 정의

RECOMMENDATION

공통 컴포넌트 비대화로 고통받는 시니어 개발자와 디자인 시스템 도입을 고민 중인 팀에게 강력 추천합니다. 특히 '일단 공통으로 빼고 보자'는 관성에서 벗어나 유지보수 가능한 아키텍처를 설계하고 싶은 분들에게 실질적인 가이드가 될 것입니다.

The Problem

제품의 성장 과정에서 재사용을 목적으로 만들어진 공통 컴포넌트들이 시간이 흐름에 따라 과도한 책임을 떠안으며 비대해지거나, 충분한 검증 없이 성급하게 공통화되어 오히려 유지보수 비용을 증가시키는 문제가 발생했습니다. 특히 특정 도메인 로직이나 환경 대응 코드가 섞이면서 변경의 영향 범위를 예측하기 어려워지고 팀 생산성을 저하시키는 결과를 초래했습니다.

The Solution

컴포넌트의 생애주기(탄생, 사춘기, 결혼, 죽음)를 정의하여 각 단계에 맞는 관리 전략을 수립하고, 템플릿과 컴포넌트를 구분하는 명확한 기준(그린/레드 라이트)을 도입했습니다. 또한 UI 스타일과 비즈니스 로직을 분리하여 확장성을 높이는 헤드리스(Headless) 패턴 도입을 검토하고, 코드 리뷰 시 공통화의 적절성을 지속적으로 질문하는 문화를 정착시켰습니다.

The Result

본문에 구체적인 수치는 명시되지 않았으나, 무분별한 공통화를 경계하고 명확한 판단 기준에 따라 컴포넌트를 분리 또는 제거함으로써 기술 부채를 예방하는 효과를 얻었습니다. 결과적으로 팀 내에서 공통 컴포넌트를 영구 자산이 아닌 유연한 관리 대상으로 인식하게 되었으며, 유지보수 효율을 고려한 의사결정 체계가 마련되었습니다.

Trade-off

로직과 스타일을 분리하는 헤드리스 패턴이나 더 세밀한 컴포넌트 분리는 초기 설계와 구현 단계에서 더 많은 공수가 투입될 수 있습니다. 또한 공통 컴포넌트를 엄격하게 관리하는 과정에서 개별 화면 개발의 속도가 단기적으로는 둔화될 수 있으며, 팀원 간의 지속적인 커뮤니케이션 비용이 발생할 수 있습니다.