GitHub UI 아키텍처 7년 반의 교훈: 네이티브 기준, 추상화의 역설, 그리고 프론트엔드 비용

GitHub의 UI 아키텍처 경험을 통해 도출된 세 가지 주요 교훈은 다음과 같습니다.

1. 네이티브가 새로운 기준입니다.GitHub는 지난 7년 반 동안 UI 구축 표준을 크게 높였습니다. 접근성 개선을 위한 광범위한 UI 변경과 가용성 향상 노력이 대표적입니다. 이제 UI 버그는 일반적인 버그와 동일하게 취급되며, 제품 사용을 방해할 경우 가용성 점수에 반영됩니다. 이는 3-Nines(연간 8.5시간 다운타임)라는 엄격한 가용성 표준을 충족하기 위함입니다. 또한, GitHub는 ‘앱과 같은’ 경험에 대한 사용자 및 경쟁사의 압력에 직면하여 React를 도입, 새로운 기능 개발에 활용하고 있습니다. 모바일 기기를 통한 인터넷 접속이 주를 이루고 앱 사용이 90%에 달하는 현실은, 문서 표시에 최적화된 웹 기술 스택이 아닌 네이티브 앱 경험이 새로운 사용자 기대치로 자리 잡았음을 시사합니다. 개발자는 자신의 인터넷 사용 모델이 현실을 반영하지 않을 수 있음을 인지하고, 업계의 네이티브 경험 기준을 파악해야 합니다.

2. UI 추상화는 역설입니다.Joel은 Vue 컴포넌트 및 Primer 디자인 시스템 구축 경험을 바탕으로 UI 추상화의 어려움을 설명합니다. 디자인 시스템은 표준 충족에 도움이 되지만, 소수의 팀에 과도한 부담을 지우며, 여러 구현체에서 표준을 유지하기 어렵습니다. 이는 Hyrum의 법칙(충분한 사용자 수가 있다면 시스템의 모든 관찰 가능한 동작에 의존하게 된다)의 완벽한 예시입니다. 특히 CSS의 전역적 특성은 작은 UI 변경조차도 확신을 가지고 배포하기 어렵게 만듭니다. Primer 업그레이드는 GitHub에서 가장 어려운 작업 중 하나로 꼽히며, 여전히 수동 테스트에 의존하는 경우가 많습니다.업계 전반에서 유사한 디자인 시스템을 재발명하는 것은 막대한 인적 자원의 낭비로 지적됩니다. Zendesk 디자인 시스템과의 유사성에서 알 수 있듯이, Brad Frost는 ‘글로벌 디자인 시스템’의 필요성을 역설합니다. Joel은 새로운 디자인 시스템을 처음부터 구축하지 말고, Highcharts, React Table, Radix, Shoelace와 같은 기존 컴포넌트 라이브러리나 디자인 시스템을 활용할 것을 강력히 권장합니다. 재발명 비용은 매우 크기 때문입니다.

3. 프론트엔드 작업 비용은 백엔드의 10배입니다.Dave Rupert의 ‘UI는 n제곱 상태의 함수(n=약 64)’라는 이론처럼, 브라우저 확장 프로그램, 다양한 브라우저/하드웨어/버전 등 프론트엔드 런타임은 백엔드에 비해 훨씬 복잡하고 예측 불가능합니다. 이러한 방대한 런타임 다양성에도 불구하고, 프론트엔드 테스트 커버리지는 백엔드보다 현저히 낮고, 브라우저 테스트는 느리고 불안정합니다. 컴포넌트 기반 UI는 테스트 용이성을 높이지만, 런타임의 복잡성을 완전히 해결하지 못합니다.디자인과 엔지니어링 사이의 변경 비용 불균형도 문제입니다. 디자이너는 엔지니어의 1년치 작업량을 단기간에 만들어낼 수 있으며, Figma와 같은 도구에서 디자인된 것이 실제 시스템에서 구현하기 어렵거나 불가능한 경우가 많습니다. Joel은 UI 복잡성을 예산으로 간주하고, GitHub의 diff나 merge box와 같이 정말 필요한 곳에만 복잡성을 할당해야 한다고 주장합니다. 대부분의 UI는 기존 패턴을 재활용해야 하며, 사용자들은 예측 가능한 경험을 선호합니다. Ruby/Rails 커뮤니티가 공유 도구를 개선하며 협력하는 것과 달리, 프론트엔드/디자인 영역에서는 재발명 경향이 강합니다. 그는 UI 프레임워크와 브라우저 자체에 기여하여 개선하는 노력을 강조하며, 동일한 코드 복잡성이 프론트엔드에서 백엔드보다 약 10배의 비용을 초래한다고 결론 내립니다.