---
id: wiki-2026-0508-webgl
title: WebGL
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-consolidated, technical-documentation]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# [[WebGL|WebGL]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> **WebGL**은 플러그인 없이 웹 브라우저에서 2D 및 3D 그래픽을 렌더링하기 위한 저수준(Low-level) [[JavaScript|JavaScript]] API입니다. 원시 WebGL은 직접 다루기 매우 복잡하고 장황하지만, **Three.js**나 **React Three Fiber(R3F)** 같은 라이브러리를 통해 추상화되어 현대 웹의 고성능 3D 인터랙티브 그래픽과 게임 엔진을 구현하는 핵심 기반 기술로 사용됩니다.

---

> 모바일 기반 WebGL 애플리케이션 개발은 상대적으로 부족한 시스템 메모리와 프로세서 성능을 지닌 모바일 브라우저 환경에서 매끄러운 3D 렌더링(60fps)을 구현하고 배터리 소모를 최소화하는 데 중점을 두는 기술적 접근입니다. 제한된 하드웨어 리소스를 극복하기 위해 엄격한 폴리곤 수 및 드로우 콜([[Draw Call|Draw Call]]) 제한, 텍스처 메모리 압축, 셰이더 정밀도 하향, 그리고 디바이스 특성을 고려한 전원 및 컨텍스트 관리 기법이 복합적으로 동원됩니다.

## 📖 구조화된 지식 (Synthesized Content)
**1. WebGL의 복잡성과 Three.js의 역할** WebGL 자체는 셰이더 코드와 버퍼를 직접 다루어야 하는 매우 저수준(Low-level)의 시스템입니다. 이러한 복잡성을 줄이고자 개발된 것이 Three.js 라이브러리이며, 개발자에게 씬(Scene), 카메라, 기하구조(Geometry), 재질(Material), 렌더러 등의 추상화된 객체를 제공하여 WebGL 렌더링 파이프라인을 훨씬 쉽게 구축할 수 있도록 지원합니다.

**2. WebGL의 메모리 및 자원 관리 (가비지 컬렉션 한계)** JavaScript의 일반적인 힙 메모리와 달리, WebGL이 사용하는 GPU 자원(VRAM에 올라간 텍스처, 기하구조, 재질, 렌더 타겟 등)은 브라우저의 가비지 컬렉터(GC)에 의해 자동으로 회수되지 않습니다. 따라서 심각한 메모리 누수와 GPU 크래시를 방지하려면, 사용이 끝난 자원에 대해 반드시 명시적으로 `.dispose()` 메서드를 호출하여 직접 메모리를 해제해야 합니다. GLTF 모델에서 로드된 `ImageBitmap` 텍스처의 경우 `.close()` 호출도 필요합니다.

**3. 성능 최적화와 드로우 콜([[Draw Call|Draw Call]])** WebGL 렌더링의 주된 성능 병목은 CPU가 GPU에게 그리기 명령을 내리는 **'드로우 콜(Draw Call)'**에서 발생합니다. 부드러운 60FPS를 유지하기 위한 황금률은 프레임당 드로우 콜을 100회 미만으로 유지하는 것입니다. 수백, 수천 개의 동일한 객체를 그릴 때는 개별 메시(Mesh)를 생성하지 않고, 단 1회의 드로우 콜만으로 GPU 내부에서 객체를 복제하는 `[[InstancedMesh|InstancedMesh]]` 최적화 기법을 사용해야 합니다. 모바일 WebGL 환경의 셰이더에서는 `mediump` 정밀도를 사용하여 연산 성능을 2배가량 향상시킬 수 있습니다.

**4. [[OffscreenCanvas|OffscreenCanvas]]를 통한 메인 스레드 분리** 복잡한 WebGL 3D 씬 연산은 메인 스레드를 블로킹하여 사용자 UI의 반응성을 크게 떨어뜨릴 수 있습니다. 이를 해결하기 위해 `OffscreenCanvas` API를 사용하여 WebGL 렌더링 컨텍스트를 DOM에서 완전히 분리하고, **웹 워커(Web Worker)**라는 백그라운드 스레드에서 WebGL을 실행할 수 있습니다. 이 멀티스레드 아키텍처는 무거운 그래픽 연산 중에도 UI가 매끄럽게 동작하도록 보장합니다.

**5. 차세대 [[WebGPU|WebGPU]]와의 공존과 TSL** 현재 WebGL 2는 브라우저의 97% 이상을 커버하는 가장 안정적이고 널리 쓰이는 표준입니다. 하지만 수십만 개의 입자를 제어하거나 고성능 물리 연산을 처리하는 컴퓨트 셰이더(Compute Shaders) 기능의 부재로 인해, 차세대 그래픽스 API인 **WebGPU**로 전환되는 추세입니다. 이에 대응하여 최신 Three.js는 **[[TSL (Three Shader Language)|TSL (Three Shader Language]]**이라는 노드 기반 셰이더 시스템을 도입했습니다. TSL로 작성된 코드는 WebGPU용 WGSL과 WebGL용 GLSL로 동시 컴파일되며, WebGPU를 지원하지 않는 브라우저에서는 **자동으로 WebGL 2로 폴백(Fallback)**되도록 설계되어 호환성과 성능을 모두 잡고 있습니다.

---

*   **지오메트리 및 드로우 콜 한계 관리**
    *   모바일 브라우저(iOS Safari, [[Chrome|Chrome]] Mobile, Firefox Mobile 등)는 씬 당 50,000에서 100,000 폴리곤을 처리하는 것이 가장 적합합니다 [1].
    *   드로우 콜이 1,000에서 2,000회를 초과할 경우 모바일 프로세서에서 병목 현상이 발생하여 심각한 성능 저하로 이어집니다 [2].

*   **메모리 및 텍스처 최적화**
    *   시스템 메모리가 2~4GB에 불과한 모바일 기기에서는 텍스처 메모리 사용량이 500MB를 초과할 때 가비지 컬렉션(GC)으로 인한 일시 정지와 심각한 프레임 끊김이 발생합니다 [3].
    *   모바일 GPU의 오버헤드를 크게 줄이려면 여러 텍스처를 하나의 아틀라스(Atlas) 텍스처로 결합하여 다중 텍스처 바인딩을 피해야 합니다 [4].
    *   Basis Universal 포맷을 사용하면 텍스처를 모바일 환경에 맞는 GPU 압축 포맷(iOS의 PVRTC, 모바일의 ASTC 등)으로 로드 시점에 맞게 트랜스코딩하여 메모리 점유율을 크게 낮출 수 있습니다 [5].

*   **셰이더 및 렌더링 파이프라인 튜닝**
    *   모바일 GPU는 `mediump` 정밀도를 `highp`보다 약 2배 빠른 속도로 처리하므로, 깊이(depth) 계산이나 위치 좌표 등 꼭 필요한 경우를 제외하고는 `mediump`를 사용해야 합니다 [6].
    *   버텍스 셰이더와 프래그먼트 셰이더 간 데이터를 전달하는 varying 변수는 모바일 GPU 환경에서 3개 이하로 최소화해야 합니다 [6].
    *   퍼포먼스를 확보하기 위해 네이티브 멀티샘플링 안티앨리어싱(MSAA)을 비활성화하고, 그 대신 FXAA를 마지막 패스에 적용해야 모바일에서 60fps를 안정적으로 유지할 수 있습니다 [7]. 
    *   그림자 맵(Shadow map)의 크기는 모바일 기기에 맞게 512에서 1024 해상도로 설정하는 것이 적절합니다 [8].

*   **배터리 절약 및 모바일 예외 상황 처리**
    *   React Three Fiber 등에서 정적인 씬을 구현할 때 `frameloop="demand"` 옵션을 설정하여 불필요한 프레임 렌더링을 멈춤으로써 모바일 기기의 배터리를 아낄 수 있습니다 [9].
    *   모바일 환경에서는 WebGL 컨텍스트가 유실(context lost)되는 현상이 발생할 수 있으므로, 해당 이벤트를 수신하여 자연스럽게 복구되도록 처리해야 합니다 [10].

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

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** Three.js, [[React Three Fiber (R3F)|React Three Fiber (R3F]], WebGPU Compute Shaders, OffscreenCanvas, [[InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화]], [[memory|memory]] Leak Prevention (메모리 누수 방지)
- **Projects/Contexts:** 브라우저 기반 3D 데이터 시각화 및 디지털 트윈, 멀티스레드 기반 고성능 웹 게임 엔진
- **Contradictions/Notes:** WebGL 파이프라인에서 `EffectComposer` 등을 활용해 커스텀 후처리(Post-[[Processing|Processing]])를 적용할 경우, WebGL의 내장 안티앨리어싱(AA) 기능이 무효화되는 제약이 있습니다. 이를 해결하려면 파이프라인 마지막 단계에 SMAA나 FXAA 효과 패스를 수동으로 추가해 주어야 시각적 품질을 유지할 수 있습니다.

---

---

- **Related Topics:** 드로우 콜 최적화(Draw Call [[Optimization|Optimization]]), 텍스처 압축 및 아틀라스(Texture Compression & Atlas), 셰이더 정밀도 최적화(Shader Precision Optimization), 가비지 컬렉션 관리(Garbage Collection [[Management|Management]])
- **Projects/Contexts:** Three.js WebGL 렌더링, 모바일 환경의 메모리 병목
- **Contradictions/Notes:** 뼈대 텍스처의 부분 업데이트(partial texture updates)와 같은 특정 세부 렌더링 최적화 기법은 일부 모바일 기기와 Firefox 브라우저 환경에서는 오히려 속도를 느리게 만드는 부작용(역효과)이 보고되었습니다 [11, 12]. 

---
*Last updated: 2026-04-19*

---

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*