docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

10_Wiki/Topics/Graphics & Performance/ANGLE (Almost Native Graphics Layer Engine).md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-46B173
+id: [[P-Reinforce|P-Reinforce]]-AUTO-46B173
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[ANGLE]] (Almost Native Graphics Layer Engine)"
+github_commit: "[P-Reinforce] Continuous Worker - [[ANGLE|ANGLE]] (Almost Native Graphics Layer Engine)"
 ---
 
-# [[ANGLE (Almost Native Graphics Layer Engine)]]
+# [[ANGLE (Almost Native Graphics Layer Engine)|ANGLE (Almost Native Graphics Layer Engine]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> ANGLE(Almost Native Graphics Layer Engine)은 주로 Windows 플랫폼의 웹 브라우저([[Chrome]], Firefox, [[Opera]] 등)에서 사용되는 그래픽 명령어 변환기입니다. 이 엔진은 [[WebGL]]의 [[OpenGL ES]] 호출을 [[Direct3D]] 11 또는 12 명령으로 변환하는 역할을 수행합니다 [1, 2]. 고도로 최적화되어 있지만, 변환 과정에서 각 드로우 콜([[Draw Call]])마다 고정된 마이크로 레이턴시(Micro-latency)를 유발하는 성능적 특징이 있습니다 [1, 3].
+> ANGLE(Almost Native Graphics Layer Engine)은 주로 Windows 플랫폼의 웹 브라우저([[Chrome|Chrome]], Firefox, Opera 등)에서 사용되는 그래픽 명령어 변환기입니다. 이 엔진은 WebGL의 [[OpenGL ES|OpenGL ES]] 호출을 Direct3D 11 또는 12 명령으로 변환하는 역할을 수행합니다 [1, 2]. 고도로 최적화되어 있지만, 변환 과정에서 각 드로우 콜([[Draw Call|Draw Call]])마다 고정된 마이크로 레이턴시(Micro-latency)를 유발하는 성능적 특징이 있습니다 [1, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **역할 및 플랫폼:** ANGLE은 Windows 환경에서 Chrome, Firefox, Opera와 같은 주요 브라우저가 WebGL(OpenGL ES) 호출을 Direct3D 11 또는 12로 변환할 때 사용됩니다 [1, 2].
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[ANGLE]] (Almost Native Graph
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[OpenGL ES]], [[Direct3D]], Micro-latency, [[Draw Call]]
-- **Projects/Contexts:** [[Chrome]], Firefox, [[Opera]]
+- **Related Topics:** [[WebGL|WebGL]], OpenGL ES, Direct3D, Micro-latency, [[Draw Call|Draw Call]]
+- **Projects/Contexts:** [[Chrome|Chrome]], Firefox, [[Opera|Opera]]
 - **Contradictions/Notes:** ANGLE은 브라우저에서 원활한 그래픽 처리를 위해 도입된 고도로 최적화된 변환기이지만, 드로우 콜이 많은 환경에서는 역설적이게도 이 변환 작업 자체가 누적되어 CPU 병목을 일으키는 주된 원인이 됩니다 [3].
 
 ---

10_Wiki/Topics/Graphics & Performance/ANGLE.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-26A7F5
+id: [[P-Reinforce|P-Reinforce]]-26A7F5
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.95
 tags: []
@@ -7,14 +7,14 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Mega Batch - Wikified ANGLE"
 ---
 
-# [[ANGLE]]
+# [[ANGLE|ANGLE]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> ANGLE(Almost Native Graphics Layer Engine)은 Windows 플랫폼에서 [[WebGL]]([[OpenGL ES]]) 명령을 [[Direct3D]] 11 또는 12로 변환해 주는 변환기(translator)입니다 [1, 2]. [[Chrome]], Firefox, [[Opera]]와 같은 브라우저에서 널리 사용되며, 고도로 최적화되어 있음에도 불구하고 그래픽 파이프라인의 명령 제출(command submission) 단계에서 마이크로 레이턴시(micro-latency)를 유발하는 주요 원인 중 하나로 작용합니다 [1-3].
+> ANGLE(Almost Native Graphics Layer Engine)은 Windows 플랫폼에서 [[WebGL|WebGL]](OpenGL ES) 명령을 Direct3D 11 또는 12로 변환해 주는 변환기(translator)입니다 [1, 2]. [[Chrome|Chrome]], Firefox, [[Opera|Opera]]와 같은 브라우저에서 널리 사용되며, 고도로 최적화되어 있음에도 불구하고 그래픽 파이프라인의 명령 제출(command submission) 단계에서 마이크로 레이턴시(micro-latency)를 유발하는 주요 원인 중 하나로 작용합니다 [1-3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **주요 기능 및 사용 환경:** Windows 플랫폼에서 Chrome, Firefox, Opera 등의 웹 브라우저는 [[WebGL API]]의 기반이 되는 OpenGL ES 호출을 Direct3D로 번역하기 위해 ANGLE을 사용합니다 [1, 2]. 일반적인 Windows 엔드 유저들은 기본적으로 ANGLE이 활성화된 상태로 웹 브라우저를 사용하게 됩니다 [2].
-* **마이크로 레이턴시(Micro-latency) 발생:** ANGLE의 변환 프로세스는 매우 고도로 최적화되어 있으나, 여전히 각 드로우 콜([[Draw Call]])마다 수 마이크로초(microseconds) 단위의 고정된 오버헤드를 발생시킵니다 [3]. 이는 그래픽 파이프라인의 명령 제출 단계에 상당한 마이크로 레이턴시를 추가합니다 [1, 4].
+* **주요 기능 및 사용 환경:** Windows 플랫폼에서 Chrome, Firefox, Opera 등의 웹 브라우저는 [[WebGL API|WebGL API]]의 기반이 되는 OpenGL ES 호출을 Direct3D로 번역하기 위해 ANGLE을 사용합니다 [1, 2]. 일반적인 Windows 엔드 유저들은 기본적으로 ANGLE이 활성화된 상태로 웹 브라우저를 사용하게 됩니다 [2].
+* **마이크로 레이턴시(Micro-latency) 발생:** ANGLE의 변환 프로세스는 매우 고도로 최적화되어 있으나, 여전히 각 드로우 콜([[Draw Call|Draw Call]])마다 수 마이크로초(microseconds) 단위의 고정된 오버헤드를 발생시킵니다 [3]. 이는 그래픽 파이프라인의 명령 제출 단계에 상당한 마이크로 레이턴시를 추가합니다 [1, 4].
 * **CPU 병목 현상 유발:** 수천 개의 드로우 콜이 발생하는 3D 애플리케이션에서는 ANGLE로 인한 미세한 오버헤드가 지속적으로 누적됩니다 [3]. 이로 인해 GPU가 비교적 유휴(idle) 상태에 있음에도 불구하고 CPU가 처리 한계에 부딪히는 "가랑비에 옷 젖는(death by a thousand cuts)" 형태의 병목 현상이 발생할 수 있습니다 [3].
 * **테스트 및 디버깅:** 개발자는 성능 프로파일링이나 네이티브 OpenGL 구현을 테스트할 목적으로 특정 브라우저 명령줄 인수(예: Chrome의 `--use-gl=desktop`)를 사용하거나 설정을 변경하여 ANGLE을 우회(bypass)할 수 있습니다 [2].
 
@@ -23,7 +23,7 @@ github_commit: "[P-Reinforce] Mega Batch - Wikified ANGLE"
 - **정책 변화:** Graphics & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[OpenGL ES]], [[Direct3D]], Micro-latency
+- **Related Topics:** [[WebGL|WebGL]], OpenGL ES, [[Direct3D|Direct3D]], Micro-latency
 - **Projects/Contexts:** Web Graphics Pipelines
 - **Contradictions/Notes:** ANGLE의 변환 작업은 "고도로 최적화(highly optimized)"되어 있지만, 역설적으로 많은 드로우 콜을 요구하는 환경에서는 이 최적화된 변환 작업조차 누적되어 CPU 병목의 주요 원인이 됩니다 [3].
 

10_Wiki/Topics/Graphics & Performance/Alpha Blending.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-25F1DA
+id: [[P-Reinforce|P-Reinforce]]-25F1DA
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.95
 tags: []
@@ -7,22 +7,22 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Mega Batch - Wikified Alpha Blending"
 ---
 
-# [[Alpha Blending]]
+# [[Alpha Blending|Alpha Blending]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 투명하거나 반투명한 객체를 렌더링할 때 시각적 결함 없이 정확한 투명도를 표현하기 위한 렌더링 혼합 기법입니다 [1]. 올바른 알파 블렌딩 결과를 얻기 위해서는 반드시 객체를 '뒤에서 앞으로(Back-to-Front)' 순서로 정렬하여 그려야 한다는 제약이 있습니다 [1]. 그 외 알파 블렌딩의 구체적인 수학적 원리나 연산식에 대해서는 소스에 관련 정보가 부족합니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **투명도 렌더링과 정렬의 필수성:** 투명하거나 반투명한 3D 객체에서 올바른 알파 블렌딩(Alpha Blending) 결과를 얻어내려면, 렌더링 파이프라인에서 카메라와 멀리 있는 객체부터 가까운 객체 순으로 렌더링하는 '뒤에서 앞으로(Back-to-Front)' 정렬 과정이 필수적으로 동반되어야 합니다 [1].
-- **[[InstancedMesh]] 환경에서의 구조적 한계:** 대규모 렌더링 최적화에 쓰이는 `InstancedMesh`는 단일 드로우 콜 내에서 인스턴스들의 렌더링 순서를 동적으로 변경하는 기본 기능을 제공하지 않습니다 [1]. 따라서 카메라 시점이 변할 때마다 객체 간의 앞뒤 관계가 뒤섞이게 되며, 이로 인해 알파 블렌딩이 비정상적으로 계산되어 투명도가 깨지는 시각적 결함이 발생합니다 [1].
-- **해결 방식 및 병목 현상:** 알파 블렌딩을 위한 투명도 정렬(Transparency [[Sorting]]) 문제를 해결하려면 매 프레임마다 카메라와의 거리를 계산하고 버퍼 내의 행렬 데이터를 재정렬(예: [[Radix Sort]])하는 로직을 추가해야 합니다 [1, 2]. 그러나 수만 개의 객체에 대해 이를 수행할 경우 CPU 메인 스레드에 치명적인 부하를 야기하므로 성능과 품질 사이의 타협이 필요합니다 [1].
+- **[[InstancedMesh|InstancedMesh]] 환경에서의 구조적 한계:** 대규모 렌더링 최적화에 쓰이는 `InstancedMesh`는 단일 드로우 콜 내에서 인스턴스들의 렌더링 순서를 동적으로 변경하는 기본 기능을 제공하지 않습니다 [1]. 따라서 카메라 시점이 변할 때마다 객체 간의 앞뒤 관계가 뒤섞이게 되며, 이로 인해 알파 블렌딩이 비정상적으로 계산되어 투명도가 깨지는 시각적 결함이 발생합니다 [1].
+- **해결 방식 및 병목 현상:** 알파 블렌딩을 위한 투명도 정렬(Transparency [[Sorting|Sorting]]) 문제를 해결하려면 매 프레임마다 카메라와의 거리를 계산하고 버퍼 내의 행렬 데이터를 재정렬(예: [[Radix Sort|Radix Sort]])하는 로직을 추가해야 합니다 [1, 2]. 그러나 수만 개의 객체에 대해 이를 수행할 경우 CPU 메인 스레드에 치명적인 부하를 야기하므로 성능과 품질 사이의 타협이 필요합니다 [1].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
 - **정책 변화:** Graphics & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Transparency Sorting, [[InstancedMesh]], [[Overdraw]]
+- **Related Topics:** Transparency Sorting, [[InstancedMesh|InstancedMesh]], [[Overdraw|Overdraw]]
 - **Projects/Contexts:** 대규모 유리창 건물이나 투명한 숲 등 다수의 반투명 객체를 `InstancedMesh` 등을 사용하여 실시간으로 렌더링하고 최적화해야 하는 웹 그래픽스 및 게임 프로젝트 맥락 [1, 2].
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스에서는 알파 블렌딩 자체의 개념보다는, 투명 객체 렌더링 정렬 문제의 원인으로서만 간략히 언급되고 있습니다.)
 

10_Wiki/Topics/Graphics & Performance/BIM 모델 렌더링.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-B22078
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B22078
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,34 +7,34 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - BIM 모델 렌더링"
 ---
 
-# [[BIM 모델 렌더링]]
+# [[BIM 모델 렌더링|BIM 모델 렌더링]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> BIM(건축 정보 모델) 및 CAD 모델 렌더링은 수십만 개의 고유하거나 반복되는 기하학적 요소로 이루어진 대규모 건설 데이터를 웹 브라우저 등에서 효율적으로 시각화하는 과정입니다 [1-3]. 이 과정에서는 막대한 드로우 콜([[Draw Call]])과 메모리 대역폭 한계로 인한 성능 저하를 방지하기 위해 형상 병합(Merging), 인스턴싱([[Instancing]]), 배칭([[Batching]]) 등의 기법을 적재적소에 활용해야 합니다 [4-7]. 최근에는 [[WebGPU]]를 도입하여 500MB 이상의 거대 BIM 데이터를 실시간으로 렌더링하고 컴퓨트 셰이더를 통해 무거운 연산을 병렬 처리하는 방식이 대규모 건설 뷰어의 핵심 기술로 부상하고 있습니다 [8-10].
+> BIM(건축 정보 모델) 및 CAD 모델 렌더링은 수십만 개의 고유하거나 반복되는 기하학적 요소로 이루어진 대규모 건설 데이터를 웹 브라우저 등에서 효율적으로 시각화하는 과정입니다 [1-3]. 이 과정에서는 막대한 드로우 콜([[Draw Call|Draw Call]])과 메모리 대역폭 한계로 인한 성능 저하를 방지하기 위해 형상 병합(Merging), 인스턴싱(Instancing), 배칭(Batching) 등의 기법을 적재적소에 활용해야 합니다 [4-7]. 최근에는 [[WebGPU|WebGPU]]를 도입하여 500MB 이상의 거대 BIM 데이터를 실시간으로 렌더링하고 컴퓨트 셰이더를 통해 무거운 연산을 병렬 처리하는 방식이 대규모 건설 뷰어의 핵심 기술로 부상하고 있습니다 [8-10].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **BIM 모델의 구조적 특징과 렌더링 과제:**
   BIM 또는 CAD 모델은 벽, 바닥, 파이프, 문, 창문 등 수많은 개별 부품(Component)으로 구성되어 있습니다 [1]. 이를 각각 개별적인 메쉬(Mesh)로 렌더링할 경우 CPU에서 GPU로 그리기 명령을 보내는 드로우 콜이 폭증하여 심각한 병목 현상이 발생합니다 [3]. 특히 통합 GPU 환경 등에서는 대용량 정점 데이터를 처리할 때 메모리 대역폭의 한계에 부딪혀 프레임 스터터링이 일어날 수 있습니다 [11, 12].
 
 - **하이브리드 렌더링 및 최적화 전략 (Fragment 시스템):**
-  건설 데이터의 렌더링 효율을 높이기 위해 IFC.js 프로젝트 등에서는 객체의 특성에 맞춘 하이브리드 방식을 제안합니다 [5, 13]. 벽이나 바닥처럼 폴리곤 수는 적으나 형태가 고유한 객체들은 단일 `[[BufferGeometry]]`로 병합(Merging)하여 드로우 콜을 최소화합니다 [5, 14]. 반면, 의자나 문 등 형태가 동일하고 폴리곤이 많은 객체는 메모리 사용량이 적은 `[[InstancedMesh]]`를 활용하여 수백, 수천 개의 복제본을 단 한 번의 드로우 콜로 렌더링합니다 [4-6].
+  건설 데이터의 렌더링 효율을 높이기 위해 IFC.js 프로젝트 등에서는 객체의 특성에 맞춘 하이브리드 방식을 제안합니다 [5, 13]. 벽이나 바닥처럼 폴리곤 수는 적으나 형태가 고유한 객체들은 단일 `[[BufferGeometry|BufferGeometry]]`로 병합(Merging)하여 드로우 콜을 최소화합니다 [5, 14]. 반면, 의자나 문 등 형태가 동일하고 폴리곤이 많은 객체는 메모리 사용량이 적은 `[[InstancedMesh|InstancedMesh]]`를 활용하여 수백, 수천 개의 복제본을 단 한 번의 드로우 콜로 렌더링합니다 [4-6].
 
 - **BatchedMesh를 활용한 이질적 기하학 처리:**
   Revit 등에서 추출한 모델 내에서 재질은 같으나 기하학적 형태가 다른 수많은 벽이나 부품들을 렌더링할 때는 `BatchedMesh`가 유용하게 사용됩니다 [6, 15, 16]. 이는 단일 렌더 콜로 거대한 어셈블리를 그리면서도 각 객체의 가시성과 변환 행렬, 색상 등을 개별적으로 쉽게 제어 및 수정할 수 있게 해줍니다 [7, 16].
 
 - **WebGPU를 통한 대규모 건설 뷰어의 진화:**
-  2026년 기준, 500MB 이상의 거대한 대형 건설 뷰어에서는 성능 한계를 극복하기 위해 WebGPU의 네이티브 기능이 필수적입니다 [8, 9]. WebGPU의 컴퓨트 셰이더([[Compute Shader]])를 활용하면 대규모 BIM 데이터 세트의 실시간 필터링, 물리 연산, 충돌 감지 등을 GPU에서 병렬로 처리하여 메인 스레드의 부하를 없애고 기존보다 100배 이상의 엄청난 처리 속도 향상을 이끌어낼 수 있습니다 [10, 17, 18].
+  2026년 기준, 500MB 이상의 거대한 대형 건설 뷰어에서는 성능 한계를 극복하기 위해 WebGPU의 네이티브 기능이 필수적입니다 [8, 9]. WebGPU의 컴퓨트 셰이더([[Compute Shader|Compute Shader]])를 활용하면 대규모 BIM 데이터 세트의 실시간 필터링, 물리 연산, 충돌 감지 등을 GPU에서 병렬로 처리하여 메인 스레드의 부하를 없애고 기존보다 100배 이상의 엄청난 처리 속도 향상을 이끌어낼 수 있습니다 [10, 17, 18].
 
 - **CAD 데이터 특화 렌더링 최적화 기법:**
-  거대한 좌표계를 가지는 CAD 모델 렌더링 시 32-bit 부동소수점 한계로 인해 모델이 떨리는 정밀도 저하(Precision collapse) 현상을 막기 위해 기하학적 데이터를 GPU에 업로드하기 전 기준점을 중심으로 좌표를 오프셋(Re-centering)하는 작업이 필요합니다 [19]. 또한 내부 구조가 겹겹이 존재하는 복잡한 어셈블리 모델은 오버드로우([[Overdraw]])가 심하므로, 색상 기록 없이 Z-버퍼만 채우는 깊이 사전 패스([[Depth Pre-Pass]])를 수동으로 적용하여 프래그먼트 셰이더의 연산 부하를 획기적으로 줄일 수 있습니다 [20, 21].
+  거대한 좌표계를 가지는 CAD 모델 렌더링 시 32-bit 부동소수점 한계로 인해 모델이 떨리는 정밀도 저하(Precision collapse) 현상을 막기 위해 기하학적 데이터를 GPU에 업로드하기 전 기준점을 중심으로 좌표를 오프셋(Re-centering)하는 작업이 필요합니다 [19]. 또한 내부 구조가 겹겹이 존재하는 복잡한 어셈블리 모델은 오버드로우([[Overdraw|Overdraw]])가 심하므로, 색상 기록 없이 Z-버퍼만 채우는 깊이 사전 패스([[Depth Pre-Pass|Depth Pre-Pass]])를 수동으로 적용하여 프래그먼트 셰이더의 연산 부하를 획기적으로 줄일 수 있습니다 [20, 21].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], BatchedMesh, [[WebGPU]], [[Draw Call]]
-- **Projects/Contexts:** IFC.js, [[Revit 모델 렌더링]], [[대규모 건설 뷰어(Construction Viewers)]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], BatchedMesh, WebGPU, [[Draw Call|Draw Call]]
+- **Projects/Contexts:** IFC.js, [[Revit 모델 렌더링|Revit 모델 렌더링]], [[대규모 건설 뷰어(Construction Viewers)|대규모 건설 뷰어(Construction Viewers]]
 - **Contradictions/Notes:** 다양한 형태의 객체를 단일 드로우 콜로 처리하여 성능을 높이기 위해 `BatchedMesh`를 사용하는 것이 일반적으로 권장되지만, 수백만 개의 정점과 수십만 개의 서브 지오메트리가 있는 거대한 Revit 기반 건축 모델에 이를 그대로 적용할 경우, 내부 버퍼 업데이트와 데이터 복사 등의 오버헤드로 인해 오히려 CPU 사용량이 40~60% 이상 폭증하고 프레임(FPS)이 급락하는 심각한 성능 역전 현상이 보고되기도 하므로 데이터 규모에 따른 주의가 필요합니다 [15, 22-25].
 
 ---

10_Wiki/Topics/Graphics & Performance/BIM 모델 시뮬레이션.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-B4BA95
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B4BA95
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,17 +7,17 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - BIM 모델 시뮬레이션"
 ---
 
-# [[BIM 모델 시뮬레이션]]
+# [[BIM 모델 시뮬레이션|BIM 모델 시뮬레이션]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> BIM(Building Information Modeling) 모델 시뮬레이션은 수십만 개의 개별 부품으로 구성된 건축 및 건설 데이터를 웹 환경 등에서 실시간으로 렌더링하고 상호작용하는 기술입니다 [1, 2]. 이러한 대규모 데이터셋은 CPU와 GPU 간의 병목 현상을 쉽게 유발하므로 성능 유지를 위해 인스턴싱, 지오메트리 병합, 그리고 최신 그래픽스 API의 활용이 필수적입니다 [2, 3]. 최근에는 대형 모델 처리를 위해 [[WebGPU]]의 컴퓨트 셰이더를 활용하여 연산 부하를 획기적으로 낮추는 방법이 도입되고 있습니다 [4, 5].
+> BIM(Building Information Modeling) 모델 시뮬레이션은 수십만 개의 개별 부품으로 구성된 건축 및 건설 데이터를 웹 환경 등에서 실시간으로 렌더링하고 상호작용하는 기술입니다 [1, 2]. 이러한 대규모 데이터셋은 CPU와 GPU 간의 병목 현상을 쉽게 유발하므로 성능 유지를 위해 인스턴싱, 지오메트리 병합, 그리고 최신 그래픽스 API의 활용이 필수적입니다 [2, 3]. 최근에는 대형 모델 처리를 위해 [[WebGPU|WebGPU]]의 컴퓨트 셰이더를 활용하여 연산 부하를 획기적으로 낮추는 방법이 도입되고 있습니다 [4, 5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **BIM 데이터의 렌더링 한계**
-    BIM 및 CAD 모델은 벽, 바닥, 파이프, 공조 시스템 등 수천에서 수십만 개의 서로 다른 부품으로 구성되는 경우가 많습니다 [1-3]. 이 때문에 모든 객체가 동일한 기하학적 구조를 공유해야만 하는 **`[[InstancedMesh]]` 최적화 기법을 단독으로 적용하는 것은 불가능하거나 매우 비효율적**입니다 [3]. 예를 들어, 건물의 콘크리트 벽면들은 동일한 재질을 공유하지만 고유한 형태와 크기를 가지기 때문입니다 [6].
-*   **하이브리드 및 배치([[Batching]]) 렌더링 전략**
+    BIM 및 CAD 모델은 벽, 바닥, 파이프, 공조 시스템 등 수천에서 수십만 개의 서로 다른 부품으로 구성되는 경우가 많습니다 [1-3]. 이 때문에 모든 객체가 동일한 기하학적 구조를 공유해야만 하는 **`[[InstancedMesh|InstancedMesh]]` 최적화 기법을 단독으로 적용하는 것은 불가능하거나 매우 비효율적**입니다 [3]. 예를 들어, 건물의 콘크리트 벽면들은 동일한 재질을 공유하지만 고유한 형태와 크기를 가지기 때문입니다 [6].
+*   **하이브리드 및 배치([[Batching|Batching]]) 렌더링 전략**
     문이나 창문처럼 기하학적 형태가 반복되는 객체는 인스턴싱(`InstancedMesh`)을 사용하고, 고유한 형태를 지닌 벽이나 바닥 같은 객체는 `BatchedMesh`를 사용하여 단일 드로우 콜로 묶어 처리하는 방식이 고려됩니다 [1, 7]. 하지만 1,200만 개 이상의 너무 거대한 폴리곤 데이터를 `BatchedMesh`로 묶을 경우, 버퍼 패킹 과정에서 오히려 CPU 오버헤드가 급증하여 일반적인 메쉬 렌더링보다 프레임이 심각하게 떨어지는 병목 현상이 보고되기도 합니다 [8-11]. 
-*   **WebGPU와 컴퓨트 셰이더([[Compute Shader]])의 활용**
+*   **WebGPU와 컴퓨트 셰이더([[Compute Shader|Compute Shader]])의 활용**
     대규모 BIM 데이터셋의 실시간 필터링, 충돌 감지, 구조 시뮬레이션과 같이 자원 소모가 큰 작업에는 **WebGPU의 컴퓨트 셰이더가 게임 체인저로 활용**됩니다 [4, 5]. 이는 CPU의 메인 스레드를 짓누르던 병목 작업들을 GPU의 수많은 코어에서 병렬로 처리하게 함으로써, 성능을 기존 대비 10배에서 100배까지 향상시킬 수 있습니다 [2, 5].
 *   **프로젝트 규모에 따른 플랫폼 선택 기준**
     500MB 이하의 표준적인 BIM 뷰어나 모델 구성기(Configurator)를 개발할 때는, 빠르고 풍부한 생태계를 갖춘 **Three.js**를 사용하는 것이 엔지니어링 노력 대비 훌륭한 성능을 제공합니다 [12, 13]. 그러나 모델 용량이 500MB를 초과하는 도시 규모의 디지털 트윈이거나, 실시간 구조 응력 시뮬레이션 같은 극단적인 성능이 요구될 경우에는 직접적인 GPU 메모리 관리와 파이프라인 제어가 가능한 **Native WebGPU** 시스템을 구축하는 것이 필수적입니다 [14, 15].
@@ -27,7 +27,7 @@ github_commit: "[P-Reinforce] Continuous Worker - BIM 모델 시뮬레이션"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[InstancedMesh]], BatchedMesh, [[Compute Shader]]
+- **Related Topics:** [[WebGPU|WebGPU]], InstancedMesh, BatchedMesh, [[Compute Shader|Compute Shader]]
 - **Projects/Contexts:** 대규모 건설 뷰어(Large-Scale Construction Viewers)
 - **Contradictions/Notes:** 다양한 부품이 혼재된 BIM 모델 최적화를 위해 다중 드로우를 하나로 묶는 `BatchedMesh`가 대안으로 제시되지만, 정점 및 면(face)의 수가 1,000만 개 단위를 넘어갈 정도로 너무 큰 경우에는 과도한 버퍼 연산으로 인해 CPU 점유율이 오히려 치솟는 치명적인 성능 저하가 발생한다는 한계가 있습니다 [8, 9, 11]. 
 

10_Wiki/Topics/Graphics & Performance/BVH.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-D211FC
+id: [[P-Reinforce|P-Reinforce]]-AUTO-D211FC
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - BVH"
 ---
 
-# [[BVH]]
+# [[BVH|BVH]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> BVH(Bounding Volume Hierarchy)는 3D 환경에서 빠르고 효율적인 레이캐스팅([[Raycasting]]), 절두체 컬링([[Frustum Culling]]) 및 공간 질의(Spatial Queries)를 가능하게 하는 정교한 공간 분할 자료구조입니다 [1, 2]. 이는 렌더링, 조명 및 그림자 연산, 충돌 처리, 자산의 메모리 로딩 등 광범위한 최적화를 주도하는 핵심 기반 기술입니다 [3]. Three.js 생태계에서는 주로 대규모 폴리곤이나 복잡한 인스턴스 씬에서의 성능을 극대화하기 위해 활용됩니다 [1, 4].
+> BVH(Bounding Volume Hierarchy)는 3D 환경에서 빠르고 효율적인 레이캐스팅([[Raycasting|Raycasting]]), 절두체 컬링([[Frustum Culling|Frustum Culling]]) 및 공간 질의(Spatial Queries)를 가능하게 하는 정교한 공간 분할 자료구조입니다 [1, 2]. 이는 렌더링, 조명 및 그림자 연산, 충돌 처리, 자산의 메모리 로딩 등 광범위한 최적화를 주도하는 핵심 기반 기술입니다 [3]. Three.js 생태계에서는 주로 대규모 폴리곤이나 복잡한 인스턴스 씬에서의 성능을 극대화하기 위해 활용됩니다 [1, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **성능 최적화 및 고속 레이캐스팅:** BVH는 복잡한 기하학적 구조를 가진 대화형 씬에서 레이캐스팅을 가속화하는 데 필수적인 요소입니다 [4]. `[[three-mesh-bvh]]` 라이브러리를 사용할 경우 60fps 환경에서 8만 개 이상의 폴리곤에 대한 레이캐스팅을 병목 없이 수행할 수 있습니다 [4, 5].
-- **대규모 씬의 공간 분할([[Spatial Partitioning]]):** BVH는 공간 분할 및 인덱싱(Indexing) 스키마를 통해 CPU 측의 연산 부담을 줄여줍니다 [3, 6]. 수만 개의 인스턴스가 존재하는 대규모 씬에서 겹쳐 있거나 가려진 객체를 정밀하게 선택(Lasso Selection 등)하려면 BVH와 같은 공간 분할 자료구조 구축이 필수적입니다 [2]. 
-- **[[InstancedMesh]]와의 통합 메커니즘:** 기본적으로 `three-mesh-bvh`는 `InstancedMesh` 내의 개별 기하학적 구조(Geometry)에 대한 BVH 기반 레이캐스팅은 지원하지만, 인스턴스 객체들의 전체 집합 자체를 대상으로 작동하지는 않습니다 [7, 8]. 그러나 `[[InstancedMesh2]]`와 같은 확장 라이브러리들은 내부적으로 BVH 공간 인덱스(Spatial Index)를 구축하여, 인스턴스 단위의 빠른 레이캐스팅과 개별 절두체 컬링(Frustum Culling)을 효과적으로 지원하도록 설계되었습니다 [9-12].
+- **성능 최적화 및 고속 레이캐스팅:** BVH는 복잡한 기하학적 구조를 가진 대화형 씬에서 레이캐스팅을 가속화하는 데 필수적인 요소입니다 [4]. `[[three-mesh-bvh|three-mesh-bvh]]` 라이브러리를 사용할 경우 60fps 환경에서 8만 개 이상의 폴리곤에 대한 레이캐스팅을 병목 없이 수행할 수 있습니다 [4, 5].
+- **대규모 씬의 공간 분할([[Spatial Partitioning|Spatial Partitioning]]):** BVH는 공간 분할 및 인덱싱(Indexing) 스키마를 통해 CPU 측의 연산 부담을 줄여줍니다 [3, 6]. 수만 개의 인스턴스가 존재하는 대규모 씬에서 겹쳐 있거나 가려진 객체를 정밀하게 선택(Lasso Selection 등)하려면 BVH와 같은 공간 분할 자료구조 구축이 필수적입니다 [2]. 
+- **[[InstancedMesh|InstancedMesh]]와의 통합 메커니즘:** 기본적으로 `three-mesh-bvh`는 `InstancedMesh` 내의 개별 기하학적 구조(Geometry)에 대한 BVH 기반 레이캐스팅은 지원하지만, 인스턴스 객체들의 전체 집합 자체를 대상으로 작동하지는 않습니다 [7, 8]. 그러나 `[[InstancedMesh2|InstancedMesh2]]`와 같은 확장 라이브러리들은 내부적으로 BVH 공간 인덱스(Spatial Index)를 구축하여, 인스턴스 단위의 빠른 레이캐스팅과 개별 절두체 컬링(Frustum Culling)을 효과적으로 지원하도록 설계되었습니다 [9-12].
 - **API 및 유틸리티:** 개발 시 BVH의 바운딩 트리 구조를 시각화하기 위해 과거에 사용되던 `MeshBVHVisualizer` 클래스는 더 이상 사용되지 않으며(deprecated), 최신 라이브러리에서는 `MeshBVHHelper`의 사용을 권장합니다 [8, 13].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - BVH"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Raycasting]], [[Frustum Culling]], [[InstancedMesh]], Spatial Indexing
-- **Projects/Contexts:** [[three-mesh-bvh]], [[InstancedMesh2]]
+- **Related Topics:** [[Raycasting|Raycasting]], Frustum Culling, [[InstancedMesh|InstancedMesh]], Spatial Indexing
+- **Projects/Contexts:** [[three-mesh-bvh|three-mesh-bvh]], [[InstancedMesh2|InstancedMesh2]]
 - **Contradictions/Notes:** 기본 `three-mesh-bvh` 라이브러리만으로는 `InstancedMesh`의 전체 인스턴스 집합에 대한 직접적인 공간 조회가 제한적이라는 점이 지적되지만 [7], 커뮤니티에서 개발된 `InstancedMesh2` 라이브러리가 BVH 공간 인덱스를 내장함으로써 이러한 한계를 성공적으로 극복하고 전체 인스턴스의 빠른 컬링 및 레이캐스팅을 가능하게 합니다 [10, 12].
 
 ---

10_Wiki/Topics/Graphics & Performance/Babylonjs.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-852A59
+id: [[P-Reinforce|P-Reinforce]]-AUTO-852A59
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Babylonjs"
 ---
 
-# [[Babylonjs]]
+# [[Babylonjs|Babylonjs]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Babylon.js는 수천에서 수만 개의 메쉬로 구성된 대규모 3D 씬을 웹 환경에서 렌더링하고 관리하는 데 사용되는 그래픽 엔진입니다. 렌더링 성능 및 메모리 최적화를 위해 MergeMesh, 인스턴스 메쉬(Instanced Meshes), 그리고 솔리드 파티클 시스템(Solid Particle[[ system]], SPS) 등의 기법을 지원합니다. 대규모 인스턴스 처리 시 발생하는 CPU 병목 현상을 극복하기 위해 하드웨어 제어력이 높은 [[WebGPU]] 기술의 도입이 적극적으로 논의되고 있습니다.
+> Babylon.js는 수천에서 수만 개의 메쉬로 구성된 대규모 3D 씬을 웹 환경에서 렌더링하고 관리하는 데 사용되는 그래픽 엔진입니다. 렌더링 성능 및 메모리 최적화를 위해 MergeMesh, 인스턴스 메쉬(Instanced Meshes), 그리고 솔리드 파티클 시스템(Solid ParticleSystem, SPS) 등의 기법을 지원합니다. 대규모 인스턴스 처리 시 발생하는 CPU 병목 현상을 극복하기 위해 하드웨어 제어력이 높은 [[WebGPU|WebGPU]] 기술의 도입이 적극적으로 논의되고 있습니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **렌더링 최적화 기법**
@@ -21,17 +21,17 @@ github_commit: "[P-Reinforce] Continuous Worker - Babylonjs"
   * **솔리드 파티클 시스템(SPS)**: `setParticles()`가 호출될 때만 전용 월드 매트릭스를 계산하며 기본적으로 절두체 검사가 비활성화되어 있어 CPU 오버헤드가 적습니다. 런타임에 개별 파티클의 색상이나 재질을 유연하게 변경할 수 있는 장점이 있으나, 지오메트리와 색상 버퍼 데이터를 내부적으로 모두 복제하기 때문에 10만 개의 실린더를 렌더링할 때 약 600MB의 엄청난 메모리를 소모합니다 [1, 3, 6, 7].
 
 * **CPU 병목 현상 및 완화 전략**
-  Babylon.js는 버퍼 내의 매트릭스를 재배열하는 방식으로 CPU 단에서 정렬([[Sorting]]) 및 절두체 컬링([[Frustum Culling]])을 수행합니다 [8]. 따라서 렌더링 시 매 프레임마다 발생하는 월드 매트릭스 계산 부하를 줄이려면 `freezeWorldMatrix()` 함수를 사용하여 정적 객체의 연산을 비활성화하거나, 시야 밖의 객체 관리를 별도의 웹 워커(Web Worker)로 분리하는 기법이 권장됩니다 [4, 9].
+  Babylon.js는 버퍼 내의 매트릭스를 재배열하는 방식으로 CPU 단에서 정렬([[Sorting|Sorting]]) 및 절두체 컬링([[Frustum Culling|Frustum Culling]])을 수행합니다 [8]. 따라서 렌더링 시 매 프레임마다 발생하는 월드 매트릭스 계산 부하를 줄이려면 `freezeWorldMatrix()` 함수를 사용하여 정적 객체의 연산을 비활성화하거나, 시야 밖의 객체 관리를 별도의 웹 워커(Web Worker)로 분리하는 기법이 권장됩니다 [4, 9].
 
 * **한계와 WebGPU의 역할**
-  현재의 [[WebGL]] 상태에서는 인스턴스 메쉬라 할지라도 수만 개의 객체를 처리하기에는 무리가 있습니다 [10]. 2,000개 미만의 메쉬에서는 원활하지만 그 이상의 거대한 스케일을 처리하기 위해서는 금속(하드웨어) 수준에 더 가깝게 접근할 수 있는 WebGPU를 대안으로 사용해야 합니다 [10].
+  현재의 [[WebGL|WebGL]] 상태에서는 인스턴스 메쉬라 할지라도 수만 개의 객체를 처리하기에는 무리가 있습니다 [10]. 2,000개 미만의 메쉬에서는 원활하지만 그 이상의 거대한 스케일을 처리하기 위해서는 금속(하드웨어) 수준에 더 가깝게 접근할 수 있는 WebGPU를 대안으로 사용해야 합니다 [10].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Instanced Meshes, Solid Particle System (SPS), [[Frustum Culling]], [[WebGPU]]
+- **Related Topics:** Instanced Meshes, Solid Particle System (SPS), [[Frustum Culling|Frustum Culling]], [[WebGPU|WebGPU]]
 - **Projects/Contexts:** 대규모 3D 환경 렌더링 최적화 프로젝트
 - **Contradictions/Notes:** 인스턴스 메쉬는 지오메트리를 복제하지 않아 메모리가 절약되어야 하지만, 한 사용자는 10,000개의 인스턴스당 100MB의 힙 메모리가 증가(인스턴스당 약 8~10KB)한다는 프로파일링 결과를 제기했습니다 [7, 11]. 이에 대해 Babylon.js 개발진(Deltakosh)은 실제 인스턴스 1개당 차지하는 메모리는 약 400바이트 수준이라고 확인하며 오해를 정정했습니다 [12].
 

10_Wiki/Topics/Graphics & Performance/BatchedMesh 및 InstancedMesh 성능 벤치마크.md

@@ -1,32 +1,32 @@
 ---
-id: [[P-Reinforce]]-AUTO-6B3697
+id: [[P-Reinforce|P-Reinforce]]-AUTO-6B3697
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 [[InstancedMesh]] 성능 벤치마크"
+github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 [[InstancedMesh|InstancedMesh]] 성능 벤치마크"
 ---
 
-# [[BatchedMesh 및 InstancedMesh 성능 벤치마크]]
+# [[BatchedMesh 및 InstancedMesh 성능 벤치마크|BatchedMesh 및 InstancedMesh 성능 벤치마크]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> BatchedMesh와 InstancedMesh는 Three.js 환경에서 드로우 콜([[Draw Call]])을 줄여 렌더링 성능을 대폭 개선하는 대표적인 최적화 기법입니다 [1, 2]. InstancedMesh는 동일한 형태의 객체를 대량으로 그릴 때 탁월한 효율을 보이지만 다양한 지오메트리를 한 번에 처리할 수는 없으며, BatchedMesh는 서로 다른 지오메트리를 하나의 드로우 콜로 묶을 수 있는 높은 유연성을 제공합니다 [3, 4]. 하지만 벤치마크 사례 연구에 따르면, 대규모 객체를 처리할 때 BatchedMesh는 내부적인 객체 정렬 및 버퍼 업로드 오버헤드로 인해 오히려 심각한 CPU 병목 현상과 렌더링 성능 저하를 유발할 수 있음이 확인되었습니다 [5, 6].
+> BatchedMesh와 InstancedMesh는 Three.js 환경에서 드로우 콜([[Draw Call|Draw Call]])을 줄여 렌더링 성능을 대폭 개선하는 대표적인 최적화 기법입니다 [1, 2]. InstancedMesh는 동일한 형태의 객체를 대량으로 그릴 때 탁월한 효율을 보이지만 다양한 지오메트리를 한 번에 처리할 수는 없으며, BatchedMesh는 서로 다른 지오메트리를 하나의 드로우 콜로 묶을 수 있는 높은 유연성을 제공합니다 [3, 4]. 하지만 벤치마크 사례 연구에 따르면, 대규모 객체를 처리할 때 BatchedMesh는 내부적인 객체 정렬 및 버퍼 업로드 오버헤드로 인해 오히려 심각한 CPU 병목 현상과 렌더링 성능 저하를 유발할 수 있음이 확인되었습니다 [5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **최적화 메커니즘과 적용 기준**
-  InstancedMesh는 동일한 기하학적 구조([[BufferGeometry]])와 재질(Material)을 공유하는 수많은 복제본을 단일 드로우 콜로 GPU에 전달해 처리합니다 [7, 8]. 고유한 지오메트리가 1,000개 미만이면서 수만 개의 복제본이 존재하는 환경에서 최상의 성능(`drawElementsInstanced`)을 발휘합니다 [9, 10]. 반면 BatchedMesh는 재질은 같으나 형태가 각기 다른 여러 지오메트리를 하나의 버퍼에 통합(`multiDrawElements[[WebGL]]` 활용)하여 한 번에 렌더링할 수 있으므로 지오메트리가 매우 다양한 씬에 적합합니다 [9, 11-13].
+  InstancedMesh는 동일한 기하학적 구조([[BufferGeometry|BufferGeometry]])와 재질(Material)을 공유하는 수많은 복제본을 단일 드로우 콜로 GPU에 전달해 처리합니다 [7, 8]. 고유한 지오메트리가 1,000개 미만이면서 수만 개의 복제본이 존재하는 환경에서 최상의 성능(`drawElementsInstanced`)을 발휘합니다 [9, 10]. 반면 BatchedMesh는 재질은 같으나 형태가 각기 다른 여러 지오메트리를 하나의 버퍼에 통합(`multiDrawElements[[WebGL|WebGL]]` 활용)하여 한 번에 렌더링할 수 있으므로 지오메트리가 매우 다양한 씬에 적합합니다 [9, 11-13].
 
 - **BatchedMesh의 대규모 씬 성능 병목 현상**
   실제 건축 BIM 모델이나 대규모 씬(예: 1,200만 개의 삼각형, 수십만 개의 고유 지오메트리)을 BatchedMesh로 렌더링한 벤치마크 테스트에서 막대한 성능 하락이 보고되었습니다 [5, 14, 15]. 동일한 환경에서 모든 객체를 하나로 병합한 Merged Mesh 방식이 60 FPS(CPU 15%, GPU 90%)의 성능을 보인 반면, BatchedMesh는 약 20 FPS 이하(CPU 40~60%, GPU 30%)로 프레임이 급락하며 극심한 CPU 부하를 보였습니다 [5, 15-17]. 
 
 - **성능 저하의 주요 원인**
-  BatchedMesh의 CPU 오버헤드는 매 프레임마다 GPU로 그려야 할 부분의 '시작(st[[Arts]])' 지점과 '카운트(counts)' 배열 데이터를 재업로드해야 하는 구조에서 비롯될 확률이 높습니다(약 20만 개 항목 기준 1.6MB의 데이터를 매 프레임 전송) [6, 18, 19]. 더불어 개별 객체마다 가시성을 판별하는 시야 절두체 컬링([[Frustum Culling]]) 및 심도 정렬([[Sorting]]) 작업이 CPU 자원을 크게 소모하며, 특히 정렬 기능을 켤 경우 `texSubImage2D` 작업 병목으로 인해 FPS가 30에서 9로 떨어지는 현상까지 관찰되었습니다 [20-22].
+  BatchedMesh의 CPU 오버헤드는 매 프레임마다 GPU로 그려야 할 부분의 '시작(st[[Arts|Arts]])' 지점과 '카운트(counts)' 배열 데이터를 재업로드해야 하는 구조에서 비롯될 확률이 높습니다(약 20만 개 항목 기준 1.6MB의 데이터를 매 프레임 전송) [6, 18, 19]. 더불어 개별 객체마다 가시성을 판별하는 시야 절두체 컬링(Frustum Culling) 및 심도 정렬([[Sorting|Sorting]]) 작업이 CPU 자원을 크게 소모하며, 특히 정렬 기능을 켤 경우 `texSubImage2D` 작업 병목으로 인해 FPS가 30에서 9로 떨어지는 현상까지 관찰되었습니다 [20-22].
 
-- **오버드로우([[Overdraw]])와 심도 정렬의 한계**
-  InstancedMesh는 내부적으로 인스턴스를 자동으로 정렬하지 않기 때문에, 불투명 객체들이 겹칠 때 발생하는 오버드로우 현상으로 인해 프래그먼트 바운드([[Fragment-bound]]) 성능 저하를 겪을 수 있습니다 [23-25]. BatchedMesh는 이러한 문제를 덜기 위해 자체적인 정렬 기능을 제공하지만, 앞서 언급한 바와 같이 수많은 요소를 CPU에서 정렬하는 연산 자체가 새로운 렌더링 지연의 원인이 됩니다 [22, 24].
+- **오버드로우([[Overdraw|Overdraw]])와 심도 정렬의 한계**
+  InstancedMesh는 내부적으로 인스턴스를 자동으로 정렬하지 않기 때문에, 불투명 객체들이 겹칠 때 발생하는 오버드로우 현상으로 인해 프래그먼트 바운드([[Fragment-bound|Fragment-bound]]) 성능 저하를 겪을 수 있습니다 [23-25]. BatchedMesh는 이러한 문제를 덜기 위해 자체적인 정렬 기능을 제공하지만, 앞서 언급한 바와 같이 수많은 요소를 CPU에서 정렬하는 연산 자체가 새로운 렌더링 지연의 원인이 됩니다 [22, 24].
 
 - **성능 벤치마크 기반의 선택 가이드라인**
-  동적인 씬에서 객체의 종류가 1,000개 이하라면 InstancedMesh가 압도적으로 효율적입니다 [10, 26]. 만일 고유 객체가 1,000개 이상이라면 BatchedMesh를 고려할 수 있으나, 수만~수십만 개의 극대규모 객체 단위로 넘어가면 한계에 부딪힙니다 [10, 27]. 씬이 정적이라면 지오메트리를 하나의 거대한 버퍼로 완전히 병합(Merge)해버리는 것이 성능에 훨씬 이로우며, 매우 방대하고 동적인 처리가 필수적이라면 [[WebGPU]] 기반의 컴퓨트 셰이더와 간접 드로우([[Indirect Draw]]) 파이프라인으로 전환하는 것이 근본적인 해결책입니다 [6, 28, 29].
+  동적인 씬에서 객체의 종류가 1,000개 이하라면 InstancedMesh가 압도적으로 효율적입니다 [10, 26]. 만일 고유 객체가 1,000개 이상이라면 BatchedMesh를 고려할 수 있으나, 수만~수십만 개의 극대규모 객체 단위로 넘어가면 한계에 부딪힙니다 [10, 27]. 씬이 정적이라면 지오메트리를 하나의 거대한 버퍼로 완전히 병합(Merge)해버리는 것이 성능에 훨씬 이로우며, 매우 방대하고 동적인 처리가 필수적이라면 [[WebGPU|WebGPU]] 기반의 컴퓨트 셰이더와 간접 드로우([[Indirect Draw|Indirect Draw]]) 파이프라인으로 전환하는 것이 근본적인 해결책입니다 [6, 28, 29].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.

10_Wiki/Topics/Graphics & Performance/Batching.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-723577
+id: [[P-Reinforce|P-Reinforce]]-AUTO-723577
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,29 +7,29 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Batching"
 ---
 
-# [[Batching]]
+# [[Batching|Batching]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Batching(배칭)은 렌더링 성능을 최적화하기 위해 여러 개의 렌더링 객체나 처리 명령을 하나의 그룹으로 묶어 일괄적으로 실행하는 기법입니다. 주로 3D 그래픽스([[WebGL]], [[WebGPU]]) 환경에서 GPU로 보내는 드로우 콜([[Draw Call]]) 횟수를 줄여 성능 오버헤드를 최소화하는 데 사용됩니다. 또한 웹 개발 환경에서는 DOM의 읽기 및 쓰기 작업을 묶어 불필요한 레이아웃 재계산을 방지하는 목적으로도 활용됩니다.
+> Batching(배칭)은 렌더링 성능을 최적화하기 위해 여러 개의 렌더링 객체나 처리 명령을 하나의 그룹으로 묶어 일괄적으로 실행하는 기법입니다. 주로 3D 그래픽스([[WebGL|WebGL]], WebGPU) 환경에서 GPU로 보내는 드로우 콜([[Draw Call|Draw Call]]) 횟수를 줄여 성능 오버헤드를 최소화하는 데 사용됩니다. 또한 웹 개발 환경에서는 DOM의 읽기 및 쓰기 작업을 묶어 불필요한 레이아웃 재계산을 방지하는 목적으로도 활용됩니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **드로우 콜(Draw Call) 최소화 전략**
   성능은 종종 실행되는 명령(드로우 콜)의 수에 크게 의존하기 때문에, 여러 그리기 호출을 하나의 WebGL 호출로 병합하는 배칭 기능은 성능 향상의 핵심입니다 [1, 2].
 * **3D 그래픽스 엔진에서의 활용**
-  * **[[Cesium]]:** 여러 객체를 하나의 명령으로 결합하기 위해 배칭을 사용합니다. 예를 들어, `BillboardCollection`은 가능한 한 많은 빌보드(Billboard)를 하나의 정점 버퍼(Vertex Buffer)에 저장하고, 이를 동일한 셰이더를 통해 렌더링함으로써 명령의 수를 대폭 줄입니다 [1]. 또한 엔진이 가시 절두체(Frustum)를 분할할 때마다 명령을 개별적으로 정렬 및 배칭(Batch)하여 작동 지연 시간을 최소화합니다 [3].
-  * **[[Wonder]]land Engine:** 배칭 기능을 극한으로 적용하여, 수만 개의 동적 객체가 포함된 장면(Scene)을 자동으로 10개 미만의 드로우 콜로 렌더링해 냅니다 [2].
+  * **[[Cesium|Cesium]]:** 여러 객체를 하나의 명령으로 결합하기 위해 배칭을 사용합니다. 예를 들어, `BillboardCollection`은 가능한 한 많은 빌보드(Billboard)를 하나의 정점 버퍼(Vertex Buffer)에 저장하고, 이를 동일한 셰이더를 통해 렌더링함으로써 명령의 수를 대폭 줄입니다 [1]. 또한 엔진이 가시 절두체(Frustum)를 분할할 때마다 명령을 개별적으로 정렬 및 배칭(Batch)하여 작동 지연 시간을 최소화합니다 [3].
+  * **[[Wonder|Wonder]]land Engine:** 배칭 기능을 극한으로 적용하여, 수만 개의 동적 객체가 포함된 장면(Scene)을 자동으로 10개 미만의 드로우 콜로 렌더링해 냅니다 [2].
 * **WebGPU에서의 명령어 배칭(Command Batching)**
   WebGPU는 명령어 기록과 제출을 분리하는 구조를 가집니다. 명령들은 명령 버퍼(Command buffers)에 기록된 후, 일괄적으로(in batches) GPU 큐(Queue)에 제출됩니다 [4]. 이는 프레임당 API 오버헤드를 크게 줄여주며, GPU 드라이버가 명령어 실행을 더 효과적으로 최적화할 수 있게 만듭니다 [4].
 * **UI 레이아웃 및 DOM 성능 최적화**
-  웹 성능 지표([[Core Web Vitals]]) 중 하나인 INP(Interaction to Next Paint)를 최적화하기 위해서도 배칭 개념이 쓰입니다. 읽기 작업 직후 쓰기 작업을 수행하여 발생하는 과도한 동기식 레이아웃 재계산(레이아웃 스래싱)을 방지하기 위해, DOM 읽기 및 쓰기 작업을 현명하게 배칭(Batch)하여 처리하는 것이 권장됩니다 [5].
+  웹 성능 지표([[Core Web Vitals|Core Web Vitals]]) 중 하나인 INP(Interaction to Next Paint)를 최적화하기 위해서도 배칭 개념이 쓰입니다. 읽기 작업 직후 쓰기 작업을 수행하여 발생하는 과도한 동기식 레이아웃 재계산(레이아웃 스래싱)을 방지하기 위해, DOM 읽기 및 쓰기 작업을 현명하게 배칭(Batch)하여 처리하는 것이 권장됩니다 [5].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Draw Calls, [[WebGL]], [[WebGPU]], [[Interaction to Next Paint (INP)]]
-- **Projects/Contexts:** [[Cesium]], [[Wonderland Engine]]
+- **Related Topics:** Draw Calls, [[WebGL|WebGL]], WebGPU, [[Interaction to Next Paint (INP)|Interaction to Next Paint (INP]]
+- **Projects/Contexts:** [[Cesium|Cesium]], [[Wonderland Engine|Wonderland Engine]]
 - **Contradictions/Notes:** 소스 내에서 배칭에 관한 상충되는 의견은 없으나, 3D 엔진에서의 '드로우 콜 병합'과 프론트엔드 최적화에서의 'DOM 연산 일괄 처리'라는 서로 다른 두 가지 시스템 컨텍스트에서 성능 개선을 위한 공통된 원리로 작용하고 있음을 보여줍니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Buffer Allocation.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-B20BA9
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B20BA9
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Buffer Allocation"
 ---
 
-# [[Buffer Allocation]]
+# [[Buffer Allocation|Buffer Allocation]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 버퍼 할당(Buffer Allocation)은 [[WebGL]] 및 [[WebGPU]] 환경에서 정점, 인덱스, 인스턴스 변환 행렬 등의 데이터를 저장하기 위해 GPU 메모리 공간을 확보하는 과정입니다. 렌더링 중 동적으로 버퍼 크기를 늘리거나 빈번하게 데이터를 업데이트할 경우 심각한 프레임 지연 및 메모리 오류가 발생할 수 있습니다. 따라서 최대 예상치에 맞춰 사전에 버퍼를 할당하고, 재사용 가능한 영구적인 GPU 버퍼를 활용하는 것이 3D 애플리케이션 성능 최적화에 필수적입니다.
+> 버퍼 할당(Buffer Allocation)은 [[WebGL|WebGL]] 및 [[WebGPU|WebGPU]] 환경에서 정점, 인덱스, 인스턴스 변환 행렬 등의 데이터를 저장하기 위해 GPU 메모리 공간을 확보하는 과정입니다. 렌더링 중 동적으로 버퍼 크기를 늘리거나 빈번하게 데이터를 업데이트할 경우 심각한 프레임 지연 및 메모리 오류가 발생할 수 있습니다. 따라서 최대 예상치에 맞춰 사전에 버퍼를 할당하고, 재사용 가능한 영구적인 GPU 버퍼를 활용하는 것이 3D 애플리케이션 성능 최적화에 필수적입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **동적 버퍼 확장의 성능 병목 현상:** 인스턴싱([[Instancing]]) 시스템이 초기에 낮은 버퍼 용량으로 시작하여 런타임에 동적으로 크기를 확장(Growing Buffer)하게 되면, 심각한 성능 지연(예: 앱 시작 시 수 초간의 멈춤 현상) 및 메모리 할당 오류가 발생할 수 있습니다 [1, 2]. 
+* **동적 버퍼 확장의 성능 병목 현상:** 인스턴싱([[Instancing|Instancing]]) 시스템이 초기에 낮은 버퍼 용량으로 시작하여 런타임에 동적으로 크기를 확장(Growing Buffer)하게 되면, 심각한 성능 지연(예: 앱 시작 시 수 초간의 멈춤 현상) 및 메모리 할당 오류가 발생할 수 있습니다 [1, 2]. 
 * **최대 용량 사전 할당 (Preallocation):** 이를 방지하기 위해 엔진 시작 시점에 예상되는 최대 인스턴스 수에 맞춰 충분한 크기의 버퍼를 사전에 할당하는 방식이 권장됩니다 [1]. 여유 용량(Excess capacity)을 미리 확보하는 것은 약간의 메모리 오버헤드를 발생시키지만, 실제 렌더링 연산 비용에는 부정적인 영향을 주지 않습니다 [3].
-* **GPU 영구 버퍼 및 업데이트 최소화:** WebGPU 환경에서 매 프레임 수많은 작은 버퍼를 반복 업데이트하는 것은 비용이 매우 큽니다 [4]. 따라서 `[[instancedArray]]`와 같은 영구적인 GPU 버퍼를 생성하여 사용하면 프레임 간 데이터가 유지되어, 성능 저하의 주원인인 CPU-GPU 간의 데이터 전송을 제거할 수 있습니다 [4, 5].
-* **오브젝트 풀링(Object [[Pooling]]) 활용:** 객체를 빈번하게 생성하고 파괴하는 작업은 버퍼 할당 오버헤드와 가비지 컬렉션(GC)에 의한 일시 정지를 유발합니다. 런타임 할당 스파이크를 피하려면 로딩 단계에서 풀을 미리 데워두는(Pre-warm) 방식의 오브젝트 풀링을 사용해야 합니다 [6].
+* **GPU 영구 버퍼 및 업데이트 최소화:** WebGPU 환경에서 매 프레임 수많은 작은 버퍼를 반복 업데이트하는 것은 비용이 매우 큽니다 [4]. 따라서 `[[instancedArray|instancedArray]]`와 같은 영구적인 GPU 버퍼를 생성하여 사용하면 프레임 간 데이터가 유지되어, 성능 저하의 주원인인 CPU-GPU 간의 데이터 전송을 제거할 수 있습니다 [4, 5].
+* **오브젝트 풀링(Object [[Pooling|Pooling]]) 활용:** 객체를 빈번하게 생성하고 파괴하는 작업은 버퍼 할당 오버헤드와 가비지 컬렉션(GC)에 의한 일시 정지를 유발합니다. 런타임 할당 스파이크를 피하려면 로딩 단계에서 풀을 미리 데워두는(Pre-warm) 방식의 오브젝트 풀링을 사용해야 합니다 [6].
 * **버퍼 재할당 시 메모리 누수 주의:** WebGL 컨텍스트는 디바이스에 따라 유한한 메모리 한도(일반적으로 256MB~1GB)를 가지며, 한도를 초과하면 뷰어가 다운될 수 있습니다 [7]. 또한, 기존의 인스턴스 메쉬 자원을 깔끔하게 폐기(Dispose)하지 못한 상태에서 동적으로 버퍼 용량을 늘리려 할 경우 메모리 누수가 발생할 수 있습니다 [8].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -24,8 +24,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Buffer Allocation"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** GPU Instancing, [[Memory Management]], [[Object Pooling]], [[Garbage Collection]]
-- **Projects/Contexts:** Three.js, [[Needle Engine]], [[WebGPU]]
+- **Related Topics:** GPU Instancing, [[Memory Management|Memory Management]], Object Pooling, [[Garbage Collection|Garbage Collection]]
+- **Projects/Contexts:** Three.js, [[Needle Engine|Needle Engine]], [[WebGPU|WebGPU]]
 - **Contradictions/Notes:** 소스에서는 실행 중 버퍼 크기를 동적으로 늘리는 방식(Dynamic Growth)은 성능 지연과 오류를 낳으므로, 초기에 넉넉하게 메모리 공간을 사전 할당(Preallocate)하는 방식이 훨씬 안정적이라고 강조합니다 [1-3].
 
 ---

10_Wiki/Topics/Graphics & Performance/BufferAttribute.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-7E5F3E
+id: [[P-Reinforce|P-Reinforce]]-AUTO-7E5F3E
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,13 +7,13 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - BufferAttribute"
 ---
 
-# [[BufferAttribute]]
+# [[BufferAttribute|BufferAttribute]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > `BufferAttribute`는 Three.js에서 3D 모델의 지오메트리 데이터를 저장하고 관리하기 위해 사용되는 핵심 클래스입니다 [1, 2]. 이 클래스는 Web Worker와 메인 스레드 간에 데이터를 중복 복사 없이 효율적으로 공유할 수 있게 해주며, 데이터 압축을 통한 메모리 최적화를 지원합니다 [2, 3]. 또한, 파생 클래스인 `InstancedBufferAttribute`를 통해 인스턴스 기반 렌더링에서 객체별 고유 데이터를 GPU로 전송하는 필수적인 역할을 수행합니다 [4, 5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 최적화 및 제로 카피(Zero-copy) 아키텍처:** [[Electron]] 등 메모리가 제한적인 환경에서 Web Worker가 STL 데이터를 `SharedArrayBuffer`로 파싱하면, 메인 스레드는 이 공유 메모리 공간을 직접 가리키는 `BufferAttribute`를 생성할 수 있습니다. 이러한 '제로 카피' 아키텍처를 활용하면 데이터 중복 복사로 인한 메모리 오버헤드 없이 멀티스레드 지오메트리 생성이 가능합니다 [2].
+- **메모리 최적화 및 제로 카피(Zero-copy) 아키텍처:** [[Electron|Electron]] 등 메모리가 제한적인 환경에서 Web Worker가 STL 데이터를 `SharedArrayBuffer`로 파싱하면, 메인 스레드는 이 공유 메모리 공간을 직접 가리키는 `BufferAttribute`를 생성할 수 있습니다. 이러한 '제로 카피' 아키텍처를 활용하면 데이터 중복 복사로 인한 메모리 오버헤드 없이 멀티스레드 지오메트리 생성이 가능합니다 [2].
 - **지오메트리 데이터 압축 지원:** `BufferAttribute`는 정규화된 정수 타입(normalized integer types)과 결합하여 지오메트리 압축을 지원함으로써 정점 버퍼의 크기를 대폭 줄일 수 있습니다 [3].
 - **다양한 타입의 파생 클래스 제공:** Three.js의 코어 API에는 데이터 타입 및 메모리 정밀도에 맞춰 `Float32BufferAttribute`, `Float16BufferAttribute`, `Int16BufferAttribute`, `Uint8BufferAttribute` 등 다양한 형태의 파생 클래스들이 존재합니다 [1].
 - **인스턴싱 연동 (InstancedBufferAttribute):** 대규모 객체 렌더링 시, 개별 인스턴스마다 다른 변환 행렬(`instanceMatrix`)이나 색상(`instanceColor`)을 적용하기 위해 파생 클래스인 `InstancedBufferAttribute`가 사용됩니다 [5, 6]. 또한, 텍스처 아틀라스 내에서 각 인스턴스별 텍스처 UV 오프셋을 전달하거나, 가시성(visibility) 및 컬링(culling) 상태 인덱스를 셰이더로 전달할 때도 핵심적으로 활용됩니다 [4, 7-9]. 매 프레임 수많은 지오메트리를 재생성하는 대신, `InstancedBufferAttribute` 일부만 갱신하여 렌더링 성능을 높일 수 있습니다 [10].
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - BufferAttribute"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** InstancedBufferAttribute, [[BufferGeometry]], SharedArrayBuffer, [[InstancedMesh]]
-- **Projects/Contexts:** [[WebGL]]/Three.js 대규모 CAD 렌더링 메모리 최적화, 다중 객체 드로우 콜 최적화 및 커스텀 셰이더 적용 맥락
+- **Related Topics:** InstancedBufferAttribute, [[BufferGeometry|BufferGeometry]], SharedArrayBuffer, [[InstancedMesh|InstancedMesh]]
+- **Projects/Contexts:** [[WebGL|WebGL]]/Three.js 대규모 CAD 렌더링 메모리 최적화, 다중 객체 드로우 콜 최적화 및 커스텀 셰이더 적용 맥락
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/BufferGeometry.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-2887C6
+id: [[P-Reinforce|P-Reinforce]]-AUTO-2887C6
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
 ---
 
-# [[BufferGeometry]]
+# [[BufferGeometry|BufferGeometry]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> BufferGeometry는 Three.js의 핵심 3D 기하학 구조를 정의하는 객체이다 [1]. [[InstancedMesh]] 기술에서 수많은 인스턴스가 공통으로 공유하는 기하학적 데이터로 사용된다 [2, 3]. 또한 여러 개의 지오메트리를 단일 BufferGeometry로 병합하여 렌더링 과정에서 발생하는 드로우 콜([[Draw Call]])을 최소화하는 성능 최적화의 핵심 단위로도 활용된다 [4, 5].
+> BufferGeometry는 Three.js의 핵심 3D 기하학 구조를 정의하는 객체이다 [1]. [[InstancedMesh|InstancedMesh]] 기술에서 수많은 인스턴스가 공통으로 공유하는 기하학적 데이터로 사용된다 [2, 3]. 또한 여러 개의 지오메트리를 단일 BufferGeometry로 병합하여 렌더링 과정에서 발생하는 드로우 콜([[Draw Call|Draw Call]])을 최소화하는 성능 최적화의 핵심 단위로도 활용된다 [4, 5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **InstancedMesh의 기본 데이터 레이어:** InstancedMesh 구조에서 BufferGeometry는 모든 개별 인스턴스가 공통으로 공유하는 기하학적 정의를 담당하는 주요 데이터 레이어이다 [2]. 다만, 하나의 InstancedMesh 인스턴스는 오직 하나의 BufferGeometry만을 참조할 수 있다는 기하학적 단일성의 제약이 존재한다 [6].
 * **지오메트리 병합(Merging)을 통한 최적화:** 정적인 환경이나 여러 개의 객체들을 렌더링할 때, `BufferGeometryUtils.mergeBufferGeometries()` 메서드를 사용하여 서로 다른 기하학적 데이터를 단일 BufferGeometry로 병합할 수 있다 [5, 7, 8]. 이를 통해 여러 객체를 단 한 번의 드로우 콜로 렌더링함으로써 CPU 오버헤드를 획기적으로 낮출 수 있다 [4].
-* **메모리 집약성 및 컬링(Culling) 효율의 한계:** 여러 객체를 하나의 BufferGeometry로 묶는 방식은 드로우 콜을 줄여주지만, 객체를 복제할 때마다 RAM 사용량이 정비례로 증가하는 메모리 집약적인 특성을 띤다 [4]. 더욱이 병합된 메쉬 전체가 하나의 단일 바운딩 볼륨(Bounding Volume)으로 취급되기 때문에, 화면 밖의 객체를 제외하는 시야 절두체 컬링([[Frustum Culling]])의 정밀도가 떨어지는 한계가 발생한다 [5].
+* **메모리 집약성 및 컬링(Culling) 효율의 한계:** 여러 객체를 하나의 BufferGeometry로 묶는 방식은 드로우 콜을 줄여주지만, 객체를 복제할 때마다 RAM 사용량이 정비례로 증가하는 메모리 집약적인 특성을 띤다 [4]. 더욱이 병합된 메쉬 전체가 하나의 단일 바운딩 볼륨(Bounding Volume)으로 취급되기 때문에, 화면 밖의 객체를 제외하는 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])의 정밀도가 떨어지는 한계가 발생한다 [5].
 * **개별 항목의 식별 및 접근:** 여러 객체를 거대한 BufferGeometry 하나로 병합한 후 특정 개별 요소를 선택하거나 수정하는 것은 까다롭지만, 버퍼 내 각 객체의 위치(Position) 데이터를 저장하는 매핑(Map) 구조를 구축하여 개별 항목을 효율적으로 조회하고 제어할 수 있다 [4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,7 +23,7 @@ github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call]], BufferGeometryUtils
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], [[Draw Call|Draw Call]], BufferGeometryUtils
 - **Projects/Contexts:** Three.js, IFC.js Fragment
 - **Contradictions/Notes:** 소스 문헌들은 성능 개선을 위해 객체들을 단일 BufferGeometry로 병합할 것을 권장하면서도, 이 방식이 드로우 콜을 최소화하는 대신 RAM 소모량을 높이고 시야 절두체 컬링의 효율을 저하시키는 트레이드오프(Trade-off)를 유발한다고 경고한다 [4, 5].
 

10_Wiki/Topics/Graphics & Performance/CPU Bottleneck.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-944A15
+id: [[P-Reinforce|P-Reinforce]]-AUTO-944A15
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,25 +7,25 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - CPU Bottleneck"
 ---
 
-# [[CPU Bottleneck]]
+# [[CPU Bottleneck|CPU Bottleneck]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D 그래픽스 및 실시간 렌더링 환경에서 CPU 병목(CPU Bottleneck)이란, CPU가 렌더링 명령어(드로우 콜)를 준비하고 GPU로 전송하거나 필요한 데이터 연산을 처리하는 속도가 느려져 GPU가 제 성능을 발휘하지 못하고 대기(Starve)하게 되는 현상을 말합니다 [1]. 주로 개별 모델에 대한 과도한 드로우 콜 발행이나 자바스크립트 메인 스레드에서의 무거운 연산(애니메이션, 정렬, 컬링 등)으로 인해 발생하며 [2-4], 이를 해결하기 위해 인스턴싱([[Instancing]])이나 연산의 GPU 오프로딩 기법이 사용됩니다 [5, 6].
+> 3D 그래픽스 및 실시간 렌더링 환경에서 CPU 병목(CPU Bottleneck)이란, CPU가 렌더링 명령어(드로우 콜)를 준비하고 GPU로 전송하거나 필요한 데이터 연산을 처리하는 속도가 느려져 GPU가 제 성능을 발휘하지 못하고 대기(Starve)하게 되는 현상을 말합니다 [1]. 주로 개별 모델에 대한 과도한 드로우 콜 발행이나 자바스크립트 메인 스레드에서의 무거운 연산(애니메이션, 정렬, 컬링 등)으로 인해 발생하며 [2-4], 이를 해결하기 위해 인스턴싱([[Instancing|Instancing]])이나 연산의 GPU 오프로딩 기법이 사용됩니다 [5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜 오버헤드 ([[Draw Call]] Overhead):** CPU 병목의 가장 주요한 원인입니다. CPU는 GPU에 그리기 명령을 내릴 때마다 변환 행렬, 셰이더 참조, 유니폼, 정점 버퍼 등의 렌더링 상태를 준비하고 통신해야 합니다 [2, 7]. 수백~수천 개의 개별 객체를 렌더링할 경우, 실제 폴리곤을 그리는 연산보다 CPU가 명령을 준비하고 발행하는 오버헤드가 시스템 버스에 막대한 부하를 가하여 병목을 유발합니다 [1, 7, 8].
-- **자바스크립트 메인 스레드 한계:** 웹 렌더링(Three.js 등) 환경에서 수만 개의 객체에 대해 수동으로 시야 절두체 컬링([[Frustum Culling]])을 계산하거나, 투명 객체의 깊이 정렬(예: [[Radix Sort]])을 수행할 경우 막대한 CPU 연산 비용이 발생합니다 [4, 9]. 단일 스레드 기반인 자바스크립트에서 렌더링 루프 내의 대규모 배열 조작은 메인 스레드를 점유하여 프레임 드랍을 유발하는 치명적인 CPU 병목을 낳습니다 [4, 9].
-- **애니메이션 및 레이캐스팅 부하:** 스킨드 메시(Skinned Mesh)의 뼈대(Bone) 애니메이션 시스템은 매 프레임 CPU에서 행렬 업데이트 연산을 요구하므로 다수의 캐릭터가 있을 경우 렌더링 예산을 초과하는 CPU 시간을 소모합니다 [3]. 또한 수만 개의 인스턴스 환경에서 CPU 기반 레이캐스팅([[Raycasting]])을 수행하면 각 인스턴스의 행렬을 일일이 역산해야 하므로 즉각적인 반응을 불가능하게 만드는 동기화 병목이 발생합니다 [10].
-- **입자 시스템 및 물리 연산:** CPU를 활용한 파티클 시스템 업데이트는 일반적인 하드웨어 기준 약 50,000개 수준에서 CPU 병목에 도달합니다 [5]. 이러한 연산 병목은 [[WebGPU]]의 컴퓨트 셰이더([[Compute Shader]]s)를 활용해 메인 스레드의 작업을 GPU 코어로 병렬 오프로드함으로써 해결할 수 있습니다 [5, 11].
+- **드로우 콜 오버헤드 ([[Draw Call|Draw Call]] Overhead):** CPU 병목의 가장 주요한 원인입니다. CPU는 GPU에 그리기 명령을 내릴 때마다 변환 행렬, 셰이더 참조, 유니폼, 정점 버퍼 등의 렌더링 상태를 준비하고 통신해야 합니다 [2, 7]. 수백~수천 개의 개별 객체를 렌더링할 경우, 실제 폴리곤을 그리는 연산보다 CPU가 명령을 준비하고 발행하는 오버헤드가 시스템 버스에 막대한 부하를 가하여 병목을 유발합니다 [1, 7, 8].
+- **자바스크립트 메인 스레드 한계:** 웹 렌더링(Three.js 등) 환경에서 수만 개의 객체에 대해 수동으로 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])을 계산하거나, 투명 객체의 깊이 정렬(예: [[Radix Sort|Radix Sort]])을 수행할 경우 막대한 CPU 연산 비용이 발생합니다 [4, 9]. 단일 스레드 기반인 자바스크립트에서 렌더링 루프 내의 대규모 배열 조작은 메인 스레드를 점유하여 프레임 드랍을 유발하는 치명적인 CPU 병목을 낳습니다 [4, 9].
+- **애니메이션 및 레이캐스팅 부하:** 스킨드 메시(Skinned Mesh)의 뼈대(Bone) 애니메이션 시스템은 매 프레임 CPU에서 행렬 업데이트 연산을 요구하므로 다수의 캐릭터가 있을 경우 렌더링 예산을 초과하는 CPU 시간을 소모합니다 [3]. 또한 수만 개의 인스턴스 환경에서 CPU 기반 레이캐스팅([[Raycasting|Raycasting]])을 수행하면 각 인스턴스의 행렬을 일일이 역산해야 하므로 즉각적인 반응을 불가능하게 만드는 동기화 병목이 발생합니다 [10].
+- **입자 시스템 및 물리 연산:** CPU를 활용한 파티클 시스템 업데이트는 일반적인 하드웨어 기준 약 50,000개 수준에서 CPU 병목에 도달합니다 [5]. 이러한 연산 병목은 [[WebGPU|WebGPU]]의 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)를 활용해 메인 스레드의 작업을 GPU 코어로 병렬 오프로드함으로써 해결할 수 있습니다 [5, 11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[Frustum Culling]]
-- **Projects/Contexts:** Three.js, [[WebGL]], [[WebGPU]]
-- **Contradictions/Notes:** `[[InstancedMesh]]` 기술은 수천 개의 객체를 단 한 번의 드로우 콜로 처리하여 CPU 병목을 획기적으로 해결하는 기술로 알려져 있습니다 [6, 12]. 그러나 이 방식은 개별 객체의 컬링이나 정렬 같은 내부 최적화를 지원하지 않으므로, 이를 극복하기 위해 CPU 단에서 수동으로 위치를 검사하고 버퍼를 재정렬하는 로직을 추가할 경우 오히려 이전보다 더 극심한 CPU 연산 병목이 발생하는 역설적인 상황이 빈번하게 발생합니다 [4, 9].
+- **Related Topics:** [[Draw Call|Draw Call]], InstancedMesh, [[Frustum Culling|Frustum Culling]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], [[WebGPU|WebGPU]]
+- **Contradictions/Notes:** `[[InstancedMesh|InstancedMesh]]` 기술은 수천 개의 객체를 단 한 번의 드로우 콜로 처리하여 CPU 병목을 획기적으로 해결하는 기술로 알려져 있습니다 [6, 12]. 그러나 이 방식은 개별 객체의 컬링이나 정렬 같은 내부 최적화를 지원하지 않으므로, 이를 극복하기 위해 CPU 단에서 수동으로 위치를 검사하고 버퍼를 재정렬하는 로직을 추가할 경우 오히려 이전보다 더 극심한 CPU 연산 병목이 발생하는 역설적인 상황이 빈번하게 발생합니다 [4, 9].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/CPU Overhead.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-38FA31
+id: [[P-Reinforce|P-Reinforce]]-AUTO-38FA31
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,28 +7,28 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - CPU Overhead"
 ---
 
-# [[CPU Overhead]]
+# [[CPU Overhead|CPU Overhead]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> CPU 오버헤드(CPU Overhead)는 웹 그래픽 렌더링 및 브라우저 실행 중에 중앙 처리 장치(CPU)에 가해지는 계산 부담 및 처리 지연을 의미합니다 [1, 2]. [[WebGL]]과 같은 기존 API에서는 단일 스레드 기반의 명령 제출과 [[JavaScript]] 실행이 CPU 병목 현상을 일으켜 GPU가 유휴 상태에 빠지게 만듭니다 [2, 3]. [[WebGPU]]와 같은 최신 API는 멀티 스레드 명령 생성과 컴퓨트 셰이더를 통한 연산 오프로딩을 통해 이러한 CPU 오버헤드를 대폭 감소시킵니다 [4, 5].
+> CPU 오버헤드(CPU Overhead)는 웹 그래픽 렌더링 및 브라우저 실행 중에 중앙 처리 장치(CPU)에 가해지는 계산 부담 및 처리 지연을 의미합니다 [1, 2]. [[WebGL|WebGL]]과 같은 기존 API에서는 단일 스레드 기반의 명령 제출과 JavaScript 실행이 CPU 병목 현상을 일으켜 GPU가 유휴 상태에 빠지게 만듭니다 [2, 3]. [[WebGPU|WebGPU]]와 같은 최신 API는 멀티 스레드 명령 생성과 컴퓨트 셰이더를 통한 연산 오프로딩을 통해 이러한 CPU 오버헤드를 대폭 감소시킵니다 [4, 5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **WebGL에서의 CPU 오버헤드 원인:** 
-  WebGL은 단일 스레드 실행 모델로 작동하여 모든 드로우 콜([[Draw Call]]), 상태 변경, 리소스 업로드가 순차적으로 실행되며 메인 스레드를 차단합니다 [2, 3]. 또한 브라우저의 보안 검사, 프로세스 격리를 위한 마샬링(marshalling), 그리고 [[ANGLE]]을 통한 API 변환([[OpenGL ES]]를 [[Direct3D]]로 변환) 과정은 드로우 콜마다 고정적인 오버헤드를 발생시킵니다 [6, 7]. 이는 결과적으로 GPU가 유휴 상태임에도 CPU가 병목이 되는 현상을 초래합니다 [6, 8].
+  WebGL은 단일 스레드 실행 모델로 작동하여 모든 드로우 콜([[Draw Call|Draw Call]]), 상태 변경, 리소스 업로드가 순차적으로 실행되며 메인 스레드를 차단합니다 [2, 3]. 또한 브라우저의 보안 검사, 프로세스 격리를 위한 마샬링(marshalling), 그리고 ANGLE을 통한 API 변환(OpenGL ES를 [[Direct3D|Direct3D]]로 변환) 과정은 드로우 콜마다 고정적인 오버헤드를 발생시킵니다 [6, 7]. 이는 결과적으로 GPU가 유휴 상태임에도 CPU가 병목이 되는 현상을 초래합니다 [6, 8].
 
 * **성능 및 사용자 환경에 미치는 영향:** 
   CPU 오버헤드는 프레임 드롭, 미세 지연(Micro-latency) 및 화면 끊김(Stuttering)의 주요 원인이 됩니다 [3, 9, 10]. 예를 들어 3D 가우시안 스플래팅(3DGS)과 같은 데이터 집약적 렌더링에서 수백만 개의 객체를 CPU에서 정렬할 경우, CPU-GPU 간 대규모 버퍼 전송과 동기화 병목 현상이 발생하여 프레임 예산을 초과하게 됩니다 [11, 12]. 특히 모바일 기기에서는 높은 CPU 오버헤드가 과도한 전력 소비와 발열로 이어지며, 이는 곧 열 쓰로틀링(Thermal throttling)에 의한 심각한 성능 저하를 유발합니다 [13-15].
 
 * **WebGPU와 구조적 최적화를 통한 해결:** 
-  WebGPU는 멀티 스레드를 통한 렌더링 명령 준비와 명시적이고 정적인 리소스 관리(GPU 리소스 읽기 전용화 등)를 지원하여 CPU 측의 재검증 오버헤드를 획기적으로 줄입니다 [4, 5, 16-18]. 컴퓨트 셰이더를 사용하여 물리 시뮬레이션이나 입자 시스템 같은 연산 논리를 GPU로 오프로딩하면 CPU-GPU 간의 왕복 통신과 JavaScript 실행 지연을 최소화하는 'GPU 주도(GPU-driven)' 렌더링이 가능해집니다 [13, 19]. 또한, 엔진 차원에서는 인스턴싱이나 배칭([[Batching]])을 통해 절대적인 드로우 콜 횟수를 최소화하는 것이 오버헤드 감소의 핵심입니다 [8, 20].
+  WebGPU는 멀티 스레드를 통한 렌더링 명령 준비와 명시적이고 정적인 리소스 관리(GPU 리소스 읽기 전용화 등)를 지원하여 CPU 측의 재검증 오버헤드를 획기적으로 줄입니다 [4, 5, 16-18]. 컴퓨트 셰이더를 사용하여 물리 시뮬레이션이나 입자 시스템 같은 연산 논리를 GPU로 오프로딩하면 CPU-GPU 간의 왕복 통신과 JavaScript 실행 지연을 최소화하는 'GPU 주도(GPU-driven)' 렌더링이 가능해집니다 [13, 19]. 또한, 엔진 차원에서는 인스턴싱이나 배칭([[Batching|Batching]])을 통해 절대적인 드로우 콜 횟수를 최소화하는 것이 오버헤드 감소의 핵심입니다 [8, 20].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], Draw Calls, Micro-latency, [[Compute Shaders]]
-- **Projects/Contexts:** [[3D Gaussian Splatting]] (3DGS), WebSplatter, [[ANGLE]]
+- **Related Topics:** [[WebGL|WebGL]], WebGPU, Draw Calls, Micro-latency, [[Compute Shaders|Compute Shaders]]
+- **Projects/Contexts:** [[3D_Gaussian_Splatting|3D Gaussian Splatting]] (3DGS), WebSplatter, [[ANGLE|ANGLE]]
 - **Contradictions/Notes:** 제공된 소스들 사이에서 명백한 모순은 발견되지 않습니다. 모든 소스가 WebGL의 단일 스레드 아키텍처가 야기하는 CPU 병목 현상을 WebGPU의 멀티 스레드 도입 및 명시적 리소스 관리로 극복한다는 공통된 기술적 진화를 설명하고 있습니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Cesium.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-8A58ED
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8A58ED
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Cesium"
 ---
 
-# [[Cesium]]
+# [[Cesium|Cesium]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 문서에서 Cesium은 3D 렌더링 중 메쉬 배칭(Mesh [[Batching]]) 기능인 `Batched3DModel`을 지원하는 환경으로 매우 짧게 언급되며, 주로 Three.js의 `BatchedMesh` 성능과 비교하기 위한 대조군으로 등장합니다 [1, 2].
+> 소스에 관련 정보가 부족합니다. 제공된 문서에서 Cesium은 3D 렌더링 중 메쉬 배칭(Mesh [[Batching|Batching]]) 기능인 `Batched3DModel`을 지원하는 환경으로 매우 짧게 언급되며, 주로 Three.js의 `BatchedMesh` 성능과 비교하기 위한 대조군으로 등장합니다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 소스에 관련 정보가 부족합니다. 

10_Wiki/Topics/Graphics & Performance/Chrome (Blink_Dawn).md

@@ -1,30 +1,30 @@
 ---
-id: [[P-Reinforce]]-AUTO-3115F7
+id: [[P-Reinforce|P-Reinforce]]-AUTO-3115F7
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Chrome]] ([[Blink]]_Dawn)"
+github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] ([[Blink|Blink]]_Dawn)"
 ---
 
-# [[Chrome (Blink_Dawn)]]
+# [[Chrome (Blink_Dawn)|Chrome (Blink_Dawn]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome(Blink/Dawn)은 구글 크롬 브라우저의 핵심 엔진인 Blink와 [[WebGPU]] 백엔드인 Dawn을 지칭합니다 [1, 2]. 이들은 웹 환경에서 고성능 그래픽 및 연산 파이프라인을 처리하는 동시에, [[Spectre]] 및 Meltdown과 같은 보안 취약점을 방지하기 위해 정밀 타이머 접근을 제한하는 보안 메커니즘을 구현하고 있습니다 [1, 2]. 또한 개발자가 웹 애플리케이션의 성능 병목 현상을 식별할 수 있도록 심층적인 프로세스 트레이싱 및 프로파일링 환경을 제공합니다 [3-5].
+> Chrome(Blink/Dawn)은 구글 크롬 브라우저의 핵심 엔진인 Blink와 [[WebGPU|WebGPU]] 백엔드인 Dawn을 지칭합니다 [1, 2]. 이들은 웹 환경에서 고성능 그래픽 및 연산 파이프라인을 처리하는 동시에, [[Spectre|Spectre]] 및 Meltdown과 같은 보안 취약점을 방지하기 위해 정밀 타이머 접근을 제한하는 보안 메커니즘을 구현하고 있습니다 [1, 2]. 또한 개발자가 웹 애플리케이션의 성능 병목 현상을 식별할 수 있도록 심층적인 프로세스 트레이싱 및 프로파일링 환경을 제공합니다 [3-5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **WebGPU 백엔드(Dawn)와 타임스탬프 양자화:** Dawn은 Chrome의 WebGPU 백엔드로 작동하며, 타이밍 기반의 정보 유출(timing-based information leaks)을 막기 위해 '타임스탬프 양자화(timestamp [[Quantization]])' 기능을 구현하고 있습니다 [1]. 이 기능은 쿼리의 해상도를 100 마이크로초 단위 등으로 의도적으로 낮추어 제공하며, 격리된 컨텍스트(isolated contexts)에 한해 이 해상도로 노출됩니다 [1, 6]. Dawn에는 "timestamp_quantization"이라는 디바이스 토글이 존재하며 이는 기본적으로 활성화되어 있습니다 [7]. 다만, 성능 프로파일링이 필요한 개발자의 경우 로컬 환경에서 "WebGPU Developer Features" 플래그를 활성화하여 이러한 양자화 제한을 우회할 수 있습니다 [1, 7].
+- **WebGPU 백엔드(Dawn)와 타임스탬프 양자화:** Dawn은 Chrome의 WebGPU 백엔드로 작동하며, 타이밍 기반의 정보 유출(timing-based information leaks)을 막기 위해 '타임스탬프 양자화(timestamp [[Quantization|Quantization]])' 기능을 구현하고 있습니다 [1]. 이 기능은 쿼리의 해상도를 100 마이크로초 단위 등으로 의도적으로 낮추어 제공하며, 격리된 컨텍스트(isolated contexts)에 한해 이 해상도로 노출됩니다 [1, 6]. Dawn에는 "timestamp_quantization"이라는 디바이스 토글이 존재하며 이는 기본적으로 활성화되어 있습니다 [7]. 다만, 성능 프로파일링이 필요한 개발자의 경우 로컬 환경에서 "WebGPU Developer Features" 플래그를 활성화하여 이러한 양자화 제한을 우회할 수 있습니다 [1, 7].
 - **렌더링 엔진(Blink)의 보안 아키텍처 재설계:** Spectre와 Meltdown 취약점이 발견된 이후, 웹 타이밍 보안에 대한 근본적인 재설계가 이루어졌습니다 [2]. 이에 따라 Chrome의 Blink 엔진은 타이머 정밀도를 감소시키고 분기 없는(branchless) 보안 검사를 구현하는 형태의 2단계 방어 체계로 전환하여 공격자가 캐시 사이드 채널 공격을 위해 필요한 서브-마이크로초 단위의 타이밍 차이를 관찰하지 못하도록 조치했습니다 [2, 8].
-- **다중 프로세스 아키텍처 및 프로파일링:** Chrome의 `about:tracing` 도구를 사용하면 브라우저 내부의 다중 프로세스 아키텍처를 상세하게 검사할 수 있습니다 [3]. 특히 [[JavaScript]]가 실행되는 렌더러 프로세스인 "CrRendererMain" 스레드와 드라이버 인터페이스가 위치한 GPU 프로세스인 "CrGpuMain" 스레드 간의 통신과 부하를 분석하는 데 유용합니다 [3, 4, 9]. 엔지니어는 트레이스를 분석하여 "CrRendererMain"은 비어있으나 "CrGpuMain"이 계속 활성화되어 있는 것을 보고 시스템이 GPU 바운드(GPU bound) 상태인지 등을 정확히 파악할 수 있습니다 [4, 10, 11].
+- **다중 프로세스 아키텍처 및 프로파일링:** Chrome의 `about:tracing` 도구를 사용하면 브라우저 내부의 다중 프로세스 아키텍처를 상세하게 검사할 수 있습니다 [3]. 특히 [[JavaScript|JavaScript]]가 실행되는 렌더러 프로세스인 "CrRendererMain" 스레드와 드라이버 인터페이스가 위치한 GPU 프로세스인 "CrGpuMain" 스레드 간의 통신과 부하를 분석하는 데 유용합니다 [3, 4, 9]. 엔지니어는 트레이스를 분석하여 "CrRendererMain"은 비어있으나 "CrGpuMain"이 계속 활성화되어 있는 것을 보고 시스템이 GPU 바운드(GPU bound) 상태인지 등을 정확히 파악할 수 있습니다 [4, 10, 11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timestamp Queries]], [[Spectre and Meltdown]]
-- **Projects/Contexts:** [[Chrome DevTools]], about:tracing
-- **Contradictions/Notes:** 타임스탬프 쿼리 해상도와 관련하여 초기에는 격리된 컨텍스트(isolated contexts) 여부에 따라 다르게 노출되는 방안이 논의되었으나, 향후 W3C의 High Re[[Solution]] Time 사양과 일치시켜 사이트 격리 여부와 관계없이 100 마이크로초(100us) 해상도를 허용하는 방향으로 [[GPU for the Web Comm[[Unity]] Group]]에서 합의를 이루었습니다 [6, 12, 13].
+- **Related Topics:** [[WebGPU|WebGPU]], Timestamp Queries, [[Spectre and Meltdown|Spectre and Meltdown]]
+- **Projects/Contexts:** [[Chrome DevTools|Chrome DevTools]], about:tracing
+- **Contradictions/Notes:** 타임스탬프 쿼리 해상도와 관련하여 초기에는 격리된 컨텍스트(isolated contexts) 여부에 따라 다르게 노출되는 방안이 논의되었으나, 향후 W3C의 High Re[[Solution|Solution]] Time 사양과 일치시켜 사이트 격리 여부와 관계없이 100 마이크로초(100us) 해상도를 허용하는 방향으로 GPU for the Web CommUnity Group에서 합의를 이루었습니다 [6, 12, 13].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Chrome WebGPU 구현.md

@@ -1,24 +1,24 @@
 ---
-id: [[P-Reinforce]]-AUTO-7CCB76
+id: [[P-Reinforce|P-Reinforce]]-AUTO-7CCB76
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Chrome]] [[WebGPU]] 구현"
+github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] [[WebGPU|WebGPU]] 구현"
 ---
 
-# [[Chrome WebGPU 구현]]
+# [[Chrome WebGPU 구현|Chrome WebGPU 구현]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > Chrome은 113 버전부터 WebGPU를 기본으로 활성화하여 차세대 웹 그래픽스 및 컴퓨팅 API를 지원하기 시작했습니다 [1, 2]. Chrome의 WebGPU 구현체는 'Dawn'이라는 백엔드와 'Tint' 셰이더 컴파일러를 기반으로 작동하며, 성능 향상과 보안 강화를 위한 다양한 기능(예: 16비트 부동소수점 지원, 타임스탬프 양자화 등)을 지속적으로 업데이트하고 있습니다 [3-5]. 초기 데스크톱 지원을 시작으로 현재는 Android 환경까지 지원을 확장하여 이식성 높고 강력한 GPU 가속 환경을 제공합니다 [6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **Dawn 백엔드 및 구조:** 
-    Chrome의 WebGPU 구현은 자체 백엔드 엔진인 'Dawn'과 셰이더 컴파일을 담당하는 'Tint'를 중심으로 구축되었습니다 [3, 7]. [[Chromium]] 프로젝트는 WebGPU 및 WGSL의 적합성 테스트(CTS)를 정기적으로 통합하여 이들 컴포넌트의 안정성과 스펙 준수 여부를 검증하고 있습니다 [3].
+    Chrome의 WebGPU 구현은 자체 백엔드 엔진인 'Dawn'과 셰이더 컴파일을 담당하는 'Tint'를 중심으로 구축되었습니다 [3, 7]. [[Chromium|Chromium]] 프로젝트는 WebGPU 및 WGSL의 적합성 테스트(CTS)를 정기적으로 통합하여 이들 컴포넌트의 안정성과 스펙 준수 여부를 검증하고 있습니다 [3].
 *   **성능 최적화 및 WGSL 확장:** 
-    Chrome 120부터는 WGSL(WebGPU Shading Language)에서 16비트 부동소수점(`f16`) 타입을 지원합니다 [4]. 이는 32비트(`f32`) 타입 대비 메모리 사용량을 크게 줄여주어, WebLLM과 같은 대용량 머신러닝 모델을 브라우저에서 실행할 때 사전 채우기(prefill) 속도 28%, 디코딩 속도 41% 향상 등 극적인 성능 개선을 제공합니다 [4]. 더불어 `maxColorAttachmentBytesPerSample`, `max[[Storage]]BuffersPerShaderStage` 등 파이프라인 리소스의 최대 제한(Limits)을 확장하여 더욱 복잡한 렌더링을 수용할 수 있도록 하였습니다 [8, 9].
-*   **보안과 타임스탬프 쿼리([[Timestamp Queries]]) 구현:** 
-    GPU 명령의 실행 시간을 나노초 단위로 정밀 측정할 수 있는 타임스탬프 쿼리 기능이 구현되었습니다 [10]. 그러나 고해상도 타이머를 악용한 부채널 공격(예: [[Spectre]])을 방지하기 위해, Chrome은 해당 타이밍 데이터의 해상도를 100마이크로초(100us) 단위로 강제 양자화([[Quantization]])하여 노출합니다 [5, 11, 12]. 성능 프로파일링이 필요한 개발자의 경우, `chrome://flags`에서 `enable-webgpu-developer-features` 및 `enable-unsafe-webgpu` 플래그를 활성화하여 이 양자화 조치를 끄고 정밀 측정을 수행할 수 있습니다 [7, 13].
+    Chrome 120부터는 WGSL(WebGPU Shading Language)에서 16비트 부동소수점(`f16`) 타입을 지원합니다 [4]. 이는 32비트(`f32`) 타입 대비 메모리 사용량을 크게 줄여주어, WebLLM과 같은 대용량 머신러닝 모델을 브라우저에서 실행할 때 사전 채우기(prefill) 속도 28%, 디코딩 속도 41% 향상 등 극적인 성능 개선을 제공합니다 [4]. 더불어 `maxColorAttachmentBytesPerSample`, `max[[Storage|Storage]]BuffersPerShaderStage` 등 파이프라인 리소스의 최대 제한(Limits)을 확장하여 더욱 복잡한 렌더링을 수용할 수 있도록 하였습니다 [8, 9].
+*   **보안과 타임스탬프 쿼리([[Timestamp Queries|Timestamp Queries]]) 구현:** 
+    GPU 명령의 실행 시간을 나노초 단위로 정밀 측정할 수 있는 타임스탬프 쿼리 기능이 구현되었습니다 [10]. 그러나 고해상도 타이머를 악용한 부채널 공격(예: [[Spectre|Spectre]])을 방지하기 위해, Chrome은 해당 타이밍 데이터의 해상도를 100마이크로초(100us) 단위로 강제 양자화([[Quantization|Quantization]])하여 노출합니다 [5, 11, 12]. 성능 프로파일링이 필요한 개발자의 경우, `chrome://flags`에서 `enable-webgpu-developer-features` 및 `enable-unsafe-webgpu` 플래그를 활성화하여 이 양자화 조치를 끄고 정밀 측정을 수행할 수 있습니다 [7, 13].
 *   **플랫폼 지원 확대:** 
     Chrome 121 버전부터는 Android 기기에서의 WebGPU 지원이 공식 추가되었으며, Windows 시스템에서는 셰이더 컴파일러를 기존 FXC에서 더 효율적인 DXC로 교체하여 컴파일 성능을 최적화했습니다 [6]. 이후로도 서브그룹(Subgroups) 기능 실험, 다중 간접 그리기(multi-draw indirect), HDR 톤 매핑 지원 등 매 버전마다 지속적으로 GPU 기능이 추가되고 있습니다 [6, 14-16].
 
@@ -28,7 +28,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Chrome]] [[WebGPU]] 구현"
 
 ## 🔗 지식 연결 (Graph)
 - **Related Topics:** Dawn, WGSL, 타임스탬프 쿼리 (Timestamp Queries), f16 부동소수점
-- **Projects/Contexts:** [[Chromium]], [[GPU for the Web Comm[[Unity]] Group]]
+- **Projects/Contexts:** [[Chromium|Chromium]], GPU for the Web CommUnity Group
 - **Contradictions/Notes:** 소스에 따르면 WebGPU 타임스탬프 쿼리의 노출 정책에 대한 변화가 있었습니다. 초기에는 보안 문제로 인해 "사이트 격리(Site isolation)가 된 컨텍스트에서만 100마이크로초로 노출하고 비격리 상태에서는 아예 노출하지 않는 방안"이 크롬 팀에 의해 제안되었습니다 [12]. 그러나 플랫폼 간의 상호 운용성(Interop) 문제를 지적하는 의견에 따라, 최종적으로는 격리 여부와 관계없이 고해상도 시간(hr-time) 스펙에 맞춰 일괄적으로 100마이크로초 해상도로 노출하는 것으로 합의되었습니다 [17, 18].
 
 ---

10_Wiki/Topics/Graphics & Performance/Chrome _ Blink WebGPU Implementation.md

@@ -1,39 +1,39 @@
 ---
-id: [[P-Reinforce]]-AUTO-4FF4D6
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4FF4D6
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Chrome]] _ [[Blink]] [[WebGPU]] Implementation"
+github_commit: "[P-Reinforce] Continuous Worker - [[Chrome|Chrome]] _ Blink [[WebGPU|WebGPU]] Implementation"
 ---
 
-# [[Chrome _ Blink WebGPU Implementation]]
+# [[Chrome _ Blink WebGPU Implementation|Chrome _ Blink WebGPU Implementation]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome과 Blink 엔진에서 WebGPU를 구현한 방식은 현대적인 GPU 파이프라인의 이점을 웹에 제공하면서도 하드웨어 보안을 유지하도록 설계되었습니다. 특히 타이밍 공격을 방지하기 위해 타임스탬프 쿼리에 양자화([[Quantization]])를 적용하여 해상도를 제한합니다. Chrome 백엔드 엔진인 Dawn을 기반으로 구동되며, 지속적인 업데이트(예: Chrome 120)를 통해 16비트 부동소수점 지원 및 GPU 리소스 할당 한계를 확장하여 성능과 개발자 경험을 향상시키고 있습니다.
+> Chrome과 Blink 엔진에서 WebGPU를 구현한 방식은 현대적인 GPU 파이프라인의 이점을 웹에 제공하면서도 하드웨어 보안을 유지하도록 설계되었습니다. 특히 타이밍 공격을 방지하기 위해 타임스탬프 쿼리에 양자화([[Quantization|Quantization]])를 적용하여 해상도를 제한합니다. Chrome 백엔드 엔진인 Dawn을 기반으로 구동되며, 지속적인 업데이트(예: Chrome 120)를 통해 16비트 부동소수점 지원 및 GPU 리소스 할당 한계를 확장하여 성능과 개발자 경험을 향상시키고 있습니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **Dawn 백엔드와 타임스탬프 양자화([[Timestamp Quantization]]):** 
-  Chrome의 WebGPU 백엔드인 Dawn과 Blink 엔진은 `timestamp-query`와 `GPUQuerySet`을 통해 연산 및 렌더링 패스 경계에서 나노초 단위의 정밀한 타이밍 측정이 가능한 API를 구현했습니다 [1, 2]. 그러나 [[Spectre]] 및 Meltdown과 같은 타이밍 기반의 사이드 채널 공격([[Side-channel Attack]]s)을 방지하기 위해, 브라우저 구현체는 타임스탬프 양자화를 강제하여 타이머의 해상도를 100 마이크로초 단위로 낮추어(Coarsening) 제공합니다 [1, 3-5].
+* **Dawn 백엔드와 타임스탬프 양자화([[Timestamp Quantization|Timestamp Quantization]]):** 
+  Chrome의 WebGPU 백엔드인 Dawn과 Blink 엔진은 `timestamp-query`와 `GPUQuerySet`을 통해 연산 및 렌더링 패스 경계에서 나노초 단위의 정밀한 타이밍 측정이 가능한 API를 구현했습니다 [1, 2]. 그러나 [[Spectre|Spectre]] 및 Meltdown과 같은 타이밍 기반의 사이드 채널 공격([[Side-channel Attack|Side-channel Attack]]s)을 방지하기 위해, 브라우저 구현체는 타임스탬프 양자화를 강제하여 타이머의 해상도를 100 마이크로초 단위로 낮추어(Coarsening) 제공합니다 [1, 3-5].
 
 * **사이트 격리(Site Isolation) 정책 변경:**
-  타임스탬프 쿼리의 노출은 초기에는 사이트 격리 환경(Isolated contexts)에서는 100 마이크로초로 제한하고 비격리 환경에서는 아예 노출하지 않는 방향으로 제안되었습니다 [5]. 그러나 최종적으로 [[GPU for the Web Comm[[Unity]] Group]]의 합의를 거쳐, 사이트 격리 여부와 무관하게 `hr-time`의 해상도에 맞춰 항상 100 마이크로초 단위로 타임스탬프를 허용하는 것으로 변경 및 적용되었습니다 [6-8].
+  타임스탬프 쿼리의 노출은 초기에는 사이트 격리 환경(Isolated contexts)에서는 100 마이크로초로 제한하고 비격리 환경에서는 아예 노출하지 않는 방향으로 제안되었습니다 [5]. 그러나 최종적으로 [[GPU for the Web Community Group|GPU for the Web CommUnity Group]]의 합의를 거쳐, 사이트 격리 여부와 무관하게 `hr-time`의 해상도에 맞춰 항상 100 마이크로초 단위로 타임스탬프를 허용하는 것으로 변경 및 적용되었습니다 [6-8].
 
 * **개발자 환경에서의 보안 우회:** 
   성능 프로파일링을 위해 로컬 환경에서 정확한 나노초 단위의 타이밍 측정이 필요한 개발자는 `chrome://flags/#enable-webgpu-developer-features` 및 `chrome://flags/#enable-unsafe-webgpu` 플래그를 활성화하여 타임스탬프 양자화를 비활성화할 수 있습니다 [3, 9]. 이 경우 Dawn 내부의 `timestamp_quantization` 디바이스 토글이 해제된 상태로 WebGPU 디바이스가 요청됩니다 [9].
 
 * **WGSL 기능 확장 및 리소스 제한 상향 (Chrome 120 기준):**
-  Chrome 120 업데이트부터 WebGPU 구현은 WGSL(WebGPU Shading Language)에서 16비트 부동소수점 값(`f16`)을 지원하기 시작했습니다. 이는 기존 `f32` 대비 메모리 사용량을 줄여 대규모 데이터를 처리하는 머신러닝(LLM 등) 구동 시 로딩 및 디코딩 속도를 대폭 향상시킵니다 [10, 11]. 이 외에도 `maxColorAttachmentBytesPerSample`을 최대 64바이트로 상향하고, `max[[Storage]]BuffersPerShaderStage`를 최대 10개까지, `maxBindGroupsPlusVertexBuffers`의 기본값을 24로 늘리는 등 하드웨어 리소스의 한계를 확장했습니다 [12, 13]. 
+  Chrome 120 업데이트부터 WebGPU 구현은 WGSL(WebGPU Shading Language)에서 16비트 부동소수점 값(`f16`)을 지원하기 시작했습니다. 이는 기존 `f32` 대비 메모리 사용량을 줄여 대규모 데이터를 처리하는 머신러닝(LLM 등) 구동 시 로딩 및 디코딩 속도를 대폭 향상시킵니다 [10, 11]. 이 외에도 `maxColorAttachmentBytesPerSample`을 최대 64바이트로 상향하고, `max[[Storage|Storage]]BuffersPerShaderStage`를 최대 10개까지, `maxBindGroupsPlusVertexBuffers`의 기본값을 24로 늘리는 등 하드웨어 리소스의 한계를 확장했습니다 [12, 13]. 
 
 * **상태 관리 및 어댑터 정보 간소화:** 
-  개발자 편의를 위해 `depthWriteEnabled`와 `depthCompare`와 같은 Depth-stencil 상태 속성이 항상 필수로 요구되지 않도록 동작이 개선되었습니다 [14]. 또한 `requestAdapterInfo()`를 호출할 때 "discrete GPU", "integrated GPU" 같은 디바이스 타입과 "D3D12", "[[Metal]]", "[[Vulkan]]" 등 백엔드 API에 대한 세부적인 정보를 조회할 수 있는 기능이 추가되었습니다 [14].
+  개발자 편의를 위해 `depthWriteEnabled`와 `depthCompare`와 같은 Depth-stencil 상태 속성이 항상 필수로 요구되지 않도록 동작이 개선되었습니다 [14]. 또한 `requestAdapterInfo()`를 호출할 때 "discrete GPU", "integrated GPU" 같은 디바이스 타입과 "D3D12", "[[Metal|Metal]]", "[[Vulkan|Vulkan]]" 등 백엔드 API에 대한 세부적인 정보를 조회할 수 있는 기능이 추가되었습니다 [14].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** WebGPU [[Timestamp Queries]], Dawn, [[Spectre and Meltdown]], WGSL
+- **Related Topics:** WebGPU [[Timestamp Queries|Timestamp Queries]], Dawn, [[Spectre and Meltdown|Spectre and Meltdown]], WGSL
 - **Projects/Contexts:** Chrome 120 WebGPU Updates
 - **Contradictions/Notes:** 소스에 따르면, 타임스탬프 노출에 대한 초기 제안은 보안을 이유로 비격리 컨텍스트에서는 타임스탬프를 전혀 제공하지 않는 것이었으나 [5], 이후 상호 운용성(Interop) 문제를 해결하기 위해 GPU for the Web 커뮤니티 그룹의 합의를 거쳐 컨텍스트의 격리 여부와 상관없이 100 마이크로초 단위로 값을 제공하는 것으로 정책이 수정되었습니다 [6].
 

10_Wiki/Topics/Graphics & Performance/Chrome.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-5D281C
+id: [[P-Reinforce|P-Reinforce]]-AUTO-5D281C
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,25 +7,25 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Chrome"
 ---
 
-# [[Chrome]]
+# [[Chrome|Chrome]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome은 웹 성능 표준과 최신 웹 그래픽 기술을 주도하는 Google의 웹 브라우저이다 [1, 2]. 강력한 개발자 도구인 [[Chrome DevTools]]를 제공하여 애플리케이션의 런타임 및 로드 성능을 심층적으로 분석할 수 있게 하며, [[WebGL]] 및 [[WebGPU]]와 같은 차세대 그래픽 API를 적극적으로 지원한다 [3, 4]. 또한 Chrome 사용자 환경 보고서([[CrUX]])를 통해 실제 사용자의 성능 데이터를 수집하여 [[Core Web Vitals]]를 측정하는 핵심적인 역할을 담당한다 [5, 6].
+> Chrome은 웹 성능 표준과 최신 웹 그래픽 기술을 주도하는 Google의 웹 브라우저이다 [1, 2]. 강력한 개발자 도구인 [[Chrome DevTools|Chrome DevTools]]를 제공하여 애플리케이션의 런타임 및 로드 성능을 심층적으로 분석할 수 있게 하며, WebGL 및 WebGPU와 같은 차세대 그래픽 API를 적극적으로 지원한다 [3, 4]. 또한 Chrome 사용자 환경 보고서([[CrUX|CrUX]])를 통해 실제 사용자의 성능 데이터를 수집하여 [[Core Web Vitals|Core Web Vitals]]를 측정하는 핵심적인 역할을 담당한다 [5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **웹 성능 측정 및 Core Web Vitals**: Chrome은 LCP, CLS, INP(기존 FID 대체)와 같은 Core Web Vitals 지표를 브라우저 단에서 직접 측정하며, 이를 Chrome UX Report (CrUX)를 통해 필드 데이터로 수집한다 [5-7]. 최근에는 교차 출처 이미지에 대한 LCP 측정 방식이나 텍스트 강조 시의 INP 처리 방식 등 지표의 정확도를 높이기 위해 측정 방식을 지속적으로 업데이트하고 있다 [8-10].
-- **Chrome DevTools 및 프로파일링**: Chrome DevTools의 Performance 패널을 통해 런타임 성능, CPU 및 네트워크 스로틀링(Throttling), 메인 스레드의 [[Flame Chart]] 등을 분석할 수 있다 [11-13]. Chrome 129 버전부터는 Performance 탭에서 CrUX 필드 데이터와 로컬 데이터를 실시간으로 비교하는 Live metrics 기능이 추가되었다 [14, 15]. 또한 `about:tracing` 도구를 제공하여 `CrGpuMain`, `CrRendererMain` 등 CPU와 GPU의 저수준 활동을 나노초 단위로 정밀하게 프로파일링할 수 있다 [16-18].
+- **Chrome DevTools 및 프로파일링**: Chrome DevTools의 Performance 패널을 통해 런타임 성능, CPU 및 네트워크 스로틀링(Throttling), 메인 스레드의 [[Flame Chart|Flame Chart]] 등을 분석할 수 있다 [11-13]. Chrome 129 버전부터는 Performance 탭에서 CrUX 필드 데이터와 로컬 데이터를 실시간으로 비교하는 Live metrics 기능이 추가되었다 [14, 15]. 또한 `about:tracing` 도구를 제공하여 `CrGpuMain`, `CrRendererMain` 등 CPU와 GPU의 저수준 활동을 나노초 단위로 정밀하게 프로파일링할 수 있다 [16-18].
 - **차세대 그래픽 기술 (WebGPU 및 WebGL) 지원**: Chrome은 113 버전부터 WebGPU를 기본적으로 지원하기 시작했으며 [2], Dawn이라는 WebGPU 백엔드를 사용한다 [19]. Chrome 120~146 버전에 걸쳐 WGSL의 16비트 부동소수점(`f16`) 지원, subgroup 기능, 호환성 모드(Compatibility mode) 등 WebGPU의 기능을 지속적으로 확장하고 있다 [20-22].
-- **보안 및 타이밍 제어**: [[Spectre]] 및 Meltdown과 같은 보안 취약점에 대응하기 위해, Chrome은 `performance.now()` 및 WebGPU 타임스탬프 쿼리의 정밀도를 제한([[Quantization]])한다 [19, 23, 24]. 교차 출처 격리(Cross-origin isolated) 상태에 따라 100 마이크로초 단위로 해상도를 낮추며, 개발자 플래그(`chrome://flags/`)를 통해서만 제한을 해제할 수 있도록 보안과 디버깅의 균형을 맞추고 있다 [19, 24, 25].
-- **실험적 기능 (Origin Trials) 및 AI 도입**: 웹 페이지가 전환될 때의 소프트 내비게이션([[Soft Navigation]]s) 성능을 측정하기 위한 API 실험을 진행 중이며 [26], Speculation rules를 통해 미래의 내비게이션에 필요한 리소스를 미리 렌더링하는 기능도 지원한다 [10, 27]. 더 나아가 DevTools 내에 AI 디버깅 기능과 [[Model Context Protocol (MCP)]] 서버를 도입하여 성능 데이터를 기반으로 코드 변경을 자동화하는 실험도 제공하고 있다 [28, 29].
+- **보안 및 타이밍 제어**: [[Spectre|Spectre]] 및 Meltdown과 같은 보안 취약점에 대응하기 위해, Chrome은 `performance.now()` 및 WebGPU 타임스탬프 쿼리의 정밀도를 제한([[Quantization|Quantization]])한다 [19, 23, 24]. 교차 출처 격리(Cross-origin isolated) 상태에 따라 100 마이크로초 단위로 해상도를 낮추며, 개발자 플래그(`chrome://flags/`)를 통해서만 제한을 해제할 수 있도록 보안과 디버깅의 균형을 맞추고 있다 [19, 24, 25].
+- **실험적 기능 (Origin Trials) 및 AI 도입**: 웹 페이지가 전환될 때의 소프트 내비게이션([[Soft Navigation|Soft Navigation]]s) 성능을 측정하기 위한 API 실험을 진행 중이며 [26], Speculation rules를 통해 미래의 내비게이션에 필요한 리소스를 미리 렌더링하는 기능도 지원한다 [10, 27]. 더 나아가 DevTools 내에 AI 디버깅 기능과 [[Model Context Protocol (MCP)|Model Context Protocol (MCP]] 서버를 도입하여 성능 데이터를 기반으로 코드 변경을 자동화하는 실험도 제공하고 있다 [28, 29].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[WebGPU]], [[Core Web Vitals]], [[CrUX]], [[WebGL]]
-- **Projects/Contexts:** [[Interop 2025]], [[Baseline Project]]
+- **Related Topics:** [[Chrome DevTools|Chrome DevTools]], WebGPU, Core Web Vitals, [[CrUX|CrUX]], [[WebGL|WebGL]]
+- **Projects/Contexts:** [[Interop 2025|Interop 2025]], [[Baseline Project|Baseline Project]]
 - **Contradictions/Notes:** 타이밍 공격(Spectre 등) 보안 문제로 인해 WebGPU의 타임스탬프 쿼리나 `EXT_disjoint_timer_query`의 해상도를 하드웨어 성능 그대로 제공하지 못하고, Chrome 자체적으로 사이트 격리 상태에 따라 정밀도를 의도적으로 낮추어(Quantization) 노출해야만 하는 한계가 존재한다 [19, 23, 24].
 
 ---

10_Wiki/Topics/Graphics & Performance/Chromium WebGPU Implementation.md

@@ -1,29 +1,29 @@
 ---
-id: [[P-Reinforce]]-AUTO-7025AF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-7025AF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Chromium]] [[WebGPU]] Implementation"
+github_commit: "[P-Reinforce] Continuous Worker - [[Chromium|Chromium]] [[WebGPU|WebGPU]] Implementation"
 ---
 
-# [[Chromium WebGPU Implementation]]
+# [[Chromium WebGPU Implementation|Chromium WebGPU Implementation]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chromium의 WebGPU 구현은 **Dawn**이라는 백엔드를 기반으로 하는 차세대 웹 그래픽 및 컴퓨팅 API입니다 [1, 2]. 보안 이슈를 방지하기 위한 타임스탬프 양자화(Timestamp [[Quantization]])와 같은 세밀한 기능이 구현되어 있으며, 싱글 스레드 기반인 [[WebGL]]의 한계를 넘어 멀티 스레드 명령 생성과 강력한 컴퓨트 셰이더 기능을 통해 브라우저 내에서 고성능 그래픽과 병렬 연산을 지원합니다 [1, 3, 4].
+> Chromium의 WebGPU 구현은 **Dawn**이라는 백엔드를 기반으로 하는 차세대 웹 그래픽 및 컴퓨팅 API입니다 [1, 2]. 보안 이슈를 방지하기 위한 타임스탬프 양자화(Timestamp [[Quantization|Quantization]])와 같은 세밀한 기능이 구현되어 있으며, 싱글 스레드 기반인 [[WebGL|WebGL]]의 한계를 넘어 멀티 스레드 명령 생성과 강력한 컴퓨트 셰이더 기능을 통해 브라우저 내에서 고성능 그래픽과 병렬 연산을 지원합니다 [1, 3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **Dawn 백엔드 및 구조:** Chromium에서 WebGPU API를 구동하는 내부 백엔드 엔진의 이름은 Dawn입니다 [1, 2]. 이 구현체는 WebGL의 기존 싱글 스레드 명령 제출 모델에서 벗어나, 여러 스레드에서 동시에 렌더링 명령을 준비(Multi-Threaded Command Generation)할 수 있도록 설계되어 CPU 오버헤드를 대폭 줄이고 GPU 활용도를 극대화합니다 [3].
-*   **보안 및 타임스탬프 양자화 ([[Timestamp Quantization]]):** 고정밀 타이머를 악용한 캐시 사이드 채널 공격(예: [[Spectre]] 및 Meltdown)을 방지하기 위해, [[Blink]] 및 Dawn 구현체는 타임스탬프 쿼리 결과의 해상도를 100 마이크로초(µs)로 양자화(Coarsening)하여 제공합니다 [1, 5, 6]. [[Chrome]]은 초기에는 보안을 위해 격리되지 않은 컨텍스트(non-isolated contexts)에서 이를 완전히 비활성화하려 했으나, 최종적으로 웹 표준 상호 운용성을 고려해 격리 여부와 무관하게 100µs 해상도를 제공하는 것으로 합의되었습니다 [5-7]. 단, 로컬 개발 환경에서 정밀한 성능 프로파일링이 필요할 때는 `chrome://flags`에서 "WebGPU Developer Features" 및 "Unsafe WebGPU [[Support]]" 플래그를 켜서 이 양자화를 비활성화할 수 있습니다 [1, 2].
-*   **버전별 주요 진화 과정:** Chrome 113 버전에서 WebGPU가 최초로 기본 활성화된 이후, Chromium 팀은 렌더링 및 머신러닝 기능 확장을 지속해 왔습니다 [8, 9]. 예를 들어, Chrome 120에서는 WGSL 내 16비트 부동소수점(`f16`) 지원을 추가하여 Llama2 모델과 같은 LLM 추론 속도를 비약적으로 향상시켰습니다 [10]. 이후 버전들에서는 서브그룹(Subgroup) 연산 확장, 3D 텍스처 포맷 지원, [[OpenGL ES]] 3.1 호환성 모드 등 다양한 GPU 메모리 및 파이프라인 한도(limits)를 상향 조정해나가고 있습니다 [11-14].
+*   **보안 및 타임스탬프 양자화 ([[Timestamp Quantization|Timestamp Quantization]]):** 고정밀 타이머를 악용한 캐시 사이드 채널 공격(예: Spectre 및 Meltdown)을 방지하기 위해, Blink 및 Dawn 구현체는 타임스탬프 쿼리 결과의 해상도를 100 마이크로초(µs)로 양자화(Coarsening)하여 제공합니다 [1, 5, 6]. [[Chrome|Chrome]]은 초기에는 보안을 위해 격리되지 않은 컨텍스트(non-isolated contexts)에서 이를 완전히 비활성화하려 했으나, 최종적으로 웹 표준 상호 운용성을 고려해 격리 여부와 무관하게 100µs 해상도를 제공하는 것으로 합의되었습니다 [5-7]. 단, 로컬 개발 환경에서 정밀한 성능 프로파일링이 필요할 때는 `chrome://flags`에서 "WebGPU Developer Features" 및 "Unsafe WebGPU [[Support|Support]]" 플래그를 켜서 이 양자화를 비활성화할 수 있습니다 [1, 2].
+*   **버전별 주요 진화 과정:** Chrome 113 버전에서 WebGPU가 최초로 기본 활성화된 이후, Chromium 팀은 렌더링 및 머신러닝 기능 확장을 지속해 왔습니다 [8, 9]. 예를 들어, Chrome 120에서는 WGSL 내 16비트 부동소수점(`f16`) 지원을 추가하여 Llama2 모델과 같은 LLM 추론 속도를 비약적으로 향상시켰습니다 [10]. 이후 버전들에서는 서브그룹(Subgroup) 연산 확장, 3D 텍스처 포맷 지원, [[OpenGL ES|OpenGL ES]] 3.1 호환성 모드 등 다양한 GPU 메모리 및 파이프라인 한도(limits)를 상향 조정해나가고 있습니다 [11-14].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], Dawn, [[Timestamp Quantization]], WGSL
-- **Projects/Contexts:** Chromium Project, [[GPU for the Web Comm[[Unity]] Group]]
+- **Related Topics:** [[WebGPU|WebGPU]], Dawn, [[Timestamp Quantization|Timestamp Quantization]], WGSL
+- **Projects/Contexts:** Chromium Project, [[GPU for the Web Community Group|GPU for the Web CommUnity Group]]
 - **Contradictions/Notes:** 타임스탬프 쿼리 기능 노출과 관련하여, 초기 Chromium(Blink) 인텐트는 Cross-Origin 격리되지 않은 컨텍스트에서 타임스탬프 쿼리를 완전히 비활성화할 계획을 세웠으나(보안 우려), 다른 브라우저 벤더 및 W3C 그룹과의 상호 운용성 논의를 거쳐 격리 여부와 무관하게 hr-time과 동일한 100µs 단위로 노출하는 방향으로 스펙 및 구현 방침이 변경되었습니다 [5-7].
 
 ---

10_Wiki/Topics/Graphics & Performance/Computational Geometry.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AI-053
+id: [[P-Reinforce|P-Reinforce]]-AI-053
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.97
 tags: [geometry, computational geometry, 3d, rendering]
@@ -7,7 +7,7 @@ last_reinforced: 2026-06-XX
 github_commit: "[P-Reinforce] Processed Computational Geometry."
 ---
 
-# [[Computational Geometry]] (계산 기하학)
+# [[Computational Geometry|Computational Geometry]] (계산 기하학)
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 수학적 알고리즘을 사용하여 컴퓨터가 점, 곡선, 다각형 같은 기하학적 객체들 사이의 관계와 공간 구조를 효율적으로 분석하고 조작하는 기술 분야이다.
@@ -15,7 +15,7 @@ github_commit: "[P-Reinforce] Processed Computational Geometry."
 ## 📖 구조화된 지식 (Synthesized Content)
 - **정의:** 수학과 컴퓨터 과학이 만나는 영역으로, 현실 세계의 형태(건축물, 인체 모델, 게임 오브젝트 등)를 디지털로 표현하고 이를 바탕으로 물리적/시각적 시뮬레이션을 수행하는 기반 기술이다.
 - **핵심 알고리즘 및 구조:**
-    1. **메쉬 데이터 구조:** 3D 객체를 삼각형(Tri[[ANGLE]])의 집합으로 근사화하여 저장하고 처리한다. (Vertices, Edges, Faces).
+    1. **메쉬 데이터 구조:** 3D 객체를 삼각형(Tri[[ANGLE|ANGLE]])의 집합으로 근사화하여 저장하고 처리한다. (Vertices, Edges, Faces).
     2. **공간 분할 기법:** 대규모 데이터를 효율적으로 검색하기 위해 공간을 나누는 방법들 (예: Octree, BVH - Bounding Volume Hierarchy). 이는 렌더링의 성능(Culling)에 필수적이다.
     3. **좌표 변환 및 근사화:** 카메라 위치나 오브젝트 이동에 따른 좌표계 변환(Transformation Matrix), 그리고 복잡한 곡선을 단순화하는 과정이 포함된다.
 
@@ -24,7 +24,7 @@ github_commit: "[P-Reinforce] Processed Computational Geometry."
 - **정책 변화:** 최신 트렌드는 하드웨어 가속(GPU)과 연동하여 복잡한 기하학적 계산(예: Ray Tracing)을 실시간으로 처리하는 방향으로 진화하고 있다.
 
 ## 🔗 지식 연결 (Graph)
-- Parent: [[Computational Geometry]]
-- Related: Bounding Volume Hierarchy (BVH) , [[Three.js 렌더링 최적화]] , [[Physics]]-Based-Simulation
+- Parent: [[Computational Geometry|Computational Geometry]]
+- Related: Bounding Volume Hierarchy (BVH) , [[Three.js 렌더링 최적화|Three.js 렌더링 최적화]] , [[Physics|Physics]]-Based-Simulation
 
 ---

10_Wiki/Topics/Graphics & Performance/Compute Shader.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-38086E
+id: [[P-Reinforce|P-Reinforce]]-AUTO-38086E
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Compute Shader"
 ---
 
-# [[Compute Shader]]
+# [[Compute Shader|Compute Shader]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴퓨트 셰이더(Compute Shader)는 자바스크립트 메인 스레드나 CPU가 처리하던 무거운 연산 작업을 수천 개의 GPU 코어를 활용해 병렬로 처리할 수 있게 해주는 [[WebGPU]]의 핵심 기능입니다 [1]. 주로 입자(Particle) 시스템, 물리 연산, 실시간 필터링, 그리고 대규모 객체의 가시성 판별(Culling)과 같은 범용 GPU 연산(GPGPU)에 사용되어, 기존 [[WebGL]] 기반 환경의 한계를 뛰어넘는 압도적인 성능 향상을 제공합니다 [1-3].
+> 컴퓨트 셰이더(Compute Shader)는 자바스크립트 메인 스레드나 CPU가 처리하던 무거운 연산 작업을 수천 개의 GPU 코어를 활용해 병렬로 처리할 수 있게 해주는 [[WebGPU|WebGPU]]의 핵심 기능입니다 [1]. 주로 입자(Particle) 시스템, 물리 연산, 실시간 필터링, 그리고 대규모 객체의 가시성 판별(Culling)과 같은 범용 GPU 연산(GPGPU)에 사용되어, 기존 [[WebGL|WebGL]] 기반 환경의 한계를 뛰어넘는 압도적인 성능 향상을 제공합니다 [1-3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **대규모 데이터 연산 및 성능 향상:** CPU 기반의 입자 시스템은 일반적으로 5만 개 정도에서 성능 병목을 겪지만, WebGPU 컴퓨트 셰이더를 도입하면 이를 수백만 개 단위로 확장할 수 있습니다 [2, 4]. 예를 들어, 1만 개의 입자를 CPU에서 업데이트할 때 30ms가 걸리던 작업을 컴퓨트 셰이더를 사용하면 10만 개의 입자를 2ms 이내에 처리하여 150배 이상의 성능 향상을 얻을 수 있습니다 [5]. 
 * **주요 활용 분야:** 컴퓨트 셰이더는 충돌 감지(Collision detection), 실시간 조명 계산, 대규모 데이터 필터링, 구조 시뮬레이션 등에 효과적으로 적용됩니다 [1, 4]. 실시간 편집과 거대한 스케일이 필요한 절차적 지형 생성(Procedural terrain generation)도 가능하게 해줍니다 [6]. 또한, 메쉬의 정점 변환을 컴퓨트 단계에서 미리 처리해 버퍼에 저장해두고 여러 렌더 패스에서 재사용하는 '컴퓨트 스키닝(Compute Skinning)' 기법도 지원합니다 [5].
-* **메모리 활용 및 스토리지 텍스처:** 일반적인 텍스처와 달리 컴퓨트 셰이더 환경에서는 '스토리지 텍스처([[Storage]] textures)'를 통해 셰이더 내에서 읽기와 쓰기 작업을 동시에 수행할 수 있으며, 이는 유체 시뮬레이션이나 이미지 처리 등에 필수적입니다 [7, 8]. 더불어 스레드 간 데이터 공유가 필요한 작업에서는 작업 그룹 변수(Workgroup variables)를 사용한 공유 메모리를 활용할 수 있는데, 이는 반복적인 데이터 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 속도를 제공합니다 [6, 9].
-* **GPU 주도 렌더링([[GPU-driven Rendering]])과 간접 그리기:** 컴퓨트 셰이더는 간접 그리기([[Indirect Draw]])와 결합하여 렌더링 파이프라인의 효율성을 극대화합니다 [9]. CPU가 인스턴스의 위치를 검사하고 그리기 명령을 준비하는 대신, 컴퓨트 셰이더가 직접 시야 포함 여부나 오클루전(가림 현상)을 판별한 뒤 시각적으로 유효한 객체들로만 간접 그리기 버퍼를 채웁니다 [3, 10, 11]. 이 방식을 통해 CPU와 GPU 간의 데이터 전송량을 거의 0으로 수렴하게 만들 수 있습니다 [3].
+* **메모리 활용 및 스토리지 텍스처:** 일반적인 텍스처와 달리 컴퓨트 셰이더 환경에서는 '스토리지 텍스처([[Storage|Storage]] textures)'를 통해 셰이더 내에서 읽기와 쓰기 작업을 동시에 수행할 수 있으며, 이는 유체 시뮬레이션이나 이미지 처리 등에 필수적입니다 [7, 8]. 더불어 스레드 간 데이터 공유가 필요한 작업에서는 작업 그룹 변수(Workgroup variables)를 사용한 공유 메모리를 활용할 수 있는데, 이는 반복적인 데이터 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 속도를 제공합니다 [6, 9].
+* **GPU 주도 렌더링([[GPU-driven Rendering|GPU-driven Rendering]])과 간접 그리기:** 컴퓨트 셰이더는 간접 그리기([[Indirect Draw|Indirect Draw]])와 결합하여 렌더링 파이프라인의 효율성을 극대화합니다 [9]. CPU가 인스턴스의 위치를 검사하고 그리기 명령을 준비하는 대신, 컴퓨트 셰이더가 직접 시야 포함 여부나 오클루전(가림 현상)을 판별한 뒤 시각적으로 유효한 객체들로만 간접 그리기 버퍼를 채웁니다 [3, 10, 11]. 이 방식을 통해 CPU와 GPU 간의 데이터 전송량을 거의 0으로 수렴하게 만들 수 있습니다 [3].
 * **렌더링 동기화:** 컴퓨트 셰이더가 포함된 씬을 렌더링할 때는 GPU 작업의 적절한 동기화가 필요합니다 [12]. 종속적인 렌더 패스가 시작되기 전에 컴퓨트 패스의 작업이 완전히 완료되도록 보장하기 위해 `renderAsync`와 같은 비동기 렌더링 방식의 사용이 권장됩니다 [12].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -24,9 +24,9 @@ github_commit: "[P-Reinforce] Continuous Worker - Compute Shader"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[GPU-driven Rendering]], [[Indirect Draw]], [[Frustum Culling]]
+- **Related Topics:** [[WebGPU|WebGPU]], GPU-driven Rendering, Indirect Draw, [[Frustum Culling|Frustum Culling]]
 - **Projects/Contexts:** 대규모 건설 및 BIM 모델 플랫폼(수백만 개의 컴포넌트 렌더링 최적화) [13, 14], 엑스포 2025 오사카에 전시된 100만 파티클 유체 시뮬레이션 설치물(Hokusai) [15, 16]. 
-- **Contradictions/Notes:** 컴퓨트 셰이더는 최신 그래픽 API인 WebGPU에서 기본 지원되지만, 구형 WebGL이나 [[WebGL2]] 환경에서는 직접적으로 지원되지 않으므로 이를 활용하기 위해서는 반드시 WebGPU 기반의 렌더러 환경을 사용해야 한다는 제약이 있습니다 [3, 17].
+- **Contradictions/Notes:** 컴퓨트 셰이더는 최신 그래픽 API인 WebGPU에서 기본 지원되지만, 구형 WebGL이나 [[WebGL2|WebGL2]] 환경에서는 직접적으로 지원되지 않으므로 이를 활용하기 위해서는 반드시 WebGPU 기반의 렌더러 환경을 사용해야 한다는 제약이 있습니다 [3, 17].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Compute Shaders.md

@@ -1,21 +1,21 @@
 ---
-id: [[P-Reinforce]]-AUTO-B1DBB3
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B1DBB3
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Compute Shader]]s"
+github_commit: "[P-Reinforce] Continuous Worker - [[Compute Shader|Compute Shader]]s"
 ---
 
-# [[Compute Shaders]]
+# [[Compute Shaders|Compute Shaders]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴퓨트 셰이더(Compute Shaders)는 [[WebGPU]] 환경에서 지원되는 기능으로, CPU의 메인 스레드에서 수행되던 무거운 범용 연산 작업을 GPU로 오프로드하는 핵심 기술입니다 [1, 2]. GPU의 수천 개 코어를 활용한 병렬 처리를 통해 물리 시뮬레이션, 충돌 감지, 대규모 파티클 시스템 등의 작업 성능을 비약적으로 향상시킵니다 [2]. 또한 간접 그리기([[Indirect Draw]]ing) 기술과 결합하여 CPU의 개입 없이 가시성을 판별하고 화면을 그리는 완전한 GPU 주도 렌더링([[GPU-driven Rendering]]) 파이프라인을 구축하는 데 사용됩니다 [3, 4].
+> 컴퓨트 셰이더(Compute Shaders)는 [[WebGPU|WebGPU]] 환경에서 지원되는 기능으로, CPU의 메인 스레드에서 수행되던 무거운 범용 연산 작업을 GPU로 오프로드하는 핵심 기술입니다 [1, 2]. GPU의 수천 개 코어를 활용한 병렬 처리를 통해 물리 시뮬레이션, 충돌 감지, 대규모 파티클 시스템 등의 작업 성능을 비약적으로 향상시킵니다 [2]. 또한 간접 그리기(Indirect Drawing) 기술과 결합하여 CPU의 개입 없이 가시성을 판별하고 화면을 그리는 완전한 GPU 주도 렌더링([[GPU-driven Rendering|GPU-driven Rendering]]) 파이프라인을 구축하는 데 사용됩니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **범용 GPU 연산 및 성능 향상:** 컴퓨트 셰이더는 물리 시뮬레이션, 충돌 감지, 유체 시뮬레이션, 이미지 처리, 대규모 데이터 필터링, 절차적 지형 생성 등 복잡한 연산을 CPU 대신 GPU에서 병렬로 처리합니다 [2, 5-8]. 기존 CPU 기반 파티클 업데이트는 약 5만 개 수준에서 병목이 발생하지만, WebGPU 컴퓨트 셰이더를 활용하면 10만 개의 파티클을 2ms 이내에 업데이트하여 최대 150배의 성능 향상을 내며 수백만 개의 유닛을 처리할 수 있습니다 [9-12].
 * **GPU 주도 렌더링 및 컬링 (GPU-driven Rendering & Culling):** 간접 그리기(Indirect Drawing) 명령과 결합하여 극도로 효율적인 렌더링 파이프라인을 구성합니다 [4, 13]. 컴퓨트 셰이더가 모든 인스턴스에 대해 시야 절두체(Frustum) 및 오클루전(Occlusion) 컬링 판별을 수행하고, 화면에 보이는 객체 정보만 원자적 카운터(Atomic Counter)를 통해 간접 그리기 버퍼에 추가합니다 [3, 4, 14]. 이를 통해 CPU와 GPU 간의 데이터 동기화 지연과 명령 발행 오버헤드가 사실상 0에 수렴하게 됩니다 [4, 15].
-* **데이터 공유 및 메모리 최적화:** 읽기와 쓰기가 모두 가능한 스토리지 텍스처([[Storage]] Textures)를 활용해 GPU 기반 렌더링과 효과 처리를 유연하게 수행합니다 [6, 16]. 또한 스레드 간 데이터 공유가 필요한 경우, 반복 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 작업 그룹 공유 메모리(Workgroup Shared [[memory]])를 활용할 수 있습니다 [7, 13].
+* **데이터 공유 및 메모리 최적화:** 읽기와 쓰기가 모두 가능한 스토리지 텍스처([[Storage|Storage]] Textures)를 활용해 GPU 기반 렌더링과 효과 처리를 유연하게 수행합니다 [6, 16]. 또한 스레드 간 데이터 공유가 필요한 경우, 반복 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 작업 그룹 공유 메모리(Workgroup Shared [[memory|memory]])를 활용할 수 있습니다 [7, 13].
 * **고급 연산 기법 지원:** 컴퓨트 단계에서 메쉬 정점 변환을 처리하고 그 결과를 버퍼에 저장해 불필요한 중복 연산을 제거하는 '컴퓨트 스키닝(Compute Skinning)'이 가능해집니다 [12]. 또한 glTF 모델에 흔히 쓰이는 8비트/16비트 정수 데이터를 32비트 포맷으로 압축 해제하는 작업도 렌더링 파이프라인 외곽에서 효율적으로 수행할 수 있습니다 [12].
 * **동기화 및 파이프라인 제어 베스트 프랙티스:** 연산 의존성이 높은 씬을 Three.js에서 렌더링할 때는 `renderAsync`를 사용하여 렌더 패스가 시작되기 전에 컴퓨트 패스가 완전히 끝나도록 동기화해야 합니다 [17]. 성능 처리량을 극대화하기 위해서는 스테이징 버퍼(Staging Buffers)를 활용한 이중 버퍼링(Double-buffering)을 적용하는 것이 좋으며, 디스패치 사이에 `await mapAsync()`를 호출할 경우 GPU 파이프라인을 멈추게 만들 수 있으므로 지양해야 합니다 [18].
 
@@ -24,9 +24,9 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Compute Shader]]s"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[WebGPU]]`, `[[GPU-driven Rendering]]`, `Indirect Drawing`, `Storage Textures`, `[[Frustum Culling]]`
+- **Related Topics:** `[[WebGPU|WebGPU]]`, `GPU-driven Rendering`, `Indirect Drawing`, `Storage Textures`, `[[Frustum Culling|Frustum Culling]]`
 - **Projects/Contexts:** `Three.js`, `Segments.ai`, `BIM Datasets`
-- **Contradictions/Notes:** 컴퓨트 셰이더는 엄청난 성능 향상을 제공하지만 구형 API인 [[WebGL]]이나 WebGL 2에서는 지원되지 않아 WebGPU 환경이 필수적입니다 [1]. 또한 GPU 최적화를 제대로 다루지 못해 동기화 대기(`await mapAsync()`)를 남용할 경우, 오히려 GPU가 최대 60%의 시간 동안 유휴 상태(Idle)에 빠지는 병목 현상을 유발할 수 있습니다 [18].
+- **Contradictions/Notes:** 컴퓨트 셰이더는 엄청난 성능 향상을 제공하지만 구형 API인 [[WebGL|WebGL]]이나 WebGL 2에서는 지원되지 않아 WebGPU 환경이 필수적입니다 [1]. 또한 GPU 최적화를 제대로 다루지 못해 동기화 대기(`await mapAsync()`)를 남용할 경우, 오히려 GPU가 최대 60%의 시간 동안 유휴 상태(Idle)에 빠지는 병목 현상을 유발할 수 있습니다 [18].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Data Array Textures.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-8AF01A
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8AF01A
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,24 +7,24 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Data Array Textures"
 ---
 
-# [[Data Array Textures]]
+# [[Data Array Textures|Data Array Textures]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Data Array Textures(배열 텍스처)는 셰이더에서 인덱스를 통해 접근할 수 있는 여러 2D 텍스처들의 스택 또는 레이어 구조를 의미합니다 [1, 2]. 이는 여러 이미지를 단일 이미지로 패킹하는 전통적인 텍스처 아틀라스([[Texture Atlas]])의 문제점들을 해결하는 현대적인 접근 방식입니다 [2]. 특히 다양한 텍스처를 사용하는 여러 객체를 `BatchedMesh`와 결합하여 최소한의 드로우 콜([[Draw Call]])로 렌더링할 수 있게 해주어 3D 렌더링 성능 최적화에 핵심적인 역할을 합니다 [1, 2].
+> Data Array Textures(배열 텍스처)는 셰이더에서 인덱스를 통해 접근할 수 있는 여러 2D 텍스처들의 스택 또는 레이어 구조를 의미합니다 [1, 2]. 이는 여러 이미지를 단일 이미지로 패킹하는 전통적인 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])의 문제점들을 해결하는 현대적인 접근 방식입니다 [2]. 특히 다양한 텍스처를 사용하는 여러 객체를 `BatchedMesh`와 결합하여 최소한의 드로우 콜([[Draw Call|Draw Call]])로 렌더링할 수 있게 해주어 3D 렌더링 성능 최적화에 핵심적인 역할을 합니다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **주요 장점:** 배열 텍스처는 인접한 텍스처가 섞이는 경계 번짐([[Edge Bleeding]]) 현상을 제거하고, 네이티브 텍스처 래핑(Wrapping) 및 타일링(Tiling)을 지원하며, 교차 오염 없이 각 레이어별로 올바른 밉맵([[Mipmap]])을 생성할 수 있습니다 [2]. 또한 복잡한 UV 오프셋 계산이나 아틀라스 패킹 알고리즘이 필요하지 않아 셰이더 코드가 크게 단순화됩니다 [2].
+- **주요 장점:** 배열 텍스처는 인접한 텍스처가 섞이는 경계 번짐([[Edge Bleeding|Edge Bleeding]]) 현상을 제거하고, 네이티브 텍스처 래핑(Wrapping) 및 타일링(Tiling)을 지원하며, 교차 오염 없이 각 레이어별로 올바른 밉맵([[Mipmap|Mipmap]])을 생성할 수 있습니다 [2]. 또한 복잡한 UV 오프셋 계산이나 아틀라스 패킹 알고리즘이 필요하지 않아 셰이더 코드가 크게 단순화됩니다 [2].
 - **렌더링 성능 및 활용:** `BatchedMesh`와 함께 사용하면 셰이더 분기(Branching) 처리 대신 하드웨어 인덱싱을 직접 사용하여 한 번의 드로우 콜만으로 서로 다른 텍스처를 가진 수많은 객체를 렌더링할 수 있습니다 [2]. 또한 노멀 맵, 러프니스 맵, 메탈니스 맵 등을 TextureArray로 저장하여 객체별로 고유한 질감을 부여하거나 [3], 원거리 객체를 표시하기 위한 빌보드 임포스터(Billboard impostors)의 다각도 뷰를 텍스처 배열로 저장하여 렌더링하는 데에도 활용될 수 있습니다 [4].
 - **구조적 한계 및 단점:** 배열 텍스처 내에 포함되는 모든 텍스처는 반드시 동일한 크기(Dimensions)를 가져야만 합니다 [5]. 다양한 해상도를 섞어 써야 한다면 여러 개의 배열 텍스처를 생성하거나 기존의 텍스처 아틀라스를 사용해야 합니다 [5]. 
-- **메모리 및 호환성:** 텍스처 아틀라스가 메모리를 더 밀도 있게 패킹할 수 있는 반면, 배열 텍스처는 런타임에 모든 레이어의 메모리를 사전에 할당해야 하는 메모리 오버헤드가 있습니다 [5]. 이 기술은 [[WebGL]]2 환경을 요구하지만, 2025년 기준 브라우저 지원이 매우 우수하여 동일한 크기의 텍스처를 다루는 현대 웹 그래픽 프로젝트에서는 전통적 아틀라싱보다 뛰어난 성능을 발휘합니다 [5].
+- **메모리 및 호환성:** 텍스처 아틀라스가 메모리를 더 밀도 있게 패킹할 수 있는 반면, 배열 텍스처는 런타임에 모든 레이어의 메모리를 사전에 할당해야 하는 메모리 오버헤드가 있습니다 [5]. 이 기술은 [[WebGL|WebGL]]2 환경을 요구하지만, 2025년 기준 브라우저 지원이 매우 우수하여 동일한 크기의 텍스처를 다루는 현대 웹 그래픽 프로젝트에서는 전통적 아틀라싱보다 뛰어난 성능을 발휘합니다 [5].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Texture Atlas]], BatchedMesh, Draw Calls, [[WebGL2]]
-- **Projects/Contexts:** Three.js 성능 최적화, [[빌보드 임포스터(Billboard Impostors)]]
+- **Related Topics:** [[Texture Atlas|Texture Atlas]], BatchedMesh, Draw Calls, [[WebGL2|WebGL2]]
+- **Projects/Contexts:** Three.js 성능 최적화, [[빌보드 임포스터(Billboard Impostors)|빌보드 임포스터(Billboard Impostors]]
 - **Contradictions/Notes:** 소스에 따르면 Data Array Textures는 텍스처 아틀라스의 단점들을 완벽히 보완하는 현대적 대안이지만, '모든 텍스처의 크기가 같아야 한다'는 엄격한 제약과 '메모리 선할당'의 부담이 존재하므로, 가변적인 크기의 텍스처를 압축하거나 구형 WebGL1 환경을 지원해야 할 때는 여전히 텍스처 아틀라스(Texture Atlas)가 가치 있는 선택지로 남는다고 지적합니다 [5].
 
 ---

10_Wiki/Topics/Graphics & Performance/Direct3D.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-D41B4F
+id: [[P-Reinforce|P-Reinforce]]-AUTO-D41B4F
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,23 +7,23 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Direct3D"
 ---
 
-# [[Direct3D]]
+# [[Direct3D|Direct3D]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Direct3D(D3D11, D3D12 등 포함)는 주요 네이티브 그래픽스 API로, Windows 환경의 웹 브라우저에서 그래픽 렌더링의 핵심 백엔드 역할을 합니다 [1, 2]. 최신 버전인 Direct3D 12는 [[Vulkan]], [[Metal]]과 함께 차세대 웹 그래픽스 표준인 [[WebGPU]]의 설계와 아키텍처에 직접적인 영감을 준 현대적인 API입니다 [3].
+> Direct3D(D3D11, D3D12 등 포함)는 주요 네이티브 그래픽스 API로, Windows 환경의 웹 브라우저에서 그래픽 렌더링의 핵심 백엔드 역할을 합니다 [1, 2]. 최신 버전인 Direct3D 12는 [[Vulkan|Vulkan]], Metal과 함께 차세대 웹 그래픽스 표준인 [[WebGPU|WebGPU]]의 설계와 아키텍처에 직접적인 영감을 준 현대적인 API입니다 [3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **[[WebGL]] 호출 변환 ([[ANGLE]]의 활용):** Windows 운영 체제에서 [[Chrome]], Firefox, [[Opera]] 등의 웹 브라우저는 ANGLE(Almost Native Graphics Layer Engine)을 사용하여 WebGL([[OpenGL ES]]) 호출을 Direct3D로 변환하여 처리합니다 [1]. (필요에 따라 개발자는 ANGLE을 우회하여 네이티브 OpenGL 구현을 테스트할 수 있습니다 [1]).
+- **[[WebGL|WebGL]] 호출 변환 (ANGLE의 활용):** Windows 운영 체제에서 Chrome, Firefox, [[Opera|Opera]] 등의 웹 브라우저는 ANGLE(Almost Native Graphics Layer Engine)을 사용하여 WebGL([[OpenGL ES|OpenGL ES]]) 호출을 Direct3D로 변환하여 처리합니다 [1]. (필요에 따라 개발자는 ANGLE을 우회하여 네이티브 OpenGL 구현을 테스트할 수 있습니다 [1]).
 - **WebGPU 아키텍처 설계의 기반:** WebGPU는 기존의 노후화된 OpenGL 표준을 기반으로 구축된 WebGL과 달리, 처음부터 최신 GPU 하드웨어를 위해 설계되었습니다 [3]. 이 과정에서 Direct3D 12는 Vulkan, Metal과 같은 여타 최신 API들과 함께 WebGPU가 차용하고 참고한 핵심적인 현대 그래픽스 API로 평가받습니다 [3].
-- **WebGPU 백엔드 어댑터 지원:** WebGPU 환경에서 `requestAdapterInfo()`를 호출하여 확인할 수 있는 백엔드([[Backend]]) 속성 값에는 'D3D11'과 'D3D12'가 포함되어 있습니다 [2]. Chrome 115 릴리스에서는 Direct3D 11에 대한 실험적 지원(Experimental [[Support]])이 추가되기도 하였습니다 [4].
+- **WebGPU 백엔드 어댑터 지원:** WebGPU 환경에서 `requestAdapterInfo()`를 호출하여 확인할 수 있는 백엔드([[Backend|Backend]]) 속성 값에는 'D3D11'과 'D3D12'가 포함되어 있습니다 [2]. Chrome 115 릴리스에서는 Direct3D 11에 대한 실험적 지원(Experimental [[Support|Support]])이 추가되기도 하였습니다 [4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]], [[Vulkan]], [[Metal]]
-- **Projects/Contexts:** 브라우저 그래픽 렌더링 백엔드, [[Chrome WebGPU 구현]]
+- **Related Topics:** [[WebGL|WebGL]], WebGPU, ANGLE, [[Vulkan|Vulkan]], [[Metal|Metal]]
+- **Projects/Contexts:** 브라우저 그래픽 렌더링 백엔드, [[Chrome WebGPU 구현|Chrome WebGPU 구현]]
 - **Contradictions/Notes:** Direct3D 자체의 내부 구조나 깊이 있는 기술적 명세에 대해서는 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Draw Call.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-E9A644
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E9A644
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,31 +7,31 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Draw Call"
 ---
 
-# [[Draw Call]]
+# [[Draw Call|Draw Call]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 드로우 콜(Draw Call)은 CPU가 GPU에게 렌더링할 기하학적 구조, 재질 및 렌더링 상태를 전달하며 객체를 화면에 그리도록 지시하는 명령입니다 [1, 2]. 실제 그래픽을 렌더링하는 연산 자체보다, 렌더링을 준비하고 상태를 변경하는 과정에서 발생하는 CPU 오버헤드가 매우 커서 성능 병목의 주된 원인이 됩니다 [3-5]. 따라서 실시간 3D 그래픽 애플리케이션에서는 높은 프레임 속도 유지를 위해 인스턴싱, 배칭, 지오메트리 병합 등의 최적화 기법을 통해 드로우 콜의 횟수를 최소화해야 합니다 [6-9].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **드로우 콜의 작동 원리**
-    드로우 콜이 발생할 때마다 시스템은 여러 단계를 거칩니다. 첫째, CPU가 변환 행렬, 셰이더 참조, 유니폼(Uniform) 및 정점 버퍼 등을 수집하여 준비합니다 [3]. 둘째, GPU 내에서 셰이더 프로그램 전환, 텍스처 바인딩, 렌더링 상태 구성 등의 렌더링 상태 변경([[State]] Change)이 일어납니다 [3, 5, 10]. 셋째, 시스템 버스를 통해 CPU-GPU 간 통신이 이루어진 후 마지막으로 GPU가 실제 정점을 처리하고 렌더링하게 됩니다 [3]. 
+    드로우 콜이 발생할 때마다 시스템은 여러 단계를 거칩니다. 첫째, CPU가 변환 행렬, 셰이더 참조, 유니폼(Uniform) 및 정점 버퍼 등을 수집하여 준비합니다 [3]. 둘째, GPU 내에서 셰이더 프로그램 전환, 텍스처 바인딩, 렌더링 상태 구성 등의 렌더링 상태 변경([[State|State]] Change)이 일어납니다 [3, 5, 10]. 셋째, 시스템 버스를 통해 CPU-GPU 간 통신이 이루어진 후 마지막으로 GPU가 실제 정점을 처리하고 렌더링하게 됩니다 [3]. 
 
 *   **드로우 콜 오버헤드와 CPU 병목**
     삼각형이 10개이든 10,000개이든 렌더링을 준비하는 1~3단계의 시간은 거의 동일하게 소모됩니다 [3]. 즉, 화면에 그리는 폴리곤의 개수보다 드로우 콜의 횟수가 성능에 훨씬 더 결정적인 영향을 미칩니다 [11]. 만약 수천 개의 객체를 개별적으로 렌더링한다면 CPU가 명령을 발행하는 속도가 GPU의 렌더링 속도를 따라가지 못해 병목 현상이 발생하고 GPU가 굶주리는(Starve) 상태가 됩니다 [6]. 일반적으로 원활한 60fps 성능을 유지하기 위해서는 프레임당 100회 미만의 드로우 콜을 목표로 하는 것이 좋으며 [11, 12], 기기나 브라우저에 따라 1,000~2,000회를 초과하면 CPU 바운드에 의한 심각한 프레임 저하가 발생합니다 [8].
 
 *   **주요 드로우 콜 최적화 기법**
-    *   **인스턴싱([[Instancing]]):** 동일한 기하학적 구조와 재질을 공유하는 여러 객체(예: 풀잎, 나무, 입자 등)의 경우, 변환 행렬만 다르게 적용하여 단 한 번의 드로우 콜로 수백~수천 개의 객체를 렌더링할 수 있습니다 (`[[InstancedMesh]]` 활용) [7, 13, 14].
-    *   **배칭([[Batching]]) 및 병합(Merging):** 구조가 다르더라도 동일한 재질을 공유하는 객체들을 묶어 하나의 드로우 콜로 처리하거나(`BatchedMesh`), 아예 움직이지 않는 정적 객체들의 기하학적 구조를 하나로 병합([[Geometry Merging]])하여 호출 횟수를 획기적으로 줄입니다 [9, 15, 16].
-    *   **상태 변경 최소화:** 여러 개의 텍스처를 텍스처 아틀라스([[Texture Atlas]]es)나 데이터 배열 텍스처([[Data Array Textures]])로 결합하여, 드로우 콜 중간에 텍스처를 전환하며 발생하는 GPU 렌더링 상태 변경 오버헤드를 방지합니다 [17-19].
+    *   **인스턴싱([[Instancing|Instancing]]):** 동일한 기하학적 구조와 재질을 공유하는 여러 객체(예: 풀잎, 나무, 입자 등)의 경우, 변환 행렬만 다르게 적용하여 단 한 번의 드로우 콜로 수백~수천 개의 객체를 렌더링할 수 있습니다 (`[[InstancedMesh|InstancedMesh]]` 활용) [7, 13, 14].
+    *   **배칭([[Batching|Batching]]) 및 병합(Merging):** 구조가 다르더라도 동일한 재질을 공유하는 객체들을 묶어 하나의 드로우 콜로 처리하거나(`BatchedMesh`), 아예 움직이지 않는 정적 객체들의 기하학적 구조를 하나로 병합([[Geometry Merging|Geometry Merging]])하여 호출 횟수를 획기적으로 줄입니다 [9, 15, 16].
+    *   **상태 변경 최소화:** 여러 개의 텍스처를 텍스처 아틀라스([[Texture Atlas|Texture Atlas]]es)나 데이터 배열 텍스처([[Data Array Textures|Data Array Textures]])로 결합하여, 드로우 콜 중간에 텍스처를 전환하며 발생하는 GPU 렌더링 상태 변경 오버헤드를 방지합니다 [17-19].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Render State]], [[CPU Bottleneck]], [[InstancedMesh]], BatchedMesh, [[Geometry Merging]], [[Texture Atlas]]
-- **Projects/Contexts:** Three.js, [[WebGL]], [[WebGPU]], [[Unity]]
-- **Contradictions/Notes:** 소스에 따르면, 드로우 콜을 1회로 줄이는 것(`InstancedMesh` 등의 도입)이 무조건 프레임 속도 상승으로 이어지지는 않습니다. 수만 개의 객체가 하나의 드로우 콜로 묶이게 되면 엔진의 시야 절두체 컬링([[Frustum Culling]]) 정밀도가 떨어지거나 투명 객체의 정렬([[Sorting]]) 부재로 인해 막대한 오버드로우([[Overdraw]])가 발생하여, 결과적으로 CPU 명령은 줄어도 GPU 연산량은 오히려 기하급수적으로 늘어나는 현상이 일어날 수 있습니다 [10, 20-22]. 
+- **Related Topics:** [[Render State|Render State]], CPU Bottleneck, InstancedMesh, BatchedMesh, [[Geometry Merging|Geometry Merging]], [[Texture Atlas|Texture Atlas]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], WebGPU, [[Unity|Unity]]
+- **Contradictions/Notes:** 소스에 따르면, 드로우 콜을 1회로 줄이는 것(`InstancedMesh` 등의 도입)이 무조건 프레임 속도 상승으로 이어지지는 않습니다. 수만 개의 객체가 하나의 드로우 콜로 묶이게 되면 엔진의 시야 절두체 컬링([[Frustum Culling|Frustum Culling]]) 정밀도가 떨어지거나 투명 객체의 정렬(Sorting) 부재로 인해 막대한 오버드로우([[Overdraw|Overdraw]])가 발생하여, 결과적으로 CPU 명령은 줄어도 GPU 연산량은 오히려 기하급수적으로 늘어나는 현상이 일어날 수 있습니다 [10, 20-22]. 
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Fill Rate.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-477640
+id: [[P-Reinforce|P-Reinforce]]-AUTO-477640
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,22 +7,22 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Fill Rate"
 ---
 
-# [[Fill Rate]]
+# [[Fill Rate|Fill Rate]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Fill Rate'는 그래픽 처리 장치(GPU)의 픽셀 처리 속도 및 성능을 나타내는 지표입니다 [1, 2]. 주로 복잡한 프래그먼트 셰이더(Fragment Shader) 연산이나 겹쳐진 투명한 객체들로 인해 발생하는 오버드로우([[Overdraw]])에 의해 직접적인 영향을 받으며, 효과적인 렌더링 최적화를 위해서는 CPU의 드로우 콜 병목과 구분하여 관리되어야 합니다 [1-3].
+> 'Fill Rate'는 그래픽 처리 장치(GPU)의 픽셀 처리 속도 및 성능을 나타내는 지표입니다 [1, 2]. 주로 복잡한 프래그먼트 셰이더(Fragment Shader) 연산이나 겹쳐진 투명한 객체들로 인해 발생하는 오버드로우([[Overdraw|Overdraw]])에 의해 직접적인 영향을 받으며, 효과적인 렌더링 최적화를 위해서는 CPU의 드로우 콜 병목과 구분하여 관리되어야 합니다 [1-3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **셰이더 복잡도에 따른 성능 저하**: 다수의 텍스처 룩업(Texture lookups), 수학적 연산 및 조건부 논리가 포함된 복잡한 프래그먼트 셰이더는 중급 사양의 GPU 환경에서 Fill Rate를 50~70%가량 크게 감소시킬 수 있습니다 [1].
 - **오버드로우(Overdraw)와 Fill Rate의 비례적 감소**: 투명한 기하학적 구조(예: 투명한 머리카락, 옷 레이어, 액세서리 등)가 겹칠 경우 동일한 픽셀이 한 프레임 내에서 5~10회 반복해서 렌더링되며, 이는 유효 Fill Rate를 그에 비례하여 크게 떨어뜨립니다 [3].
-- **성능 프로파일링에서의 역할**: 실시간 렌더링 최적화 전략을 세울 때는 씬의 병목 현상이 CPU의 명령 발행([[Draw Call]])에 있는지, 아니면 GPU의 픽셀 처리(Fill Rate/Overdraw) 한계에 있는지를 명확하게 구분해야 합니다 [2].
+- **성능 프로파일링에서의 역할**: 실시간 렌더링 최적화 전략을 세울 때는 씬의 병목 현상이 CPU의 명령 발행([[Draw Call|Draw Call]])에 있는지, 아니면 GPU의 픽셀 처리(Fill Rate/Overdraw) 한계에 있는지를 명확하게 구분해야 합니다 [2].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], Fragment Shaders, [[GPU]]
+- **Related Topics:** [[Overdraw|Overdraw]], Fragment Shaders, [[GPU|GPU]]
 - **Projects/Contexts:** Image-To-3D Models in Three.js
 - **Contradictions/Notes:** 소스 내에서 Fill Rate와 관련된 상충되는 주장이나 모순은 발견되지 않았습니다.
 

10_Wiki/Topics/Graphics & Performance/Fragment Shading.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-809D81
+id: [[P-Reinforce|P-Reinforce]]-AUTO-809D81
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,24 +7,24 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Fragment Shading"
 ---
 
-# [[Fragment Shading]]
+# [[Fragment Shading|Fragment Shading]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프래그먼트 셰이딩(Fragment Shading)은 렌더링 파이프라인 후반부에서 픽셀 단위의 렌더링 계산(퍼 픽셀 조명 연산 등)을 수행하여 최종 색상 값을 결정하는 프로세스이다 [1, 2]. 다수의 텍스처 룩업이나 복잡한 연산이 포함될 경우 필 레이트([[Fill Rate]])를 크게 저하시킬 수 있으며 [2], 동일 픽셀에 여러 번 렌더링 연산이 중첩되는 오버드로우([[Overdraw]]) 현상이 발생할 경우 GPU 성능 병목의 주요 원인이 되기도 한다 [3].
+> 프래그먼트 셰이딩(Fragment Shading)은 렌더링 파이프라인 후반부에서 픽셀 단위의 렌더링 계산(퍼 픽셀 조명 연산 등)을 수행하여 최종 색상 값을 결정하는 프로세스이다 [1, 2]. 다수의 텍스처 룩업이나 복잡한 연산이 포함될 경우 필 레이트([[Fill Rate|Fill Rate]])를 크게 저하시킬 수 있으며 [2], 동일 픽셀에 여러 번 렌더링 연산이 중첩되는 오버드로우([[Overdraw|Overdraw]]) 현상이 발생할 경우 GPU 성능 병목의 주요 원인이 되기도 한다 [3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **픽셀 단위 연산의 수행:** 프래그먼트 셰이더는 픽셀의 최종 색상 값을 결정하는 픽셀 단위의 계산을 전담한다 [2]. 버텍스 셰이더([[Vertex Shader]])와 프래그먼트 셰이더 사이에서는 varying 변수를 통해 데이터가 전달되며 [4], 구워진 노멀 맵(baked normal maps) 등을 활용해 복잡한 표면 디테일을 픽셀 셰이딩(pixel shading) 방식으로 렌더링한다 [1].
+- **픽셀 단위 연산의 수행:** 프래그먼트 셰이더는 픽셀의 최종 색상 값을 결정하는 픽셀 단위의 계산을 전담한다 [2]. 버텍스 셰이더([[Vertex Shader|Vertex Shader]])와 프래그먼트 셰이더 사이에서는 varying 변수를 통해 데이터가 전달되며 [4], 구워진 노멀 맵(baked normal maps) 등을 활용해 복잡한 표면 디테일을 픽셀 셰이딩(pixel shading) 방식으로 렌더링한다 [1].
 - **셰이더 복잡도와 필 레이트(Fill Rate):** 프래그먼트 셰이더 내에서 여러 텍스처를 조회하거나, 수학적 연산 및 조건 논리가 복잡해질 경우 중간 사양의 GPU에서는 필 레이트가 50-70%가량 감소할 수 있다 [2]. 특히 PBR(물리 기반 렌더링) 환경에서는 각 픽셀마다 다수의 텍스처 샘플링(알베도, 노멀, 메탈릭, 러프니스 등) 및 환경 반사 연산을 처리해야 하므로 프래그먼트 처리 시간이 급증하게 된다 [2].
-- **오버드로우(Overdraw)의 영향:** 프래그먼트 셰이딩 단계에서 나타나는 오버드로우는 투명한 기하학적 구조가 겹치거나 깊이 정렬(Depth [[Sorting]])이 효율적이지 않아 동일한 픽셀 위치에 렌더링 쓰기 작업이 여러 번 중첩되는 현상이다 [3, 5]. 이는 화면에 보이지 않는 픽셀의 연산에까지 GPU 자원을 낭비하게 만든다 [5].
-- **정렬 부재와 프래그먼트 바운드([[Fragment-bound]]) 현상:** 불투명 객체를 렌더링할 때 객체를 '앞에서 뒤로(Front-to-Back)' 정렬하면 가려진 픽셀 연산을 일찍 종료하는 [[Early-Z]] 최적화를 통해 성능을 확보할 수 있다 [3]. 하지만 [[InstancedMesh]]처럼 인스턴스들이 정렬되지 않은 상태로 렌더링되는 경우 이 최적화가 불가능해 막대한 오버드로우 비용을 발생시키며, 결과적으로 전체 씬(Scene)의 렌더링이 프래그먼트 연산의 한계에 부딪히는 프래그먼트 바운드 상태에 빠질 수 있다 [3, 6].
+- **오버드로우(Overdraw)의 영향:** 프래그먼트 셰이딩 단계에서 나타나는 오버드로우는 투명한 기하학적 구조가 겹치거나 깊이 정렬(Depth [[Sorting|Sorting]])이 효율적이지 않아 동일한 픽셀 위치에 렌더링 쓰기 작업이 여러 번 중첩되는 현상이다 [3, 5]. 이는 화면에 보이지 않는 픽셀의 연산에까지 GPU 자원을 낭비하게 만든다 [5].
+- **정렬 부재와 프래그먼트 바운드([[Fragment-bound|Fragment-bound]]) 현상:** 불투명 객체를 렌더링할 때 객체를 '앞에서 뒤로(Front-to-Back)' 정렬하면 가려진 픽셀 연산을 일찍 종료하는 Early-Z 최적화를 통해 성능을 확보할 수 있다 [3]. 하지만 [[InstancedMesh|InstancedMesh]]처럼 인스턴스들이 정렬되지 않은 상태로 렌더링되는 경우 이 최적화가 불가능해 막대한 오버드로우 비용을 발생시키며, 결과적으로 전체 씬(Scene)의 렌더링이 프래그먼트 연산의 한계에 부딪히는 프래그먼트 바운드 상태에 빠질 수 있다 [3, 6].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[Vertex Shader]], [[Fill Rate]], [[PBR]]
-- **Projects/Contexts:** Three.js [[WebGL]] Rendering [[Optimization]], InstancedMesh Performance [[Bottlenecks]]
+- **Related Topics:** [[Overdraw|Overdraw]], Vertex Shader, Fill Rate, [[PBR|PBR]]
+- **Projects/Contexts:** Three.js [[WebGL|WebGL]] Rendering Optimization, InstancedMesh Performance [[Bottlenecks|Bottlenecks]]
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Fragment-bound.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-589695
+id: [[P-Reinforce|P-Reinforce]]-AUTO-589695
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Fragment-bound"
 ---
 
-# [[Fragment-bound]]
+# [[Fragment-bound|Fragment-bound]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Fragment-bound(프래그먼트 바운드)'는 3D 그래픽스 렌더링 파이프라인에서 GPU의 프래그먼트 셰이딩(픽셀 처리) 용량이 한계에 도달하여 전체 시스템의 성능 병목이 되는 상태를 의미합니다 [1, 2]. 이 상태는 주로 객체들이 카메라 기준 깊이(Depth)에 따라 정렬되지 않은 채 렌더링될 때, 동일한 픽셀에 여러 번 그리기 연산이 수행되는 '오버드로우([[Overdraw]])' 현상으로 인해 촉발됩니다 [1, 2]. 특히 연산 비용이 높은 재질을 사용할 때 이 병목 현상은 더욱 극심해집니다 [2, 3].
+> 'Fragment-bound(프래그먼트 바운드)'는 3D 그래픽스 렌더링 파이프라인에서 GPU의 프래그먼트 셰이딩(픽셀 처리) 용량이 한계에 도달하여 전체 시스템의 성능 병목이 되는 상태를 의미합니다 [1, 2]. 이 상태는 주로 객체들이 카메라 기준 깊이(Depth)에 따라 정렬되지 않은 채 렌더링될 때, 동일한 픽셀에 여러 번 그리기 연산이 수행되는 '오버드로우([[Overdraw|Overdraw]])' 현상으로 인해 촉발됩니다 [1, 2]. 특히 연산 비용이 높은 재질을 사용할 때 이 병목 현상은 더욱 극심해집니다 [2, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **오버드로우(Overdraw)에 의한 연산 과부하:** 
   프래그먼트 바운드 상태는 화면의 동일한 픽셀 영역에 대해 셰이더 연산과 쓰기 작업이 여러 번 중첩되어 발생하는 오버드로우에 의해 야기됩니다 [1, 2]. GPU가 최종 화면에 보이지 않고 가려질 픽셀까지 모두 계산하게 되면서 픽셀 처리 성능을 상회하는 부하가 발생합니다 [2].
-- **[[InstancedMesh]]의 정렬 부재와 병목:** 
-  Three.js의 `InstancedMesh`는 단일 드로우 콜로 렌더링을 수행하지만 개별 인스턴스들의 렌더링 순서를 자동으로 정렬([[Sorting]])하지 않습니다 [1, 2]. 만약 카메라와 가장 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려진다면 막대한 오버드로우 비용이 발생하게 되며, 이로 인해 씬(Scene)이 프래그먼트 바운드 상태에 빠지게 됩니다 [2].
+- **[[InstancedMesh|InstancedMesh]]의 정렬 부재와 병목:** 
+  Three.js의 `InstancedMesh`는 단일 드로우 콜로 렌더링을 수행하지만 개별 인스턴스들의 렌더링 순서를 자동으로 정렬([[Sorting|Sorting]])하지 않습니다 [1, 2]. 만약 카메라와 가장 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려진다면 막대한 오버드로우 비용이 발생하게 되며, 이로 인해 씬(Scene)이 프래그먼트 바운드 상태에 빠지게 됩니다 [2].
 - **재질(Material) 복잡도의 영향과 해결책:** 
   복잡한 조명 및 그림자 연산이 포함된 `MeshStandardMaterial`과 같은 셰이더를 사용할 경우 프래그먼트 바운드 현상은 훨씬 더 심화됩니다 [2, 3]. 이 문제를 완화하기 위해서는 오버드로우의 비용 자체를 줄일 수 있는 단순한 `MeshBasicMaterial`을 사용하여 비교하거나 [3], 자동으로 인스턴스 정렬을 지원하는 `BatchedMesh`로 전환하여 렌더링 효율을 높이는 것이 대안으로 제시됩니다 [1].
 
@@ -25,7 +25,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Fragment-bound"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[InstancedMesh]], MeshStandardMaterial, BatchedMesh
+- **Related Topics:** [[Overdraw|Overdraw]], [[InstancedMesh|InstancedMesh]], MeshStandardMaterial, BatchedMesh
 - **Projects/Contexts:** Three.js 렌더링 성능 최적화
 - **Contradictions/Notes:** 드로우 콜을 줄여 성능을 향상시키기 위해 고안된 `InstancedMesh`가, 정렬 기능의 부재로 인해 오히려 심각한 오버드로우와 프래그먼트 바운드를 유발하여 일반 `Mesh`를 여러 번 그릴 때보다 프레임 레이트(FPS)를 더 하락시킬 수 있다는 점이 주의사항으로 보고됩니다 [2, 4].
 

10_Wiki/Topics/Graphics & Performance/Frustum Culling.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-7A315B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-7A315B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,30 +7,30 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Frustum Culling"
 ---
 
-# [[Frustum Culling]]
+# [[Frustum Culling|Frustum Culling]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시야 절두체 컬링(Frustum Culling)은 카메라의 시야(View Frustum) 밖으로 벗어난 객체를 렌더링 연산에서 제외하여 불필요한 GPU 자원 소모를 방지하는 최적화 기법이다 [1]. 하지만 [[InstancedMesh]]를 적용할 경우 엔진 수준에서 전체를 단일 객체로 취급하므로, 모든 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 한 번만 컬링이 수행되는 '전부 아니면 전무(All-or-Nothing)' 방식으로 작동한다 [2]. 이로 인해 화면에 극히 일부의 인스턴스만 노출되더라도 보이지 않는 나머지 모든 인스턴스의 정점 변환 연산을 GPU가 강제로 수행해야 하는 구조적 한계를 야기한다 [2].
+> 시야 절두체 컬링(Frustum Culling)은 카메라의 시야(View Frustum) 밖으로 벗어난 객체를 렌더링 연산에서 제외하여 불필요한 GPU 자원 소모를 방지하는 최적화 기법이다 [1]. 하지만 [[InstancedMesh|InstancedMesh]]를 적용할 경우 엔진 수준에서 전체를 단일 객체로 취급하므로, 모든 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 한 번만 컬링이 수행되는 '전부 아니면 전무(All-or-Nothing)' 방식으로 작동한다 [2]. 이로 인해 화면에 극히 일부의 인스턴스만 노출되더라도 보이지 않는 나머지 모든 인스턴스의 정점 변환 연산을 GPU가 강제로 수행해야 하는 구조적 한계를 야기한다 [2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **InstancedMesh에서의 구조적 비효율성**
-  Three.js는 기본적으로 카메라 시야 밖의 객체를 자동으로 컬링해 드로우 콜 생성을 방지한다 [3]. 그러나 InstancedMesh를 사용하면 개별 인스턴스 단위의 네이티브 시야 절두체 컬링 기능이 상실된다 [4]. 엔진은 전체 인스턴스의 바운딩 볼륨만을 검사하기 때문에, 10,000개의 객체 중 단 1개만 시야에 들어와도 GPU는 9,999개의 보이지 않는 객체에 대한 정점 셰이더([[Vertex Shader]]) 행렬 곱셈 연산을 처리해야 한다 [2]. 이는 특히 저사양 모바일 기기나 통합 GPU 환경에서 치명적인 GPU 점유율 상승 및 프레임 드랍을 유발한다 [2, 5].
+  Three.js는 기본적으로 카메라 시야 밖의 객체를 자동으로 컬링해 드로우 콜 생성을 방지한다 [3]. 그러나 InstancedMesh를 사용하면 개별 인스턴스 단위의 네이티브 시야 절두체 컬링 기능이 상실된다 [4]. 엔진은 전체 인스턴스의 바운딩 볼륨만을 검사하기 때문에, 10,000개의 객체 중 단 1개만 시야에 들어와도 GPU는 9,999개의 보이지 않는 객체에 대한 정점 셰이더([[Vertex Shader|Vertex Shader]]) 행렬 곱셈 연산을 처리해야 한다 [2]. 이는 특히 저사양 모바일 기기나 통합 GPU 환경에서 치명적인 GPU 점유율 상승 및 프레임 드랍을 유발한다 [2, 5].
 
 - **수동 CPU 컬링의 병목 현상**
   GPU 낭비를 막기 위해 자바스크립트(CPU) 수준에서 각 인스턴스의 위치를 카메라 평면과 대조하여 가시성을 판단하고 렌더링할 버퍼를 매 프레임 재구성(Reordering)할 수 있다 [5, 6]. 하지만 단일 스레드 특성을 갖는 자바스크립트에서 대규모 배열을 매번 순회하고 조작하는 것은 치명적인 CPU 메인 스레드 병목과 가비지 컬렉션(GC) 부하를 일으킨다 [5].
 
 - **한계 극복을 위한 대안 전략**
   1. **공간 분할 기반 그룹화 전략**: 수만 개의 인스턴스를 하나의 거대한 InstancedMesh로 묶는 대신, 공간적으로 인접한 객체들을 100~500개 단위의 소규모 InstancedMesh로 분할 관리하는 방법이다. 이 경우 드로우 콜 횟수는 다소 증가하지만 시야 절두체 컬링 정밀도가 크게 향상되어 GPU의 무의미한 정점 연산을 극적으로 줄일 수 있다 [7].
-  2. **GPU 컴퓨트 컬링 및 간접 그리기([[Indirect Draw]])**: [[WebGPU]] 환경의 컴퓨트 셰이더([[Compute Shader]])를 활용해 GPU가 직접 인스턴스의 가시성을 판별하도록 처리하는 방식이다 [8, 9]. 판별 결과는 GPU 내부 버퍼에 저장되어 `drawIndirect` 명령으로 즉각 렌더링되므로, CPU 연산 및 CPU-GPU 간 데이터 전송 병목을 완벽히 회피할 수 있다 [9].
-  3. **확장 라이브러리 도입**: BVH(Bounding Volume Hierarchy)를 이용한 고속 공간 쿼리와 `Instanced[[BufferAttribute]]`를 활용한 간접 참조(Indirection) 방식을 통해 기존 InstancedMesh를 확장하여 효율적인 개별 컬링을 제공하는 `[[InstancedMesh2]]`와 같은 외부 라이브러리 활용이 대안이 될 수 있다 [10-12].
+  2. **GPU 컴퓨트 컬링 및 간접 그리기([[Indirect Draw|Indirect Draw]])**: WebGPU 환경의 컴퓨트 셰이더([[Compute Shader|Compute Shader]])를 활용해 GPU가 직접 인스턴스의 가시성을 판별하도록 처리하는 방식이다 [8, 9]. 판별 결과는 GPU 내부 버퍼에 저장되어 `drawIndirect` 명령으로 즉각 렌더링되므로, CPU 연산 및 CPU-GPU 간 데이터 전송 병목을 완벽히 회피할 수 있다 [9].
+  3. **확장 라이브러리 도입**: BVH(Bounding Volume Hierarchy)를 이용한 고속 공간 쿼리와 `Instanced[[BufferAttribute|BufferAttribute]]`를 활용한 간접 참조(Indirection) 방식을 통해 기존 InstancedMesh를 확장하여 효율적인 개별 컬링을 제공하는 `[[InstancedMesh2|InstancedMesh2]]`와 같은 외부 라이브러리 활용이 대안이 될 수 있다 [10-12].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call]], [[WebGPU]], Bounding Volume Hierarchy (BVH)
-- **Projects/Contexts:** Three.js, [[InstancedMesh2]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], Draw Call, [[WebGPU|WebGPU]], Bounding Volume Hierarchy (BVH)
+- **Projects/Contexts:** Three.js, [[InstancedMesh2|InstancedMesh2]]
 - **Contradictions/Notes:** InstancedMesh 기술은 드로우 콜 감소를 통해 CPU 병목을 획기적으로 해결할 수 있도록 설계되었으나, 동시에 개별 시야 절두체 컬링을 무력화시킴으로써 결과적으로 GPU 측면에 새로운 정점 연산 병목을 유발하는 모순적인 절충(Trade-off)을 요구한다 [5, 13].
 
 ---

10_Wiki/Topics/Graphics & Performance/GPU Resources.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-4AA291
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4AA291
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,24 +7,24 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - GPU Resources"
 ---
 
-# [[GPU Resources]]
+# [[GPU Resources|GPU Resources]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU 리소스는 Three.js 및 [[WebGL]] 환경에서 렌더링을 위해 할당되는 VRAM 자원으로, 기하학적 구조(Geometries), 재질(Materials), 텍스처(Textures), 렌더 타겟(Render targets) 등을 포함합니다 [1-3]. 브라우저 렌더링 엔진은 이러한 리소스들을 자동으로 가비지 컬렉트(Garbage Collect)하지 않기 때문에 사용이 끝나면 개발자가 직접 명시적으로 메모리에서 해제해야 합니다 [1]. 효율적인 GPU 리소스 관리가 이루어지지 않으면 심각한 메모리 누수([[Memory Leaks]])가 발생하며, 궁극적으로 브라우저의 제한된 GPU 메모리를 초과하여 컨텍스트 손실(Context Lost)과 화면 멈춤 현상을 유발합니다 [3, 4].
+> GPU 리소스는 Three.js 및 [[WebGL|WebGL]] 환경에서 렌더링을 위해 할당되는 VRAM 자원으로, 기하학적 구조(Geometries), 재질(Materials), 텍스처(Textures), 렌더 타겟(Render targets) 등을 포함합니다 [1-3]. 브라우저 렌더링 엔진은 이러한 리소스들을 자동으로 가비지 컬렉트(Garbage Collect)하지 않기 때문에 사용이 끝나면 개발자가 직접 명시적으로 메모리에서 해제해야 합니다 [1]. 효율적인 GPU 리소스 관리가 이루어지지 않으면 심각한 메모리 누수([[Memory Leaks|Memory Leaks]])가 발생하며, 궁극적으로 브라우저의 제한된 GPU 메모리를 초과하여 컨텍스트 손실(Context Lost)과 화면 멈춤 현상을 유발합니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **GPU 리소스의 구성 및 메모리 소비량:** 3D 모델을 렌더링할 때 GPU 메모리에는 정점 버퍼(Vertex buffers), 인덱스 버퍼(Index buffers), 텍스처 맵, 그리고 셰이더 프로그램 등이 할당됩니다 [3]. 고해상도 텍스처는 막대한 메모리를 차지하여, 단일 4K(4096x4096) 압축 해제 텍스처의 경우 VRAM의 64MB 이상을 단독으로 소비할 수 있습니다 [1, 5]. 추가적으로 후처리(Post-[[Processing]]) 단계에서 사용되는 개별 렌더 타겟들 또한 프레임 버퍼 메모리를 추가 할당합니다 [2].
+- **GPU 리소스의 구성 및 메모리 소비량:** 3D 모델을 렌더링할 때 GPU 메모리에는 정점 버퍼(Vertex buffers), 인덱스 버퍼(Index buffers), 텍스처 맵, 그리고 셰이더 프로그램 등이 할당됩니다 [3]. 고해상도 텍스처는 막대한 메모리를 차지하여, 단일 4K(4096x4096) 압축 해제 텍스처의 경우 VRAM의 64MB 이상을 단독으로 소비할 수 있습니다 [1, 5]. 추가적으로 후처리(Post-[[Processing|Processing]]) 단계에서 사용되는 개별 렌더 타겟들 또한 프레임 버퍼 메모리를 추가 할당합니다 [2].
 - **명시적인 자원 해제(Disposal) 필수성:** Three.js 프레임워크는 GPU 리소스를 추적하여 자동으로 메모리에서 지워주지 않습니다 [1]. 따라서 메모리 누수를 방지하기 위해서는 에셋이 더 이상 필요하지 않을 때 반드시 `geometry.dispose()`, `material.dispose()`, `texture.dispose()` 함수를 호출해 GPU 자원을 명시적으로 해제해야 합니다 [1, 4, 6]. 
-- **특수 텍스처 및 빈번한 생성 객체 관리:** GLTF 모델 파일에서 `ImageBitmap` 형태로 로드된 텍스처 리소스의 경우, 기본 폐기 메서드 외에도 명시적으로 `texture.source.data.close?()`를 호출해 닫아주어야만 메모리가 새는 것을 막을 수 있습니다 [4, 7]. 또한 게임 내 탄환이나 파티클처럼 자주 생성되고 파괴되는 리소스의 경우 매번 새로 할당하지 않고 오브젝트 풀링(Object [[Pooling]]) 방식을 사용하여 메모리 할당 오버헤드를 막는 것이 좋습니다 [4, 7].
-- **리소스 한계 모니터링:** WebGL 컨텍스트의 가용 메모리 한도는 디바이스 환경에 따라 약 256MB에서 1GB 수준으로 제한적입니다 [3]. 이 용량을 초과해 GPU 리소스가 할당되면 컨텍스트 손실이 발생하여 애플리케이션이 충돌하게 됩니다 [3]. 이를 방지하기 위해서는 런타임 중에 `renderer.info.[[memory]]` 상태를 꾸준히 모니터링하여 텍스처나 지오메트리 수가 지속적으로 증가하는 메모리 누수 현상이 없는지 확인해야 합니다 [1, 4].
+- **특수 텍스처 및 빈번한 생성 객체 관리:** GLTF 모델 파일에서 `ImageBitmap` 형태로 로드된 텍스처 리소스의 경우, 기본 폐기 메서드 외에도 명시적으로 `texture.source.data.close?()`를 호출해 닫아주어야만 메모리가 새는 것을 막을 수 있습니다 [4, 7]. 또한 게임 내 탄환이나 파티클처럼 자주 생성되고 파괴되는 리소스의 경우 매번 새로 할당하지 않고 오브젝트 풀링(Object [[Pooling|Pooling]]) 방식을 사용하여 메모리 할당 오버헤드를 막는 것이 좋습니다 [4, 7].
+- **리소스 한계 모니터링:** WebGL 컨텍스트의 가용 메모리 한도는 디바이스 환경에 따라 약 256MB에서 1GB 수준으로 제한적입니다 [3]. 이 용량을 초과해 GPU 리소스가 할당되면 컨텍스트 손실이 발생하여 애플리케이션이 충돌하게 됩니다 [3]. 이를 방지하기 위해서는 런타임 중에 `renderer.info.[[memory|memory]]` 상태를 꾸준히 모니터링하여 텍스처나 지오메트리 수가 지속적으로 증가하는 메모리 누수 현상이 없는지 확인해야 합니다 [1, 4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Memory Leaks]], Textures, VRAM, [[Garbage Collection]]
-- **Projects/Contexts:** Three.js, [[WebGL]], [[WebGPU]]
+- **Related Topics:** [[Memory Management|Memory Management]], Memory Leaks, Textures, VRAM, [[Garbage Collection|Garbage Collection]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], [[WebGPU|WebGPU]]
 - **Contradictions/Notes:** 소스에 관련 모순이나 충돌 정보는 없습니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/GPU for the Web Community Group.md

@@ -1,23 +1,23 @@
 ---
-id: [[P-Reinforce]]-AUTO-518388
+id: [[P-Reinforce|P-Reinforce]]-AUTO-518388
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity]] Group"
+github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity|Unity]] Group"
 ---
 
-# [[GPU for the Web Community Group]]
+# [[GPU for the Web Community Group|GPU for the Web Community Group]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU for the Web Community Group은 [[Chrome]], Firefox, Safari 등 주요 웹 브라우저의 대표자들로 구성되어 [[WebGPU]]와 같은 웹 그래픽 및 컴퓨팅 API의 표준과 새로운 기능을 논의하고 승인하는 조직입니다. 이들은 웹 플랫폼의 건전성과 상호 운용성을 위해 구현에 따라 달라지는(implementation-defined) 기능을 피하고, 결정론적이며 테스트 가능한 기능을 표준에 포함시키는 것을 원칙으로 합니다. 최근에는 개발자 도구 및 성능 측정을 위한 WebGPU 타임스탬프 쿼리([[Timestamp Queries]]) 기능의 도입과 보안을 위한 양자화([[Quantization]]) 기준을 합의하는 역할을 수행했습니다.
+> GPU for the Web Community Group은 [[Chrome|Chrome]], Firefox, Safari 등 주요 웹 브라우저의 대표자들로 구성되어 WebGPU와 같은 웹 그래픽 및 컴퓨팅 API의 표준과 새로운 기능을 논의하고 승인하는 조직입니다. 이들은 웹 플랫폼의 건전성과 상호 운용성을 위해 구현에 따라 달라지는(implementation-defined) 기능을 피하고, 결정론적이며 테스트 가능한 기능을 표준에 포함시키는 것을 원칙으로 합니다. 최근에는 개발자 도구 및 성능 측정을 위한 WebGPU 타임스탬프 쿼리(Timestamp Queries) 기능의 도입과 보안을 위한 양자화([[Quantization|Quantization]]) 기준을 합의하는 역할을 수행했습니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **구성원 및 주요 역할:** 이 그룹에는 Chrome, Firefox, Safari 등 주요 브라우저 벤더의 대표자들이 참여하고 있으며, WebGPU 명세에 새로운 기능을 도입할 때 상호 운용성([[Inter[[Opera]]bility]])을 확보하기 위한 합의(consensus)를 도출합니다 [1].
+* **구성원 및 주요 역할:** 이 그룹에는 Chrome, Firefox, Safari 등 주요 브라우저 벤더의 대표자들이 참여하고 있으며, WebGPU 명세에 새로운 기능을 도입할 때 상호 운용성([[Interoperability|InterOperability]])을 확보하기 위한 합의(consensus)를 도출합니다 [1].
 * **표준화 원칙:** 그룹(WebGPU standard body)은 기본적으로 구현이 명확하지 않거나 선택적인(optional) 기능을 피하고, 상호 운용이 가능하며 테스트 스위트(test suite)로 뒷받침되는 결정론적인 기능을 갖추는 것을 목표로 합니다 [2-4].
 * **타임스탬프 쿼리(Timestamp Queries) 승인 사례:**
-  * WebGPU 애플리케이션의 GPU 명령 실행 시간을 정밀하게 측정하기 위한 타임스탬프 쿼리 기능이 타이밍 공격([[Timing Attack]])에 악용될 수 있다는 보안 우려가 있었습니다 [5, 6].
-  * 그룹 내 논의를 통해, 사이트 격리(site isolation) 여부와 상관없이 hr-time(High Re[[Solution]] Time)의 비격리 해상도인 100마이크로초(100us) 수준으로 양자화(coarsen)하여 타임스탬프를 허용하는 제안을 수용 및 승인했습니다 [7].
+  * WebGPU 애플리케이션의 GPU 명령 실행 시간을 정밀하게 측정하기 위한 타임스탬프 쿼리 기능이 타이밍 공격([[Timing Attack|Timing Attack]])에 악용될 수 있다는 보안 우려가 있었습니다 [5, 6].
+  * 그룹 내 논의를 통해, 사이트 격리(site isolation) 여부와 상관없이 hr-time(High Re[[Solution|Solution]] Time)의 비격리 해상도인 100마이크로초(100us) 수준으로 양자화(coarsen)하여 타임스탬프를 허용하는 제안을 수용 및 승인했습니다 [7].
   * 이를 통해 브라우저 간의 상호 운용성 문제를 해결하고 플랫폼 표준에 맞춘 성능 측정 기능을 제공할 수 있게 되었습니다 [8, 9].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -25,7 +25,7 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity]]
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timestamp Queries]]
+- **Related Topics:** [[WebGPU|WebGPU]], [[Timestamp Queries|Timestamp Queries]]
 - **Projects/Contexts:** WebGPU API Standardization, Chrome Intent to Ship
 - **Contradictions/Notes:** 그룹은 일반적으로 구현에 따라 달라지거나 결정론적이지 않은 기능을 표준에서 배제하려고 노력하지만, 타임스탬프 쿼리와 같은 기능의 경우 예외적으로 보안(타이밍 공격 방지)과 성능 측정의 필요성 사이에서 양자화라는 타협점을 찾아야만 했습니다 [4].
 

10_Wiki/Topics/Graphics & Performance/GPU-driven Rendering.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-C35A51
+id: [[P-Reinforce|P-Reinforce]]-AUTO-C35A51
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,23 +7,23 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - GPU-driven Rendering"
 ---
 
-# [[GPU-driven Rendering]]
+# [[GPU-driven Rendering|GPU-driven Rendering]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU-driven Rendering(GPU 주도 렌더링)은 CPU가 렌더링할 객체를 판별하고 명령하는 대신, GPU가 무엇을 렌더링할지 스스로 결정하는 현대적인 렌더링 파이프라인 기법입니다 [1, 2]. 주로 컴퓨트 셰이더([[Compute Shader]])를 활용해 객체의 가시성을 GPU 내부에서 직접 평가한 후, 간접 그리기([[Indirect Draw]]) 명령을 통해 화면에 출력합니다 [1, 3]. 이 방식을 사용하면 CPU와 GPU 간의 데이터 전송 및 통신 병목이 제거되어 수백만 개의 인스턴스를 극도로 효율적으로 처리할 수 있습니다 [1, 3].
+> GPU-driven Rendering(GPU 주도 렌더링)은 CPU가 렌더링할 객체를 판별하고 명령하는 대신, GPU가 무엇을 렌더링할지 스스로 결정하는 현대적인 렌더링 파이프라인 기법입니다 [1, 2]. 주로 컴퓨트 셰이더([[Compute Shader|Compute Shader]])를 활용해 객체의 가시성을 GPU 내부에서 직접 평가한 후, 간접 그리기([[Indirect Draw|Indirect Draw]]) 명령을 통해 화면에 출력합니다 [1, 3]. 이 방식을 사용하면 CPU와 GPU 간의 데이터 전송 및 통신 병목이 제거되어 수백만 개의 인스턴스를 극도로 효율적으로 처리할 수 있습니다 [1, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **가시성 판단의 GPU 이관 (Culling in [[Compute Shaders]]):** 기존의 렌더링 파이프라인에서는 CPU가 시야 절두체 컬링([[Frustum Culling]])이나 가림 현상(Occlusion)을 계산하여 병목이 발생했습니다 [2, 3]. GPU-driven Rendering에서는 이 역할을 GPU의 컴퓨트 셰이더로 넘겨, GPU가 직접 모든 객체와 인스턴스의 가시성을 판별하고 화면에 보일 객체의 렌더링 명령만 생성합니다 [2, 3].
+- **가시성 판단의 GPU 이관 (Culling in [[Compute Shaders|Compute Shaders]]):** 기존의 렌더링 파이프라인에서는 CPU가 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])이나 가림 현상(Occlusion)을 계산하여 병목이 발생했습니다 [2, 3]. GPU-driven Rendering에서는 이 역할을 GPU의 컴퓨트 셰이더로 넘겨, GPU가 직접 모든 객체와 인스턴스의 가시성을 판별하고 화면에 보일 객체의 렌더링 명령만 생성합니다 [2, 3].
 - **간접 그리기 (Indirect Draws) 활용:** 컴퓨트 셰이더가 가시성 평가를 마치면, 그 결과와 렌더링 명령을 GPU 내부 버퍼에 직접 기록합니다 [2, 3]. 이후 CPU의 개입 없이 `drawIndirect` 명령을 통해 GPU 내부 버퍼의 내용을 기반으로 렌더링을 수행하므로, CPU와 GPU 사이의 데이터 전송량이 거의 '0'에 수렴하게 됩니다 [1, 3].
-- **대규모 인스턴스 및 복잡한 연산 처리:** 이 기법은 매 프레임마다 GPU 수준의 컬링이 필요한 수백만 개의 인스턴스 렌더링에 필수적인 아키텍처입니다 [1]. 또한 읽기와 쓰기가 모두 허용되는 스토리지 텍스처([[Storage]] Textures) 기술과 결합되어 유체 시뮬레이션, 이미지 처리 등 복잡한 환경에서도 핵심적인 역할을 수행합니다 [4].
+- **대규모 인스턴스 및 복잡한 연산 처리:** 이 기법은 매 프레임마다 GPU 수준의 컬링이 필요한 수백만 개의 인스턴스 렌더링에 필수적인 아키텍처입니다 [1]. 또한 읽기와 쓰기가 모두 허용되는 스토리지 텍스처([[Storage|Storage]] Textures) 기술과 결합되어 유체 시뮬레이션, 이미지 처리 등 복잡한 환경에서도 핵심적인 역할을 수행합니다 [4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Compute Shader]], [[Indirect Draw]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** Three.js, [[InstancedMesh]]
+- **Related Topics:** [[Compute Shader|Compute Shader]], Indirect Draw, Frustum Culling, [[WebGPU|WebGPU]]
+- **Projects/Contexts:** Three.js, [[InstancedMesh|InstancedMesh]]
 - **Contradictions/Notes:** 대규모 객체를 렌더링할 때 'CPU 개별 컬링' 방식은 자바스크립트 연산 및 시스템 버스 전송에 막대한 병목을 유발하지만, 'GPU 주도 렌더링(GPU 컴퓨트 컬링)'은 구현 난이도가 매우 높은 대신 CPU 부하를 극도로 낮추고 전체적인 성능을 극대화한다는 뚜렷한 대비를 보입니다 [3, 5].
 
 ---

10_Wiki/Topics/Graphics & Performance/GPURenderBundles.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-BC7FBB
+id: [[P-Reinforce|P-Reinforce]]-AUTO-BC7FBB
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,14 +7,14 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - GPURenderBundles"
 ---
 
-# [[GPURenderBundles]]
+# [[GPURenderBundles|GPURenderBundles]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> `GPURenderBundles` (렌더 번들)는 Native [[WebGPU]] 환경에서 제공되는 강력한 렌더링 최적화 도구입니다 [1]. 초기화 과정에서 파이프라인, 바인드 그룹(bind groups), 드로우 콜([[Draw Call]]s)과 같은 명령을 미리 기록(pre-record)하고, 이후 렌더 루프에서 단 한 번의 호출로 이를 다시 재생(replay)할 수 있게 해줍니다 [1]. 이 방식을 통해 렌더링 성능에 병목을 일으키는 검증 작업(validation work)을 핵심 렌더링 경로 외부로 분리하여 대규모 객체를 극도로 효율적으로 처리할 수 있습니다 [1, 2].
+> `GPURenderBundles` (렌더 번들)는 Native [[WebGPU|WebGPU]] 환경에서 제공되는 강력한 렌더링 최적화 도구입니다 [1]. 초기화 과정에서 파이프라인, 바인드 그룹(bind groups), 드로우 콜([[Draw Call|Draw Call]]s)과 같은 명령을 미리 기록(pre-record)하고, 이후 렌더 루프에서 단 한 번의 호출로 이를 다시 재생(replay)할 수 있게 해줍니다 [1]. 이 방식을 통해 렌더링 성능에 병목을 일으키는 검증 작업(validation work)을 핵심 렌더링 경로 외부로 분리하여 대규모 객체를 극도로 효율적으로 처리할 수 있습니다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **사전 기록을 통한 성능 극대화:** 렌더 루프 내에서 매 프레임마다 렌더링 명령을 GPU에 지시하는 대신, 초기화 단계에서 모든 명령을 `GPURenderBundles`에 묶어 저장합니다 [1, 2]. 렌더 루프에서는 이 번들을 호출하는 것만으로 복잡한 렌더링 명령을 즉시 실행할 수 있습니다 [1].
-- **드로우 콜 오버헤드 감소:** 이 접근법은 명령 검증(validation) 작업을 렌더 루프에서 제외시켜 CPU에서 GPU로 발생하는 오버헤드를 근본적으로 제거합니다 [2]. 간접 그리기([[Indirect Draw]]ing)와 함께 사용할 경우 매우 높은 드로우 콜 효율성(Draw Call [[Efficiency]])을 달성할 수 있습니다 [3]. 
+- **드로우 콜 오버헤드 감소:** 이 접근법은 명령 검증(validation) 작업을 렌더 루프에서 제외시켜 CPU에서 GPU로 발생하는 오버헤드를 근본적으로 제거합니다 [2]. 간접 그리기([[Indirect Draw|Indirect Draw]]ing)와 함께 사용할 경우 매우 높은 드로우 콜 효율성(Draw Call [[Efficiency|Efficiency]])을 달성할 수 있습니다 [3]. 
 - **초대형 데이터셋 처리:** `GPURenderBundles`를 활용하면 한 번의 호출로 100,000개 이상의 객체를 렌더링할 수 있습니다 [1, 2]. 이는 500MB를 초과하는 병원 캠퍼스나 공항 터미널과 같은 방대하고 복잡한 건설 모델을 실시간으로 렌더링하는 데 가장 이상적인 해결책을 제공합니다 [2].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)

10_Wiki/Topics/Graphics & Performance/GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례.md

@@ -1,36 +1,36 @@
 ---
-id: [[P-Reinforce]]-AUTO-035B08
+id: [[P-Reinforce|P-Reinforce]]-AUTO-035B08
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU_[[WebGL]] 파이프라인의 미세 지연(Micro-latency) 측정 사례"
+github_commit: "[P-Reinforce] Continuous Worker - GPU_[[WebGL|WebGL]] 파이프라인의 미세 지연(Micro-latency) 측정 사례"
 ---
 
-# [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
+# [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례|GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU/WebGL 파이프라인의 미세 지연(Micro-latency)은 CPU, GPU 및 브라우저 추상화 계층 간의 상호작용에서 발생하는 서브 프레임(Sub-frame) 수준의 시간 지연을 의미하며, 사용자 몰입도를 저하시키는 주요 원인입니다 [1]. 이를 정확히 측정하기 위해 WebGL/[[WebGPU]]의 타이머 API, 브라우저 내부의 성능 프로파일링 도구, 그리고 고속 카메라와 오실로스코프를 활용한 하드웨어 기반 측정 등 다양한 접근법이 활용되고 있습니다 [2-6]. 그러나 보안 취약점([[Spectre]], Meltdown 등)으로 인해 정밀한 시간 측정 기능이 브라우저 차원에서 양자화([[Quantization]])되거나 제한되는 등 여러 측정 상의 제약이 따르고 있습니다 [3, 7].
+> GPU/WebGL 파이프라인의 미세 지연(Micro-latency)은 CPU, GPU 및 브라우저 추상화 계층 간의 상호작용에서 발생하는 서브 프레임(Sub-frame) 수준의 시간 지연을 의미하며, 사용자 몰입도를 저하시키는 주요 원인입니다 [1]. 이를 정확히 측정하기 위해 WebGL/[[WebGPU|WebGPU]]의 타이머 API, 브라우저 내부의 성능 프로파일링 도구, 그리고 고속 카메라와 오실로스코프를 활용한 하드웨어 기반 측정 등 다양한 접근법이 활용되고 있습니다 [2-6]. 그러나 보안 취약점(Spectre, Meltdown 등)으로 인해 정밀한 시간 측정 기능이 브라우저 차원에서 양자화([[Quantization|Quantization]])되거나 제한되는 등 여러 측정 상의 제약이 따르고 있습니다 [3, 7].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **API 수준의 그래픽 타이머 측정 (API-Level Timing)**
-    *   **WebGL 타이머 쿼리:** `EXT_disjoint_timer_query` 확장은 렌더링 파이프라인을 중단하지 않고 GPU 명령어 세트의 실행 시간을 측정할 수 있도록 고안되었습니다 [2, 8]. 그러나 이 고정밀 타이머가 Spectre 및 Meltdown과 같은 캐시 부채널 공격([[Side-channel Attack]]s)에 악용될 수 있다는 보안 연구 결과에 따라, 대부분의 브라우저 벤더는 해당 확장을 비활성화하거나 해상도를 엄격하게 양자화(Quantization)하였습니다 [2, 3, 9-11].
+    *   **WebGL 타이머 쿼리:** `EXT_disjoint_timer_query` 확장은 렌더링 파이프라인을 중단하지 않고 GPU 명령어 세트의 실행 시간을 측정할 수 있도록 고안되었습니다 [2, 8]. 그러나 이 고정밀 타이머가 Spectre 및 Meltdown과 같은 캐시 부채널 공격([[Side-channel Attack|Side-channel Attack]]s)에 악용될 수 있다는 보안 연구 결과에 따라, 대부분의 브라우저 벤더는 해당 확장을 비활성화하거나 해상도를 엄격하게 양자화(Quantization)하였습니다 [2, 3, 9-11].
     *   **WebGPU 타임스탬프 쿼리:** WebGPU는 `timestamp-query` 기능을 통해 나노초 단위의 정밀한 측정을 지원하도록 설계되었습니다 [3, 12]. 하지만 역시 타이밍 공격을 방지하기 위해 사이트 격리(Site isolation) 여부에 따라 타임스탬프의 해상도가 100 마이크로초 수준으로 양자화되거나 비격리 컨텍스트에서는 아예 노출되지 않는 보안 조치가 적용됩니다 [3, 7, 13, 14]. 개발자는 로컬 환경에서 브라우저 플래그(`enable-webgpu-developer-features`)를 켜서 이러한 제한을 우회할 수 있습니다 [7, 15].
 
-*   **브라우저 내부 프로파일링 도구 ([[Browser]]-Internal Profiling)**
-    *   **[[Chrome DevTools]] (Performance 패널):** 애플리케이션의 런타임 트레이스를 캡처하여 메인 스레드 차단 및 프레임 드롭을 진단할 수 있습니다 [16]. CPU 스로틀링(Throttling) 기능을 통해 고사양 기기에서 모바일 기기의 성능을 시뮬레이션함으로써, 강력한 하드웨어 성능에 가려져 있던 미세 지연을 드러낼 수 있습니다 [4, 16].
-    *   **[[Chrome]] Tracing (`about:tracing`):** 브라우저의 다중 프로세스 아키텍처를 세밀하게 분석할 수 있습니다. "CrGpuMain"과 "CrRendererMain" 스레드의 활성 상태를 비교하여 시스템이 CPU 바운드인지 GPU 바운드인지 판별하며, 긴 가비지 컬렉션 주기나 네트워크 대기 등으로 인해 발생하는 유휴 시간(Idle-time) 미세 지연을 파악하는 데 필수적입니다 [4, 17-19].
+*   **브라우저 내부 프로파일링 도구 ([[Browser|Browser]]-Internal Profiling)**
+    *   **[[Chrome DevTools|Chrome DevTools]] (Performance 패널):** 애플리케이션의 런타임 트레이스를 캡처하여 메인 스레드 차단 및 프레임 드롭을 진단할 수 있습니다 [16]. CPU 스로틀링(Throttling) 기능을 통해 고사양 기기에서 모바일 기기의 성능을 시뮬레이션함으로써, 강력한 하드웨어 성능에 가려져 있던 미세 지연을 드러낼 수 있습니다 [4, 16].
+    *   **[[Chrome|Chrome]] Tracing (`about:tracing`):** 브라우저의 다중 프로세스 아키텍처를 세밀하게 분석할 수 있습니다. "CrGpuMain"과 "CrRendererMain" 스레드의 활성 상태를 비교하여 시스템이 CPU 바운드인지 GPU 바운드인지 판별하며, 긴 가비지 컬렉션 주기나 네트워크 대기 등으로 인해 발생하는 유휴 시간(Idle-time) 미세 지연을 파악하는 데 필수적입니다 [4, 17-19].
 
-*   **하드웨어 지원 측정 방식 ([[Hardware]]-Assisted Latency Measurement)**
+*   **하드웨어 지원 측정 방식 ([[Hardware|Hardware]]-Assisted Latency Measurement)**
     *   소프트웨어 기반의 측정은 디스플레이 컨트롤러나 물리적 모니터 자체에서 발생하는 지연을 포착할 수 없으므로, 매우 정밀한 연구를 위해서는 하드웨어 보조 기법이 요구됩니다 [5].
     *   **고속 카메라 기법:** 1000Hz(밀리초당 1프레임)로 녹화하는 고속 카메라와 LED 입력 트리거를 사용하여, 버튼 클릭부터 디스플레이에 시각적 변화가 나타나기까지의 전체 "입력 대 디스플레이(Input-to-Display)" 지연을 측정합니다 [5]. 
     *   **오실로스코프와 포토다이오드:** 모니터에 부착한 포토다이오드로 시각적 변화에 따른 빛의 강도 변화를 전압 스파이크로 감지하고, 이를 입력 장치의 전기 신호와 오실로스코프에서 비교하여 밀리초 미만의 정밀도로 종단 간 지연을 측정합니다 [6].
 
 *   **운영 체제 및 드라이버 수준의 미세 지연 오버헤드**
     *   **컨텍스트 생성 지연 (Context Creation Latency):** WebGL/WebGPU 컨텍스트 생성은 브라우저가 OS 그래픽 스택과 직접 소통해야 하는 동기식 작업으로 드라이버에 따라 심각한 지연을 유발합니다. (예: Mesa 50ms, NVIDIA 120ms, FGLRX 200ms) 이는 페이지 로드 시 메인 스레드의 가시적인 프리징을 야기합니다 [20-22].
-    *   **[[ANGLE]] 변환 오버헤드:** Windows 플랫폼에서는 WebGL의 [[OpenGL ES]] 호출을 [[Direct3D]]로 변환하기 위해 ANGLE 계층을 거치며, 드로우 콜([[Draw Call]])마다 몇 마이크로초의 미세 지연이 부가됩니다. 이 지연은 수천 번의 드로우 콜이 발생하는 씬에서 누적되어 GPU가 여유로운 상황에서도 CPU 병목(Bottleneck) 현상을 일으킵니다 [21, 23, 24].
+    *   **[[ANGLE|ANGLE]] 변환 오버헤드:** Windows 플랫폼에서는 WebGL의 OpenGL ES 호출을 Direct3D로 변환하기 위해 ANGLE 계층을 거치며, 드로우 콜([[Draw Call|Draw Call]])마다 몇 마이크로초의 미세 지연이 부가됩니다. 이 지연은 수천 번의 드로우 콜이 발생하는 씬에서 누적되어 GPU가 여유로운 상황에서도 CPU 병목(Bottleneck) 현상을 일으킵니다 [21, 23, 24].
 
-*   **[[JavaScript]] 우회 측정 방법**
+*   **[[JavaScript|JavaScript]] 우회 측정 방법**
     *   일부 브라우저(예: Chrome)에서는 성능 및 구조상의 이유로 `gl.finish()`가 비정상적으로 `gl.flush()`로 작동하기 때문에 렌더링 지연을 직접 측정할 수 없습니다 [11]. 이를 우회하기 위해 `gl.readPixels()`를 사용하여 단일 픽셀을 강제로 읽어 모든 그래픽 프로세스를 지연시키고 동기화한 뒤, 그 오버헤드를 `performance.now()`로 측정 및 차감하여 실제 작업의 렌더링 시간을 추정하는 기법이 활용되기도 합니다 [25, 26].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -38,8 +38,8 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU_[[WebGL]] 파이프라인
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], WebGPU [[Timestamp Queries]], EXT_disjoint_timer_query
-- **Projects/Contexts:** Chrome DevTools [[Performance Panel]], [[ANGLE (Almost Native Graphics Layer Engine)]]
+- **Related Topics:** [[Spectre and Meltdown|Spectre and Meltdown]], WebGPU [[Timestamp Queries|Timestamp Queries]], EXT_disjoint_timer_query
+- **Projects/Contexts:** Chrome DevTools [[Performance Panel|Performance Panel]], [[ANGLE (Almost Native Graphics Layer Engine)|ANGLE (Almost Native Graphics Layer Engine]]
 - **Contradictions/Notes:** 소스에 따르면 WebGL의 `gl.finish()` 함수는 본래 GPU 파이프라인의 실행 완료를 기다리는 기능이나, Chrome에서는 `gl.flush()`로 별칭(alias) 지정되어 있어, 이를 사용해 실제 렌더링 지연 시간을 측정하려는 시도는 작동하지 않습니다 [11, 27]. 또한 `EXT_disjoint_timer_query` 확장이나 `performance.now()` 등의 도구 역시 각각 보안 문제(캐시 기반 정보 유출) 및 제한적인 렌더링 조건 탓에 순수하고 완벽한 미세 지연 측정 도구로 사용하기에는 한계가 존재합니다 [3, 11, 28].
 
 ---

10_Wiki/Topics/Graphics & Performance/Garbage Collection.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-F5453B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-F5453B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,7 +7,7 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection"
 ---
 
-# [[Garbage Collection]]
+# [[Garbage Collection|Garbage Collection]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 가비지 컬렉션(Garbage Collection, GC)은 사용되지 않는 구형 데이터를 메모리에서 해제하는 자바스크립트 엔진의 메모리 관리 프로세스입니다 [1]. 하지만 Three.js와 같은 실시간 3D 렌더링 환경에서는 빈번한 객체 생성이나 메모리 한계 초과로 인해 가비지 컬렉터가 작동할 경우, 프레임이 일시적으로 멈추는(Stuttering) 심각한 성능 저하가 발생할 수 있습니다 [1-3]. 또한, Three.js는 GPU 자원에 대해 자동으로 가비지 컬렉션을 수행하지 않기 때문에 개발자의 명시적인 메모리 관리가 필수적입니다 [4].
@@ -15,16 +15,16 @@ github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection"
 ## 📖 구조화된 지식 (Synthesized Content)
 * **GPU 자원의 명시적 해제 필요성:** Three.js는 지오메트리, 머티리얼, 텍스처 등의 GPU 자원을 자동으로 가비지 컬렉트하지 않습니다 [4]. 따라서 단일 4K 텍스처가 64MB 이상의 VRAM을 차지하는 등 메모리 누수를 방지하려면, 사용이 끝난 자원은 반드시 `.dispose()` 메서드를 호출하여 명시적으로 GPU 메모리에서 해제해야 합니다 [4].
 * **프레임 멈춤(GC Pauses) 현상:** `useFrame`과 같은 렌더링 루프 내부에서 객체를 계속 생성하거나, 모바일 기기의 시스템 메모리 한계를 초과하는 무거운 텍스처를 사용하면 가비지 컬렉션이 강제로 트리거되어 프레임 멈춤 현상과 스터터링이 발생합니다 [2, 3]. 
-* **동적 버퍼 할당과 [[TypedArray]] 부하:** 대규모 인스턴스 렌더링 환경에서 버퍼 용량을 초과해 동적으로 버퍼를 계속 확장할 경우, 수십 메가바이트 단위의 `TypedArray`가 빈번하게 생성되고 파괴됩니다 [1]. 자바스크립트 엔진이 이 구형 배열 데이터를 해제하는 과정에서 가비지 컬렉터가 작동하여 메인 스레드의 점유 시간을 늘리고 프레임 드랍을 유발합니다 [1, 5].
-* **객체 풀링(Object [[Pooling]])을 통한 GC 부하 완화:** 가비지 컬렉션으로 인한 할당 오버헤드와 멈춤 현상을 방지하기 위해서는, 총알이나 파티클처럼 자주 생성되고 파괴되는 엔티티에 대해 새로운 객체를 생성하는 대신 '객체 풀(Pool)'을 미리 구성하여 재사용하는 방식이 강력히 권장됩니다 [6].
+* **동적 버퍼 할당과 [[TypedArray|TypedArray]] 부하:** 대규모 인스턴스 렌더링 환경에서 버퍼 용량을 초과해 동적으로 버퍼를 계속 확장할 경우, 수십 메가바이트 단위의 `TypedArray`가 빈번하게 생성되고 파괴됩니다 [1]. 자바스크립트 엔진이 이 구형 배열 데이터를 해제하는 과정에서 가비지 컬렉터가 작동하여 메인 스레드의 점유 시간을 늘리고 프레임 드랍을 유발합니다 [1, 5].
+* **객체 풀링(Object [[Pooling|Pooling]])을 통한 GC 부하 완화:** 가비지 컬렉션으로 인한 할당 오버헤드와 멈춤 현상을 방지하기 위해서는, 총알이나 파티클처럼 자주 생성되고 파괴되는 엔티티에 대해 새로운 객체를 생성하는 대신 '객체 풀(Pool)'을 미리 구성하여 재사용하는 방식이 강력히 권장됩니다 [6].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Object Pooling]], [[GPU Resources]]
-- **Projects/Contexts:** Three.js, [[WebGL]]
+- **Related Topics:** [[Memory Management|Memory Management]], Object Pooling, [[GPU Resources|GPU Resources]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]]
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Geometry Merging.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-4349BD
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4349BD
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,31 +7,31 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Geometry Merging"
 ---
 
-# [[Geometry Merging]]
+# [[Geometry Merging|Geometry Merging]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Geometry Merging(지오메트리 병합)**은 Three.js 등의 3D 렌더링 환경에서 정적(static)인 여러 개의 기하학적 데이터를 단일 `[[BufferGeometry]]`로 합치는 최적화 기법입니다. 이는 여러 개의 메쉬를 개별적으로 그릴 때 발생하는 **드로우 콜([[Draw Call]])을 단 1회로 줄여주어** CPU 오버헤드를 크게 감소시킵니다. 하지만 개별 객체의 독립적인 이동이나 실시간 상호작용이 제한되며, 객체가 반복될 경우 메모리 사용량이 극심하게 증가한다는 뚜렷한 한계를 가집니다.
+> **Geometry Merging(지오메트리 병합)**은 Three.js 등의 3D 렌더링 환경에서 정적(static)인 여러 개의 기하학적 데이터를 단일 `[[BufferGeometry|BufferGeometry]]`로 합치는 최적화 기법입니다. 이는 여러 개의 메쉬를 개별적으로 그릴 때 발생하는 **드로우 콜([[Draw Call|Draw Call]])을 단 1회로 줄여주어** CPU 오버헤드를 크게 감소시킵니다. 하지만 개별 객체의 독립적인 이동이나 실시간 상호작용이 제한되며, 객체가 반복될 경우 메모리 사용량이 극심하게 증가한다는 뚜렷한 한계를 가집니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **원리 및 렌더링 최적화 효과:** 
     `BufferGeometryUtils.mergeGeometries`와 같은 유틸리티를 사용하여 로드 타임에 여러 메쉬를 하나로 병합하는 방식입니다 [1, 2]. 이 방식은 독립적인 수많은 드로우 콜을 단 하나의 드로우 콜로 결합하므로, **드로우 콜 병목 현상을 완화하는 궁극적인 해결책**을 제공합니다 [3, 4]. 움직임이 필요 없는 정적 씬이나 다수의 부품이 조립된 CAD 렌더링 모델 등에서 높은 프레임 레이트를 유지하는 데 탁월한 효과를 발휘합니다 [4]. 
 
 *   **메모리 소모 및 상호작용의 한계:** 
-    병합된 지오메트리는 병합 전 개별 객체의 기하학적 데이터를 모두 고스란히 복제하여 메모리에 저장합니다. 따라서 수천 개의 동일한 객체(예: 의자)를 렌더링할 때 단일 기하 데이터만 참조하는 인스턴싱([[Instancing]])과 달리, **메모리(RAM 및 VRAM) 소모가 기하급수적으로 증가**하는 치명적인 단점이 있습니다 [3, 5, 6]. 또한 모든 데이터가 하나로 합쳐져 있으므로, **개별 객체의 위치, 회전, 색상을 실시간으로 변경하거나 개별적인 피킹(Picking) 등 상호작용을 구현하기가 매우 까다롭습니다** [6-8].
+    병합된 지오메트리는 병합 전 개별 객체의 기하학적 데이터를 모두 고스란히 복제하여 메모리에 저장합니다. 따라서 수천 개의 동일한 객체(예: 의자)를 렌더링할 때 단일 기하 데이터만 참조하는 인스턴싱([[Instancing|Instancing]])과 달리, **메모리(RAM 및 VRAM) 소모가 기하급수적으로 증가**하는 치명적인 단점이 있습니다 [3, 5, 6]. 또한 모든 데이터가 하나로 합쳐져 있으므로, **개별 객체의 위치, 회전, 색상을 실시간으로 변경하거나 개별적인 피킹(Picking) 등 상호작용을 구현하기가 매우 까다롭습니다** [6-8].
 
-*   **시야 절두체 컬링([[Frustum Culling]]) 비효율성:** 
+*   **시야 절두체 컬링([[Frustum Culling|Frustum Culling]]) 비효율성:** 
     모든 객체가 하나의 거대한 메쉬로 병합되면 전체가 **단일 바운딩 볼륨(Bounding volume)으로 취급**됩니다. 이로 인해 합쳐진 덩어리의 극히 일부만 카메라 시야(Frustum)에 들어오더라도 화면에 보이지 않는 나머지 전체 영역까지 모두 렌더링 연산을 수행하게 되어, 결과적으로 GPU 성능의 비효율을 초래할 수 있습니다 [4].
 
 *   **실무적 대안 및 하이브리드 전략:** 
-    절두체 컬링의 문제를 완화하기 위해 공간적 인접성에 따라 메쉬를 나누어 병합하는 **'타일형 병합(Tiled merging)'** 전략이 권장됩니다 [4]. 또한, 메모리와 유연성 문제를 해결하기 위해 동적인 장면이 아니고 모델 크기가 작을 때(< 1GB)에만 병합을 적용하거나 [9], 정적인 저폴리곤 객체는 병합(Merging)하고 동적이거나 고폴리곤인 객체는 `[[InstancedMesh]]` 혹은 `BatchedMesh`를 사용하는 **하이브리드 시스템**이 대안으로 활용되기도 합니다 [10, 11].
+    절두체 컬링의 문제를 완화하기 위해 공간적 인접성에 따라 메쉬를 나누어 병합하는 **'타일형 병합(Tiled merging)'** 전략이 권장됩니다 [4]. 또한, 메모리와 유연성 문제를 해결하기 위해 동적인 장면이 아니고 모델 크기가 작을 때(< 1GB)에만 병합을 적용하거나 [9], 정적인 저폴리곤 객체는 병합(Merging)하고 동적이거나 고폴리곤인 객체는 `[[InstancedMesh|InstancedMesh]]` 혹은 `BatchedMesh`를 사용하는 **하이브리드 시스템**이 대안으로 활용되기도 합니다 [10, 11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], BatchedMesh, [[Frustum Culling]], [[BufferGeometry]]
-- **Projects/Contexts:** IFC.js Fragment, CAD Rendering [[Optimization]]
+- **Related Topics:** [[Draw Call|Draw Call]], InstancedMesh, BatchedMesh, Frustum Culling, [[BufferGeometry|BufferGeometry]]
+- **Projects/Contexts:** IFC.js Fragment, CAD Rendering [[Optimization|Optimization]]
 - **Contradictions/Notes:** 지오메트리 병합은 드로우 콜을 크게 줄여 렌더링 속도를 높이는 장점이 있지만, 단일 바운딩 박스로 묶이게 되어 시야 절두체 컬링 효율성이 떨어지고 메모리 사용량이 극도로 높아져 하드웨어 자원을 쉽게 고갈시킬 수 있다는 트레이드오프(Trade-off)가 존재합니다 [3, 4].
 
 ---

10_Wiki/Topics/Graphics & Performance/HMD(Head-Mounted Display) 기반 엑서게임 환경.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-E05076
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E05076
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기반 엑서게임 환경"
 ---
 
-# [[HMD(Head-Mounted Display) 기반 엑서게임 환경]]
+# [[HMD(Head-Mounted Display) 기반 엑서게임 환경|HMD(Head-Mounted Display) 기반 엑서게임 환경]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> HMD(Head-Mounted Display) 기반 엑서게임 환경은 가상현실(VR) 기술을 활용하여 사용자의 신체적 운동과 게임 플레이를 결합한 몰입형 시스템입니다. 이 환경은 현실감 넘치는 3D 공간과 전방위적인 시야를 제공함으로써 사용자가 운동의 신체적 피로를 잊게 하고 지속적으로 운동에 참여할 수 있는 강력한 동기를 부여합니다 [1]. 그러나 높은 몰입감을 제공하는 대신, 신체 움직임과 시각적 자극의 불일치로 인해 화면 기반(Screen-based) 환경보다 VR 멀미([[VR Sickness]])나 시각적 피로를 유발할 가능성이 더 크다는 특징을 지닙니다 [2].
+> HMD(Head-Mounted Display) 기반 엑서게임 환경은 가상현실(VR) 기술을 활용하여 사용자의 신체적 운동과 게임 플레이를 결합한 몰입형 시스템입니다. 이 환경은 현실감 넘치는 3D 공간과 전방위적인 시야를 제공함으로써 사용자가 운동의 신체적 피로를 잊게 하고 지속적으로 운동에 참여할 수 있는 강력한 동기를 부여합니다 [1]. 그러나 높은 몰입감을 제공하는 대신, 신체 움직임과 시각적 자극의 불일치로 인해 화면 기반(Screen-based) 환경보다 VR 멀미([[VR Sickness|VR Sickness]])나 시각적 피로를 유발할 가능성이 더 크다는 특징을 지닙니다 [2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **몰입감과 운동 동기 부여:** HMD 기반의 VR 엑서게임은 사용자를 가상 세계의 목표와 서사에 깊이 빠져들게 하여 신체적 노력에서 오는 고통을 효과적으로 분산시킵니다 [1]. 이러한 실재감(Presence)과 몰입은 사용자의 엑서게임 동기와 지속적인 참여를 이끌어내는 가장 핵심적인 요소입니다 [1].
 - **VR 멀미(VR Sickness)의 발생:** HMD를 착용한 채로 활발한 신체 움직임이 요구되는 엑서게임을 플레이할 경우, 일반적인 대형 화면 기반 게임에 비해 메스꺼움, 방향 감각 상실 등 시뮬레이터 멀미 증상이 더 높게 나타날 수 있습니다 [2, 3]. 이러한 VR 멀미는 게임의 실재감을 깨뜨리고 즐거움과 동기를 저하시키며 인지 능력과 작업 수행 능력을 떨어뜨릴 수 있습니다 [3].
-- **시각적 부작용 및 노출 시간의 영향:** HMD 사용 시 발생하는 눈의 폭주(Vergence)와 조절(Accommodation) 간의 불일치는 깊이 지각에 혼란을 주어 두통, 눈의 피로, 시야 겹침 현상 등의 안구 운동 관련 증상을 초래할 수 있습니다 [3, 4]. 인기 VR 엑서게임인 '[[Beat Saber]]'를 활용한 연구에 따르면, 게임 노출 시간이 길어질수록(예: 10분 대비 50분) 즉각적인 멀미 증상과 시각/인지적 영향이 유의미하게 증가하는 것으로 나타났습니다 [5-7].
+- **시각적 부작용 및 노출 시간의 영향:** HMD 사용 시 발생하는 눈의 폭주(Vergence)와 조절(Accommodation) 간의 불일치는 깊이 지각에 혼란을 주어 두통, 눈의 피로, 시야 겹침 현상 등의 안구 운동 관련 증상을 초래할 수 있습니다 [3, 4]. 인기 VR 엑서게임인 '[[Beat Saber|Beat Saber]]'를 활용한 연구에 따르면, 게임 노출 시간이 길어질수록(예: 10분 대비 50분) 즉각적인 멀미 증상과 시각/인지적 영향이 유의미하게 증가하는 것으로 나타났습니다 [5-7].
 - **사후 회복 및 안전 권고:** 대부분의 사용자는 장시간 HMD 엑서게임을 수행한 후 멀미 증상이나 인지 및 시각적 변화를 겪더라도, VR 기기를 벗고 약 40분의 휴식을 취하면 기준선(Baseline) 수준으로 정상 회복됩니다 [6, 7]. 따라서 HMD 엑서게임을 안전하게 활용하기 위해서는 긴 시간 플레이하기 전 짧은 세션을 통해 멀미 발생 여부를 테스트하고, 플레이 종료 후 충분한 대기 및 휴식 시간을 갖는 것이 권장됩니다 [8].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR Sickness)]], [[실재감(Presence)]], [[폭주-조절 불일치(Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[Beat Saber]], [[가상현실(VR) 자전거 시뮬레이터]]
+- **Related Topics:** [[VR 멀미 (VR Sickness)|VR 멀미(VR Sickness]], 실재감(Presence), [[폭주-조절 불일치(Vergence-accommodation conflict)|폭주-조절 불일치(Vergence-Accommodation Conflict]]
+- **Projects/Contexts:** [[Beat Saber|Beat Saber]], [[가상현실(VR) 자전거 시뮬레이터|가상현실(VR) 자전거 시뮬레이터]]
 - **Contradictions/Notes:** HMD 기반 엑서게임은 기존 화면 기반 게임과 비교했을 때 사용자에게 더 높은 몰입감을 제공하여 운동 효과를 극대화할 수 있지만, 반대로 신체 움직임 증가와 시각적 자극으로 인해 VR 멀미의 유발 가능성을 높인다는 양면적인 모순을 가집니다 [2]. 노출 시간에 비례해 멀미 증상이 증가하지만 대부분 40분 이내에 자연 회복되므로 적절한 휴식과 함께 병행해야 합니다 [6, 9].
 
 ---

10_Wiki/Topics/Graphics & Performance/High Resolution Time.md

@@ -1,29 +1,29 @@
 ---
-id: [[P-Reinforce]]-AUTO-05BDE3
+id: [[P-Reinforce|P-Reinforce]]-AUTO-05BDE3
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High Re[[Solution]] Time"
+github_commit: "[P-Reinforce] Continuous Worker - High Re[[Solution|Solution]] Time"
 ---
 
-# [[High Resolution Time]]
+# [[High Resolution Time|High Resolution Time]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> High Resolution Time(HR-time)은 웹 브라우저 환경에서 고정밀로 시간을 측정하기 위해 사용되는 사양(Spec) 및 메커니즘을 의미한다. 그러나 [[Spectre]]나 Meltdown 같은 타이밍 기반의 사이드 채널 공격을 방지하기 위해 이 사양은 `performance.now()`와 같은 측정 도구의 해상도를 의도적으로 제한(Coarsening)하고 있다. 최근 [[WebGPU]]의 타임스탬프 쿼리 기능 역시 이 HR-time 사양의 기준을 참조하여 보안과 성능 측정의 균형을 맞추고 있다.
+> High Resolution Time(HR-time)은 웹 브라우저 환경에서 고정밀로 시간을 측정하기 위해 사용되는 사양(Spec) 및 메커니즘을 의미한다. 그러나 [[Spectre|Spectre]]나 Meltdown 같은 타이밍 기반의 사이드 채널 공격을 방지하기 위해 이 사양은 `performance.now()`와 같은 측정 도구의 해상도를 의도적으로 제한(Coarsening)하고 있다. 최근 [[WebGPU|WebGPU]]의 타임스탬프 쿼리 기능 역시 이 HR-time 사양의 기준을 참조하여 보안과 성능 측정의 균형을 맞추고 있다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **보안 취약점에 따른 정밀도 제한 (Coarsening):** Spectre 및 Meltdown과 같은 캐시 사이드 채널 공격은 서브 마이크로초(sub-microsecond) 수준의 미세한 타이밍 차이를 이용해 메모리 접근 패턴을 파악한다 [1]. 이를 막기 위해 브라우저 엔진들은 `performance.now()`와 같은 타이머의 정밀도를 시스템의 격리 상태(isolation status)에 따라 1ms 또는 100 마이크로초(µs) 단위로 낮추었다 [1].
 - **지터(Jitter)의 도입:** 일부 브라우저 구현에서는 반환되는 시간 값에 작고 무작위적인 변동인 '지터(Jitter)'를 추가하여, 공격자가 통계적 평균을 통해 고정밀 시계를 재구성하는 것을 방지한다 [1].
 - **컨텍스트에 따른 해상도 차이:** High Resolution Time 사양(HR-time spec)은 크로스 오리진 격리(cross-origin isolated) 컨텍스트에서는 5µs로, 격리되지 않은(non-isolated) 컨텍스트에서는 100µs(또는 구현이 선호하는 더 거친 수준)로 해상도를 제한하도록 권장한다 [2].
-- **WebGPU 타임스탬프 쿼리([[Timestamp Queries]]) 연동:** WebGPU 환경에서 GPU 연산 소요 시간을 측정하는 타임스탬프 쿼리 기능도 타이밍 공격의 위험이 있어 정밀도 조정이 필요했다 [3-5]. 이에 따라 GPU for the Web 커뮤니티 그룹은 타임스탬프 값을 HR-time 사양을 참조하여 격리 여부와 무관하게 비격리 해상도 기준인 100µs로 제한([[Quantization]])하기로 합의하여 일관성 있는 보안 조치를 적용하였다 [6-8].
+- **WebGPU 타임스탬프 쿼리([[Timestamp Queries|Timestamp Queries]]) 연동:** WebGPU 환경에서 GPU 연산 소요 시간을 측정하는 타임스탬프 쿼리 기능도 타이밍 공격의 위험이 있어 정밀도 조정이 필요했다 [3-5]. 이에 따라 GPU for the Web 커뮤니티 그룹은 타임스탬프 값을 HR-time 사양을 참조하여 격리 여부와 무관하게 비격리 해상도 기준인 100µs로 제한([[Quantization|Quantization]])하기로 합의하여 일관성 있는 보안 조치를 적용하였다 [6-8].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], WebGPU Timestamp Queries, performance.now()
+- **Related Topics:** [[Spectre and Meltdown|Spectre and Meltdown]], WebGPU Timestamp Queries, performance.now()
 - **Projects/Contexts:** High Resolution Time spec (
 - **Contradictions/Notes:** 소스 내에 특별한 모순은 없으나, High Resolution Time의 정밀도는 적용되는 보안 격리 환경(Isolated vs Non-isolated) 및 브라우저 엔진의 방어 메커니즘에 따라 5µs, 100µs, 1ms 등 상이하게 적용된다는 점을 유의해야 한다 [1, 2].
 

10_Wiki/Topics/Graphics & Performance/IFCjs (Fragment).md

@@ -1,25 +1,25 @@
 ---
-id: [[P-Reinforce]]-AUTO-8A58BF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8A58BF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs]] (Fragment)"
+github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs|IFCjs]] (Fragment)"
 ---
 
-# [[IFCjs (Fragment)]]
+# [[IFCjs (Fragment)|IFCjs (Fragment]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Fragment는 대규모 3D 기하학적 환경을 효율적으로 렌더링하기 위해 IFC.js 개발자들이 고안한 하이브리드 최적화 시스템이다 [1, 2]. 이 시스템은 단일 인터페이스 내에서 로우 폴리(low-poly) 고유 객체를 위한 지오메트리 병합과 하이 폴리(high-poly) 반복 객체를 위한 인스턴싱의 장점을 결합한다 [2]. 이를 통해 메모리 소비와 드로우 콜([[Draw Call]]) 횟수 간의 최적의 균형을 달성하면서 개별 객체의 빠른 검색 및 조작 기능을 제공하는 것을 목표로 한다 [1, 3].
+> Fragment는 대규모 3D 기하학적 환경을 효율적으로 렌더링하기 위해 IFC.js 개발자들이 고안한 하이브리드 최적화 시스템이다 [1, 2]. 이 시스템은 단일 인터페이스 내에서 로우 폴리(low-poly) 고유 객체를 위한 지오메트리 병합과 하이 폴리(high-poly) 반복 객체를 위한 인스턴싱의 장점을 결합한다 [2]. 이를 통해 메모리 소비와 드로우 콜([[Draw Call|Draw Call]]) 횟수 간의 최적의 균형을 달성하면서 개별 객체의 빠른 검색 및 조작 기능을 제공하는 것을 목표로 한다 [1, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **개발 목적 및 배경:** 
-  건물 모델과 같이 수천 개에서 수백만 개의 객체로 구성된 거대한 씬(scene)을 렌더링할 때, 기존의 모든 객체를 `[[BufferGeometry]]`로 병합하는 방식은 램(RAM) 메모리를 지나치게 많이 소비하는 한계가 있었고, `[[InstancedMesh]]`를 사용하는 방식은 재질(Material) 수만큼 드로우 콜이 늘어나는 단점이 있었다 [4, 5]. Fragment는 이러한 문제를 해결하여 메모리와 FPS 측면 모두에서 효율성을 달성하고, 개별 객체를 빠르게 검색하고 하이라이트할 수 있도록 설계되었다 [1, 6].
+  건물 모델과 같이 수천 개에서 수백만 개의 객체로 구성된 거대한 씬(scene)을 렌더링할 때, 기존의 모든 객체를 `[[BufferGeometry|BufferGeometry]]`로 병합하는 방식은 램(RAM) 메모리를 지나치게 많이 소비하는 한계가 있었고, `[[InstancedMesh|InstancedMesh]]`를 사용하는 방식은 재질(Material) 수만큼 드로우 콜이 늘어나는 단점이 있었다 [4, 5]. Fragment는 이러한 문제를 해결하여 메모리와 FPS 측면 모두에서 효율성을 달성하고, 개별 객체를 빠르게 검색하고 하이라이트할 수 있도록 설계되었다 [1, 6].
 
 * **하이브리드 아키텍처:** 
   Fragment는 다음과 같이 객체의 특성에 따라 두 가지 최적화 방식을 혼합하여 사용한다.
   * **병합 (Merging):** 벽이나 바닥처럼 고유하면서 폴리곤 수가 적은(low-poly) 객체들은 하나 또는 여러 개의 `BufferGeometry`로 병합하여 드로우 콜을 최소화한다 [2, 7].
-  * **인스턴싱 ([[Instancing]]):** 문, 가구, 창문과 같이 동일한 형태가 반복되면서 폴리곤 수가 많은(high-poly) 객체들은 각각 `InstancedMesh`로 구성하여 메모리 소비를 대폭 줄인다 [2, 7].
+  * **인스턴싱 ([[Instancing|Instancing]]):** 문, 가구, 창문과 같이 동일한 형태가 반복되면서 폴리곤 수가 많은(high-poly) 객체들은 각각 `InstancedMesh`로 구성하여 메모리 소비를 대폭 줄인다 [2, 7].
 
 * **구조적 특징 및 저장 방식:** 
   공통된 Fragment 인터페이스를 통해 1,000개의 동일한 의자가 하나의 인스턴스화된 Fragment가 될 수도 있고, 프로젝트의 모든 벽면이 병합된 단일 Fragment가 될 수도 있다 [6, 7]. 영속성(persistence) 수준에서는 각 Fragment당 하나의 GLB 파일을 저장하는 방식을 고려하여 설계되었다 [7]. 모든 Fragment가 비슷한 수의 정점(vertices)과 드로우 콜을 가지도록 하여 시스템 부하의 균형을 맞춘다 [3].
@@ -32,7 +32,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[IFCjs]] (Fragment)"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BufferGeometry]], [[InstancedMesh]], [[Draw Call]]
+- **Related Topics:** [[BufferGeometry|BufferGeometry]], InstancedMesh, [[Draw Call|Draw Call]]
 - **Projects/Contexts:** IFC.js, Three.js
 - **Contradictions/Notes:** 소스에 따르면, Fragment와 같은 자체적인 최적화 시스템 구축 외에도 대규모 환경 최적화를 위해 다중 그리기(Multidrawing), LOD(Level of Detail), 오클루전 컬링(Occlusion Culling) 등의 추가적인 방법론도 함께 검토되었다 [2].
 

10_Wiki/Topics/Graphics & Performance/Index.md

@@ -1,137 +1,137 @@
 # Index: Topics > Graphics & Performance
 
 ## 📝 Documents
-- [[ANGLE (Almost Native Graphics Layer Engine)]]
-- [[ANGLE]]
-- [[Alpha Blending]]
-- [[BIM 모델 렌더링]]
-- [[BIM 모델 시뮬레이션]]
-- [[BVH]]
-- [[Babylonjs]]
-- [[BatchedMesh 및 InstancedMesh 성능 벤치마크]]
-- [[Batching]]
-- [[Buffer Allocation]]
-- [[BufferAttribute]]
-- [[BufferGeometry]]
-- [[CPU Bottleneck]]
-- [[CPU Overhead]]
-- [[Cesium]]
-- [[Chrome (Blink_Dawn)]]
-- [[Chrome WebGPU 구현]]
-- [[Chrome _ Blink WebGPU Implementation]]
-- [[Chrome]]
-- [[Chromium WebGPU Implementation]]
-- [[Computational Geometry]]
-- [[Compute Shader]]
-- [[Compute Shaders]]
-- [[Data Array Textures]]
-- [[Direct3D]]
-- [[Draw Call]]
-- [[Fill Rate]]
-- [[Fragment Shading]]
-- [[Fragment-bound]]
-- [[Frustum Culling]]
-- [[GPU Resources]]
-- [[GPU for the Web Community Group]]
-- [[GPU-driven Rendering]]
-- [[GPURenderBundles]]
-- [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
-- [[Garbage Collection]]
-- [[Geometry Merging]]
-- [[HMD(Head-Mounted Display) 기반 엑서게임 환경]]
-- [[High Resolution Time]]
-- [[IFCjs (Fragment)]]
-- [[Indirect Draw]]
-- [[InstancedMesh (드로우 콜 최적화)]]
-- [[InstancedMesh2]]
-- [[Instancing]]
-- [[JavaScript]]
-- [[Memory Leak Prevention 메모리 누수 방지]]
-- [[Memory Leaks]]
-- [[Memory Management]]
-- [[MeshStandardMaterial 조명 연산]]
-- [[Metal]]
-- [[Multi-threaded Architecture]]
-- [[Needle Engine]]
-- [[Object Pooling]]
-- [[OffscreenCanvas Safari 제약 사항]]
-- [[OffscreenCanvas]]
-- [[OpenGL ES 20]]
-- [[OpenGL ES]]
-- [[Opera]]
-- [[PBR]]
-- [[Radix Sort]]
-- [[Raycaster]]
-- [[Raycasting]]
-- [[React 19 Compiler의 Threejs 런타임 성능 개선 원리]]
-- [[React Three Fiber (R3F)]]
-- [[React Three Fiber 자산 최적화 (Asset Optimization)]]
-- [[React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
-- [[Revit glTF Export]]
-- [[Revit 모델 렌더링]]
-- [[Rowhammer attack]]
-- [[Rowhammer]]
-- [[SkinnedMesh]]
-- [[Sorting]]
-- [[Spatial Partitioning]]
-- [[Spectre and Meltdown]]
-- [[Spring Framework]]
-- [[TLB design]]
-- [[TSL (Three Shader Language)]]
-- [[Texture Compression]]
-- [[Three Shader Language (TSL)]]
-- [[Three.js 렌더링 최적화]]
-- [[Threejs WebGL Rendering Optimization]]
-- [[Threejs WebGPU 파티클 예제]]
-- [[Threejs 대규모 렌더링 최적화 파이프라인]]
-- [[Threejs 렌더링 성능 최적화]]
-- [[Threejs 렌더링 최적화]]
-- [[Threejs 모바일 렌더링 최적화]]
-- [[Threejs]]
-- [[Timestamp Quantization]]
-- [[Timestamp Queries Quantization]]
-- [[Timestamp Queries]]
-- [[TypedArray]]
-- [[UV Offset]]
-- [[Unity]]
-- [[Utsubo]]
-- [[VR 엑서게임 (VR Exergaming)]]
-- [[Varying Variables]]
-- [[Vertex Shader]]
-- [[Vulkan]]
-- [[WEBGL_multi_draw]]
-- [[WebAssembly]]
-- [[WebGL 20]]
-- [[WebGL API]]
-- [[WebGL Optimization]]
-- [[WebGL 모바일 GPU 성능 관리]]
-- [[WebGL]]
-- [[WebGL2]]
-- [[WebGLRenderingContext]]
-- [[WebGPU Compute Shader]]
-- [[WebGPU Compute Shaders]]
-- [[WebGPU Performance Profiling]]
-- [[WebGPU _ WebGL Timing API Security]]
-- [[WebGPU 대규모 건설 뷰어]]
-- [[WebGPU]]
-- [[Wonderland Engine]]
-- [[instancedArray]]
-- [[three-mesh-bvh]]
-- [[가상현실(VR)]]
-- [[고성능 멀티스레드 React 앱 아키텍처]]
-- [[대규모 3D 건축 모델(BIM) 시각화]]
-- [[대규모 건설 뷰어(Construction Viewers)]]
-- [[대규모 건축물 및 지형 뷰어(BIM)]]
-- [[대규모 파티클 시스템 최적화]]
-- [[마이크로 프론트엔드]]
-- [[모바일 기반 WebGL 애플리케이션 개발]]
-- [[셰이더 정밀도 (Mediump_Highp)]]
-- [[스토리지 텍스처(Storage Textures)]]
-- [[실시간 물리 및 유체 시뮬레이션]]
-- [[웹 브라우저 그래픽 API 호환성]]
-- [[입자 시스템(Particle Systems)]]
-- [[컴퓨트 셰이더(Compute Shaders)]]
-- [[프래그먼트 바운드(Fragment-bound)]]
-- [[프래그먼트 셰이딩(Fragment Shading)]]
-- [[헤드 마운트 디스플레이(HMD)]]
-- [[헤드마운트 디스플레이 (HMD)]]
+- [[ANGLE (Almost Native Graphics Layer Engine)|ANGLE (Almost Native Graphics Layer Engine]]
+- [[ANGLE|ANGLE]]
+- [[Alpha Blending|Alpha Blending]]
+- [[BIM 모델 렌더링|BIM 모델 렌더링]]
+- [[BIM 모델 시뮬레이션|BIM 모델 시뮬레이션]]
+- [[BVH|BVH]]
+- [[Babylonjs|Babylonjs]]
+- [[BatchedMesh 및 InstancedMesh 성능 벤치마크|BatchedMesh 및 InstancedMesh 성능 벤치마크]]
+- [[Batching|Batching]]
+- [[Buffer Allocation|Buffer Allocation]]
+- [[BufferAttribute|BufferAttribute]]
+- [[BufferGeometry|BufferGeometry]]
+- [[CPU Bottleneck|CPU Bottleneck]]
+- [[CPU Overhead|CPU Overhead]]
+- [[Cesium|Cesium]]
+- [[Chrome (Blink_Dawn)|Chrome (Blink_Dawn]]
+- [[Chrome WebGPU 구현|Chrome WebGPU 구현]]
+- [[Chrome _ Blink WebGPU Implementation|Chrome _ Blink WebGPU Implementation]]
+- [[Chrome|Chrome]]
+- [[Chromium WebGPU Implementation|Chromium WebGPU Implementation]]
+- [[Computational Geometry|Computational Geometry]]
+- [[Compute Shader|Compute Shader]]
+- [[Compute Shaders|Compute Shaders]]
+- [[Data Array Textures|Data Array Textures]]
+- [[Direct3D|Direct3D]]
+- [[Draw Call|Draw Call]]
+- [[Fill Rate|Fill Rate]]
+- [[Fragment Shading|Fragment Shading]]
+- [[Fragment-bound|Fragment-bound]]
+- [[Frustum Culling|Frustum Culling]]
+- [[GPU Resources|GPU Resources]]
+- [[GPU for the Web Community Group|GPU for the Web Community Group]]
+- [[GPU-driven Rendering|GPU-driven Rendering]]
+- [[GPURenderBundles|GPURenderBundles]]
+- [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례|GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
+- [[Garbage Collection|Garbage Collection]]
+- [[Geometry Merging|Geometry Merging]]
+- [[HMD(Head-Mounted Display) 기반 엑서게임 환경|HMD(Head-Mounted Display) 기반 엑서게임 환경]]
+- [[High Resolution Time|High Resolution Time]]
+- [[IFCjs (Fragment)|IFCjs (Fragment]]
+- [[Indirect Draw|Indirect Draw]]
+- [[InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화]]
+- [[InstancedMesh2|InstancedMesh2]]
+- [[Instancing|Instancing]]
+- [[JavaScript|JavaScript]]
+- [[Memory Leak Prevention 메모리 누수 방지|Memory Leak Prevention 메모리 누수 방지]]
+- [[Memory Leaks|Memory Leaks]]
+- [[Memory Management|Memory Management]]
+- [[MeshStandardMaterial 조명 연산|MeshStandardMaterial 조명 연산]]
+- [[Metal|Metal]]
+- [[Multi-threaded Architecture|Multi-threaded Architecture]]
+- [[Needle Engine|Needle Engine]]
+- [[Object Pooling|Object Pooling]]
+- [[OffscreenCanvas Safari 제약 사항|OffscreenCanvas Safari 제약 사항]]
+- [[OffscreenCanvas|OffscreenCanvas]]
+- [[OpenGL ES 20|OpenGL ES 20]]
+- [[OpenGL ES|OpenGL ES]]
+- [[Opera|Opera]]
+- [[PBR|PBR]]
+- [[Radix Sort|Radix Sort]]
+- [[Raycaster|Raycaster]]
+- [[Raycasting|Raycasting]]
+- [[React 19 Compiler의 Threejs 런타임 성능 개선 원리|React 19 Compiler의 Threejs 런타임 성능 개선 원리]]
+- [[React Three Fiber (R3F)|React Three Fiber (R3F]]
+- [[React Three Fiber 자산 최적화 (Asset Optimization)|React Three Fiber 자산 최적화 (Asset Optimization]]
+- [[React Three Fiber에서 Rapier 물리 엔진 최적화하기|React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
+- [[Revit glTF Export|Revit glTF Export]]
+- [[Revit 모델 렌더링|Revit 모델 렌더링]]
+- [[Rowhammer attack|Rowhammer attack]]
+- [[Rowhammer|Rowhammer]]
+- [[SkinnedMesh|SkinnedMesh]]
+- [[Sorting|Sorting]]
+- [[Spatial Partitioning|Spatial Partitioning]]
+- [[Spectre and Meltdown|Spectre and Meltdown]]
+- [[Spring Framework|Spring Framework]]
+- [[TLB design|TLB design]]
+- [[TSL (Three Shader Language)|TSL (Three Shader Language]]
+- [[Texture Compression|Texture Compression]]
+- [[Three Shader Language (TSL)|Three Shader Language (TSL]]
+- [[Three.js 렌더링 최적화|Three.js 렌더링 최적화]]
+- [[Threejs WebGL Rendering Optimization|Threejs WebGL Rendering Optimization]]
+- [[Threejs WebGPU 파티클 예제|Threejs WebGPU 파티클 예제]]
+- [[Threejs 대규모 렌더링 최적화 파이프라인|Threejs 대규모 렌더링 최적화 파이프라인]]
+- [[Threejs 렌더링 성능 최적화|Threejs 렌더링 성능 최적화]]
+- [[Threejs 렌더링 최적화|Threejs 렌더링 최적화]]
+- [[Threejs 모바일 렌더링 최적화|Threejs 모바일 렌더링 최적화]]
+- [[Threejs|Threejs]]
+- [[Timestamp Quantization|Timestamp Quantization]]
+- [[Timestamp Queries Quantization|Timestamp Queries Quantization]]
+- [[Timestamp Queries|Timestamp Queries]]
+- [[TypedArray|TypedArray]]
+- [[UV Offset|UV Offset]]
+- [[Unity|Unity]]
+- [[Utsubo|Utsubo]]
+- [[VR 엑서게임 (VR Exergaming)|VR 엑서게임 (VR Exergaming]]
+- [[Varying Variables|Varying Variables]]
+- [[Vertex Shader|Vertex Shader]]
+- [[Vulkan|Vulkan]]
+- [[WEBGL_multi_draw|WEBGL_multi_draw]]
+- [[WebAssembly|WebAssembly]]
+- [[WebGL 20|WebGL 20]]
+- [[WebGL API|WebGL API]]
+- [[WebGL Optimization|WebGL Optimization]]
+- [[WebGL 모바일 GPU 성능 관리|WebGL 모바일 GPU 성능 관리]]
+- [[WebGL|WebGL]]
+- [[WebGL2|WebGL2]]
+- [[WebGLRenderingContext|WebGLRenderingContext]]
+- [[WebGPU Compute Shader|WebGPU Compute Shader]]
+- [[WebGPU Compute Shaders|WebGPU Compute Shaders]]
+- [[WebGPU Performance Profiling|WebGPU Performance Profiling]]
+- [[WebGPU _ WebGL Timing API Security|WebGPU _ WebGL Timing API Security]]
+- [[WebGPU 대규모 건설 뷰어|WebGPU 대규모 건설 뷰어]]
+- [[WebGPU|WebGPU]]
+- [[Wonderland Engine|Wonderland Engine]]
+- [[instancedArray|instancedArray]]
+- [[three-mesh-bvh|three-mesh-bvh]]
+- [[가상현실(VR)|가상현실(VR]]
+- [[고성능 멀티스레드 React 앱 아키텍처|고성능 멀티스레드 React 앱 아키텍처]]
+- [[대규모 3D 건축 모델(BIM) 시각화|대규모 3D 건축 모델(BIM) 시각화]]
+- [[대규모 건설 뷰어(Construction Viewers)|대규모 건설 뷰어(Construction Viewers]]
+- [[대규모 건축물 및 지형 뷰어(BIM)|대규모 건축물 및 지형 뷰어(BIM]]
+- [[대규모 파티클 시스템 최적화|대규모 파티클 시스템 최적화]]
+- [[마이크로 프론트엔드|마이크로 프론트엔드]]
+- [[모바일 기반 WebGL 애플리케이션 개발|모바일 기반 WebGL 애플리케이션 개발]]
+- [[셰이더 정밀도 (Mediump_Highp)|셰이더 정밀도 (Mediump_Highp]]
+- [[스토리지 텍스처(Storage Textures)|스토리지 텍스처(Storage Textures]]
+- [[실시간 물리 및 유체 시뮬레이션|실시간 물리 및 유체 시뮬레이션]]
+- [[웹 브라우저 그래픽 API 호환성|웹 브라우저 그래픽 API 호환성]]
+- [[입자 시스템(Particle Systems)|입자 시스템(Particle Systems]]
+- [[컴퓨트 셰이더(Compute Shaders)|컴퓨트 셰이더(Compute Shaders]]
+- [[프래그먼트 바운드(Fragment-bound)|프래그먼트 바운드(Fragment-bound]]
+- [[프래그먼트 셰이딩(Fragment Shading)|프래그먼트 셰이딩(Fragment Shading]]
+- [[헤드 마운트 디스플레이(HMD)|헤드 마운트 디스플레이(HMD]]
+- [[헤드 마운트 디스플레이(HMD)|헤드마운트 디스플레이 (HMD]]

10_Wiki/Topics/Graphics & Performance/Indirect Draw.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-8EEC8D
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8EEC8D
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Indirect Draw"
 ---
 
-# [[Indirect Draw]]
+# [[Indirect Draw|Indirect Draw]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Indirect Draw(간접 그리기)는 렌더링할 객체의 수와 정보를 CPU가 아닌 GPU가 컴퓨트 셰이더([[Compute Shader]])의 연산 결과를 바탕으로 직접 결정하여 화면에 그리는 GPU 주도 렌더링([[GPU-driven Rendering]]) 기법이다 [1, 2]. 이 방식을 사용하면 시야 절두체 컬링([[Frustum Culling]])이나 오클루전(Occlusion) 컬링의 결과를 GPU 내부 버퍼에 저장하고 `drawIndirect` 명령으로 바로 출력하므로, CPU와 GPU 간의 데이터 전송량 및 동기화 지연을 거의 0으로 줄일 수 있다 [2, 3]. 매 프레임 수백만 개의 인스턴스를 GPU에서 직접 컬링하고 렌더링해야 하는 대규모 3D 환경에서 필수적인 성능 최적화 기술로 활용된다 [1, 2].
+> Indirect Draw(간접 그리기)는 렌더링할 객체의 수와 정보를 CPU가 아닌 GPU가 컴퓨트 셰이더([[Compute Shader|Compute Shader]])의 연산 결과를 바탕으로 직접 결정하여 화면에 그리는 GPU 주도 렌더링(GPU-driven Rendering) 기법이다 [1, 2]. 이 방식을 사용하면 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])이나 오클루전(Occlusion) 컬링의 결과를 GPU 내부 버퍼에 저장하고 `drawIndirect` 명령으로 바로 출력하므로, CPU와 GPU 간의 데이터 전송량 및 동기화 지연을 거의 0으로 줄일 수 있다 [2, 3]. 매 프레임 수백만 개의 인스턴스를 GPU에서 직접 컬링하고 렌더링해야 하는 대규모 3D 환경에서 필수적인 성능 최적화 기술로 활용된다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **작동 원리 및 GPU 주도 렌더링 (GPU-Driven Rendering):** 
@@ -20,15 +20,15 @@ github_commit: "[P-Reinforce] Continuous Worker - Indirect Draw"
   렌더링을 위한 데이터와 명령 버퍼가 GPU 내부에서 생성되고 직접 참조되므로(`drawIndexedIndirect` 등), CPU와 GPU 간의 무거운 메모리 전송 및 동기화 지연이 제거된다 [2, 3]. 이는 구조적으로 "CPU가 GPU에게 무엇을 할지 지시하는 방식"에서 벗어나 "GPU가 스스로 무엇을 렌더링할지 지시하는 시스템"으로의 그래픽스 패러다임 전환을 의미한다 [3].
 
 * **지원 환경 및 한계 극복:** 
-  [[WebGPU]], [[Vulkan]] 등 최신 그래픽스 API 환경에서 주로 활용되며, Three.js에서도 WebGPU 도입과 함께 적극 활용되고 있다 [2, 6, 7]. 매우 복잡하고 방대한 객체를 다룰 때, 기존의 [[InstancedMesh]]나 BatchedMesh가 CPU 기반 데이터 업데이트 및 버퍼 패킹으로 인해 겪게 되는 성능 저하 한계를 근본적으로 극복할 수 있는 기술로 평가받는다 [2, 8, 9].
+  [[WebGPU|WebGPU]], Vulkan 등 최신 그래픽스 API 환경에서 주로 활용되며, Three.js에서도 WebGPU 도입과 함께 적극 활용되고 있다 [2, 6, 7]. 매우 복잡하고 방대한 객체를 다룰 때, 기존의 [[InstancedMesh|InstancedMesh]]나 BatchedMesh가 CPU 기반 데이터 업데이트 및 버퍼 패킹으로 인해 겪게 되는 성능 저하 한계를 근본적으로 극복할 수 있는 기술로 평가받는다 [2, 8, 9].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU-Driven Rendering]], [[Compute Shader]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** Three.js WebGPURenderer, BatchedMesh, [[Vulkan]]
+- **Related Topics:** [[GPU-driven Rendering|GPU-Driven Rendering]], Compute Shader, Frustum Culling, [[WebGPU|WebGPU]]
+- **Projects/Contexts:** Three.js WebGPURenderer, BatchedMesh, [[Vulkan|Vulkan]]
 - **Contradictions/Notes:** 대규모 지오메트리를 처리할 때 BatchedMesh만으로는 CPU의 버퍼 업로드 병목이 발생할 수 있어 근본적인 성능 문제를 피하기 어려우며, 이를 해결하기 위해서는 WebGPU 환경의 Indirect Draw 지원이 필수적이라는 점이 소스에서 한계점(pushing the limits)으로 지적된다 [9].
 
 ---

10_Wiki/Topics/Graphics & Performance/InstancedMesh (드로우 콜 최적화).md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-86F967
+id: [[P-Reinforce|P-Reinforce]]-AUTO-86F967
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh]] (드로우 콜 최적화)"
+github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh|InstancedMesh]] (드로우 콜 최적화)"
 ---
 
-# [[InstancedMesh (드로우 콜 최적화)]]
+# [[InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> `InstancedMesh`는 **동일한 기하구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 1회의 드로우 콜([[Draw Call]])만으로 GPU에서 렌더링**하여, CPU의 오버헤드를 극적으로 줄이고 애플리케이션의 프레임 레이트(FPS)를 비약적으로 향상시키는 3D 그래픽스 핵심 최적화 기법입니다.
+> `InstancedMesh`는 **동일한 기하구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 1회의 드로우 콜([[Draw Call|Draw Call]])만으로 GPU에서 렌더링**하여, CPU의 오버헤드를 극적으로 줄이고 애플리케이션의 프레임 레이트(FPS)를 비약적으로 향상시키는 3D 그래픽스 핵심 최적화 기법입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 **1. 드로우 콜(Draw Call)의 개념과 성능 병목** 모든 3D 장면에서 메시는 각각의 드로우 콜을 발생시키며, 이 횟수가 많아질수록 CPU가 GPU에 렌더링 명령을 내리는 오버헤드가 급증합니다. 매끄러운 60FPS를 유지하기 위한 렌더링의 골든 룰은 **프레임당 드로우 콜을 100회 미만으로 유지**하는 것이며, 폴리곤(삼각형)의 수보다 드로우 콜의 횟수가 성능에 훨씬 치명적인 영향을 미칩니다.
@@ -26,8 +26,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh]] (드로우
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Draw Call [[Optimization]] (드로우 콜 최적화), BatchedMesh, [[Object [[Pooling]] (오브젝트 풀링)]], React Three Fiber 자산 최적화
-- **Projects/Contexts:** [[대규모 파티클 시스템 최적화]], 수만 개의 데이터를 표현하는 3D 산점도(Scatter Plot) 시각화, 숲, 군중 등 반복 객체가 많은 3D 씬
+- **Related Topics:** Draw Call [[Optimization|Optimization]] (드로우 콜 최적화), BatchedMesh, Object Pooling (오브젝트 풀링, React Three Fiber 자산 최적화
+- **Projects/Contexts:** [[대규모 파티클 시스템 최적화|대규모 파티클 시스템 최적화]], 수만 개의 데이터를 표현하는 3D 산점도(Scatter Plot) 시각화, 숲, 군중 등 반복 객체가 많은 3D 씬
 - **Contradictions/Notes:** `InstancedMesh`는 성능 개선에 탁월하지만, **모든 인스턴스가 반드시 동일한 기하구조(Geometry)와 재질(Material)을 공유해야 한다는 설계적 제약**이 따릅니다. 만약 재질은 같으나 형태(Geometry)가 서로 다른 여러 객체들을 묶어 드로우 콜을 1회로 줄이려면, R156 버전에 도입된 `BatchedMesh`를 사용하는 것이 더 적합합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/InstancedMesh2.md

@@ -1,26 +1,26 @@
 ---
-id: [[P-Reinforce]]-AUTO-0E2591
+id: [[P-Reinforce|P-Reinforce]]-AUTO-0E2591
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh]]2"
+github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh|InstancedMesh]]2"
 ---
 
-# [[InstancedMesh2]]
+# [[InstancedMesh2|InstancedMesh2]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh2는 Three.js의 기본 `InstancedMesh`를 확장하여 성능과 기능을 대폭 강화한 오픈 소스 라이브러리이다 [1-3]. 이 라이브러리는 개별 인스턴스에 대한 절두체 컬링([[Frustum Culling]]), 공간 인덱스(BVH)를 이용한 빠른 레이캐스팅, 정렬([[Sorting]]), 개별 가시성 관리 및 LOD 기능을 제공한다 [2-5]. 특히 기존 인스턴싱 기술로 처리하기 까다로웠던 개별 애니메이션 상태를 가진 스킨드 메쉬(Skinned Mesh)의 인스턴싱을 지원하여 대규모 3D 환경을 효율적으로 렌더링하는 데 활용된다 [1, 3, 6].
+> InstancedMesh2는 Three.js의 기본 `InstancedMesh`를 확장하여 성능과 기능을 대폭 강화한 오픈 소스 라이브러리이다 [1-3]. 이 라이브러리는 개별 인스턴스에 대한 절두체 컬링([[Frustum Culling|Frustum Culling]]), 공간 인덱스(BVH)를 이용한 빠른 레이캐스팅, 정렬([[Sorting|Sorting]]), 개별 가시성 관리 및 LOD 기능을 제공한다 [2-5]. 특히 기존 인스턴싱 기술로 처리하기 까다로웠던 개별 애니메이션 상태를 가진 스킨드 메쉬(Skinned Mesh)의 인스턴싱을 지원하여 대규모 3D 환경을 효율적으로 렌더링하는 데 활용된다 [1, 3, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **핵심 기능 및 최적화 기법**
     *   **인스턴스별 절두체 컬링 및 가시성 제어:** 개별 인스턴스 단위로 가시성을 관리하고 절두체 컬링을 수행한다 [2, 3, 5]. 이를 통해 카메라 뷰 내부에 존재하는 인스턴스의 뼈대(Bone) 계산만 수행하는 등 연산을 극도로 최적화할 수 있으며, `onFrustumEnter`를 사용해 인스턴스 렌더링 여부를 정밀하게 제어할 수 있다 [1, 7].
-    *   **BVH 기반 빠른 레이캐스팅:** `[[three-mesh-bvh]]` 라이브러리 설계에 착안한 공간 인덱스(Spatial index)를 포함하여, 수많은 인스턴스가 배치된 환경에서도 빠른 레이캐스팅과 컬링을 지원한다 [3-5, 8].
+    *   **BVH 기반 빠른 레이캐스팅:** `[[three-mesh-bvh|three-mesh-bvh]]` 라이브러리 설계에 착안한 공간 인덱스(Spatial index)를 포함하여, 수많은 인스턴스가 배치된 환경에서도 빠른 레이캐스팅과 컬링을 지원한다 [3-5, 8].
     *   **LOD 및 애니메이션(Skinning) 최적화:** 객체의 거리(LOD)에 따라 기하학적 구조(Geometry)뿐 아니라 뼈대(Bones) 연산까지 축소하고, 거리에 비례하여 애니메이션 FPS를 0에서 60까지 조절할 수 있다 [1, 6, 9, 10]. 이를 통해 모바일 기기에서도 2만 개 이상의 스킨드 인스턴스를 무리 없이 구동할 수 있다 [1].
-    *   **정렬(Sorting):** 렌더링 시 투명도 문제를 방지하기 위해, 내부적으로 BatchedMesh에 기반한 기수 정렬([[Radix Sort]]) 기능을 제공한다 [11, 12].
+    *   **정렬(Sorting):** 렌더링 시 투명도 문제를 방지하기 위해, 내부적으로 BatchedMesh에 기반한 기수 정렬([[Radix Sort|Radix Sort]]) 기능을 제공한다 [11, 12].
 
 *   **내부 아키텍처 및 데이터 구조**
-    *   **간접 참조(Indirection) 기반 인덱싱:** 라이브러리 초기 버전과 달리, `Instanced[[BufferAttribute]]`를 활용하여 렌더링될 인스턴스 인덱스를 간접적으로 관리한다 [12]. 이는 GPU로 데이터를 보내기 전 컬링, 선택적 렌더링, 정렬 작업을 배열의 물리적 재정렬 없이 빠르게 수행할 수 있게 한다 [12].
+    *   **간접 참조(Indirection) 기반 인덱싱:** 라이브러리 초기 버전과 달리, `Instanced[[BufferAttribute|BufferAttribute]]`를 활용하여 렌더링될 인스턴스 인덱스를 간접적으로 관리한다 [12]. 이는 GPU로 데이터를 보내기 전 컬링, 선택적 렌더링, 정렬 작업을 배열의 물리적 재정렬 없이 빠르게 수행할 수 있게 한다 [12].
     *   **SquareDataTexture의 활용:** 인스턴스의 행렬(Matrix) 및 주요 데이터를 저장하는 데 `DataTexture`의 확장 버전인 `SquareDataTexture`를 사용한다 [12]. 이 방식은 부분 업데이트(Partial Updates)를 지원하여 전체 데이터를 갱신할 필요 없이 변경된 일부 인스턴스의 정보만 갱신하도록 돕는다 [8, 12].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -28,8 +28,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[InstancedMesh]]2"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Frustum culling]], [[BVH]], [[LOD]], [[SkinnedMesh]], BatchedMesh
-- **Projects/Contexts:** [[agargaro의 오픈 소스 라이브러리]], [[20k skinned instances demo]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], Frustum culling, BVH, [[LOD|LOD]], [[SkinnedMesh|SkinnedMesh]], BatchedMesh
+- **Projects/Contexts:** [[agargaro의 오픈 소스 라이브러리|agargaro의 오픈 소스 라이브러리]], [[20k skinned instances demo|20k skinned instances demo]]
 - **Contradictions/Notes:** 
   - `SquareDataTexture`를 활용한 부분 업데이트 기능이 연속되지 않은 메모리 접근과 부가적인 함수 호출로 인해 CPU 오버헤드를 유발할 수 있다는 우려가 제기되었으나, 소수의 인스턴스만 변하는 상황에서는 상당한 대역폭 절약 효과가 있다고 라이브러리 개발자(@agargaro)가 반론했습니다 [8, 13, 14].
   - 이러한 고급 기능들이 유용함에도 불구하고, Three.js의 메인 코어에 병합하기에는 내부 셰이더 변경과 기존 코드 호환성 파괴(Breaking changes) 등 유지보수 복잡성이 너무 커서 외부 라이브러리로 분리 개발되고 있습니다 [15, 16].

10_Wiki/Topics/Graphics & Performance/Instancing.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-2752BF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-2752BF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Instancing"
 ---
 
-# [[Instancing]]
+# [[Instancing|Instancing]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인스턴싱(Instancing)은 웹 그래픽스 렌더링 및 UI 디자인 소프트웨어에서 성능을 최적화하기 위해 동일한 객체를 효율적으로 반복 처리하는 기법입니다. [[WebGL]]이나 [[WebGPU]] 환경에서는 단일 드로우 콜([[Draw Call]])로 동일한 메쉬나 형태를 대량으로 그려내어 CPU 및 GPU 오버헤드를 줄이는 핵심 기술로 사용됩니다 [1, 2]. 반면 [[Figma]]와 같은 디자인 도구에서는 원본 컴포넌트의 복제본을 의미하며, 인스턴스 내부의 구조적 최적화 여부가 소프트웨어 성능에 직접적인 영향을 미칩니다 [3, 4].
+> 인스턴싱(Instancing)은 웹 그래픽스 렌더링 및 UI 디자인 소프트웨어에서 성능을 최적화하기 위해 동일한 객체를 효율적으로 반복 처리하는 기법입니다. [[WebGL|WebGL]]이나 WebGPU 환경에서는 단일 드로우 콜(Draw Call)로 동일한 메쉬나 형태를 대량으로 그려내어 CPU 및 GPU 오버헤드를 줄이는 핵심 기술로 사용됩니다 [1, 2]. 반면 [[Figma|Figma]]와 같은 디자인 도구에서는 원본 컴포넌트의 복제본을 의미하며, 인스턴스 내부의 구조적 최적화 여부가 소프트웨어 성능에 직접적인 영향을 미칩니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **웹 그래픽스 렌더링 최적화 (WebGL & WebGPU):**
   - **드로우 콜(Draw Call) 감소:** WebGL 애플리케이션에서 성능을 극대화하는 가장 중요한 비결은 드로우 콜 횟수를 최소화하는 것입니다 [5]. 동일한 메쉬를 여러 번 호출하여 그리는 대신 인스턴싱 기법을 사용하면 대량의 메쉬를 단일 함수 호출로 렌더링할 수 있어 성능 오버헤드를 크게 줄일 수 있습니다 [1].
-  - **WebGPU를 활용한 가우시안 렌더링 (WebSplatter):** WebGPU 기반의 [[3D Gaussian Splatting]] 프레임워크인 WebSplatter는 래스터화 단계에서 인스턴스화된 드로우 콜(instanced draw call)을 통해 각 가우시안을 단일 쿼드(두 개의 삼각형)로 제출하여 렌더링합니다 [2]. 렌더 패스(Render pass) 내부에서 `passEncoder.draw(vertexCount, instanceCount)` 명령을 호출하여, 지정된 정점 및 인스턴스 수만큼 버텍스 셰이더와 프래그먼트 셰이더의 실행을 트리거합니다 [6].
-  - **관련 WebGL 확장 기능:** WebGL 생태계에서는 이와 같은 인스턴싱을 지원하기 위해 `[[ANGLE]]_instanced_arrays`라는 확장(Extension) 기능을 제공합니다 [7].
+  - **WebGPU를 활용한 가우시안 렌더링 (WebSplatter):** WebGPU 기반의 [[3D_Gaussian_Splatting|3D Gaussian Splatting]] 프레임워크인 WebSplatter는 래스터화 단계에서 인스턴스화된 드로우 콜(instanced draw call)을 통해 각 가우시안을 단일 쿼드(두 개의 삼각형)로 제출하여 렌더링합니다 [2]. 렌더 패스(Render pass) 내부에서 `passEncoder.draw(vertexCount, instanceCount)` 명령을 호출하여, 지정된 정점 및 인스턴스 수만큼 버텍스 셰이더와 프래그먼트 셰이더의 실행을 트리거합니다 [6].
+  - **관련 WebGL 확장 기능:** WebGL 생태계에서는 이와 같은 인스턴싱을 지원하기 위해 `[[ANGLE|ANGLE]]_instanced_arrays`라는 확장(Extension) 기능을 제공합니다 [7].
 
 - **디자인 시스템 및 UI 도구(Figma)에서의 인스턴스:**
   - **성능 저하의 원인:** 대규모 디자인 파일에서 복잡한 중첩 구조를 가진 컴포넌트를 사용할 때, 인스턴스 내부에 불필요하게 포함된 숨겨진 레이어(hidden layers)는 파일의 렌더링과 업데이트 속도를 크게 늦출 수 있습니다 [3, 8, 9].
@@ -27,8 +27,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Instancing"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Draw Calls, [[WebGL]], [[WebGPU]], Gaussian Splatting
-- **Projects/Contexts:** [[Wonderland Engine]], WebSplatter, [[Figma]]
+- **Related Topics:** Draw Calls, [[WebGL|WebGL]], [[WebGPU|WebGPU]], Gaussian Splatting
+- **Projects/Contexts:** [[Wonderland Engine|Wonderland Engine]], WebSplatter, [[Figma|Figma]]
 - **Contradictions/Notes:** 주어진 소스 데이터 내에서 '인스턴스(Instancing)'라는 용어는 3D 그래픽스 하드웨어 가속을 위한 렌더링 효율화 기법(WebGL/WebGPU)과, 디자인 도구 내에서 원본 객체를 복제해 사용하는 개체 단위(Figma)라는 두 가지 상이한 맥락에서 설명되고 있습니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/JavaScript.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-4A99EB
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4A99EB
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,23 +7,23 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - JavaScript"
 ---
 
-# [[JavaScript]]
+# [[JavaScript|JavaScript]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> JavaScript는 단일 페이지 애플리케이션을 구축하고 [[WebGL]], [[WebGPU]]와 같은 웹 브라우저 API를 제어하는 데 사용되는 핵심 스크립팅 언어입니다 [1, 2]. 애플리케이션 로직, 이벤트 처리 및 데이터 준비에 필수적이지만, 브라우저의 메인 스레드에서 무거운 JavaScript를 실행하거나 가비지 컬렉션이 발생하면 심각한 성능 병목 현상이 생길 수 있습니다 [3-5]. 따라서 최근의 웹 성능 최적화는 JavaScript 페이로드를 줄이고, 실행 시간을 분할하며, 무거운 연산을 GPU로 오프로드하는 방향으로 발전하고 있습니다 [6, 7].
+> JavaScript는 단일 페이지 애플리케이션을 구축하고 [[WebGL|WebGL]], [[WebGPU|WebGPU]]와 같은 웹 브라우저 API를 제어하는 데 사용되는 핵심 스크립팅 언어입니다 [1, 2]. 애플리케이션 로직, 이벤트 처리 및 데이터 준비에 필수적이지만, 브라우저의 메인 스레드에서 무거운 JavaScript를 실행하거나 가비지 컬렉션이 발생하면 심각한 성능 병목 현상이 생길 수 있습니다 [3-5]. 따라서 최근의 웹 성능 최적화는 JavaScript 페이로드를 줄이고, 실행 시간을 분할하며, 무거운 연산을 GPU로 오프로드하는 방향으로 발전하고 있습니다 [6, 7].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-*   **웹 그래픽(WebGL 및 WebGPU)에서의 역할:** JavaScript는 브라우저의 WebGL 및 WebGPU API와 상호 작용하기 위한 인터페이스 언어입니다 [2, 8]. WebGL 환경에서 JavaScript 프로그램은 CPU에서 실행되며, 3D 모델 데이터 변환, 버퍼 객체 생성, 유니폼(Uniform) 변수 설정 및 드로우 콜([[Draw Call]]) 발행 등의 작업을 수행합니다 [9, 10]. 그러나 JavaScript 프로그램과 GPU 간의 빈번한 통신 및 브라우저 API 호출은 렌더링 속도를 저하시키는 큰 오버헤드를 발생시킵니다 [11, 12]. 이러한 문제를 해결하기 위해 등장한 WebGPU는 애니메이션이나 정렬과 같은 로직을 GPU의 컴퓨트 셰이더([[Compute Shader]])로 직접 오프로드하여 JavaScript 런타임으로 인한 메인 스레드 병목 현상을 획기적으로 줄여줍니다 [6, 13, 14].
-*   **성능 영향 및 최적화:** JavaScript 실행은 INP(Interaction to Next Paint) 및 TBT(Total [[Blocking]] Time)와 같은 코어 웹 바이탈([[Core Web Vitals]]) 성능 지표에 직접적인 영향을 미칩니다 [7, 15]. 메인 스레드를 50ms 이상 차단하는 긴 작업([[Long Tasks]])은 사용자 상호 작용에 대한 응답을 지연시킵니다 [7]. 또한, JavaScript의 가비지 컬렉션([[Garbage Collection]]) 프로세스는 개발자가 제어할 수 없는 시점에 일시 중지를 유발하여 렌더링 끊김(Stutter)이나 불규칙한 프레임 속도를 발생시킬 수 있습니다 [4, 8]. 이를 최적화하기 위해 개발자는 긴 작업을 더 작은 비동기 청크로 분할하고, 필수적이지 않은 JS를 지연 로드(Defer/Lazy load)하며, 가비지가 없는(garbage-free) 코드를 작성해야 합니다 [7, 16, 17].
-*   **성능 모니터링 및 디버깅:** [[Chrome DevTools]]의 성능(Performance) 패널은 JavaScript 성능을 프로파일링하는 데 필수적인 도구입니다 [3]. 이 도구를 통해 개발자는 메인 스레드 활동의 플레임 차트([[Flame Chart]])를 분석하고, JavaScript 함수의 세부 호출 스택을 확인하며, 강제 동기식 레이아웃(Forced synchronous layouts)을 유발하거나 상호 작용 처리를 지연시키는 특정 스크립트를 식별할 수 있습니다 [3, 18, 19]. 또한, [[Long Animation Frames API]]를 기반으로 사용자 상호 작용을 지연시키는 스크립트의 레이아웃 작업 및 스크립팅 작업 비율을 확인할 수 있습니다 [20].
+*   **웹 그래픽(WebGL 및 WebGPU)에서의 역할:** JavaScript는 브라우저의 WebGL 및 WebGPU API와 상호 작용하기 위한 인터페이스 언어입니다 [2, 8]. WebGL 환경에서 JavaScript 프로그램은 CPU에서 실행되며, 3D 모델 데이터 변환, 버퍼 객체 생성, 유니폼(Uniform) 변수 설정 및 드로우 콜([[Draw Call|Draw Call]]) 발행 등의 작업을 수행합니다 [9, 10]. 그러나 JavaScript 프로그램과 GPU 간의 빈번한 통신 및 브라우저 API 호출은 렌더링 속도를 저하시키는 큰 오버헤드를 발생시킵니다 [11, 12]. 이러한 문제를 해결하기 위해 등장한 WebGPU는 애니메이션이나 정렬과 같은 로직을 GPU의 컴퓨트 셰이더([[Compute Shader|Compute Shader]])로 직접 오프로드하여 JavaScript 런타임으로 인한 메인 스레드 병목 현상을 획기적으로 줄여줍니다 [6, 13, 14].
+*   **성능 영향 및 최적화:** JavaScript 실행은 INP(Interaction to Next Paint) 및 TBT(Total [[Blocking|Blocking]] Time)와 같은 코어 웹 바이탈(Core Web Vitals) 성능 지표에 직접적인 영향을 미칩니다 [7, 15]. 메인 스레드를 50ms 이상 차단하는 긴 작업(Long Tasks)은 사용자 상호 작용에 대한 응답을 지연시킵니다 [7]. 또한, JavaScript의 가비지 컬렉션([[Garbage Collection|Garbage Collection]]) 프로세스는 개발자가 제어할 수 없는 시점에 일시 중지를 유발하여 렌더링 끊김(Stutter)이나 불규칙한 프레임 속도를 발생시킬 수 있습니다 [4, 8]. 이를 최적화하기 위해 개발자는 긴 작업을 더 작은 비동기 청크로 분할하고, 필수적이지 않은 JS를 지연 로드(Defer/Lazy load)하며, 가비지가 없는(garbage-free) 코드를 작성해야 합니다 [7, 16, 17].
+*   **성능 모니터링 및 디버깅:** [[Chrome DevTools|Chrome DevTools]]의 성능(Performance) 패널은 JavaScript 성능을 프로파일링하는 데 필수적인 도구입니다 [3]. 이 도구를 통해 개발자는 메인 스레드 활동의 플레임 차트(Flame Chart)를 분석하고, JavaScript 함수의 세부 호출 스택을 확인하며, 강제 동기식 레이아웃(Forced synchronous layouts)을 유발하거나 상호 작용 처리를 지연시키는 특정 스크립트를 식별할 수 있습니다 [3, 18, 19]. 또한, [[Long Animation Frames API|Long Animation Frames API]]를 기반으로 사용자 상호 작용을 지연시키는 스크립트의 레이아웃 작업 및 스크립팅 작업 비율을 확인할 수 있습니다 [20].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[WebGL]]`, `[[WebGPU]]`, `[[Interaction to Next Paint (INP)]]`, `[[Garbage Collection]]`, `[[Chrome DevTools]]`
-- **Projects/Contexts:** `Three.js`, `웹 그래픽 성능 최적화(Web Graphics Performance [[Optimization]])`
+- **Related Topics:** `[[WebGL|WebGL]]`, `WebGPU`, `Interaction to Next Paint (INP)`, `[[Garbage Collection|Garbage Collection]]`, `[[Chrome DevTools|Chrome DevTools]]`
+- **Projects/Contexts:** `Three.js`, `웹 그래픽 성능 최적화(Web Graphics Performance [[Optimization|Optimization]])`
 - **Contradictions/Notes:** WebGL을 구동하기 위해 JavaScript는 필수적이지만, CPU 측의 JavaScript 실행 및 상태 유효성 검사 오버헤드가 오히려 렌더링 성능을 제한하는 가장 큰 병목으로 작용합니다. 이로 인해 3D 렌더링 산업은 JavaScript의 개입을 줄이고 GPU의 병렬 연산을 극대화할 수 있는 WebGPU로 빠르게 전환하는 추세입니다 [5, 6, 13].
 
 ---

10_Wiki/Topics/Graphics & Performance/Memory Leak Prevention 메모리 누수 방지.md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-21F91F
+id: [[P-Reinforce|P-Reinforce]]-AUTO-21F91F
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[memory]] Leak Prevention 메모리 누수 방지"
+github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] Leak Prevention 메모리 누수 방지"
 ---
 
-# [[Memory Leak Prevention 메모리 누수 방지]]
+# [[Memory Leak Prevention 메모리 누수 방지|Memory Leak Prevention 메모리 누수 방지]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 애플리케이션 및 [[WebGL]]/Three.js 환경에서 해제되지 않은 타이머, 이벤트 리스너, 외부 객체 참조, 또는 GPU 자원으로 인해 시간이 지날수록 메모리 점유율이 증가하여 앱이 느려지거나 크래시되는 현상을 막기 위한 필수적인 자원 관리 및 최적화 기법입니다.
+> React 애플리케이션 및 [[WebGL|WebGL]]/Three.js 환경에서 해제되지 않은 타이머, 이벤트 리스너, 외부 객체 참조, 또는 GPU 자원으로 인해 시간이 지날수록 메모리 점유율이 증가하여 앱이 느려지거나 크래시되는 현상을 막기 위한 필수적인 자원 관리 및 최적화 기법입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 **1. React의 주요 메모리 누수 원인과 클린업(Cleanup)** React 앱이 시간이 지날수록 느려지는 가장 흔한 원인은 언마운트(Unmount)된 컴포넌트의 잔재가 계속 남아 메모리를 점유하는 경우입니다.
@@ -30,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[memory]] Leak Prevention 메
 
 **4. 메모리 누수 탐지 및 모니터링 (Debugging & Monitoring)**
 
-- **[[Chrome DevTools]] Memory Profiler:** 특정 사용자 행동 전후의 힙 스냅샷([[Heap Snapshot]]s)을 찍어 비교하고, 할당 타임라인([[Allocation Timeline]]s)을 통해 가비지 컬렉션되어야 할 객체가 그대로 남아있는지 추적하여 누수 지점을 찾아냅니다.
+- **[[Chrome DevTools|Chrome DevTools]] Memory Profiler:** 특정 사용자 행동 전후의 힙 스냅샷(Heap Snapshots)을 찍어 비교하고, 할당 타임라인([[Allocation Timeline|Allocation Timeline]]s)을 통해 가비지 컬렉션되어야 할 객체가 그대로 남아있는지 추적하여 누수 지점을 찾아냅니다.
 - 개발 환경에서는 `performance.memory.usedJSHeapSize`를 모니터링하여 메모리 점유율이 일정 수치(예: 200MB)를 넘어가면 경고(Alert)를 발생시키도록 감시 코드를 작성해 선제적으로 대응할 수 있습니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -38,7 +38,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[memory]] Leak Prevention 메
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[useEffect 클린업(Cleanup)]], [[Garbage Collection]] (GC) 최적화, Three.js 자원 해제 (Dispose), [[Chrome]] DevTools Memory Profiler
+- **Related Topics:** [[useEffect 클린업(Cleanup)|useEffect 클린업(Cleanup]], Garbage Collection (GC) 최적화, Three.js 자원 해제 (Dispose), [[Chrome|Chrome]] DevTools Memory Profiler
 - **Projects/Contexts:** 장기 실행되는 실시간 대시보드 최적화, 대규모 WebGL/R3F 3D 게임 환경의 메모리 관리
 - **Contradictions/Notes:** 최신 자바스크립트 엔진은 매우 훌륭한 가비지 컬렉터(GC)를 갖추고 있으나, DOM 이벤트, 브라우저 API(타이머, 소켓), WebGL GPU 메모리 등 '자바스크립트 엔진 외부의 자원'과 연결된 참조는 GC가 임의로 판단해 지울 수 없습니다. 따라서 외부 자원과의 연결 고리는 개발자가 직접 끊어주어야만 완벽한 메모리 관리가 가능합니다.
 

10_Wiki/Topics/Graphics & Performance/Memory Leaks.md

@@ -1,21 +1,21 @@
 ---
-id: [[P-Reinforce]]-AUTO-5A05AF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-5A05AF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[memory]] Leaks"
+github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] Leaks"
 ---
 
-# [[Memory Leaks]]
+# [[Memory Leaks|Memory Leaks]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 및 [[WebGL]] 환경에서 메모리 누수(Memory Leaks)는 GPU 리소스가 자동으로 가비지 컬렉션([[Garbage Collection]])되지 않아 VRAM 등 메모리 사용량이 지속적으로 증가하는 현상을 의미합니다 [1]. 이는 주로 지오메트리, 재질, 텍스처 등의 렌더링 리소스를 코드 상에서 명시적으로 해제하지 않았을 때 발생합니다 [1, 2]. 메모리 누수를 방지하려면 렌더러 정보를 통한 지속적인 모니터링과 올바른 메모리 관리 기법의 적용이 필수적입니다 [2].
+> Three.js 및 [[WebGL|WebGL]] 환경에서 메모리 누수(Memory Leaks)는 GPU 리소스가 자동으로 가비지 컬렉션([[Garbage Collection|Garbage Collection]])되지 않아 VRAM 등 메모리 사용량이 지속적으로 증가하는 현상을 의미합니다 [1]. 이는 주로 지오메트리, 재질, 텍스처 등의 렌더링 리소스를 코드 상에서 명시적으로 해제하지 않았을 때 발생합니다 [1, 2]. 메모리 누수를 방지하려면 렌더러 정보를 통한 지속적인 모니터링과 올바른 메모리 관리 기법의 적용이 필수적입니다 [2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **GPU 리소스의 수동 해제:** Three.js는 GPU 리소스를 자동으로 가비지 컬렉션하지 않기 때문에, 더 이상 사용하지 않는 자원은 반드시 개발자가 직접 **`geometry.dispose()`, `material.dispose()`, `texture.dispose()`, `renderTarget.dispose()`**를 호출하여 해제해야 합니다 [1-3].
 *   **GLTF ImageBitmap 특수 처리:** GLTF 모델에서 불러온 텍스처는 `ImageBitmap` 객체로 로드되므로 누수를 막기 위한 추가적인 처리가 필요합니다 [3]. 이러한 텍스처는 일반적인 `dispose()` 외에도 반드시 **`texture.source.data.close?.()`**를 호출하여 명시적으로 닫아주어야 ImageBitmap 객체의 메모리 누수를 막을 수 있습니다 [2, 3].
-*   **오브젝트 풀링(Object [[Pooling]]) 도입:** 런타임 중 빈번하게 생성되고 파괴되는 오브젝트(예: 총알, 파티클, 적 등)는 메모리 할당 오버헤드와 이로 인한 가비지 컬렉션 지연(GC pauses)을 유발할 수 있습니다 [3]. 이를 방지하기 위해 새로운 객체를 매번 할당하는 대신 기존 객체를 재활용하는 **객체 풀링([[Object Pooling]])** 패턴을 구현해야 합니다 [2, 3].
+*   **오브젝트 풀링(Object [[Pooling|Pooling]]) 도입:** 런타임 중 빈번하게 생성되고 파괴되는 오브젝트(예: 총알, 파티클, 적 등)는 메모리 할당 오버헤드와 이로 인한 가비지 컬렉션 지연(GC pauses)을 유발할 수 있습니다 [3]. 이를 방지하기 위해 새로운 객체를 매번 할당하는 대신 기존 객체를 재활용하는 **객체 풀링([[Object Pooling|Object Pooling]])** 패턴을 구현해야 합니다 [2, 3].
 *   **메모리 누수 모니터링:** 런타임에 메모리 누수가 발생하고 있는지 확인하려면 **`renderer.info.memory`** 지표를 주기적으로 모니터링해야 합니다 [1, 2]. 해당 지표에서 지오메트리와 텍스처의 카운트가 떨어지지 않고 계속해서 상승하기만 한다면, 명확한 메모리 누수로 판단할 수 있습니다 [1, 2].
 *   **에셋 스트리밍(Asset Streaming) 및 메모리 한계:** WebGL 컨텍스트는 제한된 메모리 용량(통상 256MB~1GB)을 지니고 있어 이를 초과하면 브라우저 크래시나 프리징이 발생할 수 있습니다 [4]. 무한한 크기의 씬이라도 카메라에서 100 유닛 이상 멀어진 자원들에 대해 `dispose()`를 호출해 메모리를 해제하는 스트리밍 방식을 적용하면, 활성화된 모델만 메모리에 유지하여 메모리 누수 및 고갈을 방지할 수 있습니다 [5].
 
@@ -24,8 +24,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[memory]] Leaks"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Object Pooling]], Dispose(), ImageBitmap
-- **Projects/Contexts:** Three.js Memory [[Management]], Asset Streaming in WebGL
+- **Related Topics:** [[Garbage Collection|Garbage Collection]], [[Object Pooling|Object Pooling]], Dispose(), ImageBitmap
+- **Projects/Contexts:** Three.js Memory [[Management|Management]], Asset Streaming in WebGL
 - **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 제공된 소스들은 모두 공통적으로 Three.js 엔진 환경에서 메모리 누수를 방지하기 위해 '사용이 끝난 자원의 명시적 해제(dispose)'가 절대적으로 필요함을 강조하고 있습니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Memory Management.md

@@ -1,32 +1,32 @@
 ---
-id: [[P-Reinforce]]-AUTO-F27A16
+id: [[P-Reinforce|P-Reinforce]]-AUTO-F27A16
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[memory]] [[Management]]"
+github_commit: "[P-Reinforce] Continuous Worker - [[memory|memory]] [[Management|Management]]"
 ---
 
-# [[Memory Management]]
+# [[Memory Management|Memory Management]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 3D 웹 렌더링 및 그래픽스 환경에서 'Memory Management(메모리 관리)'는 시스템의 제한된 RAM과 GPU VRAM을 효율적으로 통제하여 애플리케이션의 크래시, 메모리 누수, 그리고 가비지 컬렉션(GC)으로 인한 프레임 지연을 방지하는 필수적인 최적화 과정입니다 [1, 2]. 이는 불필요한 GPU 자원의 명시적 폐기, 객체 풀링, 버퍼의 사전 할당 및 텍스처 압축 기술을 포괄합니다 [3-6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **명시적 자원 폐기 및 누수 방지:** Three.js와 같은 엔진은 GPU 자원을 자동으로 가비지 컬렉션(GC)하지 않으므로, 사용이 끝난 Geometry, Material, Texture, Render Target은 반드시 명시적으로 폐기(`dispose()`)해야 합니다 [3, 4, 7, 8]. 특히 GLTF 모델에서 불러온 ImageBitmap 텍스처는 `close()`를 호출해야 메모리 누수를 차단할 수 있습니다 [4, 7]. 렌더러의 메모리 지표(`renderer.info.memory`)를 모니터링하여 누수 여부를 지속적으로 확인해야 합니다 [1, 3, 7].
-- **가비지 컬렉션(GC) 부하 최소화:** 런타임 중 빈번하게 생성 및 파괴되는 객체에 대해서는 매번 새로 메모리를 할당하는 대신 객체 풀링(Object [[Pooling]])을 사용하여 할당 오버헤드와 GC로 인한 일시적인 프레임 끊김(Stuttering) 현상을 방지해야 합니다 [2, 4, 7].
+- **가비지 컬렉션(GC) 부하 최소화:** 런타임 중 빈번하게 생성 및 파괴되는 객체에 대해서는 매번 새로 메모리를 할당하는 대신 객체 풀링(Object [[Pooling|Pooling]])을 사용하여 할당 오버헤드와 GC로 인한 일시적인 프레임 끊김(Stuttering) 현상을 방지해야 합니다 [2, 4, 7].
 - **동적 버퍼 할당 문제 통제:** 인스턴싱 환경에서 인스턴스 수가 변경될 때 버퍼 용량을 동적으로 확장하게 두면 잦은 메모리 재할당과 가비지 컬렉션 부하를 야기합니다 [2, 5, 9]. 이를 피하기 위해 최대 예상 인스턴스 수에 맞춰 초기 버퍼를 미리 크게 할당(Preallocate)하거나 링 버퍼(Ring Buffer) 구조를 활용하는 것이 권장됩니다 [2, 5].
-- **텍스처 및 지오메트리 압축:** 4K 해상도와 같은 고해상도 텍스처는 하나당 64MB 이상의 VRAM을 소모하며, 기기의 메모리 한계를 초과할 경우 브라우저 크래시를 유발할 수 있습니다 [1, 3, 10]. KTX2나 Basis Universal 같은 GPU 압축 텍스처 포맷을 도입하면 대역폭 및 메모리 사용량을 75% 이상 절감할 수 있으며 [6, 11, 12], 지오메트리 속성 역시 정밀도를 낮춰 양자화([[Quantization]])함으로써 버퍼 크기를 대폭 줄일 수 있습니다 [13]. 텍스처는 한 번만 로드하여 캐시한 뒤 여러 곳에서 재사용해야 합니다 [4, 14].
-- **멀티스레딩 환경의 메모리 최적화:** [[Electron]]과 같은 환경에서 대규모 CAD 모델을 로드할 때 메인 스레드와 워커 간의 메시지 전달(Structured Cloning)은 메모리 사용량을 두 배로 폭증시킬 위험이 있습니다 [15]. 이를 방지하기 위해 `SharedArrayBuffer`를 활용하여 메모리 복사 없이(Zero-copy) 데이터를 공유하는 아키텍처를 도입해야 합니다 [15, 16].
+- **텍스처 및 지오메트리 압축:** 4K 해상도와 같은 고해상도 텍스처는 하나당 64MB 이상의 VRAM을 소모하며, 기기의 메모리 한계를 초과할 경우 브라우저 크래시를 유발할 수 있습니다 [1, 3, 10]. KTX2나 Basis Universal 같은 GPU 압축 텍스처 포맷을 도입하면 대역폭 및 메모리 사용량을 75% 이상 절감할 수 있으며 [6, 11, 12], 지오메트리 속성 역시 정밀도를 낮춰 양자화([[Quantization|Quantization]])함으로써 버퍼 크기를 대폭 줄일 수 있습니다 [13]. 텍스처는 한 번만 로드하여 캐시한 뒤 여러 곳에서 재사용해야 합니다 [4, 14].
+- **멀티스레딩 환경의 메모리 최적화:** [[Electron|Electron]]과 같은 환경에서 대규모 CAD 모델을 로드할 때 메인 스레드와 워커 간의 메시지 전달(Structured Cloning)은 메모리 사용량을 두 배로 폭증시킬 위험이 있습니다 [15]. 이를 방지하기 위해 `SharedArrayBuffer`를 활용하여 메모리 복사 없이(Zero-copy) 데이터를 공유하는 아키텍처를 도입해야 합니다 [15, 16].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Object Pooling]], [[Texture Compression]], [[GPU Resources]], [[Buffer Allocation]]
-- **Projects/Contexts:** Three.js, [[WebGL]], [[Electron]], [[Needle Engine]]
-- **Contradictions/Notes:** 웹 기반 프론트엔드 개발에서는 자바스크립트의 자동 메모리 관리에 의존하기 쉬우나, 소스에 따르면 [[WebGL]]과 같은 GPU 자원은 가비지 컬렉터의 대상이 아니므로 개발자가 수동으로 자원 해제를 관리해야만 크래시와 누수를 막을 수 있다고 강력히 지적합니다 [3, 7, 17]. 또한, 드로우 콜을 줄이는 인스턴싱 기법이 성능에 유리해 보이지만, 동적으로 크기가 늘어나는 버퍼를 방치할 경우 오히려 심각한 가비지 컬렉션 병목을 초래해 전체 성능을 깎아먹을 수 있음을 경고합니다 [2, 9].
+- **Related Topics:** [[Garbage Collection|Garbage Collection]], Object Pooling, Texture Compression, [[GPU Resources|GPU Resources]], [[Buffer Allocation|Buffer Allocation]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], Electron, [[Needle Engine|Needle Engine]]
+- **Contradictions/Notes:** 웹 기반 프론트엔드 개발에서는 자바스크립트의 자동 메모리 관리에 의존하기 쉬우나, 소스에 따르면 [[WebGL|WebGL]]과 같은 GPU 자원은 가비지 컬렉터의 대상이 아니므로 개발자가 수동으로 자원 해제를 관리해야만 크래시와 누수를 막을 수 있다고 강력히 지적합니다 [3, 7, 17]. 또한, 드로우 콜을 줄이는 인스턴싱 기법이 성능에 유리해 보이지만, 동적으로 크기가 늘어나는 버퍼를 방치할 경우 오히려 심각한 가비지 컬렉션 병목을 초래해 전체 성능을 깎아먹을 수 있음을 경고합니다 [2, 9].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/MeshStandardMaterial 조명 연산.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-56F596
+id: [[P-Reinforce|P-Reinforce]]-AUTO-56F596
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - MeshStandardMaterial 조명 연산"
 ---
 
-# [[MeshStandardMaterial 조명 연산]]
+# [[MeshStandardMaterial 조명 연산|MeshStandardMaterial 조명 연산]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> MeshStandardMaterial은 금속성-거칠기([[Metal]]lic-roughness) 워크플로우를 사용하는 물리 기반 렌더링(PBR) 모델을 기반으로 한 Three.js의 재질입니다 [1]. 이 재질은 에너지 보존 법칙과 프레넬 반사(Fresnel [[Reflection]]s)와 같은 복잡한 조명 연산을 필요로 하므로, 세밀한 사실성을 제공하지만 Three.js 내에서 가장 연산 비용이 높은 재질 중 하나로 꼽힙니다 [1].
+> MeshStandardMaterial은 금속성-거칠기([[Metal|Metal]]lic-roughness) 워크플로우를 사용하는 물리 기반 렌더링(PBR) 모델을 기반으로 한 Three.js의 재질입니다 [1]. 이 재질은 에너지 보존 법칙과 프레넬 반사(Fresnel [[Reflection|Reflection]]s)와 같은 복잡한 조명 연산을 필요로 하므로, 세밀한 사실성을 제공하지만 Three.js 내에서 가장 연산 비용이 높은 재질 중 하나로 꼽힙니다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **조명 연산의 구조 및 복잡성:**
   MeshStandardMaterial의 조명 연산은 알베도(albedo), 노멀(normal), 금속성(metallic), 거칠기(roughness), 앰비언트 오클루전(AO) 등의 다양한 텍스처 맵과 환경 반사를 결합하여 이루어집니다 [1, 2]. 이 과정에서 화면에 보이는 픽셀(프래그먼트) 하나당 15~20개의 텍스처 샘플을 처리해야 하며, 수십 번의 복잡한 수학적 연산이 요구됩니다 [2].
-* **성능 병목 현상 및 프래그먼트 바운드([[Fragment-bound]]):**
-  연산이 매우 무겁기 때문에 수많은 객체가 화면에 겹쳐서 렌더링되는 오버드로우([[Overdraw]]) 현상이 발생할 경우, 중복된 조명 연산으로 인해 씬이 프래그먼트 바운드 상태에 빠지며 심각한 성능 저하를 유발합니다 [3]. 예를 들어 내장 그래픽(iGPU) 환경에서 이 재질을 사용해 100만 개 이상의 삼각형을 렌더링할 경우, 프래그먼트 프로세서가 포화되어 프레임 레이트가 30 이하로 급락할 수 있습니다 [1].
+* **성능 병목 현상 및 프래그먼트 바운드([[Fragment-bound|Fragment-bound]]):**
+  연산이 매우 무겁기 때문에 수많은 객체가 화면에 겹쳐서 렌더링되는 오버드로우([[Overdraw|Overdraw]]) 현상이 발생할 경우, 중복된 조명 연산으로 인해 씬이 프래그먼트 바운드 상태에 빠지며 심각한 성능 저하를 유발합니다 [3]. 예를 들어 내장 그래픽(iGPU) 환경에서 이 재질을 사용해 100만 개 이상의 삼각형을 렌더링할 경우, 프래그먼트 프로세서가 포화되어 프레임 레이트가 30 이하로 급락할 수 있습니다 [1].
 * **조명 연산 최적화 기법:**
   MeshStandardMaterial을 유지하면서 수백 개 이상의 다양한 객체를 최적화하여 그리기 위해, 각 객체의 재질 속성(색상, 방출, 거칠기, 금속성 등)을 하나의 데이터 텍스처에 패킹(packing)하는 기법이 활용될 수 있습니다 [4]. 이후 `onBeforeCompile`을 통해 셰이더가 기존 유니폼(Uniform) 대신 해당 텍스처의 값을 읽도록 수정하면, 동일한 셰이더를 공유하면서 단 한 번의 드로우 콜로 다양한 물리 기반 속성을 렌더링할 수 있습니다 [4].
 

10_Wiki/Topics/Graphics & Performance/Metal.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-939802
+id: [[P-Reinforce|P-Reinforce]]-AUTO-939802
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Metal"
 ---
 
-# [[Metal]]
+# [[Metal|Metal]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Metal은 주요 제조업체의 독점적인 차세대 네이티브 GPU API 중 하나입니다 [1]. [[Vulkan]], [[Direct3D]] 12(DX12)와 함께 노후화된 OpenGL 표준을 대체하는 웹용 차세대 그래픽 API인 [[WebGPU]]의 설계와 프로그래밍 모델에 직접적인 영감을 제공한 핵심 기술입니다 [1-3].
+> Metal은 주요 제조업체의 독점적인 차세대 네이티브 GPU API 중 하나입니다 [1]. [[Vulkan|Vulkan]], Direct3D 12(DX12)와 함께 노후화된 OpenGL 표준을 대체하는 웹용 차세대 그래픽 API인 [[WebGPU|WebGPU]]의 설계와 프로그래밍 모델에 직접적인 영감을 제공한 핵심 기술입니다 [1-3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **WebGPU 설계의 기반:** WebGPU는 노후화된 OpenGL 표준에 의존하지 않고, Metal을 비롯한 현대적인 네이티브 API(Vulkan, DX12 등)를 수용하도록 밑바닥부터 새롭게 설계되었습니다 [1-3].
-* **명시적(Explicit) 렌더링 접근법:** WebGPU는 Metal과 같은 현대 API들이 사용하는 명시적 접근 방식을 채택했습니다. 기존의 가변적인 전역 상태(global [[State]]) 모델 대신 불변하는 파이프라인 객체, 바인드 그룹(bind groups), 커맨드 버퍼를 사용하여 렌더링을 구성함으로써 드라이버 최적화를 극대화하고 버그를 줄입니다 [4].
-* **WebGPU 백엔드([[Backend]]) 어댑터:** [[Chrome]] 등의 브라우저에서 개발자 기능을 활성화한 후 WebGPU 어댑터 정보(`requestAdapterInfo()`)를 요청할 때, 실행을 담당하는 백엔드 중 하나로 "metal"이 식별되어 사용될 수 있습니다 [5].
+* **명시적(Explicit) 렌더링 접근법:** WebGPU는 Metal과 같은 현대 API들이 사용하는 명시적 접근 방식을 채택했습니다. 기존의 가변적인 전역 상태(global [[State|State]]) 모델 대신 불변하는 파이프라인 객체, 바인드 그룹(bind groups), 커맨드 버퍼를 사용하여 렌더링을 구성함으로써 드라이버 최적화를 극대화하고 버그를 줄입니다 [4].
+* **WebGPU 백엔드([[Backend|Backend]]) 어댑터:** [[Chrome|Chrome]] 등의 브라우저에서 개발자 기능을 활성화한 후 WebGPU 어댑터 정보(`requestAdapterInfo()`)를 요청할 때, 실행을 담당하는 백엔드 중 하나로 "metal"이 식별되어 사용될 수 있습니다 [5].
 * **성능 최적화 동향:** WebGPU의 지속적인 업데이트 과정에서 Metal 백엔드 환경을 위한 최적화가 이루어지고 있으며, 일례로 Chrome 130 릴리스에서는 Metal 상에서의 셰이더 컴파일 시간이 개선된 바 있습니다 [6].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,7 +23,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Metal"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Vulkan]], Direct3D 12 (DX12), OpenGL
+- **Related Topics:** [[WebGPU|WebGPU]], [[Vulkan|Vulkan]], Direct3D 12 (DX12), OpenGL
 - **Projects/Contexts:** WebGPU Backend
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 

10_Wiki/Topics/Graphics & Performance/Multi-threaded Architecture.md

@@ -1,27 +1,27 @@
 ---
-id: [[P-Reinforce]]-AUTO-4271F6
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4271F6
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-threaded [[Architecture]]"
+github_commit: "[P-Reinforce] Continuous Worker - Multi-threaded [[Architecture|Architecture]]"
 ---
 
-# [[Multi-threaded Architecture]]
+# [[Multi-threaded Architecture|Multi-threaded Architecture]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자바스크립트의 단일 스레드(Single-thread) 제약을 극복하기 위해 웹 워커(Web Worker)와 [[OffscreenCanvas]]를 활용하여 무거운 CPU 연산이나 3D 그래픽 렌더링을 백그라운드로 분리하고, 메인 스레드와 고효율로 상태를 동기화하여 매끄러운 반응성을 보장하는 진보된 애플리케이션 설계 패턴입니다.
+> 자바스크립트의 단일 스레드(Single-thread) 제약을 극복하기 위해 웹 워커(Web Worker)와 [[OffscreenCanvas|OffscreenCanvas]]를 활용하여 무거운 CPU 연산이나 3D 그래픽 렌더링을 백그라운드로 분리하고, 메인 스레드와 고효율로 상태를 동기화하여 매끄러운 반응성을 보장하는 진보된 애플리케이션 설계 패턴입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 **1. 멀티스레딩의 필요성과 Web Worker 분리** 자바스크립트는 기본적으로 단일 스레드 환경이므로 대규모 데이터 정렬, 이미지 처리, 물리 연산 등 무거운 작업을 수행하면 메인 스레드가 블로킹되어 UI가 멈추는 프리징(Freezing) 현상이 발생합니다. 이를 방지하기 위해 무거운 연산을 웹 워커(Web Worker)로 오프로딩(Offloading)하면, UI 상호작용은 메인 스레드에서 방해 없이 처리하고 연산은 백그라운드 스레드에서 병렬로 진행할 수 있습니다. React 앱에서는 `@koale/useworker`와 같은 훅 기반 라이브러리를 통해 워커 설정을 단순화하여 활용할 수 있습니다.
 
-**2. OffscreenCanvas와 [[WebGL]]/R3F 렌더링 분리** 복잡한 3D 씬을 다루는 WebGL 애플리케이션이나 Three.js/React Three Fiber(R3F) 환경의 경우 렌더링 연산 자체가 메인 스레드 자원을 크게 소모합니다. `OffscreenCanvas`를 사용하면 DOM과 Canvas API를 분리하여 캔버스의 제어권을 웹 워커로 넘길 수 있습니다. 이 구조에서는 렌더링과 DOM 조작이 물리적으로 분리되어 서로의 성능에 영향을 주지 않으며, 메인 스레드의 트래픽(과부하)과 무관하게 워커에서 부드러운 애니메이션을 독립적으로 유지할 수 있습니다.
+**2. OffscreenCanvas와 [[WebGL|WebGL]]/R3F 렌더링 분리** 복잡한 3D 씬을 다루는 WebGL 애플리케이션이나 Three.js/React Three Fiber(R3F) 환경의 경우 렌더링 연산 자체가 메인 스레드 자원을 크게 소모합니다. `OffscreenCanvas`를 사용하면 DOM과 Canvas API를 분리하여 캔버스의 제어권을 웹 워커로 넘길 수 있습니다. 이 구조에서는 렌더링과 DOM 조작이 물리적으로 분리되어 서로의 성능에 영향을 주지 않으며, 메인 스레드의 트래픽(과부하)과 무관하게 워커에서 부드러운 애니메이션을 독립적으로 유지할 수 있습니다.
 
-**3. 대리 인터랙션(Event Forwarding) 시스템** 웹 워커 내부에는 DOM이나 `window` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 메인 스레드에서 이벤트를 캡처한 뒤, 이벤트의 타입과 포인터 좌표 등 필수 데이터만 워커로 전달(`postMessage`)하여 워커 내부에서 상호작용 및 레이캐스팅([[Raycasting]])을 처리하도록 하는 이벤트 포워딩 파이프라인 구축이 필수적입니다.
+**3. 대리 인터랙션(Event Forwarding) 시스템** 웹 워커 내부에는 DOM이나 `window` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 메인 스레드에서 이벤트를 캡처한 뒤, 이벤트의 타입과 포인터 좌표 등 필수 데이터만 워커로 전달(`postMessage`)하여 워커 내부에서 상호작용 및 레이캐스팅([[Raycasting|Raycasting]])을 처리하도록 하는 이벤트 포워딩 파이프라인 구축이 필수적입니다.
 
-**4. 고효율 상태 동기화 ([[State]] Synchronization)** 메인 스레드(React DOM UI)와 워커(WebGL 씬 또는 연산 로직) 양쪽에서 동일한 앱 상태를 읽고 써야 하는 경우, 스레드 간 상태 동기화가 가장 큰 과제가 됩니다.
+**4. 고효율 상태 동기화 ([[State|State]] Synchronization)** 메인 스레드(React DOM UI)와 워커(WebGL 씬 또는 연산 로직) 양쪽에서 동일한 앱 상태를 읽고 써야 하는 경우, 스레드 간 상태 동기화가 가장 큰 과제가 됩니다.
 
-- **프록시 및 델타 동기화:** Valtio와 같은 프록시 기반 상태 관리 도구를 사용하여 로컬 저장소를 구축한 뒤, 상태가 변할 때마다 변경된 작업 내용([[Opera]]tions/Delta)만 `Broadcast Channel API`를 통해 상대 스레드에 전달하여 동기화합니다.
+- **프록시 및 델타 동기화:** Valtio와 같은 프록시 기반 상태 관리 도구를 사용하여 로컬 저장소를 구축한 뒤, 상태가 변할 때마다 변경된 작업 내용([[Opera|Opera]]tions/Delta)만 `Broadcast Channel API`를 통해 상대 스레드에 전달하여 동기화합니다.
 - **SharedArrayBuffer:** 지연 시간이 극도로 낮아야 하는 환경이나 ECS 기반의 게임에서는 두 스레드가 메모리를 직접 공유하는 `SharedArrayBuffer`를 사용하여 직렬화(Serialization) 및 복사 비용 없이 원자적(Atomic) 연산을 수행합니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -29,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Multi-threaded [[Architecture]
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker (웹 워커)]], [[OffscreenCanvas]], SharedArrayBuffer, 상태 관리 최적화 (Zustand, Jotai, Valtio)
+- **Related Topics:** [[Web Worker (웹 워커)|Web Worker (웹 워커]], [[OffscreenCanvas|OffscreenCanvas]], SharedArrayBuffer, 상태 관리 최적화 (Zustand, Jotai, Valtio)
 - **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처, 대규모 데이터 분석 및 시각화 대시보드
 - **Contradictions/Notes:** 멀티스레딩이 무조건적인 성능 향상을 가져오지는 않습니다. 메인 스레드와 워커 스레드 간에 데이터를 주고받는 과정(`postMessage`)에는 직렬화로 인한 오버헤드(약 5~10ms)가 수반됩니다. 따라서 연산 시간이 50ms 미만인 비교적 가벼운 작업을 워커로 분리하면, 통신 비용이 연산 시간보다 커져 오히려 전체 성능이 하락할 수 있으므로 철저한 프로파일링을 기반으로 병목 구간에만 도입해야 합니다.
 

10_Wiki/Topics/Graphics & Performance/Needle Engine.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-8D909B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8D909B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,16 +7,16 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Needle Engine"
 ---
 
-# [[Needle Engine]]
+# [[Needle Engine|Needle Engine]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Needle Engine은 3D 렌더링 및 웹 애플리케이션 개발을 지원하는 엔진이다 [1]. 동일한 객체(예: 나무)를 반복적으로 렌더링할 때 발생하는 드로우 콜 증가를 막기 위해 GPU 인스턴싱(GPU [[Instancing]]) 및 `[[InstancedMesh]]`를 활용한 최적화를 제공한다 [1, 2]. 내부적으로 인스턴싱 버퍼가 런타임에 동적으로 증가하면 성능 지연이 발생할 수 있으므로, 버퍼 사전 할당이나 프로그래밍 방식의 인스턴스 생성이 권장된다 [2, 3].
+> Needle Engine은 3D 렌더링 및 웹 애플리케이션 개발을 지원하는 엔진이다 [1]. 동일한 객체(예: 나무)를 반복적으로 렌더링할 때 발생하는 드로우 콜 증가를 막기 위해 GPU 인스턴싱(GPU [[Instancing|Instancing]]) 및 `[[InstancedMesh|InstancedMesh]]`를 활용한 최적화를 제공한다 [1, 2]. 내부적으로 인스턴싱 버퍼가 런타임에 동적으로 증가하면 성능 지연이 발생할 수 있으므로, 버퍼 사전 할당이나 프로그래밍 방식의 인스턴스 생성이 권장된다 [2, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **다중 인스턴스 처리와 드로우 콜 최적화**: 수많은 반복 객체를 렌더링할 때 씬에 개별 객체로 배치하면 엔진이 이를 독립적으로 처리하여 드로우 콜이 크게 증가한다 [1]. Needle Engine에서는 이를 해결하기 위해 명시적으로 GPU 인스턴싱을 사용하여 여러 객체를 하나의 인스턴싱 배치로 통합하는 방식을 취해야 한다 [1].
 - **동적 버퍼 확장 문제 및 대안**: 인스턴싱 시스템은 초기에 낮은 버퍼 용량으로 시작하며, 런타임에 인스턴스가 추가되어 버퍼가 동적으로 늘어날 경우(`[Instancing] Growing Buffer`) 성능 지연(Stall) 및 메모리 할당 오류가 발생할 수 있다 [3]. 이를 방지하려면 `RendererInstancing.d.ts.md` 소스의 `InstancingHandler.getStartInstanceCount`를 오버라이드하여, 엔진 시작 시 예상되는 최대 인스턴스 수만큼 버퍼를 미리 할당하는 방법이 권장된다 [3].
 - **프로그래밍 방식의 InstancedMesh 활용**: 외부 툴(예: 블렌더)에서 단일 에셋을 익스포트한 후, 코드 상에서 `InstancedMesh` 객체를 생성하여 프로그래밍 방식으로 런타임에 인스턴스화하면 버퍼의 동적 확장 문제를 피할 수 있다 [2].
-- **오버드로우([[Overdraw]]) 관리**: 인스턴싱을 적용하더라도 나뭇잎과 같은 투명한(Transparent) 재질을 겹쳐서 렌더링하면 오버드로우로 인해 렌더링 성능이 크게 저하될 수 있다 [4]. 이를 불투명(Opaque) 및 컷아웃(Cutout) 모드로 변경하면 프레임 속도를 대폭 개선할 수 있다 [5].
+- **오버드로우([[Overdraw|Overdraw]]) 관리**: 인스턴싱을 적용하더라도 나뭇잎과 같은 투명한(Transparent) 재질을 겹쳐서 렌더링하면 오버드로우로 인해 렌더링 성능이 크게 저하될 수 있다 [4]. 이를 불투명(Opaque) 및 컷아웃(Cutout) 모드로 변경하면 프레임 속도를 대폭 개선할 수 있다 [5].
 - **압축 환경에서의 버그 해결**: 프로덕션 빌드나 프리뷰 압축 적용 시 텍스처 누락이나 인스턴싱 렌더링 오류가 발생할 수 있으며, 이는 임포트 설정을 점검하거나 `@needle-tools/engine` 패키지(예: `3.19.11-beta.1`) 업데이트를 통해 해결할 수 있다 [2, 6, 7].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -24,7 +24,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Needle Engine"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** GPU Instancing, [[InstancedMesh]], [[Draw Call]], [[Overdraw]]
+- **Related Topics:** GPU Instancing, [[InstancedMesh|InstancedMesh]], Draw Call, [[Overdraw|Overdraw]]
 - **Projects/Contexts:** Needle Engine 다중 인스턴스(Multiple Instance) 렌더링 최적화 논의
 - **Contradictions/Notes:** Needle Engine 어시스턴트는 성능 지연 방지를 위해 `InstancingHandler.getStartInstanceCount`를 사용해 버퍼를 사전 할당할 것을 제안했지만, 실제 사용자는 이 방식이 매칭되는 모든 렌더러마다 해당 크기의 배열을 반복해서 할당하기 때문에 의도한 최적화 효과를 완전히 얻기 어렵다고 보고했다 [3, 8].
 

10_Wiki/Topics/Graphics & Performance/Object Pooling.md

@@ -1,21 +1,21 @@
 ---
-id: [[P-Reinforce]]-AUTO-18523F
+id: [[P-Reinforce|P-Reinforce]]-AUTO-18523F
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object [[Pooling]]"
+github_commit: "[P-Reinforce] Continuous Worker - Object [[Pooling|Pooling]]"
 ---
 
-# [[Object Pooling]]
+# [[Object Pooling|Object Pooling]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Object Pooling(오브젝트 풀링)은 총알, 파티클, 적 캐릭터와 같이 런타임 중 빈번하게 생성되고 파괴되는 개체들의 성능을 최적화하기 위해 사용되는 메모리 관리 기법입니다 [1]. 매번 새로운 객체를 메모리에 할당하는 대신, 사전에 생성해 둔 객체들의 풀(Pool)을 구축하여 이를 재사용하는 방식으로 동작합니다 [1]. 이를 통해 애플리케이션 실행 중 발생하는 메모리 할당 오버헤드와 가비지 컬렉션([[Garbage Collection]], GC)으로 인한 프레임 멈춤 현상을 효과적으로 방지할 수 있습니다 [1, 2]. 대규모 3D 씬과 동적인 렌더링 환경에서는 안정적인 메모리 제어와 누수 방지를 위해 객체 풀링 전략을 사전에 수립하는 것이 필수적입니다 [3, 4].
+> Object Pooling(오브젝트 풀링)은 총알, 파티클, 적 캐릭터와 같이 런타임 중 빈번하게 생성되고 파괴되는 개체들의 성능을 최적화하기 위해 사용되는 메모리 관리 기법입니다 [1]. 매번 새로운 객체를 메모리에 할당하는 대신, 사전에 생성해 둔 객체들의 풀(Pool)을 구축하여 이를 재사용하는 방식으로 동작합니다 [1]. 이를 통해 애플리케이션 실행 중 발생하는 메모리 할당 오버헤드와 가비지 컬렉션([[Garbage Collection|Garbage Collection]], GC)으로 인한 프레임 멈춤 현상을 효과적으로 방지할 수 있습니다 [1, 2]. 대규모 3D 씬과 동적인 렌더링 환경에서는 안정적인 메모리 제어와 누수 방지를 위해 객체 풀링 전략을 사전에 수립하는 것이 필수적입니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **가비지 컬렉션(GC) 부하 및 오버헤드 방지:** 객체의 지속적인 생성과 소멸은 가비지 컬렉터를 잦게 작동시켜 시스템에 부하를 줍니다. 객체 풀링을 도입하면 빈번하게 사용되는 리소스를 재사용하므로, 메모리 할당 오버헤드와 GC에 의한 일시 정지(Pauses)를 피할 수 있습니다 [1].
 - **프리워밍(Pre-warming) 전략:** 런타임에 객체를 할당할 때 생기는 갑작스러운 성능 저하(Allocation spike)를 피하기 위해, 애플리케이션 로딩 단계에서 풀을 미리 생성하고 데워두는(Pre-warm) 방식이 강력히 권장됩니다 [1].
-- **메모리 누수([[memory]] Leak) 관리:** Three.js와 같은 3D 그래픽스 환경에서 메모리 누수를 처리하는 핵심 지침 중 하나는, 수명이 짧고 빈번히 등장하는 리소스들에 대해 자원 풀링(Resource pooling)을 구현하여 메모리 할당을 통제하는 것입니다 [3].
+- **메모리 누수([[memory|memory]] Leak) 관리:** Three.js와 같은 3D 그래픽스 환경에서 메모리 누수를 처리하는 핵심 지침 중 하나는, 수명이 짧고 빈번히 등장하는 리소스들에 대해 자원 풀링(Resource pooling)을 구현하여 메모리 할당을 통제하는 것입니다 [3].
 - **메쉬 재활용(Recycling Meshes)을 통한 CPU 최적화:** 한 번에 너무 많은 메쉬를 처리해야 할 때, 논리적인 데이터 맵을 사용하여 객체의 상태를 추적하고, 화면에 보이는 객체만을 '사전 빌드된 메쉬 풀(pool of pre-built meshes)'을 이용해 렌더링함으로써 CPU 부담을 크게 낮출 수 있습니다 [2].
 - **대규모 메모리 대역폭 제어:** 동적인 환경에서 인스턴스 버퍼가 한계를 초과하여 재할당되는 일이 잦아지면 치명적인 GC 부하가 발생합니다. 이를 방지하기 위해 엄격한 메모리 예산 설정과 함께 객체 풀링 전략이 사전에 철저히 수립되어야 합니다 [4].
 
@@ -24,7 +24,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Object [[Pooling]]"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Garbage Collection]], [[Memory Leaks]]
+- **Related Topics:** [[Memory Management|Memory Management]], Garbage Collection, [[Memory Leaks|Memory Leaks]]
 - **Projects/Contexts:** Three.js, Babylon.js
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (주어진 소스 내에서 오브젝트 풀링의 효과나 방식에 대해 상충하는 의견은 존재하지 않으며, 모두 성능 최적화를 위해 적극적으로 권장하고 있습니다.)
 

10_Wiki/Topics/Graphics & Performance/OffscreenCanvas Safari 제약 사항.md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-600505
+id: [[P-Reinforce|P-Reinforce]]-AUTO-600505
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[OffscreenCanvas]] Safari 제약 사항"
+github_commit: "[P-Reinforce] Continuous Worker - [[OffscreenCanvas|OffscreenCanvas]] Safari 제약 사항"
 ---
 
-# [[OffscreenCanvas Safari 제약 사항]]
+# [[OffscreenCanvas Safari 제약 사항|OffscreenCanvas Safari 제약 사항]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Safari 브라우저에서는 `OffscreenCanvas`와 [[WebGL]]의 결합 사용이 아직 완전히 지원되지 않아, 워커 스레드와 메인 스레드용 렌더링 코드를 별도로 유지보수하거나 폴백(Fallback)을 구현해야 하는 치명적인 제약이 있습니다.
+> Safari 브라우저에서는 `OffscreenCanvas`와 [[WebGL|WebGL]]의 결합 사용이 아직 완전히 지원되지 않아, 워커 스레드와 메인 스레드용 렌더링 코드를 별도로 유지보수하거나 폴백(Fallback)을 구현해야 하는 치명적인 제약이 있습니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 **1. OffscreenCanvas와 WebGL 지원 부족** Safari 브라우저에서는 오프스크린 캔버스와 WebGL을 함께 사용하는 환경(`offscreen canvas + webgl`)이 아직 제대로 지원되지 않습니다. 이러한 한계 때문에 워커 내부에서 DOM과 통신(`postMessage`)해야 하는 복잡한 구조를 구현할 때 큰 제약이 따릅니다.
@@ -24,9 +24,9 @@ github_commit: "[P-Reinforce] Continuous Worker - [[OffscreenCanvas]] Safari 제
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[OffscreenCanvas]], [[Web Worker (웹 워커)]], [[React Three Fiber (R3F)]], Cross-[[Browser]] Compatibility (크로스 브라우저 호환성)
-- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처]], 실시간 3D 웹 게임 렌더링 환경
-- **Contradictions/Notes:** Safari 브라우저가 2025년 9월(v26)부터 [[WebGPU]] 지원을 시작하는 등 그래픽 지원 범위를 넓혀가고 있으나, `OffscreenCanvas`를 활용한 WebGL 멀티스레드 렌더링에 대해서는 여전히 제약이 보고되고 있으므로 프로덕션 환경에서는 반드시 메인 스레드용 `fallback` 컴포넌트를 제공해야 안정성을 보장할 수 있습니다.
+- **Related Topics:** [[OffscreenCanvas|OffscreenCanvas]], Web Worker (웹 워커), React Three Fiber (R3F), Cross-[[Browser|Browser]] Compatibility (크로스 브라우저 호환성)
+- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처|고성능 멀티스레드 React 앱 아키텍처]], 실시간 3D 웹 게임 렌더링 환경
+- **Contradictions/Notes:** Safari 브라우저가 2025년 9월(v26)부터 [[WebGPU|WebGPU]] 지원을 시작하는 등 그래픽 지원 범위를 넓혀가고 있으나, `OffscreenCanvas`를 활용한 WebGL 멀티스레드 렌더링에 대해서는 여전히 제약이 보고되고 있으므로 프로덕션 환경에서는 반드시 메인 스레드용 `fallback` 컴포넌트를 제공해야 안정성을 보장할 수 있습니다.
 
 ---
 

10_Wiki/Topics/Graphics & Performance/OffscreenCanvas.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-715F80
+id: [[P-Reinforce|P-Reinforce]]-AUTO-715F80
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,19 +7,19 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas"
 ---
 
-# [[OffscreenCanvas]]
+# [[OffscreenCanvas|OffscreenCanvas]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > **OffscreenCanvas**는 DOM과 분리된 백그라운드 스레드(웹 워커)에서 그래픽 렌더링을 수행할 수 있게 해주는 웹 API로, 무거운 3D 렌더링이나 캔버스 연산 중에도 메인 스레드의 UI 반응성을 쾌적하게 유지할 수 있도록 돕는 핵심 최적화 기술입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-**1. DOM 의존성 분리 및 Web Worker 활용** 기존의 캔버스 렌더링은 `<html>` 문서의 `<canvas>` 요소(DOM)와 직접적으로 결합되어 있어 메인 스레드에서만 실행이 가능했습니다. 하지만 OffscreenCanvas는 이름 그대로 화면 밖(Off-screen)에서 동작하여 DOM과의 동기화 과정을 생략합니다. 이 덕분에 DOM에 접근할 수 없는 웹 워커(Web Worker) 환경에서도 Canvas API와 [[WebGL]]을 사용하여 백그라운드 렌더링이 가능해집니다.
+**1. DOM 의존성 분리 및 Web Worker 활용** 기존의 캔버스 렌더링은 `<html>` 문서의 `<canvas>` 요소(DOM)와 직접적으로 결합되어 있어 메인 스레드에서만 실행이 가능했습니다. 하지만 OffscreenCanvas는 이름 그대로 화면 밖(Off-screen)에서 동작하여 DOM과의 동기화 과정을 생략합니다. 이 덕분에 DOM에 접근할 수 없는 웹 워커(Web Worker) 환경에서도 Canvas API와 [[WebGL|WebGL]]을 사용하여 백그라운드 렌더링이 가능해집니다.
 
-**2. 메인 스레드 차단 방지 (Un[[Blocking]] [[Main Thread]])** 복잡한 Three.js 씬이나 무거운 2D/3D 연산을 메인 스레드에서 실행하면 UI가 멈추는(Freezing) 현상이 발생할 수 있습니다. `transferControlToOffscreen()` 메서드를 호출하여 캔버스의 제어권을 워커 스레드로 넘기면(Offloading), 무거운 그래픽 연산이 메인 스레드(사용자의 스크롤, 클릭 등 상호작용)와 독립적으로 실행되어 시각적인 버벅거림(Jank) 없이 부드러운 애니메이션을 보장합니다.
+**2. 메인 스레드 차단 방지 (Un[[Blocking|Blocking]] [[Main Thread|Main Thread]])** 복잡한 Three.js 씬이나 무거운 2D/3D 연산을 메인 스레드에서 실행하면 UI가 멈추는(Freezing) 현상이 발생할 수 있습니다. `transferControlToOffscreen()` 메서드를 호출하여 캔버스의 제어권을 워커 스레드로 넘기면(Offloading), 무거운 그래픽 연산이 메인 스레드(사용자의 스크롤, 클릭 등 상호작용)와 독립적으로 실행되어 시각적인 버벅거림(Jank) 없이 부드러운 애니메이션을 보장합니다.
 
 **3. 이벤트 포워딩(Event Forwarding)과 통신 오버헤드** 웹 워커 내부에는 `window`나 `document` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 OffscreenCanvas를 인터랙티브하게 사용하려면 메인 스레드에서 DOM 이벤트를 캡처한 뒤, 좌표 등의 정보를 `postMessage` API를 통해 워커로 전달(Forwarding)하는 추가적인 래핑(Wrapping) 작업이 필요합니다.
 
-**4. 상태 동기화 ([[State]] Synchronization)** DOM을 제어하는 React 메인 앱과 WebGL을 렌더링하는 워커 스레드는 메모리를 공유하지 않기 때문에 애플리케이션 상태를 양쪽에서 읽고 써야 할 경우 상태 동기화가 필수적입니다. 이를 해결하기 위해 `SharedArrayBuffer`를 통해 메모리를 직접 공유하거나, `Valtio`와 같은 프록시 기반 상태 관리 도구와 `Broadcast Channel API`를 결합하여 변경된 데이터(Delta)만 메시지로 주고받는 구조를 구현해야 합니다.
+**4. 상태 동기화 ([[State|State]] Synchronization)** DOM을 제어하는 React 메인 앱과 WebGL을 렌더링하는 워커 스레드는 메모리를 공유하지 않기 때문에 애플리케이션 상태를 양쪽에서 읽고 써야 할 경우 상태 동기화가 필수적입니다. 이를 해결하기 위해 `SharedArrayBuffer`를 통해 메모리를 직접 공유하거나, `Valtio`와 같은 프록시 기반 상태 관리 도구와 `Broadcast Channel API`를 결합하여 변경된 데이터(Delta)만 메시지로 주고받는 구조를 구현해야 합니다.
 
 **5. React 생태계 통합 (React Three Fiber)** R3F 생태계에서는 `@react-three/offscreen` 패키지를 통해 손쉽게 구현할 수 있습니다. 기존의 `<Canvas>` 대신 이 패키지의 `<Canvas worker={worker}>`를 사용하면 이벤트 포워딩과 Three.js 인터페이스 패치 작업이 자동으로 처리되어, 개발자가 작성한 코드를 수정할 필요 없이 워커에서 실행되도록 만들어줍니다.
 
@@ -28,8 +28,8 @@ github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker (웹 워커)]], [[Multi-threaded Architecture]] (멀티스레드 아키텍처), [[React Three Fiber (R3F)]], Valtio (Proxy State 관리), SharedArrayBuffer
-- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처]], 무거운 렌더링 연산을 동반하는 WebGL 데이터 시각화
+- **Related Topics:** [[Web Worker (웹 워커)|Web Worker (웹 워커]], Multi-threaded Architecture (멀티스레드 아키텍처), [[React Three Fiber (R3F)|React Three Fiber (R3F]], Valtio (Proxy State 관리), SharedArrayBuffer
+- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처|고성능 멀티스레드 React 앱 아키텍처]], 무거운 렌더링 연산을 동반하는 WebGL 데이터 시각화
 - **Contradictions/Notes:** OffscreenCanvas 기능은 과거 Safari 브라우저에서 오랫동안 완벽히 지원되지 않아 프로젝트를 메인 스레드용과 워커용 두 갈래(Fork)로 유지보수해야 하는 치명적인 단점이 있었습니다. 2025년 9월(Safari v26)부터 지원이 확대되었으나, 완벽한 크로스 브라우저 호환성을 위해서는 API 지원 여부를 감지하여 워커를 지원하지 않는 환경에서는 메인 스레드에서 렌더링이 이루어지도록 `fallback` 컴포넌트를 반드시 제공해야 합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/OpenGL ES 20.md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-8560F5
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8560F5
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[OpenGL ES]] 20"
+github_commit: "[P-Reinforce] Continuous Worker - [[OpenGL ES|OpenGL ES]] 20"
 ---
 
-# [[OpenGL ES 20]]
+# [[OpenGL ES 20|OpenGL ES 20]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> OpenGL ES 2.0은 2011년에 도입된 크로스 플랫폼 웹 그래픽 라이브러리인 [[WebGL]]의 근간이 되는 그래픽 API입니다 [1, 2]. 이 아키텍처는 전역 그래픽 상태를 설정하고 유지하는 상태 머신([[State]]-machine) 설계를 사용하며, 자바스크립트 코드를 GPU 명령으로 변환하는 역할을 수행합니다 [2, 3].
+> OpenGL ES 2.0은 2011년에 도입된 크로스 플랫폼 웹 그래픽 라이브러리인 [[WebGL|WebGL]]의 근간이 되는 그래픽 API입니다 [1, 2]. 이 아키텍처는 전역 그래픽 상태를 설정하고 유지하는 상태 머신([[State|State]]-machine) 설계를 사용하며, 자바스크립트 코드를 GPU 명령으로 변환하는 역할을 수행합니다 [2, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **WebGL의 핵심 기반:** WebGL은 OpenGL ES 2.0을 기반으로 구축되어, 웹 브라우저에서 자바스크립트를 이용해 3D 장면을 렌더링할 수 있도록 지원하는 라이브러리입니다 [1, 2].
@@ -22,7 +22,7 @@ github_commit: "[P-Reinforce] Continuous Worker - [[OpenGL ES]] 20"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], State-machine design
+- **Related Topics:** [[WebGL|WebGL]], [[WebGPU|WebGPU]], State-machine design
 - **Projects/Contexts:** Web Graphics Rendering API, 3D Web-based HMI
 - **Contradictions/Notes:** 소스 내에 직접적인 모순은 없으나, OpenGL ES 2.0 기반의 상태 머신 모델이 개발 초기(2011년)에는 타당한 설계였음에도 불구하고 오늘날의 대규모 그래픽 처리에서는 심각한 버그와 병목 현상의 원인이 되고 있음이 지적됩니다 [3, 4].
 

10_Wiki/Topics/Graphics & Performance/OpenGL ES.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-D76AA6
+id: [[P-Reinforce|P-Reinforce]]-AUTO-D76AA6
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,23 +7,23 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - OpenGL ES"
 ---
 
-# [[OpenGL ES]]
+# [[OpenGL ES|OpenGL ES]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> OpenGL ES(특히 OpenGL ES 2.0)는 웹 기반 3D 렌더링을 지원하는 크로스 플랫폼 그래픽 라이브러리인 [[WebGL]]의 기반이 되는 그래픽 API입니다 [1, 2]. 텍스처나 셰이더 등의 전역 상태가 한 번 설정되면 변경될 때까지 유지되는 상태 머신([[State]]-machine) 디자인을 채택하고 있습니다 [3]. 2011년경의 사양에 고정되어 있어, 최신 GPU의 고급 기능을 활용하기에는 아키텍처상 근본적인 한계를 지니고 있습니다 [3, 4].
+> OpenGL ES(특히 OpenGL ES 2.0)는 웹 기반 3D 렌더링을 지원하는 크로스 플랫폼 그래픽 라이브러리인 [[WebGL|WebGL]]의 기반이 되는 그래픽 API입니다 [1, 2]. 텍스처나 셰이더 등의 전역 상태가 한 번 설정되면 변경될 때까지 유지되는 상태 머신([[State|State]]-machine) 디자인을 채택하고 있습니다 [3]. 2011년경의 사양에 고정되어 있어, 최신 GPU의 고급 기능을 활용하기에는 아키텍처상 근본적인 한계를 지니고 있습니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **WebGL의 기술적 토대:** WebGL은 OpenGL ES 2.0을 기반으로 구축되어 [[JavaScript]] 코드를 GPU 명령어로 변환하며, 지난 10년 이상 웹 3D 렌더링의 핵심 역할을 수행해 왔습니다 [1, 2].
-- **작동 방식과 호환성:** OpenGL ES 2.0에서 상속받은 상태 머신(State-machine) 모델을 사용하여 렌더링 상태를 관리합니다 [3]. Windows 환경의 브라우저([[Chrome]], Firefox, [[Opera]] 등)는 [[ANGLE]]이라는 기술을 사용하여 WebGL(OpenGL ES) 호출을 [[Direct3D]]로 변환하는 방식으로 구동됩니다 [5].
-- **구조적 한계:** WebGL이 OpenGL ES 2.0을 기반으로 설계된 탓에, 기능 세트가 2011년 사양에 묶여 있는 근본적인 한계가 존재합니다 [4]. 이로 인해 최신 GPU의 컴퓨트 셰이더([[Compute Shader]])나 고급 텍스처 포맷 등을 활용할 수 없으며, 규모가 커질수록 전역 상태 관리로 인한 미묘한 버그나 CPU 병목 현상이 발생하기 쉽습니다 [3, 4].
-- **최신 브라우저 동향:** Chrome 146 등의 최신 업데이트에서는 [[WebGPU]]가 OpenGL ES 3.1 위에서 호환 모드(compatibility mode)로 동작할 수 있도록 지원하는 기능이 추가되고 있습니다 [6].
+- **WebGL의 기술적 토대:** WebGL은 OpenGL ES 2.0을 기반으로 구축되어 [[JavaScript|JavaScript]] 코드를 GPU 명령어로 변환하며, 지난 10년 이상 웹 3D 렌더링의 핵심 역할을 수행해 왔습니다 [1, 2].
+- **작동 방식과 호환성:** OpenGL ES 2.0에서 상속받은 상태 머신(State-machine) 모델을 사용하여 렌더링 상태를 관리합니다 [3]. Windows 환경의 브라우저([[Chrome|Chrome]], Firefox, Opera 등)는 ANGLE이라는 기술을 사용하여 WebGL(OpenGL ES) 호출을 [[Direct3D|Direct3D]]로 변환하는 방식으로 구동됩니다 [5].
+- **구조적 한계:** WebGL이 OpenGL ES 2.0을 기반으로 설계된 탓에, 기능 세트가 2011년 사양에 묶여 있는 근본적인 한계가 존재합니다 [4]. 이로 인해 최신 GPU의 컴퓨트 셰이더([[Compute Shader|Compute Shader]])나 고급 텍스처 포맷 등을 활용할 수 없으며, 규모가 커질수록 전역 상태 관리로 인한 미묘한 버그나 CPU 병목 현상이 발생하기 쉽습니다 [3, 4].
+- **최신 브라우저 동향:** Chrome 146 등의 최신 업데이트에서는 [[WebGPU|WebGPU]]가 OpenGL ES 3.1 위에서 호환 모드(compatibility mode)로 동작할 수 있도록 지원하는 기능이 추가되고 있습니다 [6].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]]
+- **Related Topics:** [[WebGL|WebGL]], WebGPU, [[ANGLE|ANGLE]]
 - **Projects/Contexts:** 3D Web-based HMI
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 

10_Wiki/Topics/Graphics & Performance/Opera.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-71E521
+id: [[P-Reinforce|P-Reinforce]]-AUTO-71E521
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Opera"
 ---
 
-# [[Opera]]
+# [[Opera|Opera]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Opera는 웹 환경에서 그래픽 및 렌더링 기술을 구동하기 위해 사용되는 웹 브라우저 중 하나입니다. 업로드된 소스에서는 브라우저의 독립적인 특징보다는 [[WebGL]] 및 [[WebGPU]]와 같은 웹 그래픽 API의 호환성 및 지원 여부를 설명할 때 제한적으로만 언급됩니다. 전반적으로 Opera에 초점을 맞춘 상세한 설명은 존재하지 않으므로 소스에 관련 정보가 부족합니다.
+> Opera는 웹 환경에서 그래픽 및 렌더링 기술을 구동하기 위해 사용되는 웹 브라우저 중 하나입니다. 업로드된 소스에서는 브라우저의 독립적인 특징보다는 [[WebGL|WebGL]] 및 [[WebGPU|WebGPU]]와 같은 웹 그래픽 API의 호환성 및 지원 여부를 설명할 때 제한적으로만 언급됩니다. 전반적으로 Opera에 초점을 맞춘 상세한 설명은 존재하지 않으므로 소스에 관련 정보가 부족합니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **[[ANGLE]]을 통한 WebGL 변환:** Windows 운영 체제 환경에서 Opera 브라우저는 [[Chrome]], Firefox와 마찬가지로 WebGL([[OpenGL ES]]) 호출을 [[Direct3D]]로 변환하기 위해 ANGLE 기술을 사용합니다 [1].
+* **[[ANGLE|ANGLE]]을 통한 WebGL 변환:** Windows 운영 체제 환경에서 Opera 브라우저는 Chrome, Firefox와 마찬가지로 WebGL(OpenGL ES) 호출을 [[Direct3D|Direct3D]]로 변환하기 위해 ANGLE 기술을 사용합니다 [1].
 * **WebGPU 지원 현황:** 2026년 1월 기준으로, Opera는 Chrome, Edge 브라우저와 함께 데스크톱 플랫폼 전반에서 차세대 그래픽 API인 WebGPU를 공식적으로 탑재하여(ship) 지원하고 있습니다 [2].
-* **`EXT_disjoint_timer_query` 확장 기능 호환성:** WebGL 렌더링 파이프라인을 지연시키지 않고 GL 명령의 실행 시간을 측정하는 `EXT_disjoint_timer_query` 기능에 대해, 데스크톱용 Opera(버전 57 이상)는 부분적인 지원(Partial [[Support]])을 제공합니다 [3, 4]. 그러나 모바일 환경인 Opera Android(버전 34-46)에서는 해당 기능을 지원하지 않는 것으로 확인됩니다 [4].
+* **`EXT_disjoint_timer_query` 확장 기능 호환성:** WebGL 렌더링 파이프라인을 지연시키지 않고 GL 명령의 실행 시간을 측정하는 `EXT_disjoint_timer_query` 기능에 대해, 데스크톱용 Opera(버전 57 이상)는 부분적인 지원(Partial [[Support|Support]])을 제공합니다 [3, 4]. 그러나 모바일 환경인 Opera Android(버전 34-46)에서는 해당 기능을 지원하지 않는 것으로 확인됩니다 [4].
 * **한계:** Opera 브라우저의 전반적인 아키텍처나 기능에 대해서는 소스에 관련 정보가 부족합니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Opera"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]]
-- **Projects/Contexts:** [[웹 브라우저 그래픽 API 호환성]]
+- **Related Topics:** [[WebGL|WebGL]], WebGPU, [[ANGLE|ANGLE]]
+- **Projects/Contexts:** [[웹 브라우저 그래픽 API 호환성|웹 브라우저 그래픽 API 호환성]]
 - **Contradictions/Notes:** 데스크톱 Opera는 특정 WebGL 확장 기능(`EXT_disjoint_timer_query`)을 부분적으로나마 지원하지만, 모바일(Android) 버전의 Opera에서는 해당 기능이 전혀 지원되지 않는 등 플랫폼에 따른 지원 격차가 존재합니다 [4].
 
 ---

10_Wiki/Topics/Graphics & Performance/PBR.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-773FEF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-773FEF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - PBR"
 ---
 
-# [[PBR]]
+# [[PBR|PBR]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> PBR(Physically-Based Rendering)은 현실 세계의 물질 물리 법칙을 적용하여 사실적인 시각 효과를 달성하는 렌더링 방법론입니다 [1]. 알베도(albedo), 노멀(normal), 메탈릭([[Metal]]lic), 러프니스(roughness), 앰비언트 오클루전(ambient occlusion) 등의 다중 텍스처 맵을 조합하여 표면 속성을 세밀하게 정의합니다 [2]. 사실감을 표현하는 최신 표준 기술이지만, 에너지 보존 법칙과 프레넬(Fresnel) 반사 등의 복잡한 계산을 수반하기 때문에 그래픽 연산 비용이 매우 높다는 특징이 있습니다 [3].
+> PBR(Physically-Based Rendering)은 현실 세계의 물질 물리 법칙을 적용하여 사실적인 시각 효과를 달성하는 렌더링 방법론입니다 [1]. 알베도(albedo), 노멀(normal), 메탈릭([[Metal|Metal]]lic), 러프니스(roughness), 앰비언트 오클루전(ambient occlusion) 등의 다중 텍스처 맵을 조합하여 표면 속성을 세밀하게 정의합니다 [2]. 사실감을 표현하는 최신 표준 기술이지만, 에너지 보존 법칙과 프레넬(Fresnel) 반사 등의 복잡한 계산을 수반하기 때문에 그래픽 연산 비용이 매우 높다는 특징이 있습니다 [3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **물리 기반 속성 정의와 워크플로우:** 

10_Wiki/Topics/Graphics & Performance/Radix Sort.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-846BA8
+id: [[P-Reinforce|P-Reinforce]]-AUTO-846BA8
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Radix Sort"
 ---
 
-# [[Radix Sort]]
+# [[Radix Sort|Radix Sort]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Radix Sort(기수 정렬)는 대규모 데이터 세트를 처리할 때 매우 높은 효율을 낼 수 있는 복잡한 정렬 알고리즘입니다 [1]. Three.js의 `BatchedMesh`에서 겹치는 인스턴스의 렌더링 순서(Depth [[Sorting]])를 해결하기 위해 사용된 적이 있으나 단순성을 위해 대체되었으며, 현재는 확장 라이브러리인 `[[InstancedMesh2]]`의 예제 등에서 활용되고 있습니다 [1, 2].
+> Radix Sort(기수 정렬)는 대규모 데이터 세트를 처리할 때 매우 높은 효율을 낼 수 있는 복잡한 정렬 알고리즘입니다 [1]. Three.js의 `BatchedMesh`에서 겹치는 인스턴스의 렌더링 순서(Depth [[Sorting|Sorting]])를 해결하기 위해 사용된 적이 있으나 단순성을 위해 대체되었으며, 현재는 확장 라이브러리인 `[[InstancedMesh2|InstancedMesh2]]`의 예제 등에서 활용되고 있습니다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **성능 이점:** 대규모 데이터 세트를 정렬해야 하는 상황에서 다른 정렬 방식에 비해 최대 7배가량 빠른 성능을 제공할 수 있습니다 [1].
 - **Three.js 생태계에서의 활용 및 제외:** `BatchedMesh`는 여러 인스턴스가 겹칠 때 발생할 수 있는 시각적 오류를 방지하고자 심도 정렬(Depth sorting)을 구현하는 데 Radix Sort 알고리즘을 사용했습니다 [1, 2]. 하지만 코드 구현의 단순성을 위해 현재는 이보다 간단한 알고리즘으로 대체되었습니다 [1].
-- **[[InstancedMesh]]2에서의 제공:** 공식 `BatchedMesh`에서는 제외되었으나, 이를 기반으로 개발된 `InstancedMesh2` 라이브러리에서는 여전히 Radix Sort를 활용한 인스턴스 정렬 예제를 제공하고 있습니다 [1].
+- **[[InstancedMesh|InstancedMesh]]2에서의 제공:** 공식 `BatchedMesh`에서는 제외되었으나, 이를 기반으로 개발된 `InstancedMesh2` 라이브러리에서는 여전히 Radix Sort를 활용한 인스턴스 정렬 예제를 제공하고 있습니다 [1].
 - **한계:** Radix Sort 알고리즘 고유의 구체적인 동작 방식이나 기술적 메커니즘에 대해서는 소스에 관련 정보가 부족합니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,7 +23,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Radix Sort"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** BatchedMesh, [[InstancedMesh2]]
+- **Related Topics:** BatchedMesh, [[InstancedMesh2|InstancedMesh2]]
 - **Projects/Contexts:** Three.js, Depth Sorting
 - **Contradictions/Notes:** Radix Sort는 대규모 데이터에서 7배 빠른 성능을 제공하는 훌륭한 장점이 있음에도 불구하고, 공식 `BatchedMesh`에서는 라이브러리 내부 구조의 단순성(simplicity)을 유지하기 위해 제거되었다는 특징이 있습니다 [1]. 그 외 알고리즘 작동 원리에 대해서는 소스에 관련 정보가 부족합니다.
 

10_Wiki/Topics/Graphics & Performance/Raycaster.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-D7A57A
+id: [[P-Reinforce|P-Reinforce]]-AUTO-D7A57A
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,25 +7,25 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Raycaster"
 ---
 
-# [[Raycaster]]
+# [[Raycaster|Raycaster]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > Raycaster(레이캐스터)는 가상의 광선(Ray)과 3D 장면 내 객체 간의 교차점을 계산하여 충돌을 감지하는 기법이자 Three.js의 핵심 클래스(`THREE.Raycaster`)입니다 [1-3]. 주로 마우스 클릭과 같은 사용자 상호작용(오브젝트 피킹)을 구현하여 카메라 시점이나 특정 위치에서 어떤 객체가 선택되었는지 판별하는 데 필수적으로 사용됩니다 [4-6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **동작 원리 및 사용법:** Raycaster는 시작점과 방향을 명시적으로 지정하거나(`raycaster.set`), 화면의 픽셀 좌표와 카메라를 기준으로 광선을 설정(`raycaster.setFromCamera`)하여 작동합니다 [3, 5]. 이후 `intersectObjects` 메서드를 통해 광선과 교차하는 대상들을 거리가 가까운 순서대로 정렬된 배열 형태로 반환받을 수 있으며, 반환된 데이터에는 교차한 객체(`.object`)와 월드 좌표계 기준의 교차점(`.point`) 정보가 포함됩니다 [6, 7].
-- **[[InstancedMesh]] 적용 시의 한계와 병목:** 일반적인 메쉬의 레이캐스팅은 CPU 단에서 수행되는데, `InstancedMesh`의 경우 수많은 인스턴스의 변환 행렬을 CPU가 개별적으로 역산하여 교차 여부를 판별해야 하므로 인스턴스 수에 비례하여 막대한 연산 병목이 발생합니다 [8]. 특히 애니메이션이나 기하학적 변환이 GPU 셰이더 내에서만 연산된 경우, CPU 레이캐스터는 변환된 위치를 알지 못해 객체의 초기 위치만 검사하게 되며 이는 피킹 불가능 상태인 '데이터 불일치'를 유발합니다 [8, 9].
-- **인스턴스 변환 시 바운딩 볼륨 업데이트:** Three.js r151 버전 이후부터 `InstancedMesh`는 바운딩 볼륨 연산을 지원합니다 [10]. 런타임에 인스턴스의 위치나 형태를 변환한 후 레이캐스팅이 정상적으로 작동하게 하려면, `computeBoundingSphere()` 및 `computeBoundingBox()`를 반드시 호출해야 합니다 [10-12]. 레이캐스터가 연산 최적화를 위해 바운딩 볼륨을 이용한 빠른 사전 테스트(early-out [[Testing]])를 거치기 때문입니다 [12].
-- **성능 최적화 (BVH 도입):** 80,000개 이상의 다각형을 갖는 복잡한 장면이나 잦은 레이캐스팅이 필요한 환경에서는 기본 Raycaster만으로는 성능을 보장하기 어렵습니다 [13, 14]. 이를 해결하기 위해 공간 분할 트리 알고리즘을 구현한 `[[three-mesh-bvh]]` 라이브러리를 사용하면 레이캐스팅 속도를 비약적으로 향상시킬 수 있으며, 확장 라이브러리인 `[[InstancedMesh2]]`도 빠른 레이캐스팅을 위해 BVH를 적극적으로 활용합니다 [13, 15-17].
+- **[[InstancedMesh|InstancedMesh]] 적용 시의 한계와 병목:** 일반적인 메쉬의 레이캐스팅은 CPU 단에서 수행되는데, `InstancedMesh`의 경우 수많은 인스턴스의 변환 행렬을 CPU가 개별적으로 역산하여 교차 여부를 판별해야 하므로 인스턴스 수에 비례하여 막대한 연산 병목이 발생합니다 [8]. 특히 애니메이션이나 기하학적 변환이 GPU 셰이더 내에서만 연산된 경우, CPU 레이캐스터는 변환된 위치를 알지 못해 객체의 초기 위치만 검사하게 되며 이는 피킹 불가능 상태인 '데이터 불일치'를 유발합니다 [8, 9].
+- **인스턴스 변환 시 바운딩 볼륨 업데이트:** Three.js r151 버전 이후부터 `InstancedMesh`는 바운딩 볼륨 연산을 지원합니다 [10]. 런타임에 인스턴스의 위치나 형태를 변환한 후 레이캐스팅이 정상적으로 작동하게 하려면, `computeBoundingSphere()` 및 `computeBoundingBox()`를 반드시 호출해야 합니다 [10-12]. 레이캐스터가 연산 최적화를 위해 바운딩 볼륨을 이용한 빠른 사전 테스트(early-out [[Testing|Testing]])를 거치기 때문입니다 [12].
+- **성능 최적화 (BVH 도입):** 80,000개 이상의 다각형을 갖는 복잡한 장면이나 잦은 레이캐스팅이 필요한 환경에서는 기본 Raycaster만으로는 성능을 보장하기 어렵습니다 [13, 14]. 이를 해결하기 위해 공간 분할 트리 알고리즘을 구현한 `[[three-mesh-bvh|three-mesh-bvh]]` 라이브러리를 사용하면 레이캐스팅 속도를 비약적으로 향상시킬 수 있으며, 확장 라이브러리인 `[[InstancedMesh2|InstancedMesh2]]`도 빠른 레이캐스팅을 위해 BVH를 적극적으로 활용합니다 [13, 15-17].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Three.js, [[InstancedMesh]], [[three-mesh-bvh]], Bounding Volume
-- **Projects/Contexts:** 3D Object Picking, Interaction in [[WebGL]]
-- **Contradictions/Notes:** 소스에 따르면 레이캐스팅은 CPU 기반 연산이므로, GPU 셰이더([[Compute Shader]] 등)를 통해 동적으로 애니메이션 처리된 기하학적 구조에 대해서는 CPU가 변환을 알지 못해 기본 레이캐스터로 올바른 피킹을 수행할 수 없습니다 [8, 9].
+- **Related Topics:** Three.js, [[InstancedMesh|InstancedMesh]], [[three-mesh-bvh|three-mesh-bvh]], Bounding Volume
+- **Projects/Contexts:** 3D Object Picking, Interaction in [[WebGL|WebGL]]
+- **Contradictions/Notes:** 소스에 따르면 레이캐스팅은 CPU 기반 연산이므로, GPU 셰이더([[Compute Shader|Compute Shader]] 등)를 통해 동적으로 애니메이션 처리된 기하학적 구조에 대해서는 CPU가 변환을 알지 못해 기본 레이캐스터로 올바른 피킹을 수행할 수 없습니다 [8, 9].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Raycasting.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-BD8B44
+id: [[P-Reinforce|P-Reinforce]]-AUTO-BD8B44
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
 ---
 
-# [[Raycasting]]
+# [[Raycasting|Raycasting]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Raycasting(레이캐스팅)은 가상의 광선(Ray)과 3D 환경 내 객체들 간의 교차점을 감지하는 계산 기법입니다 [1, 2]. 3D 씬 내에서 사용자가 화면을 클릭하여 특정 객체를 선택(Picking)하거나 드래그하는 등의 사용자 상호작용(Interaction)을 구현할 때 필수적으로 사용됩니다 [3-5]. Three.js 환경에서는 `THREE.[[Raycaster]]` 클래스를 통해 이 기능을 수행할 수 있습니다 [2, 3].
+> Raycasting(레이캐스팅)은 가상의 광선(Ray)과 3D 환경 내 객체들 간의 교차점을 감지하는 계산 기법입니다 [1, 2]. 3D 씬 내에서 사용자가 화면을 클릭하여 특정 객체를 선택(Picking)하거나 드래그하는 등의 사용자 상호작용(Interaction)을 구현할 때 필수적으로 사용됩니다 [3-5]. Three.js 환경에서는 `THREE.[[Raycaster|Raycaster]]` 클래스를 통해 이 기능을 수행할 수 있습니다 [2, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **기본 작동 원리**
@@ -18,8 +18,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
     *   `intersectObjects` 메서드를 호출하면 광선과 교차하는 객체들의 배열을 거리순으로 반환합니다. 반환된 항목에는 교차된 대상 객체(`item.object`)와 세계 좌표계 기준의 정확한 교차 지점(`item.point`) 정보가 포함됩니다 [7-10].
 *   **성능 최적화 기법 (BVH 도입)**
     *   복잡한 지오메트리를 상대로 반복적인 레이캐스팅을 수행하면 성능 저하가 발생할 수 있습니다. 
-    *   이를 해결하기 위해 공간 분할 구조인 `[[three-mesh-bvh]]`(Bounding Volume Hierarchy) 라이브러리를 활용하면, 80,000개 이상의 폴리곤에 대해서도 60fps로 매우 빠른 레이캐스팅(Fast Raycasting) 쿼리를 수행할 수 있습니다 [11-13].
-*   **[[InstancedMesh]] 환경에서의 제약 및 고려사항**
+    *   이를 해결하기 위해 공간 분할 구조인 `[[three-mesh-bvh|three-mesh-bvh]]`(Bounding Volume Hierarchy) 라이브러리를 활용하면, 80,000개 이상의 폴리곤에 대해서도 60fps로 매우 빠른 레이캐스팅(Fast Raycasting) 쿼리를 수행할 수 있습니다 [11-13].
+*   **[[InstancedMesh|InstancedMesh]] 환경에서의 제약 및 고려사항**
     *   `InstancedMesh`는 네이티브 레이캐스터를 지원하지만, 초기에는 모든 인스턴스 멤버의 모든 삼각형을 검사해야 하여 성능상 한계가 있었습니다 [14, 15]. 
     *   Three.js r151 버전 이후부터는 바운딩 볼륨(Bounding Volume)을 통한 빠른 조기 종료(Early-out) 테스트를 지원하여 속도가 개선되었습니다 [16, 17]. 그러나 인스턴스를 이동시키는 등 변환이 발생한 후에는 반드시 `computeBoundingSphere()`와 `computeBoundingBox()`를 수동으로 재계산해주어야 레이캐스팅이 정상 작동합니다 [16, 18].
     *   일부 커스텀 구현(예: A-Frame용 컴포넌트)에서는 유연성과 성능 확보를 위해 `InstancedMesh` 자체에 대한 직접적인 레이캐스팅 대신, 동일한 형태의 보이지 않는 메시(Invisible Mesh)를 멤버별로 생성하여 레이캐스팅의 타겟으로 삼는 우회법을 사용하기도 합니다 [15, 19, 20].
@@ -33,8 +33,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** THREE.Raycaster, Bounding Volume Hierarchy (BVH), [[InstancedMesh]], GPU Picking
-- **Projects/Contexts:** 3D 사용자 상호작용 및 마우스 피킹 (Picking) 구현, [[three-mesh-bvh]] 라이브러리 연동
+- **Related Topics:** THREE.Raycaster, Bounding Volume Hierarchy (BVH), [[InstancedMesh|InstancedMesh]], GPU Picking
+- **Projects/Contexts:** 3D 사용자 상호작용 및 마우스 피킹 (Picking) 구현, [[three-mesh-bvh|three-mesh-bvh]] 라이브러리 연동
 - **Contradictions/Notes:** `InstancedMesh`를 사용할 때 GPU 성능 이점은 크지만, 각 인스턴스마다 CPU 기반 레이캐스팅을 처리하거나 개별 정밀도를 조작하는 데는 유연성이 떨어집니다 [15]. 또한 셰이더로 지오메트리를 변경하면 CPU 레이캐스팅과 데이터 불일치가 발생하므로 설계 시 주의가 필요합니다 [21].
 
 ---

10_Wiki/Topics/Graphics & Performance/React 19 Compiler의 Threejs 런타임 성능 개선 원리.md

@@ -1,23 +1,23 @@
 ---
-id: [[P-Reinforce]]-AUTO-777FEC
+id: [[P-Reinforce|P-Reinforce]]-AUTO-777FEC
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[React 19]] Compiler의 [[Threejs]] 런타임 성능 개선 원리"
+github_commit: "[P-Reinforce] Continuous Worker - [[React 19|React 19]] Compiler의 [[Threejs|Threejs]] 런타임 성능 개선 원리"
 ---
 
-# [[React 19 Compiler의 Threejs 런타임 성능 개선 원리]]
+# [[React 19 Compiler의 Threejs 런타임 성능 개선 원리|React 19 Compiler의 Threejs 런타임 성능 개선 원리]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > React 19 컴파일러는 빌드 타임에 코드의 값, 컴포넌트, 콜백 함수를 자동으로 메모이제이션하여 잦은 가비지 컬렉션(GC)과 불필요한 리렌더링을 차단함으로써, React Three Fiber(R3F) 기반 3D 게임의 프레임 레이트(FPS)를 안정화하고 런타임 성능을 획기적으로 개선합니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-**1. 자동 참조 안정성([[Reference]] [[Stability]]) 확보를 통한 리렌더링 방지** React 환경에서는 부모 컴포넌트의 상태가 변할 때마다 하위 컴포넌트들이 기본적으로 모두 리렌더링됩니다. 특히 인라인 함수나 객체가 매 렌더링마다 새로운 참조(Reference)를 생성하면, 하위에 있는 무거운 3D 컴포넌트(Mesh, Material 등)가 불필요하게 렌더링을 반복하게 됩니다. React 19 컴파일러는 `useMemo`나 `useCallback` 없이도 안전한 모든 곳에 메모이제이션을 자동 적용하여 참조 안정성을 확보해 주므로, 무거운 3D 객체의 무의미한 재생성을 막아줍니다.
+**1. 자동 참조 안정성([[Reference|Reference]] Stability) 확보를 통한 리렌더링 방지** React 환경에서는 부모 컴포넌트의 상태가 변할 때마다 하위 컴포넌트들이 기본적으로 모두 리렌더링됩니다. 특히 인라인 함수나 객체가 매 렌더링마다 새로운 참조(Reference)를 생성하면, 하위에 있는 무거운 3D 컴포넌트(Mesh, Material 등)가 불필요하게 렌더링을 반복하게 됩니다. React 19 컴파일러는 `useMemo`나 `useCallback` 없이도 안전한 모든 곳에 메모이제이션을 자동 적용하여 참조 안정성을 확보해 주므로, 무거운 3D 객체의 무의미한 재생성을 막아줍니다.
 
-**2. 가비지 컬렉션(GC) 스파이크 억제** 실시간 3D 게임에서 가장 치명적인 성능 저하 원인 중 하나는 단기간에 수많은 객체가 생성되고 버려지면서 발생하는 가비지 컬렉션 멈춤([[Stop-the-world]]) 현상입니다. 컴파일러가 연산 결과와 콜백 함수를 자동으로 캐싱하면 렌더링마다 버려지는 객체의 생성이 크게 줄어들어, 메모리 파편화 및 GC로 인한 프레임 드랍(Lag)을 효과적으로 억제할 수 있습니다.
+**2. 가비지 컬렉션(GC) 스파이크 억제** 실시간 3D 게임에서 가장 치명적인 성능 저하 원인 중 하나는 단기간에 수많은 객체가 생성되고 버려지면서 발생하는 가비지 컬렉션 멈춤([[Stop-the-world|Stop-the-world]]) 현상입니다. 컴파일러가 연산 결과와 콜백 함수를 자동으로 캐싱하면 렌더링마다 버려지는 객체의 생성이 크게 줄어들어, 메모리 파편화 및 GC로 인한 프레임 드랍(Lag)을 효과적으로 억제할 수 있습니다.
 
-**3. 재조정([[Reconciliation]]) 오버헤드 감소로 메인 스레드 확보** React의 가상 DOM 트리를 비교하는 재조정(Reconciliation) 과정은 CPU 연산 비용이 높습니다. 컴파일러 적용 시 순수 컴포넌트의 90% 이상, 연산 값의 85% 이상이 자동으로 캐싱되어 렌더링 소요 시간이 단축됩니다. 덕분에 메인 스레드의 부하가 줄어들어, 게임 루프가 물리 엔진 연산이나 렌더링 로직 처리에 더 많은 자원을 온전히 사용할 수 있게 됩니다.
+**3. 재조정([[Reconciliation|Reconciliation]]) 오버헤드 감소로 메인 스레드 확보** React의 가상 DOM 트리를 비교하는 재조정(Reconciliation) 과정은 CPU 연산 비용이 높습니다. 컴파일러 적용 시 순수 컴포넌트의 90% 이상, 연산 값의 85% 이상이 자동으로 캐싱되어 렌더링 소요 시간이 단축됩니다. 덕분에 메인 스레드의 부하가 줄어들어, 게임 루프가 물리 엔진 연산이나 렌더링 로직 처리에 더 많은 자원을 온전히 사용할 수 있게 됩니다.
 
 **4. 수동 최적화의 한계 및 휴먼 에러 극복** 과거에는 복잡한 3D 씬을 구성할 때 개발자가 직접 모든 의존성 배열을 관리하며 수동으로 메모이제이션을 해야 했고, 이 과정에서 실수가 발생하기 쉬웠습니다. 컴파일러는 이러한 보일러플레이트 코드를 제거하고 빌드 타임에 최적화를 보장하므로, 개발자는 미세한 메모이제이션에 신경 쓰는 대신 Three.js 씬 그래프 최적화 등 근본적인 엔진 아키텍처에 더 집중할 수 있습니다.
 
@@ -26,9 +26,9 @@ github_commit: "[P-Reinforce] Continuous Worker - [[React 19]] Compiler의 [[Thr
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React 19 Compiler]], [[React Three Fiber (R3F)]], 가비지 컬렉션(GC) 최적화, [[불필요한 리렌더링 방지]]
+- **Related Topics:** [[React 19 Compiler|React 19 Compiler]], React Three Fiber (R3F), 가비지 컬렉션(GC) 최적화, [[불필요한 리렌더링 방지|불필요한 리렌더링 방지]]
 - **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처
-- **Contradictions/Notes:** React 19 컴파일러가 선언적 UI의 리렌더링 성능을 비약적으로 높여주지만, 게임의 근본적인 안티 패턴까지 해결해 주지는 않습니다. 예를 들어, 매 프레임 실행되는 `useFrame` 루프 내부에서 React 상태(`set[[State]]`)를 업데이트하거나 객체를 새로 생성(`new Vector3()`)하는 것은 여전히 치명적입니다. 빈번하게 변하는 3D 객체의 위치나 회전값 등은 컴파일러에 의존할 것이 아니라, 반드시 참조(Ref)를 사용하여 직접 변형(Direct Mutation)해야 합니다.
+- **Contradictions/Notes:** React 19 컴파일러가 선언적 UI의 리렌더링 성능을 비약적으로 높여주지만, 게임의 근본적인 안티 패턴까지 해결해 주지는 않습니다. 예를 들어, 매 프레임 실행되는 `useFrame` 루프 내부에서 React 상태(`set[[State|State]]`)를 업데이트하거나 객체를 새로 생성(`new Vector3()`)하는 것은 여전히 치명적입니다. 빈번하게 변하는 3D 객체의 위치나 회전값 등은 컴파일러에 의존할 것이 아니라, 반드시 참조(Ref)를 사용하여 직접 변형(Direct Mutation)해야 합니다.
 
 ---
 

10_Wiki/Topics/Graphics & Performance/React Three Fiber (R3F).md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-979529
+id: [[P-Reinforce|P-Reinforce]]-AUTO-979529
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,13 +7,13 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber (R3F)"
 ---
 
-# [[React Three Fiber (R3F)]]
+# [[React Three Fiber (R3F)|React Three Fiber (R3F]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> React Three Fiber(R3F)는 Three.js에 React의 렌더링 패러다임과 멘탈 모델을 더해주는 라이브러리입니다 [1]. [[WebGPU]]와 같은 최신 렌더링 기술을 지원하며 비동기 `gl` prop 팩토리를 통해 원활하게 통합할 수 있어 건축 대시보드와 같은 환경에서 유용하게 사용됩니다 [2]. 하지만 React 특유의 상태 기반 렌더링 방식으로 인해 고유한 성능 문제(pitfalls)가 발생할 수 있으므로 렌더링과 메모리 관리에 세심한 주의가 필요합니다 [1].
+> React Three Fiber(R3F)는 Three.js에 React의 렌더링 패러다임과 멘탈 모델을 더해주는 라이브러리입니다 [1]. [[WebGPU|WebGPU]]와 같은 최신 렌더링 기술을 지원하며 비동기 `gl` prop 팩토리를 통해 원활하게 통합할 수 있어 건축 대시보드와 같은 환경에서 유용하게 사용됩니다 [2]. 하지만 React 특유의 상태 기반 렌더링 방식으로 인해 고유한 성능 문제(pitfalls)가 발생할 수 있으므로 렌더링과 메모리 관리에 세심한 주의가 필요합니다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **상태 관리 및 애니메이션 루프:** R3F에서 성능을 최적화하기 위한 핵심 규칙은 Three.js의 변이(mutation)를 React의 상태 변경(`set[[State]]`)이 아닌 `useFrame` 내부에서 처리하는 것입니다 [1]. 프레임 속도에 독립적인 움직임을 구현하려면 `delta` 값을 사용해야 하며, 가비지 컬렉션(GC)을 유발하는 객체 생성 작업은 절대 `useFrame` 내부에서 수행해서는 안 됩니다 [1, 3].
+- **상태 관리 및 애니메이션 루프:** R3F에서 성능을 최적화하기 위한 핵심 규칙은 Three.js의 변이(mutation)를 React의 상태 변경(`set[[State|State]]`)이 아닌 `useFrame` 내부에서 처리하는 것입니다 [1]. 프레임 속도에 독립적인 움직임을 구현하려면 `delta` 값을 사용해야 하며, 가비지 컬렉션(GC)을 유발하는 객체 생성 작업은 절대 `useFrame` 내부에서 수행해서는 안 됩니다 [1, 3].
 - **렌더링 횟수 제어:** 애니메이션이 없는 정적인 씬에서는 `frameloop="demand"` 옵션을 사용하여 매 프레임 렌더링되는 것을 방지함으로써 리소스(모바일의 경우 배터리)를 절약할 수 있습니다 [1]. 필요한 경우에만 렌더링을 갱신하려면 수동으로 `invalidate()` 함수를 호출해야 합니다 [1].
 - **컴포넌트 최적화 및 자원 관리:** 불필요한 리렌더링을 방지하기 위해 비용이 많이 드는 컴포넌트는 `React.memo`로 감싸는 것이 좋습니다 [3]. 또한, 컴포넌트를 완전히 언마운트했다가 다시 마운트하면 버퍼가 재생성되고 셰이더가 다시 컴파일되는 비용이 발생하므로, 대신 가시성(visibility)을 토글하는 방식이 권장됩니다 [3]. React 컴포넌트가 언마운트될 때는 클린업(cleanup) 함수를 사용하여 메모리에 남은 GPU 자원을 폐기해야 합니다 [4].
 - **에셋 로딩 및 생태계 활용:** R3F는 React Suspense와 원활하게 통합되어 렌더링 지연을 관리할 수 있으며 [5], `useGLTF.preload`를 통해 모델이 필요하기 전에 미리 로드할 수 있습니다 [3]. 복잡한 구현 없이 LOD(Level of Detail)를 적용하려면 Drei 라이브러리의 `<Detailed />` 컴포넌트를 사용하고 [3, 6], 드롭인(drop-in) 성능 모니터링을 위해서는 `r3f-perf`를 활용할 수 있습니다 [3]. 정적 씬의 런타임 라이트맵 베이킹에는 `@react-three/lightmap`을 사용할 수 있습니다 [7].
@@ -23,7 +23,7 @@ github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber (R3F)"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Three.js, [[WebGPU]], Drei
+- **Related Topics:** Three.js, [[WebGPU|WebGPU]], Drei
 - **Projects/Contexts:** React-based construction dashboards
 - **Contradictions/Notes:** 소스 내에서 상충되는 주장은 없으나, R3F가 React 기반임에도 불구하고 렌더링 루프 최적화를 위해 React의 핵심 패턴 중 하나인 상태 변경(`setState`)을 `useFrame` 안에서 피하라고 경고하는 등 [1] 패러다임 간의 조율이 필요하다는 점을 강조합니다.
 

10_Wiki/Topics/Graphics & Performance/React Three Fiber 자산 최적화 (Asset Optimization).md

@@ -1,13 +1,13 @@
 ---
-id: [[P-Reinforce]]-AUTO-C16818
+id: [[P-Reinforce|P-Reinforce]]-AUTO-C16818
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber 자산 최적화 (Asset [[Optimization]])"
+github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber 자산 최적화 (Asset [[Optimization|Optimization]])"
 ---
 
-# [[React Three Fiber 자산 최적화 (Asset Optimization)]]
+# [[React Three Fiber 자산 최적화 (Asset Optimization)|React Three Fiber 자산 최적화 (Asset Optimization]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > React Three Fiber(R3F) 환경에서 3D 모델(GLTF), 텍스처 등의 자산 크기를 대폭 줄이고, GPU 메모리 점유를 최소화하며 초기 로딩 속도와 렌더링 성능을 극대화하기 위한 압축 및 파이프라인 관리 기법입니다.
@@ -32,15 +32,15 @@ github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber 자산 최
 - **프리로딩:** 씬이 화면에 나타나기 전에 `useGLTF.preload('/model.glb')`를 호출하여 렌더링 지연(Pop-in)을 방지합니다.
 - **점진적 로딩 / Suspense:** 로딩 시간이 길어질 수 있는 거대한 모델의 경우, React의 `<Suspense fallback={<Loader />}>`를 활용해 우선 가벼운 플레이스홀더(스켈레톤 지오메트리나 저해상도 모델)를 즉시 띄워두고 백그라운드에서 고해상도 에셋을 불러오도록 처리합니다.
 
-**6. 텍스처 아틀라싱([[Texture Atlas]]ing) 및 메시 병합** 여러 개의 텍스처를 하나의 큰 이미지 맵(Atlas)으로 합치거나, 동일한 재질을 공유하는 여러 정적 메시(Mesh)를 하나로 병합(Merge)하여 **드로우 콜([[Draw Call]])과 텍스처 바인딩 횟수를 최소화**해야 모바일 기기에서도 원활한 성능을 보장할 수 있습니다.
+**6. 텍스처 아틀라싱([[Texture Atlas|Texture Atlas]]ing) 및 메시 병합** 여러 개의 텍스처를 하나의 큰 이미지 맵(Atlas)으로 합치거나, 동일한 재질을 공유하는 여러 정적 메시(Mesh)를 하나로 병합(Merge)하여 **드로우 콜([[Draw Call|Draw Call]])과 텍스처 바인딩 횟수를 최소화**해야 모바일 기기에서도 원활한 성능을 보장할 수 있습니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Code Splitting & Lazy Loading, [[Draw Call Optimization]] (드로우 콜 최적화), [[memory]] Leak Prevention (메모리 누수 방지), 웹 워커(Web Worker)
-- **Projects/Contexts:** 대규모 [[WebGL]]/R3F 3D 쇼핑몰 제품 컨피규레이터, 모바일 환경을 타겟으로 하는 웹 기반 3D 게임
+- **Related Topics:** Code Splitting & Lazy Loading, [[Draw Call Optimization|Draw Call Optimization]] (드로우 콜 최적화), [[memory|memory]] Leak Prevention (메모리 누수 방지), 웹 워커(Web Worker)
+- **Projects/Contexts:** 대규모 [[WebGL|WebGL]]/R3F 3D 쇼핑몰 제품 컨피규레이터, 모바일 환경을 타겟으로 하는 웹 기반 3D 게임
 - **Contradictions/Notes:** 지오메트리나 텍스처를 과도하게 압축(Draco, KTX2)하면 다운로드되는 파일 크기와 GPU 메모리는 대폭 줄어들지만, 클라이언트의 웹 워커에서 이를 압축 해제(Decompression)하는 과정에서 CPU 연산 비용과 디코더 로딩 지연이 발생합니다. 따라서, 복잡도가 낮고 빠른 즉각적 렌더링이 필요한 에셋의 경우 오히려 압축 없이 원본을 사용하는 것이 TTI(Time to Interactive) 면에서 더 유리할 수도 있으므로 Trade-off를 고려해야 합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/React Three Fiber에서 Rapier 물리 엔진 최적화하기.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-95FEB9
+id: [[P-Reinforce|P-Reinforce]]-AUTO-95FEB9
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,28 +7,28 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber에서 Rapier 물리 엔진 최적화하기"
 ---
 
-# [[React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
+# [[React Three Fiber에서 Rapier 물리 엔진 최적화하기|React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > React Three Fiber(R3F) 환경에서 `@react-three/rapier`를 사용할 때, 대규모 `InstancedRigidBodies` 적용, 비트마스크 기반의 충돌 필터링, Rust 메모리 에러 방지를 위한 상태 캐싱, 그리고 렌더링 루프 분리를 통해 연산 오버헤드를 극적으로 줄이는 고성능 물리 엔진 최적화 기법입니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-**1. InstancedRigidBodies를 활용한 대규모 물리 객체 처리** 수백, 수천 개의 물리 객체(총알, 파편 등)를 개별 `<RigidBody>`로 렌더링하면 물리 연산과 드로우 콜 오버헤드로 인해 프레임이 급락합니다. 이를 방지하려면 Three.js의 `[[InstancedMesh]]`를 `<InstancedRigidBodies>`로 감싸서 사용해야 합니다. 이 방식을 사용하면 수천 개의 인스턴스에 대한 위치, 회전, 물리적 상태를 배열(`InstancedRigidBodyProps[]`) 형태로 단 번에 초기화하고 단일 드로우 콜로 렌더링할 수 있어 성능이 비약적으로 향상됩니다.
+**1. InstancedRigidBodies를 활용한 대규모 물리 객체 처리** 수백, 수천 개의 물리 객체(총알, 파편 등)를 개별 `<RigidBody>`로 렌더링하면 물리 연산과 드로우 콜 오버헤드로 인해 프레임이 급락합니다. 이를 방지하려면 Three.js의 `[[InstancedMesh|InstancedMesh]]`를 `<InstancedRigidBodies>`로 감싸서 사용해야 합니다. 이 방식을 사용하면 수천 개의 인스턴스에 대한 위치, 회전, 물리적 상태를 배열(`InstancedRigidBodyProps[]`) 형태로 단 번에 초기화하고 단일 드로우 콜로 렌더링할 수 있어 성능이 비약적으로 향상됩니다.
 
 **2. interactionGroups를 통한 충돌 및 솔버 연산 최소화** 모든 객체가 서로 충돌 여부를 계산하게 두면 엔진에 큰 부하를 줍니다. Rapier에서는 `collisionGroups` 및 `solverGroups` 속성에 비트마스크(Bitmask)를 설정하여 상호작용할 대상을 제한할 수 있습니다. 라이브러리에서 제공하는 `interactionGroups` 헬퍼 함수를 사용해 객체가 속한 그룹과 상호작용할 그룹을 명시(예: `interactionGroups(0,)`)함으로써 불필요한 충돌 연산을 원천적으로 차단해야 합니다.
 
-**3. [[Physics]] Hooks 캐싱을 통한 Rust 메모리 에일리어싱 에러 방지** 복잡한 일방향 플랫폼(One-way platform) 등 고급 충돌 필터링을 위해 `useFilterContactPair` 훅을 사용할 때, 물리 스텝 진행 도중 `translation()`이나 `linvel()` 같은 RigidBody 속성에 직접 접근하면 WASM(Rust) 계층에서 에일리어싱 에러가 발생합니다. 이를 방지하려면 반드시 `useBeforePhysicsStep` 훅을 사용해 물리 스텝 시작 전에 필요한 객체들의 상태(위치, 속도 등)를 자바스크립트 `Map` 등 캐시(Cache) 메모리에 미리 저장해 두고, 필터링 훅에서는 이 캐시된 데이터만 읽도록 설계해야 합니다.
+**3. [[Physics|Physics]] Hooks 캐싱을 통한 Rust 메모리 에일리어싱 에러 방지** 복잡한 일방향 플랫폼(One-way platform) 등 고급 충돌 필터링을 위해 `useFilterContactPair` 훅을 사용할 때, 물리 스텝 진행 도중 `translation()`이나 `linvel()` 같은 RigidBody 속성에 직접 접근하면 WASM(Rust) 계층에서 에일리어싱 에러가 발생합니다. 이를 방지하려면 반드시 `useBeforePhysicsStep` 훅을 사용해 물리 스텝 시작 전에 필요한 객체들의 상태(위치, 속도 등)를 자바스크립트 `Map` 등 캐시(Cache) 메모리에 미리 저장해 두고, 필터링 훅에서는 이 캐시된 데이터만 읽도록 설계해야 합니다.
 
 **4. On-demand Rendering 및 물리 스텝 수동 제어** 기본적으로 `@react-three/rapier`는 프레임이 렌더링될 때마다 물리 시뮬레이션을 업데이트합니다. 하지만 화면의 시각적 업데이트가 필요 없을 때도 물리 연산이 필요하거나, 반대로 물리 연산을 일시정지하고 싶다면 `<Physics updateLoop="independent">`를 설정하여 렌더링 루프와 물리 루프를 분리할 수 있습니다. 또한 `useRapier().step()` 메서드를 통해 물리 시뮬레이션을 수동으로 진행(Manual stepping)시킬 수도 있습니다.
 
-**5. 센서(Sensor) 활용 및 충돌 이벤트 내 React 상태 업데이트 지양** 물리적 반발력이나 밀어내기 연산이 필요 없고 오직 '영역에 들어왔는지(Overlapping)' 여부만 판별해야 한다면 해당 콜라이더에 `sensor` 속성을 부여해야 불필요한 솔버(Solver) 연산을 줄일 수 있습니다. 또한, `onCollisionEnter`와 같은 빈번한 충돌 이벤트 내부에서 React의 `set[[State]]`를 호출하면 심각한 리렌더링 지연이 발생하므로, 전역 상태 변경이 아닌 이상 명령형(Imperative) 파티클 시스템에 직접 신호를 보내 처리하는 것이 바람직합니다.
+**5. 센서(Sensor) 활용 및 충돌 이벤트 내 React 상태 업데이트 지양** 물리적 반발력이나 밀어내기 연산이 필요 없고 오직 '영역에 들어왔는지(Overlapping)' 여부만 판별해야 한다면 해당 콜라이더에 `sensor` 속성을 부여해야 불필요한 솔버(Solver) 연산을 줄일 수 있습니다. 또한, `onCollisionEnter`와 같은 빈번한 충돌 이벤트 내부에서 React의 `set[[State|State]]`를 호출하면 심각한 리렌더링 지연이 발생하므로, 전역 상태 변경이 아닌 이상 명령형(Imperative) 파티클 시스템에 직접 신호를 보내 처리하는 것이 바람직합니다.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh (드로우 콜 최적화)]], [[Web Worker (웹 워커)]], [[Garbage Collection]] (GC) 최적화, [[Object [[Pooling]] (오브젝트 풀링)]]
+- **Related Topics:** [[InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화]], Web Worker (웹 워커), Garbage Collection (GC) 최적화, [[Object Pooling (오브젝트 풀링)|Object Pooling (오브젝트 풀링]]
 - **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처
 - **Contradictions/Notes:** Rapier의 스냅샷(Snapshot) 기능(`world.takeSnapshot()`)을 이용해 물리 세계의 상태를 저장하고 복원할 수 있지만, 복원 시점의 객체 생성 순서나 식별자가 스냅샷 캡처 시점과 정확히 일치하지 않으면 RigidBody들이 엉키는(Scramble) 버그가 발생하므로 상태 직렬화에 각별한 주의가 필요합니다.
 

10_Wiki/Topics/Graphics & Performance/Revit glTF Export.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-E2D208
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E2D208
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,14 +7,14 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Revit glTF Export"
 ---
 
-# [[Revit glTF Export]]
+# [[Revit glTF Export|Revit glTF Export]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > Revit glTF Export는 Revit에서 작성된 건축 및 건물 모델을 웹 3D 환경에서 효율적으로 렌더링하기 위해 glTF 형식으로 내보내는 과정입니다 [1, 2]. 이 과정에서는 성능 최적화를 위해 동일한 재질을 가진 메쉬를 병합하는 동시에, 병합된 모델 내에서도 개별 객체를 식별하고 제어하기 위해 특수한 glTF 확장 기능과 정점 데이터 속성을 함께 활용합니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **재질 기반의 메쉬 병합:** Revit 모델(예: 콘크리트 벽체 등)을 glTF로 내보낼 때, 드로우 콜을 줄이고 렌더링을 최적화하기 위해 동일한 재질을 공유하는 메쉬들을 그룹화합니다 [1, 3]. 건물의 벽체들은 재질은 같지만 기하학적 형태가 대부분 고유하기 때문에 일반적인 `[[InstancedMesh]]`로는 처리할 수 없어 데이터를 병합(Merge)하거나 `BatchedMesh`를 통해 관리하게 됩니다 [4].
-- **glTF 확장 기능(Extensions)의 적용:** 기하학적 데이터를 하나로 병합한 후에도, 사용자가 특정 벽체를 개별적으로 선택(Pick)하거나 가시성(Visibility) 및 색상을 동적으로 변경할 수 있어야 합니다 [4]. 이를 구현하기 위해 모델을 내보낼 때 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_[[Instancing]]`과 같은 glTF 확장 기능을 추가하여 데이터를 구성합니다 [3].
+- **재질 기반의 메쉬 병합:** Revit 모델(예: 콘크리트 벽체 등)을 glTF로 내보낼 때, 드로우 콜을 줄이고 렌더링을 최적화하기 위해 동일한 재질을 공유하는 메쉬들을 그룹화합니다 [1, 3]. 건물의 벽체들은 재질은 같지만 기하학적 형태가 대부분 고유하기 때문에 일반적인 `[[InstancedMesh|InstancedMesh]]`로는 처리할 수 없어 데이터를 병합(Merge)하거나 `BatchedMesh`를 통해 관리하게 됩니다 [4].
+- **glTF 확장 기능(Extensions)의 적용:** 기하학적 데이터를 하나로 병합한 후에도, 사용자가 특정 벽체를 개별적으로 선택(Pick)하거나 가시성(Visibility) 및 색상을 동적으로 변경할 수 있어야 합니다 [4]. 이를 구현하기 위해 모델을 내보낼 때 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_[[Instancing|Instancing]]`과 같은 glTF 확장 기능을 추가하여 데이터를 구성합니다 [3].
 - **정점 식별 속성(Feature ID) 할당:** 병합된 모델 내에서 서로 다른 배치를 구분하기 위해 각 정점(Vertex)에 `_FEATURE_ID_0`과 같은 특수 속성을 할당합니다. 렌더러(Three.js 등)는 모델을 로드할 때 이 속성을 파싱하여, 단일 객체로 병합된 상태에서도 내부의 서로 다른 기하학적 파트를 식별하고 개별적인 제어를 수행할 수 있습니다 [3, 5].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)

10_Wiki/Topics/Graphics & Performance/Revit 모델 렌더링.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-EC4298
+id: [[P-Reinforce|P-Reinforce]]-AUTO-EC4298
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,7 +7,7 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Revit 모델 렌더링"
 ---
 
-# [[Revit 모델 렌더링]]
+# [[Revit 모델 렌더링|Revit 모델 렌더링]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 소스에 관련 정보가 부족합니다. 제공된 텍스트에서는 Revit 모델을 Three.js와 같은 웹 그래픽 환경으로 내보내어 렌더링하는 과정에서 발생한 특정 사용자의 워크플로우와 성능 병목 사례만이 제한적으로 언급되어 있습니다.
@@ -15,8 +15,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Revit 모델 렌더링"
 ## 📖 구조화된 지식 (Synthesized Content)
 소스에 관련 정보가 부족합니다. 제공된 문서 내에서 확인할 수 있는 단편적인 Revit 모델 렌더링 시도 및 사례는 다음과 같습니다.
 
-* **glTF 포맷 변환 및 데이터 구조화:** 한 사용자는 Revit에서 제작된 건물 모델을 glTF 형식으로 추출하고, Three.js 환경에서 가시성을 관리하기 위해 동일한 재질을 가진 메쉬들을 병합하는 방식을 사용했습니다 [1, 2]. 이 과정에서 객체의 배치를 구분하기 위해 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_[[Instancing]]` 등의 확장을 추가하고, 각 정점에 `_FEATURE_ID_0` 속성을 할당하여 파싱하는 과정을 거쳤습니다 [3, 4].
-* **고유 지오메트리에 따른 렌더링 방식의 제약:** Revit 건물 모델 내의 벽체들은 콘크리트라는 동일한 재질을 공유하지만, 각기 고유한 기하학적 형태(Geometry)를 가지고 있어 단일 형태를 복제하는 `[[InstancedMesh]]`를 적용하기 어려웠습니다 [5]. 따라서 개별 벽체를 선택(Picking)하거나 가시성 및 색상을 동적으로 변경하기 위한 목적으로, 다양한 지오메트리를 하나로 묶을 수 있는 `BatchedMesh`를 채택해야만 했습니다 [5].
+* **glTF 포맷 변환 및 데이터 구조화:** 한 사용자는 Revit에서 제작된 건물 모델을 glTF 형식으로 추출하고, Three.js 환경에서 가시성을 관리하기 위해 동일한 재질을 가진 메쉬들을 병합하는 방식을 사용했습니다 [1, 2]. 이 과정에서 객체의 배치를 구분하기 위해 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_[[Instancing|Instancing]]` 등의 확장을 추가하고, 각 정점에 `_FEATURE_ID_0` 속성을 할당하여 파싱하는 과정을 거쳤습니다 [3, 4].
+* **고유 지오메트리에 따른 렌더링 방식의 제약:** Revit 건물 모델 내의 벽체들은 콘크리트라는 동일한 재질을 공유하지만, 각기 고유한 기하학적 형태(Geometry)를 가지고 있어 단일 형태를 복제하는 `[[InstancedMesh|InstancedMesh]]`를 적용하기 어려웠습니다 [5]. 따라서 개별 벽체를 선택(Picking)하거나 가시성 및 색상을 동적으로 변경하기 위한 목적으로, 다양한 지오메트리를 하나로 묶을 수 있는 `BatchedMesh`를 채택해야만 했습니다 [5].
 * **대규모 모델에서의 성능 병목 문제:** 약 1,200만 개의 삼각형과 1,600만 개의 정점, 약 10만 개 이상의 지오메트리로 구성된 대규모 Revit 모델을 `BatchedMesh`를 활용해 렌더링할 경우 심각한 성능 저하가 보고되었습니다 [6, 7]. 일반적인 `Mesh`로 렌더링할 때는 60 FPS(CPU 15%, GPU 90%)가 유지되었으나, `BatchedMesh` 적용 시 CPU 사용량이 40% 이상으로 급증하며 프레임 레이트가 10~20 FPS 수준으로 크게 하락했습니다 [1, 8, 9].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)

10_Wiki/Topics/Graphics & Performance/Rowhammer attack.md

@@ -1,19 +1,19 @@
 ---
-id: [[P-Reinforce]]-AUTO-80DA6E
+id: [[P-Reinforce|P-Reinforce]]-AUTO-80DA6E
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Rowhammer]] attack"
+github_commit: "[P-Reinforce] Continuous Worker - [[Rowhammer|Rowhammer]] attack"
 ---
 
-# [[Rowhammer attack]]
+# [[Rowhammer attack|Rowhammer attack]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Rowhammer 공격은 [[WebGL]]을 사용하여 GPU에서 실행되었던 심각한 보안 취약점 공격입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 활용하여 캐시 적중 실패율([[Cache miss rates]])을 관찰하고, 이를 통해 GPU의 물리적 메모리 레이아웃을 파악합니다 [1]. 이후 파악된 메모리에서 특정 비트를 반전(flip)시켜 페이지 테이블을 조작하고 악의적인 작업을 수행하도록 유도합니다 [1]. 과거에는 막기 어려운 공격으로 보고되었으나, 현재는 최신 RAM에 적용된 완화(mitigations) 기술을 통해 방어할 수 있습니다 [1].
+> Rowhammer 공격은 [[WebGL|WebGL]]을 사용하여 GPU에서 실행되었던 심각한 보안 취약점 공격입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 활용하여 캐시 적중 실패율([[Cache miss rates|Cache miss rates]])을 관찰하고, 이를 통해 GPU의 물리적 메모리 레이아웃을 파악합니다 [1]. 이후 파악된 메모리에서 특정 비트를 반전(flip)시켜 페이지 테이블을 조작하고 악의적인 작업을 수행하도록 유도합니다 [1]. 과거에는 막기 어려운 공격으로 보고되었으나, 현재는 최신 RAM에 적용된 완화(mitigations) 기술을 통해 방어할 수 있습니다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **공격 원리 및 실행:** 이 공격은 WebGL 환경에서 타임스탬프 쿼리([[Timestamp Queries]])로부터 얻은 고정밀 타임스탬프(high precision timestamps)를 반드시 필요로 합니다 [1]. 공격자는 이를 통해 캐시 적중 실패율을 관찰하고 GPU 상의 물리적 메모리 배치를 알아냅니다 [1]. 
+* **공격 원리 및 실행:** 이 공격은 WebGL 환경에서 타임스탬프 쿼리([[Timestamp Queries|Timestamp Queries]])로부터 얻은 고정밀 타임스탬프(high precision timestamps)를 반드시 필요로 합니다 [1]. 공격자는 이를 통해 캐시 적중 실패율을 관찰하고 GPU 상의 물리적 메모리 배치를 알아냅니다 [1]. 
 * **페이지 테이블 조작:** 메모리 구조를 파악한 뒤에는 타겟으로 삼은 특정 비트를 Rowhammer 기법으로 반전시킵니다 [1]. 이 과정을 통해 페이지 테이블(page table)을 속여 시스템이 은밀하고 악의적인 동작(insidious action)을 실행하도록 만듭니다 [1].
 * **공격의 한계 및 최신 방어 동향:** 이 공격은 매우 명확하게 정의된 TLB(Translation Lookaside Buffer) 설계를 가진 특정 기기에만 제한적으로 적용되었습니다 [1]. 한때는 막을 수 없는(couldn't plug) 실질적이고 심각한 공격으로 평가받았으나, 이후 최신 RAM 하드웨어에 Rowhammer 방어 기술(mitigations)이 도입되면서 이러한 유형의 공격은 예방 가능해졌습니다 [1].
 
@@ -22,8 +22,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Rowhammer]] attack"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[GPU]], [[Timestamp queries]], [[TLB design]], [[Cache miss rates]]
-- **Projects/Contexts:** [[WebGPU]]의 High Re[[Solution]] Time spec 이슈 논의 과정 중, 고해상도 타임스탬프가 야기할 수 있는 심각한 보안 위협(타이밍 공격)의 과거 사례로 언급되었습니다 [1].
+- **Related Topics:** [[WebGL|WebGL]], GPU, Timestamp queries, [[TLB design|TLB design]], [[Cache miss rates|Cache miss rates]]
+- **Projects/Contexts:** [[WebGPU|WebGPU]]의 High Re[[Solution|Solution]] Time spec 이슈 논의 과정 중, 고해상도 타임스탬프가 야기할 수 있는 심각한 보안 위협(타이밍 공격)의 과거 사례로 언급되었습니다 [1].
 - **Contradictions/Notes:** 소스에 따르면 보고된 당시에는 막을 수 없는(couldn't plug) 공격이었으나, 현재는 하드웨어(최신 RAM)의 개선으로 인해 더 이상 유효하지 않은 것으로 보입니다 [1].
 
 ---

10_Wiki/Topics/Graphics & Performance/Rowhammer.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-13F9F1
+id: [[P-Reinforce|P-Reinforce]]-AUTO-13F9F1
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,13 +7,13 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Rowhammer"
 ---
 
-# [[Rowhammer]]
+# [[Rowhammer|Rowhammer]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Rowhammer는 [[WebGL]]을 통해 GPU 상에서 실행되어 물리적 메모리의 특정 비트를 반전시키는 심각한 보안 공격 기법입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악하는 방식으로 이루어집니다 [1]. 한때 막을 수 없었던 위협적인 공격이었으나, 특정 장치에만 국한되어 발생하며 최신 RAM의 방어 기술을 통해 완화되었습니다 [1].
+> Rowhammer는 [[WebGL|WebGL]]을 통해 GPU 상에서 실행되어 물리적 메모리의 특정 비트를 반전시키는 심각한 보안 공격 기법입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악하는 방식으로 이루어집니다 [1]. 한때 막을 수 없었던 위협적인 공격이었으나, 특정 장치에만 국한되어 발생하며 최신 RAM의 방어 기술을 통해 완화되었습니다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **공격 원리:** 과거에 보고된 Rowhammer 공격은 타임스탬프 쿼리([[Timestamp Queries]])에서 얻은 고정밀 타임스탬프를 필수적으로 요구했습니다 [1]. 공격자는 이를 통해 캐시 미스율([[Cache miss rates]])을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악할 수 있었습니다 [1].
+- **공격 원리:** 과거에 보고된 Rowhammer 공격은 타임스탬프 쿼리([[Timestamp Queries|Timestamp Queries]])에서 얻은 고정밀 타임스탬프를 필수적으로 요구했습니다 [1]. 공격자는 이를 통해 캐시 미스율([[Cache miss rates|Cache miss rates]])을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악할 수 있었습니다 [1].
 - **시스템 조작:** 확보한 메모리 레이아웃 정보를 바탕으로 특정 비트를 목표로 삼아 반전(flip)시킴으로써, 페이지 테이블(page table)을 속이고 악의적인(insidious) 조작을 수행할 수 있습니다 [1].
 - **한계 및 방어(Mitigations):** 이 공격은 매우 명확하게 정의된 TLB(Translation Lookaside Buffer) 설계를 가진 특정 장치에만 제한적으로 적용되었습니다 [1]. 또한, 최신 RAM(newer RAM)에 도입된 Rowhammer 완화 기술을 통해 이러한 공격을 방지할 수 있습니다 [1].
 
@@ -22,8 +22,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Rowhammer"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[Timestamp Queries]], TLB (Translation Lookaside Buffer)
-- **Projects/Contexts:** High Re[[Solution]] Time spec 논의 (GPU 타임스탬프 해상도를 제한(coarsen)하여 보안 취약점을 방지해야 한다는 논의 중, 고정밀 타임스탬프를 악용한 실제 공격 사례로 언급됨 [1])
+- **Related Topics:** [[WebGL|WebGL]], [[Timestamp Queries|Timestamp Queries]], TLB (Translation Lookaside Buffer)
+- **Projects/Contexts:** High Re[[Solution|Solution]] Time spec 논의 (GPU 타임스탬프 해상도를 제한(coarsen)하여 보안 취약점을 방지해야 한다는 논의 중, 고정밀 타임스탬프를 악용한 실제 공격 사례로 언급됨 [1])
 - **Contradictions/Notes:** 소스에 따르면 Rowhammer는 초기에 "막을 수 없었던 최초의 실질적이고 심각한 공격(the first real, serious attack we couldn't plug)"으로 평가되었으나, 현재는 최신 RAM 하드웨어의 발전으로 회피가 가능해졌습니다 [1].
 
 ---

10_Wiki/Topics/Graphics & Performance/SkinnedMesh.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-1189F7
+id: [[P-Reinforce|P-Reinforce]]-AUTO-1189F7
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - SkinnedMesh"
 ---
 
-# [[SkinnedMesh]]
+# [[SkinnedMesh|SkinnedMesh]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> SkinnedMesh는 뼈대(Bone) 계층 구조를 기반으로 한 애니메이션(예: 캐릭터의 얼굴 뼈대나 손가락 움직임 등)을 구현할 때 사용되는 3D 객체 타입입니다 [1-3]. 단일 객체로는 원활하게 동작하지만 대량으로 렌더링할 경우 심각한 CPU 병목 현상을 유발하며 [4], 정점이 다수의 본 행렬에 영향을 받는 특성상 대규모 렌더링 최적화 기법인 [[InstancedMesh]]와 기본적으로 호환되지 않는 물리적 한계를 지닙니다 [3].
+> SkinnedMesh는 뼈대(Bone) 계층 구조를 기반으로 한 애니메이션(예: 캐릭터의 얼굴 뼈대나 손가락 움직임 등)을 구현할 때 사용되는 3D 객체 타입입니다 [1-3]. 단일 객체로는 원활하게 동작하지만 대량으로 렌더링할 경우 심각한 CPU 병목 현상을 유발하며 [4], 정점이 다수의 본 행렬에 영향을 받는 특성상 대규모 렌더링 최적화 기법인 [[InstancedMesh|InstancedMesh]]와 기본적으로 호환되지 않는 물리적 한계를 지닙니다 [3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **동작 원리와 성능 병목:**
@@ -25,14 +25,14 @@ github_commit: "[P-Reinforce] Continuous Worker - SkinnedMesh"
 - **스킨드 메쉬 렌더링 최적화 전략:**
   - **본 텍스처(Bone Texture) 도입:** GPU 전송 한계를 극복하기 위해 모든 애니메이션 변환 행렬 데이터를 '본 텍스처(Bone Texture)' 또는 텍스처 아틀라스에 구워 넣고, 커스텀 셰이더 단계에서 이를 샘플링해 애니메이션을 구현하는 우회 파이프라인이 사용됩니다 [1, 3, 5].
   - **애니메이션 LOD(Level of Detail):** 거리가 먼 SkinnedMesh 인스턴스의 경우 계산해야 할 본의 개수를 줄이거나(예: 손가락이나 발의 굽힘 뼈대 연산 생략), 애니메이션 업데이트 주기를 낮추어 본 텍스처의 크기와 연산량을 줄이는 방식이 필수적입니다 [6-9].
-  - **커스텀 라이브러리 활용:** 커뮤니티에서는 기본 기능의 한계를 보완하기 위해, 개별 애니메이션 믹서 제어, LOD 시스템, 그리고 절두체 컬링([[Frustum Culling]]) 기능을 포함하여 2만 개 이상의 스킨드 인스턴스 처리를 가능하게 하는 `[[InstancedMesh2]]`와 같은 확장 라이브러리를 활용하기도 합니다 [6, 10-13].
+  - **커스텀 라이브러리 활용:** 커뮤니티에서는 기본 기능의 한계를 보완하기 위해, 개별 애니메이션 믹서 제어, LOD 시스템, 그리고 절두체 컬링([[Frustum Culling|Frustum Culling]]) 기능을 포함하여 2만 개 이상의 스킨드 인스턴스 처리를 가능하게 하는 `[[InstancedMesh2|InstancedMesh2]]`와 같은 확장 라이브러리를 활용하기도 합니다 [6, 10-13].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[InstancedMesh2]], AnimationMixer, Bone Texture, [[Level of Detail (LOD)]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], InstancedMesh2, AnimationMixer, Bone Texture, [[Level of Detail (LOD)|Level of Detail (LOD]]
 - **Projects/Contexts:** Three.js 엔진의 대규모 군중 렌더링 및 애니메이션 처리
 - **Contradictions/Notes:** 엔진의 공식 기능 상으로는 데이터 전송량의 기하급수적 증가 및 `AnimationMixer`와의 아키텍처 충돌 문제로 스킨드 메쉬의 대규모 인스턴싱이 불가능하다고 지적되지만 [3], 개발자들은 본 텍스처를 활용한 셰이더 커스터마이징이나 `InstancedMesh2` 라이브러리를 적용하여 각기 다른 애니메이션을 가진 수만 개의 SkinnedMesh를 단일 혹은 최소한의 드로우 콜로 최적화하여 렌더링하는 데 성공하고 있습니다 [3, 6, 12].
 

10_Wiki/Topics/Graphics & Performance/Sorting.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-9C6ABB
+id: [[P-Reinforce|P-Reinforce]]-AUTO-9C6ABB
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,24 +7,24 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Sorting"
 ---
 
-# [[Sorting]]
+# [[Sorting|Sorting]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D 렌더링 환경에서 정렬(Sorting)은 카메라와의 거리를 기준으로 객체의 렌더링 순서를 결정하는 핵심 프로세스입니다. 불투명한 객체는 앞에서 뒤로(Front-to-Back) 정렬하여 오버드로우를 최소화하고, 투명한 객체는 뒤에서 앞으로(Back-to-Front) 정렬하여 알파 블렌딩([[Alpha Blending]])을 올바르게 표현하기 위해 필수적입니다. 그러나 수많은 객체를 다루는 인스턴싱 환경에서는 매 프레임 정렬을 계산하고 버퍼를 재배열하는 과정이 심각한 CPU 병목 현상을 유발할 수 있습니다 [1, 2].
+> 3D 렌더링 환경에서 정렬(Sorting)은 카메라와의 거리를 기준으로 객체의 렌더링 순서를 결정하는 핵심 프로세스입니다. 불투명한 객체는 앞에서 뒤로(Front-to-Back) 정렬하여 오버드로우를 최소화하고, 투명한 객체는 뒤에서 앞으로(Back-to-Front) 정렬하여 알파 블렌딩([[Alpha Blending|Alpha Blending]])을 올바르게 표현하기 위해 필수적입니다. 그러나 수많은 객체를 다루는 인스턴싱 환경에서는 매 프레임 정렬을 계산하고 버퍼를 재배열하는 과정이 심각한 CPU 병목 현상을 유발할 수 있습니다 [1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **정렬의 목적과 필요성**
-  불투명한 물체를 앞에서 뒤로 정렬하면 뒤에 가려진 픽셀 연산을 조기에 종료([[Early-Z]])할 수 있어 GPU 성능이 향상됩니다 [1]. 반면 투명도를 가진 객체의 경우, 시각적인 오류 없이 올바른 알파 블렌딩 결과를 얻기 위해 반드시 뒤에서 앞으로 렌더링해야 합니다 [2, 3].
+  불투명한 물체를 앞에서 뒤로 정렬하면 뒤에 가려진 픽셀 연산을 조기에 종료([[Early-Z|Early-Z]])할 수 있어 GPU 성능이 향상됩니다 [1]. 반면 투명도를 가진 객체의 경우, 시각적인 오류 없이 올바른 알파 블렌딩 결과를 얻기 위해 반드시 뒤에서 앞으로 렌더링해야 합니다 [2, 3].
 
-- **[[InstancedMesh]]의 정렬 한계**
+- **[[InstancedMesh|InstancedMesh]]의 정렬 한계**
   기본적으로 Three.js의 `InstancedMesh`는 단일 드로우 콜 내에서 객체의 렌더링 순서를 동적으로 변경하거나 자동 정렬하는 기능을 제공하지 않습니다 [1, 2]. 정렬을 구현하려면 매 프레임 카메라와의 거리를 계산하고 색상, 변환 행렬 등 모든 인스턴스 속성 데이터를 재정렬해야 하므로 막대한 CPU 오버헤드가 발생합니다 [2, 4].
 
 - **정렬 알고리즘 및 처리 비용**
-  수만 개의 객체를 정렬하기 위해 기수 정렬([[Radix Sort]])과 같은 알고리즘을 사용할 수 있으나, 이를 메인 스레드에서 실행하면 CPU에 치명적인 부하를 주어 프레임 드랍을 유발합니다 [2, 5]. 실제로 `BatchedMesh`에서 `.sortObjects` 옵션을 활성화하면 `texSubImage2D` 함수 등의 호출로 인해 CPU 사용량이 급증하고 프레임 속도가 30FPS에서 9FPS로 떨어지는 등 성능이 크게 저하되는 사례가 확인되었습니다 [6-8].
+  수만 개의 객체를 정렬하기 위해 기수 정렬([[Radix Sort|Radix Sort]])과 같은 알고리즘을 사용할 수 있으나, 이를 메인 스레드에서 실행하면 CPU에 치명적인 부하를 주어 프레임 드랍을 유발합니다 [2, 5]. 실제로 `BatchedMesh`에서 `.sortObjects` 옵션을 활성화하면 `texSubImage2D` 함수 등의 호출로 인해 CPU 사용량이 급증하고 프레임 속도가 30FPS에서 9FPS로 떨어지는 등 성능이 크게 저하되는 사례가 확인되었습니다 [6-8].
 
 - **대안적 정렬 기법**
-  - **인디렉션(Indirection) 활용:** `[[InstancedMesh2]]`와 같은 확장 라이브러리는 렌더링할 인스턴스 인덱스를 관리하는 별도의 `Instanced[[BufferAttribute]]`를 사용하여, 실제 행렬 데이터를 직접 섞지 않고도 효율적으로 정렬 및 컬링을 수행합니다 [9].
-  - **다중 그리기(Multi-Draw) 확장:** [[WebGL]]의 `multi_draw` 기능을 사용하면 단일 드로우 콜을 유지하면서 인스턴스 그리기의 순서를 지정할 수 있어 정렬 문제를 완화할 수 있습니다 [3, 10].
+  - **인디렉션(Indirection) 활용:** `[[InstancedMesh2|InstancedMesh2]]`와 같은 확장 라이브러리는 렌더링할 인스턴스 인덱스를 관리하는 별도의 `Instanced[[BufferAttribute|BufferAttribute]]`를 사용하여, 실제 행렬 데이터를 직접 섞지 않고도 효율적으로 정렬 및 컬링을 수행합니다 [9].
+  - **다중 그리기(Multi-Draw) 확장:** [[WebGL|WebGL]]의 `multi_draw` 기능을 사용하면 단일 드로우 콜을 유지하면서 인스턴스 그리기의 순서를 지정할 수 있어 정렬 문제를 완화할 수 있습니다 [3, 10].
   - **인덱스 버퍼 업데이트:** 정점 버퍼(Vertex Buffer) 대신 인덱스 버퍼(Index Buffer)를 업데이트하여 객체를 정렬하거나 인스턴스화하는 것도 오버헤드를 줄이는 효과적인 저수준 최적화 기법입니다 [11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -32,8 +32,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Sorting"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], BatchedMesh, [[Overdraw]], [[Alpha Blending]], [[Frustum Culling]], [[Radix Sort]]
-- **Projects/Contexts:** Three.js, [[InstancedMesh2]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], BatchedMesh, Overdraw, Alpha Blending, [[Frustum Culling|Frustum Culling]], [[Radix Sort|Radix Sort]]
+- **Projects/Contexts:** Three.js, [[InstancedMesh2|InstancedMesh2]]
 - **Contradictions/Notes:** 투명도 및 오버드로우 해결을 위해 정렬이 필수적이지만, 정렬 연산 자체(버퍼 재배열 등)가 CPU에 큰 부하를 가하기 때문에 오히려 전체 프레임 레이트를 떨어뜨리는 역설적인 결과를 낳을 수 있습니다. 이는 GPU 압박과 CPU 병목 사이의 가혹한 절충안을 요구합니다 [1, 2, 7, 8].
 
 ---

10_Wiki/Topics/Graphics & Performance/Spatial Partitioning.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-1BF809
+id: [[P-Reinforce|P-Reinforce]]-AUTO-1BF809
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,15 +7,15 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Spatial Partitioning"
 ---
 
-# [[Spatial Partitioning]]
+# [[Spatial Partitioning|Spatial Partitioning]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 공간 분할(Spatial Partitioning)은 3D 그래픽스에서 대규모 씬(Scene)의 수많은 객체나 복잡한 기하학적 구조를 효율적으로 렌더링하고 관리하기 위한 최적화 기법입니다. 3D 공간을 BVH(Bounding Volume Hierarchy)나 옥트리(Octree)와 같은 계층적 인덱스 자료구조로 분할하여 관리함으로써, 시스템이 시야 밖의 객체를 조기에 연산에서 제외(Culling)할 수 있게 합니다 [1]. 이를 통해 광선 추적([[Raycasting]]) 상호작용의 속도를 높이고, 프러스텀 컬링의 효율성을 극대화하여 CPU 및 GPU의 과부하를 방지하는 핵심적인 역할을 수행합니다 [1-3].
+> 공간 분할(Spatial Partitioning)은 3D 그래픽스에서 대규모 씬(Scene)의 수많은 객체나 복잡한 기하학적 구조를 효율적으로 렌더링하고 관리하기 위한 최적화 기법입니다. 3D 공간을 BVH(Bounding Volume Hierarchy)나 옥트리(Octree)와 같은 계층적 인덱스 자료구조로 분할하여 관리함으로써, 시스템이 시야 밖의 객체를 조기에 연산에서 제외(Culling)할 수 있게 합니다 [1]. 이를 통해 광선 추적([[Raycasting|Raycasting]]) 상호작용의 속도를 높이고, 프러스텀 컬링의 효율성을 극대화하여 CPU 및 GPU의 과부하를 방지하는 핵심적인 역할을 수행합니다 [1-3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **자료구조의 종류:** 주로 BVH(Bounding Volume Hierarchy) 및 옥트리(Octree)와 같은 계층적 공간 인덱스(Hierarchical spatial index)를 활용하여 전체 씬을 여러 공간 노드로 나눕니다 [1, 4]. 한편, 실내 건축(Arch domain) 환경과 같은 특수한 경우에는 방(Room)과 문(Portal)을 연결하는 공간-포털(Cell-portal) 접근법이 매우 직관적이고 효과적인 공간 분할법으로 채택되기도 합니다 [5].
-- **시야 절두체 컬링([[Frustum Culling]]) 최적화:** 렌더러는 상위 레벨의 공간 노드를 카메라의 시야 프러스텀과 먼저 대조하여, 노드가 시야 내에 있을 때만 개별 컴포넌트 하위로 탐색해 내려갑니다 [1]. 이를 통해 보이지 않는 객체의 교차 테스트와 바운딩 스피어 계산을 과감히 생략할 수 있어 연산 자원을 대폭 절약할 수 있습니다 [1]. 대량의 `[[InstancedMesh]]` 환경에서도 전체를 하나로 관리하기보다는 공간적으로 인접한 소규모 인스턴스 그룹 단위로 분할 관리하는 전략을 취해야 컬링 정밀도가 높아져 GPU 낭비를 막을 수 있습니다 [3].
-- **레이캐스팅 가속 (Raycasting Acceleration):** 수만 개의 폴리곤 또는 대규모 인스턴스 씬에서 사용자의 피킹(Picking) 상호작용을 즉각적으로 처리하려면 정교한 공간 분할 자료구조 구축이 필수적입니다 [6]. `[[three-mesh-bvh]]`와 같은 라이브러리는 공간 인덱싱(BVH)을 구현하여 8만 개 이상의 폴리곤에 대해서도 60fps를 유지하며 매우 빠른 레이캐스팅과 공간 쿼리(Spatial queries) 성능을 제공합니다 [2, 7].
+- **시야 절두체 컬링([[Frustum Culling|Frustum Culling]]) 최적화:** 렌더러는 상위 레벨의 공간 노드를 카메라의 시야 프러스텀과 먼저 대조하여, 노드가 시야 내에 있을 때만 개별 컴포넌트 하위로 탐색해 내려갑니다 [1]. 이를 통해 보이지 않는 객체의 교차 테스트와 바운딩 스피어 계산을 과감히 생략할 수 있어 연산 자원을 대폭 절약할 수 있습니다 [1]. 대량의 `[[InstancedMesh|InstancedMesh]]` 환경에서도 전체를 하나로 관리하기보다는 공간적으로 인접한 소규모 인스턴스 그룹 단위로 분할 관리하는 전략을 취해야 컬링 정밀도가 높아져 GPU 낭비를 막을 수 있습니다 [3].
+- **레이캐스팅 가속 (Raycasting Acceleration):** 수만 개의 폴리곤 또는 대규모 인스턴스 씬에서 사용자의 피킹(Picking) 상호작용을 즉각적으로 처리하려면 정교한 공간 분할 자료구조 구축이 필수적입니다 [6]. `[[three-mesh-bvh|three-mesh-bvh]]`와 같은 라이브러리는 공간 인덱싱(BVH)을 구현하여 8만 개 이상의 폴리곤에 대해서도 60fps를 유지하며 매우 빠른 레이캐스팅과 공간 쿼리(Spatial queries) 성능을 제공합니다 [2, 7].
 - **대규모 환경 및 로딩 관리:** 거대한 오픈 월드 엔진이나 대형 건축물 씬에서 공간 인덱싱은 단순한 렌더링 가속을 넘어, 라이팅(Lighting), 충돌(Collisions), 에셋의 RAM 메모리 로드 및 폐기, 그리고 청크 단위의 월드 콘텐츠 스트리밍(Chunked world content streaming) 등 여러 시스템의 부하를 조율하는 핵심적인 뼈대 역할을 수행합니다 [5, 8].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Spatial Partitioning"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], BVH (Bounding Volume Hierarchy), Octree, [[InstancedMesh]], [[Raycasting]]
-- **Projects/Contexts:** [[three-mesh-bvh]], Tesseract Engine
+- **Related Topics:** [[Frustum Culling|Frustum Culling]], BVH (Bounding Volume Hierarchy), Octree, InstancedMesh, [[Raycasting|Raycasting]]
+- **Projects/Contexts:** [[three-mesh-bvh|three-mesh-bvh]], Tesseract Engine
 - **Contradictions/Notes:** 대규모 환경에서 레이캐스팅 및 렌더링 최적화를 위해 공간 인덱스(Spatial index)를 활용하는 것은 명확한 성능 향상을 제공하지만, 이러한 공간 분할 자료구조를 구축하고 유지하는 데에는 상당한 복잡성(non-trivial complexity)이 수반되며 구현 난이도가 높다는 개발자들의 논의가 존재합니다 [6, 9].
 
 ---

10_Wiki/Topics/Graphics & Performance/Spectre and Meltdown.md

@@ -1,26 +1,26 @@
 ---
-id: [[P-Reinforce]]-AUTO-8FCA7F
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8FCA7F
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Spectre]] and Meltdown"
+github_commit: "[P-Reinforce] Continuous Worker - [[Spectre|Spectre]] and Meltdown"
 ---
 
-# [[Spectre and Meltdown]]
+# [[Spectre and Meltdown|Spectre and Meltdown]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Spectre와 Meltdown은 현대 프로세서의 투기적 실행([[Speculative Execution]]) 과정에서 발생하는 취약점을 악용하여, 공격자가 접근 권한이 없는 메모리 영역의 비밀 데이터를 읽을 수 있게 하는 보안 결함이다 [1, 2]. 웹 브라우저 환경에서는 캐시 적중률과 메모리 접근 패턴의 미세한 시간 차이를 측정하는 타이밍 공격을 통해 이 취약점이 실행될 수 있다 [3-6]. 이를 방지하기 위해 브라우저 엔진들은 타이머의 정밀도를 낮추고 분기 없는 보안 검사를 도입하였으며, 이는 결과적으로 GPU 및 [[WebGL]] 파이프라인 연산의 미세 지연(micro-latency)을 소폭 증가시켰다 [7-9].
+> Spectre와 Meltdown은 현대 프로세서의 투기적 실행([[Speculative Execution|Speculative Execution]]) 과정에서 발생하는 취약점을 악용하여, 공격자가 접근 권한이 없는 메모리 영역의 비밀 데이터를 읽을 수 있게 하는 보안 결함이다 [1, 2]. 웹 브라우저 환경에서는 캐시 적중률과 메모리 접근 패턴의 미세한 시간 차이를 측정하는 타이밍 공격을 통해 이 취약점이 실행될 수 있다 [3-6]. 이를 방지하기 위해 브라우저 엔진들은 타이머의 정밀도를 낮추고 분기 없는 보안 검사를 도입하였으며, 이는 결과적으로 GPU 및 [[WebGL|WebGL]] 파이프라인 연산의 미세 지연(micro-latency)을 소폭 증가시켰다 [7-9].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **투기적 실행과 메모리 접근 타이밍 악용:**
-  Spectre와 Meltdown은 CPU가 성능 향상을 위해 분기문의 결과를 예측하고 미리 코드를 실행하는 '투기적 실행'을 악용한다 [2]. CPU는 예측이 틀렸을 경우 실행 상태를 롤백하지만, 이 과정에서 메인 메모리에서 L1 캐시로 데이터를 로드한 흔적은 그대로 남게 된다 [2, 5]. 공격자는 고정밀 타이머를 사용하여 특정 메모리 배열(예: `otherArray`과 `otherArray[10]`)에 대한 접근 속도 차이를 측정함으로써 캐시에 로드된 데이터를 추론하는 타이밍 기반 정보 유출 공격을 수행할 수 있다 [5, 6]. [[WebKit]]과 같은 [[JavaScript]] 엔진에서 악의적인 스크립트가 실행될 경우, 경계 검사(bounds check)나 타입 검사를 우회하여 프로세스 주소 공간의 임의의 메모리를 읽을 위험이 있다 [11, 12].
+  Spectre와 Meltdown은 CPU가 성능 향상을 위해 분기문의 결과를 예측하고 미리 코드를 실행하는 '투기적 실행'을 악용한다 [2]. CPU는 예측이 틀렸을 경우 실행 상태를 롤백하지만, 이 과정에서 메인 메모리에서 L1 캐시로 데이터를 로드한 흔적은 그대로 남게 된다 [2, 5]. 공격자는 고정밀 타이머를 사용하여 특정 메모리 배열(예: `otherArray`과 `otherArray[10]`)에 대한 접근 속도 차이를 측정함으로써 캐시에 로드된 데이터를 추론하는 타이밍 기반 정보 유출 공격을 수행할 수 있다 [5, 6]. [[WebKit|WebKit]]과 같은 [[JavaScript|JavaScript]] 엔진에서 악의적인 스크립트가 실행될 경우, 경계 검사(bounds check)나 타입 검사를 우회하여 프로세스 주소 공간의 임의의 메모리를 읽을 위험이 있다 [11, 12].
 
 - **브라우저의 보안 완화 조치 (타이머 정밀도 감소 및 지터 도입):**
-  고해상도 타이밍 공격을 막기 위해 WebKit과 [[Blink]] 등의 브라우저 엔진은 `performance.now()`의 정밀도를 1ms 또는 100 마이크로초 수준으로 대폭 낮추고, 반환되는 시간 값에 무작위 변동성인 '지터(jitter)'를 추가하였다 [7, 9, 13]. 또한, 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer`를 비활성화하였다 [9]. [[WebGPU]]의 `timestamp-query` 기능 역시 타이밍 공격 우려로 인해 양자화([[Quantization]])를 적용하여 격리된 컨텍스트에서도 해상도를 100 마이크로초로 제한하였다 [14-16]. 과거 WebGL에서는 `EXT_disjoint_timer_query` 확장을 통해 프레임 지연을 정밀하게 측정할 수 있었으나, 이 역시 동일한 보안 이유로 인해 최신 브라우저들에서 비활성화되거나 제한되었다 [3, 4].
+  고해상도 타이밍 공격을 막기 위해 WebKit과 [[Blink|Blink]] 등의 브라우저 엔진은 `performance.now()`의 정밀도를 1ms 또는 100 마이크로초 수준으로 대폭 낮추고, 반환되는 시간 값에 무작위 변동성인 '지터(jitter)'를 추가하였다 [7, 9, 13]. 또한, 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer`를 비활성화하였다 [9]. WebGPU의 `timestamp-query` 기능 역시 타이밍 공격 우려로 인해 양자화([[Quantization|Quantization]])를 적용하여 격리된 컨텍스트에서도 해상도를 100 마이크로초로 제한하였다 [14-16]. 과거 WebGL에서는 `EXT_disjoint_timer_query` 확장을 통해 프레임 지연을 정밀하게 측정할 수 있었으나, 이 역시 동일한 보안 이유로 인해 최신 브라우저들에서 비활성화되거나 제한되었다 [3, 4].
 
-- **분기 없는 보안 검사([[Branchless Security Checks]]) 도입:**
-  브라우저는 타이머 조작 외에도 투기적 실행 자체의 부작용을 방어하기 위해 인덱스 마스킹([[Index Masking]])과 포인터 포이즈닝([[Pointer Poisoning]]) 같은 분기 없는 보안 검사 기법을 도입했다 [17, 18]. 인덱스 마스킹은 비트 연산을 사용하여 투기적 실행 중에도 배열 인덱스가 항상 유효한 범위 내에 있도록 강제한다 [17, 19]. 포인터 포이즈닝은 포인터에 임의의 값을 XOR 연산하여, 잘못된 투기적 분기가 일어날 경우 매핑되지 않은 유효하지 않은 메모리를 가리키도록 유도한다 [17, 20].
+- **분기 없는 보안 검사([[Branchless Security Checks|Branchless Security Checks]]) 도입:**
+  브라우저는 타이머 조작 외에도 투기적 실행 자체의 부작용을 방어하기 위해 인덱스 마스킹([[Index Masking|Index Masking]])과 포인터 포이즈닝([[Pointer Poisoning|Pointer Poisoning]]) 같은 분기 없는 보안 검사 기법을 도입했다 [17, 18]. 인덱스 마스킹은 비트 연산을 사용하여 투기적 실행 중에도 배열 인덱스가 항상 유효한 범위 내에 있도록 강제한다 [17, 19]. 포인터 포이즈닝은 포인터에 임의의 값을 XOR 연산하여, 잘못된 투기적 분기가 일어날 경우 매핑되지 않은 유효하지 않은 메모리를 가리키도록 유도한다 [17, 20].
 
 - **그래픽스 파이프라인의 미세 지연(Micro-latency)에 미치는 영향:**
   이러한 보안 완화 조치들은 웹 타이밍 보안을 위해 필수적이지만, JavaScript 엔진과 JIT(Just-In-Time) 컴파일러가 수행하는 그래픽스 실행 중요 경로(critical path)에 추가적인 명령어를 삽입하게 만든다 [8]. 결과적으로 이는 그래픽스 파이프라인 내에서 수행되는 모든 연산의 기본 미세 지연(base micro-latency)을 약간 증가시키는 원인이 된다 [8].
@@ -30,8 +30,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Spectre]] and Meltdown"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** EXT_disjoint_timer_query, [[Timestamp Queries Quantization]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit Security Mitigations]], WebGPU / WebGL Timing API Security
+- **Related Topics:** EXT_disjoint_timer_query, [[Timestamp Queries Quantization|Timestamp Queries Quantization]], [[Branchless Security Checks|Branchless Security Checks]]
+- **Projects/Contexts:** [[WebKit Security Mitigations|WebKit Security Mitigations]], WebGPU / WebGL Timing API Security
 - **Contradictions/Notes:** 소스에는 Spectre 및 Meltdown 취약점으로 인해 도입된 브라우저 엔진의 보안 조치(타이머 정밀도 하향, 분기 없는 보안 검사 추가 등)가 그래픽스 파이프라인의 전반적인 미세 지연을 증가시킨다는 사실은 설명되어 있으나 [8], 루트 주제에서 명시한 '브라우저 메모리 할당 시점별' 미세 지연의 변화를 직접적으로 측정한 구체적인 실험 사례나 수치에 대해서는 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Spring Framework.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-C45BD6
+id: [[P-Reinforce|P-Reinforce]]-AUTO-C45BD6
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,14 +7,14 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Spring Framework"
 ---
 
-# [[Spring Framework]]
+# [[Spring Framework|Spring Framework]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > Spring Framework는 자바(Java) 환경에서 사용되는 프레임워크로, 주로 내장된 DI(의존성 주입) 컨테이너를 통해 컴포넌트 간의 결합도를 낮추는 역할을 합니다 [1]. 또한 런타임 시점에 적용되는 Spring AOP를 지원하여 트랜잭션 관리 및 캐시 처리와 같은 횡단 관심사의 모듈화를 돕습니다 [2, 3]. 다만 제공된 문헌에는 Spring Framework의 전반적인 아키텍처나 생태계 전반을 다루는 내용이 없어, 소스에 관련 정보가 부족합니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **의존성 주입(DI)과 결합도 감소**
-  Spring Framework는 내장된 의존성 주입(Dependency Injection) 컨테이너를 제공하여 SOLID 원칙 중 하나인 의존성 역전 원칙(Dependency [[Inversion]] Principle, DIP)을 훨씬 쉽게 구현할 수 있도록 지원합니다 [1]. 이를 통해 소프트웨어 컴포넌트들을 효과적으로 분리(decoupling)하고 유연한 설계를 가능하게 합니다 [1].
+  Spring Framework는 내장된 의존성 주입(Dependency Injection) 컨테이너를 제공하여 SOLID 원칙 중 하나인 의존성 역전 원칙(Dependency [[Inversion|Inversion]] Principle, DIP)을 훨씬 쉽게 구현할 수 있도록 지원합니다 [1]. 이를 통해 소프트웨어 컴포넌트들을 효과적으로 분리(decoupling)하고 유연한 설계를 가능하게 합니다 [1].
 
 * **Spring AOP (관점 지향 프로그래밍) 지원**
   * **런타임 위빙(Runtime Weaving):** Spring AOP는 애플리케이션의 실제 코드와 Aspect를 결합하는 위빙 과정에 있어 프로그램 실행 시점에 적용되는 런타임 위빙 방식을 사용합니다 [2].
@@ -29,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Spring Framework"
 
 ## 🔗 지식 연결 (Graph)
 - **Related Topics:** Dependency Injection (DI), Aspect-Oriented Programming (AOP)
-- **Projects/Contexts:** SOLID [[Principles]], [[객체 지향 프로그래밍 (OOP)]]
+- **Projects/Contexts:** SOLID [[Principles|Principles]], [[객체 지향 프로그래밍 (OOP)|객체 지향 프로그래밍 (OOP]]
 - **Contradictions/Notes:** 소스에 따르면 Spring AOP는 런타임에 적용되어 유용한 모듈화를 제공하지만, 오직 메서드 실행 시점의 조인 포인트만 지원하는 한계가 있어 더 정밀한 제어를 원할 경우 AspectJ 사용이 권장됩니다 [4, 5].
 
 ---

10_Wiki/Topics/Graphics & Performance/TLB design.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-3CAF83
+id: [[P-Reinforce|P-Reinforce]]-AUTO-3CAF83
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,7 +7,7 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - TLB design"
 ---
 
-# [[TLB design]]
+# [[TLB design|TLB design]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 소스에 관련 정보가 부족합니다. 제공된 문헌에는 TLB design(Translation Lookaside Buffer 설계)에 대한 직접적이고 구체적인 정의나 기술적 설명이 포함되어 있지 않습니다.
@@ -17,7 +17,7 @@ github_commit: "[P-Reinforce] Continuous Worker - TLB design"
 
 제공된 소스에서 'TLB design'과 관련하여 파악할 수 있는 유일한 단편적인 정보는 다음과 같습니다:
 
-* **GPU 보안 취약점과의 연관성:** 과거 [[WebGL]]을 통해 GPU에서 [[Rowhammer]] 공격을 실행한 심각한 보안 사례가 보고된 바 있습니다. 공격자들은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 확인하고 GPU의 물리적 메모리 레이아웃을 파악하여 특정 비트를 조작(flip)했습니다 [1].
+* **GPU 보안 취약점과의 연관성:** 과거 [[WebGL|WebGL]]을 통해 GPU에서 [[Rowhammer|Rowhammer]] 공격을 실행한 심각한 보안 사례가 보고된 바 있습니다. 공격자들은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 확인하고 GPU의 물리적 메모리 레이아웃을 파악하여 특정 비트를 조작(flip)했습니다 [1].
 * **특정 설계에 국한된 공격:** 이 정교한 공격이 가능했던 이유는 공격 대상이 된 기기가 "매우 명확하게 정의된 TLB 설계(TLB design)"를 가지고 있었기 때문입니다. 즉, 특정 TLB 설계 구조가 해당 보안 취약점(Rowhammer)이 성립하기 위한 조건 중 하나로 작용했습니다 [1].
 * **최신 하드웨어의 방어:** 이러한 특정 TLB 설계를 타겟으로 한 공격은 최신 RAM에 적용된 Rowhammer 방어 기법(mitigations)을 통해 예방되었습니다 [1].
 
@@ -26,8 +26,8 @@ github_commit: "[P-Reinforce] Continuous Worker - TLB design"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Rowhammer]], [[WebGL]]
-- **Projects/Contexts:** [[WebGPU]] High Re[[Solution]] Time Spec
+- **Related Topics:** [[Rowhammer|Rowhammer]], [[WebGL|WebGL]]
+- **Projects/Contexts:** [[WebGPU|WebGPU]] High Re[[Solution|Solution]] Time Spec
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/TSL (Three Shader Language).md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-C8966B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-C8966B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,24 +7,24 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - TSL (Three Shader Language)"
 ---
 
-# [[TSL (Three Shader Language)]]
+# [[TSL (Three Shader Language)|TSL (Three Shader Language]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> TSL (Three Shader Language)은 Three.js의 노드 기반 머티리얼 시스템입니다 [1]. 셰이더를 한 번 작성하면 [[WebGPU]]용 WGSL과 [[WebGL]]용 GLSL로 자동 컴파일되어 실행될 수 있게 해줍니다 [1, 2]. 로우 레벨(Raw) 셰이더를 직접 작성하는 것을 대체하며, 향후 Three.js에서 커스텀 셰이더를 구현하기 위한 권장 방식입니다 [1, 3].
+> TSL (Three Shader Language)은 Three.js의 노드 기반 머티리얼 시스템입니다 [1]. 셰이더를 한 번 작성하면 [[WebGPU|WebGPU]]용 WGSL과 [[WebGL|WebGL]]용 GLSL로 자동 컴파일되어 실행될 수 있게 해줍니다 [1, 2]. 로우 레벨(Raw) 셰이더를 직접 작성하는 것을 대체하며, 향후 Three.js에서 커스텀 셰이더를 구현하기 위한 권장 방식입니다 [1, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **교차 컴파일 및 자동화**: TSL은 GLSL과 WGSL 두 개의 별도 코드베이스를 유지할 필요가 없도록 교차 컴파일을 지원합니다 [3]. 또한, 유니폼(Uniform)과 속성(Attribute) 데이터 처리를 자동으로 핸들링하여 개발 복잡도를 줄여줍니다 [3].
 - **동적 노드 머티리얼(Node Materials) 제어**: TSL 기반의 노드 머티리얼은 합성(Composable)이 가능하며, `positionNode`, `colorNode`, `normalNode`와 같은 속성을 통해 프로그래밍 방식으로 제어할 수 있어 기존 WebGL에서는 커스텀 셰이더가 필요했던 효과들을 동적으로 구현할 수 있습니다 [3, 4].
 - **재사용 가능한 셰이더 로직(Fn 패턴)**: `Fn` 패턴을 사용하여 재사용 가능한 셰이더 함수를 작성할 수 있습니다 [5]. 이렇게 작성된 함수는 한 번 컴파일된 후 여러 머티리얼에 걸쳐 재사용이 가능합니다 [5].
 - **내장 노이즈 함수**: TSL에는 MaterialX 노이즈 함수가 기본적으로 내장되어 있어, 외부 라이브러리에 의존하지 않고도 노이즈 효과를 구현할 수 있습니다 [5].
-- **WebGPU 네이티브 포스트 프로세싱**: WebGPU 기반의 프로젝트에서는 `pmndrs/post[[Processing]]` 라이브러리 대신 TSL 노드를 사용하는 Three.js 내장 포스트 프로세싱을 사용하는 것이 컴퓨트 셰이더를 완벽히 지원하는 네이티브 해결책입니다 [6].
+- **WebGPU 네이티브 포스트 프로세싱**: WebGPU 기반의 프로젝트에서는 `pmndrs/post[[Processing|Processing]]` 라이브러리 대신 TSL 노드를 사용하는 Three.js 내장 포스트 프로세싱을 사용하는 것이 컴퓨트 셰이더를 완벽히 지원하는 네이티브 해결책입니다 [6].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], WGSL, GLSL, Node Material
+- **Related Topics:** [[WebGPU|WebGPU]], [[WebGL|WebGL]], WGSL, GLSL, Node Material
 - **Projects/Contexts:** Three.js
 - **Contradictions/Notes:** 소스 간의 모순점은 없으나, 이전의 렌더링 방식과 달리 별도의 GLSL/WGSL 코드를 직접 작성하는 것보다 TSL을 사용하는 것이 코드 유지보수 및 교차 호환성 측면에서 명백히 우월하다고 강조하고 있습니다 [3].
 

10_Wiki/Topics/Graphics & Performance/Texture Compression.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-B90AAF
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B90AAF
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,7 +7,7 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Texture Compression"
 ---
 
-# [[Texture Compression]]
+# [[Texture Compression|Texture Compression]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 텍스처 압축(Texture Compression)은 웹 기반 3D 애플리케이션(예: Three.js)에서 GPU 메모리(VRAM) 소비와 파일 다운로드 크기를 획기적으로 줄이기 위한 필수 최적화 기술입니다 [1-3]. PNG나 JPEG와 같은 일반적인 이미지 포맷이 GPU 메모리 내에서 압축이 완전히 풀리는 것과 달리, KTX2나 Basis Universal 같은 포맷은 GPU 상에서도 압축된 상태를 유지하여 하드웨어 가속 압축 해제를 지원합니다 [1, 3]. 이를 통해 메모리 대역폭 요구량을 줄이고 저사양 기기에서의 브라우저 크래시나 프레임 저하를 방지할 수 있습니다 [2, 3].
@@ -30,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Texture Compression"
 
 ## 🔗 지식 연결 (Graph)
 - **Related Topics:** KTX2, Basis Universal, UASTC, ETC1S, VRAM
-- **Projects/Contexts:** Three.js, [[WebGL]], gltf-compressor
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]], gltf-compressor
 - **Contradictions/Notes:** 소스에 내용 충돌은 없으며, PNG/JPEG 포맷은 파일 크기(예: 200KB)가 작더라도 GPU 메모리에 올라갈 때 압축이 해제되어 막대한 VRAM(예: 20MB+)을 소모하므로 KTX2와 같은 전용 텍스처 압축 기술이 필수적이라고 일관되게 강조하고 있습니다 [1].
 
 ---

10_Wiki/Topics/Graphics & Performance/Three Shader Language (TSL).md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-1AF9EB
+id: [[P-Reinforce|P-Reinforce]]-AUTO-1AF9EB
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,25 +7,25 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Three Shader Language (TSL)"
 ---
 
-# [[Three Shader Language (TSL)]]
+# [[Three Shader Language (TSL)|Three Shader Language (TSL]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> TSL(Three Shader Language)은 [[WebGPU]]의 WGSL과 [[WebGL]]의 GLSL로 모두 컴파일될 수 있는 Three.js의 노드 기반 머티리얼 및 셰이더 시스템입니다 [1]. 개발자가 셰이더 코드를 한 번만 작성하면 여러 플랫폼에서 실행 가능하도록 자동 교차 컴파일을 지원하여 코드 중복을 방지합니다 [1-3]. 유니폼 및 속성 관리를 자동으로 처리해주며, 향후 Three.js에서 커스텀 셰이더를 개발하기 위한 권장 방식으로 평가받고 있습니다 [1, 2, 4].
+> TSL(Three Shader Language)은 [[WebGPU|WebGPU]]의 WGSL과 [[WebGL|WebGL]]의 GLSL로 모두 컴파일될 수 있는 Three.js의 노드 기반 머티리얼 및 셰이더 시스템입니다 [1]. 개발자가 셰이더 코드를 한 번만 작성하면 여러 플랫폼에서 실행 가능하도록 자동 교차 컴파일을 지원하여 코드 중복을 방지합니다 [1-3]. 유니폼 및 속성 관리를 자동으로 처리해주며, 향후 Three.js에서 커스텀 셰이더를 개발하기 위한 권장 방식으로 평가받고 있습니다 [1, 2, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **단일 코드베이스와 자동 교차 컴파일:** TSL은 원시(raw) GLSL 또는 WGSL을 직접 작성하여 두 개의 셰이더 코드베이스를 유지해야 하는 수고를 덜어줍니다 [2]. 작성된 코드는 WebGPU 및 WebGL 환경 모두에 맞춰 자동으로 교차 컴파일되며, 유니폼(uniforms) 및 속성(attributes) 처리 역시 TSL이 자동으로 관리합니다 [2, 4].
 *   **노드 기반 머티리얼 제어:** TSL의 노드 머티리얼은 조합이 가능(composable)하며, `positionNode`, `colorNode`, `normalNode`와 같은 속성을 수용하여 프로그래밍 방식의 제어를 지원합니다 [2, 5]. 이를 통해 기존 WebGL 환경에서는 별도의 복잡한 커스텀 셰이더를 작성해야만 했던 동적인 렌더링 효과를 더 쉽게 구현할 수 있습니다 [5].
 *   **코드 재사용성 및 내장 함수:** 개발자는 `Fn` 패턴을 활용하여 재사용 가능한 TSL 함수를 작성할 수 있으며, 이 함수들은 한 번 컴파일된 후 여러 머티리얼에 걸쳐 자유롭게 재사용할 수 있습니다 [6]. 또한, MaterialX 노이즈 함수와 같은 유용한 기능들이 내장되어 있어 외부 라이브러리에 의존하지 않고도 노이즈 관련 셰이더 로직을 구현할 수 있습니다 [6].
-*   **WebGPU 포스트 프로세싱 지원:** WebGPU 기반 프로젝트의 경우, TSL 노드와 결합된 Three.js의 내장(native) 포스트 프로세싱 기능을 사용하는 것이 권장됩니다 [7]. 이는 전체 컴퓨트 셰이더([[Compute Shader]]) 지원이 통합된 WebGPU용 네이티브 솔루션으로 작동합니다 [7].
+*   **WebGPU 포스트 프로세싱 지원:** WebGPU 기반 프로젝트의 경우, TSL 노드와 결합된 Three.js의 내장(native) 포스트 프로세싱 기능을 사용하는 것이 권장됩니다 [7]. 이는 전체 컴퓨트 셰이더([[Compute Shader|Compute Shader]]) 지원이 통합된 WebGPU용 네이티브 솔루션으로 작동합니다 [7].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], WGSL, GLSL, Node Material
+- **Related Topics:** [[WebGPU|WebGPU]], [[WebGL|WebGL]], WGSL, GLSL, Node Material
 - **Projects/Contexts:** Three.js 크로스 플랫폼 커스텀 셰이더 및 포스트 프로세싱 개발
-- **Contradictions/Notes:** 기존 WebGL 프로젝트에서는 외부 라이브러리인 `pmndrs/post[[Processing]]`이 여전히 훌륭한 선택지로 평가되지만, WebGPU 프로젝트 환경에서는 TSL 노드 기반의 Three.js 네이티브 포스트 프로세싱을 사용하는 것으로 개발 방식이 전환될 것을 권장하고 있습니다 [7].
+- **Contradictions/Notes:** 기존 WebGL 프로젝트에서는 외부 라이브러리인 `pmndrs/post[[Processing|Processing]]`이 여전히 훌륭한 선택지로 평가되지만, WebGPU 프로젝트 환경에서는 TSL 노드 기반의 Three.js 네이티브 포스트 프로세싱을 사용하는 것으로 개발 방식이 전환될 것을 권장하고 있습니다 [7].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Three.js 렌더링 최적화.md

@@ -1,13 +1,13 @@
 ---
-id: [[P-Reinforce]]-AI-046
+id: [[P-Reinforce|P-Reinforce]]-AI-046
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.97
-tags: [three.js, [[WebGL]], rendering, [[Optimization]]]
+tags: [three.js, [[WebGL|WebGL]], rendering, [[Optimization|Optimization]]]
 last_reinforced: 2026-06-XX
 github_commit: "[P-Reinforce] Processed Three.js WebGL 렌더링 최적화."
 ---
 
-# [[Three.js 렌더링 최적화]] (이전 배치와 동일한 내용)
+# [[Three.js 렌더링 최적화|Three.js 렌더링 최적화]] (이전 배치와 동일한 내용)
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 대규모 웹 환경에서 WebGL 기반 3D 씬을 구현할 때, 단순한 모델 로딩 이상의 관점에서 드로우 콜 감소, 자원 재활용, 그리고 GPU/CPU 부하 분산을 통해 성능 병목을 해결하는 것이 핵심이다.
@@ -15,15 +15,15 @@ github_commit: "[P-Reinforce] Processed Three.js WebGL 렌더링 최적화."
 ## 📖 구조화된 지식 (Synthesized Content)
 - **성능 최적화의 목표:** 웹 브라우저 환경에서 높은 프레임률(60FPS 이상)을 유지하면서 복잡한 3D 시각화를 구현하는 것이다. 주요 병목 구간은 CPU/GPU 자원 관리와 데이터 전송량에 있다.
 - **핵심 기술 및 전략:** (생략 - 핵심 내용은 이미 위키화 되어있음)
-    1. **드로우 콜 최적화 ([[Draw Call]] Optimization):** [[Instancing]], [[Batching]]을 통해 GPU 부하를 줄인다.
-    2. **자원 관리 (Resource [[Management]]):** Dispose() 호출을 통한 메모리 누수 방지 및 효율적인 자원 재활용.
+    1. **드로우 콜 최적화 ([[Draw Call|Draw Call]] Optimization):** Instancing, [[Batching|Batching]]을 통해 GPU 부하를 줄인다.
+    2. **자원 관리 (Resource [[Management|Management]]):** Dispose() 호출을 통한 메모리 누수 방지 및 효율적인 자원 재활용.
     3. **렌더링 기법 개선:** LOD, Culling 등 하드웨어 기반 최적화 적용.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **정책 변화:** [[WebGPU]]의 도입은 기존 WebGL의 한계를 뛰어넘는 가장 중요한 패러다임 전환점이며, 이를 활용한 컴퓨팅 기능([[Compute Shader]])이 핵심 트렌드로 부상 중이다.
+- **정책 변화:** [[WebGPU|WebGPU]]의 도입은 기존 WebGL의 한계를 뛰어넘는 가장 중요한 패러다임 전환점이며, 이를 활용한 컴퓨팅 기능([[Compute Shader|Compute Shader]])이 핵심 트렌드로 부상 중이다.
 
 ## 🔗 지식 연결 (Graph)
-- Parent: [[WebGL Optimization]]
-- Related: [[InstancedMesh]] , [[Draw Call Optimization]] , [[WebGPU]]
+- Parent: [[WebGL Optimization|WebGL Optimization]]
+- Related: [[InstancedMesh|InstancedMesh]] , Draw Call Optimization , [[WebGPU|WebGPU]]
 
 ---

10_Wiki/Topics/Graphics & Performance/Threejs WebGL Rendering Optimization.md

@@ -1,48 +1,48 @@
 ---
-id: [[P-Reinforce]]-AUTO-46187E
+id: [[P-Reinforce|P-Reinforce]]-AUTO-46187E
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] [[WebGL]] Rendering [[Optimization]]"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] WebGL Rendering [[Optimization|Optimization]]"
 ---
 
-# [[Threejs WebGL Rendering Optimization]]
+# [[Threejs WebGL Rendering Optimization|Threejs WebGL Rendering Optimization]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js WebGL 렌더링 최적화는 3D 웹 애플리케이션의 프레임 속도를 향상시키고 메모리 사용량을 줄이기 위한 기술적 접근 방식을 의미합니다 [1, 2]. 이 최적화의 핵심은 CPU와 GPU 간의 병목 현상을 유발하는 드로우 콜([[Draw Call]]) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [3, 4]. 이를 위해 `[[InstancedMesh]]`, `BatchedMesh`, 기하학 병합([[Geometry Merging]]), 텍스처 압축, 그리고 시야 절두체 컬링([[Frustum Culling]])과 같은 다양한 기법이 활용되며, 2026년 도입된 [[WebGPU]] 기술은 컴퓨트 셰이더를 통해 렌더링 한계를 더욱 확장시켰습니다 [3, 5-8].
+> Three.js WebGL 렌더링 최적화는 3D 웹 애플리케이션의 프레임 속도를 향상시키고 메모리 사용량을 줄이기 위한 기술적 접근 방식을 의미합니다 [1, 2]. 이 최적화의 핵심은 CPU와 GPU 간의 병목 현상을 유발하는 드로우 콜([[Draw Call|Draw Call]]) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [3, 4]. 이를 위해 `InstancedMesh`, `BatchedMesh`, 기하학 병합(Geometry Merging), 텍스처 압축, 그리고 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])과 같은 다양한 기법이 활용되며, 2026년 도입된 [[WebGPU|WebGPU]] 기술은 컴퓨트 셰이더를 통해 렌더링 한계를 더욱 확장시켰습니다 [3, 5-8].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-**드로우 콜 최적화 ([[Draw Call Optimization]])**
+**드로우 콜 최적화 ([[Draw Call Optimization|Draw Call Optimization]])**
 *   CPU가 GPU에 렌더링 명령을 내리는 드로우 콜은 상태 변경 및 준비 과정에서 막대한 오버헤드를 발생시킵니다 [4, 9, 10]. 매끄러운 60fps 성능을 유지하기 위해 프레임당 드로우 콜을 100회 미만으로 유지하는 것이 권장됩니다 [11-13].
 *   동일한 기하학적 구조와 재질을 가진 객체가 수백, 수천 개 반복될 때는 단일 드로우 콜로 렌더링을 처리할 수 있는 `InstancedMesh`를 사용하는 것이 가장 효율적입니다 [11, 14, 15].
 *   반면 재질은 공유하지만 각기 다른 기하학적 구조를 가진 객체들을 렌더링할 때는 `BatchedMesh`를 사용하여 하나의 드로우 콜로 묶을 수 있습니다 [5, 16, 17].
-*   정적인 환경 객체(건물, 지형 등)는 `[[BufferGeometry]]Utils`를 사용하여 로드 시점에 하나의 기하학으로 병합(Merge)하는 것이 유리합니다 [6, 16, 18]. 단, 병합된 객체는 개별적으로 애니메이션을 주거나 독립적인 컬링(Culling)을 적용할 수 없는 단점이 있습니다 [6, 18].
+*   정적인 환경 객체(건물, 지형 등)는 `[[BufferGeometry|BufferGeometry]]Utils`를 사용하여 로드 시점에 하나의 기하학으로 병합(Merge)하는 것이 유리합니다 [6, 16, 18]. 단, 병합된 객체는 개별적으로 애니메이션을 주거나 독립적인 컬링(Culling)을 적용할 수 없는 단점이 있습니다 [6, 18].
 
-**메모리 및 에셋 관리 ([[memory]] and Asset [[Management]])**
+**메모리 및 에셋 관리 ([[memory|memory]] and Asset [[Management|Management]])**
 *   Three.js는 GPU 리소스를 자동으로 가비지 컬렉션(Garbage Collect)하지 않으므로, 사용이 끝난 기하학, 재질, 텍스처, 렌더 타겟은 반드시 `.dispose()`를 호출하여 GPU 메모리에서 명시적으로 삭제해야 메모리 누수를 막을 수 있습니다 [19-21]. 
 *   3D 모델의 기하학적 데이터를 Draco로 압축하면 파일 크기를 90~95%까지 줄일 수 있으며, KTX2 (Basis Universal) 텍스처 압축을 사용하면 일반 PNG 대비 GPU 메모리(VRAM) 사용량을 대폭 절감할 수 있습니다 [12, 22-24].
-*   수많은 작은 텍스처들은 텍스처 아틀라스([[Texture Atlas]])나 배열 텍스처(Data Array Texture)로 결합하여 텍스처 바인딩 횟수를 줄여야 합니다 [25-27].
+*   수많은 작은 텍스처들은 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])나 배열 텍스처(Data Array Texture)로 결합하여 텍스처 바인딩 횟수를 줄여야 합니다 [25-27].
 
 **InstancedMesh의 구조적 한계와 성능 병목**
 *   **비효율적인 절두체 컬링(Frustum Culling):** `InstancedMesh`는 내부의 개별 인스턴스가 아닌, 전체 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 컬링을 수행합니다 [28]. 즉, 단 하나의 인스턴스만 시야에 있어도 화면 밖의 모든 인스턴스에 대해 강제적인 정점 연산이 발생하여 GPU 자원이 낭비될 수 있습니다 [28, 29].
-*   **오버드로우([[Overdraw]]) 발생:** `InstancedMesh` 내의 인스턴스들은 렌더링 순서가 자동 정렬되지 않으므로 앞뒤 객체 간 오버드로우(동일 픽셀 영역에 중복 계산)가 발생합니다 [30, 31]. 이는 불투명 객체의 프래그먼트 병목을 유발하고 투명한 객체에서는 심각한 시각적 오류를 발생시킵니다 [31, 32].
-*   **레이캐스팅([[Raycasting]]) 제약:** 움직이는 인스턴스들에 대해 레이캐스팅이 정상 작동하려면 인스턴스 행렬이 변경된 후 반드시 `computeBoundingSphere()`와 `computeBoundingBox()`를 호출하여 바운딩 볼륨을 다시 계산해야 합니다 [33, 34].
+*   **오버드로우([[Overdraw|Overdraw]]) 발생:** `InstancedMesh` 내의 인스턴스들은 렌더링 순서가 자동 정렬되지 않으므로 앞뒤 객체 간 오버드로우(동일 픽셀 영역에 중복 계산)가 발생합니다 [30, 31]. 이는 불투명 객체의 프래그먼트 병목을 유발하고 투명한 객체에서는 심각한 시각적 오류를 발생시킵니다 [31, 32].
+*   **레이캐스팅([[Raycasting|Raycasting]]) 제약:** 움직이는 인스턴스들에 대해 레이캐스팅이 정상 작동하려면 인스턴스 행렬이 변경된 후 반드시 `computeBoundingSphere()`와 `computeBoundingBox()`를 호출하여 바운딩 볼륨을 다시 계산해야 합니다 [33, 34].
 
 **셰이더, LOD 및 WebGPU 렌더링 파이프라인**
 *   카메라 거리에 따라 고해상도 메쉬를 저해상도 메쉬나 단순한 임포스터(빌보드)로 교체하는 LOD (Level of Detail) 시스템을 구현하면 프레임 속도를 크게 방어할 수 있습니다 [13, 35-37].
-*   저사양 통합 GPU 환경에서는 오버드로우로 인한 픽셀 처리 부하를 줄이기 위해 먼저 깊이(Depth)만 렌더링한 후(색상 쓰기 비활성화), 실제 렌더링에서 깊이 테스트를 EQUAL로 설정하여 가려진 픽셀 연산을 생략하는 '[[Depth Pre-Pass]]' 기법이 효과적입니다 [38, 39]. 또한 물리 기반 렌더링인 `MeshStandardMaterial` 대신 계산 비용이 저렴한 `MeshPhongMaterial`을 활용하면 성능 향상에 도움이 됩니다 [40, 41].
-*   2026년 기준, WebGL에서 WebGPU(`WebGPURenderer`)로 전환하면 컴퓨트 셰이더([[Compute Shader]]s)를 활용하여 CPU가 처리하던 대규모 파티클 시스템 업데이트, 물리 시뮬레이션 연산 등을 GPU 병렬 처리로 넘겨 비약적인 성능 향상(최대 100배)을 이룰 수 있습니다 [7, 42-45].
+*   저사양 통합 GPU 환경에서는 오버드로우로 인한 픽셀 처리 부하를 줄이기 위해 먼저 깊이(Depth)만 렌더링한 후(색상 쓰기 비활성화), 실제 렌더링에서 깊이 테스트를 EQUAL로 설정하여 가려진 픽셀 연산을 생략하는 '[[Depth Pre-Pass|Depth Pre-Pass]]' 기법이 효과적입니다 [38, 39]. 또한 물리 기반 렌더링인 `MeshStandardMaterial` 대신 계산 비용이 저렴한 `MeshPhongMaterial`을 활용하면 성능 향상에 도움이 됩니다 [40, 41].
+*   2026년 기준, WebGL에서 WebGPU(`WebGPURenderer`)로 전환하면 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)를 활용하여 CPU가 처리하던 대규모 파티클 시스템 업데이트, 물리 시뮬레이션 연산 등을 GPU 병렬 처리로 넘겨 비약적인 성능 향상(최대 100배)을 이룰 수 있습니다 [7, 42-45].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], BatchedMesh, [[Level of Detail (LOD)]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** Segments.ai WebGPU Migration, [[InstancedMesh2 Library]], Three.js WebGPURenderer (r171+)
+- **Related Topics:** [[Draw Call|Draw Call]], InstancedMesh, BatchedMesh, Level of Detail (LOD), [[Frustum Culling|Frustum Culling]], [[WebGPU|WebGPU]]
+- **Projects/Contexts:** Segments.ai WebGPU Migration, [[InstancedMesh2 library|InstancedMesh2 Library]], Three.js WebGPURenderer (r171+)
 - **Contradictions/Notes:** 
-  - `BatchedMesh`는 다수의 고유 기하학 객체를 단일 드로우 콜로 묶어주는 훌륭한 최적화 도구이지만 [5, 16], 20만 개가 넘는 수준의 과도하게 많은 지오메트리에 적용할 경우 버퍼의 draw "st[[Arts]]" 및 "counts" 데이터를 매 프레임 업데이트해야 하는 오버헤드로 인해 오히려 CPU 사용률이 폭증하고 기존의 Merged Mesh 방식보다 성능이 크게 저하되는 현상이 발생할 수 있습니다 [46-49].
+  - `BatchedMesh`는 다수의 고유 기하학 객체를 단일 드로우 콜로 묶어주는 훌륭한 최적화 도구이지만 [5, 16], 20만 개가 넘는 수준의 과도하게 많은 지오메트리에 적용할 경우 버퍼의 draw "st[[Arts|Arts]]" 및 "counts" 데이터를 매 프레임 업데이트해야 하는 오버헤드로 인해 오히려 CPU 사용률이 폭증하고 기존의 Merged Mesh 방식보다 성능이 크게 저하되는 현상이 발생할 수 있습니다 [46-49].
   - `InstancedMesh`는 드로우 콜을 혁신적으로 줄여주지만, 인스턴스들이 정렬되지 않아 막대한 오버드로우를 유발하므로, 객체가 겹치는 씬의 경우 여러 개의 개별 Mesh를 공유 속성으로 렌더링하는 것보다 오히려 프레임 속도가 더 떨어지는 역설적인 상황이 발생할 수 있습니다 [30, 31, 50].
 
 ---

10_Wiki/Topics/Graphics & Performance/Threejs WebGPU 파티클 예제.md

@@ -1,19 +1,19 @@
 ---
-id: [[P-Reinforce]]-AUTO-A9D3D4
+id: [[P-Reinforce|P-Reinforce]]-AUTO-A9D3D4
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] [[WebGPU]] 파티클 예제"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] [[WebGPU|WebGPU]] 파티클 예제"
 ---
 
-# [[Threejs WebGPU 파티클 예제]]
+# [[Threejs WebGPU 파티클 예제|Threejs WebGPU 파티클 예제]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js에서 전통적인 CPU 기반의 파티클 업데이트는 약 5만 개 수준에서 병목 현상이 발생하지만, WebGPU 컴퓨트 셰이더를 활용하면 이를 수백만 개 단위로 확장할 수 있습니다 [1]. WebGPU 파티클 예제들은 `[[instancedArray]]`와 같은 GPU 영구 버퍼를 사용하여 CPU와 GPU 간의 데이터 전송 부하를 제거하는 방식을 보여줍니다 [1]. 이러한 최적화 기술은 [[Expo 2025 Osaka]]와 같은 실제 프로젝트에서 100만 개의 파티클을 지연 없이 실시간으로 렌더링하는 데 성공적으로 적용되었습니다 [2, 3].
+> Three.js에서 전통적인 CPU 기반의 파티클 업데이트는 약 5만 개 수준에서 병목 현상이 발생하지만, WebGPU 컴퓨트 셰이더를 활용하면 이를 수백만 개 단위로 확장할 수 있습니다 [1]. WebGPU 파티클 예제들은 `[[instancedArray|instancedArray]]`와 같은 GPU 영구 버퍼를 사용하여 CPU와 GPU 간의 데이터 전송 부하를 제거하는 방식을 보여줍니다 [1]. 이러한 최적화 기술은 [[Expo 2025 Osaka|Expo 2025 Osaka]]와 같은 실제 프로젝트에서 100만 개의 파티클을 지연 없이 실시간으로 렌더링하는 데 성공적으로 적용되었습니다 [2, 3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **성능 한계 돌파:** 일반적인 하드웨어 환경에서 CPU를 이용해 파티클을 업데이트할 경우 보통 50,000개 정도에서 성능 병목이 발생합니다 [1]. 하지만 파티클 시스템을 WebGPU의 컴퓨트 셰이더([[Compute Shader]]s)로 이동시키면 한계를 수백만 개 수준으로 끌어올릴 수 있습니다 [1].
+* **성능 한계 돌파:** 일반적인 하드웨어 환경에서 CPU를 이용해 파티클을 업데이트할 경우 보통 50,000개 정도에서 성능 병목이 발생합니다 [1]. 하지만 파티클 시스템을 WebGPU의 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)로 이동시키면 한계를 수백만 개 수준으로 끌어올릴 수 있습니다 [1].
 * **영구적인 GPU 버퍼 사용 (`instancedArray`):** Three.js WebGPU 파티클 예제에서는 `instancedArray`를 사용하여 프레임 간 데이터가 유지되는 영구적인 GPU 버퍼를 생성합니다 [1]. 이 방식은 전통적인 파티클 시스템에서 성능 저하의 주원인이었던 CPU와 GPU 간의 데이터 전송 과정을 완전히 제거하여 성능을 극대화합니다 [1].
 * **대규모 실제 적용 사례:** 고성능 WebGPU 파티클 시스템의 강력함을 보여주는 대표적인 실제 사례로 2025년 오사카 엑스포(Expo 2025 Osaka)의 "Waves of Connection" (Hokusai 인스톨레이션)이 있습니다 [2, 3]. 이 프로젝트에서는 98인치 4K 디스플레이 환경에서 100만 개의 파티클을 이용한 유체 시뮬레이션을 지연 현상 없이 실시간으로 렌더링했으며, 다인원 바디 트래킹까지 원활하게 처리했습니다 [2, 3].
 * **컴퓨트 셰이더의 연산 확장성:** 파티클 렌더링 외에도 물리 연산, 충돌 감지, 실시간 데이터 필터링 등 연산 집약적인 작업들은 WebGPU 컴퓨트 셰이더를 통해 수천 개의 GPU 코어에서 병렬로 처리될 수 있습니다 [4, 5].
@@ -23,9 +23,9 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] [[WebGPU]] 파티
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU Compute Shaders]], [[instancedArray]]
-- **Projects/Contexts:** [[Expo 2025 Osaka]], Waves of Connection
-- **Contradictions/Notes:** 소스 내용에 따르면, WebGPU 파티클 예제는 [[WebGL]] 기반의 단일 스레드 CPU 처리 한계(약 5만 개)를 극복하기 위해 컴퓨트 셰이더 연산과 영구적인 GPU 데이터 할당 구조를 결합하여 수십 배 이상의 파티클을 렌더링할 수 있는 방향으로 발전하고 있습니다 [1, 5, 6].
+- **Related Topics:** [[WebGPU Compute Shaders|WebGPU Compute Shaders]], [[instancedArray|instancedArray]]
+- **Projects/Contexts:** [[Expo 2025 Osaka|Expo 2025 Osaka]], Waves of Connection
+- **Contradictions/Notes:** 소스 내용에 따르면, WebGPU 파티클 예제는 [[WebGL|WebGL]] 기반의 단일 스레드 CPU 처리 한계(약 5만 개)를 극복하기 위해 컴퓨트 셰이더 연산과 영구적인 GPU 데이터 할당 구조를 결합하여 수십 배 이상의 파티클을 렌더링할 수 있는 방향으로 발전하고 있습니다 [1, 5, 6].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Threejs 대규모 렌더링 최적화 파이프라인.md

@@ -1,29 +1,29 @@
 ---
-id: [[P-Reinforce]]-AUTO-8E841B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-8E841B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 대규모 렌더링 최적화 파이프라인"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] 대규모 렌더링 최적화 파이프라인"
 ---
 
-# [[Threejs 대규모 렌더링 최적화 파이프라인]]
+# [[Threejs 대규모 렌더링 최적화 파이프라인|Threejs 대규모 렌더링 최적화 파이프라인]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 대규모 렌더링 최적화 파이프라인은 수많은 3D 객체를 브라우저 환경에서 매끄럽게 렌더링하기 위해 CPU와 GPU 간의 통신 오버헤드, 즉 드로우 콜([[Draw Call]])과 메모리 병목 현상을 극복하는 일련의 기술적 아키텍처입니다 [1, 2]. 주로 [[InstancedMesh]]와 BatchedMesh를 통한 드로우 콜 최소화, Draco 및 KTX2 등을 이용한 에셋 압축, 절두체 컬링([[Frustum Culling]]) 및 LOD 시스템을 활용하여 그래픽 자원의 낭비를 줄입니다 [3-6]. 최근에는 [[WebGPU]]와 컴퓨트 셰이더([[Compute Shader]])가 도입되어 렌더링 제어 및 가시성 판단 연산을 GPU로 대거 이관함으로써, 더욱 막대한 규모의 씬을 유연하게 처리할 수 있는 차세대 파이프라인으로 진화하고 있습니다 [7-9].
+> Three.js 대규모 렌더링 최적화 파이프라인은 수많은 3D 객체를 브라우저 환경에서 매끄럽게 렌더링하기 위해 CPU와 GPU 간의 통신 오버헤드, 즉 드로우 콜([[Draw Call|Draw Call]])과 메모리 병목 현상을 극복하는 일련의 기술적 아키텍처입니다 [1, 2]. 주로 InstancedMesh와 BatchedMesh를 통한 드로우 콜 최소화, Draco 및 KTX2 등을 이용한 에셋 압축, 절두체 컬링(Frustum Culling) 및 LOD 시스템을 활용하여 그래픽 자원의 낭비를 줄입니다 [3-6]. 최근에는 [[WebGPU|WebGPU]]와 컴퓨트 셰이더([[Compute Shader|Compute Shader]])가 도입되어 렌더링 제어 및 가시성 판단 연산을 GPU로 대거 이관함으로써, 더욱 막대한 규모의 씬을 유연하게 처리할 수 있는 차세대 파이프라인으로 진화하고 있습니다 [7-9].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜(Draw Call) 최소화 전략:** 실시간 렌더링 성능을 저하시키는 가장 결정적인 요인은 CPU가 렌더링 상태를 변경하고 GPU에 명령을 내리는 드로우 콜의 오버헤드입니다 [2, 10]. 원활한 60fps를 유지하려면 프레임당 드로우 콜을 100회 미만으로 타겟팅해야 합니다 [4, 11]. 이를 위해 동일한 기하학적 구조와 재질을 공유하는 객체는 `InstancedMesh`를 활용하여 수천 개를 단일 드로우 콜로 처리하며 [4, 5, 12], 재질은 같으나 지오메트리가 다양한 객체들은 `BatchedMesh`를 통해 최적화합니다 [13-15]. 정적인 배경이나 환경 모델은 `[[BufferGeometry]]Utils`를 사용해 하나의 지오메트리로 병합(Merging)하는 방법이 사용됩니다 [13, 16].
-- **가시성 판단(Culling) 및 정렬 한계 극복:** `InstancedMesh`는 엔진 내부에서 단일 객체로 취급되기 때문에, 기본 절두체 컬링이 개별 인스턴스에는 작동하지 않는 '전부 아니면 전무' 방식의 한계를 가집니다 [17]. 이로 인해 화면 밖의 객체까지 정점 연산이 강제되고, 거리 기반 자동 정렬의 부재로 인해 막대한 오버드로우([[Overdraw]]) 현상을 일으킬 수 있습니다 [18, 19]. 이에 대응하기 위해 BVH(Bounding Volume Hierarchy)를 결합하여 인스턴스 단위의 개별 컬링과 정렬을 지원하는 확장 라이브러리(예: `[[InstancedMesh2]]`)를 사용하거나 [20-22], 거리에 따라 모델 해상도를 낮추는 LOD(Level of Detail) 기법을 함께 적용하여 연산량을 제한합니다 [6, 11, 23].
-- **메모리 대역폭 및 에셋 최적화:** 대형 어셈블리 모델이나 포인트 클라우드의 VRAM 고갈과 대역폭 한계를 막는 것은 파이프라인의 핵심입니다. Draco 압축을 통해 지오메트리 파일 크기를 최대 95%까지 축소시키고 [3, 24], KTX2나 Basis Universal 포맷을 적용하여 텍스처가 압축된 상태로 GPU 메모리에 상주하도록 만들어 메모리 소비를 약 10배 절감합니다 [3, 25]. 또한 다양한 재질의 텍스처를 하나의 텍스처 아틀라스([[Texture Atlas]])나 배열 텍스처([[Data Array Textures]])로 결합하면 텍스처 바인딩으로 인한 상태 변경 비용을 크게 줄일 수 있습니다 [26-29].
-- **WebGPU 기반 차세대 렌더링 파이프라인:** 2026년 기준, Three.js(r171 이상)의 `WebGPURenderer` 및 TSL(Three Shader Language) 도입으로 대규모 렌더링 구조가 혁신적으로 변화했습니다 [7, 30]. 일반적인 CPU 한계를 초과하던 100만 개 이상의 파티클 연산, 물리 시뮬레이션, 복잡한 군중 애니메이션 등을 컴퓨트 셰이더(Compute Shader)를 통한 [[GPU-driven Rendering]]으로 병렬 처리할 수 있게 되었습니다 [31-34]. Native WebGPU 수준에서는 `[[GPURenderBundles]]` 및 [[Indirect Draw]]ing 기술을 통해 500MB 이상의 초대형 건설/BIM 데이터셋에서도 강력한 성능 향상을 이끌어냅니다 [35, 36].
+- **드로우 콜(Draw Call) 최소화 전략:** 실시간 렌더링 성능을 저하시키는 가장 결정적인 요인은 CPU가 렌더링 상태를 변경하고 GPU에 명령을 내리는 드로우 콜의 오버헤드입니다 [2, 10]. 원활한 60fps를 유지하려면 프레임당 드로우 콜을 100회 미만으로 타겟팅해야 합니다 [4, 11]. 이를 위해 동일한 기하학적 구조와 재질을 공유하는 객체는 `InstancedMesh`를 활용하여 수천 개를 단일 드로우 콜로 처리하며 [4, 5, 12], 재질은 같으나 지오메트리가 다양한 객체들은 `BatchedMesh`를 통해 최적화합니다 [13-15]. 정적인 배경이나 환경 모델은 `[[BufferGeometry|BufferGeometry]]Utils`를 사용해 하나의 지오메트리로 병합(Merging)하는 방법이 사용됩니다 [13, 16].
+- **가시성 판단(Culling) 및 정렬 한계 극복:** `InstancedMesh`는 엔진 내부에서 단일 객체로 취급되기 때문에, 기본 절두체 컬링이 개별 인스턴스에는 작동하지 않는 '전부 아니면 전무' 방식의 한계를 가집니다 [17]. 이로 인해 화면 밖의 객체까지 정점 연산이 강제되고, 거리 기반 자동 정렬의 부재로 인해 막대한 오버드로우([[Overdraw|Overdraw]]) 현상을 일으킬 수 있습니다 [18, 19]. 이에 대응하기 위해 BVH(Bounding Volume Hierarchy)를 결합하여 인스턴스 단위의 개별 컬링과 정렬을 지원하는 확장 라이브러리(예: `[[InstancedMesh2|InstancedMesh2]]`)를 사용하거나 [20-22], 거리에 따라 모델 해상도를 낮추는 LOD(Level of Detail) 기법을 함께 적용하여 연산량을 제한합니다 [6, 11, 23].
+- **메모리 대역폭 및 에셋 최적화:** 대형 어셈블리 모델이나 포인트 클라우드의 VRAM 고갈과 대역폭 한계를 막는 것은 파이프라인의 핵심입니다. Draco 압축을 통해 지오메트리 파일 크기를 최대 95%까지 축소시키고 [3, 24], KTX2나 Basis Universal 포맷을 적용하여 텍스처가 압축된 상태로 GPU 메모리에 상주하도록 만들어 메모리 소비를 약 10배 절감합니다 [3, 25]. 또한 다양한 재질의 텍스처를 하나의 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])나 배열 텍스처([[Data Array Textures|Data Array Textures]])로 결합하면 텍스처 바인딩으로 인한 상태 변경 비용을 크게 줄일 수 있습니다 [26-29].
+- **WebGPU 기반 차세대 렌더링 파이프라인:** 2026년 기준, Three.js(r171 이상)의 `WebGPURenderer` 및 TSL(Three Shader Language) 도입으로 대규모 렌더링 구조가 혁신적으로 변화했습니다 [7, 30]. 일반적인 CPU 한계를 초과하던 100만 개 이상의 파티클 연산, 물리 시뮬레이션, 복잡한 군중 애니메이션 등을 컴퓨트 셰이더(Compute Shader)를 통한 [[GPU-driven Rendering|GPU-driven Rendering]]으로 병렬 처리할 수 있게 되었습니다 [31-34]. Native WebGPU 수준에서는 `GPURenderBundles` 및 [[Indirect Draw|Indirect Draw]]ing 기술을 통해 500MB 이상의 초대형 건설/BIM 데이터셋에서도 강력한 성능 향상을 이끌어냅니다 [35, 36].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[InstancedMesh]]`, `BatchedMesh`, `[[WebGPU]]`, `Draw Call (드로우 콜)`, `Frustum Culling (절두체 컬링)`, `LOD (Level of Detail)`, `Overdraw (오버드로우)`, `Compute Shader (컴퓨트 셰이더)`
+- **Related Topics:** `[[InstancedMesh|InstancedMesh]]`, `BatchedMesh`, `[[WebGPU|WebGPU]]`, `Draw Call (드로우 콜)`, `Frustum Culling (절두체 컬링)`, `LOD (Level of Detail)`, `Overdraw (오버드로우)`, `Compute Shader (컴퓨트 셰이더)`
 - **Projects/Contexts:** `InstancedMesh2 (agargaro)`, `Three.js r171 WebGPURenderer`, `Segments.ai`, `Fragment (IFC.js)`
 - **Contradictions/Notes:** 
   - `InstancedMesh`는 드로우 콜을 줄여 성능을 크게 향상시키도록 설계되었으나, 불투명도 및 복잡한 셰이더 환경에서는 인스턴스 정렬 부재로 인한 심각한 오버드로우(Overdraw)를 유발해 일반 개별 Mesh(Shared attributes)를 사용할 때보다 프레임 레이트(FPS)가 오히려 낮아지는 역설적인 사례가 보고되고 있습니다 [18, 19].

10_Wiki/Topics/Graphics & Performance/Threejs 렌더링 성능 최적화.md

@@ -1,22 +1,22 @@
 ---
-id: [[P-Reinforce]]-AUTO-4EE7A9
+id: [[P-Reinforce|P-Reinforce]]-AUTO-4EE7A9
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 렌더링 성능 최적화"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] 렌더링 성능 최적화"
 ---
 
-# [[Threejs 렌더링 성능 최적화]]
+# [[Threejs 렌더링 성능 최적화|Threejs 렌더링 성능 최적화]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 렌더링 성능 최적화는 브라우저 환경에서 3D 씬을 부드럽게 렌더링하기 위해 CPU와 GPU 간의 병목 현상을 줄이고 하드웨어 자원의 효율성을 극대화하는 일련의 기법을 의미합니다. 가장 핵심적인 목표는 CPU 오버헤드를 유발하는 드로우 콜([[Draw Call]]) 횟수를 프레임당 100회 미만으로 유지하는 것이며, 이를 위해 인스턴싱([[Instancing]])과 배칭([[Batching]]) 같은 기술이 필수적으로 사용됩니다 [1-5]. 또한, 에셋 압축, 메모리 관리, 셰이더 및 시야 절두체 컬링([[Frustum Culling]]) 조정, [[WebGPU]]와 컴퓨트 셰이더의 도입 등을 통해 전반적인 연산 부하를 다각도로 최적화합니다 [1, 6-8].
+> Three.js 렌더링 성능 최적화는 브라우저 환경에서 3D 씬을 부드럽게 렌더링하기 위해 CPU와 GPU 간의 병목 현상을 줄이고 하드웨어 자원의 효율성을 극대화하는 일련의 기법을 의미합니다. 가장 핵심적인 목표는 CPU 오버헤드를 유발하는 드로우 콜([[Draw Call|Draw Call]]) 횟수를 프레임당 100회 미만으로 유지하는 것이며, 이를 위해 인스턴싱(Instancing)과 배칭(Batching) 같은 기술이 필수적으로 사용됩니다 [1-5]. 또한, 에셋 압축, 메모리 관리, 셰이더 및 시야 절두체 컬링([[Frustum Culling|Frustum Culling]]) 조정, [[WebGPU|WebGPU]]와 컴퓨트 셰이더의 도입 등을 통해 전반적인 연산 부하를 다각도로 최적화합니다 [1, 6-8].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **드로우 콜(Draw Call) 최적화**
-  * **[[InstancedMesh]]:** 동일한 기하학적 구조(Geometry)와 재질(Material)을 가진 수천 개의 객체를 단 한 번의 드로우 콜로 렌더링하여 CPU-GPU 간 명령 발행 오버헤드를 대폭 감소시킵니다 [2, 9-11]. 하지만 기본적으로 전체 인스턴스를 하나로 묶어 단일 시야 절두체 컬링을 수행하므로 화면 밖의 객체까지 연산할 수 있으며, 깊이 정렬이 자동 지원되지 않아 오버드로우([[Overdraw]])로 인한 프래그먼트 셰이더 병목을 유발할 수 있습니다 [12-15].
-  * **BatchedMesh:** 재질은 동일하지만 기하학적 구조가 다른 여러 객체를 하나의 드로우 콜로 묶어 렌더링할 수 있는 객체입니다 [16-19]. 복잡하고 이질적인 부품이 많은 모델에 유용하지만, 정렬([[Sorting]]) 및 개별 객체 컬링을 수행하는 과정과 멀티 드로우(`multiDrawElements[[WebGL]]`) API의 오버헤드로 인해 정점 수가 매우 많은 상황에서는 CPU 점유율이 40~60%까지 치솟고 프레임률이 급락하는 성능 저하가 발생할 수 있습니다 [19-22].
-  * **지오메트리 병합 ([[Geometry Merging]]):** 움직이지 않는 정적인 객체들은 로딩 시점에 `[[BufferGeometry]]Utils`를 사용하여 하나의 메쉬로 병합함으로써 드로우 콜을 1회로 줄일 수 있습니다 [16, 23-25]. 하지만 이는 메모리 사용량을 크게 증가시키고 개별 객체의 제어나 컬링이 불가능해지는 단점이 있습니다 [23-25].
+  * **[[InstancedMesh|InstancedMesh]]:** 동일한 기하학적 구조(Geometry)와 재질(Material)을 가진 수천 개의 객체를 단 한 번의 드로우 콜로 렌더링하여 CPU-GPU 간 명령 발행 오버헤드를 대폭 감소시킵니다 [2, 9-11]. 하지만 기본적으로 전체 인스턴스를 하나로 묶어 단일 시야 절두체 컬링을 수행하므로 화면 밖의 객체까지 연산할 수 있으며, 깊이 정렬이 자동 지원되지 않아 오버드로우([[Overdraw|Overdraw]])로 인한 프래그먼트 셰이더 병목을 유발할 수 있습니다 [12-15].
+  * **BatchedMesh:** 재질은 동일하지만 기하학적 구조가 다른 여러 객체를 하나의 드로우 콜로 묶어 렌더링할 수 있는 객체입니다 [16-19]. 복잡하고 이질적인 부품이 많은 모델에 유용하지만, 정렬([[Sorting|Sorting]]) 및 개별 객체 컬링을 수행하는 과정과 멀티 드로우(`multiDrawElements[[WebGL|WebGL]]`) API의 오버헤드로 인해 정점 수가 매우 많은 상황에서는 CPU 점유율이 40~60%까지 치솟고 프레임률이 급락하는 성능 저하가 발생할 수 있습니다 [19-22].
+  * **지오메트리 병합 ([[Geometry Merging|Geometry Merging]]):** 움직이지 않는 정적인 객체들은 로딩 시점에 `[[BufferGeometry|BufferGeometry]]Utils`를 사용하여 하나의 메쉬로 병합함으로써 드로우 콜을 1회로 줄일 수 있습니다 [16, 23-25]. 하지만 이는 메모리 사용량을 크게 증가시키고 개별 객체의 제어나 컬링이 불가능해지는 단점이 있습니다 [23-25].
 
 * **에셋 압축 및 메모리 관리**
   * 모델의 기하학적 용량을 90-95% 줄여주는 Draco 압축과, VRAM 내에서 압축 상태를 유지해 텍스처 메모리 사용량을 대폭 줄여주는 KTX2 또는 Basis Universal 텍스처 포맷 사용이 강력히 권장됩니다 [3, 26-29].
@@ -24,20 +24,20 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 렌더링 성능
 
 * **시각적 최적화 및 셰이더 기법**
   * **LOD (Level of Detail):** 카메라와의 거리에 따라 객체를 단순한 폴리곤 버전을 사용하거나 임포스터(Billboard Impostor)로 교체하여 프래그먼트 연산 비용과 삼각형 수를 극적으로 줄일 수 있습니다 [7, 34-37]. 단, LOD는 드로우 콜 자체를 줄여주지는 않으므로 병목의 원인에 맞춰 사용해야 합니다 [38].
-  * 다수의 텍스처 바인딩 비용을 줄이기 위해 여러 텍스처를 한 이미지에 담는 텍스처 아틀라스([[Texture Atlas]])나 최신의 데이터 배열 텍스처([[Data Array Textures]])를 활용하여 상태 변경([[State]] Change)을 최소화합니다 [39-42].
+  * 다수의 텍스처 바인딩 비용을 줄이기 위해 여러 텍스처를 한 이미지에 담는 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])나 최신의 데이터 배열 텍스처(Data Array Textures)를 활용하여 상태 변경([[State|State]] Change)을 최소화합니다 [39-42].
   * 연산량이 많은 조명과 그림자는 정적 씬의 경우 라이트맵이나 주변 차폐 맵(AO Maps)으로 사전에 구워(Baking) 연산을 완전히 대체해야 합니다 [43-45]. 모바일 환경에서는 셰이더 변수 정밀도를 `mediump`로 낮춰 성능을 2배가량 향상시킬 수 있습니다 [46].
 
 * **WebGPU 시대의 도래 (2026년 기준)**
-  * Three.js r171부터 도입된 WebGPURenderer는 무거운 드로우 콜 환경이나 수백만 개의 파티클 연산에 컴퓨트 셰이더([[Compute Shader]]s)를 적용하여 CPU의 단일 스레드 한계를 극복하고 100배 이상의 성능 향상을 가능하게 합니다 [8, 47-49].
-  * [[TSL (Three Shader Language)]]을 사용하면 WGSL(WebGPU)과 GLSL(WebGL) 양쪽 모두에서 호환되는 크로스 플랫폼 커스텀 셰이더를 구축할 수 있습니다 [50, 51].
+  * Three.js r171부터 도입된 WebGPURenderer는 무거운 드로우 콜 환경이나 수백만 개의 파티클 연산에 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)를 적용하여 CPU의 단일 스레드 한계를 극복하고 100배 이상의 성능 향상을 가능하게 합니다 [8, 47-49].
+  * [[TSL (Three Shader Language)|TSL (Three Shader Language]]을 사용하면 WGSL(WebGPU)과 GLSL(WebGL) 양쪽 모두에서 호환되는 크로스 플랫폼 커스텀 셰이더를 구축할 수 있습니다 [50, 51].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** 드로우 콜 (Draw Call), [[InstancedMesh]], BatchedMesh, LOD (Level of Detail), [[WebGPU]]
-- **Projects/Contexts:** Three.js r171 WebGPU 도입, IFC.js Fragment 아키텍처, [[InstancedMesh2]] 라이브러리
+- **Related Topics:** 드로우 콜 (Draw Call), [[InstancedMesh|InstancedMesh]], BatchedMesh, LOD (Level of Detail), [[WebGPU|WebGPU]]
+- **Projects/Contexts:** Three.js r171 WebGPU 도입, IFC.js Fragment 아키텍처, [[InstancedMesh2|InstancedMesh2]] 라이브러리
 - **Contradictions/Notes:** 다양한 지오메트리를 한 번에 렌더링하기 위해 제안된 `BatchedMesh`는 드로우 콜 최적화의 훌륭한 대안으로 소개되지만[18], 다른 소스에서는 1,000만 개가 넘는 트라이앵글 환경에서 인스턴싱 또는 일반 `Merged Mesh`보다 CPU 점유율을 비정상적으로 높이고 프레임률을 크게 떨어뜨리는 심각한 구조적 오버헤드가 있음을 상반되게 지적하고 있습니다[19-22]. 또한 `InstancedMesh` 역시 만능이 아니며 정렬의 부재로 인해 발생하는 심각한 오버드로우(Overdraw) 때문에 일반 메쉬 렌더링보다 느려지는 병목 사례가 보고되고 있습니다[13, 14].
 
 ---

10_Wiki/Topics/Graphics & Performance/Threejs 렌더링 최적화.md

@@ -1,32 +1,32 @@
 ---
-id: [[P-Reinforce]]-AUTO-13670A
+id: [[P-Reinforce|P-Reinforce]]-AUTO-13670A
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 렌더링 최적화"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] 렌더링 최적화"
 ---
 
-# [[Threejs 렌더링 최적화]]
+# [[Threejs 렌더링 최적화|Threejs 렌더링 최적화]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 렌더링 최적화는 웹 환경에서 3D 그래픽을 부드럽고 효율적으로 구동하기 위해 CPU와 GPU 간의 병목 현상을 해소하는 일련의 기술적 과정입니다 [1-3]. 핵심 목표는 초당 프레임 수(FPS)를 안정적으로 유지하기 위해 드로우 콜([[Draw Call]]) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [4-7]. 이를 위해 인스턴싱([[Instancing]]), 배칭([[Batching]]), 에셋 압축, 디테일 수준(LOD) 조절 및 최신 [[WebGPU]] API의 도입이 필수적으로 요구됩니다 [4, 8-10].
+> Three.js 렌더링 최적화는 웹 환경에서 3D 그래픽을 부드럽고 효율적으로 구동하기 위해 CPU와 GPU 간의 병목 현상을 해소하는 일련의 기술적 과정입니다 [1-3]. 핵심 목표는 초당 프레임 수(FPS)를 안정적으로 유지하기 위해 드로우 콜([[Draw Call|Draw Call]]) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [4-7]. 이를 위해 인스턴싱(Instancing), 배칭(Batching), 에셋 압축, 디테일 수준(LOD) 조절 및 최신 [[WebGPU|WebGPU]] API의 도입이 필수적으로 요구됩니다 [4, 8-10].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **드로우 콜(Draw Call)의 최소화:** 드로우 콜은 CPU가 GPU에게 렌더링을 지시하는 명령으로, 과도한 호출에 따른 오버헤드는 성능을 저하시키는 가장 큰 원인입니다 [3, 11, 12]. 원활한 60fps를 유지하기 위해서는 프레임당 드로우 콜을 100회 미만으로 유지하는 것이 권장됩니다 [5, 8, 13].
-- **[[InstancedMesh]]와 BatchedMesh 활용:** 동일한 기하학적 구조와 재질을 가진 반복적인 객체(예: 나무, 군중)를 렌더링할 때는 `InstancedMesh`를 사용하여 단일 드로우 콜로 수많은 객체를 렌더링해야 합니다 [5, 14-16]. 반면, 재질은 동일하지만 지오메트리가 서로 다른 객체들을 그룹화하여 렌더링할 때는 `BatchedMesh`를 사용하는 것이 효율적입니다 [17-20].
+- **[[InstancedMesh|InstancedMesh]]와 BatchedMesh 활용:** 동일한 기하학적 구조와 재질을 가진 반복적인 객체(예: 나무, 군중)를 렌더링할 때는 `InstancedMesh`를 사용하여 단일 드로우 콜로 수많은 객체를 렌더링해야 합니다 [5, 14-16]. 반면, 재질은 동일하지만 지오메트리가 서로 다른 객체들을 그룹화하여 렌더링할 때는 `BatchedMesh`를 사용하는 것이 효율적입니다 [17-20].
 - **에셋 및 메모리 최적화:** 지오메트리 파일 크기를 최대 95%까지 줄여주는 Draco 압축을 사용하고, VRAM 사용량을 대폭 감소시키며 GPU에서 직접 압축이 해제되는 KTX2 및 Basis Universal 텍스처 형식을 적용해야 합니다 [8, 21-23]. 또한 사용이 끝난 지오메트리, 재질, 텍스처, 렌더 타겟 등은 반드시 `.dispose()`를 호출하여 명시적으로 GPU 메모리를 해제해야 누수를 방지할 수 있습니다 [24-27].
-- **LOD(Level of Detail) 및 컬링:** 카메라와의 거리에 따라 폴리곤 수가 적은 모델이나 임포스터(Impostor)로 교체하여 렌더링 연산을 줄이는 LOD 시스템을 구현해야 합니다 [13, 28-31]. 더불어 보이지 않는 객체를 렌더링에서 제외하는 절두체 컬링([[Frustum Culling]])이 올바르게 동작하도록 바운딩 박스를 관리해야 합니다 [32, 33].
-- **WebGPU 및 TSL 전환:** Three.js r171 버전부터 정식 지원되는 `WebGPURenderer`는 대규모 데이터셋 처리와 컴퓨트 집약적인 효과(파티클, 물리 연산 등)에서 기존 대비 수 배에서 100배 이상의 성능 향상을 제공합니다 [34-37]. 새로운 TSL(Three Shader Language)을 사용하면 단일 코드로 작성된 셰이더를 WebGPU와 [[WebGL]] 모두에 호환되게 배포할 수 있습니다 [38-40].
+- **LOD(Level of Detail) 및 컬링:** 카메라와의 거리에 따라 폴리곤 수가 적은 모델이나 임포스터(Impostor)로 교체하여 렌더링 연산을 줄이는 LOD 시스템을 구현해야 합니다 [13, 28-31]. 더불어 보이지 않는 객체를 렌더링에서 제외하는 절두체 컬링([[Frustum Culling|Frustum Culling]])이 올바르게 동작하도록 바운딩 박스를 관리해야 합니다 [32, 33].
+- **WebGPU 및 TSL 전환:** Three.js r171 버전부터 정식 지원되는 `WebGPURenderer`는 대규모 데이터셋 처리와 컴퓨트 집약적인 효과(파티클, 물리 연산 등)에서 기존 대비 수 배에서 100배 이상의 성능 향상을 제공합니다 [34-37]. 새로운 TSL(Three Shader Language)을 사용하면 단일 코드로 작성된 셰이더를 WebGPU와 [[WebGL|WebGL]] 모두에 호환되게 배포할 수 있습니다 [38-40].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], BatchedMesh, [[WebGPU]], [[Level of Detail (LOD)]], [[Texture Compression]]
-- **Projects/Contexts:** [[Utsubo]], Segments.ai, [[InstancedMesh2 library]]
-- **Contradictions/Notes:** `InstancedMesh`는 드로우 콜을 획기적으로 줄여주지만, 엔진 수준에서 개별 인스턴스에 대한 절두체 컬링과 깊이 정렬([[Sorting]])이 불가능하여 오버드로우([[Overdraw]])가 유발됩니다. 이로 인해 픽셀 연산이 무거운 씬에서는 오히려 일반 메쉬 방식보다 프레임 레이트가 하락할 수 있다는 한계가 지적됩니다 [41-44]. 대안으로 꼽히는 `BatchedMesh` 역시 수십만 개 단위의 복잡한 기하학적 데이터와 인스턴스를 처리할 때는 심각한 CPU 병목 현상 및 성능 저하를 야기할 수 있습니다 [20, 45-48].
+- **Related Topics:** [[Draw Call|Draw Call]], InstancedMesh, BatchedMesh, WebGPU, [[Level of Detail (LOD)|Level of Detail (LOD]], [[Texture Compression|Texture Compression]]
+- **Projects/Contexts:** [[Utsubo|Utsubo]], Segments.ai, [[InstancedMesh2 library|InstancedMesh2 library]]
+- **Contradictions/Notes:** `InstancedMesh`는 드로우 콜을 획기적으로 줄여주지만, 엔진 수준에서 개별 인스턴스에 대한 절두체 컬링과 깊이 정렬([[Sorting|Sorting]])이 불가능하여 오버드로우([[Overdraw|Overdraw]])가 유발됩니다. 이로 인해 픽셀 연산이 무거운 씬에서는 오히려 일반 메쉬 방식보다 프레임 레이트가 하락할 수 있다는 한계가 지적됩니다 [41-44]. 대안으로 꼽히는 `BatchedMesh` 역시 수십만 개 단위의 복잡한 기하학적 데이터와 인스턴스를 처리할 때는 심각한 CPU 병목 현상 및 성능 저하를 야기할 수 있습니다 [20, 45-48].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Threejs 모바일 렌더링 최적화.md

@@ -1,16 +1,16 @@
 ---
-id: [[P-Reinforce]]-AUTO-E3AAE4
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E3AAE4
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 모바일 렌더링 최적화"
+github_commit: "[P-Reinforce] Continuous Worker - [[Threejs|Threejs]] 모바일 렌더링 최적화"
 ---
 
-# [[Threejs 모바일 렌더링 최적화]]
+# [[Threejs 모바일 렌더링 최적화|Threejs 모바일 렌더링 최적화]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 모바일 렌더링 최적화는 제한된 컴퓨팅 파워, 메모리 대역폭 및 배터리 용량을 가진 모바일 기기 환경에서 3D 장면을 원활하게 구동하기 위한 일련의 기술적 접근이다. 이 최적화는 셰이더 정밀도 조절, 텍스처 및 폴리곤 수 제한, 드로우 콜([[Draw Call]]) 감소, 배터리 절약을 위한 렌더링 루프 제어 등을 포함한다 [1-4]. 이를 통해 모바일 브라우저에서도 60fps의 안정적인 프레임 속도를 유지하고 메모리 한계로 인한 애플리케이션 크래시를 방지할 수 있다 [5, 6].
+> Three.js 모바일 렌더링 최적화는 제한된 컴퓨팅 파워, 메모리 대역폭 및 배터리 용량을 가진 모바일 기기 환경에서 3D 장면을 원활하게 구동하기 위한 일련의 기술적 접근이다. 이 최적화는 셰이더 정밀도 조절, 텍스처 및 폴리곤 수 제한, 드로우 콜([[Draw Call|Draw Call]]) 감소, 배터리 절약을 위한 렌더링 루프 제어 등을 포함한다 [1-4]. 이를 통해 모바일 브라우저에서도 60fps의 안정적인 프레임 속도를 유지하고 메모리 한계로 인한 애플리케이션 크래시를 방지할 수 있다 [5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **셰이더 및 정밀도 최적화**
@@ -20,27 +20,27 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Threejs]] 모바일 렌더
 *   **메모리 및 텍스처 관리**
     *   모바일 기기는 보통 2~4GB의 제한된 시스템 메모리를 가지며, 텍스처 메모리가 500MB를 초과하면 가비지 컬렉션(GC)으로 인한 일시 중지와 심각한 프레임 끊김이 발생한다 [5].
     *   이를 해결하기 위해 Basis Universal이나 KTX2와 같은 GPU 친화적인 압축 텍스처를 사용해야 한다. 이러한 포맷은 모바일 플랫폼에 따라 ASTC(Android)나 PVRTC(iOS)로 로드 시 변환되어 메모리 사용량을 대폭 줄여준다 [7].
-    *   다수의 텍스처를 사용하는 대신, 텍스처 아틀라스([[Texture Atlas]])로 결합하여 텍스처 바인딩 횟수를 줄이는 것이 모바일 GPU의 렌더링 오버헤드를 크게 감소시키는 방법이다 [8, 9].
+    *   다수의 텍스처를 사용하는 대신, 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])로 결합하여 텍스처 바인딩 횟수를 줄이는 것이 모바일 GPU의 렌더링 오버헤드를 크게 감소시키는 방법이다 [8, 9].
 
 *   **드로우 콜 및 지오메트리 제한**
     *   프로세서 성능이 상대적으로 낮은 모바일 브라우저에서는 1,000~2,000회의 드로우 콜 한계치에 도달하면 CPU 병목으로 인한 성능 저하가 눈에 띄게 나타난다 [4].
-    *   모바일 브라우저(iOS Safari, [[Chrome]] Mobile 등) 환경에서는 화면당 폴리곤 개수를 50,000~100,000개 수준으로 제한해야 매끄러운 렌더링이 보장된다 [3].
+    *   모바일 브라우저(iOS Safari, [[Chrome|Chrome]] Mobile 등) 환경에서는 화면당 폴리곤 개수를 50,000~100,000개 수준으로 제한해야 매끄러운 렌더링이 보장된다 [3].
 
 *   **그림자 및 안티앨리어싱 설정 타협**
     *   섀도우 맵 렌더링은 리소스 소모가 크므로, 모바일의 경우 섀도우 맵 크기를 512에서 1024 사이로 작게 설정하는 것이 바람직하다 [10].
     *   렌더링 파이프라인 구성 시 고비용의 네이티브 안티앨리어싱(MSAA)을 비활성화하고, 그 대신 포스트 프로세싱인 FXAA를 사용하면 모바일 기기에서도 성능 부하를 5~10% 수준으로 낮추면서 60fps를 유지할 수 있다 [6].
 
-*   **배터리 절약 및 오류 복구(Context [[Management]])**
+*   **배터리 절약 및 오류 복구(Context [[Management|Management]])**
     *   정적인 씬(Static scenes)의 경우 리액트 기반 환경(R3F 등)에서 `frameloop="demand"` 옵션을 사용하여 불필요한 프레임 렌더링을 방지함으로써 모바일 기기의 배터리를 아껴야 한다 [2].
-    *   모바일 환경에서는 [[WebGL]] 컨텍스트 손실(Context lost)이 발생할 수 있으므로, 리스너(`webglcontextlost`)를 등록하여 이를 감지하고 우아하게 복구하는(gracefully recover) 예외 처리가 필수적이다 [11].
+    *   모바일 환경에서는 [[WebGL|WebGL]] 컨텍스트 손실(Context lost)이 발생할 수 있으므로, 리스너(`webglcontextlost`)를 등록하여 이를 감지하고 우아하게 복구하는(gracefully recover) 예외 처리가 필수적이다 [11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** 드로우 콜 최적화 (Draw Call [[Optimization]]), 텍스처 압축 ([[Texture Compression]]), 셰이더 정밀도 (Shader Precision), [[가비지 컬렉션 ([[Garbage Collection]])]]
-- **Projects/Contexts:** [[React Three Fiber (R3F)]], Basis Universal / KTX2
+- **Related Topics:** 드로우 콜 최적화 (Draw Call [[Optimization|Optimization]]), 텍스처 압축 (Texture Compression), 셰이더 정밀도 (Shader Precision), 가비지 컬렉션 ([[Garbage Collection|Garbage Collection]]
+- **Projects/Contexts:** [[React Three Fiber (R3F)|React Three Fiber (R3F]], Basis Universal / KTX2
 - **Contradictions/Notes:** 소스에서는 모바일 환경 구현 시 시각적 품질과 성능 간의 직접적인 타협(trade-off)을 강조한다. 데스크톱 환경에서는 다중 텍스처 파일과 MSAA, 4096 크기의 섀도우 맵 활용이 가능하지만, 모바일 기기에서는 동일한 구성을 유지할 경우 프레임 속도 저하와 발열, 메모리 부족으로 인한 강제 종료를 유발할 수 있으므로 극단적인 간소화(FXAA, 아틀라스 텍스처, 512~1024 섀도우 등)를 필수적으로 도입해야 함을 명시한다 [5, 6, 10].
 
 ---

10_Wiki/Topics/Graphics & Performance/Threejs.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-A5498B
+id: [[P-Reinforce|P-Reinforce]]-AUTO-A5498B
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,30 +7,30 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Threejs"
 ---
 
-# [[Threejs]]
+# [[Threejs|Threejs]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js는 [[WebGL]] 및 [[WebGPU]]를 사용하여 웹 브라우저에서 애니메이션 3D 컴퓨터 그래픽스를 생성하고 표시할 수 있도록 지원하는 크로스 브라우저 자바스크립트 라이브러리이자 API이다 [1, 2]. 브라우저, GPU, 자바스크립트 간의 복잡한 상호작용을 추상화하여 개발자가 고성능의 3D 환경을 쉽게 구축할 수 있도록 돕는다 [3]. 2026년을 기점으로 프로덕션 수준의 WebGPU 렌더러와 TSL(Three Shader Language)이 도입되면서, 단순한 시각화를 넘어 수백만 개의 파티클 연산이나 대규모 CAD 모델 처리까지 가능한 고성능 플랫폼으로 진화했다 [4-7].
+> Three.js는 [[WebGL|WebGL]] 및 [[WebGPU|WebGPU]]를 사용하여 웹 브라우저에서 애니메이션 3D 컴퓨터 그래픽스를 생성하고 표시할 수 있도록 지원하는 크로스 브라우저 자바스크립트 라이브러리이자 API이다 [1, 2]. 브라우저, GPU, 자바스크립트 간의 복잡한 상호작용을 추상화하여 개발자가 고성능의 3D 환경을 쉽게 구축할 수 있도록 돕는다 [3]. 2026년을 기점으로 프로덕션 수준의 WebGPU 렌더러와 TSL(Three Shader Language)이 도입되면서, 단순한 시각화를 넘어 수백만 개의 파티클 연산이나 대규모 CAD 모델 처리까지 가능한 고성능 플랫폼으로 진화했다 [4-7].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-*   **렌더링 파이프라인 및 드로우 콜([[Draw Call]]) 최적화:** 
-    실시간 3D 렌더링에서 CPU가 GPU에 렌더링을 명령하는 '드로우 콜'은 시스템 오버헤드의 주된 원인으로 꼽힌다 [8-10]. Three.js는 이를 최소화하기 위해 단일 기하학(Geometry)과 재질(Material)을 공유하는 객체들을 한 번에 렌더링하는 `[[InstancedMesh]]`, 다양한 기하학적 구조를 동일한 재질 하에 하나로 묶어 처리하는 `BatchedMesh`, 그리고 정적 객체들을 로드 시점에 병합해버리는 `[[BufferGeometry]]Utils.mergeBufferGeometries` 기법을 지원한다 [11-15].
+*   **렌더링 파이프라인 및 드로우 콜([[Draw Call|Draw Call]]) 최적화:** 
+    실시간 3D 렌더링에서 CPU가 GPU에 렌더링을 명령하는 '드로우 콜'은 시스템 오버헤드의 주된 원인으로 꼽힌다 [8-10]. Three.js는 이를 최소화하기 위해 단일 기하학(Geometry)과 재질(Material)을 공유하는 객체들을 한 번에 렌더링하는 `[[InstancedMesh|InstancedMesh]]`, 다양한 기하학적 구조를 동일한 재질 하에 하나로 묶어 처리하는 `BatchedMesh`, 그리고 정적 객체들을 로드 시점에 병합해버리는 `[[BufferGeometry|BufferGeometry]]Utils.mergeBufferGeometries` 기법을 지원한다 [11-15].
 *   **WebGPU와 TSL(Three Shader Language)의 도입:** 
-    릴리즈 r171부터 도입된 WebGPURenderer는 `forceWebGL`이 필요한 상황을 제외하면 WebGL 2 자동 폴백 기능을 지원하는 "제로 설정(zero-config)" 방식으로 쉽게 적용할 수 있다 [4, 5, 16]. 새롭게 도입된 TSL은 단일 코드로 WGSL과 GLSL 양쪽 모두에 컴파일되는 노드 기반의 재질 시스템이며, 컴퓨트 셰이더([[Compute Shader]]s)를 통해 물리 연산, 충돌 감지, 수백만 단위의 대규모 파티클 시스템 렌더링 등 병렬 처리를 GPU로 오프로딩할 수 있게 해준다 [5, 17-20].
+    릴리즈 r171부터 도입된 WebGPURenderer는 `forceWebGL`이 필요한 상황을 제외하면 WebGL 2 자동 폴백 기능을 지원하는 "제로 설정(zero-config)" 방식으로 쉽게 적용할 수 있다 [4, 5, 16]. 새롭게 도입된 TSL은 단일 코드로 WGSL과 GLSL 양쪽 모두에 컴파일되는 노드 기반의 재질 시스템이며, 컴퓨트 셰이더([[Compute Shader|Compute Shader]]s)를 통해 물리 연산, 충돌 감지, 수백만 단위의 대규모 파티클 시스템 렌더링 등 병렬 처리를 GPU로 오프로딩할 수 있게 해준다 [5, 17-20].
 *   **메모리 및 애셋 관리의 중요성:** 
-    Three.js는 GPU 리소스를 자동으로 가비지 컬렉션([[Garbage Collection]])하지 않으므로, 사용이 끝난 지오메트리, 재질, 텍스처는 반드시 `.dispose()` 메서드를 호출해 명시적으로 해제해야만 VRAM 누수를 막을 수 있다 [21, 22]. 모델 로드 시 대역폭과 메모리를 아끼기 위해 Draco 지오메트리 압축, KTX2 및 Basis Universal과 같은 GPU 네이티브 텍스처 압축 기술이 필수적이며 [23-25], 카메라 거리에 따라 다각형 수를 조절하는 LOD(Level of Detail) 기능으로 렌더링 부하를 동적으로 줄일 수 있다 [26-28].
-*   **인스턴싱([[Instancing]])의 구조적 한계:**
-    `InstancedMesh`는 성능 향상에 필수적인 도구지만 몇 가지 한계가 있다. 엔진 수준에서 전체 인스턴스를 아우르는 하나의 경계 볼륨(Bounding Volume)을 기준으로 시야 절두체 컬링([[Frustum Culling]])을 처리하기 때문에, 시야 밖에 있는 인스턴스에 대해서도 GPU 정점 연산을 수행하는 비효율이 발생한다 [29, 30]. 또한, 객체들의 심도에 따른 자동 정렬(Depth [[Sorting]])을 제공하지 않아, 투명한 객체가 겹쳐 있거나 복잡한 셰이더를 사용할 경우 심각한 오버드로우([[Overdraw]])를 유발하여 GPU 프래그먼트 처리 병목을 초래할 수 있다 [31-34].
-*   **사용자 입력과 레이캐스팅([[Raycasting]]):**
-    사용자의 마우스나 터치 입력을 통한 화면 상의 3D 객체 선택(피킹)은 `[[Raycaster]]` 객체를 통해 수행된다 [35, 36]. 하지만 `InstancedMesh`에서 개별 인스턴스의 행렬(위치/회전/축척)을 동적으로 변경할 경우, 레이캐스팅이 정상 작동하려면 변경 직후 반드시 `.computeBoundingSphere()` 및 `.computeBoundingBox()`를 호출하여 바운딩 볼륨을 갱신해야 한다 [37, 38]. 다량의 인스턴스가 존재하는 환경에서 충돌 및 선택의 속도를 높이려면 `[[three-mesh-bvh]]` 같은 공간 분할(Spatial Indexing) 라이브러리를 활용하는 것이 권장된다 [39, 40].
+    Three.js는 GPU 리소스를 자동으로 가비지 컬렉션([[Garbage Collection|Garbage Collection]])하지 않으므로, 사용이 끝난 지오메트리, 재질, 텍스처는 반드시 `.dispose()` 메서드를 호출해 명시적으로 해제해야만 VRAM 누수를 막을 수 있다 [21, 22]. 모델 로드 시 대역폭과 메모리를 아끼기 위해 Draco 지오메트리 압축, KTX2 및 Basis Universal과 같은 GPU 네이티브 텍스처 압축 기술이 필수적이며 [23-25], 카메라 거리에 따라 다각형 수를 조절하는 LOD(Level of Detail) 기능으로 렌더링 부하를 동적으로 줄일 수 있다 [26-28].
+*   **인스턴싱([[Instancing|Instancing]])의 구조적 한계:**
+    `InstancedMesh`는 성능 향상에 필수적인 도구지만 몇 가지 한계가 있다. 엔진 수준에서 전체 인스턴스를 아우르는 하나의 경계 볼륨(Bounding Volume)을 기준으로 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])을 처리하기 때문에, 시야 밖에 있는 인스턴스에 대해서도 GPU 정점 연산을 수행하는 비효율이 발생한다 [29, 30]. 또한, 객체들의 심도에 따른 자동 정렬(Depth Sorting)을 제공하지 않아, 투명한 객체가 겹쳐 있거나 복잡한 셰이더를 사용할 경우 심각한 오버드로우([[Overdraw|Overdraw]])를 유발하여 GPU 프래그먼트 처리 병목을 초래할 수 있다 [31-34].
+*   **사용자 입력과 레이캐스팅([[Raycasting|Raycasting]]):**
+    사용자의 마우스나 터치 입력을 통한 화면 상의 3D 객체 선택(피킹)은 `[[Raycaster|Raycaster]]` 객체를 통해 수행된다 [35, 36]. 하지만 `InstancedMesh`에서 개별 인스턴스의 행렬(위치/회전/축척)을 동적으로 변경할 경우, 레이캐스팅이 정상 작동하려면 변경 직후 반드시 `.computeBoundingSphere()` 및 `.computeBoundingBox()`를 호출하여 바운딩 볼륨을 갱신해야 한다 [37, 38]. 다량의 인스턴스가 존재하는 환경에서 충돌 및 선택의 속도를 높이려면 `[[three-mesh-bvh|three-mesh-bvh]]` 같은 공간 분할(Spatial Indexing) 라이브러리를 활용하는 것이 권장된다 [39, 40].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[InstancedMesh]], BatchedMesh, [[TSL (Three Shader Language)]], [[Raycaster]], LOD (Level of Detail)
-- **Projects/Contexts:** [[React Three Fiber (R3F)]], IFC.js, [[InstancedMesh2]]
+- **Related Topics:** [[WebGPU|WebGPU]], InstancedMesh, BatchedMesh, TSL (Three Shader Language), [[Raycaster|Raycaster]], LOD (Level of Detail)
+- **Projects/Contexts:** [[React Three Fiber (R3F)|React Three Fiber (R3F]], IFC.js, [[InstancedMesh2|InstancedMesh2]]
 - **Contradictions/Notes:** 일반적으로 `InstancedMesh`는 드로우 콜을 1회로 줄여 렌더링 성능을 획기적으로 높인다고 알려져 있으나, 인스턴스의 자동 정렬 기능이 없어 오버드로우(Overdraw)가 빈번하게 발생할 경우 단일 메쉬를 분할하여 그릴 때보다 오히려 프레임 속도(FPS)가 급락할 수 있습니다 [4, 31-33]. 또한 여러 다른 지오메트리를 하나의 렌더 호출로 묶어주는 `BatchedMesh` 역시, 지나치게 많은 수의 정점과 데이터를 렌더링할 경우 패킹 및 컬링 연산 때문에 극심한 CPU 과부하와 성능 저하를 야기할 수 있다는 한계가 보고되고 있습니다 [41, 42].
 
 ---

10_Wiki/Topics/Graphics & Performance/Timestamp Quantization.md

@@ -1,20 +1,20 @@
 ---
-id: [[P-Reinforce]]-AUTO-B27B31
+id: [[P-Reinforce|P-Reinforce]]-AUTO-B27B31
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timestamp [[Quantization]]"
+github_commit: "[P-Reinforce] Continuous Worker - Timestamp [[Quantization|Quantization]]"
 ---
 
-# [[Timestamp Quantization]]
+# [[Timestamp Quantization|Timestamp Quantization]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타임스탬프 양자화(Timestamp Quantization)는 [[WebGPU]] 등 웹 그래픽 API에서 발생할 수 있는 타이밍 공격([[Timing Attack]]) 및 기기 핑거프린팅을 방지하기 위해, 타이머 쿼리의 해상도를 의도적으로 조대화(coarsening)하여 낮추는 보안 메커니즘입니다 [1-3]. 고정밀 타이밍 정보가 캐시 사이드 채널 공격이나 [[Rowhammer]] 공격 등에 악용되는 것을 막기 위해 브라우저 엔진은 타임스탬프의 측정 해상도를 100 마이크로초(µs)와 같은 표준 단위로 제한합니다 [1, 4-6].
+> 타임스탬프 양자화(Timestamp Quantization)는 [[WebGPU|WebGPU]] 등 웹 그래픽 API에서 발생할 수 있는 타이밍 공격(Timing Attack) 및 기기 핑거프린팅을 방지하기 위해, 타이머 쿼리의 해상도를 의도적으로 조대화(coarsening)하여 낮추는 보안 메커니즘입니다 [1-3]. 고정밀 타이밍 정보가 캐시 사이드 채널 공격이나 [[Rowhammer|Rowhammer]] 공격 등에 악용되는 것을 막기 위해 브라우저 엔진은 타임스탬프의 측정 해상도를 100 마이크로초(µs)와 같은 표준 단위로 제한합니다 [1, 4-6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 GPU 명령어의 실행 시간을 나노초(nanosecond) 단위로 정밀하게 측정할 수 있도록 지원합니다 [6, 7]. 그러나 이러한 고해상도 타이밍 정보는 캐시 적중률과 메모리 접근 패턴을 관찰 가능하게 만들어 [[Spectre]], Meltdown과 같은 사이드 채널 공격이나 GPU 물리적 메모리 구조를 파악해 조작하는 Rowhammer 공격에 악용될 수 있습니다 [1, 5, 8-10].
-* **양자화 및 조대화(Coarsening) 적용:** 이러한 보안 위협을 완화하기 위해 [[Chrome]]의 WebGPU 백엔드인 Dawn 및 [[Blink]] 엔진 등은 타임스탬프 양자화를 구현합니다 [1, 2]. WebGPU 표준 기구 및 브라우저 벤더들은 High Re[[Solution]] Time(hr-time) 사양과 일치하도록 GPU 타임스탬프를 비격리 컨텍스트와 동일하게 100 마이크로초(100µs) 해상도로 조대화하는 방식을 채택했습니다 [4-6, 11].
+* **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 GPU 명령어의 실행 시간을 나노초(nanosecond) 단위로 정밀하게 측정할 수 있도록 지원합니다 [6, 7]. 그러나 이러한 고해상도 타이밍 정보는 캐시 적중률과 메모리 접근 패턴을 관찰 가능하게 만들어 [[Spectre|Spectre]], Meltdown과 같은 사이드 채널 공격이나 GPU 물리적 메모리 구조를 파악해 조작하는 Rowhammer 공격에 악용될 수 있습니다 [1, 5, 8-10].
+* **양자화 및 조대화(Coarsening) 적용:** 이러한 보안 위협을 완화하기 위해 [[Chrome|Chrome]]의 WebGPU 백엔드인 Dawn 및 Blink 엔진 등은 타임스탬프 양자화를 구현합니다 [1, 2]. WebGPU 표준 기구 및 브라우저 벤더들은 High Re[[Solution|Solution]] Time(hr-time) 사양과 일치하도록 GPU 타임스탬프를 비격리 컨텍스트와 동일하게 100 마이크로초(100µs) 해상도로 조대화하는 방식을 채택했습니다 [4-6, 11].
 * **개발자 도구를 통한 예외 처리:** 성능 프로파일링을 위해 고정밀 측정이 필요한 개발자를 위해, Chrome에서는 로컬 환경에서 `chrome://flags/#enable-webgpu-developer-features` 플래그를 활성화하여 이 양자화(제한)를 우회하고 본래의 나노초 단위 정밀도를 사용할 수 있는 예외를 제공합니다 [2, 12].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -22,9 +22,9 @@ github_commit: "[P-Reinforce] Continuous Worker - Timestamp [[Quantization]]"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timing Attack]], [[Side-channel Attack]], [[Spectre]], [[Rowhammer]], [[High Resolution Time]]
-- **Projects/Contexts:** Chrome (Blink/Dawn), [[GPU for the Web Comm[[Unity]] Group]]
-- **Contradictions/Notes:** Chrome의 초기 제안에서는 교차 출처 격리(cross-origin isolated) 상태에 따라 격리된 컨텍스트에서는 100µs 해상도를 제공하고 비격리 컨텍스트에서는 타임스탬프를 아예 노출하지 않으려 했습니다 [3, 13]. 그러나 상호운용성([[Inter[[Opera]]bility]]) 문제와 모호한 사양에 대한 지적이 제기되었고, 최종적으로는 사이트 격리 상태와 무관하게 항상 100µs 해상도로 타임스탬프를 허용하는 방안이 합의되었습니다 [5, 11, 14].
+- **Related Topics:** [[WebGPU|WebGPU]], Timing Attack, Side-channel Attack, [[Spectre|Spectre]], Rowhammer, [[High Resolution Time|High Resolution Time]]
+- **Projects/Contexts:** Chrome (Blink/Dawn), [[GPU for the Web Community Group|GPU for the Web CommUnity Group]]
+- **Contradictions/Notes:** Chrome의 초기 제안에서는 교차 출처 격리(cross-origin isolated) 상태에 따라 격리된 컨텍스트에서는 100µs 해상도를 제공하고 비격리 컨텍스트에서는 타임스탬프를 아예 노출하지 않으려 했습니다 [3, 13]. 그러나 상호운용성([[Interoperability|InterOperability]]) 문제와 모호한 사양에 대한 지적이 제기되었고, 최종적으로는 사이트 격리 상태와 무관하게 항상 100µs 해상도로 타임스탬프를 허용하는 방안이 합의되었습니다 [5, 11, 14].
 
 ---
 *Last updated: 2026-04-19*

10_Wiki/Topics/Graphics & Performance/Timestamp Queries Quantization.md

@@ -1,20 +1,20 @@
 ---
-id: [[P-Reinforce]]-AUTO-788E1E
+id: [[P-Reinforce|P-Reinforce]]-AUTO-788E1E
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[Timestamp Queries]] [[Quantization]]"
+github_commit: "[P-Reinforce] Continuous Worker - [[Timestamp Queries|Timestamp Queries]] [[Quantization|Quantization]]"
 ---
 
-# [[Timestamp Queries Quantization]]
+# [[Timestamp Queries Quantization|Timestamp Queries Quantization]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타임스탬프 쿼리 양자화(Timestamp Queries Quantization)는 [[WebGPU]] 애플리케이션에서 GPU 명령의 실행 시간을 측정할 때 그 정밀도를 의도적으로 낮추는 보안 메커니즘입니다 [1], [2], [3], [4]. 개발자는 타임스탬프 쿼리를 통해 나노초 단위의 정밀한 데이터를 얻을 수 있지만, 이는 [[Spectre]]나 [[Rowhammer]]와 같은 캐시 기반 타이밍 공격([[Timing Attack]])에 악용될 수 있습니다 [5], [1], [2], [6]. 이를 방지하기 위해 브라우저 엔진은 반환되는 타이머의 해상도를 100 마이크로초(µs) 수준으로 낮추어 보안과 성능 분석의 균형을 맞춥니다 [1], [7], [3], [4].
+> 타임스탬프 쿼리 양자화(Timestamp Queries Quantization)는 [[WebGPU|WebGPU]] 애플리케이션에서 GPU 명령의 실행 시간을 측정할 때 그 정밀도를 의도적으로 낮추는 보안 메커니즘입니다 [1], [2], [3], [4]. 개발자는 타임스탬프 쿼리를 통해 나노초 단위의 정밀한 데이터를 얻을 수 있지만, 이는 Spectre나 Rowhammer와 같은 캐시 기반 타이밍 공격([[Timing Attack|Timing Attack]])에 악용될 수 있습니다 [5], [1], [2], [6]. 이를 방지하기 위해 브라우저 엔진은 반환되는 타이머의 해상도를 100 마이크로초(µs) 수준으로 낮추어 보안과 성능 분석의 균형을 맞춥니다 [1], [7], [3], [4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 패스(pass)의 시작과 끝 등 GPU 워크로드의 실행 시간을 나노초 단위까지 정밀하게 측정할 수 있도록 지원합니다 [2], [4]. 하지만 고정밀 타이머는 악의적인 공격자가 캐시 적중률과 물리적 메모리 구조를 파악하여 Spectre, Meltdown, Rowhammer 같은 사이드 채널 공격을 수행하거나 기기 지문을 수집(Fingerprinting)하는 데 사용될 수 있습니다 [5], [1], [8], [6]. 과거 [[WebGL]]의 `EXT_disjoint_timer_query` 확장 역시 동일한 보안 문제로 인해 브라우저에서 비활성화되거나 제한된 바 있습니다 [5], [1], [9].
-- **양자화(Quantization/Coarsening)의 동작 방식:** 타이밍 공격을 방어하기 위해 [[Chrome]]의 [[Blink]] 및 Dawn과 같은 엔진은 타임스탬프 쿼리의 해상도를 인위적으로 낮추는 '양자화(또는 조대화, Coarsening)'를 구현했습니다 [7], [3]. 본래 격리된 컨텍스트(Isolated context)에서만 100 마이크로초 해상도를 제공하고 비격리 환경에서는 노출하지 않으려 했으나 [7], [3], 이후 브라우저 간 상호 운용성을 확보하고 High Re[[Solution]] Time 사양과 일치시키기 위해 사이트 격리 여부와 무관하게 100 마이크로초(100µs)의 해상도를 제공하는 것으로 최종 합의되었습니다 [10], [11].
+- **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 패스(pass)의 시작과 끝 등 GPU 워크로드의 실행 시간을 나노초 단위까지 정밀하게 측정할 수 있도록 지원합니다 [2], [4]. 하지만 고정밀 타이머는 악의적인 공격자가 캐시 적중률과 물리적 메모리 구조를 파악하여 Spectre, Meltdown, Rowhammer 같은 사이드 채널 공격을 수행하거나 기기 지문을 수집(Fingerprinting)하는 데 사용될 수 있습니다 [5], [1], [8], [6]. 과거 [[WebGL|WebGL]]의 `EXT_disjoint_timer_query` 확장 역시 동일한 보안 문제로 인해 브라우저에서 비활성화되거나 제한된 바 있습니다 [5], [1], [9].
+- **양자화(Quantization/Coarsening)의 동작 방식:** 타이밍 공격을 방어하기 위해 [[Chrome|Chrome]]의 Blink 및 Dawn과 같은 엔진은 타임스탬프 쿼리의 해상도를 인위적으로 낮추는 '양자화(또는 조대화, Coarsening)'를 구현했습니다 [7], [3]. 본래 격리된 컨텍스트(Isolated context)에서만 100 마이크로초 해상도를 제공하고 비격리 환경에서는 노출하지 않으려 했으나 [7], [3], 이후 브라우저 간 상호 운용성을 확보하고 High Re[[Solution|Solution]] Time 사양과 일치시키기 위해 사이트 격리 여부와 무관하게 100 마이크로초(100µs)의 해상도를 제공하는 것으로 최종 합의되었습니다 [10], [11].
 - **개발자 환경에서의 우회:** 100 마이크로초 단위의 해상도는 단일 프레임 내의 정밀한 GPU 마이크로 지연 시간(Micro-latency)을 분석하기에는 지나치게 거칠 수 있습니다 [7], [12]. 따라서 정밀한 로컬 프로파일링이 필요한 개발자는 Chrome 브라우저에서 `chrome://flags/#enable-webgpu-developer-features` 플래그를 활성화하여 양자화 제한을 해제하고, 나노초 단위의 원본 타임스탬프 데이터를 획득할 수 있습니다 [7], [13], [14], [4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -22,8 +22,8 @@ github_commit: "[P-Reinforce] Continuous Worker - [[Timestamp Queries]] [[Quanti
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timing Attack]], [[Spectre]], EXT_disjoint_timer_query
-- **Projects/Contexts:** [[High Resolution Time]] Spec, [[Chrome DevTools]]
+- **Related Topics:** [[WebGPU|WebGPU]], Timing Attack, [[Spectre|Spectre]], EXT_disjoint_timer_query
+- **Projects/Contexts:** [[High Resolution Time|High Resolution Time]] Spec, [[Chrome DevTools|Chrome DevTools]]
 - **Contradictions/Notes:** 초기 WebGPU 사양 제안에서는 사이트 격리(Site isolation) 여부에 따라 타임스탬프 쿼리 제공 여부를 차등 적용(비격리 시 완전히 미노출)하려 했으나 [3], 이후 표준화 논의 과정에서 상호 운용성을 위해 모든 컨텍스트에 대해 100 마이크로초의 해상도를 일괄 제공하도록 정책이 변경되었습니다 [10], [11].
 
 ---

10_Wiki/Topics/Graphics & Performance/Timestamp Queries.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-77D993
+id: [[P-Reinforce|P-Reinforce]]-AUTO-77D993
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Timestamp Queries"
 ---
 
-# [[Timestamp Queries]]
+# [[Timestamp Queries|Timestamp Queries]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Timestamp Queries(타임스탬프 쿼리)는 [[WebGL]] 및 [[WebGPU]]와 같은 웹 그래픽 파이프라인에서 GPU 명령 세트의 경과 시간을 나노초 단위까지 정밀하게 측정할 수 있게 해주는 기능입니다 [1-3]. 렌더링 파이프라인을 지연시키지 않으면서 GPU 작업 부하의 성능과 동작에 대한 깊은 통찰력을 제공하는 데 필수적입니다 [3, 4]. 그러나 고정밀 타이머가 사이드 채널 공격(예: [[Spectre]] 및 Meltdown)에 악용될 수 있다는 보안 취약점 때문에, 최신 브라우저 환경에서는 타이머의 정밀도를 의도적으로 낮추는 양자화([[Quantization]]) 기법이 적용됩니다 [2, 5, 6].
+> Timestamp Queries(타임스탬프 쿼리)는 [[WebGL|WebGL]] 및 WebGPU와 같은 웹 그래픽 파이프라인에서 GPU 명령 세트의 경과 시간을 나노초 단위까지 정밀하게 측정할 수 있게 해주는 기능입니다 [1-3]. 렌더링 파이프라인을 지연시키지 않으면서 GPU 작업 부하의 성능과 동작에 대한 깊은 통찰력을 제공하는 데 필수적입니다 [3, 4]. 그러나 고정밀 타이머가 사이드 채널 공격(예: Spectre 및 Meltdown)에 악용될 수 있다는 보안 취약점 때문에, 최신 브라우저 환경에서는 타이머의 정밀도를 의도적으로 낮추는 양자화([[Quantization|Quantization]]) 기법이 적용됩니다 [2, 5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **WebGL에서의 타이머 쿼리 한계:**
@@ -22,15 +22,15 @@ github_commit: "[P-Reinforce] Continuous Worker - Timestamp Queries"
 *   **교차 출처(Cross-origin) 및 하드웨어 특성을 반영한 정책 변경:**
     이후 논의 과정에서 GPU 타임스탬프는 고립된 컨텍스트 간에도 공유될 수 있으며 GPU 캐시를 통한 타이밍 공격 위험이 여전히 존재함이 확인되었습니다 [6]. 상호 운용성(Interop)을 높이고 보안을 유지하기 위해, 사이트의 교차 출처 격리(cross-origin isolated) 상태와 무관하게 항상 고해상도 시간 사양(HR-time)에 맞추어 100 마이크로초(µs)로 해상도를 거칠게 만드는(coarsening) 것으로 최종 정책이 합의되었습니다 [6, 9].
 *   **개발자를 위한 예외 처리:** 
-    성능 프로파일링을 위해 실제 나노초 단위의 정밀한 측정값이 필요한 개발자는 로컬 환경에서 "WebGPU Developer Features" 또는 "Unsafe WebGPU [[Support]]" 같은 특정 브라우저 플래그를 활성화하여 이러한 양자화 제한을 일시적으로 우회할 수 있습니다 [8, 10].
+    성능 프로파일링을 위해 실제 나노초 단위의 정밀한 측정값이 필요한 개발자는 로컬 환경에서 "WebGPU Developer Features" 또는 "Unsafe WebGPU [[Support|Support]]" 같은 특정 브라우저 플래그를 활성화하여 이러한 양자화 제한을 일시적으로 우회할 수 있습니다 [8, 10].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** WebGL Timer Queries, [[Spectre and Meltdown]], [[WebGPU]], [[Timestamp Quantization]]
-- **Projects/Contexts:** EXT_disjoint_timer_query, High Re[[Solution]] Time Spec
+- **Related Topics:** WebGL Timer Queries, [[Spectre and Meltdown|Spectre and Meltdown]], WebGPU, [[Timestamp Quantization|Timestamp Quantization]]
+- **Projects/Contexts:** EXT_disjoint_timer_query, High Re[[Solution|Solution]] Time Spec
 - **Contradictions/Notes:** 초기 WebGPU 구현 제안에서는 사이트 격리 상태에 따라 타임스탬프 쿼리의 노출 여부와 해상도를 다르게 적용하려고 했으나(격리 시 100µs, 비격리 시 미노출) [5], 브라우저 간의 상호 운용성 부족 및 GPU의 격리 한계를 이유로 격리 상태와 관계없이 모든 GPU 작업에 대해 일괄적으로 100µs 해상도를 적용하도록 사양이 수정되었습니다 [6, 9].
 
 ---

10_Wiki/Topics/Graphics & Performance/TypedArray.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-DEE006
+id: [[P-Reinforce|P-Reinforce]]-AUTO-DEE006
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,14 +7,14 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - TypedArray"
 ---
 
-# [[TypedArray]]
+# [[TypedArray|TypedArray]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypedArray는 Three.js 등의 [[WebGL]] 렌더링 환경에서 정점 데이터나 인스턴스의 속성값(예: `Float32Array`를 통한 UV 오프셋 등)을 저장하고 GPU로 전달하기 위해 사용되는 자바스크립트의 데이터 구조입니다 [1, 2]. 대규모 그래픽 데이터를 처리하는 데 사용되지만, 동적 환경에서 잦은 할당 및 해제는 성능 저하를 일으킬 수 있습니다 [3]. 다만 본 문서의 전반적인 작동 원리나 세부 명세에 대해서는 **소스에 관련 정보가 부족합니다.**
+> TypedArray는 Three.js 등의 [[WebGL|WebGL]] 렌더링 환경에서 정점 데이터나 인스턴스의 속성값(예: `Float32Array`를 통한 UV 오프셋 등)을 저장하고 GPU로 전달하기 위해 사용되는 자바스크립트의 데이터 구조입니다 [1, 2]. 대규모 그래픽 데이터를 처리하는 데 사용되지만, 동적 환경에서 잦은 할당 및 해제는 성능 저하를 일으킬 수 있습니다 [3]. 다만 본 문서의 전반적인 작동 원리나 세부 명세에 대해서는 **소스에 관련 정보가 부족합니다.**
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **소스에 관련 정보가 부족합니다.** TypedArray에 대한 포괄적이고 전문적인 원리는 소스 데이터에 명시되어 있지 않으며, 주로 Three.js의 메모리 관리 및 성능 최적화 문맥에서 제한적으로 언급됩니다.
-* **데이터 버퍼 할당 및 활용:** Three.js에서 `[[InstancedMesh]]` 등을 사용하여 개별 인스턴스에 고유한 텍스처 UV 오프셋이나 기타 속성을 부여할 때, `Float32Array`와 같은 TypedArray를 기반으로 `Instanced[[BufferAttribute]]`를 생성하여 GPU에 데이터를 전달합니다 [1, 2]. 
+* **데이터 버퍼 할당 및 활용:** Three.js에서 `[[InstancedMesh|InstancedMesh]]` 등을 사용하여 개별 인스턴스에 고유한 텍스처 UV 오프셋이나 기타 속성을 부여할 때, `Float32Array`와 같은 TypedArray를 기반으로 `Instanced[[BufferAttribute|BufferAttribute]]`를 생성하여 GPU에 데이터를 전달합니다 [1, 2]. 
 * **가비지 컬렉션(GC) 부하 및 성능 병목:** 객체의 수가 동적으로 변하여 `InstancedMesh`의 초기 할당 용량(Capacity)을 초과하게 되면, 엔진은 더 큰 버퍼를 할당하고 기존 데이터를 복사해야 합니다 [3]. 이 과정에서 수십 메가바이트 단위의 TypedArray가 빈번하게 생성되고 파괴될 경우 자바스크립트 엔진의 가비지 컬렉터가 작동하게 되며, 이는 렌더링 프레임이 일시적으로 멈추는 스터터링(Stuttering) 현상의 직접적인 원인이 됩니다 [3].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -22,7 +22,7 @@ github_commit: "[P-Reinforce] Continuous Worker - TypedArray"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], InstancedBufferAttribute, [[Garbage Collection]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], InstancedBufferAttribute, [[Garbage Collection|Garbage Collection]]
 - **Projects/Contexts:** Three.js 메모리 관리 및 렌더링 최적화
 - **Contradictions/Notes:** 제공된 소스는 TypedArray 자체의 기능적 설명보다는, 이를 활용한 대규모 인스턴스 환경에서 동적 버퍼 확장이 유발하는 메모리 해제와 생성의 위험성(프레임 드랍)을 경고하는 데 초점을 맞추고 있습니다 [3].
 

10_Wiki/Topics/Graphics & Performance/UV Offset.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-FF2C8C
+id: [[P-Reinforce|P-Reinforce]]-AUTO-FF2C8C
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,23 +7,23 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - UV Offset"
 ---
 
-# [[UV Offset]]
+# [[UV Offset|UV Offset]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> UV Offset(UV 오프셋)은 3D 모델에 텍스처의 특정 영역을 매핑하기 위해 UV 좌표를 조정하거나 계산하는 기법입니다 [1, 2]. 실시간 렌더링 최적화 환경에서는 여러 텍스처를 하나로 합친 텍스처 아틀라스([[Texture Atlas]])와 함께 주로 사용됩니다 [3, 4]. 특히 수많은 인스턴스를 렌더링할 때 각 인스턴스의 속성으로 UV 오프셋을 전달함으로써, 단일 드로우 콜([[Draw Call]]) 내에서 개별 인스턴스마다 다른 텍스처 이미지를 적용할 수 있게 해줍니다 [5, 6].
+> UV Offset(UV 오프셋)은 3D 모델에 텍스처의 특정 영역을 매핑하기 위해 UV 좌표를 조정하거나 계산하는 기법입니다 [1, 2]. 실시간 렌더링 최적화 환경에서는 여러 텍스처를 하나로 합친 텍스처 아틀라스([[Texture Atlas|Texture Atlas]])와 함께 주로 사용됩니다 [3, 4]. 특히 수많은 인스턴스를 렌더링할 때 각 인스턴스의 속성으로 UV 오프셋을 전달함으로써, 단일 드로우 콜([[Draw Call|Draw Call]]) 내에서 개별 인스턴스마다 다른 텍스처 이미지를 적용할 수 있게 해줍니다 [5, 6].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **텍스처 아틀라스 매핑 (Texture Atlas Mapping):** 텍스처 바인딩 횟수와 드로우 콜을 줄이기 위해 여러 텍스처를 단일 텍스처 아틀라스로 병합할 때, 개발자는 메쉬 영역이 아틀라스의 올바른 위치를 참조하도록 UV 좌표를 조정(UV Offset 계산)해야 합니다 [1-4].
-* **[[InstancedMesh]]에서의 구현 방식:** `InstancedMesh`를 통해 수천 개의 개별 인스턴스에 각기 다른 텍스처를 부여하기 위해서는 단일 재질(Material)의 확산 맵(Diffuse map)으로 텍스처 아틀라스를 지정해야 합니다 [5, 7]. 이후 각 인스턴스마다 텍스처 오프셋을 정의하는 추가적인 인스턴스 버퍼 속성(예: `uvOffsets`)을 기하구조(Geometry)에 주입합니다 [5, 6, 8]. 구체적으로는 `Float32Array`를 사용해 각 인스턴스의 x/y 오프셋 좌표 배열을 생성한 뒤, 셰이더를 수정하여 이 `uvOffsets` 속성을 기반으로 각 인스턴스의 텍스처 위치를 이동(Offset)시키도록 렌더링합니다 [8-10].
-* **한계 및 현대적 대안:** 텍스처 아틀라스를 위한 복잡한 UV 오프셋 계산 알고리즘은 까다로울 뿐만 아니라, 인접한 텍스처 간에 픽셀이 섞이는 경계선 블리딩([[Edge Bleeding]]) 현상을 유발할 수 있습니다 [2, 6]. 이러한 단점을 극복하기 위해 [[WebGL]]2부터 지원되는 데이터 배열 텍스처([[Data Array Textures]])를 활용하면, 복잡한 UV 오프셋 연산이나 패킹 없이 인덱스 접근만으로 다중 텍스처를 처리할 수 있습니다 [2, 11].
+* **[[InstancedMesh|InstancedMesh]]에서의 구현 방식:** `InstancedMesh`를 통해 수천 개의 개별 인스턴스에 각기 다른 텍스처를 부여하기 위해서는 단일 재질(Material)의 확산 맵(Diffuse map)으로 텍스처 아틀라스를 지정해야 합니다 [5, 7]. 이후 각 인스턴스마다 텍스처 오프셋을 정의하는 추가적인 인스턴스 버퍼 속성(예: `uvOffsets`)을 기하구조(Geometry)에 주입합니다 [5, 6, 8]. 구체적으로는 `Float32Array`를 사용해 각 인스턴스의 x/y 오프셋 좌표 배열을 생성한 뒤, 셰이더를 수정하여 이 `uvOffsets` 속성을 기반으로 각 인스턴스의 텍스처 위치를 이동(Offset)시키도록 렌더링합니다 [8-10].
+* **한계 및 현대적 대안:** 텍스처 아틀라스를 위한 복잡한 UV 오프셋 계산 알고리즘은 까다로울 뿐만 아니라, 인접한 텍스처 간에 픽셀이 섞이는 경계선 블리딩([[Edge Bleeding|Edge Bleeding]]) 현상을 유발할 수 있습니다 [2, 6]. 이러한 단점을 극복하기 위해 WebGL2부터 지원되는 데이터 배열 텍스처([[Data Array Textures|Data Array Textures]])를 활용하면, 복잡한 UV 오프셋 연산이나 패킹 없이 인덱스 접근만으로 다중 텍스처를 처리할 수 있습니다 [2, 11].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Texture Atlas]], [[InstancedMesh]], [[BufferAttribute]]
-- **Projects/Contexts:** Three.js, [[WebGL Optimization]]
+- **Related Topics:** [[Texture Atlas|Texture Atlas]], InstancedMesh, [[BufferAttribute|BufferAttribute]]
+- **Projects/Contexts:** Three.js, [[WebGL Optimization|WebGL Optimization]]
 - **Contradictions/Notes:** 텍스처 아틀라스와 UV 오프셋의 조합은 인스턴싱 최적화를 위해 필수적이지만 UV 연산의 복잡성과 경계선 블리딩(Edge Bleeding)이라는 한계를 가지며, 소스에 따르면 이를 완전히 회피하기 위한 대안으로 데이터 배열 텍스처(Data Array Textures)의 사용이 제안됩니다 [2, 11].
 
 ---

10_Wiki/Topics/Graphics & Performance/Unity.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-6033D2
+id: [[P-Reinforce|P-Reinforce]]-AUTO-6033D2
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,19 +7,19 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Unity"
 ---
 
-# [[Unity]]
+# [[Unity|Unity]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Unity는 2D 및 3D 프로젝트를 개발할 수 있는 소프트웨어 엔진 및 플랫폼입니다 [1]. 그래픽 렌더링 파이프라인, 물리 시스템, 씬(Scene) 및 게임 오브젝트(GameObject) 구성을 지원하며, 높은 그래픽 성능을 달성하기 위한 다양한 도구를 제공합니다 [1, 2]. 특히 화면에 기하학적 구조를 그리기 위해 그래픽 API에 명령을 내리는 드로우 콜([[Draw Call]])과 렌더 상태 변경(Render-[[State]] changes)을 최적화하는 아키텍처가 핵심적으로 다뤄집니다 [3, 4].
+> Unity는 2D 및 3D 프로젝트를 개발할 수 있는 소프트웨어 엔진 및 플랫폼입니다 [1]. 그래픽 렌더링 파이프라인, 물리 시스템, 씬(Scene) 및 게임 오브젝트(GameObject) 구성을 지원하며, 높은 그래픽 성능을 달성하기 위한 다양한 도구를 제공합니다 [1, 2]. 특히 화면에 기하학적 구조를 그리기 위해 그래픽 API에 명령을 내리는 드로우 콜([[Draw Call|Draw Call]])과 렌더 상태 변경(Render-[[State|State]] changes)을 최적화하는 아키텍처가 핵심적으로 다뤄집니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **드로우 콜(Draw Calls) 및 성능 최적화**
-  Unity는 기하학적 구조, 텍스처, 셰이더 등의 정보를 그래픽 API에 전달하여 화면을 그리기 위해 드로우 콜을 발생시킵니다 [3]. 재질을 변경하는 등의 렌더 상태([[Render State]]) 변경 과정은 CPU 자원을 매우 많이 소모하므로, 드로우 콜의 총 횟수를 줄이고 렌더 상태 변경이 적게 일어나도록 호출을 구성하는 것이 성능 최적화의 핵심입니다 [4, 5].
+  Unity는 기하학적 구조, 텍스처, 셰이더 등의 정보를 그래픽 API에 전달하여 화면을 그리기 위해 드로우 콜을 발생시킵니다 [3]. 재질을 변경하는 등의 렌더 상태([[Render State|Render State]]) 변경 과정은 CPU 자원을 매우 많이 소모하므로, 드로우 콜의 총 횟수를 줄이고 렌더 상태 변경이 적게 일어나도록 호출을 구성하는 것이 성능 최적화의 핵심입니다 [4, 5].
 
 - **드로우 콜 최적화 기법**
   Unity는 드로우 콜과 렌더 상태 변경을 최적화하기 위해 다음과 같은 내장 방법들을 제공합니다 [2].
-  - **GPU 인스턴싱(GPU [[Instancing]]):** 나무나 덤불처럼 씬에 반복적으로 나타나는 동일한 메쉬의 여러 복사본을 동시에 렌더링합니다 [2].
-  - **드로우 콜 배칭(Draw Call [[Batching]]):** 움직이지 않는 정적 게임 오브젝트들의 메쉬를 사전에 결합하는 '정적 배칭(Static batching)'과, CPU에서 동일한 속성을 가진 정점들을 그룹화하여 한 번의 드로우 콜로 렌더링하는 '동적 배칭(Dynamic batching)'이 있습니다 [2].
+  - **GPU 인스턴싱(GPU [[Instancing|Instancing]]):** 나무나 덤불처럼 씬에 반복적으로 나타나는 동일한 메쉬의 여러 복사본을 동시에 렌더링합니다 [2].
+  - **드로우 콜 배칭(Draw Call [[Batching|Batching]]):** 움직이지 않는 정적 게임 오브젝트들의 메쉬를 사전에 결합하는 '정적 배칭(Static batching)'과, CPU에서 동일한 속성을 가진 정점들을 그룹화하여 한 번의 드로우 콜로 렌더링하는 '동적 배칭(Dynamic batching)'이 있습니다 [2].
   - **수동 메쉬 결합:** `Mesh.CombineMeshes` 함수를 사용하여 다수의 메쉬를 수동으로 단일 메쉬로 병합해 한 번의 호출로 렌더링합니다 [2].
   - **SRP 배처(SRP Batcher):** 스크립터블 렌더 파이프라인(SRP) 환경에서, 동일한 셰이더 변형(Shader variant)을 사용하는 재질에 대해 드로우 콜을 준비하는 CPU 소요 시간을 줄여줍니다 [2].
 
@@ -27,7 +27,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Unity"
   여러 최적화 기법이 중복으로 설정될 경우, Unity는 가장 높은 우선순위의 방법을 적용합니다. 우선순위는 1. SRP 배처 및 정적 배칭, 2. GPU 인스턴싱, 3. 동적 배칭 순입니다 [6, 7]. 예를 들어, 객체에 정적 배칭이 성공적으로 적용되면 해당 객체의 GPU 인스턴싱은 비활성화됩니다 [7].
 
 - **외부 도구와의 연동**
-  [[Needle Engine]]과 같은 도구와 함께 사용될 때, 성능 문제나 텍스처 누락 등을 해결하기 위해 Unity 환경 내에서 "Copy Project Info Into [[CLIP]]board" 기능을 사용하여 특정 설정 상태를 외부로 복사하고 디버깅할 수 있습니다 [8].
+  [[Needle Engine|Needle Engine]]과 같은 도구와 함께 사용될 때, 성능 문제나 텍스처 누락 등을 해결하기 위해 Unity 환경 내에서 "Copy Project Info Into [[CLIP|CLIP]]board" 기능을 사용하여 특정 설정 상태를 외부로 복사하고 디버깅할 수 있습니다 [8].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
@@ -35,7 +35,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Unity"
 
 ## 🔗 지식 연결 (Graph)
 - **Related Topics:** GPU Instancing, Draw Call Batching, Scriptable Render Pipeline (SRP), GameObject
-- **Projects/Contexts:** [[Needle Engine]], Optimizing draw calls
+- **Projects/Contexts:** [[Needle Engine|Needle Engine]], Optimizing draw calls
 - **Contradictions/Notes:** Unity는 여러 드로우 콜 최적화 옵션을 지원하지만 기법 간에 충돌이 발생할 수 있습니다. 렌더러가 인스턴싱 셰이더를 사용하더라도 정적 배칭(Static batching)이 적용되는 경우 Unity는 자동으로 GPU 인스턴싱을 비활성화하며, 인스펙터(Inspector) 창에 정적 배칭을 끄라는 경고 메시지를 표시합니다 [7].
 
 ---

10_Wiki/Topics/Graphics & Performance/Utsubo.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-468135
+id: [[P-Reinforce|P-Reinforce]]-AUTO-468135
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,19 +7,19 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Utsubo"
 ---
 
-# [[Utsubo]]
+# [[Utsubo|Utsubo]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Utsubo는 브랜드 웹사이트부터 물리적 설치물에 이르기까지 Three.js 개발을 전문으로 하는 기술 중심의 인터랙티브 크리에이티브 스튜디오이다 [1, 2]. 이들은 2024년 초에 최초의 프로덕션 [[WebGPU]] Three.js 환경 중 하나를 구축하여 출시했으며, WebGPU 성능 모니터링을 위한 `stats-gl`과 같은 도구를 개발하는 등 Three.js 생태계 발전에 적극적으로 기여하고 있다 [1].
+> Utsubo는 브랜드 웹사이트부터 물리적 설치물에 이르기까지 Three.js 개발을 전문으로 하는 기술 중심의 인터랙티브 크리에이티브 스튜디오이다 [1, 2]. 이들은 2024년 초에 최초의 프로덕션 [[WebGPU|WebGPU]] Three.js 환경 중 하나를 구축하여 출시했으며, WebGPU 성능 모니터링을 위한 `stats-gl`과 같은 도구를 개발하는 등 Three.js 생태계 발전에 적극적으로 기여하고 있다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **스튜디오 개요 및 전문 분야:** 
   Utsubo는 브랜드 웹사이트 제작부터 박물관 및 호텔을 위한 인터랙티브 설치물에 이르기까지 폭넓은 영역에서 Three.js 개발을 전문으로 하는 기술 우선(Technology-First) 크리에이티브 스튜디오이다 [1-3]. 이들은 테크 기업 및 브랜드 등과 협력하여 차세대 3D 웹 경험을 구축하고 있다 [3].
 * **WebGPU 및 생태계 기여:** 
-  Utsubo는 2024년 초 2024.utsubo.com을 통해 업계 최초 수준의 프로덕션 WebGPU Three.js 경험을 출시했다 [1]. 또한 [[WebGL]] 및 WebGPU 성능 모니터링을 위해 설계된 `stats-gl`과 같은 핵심 도구를 포함하여 Three.js 생태계에 활발하게 기여하고 있다 [1, 4]. Utsubo의 CEO이자 공동 창립자인 조슬린 르카뮈(Jocelyn Lecamus)는 Three.js가 단순한 웹사이트를 넘어 수백만 개의 데이터 포인트를 실시간으로 처리하는 애플리케이션으로 진화하고 있다고 강조한 바 있다 [5, 6].
+  Utsubo는 2024년 초 2024.utsubo.com을 통해 업계 최초 수준의 프로덕션 WebGPU Three.js 경험을 출시했다 [1]. 또한 [[WebGL|WebGL]] 및 WebGPU 성능 모니터링을 위해 설계된 `stats-gl`과 같은 핵심 도구를 포함하여 Three.js 생태계에 활발하게 기여하고 있다 [1, 4]. Utsubo의 CEO이자 공동 창립자인 조슬린 르카뮈(Jocelyn Lecamus)는 Three.js가 단순한 웹사이트를 넘어 수백만 개의 데이터 포인트를 실시간으로 처리하는 애플리케이션으로 진화하고 있다고 강조한 바 있다 [5, 6].
 * **주요 프로젝트 및 포트폴리오:**
   * **utsubo.com:** 수상 경력에 빛나는 고사양 3D 웹 경험(Award-winning 3D heavy experience)을 제공한다 [1].
-  * **호쿠사이(Hokusai) 설치물:** 2025 오사카 엑스포([[Expo 2025 Osaka]])에서 100만 개의 파티클을 활용한 유체 시뮬레이션을 구현하여 선보였다 [1].
+  * **호쿠사이(Hokusai) 설치물:** 2025 오사카 엑스포([[Expo 2025 Osaka|Expo 2025 Osaka]])에서 100만 개의 파티클을 활용한 유체 시뮬레이션을 구현하여 선보였다 [1].
   * **Segments.ai:** WebGPU로의 마이그레이션을 지원하여 기존 대비 100배의 성능 향상을 이끌어냈다 [1].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -27,8 +27,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Utsubo"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Three.js, [[WebGPU]], stats-gl
-- **Projects/Contexts:** [[Expo 2025 Osaka]], Segments.ai
+- **Related Topics:** Three.js, [[WebGPU|WebGPU]], stats-gl
+- **Projects/Contexts:** [[Expo 2025 Osaka|Expo 2025 Osaka]], Segments.ai
 - **Contradictions/Notes:** 소스에 관련된 모순 정보나 반대 주장이 부족합니다. (제공된 소스는 모두 Utsubo의 성과와 기술적 기여를 일관되게 긍정적으로 설명하고 있습니다.)
 
 ---

10_Wiki/Topics/Graphics & Performance/VR 엑서게임 (VR Exergaming).md

@@ -1,20 +1,20 @@
 ---
-id: [[P-Reinforce]]-AUTO-E1E503
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E1E503
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VR 엑서게임 (VR [[Exergaming]])"
+github_commit: "[P-Reinforce] Continuous Worker - VR 엑서게임 (VR [[Exergaming|Exergaming]])"
 ---
 
-# [[VR 엑서게임 (VR Exergaming)]]
+# [[VR 엑서게임 (VR Exergaming)|VR 엑서게임 (VR Exergaming]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> VR 엑서게임(VR Exergaming)은 운동(Exercise)과 게임 플레이(Gameplay)를 3D 가상 환경에 결합하여 신체 활동을 촉진하고 사람들의 좌식 생활 습관을 개선하는 활동을 말합니다 [1, 2]. 사용자에게 360도 공간과 신체 추적 기능을 제공하여 높은 몰입감을 유도하며, 이를 통해 운동에 수반되는 육체적 피로를 잊게 만들고 지속적인 참여 동기를 부여합니다 [2]. 대표적인 예시로 '비트 세이버([[Beat Saber]])'가 있으며, 실제 테니스와 맞먹는 에너지를 소모할 정도로 신체적, 심리적 이점을 모두 제공하는 도구로 주목받고 있습니다 [3].
+> VR 엑서게임(VR Exergaming)은 운동(Exercise)과 게임 플레이(Gameplay)를 3D 가상 환경에 결합하여 신체 활동을 촉진하고 사람들의 좌식 생활 습관을 개선하는 활동을 말합니다 [1, 2]. 사용자에게 360도 공간과 신체 추적 기능을 제공하여 높은 몰입감을 유도하며, 이를 통해 운동에 수반되는 육체적 피로를 잊게 만들고 지속적인 참여 동기를 부여합니다 [2]. 대표적인 예시로 '비트 세이버([[Beat Saber|Beat Saber]])'가 있으며, 실제 테니스와 맞먹는 에너지를 소모할 정도로 신체적, 심리적 이점을 모두 제공하는 도구로 주목받고 있습니다 [3].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 - **육체적 및 심리적 이점**: VR 엑서게임은 달리기나 에어로빅과 비견될 만한 생리학적 건강 증진 효과를 제공합니다 [1]. 특히 가상현실이 제공하는 강력한 몰입감과 존재감(Presence)은 사용자가 게임 목표에 깊이 빠져드는 '몰입(Flow)' 상태를 촉진하여, 전통적인 형태의 운동보다 훨씬 큰 즐거움과 운동 지속성을 이끌어냅니다 [1, 2]. 
-- **VR 멀미([[VR Sickness]])와 부작용**: VR 엑서게임 보급의 주요 장애물 중 하나는 메스꺼움, 눈의 피로(안구 운동 이상), 방향 감각 상실 등을 유발하는 VR 멀미입니다 [4, 5]. 엑서게임의 특성상 높은 수준의 사용자 움직임과 시각적 자극이 동시에 요구되기 때문에 멀미 발생 가능성이 크며, 이는 사용자의 몰입을 깨뜨리고 과제 수행 능력 및 즐거움을 저하시킬 수 있습니다 [4, 6].
+- **VR 멀미([[VR Sickness|VR Sickness]])와 부작용**: VR 엑서게임 보급의 주요 장애물 중 하나는 메스꺼움, 눈의 피로(안구 운동 이상), 방향 감각 상실 등을 유발하는 VR 멀미입니다 [4, 5]. 엑서게임의 특성상 높은 수준의 사용자 움직임과 시각적 자극이 동시에 요구되기 때문에 멀미 발생 가능성이 크며, 이는 사용자의 몰입을 깨뜨리고 과제 수행 능력 및 즐거움을 저하시킬 수 있습니다 [4, 6].
 - **노출 시간과 잔여 효과(Aftereffects)**: 10분과 50분의 VR 노출을 비교한 연구에 따르면, 노출 시간이 길어질수록 VR 종료 직후 더 심각한 멀미 증상이 보고되었습니다 [7]. HMD 기기 사용으로 인해 눈의 조절(Accommodation) 및 수렴(Convergence)에 시각적 변화가 일어날 수 있으나 [8], 전반적인 그룹 평균을 보았을 때 VR 종료 후 40분이 지나면 시각, 인지, 주관적 멀미 증상이 대부분 기준치로 회복되는 것으로 나타났습니다 [7, 9].
 - **인지적 영향**: VR 엑서게임은 단기적인 인지 및 결정 시간에 심각한 악영향을 주지 않습니다 [10, 11]. 오히려 10분간의 게임 플레이 직후에는 게임 내에서 요구되는 빠른 운동 동작의 결과로 사용자의 움직임 속도(Movement speed)가 소폭 빨라지는 긍정적인 현상도 관찰되었습니다 [11].
 
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - VR 엑서게임 (VR [[Exergami
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Flow State]], [[VR 멀미 (VR Sickness)]]
-- **Projects/Contexts:** [[Beat Saber]]
+- **Related Topics:** [[Flow State|Flow State]], [[VR 멀미 (VR Sickness)|VR 멀미 (VR Sickness]]
+- **Projects/Contexts:** [[Beat Saber|Beat Saber]]
 - **Contradictions/Notes:** 평균적인 그룹 데이터로는 VR 엑서게임 종료 40분 후 멀미 증상이 모두 회복되는 것으로 나타나지만, 개별 데이터에 따르면 50분 플레이 후 약 14%의 사용자는 40분 뒤에도 여전히 높은 수준의 멀미를 겪고 있어 심각한 개인차가 존재함을 알 수 있습니다 [12]. 또한, 문헌에 따라 VR 노출이 사용자의 반응 시간(Reaction time)에 미치는 영향이 긍정적이라는 연구와 부정적이라는 연구가 혼재되어 있습니다 [13].
 
 ---

10_Wiki/Topics/Graphics & Performance/Varying Variables.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-9ED1C2
+id: [[P-Reinforce|P-Reinforce]]-AUTO-9ED1C2
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Varying Variables"
 ---
 
-# [[Varying Variables]]
+# [[Varying Variables|Varying Variables]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Varying Variables(베어링 변수)는 3D 그래픽 파이프라인에서 버텍스 셰이더([[Vertex Shader]]s)와 프래그먼트 셰이더(fragment shaders) 간에 데이터를 전송하는 역할을 하는 변수입니다 [1]. 모바일 기기에서의 렌더링 성능을 위해 사용량을 최소화해야 하는 셰이더 최적화 대상 중 하나입니다 [1].
+> Varying Variables(베어링 변수)는 3D 그래픽 파이프라인에서 버텍스 셰이더([[Vertex Shader|Vertex Shader]]s)와 프래그먼트 셰이더(fragment shaders) 간에 데이터를 전송하는 역할을 하는 변수입니다 [1]. 모바일 기기에서의 렌더링 성능을 위해 사용량을 최소화해야 하는 셰이더 최적화 대상 중 하나입니다 [1].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 소스에 관련 정보가 부족합니다. 제공된 소스에서는 이 주제에 대한 깊이 있는 기술적 설명은 포함되어 있지 않으며, Three.js 셰이더 성능 최적화 관점에서의 단편적인 지침만 다음과 같이 제공됩니다.
@@ -23,8 +23,8 @@ github_commit: "[P-Reinforce] Continuous Worker - Varying Variables"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Vertex Shader]], Fragment Shader, Mobile GPU
-- **Projects/Contexts:** Three.js Performance [[Optimization]] (Shaders & Materials 최적화 팁)
+- **Related Topics:** [[Vertex Shader|Vertex Shader]], Fragment Shader, Mobile GPU
+- **Projects/Contexts:** Three.js Performance [[Optimization|Optimization]] (Shaders & Materials 최적화 팁)
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---

10_Wiki/Topics/Graphics & Performance/Vertex Shader.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-E201D0
+id: [[P-Reinforce|P-Reinforce]]-AUTO-E201D0
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,7 +7,7 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Vertex Shader"
 ---
 
-# [[Vertex Shader]]
+# [[Vertex Shader|Vertex Shader]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 > 버텍스 셰이더(Vertex Shader)는 렌더링 파이프라인에서 정점(Vertex)의 연산을 처리하는 셰이더 단계입니다 [1, 2]. 주로 인스턴스화된 메쉬(Instanced Mesh) 기반의 애니메이션을 처리하거나, 메쉬 데이터의 복제 없이 무작위 축척 및 회전 등을 절차적으로 변형하는 데 사용됩니다 [3, 4]. 계산된 데이터는 Varying 변수를 통해 프래그먼트 셰이더(Fragment Shader)로 전달됩니다 [1].
@@ -15,14 +15,14 @@ github_commit: "[P-Reinforce] Continuous Worker - Vertex Shader"
 ## 📖 구조화된 지식 (Synthesized Content)
 - **인스턴싱 및 절차적 기하학 변형:** 버텍스 셰이더는 인스턴스 메쉬에 적용되어 다수의 이미지를 월드 공간에서 움직이도록 하는 애니메이션 로직을 수행할 수 있습니다 [3]. 또한, 커스텀 버텍스 셰이더를 통해 메쉬 데이터를 복제하지 않고도 인스턴스별로 무작위 축척(Scale), 회전 오프셋, 정점 변위(Vertex Displacement) 등의 절차적 변형을 가하여 다양성을 만들어낼 수 있습니다 [4].
 - **프래그먼트 셰이더와의 데이터 전송:** 버텍스 셰이더에서 처리된 데이터는 Varying 변수를 통해 프래그먼트 셰이더로 전달됩니다 [1]. 모바일 GPU 환경에서 성능을 최적화하기 위해서는 이 Varying 변수의 사용을 3개 미만으로 최소화하는 것이 권장됩니다 [1].
-- **성능 병목과 연산 부하:** 버텍스 셰이더 단계에서 수행되는 행렬 곱셈 등의 연산은 렌더링되는 인스턴스의 수가 늘어날수록 선형적으로 증가합니다 [2]. 시야 절두체 컬링([[Frustum Culling]])이 제대로 이루어지지 않을 경우, 화면에 실제로 그려지는 영역이 적더라도 보이지 않는 객체에 대해 강제로 버텍스 셰이더 연산이 수행되어 GPU 점유율을 100%까지 상승시키고 프레임 드랍을 유발할 수 있습니다 [2].
+- **성능 병목과 연산 부하:** 버텍스 셰이더 단계에서 수행되는 행렬 곱셈 등의 연산은 렌더링되는 인스턴스의 수가 늘어날수록 선형적으로 증가합니다 [2]. 시야 절두체 컬링([[Frustum Culling|Frustum Culling]])이 제대로 이루어지지 않을 경우, 화면에 실제로 그려지는 영역이 적더라도 보이지 않는 객체에 대해 강제로 버텍스 셰이더 연산이 수행되어 GPU 점유율을 100%까지 상승시키고 프레임 드랍을 유발할 수 있습니다 [2].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** Fragment Shader, [[Instancing]], [[Varying Variables]]
+- **Related Topics:** Fragment Shader, [[Instancing|Instancing]], [[Varying Variables|Varying Variables]]
 - **Projects/Contexts:** 대규모 인스턴스 렌더링 최적화, 모바일 GPU 셰이더 성능 관리
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (버텍스 셰이더 자체의 구체적인 내부 문법이나 근본적인 그래픽스 파이프라인 원리에 대한 상세한 설명은 제공된 소스에 포함되어 있지 않습니다.)
 

10_Wiki/Topics/Graphics & Performance/Vulkan.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-DDC386
+id: [[P-Reinforce|P-Reinforce]]-AUTO-DDC386
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Vulkan"
 ---
 
-# [[Vulkan]]
+# [[Vulkan|Vulkan]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> Vulkan은 [[Metal]], [[Direct3D]] 12와 함께 [[WebGPU]] 설계의 기반이 된 현대적인 그래픽스 API입니다 [1]. 단일 스레드와 상태 저장([[State]]ful)에 의존하는 [[WebGL]]이나 d3d9 같은 구형 API와 달리, 드로우 콜([[Draw Call]]) 오버헤드 처리에 훨씬 효율적인 아키텍처를 가집니다 [1, 2]. 조건부 렌더링(Conditional Rendering)이나 간접 그리기([[Indirect Draw]]ing) 등 최신 렌더링 파이프라인을 구현하는 데 강력한 성능을 제공합니다 [3, 4].
+> Vulkan은 [[Metal|Metal]], Direct3D 12와 함께 WebGPU 설계의 기반이 된 현대적인 그래픽스 API입니다 [1]. 단일 스레드와 상태 저장([[State|State]]ful)에 의존하는 WebGL이나 d3d9 같은 구형 API와 달리, 드로우 콜([[Draw Call|Draw Call]]) 오버헤드 처리에 훨씬 효율적인 아키텍처를 가집니다 [1, 2]. 조건부 렌더링(Conditional Rendering)이나 간접 그리기([[Indirect Draw|Indirect Draw]]ing) 등 최신 렌더링 파이프라인을 구현하는 데 강력한 성능을 제공합니다 [3, 4].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 루트 주제인 Vulkan에 대한 전반적이고 상세한 아키텍처 설명은 소스에 관련 정보가 부족합니다. 제공된 데이터에서 확인 가능한 핵심적인 특징과 활용 사례는 다음과 같습니다.
@@ -25,7 +25,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Vulkan"
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], Direct3D 12, [[Metal]], Conditional Rendering
+- **Related Topics:** [[WebGPU|WebGPU]], Direct3D 12, [[Metal|Metal]], Conditional Rendering
 - **Projects/Contexts:** Vulkan Forward+ Renderer, Vulkan Pathtracer
 - **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. Vulkan 기술 자체를 깊이 있게 다루는 문헌은 없으며, 대부분 WebGPU의 성능을 설명하기 위한 비교 대상이나 그래픽스 개발자들의 프로젝트 제목 및 질의응답 속에서 단편적으로만 등장합니다.
 

10_Wiki/Topics/Graphics & Performance/WEBGL_multi_draw.md

@@ -1,36 +1,36 @@
 ---
-id: [[P-Reinforce]]-AUTO-C71621
+id: [[P-Reinforce|P-Reinforce]]-AUTO-C71621
 category: "10_Wiki/💡 Topics/Graphics & Performance"
 confidence_score: 0.90
 tags: [auto-reinforced]
 last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - [[WebGL]]_multi_draw"
+github_commit: "[P-Reinforce] Continuous Worker - [[WebGL|WebGL]]_multi_draw"
 ---
 
-# [[WEBGL_multi_draw]]
+# [[WEBGL_multi_draw|WEBGL_multi_draw]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> `WEBGL_multi_draw`는 한 번의 드로우 콜([[Draw Call]])로 정렬된 다수의 드로우 요청을 한꺼번에 제출할 수 있게 해주는 WebGL 확장 기능(Extension)입니다 [1, 2]. Three.js에서는 `BatchedMesh`가 이 API를 활용하여 동일한 재질을 공유하지만 각기 다른 기하학적 구조(Geometry)를 가진 여러 객체들을 묶어 렌더링하는 데 사용됩니다 [3-5]. 다양한 고유 객체들을 처리할 때 기존의 개별 호출 방식에 비해 엄청난 성능 향상을 제공하지만, 브라우저 호환성 문제와 대규모 씬에서의 오버헤드 한계를 동시에 안고 있습니다 [6, 7].
+> `WEBGL_multi_draw`는 한 번의 드로우 콜([[Draw Call|Draw Call]])로 정렬된 다수의 드로우 요청을 한꺼번에 제출할 수 있게 해주는 WebGL 확장 기능(Extension)입니다 [1, 2]. Three.js에서는 `BatchedMesh`가 이 API를 활용하여 동일한 재질을 공유하지만 각기 다른 기하학적 구조(Geometry)를 가진 여러 객체들을 묶어 렌더링하는 데 사용됩니다 [3-5]. 다양한 고유 객체들을 처리할 때 기존의 개별 호출 방식에 비해 엄청난 성능 향상을 제공하지만, 브라우저 호환성 문제와 대규모 씬에서의 오버헤드 한계를 동시에 안고 있습니다 [6, 7].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **BatchedMesh에서의 활용과 최적화 기능**
-  Three.js의 `BatchedMesh` 클래스는 `WEBGL_multi_draw` (구체적으로 `multiDraw` API)를 내부적으로 활용합니다 [1, 2]. 이를 통해 메모리에서 지오메트리를 중복시키지 않으면서도 지오메트리별 정렬([[Sorting]]), 시야 절두체 컬링([[Frustum Culling]]), 가시성 전환(Visibility Toggling), 인스턴싱 등의 기능을 단일 드로우 콜 내에서 수행할 수 있습니다 [2].
+  Three.js의 `BatchedMesh` 클래스는 `WEBGL_multi_draw` (구체적으로 `multiDraw` API)를 내부적으로 활용합니다 [1, 2]. 이를 통해 메모리에서 지오메트리를 중복시키지 않으면서도 지오메트리별 정렬([[Sorting|Sorting]]), 시야 절두체 컬링([[Frustum Culling|Frustum Culling]]), 가시성 전환(Visibility Toggling), 인스턴싱 등의 기능을 단일 드로우 콜 내에서 수행할 수 있습니다 [2].
 * **InstancedDraw와의 성능 비교**
-  수십만 개(예: 10만 개 이상)의 동일한 인스턴스를 그릴 때는 `[[InstancedMesh]]`가 사용하는 `instancedDraw`가 더 우수한 성능을 발휘합니다 [3]. 반면, 1,000개 이상의 각기 다른 '고유한(unique)' 지오메트리 객체들을 그려야 할 때는 `multiDrawElementsWEBGL`이 매우 유용합니다 [8]. 10만 개의 고유 지오메트리를 기존의 바인딩 및 렌더링 호출(`bindVertexArray` + `drawElements`)로 처리하는 것과 비교하면, `multiDraw` 방식이 수천 배 더 빠른 속도를 제공합니다 [9].
+  수십만 개(예: 10만 개 이상)의 동일한 인스턴스를 그릴 때는 `[[InstancedMesh|InstancedMesh]]`가 사용하는 `instancedDraw`가 더 우수한 성능을 발휘합니다 [3]. 반면, 1,000개 이상의 각기 다른 '고유한(unique)' 지오메트리 객체들을 그려야 할 때는 `multiDrawElementsWEBGL`이 매우 유용합니다 [8]. 10만 개의 고유 지오메트리를 기존의 바인딩 및 렌더링 호출(`bindVertexArray` + `drawElements`)로 처리하는 것과 비교하면, `multiDraw` 방식이 수천 배 더 빠른 속도를 제공합니다 [9].
 * **인스턴싱 지원 변형 (Instanced Variants)**
   이 확장 기능에는 `multiDrawArraysInstancedWEBGL` 및 `multiDrawElementsInstancedWEBGL`과 같은 인스턴싱 지원 변형 함수도 포함되어 있습니다 [10]. 이들은 수천 개의 고유 객체와 다수의 인스턴스가 혼합된 복잡한 환경에서 객체들을 하나의 드로우 콜로 묶어 렌더링할 수 있게 해줍니다 [8].
 * **브라우저 호환성 제약**
   Firefox 브라우저에서는 현재 `WEBGL_multi_draw` 확장을 지원하지 않습니다 [6, 11]. 이로 인해 Three.js 환경에서는 Firefox 지원을 위해 `gl_DrawID`를 에뮬레이트하는 속성을 추가하고, 지원되지 않을 경우 각 메쉬마다 새로운 드로우 콜을 생성하도록 하는 대체 수단(Fallback)이 필요합니다 [12].
 * **성능 병목 현상 및 기술적 한계**
-  지오메트리 수가 20만 개에 달할 정도로 규모가 커지면 `BatchedMesh` 사용 시 오히려 CPU 점유율이 치솟고 프레임이 심각하게 떨어지는 문제가 보고되었습니다 [13, 14]. 이는 매 프레임마다 드로우 "시작점(st[[Arts]])"과 "카운트(counts)" 정보를 담은 약 1.6MB 규모의 버퍼 데이터를 GPU로 업로드해야 하는 통신 오버헤드나, 인디렉트 텍스처 업데이트 지연과 관련이 있을 것으로 추정됩니다 [7, 15]. 또한 인스턴스 렌더링을 적용할 때 `multiDrawArraysInstancedWEBGL` 방식으로는 셰이더 내에서 특정 행렬이나 색상에 접근하기 위한 인스턴스 ID를 직접 검색할 방법이 없어 부가적인 텍스처 우회 처리가 요구되는 한계도 있습니다 [16].
+  지오메트리 수가 20만 개에 달할 정도로 규모가 커지면 `BatchedMesh` 사용 시 오히려 CPU 점유율이 치솟고 프레임이 심각하게 떨어지는 문제가 보고되었습니다 [13, 14]. 이는 매 프레임마다 드로우 "시작점(st[[Arts|Arts]])"과 "카운트(counts)" 정보를 담은 약 1.6MB 규모의 버퍼 데이터를 GPU로 업로드해야 하는 통신 오버헤드나, 인디렉트 텍스처 업데이트 지연과 관련이 있을 것으로 추정됩니다 [7, 15]. 또한 인스턴스 렌더링을 적용할 때 `multiDrawArraysInstancedWEBGL` 방식으로는 셰이더 내에서 특정 행렬이나 색상에 접근하기 위한 인스턴스 ID를 직접 검색할 방법이 없어 부가적인 텍스처 우회 처리가 요구되는 한계도 있습니다 [16].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** BatchedMesh, [[InstancedMesh]], [[Draw Call]]
-- **Projects/Contexts:** Three.js, [[WebGL]]
+- **Related Topics:** BatchedMesh, [[InstancedMesh|InstancedMesh]], [[Draw Call|Draw Call]]
+- **Projects/Contexts:** Three.js, [[WebGL|WebGL]]
 - **Contradictions/Notes:** `WEBGL_multi_draw`는 다수의 고유 객체를 그릴 때 CPU의 드로우 콜 병목을 해소하기 위해 설계되었으나 [1, 9], 역설적으로 특정 임계치(예: 수십만 단위)를 넘어서면 관련 버퍼 업로드 및 GPU 텍스처 업데이트 비용 때문에 오히려 병합된 지오메트리(Merged Geometry) 방식보다 성능이 30~50% 더 악화되는 실증적 모순이 관찰되었습니다 [7, 17, 18].
 
 ---