AI 슬롭 지문 — 노드 값으로 세는 패턴

작업규칙(L0/L1/L2)을 다 지키고 마감 판정(figma-quality-rubric.md)까지 통과해도, 화면이 어느 서비스에 넣어도 어색하지 않은 모습으로 나올 수 있다. 아무도 고르지 않은 선택이 평균값으로 채워진 흔적이다. 이 문서는 그 흔적 중 노드 값으로 셀 수 있는 것만 모은다. 셀 수 없는 것 — 이 서비스여야 하는 화면인가, 지워도 되는 요소인가 — 는 cc-designer:critique-screen 의 고유성·절제 렌즈가 본다. 감상을 게이트에 섞지 않는다(design-self-check 「품질 판단 라우팅」).

• 측정: references/recipes/slop-scan.figma.js 가 후보를 뽑는다. 경계값(크기·두께·면적 상한·문구 목록)의 유일한 정의는 그 파일 상단 상수다 — 이 문서에 사본을 두지 않는다.
• 등급: 정본은 figma-workflow.md §4 다. 판정은 design-self-check 11번이 한다.
• 출처: 항목 일부는 hallmark(MIT)의 slop-test 게이트를 앱 화면·한국어 맥락으로 옮긴 것이다. 랜딩페이지에만 맞는 항목(히어로 모양 · 사이트 내비·푸터 형태 · 결과마다 골격 바꾸기)은 앱 화면에 맞지 않아 옮기지 않았다 — 앱 안에서는 화면끼리 같은 골격이 일관성이다.

• 지문은 오류가 아니라 흔적이다. 하나만으로 화면이 틀렸다는 뜻은 아니지만, 한 화면에 둘 이상 모이면 그 화면은 평균값으로 그려졌을 가능성이 높다. 그래서 등급은 L1(사유 기록 시 통과) 또는 L2 다. 사유는 "이 서비스에서는 왜 이게 맞는가" 한 줄이다 (예: 카테고리 바로가기는 같은 크기 칸이 맞다). 사유를 쓰다 막히면 그 선택은 고른 것이 아니라 남은 것이다.
• 누가 놓은 것만 세는가: 경계·선을 보는 항목(§S1·§S3)은 저작자가 놓은 것 — 직접 만든 프레임, 슬롯에 넣은 내용, 오버라이드 — 만 센다. 라이브러리 컴포넌트 안쪽에 원래 있는 설계(인스턴스의 main component 에 같은 이름 경로가 있는 노드)는 컴포넌트의 몫이라 세지 않는다. 글자를 보는 항목(§S5–§S11)은 인스턴스 안 글자도 센다 — 글자는 저작자가 넣은 값이다.
• 범위: 레지스트리에 등재된 섹션의 화면 프레임(figma-workflow §1). 숨긴 노드는 세지 않는다.

• 규칙 — 경계를 가진 면(네 변 외곽선, 또는 바로 뒤 바탕과 다른 채움. 버튼·입력·칩보다 큰 것) 안에 또 경계를 가진 면을 두지 않는다. 담는 층은 하나다.
• 왜 — 경계가 겹치면 위계가 아니라 상자만 늘어난다. 바깥 면이 이미 묶은 것을 안쪽 면이 다시 묶으면 어느 쪽이 한 덩어리인지 읽히지 않는다. figma-composition-patterns.md §C9 ③(선과 면 대비 중 하나만)을 층 단위로 적용한 것이다.
• 확인 — 레시피 nested. 여러 줄 입력처럼 큰 입력 칸이 걸리면 판단.
• 고치는 법 — 대개 바깥 면이 불필요하다. 바깥 면의 외곽선·채움을 끄고 간격(space/*)으로 묶거나, 안쪽 면을 행·구분선으로 바꾼다.

• 규칙 — 한 줄에 같은 폭의 칸 셋 이상이 [아이콘 → 제목 → 본문] 구성을 되풀이하면 지문이다. 아이콘과 짧은 라벨만 있는 바로가기(카테고리·메뉴)는 해당하지 않는다.
• 왜 — 기능·혜택을 같은 크기 세 칸에 나눠 담는 구성은 생성 결과가 가장 먼저 내는 기본값이다. 내용의 중요도가 다르면 크기도 달라야 하고, 중요도가 같다면 대개 목록이 더 잘 읽힌다.
• 확인 — 레시피 tiles. 바로가기·필터처럼 같은 무게가 맞는 경우는 판단 + 사유 한 줄.

• 규칙 — 카드·행의 한 변에만 굵은 선을 두거나 가장자리에 좁은 색 막대를 붙여 상태·분류를 표시하지 않는다.
• 왜 — 의미를 색 띠 하나에 실으면 색을 구별하기 어려운 사용자에게 사라진다(상태 구분은 단서 둘 이상 — composition-patterns §C3 ④). 띠 자체도 흔한 템플릿 표시다.
• 확인 — 레시피 stripes.
• 고치는 법 — 상태는 Badge · 아이콘 · 라벨로, 분류는 그룹 제목으로.

• 규칙 — 강조색(color/primary 에 묶인 채움)이 프레임 면적에서 차지하는 비율이 상한을 넘지 않는다. 상한은 브리프의 '강조 면적' 칸 (figma-brand-selection.md §1)이 정하고, 그 칸이 기본이거나 비었으면 레시피 기본값이다. 화면을 그린 뒤 상한을 고치지 않는다(같은 절).
• 왜 — 강조색이 넓게 깔리면 강조가 아니라 배경이 된다. 주 행동 하나에 써야 할 신호가 화면 전체로 흩어진다. quality-rubric D4 는 강조가 있는지를 보고, 이 항목은 넘치는지를 본다.
• 확인 — 레시피 accent.ratio · accent.over. 글자색과 container 틴트(primary-container)는 세지 않는다.

• 규칙 — 글자 안에 그림 문자(이모지 · 딩뱃 기호)를 넣지 않는다. 아이콘이 필요하면 라이브러리 Icon 인스턴스를 쓴다.
• 왜 — 그림 문자는 플랫폼마다 다르게 그려져 같은 화면이 기기마다 달라지고, 아이콘 체계(크기 · 획 · 색 토큰) 밖에 있다. 기능 아이콘 자리를 이모지로 채우는 것은 생성 결과의 대표 흔적이다.
• 확인 — 레시피 emoji.

• 규칙 — 흔한 가명(홍길동 · 김철수 · John Doe 류)과 더미 문구(Lorem ipsum · 테스트 · Acme 류), 부품 기본 문구(제목 · 내용 · Label · Button 류)를 화면에 남기지 않는다. 스펙 문구에 붙은 저작 메모(그 문구 자체의 지위를 말하는 말 — — 데모 문구 · (가안) · 문구 미정 류)도 화면에 옮기지 않는다 — 메모를 뺀 문구를 그린다. 판정과 처리는 composition-patterns §C10 ①. 샘플을 채우는 법은 composition-patterns §C10.
• 왜 — 더미 값은 검토자가 그 자리의 실제 데이터를 떠올리지 못하게 한다. 실제 이름과 제목은 길이가 제각각이고, 그 차이가 레이아웃을 시험한다. 저작 메모는 스펙을 쓴 사람이 팀에게 한 말이라, 화면에 남으면 제품 문구로 읽히고 시안을 본 사람은 그 문구가 확정된 것으로 기억한다.
• 확인 — 레시피 placeholder(목록은 레시피 상수). 도메인 용어와 겹치면(시험 서비스의 '테스트' 같은) 판단. 레시피 memo — 저작 메모 후보. 오탐을 줄이려고 보수적으로 센다: 문구에 대한 말임이 분명한 구(데모 문구 · 문구 미정 · copy TBD 류)는 어디서든, 낱말 하나(가안 · 예시 · 임시 · 미정 · TBD)는 괄호 안에 그것만 있거나 줄 끝 대시 뒤에 그것만 있을 때만 센다. 그래서 입력 예시: 010-… · 임시 비밀번호 · 체험용 데모 · 할 일 앱의 TODO 는 걸리지 않는다. 사용자에게 하는 고지가 걸리면(스펙이 화면에 보이라고 한 말) 판단 이고 사유는 그 스펙 문장이다. 파이프라인 표지 '수치 확인 필요'(composition-patterns §C10 ③)는 메모가 아니라 세지 않는다.

• 규칙 — 비율(%) · 배수 · 증감(+N · ▲▼) · 평점 · 누적 이용자 같은 지표 수치는 스펙 수치 체크리스트(design.md Step 1)에 있는 것만 쓴다. 자리가 꼭 필요한데 값이 없으면 — 와 '수치 확인 필요'를 쓴다. 가격 · 시각 · 개수 같은 샘플 데이터 값은 이 항목이 아니라 composition-patterns §C10 이 다룬다.
• 왜 — 시안의 숫자는 본 사람이 사실로 기억한다. 지어낸 '+23%' 는 기획 문서로 역류하고, 실제 값이 나왔을 때 화면은 이미 그 숫자에 맞춰져 있다.
• 확인 — 레시피 metric 이 지표 모양의 글자를 뽑고, self-check 가 스펙 수치 체크리스트와 대조한다. 체크리스트에 있는 값이면 위반이 아니다.

• 규칙 — '을(를)' · '이(가)' · '은(는)' · '(으)로' 같은 병기를 화면에 남기지 않는다. 시안의 값은 하나로 정해져 있으므로 조사도 하나로 정한다.
• 왜 — 병기는 템플릿을 채우다 만 흔적으로 읽힌다. 실제 앱의 조사 처리는 번역 키의 일이지 시안의 일이 아니다.
• 확인 — 레시피 particle.

• 규칙 — 한 화면의 안내문 · 버튼 문구는 높임 수준이 하나다(해요체 · 합쇼체끼리, 해라체 · 반말끼리).
• 왜 — 한 화면 안에서 말투가 바뀌면 여러 출처에서 문구를 모아 붙인 화면으로 읽힌다. 생성된 문구에서 자주 생긴다.
• 확인 — 레시피 politeness. 문장으로 끝나는 글자만 보고(라벨 · 명사형은 세지 않는다) 어미로만 가르므로 늘 판단.

• 규칙 — 한 글자 노드 안에서 값이나 구절을 기호로 이어 붙여 구분하지 않는다. 대상은 대시(— –), 양옆을 띄어 쓴 붙임표(-), 가운뎃점(· •)이다(글자 목록의 정의는 레시피 상수). 구분은 화면 구조로 한다 — 자리를 나누고 간격(space/*)이나 Divider 를 두거나, 줄을 바꾸거나, 문장으로 쓴다. 레이어 · 섹션 · 프레임 이름은 대상이 아니다.
• 왜 — '제목 — 부제', '3분 전 · 조회 120' 처럼 기호로 이어 붙이는 것은 생성된 문구가 가장 먼저 내는 구분 방식이라, 고른 문구가 아니라 채워진 문구로 읽힌다. 한 노드에 붙인 값들은 줄임과 정렬을 따로 줄 수 없어서, 값 하나가 길어지면 나머지도 함께 잘린다.
• 확인 — 레시피 separator(줄마다 본다).
  • 세지 않는 것 — 바로 옆 글자가 양쪽 다 숫자인 범위 대시(10–20 · 09:00 - 18:00 · 날짜 · 전화번호)와 붙여 쓴 숫자 사이 가운뎃점(3·1), 줄 맨 앞 · 맨 뒤의 기호(줄머리 기호 · 값이 없는 자리의 — — §S7), 한쪽에만 붙은 대시(전환율 —%), 띄어 쓰지 않은 붙임표(A-12), 셋 이상 이어진 기호(가림 •••• · 줄임 ···).
  • 걸리지만 판단 인 것 — 단위 · 통화 · 요일이 낀 범위(9시 – 18시 · 월–금), 띄어 쓴 빼기 부호(할인 - 3,000원), 값 자리를 비운 — 가 라벨과 띄어 한 노드에 든 것(총 — 건), 맞춤법상 붙여 쓴 열거(가전·디지털 · 초·중·고), 고유명사 · 인용문, 부품이 고정으로 싣는 문구.
  • 위반이 아닌 것 — 스펙이 준 문구와 같은 글자(판정법은 design-self-check 11번). 스펙이 준 문구는 저작 메모를 뺀 글자다(§S6) — 메모를 이은 대시는 문구가 아니므로 이 예외에 들지 않는다.
  • 레시피가 놓치는 것 — 양쪽이 숫자로 맞닿은 붙임표 · 엔 대시는 구분이어도 범위로 보고 세지 않는다(조회 120 - 3분 전).
• 고치는 법 — 먼저 그 자리에 값이 둘 다 필요한지 본다. 하나면 하나만 남긴다.
  • 저작자 소유 글자(직접 만든 프레임 · 슬롯에 넣은 내용 · 도메인 컴포넌트) — 값마다 글자 노드를 나누고 간격으로 띄운다. 제목과 부제는 줄을 나누고 텍스트 스타일로 위계를 준다. 나열은 행을 나누거나 문장으로 쓴다.
  • 라이브러리 인스턴스 안 글자 — 노드를 늘리거나 옆에 덧댈 수 없다(coui-library-consumption.md §2 · §7). 값을 부품의 다른 자리(다른 TEXT property · 슬롯에 넣는 인스턴스)로 옮기거나, 같은 글자 안에서 줄을 바꾸거나, 문장으로 쓴다. 자리가 없으면 떼거나 흉내 내지 않고 consumption §8 로 처리한다.
  • 부품이 고정으로 싣는 문구(바꿀 property 가 없는 글자) — 소비 파일에서 고치지 않는다. 판단 으로 남기고 사유에 상류 이슈(consumption §6)를 적는다.
  • | 나 / 같은 다른 기호로 바꾸는 것은 고친 것이 아니다 — 레시피가 세지 않을 뿐 같은 지문이다. 범위는 물결표로 쓰면 걸리지 않는다(월~금).

• 규칙 — 한글이 든 글자가 줄을 넘기면 어절 경계(띄어쓰기 자리)에서 꺾는다. Figma 는 한글을 음절 사이에서 꺾으므로 두면 …회복 스트레/칭 처럼 한 낱말이 두 줄로 찢어진다 — 줄바꿈 자리는 저작이 정한다. ① 어절 경계의 띄어쓰기를 줄바꿈 문자 U+2028(LINE SEPARATOR — Figma 의 Shift+Enter)로 바꾼다. keep-all.figma.js 가 같은 폭 · 같은 글꼴로 어절 누적 폭을 재서 넘치는 어절 앞에 넣는다(CSS word-break: keep-all 흉내). 글자와 폭이 다 정해진 뒤 돌리고, 그 뒤에 글자나 폭이 바뀌면 다시 돌린다. ② 또는 레이아웃(폭) · 샘플 값을 바꾼다. 긴 값을 일부러 넣었으면(composition-patterns §C10 ②) 값은 두고 ① 로 자리를 정한다 — 긴 값은 넘치는 줄을 보려고 넣은 것이다. ③ 손으로 정하는 줄 나눔(문장 · 구 경계 — composition-patterns §C3 ①)은 LF(Enter)로 넣는다. U+2028 은 레시피가 넣고 되돌리는 문자라(rewrap · unwrap) 손으로 넣은 것도 띄어쓰기로 돌아갈 수 있고, LF 는 레시피가 늘 지킨다. 한 어절이 한 줄보다 길면 어절 안에서 꺾일 수밖에 없다 — 레시피는 그 어절을 그대로 두고 알려 준다(tooLong). 폭이나 값을 바꿀지는 저작이 정한다.
• 코드 쪽 — CoUI 의 Text 체인은 .keepAll 로 같은 자리에서 꺾는다(Web 은 CSS word-break: keep-all, Flutter 는 같은 판정으로 만든 표시 문자열 — CoUI 이슈 — 한국어 어절 단위 줄바꿈). 옵트인이라 켠 글자에만 닿는다. 그래서 시안에서 어절 경계로 꺾은 한글 글자는 코드에서 .keepAll 을 단다(/cc-blueprint:build). 시안에 넣은 U+2028 은 글자 데이터가 아니라 Figma 조판 보정이므로 코드 문자열로 옮기지 않는다 — 코드의 줄바꿈 자리는 .keepAll 이 정한다.
• 캔버스의 줄바꿈은 남는다 — Figma 텍스트 노드에는 줄바꿈 방식 옵션이 없어서, 코드가 어절 단위로 꺾어도 캔버스는 여전히 음절 사이에서 꺾는다. 시안의 U+2028 은 만료되지 않는다 — 글자나 폭이 바뀌면 레시피를 MODE = 'rewrap' 으로 다시 돌린다.
• 왜 — 한국어 UI 조판의 관례는 어절 단위 줄바꿈이다. 음절 사이에서 꺾으면 한 낱말이 두 줄로 찢어져 읽기가 끊긴다. 실제로 블라인드 평가에서 긴 수업명이 스트레/칭 으로 꺾인 것이 결함으로 짚혔다. 같은 화면의 크리틱도 그것을 잡았지만 "코드에서 할 일"로 적고 지나갔다 — 코드는 .keepAll 을 단 글자만 어절 단위로 꺾으므로, 시안이 자리를 정하고 build 가 그 글자에 .keepAll 을 달지 않으면 아무도 정하지 않는다.
• 확인 — 레시피 wrap(slop-scan): 한글이 든 글자의 높이로 센 줄 수(높이 ÷ 줄 높이)가 직접 넣은 줄바꿈으로 나뉜 줄 수보다 많으면 — Figma 가 스스로 꺾었으면 — 후보다. 후보일 뿐이고 판정은 사람이 본다 — 어디서 꺾였는지는 노드 값에 없어서, 띄어쓰기 자리에서 우연히 꺾인 글자도 후보로 나온다(판정법은 design-self-check 11번). 줄 높이를 알 수 없는 글자(범위마다 스타일이 다름 · 줄 높이 자동 · 위아래 여백 자르기 · 고정 상자)는 세지 않고 wrap.skipped 로 돌려준다.
• 고치는 법 — 그 페이지에 keep-all 레시피를 돌리고 다시 잰다. 남는 후보는 레시피가 건너뛴 노드다(범위마다 스타일이 다른 글자 · 한 줄보다 긴 어절) — 스크린샷으로 줄 끝을 보고, 어절 중간이면 손으로 U+2028 을 넣거나 값 · 폭을 바꾼다.

• 화면 골격 반복(모든 화면이 같은 구성) — 노드로 세면 같은 앱 안의 공통 셸(§C4)까지 걸린다. 다른 서비스와 같은 골격인지는 고유성 렌즈(cc-designer:critique-specificity)가 보고, 같은 조직의 다른 제품과 같은 축인지는 다양성 장부(figma-direction.md §D4)가 본다.
• 목적 없는 장식 · 축하 토스트 · 되돌릴 수 있는 동작의 확인 창 — 노드 값으로는 '목적'과 '되돌릴 수 있음'을 알 수 없다. 절제 렌즈(cc-designer:critique-restraint)가 본다.

새 항목은 노드 값으로 셀 수 있을 때만 더한다. 셀 수 없으면 크리틱 렌즈의 일이다 — 이 문서에 넣으면 판정이 재현되지 않는다.