2nd/10_Wiki/Topics/Architecture/Design-System.md

---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Design-System|Design-System]]
last_updated: 2026-05-02
---

# [[Design-System|Design-System]]

## 📌 Brief Summary
> "조직의 시각적 언어: 단순한 UI 가이드를 넘어, 재사용 가능한 컴포넌트와 명확한 표준(심볼, 컬러, 간격 등)을 정의함으로써 디자이너와 개발자가 동일한 속도로 고품질의 사용자 경험을 양산하게 돕는 공유 지식 체계."

---

시스템 설계(System Design) 및 소프트웨어 아키텍처는 시스템의 다양한 구성 요소가 어떻게 결합하고 상호작용하는지를 보여주는 청사진이자 근본적인 구조적 결정을 내리는 과정이다 [1-3]. 이는 시스템의 성능, 확장성, 유지보수성, 보안 및 내결함성을 결정짓는 핵심 토대 역할을 한다 [4-6]. 초기 설계 단계에서의 선택은 이후 변경 비용이 매우 높기 때문에, 비즈니스 요구사항과 기술적 가능성을 종합적으로 고려한 전략적 의사결정이 필수적이다 [3, 7].

---

디자인 시스템은 명확한 표준에 따라 애플리케이션을 구축하기 위해 조립할 수 있는 재사용 가능한 컴포넌트의 모음입니다 [1]. 이는 브랜드의 시각적 정체성을 프로그래밍적으로 구현한 것으로, 통합된 디자인 언어를 제공합니다 [2]. 디자인 시스템의 핵심에는 색상, 간격, 타이포그래피와 같은 시각적 디자인의 원자 단위인 '디자인 토큰([[Design Tokens|Design Tokens]])'이 존재하며, 이를 통해 제품 및 플랫폼 전반의 일관성을 보장하고 디자인 및 엔지니어링 간의 공통 언어를 생성합니다 [1-3]. 대규모 엔터프라이즈 환경에서 디자인 시스템은 단순한 컴포넌트 라이브러리를 넘어선 일종의 '커뮤니케이션 프로토콜'로 기능합니다 [4].

---

디자인 시스템은 재사용 가능한 컴포넌트와 명확한 표준으로 구성되어 애플리케이션을 구축하는 데 사용되는 브랜드의 시각적 정체성 집합체입니다 [1, 2]. 이는 단순한 컴포넌트 라이브러리를 넘어 디자인과 엔지니어링 간의 커뮤니케이션 프로토콜 역할을 수행합니다 [3]. 디자인 시스템의 가장 핵심적인 구성 요소는 '디자인 토큰([[Design Tokens|Design Tokens]])'으로, 색상, 간격, 타이포그래피와 같은 시각적 디자인 원자들을 플랫폼에 종속되지 않는 변수 형태로 저장하여 여러 플랫폼에서 일관성과 확장성을 유지하도록 돕습니다 [1, 2].

## 📖 Core Content
디자인 시스템(Design-System)은 제품 개발 프로세스에서 일관성을 유지하기 위한 컴포넌트 라이브러리와 스타일 가이드의 집합입니다.

1.  **핵심 구성 요소**:
    *   **[[Design Tokens|Design Tokens]]**: 색상, 폰트 크기, 간격 등을 변수화한 최소 단위.
    *   **Pattern Library**: 버튼, 입력창 등 재사용 가능한 UI 컴포넌트들.
    *   **Guidelines**: '어떤 상황에 어떤 컴포넌트를 사용해야 하는가'에 대한 원칙.
2.  **왜 중요한가?**:
    *   **[[Efficiency|Efficiency]]**: 매번 새로 디자인/코딩할 필요 없이 기존 자산을 조립.
    *   **Scalability**: 수백 명의 개발자가 작업해도 하나의 앱처럼 느껴지는 일관성 유지.
    *   **Communication**: "그 파란색" 대신 "Primary-500"이라는 명확한 명칭으로 협업.

---

- **시스템 설계의 정의 및 범위**
  시스템 설계(소프트웨어 아키텍처)는 시스템의 고수준 구조, 구성 요소(컴포넌트), 그리고 이들 간의 관계(커넥터)를 정의하는 작업이다 [1, 6, 8]. 이는 기능적 요구사항뿐만 아니라 시스템이 얼마나 잘 수행되는지를 결정하는 비기능적 요구사항(품질 속성)을 만족시키기 위한 인프라 설계를 포함한다 [9, 10]. 시스템 설계는 구현 세부 사항과 분리된, 시스템이 수행해야 할 작업과 그 방법에 대한 전반적인 비전을 제시한다 [11].

- **핵심 목표 및 품질 속성(Quality Attributes)**
  훌륭한 시스템 설계는 모듈성, 캡슐화, 보안, 성능, 문서화를 보장해야 한다 [6]. 더불어 시스템의 확장성(Scalability), 유지보수성(Maintainability), 유연성(Flexibility), 신뢰성(Reliability)을 확보하여 급변하는 비즈니스 환경과 트래픽 부하에 대응할 수 있어야 한다 [12-15]. ISO 25010 표준과 같은 품질 모델은 기능 적합성, 성능 효율성, 호환성 등을 객관적으로 평가하는 기준이 된다 [15].

- **설계 프로세스의 4단계 핵심 활동**
  1. **아키텍처 분석(Architectural Analysis)**: 시스템이 운영될 환경을 이해하고 기능적/비기능적 요구사항(성능, 보안, 법적 제약 등)을 도출한다 [16, 17].
  2. **아키텍처 합성(Architectural Synthesis/Design)**: 요구사항을 바탕으로 아키텍처 패턴을 결정하고 구조를 설계한다 [18].
  3. **아키텍처 평가(Architecture Evaluation)**: 설계가 요구사항을 얼마나 잘 충족하는지 ATAM 등의 방법을 통해 평가하고 절충안을 찾는다 [18].
  4. **아키텍처 진화(Architecture Evolution)**: 변화하는 요구사항과 환경에 맞춰 기존 아키텍처를 유지보수하고 적응시킨다 [19].

- **아키텍처 패턴과 디자인 패턴의 차이**
  아키텍처 패턴(Layered, Microservices, Event-Driven 등)은 시스템 전체의 거시적(Macro-level) 구조와 컴포넌트 간의 상호작용을 다루어 확장성이나 성능 등의 거시적 문제를 해결한다 [3, 20-22]. 반면, 디자인 패턴(Singleton, Observer 등)은 특정 컴포넌트나 클래스 내부의 미시적(Micro-level) 구조나 행동 문제를 해결하는 재사용 가능한 솔루션이다 [20, 22, 23].

---

*   **디자인 시스템의 중요성 및 목적**
    디자인 시스템은 제품과 여러 플랫폼 간의 시각적 일관성을 보장하고, 디자인 및 개발 워크플로우의 속도를 높이며, 팀과 제품 전반에 걸쳐 디자인을 확장하는 데 필수적인 역할을 합니다 [3]. 또한 시스템을 통해 리브랜딩 및 스타일 업데이트를 훨씬 용이하게 만들고, 디자이너와 엔지니어 간의 명확한 공유 언어를 생성하여 협업의 효율성을 극대화합니다 [3].

*   **디자인 토큰 (Design Tokens)의 역할과 계층 구조**
    디자인 시스템의 가장 기본 구성 요소인 디자인 토큰은 플랫폼에 구애받지 않는(platform-agnostic) 디자인 변수로, 색상, 타이포그래피, 간격, 애니메이션 등에 대한 원시 값을 저장합니다 [1, 2]. 토큰은 테마 적용의 용이성과 유연성을 위해 3단계 계층 구조를 갖습니다:
    1. **글로벌 토큰 (Primitives):** 맥락이 배제된 원시 값(예: `--blue-500: #3b82f6`)으로 구성된 디자인 시스템의 기본 팔레트입니다 [5, 6].
    2. **별칭 토큰 (Alias/Semantic):** 글로벌 토큰을 참조하며 특정한 의도나 사용 맥락을 설명합니다(예: `--color-primary: var(--blue-500)`) [5, 6].
    3. **컴포넌트 토큰 (Component-specific):** 특정 UI 요소에 직접적으로 범위가 지정된 토큰으로, 시스템의 다른 부분에 영향을 주지 않고 개별 컴포넌트 단위의 세밀한 조정(예: `--button-bg-primary: var(--color-primary)`)을 가능하게 합니다 [5, 6].

*   **플랫폼 간 확장 및 자동화 파이프라인**
    웹, iOS, Android 등 다중 플랫폼에 걸친 대규모 프로젝트의 경우, 디자인 토큰은 일반적으로 JSON과 같은 중립적인 형식으로 저장됩니다 [7]. 그런 다음 '[[Style Dictionary|Style Dictionary]]' 또는 'Theo'와 같은 도구를 사용하여 이 JSON 데이터를 웹용 CSS 변수, Android용 XML, iOS용 Swift 등 각 플랫폼에 특화된 코드로 자동 변환합니다 [7]. 이러한 '단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])' 접근 방식은 수동으로 인한 오류를 제거하고 전체 제품 생태계에 걸쳐 엄격한 시각적 일관성을 보장합니다 [7]. 

*   **반응형 디자인 및 컴포넌트화의 융합**
    현대적인 디자인 시스템에서는 반응형 동작을 개별 페이지가 아닌 '컴포넌트 자체의 속성'으로 취급합니다 [8]. 반응형 기본값(예: 컨테이너 쿼리를 활용한 구성)을 갖춘 컴포넌트를 시스템 수준에서 구축하면, 해당 컴포넌트를 사용하는 모든 팀이 별도의 미디어 쿼리 작업 없이 동일하고 올바른 동작을 상속받게 되며 이는 유지보수성과 확장성을 비약적으로 향상시킵니다 [8].

---

*   **디자인 시스템의 목적과 역할**
    디자인 시스템은 여러 제품 및 플랫폼 전반에 걸쳐 일관성을 보장하고, 디자인과 개발 워크플로우의 속도를 높이며, 팀 간의 공통 언어를 생성합니다 [4]. 대규모 엔터프라이즈 환경에서 디자인 시스템은 디자인 결정(예: [[Figma|Figma]]에서의 색상 변경)이 웹, 모바일(iOS, Android) 등의 여러 플랫폼으로 자동 전파되게 하는 시스템적 사고의 결과물로, 단순히 예쁜 인터페이스가 아닌 진정으로 유지보수 가능한 소프트웨어 시스템을 구축하는 기준이 됩니다 [3, 5].

*   **디자인 시스템의 구성 요소: 디자인 토큰(Design Tokens)**
    디자인 토큰은 디자인 시스템에 동력을 제공하는 시각적 디자인의 원자(원시 값)입니다 [1]. 이는 플랫폼에 구애받지 않는(platform-agnostic) 특징을 가지며, 단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])으로서 JSON 등의 형식으로 저장됩니다 [1, 6]. 이후 [[Style Dictionary|Style Dictionary]]와 같은 변환 도구를 통해 웹용 CSS 변수, Android용 XML, iOS용 Swift 코드 등으로 변환되어 배포됩니다 [6-8]. 

*   **디자인 토큰의 계층 구조 (Hierarchy)**
    확장성과 유연성을 위해 디자인 토큰은 일반적으로 3단계 계층으로 구성됩니다 [9, 10].
    1.  **글로벌 토큰 (Global Tokens / Primitives):** 컨텍스트가 없는 원시 값입니다. (예: `--blue-500: #3b82f6`) [9, 10]
    2.  **가명/시맨틱 토큰 (Alias / Semantic Tokens):** 글로벌 토큰을 참조하여 특정 맥락이나 의도를 부여합니다. (예: `--color-primary: var(--blue-500)`) [9, 10]
    3.  **컴포넌트 토큰 (Component Tokens):** 특정 UI 요소에만 국한된 토큰입니다. (예: `--button-bg: var(--color-primary)`) 이를 통해 다른 시각적 시스템에 영향을 주지 않고 개별 컴포넌트를 조정할 수 있습니다 [9, 10].

*   **CSS 아키텍처 및 반응형 컴포넌트와의 결합**
    현대의 디자인 시스템은 반응형 동작(Responsive [[Behavior|Behavior]])을 페이지가 아닌 '컴포넌트의 속성'으로 취급합니다 [11]. 버튼, 모달, 데이터 테이블과 같은 컴포넌트가 컨텍스트를 인지하고 스스로 반응형으로 동작하도록 구축되면, 동일한 레이아웃 문제를 반복해서 해결할 필요가 없습니다 [11, 12]. 또한, BEM과 같은 CSS 구조화 방법론은 컴포넌트를 독립적이고 재사용 가능하게 만들어 디자인 시스템과 자연스럽게 결합되며 [13], Panda CSS와 같은 현대적 [[CSS-in-JS|CSS-in-JS]] 도구들은 디자인 시스템과 테마(Theme)를 내장 지원하여 아키텍처의 유지보수성을 극대화합니다 [14, 15].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌**: 과거에는 종이에 인쇄된 '스타일 가이드 정책'이었으나, 현대 정책은 코드와 디자인 도구([[Figma|Figma]] 등)가 실시간 동기화되는 '디지털 자산 정책'으로 진화함(RL Update).
- **정책 변화(RL Update)**: 생성 AI가 디자인 시스템의 가이드라인을 학습하여 자동으로 UI를 생성하거나 코드로 변환해주는 'Gen-UI 기반 자동 설계 정책'이 도입되며 디자이너의 역할이 '시스템 관리자 정책'으로 변화 중임.

---

- **절충(Trade-off)의 법칙**
  소프트웨어 아키텍처의 기본 법칙 중 하나는 "모든 것은 절충(Trade-off)이다"라는 점이다 [7, 24]. '완벽한 아키텍처'는 존재하지 않으며, 고도의 보안을 확보하면 응답 성능(Latency)에 손해를 볼 수 있고, 빠른 개발을 우선하면 향후 유지보수성이 저하될 수 있다 [24, 25].
- **패턴 선택에 따른 제약과 부작용**
  시스템 설계 시 모놀리식 아키텍처를 선택하면 초기 개발과 배포가 단순하지만 시스템이 커질수록 확장성과 유지보수가 어려워진다 [26, 27]. 반면, 마이크로서비스 아키텍처(MSA)를 적용하면 확장성과 독립적 배포가 뛰어나지만 네트워크 지연, 최종 일관성(Eventual Consistency)에 따른 데이터 일관성 문제, 그리고 분산 시스템 관리를 위한 운영 복잡성이 크게 증가한다 [28-31].
- **아키텍처 침식(Architecture Erosion)**
  초기 설계가 훌륭하더라도 시간이 지남에 따라 기술 부채가 축적되거나 의도된 아키텍처 원칙을 위반하면서 실제 구현과 아키텍처 간의 간극이 발생하는 '아키텍처 침식' 현상이 나타날 수 있다 [32]. 이는 시스템 성능을 저하시키고 유지보수 비용을 급증시킨다 [33].
- **의사결정 안티패턴(Anti-patterns)**
  잘못된 선택을 두려워하여 결정을 미루는 현상이나, 결정 사항을 제대로 문서화(ADR)하지 않아 동일한 논의가 끝없이 반복되는 상황은 시스템 설계 단계에서 흔히 발생하는 안티패턴이므로 지양해야 한다 [34].

## 🔗 Knowledge Connections
- [[Scalability|Scalability]], [[Branding|Branding]], [[클린 아키텍처 (Clean Architecture)|Clean-[[Architecture]]-TypeScript]], User Experience (UX), [[Frontend|Frontend]]
- **Modern Tech/Tools**: Figma, Storybook, Material UI (MUI), [[Tailwind CSS|Tailwind CSS]], [[Headless UI|Headless UI]].
---

---

### Related Concepts

#### [아키텍처 패턴 (Architectural Patterns)]
- [[Microservices Architecture]]
  - 연결 이유: 대규모 시스템 설계 시 단일 애플리케이션을 작고 독립적인 서비스로 분할하는 가장 핵심적인 현대 아키텍처 접근법이다 [35, 36].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 시스템에서의 독립적 배포, 개별 확장성, 장애 격리(Fault Tolerance) 원리 및 서비스 간 통신 복잡성을 이해할 수 있다 [28, 37, 38].
- [[Event-Driven Architecture]]
  - 연결 이유: 컴포넌트 간 비동기 이벤트를 통해 소통하는 설계 방식으로, 실시간 처리와 고도의 확장성을 요구하는 시스템 설계에 필수적이다 [39, 40].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 느슨한 결합(Loose Coupling), 상태 변화에 따른 시스템의 비동기 반응, 브로커(Broker) 및 메디에이터(Mediator) 토폴로지의 구조적 차이를 학습할 수 있다 [41, 42].
- [[Layered Architecture]]
  - 연결 이유: 가장 널리 사용되는 전통적인 패턴으로, 시스템을 수평적인 계층(예: 프레젠테이션, 비즈니스, 데이터)으로 나누어 설계하는 기본 구조이다 [43, 44].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 관심사의 분리(Separation of Concerns), 계층 간 격리 원칙, 그리고 모놀리식 시스템의 유지보수 및 테스트 방법론을 이해할 수 있다 [45-47].

#### [아키텍처 평가 및 관리 (Evaluation & Management)]
- [[ATAM (Architecture Tradeoff Analysis Method)]]
  - 연결 이유: 시스템 설계가 비즈니스 및 품질 목표를 얼마나 잘 충족하는지 평가하는 표준 방법론이다 [18, 24].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 구체적인 시나리오를 바탕으로 아키텍처의 리스크, 민감도, 절충점(Trade-off points)을 식별하고 객관적으로 평가하는 실무 기법을 배울 수 있다 [24, 25].
- [[ADR (Architecture Decision Record)]]
  - 연결 이유: 아키텍처 의사결정의 맥락, 결정된 사항, 거절된 대안 및 위험 요소 등을 기록하여 시스템 설계의 타당성을 남기는 핵심 문서화 기법이다 [34, 48].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀의 변동이나 시간이 지난 후에도 설계 결정을 추적 가능(Comprehensible)하게 유지하여, 아키텍처의 일관성을 보호하는 관리 방법을 파악할 수 있다 [48, 49].

### Deeper Research Questions

- 단일 모놀리식(Monolithic) 시스템에서 마이크로서비스(Microservices) 아키텍처로 마이그레이션할 때, 데이터베이스 분리와 도메인 분해(Decomposition)를 위해 고려해야 할 시스템 설계 원칙은 무엇인가?
- 이벤트 기반 아키텍처(Event-Driven Architecture) 설계 시, 서비스 간 데이터의 '최종 일관성(Eventual Consistency)'을 보장하면서도 분산 트랜잭션의 복잡성을 관리하기 위한 Saga 패턴 등의 적용 전략은 어떠한가?
- 대용량 데이터 및 트래픽 폭증이 예상되는 시스템 설계에서, 기존 관계형 데이터베이스의 병목을 해결하기 위한 Space-Based 아키텍처의 작동 원리와 한계는 무엇인가?
- 조직의 구조가 소프트웨어 시스템의 설계 구조에 반영된다는 '콘웨이의 법칙(Conway's Law)'은 매크로 수준의 아키텍처 설계와 팀 구성에 어떤 영향을 미치는가?
- 소프트웨어 아키텍처 침식(Erosion) 현상을 초기에 진단하고 이를 방지하기 위해, CI/CD 파이프라인과 정적 코드 분석 등 자동화된 개발 프로세스를 어떻게 설계에 통합해야 하는가?

### Practical Application Contexts

- **Implementation:** 개발자는 시스템 설계 단계에서 확정된 아키텍처 패턴(예: 헥사고날 아키텍처의 포트와 어댑터)에 따라 코드베이스 구조를 짜고, 비즈니스 로직과 외부 인프라스트럭처(DB, UI 등) 간의 의존성을 엄격히 격리하여 구현한다 [50, 51].
- **System Design:** 소프트웨어 아키텍트는 비즈니스 목표(예: 빠른 타임 투 마켓, 대규모 트래픽 수용)와 제약 사항을 바탕으로, 모놀리식, 마이크로서비스, 또는 서버리스 등 거시적 아키텍처를 결정하고 시스템의 논리적, 물리적 인프라 청사진을 도출한다 [2, 52-55].
- **Operation / Maintenance:** 설계된 아키텍처는 시스템 운영 및 장애 복구 능력에 직결된다. 분산된 마이크로서비스 기반 시스템에서는 각 서비스별로 독립적 확장이 가능하나, 운영 복잡성을 낮추기 위해 서킷 브레이커, 분산 로깅 및 트레이싱과 같은 관측성(Observability) 도구가 필수적으로 병행 운영되어야 한다 [31, 56, 57].
- **Learning Path:** 시스템 설계 학습은 기초 컴퓨터 과학 및 객체 지향 원칙 이해 -> 디자인 패턴(클래스/객체 단위) 습득 -> 전통적인 N-Tier 계층형 모놀리식 아키텍처 구현 -> MSA 및 EDA와 같은 분산 시스템 설계 패턴 탐구 -> 시스템 성능 평가 및 절충 분석(ATAM) 역량 확보의 단계로 진행된다.
- **My Project Relevance:** 현재 진행 중인 프로젝트의 팀 규모, 예산, 예상 트래픽을 평가하여 초기에는 비용과 개발 속도가 유리한 모듈형 모놀리스(Modular Monolith)나 계층형 구조로 시작하고, 서비스가 성장함에 따라 병목이 발생하는 도메인만 점진적으로 마이크로서비스나 서버리스로 분리하는 실용적인 기술 전략을 수립하는 데 적용할 수 있다 [58-62].

### Adjacent Topics

- [[Design Patterns]]
  - 확장 방향: 아키텍처 패턴이 시스템 전반의 뼈대와 컴포넌트 간 통신을 다룬다면, 디자인 패턴은 그 하위 레벨에서 특정 모듈 내 객체의 생성, 구조, 행위와 관련된 구체적인 구현 문제(예: Singleton, Factory, Observer)를 해결하는 기법으로 확장 학습할 수 있다 [20-22].
- [[Domain-Driven Design (DDD)]]
  - 확장 방향: 복잡한 시스템 설계 시 비즈니스 도메인을 모델링하고 '바운디드 컨텍스트(Bounded Context)'를 식별하는 방법을 학습하여, 마이크로서비스나 헥사고날 아키텍처의 서비스 경계를 올바르게 나누는 핵심 기준을 확보할 수 있다 [63-65].

---
*Last updated: 2026-05-02*

---

- **Related Topics:** [[디자인 토큰 (Design Tokens)|디자인 토큰 (Design Tokens]], 컴포넌트 기반 아키텍처 (Component-Based Architecture), 반응형 웹 디자인 ([[Responsive Web Design|Responsive Web Design]]
- **Projects/Contexts:** 대규모 엔터프라이즈 프론트엔드 아키텍처 구축, 다중 플랫폼(Web, iOS, Android) UI 스타일 동기화 파이프라인
- **Contradictions/Notes:** 소스 내에 명시적인 상충 의견은 없으나, 순수 BEM과 같은 수동적인 CSS 방법론이 갖는 '인간 의존성(Human Error)' 한계를 극복하기 위해, 대규모 팀에서는 디자인 시스템과 토큰 자동화(Style Dictionary 등)를 도입하여 기술 부채를 줄이고 유지보수성을 확보하는 것이 강력히 권장됩니다 [9-11]. 

---
*Last updated: 2026-04-26*

---

- **Related Topics:** [[디자인 토큰 (Design Tokens)|디자인 토큰(Design Tokens]], 반응형 웹 디자인(Responsive Web Design), BEM 방법론, 컴포넌트 기반 아키텍처([[Component-Based Architecture|Component-Based Architecture]]
- **Projects/Contexts:** 대규모 엔터프라이즈 프론트엔드 아키텍처(Enterprise [[Frontend|Frontend]] Architecture), [[크로스 플랫폼 UI 개발(Cross-Platform UI Development)|크로스 플랫폼 UI 개발(Cross-Platform UI Development]]
- **Contradictions/Notes:** 디자인 시스템은 일관된 타이포그래피나 색상 스케일을 강제하기 위해 존재하지만, [[Tailwind CSS|Tailwind CSS]]와 같은 유틸리티 우선 프레임워크를 사용할 때 개발자가 임의의 값(arbitrary values, 예: `w-[347px]`)을 남용하게 되면 디자인 시스템의 사전 정의된 규칙을 우회하게 되어 일관성을 해칠 수 있습니다 [16].

---
*Last updated: 2026-04-26*