Impeccable: AI 코딩 에이전트를 위한 디자인 언어와 결정론적 규칙 엔진
Impeccable은 Paul Bakaus가 만든 오픈소스 디자인 스킬로, 비슷한 학습 데이터 때문에 생기는 AI 생성 프런트엔드의 획일성 문제——기본 Inter 글꼴, 보라-파랑 그라데이션, 중첩된 카드——를 겨냥한다. Anthropic의 frontend-design 스킬을 토대로 지속적인 제품 맥락(PRODUCT.md)과 시각적 방향(DESIGN.md)을 분리하고, 기획부터 구축, 비평, 강화까지 아우르는 24개 명령과 LLM이나 API 키 없이 CLI와 브라우저 확장에서 작동하는 61개의 결정론적 탐지 규칙을 제공하며 짧은 기간에 7만 4천 개 이상의 스타를 모았다.
배경 및 문제 정의
코딩에 사용되는 거의 모든 대형 언어 모델은 사실상 동일한 공개 웹 코드 말뭉치로 학습된다. 같은 컴포넌트 라이브러리, 같은 SaaS 마케팅 사이트, 같은 Tailwind 스타일 템플릿이다. 그 결과 어떤 모델을 쓰든 AI가 생성한 프런트엔드는 좁은 범위의 시각적 습관으로 수렴한다. 기본 글꼴로 Inter를 쓰고, 보라에서 파랑으로 이어지는 그라데이션 히어로를 넣고, 카드 안에 카드를 중첩시키고, 색이 있는 배경 위에 옅은 회색 글자를 올리고, 모든 섹션 제목 위에 둥근 사각형 아이콘 타일을 띄운다. 이는 특정 모델의 결함이 아니라 학습 데이터가 만들어내는 통계적 산물이며, 프롬프트 엔지니어링만으로는 확실히 제거하기 어렵다. 모델은 어제 무엇을 납품했는지 기억하지 못하고, 자신의 출력을 규칙집과 대조할 메커니즘도 갖고 있지 않기 때문이다. Anthropic의 frontend-design 스킬은 심미적 판단을 우연에 맡기는 대신 코딩 에이전트에게 명시적인 디자인 지침을 준 첫 번째로 널리 채택된 시도였다. Paul Bakaus가 만든 Impeccable은 이 토대에서 출발하되, 근본 문제를 단일 스킬 파일이 아니라 워크플로와 도구의 공백으로 재정의한다. 에이전트에게는 세션을 넘나드는 지속적인 제품 맥락, 변경을 요청하기 위한 공유 어휘, 그리고 같은 모델의 자기 평가에 의존하지 않는 검증 수단이 필요하다는 것이다.
핵심 아키텍처와 기술 원리
Impeccable은 `/impeccable`이라는 단일 명령으로 설치되지만, 실제 아키텍처는 두 개의 문서와 두 개의 검증 계층을 분리하는 데 있다. `PRODUCT.md`는 `/impeccable init`이 한 번만 작성하며, 대상 사용자, 목적, 운영 맥락, 제약, 어조, 근거 같은 지속적인 제품 사실을 담는다. 이는 표면적인 시각적 방향과 의도적으로 분리되어 있으며, 시각적 방향은 화면마다 따로 선택되어 기존 또는 새로 구축된 시각 시스템이 생기면 별도로 `DESIGN.md`에 기록된다. 이 토대 위에 디자인 워크플로의 서로 다른 단계에 대응하는 24개 명령이 놓인다. 기획과 구축을 맡는 `shape`와 `craft`, 리뷰를 맡는 `critique`와 `audit`, 출시 준비를 맡는 `polish`, `harden`, `onboard`, 그리고 전체 방향을 다시 논쟁하지 않고 강도를 조절하는 다이얼형 명령군인 `bolder`, `quieter`, `distill`, `animate`, `colorize`, `overdrive`가 있다. 두 번째 계층은 LLM도 API 키도 필요 없는 61개의 결정론적 탐지 규칙으로, CLI와 동반 브라우저 확장 프로그램이 동일한 규칙 세트를 실행하므로 대비율, 여백 리듬, 글꼴 조합 위반 여부 같은 검사는 실행 횟수나 모델이 바뀌어도 항상 같은 답을 내놓는다.
실전 평가 및 활용
실제로는 프로젝트가 `npx impeccable install`을 한 번 실행하고, 새로운 작업을 시작할 때마다 `/impeccable init`을 실행하는 방식으로 Impeccable을 도입한다. 설정 단계는 지속적인 제품 맥락 중 비어 있는 부분만 묻고, 이미 기록된 사실을 팀에 다시 묻지 않는다. 이후 `/impeccable craft`는 실시간 브라우저 반복을 곁들인 '방향 설정 후 구축'의 전체 흐름을 실행하여, 에이전트가 자신이 렌더링한 결과를 보고 제어권을 넘기기 전에 스스로 수정할 수 있게 한다. 결정론적 규칙이 가장 중요해지는 곳은 리뷰 명령이다. `/impeccable audit`은 접근성, 성능, 반응형 대응이라는 61개 규칙의 기술적 검사를 실행하고, `/impeccable critique`는 정성적 판단을 유지하며 디자인 리드가 크리틱 세션에서 하듯 위계, 명료성, 감정적 울림을 평가한다. `/impeccable document`와 `/impeccable extract`는 기존 코드에서 `DESIGN.md`를 생성하고 재사용 가능한 컴포넌트와 토큰을 공유 시스템으로 끌어들여 순환을 완성하는데, 이는 문서화되지 않았더라도 이미 고유한 시각 언어를 갖춘 코드베이스에 Impeccable을 도입하는 팀에 특히 중요하다.
업계 영향과 향후 전망
Impeccable이 짧은 기간에 7만 4천 개가 넘는 스타를 모았다는 사실은 에이전트형 코딩 도구가 프런트엔드 코드 대부분을 실제로 작성하게 된 지금, 획일성에 대한 우려가 얼마나 절박한지를 보여준다. 이 프로젝트의 진짜 기여는 개별 명령이 아니라, AI 산출물에 대한 디자인 품질 검사도 테스트 스위트와 같은 수준의 엄격함을 갖춰야 한다는 주장에 있다. 판단이 필요 없는 부분은 결정론적이고 재현 가능하며 모델 없이도 실행할 수 있어야 한다는 것이다. 주관적인 절반은 LLM 비평에, 검증 가능한 절반은 결정론적 규칙에 맡기는 이 분담 방식은, 코드를 작성한 모델이 자기 채점까지 하게 되는 불일치를 피할 수 있는 유일한 방법이기에 이 분야 후속 도구들이 따를 가능성이 높은 틀이다. 남은 질문은 디자인 유행이 바뀌는 가운데 61개 규칙이 얼마나 오래 버틸 수 있는가이다. 오늘날의 'AI 티'에 맞춰 조정된 규칙 세트도 다른 린터 설정과 마찬가지로 지속적인 유지보수가 필요하며, 그렇지 않으면 에이전트가 이미 내일의 기본값으로 넘어간 뒤에도 어제의 그라데이션만 쫓게 될 것이다.
Sources
FAQ
Impeccable은 Anthropic의 frontend-design 스킬과 어떤 관계인가?
Paul Bakaus가 만든 Impeccable은 Anthropic의 frontend-design 스킬에서 명시적으로 출발하여 PRODUCT.md/DESIGN.md 분리, 24개의 워크플로 명령, 61개의 결정론적 탐지 규칙으로 이를 확장한다.
61개의 탐지 규칙이 LLM을 쓰지 않는 이유는?
대비율, 여백 리듬, 글꼴 조합 위반처럼 객관적으로 판단 가능한 문제를 검사하기 때문에, 결정론적으로 실행하면 모델이나 실행마다 달라질 수 있는 확률적 판단과 달리 매번 같은 결과를 보장할 수 있다.
PRODUCT.md와 DESIGN.md는 각각 무엇을 기록하는가?
PRODUCT.md는 세션을 넘나드는 지속적인 제품 사실——대상, 목적, 제약, 어조——을 기록하고, DESIGN.md는 시각 시스템이 갖춰진 뒤 화면마다 선택되는 구체적인 시각적 방향을 기록하며, 둘은 의도적으로 분리되어 있다.