에이전트를 감시하는 린터가 나왔다 — shadcn/lint, 문제를 푸는가 증상을 관리하는가

shadcn이 shadcn/lint를 내놨어요.

Tailwind 디자인 시스템 규칙을 정해두면, AI 에이전트가 그 규칙을 어겼을 때 무엇을 어겼는지 짚고 고칠 방법까지 제시하는 린터예요.

소개를 처음 봤을 때 든 생각은 두 겹이었어요 — “잘 만들었다”, 그리고 “그런데 왜 이게 필요해졌지?”

먼저, 공정하게 — 잘 만든 도구다

깎아내리기 전에 인정할 건 인정할게요.

개발자가 “강조색은 이 변형만, 원색 하드코딩 금지” 같은 정책을 정하면, 에이전트가 버튼을 엉뚱하게 칠했을 때 린터가 “이건 규칙 위반이고, 네 프로젝트의 이 컴포넌트/변형/테마를 쓰면 된다”고 되돌려줘요.

그냥 “틀렸다”가 아니라 고칠 방향까지 주는 게 핵심이에요.

팀은 150번 넘는 에이전트 작업으로 시험했고, 거의 모든 작업이 한 번의 교정으로 위반 0에 도달했대요.

Claude로 돌린 대조군에선 규칙만 줄 때보다 위반을 고치는 비용이 10~48% 낮았고요.

Tailwind v4 + ESLint·Oxlint에 붙고, 테마를 자동으로 찾고, shadcn/ui를 안 써도 돌아가요.

에이전트가 코드를 점점 더 많이 짜는 시대에, “사람이 읽는 지침” 말고 “기계가 검증하는 규칙”이 필요하다는 방향 자체는 옳아요.

이건 진심이에요.

그런데 — 이건 해결인가, 증상 관리인가

여기서부터가 제가 걸리는 지점이에요.

에이전트가 디자인 시스템을 어기는 건 왜일까요.

규칙이 코드에 강제돼 있지 않고, 관습으로 떠 있기 때문이에요.

Tailwind는 마크업에 유틸리티 클래스를 흩뿌리고, shadcn/ui는 컴포넌트를 내 저장소로 복사해 넣어요.

그러면 “우리의 파랑은 이거야”라는 약속이 토큰 하나로 못 박혀 있는 게 아니라, 수십 개 파일에 복사된 클래스 문자열로 흩어져 있어요.

지킬 것이 흩어져 있으니, 어기기가 쉬워요.

어기기 쉬우니, 감시자가 필요해져요.

shadcn/lint는 그 감시자예요.

그래서 저는 이걸 “문제의 해결”이라기보다 “구조가 만든 증상의 관리” 로 읽어요.

훌륭한 감시자를 붙이는 것과, 애초에 어길 표면을 줄이는 것은 다른 이야기거든요.

레이어 위에 레이어

또 하나 걸리는 건 층이에요.

Tailwind(유틸리티) 위에 shadcn/ui(복사된 컴포넌트)를 얹고, 그 위에 shadcn/lint(에이전트 감시)를 다시 얹어요.

문제가 생길 때마다 도구를 하나씩 더 쌓는 방향이에요.

Tailwind v4가 오히려 층을 걷어내는 쪽으로 갔다고 반겼던 저로선, 이 흐름은 반대로 보여요.

“복사해서 네가 소유하라(you own the code)“는 shadcn의 철학도 양날이에요.

자유롭게 고칠 수 있다는 뜻이지만, 동시에 업데이트와 드리프트를 통째로 네가 떠안는다는 뜻이기도 해요.

복사본이 프로젝트마다, 파일마다 조금씩 어긋나기 시작하면, 린터는 그 어긋남을 늦춰줄 뿐 없애주진 못해요.

나는 반대 방향을 택했다

이 블로그의 디자인은 정반대 선택이에요.

nacre 디자인 시스템은 빌드 도구도, 컴포넌트 복사도 없이 플레인 CSS로 짰어요.

색·간격·강조는 :root의 토큰 몇 개로 못 박아 두고, 나머지는 거기서 파생돼요.

그래서 “우리의 파랑”을 바꾸려면 한 곳만 고치면 되고, 어기려면 오히려 일부러 토큰을 벗어나야 해요.

어길 수 있는 표면이 작으면, 어기는 걸 감시할 도구도 덜 필요해요.

에이전트에게 일을 맡길 때도 마찬가지예요 — 제약이 바닥에 박혀 있으면, 에이전트가 헤맬 여지 자체가 줄거든요.

물론 이건 개인 블로그라 가능한 사치일 수 있어요.

수백 명이 만지는 대형 코드베이스, 이미 Tailwind로 굳은 제품이라면, 바닥을 다시 까는 것보다 좋은 감시자를 붙이는 게 훨씬 현실적이에요.

그 맥락에선 shadcn/lint가 정답에 가깝고, 저도 그걸 부정하진 않아요.

도구보다, 도구가 필요해진 이유를

정리하면, 제 불편함은 shadcn/lint 자체를 향한 게 아니에요.

그건 주어진 조건 안에서 잘 만든, 심지어 영리한 도구예요.

제가 묻고 싶은 건 그 앞이에요 — 왜 우리는 디자인 시스템을 감시할 도구가 필요한 지경까지 왔나.

규칙을 관습으로 흩뿌려 두고, 그걸 지키는지 기계로 감시하는 것.

아니면 규칙을 처음부터 코드 바닥에 심어, 감시할 일을 줄이는 것.

퍼블리셔로 10년 CSS를 만지던 눈엔, 후자가 여전히 더 ‘덜어낸’ 쪽으로 보여요.

새 도구가 나오면 “이걸 써야 하나”를 묻기 쉬운데, 저는 한 번 더 물어요.

”이 도구가 메우려는 구멍을, 나는 애초에 안 낼 수 있나?”