공통 컴포넌트를 건강하게 키우는 고민

공통 컴포넌트는 처음엔 재사용성을 높여 주지만, 시간이 지나면 책임 범위와 유지 비용이 함께 커진다. 이미 구현돼 있던 StaticLabelTextArea처럼 겉보기엔 공통화가 자연스러워 보여도, 실제로는 deprecated 예정 컴포넌트에 의존하고 사용처도 적어 공통화의 이점이 크지 않은 경우가 있었다.

오래된 공통 컴포넌트는 요구사항을 계속 흡수하며 점점 비대해진다. 예를 들어 CoverageSelectCard는 보험 상품 선택 UI에서 출발했지만, 바텀시트 열기·닫기, iOS body height 조작, 드래그 인터랙션, 애니메이션과 딜레이 제어까지 떠안으며 여러 역할을 동시에 수행하게 됐다. 결국 중요한 질문은 “공통으로 만들 수 있는가”가 아니라, “언제 어떤 기준으로 분리해야 유지보수가 쉬운가”로 바뀐다.

반대로 DelayRender처럼 작고 독립적인 컴포넌트는 공통으로 두는 것이 합리적일 수 있다. 다만 실제 사용처가 적고 앱 내부에서도 충분히 처리 가능한 규모라면, 공통 컴포넌트로 유지할 근거가 약해진다. 그래서 몇 번 반복돼야 공통으로 볼지, 실제 사용 빈도와 관리 비용을 어떻게 저울질할지 같은 기준을 팀 안에서 공유하는 일이 중요해진다.

템플릿은 여러 컴포넌트를 단순히 묶는 수준이 아니라, 특정 결정을 코드로 고정하는 구조로 봐야 한다. 같은 조합이 반복되고 조합의 주체가 명확할 때는 결합해도 되지만, 화면마다 예외가 계속 생기거나 아직 검증되지 않은 패턴이라면 템플릿으로 굳히기보다 분리된 상태로 두는 편이 낫다. 즉 템플릿은 재사용을 위한 도구라기보다, 변경하지 않기로 합의한 결정 집합에 가깝다.

시간이 지나면 일부 공통 컴포넌트는 더 이상 선택되지 않거나, 변경하면 영향 범위가 너무 커져 사실상 손대기 어려운 상태가 된다. 이때 deprecated는 실패 선언이 아니라 비용 절감을 위한 선택이 된다. 디자인 시스템 정비와 팀의 UI 기준 재정의 과정 속에서, 기존 공통 컴포넌트의 역할을 다시 정의하거나 대체 컴포넌트를 제시하는 흐름도 자연스럽게 필요해진다.

대안으로는 Headless 컴포넌트 접근이 제시된다. 상태 관리, 인터랙션 로직, 접근성 같은 핵심 동작만 공통으로 제공하고, 스타일과 시각적 표현은 사용처가 결정하는 방식이다. 안정성과 접근성은 공통으로 가져가되 디자인은 유연하게 허용하는 구조라면, 서비스 특성에 맞게 유지보수성과 확장성 사이의 균형을 더 잘 맞출 수 있다.

결국 공통 컴포넌트를 건강하게 키우는 방법은 더 많이 만들고 더 많이 합치는 데 있지 않다. 만들기 전에는 기존 조합으로 해결 가능한지, 지금은 공통이 아니라고 말할 수 있는지, 나중에 옮겨도 되는 구조인지 먼저 묻고, 사용할 때도 여전히 공통으로 유지하는 것이 맞는지 계속 질문하는 일에 가깝다.