chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)

이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해 끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은 과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업. 도구: Datacollect/scripts/link_reconcile_apply.mjs Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-08 12:24:15 +09:00
parent 2ddf30f8e4
commit d8a80f6272
768 changed files with 1085 additions and 1085 deletions
@@ -35,7 +35,7 @@ tech_stack:

 ## 🔗 지식 연결 (Graph)
 - **Related Topics:** [[선언 병합(Declaration Merging)]], [[Type_Alias|Type Alias]], [[교집합 타입(Intersection Type)]]
- **Projects/Contexts:** [[외부 라이브러리 API 설계]], [[TypeScript 컴파일러 캐싱 최적화]], [[선언 파일(.d.ts)]]
+- **Projects/Contexts:** [[외부 라이브러리 API 설계]], [[TypeScript 컴파일러 캐싱 최적화]], [[선언 파일(dts)]]
 - **Contradictions/Notes:** 애플리케이션 내부 코드의 경우, 인터페이스의 확장성을 '의도치 않은 속성 병합(Bad Thing)'으로 간주하여 타입 별칭(Type Alias)의 사용을 선호하는 실무적 의견이 다수 존재합니다 [4, 10-12]. 하지만 외부 패키지나 라이브러리 생태계에서는 여전히 사용자에게 타입 확장을 허용하기 위해 인터페이스를 채택하는 것이 정석으로 평가받고 있습니다 [2, 3]. 또한, 객체를 확장할 때 교집합(`&`) 방식은 유연해 보이지만, 성능 이슈와 충돌 검사 한계로 인해 `interface extends` 방식에 비해 상대적으로 지양됩니다 [5, 7, 13].

 ---
@@ -41,7 +41,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[재귀적 불변성 (DeepReadonly)]], [[브랜디드 타입 (Branded Types)]], [[SOLID 원칙]]
+- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[재귀적 불변성 (DeepReadonly)]], [[브랜디드 타입 (Branded Types)]], [[SOLID 원칙]]
 - **Projects/Contexts:** [[Toss Front SDK의 Facade 패턴 적용 사례]]
 - **Contradictions/Notes:** TypeScript의 구조적 타이핑은 최소 요건만 충족하면 호환성을 허용하므로 매우 유연하지만, 이메일 주소와 이름이 같은 `string`으로 취급되는 등 "기본 타입에의 집착(Primitive Obsession)" 문제를 야기한다 [11]. 이를 방어하기 위해 컴파일 시점에만 존재하는 고유 속성을 부여하는 브랜디드 타입(Branded Types)을 사용하여 데이터의 무분별한 혼용을 차단해야 한다 [10, 11].

@@ -48,7 +48,7 @@ TypeScript의 객체 타입은 명목적 타이핑(Nominal Typing)과 달리 명
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[초과 속성 검사 (Excess Property Checking)]], [[선언 병합 (Declaration Merging)]], [[satisfies 연산자]]
+- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[초과 속성 검사 (Excess Property Checking)]], [[선언 병합(Declaration Merging)]], [[satisfies 연산자]]
 - **Contradictions/Notes:** 소스 간 의견 대립이 존재합니다. 일부 개발자(소스 52, 138, 141)는 캐싱 성능 최적화와 외부 확장을 위한 선언 병합 기능 때문에 '인터페이스(Interface) 우선 사용'을 강력히 주장하지만, 또 다른 현업 개발자(소스 138, 140, 147)는 의도치 않은 선언 병합으로 인해 런타임 로직이 오염될 위험과 일관된 문법을 이유로 '모든 상황에서 타입 별칭(Type)만을 사용하는 규칙'을 조직 내에 강제하는 것이 장기 유지보수에 유리하다고 반박합니다.

 ---
@@ -38,7 +38,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[선언 병합(Declaration Merging)]], [[타입 별칭(Type Alias)]]
+- **Related Topics:** , [[선언 병합(Declaration Merging)]], [[타입 별칭 (Type Alias)]]
 - **Contradictions/Notes:** 소스에 따르면, 일반적인 애플리케이션 코드 작성 시에는 엄격한 관리가 가능한 타입 별칭(Type)을 선호하는 실무 의견이 많지만, 외부 라이브러리 사용자가 타입을 확장해야 하는 특수한 상황에서는 선언 병합이 가능한 인터페이스(Interface)가 절대적으로 더 적합하다는 뚜렷한 용도 차이를 보입니다 [1, 2, 5, 7].

 ---
@@ -34,7 +34,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[관심사의 분리 (Separation of Concerns, SoC)]]
+- **Related Topics:** , [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[관심사의 분리 Separation of Concerns, SoC]]
 - **Projects/Contexts:** 복잡한 비즈니스 도메인 모델링 [1], 객체 지향 및 모듈러 소프트웨어 시스템 설계 [3, 5], 마이크로서비스로의 서비스 분리 및 마이그레이션 [2]
 - **Contradictions/Notes:** 소스 내에 바운디드 컨텍스트의 효용이나 개념에 대한 상반된 주장은 존재하지 않으며, 일관되게 시스템 복잡성 완화와 마이크로서비스 확장을 위한 핵심 기반으로 설명되고 있습니다.

@@ -35,7 +35,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[완전성 검사 (Exhaustiveness Checking)]]
+- **Related Topics:** , [[완전성 검사(Exhaustiveness Checking)]]
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.

 ---
@@ -34,7 +34,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[타입 별칭(Type Alias)]]
+- **Related Topics:** , [[타입 별칭 (Type Alias)]]
 - **Contradictions/Notes:** 소스에 따르면 라이브러리 제작 관점에서는 소비자에게 확장을 허용하는 매우 유용한 기능으로 평가받지만 [1, 4], 애플리케이션 개발 팀 관점에서는 의도치 않은 병합 버그를 유발할 수 있어 피해야 할 기능으로 강하게 반대되기도 합니다 [2, 8].

 ---
@@ -19,7 +19,7 @@ inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
 # 자기 효능감(Self Efficacy)

 > [!IMPORTANT]
-> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[자기 효능감 (Self-Efficacy)]]**로 통합되었습니다.
+> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[자기 효능감(Self Efficacy)]]**로 통합되었습니다.

 ---
-*Redirected to: [[자기 효능감 (Self-Efficacy)]]*
+*Redirected to: [[자기 효능감(Self Efficacy)]]*
@@ -44,7 +44,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]], [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]]
+- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[선언 병합(Declaration Merging)]], [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]]
 - **Contradictions/Notes:** 과잉 속성 체크(EPC)는 객체 리터럴을 직접 다룰 때만 활성화되어 간접 할당 시 우회될 수 있다는 취약점이 있으나, TypeScript 4.9부터 도입된 satisfies 연산자를 통해 이 문제를 해결하고 엄격한 속성 검사를 수행할 수 있습니다 [9, 10].

 ---
@@ -49,7 +49,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[의존성 역전 원칙(Dependency Inversion Principle)]]
+- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[의존성 역전 원칙 (Dependency Inversion Principle)]]
 - **Contradictions/Notes:** 소스 출처 "Complete Guide to Clean Architecture - GeeksforGeeks"는 클린 아키텍처가 시스템의 장기적인 유지보수성, 테스트 가능성, 유연성을 제공한다고 강조하지만, 동시에 도입 초기에는 여러 추상화 계층을 구축해야 하므로 초기 개발 시간이 증가하고 오버엔지니어링(Over-Engineering)에 빠질 위험이 있다고 지적합니다. 따라서 실용적인 관점과의 균형 유지가 필수적입니다 [21], [19].

 ---
@@ -43,7 +43,7 @@ tech_stack:
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

 ## 🔗 지식 연결 (Graph)
- **Related Topics:** , [[유니온 타입 (Union Types)]], [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]]
+- **Related Topics:** , [[유니온 타입(Union Types)]], [[구조적 타이핑(Structural Typing)]], [[선언 병합(Declaration Merging)]]
 - **Projects/Contexts:** [[대규모 TypeScript 프로젝트의 컴파일 성능 최적화]], [[견고한 도메인 모델 및 API 계약 설계]]
 - **Contradictions/Notes:** TypeScript 핸드북 및 성능 가이드라인은 컴파일러의 캐싱 이점과 성능 최적화를 이유로 객체 확장 시 교집합을 사용하는 타입 별칭보다 인터페이스 상속(extends)을 사용할 것을 권장합니다 [8-10]. 하지만 실무 현장에서는 의도치 않은 선언 병합을 방지하고 유연성을 얻고자 린팅(Linting) 규칙을 통해 인터페이스 사용을 아예 금지하고 타입 별칭(Type Alias)만을 전면적으로 사용하는 개발 팀들도 많아 명확한 대립이 존재합니다 [4, 6, 15].