Initial Commit: Reinforced Knowledge Wiki v1.0 - Pure Origin

2026-04-20 14:26:57 +09:00
commit f4e731b115
2141 changed files with 63988 additions and 0 deletions
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-AUTO-176A7F
+category: "[[10_Wiki/💡 Topics/Programming & Language]]"
+confidence_score: 0.90
+tags: [auto-reinforced]
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD)"
+---
+
+# [[TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 정보 추출 중...
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **구조적 타이핑의 한계와 명목적 타이핑의 수복**
+  TypeScript는 객체의 구조(형태)가 같으면 동일한 타입으로 취급하는 구조적 타이핑을 사용합니다 [1, 2, 8]. 하지만 도메인 모델링에서는 이메일 주소와 사용자의 이름이 모두 문자열(`string`)이라고 해서 섞여 쓰이면 안 되는 '기본 타입에의 집착(Primitive Obsession)' 문제가 발생합니다 [3, 9]. 
+
+- **브랜디드 타입(Branded Types)을 통한 데이터 격리**
+  위 문제를 해결하기 위해 도메인 기반 설계에서는 브랜디드 타입(또는 Opaque Types)을 적극 활용합니다 [10, 11]. 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 속성(예: `unique symbol`)을 타입에 부여하여 `UserId`와 `OrderId`를 엄격히 분리합니다 [3, 9, 12]. 이를 통해 오직 검증된 데이터만이 시스템의 내부 로직으로 진입하도록 강제할 수 있습니다 [11, 12].
+
+- **"검증하지 말고 파싱하라 (Parse, Don't Validate)"**
+  외부에서 유입되는 언타입드(untyped) 데이터를 단순히 유효성 검사하는 것에 그치지 않고, 시스템 경계(Boundary)에서 한 번에 완벽히 타이핑된 구조로 변환(파싱)해야 한다는 설계 철학입니다 [4, 6, 13]. Zod와 같은 런타임 검증 라이브러리와 브랜디드 타입을 결합하면, 파싱을 통과한 데이터가 도메인 객체로서 안전하다는 것을 타입 시스템 레벨에서 영구적으로 보장할 수 있습니다 [6, 12, 14].
+
+- **식별 가능한 유니온(Discriminated Unions)과 완전성 검사(Exhaustiveness Checking)**
+  공통된 리터럴 속성(태그)을 사용하여 도메인의 복잡한 상태 머신을 모델링하는 기법으로, "불가능한 상태를 표현 불가능하게 만드는" 핵심 수비 기술입니다 [5, 15-18]. `switch`문과 `never` 타입을 결합한 완전성 검사(Exhaustiveness Checking) 기법을 사용하면, 도메인에 새로운 상태가 추가되었을 때 이를 처리하지 않은 모든 코드를 컴파일 에러로 즉각 찾아낼 수 있습니다 [18-22].
+
+- **불변성(Immutability) 확립**
+  상태의 무분별한 변경을 막기 위해 `readonly` 수식어를 적극적으로 사용하여 객체와 배열의 수정을 컴파일 수준에서 금지합니다 [23-25]. 단순한 얕은 보호를 넘어 매핑 타입과 조건부 타입을 결합한 재귀적 불변성(`DeepReadonly`)을 구축하면, 복잡한 도메인 엔티티의 무결성을 완벽하게 방어할 수 있습니다 [5, 25, 26].
+
+- **경계면의 방어: EPC와 `satisfies` 연산자**
+  객체 리터럴이 직접 할당될 때 작동하는 과잉 속성 체크(Excess Property Checking, EPC)를 통해 정의되지 않은 도메인 속성이 포함되는 것을 차단합니다 [8, 27, 28]. 간접 할당으로 인해 EPC가 우회되는 것을 막기 위해 `satisfies` 연산자를 활용하면, 객체의 구체적인 리터럴 타입 정보를 유지하면서도 안전하게 도메인 인터페이스 규격을 충족하는지 검증할 수 있습니다 [11, 29, 30].
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+- **Related Topics:** [[브랜디드 타입(Branded Types)]], [[식별 가능한 유니온(Discriminated Unions)]], [[구조적 타이핑(Structural Typing)]], [[Parse, Don't Validate]], [[완전성 검사(Exhaustiveness Checking)]]
+- **Projects/Contexts:** [[Zod 유효성 검사 라이브러리 연동]], [[프론트엔드 상태 머신(State Machine) 구현]]
+- **Contradictions/Notes:** TypeScript는 본래 Java나 C#과 달리 명목적 타이핑(Nominal Typing)을 네이티브로 지원하지 않고 구조적 타이핑으로 동작합니다. 따라서 엄격한 도메인 설계를 구축하려면, 컴파일러를 속이는 방식(가짜 속성 추가 등)인 브랜디드 타입과 같은 우회 전략을 인위적으로 도입해야만 명목적 타이핑의 효과를 얻을 수 있습니다.
+
+---
+*Last updated: 2026-04-18*
+- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md]]
+---