AI 이후, UI 라이브러리를 걷어낸 이유

사진: Balázs Kétyi, Unsplash

AI 이전에는 남이 만든 컴포넌트를 쓰는 편이 더 저렴했습니다

LLM 이 나오기 전, 웹 팀에게 UI 컴포넌트 라이브러리는 합리적인 선택이었습니다. 컴포넌트 코드는 사람이 직접 쓰고 읽고 고쳐야 했습니다. 그러니 직접 만들어 유지하는 쪽이 남의 것을 가져다 쓰는 쪽보다 훨씬 비쌌습니다.

일관성 문제의 해법으로 출발했습니다.

Bootstrap 은 2010년 Twitter 사내에서 만들어졌습니다. 2011년 공개 글에 따르면 당시 엔지니어들은 익숙한 라이브러리를 제각각 가져다 썼고, 앱마다 생긴 불일치가 확장과 유지보수를 어렵게 했습니다(Bootstrap from Twitter, 2011–08–19). Bootstrap 은 공개 전 1년 넘게 사내 도구 개발의 스타일 가이드 역할을 했습니다(Bootstrap 공식 문서). 공통 패턴을 한 곳에 모아 공유하는 것이 출발점이었습니다.

직접 만드는 쪽은 사람과 시간이 많이 듭니다.

zeroheight 의 2025년 리포트에서 직원 500명 이상 기업의 디자인 시스템 팀은 평균 9명이었고, 가장 큰 어려움으로 인력과 리소스 부족(63%)이 꼽혔습니다(zeroheight Design Systems Report 2025). Sparkbox 2021년 조사에서는 사내 디자인 시스템을 둔 응답자 중 전담 팀이 있는 곳이 46%였고, 스스로 성공적이라고 평가한 시스템은 40% 정도였습니다(Sparkbox Design Systems Survey 2021). EightShapes 의 Nathan Curtis 는 소수가 혼자 끌고 가는 모델은 확장되지 않는다고 짚었습니다(“Overlords don’t scale”, Team Models for Scaling a Design System, 2015).

보이지 않는 복잡도가 높았습니다.

Adobe 의 Devon Govett 는 버튼 하나도 지원해야 할 상호작용을 따지면 “보기보다 복잡하다”고 썼고, 접근성과 국제화를 제대로 지원하는 일은 여전히 “극도로 어렵다”고 했습니다(Building a Button Part 1, 2020–08–12). W3C 의 ARIA 작성 가이드는 아예 “잘못된 ARIA 보다 ARIA 가 없는 편이 낫다”는 경고로 시작합니다(WAI-ARIA APG). 키보드 동작, 포커스 관리, 스크린리더 대응을 팀마다 새로 구현하는 것은 낭비였습니다.

라이브러리는 바로 그 비용을 덜어주겠다고 약속했습니다.

MUI 는 “바퀴를 다시 발명하지 말고 핵심 비즈니스 로직에 집중하라”고 말합니다(MUI). Ant Design 은 UI 규격을 통일해 중복과 과도한 제작 비용을 줄이는 것을 목표로 내겁니다(Ant Design). 프루퍼가 쓰던 Mantine 은 120개 넘는 컴포넌트와 70개 넘는 훅을 제공합니다(Mantine). 시장의 답도 분명했습니다. State of React 2023 에서 MUI 사용 경험 비율은 57.5%로 1위였습니다(State of React 2023).

대가는 있었지만 감당할 만했습니다.

라이브러리에 기대면 그 라이브러리의 설계 결정도 함께 떠안습니다. MUI 는 v5 에서 스타일 엔진을 JSS 에서 Emotion 으로 바꿨고, 마이그레이션 가이드는 여러 편으로 나뉘어 있습니다(MUI v4 to v5). Mantine 은 7.0 에서 Emotion 의존을 끊으면서 createStyles 와 sx prop 을 없애고 CSS Modules 로 옮기라고 안내했습니다(Mantine 7.0.0, 2023-09-18). 그래도 이런 메이저 업그레이드 몇 번의 비용은 컴포넌트를 처음부터 만들고 지키는 비용보다 작았습니다. 이 계산에는 전제가 하나 깔려 있었습니다. 코드를 쓰는 것도 읽는 것도 사람이라는 전제입니다.

LLM 이 코드를 쓰면서 계산이 뒤집혔습니다

그 전제가 무너졌습니다. 지금은 LLM 이 UI 코드를 생성하고, 개발자는 그 코드를 일일이 읽지 않고 화면과 동작을 확인합니다. 컴포넌트를 처음부터 만드는 비용이 거의 사라지면서, 라이브러리가 덜어주던 비용도 함께 사라졌습니다.

라이브러리의 장점은 사람을 위한 것이었습니다.

잘 정리된 API, 외우기 쉬운 prop 이름, 버전별 문서는 사람이 코드를 읽고 쓸 때 효용이 있습니다. LLM 에게는 오히려 부담이 될 수 있습니다. Mantine 6 의 createStyles 와 7 의 CSS Modules 처럼 한 라이브러리 안에서도 시대별 문법이 갈리고, 모델은 두 시대의 코드를 섞어 내놓을 여지가 있습니다. 반면 저장소 안에 있는 컴포넌트 코드는 모델이 직접 읽고 그 문법을 따릅니다.

그래서 코드를 소유하는 방식이 떠올랐습니다.

shadcn/ui 는 스스로를 이렇게 소개합니다. “이것은 컴포넌트 라이브러리가 아닙니다. 당신의 컴포넌트 라이브러리를 만드는 방법입니다.” 문서는 원칙 중 하나로 AI-Ready 를 꼽고, LLM 이 읽고 이해하고 개선할 수 있도록 코드를 열어 둔다고 적고 있습니다(shadcn/ui 문서). 패키지를 설치하는 대신 컴포넌트 소스를 프로젝트에 복사해 넣고, 그 다음부터는 내 코드로 다룹니다.

이 흐름은 눈으로도 볼 수 있었습니다.

State of React 에서 shadcn/ui 사용 비율은 2023년 20.8%에서 2024년 42%로 두 배가 됐고, 만족도 1위(80%)에 올랐습니다(State of React 2024). 2025년 조사는 MUI 가 여전히 사용량 1위지만 shadcn/ui 가 그 자리를 넘보고 있다고 정리했습니다(State of React 2025). GitHub 별은 12만 5천 개를 넘었습니다(shadcn-ui/ui, 2026–10–11 기준).

그래서 AI 도구가 기본값으로 고른 것도 이쪽입니다.

Vercel 의 v0 는 Next.js, Tailwind CSS 와 함께 shadcn/ui 로 코드를 만듭니다(v0 FAQ). RedMonk 는 Bolt, Lovable, v0 가 모두 shadcn 위에 있다고 짚으며 shadcn 을 “LLM 의 기본 UI 라이브러리”라고 부른 개발자의 말을 인용했습니다(RedMonk, 2025–04–22). Vercel 은 2026년 글에서 코딩 에이전트를 쓰는 팀은 컴포넌트 소스가 저장소에 있을 때 이득을 본다고 썼습니다(Shadcn/ui vs. Radix UI, 2026–06–25).

물론 이에 대한 대가도 있습니다. 복사한 파일은 원본의 수정 사항을 자동으로 받지 못합니다. 예전에는 이 단점이 치명적이었습니다. 버그 수정과 개선을 사람이 직접 옮겨야 했기 때문입니다. 이제 그 일을 LLM 이 맡을 수 있으니, 소유의 비용이 감당할 만한 수준으로 내려왔습니다. AI 이전에 라이브러리를 택하게 만든 계산이 AI 이후에는 반대 방향을 가리킵니다.

프루퍼가 홈페이지에서 Mantine 을 걷어낸 생각

프루퍼는 최근 proofer.tech 홈페이지에서 Mantine 을 걷어냈습니다. 그리고 그 자리에 다른 컴포넌트 라이브러리를 넣지 않았습니다.

리뉴얼 전 메인 페이지를 진단하며 적은 문장이 있습니다. Mantine 기본 컴포넌트, 가운데 정렬 텍스트, Divider 반복이라 차별화가 약하다는 것이었습니다. 제품 화면에서는 익숙한 기본값이 장점입니다. 회사를 소개하는 홈페이지에서는 그 익숙함이 곧 누구의 홈페이지와도 닮아 보이게 만듭니다.

라이브러리를 쓰면 브랜드 색, 타입, 간격을 그 라이브러리의 테마 체계에 맞춰 번역해야 합니다. 프루퍼 레포에는 그 번역의 흔적이 남아 있었습니다. Mantine 테마, 전역 스타일, 홈 전용 스타일에 토큰이 각각 따로 있었고, 값이 서로 일치하는 것은 브랜드 블루와 그린 정도였습니다. 라이브러리는 일관성을 약속했지만, 실제로는 일관성의 정본이 여러 곳으로 갈리는 원인이 됐습니다.

홈페이지를 이루는 것은 섹션, 버튼, 카드, 내비게이션, 문의 폼 정도입니다. 복잡한 데이터 테이블도, 중첩된 다이얼로그도 거의 없습니다. 이 정도 컴포넌트는 LLM 이 브랜드 규칙에 맞춰 바로 만듭니다. 남은 것은 라이브러리 테마를 경유하는 간접비와 메이저 업그레이드 때마다 치르는 비용뿐이었습니다.

디자인 시스템은 Claude Design 에, 구현은 LLM 에게

앞으로 프루퍼 홈페이지는 컴포넌트 라이브러리 없이 갑니다. 디자인 시스템은 Claude Design 에서 관리하고, 코드는 LLM 이 그 시스템을 읽어 구현합니다.

라이브러리를 쓸 때 디자인의 정본은 사실상 npm 패키지와 그 테마 파일이었습니다. 디자인 파일은 그 코드를 뒤따라가는 그림에 가까웠습니다. 이제는 순서가 반대입니다. 색, 타입, 간격, 컴포넌트 규칙을 담은 디자인 시스템이 정본이고, 코드는 그것을 매번 다시 펼친 결과물입니다.

Claude Design 은 그 정본을 두기에 맞는 자리입니다. Anthropic 은 2026년 4월 Claude Design 을 공개하며, 온보딩 때 Claude 가 코드베이스와 디자인 파일을 읽고 팀의 디자인 시스템을 만든다고 설명했습니다. 그 뒤 모든 프로젝트가 그 색, 타이포그래피, 컴포넌트를 자동으로 쓰고, 결과는 핸드오프 번들로 Claude Code 에 넘길 수 있습니다(Introducing Claude Design, 2026–04–17). 디자인 시스템을 만드는 곳과 그것을 코드로 옮기는 곳이 하나의 흐름으로 이어집니다.

개발자가 컴포넌트 코드를 직접 검토하던 자리에는 두 가지 일이 남습니다. 디자인 시스템의 규칙을 정확하게 쓰는 일, 그리고 나온 화면이 그 규칙을 지켰는지 확인하는 일입니다. 라이브러리를 고르던 판단은 규칙을 설계하는 판단으로 바뀝니다.

라이브러리가 대신 챙겨주던 접근성과 브라우저 호환성을 이제 우리가 검증해야 합니다. 생성된 코드가 디자인 시스템에서 조금씩 어긋나는 것을 어떻게 잡을지도 정해야 합니다. 이 방식을 홈페이지 밖의 제품 화면까지 넓힐지는 홈페이지에서 먼저 검증한 뒤에 판단해보겠습니다.

저희도 아직 해 보면서 배우는 중입니다. 비슷한 고민을 하고 계신다면 어떻게 풀고 계신지 편하게 들려주세요. 홈페이지에서 직접 부딪히며 알게 된 것들도 기회가 닿는 대로 또 나누겠습니다.