AI slop 덜어내기 1편: UI 스킬 suta(수타)

AI가 만든 티가 나는 결과물을 AI slop이라고 부릅니다. 저는 이 티를 덜어내려고 Claude Code와 Codex에서 쓰는 스킬 세 개를 만들었습니다. 화면을 다루는 suta(수타), 코드 리뷰와 테스트를 다루는 gimi(기미), 문서와 글을 다루는 geulppal(글빨)입니다.

세 편에 걸쳐 스킬마다 왜 만들었는지, 어떻게 설계하고 구현했는지, 결과가 어땠는지 정리해보려 합니다. 첫 번째는 suta입니다.

왜: 항상 비슷하고 어색한 AI 디자인

AI로 UI를 만들 때마다 비슷한 카드와 과한 색, 불필요한 장식이 반복되는 게 불편했습니다.

증상은 대체로 이렇습니다. 모든 섹션을 카드로 감싸고, 간격은 한 값으로 맞추고, 그라데이션과 배지로 꾸밉니다. 강조색은 프레임워크 기본 파랑이고, 상태마다 연노랑·주황·연두 알약이 붙습니다. 같은 정보와 버튼이 두세 곳에 나오고, 글자는 작고 흐립니다.

코드에도 티가 납니다. 모든 요소에 transition: all을 붙이고, height나 top을 움직여 화면이 버벅입니다. 동작 줄이기 설정은 무시하고, div에 onClick을 달아 키보드로는 쓸 수 없게 만듭니다.

하나씩 보면 사소합니다. 그런데 한곳에 모이면 어디서 본 듯한 화면이 됩니다.

UI 예제 모음으로 시작한 fe-skills

suta는 2026년 8월에 fe-skills라는 이름으로 시작했습니다. 바텀시트, 핀치 줌, 가상 스크롤처럼 구현이 까다로운 UI를 AI가 참고하도록 설명과 코드를 묶은 스킬 모음이었습니다. 진입·퇴장 애니메이션과 스크롤 등장 두 개로 시작해서, 10월 초에는 UI 스킬이 53개가 됐습니다.

그런데 53개를 쌓고 보니 스킬이 읽혀야 할 때 읽히지 않았습니다. 스킬은 각자의 설명(description)을 보고 선택됩니다. 바텀시트를 구현한다, 토스트를 구현한다는 설명 53개가 서로 경쟁하니, "로그인 화면 만들어줘" 같은 평범한 요청에는 아무것도 걸리지 않았습니다.

스킬 목록의 길이도 문제였습니다. 당시 확인한 기준으로 Claude Code는 컨텍스트의 1%, Codex는 2%를 스킬 목록에 씁니다. 53개 설명을 합치면 약 12,100자라서 이 예산을 넘었습니다.

줄이고 싶은 문제는 화면 전체에서 생기는데, 스킬은 특정 컴포넌트를 요청할 때만 읽히는 구조였던 겁니다.

UI 요청마다 읽히는 스킬 하나로 전환

그래서 10월 6일에 방향을 바꿨습니다. 스킬 모음 대신, 한 번 설치하면 Claude Code와 Codex가 UI 요청마다 읽는 스킬 하나를 만들기로 했습니다. 디자인 스킬 impeccable이 이런 방식으로 동작합니다.

이름도 suta(수타)로 바꿨습니다. 수타(手打)는 기계가 아니라 손으로 친다는 뜻입니다. 찍어낸 UI가 아니라 손으로 다듬은 UI를 목표로 지은 이름입니다. unslop, deslop, slopless처럼 'slop'이 들어간 후보도 있었지만, 같은 분야의 기존 프로젝트와 이름이 겹쳐 뺐습니다.

전환은 세 단계로 했습니다. 이름을 바꾸고, 함께 들어 있던 설계 문답 스킬을 지우고, UI 스킬 53개를 진입 스킬 suta 아래의 패턴으로 옮겼습니다.

설계: 레퍼런스에서 뽑은 기준과 금지선

디자인 피드백 307건에서 뽑은 원칙

금지선을 적으려면 무엇이 AI 티인지부터 정해야 했습니다. 먼저 실무 UI 디자인 피드백 사례를 분석했습니다. 시안을 고치기 전과 후를 비교한 사례 중 레이아웃·시각·UX를 다룬 307건입니다. 여기서 원칙 12개를 뽑았고, 원칙들은 한 문장으로 모였습니다.

레이아웃은 꾸미는 일이 아니라 순서를 정하는 일이다.

무엇을 먼저 보게 할지, 무엇을 같이 묶을지, 무엇을 뺄지를 먼저 정합니다. 그 순서는 크기·굵기·색 농도·간격·정렬처럼 값싼 수단으로 보여줍니다. 채운 색 면·그림자·그라데이션·상자 같은 비싼 수단은 한두 번만 씁니다.

AI가 만든 화면은 정확히 반대로 갑니다. 모든 요소를 같은 무게로 늘어놓고, 순서를 정하는 대신 카드·그라데이션·배지로 꾸밉니다. 피드백에서 "망한 디자인"으로 지적받아 고친 시안과 AI slop은 증상이 거의 같았습니다.

잘 만든 앱과 웹사이트에서 잰 기준값

원칙만으로는 간격을 몇 px로 할지, 색을 몇 개 쓸지 정할 수 없습니다. 그래서 잘 만든 서비스를 쟀습니다. 국내 앱 31곳의 화면 1,116장을 화면 유형별로 기록하고, 웹사이트 19곳의 공개 CSS를 측정했습니다. 몇 가지 결과는 이렇습니다.

• 앱 31곳 중 25곳(81%)이 UI에 체계 색을 2종 이하로 썼습니다.
• 화면의 87%에는 연노랑·연민트 같은 옅은 색 면이 없었습니다.
• 카드의 71%는 테두리와 그림자 없이 바탕 톤 차이로만 구분했습니다.
• UI 문구 7,539개를 받아 적어 보니 오류 문구의 87%가 해요체였습니다.
• 웹사이트 19곳은 모두 글꼴 파일을 불러왔습니다. AI가 만든 결과물 48개는 하나도 불러오지 않았습니다.

이 값들이 금지선과 토큰이 됐습니다. 프로젝트에 이미 디자인 체계가 있으면 그 값을 쓰고, 없을 때만 이 기본값을 씁니다. 다만 기존 체계라도 금지선에 걸리는 색과 구조까지 지키지는 않습니다.

AI가 흔히 하는 것과 대신 할 것을 짝지은 금지선

진입 스킬의 중심은 금지선 표입니다. AI가 흔히 하는 것, 대신 할 것, 근거가 되는 패턴을 한 행에 적었습니다. 일부를 옮기면 이렇습니다.

금지선은 레이아웃, 글자·색·면, 문구, 모션, 상호작용·피드백, 접근성, CSS 구조로 나뉩니다. 맞는 패턴이 없는 UI에도 금지선은 그대로 적용됩니다.

진입 스킬 하나와 필요할 때만 읽는 패턴

에이전트가 처음 읽는 파일은 SKILL.md 하나입니다. 작업 절차, 금지선, 레이아웃·모션 값, 마무리 체크리스트, 패턴 카탈로그가 들어 있습니다. 카탈로그에는 패턴마다 설명의 첫 문장만 넣었습니다. 전환 당시 53개 기준으로 3,555자, 설명 전체(10,900자)의 3분의 1 정도입니다.

에이전트는 카탈로그에서 맞는 패턴을 고른 뒤에야 그 패턴의 PATTERN.md를 읽습니다. 언제 쓰는지, 왜 이 기술을 골랐는지, 사용법과 주의사항이 적혀 있습니다. 패턴은 지금 57종입니다.

패턴 코드는 라이브러리로 설치하지 않고 프로젝트에 복사해 맞춰 씁니다. 프레임워크와 무관한 코어(TypeScript, 의존성 0)와 React 래퍼, CSS로 나눴습니다. 처음에는 React 전용으로 만들었다가 이 두 층 구조로 고쳤습니다. React가 아닌 프로젝트는 코어와 CSS만 가져가면 됩니다. CSS로 되는 것은 CSS로 하고, 제스처와 물리 계산만 TypeScript로 썼습니다.

덜어내기부터 하는 작업 절차

SKILL.md의 작업 절차는 12단계입니다. 줄이면 이런 순서입니다.

1. 프로젝트를 먼저 읽습니다. 프레임워크, 스타일 방식, 기존 토큰을 확인합니다.
2. 기존 화면을 고칠 때는 덜어내기부터 합니다. 같은 정보가 두 곳에 있는지, 같은 행동의 입구가 여럿인지, 색 배지와 옅은 색 상자가 있는지 먼저 봅니다.
3. 순서를 정합니다. 1순위는 하나이고, 넣을 이유를 한 문장으로 말할 수 없는 요소는 뺍니다.
4. 글자·색·면의 톤을 정합니다.
5. 금지선을 확인하고, 카탈로그에서 패턴을 골라 PATTERN.md를 끝까지 읽은 뒤 코드를 복사해 맞춥니다.
6. 검사를 돌리고, 체크리스트를 확인하고, 어떤 패턴을 왜 썼는지 보고합니다.

2단계에는 이런 문장이 있습니다.

값만 고치면 화면은 그대로다.

이 단계는 처음 설계에 없었고, 직접 써본 뒤에 넣었습니다.

구현: 편집 후 검사 훅과 검사 규칙

파일을 고칠 때마다 도는 검사 훅

기준을 문서로만 두지 않고, 에이전트가 파일을 고칠 때마다 검사가 돌게 했습니다. Claude Code에서는 Write·Edit·MultiEdit 뒤에, Codex에서는 apply_patch 뒤에 같은 스크립트가 실행됩니다. 훅 파일 머리의 주석이 동작을 요약합니다.

/**
 * suta 편집 후 검사 훅 — 에이전트가 파일을 고친 직후, 그 파일에 모션·레이아웃 검사를 돌린다.
 *   Claude Code: 플러그인 매니페스트(.claude-plugin/plugin.json)의 PostToolUse(Write·Edit·MultiEdit)
 *   Codex:       플러그인 매니페스트(.codex-plugin/plugin.json)의 PostToolUse(apply_patch) — /hooks에서 승인해야 돈다
 *
 * - 이번 편집이 바꾼 줄만 본다. 파일에 원래 있던 위반은 막지 않는다(기존 프로젝트의 CSS를 고칠 때마다 상관없는 줄로 되돌아오지 않게).
 * - 바꾼 줄에 error가 있으면 종료 코드 2 + stderr. 두 도구 모두 이 내용을 에이전트에게 돌려보내 바로 고치게 한다(편집은 이미 적용됐다).
 * - warn만 있으면 종료 0 + JSON additionalContext. 에이전트가 참고만 한다.
 * - 문제가 없으면 아무것도 출력하지 않는다.
 * - 훅이 실패해도 편집을 막지 않는다. SUTA_HOOK=off, 입력 해석 실패, Node 22.18 미만(.ts를 못 읽음)이면 조용히 종료 0.
 */

error는 종료 코드 2로 에이전트에게 돌려보내 그 자리에서 고치게 합니다. warn은 참고로만 알립니다. 훅이 실패해도 편집은 막지 않습니다. 셸로 파일을 쓰면 훅이 돌지 않기 때문에, 절차 마지막에 통합 검사를 한 번 더 돌립니다.

바꾼 줄만 판정하는 이유

처음 만든 훅은 고친 파일 전체를 판정했습니다. 웹사이트 19곳의 공개 CSS에서 아무 줄이나 하나 고치는 식으로 시험해 보니, 잘 만든 사이트인데도 편집의 59%가 막혔습니다. 파일에 원래 있던 문제 때문이었습니다. 기존 프로젝트에 붙이면 에이전트가 상관없는 줄 때문에 계속 멈춘다는 뜻입니다.

이번 편집이 바꾼 줄만 판정하도록 바꾸자 막는 비율이 0.9%로 줄었습니다. 원래 있던 error는 한 줄로만 알립니다.

규칙 후보도 같은 방식으로 걸렀습니다. 하단 고정 바의 안전 영역, 사진 크기 고정, 본문 14px 미만, 버튼 44px 미만은 잘 만든 사이트에서 오탐이 커서 규칙으로 넣지 않았습니다.

실제 실수에서 나온 검사 규칙

레이아웃 검사 규칙은 26개이고, 모션 검사와 함께 audit.mjs 하나로 돕니다. 몇 가지는 이렇습니다.

상당수는 벤치마크에서 본 실수를 규칙으로 옮긴 것입니다. numbered-markers는 시중 SaaS·서비스 랜딩 42곳 중 3곳만 01·02·03 번호 목록을 썼는데, suta로 만든 랜딩은 6번 모두 그래서 넣었습니다. grid-blowout은 채팅방 화면이 390px 폭에서 413~458px로 넘친 원인을 잡습니다.

색 조합은 palette.mjs가 맡습니다. 강조색 하나를 넣으면 주 버튼 면, 그 위 글자, 강조 글자, 선택 바탕, 무채색을 한 벌로 내줍니다.

node <이 스킬 폴더>/scripts/palette.mjs '<강조색>'

글자 대비 4.5:1은 반올림하지 않고 잽니다. 4.495:1을 통과로 치면 axe는 4.49로 보고 위반으로 잡기 때문입니다.

검사에는 한계가 있습니다. 코드의 값과 색만 봅니다. error와 warn이 0이어도 정보와 행동이 겹치거나 화면 유형의 뼈대와 다르면 끝난 게 아닙니다. 그래서 마지막에 체크리스트와 브라우저 확인을 둡니다.

같은 요청을 비교하는 벤치마크

효과를 확인하려고 벤치마크도 만들었습니다. 같은 요청문을 두 Claude Code에 줍니다. 하나는 아무것도 설치하지 않았고, 다른 하나는 suta 플러그인만 실었습니다. 실행마다 빈 폴더와 새 세션에서 시작하고, 권한 설정도 같습니다.

만든 화면은 Chromium으로 열어 렌더 지표, axe-core 접근성 검사, suta 검사로 잽니다. 마지막으로 어느 쪽인지 가린 두 화면을 판정 모델에게 보여주고 고르게 합니다. 순서를 바꿔 두 번 묻고, 판정 모델도 두 개를 씁니다.

결과: 벤치마크와 실사용 점검

1차 벤치마크: 결함은 줄었지만 판정에서 패배

10월 7일에 첫 벤치마크를 돌렸습니다. 상세·폼·설정·대시보드·랜딩·장바구니·목록·인터랙션, 요청 8개를 조건마다 두 번씩 실행했습니다.

측정한 결함은 거의 사라졌습니다. 그런데 블라인드 판정은 반대였습니다. 32번 중 suta 화면을 고른 횟수가 판정 모델별로 7번과 14번이었습니다. 진 이유로 많이 나온 말은 이랬습니다.

"깔끔하지만 밋밋하다."

제가 봐도 그랬습니다. 깔끔한데, 여전히 AI가 만든 티가 났습니다.

원인을 다시 찾아보니 세 가지였습니다. 본문 자리에 보조 크기 글자를 썼고, 흰 바탕 하나에 선만 남겼고, 기본 파랑 강조색을 주 버튼에만 썼습니다. 장식을 걷어낸 뒤에도 남는 AI 티였습니다. 그래서 글자 색 3단계, 흰 면과 옅은 회색 바탕의 두 단계 면, 강조색을 선택 상태와 링크에 이어 쓰는 기준을 더했습니다. 2차 판정에서 suta를 고른 횟수는 7번에서 11번, 14번에서 19번으로 늘었습니다.

그런데 2차에서는 강조색을 고를 근거가 없는 화면 9개가 모두 짙은 청록을 골랐습니다. 파랑 대신 청록이 새 기본값이 된 겁니다. 그래서 "근거가 없으면 거의 검정"이라는 기준을 더했습니다. 근거 없이 고른 색은 파랑이든 청록이든 기본값으로 보이니까요.

NoodleLens 적용: 숫자만 바뀐 화면

다음으로 제 사이드 프로젝트인 NoodleLens에 suta를 적용했습니다. 크롬 사이드 패널에서 쓰는 AI 채팅 도구입니다. 결과를 보고 남긴 평가는 이랬습니다.

"구조가 난잡하고, 불필요한 색 버튼과 연노랑·주황·쨍한 초록이 남았다."

적용 전후 캡처를 나란히 놓으니 화면이 거의 같았습니다. suta가 바꾼 건 숫자뿐이었습니다. 글자 크기 11종을 4종으로, 모서리 반경 12종을 3종으로 줄이고, 4px 격자 밖 간격 119곳을 고쳤습니다. 위에 고정된 줄 3개, 세 곳에 흩어진 "요소 선택" 입구, 색 토큰 34개는 그대로 남았습니다.

원인은 suta의 절차에 있었습니다. "이미 있는 체계가 우선"이라고 적어 둬서 에이전트는 기존 팔레트와 구조를 그대로 뒀습니다. 검사는 CSS 값만 보는데, error 0·warn 0이 곧 완료 신호가 됐습니다.

그래서 값을 고치기 전에 덜어내는 단계를 절차에 넣고, 색은 무채색과 강조색 하나, 오류 빨강까지로 정했습니다. 옅은 색 바탕과 유채색 개수를 세는 검사 규칙(tinted-surface, hue-count)도 이때 더했습니다.

실사용 화면 점검

이후로는 실제로 만들 법한 화면을 정해 같은 과정을 반복했습니다. 같은 요청을 suta 없이, 그리고 suta로 만든 뒤 차이를 보고 suta를 고쳐 다시 돌렸습니다.

고친 뒤 이커머스 화면의 접근성 위반은 suta 없이 만든 쪽이 색 대비 111곳, suta 쪽이 실행마다 0~2곳이었습니다. 증권 화면은 판정 모델 두 개가 28번 중 23번과 24번 suta를 골랐고, 걷기 리워드는 두 모델 모두 24번 중 20번이었습니다.

판정 모델과 의견이 갈린 설정 화면

비교 이미지를 다시 보니 설정 화면과 SaaS 랜딩은 여전히 AI slop 같았습니다. 그래서 레퍼런스 앱의 설정류 화면 161장을 다시 기록하고, 시중 SaaS·서비스 42곳의 랜딩을 끝까지 찍어 쟀습니다. 설정은 30곳 중 26곳이 폭 가득한 흰 목록이었고, 켜진 스위치는 18곳 중 16곳이 강조색이었습니다. 랜딩은 구역이 중앙값 10개였고, 01·02·03 번호 목록은 3곳뿐이었습니다.

랜딩은 이 기준으로 고친 뒤 6쌍을 모두 이겼습니다. 설정은 달랐습니다. 판정 모델은 두 차례 모두 옅은 바탕 위 둥근 카드 묶음과 테마 세그먼트가 있는 이전 버전을 골랐습니다. 레퍼런스 앱 대부분과 반대이고, 이번 작업이 걷어내려던 틀입니다. 그래서 설정은 판정을 따라 되돌리지 않았습니다. 판정 모델의 취향이 AI가 흔히 만드는 틀 쪽으로 기울어 있었던 겁니다.

suta README 맨 위에 둔 비교입니다. 같은 요청·모델·설정으로 왼쪽은 suta 없이, 오른쪽은 suta 0.14로 만들었고, 조건마다 두 번 실행한 것 중 첫 번째입니다. 이 네 요청의 블라인드 판정은 16번 중 9번과 7번으로 우열이 없었습니다. 설정은 여기서도 4번 모두 졌습니다.

앱 화면: 비어 있던 콘텐츠 자리

앱 화면만 모은 요청 8개에서는 suta 0.14가 크게 졌습니다. 판정 모델별로 16번 중 4번과 3번만 suta를 골랐습니다. 사진 자리를 회색 칸과 사진 아이콘으로 비웠고, 요청한 요소를 빼먹었기 때문입니다.

레퍼런스 앱 화면 194장을 유형별로 다시 기록하고, 시중 앱 16곳의 앱 마켓 스크린샷을 봤습니다. 잘 만든 앱은 UI를 무채색에 가깝게 두지만, 색과 밀도는 사진·배너·분류 그림·로고 같은 콘텐츠가 맡았습니다. 앱 홈 34장 중 29장은 첫 화면의 10% 이상이 사진이나 그림이었습니다.

suta는 장식을 덜어내다가 콘텐츠 자리까지 비우고 있었던 겁니다. 그래서 사진이 없을 때 그 자리를 채우는 콘텐츠 그림과, 분류 바로가기 같은 큰 칸에만 쓰는 그림 아이콘 57개를 더했습니다.

그 뒤로 다섯 차례 다시 돌렸습니다. 중간에 제가 남긴 말은 이랬습니다.

"메인 말고는 AS-IS가 더 앱 같다."

"달라진 게 없어 보인다."

3차에서는 목록 행까지 그림 아이콘을 썼다가 판정 모델이 "이모지풍"으로 읽어서 큰 칸으로 좁혔습니다. 5차까지 판정은 32번 중 15번 안팎에 머물렀습니다. 6차에서는 채팅방의 렌더 결함 두 개를 검사 규칙(grid-blowout, hidden-text-escape)으로 잡고, 판정이 짚은 세부를 화면 관례에 넣었습니다. 최종 판정은 32번 중 19번과 20번이었습니다.

위는 suta 없이, 아래는 suta 0.15로 만든 390×844 첫 화면입니다. 표는 조건마다 16번 실행한 전체 측정값입니다.

숙소 상세와 온보딩은 여전히 졌습니다. 숙소는 대표 사진 대역이 "도형 플레이스홀더"로 읽혔고, 온보딩은 판정 모델이 늘어나는 알약형 페이지 점을 골랐습니다. 레퍼런스의 페이지 점은 모두 같은 크기의 원이어서 원을 유지했습니다.

남은 한계

결과를 읽을 때 주의할 점도 있습니다.

• 실험마다 조건당 1~4번만 실행했습니다. 같은 요청도 실행마다 결과가 달라집니다.
• 판정 모델 하나는 화면을 만든 모델과 같고, 정지 화면만 봤습니다. 사람 디자이너의 평가는 하지 않았습니다.
• 기준값은 국내 앱 31곳과 웹사이트 19곳에서 뽑았습니다. 다른 나라 서비스의 관례와는 다를 수 있습니다.
• 에이전트가 읽는 양이 늘어 시간과 비용이 늘어납니다. README의 비교에서는 생성 시간이 약 세 배였습니다.
• 정적 검사로 모든 UI 문제를 찾을 수는 없어서, 브라우저에서도 확인해야 합니다.

마치며

suta는 지금 0.15이고, 패턴 57종과 테스트 713개가 있습니다. Claude Code에서는 대화창에 이렇게 입력합니다.

/plugin marketplace add Guksu/suta
/plugin install suta@suta

Codex는 터미널에서 설치한 뒤 /hooks에서 suta의 편집 후 검사를 승인합니다.

codex plugin marketplace add Guksu/suta
codex plugin add suta@suta

다른 에이전트에서는 npx skills add Guksu/suta --skill suta로 기준과 패턴만 설치할 수 있습니다. 이 경우 편집 후 검사는 포함되지 않습니다.

AI에게 화면을 맡겼는데 어딘가 익숙한 결과가 나온다면, 값을 고치기 전에 화면에 있는 요소를 모두 적어보길 권합니다. 같은 정보가 두 곳에 있는지, 같은 행동의 버튼이 몇 개인지, 유채색이 몇 가지인지만 세어봐도 덜어낼 곳이 꽤 보일 겁니다.

저도 직접 쓰면서 부족한 부분을 계속 고치고 있습니다. 써보시고 이상한 화면이 나오면 이슈로 알려주시면 반영하겠습니다.

다음 글에서는 코드 리뷰와 테스트에서 AI 티를 덜어내는 gimi(기미)를 다룹니다.

• 저장소: github.com/Guksu/suta
• 라이브 데모: guksu.github.io/suta
• 실험 방법과 전체 결과: 화면 비교 문서