shadcn/ui가 2026년 3월 업데이트에서 공개한 shadcn/skills는 단순한 기능 추가가 아니다. Cursor, v0, Claude 같은 코딩 에이전트에게 프로젝트의 레지스트리 구조와 컴포넌트 패턴을 '맥락 레이어'로 주입함으로써, AI가 UI를 생성할 때 발생하는 환각과 오작동을 구조적으로 줄이겠다는 선언이다. 에이전트가 Radix와 Base UI 프리미티브의 차이를 이해하고, CLI 플래그를 정확히 사용하며, 레지스트리 워크플로우를 따르도록 만드는 것—이것이 'AI-ready 디자인 시스템'의 실체다.
그런데 여기서 잠깐 멈춰야 한다. 에이전트가 컨텍스트를 잘 이해할수록, 그 에이전트는 더 빠르고 더 자신 있게 행동한다. 그 자신감이 문제다. dev.to에 올라온 'I Called Them Suggestions'는 AI 개인 어시스턴트를 1년간 운영한 개발자의 회고인데, 핵심 메시지는 충격적일 만큼 단순하다. "AI는 '다음 토큰을 예측하는 확률 기계'다. 결과를 시뮬레이션하지 않는다." 임원에게 '확인 후 실행'이라고 지시받은 AI가 받은 편지함 전체를 삭제한 실제 사례를 언급하며, 저자는 자신의 시스템이 '제안'만 하도록 설계한 이유를 설명한다. 에이전트가 이메일 초안을 작성해도 발송은 사람이 승인해야 하고, 태스크를 분류해도 삭제는 사람이 결정한다. "그게 한계가 아니라, 그게 설계야."
이 두 흐름이 교차하는 지점이 흥미롭다. shadcn/ui는 에이전트에게 더 많은 프로젝트 지식을 주려 하고, 'I Called Them Suggestions'의 저자는 에이전트의 자율 행동 반경을 의도적으로 좁히려 한다. 방향이 반대처럼 보이지만, 실제로는 같은 문제를 다른 레이어에서 다루고 있다. 하나는 생성 품질의 문제고, 다른 하나는 실행 권한의 문제다. 컨텍스트를 잘 주입해도 에이전트가 어디까지 행동할 수 있는지를 정의하지 않으면, 품질 좋은 UI가 잘못된 위치에 잘못된 방식으로 배포될 수 있다.
이 공백을 메우는 아이디어가 BEAR(Block Enforceable Architectural Representation)다. dev.to에 공개된 이 실험적 프로젝트는 에이전트가 코드를 자유롭게 생성하되, 아키텍처 경계—어떤 블록이 무엇에 접근할 수 있고, 어떤 의존성을 가질 수 있는지—는 코드 위의 명시적인 레이어로 선언해 두는 방식을 탐구한다. 저자의 비유가 직관적이다. "케이지 안에서 곰은 원하는 대로 움직일 수 있다. 하지만 케이지가 한계를 정의한다." 에이전트가 PR에 구조적 변경을 몰래 끼워 넣어도, BEAR CLI가 CI 단계에서 경계 위반을 감지해 인간 리뷰를 트리거한다.
세 프로젝트를 나란히 놓으면, 에이전트 시대의 UI 개발에서 사람이 지켜야 할 세 개의 경계가 보인다. 첫째는 컨텍스트 경계—에이전트에게 무엇을 알려줄지 설계하는 것(shadcn/skills). 둘째는 실행 경계—에이전트가 무엇을 자율적으로 할 수 있고 무엇은 반드시 승인받아야 하는지(Suggestion 모델). 셋째는 아키텍처 경계—에이전트가 생성한 코드가 시스템 구조를 어디까지 바꿀 수 있는지(BEAR). 이 세 경계를 누가 설계하느냐가 에이전트 워크플로우의 품질을 결정한다.
프론트엔드 개발자 관점에서 이 변화는 역할 재정의를 요구한다. 컴포넌트를 직접 짜는 시간이 줄어드는 대신, 에이전트가 참조할 디자인 시스템의 규칙과 토큰을 얼마나 명확하게 정의하느냐가 결과물의 일관성을 좌우한다. shadcn/ui의 Design System Presets가 색상·타이포그래피·반경을 하나의 포터블 문자열로 패키징하는 것도 이 맥락에서 읽힌다. 에이전트가 소비할 수 있는 형태로 디자인 의도를 인코딩하는 일—이것이 다음 세대 디자인 시스템의 핵심 역량이 될 것이다.
'I Called Them Suggestions'의 저자는 Cummings의 자동화 레벨 연구를 인용하며 자율성은 이진 선택이 아니라 슬라이딩 스케일이라고 말한다. 이메일 분류는 에이전트에게, 발송은 사람에게. UI 컴포넌트 초안은 에이전트에게, 디자인 토큰 수정은 사람에게. 아키텍처 경계 안에서의 리팩토링은 에이전트에게, 블록 간 의존성 변경은 CI 리뷰에게. 어디에 선을 그을지 결정하는 것—그게 지금 프론트엔드 개발자에게 남겨진 가장 중요한 설계 문제다.
에이전트는 점점 더 빠르게, 더 그럴듯하게 UI를 만들어낼 것이다. shadcn/skills가 보여주듯 컨텍스트 품질은 계속 올라가고, 생성 속도는 더 빨라진다. 그럴수록 설계 경계를 어디에 긋느냐는 질문의 무게가 커진다. 에이전트가 케이지 안에서 자유롭게 움직이게 하려면, 케이지를 먼저 설계해야 한다. 그 케이지를 설계하는 권한—그것만큼은 여전히, 그리고 반드시 사람의 것이어야 한다.