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,33 @@
+---
+id: P-REINFORCE-AUTO-BF50D4
+category: "[[10_Wiki/💡 Topics/Design & Experience]]"
+confidence_score: 0.90
+tags: [auto-reinforced]
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Continuous Worker - TypeScript 라이브러리 타입 확장"
+---
+
+# [[TypeScript 라이브러리 타입 확장]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 정보 추출 중...
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **선언 병합(Declaration Merging)을 통한 확장**: TypeScript에서 동일한 이름의 인터페이스를 여러 번 선언하면, 컴파일러가 이를 자동으로 하나의 인터페이스로 합칩니다 [1, 2]. 이 기능은 라이브러리 코드를 작성할 때 사용자가 필요에 따라 선언부를 유연하게 확장(extend)할 수 있도록 허용하는 핵심 메커니즘입니다 [2, 3]. 반면, 타입 별칭(Type Alias)은 동일한 이름으로 재선언할 수 없으므로 이러한 방식의 확장이 불가능합니다 [2, 4].
+- **성능을 고려한 인터페이스 확장(extends) 전략**: 타입을 확장할 때 교집합(Intersection, `&`)을 사용하는 것보다 `interface extends`를 사용하는 것이 권장됩니다 [5, 6]. TypeScript 컴파일러는 인터페이스를 처리할 때 이름 기준으로 타입 관계를 캐싱하여 활용하지만, 교집합 연산은 사용될 때마다 속성을 재귀적으로 병합하고 계산해야 하므로 대규모 프로젝트나 라이브러리 사용 시 컴파일 성능을 저하시킬 수 있습니다 [5, 7, 8].
+- **외부 라이브러리 타입 선언 파일(.d.ts)**: 기존 JavaScript 라이브러리를 TypeScript에서 사용할 때는 구현부 없이 타입 정보만을 제공하는 선언 파일(`.d.ts`)이 필요합니다 [9]. 많은 인기 라이브러리들이 자체 타입을 제공하지만, 타입이 존재하지 않는 경우 사용자가 직접 모듈을 선언하여 타입 확장을 하거나 에러를 억제할 수 있습니다 [9].
+- **내부 코드와 외부 라이브러리 코드 간의 이원화 설계**: 개발 커뮤니티에서는 "내부는 Types, 외부는 Interfaces를 사용하라"는 전략이 제안되기도 합니다 [6]. 애플리케이션 내부 핵심 도메인 로직에서는 의도치 않은 선언 병합으로 인한 버그나 충돌을 막기 위해 타입 별칭(Type)을 사용하여 엄격하게 관리하는 것이 좋습니다 [2, 10]. 반대로 외부 라이브러리로 제공되거나 외부와의 소통이 잦은 계약 지점의 코드에서는 소비자의 유연한 확장을 위해 인터페이스(Interface)를 사용하는 것이 바람직합니다 [2, 3].
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+- **Related Topics:** [[선언 병합(Declaration Merging)]], [[Interface]], [[Type Alias]], [[교집합 타입(Intersection Type)]]
+- **Projects/Contexts:** [[외부 라이브러리 API 설계]], [[TypeScript 컴파일러 캐싱 최적화]], [[선언 파일(.d.ts)]]
+- **Contradictions/Notes:** 애플리케이션 내부 코드의 경우, 인터페이스의 확장성을 '의도치 않은 속성 병합(Bad Thing)'으로 간주하여 타입 별칭(Type Alias)의 사용을 선호하는 실무적 의견이 다수 존재합니다 [4, 10-12]. 하지만 외부 패키지나 라이브러리 생태계에서는 여전히 사용자에게 타입 확장을 허용하기 위해 인터페이스를 채택하는 것이 정석으로 평가받고 있습니다 [2, 3]. 또한, 객체를 확장할 때 교집합(`&`) 방식은 유연해 보이지만, 성능 이슈와 충돌 검사 한계로 인해 `interface extends` 방식에 비해 상대적으로 지양됩니다 [5, 7, 13].
+
+---
+*Last updated: 2026-04-18*
+- Raw Source: [[00_Raw/2026-04-20/TypeScript 라이브러리 타입 확장.md]]
+---