Ramp는 디자인 변경이 새어 나가지 않도록 UI 컴포넌트 라이브러리를 자체 저장소로 분리했다

빠르게 반복 개발하는 스타트업에서는 컴포넌트 라이브러리를 만들 적절한 시점이 좀처럼 오지 않는다. 컴포넌트를 표준화하는 일은 제품-시장 적합성을 찾기 위해 필요한 빠르고 끊임없는 변화와 충돌하기 때문이다. Ramp의 엔지니어링 팀은 이 문제를 정면으로 마주했다. 라이브러리 구축을 시작할 무렵, Ramp는 이미 메인 코드베이스 안에서 수년간 반복 개선된 컴포넌트를 갖춘 제품을 보유하고 있었고, 이 컴포넌트들은 일상적인 기능 개발의 일환으로 그때그때 수정되었으며 비즈니스 로직과 디자인 결정 사이에 아무런 분리도 없었다.

Ramp의 팀은 컴포넌트를 메인 저장소에 그대로 두고 무심코 이루어지는 수정을 피하기 위해 규율에 의존하는 대신, 이른바 단단한 경계를 그었다. 즉 별도 저장소로 분리하고 자체 npm 패키지로 배포하며, 직접 작성한 체인지로그와 적절한 버전 관리를 갖추어 사용하는 팀들이 원하는 일정에 맞춰 변경 사항을 도입할 수 있게 했다. 또한 라이브러리 내부의 값에는 시맨틱 이름을 부여했다. 특정 빨간색 대신 'destructive' 색상처럼 이름을 붙여, 시각적 결정과 이를 사용하는 코드가 더 이상 같은 것이 아니게 만들었다.

도입을 이끌어내기 위해 팀은 내부 패키지를 오픈소스 프로젝트처럼 다루었고, 라이브러리 자체의 컴포넌트로 자체 문서 사이트를 구축했다. 이 과정에서 팀은 Ryu를 실제 두 번째 소비자로서 직접 사용(dogfooding)해야 했다. 또한 팀은 적용 범위의 넓이보다 적용의 깊이를 택했다. 아무도 쓰지 않는 25개의 컴포넌트보다 모든 곳에서 완전히 채택된 5개의 컴포넌트가 더 낫다고 보았기에, 새 코드는 새 라이브러리를 기본으로 사용하게 하고 기존 컴포넌트는 한꺼번에 다시 작성하는 대신 점진적으로 마이그레이션했다.

라이브러리를 자체 저장소와 패키지로 분리

별도 저장소는 모든 디자인 변경을 기능 개발의 부수 효과가 아니라 의도적이고 검토된 기여로 만든다.

시맨틱 네이밍은 시각적 결정을 구현으로부터 분리하여, 색상이나 간격을 사용하는 쪽을 깨뜨리지 않고 변경할 수 있게 한다.

라이브러리 자체로 문서 사이트를 구축하면 실제 두 번째 소비자가 생겨 통합 버그를 조기에 드러낼 수 있다.

내부 패키지를 체인지로그와 버전 관리를 갖춘 오픈소스처럼 다루면 팀이 강제적인 재작성 없이 변경 사항을 도입할 수 있다.

공유 시스템은 이를 편집하는 데 의도적인 단계가 필요할 때 일관성을 유지한다. 즉 자체 저장소로 분리하고, 소비자가 원시 값 대신 추상적인 속성을 요청하게 하라.

Ramp의 엔지니어링 팀은 2021년 11월 기준으로 라이브러리가 여전히 활발히 구축되고 있다고 설명하며, 이를 회사 생애의 "973일째"라고 불렀고, 단지 존재하기만 하는 컴포넌트보다 완전히 사용되는 컴포넌트를 우선시함으로써 도입을 점진적으로 이끌었다. 분리와 시맨틱 네이밍 접근 방식은 일회성 마이그레이션이 아니라, 팀이 회사의 핵심 앱, 블로그, 내부 도구 전반으로 계속 확장해 나간 패턴이 되었다.