새로운 프레임워크 선택의 기준

LLM이 코드를 생성하는 에이전틱 코딩 환경에서는 완전히 다른 질문을 던져야 한다. "이 라이브러리가 LLM의 학습 데이터에 얼마나 포함되어 있는가?"

Paul Kinlan이 제시한 Dead Framework Theory는 이 변화를 정확히 짚는다. React가 다른 프레임워크와 경쟁에서 이긴 것이 아니라, 웹 플랫폼 그 자체가 되어버렸다는 분석이다. LLM은 기존 웹 콘텐츠를 학습하고, 그 결과물로 React 코드를 출력하며, 이렇게 생성된 사이트가 다시 학습 데이터가 된다. 자기 강화 피드백 루프가 형성된 것이다.

이 논리는 프레임워크뿐 아니라 사내에서 독자적으로 구축한 모든 시스템에 적용된다. 사내 인증 모듈, 사내 API 클라이언트, 사내 유틸리티 라이브러리 모두 같은 문제를 안고 있다. 그중에서도 사내 디자인 시스템은 이 문제의 전형적인 사례다. UI 컴포넌트는 코드 생성 요청에서 가장 빈번하게 등장하고, LLM의 출력 품질 차이가 가장 극명하게 드러나는 영역이기 때문이다.

사내 디자인 시스템의 이중 부담

첫 번째 부담은 AI 생산성 저하다. "우리 디자인 시스템으로 버튼 만들어줘"라고 프롬프트를 입력하면 환각이나 거부가 돌아온다. "Shadcn으로 버튼 만들어줘"라고 하면 즉시 정확한 코드가 나온다. 사내 디자인 시스템은 LLM 학습 데이터에 단 하나의 예제도 없기 때문이다. Kinlan의 표현을 빌리면, "학습 데이터에 없으면 존재하지 않는 것이다. 최소 12-18개월 동안은."

두 번째 부담은 팀 협업 프로세스의 병목이다. 프로젝트에서 UI 수정이 필요한 상황을 생각해보자. 기존 디자인 시스템과 충돌이 발생하면 디자인 시스템 담당자가 전체 가이드를 검토하고, 디자인 시스템 개발자가 시스템을 수정하고, 기존 시스템을 사용하는 다른 프로젝트들과 호환성을 검토한 뒤에야 원래 프로젝트에 적용할 수 있다.

프로젝트 개발자가 직접 UI를 수정하고 싶어도 권한과 구조적으로 불가능하다. "디자인 시스템을 건드리면 안 돼요"라는 암묵적 금기가 있다. 단순한 UI 수정에도 외부 의존성이 발생한다. 디자인 시스템 담당자는 피처 개발 지원에 급하게 투입되는 패턴이 반복되고, 본연의 업무인 시스템 고도화와 긴급 지원 사이에서 충돌한다. 한 사람의 일정이 여러 프로젝트를 블로킹하는 병목 인력이 된다.

AI 생산성 저하와 팀 프로세스 병목이 결합하면 복합적 비효율이 발생한다. 사내 디자인 시스템 고집의 숨겨진 비용은 예상보다 훨씬 크다.

사내 디자인 시스템이 가졌던 가치

물론 사내 디자인 시스템을 구축한 데는 합리적인 이유가 있었다. 브랜드 일관성, 특수한 비즈니스 요구사항, 기존 레거시와의 호환성. LLM이 코드를 생성하기 전까지, 사내 디자인 시스템은 컴포넌트 개발에 분명한 이점을 제공했다. 개발자들이 매번 버튼이나 모달을 처음부터 구현할 필요 없이 검증된 컴포넌트를 재사용할 수 있었고, 디자이너와 개발자 간의 커뮤니케이션 비용도 줄었다. 신규 입사자도 디자인 시스템 문서만 숙지하면 일관된 UI를 빠르게 만들어낼 수 있었다.

문제는 이제 코드를 작성하는 주체가 바뀌고 있다는 점이다. LLM이 코드 생성의 상당 부분을 담당하는 환경에서, 사내 디자인 시스템의 장점은 퇴색하고 단점은 부각된다.

LLM이 UI 구성에서 겪는 어려움

LLM은 비즈니스 로직이나 알고리즘 작성에서는 인상적인 성능을 보여주지만, 정밀한 UI 구성에서는 여전히 한계가 뚜렷하다. 컴포넌트 간의 시각적 관계, 레이아웃의 미세한 조정, 디자인 토큰의 일관된 적용 같은 작업에서 오류가 빈번하다.

이 한계가 라이브러리 선택을 더욱 중요하게 만든다. LLM이 UI를 생성할 때 의존하는 것은 학습 데이터에서 본 패턴의 통계적 분포다. 특정 라이브러리의 사용 예제가 학습 데이터에 풍부할수록, LLM은 그 라이브러리를 더 정확하게 활용한다. 사내 전용 컴포넌트는 이 이점을 누릴 수 없다.

반면 Shadcn이나 Material UI 같은 공개 라이브러리는 수천 개의 GitHub 저장소, 블로그 포스트, 튜토리얼에 사용 예제가 노출되어 있다. LLM은 이 라이브러리들의 정확한 API와 관용적 사용법을 "알고 있다."

Shadcn이 에이전틱 코딩에 유리한 이유

Shadcn은 일반적인 컴포넌트 라이브러리와 다른 접근법을 취한다. npm 패키지로 설치하는 대신, 컴포넌트의 전체 소스 코드를 프로젝트에 직접 복사한다. 이 방식이 에이전틱 코딩 환경에서 결정적인 이점을 제공한다.

첫째, 컴포넌트의 구현 전체가 공개되어 있어 LLM의 학습 데이터에 포함될 가능성이 높다. 추상화된 API만 노출하는 라이브러리와 달리, Shadcn은 컴포넌트가 어떻게 구성되는지 전체 맥락을 제공한다.

둘째, 코드가 프로젝트 내부에 존재하므로 LLM이 해당 코드를 직접 참조하고 수정할 수 있다. 외부 패키지의 내부 구현을 변경하는 것은 불가능하지만, 로컬에 있는 Shadcn 컴포넌트는 자유롭게 확장하거나 커스터마이징할 수 있다. 대중적 라이브러리를 사용하면 프로젝트 개발자가 직접 Shadcn 컴포넌트를 수정하고 확장할 수 있다. 외부 의존성 없이 즉시 작업을 진행하고, LLM이 수정 방법까지 제안하니 자율적으로 문제를 해결한다. 앞서 언급한 팀 프로세스 병목이 사라지는 것이다.

Tailwind CSS의 명시성이 주는 이점

Tailwind CSS는 스타일을 별도 파일이 아닌 className으로 컴포넌트에 직접 명시한다. 이 특성이 LLM 기반 개발에서 상당한 이점으로 작용한다.

전통적인 CSS 접근법에서 LLM이 스타일을 수정하려면 HTML/JSX 파일과 CSS 파일을 동시에 이해하고 조작해야 한다. 클래스 이름의 의미를 추론하고, 해당 스타일 정의를 찾아 수정하는 과정에서 오류가 발생하기 쉽다. Tailwind는 이 문제를 제거한다. className="flex items-center gap-4 p-2"라는 선언은 해석의 여지 없이 명확하다.

또한 Tailwind의 유틸리티 클래스는 표준화되어 있다. LLM은 flex, grid, p-4, text-lg 같은 클래스의 의미를 정확히 알고 있으며, 이를 조합해 원하는 레이아웃을 생성할 수 있다. 커스텀 CSS 클래스 이름은 프로젝트마다 다르지만, Tailwind 클래스는 보편적이다.

기존 디자인 시스템을 유지해야 한다면

현실적으로 많은 조직이 기존 디자인 시스템을 완전히 버릴 수 없다. 레거시 호환성, 브랜드 요구사항, 마이그레이션 비용 등 여러 제약이 있다. 이 경우 몇 가지 대안을 고려할 수 있다.

컨텍스트 주입 (RAG)

LLM의 학습 데이터에 없더라도 추론 시점에 컨텍스트로 제공하면 정확도가 올라간다. Cursor의 경우 .cursor/rules 디렉토리에 .mdc 파일로 프로젝트 규칙을 정의할 수 있다. 디자인 시스템의 컴포넌트 API, 사용 예제, 금지 패턴을 규칙으로 명시하면 LLM이 참조한다.

llms.txt 표준도 대안이 될 수 있다. Chakra UI 같은 라이브러리는 이미 /llms.txt, /llms-full.txt 파일을 제공해 AI 도구가 문서를 효율적으로 소비할 수 있게 한다. 사내 디자인 시스템도 이 형식으로 문서화하면 Cursor의 @Docs 기능으로 바로 활용할 수 있다.

다만 한계가 있다. 컨텍스트 윈도우는 유한하고, 매번 주입해야 하는 오버헤드가 존재한다. 복잡한 디자인 시스템 전체를 컨텍스트에 담기는 어렵다.

파인튜닝

사내 코드베이스로 모델을 파인튜닝하면 디자인 시스템 패턴을 학습시킬 수 있다. 이론적으로는 가장 강력한 해결책이지만, 현실적인 장벽이 높다. 파인튜닝에 필요한 고품질 데이터셋 구축, 학습 인프라 비용, 모델 업데이트 시마다 재학습이 필요한 유지보수 부담이 있다. 대부분의 조직에서 ROI를 맞추기 어렵다.

Shadcn/Tailwind 기반 확장 + 설치형 배포

가장 실용적인 절충안이다. 디자인 시스템 자체를 Shadcn과 Tailwind 위에 구축하고, npm 패키지 대신 CLI로 소스 코드를 프로젝트에 직접 설치하는 방식이다.

이 접근법이 효과적인 이유는 LLM이 이미 아는 것과 새로 알려줘야 하는 것의 비율이 완전히 달라지기 때문이다. LLM은 Shadcn 컴포넌트의 기본 API, Radix UI 프리미티브의 동작 방식, Tailwind 유틸리티 클래스 전체, cn() 유틸리티로 클래스를 조합하는 패턴을 이미 알고 있다. 컨텍스트로 알려줘야 하는 것은 추가된 variant, 커스텀 색상 토큰, 사내 전용 컴포넌트 정도로 줄어든다.

.cursor/rules에 전체 문서를 넣을 필요 없이 Shadcn 기본과 다른 부분만 명시하면 된다. LLM은 Shadcn 지식을 기반으로 나머지를 정확하게 추론할 수 있고, 컨텍스트 윈도우 사용량도 최소화된다.

결론: 통계적 지배력을 선택의 기준으로

기술 선택의 기준이 바뀌고 있다. 과거에는 "어떤 도구가 기술적으로 우수한가"가 핵심 질문이었다면, 에이전틱 코딩 시대에는 "어떤 도구가 LLM 학습 데이터에서 통계적으로 지배적인가"를 함께 고려해야 한다.

사내 디자인 시스템은 조직의 특수성을 반영할 수 있지만, LLM의 지원을 받기 어렵다. 반면 Shadcn과 Tailwind CSS 같은 공개 라이브러리는 방대한 학습 데이터 덕분에 AI 어시스턴트가 정확하게 활용할 수 있다. 개발 생산성에서 이 차이는 점점 벌어질 것이다.

완전히 새로운 프로젝트라면 Shadcn과 Tailwind를 기반으로 시작하는 것이 최선이다. 기존 디자인 시스템을 유지해야 한다면 Shadcn/Tailwind 기반으로 재구축하고 설치형으로 배포하는 방식이 가장 현실적인 절충안이다. 컨텍스트 주입이나 파인튜닝은 보조적인 수단으로 활용할 수 있지만, 근본적인 해결책이 되기는 어렵다.

기술적 우수성과 별개로, 생태계의 통계적 현실이 실질적인 생산성을 결정하는 시대가 되었다.