Files
2nd/10_Wiki/Topics/Visual_Effects/Graphics & Performance/Threejs 자원 해제 (Dispose).md
T
koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)
이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-08 12:24:15 +09:00

4.2 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit inferred_by tech_stack
wiki-2026-0508-threejs-자원-해제-dispose Threejs 자원 해제 (Dispose) 10_Wiki/Topics/Visual_Effects/Graphics & Performance verified self
GFX-RES-2026-05-007
none A 0.99
threejs
webgl
memory-management
optimization
javascript
garbage-collection
2026-05-08 pending Claude Opus 4.7 (auto-normalize 2026-05-08)
language framework
unspecified unspecified

Three.js 자원 해제 (Dispose)

📌 한 줄 통찰 (The Karpathy Summary)

"GPU 메모리는 자동으로 비워지지 않는다: JavaScript의 가비지 컬렉션(GC)은 CPU 메모리만 관리하므로, WebGL 자원(지오메트리, 텍스처, 렌더 타겟)은 반드시 명시적인 .dispose() 호출을 통해 GPU에서 제거해야 한다."

📖 구조화된 지식 (Synthesized Content)

  • Dispose의 대상:
    • Geometries: 정점 데이터와 인덱스 버퍼를 GPU에서 해제한다.
    • Materials: 쉐이더 프로그램과 관련 유니폼 데이터를 제거한다. (텍스처는 별도 해제 필요)
    • Textures: GPU 텍스처 메모리를 비운다. 캔버스나 이미지 소스도 포함될 수 있다.
    • Render Targets: 프레임버퍼와 뎁스 버퍼 자원을 해제한다.
  • 해제 메커니즘: Scene에서 mesh를 제거(scene.remove(mesh))하는 것만으로는 GPU 메모리가 해제되지 않는다. 해당 메시가 참조하는 mesh.geometry.dispose()mesh.material.dispose()를 각각 호출해야 한다.
  • 재귀적 해제 패턴: 복잡한 씬 그래프에서는 traverse 메서드를 사용하여 하위 모든 노드를 순회하며 자원을 해제하는 유틸리티 함수를 구현하는 것이 권장된다.

⚖️ 트레이드오프 및 고려사항

  • 과도한 Dispose: 빈번하게 객체를 생성하고 즉시 파괴하는 패턴은 오히려 성능 저하를 유발한다. 유사한 객체는 Object Pooling을 통해 재사용하는 것이 GPU 업로드 비용을 줄이는 데 유리하다.
  • 공유 자원 관리: 여러 메시가 동일한 머티리얼이나 텍스처를 공유할 경우, 하나를 dispose 하면 다른 메시들도 렌더링에 실패한다. 참조 카운팅(Reference Counting) 로직을 별도로 관리해야 한다.
  • Leak 탐지: Chrome DevTools의 'Memory' 탭이나 Three.js 전용 인스펙터를 통해 renderer.info.memory 값을 모니터링하여 자원 누수 여부를 상시 확인해야 한다.

🔗 지식 연결 (Graph)

  • 상위 개념: Memory Management
  • 유사 개념: Garbage Collection, GPU Acceleration, Object Pooling (오브젝트 풀링)
  • 관련 기술: Three.js, WebGL, WebGPU

Last updated: 2026-05-08

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

언제 이 지식을 쓰는가:

  • (TODO)

언제 쓰면 안 되는가:

  • (TODO)

🧪 검증 상태 (Validation)

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

🧬 중복 검사 (Duplicate Check)

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

⚠️ 모순 및 업데이트 (Contradictions & Updates)

  • 과거 데이터와의 충돌: 없음
  • 정책 변화: 없음

🕓 변경 이력 (Changelog)

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

💻 코드 패턴 (Code Patterns)

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

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

안티패턴 (Anti-Patterns)

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