디자인 토큰 포맷 모듈 2025.10

이 포맷에서 정의된 모든 속성은 달러 기호($)로 시작합니다. 이 규칙은 향후 명세 버전에서 새 속성을 도입할 때도 적용됩니다. 따라서 토큰 및 그룹 이름은 $ 문자로 시작할 수 없습니다 MUST NOT.

또한 토큰 별칭에 사용되는 구문 때문에 다음 문자는 토큰 및 그룹 이름에 사용할 수 없습니다 MUST NOT:

• { (왼쪽 중괄호)
• } (오른쪽 중괄호)
• . (마침표)

토큰의 용도를 설명하는 일반 텍스트 설명을 선택 속성 $description으로 추가할 수 있습니다. 도구에 따라 설명을 다양한 방식으로 활용할 수 있습니다 MAY.

예시:

• 스타일 가이드 생성기는 설명 텍스트를 시각적 미리보기와 함께 표시할 수 있습니다 MAY
• IDE는 자동 완성시 설명을 툴팁으로 표시할 수 있습니다(마치 API 문서처럼) MAY
• 디자인 도구는 토큰 선택 시 툴팁이나 옆에 설명을 보여줄 수 있습니다 MAY
• 변환 도구는 설명을 내보낸 변수나 상수의 주석으로 표시할 수 있습니다 MAY

$description 값은 반드시 일반 JSON 문자열이어야 합니다 MUST. 예시:

디자인 토큰은 언제나 명확한 타입을 가지므로, 도구들이 해당 값을 신뢰성 있게 해석할 수 있습니다.

토큰의 타입은 선택 속성 $type으로 지정할 수 있습니다. 만약 토큰에 $type이 없다면, 다음 규칙에 따라 타입을 반드시 결정해야 합니다 MUST:

• 토큰의 값이 참조라면, 참조된 토큰의 해석된 타입이 해당 토큰의 타입입니다.
• 그렇지 않고, 토큰의 부모 그룹 중 어느 하나라도 $type 속성이 있다면, 가장 가까운 부모 그룹의 $type을 상속합니다.
• 부모 그룹에 $type이 하나도 없다면 타입을 정할 수 없으므로, 해당 토큰은 무효로 간주해야 합니다 MUST.

도구는 토큰의 값을 검사하여 타입을 추론해서는 안됩니다 MUST NOT.

$type 속성은 다음 수준에서 설정할 수 있습니다:

• 그룹 레벨
• 토큰 레벨

$type 값은 반드시 명세 내 타입 정의에 명시된 값 중 하나인 일반 JSON 문자열이어야 하며 MUST, 대소문자를 구분합니다.

예시:

선택 속성 $extensions는 도구가 특정 벤더, 사용자, 팀, 혹은 벤더별 데이터를 디자인 토큰에 추가할 수 있도록 해주는 객체입니다 MAY. 이때, 각 도구는 반드시 벤더 고유의 키를 사용하고 MUST 값으로는 유효한 JSON 데이터를 자유롭게 넣을 수 있습니다 MAY.

• 키는 다른 벤더와의 이름 충돌을 피할 수 있도록 선택해야 하며 SHOULD, 이를 위해 도메인 역순 표기법이 추천됩니다.
• 디자인 토큰 파일을 처리하는 도구는, 자신이 이해하지 못하는 확장 데이터를 반드시 보존해야 합니다 MUST. 예컨대, A 도구의 확장 데이터가 들어간 토큰이 B 도구에서 열려 저장될 때도, 원래의 A 도구의 확장 데이터는 반드시 남겨야 합니다.

이 포맷을 지원하는 도구 간의 상호운용성을 위해, 팀·도구는 확장 데이터의 사용을 토큰 값 이해에 필수적이지 않은 선택적 메타데이터로만 제한해야 합니다 SHOULD.

도구 벤더는 자신의 확장 데이터 명세를 공개할 것을 권장합니다. 그래야 타 도구들도 이를 역공학하지 않고 지원할 수 있습니다. 인기 있는 확장은 향후 명세 표준 기능으로 통합될 수도 있습니다.

$deprecated 속성은 토큰을 사용 중단(deprecate) 대상으로 지정하고, 이유를 설명할 때 MAY 사용할 수 있습니다. 사용중단의 이유는 다음에 국한되지 않습니다:

• 향후 디자인 시스템 업데이트에서 이 토큰이 제거될 예정임
• 지금 제거하면 기존 지원이 깨질 수 있음
• 이 토큰의 향후 사용을 지양하도록 권장함

도구 개발자는 예시와 같은 별칭이 들어갈 때 문자열을 보완하여 보여줄 수 있습니다 MAY. 도구는 토큰을 해석하고 문서, 코드, 시각적 표현 또는 다른 토큰으로 연결 등 다양한 방법으로 UI에서 안내할 수 있습니다. 예를 들어 “Please use {button.activeBorder} instead“는 JS에서 아래처럼 출력할 수 있습니다:

또는

그룹은 전체 그룹을 사용 중단으로 표시하기 위해 선택 속성 $deprecated를 포함할 수 있습니다 MAY. 이는 그룹 내의 모든 자식 토큰에도 확장됩니다(명시적으로 덮어쓰는 경우 제외).

그룹은 도구가 독점적이거나 사용자·팀·벤더별 데이터를 추가할 수 있는 선택 속성 $extensions를 포함할 수 있습니다 MAY. 각 도구는 벤더 고유의 키를 사용해야 하며 그 값은 유효한 JSON 데이터일 수 있습니다 MUST.

$extends 속성은 [json-schema-2020-12]에 명시된 JSON Schema의 $ref 키워드와 의미적으로 동등합니다. 다음 두 그룹 정의는 기능적으로 동일합니다:

$extends 사용(Design Token 문법):

{
  "button-primary": {
    "$extends": "{button}",
    "background": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0.8, 0, 0.4],
        "hex": "#cc0066"
      }
    },
    "focus": {
      "$value": {
        "colorSpace": "srgb",
        "components": [1, 0.2, 0.6],
        "hex": "#ff3399"
      }
    }
  }
}

$ref 사용(JSON Schema 문법):

{
  "button-primary": {
    "$ref": "#/button",
    "background": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0.8, 0, 0.4],
        "hex": "#cc0066"
      }
    },
    "focus": {
      "$value": {
        "colorSpace": "srgb",
        "components": [1, 0.2, 0.6],
        "hex": "#ff3399"
      }
    }
  }
}

확장 해석은 다음의 간단한 절차를 따릅니다:

1. 대상 찾기: $extends 참조를 해석하여 대상 그룹을 찾습니다
2. 상속된 내용 복사: 대상 그룹의 모든 토큰과 속성으로 시작합니다
3. 로컬 오버라이드 적용: 동일한 경로에 로컬 정의가 있으면 상속된 토큰/속성을 교체합니다
4. 새 내용 추가: 상속된 그룹에 없는 로컬 토큰/속성을 포함합니다

이로써 상속된 내용과 로컬 내용을 위 규칙에 따라 결합한 새로 해석된 그룹이 생성됩니다.

그룹 확장은 로컬 속성이 동일 경로의 상속된 속성을 덮어쓰는 딥 머지 동작을 따릅니다:

1. 상속: 참조된 그룹의 모든 토큰과 속성이 상속됩니다(순환 참조 금지)
2. 오버라이드: 동일 경로에 로컬 토큰/속성이 있으면 로컬 정의가 우선합니다
3. 추가: 새로운 경로의 로컬 토큰/속성은 상속된 항목과 함께 추가됩니다

오버라이드 규칙:

• 동일 경로 = 오버라이드: 상속된 그룹과 로컬 그룹이 동일 경로에 토큰을 정의하면 로컬 정의가 우선합니다
• 다른 경로 = 병합: 다른 경로의 토큰은 최종 결과에 공존합니다
• 완전 교체: 오버라이드할 때는 전체 토큰 정의가 교체되며(속성별 병합이 아님)

input-amount의 결과:

다단계 오버라이드 예시:

extended의 결과:

그룹은 순환 상속 체인을 생성해서는 안 됩니다 MUST NOT. 다음 패턴들은 무효입니다:

유효한 상속 패턴:

$extends는 디자인 토큰 별칭와 동일한 참조 포맷을 지원합니다.

$extends 오류 처리는 JSON Schema의 $ref 오류 패턴을 따릅니다:

• 해결 불가한 참조: 대상 그룹을 찾을 수 없을 때
• 잘못된 대상: 참조가 그룹이 아닌(예: 토큰) 대상을 가리킬 때
• 순환 참조: 확장 체인이 사이클을 만들 때
• 제약 위반: 로컬 속성이 상속된 제약을 위반할 때

도구는 JSON Schema 검증기에서 사용하는 것과 동일한 오류 감지 및 보고 패턴을 구현해야 합니다 MUST.

디자인 토큰 파싱을 구현하는 도구는 다음 중 하나를 선택할 수 있습니다 MAY:

1. $ref로 변환: $extends를 표준 JSON Schema $ref 문법으로 변환하고 기존 JSON Schema 라이브러리로 검증
2. 네이티브 구현: JSON Schema $ref 처리와 동일한 알고리즘을 사용하여 $extends를 직접 구현
3. 하이브리드 접근: 검증에는 JSON Schema 라이브러리를 사용하되 디자인 토큰 고유의 참조 문법을 유지

구현 방식에 관계없이 의미적 동작은 JSON Schema 2020-12 이상에 명시된 $ref와 동등해야 합니다 MUST.

이 명세는 $extends를 JSON Schema의 $ref 키워드에 대한 문법적 설탕으로 정의하며, 디자인 토큰 전용 참조 문법을 제공하면서도 동등한 동작을 유지합니다. 위에서 설명한 딥 머지 의미론은 JSON Schema 2020-12가 동반 속성과 함께 $ref를 처리하는 방식과 일치합니다.

JSON Schema에 익숙한 구현자는 $extends 동작을 다음과 같이 이해할 수 있습니다:

• "$extends": "{group}"를 "$ref": "#/group"로 변환
• 형제 속성 평가와 함께 JSON Schema 2020-12의 $ref 해석 적용

이 명세를 구현하는 도구는 다음을 선택할 수 있습니다 MAY:

1. 변환 접근: $extends를 $ref로 변환하고 JSON Schema 라이브러리 사용
2. 직접 구현: 위에 설명된 딥 머지 동작을 직접 구현
3. 하이브리드 접근: 디자인 토큰 문법을 유지하면서 검증에 JSON Schema 사용

구현 방식에 관계없이 사용자에게 보이는 동작은 본 명세에 설명된 딥 머지 의미론과 일치해야 합니다 MUST.

도구는 [rfc6901]에 정의된 대로 JSON Pointer 참조를 $ref 속성을 사용하여 지원해야 합니다 MUST:

그룹을 처리할 때 도구는 다음 해석 순서를 따라야 합니다 MUST:

1. 로컬 토큰 - $value 속성을 가진 직계 자식
2. 루트 토큰 - $root 이름을 가진 토큰
3. 확장된 토큰 - $extends를 통해 상속된 토큰(오버라이드되지 않은 경우)
4. 중첩 그룹 - 재귀적으로 처리

토큰 경로는 그룹 이름과 토큰 이름을 마침표(.)로 연결하여 구성됩니다. 예약된 토큰 이름 $root는 명시적이고 모호하지 않은 참조를 유지하기 위해 경로에 포함됩니다.

예시:

타입 해석은 다음 우선순위 규칙을 따릅니다:

1. 토큰의 명시적 $type 속성 (가장 높은 우선순위)
2. 해석된 그룹의 $type 속성 ($extends 해석 후)
3. 부모 그룹의 $type 속성 (계층을 따라 올라감)
4. 타입을 결정할 수 없으면 토큰은 무효

확장과 함께하는 타입 해석: $extends가 JSON Schema $ref 의미론을 따르므로, 타입 상속 동작은 명시적 병합 규칙보다는 제약 검증에 의해 결정됩니다. 로컬 타입 제약은 JSON Schema 검증 패턴에 따라 상속된 제약과 함께 평가됩니다.

이 예시에서 그룹 extended는 로컬 $type: "dimension" 제약과 참조된 base 그룹의 적용 가능한 제약을 모두 만족해야 하며, 이는 JSON Schema 제약 해석 규칙을 따릅니다.

도구는 다음에서의 순환 참조를 감지하고 오류를 발생시켜야 합니다 MUST:

• 토큰 별칭(aliases) ({token} 참조)
• 그룹 확장($extends 참조)
• JSON Pointer 참조($ref 속성, 지원되는 경우)

$extends에 대한 순환 참조 감지는 JSON Schema $ref의 요구 사항과 동일합니다. 도구는 사이클 감지를 위한 JSON Schema 검증기가 사용하는 알고리즘을 구현하는 것이 권장됩니다 SHOULD.

도구는 그룹 a, b, c에 영향을 미치는 오류로 이를 보고해야 합니다 MUST.

해석된 토큰:

• {input-amount.field.width} → { "value": 100, "unit": "px" } (오버라이드됨)
• {input-amount.field.background} → #ffffff (input에서 상속됨)

이 예시는 구성요소가 기본 구성요소를 확장하면서 특정 토큰은 오버라이드하고 다른 토큰은 상속받는 주요 사용 사례를 보여줍니다.

이 구조는 다음과 같은 토큰 접근을 생성합니다:

그룹을 사용하면 토큰 파일 작성자가 토큰 파일을 더 잘 구성할 수 있습니다. 관련 토큰을 그룹으로 중첩하여 팀의 명명 규칙이나 사고 모델에 맞출 수 있습니다. 수동으로 파일을 작성할 때 그룹을 사용하면 반복 접두사가 많은 평탄한 토큰 목록보다 덜 장황합니다.

예를 들면:

...는 다음과 같은 평탄한 구조보다 타이핑하기 편하고 읽기 쉬울 가능성이 큽니다:

GUI를 통해 토큰을 선택하거나 편집할 수 있는 도구는 그룹 구조를 사용하여 적절한 점진적 공개 방식(예: 접이식 트리 뷰)을 표시할 수 있습니다 MAY.

토큰 이름은 같은 파일 내에서 고유하다고 보장되지 않습니다. 동일한 이름이 서로 다른 그룹에서 사용될 수 있습니다. 또한, 변환 도구는 코드의 변수처럼 고유하게 식별 가능한 방식으로 디자인 토큰을 내보내야 할 MAY 있습니다. 따라서 변환 도구는 디자인 토큰의 경로를 사용해야 합니다. 경로는 파일 내에서 고유합니다 SHOULD.

예를 들어, 변환 도구인 Style Dictionary는 다음과 같은 디자인 토큰 파일을 사용할 수 있습니다:

...그리고 경로를 연결하여 변수 이름을 만들면 다음과 같이 Sass 변수로 출력할 수 있습니다:

중괄호 구문은 완전한 토큰 값 전체을 참조하도록 설계되었으며, 항상 대상 토큰의 $value 속성으로 해석됩니다.

이 예에서 {colors.blue}는 전체 색상 객체 {"colorSpace": "srgb", "components": [0, 0.4, 0.8], "hex": "#0066cc"}로 해석됩니다.

중요: 중괄호 참조는 오직 $value 속성을 가진 완전한 토큰(객체)만 대상이 될 수 있으며, 토큰 값 내부의 개별 속성이나 문서의 임의 위치는 대상으로 할 수 없습니다.

토큰 값의 특정 속성이나 문서 구조의 다른 부분에 접근해야 하는 고급 사용 사례를 위해, 토큰은 [rfc6901]에 정의된 JSON Pointer 표기법을 $ref 속성으로 지원해야 합니다. 본 명세를 구현하는 도구는 JSON Pointer 구문을 반드시 지원해야 합니다 MUST.

이 예에서:

• "$ref": "#/colors/blue/$value"는 "{colors.blue}"와 동등합니다
• "$ref": "#/colors/blue/$value/components/0"는 blue 색상의 첫 번째(빨강) 구성 요소(0)에만 접근합니다

주요 차이점:

중괄호 참조의 경우:

1. 참조 파싱: {group.token}에서 토큰 경로를 추출
2. 경로 분할: ["group", "token"] 같은 세그먼트로 변환
3. 토큰으로 이동: 대상 토큰 객체를 찾음
4. 토큰 검증: 대상에 $value 속성이 있는지 확인
5. 토큰 값 반환: $value 내용을 추출하여 반환
6. 순환 검사: 해석 중인 참조 스택을 유지하여 사이클 검사

JSON Pointer 참조의 경우:

1. JSON Pointer 파싱: #/path/to/target에서 경로 세그먼트를 추출
2. 문서 순회: 각 경로 세그먼트를 통해 탐색
3. JSON Pointer 규칙 적용:
   • 배열 컨텍스트에서는 숫자 세그먼트가 배열 인덱스가 됨
   • 객체 컨텍스트에서는 모든 세그먼트가 속성 이름이 됨
   • 이스케이프 문자(~0, ~1) 처리
4. 대상 검증: 최종 대상이 존재하고 접근 가능한지 확인
5. 값 반환: 해석된 값을 추출하여 반환

별칭은 다른 별칭을 참조할 수 있습니다 MAY. 이 경우 도구는 명시적 값이 있는 토큰을 찾을 때까지 모든 참조를 따라가야 합니다 MUST.

이 예에서 {semantic.link}은 체인을 따라 semantic.link → semantic.brand → base.primary로 이동하여 {base.primary}과 동일한 색상 값으로 해석됩니다.

참조는 순환이 되어서는 안 됩니다 MUST NOT. 디자인 토큰 파일에 순환 참조가 포함되어 있으면 그 체인의 모든 토큰 값은 알 수 없게 되며 사용자에게 적절한 오류 또는 경고 메시지가 표시되어야 합니다 SHOULD.

도구는 이 순환을 감지하여 해당 순환 체인에 속한 모든 토큰에 영향을 주는 오류로 보고해야 합니다 MUST.

이 예에서:

• layout.small은 base.spacing과 동일한 숫자 값(16)을 사용하지만 다른 단위(rem)를 사용합니다
• layout.large은 base.spacing과 동일한 단위(px)를 사용하지만 숫자 값은 다릅니다 (32)

이 예에서:

• 두 제목 모두 base.text에서 fontFamily와 lineHeight를 상속합니다
• 각 제목은 자체적인 fontSize와 fontWeight를 정의합니다
• 기본 글꼴 패밀리나 줄 높이가 변경되면 모든 제목에 자동으로 반영됩니다

• 루트 참조: #/ (문서 루트를 가리킴)
• 객체 속성: /로 각 레벨을 구분 (예: #/group/token/$value)
• 배열 인덱스: 배열 요소의 숫자 인덱스 사용 (예: #/color/$value/components/0)
• 특수 문자: JSON Pointer 규칙에 따라 이스케이프해야 함:
  • ~는 ~0으로
  • /는 ~1으로

디자인 토큰은 값을 $value 속성에 저장하므로, 토큰 값에 대한 JSON Pointer 경로는 예측 가능한 패턴을 따릅니다:

1. JSON Pointer 파싱: #/path/to/target에서 경로 세그먼트 추출
2. 문서 순회: 각 경로 세그먼트를 통해 탐색
3. JSON Pointer 규칙 적용:
   • 배열 컨텍스트의 숫자 세그먼트는 배열 인덱스가 됨
   • 객체 컨텍스트의 모든 세그먼트는 속성 이름이 됨
   • 이스케이프 문자(~0, ~1) 처리
4. 대상 검증: 최종 대상이 존재하고 접근 가능한지 확인
5. 값 반환: 해석된 값을 추출하여 반환

1. 참조 파싱: {group.token}에서 토큰 경로 추출
2. 경로 분할: ["group", "token"] 같은 세그먼트로 변환
3. 토큰으로 이동: 대상 토큰 객체를 찾음
4. 토큰 검증: 대상에 $value 속성이 있는지 확인
5. 토큰 값 반환: $value 내용을 추출하여 반환
6. 순환 검사: 해석 중인 참조 스택을 유지하여 사이클 검사

도구는 다음에 대해 오류를 보고해야 합니다 MUST:

• 잘못된 구문: 잘못된 중괄호 구문 또는 JSON Pointer 구문
• 해결 불가 경로: 대상 경로가 문서에 존재하지 않을 때
• 잘못된 토큰 참조: 중괄호 구문이 토큰이 아닌 대상을 타겟팅할 때
• 순환 참조: 참조 체인이 자기 자신으로 돌아오는 경우
• 타입 불일치: 참조된 값이 기대 타입과 호환되지 않을 때

디자인 토큰 파싱을 구현하는 도구는 다음을 반드시 수행해야 합니다 MUST:

1. 중괄호 구문 지원: 토큰 간 참조의 기본 메커니즘으로 중괄호 구문을 지원
2. JSON Pointer 지원: 문서 수준 참조 및 속성 접근을 위해 JSON Pointer 구문을 지원
3. 참조 대상 검증: 중괄호의 경우 유효한 토큰을, JSON Pointer의 경우 유효한 문서 위치를 가리키는지 검증
4. 명세에 정의된 해석 알고리즘에 따라 참조 해석: (Resolution Algorithms)
5. 순환 참조 탐지: 해석 시 순환 참조를 감지
6. 참조 보존: 메모리/저장소에서 참조를 보존하고 값이 필요할 때만 해석
7. 변경 전파: 참조된 토큰의 변경사항을 모든 별칭에 전파

명확한 해석:

도구는 다음에 대해 오류를 보고해야 합니다 MUST:

• 잘못된 참조 구문: 잘못된 중괄호 또는 JSON Pointer 구문
• 해결 불가 참조: 대상 경로가 존재하지 않음
• 순환 참조: 참조 체인이 자기 자신으로 돌아오는 경우
• 타입 불일치: 참조된 속성 타입이 토큰 타입과 호환되지 않을 때
• 잘못된 속성 경로: 존재하지 않는 속성을 참조하려는 시도

• $value.unit은 오직 "px" 또는 "rem"만 허용됩니다.
  • px: 뷰포트상의 이상화된 픽셀을 나타냅니다. Android에서는 dp, iOS에서는 pt에 해당합니다. 변환 도구는 필요에 따라 이들 또는 다른 동등 단위로 변환해야 할 SHOULD 수 있습니다.
  • rem: 시스템의 기본 글꼴 크기의 배수를 나타냅니다(사용자가 구성할 수 있을 MAY 있습니다). 1rem은 기본 글꼴 크기의 100%입니다. Android에서 1rem은 16sp와 동등합니다. 모든 플랫폼이 rem에 대응하는 단위를 갖고 있지는 않으므로, 변환 도구는 이러한 플랫폼에 대해 종종 기본 글꼴 크기(보통 16px)를 가정하여 손실이 있는(px 고정) 변환을 수행해야 할 MAY 수 있습니다.
• $value.value가 0인 경우에도 $value.unit은 여전히 요구됩니다.

• $value.unit은 오직 "ms" 또는 "s"만 허용됩니다.

문자열 형태의 스트로크 스타일 값은 다음 미리 정의된 값들 중 하나여야 합니다 MUST:

• solid
• dashed
• dotted
• double
• groove
• ridge
• outset
• inset

이 값들은 CSS의 동등한 "line style" 값들과 같은 의미를 가집니다. CSS 명세에 따라 정확한 렌더링은 구현에 따라 달라집니다. 예를 들어 dashed 스타일에서 대시와 간격의 길이는 도구마다 달라질 수 있습니다.

객체 형태의 스트로크 스타일 값은 다음 속성을 가져야 합니다 MUST:

• dashArray: dimension 값 또는 dimension 토큰에 대한 참조들의 배열입니다. 교대로 나타나는 대시와 간격의 길이를 지정합니다. 배열의 각 요소는 명시적 dimension 값 또는 dimension 토큰에 대한 참조여야 합니다. 만약 홀수 개의 값이 제공되면, 값들의 리스트는 짝수 개를 만들기 위해 반복됩니다.
• lineCap: 다음 미리 정의된 문자열 값 중 하나여야 합니다: "round", "butt" 또는 "square". 이 값들은 SVG의 stroke-linecap 속성과 동일한 의미를 가집니다.

문자열 값과 객체 값은 서로 배타적인 방식으로 스트로크 스타일을 표현합니다. 예를 들어 inset이나 groove 같은 일부 문자열 값은 테두리의 일부 영역에 대해 색상을 밝거나 어둡게 처리하는 구현 특화 방식이 필요하므로 dashArray와 lineCap로 표현할 수 없습니다. 반대로, 정확히 정의된 dashArray와 lineCap 조합이 dashed나 dotted 키워드와 동일한 시각적 결과를 보장하지는 않습니다(구현별 차이).

또한 일부 도구나 플랫폼은 이 타입이 표현할 수 있는 전체 범위의 스트로크 스타일을 지원하지 않을 수 있습니다. 이런 경우, 해당 플랫폼에서 네이티브로 지원하지 않는 strokeStyle 토큰을 표시하거나 내보낼 때 지원되는 가장 근접한 근사값으로 대체해야 합니다.

"가장 근접한 근사값"을 선택하는 구체적 방법은 구현에 따라 다릅니다. 그러나 다음 예시는 도구가 몇몇 시나리오에서 사용할 수 있는 대체 방식을 보여줍니다.