---
id: P-REINFORCE-AUTO-655682
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 Optimization"
---

# [[WebGL Optimization|WebGL Optimization]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> WebGL 최적화는 웹 브라우저 환경에서 3D 그래픽스의 렌더링 속도와 메모리 효율성을 향상시키기 위한 체계적인 기술과 방법론을 의미합니다 [1, 2]. 주된 목적은 CPU와 GPU 간의 통신 오버헤드를 유발하는 드로우 콜(Draw Call)을 최소화하여 안정적인 60 FPS 프레임 레이트를 유지하는 것입니다 [2, 3]. 이를 위해 기하학적 구조 인스턴싱(Instancing), 텍스처 압축, 디테일 수준(LOD) 제어, 그리고 브라우저 메모리 한계를 고려한 자원 해제 등의 최적화 기법이 복합적으로 적용됩니다 [4-6].

## 📖 구조화된 지식 (Synthesized Content)
* **드로우 콜 최적화 (Draw Call Optimization):** CPU가 GPU에게 렌더링을 명령하는 '드로우 콜'은 WebGL 렌더링 성능을 떨어뜨리는 가장 큰 병목 현상입니다 [7, 8]. WebGL 환경에서는 CPU-GPU 통신 오버헤드를 막기 위해 프레임당 드로우 콜을 100회 미만으로 타겟팅하는 것이 좋으며, 1,000~2,000회에 도달하면 심각한 성능 저하가 발생합니다 [9, 10]. 이를 해결하기 위해 동일한 기하학적 구조를 반복 렌더링하는 `InstancedMesh`, 다양한 구조라도 동일한 재질이면 병합 처리하는 `BatchedMesh`, 그리고 정적 객체의 지오메트리 병합(Geometry Merging) 기술을 필수적으로 활용해야 합니다 [9, 11-13].
* **에셋 및 텍스처 압축 (Asset & Texture Optimization):** 웹 환경의 메모리 대역폭을 고려하여, 폴리곤 수는 모바일 및 웹 뷰어 기준 10,000개에서 100,000개 사이로 유지(Decimation/Retopology)하는 것이 권장됩니다 [14, 15]. 또한 일반 PNG 텍스처는 GPU 메모리를 과도하게 점유하므로 KTX2나 Basis Universal과 같이 GPU 친화적인 압축 형식을 사용하여 메모리 사용량을 75~90%가량 줄이고, 텍스처 아틀라스(Texture Atlas)로 여러 텍스처를 하나로 병합해 바인딩 횟수를 감소시켜야 합니다 [16-18].
* **메모리 파이프라인 관리 (Memory Pipeline Management):** WebGL 컨텍스트는 브라우저 환경에서 대개 256MB~1GB의 메모리 한계를 지니고 있어 한계를 초과하면 브라우저가 충돌합니다 [6]. 따라서 사용하지 않는 지오메트리, 재질, 텍스처는 가비지 컬렉터에 의존하지 않고 명시적으로 `.dispose()`를 호출해 GPU 메모리에서 해제해야 합니다 [19, 20]. 또한 카메라 시야 범위 밖의 연산을 건너뛰게 하는 시야 절두체 컬링(Frustum Culling), 거리에 따라 객체 디테일을 동적으로 줄이거나 빌보드 임포스터로 대체하는 LOD(Level of Detail) 시스템 적용도 필수입니다 [21-24].
* **셰이더 연산 간소화 (Shader & Overdraw Optimization):** 모바일 GPU에서는 연산 속도를 2배 이상 높일 수 있도록 `mediump` 정밀도를 사용하는 것이 유리합니다 [25]. 프래그먼트 셰이더 내에서 분기문(Conditionals)은 GPU 병렬 처리를 방해하므로 `mix()` 및 `step()` 함수로 대체하고, 다중 텍스처 조회를 줄이기 위해 여러 PBR 데이터를 RGBA 채널에 압축(Packing)해야 대역폭을 절약할 수 있습니다 [26, 27]. 또한 보이지 않는 투명한 기하학적 구조가 겹쳐 불필요하게 렌더링 연산을 반복하는 오버드로우(Overdraw)를 최소화해야 합니다 [28].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Draw Call|Draw Call]], [[InstancedMesh|InstancedMesh]], [[BatchedMesh|BatchedMesh]], [[Frustum Culling|Frustum Culling]], [[Level of Detail (LOD)|Level of Detail (LOD)]]
- **Projects/Contexts:** [[Three.js|Three.js]]
- **Contradictions/Notes:** 
  - `InstancedMesh`는 드로우 콜을 1회로 줄여주어 강력하지만, 단일 엔진 객체로 취급되기 때문에 인스턴스 각각에 대한 시야 절두체 컬링(Frustum Culling)이 개별 적용되지 않는 한계가 있습니다 [29]. 따라서 화면에 하나의 인스턴스만 걸쳐 있어도 보이지 않는 나머지 인스턴스의 정점 연산까지 수행해야 하는 GPU 낭비가 발생할 수 있습니다 [29].
  - 오버드로우(Overdraw) 관점에서도 `InstancedMesh`는 자동 정렬(Sorting) 기능을 지원하지 않아 뒤에 있는 객체가 덮어 씌워지면서 픽셀 처리에 병목을 일으킬 수 있으므로, 상황에 따라서는 오히려 개별 메쉬나 정적 지오메트리 병합(Merging)을 활용하는 것이 더 높은 FPS를 제공할 수 있다고 지적합니다 [30-32]. 

---
*Last updated: 2026-04-19*
- Raw Source: 00_Raw/2026-04-20/WebGL Optimization.md
---