SLASH 22 - Effective Component 지속 가능한 성장과 컴포넌트

'적당히'를 일반화할 수 없을까라는 물음에서, 제어할 수 있는 것 중 컴포넌트에 집중한다. 변경에 유연한 컴포넌트의 특징은 셋이다. 첫째 헤드리스 기반으로 추상화가 잘 이뤄져야 하고, 둘째 한 가지 역할만 하거나 그 조합으로 만들어져야 하며, 셋째 도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트를 분리해야 한다. 첫 번째 특징을 풀기 위해 컴포넌트의 세 역할을 짚는다. 컴포넌트는 외부에서 주입받은 데이터와 내부 데이터를 관리하고, 그 데이터가 어떻게 보일지(UI)를 정의하며, UI를 기반으로 사용자와 어떻게 상호작용할지를 정의한다. 버튼 예제에서 state는 데이터로 상태를 관리하고, on/off 텍스트로 노출하며, onClick으로 상호작용을 정의한다. 어떻게 보일지는 디자인에 의존하므로, 디자인에 의존하는 UI를 데이터와 분리하자는 방향을 제시한다.

데이터와 UI 분리를 달력 컴포넌트로 구체화한다. 달력 데이터 자체는 변하지 않지만 UI는 언제든 바뀌므로 둘을 분리하는데, 달력을 2×2 배열의 Date 객체로 추상화하고 현재 날짜 값을 함께 추상화한 뒤 이 계산 역할을 useCalendar 같은 훅에 위임한다. 그러면 디자인이 다른 달력을 만들 때도 같은 훅을 쓸 수 있다. 이렇게 UI 관심사를 제외하고 오직 데이터에만 집중해 모듈화하는 패턴을 헤드리스라 부르며, 한 문제에만 집중하기 때문에 더 많은 곳에서 쓰이고 다른 변경으로부터 격리된다. 상호작용도 같은 방식으로 분리한다. 버튼에 롱프레스 로직을 넣으면 내부가 복잡해지는데, useLongPress 훅으로 추출하면 버튼은 어떻게 보일지에만 집중하면 되고 다른 컴포넌트에서도 가져다 쓸 수 있다. 컴포넌트 대신 훅을 모듈화한 이유는, 변경이 유연해지려면 각 모듈이 한 가지 일만 하는 것이 중요하기 때문이다.

두 번째 특징 '한 가지 역할만 하는 컴포넌트들의 조합'을 셀렉트 UI로 설명한다. 흔한 셀렉트 UI를 만들다 보면 작은 컴포넌트들로 구성하게 되는데, 처음 보여준 구조는 라벨만 달라져도 옵스로 받도록 고쳐야 하고 내부 InputButton을 바꾸기도 어려워 변경에 제대로 대응하지 못한다. 이를 개선하려고 메뉴 노출 여부를 결정하는 내부 상태(isOpen)를 Dropdown으로 관리하고, 그 상태를 바꾸는 상호작용은 DropdownTrigger로, 옵션 영역은 DropdownMenu로, 각 항목은 별도 컴포넌트로 나눈다. 합성 가능하게 설계하면 Select와 트리거로 전달한 InputButton이 서로의 존재를 알지 못해 서로의 변경이 영향을 주지 않고, 트리거가 바뀌어도 Select 자체는 그대로여서 재사용과 확장에 유리하다. 더 복잡한 경우로 버튼을 누르면 모달이 열리고 체크박스로 여러 개를 선택한 뒤 적용하는 UI도, 데이터 중심으로 보면 '옵션을 제공하고 선택한 값을 보여주는' 컴포넌트로 셀렉트 UI와 본질이 같아 같은 Dropdown을 재사용한다. 트리거 아래가 아닌 곳에 뜨는 모달은 DropdownModal로 분리하고, 적용하기에서 onChange를 발생시키기 위해 모달을 하나의 폼으로 보고 submit 이벤트를 활용한다. 데이터 흐름이 비슷하면 인터페이스도 비슷해져, 트리거만 바꾸면 곧바로 대응된다.

세 번째 특징은 도메인 포함 여부에 따른 분리다. 모든 컴포넌트가 데이터에 접근할 수 있지만, 컴포넌트를 주입받듯 데이터도 주입받으면 어떨까라는 물음에서, 도메인이 섞인 셀렉트는 그대로 재사용하기 어렵다. 해법은 프롭스 네이밍에서 도메인 맥락을 제거하는 것이다. 도메인을 걷어내면 일반적인 이름이 되는데, 사람은 기존 배경 지식으로 해석하므로 이름과 프롭스를 표준에 가깝게 지을수록 더 많은 사람이 쉽게 이해한다. 실제로 도메인을 제거하니 표준 select 어트리뷰트와 네이밍이 같아져 프론트엔드 개발자라면 동작을 바로 예측할 수 있다. 이렇게 도메인을 모르는 컴포넌트와 포함하는 컴포넌트를 구분하고, 비즈니스 로직은 스스로 처리하되 UI 로직은 위임한다. 마지막으로 두 가지 액션 아이템을 제안한다. 구현할 기능이 이미 만들어져 있다고 가정하고 사용하듯 코드를 써 보는 '인터페이스 먼저 고민하기', 그리고 컴포넌트를 나누기 전에 그 이유가 복잡도를 낮추기 위함인지 재사용을 위함인지 다시 생각하는 습관이다. 변경에 유연한 코드는 안정적으로 비즈니스를 운영하며 빠른 속도를 유지하는 데 필수적이라며 마무리한다.