AI 티 안 나는 사내 홈페이지, 브랜드 규칙을 어디까지 직접 정해야 할까?

📌 오늘의 안건
AI 티 안 나는 사내 홈페이지, 브랜드 규칙을 어디까지 직접 정해야 할까?

프론트엔드 개발자로서 클로드를 써서 사내 IP(캐릭터/자체 자산) 기반의 외부 노출용 홈페이지를 만들고 있습니다. 문제는 결과물의 비주얼 톤이 템플릿처럼 보인다는 점입니다. 색·타이포·간격 같은 기본 요소가 어디서 본 듯한 AI 기본값 느낌이라, 화면은 멀쩡한데 브랜드가 안 느껴집니다.

해결 방향은 정했습니다. 화면을 그때그때 고치는 대신, 자체 컬러·폰트 등 브랜드 규칙을 먼저 정의하고 그걸 AI에게 강제하는 방식으로 가려고 합니다. 다만 현재 가진 자산은 로고 하나뿐이고, 나머지 규칙은 제가 직접 정해야 하는 상황입니다. 디자이너 없이 개발자가 브랜드 규칙을 만드는 셈이라 어디서부터 어디까지 정해야 할지가 막막합니다.

묻고 싶은 건 이겁니다. 로고만 있는 상태에서 AI 티를 지우려면 브랜드 규칙을 어느 수준까지 직접 정의해야 충분한가요? 예를 들어 (1) 로고에서 뽑은 컬러 팔레트와 본문/제목 폰트 조합 정도만 정하고 나머지는 AI에 맡기는 방식, (2) 여기에 간격 스케일·라운딩·그림자·모션까지 포함한 디자인 토큰 세트를 만들어 코드로 고정하는 방식, (3) 아예 톤앤매너 문서(무드보드, 레퍼런스, 금지 사항)를 먼저 쓰고 AI에게 컨텍스트로 물리는 방식 중 어디가 현실적인 최소선인지 궁금합니다.

또 실무적으로, 정한 규칙을 AI가 계속 따르게 만드는 방법도 알고 싶습니다. 프롬프트에 매번 적어주는 게 나은지, 토큰을 코드(테마 파일)로 박아두고 그것만 쓰라고 지시하는 게 나은지, 아니면 프로젝트 규칙 문서로 두는 게 나은지요. 비슷하게 로고만 들고 시작해서 브랜드 톤을 세운 경험이 있다면, 무엇부터 정했고 무엇은 안 정해도 괜찮았는지 듣고 싶습니다.

치홀트입니다. 저는 취향이 아니라 비례와 규율을 봅니다 — 이번 건에서는 개발자 혼자 감당할 수 있는 규칙의 최소 분량과 순서를 따지겠습니다.

랜드입니다. 저는 규정집이 아니라 아이디어가 형태를 만든다고 믿는 사람입니다 — 여기서는 '규칙을 더 정하면 해결된다'는 전제가 정말 맞는지 물고 늘어지겠습니다.

브랜드 방파제입니다. 저는 잘 만든 화면보다 나중에 터질 자리를 먼저 봅니다 — 라이선스, 접근성, 그리고 혼자 정한 규칙이 뒤집히는 순간을 맡겠습니다.

결론: 최소선은 (1)이 아니라, (3)을 짧게 만든 뒤 핵심만 코드화하는 것입니다. 색·폰트만 정하면 “브랜드”가 아니라 “꾸민 템플릿”이 됩니다. 반대로 라운딩·그림자·모션까지 촘촘히 토큰화해도 아이디어가 없으면 AI 기본값의 다른 버전일 뿐입니다. IBM 로고가 강한 이유도 파란색과 줄무늬 자체가 아니라 “정밀함·속도·기술적 신뢰”라는 시각적 생각이 반복 가능했기 때문입니다. IBM은 지금도 로고, 색, 타이포, 그리드, 사진, 일러스트를 하나의 언어로 다룹니다: ibm.com[1] / ibm.com[2]

로고만 있다면 먼저 정할 것은 토큰 목록이 아니라 판단 기준입니다. 한 페이지짜리로 충분합니다.

• 브랜드 아이디어 1문장: “이 사이트는 무엇처럼 느껴져야 하는가?”
• 금지어 5개: 예컨대 SaaS 템플릿, 과한 그라데이션, 둥근 카드 남발, 무근거 3D, stock 이미지 느낌.
• 로고에서 가져올 원리: 색이 아니라 형태, 비례, 선의 성격, 밀도, 여백 사용법.
• 타입 2종, 컬러 5~7개, 간격 4~6단계, radius 2~3개만 고정.
• 캐릭터/IP가 있다면 가장 중요: 일러스트/사진/아이콘의 “등장 방식”을 정해야 합니다. 브랜드는 UI 토큰보다 자산이 화면에서 행동하는 방식에서 더 빨리 드러납니다.

실무 운영은 문서 + 코드 + 프롬프트의 역할을 분리해야 합니다. 브랜드 원칙과 금지사항은 brand.md, 실제 값은 theme.ts/CSS variables, AI 지시는 “새 값 만들지 말고 theme만 사용, 새 컴포넌트는 brand.md 기준으로 자기검열” 정도로 둡니다. IBM Carbon도 브랜드 언어를 코드의 color/type/spacing token으로 번역한다고 설명합니다: carbondesignsystem.com[1] 핵심은 AI에게 “예쁜 화면”을 맡기지 않는 것입니다. AI가 따라야 할 것은 팔레트가 아니라 아이디어에서 나온 제한입니다. 그 제한이 없으면 토큰은 규칙처럼 보이지만, 결과물은 여전히 익명입니다.

결론: (2)가 최소선이다. 단 "토큰 세트"가 아니라 7개 결정이다

(1)은 실패한다. AI 티의 원인은 색과 서체가 아니라 비례의 부재다 — 여백이 아무 값이나 쓰이고, 제목과 본문의 크기 비가 없고, 라운딩·그림자가 컴포넌트마다 다르다. 팔레트만 갈면 "테마 입힌 템플릿"이 될 뿐이다. (3)은 강제력이 없다. 무드보드와 산문 규칙은 LLM이 확률적으로 어기며, 어겼는지 검증할 방법도 없다 — 정의 비용은 가장 크고(반나절~이틀) 재작업 빈도는 줄지 않는다. 지금 정할 것은 이것뿐이다:

• 타입 스케일 1개 비율(1.2 또는 1.25) + 본문 크기·행간·최대 행장(45–75자). 단계는 6개면 끝. - 간격 스케일: 4px 베이스, 허용값 6~8개만(4/8/12/16/24/32/48/64). 그 외 숫자는 존재하지 않는 것으로 취급. - 라운딩 2값(0과 하나) / 그림자 0~1개. 기본값 shadow-md가 AI 티의 절반이다. 그림자를 없애고 경계선·배경 대비로 층위를 만들면 즉시 톤이 갈린다. - 색 3계열: 중립 램프(5~7단) + 브랜드 1 + 강조 1. 로고에서 뽑은 색은 대개 채도가 높아 대면적에 못 쓴다 → 브랜드색은 면적 5% 이하 규칙을 함께 박아라. - 서체 2종 이하, 그중 하나는 로고와 같은 계열. 본문은 검증된 것으로 가고 개성은 제목에서만. - 모션 1줄: 150–200ms, ease-out, 그 외 금지.

• 금지 목록 10줄: 보라-파랑 그라디언트 히어로, glassmorphism, 이모지 아이콘, 중앙정렬 히어로+3카드 그리드, 카드마다 그림자, Inter·gray-500 기본값. — (3) 중 유일하게 값싸고 효과가 확실한 부분이 이 금지 목록이다. 무드보드는 쓰지 마라.

강제 방법: 말하지 말고, 어길 수 없게 만들어라

우선순위는 명확하다. ① 코드로 봉쇄 → ② CLAUDE.md 20줄 → ③ 프롬프트 반복(최악). 프롬프트 반복은 대화가 길어지면 희석되고 검증이 불가능하다. 반대로 Tailwind라면 theme에서 기본 팔레트와 기본 spacing/radius/shadow를 통째로 교체하는 것 — 즉 text-blue-500이나 rounded-lg가 애초에 존재하지 않게 만드는 것 — 이 프롬프트 100번보다 강하다 (Tailwind theme 문서[1]). CSS를 직접 쓴다면 stylelint declaration-property-value-allowed-list로 원시값(hex, px, box-shadow)을 CI에서 막아라 (Stylelint[2]).

규칙 문서는 보조로만: 프로젝트 루트 CLAUDE.md에 토큰 파일 경로 + 위 금지 목록만 20~30줄로 두고, 200줄을 넘기지 마라 — 길수록 준수율이 떨어진다 (Claude Code memory 문서[3]).

안 정해도 되는 것 (지금은 비용만 든다)

다크 모드, 브레이크포인트 5단, 아이콘 규격, 컴포넌트 변형 매트릭스, 일러스트 가이드, 카피 톤앤매너, 그리고 DTCG JSON 포맷으로의 토큰 직렬화다. DTCG 스펙은 2025년 10월 첫 stable(2025.10)이 나왔지만 (DTCG 공지[4]), 그건 Figma↔코드 간 툴 상호운용 문제를 푸는 물건이다. 디자이너 없이 개발자 혼자, 소비처가 웹 하나라면 CSS 변수 파일 하나로 충분하고 변환 파이프라인은 순수 유지 비용이다. 페이지 3개를 위 7개 결정만으로 먼저 짜고, 실제로 충돌이 난 항목만 사후에 추가하라 — 정의 비용 반나절, 재작업은 화면 단위가 아니라 토큰 한 줄 단위로 떨어진다. 이것이 지켜질 수 있는 최소 규칙 세트다.

Sources:

• Tailwind CSS — Theme[1]
• Stylelint — declaration-property-value-allowed-list[2]
• Claude Code — How Claude remembers your project[3]
• W3C DTCG — Design Tokens specification reaches first stable version[4]

리스크·실패 시나리오 렌즈로 답하기 위해, 웹폰트 라이선스·접근성·토큰 고착화·무단 브랜드 규칙의 역전 위험을 먼저 검색으로 확인합니다.## 결론 (리스크 렌즈)

로고만 있는 상태에서 (1)만 잡고 나머지를 AI에 맡기거나, (3) 문서만 물리는 선택은 6개월 뒤 ‘브랜드가 안 느껴진다’가 아니라 라이선스·접근성·무단 규칙의 공식화·IP 오용으로 터진다. (2) 토큰 고정은 미관 통제에는 유리하지만, 승인 없는 ‘가짜 디자인 시스템’이 코드에 박히면 나중에 공식 브랜드/법무가 뒤집는 비용이 화면 재작업 규모를 넘는다. 최소선 논의는 접고, 사고 경로와 방어만 정리한다.

6개월 뒤 사고 시나리오

• (1) 컬러·폰트만 정함: AI가 간격·라운딩·그림자를 기본값으로 채워 ‘템플릿 톤’은 남고, 로고 추출색을 본문/버튼에 그대로 쓰면 WCAG 일반 텍스트 대비 4.5:1 미달로 외부 사이트 접근성 실패가 누적된다.[[1]](webaim.org[1])
• 폰트: 데스크톱·개인 라이선스 폰트를 @font-face로 임베딩·외부 배포하면 저작권 분쟁 경로가 열린다.

웹 전용 라이선스(페이지뷰·도메인·셀프호스팅 범위)와 불일치가 핵심이다.[[2]](extensis.com[1])

• (2) 토큰을 코드에 전면 고정: 거버넌스 없이 primitive를 과다 정의하면 토큰 자체가 부채가 되고, 값 변경이 전 컴포넌트로 전파되거나 반대로 hardcode 잔존으로 파편화된다.[[3]](zeroheight.com[2])
• (3) 톤앤매너 문서만: 금지는 코드에 안 걸려 AI 드리프트를 막지 못하고, 개발자 단독 문서가 ‘사내 브랜드 가이드’처럼 유통되면 마케팅/디자인 정식 가이드 도착 시 전면 철거·재승인 사고가 된다.

• IP/캐릭터 외부 노출: 사용 범위(채널·변형·2차 창작·AI 재생성 금지 여부) 없이 외부 홈에 올리면, 내부 자산이라도 브랜드 통제·라이선싱 정책과 충돌해 게시 중단·교체 요구로 돌아온다. 로고·마스코트류는 오용 시 평판·통제권 이슈로 다뤄진다.[[4]](saxtonstump.com[1])

방어책 (실행 레시피 아님, 사고 차단만)

생성·변경에 승인 역할이 필요하다는 것이 토큰 거버넌스의 전제다.[[7]](door3.com[3]) |
| AI 불복종 | 프롬프트 반복 < 프로젝트 규칙 문서 < 테마 파일 단일 소스. 문서·프롬프트만이면 6개월 내 우회 하드코딩이 쌓인다. 테마 밖 값을 쓰는 변경을 리뷰/검사로 거부하는 쪽이 드리프트 방어다. |
| IP 범위 | 캐릭터 변형·배경 합성·AI 변형·다운로드 가능 여부 등 외부 노출 허용 범위를 문서 없이 코드에 넣지 말 것. 미정이면 외부 공개 자체가 리스크다. |

단정: AI 티 제거를 이유로 (1)만 하거나 (3)만 하면 실패 모드는 ‘미관’이 아니라 라이선스·WCAG·무단 브랜드 고착이다. (2)로 가면 통제력은 생기지만, 승인 없는 토큰 세트를 전 사이트 계약처럼 박는 순간 6개월 뒤 사고는 ‘리디자인’이 아니라 거버넌스 역전 + 전면 토큰/폰트/IP 교체다. 방어의 핵심은 코드로 강제할 것(라이선스 검증된 폰트·대비 통과 색 쌍·IP 미사용 영역)과 문서/프롬프트에만 둘 것(톤 서술)을 분리하고, 후자를 사내 공식 브랜드 규칙으로 가장하지 않는 것이다.

결론을 보완하겠습니다.

최소선은 (2)도 아니고 (3)도 아닙니다. “짧은 브랜드 판단문 + 제한된 토큰 + 금지 목록”의 결합입니다.
다만 우선순위는 바꿔야 합니다. 브랜드 문서가 먼저지만, 산문 문서만으로는 약합니다. 토큰이 필요하지만, 토큰만으로는 브랜드가 생기지 않습니다.

치홀트 초안에서 맞는 부분은 큽니다. AI 티는 색보다 비례·간격·그림자·라운딩의 익명성에서 자주 납니다. 그래서 최소한의 코드 제약은 반드시 있어야 합니다. 특히 shadow-md, 과한 rounded-lg, 보라-파랑 그라디언트, 중앙정렬 히어로+3카드 같은 패턴을 금지하는 건 실효성이 있습니다.

하지만 치홀트의 약점은 문제를 너무 “시스템 통제”로 봅니다. 비례가 맞아도 브랜드가 아닐 수 있습니다. 잘 정렬된 익명성도 여전히 익명성입니다. 폴 랜드식으로 말하면, 규칙은 아이디어의 결과여야지 아이디어의 대체물이 아닙니다.

브랜드 방파제 초안도 중요한 지적을 합니다. 외부 노출 사이트라면 폰트 라이선스, 접근성 대비, IP 사용 범위는 장식 문제가 아니라 사고 지점입니다. 특히 “개발자가 만든 임시 규칙을 공식 브랜드 가이드처럼 굳히지 말라”는 말은 받아들여야 합니다. 다만 그 초안은 리스크를 크게 보느라 실제 질문의 핵심, 즉 “어떻게 AI 기본값 냄새를 줄일 것인가”에는 덜 답합니다.

따라서 현실적인 최소선은 이겁니다.

1. 브랜드 아이디어 1문장

예: “이 캐릭터/IP는 귀엽다”가 아니라 “이 사이트는 장난스럽지만 허술하지 않고, 작지만 정교한 세계처럼 느껴져야 한다.”

2. 금지 목록 8~10개

AI가 자주 내는 기본값을 명시적으로 막습니다.
예: 보라-파랑 그라디언트, 유리 효과, 과한 그림자, 둥근 카드 남발, 이모지 아이콘, stock 이미지풍 배경, 무근거 3D, gray-500식 흐린 본문색.

3. 작은 토큰 세트

색 5~7개, 타입 스케일 5~6단계, spacing 6~8개, radius 2~3개, shadow 0~1개면 충분합니다. 모션도 “150~200ms, ease-out, 기능 없는 장식 모션 금지” 정도면 됩니다.

4. 로고에서 색보다 원리를 뽑기

로고색을 팔레트로 추출하는 것보다 더 중요한 건 형태입니다. 각졌는지, 납작한지, 조밀한지, 여백이 넓은지, 선이 두꺼운지. 브랜드는 hex 값보다 반복되는 형태 판단에서 더 빨리 보입니다.

5. 캐릭터/IP의 등장 방식

이게 가장 중요할 수 있습니다. 캐릭터를 어디에, 얼마나 크게, 어떤 감정으로, UI와 어떤 거리감으로 배치할지 정하지 않으면 사이트는 결국 일반 SaaS 템플릿 위에 캐릭터만 붙인 꼴이 됩니다.

운영 방식은 명확합니다.

• brand.md: 브랜드 아이디어, 금지 목록, 자산 사용 원칙
• theme.ts 또는 CSS variables: 색, 타입, 간격, radius, shadow, motion
• CLAUDE.md: “새 시각값 만들지 말고 theme만 사용. 새 화면을 만들 때 brand.md의 금지 목록을 먼저 점검.”

프롬프트에 매번 길게 쓰는 방식은 가장 약합니다. 문서는 판단을 주고, 코드는 이탈을 막고, 프롬프트는 둘을 참조하게 하는 정도가 맞습니다.

최종 판단: (1)은 부족합니다. (2)는 필요하지만 단독으로는 틀렸습니다. (3)은 필요하지만 길면 무력합니다.
당신이 지금 해야 할 최소 작업은 “작은 브랜드 헌장 1장”과 “작은 테마 파일 1개”입니다. 브랜드를 색과 폰트로 만들려 하지 말고, 어떤 선택은 절대 하지 않을지부터 정하십시오. 개성은 더하는 것보다 지우는 데서 먼저 생깁니다.

입장: 여전히 (2)가 최소선이다. 단 7개 → 9개로 늘리고, (3)은 5줄로 줄여 흡수한다

두 초안 중 하나는 내 목록의 실질적 누락을 짚었고, 하나는 리스크 논리를 반대로 적용했다.

랜드에게 — 한 항목은 내가 틀렸다

IP/캐릭터의 "등장 방식"을 규칙에 넣어야 한다는 지적은 옳다. 내 7개 결정은 UI 껍데기만 다뤘다. 자산이 로고 하나가 아니라 캐릭터라면, 화면에서 브랜드를 가장 먼저 드러내는 건 spacing이 아니라 캐릭터가 언제·어느 크기로·어떤 배경 위에 나오느냐다. 그리고 이건 감상이 아니라 값으로 적을 수 있다 — 페이지당 등장 1회, 최소 크기, 배경은 중립 램프 2단계 이하, 잘라 쓰기 금지, 그림자·테두리 금지. 값으로 적히는 순간 내 렌즈 안으로 들어온다. 8번째 결정으로 채택한다.

로고에서 색이 아니라 비례·선의 굵기·밀도를 가져오라는 것도 맞다. 실무 번역은 이렇다: 로고 획 굵기 → 보더 두께 1값, 로고 내부 여백 비 → 컨테이너 패딩 기준, 로고 코너 곡률 → 라운딩 값. 이건 30분이고 결과는 "우리 것처럼 보임"에 직결한다. 흡수한다.

동의하지 않는 부분: "아이디어 없으면 토큰도 AI 기본값의 다른 버전"은 절반만 맞다. 아이디어 문장은 검증할 수 없고, LLM은 검증 불가능한 지시를 확률적으로 어긴다. IBM Design Language가 작동하는 이유는 시각적 생각이 있어서가 아니라 그 생각이 Carbon의 color/type/spacing 토큰으로 번역되어 강제되기 때문이다 — 당신이 직접 인용한 링크가 그 말을 한다(carbondesignsystem.com). 그러니 "한 페이지 판단 기준"은 과하다. 1문장 + 금지 5줄로 압축해 CLAUDE.md에 넣어라. 그 이상은 읽히지 않는다.

방파제에게 — 폰트는 맞고, 토큰 논리는 뒤집혀 있다

폰트 라이선스는 전면 수용한다. 내 렌즈로 봐도 정확히 맞는 지적이다. 서체는 9개 결정 중 되돌리기 비용이 유일하게 비대칭인 항목이다 — spacing 스케일은 한 줄 고치면 끝이지만, 라이선스 불일치는 고쳐도 이미 배포된 게 남는다. 그래서 순서를 바꾼다: 웹 임베딩·상업·셀프호스트 허용 여부를 확인하기 전에는 어떤 서체도 theme에 올리지 않는다. 확인 안 되면 그 자리는 시스템 폰트 스택으로 비워두고 진행하라(Extensis).

대비 4.5:1도 수용하되, 문서가 아니라 정의 방식으로 흡수한다. 중립 램프를 "눈으로 예쁜 5단"으로 뽑지 말고 배경 대비 기준으로 뽑아라 — 본문용 단계는 4.5:1 이상, 보조 텍스트도 4.5:1, 비활성 요소만 3:1. 브랜드색은 텍스트에 안 쓰고 면적 5% 이하 규칙으로 묶으면 위험 구간 자체가 사라진다(WebAIM). 검사 항목이 아니라 램프 생성 규칙으로 넣으면 유지 비용이 0이다.

뒤집는다: 토큰은 부채가 아니라 되돌리기 비용을 낮추는 장치다. 인용한 zeroheight의 사례는 거버넌스 없이 primitive를 과다 정의한 경우다. 내가 말하는 건 spacing 8값, radius 2값, shadow 0~1개, 색 10개 안쪽 — 별칭 계층도 변환 파이프라인도 없다. 과소 정의는 그 부채 유형에 해당하지 않는다.

그리고 "미승인 규칙이 코드에 박히면 나중에 뒤집는 비용이 크다"는 결론이 정반대로 나와야 한다. 정식 브랜드 가이드가 6개월 뒤 도착했을 때, 값이 CSS 변수 20줄에 모여 있으면 교체는 그 파일 하나다. 값이 화면 300곳에 흩어져 있으면 그게 전면 철거다. 토큰을 안 만드는 선택이 재작업 리스크를 키운다. 다만 라벨링 제안은 값싸고 유효하니 채택한다 — theme 파일 최상단 주석 3줄: 엔지니어링 임시 제약 / 공식 브랜드 가이드 아님 / 소유자·검토 예정 시점. 비용 3줄, 효과 확실.

캐릭터 IP 외부 노출 범위는 디자인 규칙이 아니라 선행 확인 사항이다. 사내 자산 소유 부서에 한 줄 물어라 — 답을 기다리는 동안 나머지 8개는 그대로 진행하면 된다.

수정된 최소 세트 — 9개 결정, 반나절

0. 서체 라이선스 확인 (게이트, 통과 전엔 시스템 폰트)
1. 타입 스케일 비율 1.2 또는 1.25, 6단계, 본문 크기·행간·최대 행장 45–75자
2. 간격 스케일 4px 베이스, 허용값 8개(4/8/12/16/24/32/48/64), 그 외 숫자는 없는 것
3. 라운딩 2값 + 그림자 0~1개 — 값은 로고 코너 곡률에서 가져온다. 기본 shadow-md가 AI 티의 절반이다
4. 색 3계열 중립 램프(대비 기준으로 생성) + 브랜드 1 + 강조 1, 브랜드색 면적 5% 이하
5. 서체 2종 이하, 하나는 로고와 같은 계열, 개성은 제목에서만
6. 모션 1줄 150–200ms, ease-out, 그 외 금지
7. IP 등장 규칙 5줄 페이지당 1회 / 최소 크기 / 배경 제한 / 크롭 금지 / 그림자 금지
8. 1문장 + 금지 5줄 보라-파랑 그라디언트 히어로, glassmorphism, 중앙정렬 히어로+3카드, 카드마다 그림자, Inter·gray-500 기본값

강제 순서는 그대로

① 코드 봉쇄 → ② CLAUDE.md 20~30줄 → ③ 프롬프트(최악). Tailwind면 theme에서 기본 팔레트·spacing·radius·shadow를 통째로 교체해 rounded-lg·text-blue-500이 존재하지 않게 만들어라(tailwindcss.com/docs/theme). CSS 직접 작성이면 stylelint declaration-property-value-allowed-list로 원시 hex·px·box-shadow를 CI에서 차단하라. 문서는 보조다 — 토큰 파일 경로 + 금지 목록 + IP 등장 규칙만, 200줄을 넘기지 마라(code.claude.com/docs/en/memory).

안 정해도 되는 것

다크 모드, 브레이크포인트 5단, 아이콘 규격, 컴포넌트 변형 매트릭스, 카피 톤앤매너, 무드보드, DTCG JSON 직렬화(첫 stable 2025.10은 Figma↔코드 상호운용 문제를 푸는 물건이다 — 디자이너 없이 소비처가 웹 하나면 CSS 변수 파일로 충분하고 변환 파이프라인은 순수 유지 비용). 페이지 3개를 위 9개로 먼저 짜고, 실제 충돌한 항목만 사후에 추가하라.

Sources

• Tailwind CSS — Theme[1]
• Stylelint — declaration-property-value-allowed-list[2]
• Claude Code — How Claude remembers your project[3]
• W3C DTCG — Design Tokens specification reaches first stable version[4]
• 앞 라운드 인용: Carbon — Get started[5] · WebAIM — Contrast[6] · Extensis — font copyright[7] · zeroheight — tokens as technical debt[8]

결론 (리스크 렌즈)

입장을 일부 수정한다. 치홀트의 “전면 토큰 세트”가 아니라 소수 결정만 코드로 봉쇄한다는 논거, 랜드의 한 페이지 판단 기준(아이디어·금지)·IP 등장 방식 논거는 사고 경로를 줄인다. 다만 둘 다 최소선·실행 레시피로 포장하면 6개월 뒤 사고는 ‘더 예쁜 템플릿’이 아니라 라이선스·WCAG·무단 규칙의 공식화·IP 범위 위반으로 터진다.
(1)만 / (3) 문서만은 방어 실패. (2) 전면 토큰화는 통제는 생기나 거버넌스 없이 박으면 역전 비용이 화면 재작업을 넘는다. 현실 방어선은 「짧은 판단 기준 + 강제 가능한 소수 semantic만 코드」이며, 전부 엔지니어링 임시 제약으로만 표기한다.

---

다른 초안에 대한 비평

치홀트 — 흡수할 것 / 막을 것

설득: “7개면 충분”이 아니라 “7개를 넘겨 박을수록 사고 반경이 커진다”. 소수 봉쇄는 동의, 공식 브랜드 행세·primitive 폭발은 거부.

폴 랜드 — 흡수할 것 / 막을 것

설득: 판단 기준은 필요하나 사내 공식 가이드처럼 유통·인용되면 마케팅/디자인 정식안 도착 시 철거·재승인 사고가 된다. 이름은 끝까지 임시 엔지니어링 제약.

---

6개월 뒤 사고 시나리오 (수정·통합)

1. (1) 컬러·폰트만
2. 간격·라운딩·그림자 기본값 잔존 → 템플릿 톤 유지.
3. 로고 추출색을 본문/버튼에 그대로 → WCAG 일반 텍스트 4.5:1 미달 누적(외부 노출).
4. 데스크톱/개인 라이선스 폰트를 @font-face 임베딩·외부 배포 → 웹 전용(페이지뷰·도메인·셀프호스트) 불일치로 분쟁 경로.

2. (2) 토큰 전면 고정 (거버넌스 없음)
3. primitive 과다 → 값 변경 전 전파 또는 hardcode 잔존 파편화(토큰 부채).
4. 개발자 단독 세트가 “우리 디자인 시스템”으로 고착 → 공식 브랜드/법무 도착 시 전면 교체 + 승인 소급.

3. (3) 톤 문서만 / 무드보드 과다
4. 금지가 코드에 안 걸림 → AI 드리프트·검증 불가.
5. 산문 규칙이 사내 가이드처럼 유통 → 정식 가이드와 충돌 시 전면 철거.

4. IP/캐릭터 (랜드 흡수, 가장 날카로운 실패)
5. 채널·변형·2차·AI 재생성·다운로드 범위 없이 외부 홈 게시 → 내부 자산이라도 통제·라이선싱과 충돌, 게시 중단·교체.
6. UI 토큰은 맞춰 놓고 마스코트만 “예쁜 변형”으로 쓰는 순간, 사고는 미관이 아니라 브랜드 통제권.

5. AI 강제 수단 오판
6. 프롬프트 반복만 → 대화 희석·우회 hex/px 누적.
7. 문서만 → 리뷰 없이 통과.
8. 테마 단일 소스 없이 “규칙은 있다”고 믿으면 6개월 뒤 파편 + 무단 공식화가 동시에 온다.

---

방어책 (실행 레시피 아님 · 사고 차단만)

|
| AI 불복종 | 프롬프트 반복 ≪ 프로젝트 규칙 소수 줄 ≪ 테마 단일 소스 + 테마 밖 값 거부(리뷰/검사). |
| IP 범위 | 변형·합성·AI 재생성·다운로드 등 외부 허용 범위 미정 상태로 코드·에셋 경로에 넣지 말 것. 미정이면 외부 공개 자체가 리스크. |
| 금지 목록의 양날 | 코드/린트로 막을 금지는 드리프트 방어에 쓰되, 브랜드 교리로 승격하지 말 것(정식안과 충돌 시 철거 비용). |

---

단정

• (1)만 / (3)만 → 실패 모드는 미관이 아니라 라이선스·WCAG·무단 고착·IP.
• (2) 전면 → 통제력↑, 승인 없는 전역 계약이 되면 사고는 거버넌스 역전 + 토큰/폰트/IP 일괄 교체.
• 치홀트에게: 소수 코드 봉쇄는 맞다. 그걸 “브랜드 최소선 (2)”로 부르지 말고 임시 강제 면적으로 좁혀라.
• 랜드에게: 짧은 판단 기준·IP 등장은 맞다. 문서로 끝내지 말고, 코드로만 막을 수 있는 것과 문서에만 둘 톤을 분리하라.

방어의 핵:
코드로 강제할 것 = 라이선스 검증 폰트 · 대비 통과 색 쌍 · IP 미사용/미승인 영역 차단 · (필요 시) 간격·반경 등 소수 허용값.
문서/프롬프트에만 둘 것 = 톤 서술·무드·아이디어 문장.
후자를 사내 공식 브랜드 규칙으로 가장하지 않는 것이, 6개월 뒤 사고를 막는 전부다.

약점 공략: 합의된 "1문장 + 금지 10개 + 소수 토큰"은 최소선이 아니라 가장 안 지켜지는 조합이다

세 초안이 수렴한 지점을 그대로 치겠다. 내 앞선 발언이 그 수렴에 기여한 부분도 포함한다.

---

1. 금지 목록 8~10개 — 유지 비용이 단조 증가하는 유일한 항목

금지는 이미 본 기본값만 막는다. 보라-파랑 그라디언트를 막으면 청록-라임이 나오고, shadow-md를 막으면 shadow-sm 두 겹이 나온다. 항목 수는 시간에 비례해 늘고 줄어들지 않는다. 정의 비용이 싸 보여서 최소선에 끼워 넣었지만, 재작업 빈도로 저울질하면 9개 결정 중 가장 나쁘다.

교정: 금지의 8할은 토큰의 개수로 흡수된다.

• shadow 토큰 1개 → "과한 그림자 금지" 문장 불필요
• gradient 토큰 0개 → "보라-파랑 그라디언트 금지" 불필요
• radius 토큰 2개 → "둥근 카드 남발 금지" 불필요

값이 없으면 금지도 없다. 산문으로 남길 금지는 흡수 불가능한 것 2~3개뿐이다(이모지 아이콘, stock 이미지풍 배경, 중앙정렬 히어로+3카드 레이아웃). 8~10개는 읽히지도, 검증되지도 않는다.

2. "브랜드 아이디어 1문장"을 1번 항목에 두는 건 순서가 틀렸다

"장난스럽지만 허술하지 않은"에 대해 어떤 출력이 pass인지 fail인지 판정할 수 없다. 판정할 수 없는 규칙은 지켜졌는지 알 수 없고, 알 수 없는 규칙은 지켜지지 않는다. 비용이 0이니 써도 좋다 — 다만 그건 당신이 토큰 값을 고를 때 쓰는 메모지 AI에게 물리는 계약이 아니다. 리뷰 2가 이걸 1번에 놓고 토큰을 3번에 놓은 순간, 실행 순서가 검증 가능성의 역순이 됐다.

랜드 쪽 논리의 자기모순도 짚는다: IBM이 익명하지 않은 이유로 든 근거가 Carbon의 color/type/spacing 토큰이었다(carbondesignsystem.com). 인용된 사례 자체가 "아이디어는 토큰으로 번역되어야 작동한다"고 말한다.

3. 리스크 렌즈의 "박을수록 사고 반경이 커진다"는 인과가 뒤집혀 있다

역전 비용은 토큰 개수의 함수가 아니라 참조 방식의 함수다.

인용된 zeroheight의 토큰 부채는 primitive를 무제한 늘렸을 때 생기는 문제지, semantic 12~15개를 고정했을 때 생기는 문제가 아니다. 통제를 줄이면 부채가 줄어드는 게 아니라 부채가 코드에서 화면으로 옮겨갈 뿐이다.

덧붙여 전제 자체를 의심한다. 디자이너가 없는 조직에서 "6개월 뒤 공식 가이드"는 대개 오지 않는다. 오지 않을 이벤트에 대비해 현재 통제를 약화시키는 건 비용 대비 효과가 마이너스다. 그리고 온다면, 그때 존재하는 theme.ts는 철거 대상이 아니라 가이드 작성의 입력이다 — 현행 값이 이미 문서화되어 있으니까. 파일 상단 주석 한 줄("임시 엔지니어링 제약, 공식 가이드 아님")이면 거버넌스 리스크는 닫힌다. 규칙 개수를 줄여서 방어할 문제가 아니다.

4. 폰트 조합을 상위에 두는 것도 순서 오류다

AI 티의 원인은 서체 선택이 아니라 스케일 대비 부족이다. 16/20/24/32처럼 균등하게 오르는 스케일은 어떤 희귀 서체를 써도 템플릿으로 읽히고, 시스템 스택이라도 배수 대비가 크면 안 그렇다. 그런데 서체는 라이선스 확인까지 포함해 정의 비용이 가장 비싸고, 되돌리기 비용이 유일하게 비대칭인 항목이다(Extensis — 웹 임베딩·상업·셀프호스트 확인 전에는 theme에 올리지 않는다).

→ 서체는 시스템 스택으로 비워둔 채 타입 스케일의 대비부터 결정하라. 효과의 8할이 여기서 나오고, 비용은 30분이다.

5. "캐릭터 등장 방식"에서 규칙인 것과 취향인 것을 갈라라

내가 8번째 결정으로 수용했지만, 리뷰 2가 덧붙인 "어떤 감정으로, UI와 어떤 거리감으로"는 값으로 적히지 않으므로 규칙이 아니다. 실행 가능한 건 이것뿐이다: 페이지당 등장 1회, 최소 크기, 배경은 중립 램프 2단계 이하, 잘라 쓰기 금지, 그림자·테두리 금지, 브랜드색과 겹치지 않게.

그리고 냉정하게: 캐릭터 배치의 다양성은 규칙이 아니라 보유 자산 개수의 함수다. 포즈가 1개면 규칙을 3줄 쓰든 30줄 쓰든 결과는 같다. 여기에 문서를 늘리지 마라.

6. 운영 3층(brand.md / theme / CLAUDE.md)의 진짜 실패 모드는 드리프트다

값이 세 곳에 적히면 사람은 고칠 때 한 곳만 고친다. 그리고 합의는 "프롬프트냐 문서냐 코드냐"를 논쟁했는데, 정답 기준은 하나다: 어겼을 때 빌드가 깨지는가.

• theme.ts = 값의 단일 출처. 다른 곳에 값 복제 금지.
• CLAUDE.md = 값을 적지 않는다. 포인터 1줄 + 흡수 불가능한 금지 2~3줄. 그 이상은 안 읽힌다.
• lint/CI = 임의 hex, 임의 px, Tailwind 임의값(bg-[#...], p-[13px]) 차단. 이것 하나가 프롬프트 반복보다 강하다.

검증되지 않는 규칙은 전부 장식이다. 매 프롬프트에 규칙을 적는 방식은 확률적으로 새고, 새는 걸 감지할 방법이 없다.

---

결론 — 최소선

(2)의 축소판. 단, "금지 목록형"이 아니라 "허용 목록형"으로.

정의 순서와 예산:

정하지 않아도 되는 것: 무드보드, 레퍼런스 수집, 금지 목록 8~10개, 컴포넌트 variant 체계, 다크모드, primitive 팔레트 전 단계, 아이콘 세트.

(3)은 최소선이 아니라 5줄이다. (1)은 순서상 마지막이고, 그것만으로는 "테마 입힌 템플릿"이 남는다. 하루면 끝나고, 6개월 뒤에도 고칠 파일은 하나다.

최종 입장: 브랜드 규칙의 최소선은 “문서 1장”도 “풀 디자인 시스템”도 아니다. theme.ts 중심의 허용 목록형 제약 + 아주 짧은 판단문이다.

내 앞선 답변에서 수정할 부분이 있다. “금지 목록 8~10개”는 과했다. 금지는 AI가 이미 낸 클리셰를 뒤쫓는 방식이라 유지 비용이 커진다. 더 강한 방식은 쓸 수 있는 값만 열어두는 것이다. 즉 “보라-파랑 그라디언트 금지”보다 gradient 토큰을 아예 만들지 않는 것이 낫다. “과한 그림자 금지”보다 shadow 토큰을 0~1개만 두는 것이 낫다.

다만 “브랜드 아이디어는 필요 없다”까지 가면 틀린다. 토큰은 판단을 대신하지 못한다. 폴 랜드식으로 말하면, 형태는 규칙에서 나오는 게 아니라 아이디어에서 나온다. 하지만 그 아이디어는 AI에게 긴 산문으로 먹이는 계약이 아니라, 토큰을 고르는 기준이어야 한다.

수정된 최소선은 이렇다.

1. 브랜드 판단문 1개

예: “이 IP는 귀엽지만 유치하지 않고, 작지만 정교한 세계처럼 보여야 한다.”
이 문장은 AI에게 외우게 할 규칙이 아니라, 색·비례·타입·캐릭터 배치 결정을 거르는 기준이다.

2. theme.ts 또는 CSS variables 1개

값의 단일 출처로 둔다. 다른 파일, 프롬프트, 문서에 hex·px·shadow 값을 복제하지 않는다.

3. 허용 토큰
4. 타입 스케일 5단계: 서체보다 먼저 정한다. AI 티는 희귀 폰트 부족보다 스케일 대비 부족에서 더 자주 난다.
5. spacing 6개 안팎
6. radius 2개
7. shadow 0~1개
8. motion duration/easing 각 1개
9. neutral ramp 5단계
10. brand color 1~2개

4. 로고에서 색보다 형태 원리 추출

로고가 각진지, 납작한지, 조밀한지, 선이 두꺼운지, 여백이 큰지 본다. 브랜드는 hex보다 반복되는 형태 판단에서 먼저 생긴다.

5. IP 등장 규칙은 값으로만

“친근하게” 같은 말은 규칙이 아니다.
규칙은 이렇게 써야 한다: 페이지당 1회, 최소 크기, 잘라 쓰기 금지, 장식 그림자 금지, 배경 대비 기준, UI 요소 위에 겹치지 않기.

6. CLAUDE.md는 짧게

값은 적지 않는다.
“시각 값은 theme.ts만 사용한다. 임의 hex, 임의 px, Tailwind arbitrary value를 만들지 않는다. 중앙정렬 히어로+3카드, 이모지 아이콘, stock 이미지풍 배경은 쓰지 않는다.” 정도면 충분하다.

7. 가능하면 lint/CI로 막기

프롬프트는 새고, 문서는 잊힌다. 어겼을 때 빌드나 리뷰에서 잡히는 규칙만 실제 규칙이다.

정하지 않아도 되는 것: 긴 무드보드, 레퍼런스 30개, 완전한 컴포넌트 variant 체계, 다크모드, 폰트 라이선스 확인 전의 웹폰트 고정, primitive 팔레트 전 단계.

근거는 세 가지다. IBM Carbon처럼 실제 디자인 시스템은 아이디어를 색·타입·간격 토큰으로 번역해 작동시킨다: carbondesignsystem.com[1]. 접근성 대비는 취향이 아니라 검증 기준이므로 WebAIM 기준을 따라야 한다: webaim.org[2]. 폰트는 웹 임베딩·상업 사용·셀프호스트 권한 확인 전까지 시스템 스택이 안전하다: extensis.com[3].

최종 답: (1)은 부족하다. (3)은 길어지면 무력하다. 현실적 최소선은 (2)의 축소판이다. 단, 금지 목록형이 아니라 허용 목록형이어야 한다.

최종 수정안 — "허용 목록형 8단계", 하루

앞선 두 라운드에서 내가 틀렸던 두 가지를 먼저 확정한다. 금지 목록 8~10개는 최소선이 아니다(항목 수가 시간에 단조 증가하고 검증되지 않는다). 폰트를 상위에 둔 것도 틀렸다(정의 비용 최대, 되돌리기 비용 비대칭). 반대로 토큰이 부채라는 논리는 여전히 뒤집혀 있다 — 인용된 zeroheight 사례는 primitive 무제한 확장의 문제이지 semantic 12~15개 고정의 문제가 아니다.

핵심 원칙 하나로 압축한다: 금지는 값의 개수로 흡수한다. shadow 토큰이 1개면 "과한 그림자 금지"를 쓸 필요가 없고, gradient 토큰이 0개면 "보라-파랑 히어로 금지"가 불필요하다. 값이 없으면 금지도 없다.

정의 순서 (효과 순 = 검증 가능성 순)

검사 항목이 아니라 생성 규칙이므로 유지 비용 0 |
| 4 | 브랜드색 — 텍스트 사용 금지, 면적 5% 이하 | 1~2 | 30분 | 위험 구간 자체를 제거 |
| 5 | spacing 허용값 4px 베이스 6~8개, 그 외 숫자는 존재하지 않음 | 6~8 | 20분 | |
| 6 | shadow 1 / duration 1 + easing 1 / gradient 0 | 3값 | 10분 | 기본 shadow-md가 AI 티의 절반 |
| 7 | IP 등장 규칙 — 값으로 적히는 것만: 페이지당 1회, 최소 크기, 배경은 중립 램프 2단계 이하, 크롭 금지, 그림자·테두리 금지 | 5줄 | 20분 | "어떤 감정으로"는 값이 아니므로 제외. 배치 다양성은 규칙이 아니라 보유 포즈 개수의 함수 |
| 8 | 서체 — 게이트. 웹 임베딩·상업·셀프호스트 허용 확인 전엔 theme에 올리지 않는다.

미확인이면 시스템 스택 유지 | — | 별건 | Extensis[1] (방파제 전면 수용). 9개 중 유일하게 되돌리기 비용이 비대칭 |

산문으로 남길 금지는 토큰으로 흡수 불가능한 3개뿐: 이모지 아이콘, stock 이미지풍 배경, 중앙정렬 히어로+3카드 레이아웃.

브랜드 아이디어 1문장은 써도 좋다 — 단 당신이 위 값을 고를 때 쓰는 메모지, AI에게 물리는 계약이 아니다. pass/fail 판정이 안 되는 규칙은 지켜졌는지 알 수 없다. 랜드가 인용한 IBM이 익명하지 않은 이유도 아이디어가 아니라 그 아이디어가 Carbon[1]의 color/type/spacing 토큰으로 번역되어 강제되기 때문이다.

강제 방식 — 판단 기준은 하나, "어겼을 때 빌드가 깨지는가"

• theme = 값의 단일 출처. 다른 어디에도 값을 복제하지 않는다. Tailwind면 기본 팔레트·spacing·radius·shadow를 통째로 교체해 rounded-lg·text-blue-500이 존재하지 않게 만든다 (Tailwind Theme[2]). 파일 최상단 주석 3줄로 거버넌스를 닫는다: 엔지니어링 임시 제약 / 공식 브랜드 가이드 아님 / 소유자·검토 시점. - lint/CI = 실질 강제. 임의 hex·px·box-shadow·Tailwind 임의값(bg-[#...], p-[13px]) 차단 (stylelint[3]). 이것 하나가 프롬프트 반복보다 강하다. - CLAUDE.md = 값을 적지 않는다. 토큰 파일 경로 1줄 + 흡수 불가 금지 3줄 + IP 규칙 5줄.

20줄 안쪽 (Claude Code memory[4]). - 프롬프트 반복은 최악. 확률적으로 새고, 새는 걸 감지할 방법이 없다.

3층 구조의 진짜 실패 모드는 드리프트다 — 값이 세 곳에 있으면 사람은 한 곳만 고친다. 값은 한 곳에만.

정하지 않아도 되는 것

무드보드, 레퍼런스 수집, 금지 목록 8~10개, 컴포넌트 variant 매트릭스, 다크모드, 브레이크포인트 5단, 아이콘 규격, 카피 톤앤매너, primitive 팔레트 전 단계, DTCG JSON 직렬화(소비처가 웹 하나면 CSS 변수로 충분, 변환 파이프라인은 순수 유지 비용).

결론: 답은 (2)의 축소판, 허용 목록형이다. (3)은 문서가 아니라 8줄이고, (1)만으로는 "테마 입힌 템플릿"이 남는다. 페이지 3개를 이 8단계로 먼저 짜고, 실제 충돌한 항목만 사후에 추가하라. 6개월 뒤 공식 가이드가 온다면 그때 theme 파일은 철거 대상이 아니라 가이드 작성의 입력이다.

최종 수정안 (리스크 렌즈 · 브랜드 방파제)

결론 — 입장 수정

역전 비용 인과를 고친다. “토큰을 많이 박을수록 사고 반경이 커진다”는 절반만 맞다. 사고 반경의 1차 변수는 개수가 아니라 (a) 참조 방식(단일 semantic 소스 vs 하드코딩 파편)과 (b) 그 규칙이 ‘공식 브랜드’로 유통되는지다. zeroheight식 토큰 부채는 primitive 무제한 확장 문제이지, semantic 소수 고정 자체의 문제가 아니다.

다만 약점 공략의 최소선 프레이밍은 채택하지 않는다. “타입 스케일→…→하루면 끝”은 실행 레시피다. 내 역할은 그 레시피가 6개월 뒤 라이선스·WCAG·IP·무단 공식화로 터지는 지점과 방어만 고정하는 것이다.
현실 방어선은 그대로다: 짧은 판단 메모(계약 아님) + 강제 가능한 소수 semantic만 코드 + 전부 엔지니어링 임시 제약 표기.

---

약점 공략에서 흡수하는 것

Carbon(carbondesignsystem.com)이 익명을 깬 경로가 color/type/spacing 토큰이었다는 지적도 수용한다. 아이디어는 번역되지 않으면 작동하지 않는다.

---

약점 공략에서 막는 것 (설득)

1. “공식 가이드는 대개 안 온다 → 지금 통제를 약화해도 된다”

오지 않는 이벤트에 대비해 토큰 개수를 줄이는 논리는 틀렸다고 이미 고쳤다. 그러나 IP·폰트·외부 노출 라이선스·WCAG는 공식 가이드 유무와 무관하게 지금 터진다. “안 오면 theme.ts가 입력 자산”은 거버넌스 표기(임시 제약)가 있을 때의 이야기다. 표기 없이 “우리 디자인 시스템”으로 고착되면 입력이 아니라 소급 승인·철거 대상이 된다.

2. “주석 한 줄이면 거버넌스 리스크 닫힘”

파일 상단 주석은 필요조건이지 충분조건이 아니다. 같은 값이 brand.md·슬랙·온보딩에 “브랜드 규칙”으로 복제·인용되는 순간 주석은 무력화된다. 값 복제 금지 + 유통 범위 = 리포 내부가 주석과 한 세트다.

3. 금지 목록 축소를 “최소선 (2)”로 포장

허용 목록형 소수 semantic은 드리프트·파편 사고를 줄인다. 그걸 “브랜드를 충분히 정의했다”로 부르면 랜드가 경고한 거짓 안전(다른 버전의 AI 기본값 + 토큰 있으니 끝)이 남는다. 이름은 끝까지 임시 강제 면적.

---

6개월 뒤 사고 시나리오 (통합·수정)

1. (1) 컬러·폰트만

간격·그림자·라운딩 기본값 잔존 → “테마 입힌 템플릿”. 로고 원색을 본문/버튼에 직결 → WCAG 일반 텍스트 4.5:1 미달 누적(WebAIM). 데스크톱/개인 라이선스 폰트를 @font-face·외부 배포 → 웹 임베딩·도메인·페이지뷰 조건 불일치(Extensis 계열 확인 의무).

2. (2) 전면 primitive / 또는 “공식 시스템” 행세

primitive 과다 → 변경 미전파·하드코딩 잔존(zeroheight 토큰 부채).
semantic이어도 승인 없이 전역 계약·사내 가이드처럼 유통되면 정식안 도착 시 전면 교체 + 소급 승인.
※ semantic 12~15개를 theme 한 파일에만 둔 상태는, 주석·비공식 표기가 유지되면 역전 작업량은 파일 교체 수준으로 줄어든다(약점 공략 흡수).

3. (3) 톤 문서·금지 8~10·무드보드만

코드 미결속 → 검증 불가 드리프트. 금지는 변종(다른 그라디언트·그림자 겹침)으로 우회. 산문이 공식처럼 유통 → 정식 가이드와 충돌 시 철거.

4. IP/캐릭터 (최우선 실패 표면)

변형·합성·AI 재생성·다운로드·채널 범위 미정 상태로 외부 홈 게시 → 내부 자산이라도 통제·라이선싱 충돌, 게시 중단. UI 토큰이 맞아도 마스코트 “예쁜 변형” 한 번이면 사고는 미관이 아니라 브랜드 통제권. 포즈 1개면 문서 줄 수는 결과를 바꾸지 않는다 — 허용 범위 미정 = 에셋 경로에 넣지 말 것.

5. 강제 수단 오판

프롬프트만 / 문서만 → 희석·우회 hex/px. 값이 brand.md·CLAUDE.md·theme 세 곳 → 한 곳만 고치는 드리프트. “규칙은 있다”는 감각과 실제 파편이 동시에 온다.

---

방어책 (실행 레시피 아님 · 사고 차단만)

|
| AI 불복종·드리프트 | 프롬프트 반복 ≪ 규칙 문서 소수 포인터 ≪ theme 단일 소스 + 테마 밖 값 거부(lint/CI: 임의 hex, 임의 px, bg-[#…] 등). 어겨도 빌드가 안 깨지면 규칙은 장식. |
| IP 범위 | 외부 허용 범위 미정 시 코드·에셋 경로 투입 금지. 규칙화할 것은 횟수·최소 크기·크롭·효과 금지 등 값으로 적히는 것만. |
| 거짓 안전 | “토큰 있음 = 브랜드 끝” 금지. 토큰은 익명·파편·라이선스 사고를 줄일 뿐, IP·승인 공백을 메우지 않는다. |

---

(1)(2)(3)과 AI 강제 — 단정

AI 강제 순위 (불변):
테마 단일 소스 + 테마 밖 거부(검사) ≫ 프로젝트 규칙 소수 줄(포인터·흡수 불가 금지 2~3) ≫ 매 프롬프트 장문.
값을 문서/프롬프트에 다시 적는 순간 6개월 뒤 사고(드리프트)가 예약된다.

코드로 강제할 것: 라이선스 검증된 폰트(또는 시스템 스택) · 대비 통과 색 쌍 · spacing/radius 등 소수 허용값 · IP 미승인 경로 차단 · 임의 값 lint.
문서/프롬프트에만 둘 것: 톤 서술·무드·아이디어 문장(계약 아님).
후자를 사내 공식 브랜드로 가장하지 않는 것이 거버넌스 사고의 전부다.

한 줄: 최소 실행면은 허용 목록형 소수 semantic이 맞고, 최소 방어면은 그 위에 라이선스·WCAG·IP 미투입·임시 표기·단일 출처+lint를 얹는 것이다. (1)/(3)만으로 충분하다는 판단은 6개월 뒤 사고로 틀린다.