chore(wiki): reinforce knowledge batch #6-#10 (200 docs milestone)
This commit is contained in:
Antigravity Agent
@@ -1,43 +1,29 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-B1B522
|
||||
id: CHROME-MEM-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools Memory Profiling"
|
||||
confidence_score: 1.0
|
||||
tags: [web-performance, debugging, memory-leak, devtools]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Chrome DevTools Memory Profiling]]
|
||||
# [[Chrome DevTools Memory Profiling (메모리 분석 및 성능 최적화)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Chrome DevTools Memory Profiling은 JavaScript 애플리케이션 및 브라우저에서 발생하는 메모리 누수를 감지하고 분석하기 위한 분석 도구 모음입니다 [1, 2]. 주로 DevTools의 Memory 패널을 통해 제공되며, 객체의 메모리 할당 시점, 유지(Retaining) 경로, 가비지 컬렉션 여부를 시각적으로 추적하여 정상적으로 정리되지 않은 객체를 식별합니다 [3-6]. 이를 통해 개발자는 메모리 힙(Heap) 상태를 정밀하게 분석하고 메모리 부족 현상이나 성능 저하를 유발하는 코드의 근본 원인을 파악할 수 있습니다 [7-9].
|
||||
> "보이지 않는 메모리 누수를 가시화하라" — 브라우저의 힙 스냅샷과 타임라인 기록을 통해 자바스크립트 객체의 할당 및 해제 과정을 추적하여 웹 애플리케이션의 메모리 효율성을 극대화하는 진단 도구.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **핵심 프로파일링 도구 (Memory Panel Tools):**
|
||||
* **Heap Snapshot (힙 스냅샷):** 특정 시점의 전체 메모리 객체 그래프를 캡처하는 도구입니다 [3, 10]. 의심되는 작업 전, 작업 중, 작업 후의 세 번의 스냅샷을 찍어 비교하는 '3-스냅샷 기법(three-snapshot technique)'을 통해 일회성 할당을 필터링하고 실제 누수 후보를 안정적으로 식별할 수 있습니다 [7, 11]. 제공되는 뷰(View)에는 생성자별로 객체를 묶어 크기를 보여주는 Summary, 두 스냅샷 간의 차이를 보여주는 Comparison, 애플리케이션 구조를 조감도로 보여주는 Containment, 메모리 할당의 파이 차트를 보여주는 Statistics 등이 있습니다 [9].
|
||||
* **Allocation instrumentation on timeline (타임라인의 할당 계측):** 일정 기간 동안의 모든 메모리 할당을 스택 트레이스와 함께 기록하며, 최소 50ms 간격으로 스냅샷을 주기적으로 캡처합니다 [3, 12, 13]. 타임라인에서 파란색 막대는 기록 종료 시점까지 여전히 살아있는 객체(누수 후보)를 의미하며, 회색 막대는 할당 후 이미 가비지 컬렉션된 객체를 의미합니다 [3, 4, 14, 15].
|
||||
* **Allocation sampling (할당 샘플링):** 전체 할당 추적보다 오버헤드가 적은 통계적 샘플링 방법으로, 프로덕션 환경의 프로파일링에 적합합니다 [16].
|
||||
|
||||
* **주요 지표 및 분석 개념:**
|
||||
* **Shallow Size vs. Retained Size:** 'Shallow size'는 객체 자체가 독립적으로 차지하는 메모리 크기(일반적으로 문자열이나 배열이 큼)이며, 'Retained size'는 해당 객체를 삭제하여 참조가 끊어졌을 때 가비지 컬렉터를 통해 확보할 수 있는 총 메모리 크기를 의미합니다 [17].
|
||||
* **Retainers (유지 경로):** 특정 객체를 메모리에 살아있게 만들어 가비지 컬렉션을 방해하는 참조 체인을 보여줍니다 [3, 6]. 개발자는 이 트리를 확인하여 어떤 참조가 메모리 누수를 유발하는지 파악할 수 있습니다 [8, 18].
|
||||
* **객체 ID (Object ID):** 객체 이름 뒤에 붙는 `@` 기호와 숫자는 고유 ID로, 가비지 컬렉션 과정에서 객체가 이동하더라도 변하지 않아 여러 스냅샷에 걸쳐 특정 객체의 상태를 정확하게 추적 및 비교할 수 있게 해줍니다 [12, 19, 20].
|
||||
|
||||
* **프로파일링을 통해 식별되는 주요 메모리 누수 패턴:**
|
||||
* 문서(DOM)에서는 제거되었으나 자바스크립트 변수, Map/Set, 또는 클로저 등에 의해 여전히 참조되고 있는 분리된 DOM 노드(Detached DOM nodes) [16, 21, 22].
|
||||
* 생명 주기에 맞게 제거되지 않고 반복적으로 쌓이는 이벤트 리스너(Event listener accumulation) 및 잊혀진 타이머나 옵저버(Forgotten timers and observers) [23, 24].
|
||||
* 여러 클로저가 스코프를 공유할 때, 큰 데이터를 캡처한 변수를 다른 클로저의 수명 때문에 메모리에서 해제하지 못하는 클로저 스코프 보존(Closure scope retention) [23].
|
||||
- **추출된 패턴:** 메모리 점유율이 지속적으로 우상향하는 '메모리 누수(Memory Leak)' 패턴을 식별하고, 해제되지 않은 참조 관계(Retainer Tree)를 찾아내는 진단 패턴.
|
||||
- **세부 내용:**
|
||||
- **Heap Snapshot:** 특정 시점의 메모리 사용 현황을 캡처하여 어떤 객체가 가장 많은 용량을 차지하는지 분석.
|
||||
- **Allocation Instrumentation on Timeline:** 시간에 따른 메모리 할당 현황을 기록하여 특정 사용자 동작(클릭 등) 시 메모리가 비정상적으로 급증하는지 확인.
|
||||
- **Detached DOM Nodes:** 화면에서 사라졌지만 가비지 컬렉터(GC)에 의해 수거되지 못한 DOM 노드를 탐지.
|
||||
- **Shallow Size vs Retained Size:** 객체 자체의 크기와 해당 객체가 유지하고 있는 다른 객체들의 합계 크기를 구분하여 병목 지점 파악.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
- **과거 데이터와의 충돌:** 단순 '새로고침'으로 해결하던 방식에서, SPA(Single Page Application) 환경의 장기 생존 메모리 관리로 최적화 패러다임 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트의 웹 대시보드 성능 가이드라인에 따라 5분 이상 미사용 시 유휴 메모리 강제 해제 로직 검증에 활용.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Heap Snapshot]], [[Allocation Timeline]], [[Garbage Collection]], [[Retaining Path]], [[Shallow Size and Retained Size]]
|
||||
- **Projects/Contexts:** [[V8 Engine Memory Management]], [[Browser Memory Leak Detection]]
|
||||
- **Contradictions/Notes:** 소스 간의 직접적인 모순은 없습니다. 다만, 실무적 주의사항으로 `console.log`가 평가된 객체에 대한 참조를 계속 유지하여 가짜 양성(false positive)의 메모리 누수를 표시할 수 있으므로, 메모리 누수 조사 중에는 콘솔을 지우거나 큰 객체 기록을 피해야 한다고 경고하고 있습니다 [21, 25]. 또한 코드의 난독화(Minified code) 때문에 Retainer 체인을 읽기 어려울 수 있으므로, 의미 있는 함수/변수 명을 보려면 소스 맵(Source maps)을 활성화해야 합니다 [25].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools Memory Profiling.md]]
|
||||
---
|
||||
- **Parent:** [[10_Wiki/💡 Topics/AI]]
|
||||
- **Related:** [[Garbage-Collection]], [[Reflow-Repaint]], [[V8-Engine]]
|
||||
- **Merged Source:** [[10_Wiki/Topics/AI/Chrome DevTools 메모리 분석 및 성능 최적화.md]]
|
||||
|
||||
Reference in New Issue
Block a user