실측 기반 소개

AI가 만든 UI가 다 똑같아 보일 때 — Taste Skill(anti-slop) 정리

AI 코딩 결과물의 "AI티"를 줄이는 오픈소스 에이전트 스킬. npx 한 줄로 설치, MIT 무료.

도구 Taste Skill
가격 무료 (MIT 라이선스, 오픈소스)
툴콕 점수 7.4
AI가 만든 UI가 다 똑같아 보일 때 — Taste Skill(anti-slop) 정리 커버 이미지
9 MIN

에이전트에게 랜딩 페이지를 만들라고 시켜보면 결과물이 대체로 예상 범위 안에 들어옵니다. 가운데 정렬된 히어로, 그라데이션이 살짝 들어간 큰 제목, 그 아래 아이콘 세 개짜리 특징 카드 3단, 회색 배경의 CTA 섹션, 마지막에 링크 네 줄짜리 푸터. 작동은 합니다. 반응형도 대체로 맞습니다. 그런데 어제 다른 프로젝트에서 뽑은 화면과 구분이 안 됩니다.

문제는 이걸 고치는 방식입니다. 보통은 “좀 더 세련되게”, “좀 더 프리미엄하게” 같은 말을 덧붙여서 다시 시킵니다. 그러면 그라데이션이 하나 더 늘고 보더 반경이 커진 같은 화면이 나옵니다. 미감에 대한 지시는 형용사로 주는 순간 거의 아무 정보도 전달하지 못합니다. 모델 입장에서 “세련되게”는 학습 데이터의 평균값을 다시 한번 꺼내라는 말과 크게 다르지 않기 때문입니다.

Taste Skill은 이 지점을 노린 오픈소스 프로젝트입니다. 저장소가 스스로를 소개하는 문구는 “The Anti-Slop Frontend Framework for AI Agents”입니다. slop은 AI가 대량으로 찍어내는 밋밋한 결과물을 가리키는 말이고, 이 스킬은 에이전트가 프론트엔드를 만들 때 참고할 판단 기준을 붙여줘서 그 밋밋함을 줄이겠다는 접근입니다. 라이선스는 MIT, 설치는 명령어 한 줄입니다.

이 글은 저장소 공개 문서와 설치 방법을 정리한 것입니다. 여러 프로젝트에 장기간 적용해 A/B로 비교한 결과가 아니므로 검증완료 배지는 붙이지 않았습니다. 아래 점수도 공개 사양과 구조를 본 판단입니다.

AI 결과물이 서로 닮아가는 네 가지 이유

도구를 보기 전에 원인부터 정리하는 편이 낫습니다. 원인을 모르면 어떤 스킬을 붙여도 형용사만 바뀝니다.

원인무슨 일이 벌어지나
평균으로 수렴모델은 확률이 높은 선택을 합니다. 디자인에서 확률이 높은 선택은 곧 흔한 선택입니다
기본값 관성프레임워크·UI 킷의 기본 팔레트, 기본 간격, 기본 그림자가 그대로 남습니다
미명시된 요구프롬프트는 기능만 적습니다. 여백·리듬·타이포 위계는 아무도 지시하지 않으니 기본값이 이깁니다
피드백 루프 부재코드는 빌드 실패로 틀렸음을 알 수 있지만, 촌스러움은 에러를 내지 않습니다

네 번째가 제일 큽니다. 개발 쪽에는 테스트·린터·타입체커가 있어서 에이전트가 자기 출력을 검증할 수 있습니다. 시각 결과물에는 그런 장치가 없습니다. 그래서 “잘 만들어진 화면은 이런 조건을 만족한다”는 기준을 외부에서 문서로 주입하는 접근이 나옵니다. 에이전트 스킬 형태의 디자인 가이드가 하는 일이 정확히 그것입니다.

Taste Skill의 구성

정리하면 이 저장소는 두 종류를 함께 담고 있습니다.

  • 코드 구현 스킬 — 에이전트가 프론트엔드를 짤 때 따를 레이아웃·타이포·모션·여백 기준을 담은 부분입니다. 핵심은 design-taste-frontend입니다.
  • 레퍼런스 이미지 생성 스킬 — 무드보드/레퍼런스 보드를 만들기 위한 프롬프트 스킬로, web·mobile·brand kit 용도가 나뉘어 있습니다.

두 번째가 있다는 점이 이 저장소의 성격을 잘 보여줍니다. 저장소가 제안하는 흐름은 코드부터 시키는 게 아니라 시안을 먼저 이미지로 뽑고, 그 프레임을 코딩 에이전트에 넘겨 구현시키는 순서입니다. ChatGPT Images 같은 도구로 화면 시안을 만들고, 그 결과를 Codex / Cursor / Claude Code에 넘기는 구성입니다.

이 순서가 왜 중요한지는 위의 네 번째 원인과 이어집니다. 에이전트에게 “알아서 예쁘게”를 맡기면 평균값이 나오지만, 시각적 기준이 되는 이미지를 먼저 고정해 놓으면 그때부터는 “만들라”가 아니라 “맞춰라”가 됩니다. 형용사 대신 대조군을 주는 셈입니다.

호환 대상으로 표기된 환경은 다음과 같습니다.

환경사용 방식
Claude Code스킬 설치 후 세션에서 사용
Cursor스킬 설치 또는 SKILL.md 참조
Codex스킬 설치 또는 SKILL.md 참조
ChatGPTSKILL.md 내용을 대화에 붙여넣어 사용

즉 특정 IDE에 묶인 플러그인이 아니라, 마크다운 문서 한 벌을 여러 도구에 이식하는 형태입니다. 이걸 저장소는 Portable Agent Skills라고 부릅니다.

설치

npx skills add 로 저장소를 통째로 가져올 수 있습니다.

# 저장소의 스킬 전체 설치
npx skills add https://github.com/Leonxlnx/taste-skill

전부 필요하지 않다면 anti-slop 프론트엔드 스킬만 골라 설치합니다.

# 프론트엔드 스킬 하나만 (기본값 = v2)
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

여기서 실무자가 알고 있어야 할 부분이 버전 구분입니다. design-taste-frontend 이름은 현재 v2를 가리키며, v2는 실험 단계로 표기돼 있습니다. 안정적인 쪽을 원하면 v1을 명시적으로 지정해야 합니다.

# v1로 고정하고 싶을 때
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"

설치 도구를 쓰고 싶지 않다면 방법은 더 단순합니다. SKILL.md 파일을 프로젝트 폴더에 복사해 두고 에이전트가 읽게 하거나, 내용을 그대로 ChatGPT·Codex 대화창에 붙여넣어도 동작합니다. 결국 실체는 규칙이 적힌 마크다운이기 때문입니다. 팀에서 쓴다면 저장소에 커밋해 두고 리뷰 대상으로 삼는 편이 버전 관리 측면에서 낫습니다.

실무 워크플로우에 끼워 넣는 순서

이 스킬은 단독으로 쓰는 도구라기보다 기존 작업 순서의 한 칸을 채우는 쪽에 가깝습니다.

  1. 요구사항 정리 — 페이지 구조, 필요한 섹션, 콘텐츠를 먼저 확정합니다. 이 단계는 스킬과 무관합니다.
  2. 시각 기준 확보 — 이미지 생성 스킬이나 실제 레퍼런스 사이트로 무드보드를 만듭니다. 여기서 색·타이포·밀도의 방향이 정해집니다.
  3. 구현 — Taste Skill을 장착한 상태로 코딩 에이전트에 넘깁니다. 2번의 결과물을 함께 전달합니다.
  4. 검수 — 사람이 봅니다. 이 단계는 어떤 스킬을 써도 없어지지 않습니다.

3번만 도입하고 2번을 건너뛰면 효과가 줄어들 가능성이 큽니다. 기준선이 되는 시각 자료 없이 규칙 문서만 있으면, 에이전트는 여전히 자기 평균값 위에서 규칙을 적용합니다. 반대로 2번을 제대로 하면 스킬 없이도 결과가 꽤 올라갑니다.

점수: 7.4

좋은 점

  • MIT 라이선스 무료입니다. 도입 비용이 0이고, 마음에 안 들면 파일을 지우면 끝입니다. 계정도 결제 정보도 필요 없습니다.
  • 특정 도구에 묶이지 않습니다. Claude Code, Cursor, Codex, ChatGPT를 오가는 사람이라도 같은 기준 문서를 그대로 씁니다.
  • 구현 스킬과 이미지 생성 스킬이 한 저장소에 있어서, 시안 → 구현 흐름을 한 세트로 가져갈 수 있습니다.
  • 실체가 마크다운이라 내용을 읽고 검증할 수 있습니다. 우리 팀 컨벤션에 맞게 잘라내거나 덧붙이기도 쉽습니다. 블랙박스 SaaS와 다른 점입니다.

아쉬운 점

  • 기본으로 설치되는 design-taste-frontend가 v2, 즉 실험 버전입니다. 안정성을 원하면 v1을 직접 지정해야 하는데, 이걸 모르고 설치하면 버전이 바뀔 때 결과가 흔들릴 수 있습니다.
  • 효과를 객관적으로 측정할 방법이 없습니다. “덜 뻔해졌다”는 판단은 결국 사람이 눈으로 합니다. 팀 안에서 도입 여부를 설득하기 어려운 종류의 도구입니다.
  • 프롬프트에 규칙 문서가 얹히는 만큼 컨텍스트를 먹습니다. 긴 세션에서는 무시할 수 없는 비용이고, 작업이 길어질수록 초반 규칙이 희석되는 문제도 같이 옵니다.
  • 규칙이 강하면 결과가 그 규칙 쪽으로 수렴합니다. 평균에서 벗어나는 대신 이 스킬 특유의 스타일로 몰릴 여지가 있습니다. 브랜드 아이덴티티가 뚜렷한 프로젝트에서는 그대로 쓰기보다 덜어내고 쓰는 편이 낫습니다.
  • 오픈소스 개인 저장소이므로 유지보수 지속성에 대한 보장이 없습니다. 업무 파이프라인의 필수 요소로 삼기보다, 언제든 뺄 수 있는 보조 장치로 두는 게 안전합니다.

이럴 때 쓰세요: 코딩 에이전트로 프론트엔드를 자주 뽑는데 결과물이 매번 비슷한 인상이라 손으로 다시 만지는 시간이 길어지고 있다면, 무료이므로 한 프로젝트에 붙여보고 판단할 만합니다.

주의사항

저장소 README에 명시된 경고를 그대로 옮깁니다. 이 프로젝트를 사칭한 비공식 토큰이나 코인이 돌아다닌다고 합니다. 공식 채널은 깃허브 저장소뿐이며, 이 프로젝트와 관련해 무언가를 사라는 제안을 받으면 그 자체가 사칭 신호입니다.

  • 공식 저장소: Leonxlnx/taste-skill
  • 이 프로젝트는 무료 오픈소스입니다. 결제나 지갑 연결을 요구하는 경로는 공식이 아닙니다.

설치 명령이 npx로 원격 저장소를 가져오는 방식이라는 점도 짚어둡니다. 실행 전에 URL이 위 주소와 정확히 일치하는지 확인하고, 설치 후 받아진 SKILL.md를 한 번 읽어보길 권합니다. 어차피 내용이 마크다운이라 몇 분이면 훑습니다. 에이전트에게 규칙을 주입하는 파일이므로, 무엇이 주입되는지는 알고 쓰는 편이 맞습니다.

정리

이 도구가 해결하는 건 “AI가 못 만든다”가 아니라 “AI가 평균적으로 만든다” 쪽입니다. 그래서 기대치도 거기에 맞추는 게 좋습니다. 스킬 하나를 붙였다고 디자이너의 판단이 대체되지는 않습니다. 대신 첫 출력의 시작점이 조금 위로 올라가고, 그만큼 손보는 시간이 줄어듭니다.

무료이고 되돌리기 쉬운 도구라서, 고민하는 시간보다 한 프로젝트에 붙여보고 결과를 비교하는 편이 빠릅니다. 다만 설치할 때 v1과 v2 중 무엇을 받는지는 꼭 확인하세요. 기본값이 실험 버전이라는 점이 이 저장소에서 가장 놓치기 쉬운 부분입니다.