무드 — 차분하고 정돈된 업무 도구

이 문서는 CoUI 로 만드는 서비스 화면의 기본 「무드」를 정의하고, 화면이 그 무드에 맞는지 판단하는 순서를 적습니다. 색 값 · 모서리 · 내부 여백 같은 생김새는 CoUI 가 정하므로 여기서는 정하지 않습니다. 이 문서가 정하는 것은 「무엇을 먼저 보고, 무엇을 또렷하게 하고, 무엇을 뺄 것인가」입니다. 토큰은 모두 CoUI 의 것을 이름으로만 부르고, CoUI 가 값을 바꾸면 화면도 따라갑니다. 어느 토큰을 어느 자리에 쓰는지는 token-usage.md, 화면 구성과 여백은 layout.md, 알림 · 상태 처리는 patterns.md, 문구는 copy.md 가 맡습니다.

차분하고 정돈된 업무 도구. 화면은 조용하고, 중요한 것만 또렷합니다.

• 「차분하다」 — 색은 강조색 하나, 상태색은 작게, 장식은 없습니다.
• 「정돈되다」 — 층은 면의 명도 차이로 나뉘고, 글자 크기는 네 단계 안에 있고, 여백은 한 리듬입니다.
• 「업무 도구」 — 소비자 앱보다 촘촘하고 콘솔보다 느슨합니다. 큰 숫자와 상태가 먼저 읽힙니다.
• 「조용하다」 — 같은 말을 두 번 하지 않고, 이미 보이는 결과를 다시 알리지 않습니다.
• 「중요한 것만 또렷하다」 — 한 화면에 주 행동 하나, 가장 높은 대비는 그 하나에만 줍니다.

위 한 줄은 운영자 · 직원이 하루 종일 켜 두는 업무 도구의 예시입니다. 손님이 폰으로 가끔 열어 내 일 하나를 끝내는 앱(예약 · 주문 · 거래 · 수강 신청)은 같은 바닥(면 · 주 행동 하나 · 상태색은 작게 · 장식 없음) 위에서 아래 예시를 출발점으로 씁니다.

믿고 맡기는 앱. 내 것과 숫자가 먼저 보이고, 다음 할 일은 엄지 자리에 하나입니다.

• 고르는 법 — 요청이 어느 예시를 쓰라고 말할 필요는 없습니다. 서비스 설명에서 그 화면을 누가 쓰는지 읽고 고릅니다(「손님이 예약하고 사장님이 관리하는 가게 앱」이면 손님 화면은 손님용 앱, 사장님 화면은 업무 도구). 고른 예시와 근거 한 줄을 디자인 결정 기록에 남깁니다. 한 화면을 손님과 운영자가 함께 써서 정말 갈리지 않을 때만 묻습니다.
• 두 예시 모두 출발점입니다. 제품의 브랜드 테마와 요구가 정한 것이 있으면 그것이 먼저입니다(SKILL.md).
• 손님용이라고 4절의 소비자 마케팅 톤(일러스트 · 축하 모션 · 카드 그림자)을 들이지 않습니다. 손님이 믿고 맡기게 하는 것은 장식이 아니라, 내 것이 먼저 보이고 위험을 미리 말해 주는 화면입니다.

이 무드는 도메인을 가리지 않는 기본값입니다. 학원 수강 관리, 병원 접수 대시보드, 커머스 정산 화면, 사내 승인 도구가 모두 이 결을 바닥선으로 삼습니다. 아래 판단 순서와 값은 출발점인 기본 예시이고, 제품의 브랜드 테마가 색 · 서체 · 밀도 · 형태 · 면 · 그림자를 정했으면 그것이 먼저입니다(SKILL.md 「두 수준의 스타일 제어」). 라이트 모드가 기본이고, 모든 판단은 다크에서도 그대로 성립해야 합니다. 다크는 CoUI 변수 모드가 처리하므로 화면을 그리는 쪽에서 채도나 밝기를 손으로 고치지 않습니다.

순서가 곧 우선순위입니다. 앞 단계가 깨졌으면 뒤 단계를 고쳐도 무드가 살지 않습니다. 화면을 만들 때는 1 에서 7 로 내려가며 정하고, 검수할 때는 같은 순서로 봅니다. 각 단계에 「보는 것」 · 「CoUI 로는」 · 「통과」 · 「실패」 를 적었습니다. 예시는 도메인을 섞었고, 어느 도메인의 규칙도 아닙니다.

• 보는 것 — 이 화면이 끝내는 일이 한 문장으로 적히는지. 가장 높은 대비의 버튼이 하나뿐인지. 페이지 머리 · 빈 상태 · 패널 안 행 · 알림이 같은 행동을 두 번 내놓지 않는지.
• CoUI 로는 — 주 행동은 Button primary 하나입니다. 보조 행동은 흰 면 위면 secondary(옅은 무채 면), 회색 카드 위면 outline 이고, 덜 중요한 행동은 ghost, 글자만 있는 이동은 Link 입니다(되돌리기 어려운 행동의 버튼만 destructive, patterns.md 5절). 손님용 앱의 흐름 화면에서는 주 행동이 맨 아래 BottomActionBar 에 있습니다(layout.md 10-4). 알림 안 버튼은 Alert 면 outline 또는 ghost 의 sm, Toast 면 ghost 입니다. 브랜드가 중립이어서 「중립 고대비 주 버튼」이 필요한 경우, 그런 변형은 CoUI 에 없음 입니다. 가장 가까운 것은 브랜드 테마에서 color/primary 를 무채로 두는 것이며, 반전 변형은 CoUI 후보로 올립니다(token-usage.md 6절).
• 통과 (교육) — 「수강 등록」 화면. 제목 아래 입력, 오른쪽 위에 primary 「등록하기」 하나. 「임시 저장하기」는 outline, 「돌아가기」는 ghost.
• 실패 (사내 도구) — 승인 대시보드. 페이지 머리에 primary 「요청 올리기」, 각 행에도 primary 「승인하기」, 사이드바 플랜 카드에도 primary 「업그레이드하기」. 세 개가 서로 다투어 무엇을 하라는 화면인지 읽히지 않습니다. 행 안 「승인하기」는 outline sm 으로 내리고, 플랜 카드의 버튼은 지우거나 ghost 로 내립니다.

• 보는 것 — 페이지 · 카드 · 카드 안이 선 없이 면의 밝기로 나뉘는지. 카드 안에서 면이 달라지는 곳이 부품의 상태(표 · 메뉴의 선택 · 호버)뿐이고 평상시 행은 카드 면 그대로인지. 선이 있다면 부품 기본값이 긋는 자리(표 행 구분 · 사이드바 경계 · 상단 바 아래 · 입력 칸)와 톤이 바탕과 같아지는 카드의 outlined 에만 있는지. 선과 면 차이를 한 자리에 겹쳐 쓰지 않았는지(사이드바는 부품 기본값의 면과 경계선을 그대로 두는 예외 — token-usage.md 2-2).
• CoUI 로는 — 면은 부품 기본값이 정합니다(token-usage.md 2절): 페이지 Scaffold(color/surface) → 카드 · 패널 · KPI Card · Stat 기본(filled, color/surface-container, 선 없음) → 카드 안 선택 행(Table 기본 color/surface-container-high). 라이트는 「흰 바탕 위 옅은 회색 카드」, 다크는 「어두운 바탕 위 한 단계 밝은 카드」가 같은 이름으로 성립합니다. 선이 필요한 자리 중 표 행 구분 · 사이드바 경계는 부품 기본값 color/outline-variant(CoreColors.outlineVariant) 이고, 입력 칸 경계는 TextField 기본값(color/outline) 그대로입니다. 카드 면의 톤이 바탕과 같아지는 자리(제품이 바탕을 회색으로 고른 화면 · 회색 면 위)만 Card(variant: CoreCardVariant.outlined) 의 옅은 선을 씁니다.
• 통과 (병원) — 접수 현황. 흰 페이지 위에 회색 카드 세 장. 카드 안 대기 환자 표는 행을 카드 면 그대로 두고 선은 행 사이에만 color/outline-variant(Table 기본값). 고른 행만 부품 기본값대로 color/surface-container-high 로 한 단계 진합니다.
• 실패 (커머스) — 정산 화면. 패널을 직접 만든 흰 면으로 그려 페이지와 같은 색이 되자 패널마다 진한 color/outline 테두리를 둘렀고, 안쪽 행에도 다시 테두리. 선이 격자를 만들어 화면이 시끄럽습니다. 패널을 Card 기본(filled)으로 되돌리고 테두리를 지웁니다.

• 보는 것 — 강조색이 선택 상태 · 링크 · 진행 · 정보 표시에만 있는지. 넓은 면에 강조색이 깔리지 않았는지. 상태색이 칩 · 점 · 아이콘 · 상태 제목 글자 · 알림 표면의 옅은 톤에만 있고, 넓은 면을 칠하지 않았는지. 도메인 색(진료과 · 과목 · 카테고리)을 상태색과 헷갈리게 쓰지 않았는지.
• CoUI 로는 — 강조는 color/primary(CoreColors.primary) 계열입니다. 글자로 쓸 때 color/primary-text, 링크 color/link, 포커스 color/focus-ring. 옅은 강조 면(primarySubtle 이라는 이름으로 찾는 것)은 CoUI 에 없음 이고, 가장 가까운 것은 color/primary-container + color/on-primary-container 입니다. 상태색은 color/success · color/warning · color/info · color/error 와 각각의 -container 짝입니다. 상태색 옅은 테두리와 「진한」 단계(success-strong 같은 것)는 CoUI 에 없음 입니다. 상태 칩은 Badge 의 tone 입니다(Badge(tone: CoreBadgeTone.success) — token-usage.md 7절). 점 하나로 충분한 자리는 Status 점 + 글자입니다. 다크에서 강조색이 무슨 색인지는 CoUI 가 정합니다. 화면은 color/primary 라는 역할만 고르고, 「파란 버튼」 같이 값에 기대는 판단을 적지 않습니다.
• 통과 (사내 도구) — 배포 목록. 지금 보고 있는 메뉴와 선택된 행에만 color/primary 계열, 진행 막대도 같은 색. 「실패」 행은 상태 칩(Badge tone destructive) 하나이고 행 전체는 칠하지 않았습니다.
• 실패 (교육) — 출결 화면. 출석 행 전체를 color/success-container 로, 지각 행 전체를 color/warning-container 로, 결석 행 전체를 color/error-container 로 칠했습니다. 표가 알록달록해져 상태색이 신호가 아니라 배경이 됩니다. 행은 color/surface 로 두고 상태는 상태 열의 칩(Badge tone) 한 자리에만 둡니다.

• 보는 것 — 화면에서 가장 큰 글자가 페이지 제목과 핵심 수치 · 상태인지(KPI 숫자는 부품 기본값으로 페이지 제목보다 큽니다). 설명이 한 줄 안에 끝나는지. 글자 크기가 페이지 제목 · 패널 제목 · 본문 · 메타 네 단계 안에 있는지(핵심 수치만 예외 — 업무 도구는 KPI 숫자, 손님용 앱은 숫자 카드의 값, layout.md 9절). 코드 · ID · 주문번호 · 버전이 고정폭인지.
• CoUI 로는 — KPI 는 CoUI Stat 입니다(cc-coui:coui-stat). 값은 부품 기본값 Headline/Large 이고, 단위(unit) · 라벨 · 비교 한 줄도 부품 기본값입니다(layout.md 2-2). 글자 색은 CoUI 의 세 단계(color/on-surface 본문 · color/on-surface-variant 보조 · color/on-surface-subtle 메타)를 그대로 쓰고 이 문서는 색 값을 정하지 않습니다(token-usage.md 4절). 고정폭은 코드 역할입니다 — 피그마 Code/XS · Code/SM · Code/MD 텍스트 스타일(font/family/Geist Mono), 코드 .codeSm · .codeMd. 로컬 텍스트 스타일은 만들지 않습니다(layout.md 9절).
• 통과 (커머스) — 정산 요약. 「이번 달 정산액」 아래 「12,480,000원」이 Stat 기본값(Headline/Large)으로 가장 크고, 그 아래 「지난달보다 8% 늘었어요」 한 줄. 주문번호 ORD-2041 은 고정폭.
• 실패 (병원) — 대기 현황 패널. 「현재 대기」 숫자는 본문 크기인데 안내문이 세 줄이고, 제목 · 소제목 · 본문 · 캡션 · 각주로 다섯 단계가 쓰였습니다. 패널을 Stat 으로 바꿔 숫자 「7명」을 부품 기본값(Headline/Large)으로 올리고 안내문을 「평균 12분 기다려요」 한 줄로 줄입니다.

• 보는 것 — 일러스트 · 장식 사진 · 이모지 · 장식 그라디언트 · 뜻 없는 아이콘이 있는지. 지웠을 때 정보나 행동이 줄지 않는 요소가 있는지(cc-designer:critique-restraint 의 지우기 시험).
• CoUI 로는 — 빈 상태는 EmptyState 를 아이콘 없이(showIcon: false) 또는 뜻 있는 Lucide 아이콘 하나로 씁니다. 알림은 CoUI Alert · Toast 를 그대로 쓰고 그라디언트 표면을 덧대지 않습니다. 재질 기본은 Semantic/ Surface 의 defaultStyle 모드입니다. 다른 서페이스 스타일은 서비스가 근거를 대고 덮어쓸 때만 쓰고, 면의 층 세 단계가 그대로 읽혀야 합니다. 사이드바 메뉴는 모든 항목에 아이콘을 둡니다. 태블릿 레일 · 모바일 하단 탭이 아이콘으로 보이기 때문입니다(layout.md 1절). 행동 메뉴(DropdownMenu)의 아이콘은 모든 항목에 있거나 모두 없어야 합니다. cc-designer:ui-illustration-style 은 이 무드의 화면에 쓰지 않습니다.
• 통과 (사내 도구) — 「아직 요청이 없어요」 빈 상태. 제목 한 줄, 「첫 요청을 만들면 여기에 보여요」 한 줄, outline 버튼 하나. 그림 없음.
• 실패 (교육) — 홈 상단에 「환영해요」 뒤에 축하 그림 문자를 붙인 배너, 파랑에서 보라로 번지는 그라디언트, 책 읽는 사람 일러스트. 지워도 사라지는 정보가 없습니다. 배너를 지우고 그 자리에 오늘 수업 KPI 를 둡니다.

• 보는 것 — 블록 사이와 패널 안 여백이 한 리듬인지(모두 4 의 배수, 같은 자리는 같은 값). 한 화면에 들어온 정보가 「소비자 앱보다 촘촘하고 콘솔보다 느슨한」 정도인지. 데스크톱에서 한 눈에 KPI 4 개 + 표 한 장 정도가 보이고, 스크롤 없이 다 넣으려고 글자를 줄이지 않았는지. 손님용 앱은 밀도를 화면이 아니라 카드로 셉니다 — 카드 한 장이 한 건이고, 첫 화면에 내 것 한 장과 둘러볼 것의 첫 줄이 보이면 충분합니다.
• CoUI 로는 — 간격은 space/* 사다리(피그마는 Primitives 의 space/*, 코드에서는 CoreSpace.space16 꼴)만 쓰고, 밀도 기본은 standard 입니다(layout.md 표기 문단). 이 스킬의 여백 리듬(본문 바깥 데스크톱 space/32space/36 · 모바일 space/16, 블록 사이와 패널 안 space/20space/24, 패널 안 요소 사이 space/12~space/16)은 모두 사다리 위에 있습니다. 시맨틱 간격 이름(「페이지 여백」 같은 역할)은 CoUI 에 없음 이므로 숫자 토큰을 쓰고, 정확한 값 배정은 layout.md 를 따릅니다. compact · spacious 는 서비스가 근거를 대고 덮어쓸 때만 쓰고, 이 절의 여백 리듬은 standard 기준입니다.
• 통과 (병원) — 진료과별 접수 표. 패널 안 space/24, 행 높이는 CoUI 기본, 열은 「이름」 「접수 시각」 「담당」 「상태」 네 개. 더 보려면 행을 눌러 상세로 갑니다.
• 실패 (커머스) — 상품 관리 표에 열 열두 개, 글자를 Label/Small 로 줄여 한 화면에 다 넣었습니다. 콘솔처럼 보입니다. 열을 여섯 개로 줄이고 나머지는 상세 패널로 옮기고, 글자를 부품 기본값 Body/Medium 으로 되돌립니다.

• 보는 것 — 그림자가 메뉴 · 팝오버 · 대화상자 · 토스트 · 드로어에만 있는지. 페이지 안 패널 · 카드 · KPI 에 그림자가 없는지. 누를 수 있는 카드가 올렸을 때 떠오르지 않는지.
• CoUI 로는 — 떠 있는 부품은 CoUI 기본 그림자를 그대로 씁니다. Toast shadow/md(CoreShadow.md, coui_flutter 0.165 부터 어두운 말풍선이라 CoreShadow.sm), Popup · Drawer shadow/lg, Dialog shadow/xl. 페이지 안 카드는 그림자 없이 2-2 의 면 차이로만 구분합니다. CoUI Card 는 누를 수 있을 때 올리면 그림자가 기본으로 생기므로 카드 테마(CoreCardTheme(style: CoreCardStyle(hoverElevation: CoreCardElevation.none)))로 끕니다. 피그마 이펙트 스타일 shadow/* 는 떠 있는 부품 인스턴스가 이미 들고 있으니 화면 쪽에서 더하지 않습니다.
• 통과 (사내 도구) — 멤버 표의 행 끝 「더 보기」를 열면 shadow/lg 메뉴가 뜨고, 삭제 확인은 shadow/xl 대화상자. 표를 담은 패널 자체는 평면.
• 실패 (교육) — 대시보드의 KPI 카드 네 장과 수업 카드 여덟 장이 모두 그림자를 달았습니다. 다 떠 있어서 아무것도 떠 있지 않습니다. 카드 그림자를 지우고 Card 기본 면(filled)과 페이지의 면 차이로 구분합니다.

세 결을 섞되 베끼지 않습니다. 레퍼런스는 참고일 뿐 근거가 아닙니다. 결정의 근거는 「CoUI 와의 일관성」 · 「실제 쓰임에서 무엇이 나은지」 · 「다른 디자인 시스템은 어떻게 하는지」 세 관점이고(figma-file.md 8절), 「토스가 그렇게 해서」는 근거로 적지 않습니다. 회사 안의 참고 구현(한 사내 도구의 v2 시안)에서 가져올 원칙은 reference-impl.md 에 따로 있습니다.

3-2. Vercel Geist#

• 구성은 토스 · 플렉스에서(큰 숫자 · 짧은 말 · 행 세 자리), 면과 선의 태도는 Geist 에서(면 대비 · 절제된 선 · 고정폭) 가져옵니다.
• 둘 중 어느 쪽의 색 · 글꼴 · 모서리 · 그림자 값도 가져오지 않습니다. 그 값은 모두 CoUI 토큰입니다.
• 레퍼런스에서 가져온 결정은 DDR 에 「레퍼런스」가 아니라 「실제 쓰임」 또는 「CoUI 일관성」으로 근거를 적습니다. 그렇게 적을 수 없으면 가져오지 않습니다.

• 소비자 마케팅 톤 — 히어로 그라디언트, 일러스트, 「환영해요!」 느낌표, 축하 모션.
• 콘솔 · IDE 밀도 — 열 열 개짜리 표, Label/Small 본문, 다크 전용, 한 화면에 모든 것.
• 대시보드 과시 — 차트로 가득한 첫 화면, 색색의 KPI 카드, 뜻 없이 움직이는 숫자.
• 장식적 미니멀 — 신호까지 지워서 무엇을 눌러야 하는지 모르는 화면. 절제는 신호를 남기고 장식을 지우는 것입니다.
• 상태색 바탕 — 성공은 초록 행, 실패는 빨간 행처럼 행과 패널을 상태색으로 칠하는 것.
• 카드 더미 — 패널마다 그림자와 큰 모서리로 떠 있는 것처럼 보이게 하는 것.
• 브랜드 색 도배 — 상단 바 · 사이드바 · 버튼을 모두 강조색으로 칠하는 것.
• 알림 재도색 — CoUI Alert · Toast 에 그라디언트 · 틴트 · 테두리를 덧대 다른 생김새로 만드는 것. 자리와 동작만 정합니다(patterns.md).
• 다크만 그린 시안 — 라이트에서 성립하지 않는 결정. 라이트로 그리고 변수 모드를 다크로 바꿔 확인합니다.
• 도메인 가정 예시 — 한 업계의 화면만 예로 들어 그 업계의 관례를 무드라고 부르는 것.

크리틱 스킬이 그대로 가져다 쓰는 열 줄과, 손님용 앱에만 더하는 두 줄입니다. 1 번부터 순서대로 보고, 하나라도 「아니오」면 아래 대응의 단계를 고칩니다 — 1 → 2-1, 2 · 3 → 2-2, 4 · 5 → 2-3, 6 · 7 → 2-4, 8 → 2-5, 9 → 2-6, 10 → 2-7, 11 · 12 → layout.md 10절.

1. 이 화면이 끝내는 일이 한 문장으로 적히고, Button primary 가 하나뿐입니까.
2. 면이 부품 기본값(token-usage.md 2절 — 페이지 Scaffold · 카드 Card · Stat 기본 filled · 떠 있는 판)대로 선 없이 명도 차이로 나뉘고, 카드 안에서 면이 달라지는 곳은 부품의 상태(선택 · 호버)뿐이며 평상시 행은 카드 면 그대로입니까.
3. 선은 부품 기본값이 긋는 자리(표 행 구분 · 사이드바 경계 · 상단 바 아래 color/outline-variant, 입력 칸 TextField 기본 color/outline)와 톤이 바탕과 같아지는 카드의 outlined 에만 있습니까.
4. 강조색(color/primary 계열)이 선택 · 링크 · 진행 · 정보 표시에만 있고 넓은 면을 칠하지 않습니까.
5. 상태색(color/success · color/warning · color/info · color/error)이 칩 · 점 · 아이콘 · 상태 제목 · 알림 표면에만 있습니까.
6. 가장 큰 글자가 페이지 제목 다음으로 핵심 수치 또는 상태이고, 글자 크기가 네 단계 안에 있습니까(KPI 숫자 · 손님용 앱 숫자 카드의 값 예외. Mobile-* 프레임은 KPI 가 패널 제목보다 작아지는 CoUI 값 차이가 있어 크기 대신 자리로 봅니다, layout.md 9절).
7. 설명은 한 줄이고, 코드 · ID · 번호는 고정폭입니까.
8. 지워도 정보와 행동이 줄지 않는 요소(일러스트 · 장식 그라디언트 · 이모지 · 뜻 없는 아이콘)가 없습니까.
9. 여백이 space/* 한 리듬이고 밀도가 standard(덮어쓴 서비스는 그 값)이며, 스크롤을 피하려 글자를 줄이지 않았습니까.
10. 그림자가 메뉴 · 팝오버 · 대화상자 · 토스트 · 드로어에만 있고, 페이지 안 패널에는 없습니까.
11. (손님용 앱) 홈에서 이 사람의 것(내 예약 · 내 주문 · 내 거래)이 둘러볼 것보다 먼저 보이고, 실패는 실패한 섹션만 덮습니까.
12. (손님용 앱) 흐름을 끝내는 화면의 주 행동이 맨 아래 BottomActionBar 에 있고, 조건이 안 되면 숨기지 않고 비활성으로 보입니까.

• cc-designer:critique-brand-consistency 는 프로젝트 루트의 mood.md 를 찾아 무드 정합성을 봅니다. 프로젝트에 mood.md 가 없으면 이 파일을 무드 기준으로 쓸 수 있습니다. 문구 기준(voice)은 같은 폴더의 copy.md 입니다.
• cc-designer:critique-restraint 는 2-5 의 지우기 시험을, cc-designer:critique-visual-hierarchy 는 2-1 · 2-4 를, cc-designer:critique-color 는 2-3 을 더 깊게 봅니다. 이 문서는 그 렌즈들이 공유하는 기준입니다.
• cc-designer:critique-specificity 와의 관계 — 이 무드를 따르는 서비스끼리 셸 · 밀도 · 강조가 같은 것은 일관성이지 결함이 아닙니다. 고유성은 도메인 데이터 · 흐름 · 용어 · 도메인 컴포넌트와, 제품의 브랜드 테마 · 컴포넌트 스타일이 정한 값에서 찾습니다. 그리기 전에 정한 고유 요소 셋(cc-blueprint/rules/figma-direction.md §D1 ⑤)이 화면에 그려졌는지는 이 렌즈가 따로 봅니다.
• 피그마에서 그릴 때의 절차와 검사는 cc-blueprint:design 과 cc-blueprint/rules/figma-workflow.md 를 따르고, 이 문서는 무엇을 그릴지의 기준만 줍니다.
• 토큰의 정의와 값은 cc-designer:design-system 이 정본이고, 앱 테마를 잇는 코드는 cc-coui:coui-theme 입니다. 이 문서와 token-usage.md 는 「어느 자리에 쓰나」만 말합니다.