Ø NEWS

지난 10년 동안 성장하는 조직에 주어지는 조언은 거의 하나로 수렴했다. 버튼과 모달, 데이터 그리드와 폼 컨트롤을 하나의 버전 관리 패키지에 모아두면 모든 팀이 일관성과 접근성, 속도를 물려받는다는 식이었다. 컨설팅사 그리피스 웨이트에서 10년 가까이 기업 고객들의 공유 UI와 디자인 시스템을 맡아온 저자는 이 조언을 2026년 기준으로 다시 따져본다. 모델이 탄탄한 디자인 시스템 하나만 참고해도 표준적인 UI 대부분을 그 자리에서 찍어낼 수 있게 되면서, 회사 전체가 쓰는 컴포넌트 패키지를 계속 떠받칠 이유는 예전만큼 분명하지 않아졌다.

라이브러리가 한 묶음으로 팔던 네 가지

공유 라이브러리 하나는 실은 네 가지 약속을 한 패키지에 묶어 팔았다. 데이트피커를 다섯 번째로 또 만들지 않아도 되는 재사용, 한 팀의 버튼이 다른 팀의 버튼과 똑같이 움직이는 일관성, 접근성이나 키보드 처리 같은 까다로운 예외를 한 번만 풀어두는 축적된 전문성, 브랜드가 바뀌면 한 곳만 고치면 되는 단일 소스가 그것이다. 이 중 일관성과 단일 소스는 디자인 시스템과 토큰 — 컴포넌트가 참조하는 색상·타이포·간격 값 — 만 있으면 충분하다. 패키지 자체를 정당화했던 건 나머지 둘, 재사용과 축적된 전문성 쪽이었는데, 공교롭게도 지금 AI가 가장 잘 거들 수 있는 부분이 바로 거기다.

다만 이 치환에는 조건이 붙는다. 재생성된 코드는 그대로 믿을 게 아니라 비주얼 회귀 테스트와 접근성 검사, 토큰 준수 검사를 통과해야 신뢰할 수 있다. 기준 없이 두면 모델은 특색 없는 평균값으로 수렴하는 경향이 있어서, 오히려 뚜렷한 관점을 가진 디자인 시스템이 차별점으로 남는다. 접근성이 유난히 까다로운 위젯이나 여러 팀에 걸쳐 기능이 똑같이 맞아야 하는 부분은 여전히 큐레이션된 공유 코드를 남겨둘 이유로 꼽힌다.

유지보수라는 진짜 청구서

라이브러리를 처음 만드는 데도 시간이 들지만, 진짜 비용은 그 다음 10년에 있다. 한 해커뉴스 스레드에는 사내 컴포넌트 라이브러리를 두 번째로 다시 시도 중이라는 회사의 댓글이 달렸다. 내부 UI 라이브러리는 만들고 유지하는 비용이 크고, 몇 년 앞을 내다보면서 인력 이탈이 적은 숙련된 팀이 있어야 굴러간다는 내용이었다. 도입 범위가 다른 팀으로 번지면 소유권이 애매해지고, 관리자는 다른 업무에 끌려가고, 팀마다 우선순위가 부딪히면서 두세 개면 충분한 컴포넌트를 팀마다 변형해 쓰게 된다. 결국 라이브러리는 백로그와 조율 회의, 계획 수립까지 갖춘 하나의 프로젝트로 굴러가야 하고, 그 운영 부담은 첫 릴리스 이후로도 몇 년씩 이어진다. 그리피스 웨이트도 같은 문제를 직접 겪었다. 라이브러리가 널리 쓰이기 시작하면 여러 버전의 컴포넌트를 맞춰 두는 일이 균형 잡기처럼 되고, 특정 서드파티 라이브러리를 감싼 공유 컴포넌트는 그 의존성을 올리거나 바꿀 때마다 얽힌 실타래를 풀어야 했다.