프리뷰 산문이 services/*.md가 뒷받침하지 않는 주장을 하는지 사람이 대조하는\n작업이 2026-08-04 ~ 08-17 에 걸쳐 이어졌다. 그 판정에는\n근거 등급이 있고, 낮은 등급을 근거로 쓰면 프리뷰를 망가뜨린다.
상류를 확인하는 법: DesignSync MCP(list_projects → list_files →\nget_file)로 슬러그별 Claude Design 프로젝트를 읽는다. 거의 모든 카탈로그 항목에\n대응 프로젝트가 있다.
다만 번들이 상류인 것은 md가 번들에서 나왔을 때뿐이다. md가 브랜드 발행물(공개 문서·\n오픈소스 저장소·npm 패키지)에서 직접 만들어졌다면 그것들이 상류이고 번들은 형제다 —\n같은 출처에서 갈라진 또 하나의 재구성물이라 md를 뒤엎을 권위가 없다. md의 ## References 를\n먼저 보라: 번들을 가리키지 않고 공개 URL만 열거하면 이 경우다.
/design-md 스킬이 처음부터 만든 항목은 또 다르다 — 스킬은 승인된 md를 프리뷰 저자에게 넘겨\n프리뷰를 md에서 만든다. 그 항목에서 확인할 곳은 번들이 아니라 md와 md가 인용한 출처다.
이 문서는 산문이 참인가만 다룬다. 중복인가는 다른 자리에 있다. 한 문장이\n참이면서 불필요할 수 있고(md 가 이미 같은 말을 한다), 필요하면서 거짓일 수도 있다 —\n한쪽 판정이 다른 쪽을 대신하지 못한다. 중복 축은\n.claude/skills/design-md/references/rubric-preview.md 의 ## Explanatory prose 가\nadvisory 로 다룬다(warn 만 내고 10점 총점은 건드리지 않는다). 그 절의 질문은 하나다 —\n\"이 말을 design.md 가 할 수 있는가?\"
할 수 있으면 같은 페이지의 다른 탭이 이미 그 값을 싣고 있으니 뺀다. 다만 세 탭은\n배타적이다 — Live Preview · Tokens · DESIGN.md 가 서로를 가리므로\n(src/routes/services/$slug.tsx:212-216 의 탭, :248-271 의 패널 셋), 프리뷰를 보는\n사람에게 그 값은 같은 화면이 아니라 탭 하나 거리에 있다. 그래서 중복 판정의 근거는\n\"한 화면에 세 번\"이 아니라 \"프리뷰의 일은 설명이 아니라 시연\" 이다. 이 차이를 넘겨\n짚지 말 것 — 넘겨 짚으면 화면에만 있는 문장까지 지우게 된다.
못 하면 남긴다 — md 에는 화면이 없어서, 시연을 어떻게 띄우는지 · 빌려 온 값 ·\n한 마디 없으면 결함으로 읽히는 반응형 거동 · 토큰에서 벗어난 자리 · 시연 자체의\n접근성 단서는 갈 곳이 없다.
\n리멤버가 렌더 텍스트의 61% 가 설명인 채 10/10 을 받은 것이 그 축이 없던 시절의\n결과다(이슈 #396). 여기서 \"참이다\" 를 확인했다고 그 문장이 남을 자격을 얻는 것은\n아니다.
\n| 슬러그 | \n상태 | \n
|---|---|
seed-design | \n번들 없음 — 브랜드 발행물(공개 문서·npm 패키지)에서 직접 만들었다 | \n
class101 | \n번들 있으나 상류 아님 — 번들 README가 스스로를 \"a faithful recreation of CLASS101's open-source Vibrant Design System\" 이라 적고, 출처로 크롤 코퍼스 58쪽 · vibrant-design.com · github.com/pedaling/opensource(MIT)를 든다. md도 같은 공개 출처 48개를 인용 190개로 쓴다 — 둘이 형제다. 판정은 브랜드 발행물(공개 문서·오픈소스 코드)로 한다 | \n
vapor-ui | \n번들에서 만들었으나 전량 뒤집혔다 — md 머리말이 번들을 1차 출처로 밝혔지만 References 5개는 전부 공개(vapor-ui.goorm.io · goorm 블로그 · Figma Community · npm · 공개 저장소 goorm-dev/vapor-ui). 번들값이 공개 발행값과 크게 어긋나 토큰 절과 컴포넌트 절을 차례로 교체했다 — ## Colors 110개(2026-07-29), 그리고 ## Typography · ## Spacing · ## Rounded · ## Elevation & Depth · ## Components(2026-08-17, 이슈 292번). 판정은 npm @vapor-ui/core 1.3.0 배포본과 문서 사이트가 서빙하는 CSS 청크 둘로 하며, 이 둘이 서로를 확인해 준다. 문서 사이트의 props 표는 지연 로드라 수치 출처로 쓸 수 없다 | \n
| wanted | 번들 있고 상류가 맞으나 항목에 따라 진다 — md 가 번들이 아니라 브랜드 발행물(몽타주 문서)을 대조한 블록이 있고, 그 자리에서는 번들 README 가 브랜드 발행값과 어긋난다. 아래 타입 스타일 수 사례 |
이 표는 발견되는 대로 늘어난다 — 새 슬러그를 감사하기 전에 md의 ## References 를 먼저\n확인하고, 번들이 상류가 아니면 여기에 적을 것.
DesignSync를 못 쓰면 판정하지 말 것. 이 규칙은 상류 확인을 요구하는데 그 MCP는\n모두에게 열려 있지 않다. 대안 경로는 두 가지다 — 슬러그의 크롤 캐시\n(.claude/cache/design-md/<slug>/, gitignore됨)와 브랜드 발행물.\n셋 다 없으면 결함으로 올리지 말고 유보로 남긴다 — 상류를 열어 볼 수 없었다고 적는다. 확인할 수 없는 것을\n\"md에 없으니 결함\"으로 처리하는 것이 바로 이 절이 막으려는 오류다.
상류가 프리뷰를 뒷받침하는데 md가 비어 있으면 고칠 것은 프리뷰가 아니라 md다.
\n다만 상류가 늘 이기는 건 아니다. 이 규칙이 상류를 앞세우는 이유는 md가 번들의\n손실 전사이기 때문이다 — 그 관계가 성립하지 않으면 적용되지 않는다. 번들도\n재구성물이라 브랜드 발행물과 어긋날 수 있다. 상류를 확인했는데 md와 다르면 어느\n쪽이 브랜드 발행물에 더 가까운가로 가른다.
\n단, 그 판단은 브랜드 발행물을 직접 열어서 한다. md가 \"브랜드 발행물과 대조했다\"고\n적어 둔 것만으로는 부족하다 — 그건 md의 자기 서술이고, 루트 문서(CLAUDE.md)의\n「인용은 존재가 아니라 내용 일치」 원칙이 바로 그것을 검사 대상으로 삼는다.\nmd의 주장을 근거로 md를 신뢰하면 순환이다. 인용된 URL을 열어 값을 세어 보고,\n확인하지 못하면 어느 쪽이 맞다고도 정하지 말고 유보한다.
\n\n사례 (wanted 타입 스타일 수). 번들 README는
\n18, md는19로 적는다.\n[src:5](몽타주 공식 타이포그래피 문서)를 직접 열어 세었더니 19개였고 md의\n표와 이름까지 일치했다. 즉 번들 README가 브랜드 발행물과 어긋난 경우이고,\n\"상류 우선\"만 기계적으로 적용하면 브랜드 공식값을 버리고 번들값으로 되돌리게 된다.\n공식 표가 싣는 19개는 Display 1·2·3 / Title 1·2·3 / Heading 1·2 / Headline 1·2 /\nBody 1·2 × Normal·Reading / Label 1 × Normal·Reading · Label 2 / Caption 1·2 다\n(montage.wanted.co.kr/docs/foundations/base-material/typography).\nmd 가 번들이 아니라 브랜드 발행물을 대조한 자리라 손실 전사 관계가 성립하지\n않고, 그래서 \"상류 우선\" 도 적용되지 않는다. md:322가 숫자만 적지 않고\n\"공식 타입 스케일 19행과 대응하며 57개 값 중 56개가 일치한다\" 고 밝힌 것이 단서였다 —\n그래도 자기 서술만으로는 부족해[src:5]를 직접 열어 세었다.
\n\n이 규칙은 사고 후에 생겼다. 2026-08-06 전수 조사에서 착지한 산문 정정\n84건 중 33건만 정당했다. 나머지 50건을 반증 검증에 걸어 30건이 감사 오탐으로\n확증, 19건 기각, 1건 유보가 나왔다. 집행하면서 확증은 31로 움직였다 —\n기각 판정도 부재 주장에 기대면 확증과 똑같이 틀리기 때문이다.\n대표 사례: kyobobook의
\nState — hover를 \"md에 hover가 0건\"이라며pressed로\n바꿨는데 번들에<span>Hover</span>와.primary.hover{background:blue-800}이\n그대로 있었다. greeting은Drawer카드를Side panel로 개명했는데 번들에\nDrawer.jsx·drawer.card.html·Drawer.prompt.md가 있다.봇 리뷰 3~4라운드가 이 오류를 전부 통과시켰다 — 리뷰어도 md만 근거로 삼아\n같은 전제를 공유했기 때문이다. 같은 전제를 공유한 검증은 그 전제를 검사하지\n못한다. 값을 고치는 것보다 이름을 바꾸는 정정이 더 위험하다 — 값은 틀리면\n눈에 띄지만 이름은 굳어져 다음 감사가 그 이름을 기준으로 삼는다.
\n
확증된 감사 오탐을 되돌렸고(bezier · toss · socar · 11st · greeting · wanted ·\ngmarket · vapor-ui), 기각 19건도 사유 전문으로 재검토했으며, 상류를 열어 보지 못해 유보로 남았던\n2건도 해소했다. 열려 있는 건은 없다.
\n다만 확증된 감사 오탐이 전부 되돌려진 것은 아니다. greeting 의 Doodlin 워드마크 카드 1건은\n확증된 감사 오탐인데도 되살리지 않고 종결했다 — 빈 카드 제거로 이미 걷혔고, 복원하려면 프리뷰를\n자체 완결로 만들면서 싣지 않기로 한 브랜드 PNG 자산이 필요하기 때문이다. 아래 넷째 규칙의\n실례이고, 판정의 수와 집행의 수를 섞지 말 것. 자산 정책이 바뀌어 되살리게 되면 그 카드를\n두 차례 고친 문구를 따로 되돌리지 말고 상류 카드를 처음부터 다시 옮길 것.
\n진행 상황을 슬러그별로 들고 있던 대장 문서는 그래서 지웠다 — 건별 판정 근거와 되돌린\n문구 전문은 git 히스토리와 그 PR 들에 남는다. 여기에 슬러그 목록이나 PR 번호를 다시\n적지 말 것. 대장을 따로 둔 이유가 그것이었고, 대장이 스스로 경고했듯 문서에 적힌\n상태는 늘 낡는다.
\n그 캠페인이 남긴 판정 규칙 넷은 다음 감사에도 그대로 적용된다.
\nscrim 40%\n는 번들이 뒷받침해 감사 오탐이지만 다크의 55% 는 근거가 없어 정당한 정정이었다.\n양 테마를 같은 값으로 되돌리지 말 것.