[G1-Sync] Manual knowledge update

10_Wiki/Topics/Specification.md

@@ -1,8 +1,8 @@
 ---
-id: P-REINFORCE-AUTO-SPEC-001
+id: [[P-Reinforce]]-AUTO-SPEC-001
 category: "10_Wiki/💡 Topics/AI"
 confidence_score: 0.96
-tags: [auto-reinforced, specification, engineering, requirement, blueprint, documentation-strategy]
+tags: [auto-reinforced, specification, engineering, requirement, blueprint, [[Documentation-Strategy]]]
 last_reinforced: 2026-04-20
 ---
 
@@ -15,11 +15,11 @@ last_reinforced: 2026-04-20
 명세서(Specification)는 제품이나 시스템이 갖추어야 할 기술적 요건과 성능, 외형을 상세히 기술한 문서입니다.
 
 1.  **명세의 힘**:
-    *   **Precision**: 구현해야 할 기능의 경계선을 명확히 확정. (Requirements와 연결)
+    *   **Precision**: 구현해야 할 기능의 경계선을 명확히 확정. ([[Requirements]]와 연결)
     *   **Agreement**: 이해관계자들 간의 '완료 기준'에 대한 법적/기술적 합의점 제공. (SOW와 연결)
-    *   **Reference**: 개발 도중 의문이 생길 때마다 찾아볼 수 있는 유일한 진실의 원천(Single Source of Truth).
+    *   **[[Reference]]**: 개발 도중 의문이 생길 때마다 찾아볼 수 있는 유일한 진실의 원천([[Single Source of Truth]]).
 2.  **왜 중요한가?**:
-    *   명세가 부실한 프로젝트는 필연적으로 구현 단계에서 '재작업(Rework)'이라는 거대한 비용 정책을 치르게 되기 때문임. (Efficiency의 수호자)
+    *   명세가 부실한 프로젝트는 필연적으로 구현 단계에서 '재작업(Rework)'이라는 거대한 비용 정책을 치르게 되기 때문임. ([[Efficiency]]의 수호자)
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌**: 과거에는 수백 페이지의 정적 문서 정책 위주였으나, 현대 정책은 코드 내의 주석이나 '테스트 코드(TDD)' 자체가 살아있는 명세 정책 역할을 하는 방향으로 전환됨(RL Update).