Impeccable, 모델 없이 62개 규칙으로 AI 티를 잡아낸다

모델이 만든 페이지에는 특유의 생김새가 있다. 다들 봤을 것이다. 모든 곳에 Inter, 히어로에는 보라에서 파랑으로 가는 그라디언트, 카드 안에 또 카드, 색이 깔린 배경 위의 회색 글씨, 그리고 제목마다 위에 떠 있는 둥근 사각형 아이콘 타일. Paul Bakaus는 그 생김새에 이름을 붙였고, 이어서 그걸 위한 linter를 썼다.

Impeccable은 코딩 에이전트를 위한 디자인 스킬이다. 이번 주에 약 6,700개의 스타를 받아 누적 약 91,500개가 됐다. "당신의 코딩 에이전트를 위한 디자인 어휘"라는 소개 문구는 정작 진짜로 특이한 부분을 축소해서 말한다. 62개 검사가 모델을 전혀 거치지 않는 결정론적 규칙으로 돌아간다는 점이다.

구체적으로 무엇인가

스킬 하나, 명령 24개, 그리고 검출기 하나. Anthropic의 frontend-design 스킬을 확장하는 데서 시작해, 자기 주관을 갖춘 물건으로 자랐다.

설치는 프로젝트 루트에서 명령 한 줄이면 된다:

npx impeccable install
/impeccable init

사람들이 건너뛰는 쪽이 두 번째 단계다. init은 제품에 대해 사용자층, 목적, 제약, 톤을 인터뷰하고 그 답을 PRODUCT.md에 적는다. 별도의 document 명령은 기존 코드에서 DESIGN.md를 생성한다. 이 분리가 중요하다. 제품의 사실과 시각 시스템은 서로 다른 산출물이고 갱신 주기도 다르다. 둘을 한 파일에 밀어 넣는 것이야말로 디자인 문서가 낡는 지름길이다.

그다음이 24개 명령이다. 워크플로라기보다 어휘에 가깝다:

craft는 형태를 먼저 잡고 만드는 전 과정을 시각적 반복과 함께 돌린다. critique는 위계, 명료성, 정서적 톤을 검토한다. audit는 접근성, 성능, 반응형을 점검한다. polish는 출시 전에 디자인 시스템에 맞춘다. bolder와 quieter는 방향 조정, 즉 증폭하거나 억제한다. harden은 오류 상태, i18n, 텍스트 넘침, 경계 조건을 다룬다. typeset과 layout은 에이전트가 만든 UI가 가장 자주 틀리는 두 가지를 고친다. live는 브라우저를 열고 지정한 요소의 변형을 그 자리에서 생성한다.

어느 것이든 단독 단축키로 고정할 수 있다:

/impeccable pin audit

그러면 /audit이 최상위 명령으로 생긴다. 사소한 기능이지만, 이 어휘가 실제로 쓰이느냐를 가르는 차이는 크다.

진짜 흥미로운 공학은 검출기 쪽이다

Impeccable을 프롬프트 모음 저장소 더미와 구분 짓는 지점이 여기다. 62개 규칙에는 모델도, API 키도, 에이전트도 필요 없다.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

즉 CI에서 돈다. 바운스 이징을 다시 들여오거나, 보라색 그라디언트를 슬쩍 넣거나, 청록 배경 위에 14px 회색 캡션을 남긴 풀 리퀘스트는 토큰 값을 아무도 치르지 않고 검사에서 떨어질 수 있다. GitHub Actions 애노테이션을 내보내는 --github 플래그도 있다. 대부분의 팀에 의미 있는 통합 디테일은 이것 하나다.

규칙 세트는 확실히 주관적이고, 어떤 사람들에게는 거슬릴 것이다. 문서도 이를 숨기지 않는다. 안티패턴 목록은 Arial, Inter, 시스템 기본 글꼴을 금지하고, 순수 검정과 순수 회색을 금지하며(항상 색을 섞어야 한다), 무엇이든 카드로 감싸는 것과 카드 안의 카드를 금지하고, 바운스와 탄성 이징을 시대에 뒤진 것으로 금지하고, 색 배경 위 회색 글씨를 금지한다.

그중 일부는 장인론으로서 방어 가능한 주장이다. 채도 높은 배경 위 대비 부족한 본문은 접근성 결함이고, 마침 싸구려처럼 보이기도 한다. Inter 금지는 유행 판단이고, 유행 규칙은 빨리 늙는다. Inter를 금지한 그 문서도 3년 뒤엔 시대극처럼 보일 것이다. 하지만 의견 없는 linter는 그냥 포매터다. 이 도구의 요점은 입장을 갖고 있다는 데 있다.

결정론적이기 때문에 우회도 가능하다. 보라색 그라디언트를 끝까지 밀고 싶은 팀은 인라인 예외를 한 줄 넣으면 된다:

<!-- impeccable-disable overused-font: exported brand doc -->

아니면 npx impeccable ignores add-value overused-font Inter --reason "Brand font"로 무시 목록을 전역 관리하면 된다. --reason 플래그는 조용한 사회적 작업을 한다. 예외를 diff 안에서 눈에 띄게 만드는 것이다.

에이전트에 어떻게 걸리는가

어떤 설치 경로를 고르느냐가 침습성을 결정한다. Claude Code, Copilot, Codex, Cursor, Grok Build의 경우 install이 각 제공자 고유의 훅 매니페스트를 쓴다. Claude Code에서는 .claude/settings.local.json이고, gitignore되어 머신 로컬로 남는다. Copilot에서는 .github/hooks/impeccable.json이고, 커밋되어 클라우드 에이전트와 공유된다. Cursor에서는 .cursor/hooks.json이고, 파일이 쓰일 때 postToolUse에 발동한다.

결과적으로 검출기는 에이전트 자신의 수정 위에서 돌고, 발견한 내용을 에이전트의 루프로 되먹인다. "생각날 때 audit 명령을 돌리는" 방식과는 기제가 다르다. 리뷰 시점이 아니라 생성되는 순간에 슬롭을 잡는다.

대가는 늘 그렇다. 저장소 설정에 쓰는 훅은 코드 리뷰에도 나타나고, Codex 사용자는 설치 후 /hooks로 프로젝트 훅을 명시적으로 승인해야 한다. 도구 설정을 커밋하는 일에 강한 의견이 있는 팀을 위해 서브모듈 경로가 있다. git submodule add에 npx impeccable link --source=.impeccable --providers=claude,cursor를 더하면, 도구가 자기가 통제하는 코드와 함께 버전 관리된다.

고치지 못하는 것

세 가지 한계는 짚어둘 만하다.

이 페이지가 좋은지 나쁜지는 알려주지 못한다. 62개 규칙이 잡는 것은 표면의 징후다. 모든 검사를 통과하고도 관점이 하나도 없는 페이지는 있을 수 있다. AI 슬롭 문제의 더 깊은 층이고, 아직 어떤 linter도 풀지 못한 층이다.

live 모드는 로컬 체크아웃에서만 동작한다. 운영 사이트에는 HTTPS여도 주입하지 않는다. 합당하지만, 시각적 반복 루프가 개발 시점의 도구이지 리뷰 도구는 아니라는 뜻이다.

그리고 어휘는 에이전트가 읽어야만 효과가 있다. Impeccable의 자기 설명은 이 점에서 정직하다. 모든 모델이 같은 디자인을 내놓는 이유는 모든 모델이 같은 SaaS 템플릿으로 학습됐기 때문이다. 스킬 파일은 학습 분포에 대한 가벼운 넛지이고, 넛지는 누구도 바라는 것보다 자주 분포에 진다.

그냥 체크리스트를 쓰면 안 되나?

타당한 질문이다. markdown 파일 한 장짜리 스타일 가이드는 비용이 없고 하는 일도 거의 같아 보인다.

차이는 강제력이다. 프롬프트 속 체크리스트는 제안이다. 모델은 읽고 동의한 다음, 보라색 그라디언트를 그대로 낸다. 그 그라디언트가 학습 데이터에 4만 번 있었기 때문이다. 결정론적 규칙은 빌드를 떨어뜨린다. 압박의 종류가 다르고, 마감 앞에서 살아남는 것은 그 종류뿐이다.

두 번째 차이는 입자다. 체크리스트는 "타이포그래피를 잘 쓰라"고 말한다. Impeccable의 typeset 명령은 위계, 스케일, 페어링을 구체적으로 다루고, 검출기는 개별 실패마다 개별 규칙을 갖는다. 즉 피드백이 취향을 향해 손짓하는 대신 CSS 한 줄을 가리킬 수 있다. 도구가 문서를 이긴다는 논증 전체가 여기 있고, 20년 전 linter에서 그랬던 것과 같은 이유로 여기서도 성립한다.

세 번째는 어휘가 공유된다는 점이다. bolder, quieter, distill, harden. 디자이너와 에이전트 모두 이 말에 따라 행동할 수 있다. "더 튀게 해줘"는 그렇지 않다.

왜 지금 뜨는가

양의 문제가 도착했기 때문이다. 1년 전만 해도 에이전트가 랜딩 페이지를 만드는 일은 이따금이었다. 지금은 팀이 점심 전에 40개 시안을 뽑는다. 병목은 "만들 수 있느냐"에서 "이 중 어느 것이 좋은지, 충분히 빨리 판별할 수 있느냐"로 옮겨갔다.

값싼 실패를 잡는 결정론적 검사기만이 그 문제에서 확장되는 부분이다. 취향은 확장되지 않는다. 글꼴과 이징에 관한 62개의 정규식 모양 규칙은 확장된다. 그리고 그것을 모델 호출 없이 CI에서 도는 물건으로 내놓은 결정이 이 저장소에서 가장 화려하지 않고 가장 유용한 판단이다.