[심층분석] AI가 만든 화면은 왜 다 똑같이 생겼을까? 디자인 감각을 코드로 심어주는 'Impeccable' 해부하기

들어가며: 어디서 많이 본 그 화면

혹시 이런 경험 있으신가요? Claude Code나 Cursor 같은 AI 코딩 도구한테 "랜딩 페이지 하나 만들어줘"라고 했더니, 결과물이 묘하게 익숙한 거예요. 폰트는 어김없이 Inter, 배경에는 보라색에서 파란색으로 흐르는 그라디언트, 카드 안에 또 카드가 들어가 있고, 제목 위에는 모서리 둥근 네모 아이콘이 하나씩 얹혀 있죠. 프로젝트가 달라도, 심지어 모델이 달라도 신기할 만큼 비슷하게 나와요.

이게 우연이 아니거든요. 지금의 AI 모델들은 대부분 비슷한 SaaS 템플릿 데이터를 보고 학습했어요. 그래서 별다른 지침 없이 디자인을 시키면, 학습 데이터의 '평균값' 같은 화면을 뽑아냅니다. 무난하긴 한데 어디에도 개성이 없는, 딱 그 얼굴이요. 오늘 소개할 Impeccable은 바로 이 문제를 정면으로 겨냥한 오픈소스 프로젝트예요. 만든 사람은 jQuery UI를 공동 개발했던 Paul Bakaus인데요, "AI 에이전트를 디자인에 더 능숙하게 만드는 디자인 언어"를 표방하고 있어요.

사실 이 흐름의 출발점은 Anthropic이 공개했던 frontend-design 스킬이에요. Claude에게 프론트엔드 디자인 지침을 주는 최초의 대중적인 스킬이었는데, Impeccable은 여기서 출발해 훨씬 체계적인 도구로 확장한 거예요. 스킬 1개, 커맨드 23개, 브라우저에서 실시간으로 확인하며 고치는 기능, 그리고 LLM 없이 돌아가는 60개의 결정론적 검사 규칙까지 갖춘 종합 패키지가 됐죠.

기술 분석: '감각'을 어떻게 파일로 만들었나

스킬이라는 개념부터 짚고 가요

'스킬'이 뭐냐면, 쉽게 말해 AI 에이전트에게 쥐여주는 전문 분야 매뉴얼이에요. 신입 디자이너가 입사하면 브랜드 가이드 문서를 받잖아요? 그것처럼 AI가 특정 작업을 할 때 참고하는 마크다운 문서 묶음이라고 보시면 돼요. AI 모델 자체를 다시 학습시키는 게 아니라, 작업 시점에 "이런 원칙으로 디자인해"라는 지식을 얹어주는 방식이라 어떤 프로젝트에든 바로 붙일 수 있어요.

설정은 대화 한 번으로 끝나요

설치는 프로젝트 루트에서 npx impeccable install 한 줄이면 되고, 그다음 AI 코딩 도구 안에서 /impeccable init을 실행하면 설정 대화가 시작돼요. 이 과정에서 두 개의 핵심 문서가 만들어지는데요.

• PRODUCT.md: 이 제품이 뭔지, 누구를 위한 건지, 어떤 목소리로 말하는지를 정리한 문서예요.
• DESIGN.md: 브랜드 색상, 타이포그래피, 컴포넌트 규칙, 그리고 '이런 건 절대 따라 하지 마'라는 안티 레퍼런스까지 담겨요.

이게 왜 중요하냐면, 이후의 모든 디자인 명령이 이 두 문서를 기준으로 동작하거든요. AI가 매번 백지에서 '평균적인 SaaS 화면'을 상상하는 게 아니라, 우리 제품의 맥락 위에서 판단하게 되는 거예요.

23개의 커맨드: 팀과 AI가 같은 언어로 말하기

Impeccable의 재미있는 지점은 디자인 작업을 동사로 쪼갰다는 거예요. /polish(다듬기), /audit(점검), /critique(비평), /distill(덜어내기), /animate(움직임 넣기), /bolder(더 과감하게), /quieter(더 차분하게) 같은 식이죠.

평소에 우리가 AI한테 디자인 수정을 시킬 때를 떠올려 보세요. "좀 더 예쁘게 해줘"라고 하면 뭘 어떻게 바꿀지 복불복이잖아요. 그런데 /quieter라고 하면 '시각적 소음을 줄이는 방향'이라는 구체적인 작업 정의가 이미 스킬 안에 들어 있어요. 사람끼리도 "이 화면 좀 시끄럽지 않아?"라는 말의 기준이 제각각인데, AI와 나 사이에 공유된 디자인 어휘가 생기는 셈이에요.

60개의 결정론적 규칙: 디자인계의 ESLint

개인적으로 가장 눈여겨볼 부분은 이거예요. Impeccable에는 LLM 없이, API 키도 없이 돌아가는 60개의 검사 규칙이 있어요. '결정론적'이라는 건 같은 입력을 넣으면 언제나 같은 결과가 나온다는 뜻인데요. AI한테 "이 디자인 어때?"라고 물으면 물을 때마다 답이 조금씩 달라지지만, 이 규칙들은 코드 린터처럼 기계적으로 딱딱 잡아내요.

비유하자면 ESLint와 코드 리뷰의 관계예요. 세미콜론 빠진 것, 안 쓰는 변수 같은 건 린터가 기계적으로 잡고, 설계가 좋은지 나쁜지는 사람이 리뷰하잖아요. Impeccable도 '회색 텍스트를 유색 배경 위에 올렸다' 같은 명백한 문제는 규칙으로 잡고, 더 미묘한 취향의 영역은 LLM 기반 비평 검사로 넘겨요. 결정론적 규칙은 CLI와 브라우저 확장 프로그램으로도 돌릴 수 있어서, CI 파이프라인에 넣어 '디자인 테스트'처럼 쓸 수도 있고요.

브라우저에서 직접 보면서 고쳐요

또 하나, 라이브 브라우저 반복(live browser iteration) 기능도 있어요. AI가 코드만 써놓고 "잘 됐겠지" 하는 게 아니라, 실제 브라우저에 렌더링된 결과를 확인하면서 고치는 루프를 도는 거예요. 디자인은 코드가 아니라 화면으로 평가받는 거라, 이 피드백 루프가 있고 없고의 차이가 꽤 커요.

업계 맥락: 왜 지금 '디자인 스킬'인가

저장소 구조를 보면 흥미로운 게 하나 있어요. .claude, .cursor, .codex, .gemini, .kiro, .opencode, .trae 등등, 지금 시장에 나와 있는 거의 모든 AI 코딩 도구용 디렉터리가 다 들어 있거든요. 에이전트 생태계는 도구마다 설정 방식이 달라 파편화되어 있는데, "한 번 설치하면 어느 도구에서든 같은 디자인 언어를 쓴다"는 포지셔닝을 잡은 거예요.

기존 접근들과 비교하면 이렇게 볼 수 있어요.

• Anthropic frontend-design 스킬: 방향을 제시한 원조예요. 다만 일반적인 지침 문서에 가까워서, 우리 제품의 맥락을 담거나 결과를 기계적으로 검증하는 장치는 없었죠.
• 디자인 시스템(사내 시스템, shadcn/ui 등): 부품(컴포넌트)의 표준화예요. 그런데 좋은 부품을 써도 조립을 이상하게 하면 이상한 화면이 나오잖아요. Impeccable은 부품이 아니라 '조립하는 안목'을 다뤄요. 대체제가 아니라 보완재인 셈이에요.
• 프롬프트에 디자인 지침 붙여넣기: 많은 분들이 지금 이렇게 쓰고 계실 텐데, 이건 개인의 비법 노트에 머물러요. Impeccable은 그 비법을 버전 관리되는 파일과 검증 가능한 규칙으로 끌어올린 거고요.

한국 개발자에게 주는 시사점

가장 와닿을 사람들은 디자이너 없이 제품을 만드는 팀이에요. 초기 스타트업, 사이드 프로젝트, 사내 어드민을 만들 때처럼요. AI 덕분에 화면을 뽑는 속도는 빨라졌는데, 뽑아놓고 보면 어딘가 어색하고, 뭐가 어색한지 말로 설명을 못 하는 상황이 많잖아요. 그 '설명 못 하는 어색함'을 60개 규칙이 어느 정도 언어화해줘요.

실무 도입은 이런 흐름이 될 거예요.

1. 진행 중인 프로젝트에서 npx impeccable install 실행 — 5분이면 돼요.
2. /impeccable init으로 PRODUCT.md와 DESIGN.md 생성 — 이때 대충 넘기지 말고 타깃 사용자와 안티 레퍼런스를 구체적으로 적는 게 핵심이에요.
3. 기존 화면에 /audit를 돌려서 현재 상태부터 점검해보기.
4. 자주 쓰는 커맨드(/polish, /quieter)를 팀 위키에 정리해서 컨벤션으로 만들기.

다만 고려할 점도 있어요. 이 규칙들은 영어권 웹 기준으로 만들어졌을 가능성이 커요. 한글 타이포그래피는 사정이 다르거든요. Inter 대신 Pretendard를 쓴다든지, word-break: keep-all 같은 한글 줄바꿈 처리, 영문보다 자간과 행간을 다르게 잡아야 하는 문제 같은 건 DESIGN.md에 직접 명시해줘야 해요. 뒤집어 보면, 이런 한글 특화 규칙을 정리해서 기여하는 것도 꽤 좋은 오픈소스 기여 소재가 될 수 있어요.

학습 순서를 제안하자면 이래요. 먼저 에이전트 스킬이라는 개념 자체를 이해하고(마크다운으로 AI에게 전문 지식을 주입하는 방식이라는 것), 그다음 데모 프로젝트에 설치해서 /audit와 /critique의 결과 차이를 비교해보세요. 결정론적 검사와 LLM 비평이 각각 뭘 잡아내는지 보면 이 도구의 설계 철학이 몸으로 이해될 거예요. 마지막으로 DESIGN.md를 우리 서비스에 맞게 다듬는 단계까지 가면 실전 투입 준비 완료예요.

마무리: 디자인 감각도 버전 관리되는 시대

Impeccable이 보여주는 큰 그림은 '디자인 취향의 코드화'예요. 지금까지 디자인 감각은 사람 머릿속에만 있어서, 그 사람을 채용하거나 오래 협업해야만 얻을 수 있는 자산이었는데요. 이제는 마크다운 파일과 검사 규칙의 형태로 저장소에 커밋되고, PR로 리뷰되고, 팀원 모두의 AI에게 똑같이 적용되는 거죠. 인프라를 코드로 관리하는 IaC(Infrastructure as Code)가 운영 지식을 코드화했듯이, 디자인 지식도 같은 길을 걷기 시작한 거예요.

물론 규칙이 취향을 완전히 대신할 수는 없어요. 60개 규칙을 다 통과해도 감동이 없는 화면은 얼마든지 나올 수 있죠. 하지만 '명백히 이상한 것'을 기계가 걸러주면, 사람은 더 높은 차원의 고민에 시간을 쓸 수 있게 돼요. 그게 이런 도구의 진짜 가치 아닐까요.

여러분은 어떠세요? AI가 만들어준 화면을 보고 '아, 이거 AI가 만들었구나' 싶었던 순간이 있었나요? 그리고 우리 팀만의 디자인 원칙을 파일 하나에 적어야 한다면, 첫 줄에 뭐라고 쓰시겠어요? 댓글로 이야기 나눠주세요.