Figma 브랜드 선택·저작·바인딩

디자이너가 CoUI 라이브러리에 이미 게시한 팔레트(Demo {이름} 과 CoUI) 중 이 제품에 맞는 하나를 고르고, 기본 색상 출처를 정하는 절차다. 등록된 제품·컴포넌트 컬렉션을 함께 사용할 수 있다. 게시 팔레트 선택은 출발점이다. 제품 테마와 컴포넌트별 스타일을 새로 정의·수정할 수 있으며 로컬 변수도 허용한다. 전체 절차는 cc-designer:coui-product-style의 references/brand-theme-workflow.md다. 브리프(§1)와 순위·결정(§4)은 판단이고, 계산(§3)·바인딩·스캔(§6)은 references/recipes/ 의 코드가 같은 결과를 낸다. --brand 처리의 유일한 정본이 이 문서다 — design.md Step 0.5 는 실행 순서만 가리킨다.

브리프(§1) → 발견(§2) → 특성화(§3) → 순위·결정(§4) → 바인딩·순도 스캔(§6)
                                          └ 색상군 불일치 → 순위 1 + 팔레트 요청(§5)

게시 팔레트가 없더라도 브랜드 저작은 진행할 수 있다. 선택할 수 있는 기본 팔레트와 새로 설계할 제품 테마를 구분한다.

규칙: 첫 화면 전에 아래 브리프를 쓴다. 스펙이 이미 말한 항목은 그대로 쓰고 조사하지 않는다.

서비스: {한 줄 성격} · 대상: {구체적인 사람과 상황} · 키워드: {a} / {b} / {c}
방향: 핵심 행동 {하나} · 톤 {구체적 이미지} — 출처 {--direction | 스펙 | 답변 | 추론함}   ← figma-direction §D1. 대상은 윗줄
결정 정보: {사실 — 형태: 값 (스펙 인용 | 유도 | 샘플 | 수치 확인 필요)} / … · 결정 화면 {화면 id}   ← figma-direction §D1 ④. 크리틱은 이 줄로 결정 화면을 본다
색 방향: {색상군 1~2개} · {채도 등급}   ← §3 반환 어휘(예 `파랑 · 선명`). 톤과 키워드에서 정한다. 레퍼런스가 갈리면 키워드 쪽, '차분한' 같은 형용사로 정하지 않는다
레퍼런스(3~5곳): 서비스 | 색 계열 | radius | 밀도 | 이미지 사용
구성 지침: {위계 — 가장 크게 둘 것 · 구성 단위 · 밀도 · 이미지 톤}   ← figma-direction §D2 의 레버. Step 2 의 화면 구성·강조 판단이 읽는다
카드 깊이: {평면 | 카드까지} — {이유}   ← 톤과 서비스 키워드에서 도출한다. 다른 제품 시안의 관행은 이유가 아니다
강조 면적: {기본 | 상한 N%} — {이유}   ← self-check 11번(슬롭 지문 §S4)이 읽는다. 화면을 그리기 전에 정하고, 그린 뒤 고치지 않는다

• 제한된 조사 — 위 레퍼런스 칸(서비스 3~5곳)만 본다. 조사 수단이 없거나 결과가 부족하면 스펙만으로 브리프를 쓰고(색 방향은 스펙의 키워드에서 같은 어휘로) 보고에 "조사 생략"을 적는다 — 차단 아님.
• 쓰임 셋 — ① §4 순위의 입력(색 방향) ② 화면 구성·깊이·강조 면적의 지침 ③ 결정 정보 — 저작 · 스펙 대조(design.md Step 1) · 크리틱(figma-quality-rubric §2)이 같은 목록을 본다. 구성 지침 · 카드 깊이 · 강조 면적은 톤에서 도출한다(figma-direction §D2) — 레퍼런스의 구성 · radius · 밀도도 제품 맥락과 연결해 근거로 사용할 수 있다. 카테고리 평균을 그대로 복제하지 않고 화면 목적에 맞게 판단한다.
• 강조 면적 — 보통의 답은 기본이다(강조색은 주 행동 하나에 — 상한 값은 slop-scan.figma.js 의 ACCENT_CAP_DEFAULT). 상한을 넓히는 것은 강조색 면 자체가 서비스의 성격이고 키워드가 그렇게 말할 때뿐이며, 그 키워드를 이유에 적는다. 화면을 그린 뒤 검사를 통과시키려고 올린 상한은 검사를 끈 것과 같다 — 그래서 화면보다 먼저 정한다.
• 하우스 스타일 — 하우스 스타일이면(기본 — 레버 DDR 첫 줄이 하우스 스타일: 없음 이 아니면, figma-direction.md §D2) 하우스 값은 초깃값으로 참고하고 제품의 밀도·카드 깊이·강조 면적을 독립적으로 결정한다. 색 방향은 그대로 §2~§6 으로 고른다 — 하우스 값은 기본 예시이며 브랜드는 색 외의 모든 시각 속성과 컴포넌트별 스타일도 정한다.
• 조사 결과는 브랜드 이름·고유 색 조합을 베끼는 근거가 아니다 — 색상군·채도·분위기만 뽑는다.

보고에는 브리프 한 줄 요약과 조사 생략 여부를 싣고, 전문은 DDR 에 둔다.

규칙: 브랜드 목록은 실행 때 읽는다. get_libraries 로 얻은 CoUI 라이브러리 키로 한정해(빼면 다른 라이브러리의 변수가 먼저 나온다) 한 번에 검색한다.

search_design_system({ fileKey, includeLibraryKeys: [CoUI 라이브러리 키],
  queries: [ {entity:'variable', query:'color/primary'},   {entity:'variable', query:'color/on-primary'},
             {entity:'variable', query:'color/secondary'}, {entity:'variable', query:'color/tertiary'},
             {entity:'variable', query:'color/surface'} ] })

1. 결과 항목 중 이름이 위 5개와 정확히 같은 것만 남긴다.
2. 항목의 variableCollectionName 이 Semantic/ Color · {Brand} 형식인 것만 브랜드로 센다. {Brand} = · 뒤 문자열. 그중 Demo 로 시작하는 것과 CoUI 만 후보다 — 자동 후보 검색에서는 다른 운영 제품 브랜드를 제외한다. 사용자가 지정한 제품 브랜드·로컬 브랜드는 이 필터로 제외하지 않는다. 같은 변수 이름이 컬렉션마다 하나씩 나오고 key 만 다르다 — 이름이 아니라 컬렉션 이름으로 가른다.
3. 브랜드마다 5개 변수의 key 를 모은다. 5개를 다 못 얻어도 그 브랜드의 항목이 하나라도 있으면 그 항목의 variableSetKey 로 후보에 둔다(recipe 가 컬렉션 변수 목록에서 5개를 찾는다). 항목이 전혀 없는 브랜드는 후보가 아니다 — 보고에 적는다.
4. figma.teamLibrary.getAvailableLibraryVariableCollectionsAsync 에 의존하지 않는다 — 소비 파일에서 아이콘 라이브러리만 나왔다.

확인: 보고의 "발견된 브랜드" 가 검색 결과의 컬렉션 이름과 글자 그대로 같고, 이 문서·recipes 에 브랜드 목록이 없다.

references/recipes/brand-catalog.figma.js 에 발견한 key 를 붙여 실행하면(PARAMS 의 BRANDS) 브랜드마다 Light 모드 실값으로 색상군(primary·secondary·tertiary) · 채도 등급(무채색/차분/선명) · 명도 · on-primary 대 primary 대비를 돌려준다. 경계값의 유일한 정의는 그 파일 상단 상수(MIN_CONTRAST·MONO·VIVID·FAMILIES)다 — 이 문서에 사본을 두지 않는다. 경계 근처 색은 chroma(OKLCH 채도)·색상각 숫자를 같이 읽는다. 적격 = 대비 ≥ 4.5 이고 warn 없음(버튼 라벨은 작은 글자라 일반 텍스트 기준). 미달 브랜드는 후보에서 빼고 보고에 브랜드·수치를 적는다.

순위 — 적격 브랜드만 사전식 순서로 줄 세운다: primary 색상군 > secondary·tertiary 색상군 > 채도 등급 > 대비(높은 쪽). primary 색상군이 맞는 후보가 없으면 첫 칸을 브리프 색상군까지의 색상각 차이(hueGap, 작은 쪽 먼저 — 무채색은 null 이라 색이 있는 후보 뒤)로 대신한다 — 채도만 맞는 브랜드가 색상이 가까운 브랜드 위로 오지 않는다.

결정 — 항상 자동으로 순위 1. primary 색상군이 브리프와 다르면 팔레트 요청(§5)을 붙인다. 보고에는 항상 선택한 브랜드 · 방식 · 상위 3개와 색상군·채도로 쓴 한 줄 이유를 싣는다(--brand 로 다시 돌릴 수 있게). 방식 = 자동(순위 1) · 지정(--brand).

확인: 보고에서 적격·색상군·채도 판정을 읽을 수 있다.

--brand 를 생략했고 순위 1 의 primary 색상군이 브리프 색상군과 다르면 그 팔레트로 가되 보고에만 디자이너용 한 줄을 남긴다:

팔레트 요청 — {서비스 한 줄}: {색상군} 계열 · {채도 등급} · 주색 위 글자 대비 ≥ 4.5 의 Demo 팔레트가 게시되면 다음 실행부터 후보가 됩니다.

적격 후보가 하나도 없으면 중단하고 수치를 보고한다.

규칙: 기본 브랜드와 등록된 component/slot/instance override의 출처·범위를 명시한다. references/recipes/brand-bind.figma.js 를 쓴다.

1. 선언 — 컬렉션 이름·id 를 DDR 에 남긴다. 변수 key 는 실제 라이브러리 검색 또는 로컬 변수 조회로 확인한다.
2. 저작 중 — 직접 칠하는 fill·stroke·글자색은 처음부터 선택 컬렉션의 같은 이름 슬롯(color/primary …)에 바인딩한다. 칠하지 않을 프레임·SLOT·섹션은 만들 때 붙는 기본 흰 채움·선을 비운다.
3. 마지막에 recipe 한 번 — FRAMES = 같은 페이지의 화면 프레임·공유 컴포넌트 id, 페이지마다 한 번. 하는 일: ⓐ 모든 화면 프레임(Mobile·Web)에 해당 화면의 지원 모드(Light/Dark 등)를 명시한다. recipe의 MODE를 화면 그룹별로 설정한다. 고정은 그 컬렉션에 바인딩된 노드에만 듣는다. Web(폭 ≥ 1024) 프레임은 Typography 컬렉션도 Desktop 모드로 고정한다(TYPO_KEY — 안 하면 Mobile 크기로 나온다: 라이브러리 00. Overview). ⓑ 라이브러리 인스턴스 안쪽은 기본이 CoUI 컬렉션이라 고정만으로는 안 바뀐다 — 프레임 안 SOLID fill·stroke(글자 포함)를 검사하고, 등록된 override 범위를 보존하면서 기본 브랜드의 같은 의미 변수로 다시 묶는다. ALLOWED_OVERRIDES에 nodeId/collectionId를 등록한다. 반드시 마지막 — 이유는 consumption §7 '순서'. 그 뒤 Variant 를 바꾸거나 라이브러리를 업데이트했다면(coui-library-update D·E) recipe 를 다시 돈다.
4. 스캔 판독 — 통과 = pure && pinnedAll(pure 의 조건은 brand-bind.figma.js 코드가 정본이다 — 여기에 옮겨 적지 않는다). 등록 범위 밖의 잘못된 컬렉션 바인딩이 있으면 실패(figma-workflow §4 L0, design-self-check 3번) — after 를 보고에 싣고 놓친 노드를 고쳐 다시 돈다. libraryLiteral(라이브러리 인스턴스 안쪽의 바인딩 없는 보이는 페인트)은 실패에서 빼되, 비어 있지 않으면 순정 인스턴스와 대조해 저작자가 덮어쓴 것을 authorLiteral 로 센다.

확인: 컬렉션별 바인딩 수, 화면별 모드, 등록된 override 범위, 미해결 바인딩을 보고한다. pure는 이 recipe의 제한된 색상 검사이며 전체 테마 품질을 보장하지 않는다.

색상 후보 선정만으로 브랜드 설계를 완료하지 않는다. typography, dimension, surface, motion, component 스타일을 제품 요구에 맞게 정의하고 Figma에서 실제로 적용한다. preset과 현재 API는 상한이 아니다. 전체 테마 → 컴포넌트 공통 → variant/size/state → 부모 슬롯 → 인스턴스 순서와 상속값을 기록한다. 별도 브랜드 파일 또는 분리된 로컬 컬렉션에서 정의하고, 확장 컬렉션 지원 여부에 따라 상속 또는 명시적 재바인딩을 선택한다. 같은 이름의 복사본은 override로 보지 않는다. 대표 화면을 검증한 뒤 요청된 전체 화면으로 확장하고 같은 revision의 코드 theme/style로 연결한다. brand-bind.figma.js는 색과 기존 mode의 도구이며 전체 테마 exporter로 간주하지 않는다. 모든 디자인 속성이 현재 코드에서 자동 지원된다고 주장하지 말고 adapter/API gap을 남긴다.