Joel은 UI 아키텍처에 대한 세 가지 주요 교훈을 제시합니다.
1. 네이티브 경험이 새로운 기준선
- UI 표준의 변화: GitHub는 접근성과 가용성 측면에서 UI 구축 표준을 크게 높였습니다. UI 버그는 이제 제품 사용을 방해하는 다른 버그와 동일하게 가용성 점수에 반영됩니다. (예: 99.9% 가용성은 연간 8.5시간의 다운타임을 의미하며, 코드 변경 배포에 1시간이 소요된다면 연간 8번의 수정 기회만 주어짐).
- ‘앱 같은’ 경험 요구: GitHub 프로젝트와 같은 사례에서 고객들은 더 ‘앱 같은’ 기능을 요구하며, 경쟁사들도 이러한 경험을 제공하고 있습니다.
- React 도입: 이러한 요구에 따라 GitHub는 새로운 기능을 React로 구축하고 있으며, 현재 GitHub 페이지의 절반가량이 React로 제공됩니다.
- 모바일 중심의 인터넷 사용: Pew Research에 따르면 미국 성인의 15%는 모바일 기기로만 인터넷에 접속하며, 모바일 인터넷 사용의 90%는 앱에서 이루어집니다. 이는 모바일이 사용자 경험의 새로운 기준선이 되었음을 의미하며, 웹은 문서 표시에 적합하게 만들어진 기술 스택으로 앱과 같은 풍부한 경험을 제공하는 데 한계가 있습니다.
2. UI 추상화는 역설
- 디자인 시스템의 도전: 디자인 시스템은 팀이 접근성 및 가용성 표준을 충족하도록 돕지만, 소수의 팀에 과도한 부담을 줍니다. GitHub의 Primer는 CSS 클래스 라이브러리에서 컴포넌트 기반 추상화(React 및 Vue 컴포넌트)로 발전했지만, 여러 구현에서 표준을 충족하는 디자인 시스템을 구축하고 유지하는 데 어려움을 겪고 있습니다.
- 하이럼의 법칙: ‘충분한 수의 API 사용자가 있다면, 계약이나 문서에서 무엇을 약속하든 시스템의 모든 관찰 가능한 동작은 누군가에게 의존될 것이다.’ 이는 CSS의 전역적 특성과 결합하여 작은 UI 변경도 예측하기 어렵게 만듭니다.
- 비효율적인 중복: 여러 회사에서 유사한 디자인 시스템(예: GitHub와 Zendesk의 버튼 컴포넌트)을 재창조하는 것은 막대한 인적 자원의 낭비입니다.
- 재사용의 중요성: Joel은 디자인 시스템을 처음부터 구축하지 말 것을 강력히 권고합니다. GitHub조차도 모든 컴포넌트를 자체적으로 구축하지 않고 Highcharts나 React Table과 같은 외부 라이브러리를 사용하며, 기존 디자인 시스템을 테마화하는 방안(Radix, Shoelace)을 고려합니다.
3. 프론트엔드 작업 비용은 백엔드의 10배
- 프론트엔드의 복잡성: UI는 ‘f(states)^n’ (n=64)으로 표현될 만큼 수많은 런타임 입력에 의해 영향을 받으며, 브라우저 확장 프로그램과 같이 통제 불가능한 요소가 많습니다. 백엔드는 단일 Ruby 버전으로 운영되지만, 프론트엔드는 다양한 브라우저, 하드웨어 스택, 버전에 걸쳐 실행됩니다.
- 테스트의 어려움: 이러한 복잡성에도 불구하고 프론트엔드 코드의 테스트 커버리지는 백엔드보다 낮은 경우가 많습니다. 브라우저 테스트는 느리고 불안정합니다. 컴포넌트 기반 UI는 테스트 커버리지를 높이는 데 도움이 되지만, 런타임 다양성 때문에 여전히 충분하지 않습니다.
- 디자인과 엔지니어링 간의 불균형: 디자이너는 엔지니어가 1년 걸릴 작업을 일주일 만에 만들 수 있으며, Figma와 같은 도구는 완벽해 보이지만 실제로는 구현하기 어려운 디자인을 쉽게 만듭니다.
- 복잡성 예산: Joel은 UI 복잡성을 예산처럼 관리하고, 꼭 필요한 경우에만 혁신을 시도해야 한다고 주장합니다. GitHub는 diffs나 4차원 드래그 앤 드롭과 같은 고유한 UI에만 복잡성을 할당합니다.
- 재사용과 사용자 경험: 고객은 다른 앱에서 학습한 UI 패턴을 재학습하는 것을 원치 않으므로, 기존 패턴을 따르는 것이 좋습니다(예: Shopify의 예측 가능한 결제 양식).
- 오픈 소스 기여: Ruby 개발자들이 Rails와 같은 공유 도구를 개선하는 데 협력하듯이, UI 프레임워크와 브라우저 자체에도 기여하여 불필요한 워크어라운드를 제거해야 합니다.