공통 컴포넌트, 어떻게 하면 건강하게 관리할 수 있을까?

공통 컴포넌트(Common Component)의 과도한 증가로 인한 유지보수 어려움과 문서화 부재 문제를 제기하며, 팀 생산성 저하(Team Productivity Decline)의 원인을 분석

컴포넌트의 역할 확장에 따른 CoverageSelectCard 사례를 통해, 책임 범위 모호성과 유지보수 비용 증가(Maintenance Cost Increase)의 상관관계를 설명

DelayRender 컴포넌트 사례를 통해, 공통 컴포넌트의 적절한 사용 기준과 팀 내 합의(Team Agreement)의 중요성을 강조

템플릿(Template)의 정의를 재사용성 도구가 아닌, 변경 불가 결정 집합(Immutable Decision Set)으로 정의하며, 템플릿 사용 기준 제시

헤드리스 컴포넌트(Headless Component)를 대안으로 제시하며, UI 커스터마이징(UI Customization)과 접근성(Accessibility)을 동시에 확보하는 방안 제시

공통 컴포넌트, 왜 사춘기를 겪는가?

본문에서는 공통 컴포넌트가 시간이 지남에 따라 과도한 역할(Excessive Responsibility)을 부여받아 비대해지는 현상을 '사춘기'에 비유한다. CoverageSelectCard 사례를 통해, 초기 단순한 UI 목적에서 시작했으나, 바텀시트 관련 로직 추가로 인해 책임 범위(Responsibility Scope)가 모호해지는 과정을 설명한다.

문제점: 기능 추가에 따른 코드 복잡도 증가, 수정 및 테스트(Testing) 어려움 발생

해결책: 컴포넌트 분리, 단일 책임 원칙(Single Responsibility Principle) 준수, 코드 리뷰(Code Review) 강화

결과적으로, 컴포넌트의 역할 분담과 책임 소재를 명확히 하는 것이 유지보수성을 향상시키는 핵심 전략임을 강조한다.

공통 컴포넌트, 언제 독립해야 하는가?

글에서는 모든 컴포넌트가 과도하게 비대해지는 것은 아니라고 말하며, 충분히 사용되지 않음에도 공통 컴포넌트로 분리되는 경우를 지적한다. DelayRender 컴포넌트 사례를 통해, 공통 컴포넌트의 적절한 사용 기준(Usage Criteria)에 대한 질문을 던진다.

핵심 질문: 실제 사용 빈도(Frequency of Use)와 관리 비용(Management Cost) 간의 균형은 어떻게 맞출 것인가?

고려 사항: 컴포넌트의 독립성, 팀 내 합의(Team Agreement), 향후 확장 가능성

결론적으로, 공통 컴포넌트의 생성 여부보다, 유지 여부(Maintenance)에 대한 지속적인 고민과 팀 내 합의가 중요함을 강조한다.

템플릿, 재사용을 위한 도구인가, 결정의 집합인가?

본문에서는 템플릿(Template)을 단순히 컴포넌트의 조합이 아닌, 변경하지 않기로 합의된 결정의 집합(Decision Set)으로 정의한다. 보험 도메인(Insurance Domain)의 청약 씬(Application Scene)을 예시로, 템플릿의 필요성을 설명한다.

템플릿 사용 기준: 반복적인 UI 조합(Repeated UI Combination), 조합의 주체 명확성, 예외 발생 최소화

템플릿 미사용 기준: 화면별 예외 발생, 불확실한 미래를 고려한 템플릿 사용, 충분한 검증(Validation) 부재

결과적으로, 템플릿은 재사용성을 위한 도구인 동시에, 일관성(Consistency)을 유지하기 위한 전략적 선택임을 강조한다.

공통 컴포넌트, 어떻게 추모할 것인가?

글에서는 공통 컴포넌트의 '죽음'을, 더 이상 사용되지 않거나, 팀의 기본 선택지에서 제외되는 것으로 정의한다. 디자인 시스템(Design System)의 진화, 조직 구조 변화, 유지 비용 증가 등을 이유로 의도적인 Deprecated(Deprecated)를 선택하는 사례를 제시한다.

Deprecated의 시작: 새로운 요구사항 미충족, 팀 내 합의(Team Agreement) 부재

Deprecated의 의미: 실패가 아닌, 비용 절감(Cost Reduction)을 위한 선택

대안 제시: 대체 컴포넌트(Replacement Component) 제시, 디자인 시스템(Design System) 업데이트

결론적으로, 공통 컴포넌트의 생애주기(Lifecycle)를 이해하고, 적절한 시점에 Deprecated를 결정하는 것이 중요함을 강조한다.

헤드리스 컴포넌트, 가이드와 자유를 모두 잡는 방법

본문에서는 헤드리스 컴포넌트(Headless Component)를 대안으로 제시하며, UI 커스터마이징(UI Customization)과 접근성(Accessibility)을 동시에 확보하는 방안을 제시한다. Headless 컴포넌트는 로직과 접근성만을 제공하고, 시각적인 표현은 사용처에서 결정하도록 위임한다.

장점: UI 유연성(UI Flexibility) 확보, 접근성(Accessibility) 문제 해결, 코드 재사용성(Code Reusability) 향상

구현 방식: Headless 컴포넌트 + 기본 UI 버전 + 커스텀 UI 버전

고려 사항: 디자인 시스템(Design System)과의 연동, 팀 내 가이드라인(Guideline) 설정

결과적으로, 헤드리스 컴포넌트는 디자인 시스템의 일관성과 UI 커스터마이징의 유연성을 동시에 만족시키는 효과적인 해결책(Effective Solution)이 될 수 있음을 시사한다.