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,34 @@
+---
+id: P-REINFORCE-AUTO-5C8A49
+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 타입 시스템 (TypeScript Type System)"
+---
+
+# [[TypeScript 타입 시스템 (TypeScript Type System)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> TypeScript의 타입 시스템은 구조적 타이핑(Structural Typing)을 기반으로 하여, 객체의 실제 형태가 일치하면 호환성을 인정하는 유연성을 제공한다[1, 2]. 동시에 과잉 속성 체크(Excess Property Checking)나 `satisfies` 연산자와 같은 방어 기제를 통해 런타임 에러와 의도치 않은 데이터 유입을 컴파일 시점에 차단한다[3-6]. 이는 집합론(Set Theory)적 관점에서 타입을 정의하고 평가하며, 궁극적으로 복잡한 비즈니스 로직을 보호하고 견고한 인터페이스 설계를 가능하게 하는 아키텍처적 도구로 기능한다[2, 7-9].
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **구조적 타이핑과 집합론 (Structural Typing & Set Theory):** TypeScript는 객체의 속성과 메서드 형태가 같으면 동일한 타입으로 간주하는 "덕 타이핑(Duck Typing)" 방식의 구조적 타이핑을 채택한다[1, 2, 5]. 이 타입 시스템은 집합론으로 해석될 수 있으며, `never`는 공집합, `unknown`은 전체 집합을 의미하고, `A extends B`는 $A \subseteq B$ (부분집합)의 관계로 동작한다[5, 7, 8].
+- **타입 간의 호환성과 수비 전략:** 유연한 구조적 타이핑으로 인한 의도치 않은 데이터 유입을 막기 위해, TypeScript는 객체 리터럴 할당 시 정의되지 않은 속성을 차단하는 과잉 속성 체크(Excess Property Checking)를 수행한다[3, 5]. 간접 할당 시 EPC가 우회되는 한계를 극복하기 위해 도입된 `satisfies` 연산자는 대상의 요구사항 충족 여부를 검사하면서도 구체적인 리터럴 타입을 유지하도록 보장한다[4, 6, 10]. 또한, 구조가 같더라도 의미가 다른 데이터(예: 이메일과 일반 문자열)를 구별하기 위해 브랜디드 타입(Branded Types) 혹은 Opaque Types를 사용하여 컴파일 시점에 고유한 표식(`__brand` 등)을 부여하는 명목적 타이핑을 구현할 수 있다[10-13].
+- **상태 보호와 불변성 (Immutability):** `readonly` 수식어를 통해 객체와 배열의 수정을 컴파일 수준에서 금지함으로써 데이터의 무결성을 보장한다[14-16]. 기본적인 `readonly`는 얕은(shallow) 수준의 보호만 제공하므로, 중첩된 객체를 완벽히 보호하기 위해서는 재귀적 불변성을 보장하는 `DeepReadonly` 유틸리티 타입을 활용하여 데이터를 동결할 수 있다[16-18].
+- **식별 가능한 유니온과 완전성 검사 (Discriminated Unions & Exhaustiveness Checking):** 여러 상태를 가질 수 있는 합집합 타입을 다룰 때, 공통된 리터럴 속성을 태그(Discriminant)로 사용하여 타입을 안전하게 좁혀나간다(Narrowing)[19-21]. 이에 더해 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking) 기법을 도입하면, 유니온에 새로운 분기나 상태가 추가되었을 때 처리되지 않은 로직을 컴파일 에러로 포착하여 빈틈없는 방어가 가능하다[21-23].
+- **인터페이스 설계와 타입 별칭 (Interface vs Type Alias):** TypeScript 컴파일러는 인터페이스(`interface`) 처리 시 이름을 기준으로 관계를 캐싱하기 때문에 도메인 모델이나 객체 계약 정의에 성능상 유리하며 선언 병합(Declaration Merging) 확장을 지원한다[24-27]. 반면 교집합이나 합집합 등 더 엄격하고 복잡한 조합을 제어할 필요가 있는 곳에는 타입 별칭(`type`)을 사용하는 전략적 이원화가 권장된다[26-29].
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[과잉 속성 체크 (Excess Property Checking)]], [[satisfies 연산자]], [[불변성 (Immutability)]]
+- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[SOLID 원칙 기반 인터페이스 설계]], [[Toss Front SDK 설계]]
+- **Contradictions/Notes:** 인터페이스(`interface`)와 타입 별칭(`type`)의 선택과 관련하여, 선언 병합으로 인한 예기치 않은 구조 오버라이딩을 피하기 위해 오직 `type`만을 엄격하게 사용하는 팀 문화가 존재하는 반면[30, 31], 컴파일러 캐싱 최적화 관점에서는 객체 상속 시 `interface`를 우선할 것을 강력히 권고하는 이견이 존재한다[25, 26, 28]. 또한 `ts-pattern` 라이브러리는 철저한 타입 추론과 가독성을 주지만 네이티브 `if/switch` 구문에 비해 성능이 현저히 떨어지므로(초당 연산 횟수 기준 99% 저하 등), 간단한 분기문에 남용할 경우 불필요한 런타임 오버헤드를 유발할 수 있다는 비판적 견해가 있다[32-34].
+
+---
+*Last updated: 2026-04-18*
+- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 (TypeScript Type System).md]]
+---