fix(topics): 지식 그래프 정상화 — 고아 29%→4%, 인덱스 12개·개념 문서 13편

링크 그래프 분석(6,372문서·31,623링크) 기반 최소 수정 정상화:
- [수정] Topic_CPP/Topic_C 인덱스의 링크 표기를 실제 문서 제목으로 교정
  (CPP 117건·C 68건 — [[CPP Intro]] → [[C++ Intro]] 등, 인덱스 파일 2개만 수정)
- [수정] C Tutorial 별칭에 'C' 추가 — [[c]] 60건 해소 (frontmatter 1줄)
- [신규] 고아 다발 폴더 11곳에 00_INDEX MOC 자동 생성 (Poetic_Blog_Writing 500편,
  AI_and_ML 330, Coding 200, Reasoning_Creativity 161, Frontend 146 등)
- [신규] 루트 MOC(Topics Root Index) — breadcrumb [[10_Wiki/Topics]] 47건을 별칭으로 수용
- [신규] 수요 최상위 미싱 개념 문서 13편 (깨진 링크 다발 해소):
  글쓰기 7편(리듬·감정·문체·블로그·퇴고·정서·구조) + 설계 6편(React·Software
  Architecture·ADR·CQRS·Observability·RLHF) — AI 생성 초안임을 review_reason에 명시
- 기존 문서 본문은 무수정 (인덱스 2개 링크 교정 + 별칭 1줄이 수정의 전부)

결과: 고아 1,901(29%)→314(4%), 완전고립 1,018→173, 깨진 링크 10,258→9,679

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

10_Wiki/Topics/Domain_Programming/Architecture/ADR.md

@@ -0,0 +1,36 @@
+---
+id: adr
+title: "ADR"
+category: "Architecture"
+status: "draft"
+verification_status: "conceptual"
+canonical_id: ""
+aliases: ["ADR", "Architecture Decision Record", "아키텍처 결정 기록"]
+duplicate_of: ""
+source_trust_level: "B"
+confidence_score: 0.80
+created_at: 2026-07-11
+updated_at: 2026-07-11
+review_reason: "깨진 링크 다발 해소용 AI 생성 초안 — 원출처 리서치로 검증·보강 권장"
+merge_history: []
+tags: ["architecture","documentation"]
+raw_sources: []
+applied_in: []
+github_commit: ""
+---
+
+# [[ADR]]
+
+## 🎯 한 줄 통찰 (One-line insight)
+아키텍처 결정을 "무엇을·왜·무엇을 포기하고" 선택했는지 한 장으로 남기는 기록 — 코드는 결과만 보여주고, ADR은 이유를 보존한다.
+
+## 🧠 핵심 개념 (Core concepts)
+- **구성 요소** — 맥락(Context) / 결정(Decision) / 결과(Consequences) 세 부분이 핵심. 상태(제안/승인/폐기)를 함께 관리한다.
+- **불변 기록** — 결정이 바뀌면 기존 ADR 을 수정하지 않고 새 ADR 이 이전 것을 대체(supersede)한다. 결정의 역사가 남는다.
+- **작성 시점** — 되돌리기 비싼 결정(프레임워크, 데이터 저장 방식, 통신 방식, 경계 설계)을 내릴 때마다 짧게라도 쓴다.
+
+## 🧩 추출된 패턴 (Extracted patterns)
+- "6개월 뒤의 나(또는 새 팀원)가 왜 이렇게 됐는지 물을 결정인가?"가 ADR 작성 여부의 판별식이다.
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Software Architecture]] · [[CQRS]]

10_Wiki/Topics/Domain_Programming/Architecture/CQRS.md

@@ -0,0 +1,37 @@
+---
+id: cqrs
+title: "CQRS"
+category: "Architecture"
+status: "draft"
+verification_status: "conceptual"
+canonical_id: ""
+aliases: ["CQRS", "Command Query Responsibility Segregation", "명령 조회 책임 분리"]
+duplicate_of: ""
+source_trust_level: "B"
+confidence_score: 0.80
+created_at: 2026-07-11
+updated_at: 2026-07-11
+review_reason: "깨진 링크 다발 해소용 AI 생성 초안 — 원출처 리서치로 검증·보강 권장"
+merge_history: []
+tags: ["architecture","pattern"]
+raw_sources: []
+applied_in: []
+github_commit: ""
+---
+
+# [[CQRS]]
+
+## 🎯 한 줄 통찰 (One-line insight)
+쓰기(Command)와 읽기(Query)의 모델을 분리하는 패턴 — 변경과 조회는 요구사항이 근본적으로 달라서, 하나의 모델로 둘 다 잘하기 어렵다는 통찰에서 출발한다.
+
+## 🧠 핵심 개념 (Core concepts)
+- **명령 모델** — 비즈니스 규칙·일관성 검증에 최적화. 도메인 모델이 여기 산다.
+- **조회 모델** — 화면·리포트에 맞춘 비정규화 구조. 빠른 읽기가 목적이며 규칙 검증이 없다.
+- **동기화** — 쓰기 측 변경을 이벤트 등으로 읽기 모델에 반영한다. 이때 최종 일관성(eventual consistency)을 수용해야 한다.
+- **적용 판단** — 읽기/쓰기 부하나 복잡도가 크게 비대칭일 때 가치가 있다. 단순 CRUD에 적용하면 복잡도만 산다.
+
+## 🧩 추출된 패턴 (Extracted patterns)
+- CQRS 는 전체 시스템이 아니라 "필요한 경계 컨텍스트 안에서만" 적용하는 것이 정석 — 전면 도입은 대표적 과잉 설계다.
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Software Architecture]] · [[ADR]]

10_Wiki/Topics/Domain_Programming/Architecture/Software Architecture.md

@@ -0,0 +1,37 @@
+---
+id: software-architecture
+title: "Software Architecture"
+category: "Architecture"
+status: "draft"
+verification_status: "conceptual"
+canonical_id: ""
+aliases: ["Software Architecture", "소프트웨어 아키텍처", "SW 아키텍처"]
+duplicate_of: ""
+source_trust_level: "B"
+confidence_score: 0.80
+created_at: 2026-07-11
+updated_at: 2026-07-11
+review_reason: "깨진 링크 다발 해소용 AI 생성 초안 — 원출처 리서치로 검증·보강 권장"
+merge_history: []
+tags: ["architecture","design"]
+raw_sources: []
+applied_in: []
+github_commit: ""
+---
+
+# [[Software Architecture]]
+
+## 🎯 한 줄 통찰 (One-line insight)
+아키텍처는 "바꾸기 비싼 결정들의 집합" — 코드가 아니라 구조·경계·의존 방향에 대한 결정이며, 좋은 아키텍처는 결정을 미룰 수 있게 해준다.
+
+## 🧠 핵심 개념 (Core concepts)
+- **관심사 분리** — 시스템을 책임 단위로 나누고 경계를 명시한다. 경계가 흐리면 변경이 전염된다.
+- **의존 방향 통제** — 안정적인 것(정책·도메인)이 불안정한 것(UI·DB·프레임워크)에 의존하지 않게 한다.
+- **트레이드오프의 학문** — 모든 아키텍처 결정은 무언가를 얻고 무언가를 포기한다. "정답"이 아니라 "맥락에 맞는 선택"이 있을 뿐.
+- **아키텍처 스타일** — 계층형, 헥사고날, 마이크로서비스, 이벤트 기반 등은 반복 검증된 구조 패턴의 이름이다.
+
+## 🧩 추출된 패턴 (Extracted patterns)
+- 결정을 기록하지 않은 아키텍처는 전승되지 않는다 — 중요한 구조 결정은 [[ADR]] 로 남기는 것이 실무 표준.
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[ADR]] · [[CQRS]] · [[Observability]]