Organizer 정리 산출물(From_RawData) + 이사 체크리스트 + 인덱스 갱신

- Raw_Data 자동 정리 산출물이 각 도메인 From_RawData/ 로 편입, 00_INDEX 연결 갱신 - 컴퓨터_이사_체크리스트.md 추가 (두뇌-상대 경로 규약 v2.2.304 — 새 컴퓨터에서 바꿀 절대 경로는 localBrainPath 1개) - Astra 세션 산출물(에피소드 기억·기능 인벤토리) 갱신 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-11 21:03:00 +09:00
parent 468322768c
commit 2cc6eff2dd
162 changed files with 15836 additions and 14 deletions
@@ -0,0 +1,116 @@
+---
+id: android-context
+title: "Android Context"
+category: "Android Architecture"
+status: "draft"
+verification_status: "conceptual"
+canonical_id: ""
+aliases: 
+  - "안드로이드 컨텍스트"
+  - "Application Context"
+  - "Activity Context"
+  - "Context 객체"
+  - "앱 상태 참조"
+duplicate_of: ""
+source_trust_level: "A"
+confidence_score: 0.90
+created_at: 2026-07-11
+updated_at: 2026-07-11
+review_reason: ""
+merge_history: []
+tags: ["research", "context 이해 규칙"]
+raw_sources: 
+  - "Application Context, Activity Context and Memory leaks | by Shashank Mistry | Medium"
+  - "[Android/안드로이드] Context, 뭐하는 녀석인지 알고 사용하자! - 코딩스토리"
+applied_in: []
+github_commit: ""
+---
+
+# [[Android Context]]
+
+## 🎯 한 줄 통찰 (One-line insight)
+Android Context는 애플리케이션과 액티비티의 현재 상태 및 환경 정보를 제공하는 시스템 핸들로, 생명주기에 맞는 적절한 Context(Application vs Activity)의 선택이 메모리 누수 방지의 핵심이다.
+
+## 🧠 핵심 개념 (Core concepts)
+- **시스템 핸들 (System Handle):** 애플리케이션의 현재 상태를 나타내며 리소스, 데이터베이스, 시스템 서비스 등에 접근할 수 있게 해주는 포괄적 정보 객체
+- **Application Context:** 애플리케이션의 생명주기(LifeCycle)와 결속되어 앱 시작부터 종료 시까지 유지되는 Context
+- **Activity Context:** 개별 액티비티의 생명주기와 결속되어 해당 액티비티와 함께 생성되고 소멸되는 Context
+- **메모리 누수 방지 (Memory Leak Prevention):** 뷰모델(ViewModel)이나 싱글톤(Singleton)과 같이 오래 유지되는 객체에서 짧은 생명주기를 가진 Activity Context를 참조하지 않도록 관리하는 설계 원칙
+
+## 🧩 추출된 패턴 (Extracted patterns)
+- **UI 및 화면 관련 작업:** Toast, Dialog 등 GUI와 직결된 작업에는 항상 액티비티에 대한 추가 정보를 포함하는 Activity Context를 사용한다.
+- **액티비티 생명주기 외의 작업:** ViewModel 내부의 데이터베이스 접근 등 액티비티 소멸 이후에도 Context 참조가 필요한 경우에는 Application Context를 주입받아 사용한다.
+- **메모리 누수 안티패턴 회피:** ViewModel에서 Activity를 멤버 변수로 참조, non-static 내부 클래스로 선언된 Handler 사용, View를 static 변수로 선언, Singleton에서 Activity 참조 등은 엄격히 금지된다.
+
+## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)
+
+| 항목 (Option) | 장점 | 단점 | 언제 선택 |
+|---|---|---|---|
+| **Activity Context** | 현재 액티비티에 대한 구체적 정보를 포함하여 GUI 컴포넌트(Toast, Dialog 등)가 정상 작동함 | 액티비티 소멸 시 함께 파괴되므로, 외부나 비동기 작업에서 잘못 참조 시 심각한 메모리 누수 발생 | UI 관련 요소를 화면에 띄우거나, 액티비티 내부 생명주기 안에서만 작업이 완료될 때 |
+| **Application Context** | 앱의 생명주기를 따르므로 액티비티 파괴와 무관하게 안전하게 참조 가능하여 메모리 누수를 예방함 | Activity Context가 지원하는 모든 GUI 기능을 지원하지 않아 화면 관련 작업 시 비표준적 동작이나 오류 발생 가능 | 액티비티 생명주기를 벗어나 유지되어야 하는 참조(예: ViewModel의 DB 접근 등)가 필요할 때 |
+
+## 📖 세부 내용 (Details)
+- **Context의 정의와 역할:** 안드로이드에서 Context는 시스템에 대한 핸들로 작용하며, 로컬 파일, 데이터베이스, 시스템 서비스 및 위치 서비스와 같은 중요한 환경 데이터를 포함한다 [S1]. 이는 현재 사용되고 있는 애플리케이션이나 액티비티에 대한 포괄적인 상태 정보를 지닌 객체이며, Activity와 Application 클래스는 이 Context 클래스를 확장(상속)하여 구현된다 [S2].
+- **Application Context와 Activity Context의 차이:**
+  - **Application Context:** 애플리케이션의 라이프사이클을 따르며, 앱이 실행되어 종료될 때까지 동일한 객체를 참조한다 [S1], [S2]. 
+  - **Activity Context:** 개별 액티비티의 라이프사이클을 따르며, 액티비티가 소멸(`onDestroy()`)될 때 컨텍스트도 함께 사라진다. 이 Context는 현재 액티비티에 대한 추가적인 정보를 더 가지고 있다 [S1], [S2].
+- **메모리 누수(Memory Leak)의 원인과 해결책:**
+  - Context를 잘못 사용하면 메모리 누수가 발생하고 앱이 강제 종료될 수 있다 [S1], [S2].
+  - 예를 들어, ViewModel에서 Activity Context를 주입받아 데이터베이스(Room 등)를 호출하는 상황에서, 데이터 로딩(예: 3초 소요)이 완료되기 전에 액티비티가 종료되면, ViewModel이 여전히 Activity Context를 쥐고 있어 가비지 컬렉터가 메모리를 회수하지 못해 메모리 누수가 발생한다 [S2].
+  - 이러한 문제를 해결하기 위해 생명주기가 긴 ViewModel 등에서는 `getApplicationContext()`를 참조해야 한다(예: AndroidViewModel 사용) [S1], [S2].
+- **올바른 Context 사용 규칙:**
+  - 무조건 Application Context만 사용하는 것은 잘못된 방법이다. Application Context는 Activity Context가 제공하는 모든 것을 지원하지 않기 때문에 Dialog, Toast 등 GUI와 관련된 작업에서는 정상적으로 작동하지 않을 수 있으며 메모리 낭비를 유발할 수 있다 [S1], [S2].
+  - 특별한 이유가 없다면 직접적으로 가용한 Activity Context를 사용하되, 액티비티 생명주기 밖에서 참조를 유지해야 할 때만 Application Context로 전환하여 사용해야 한다 [S1], [S2].
+
+## ⚖️ 모순 및 업데이트 (Contradictions & updates)
+소스 내에서 상충되는 정보나 모순점은 발견되지 않았으며, 제공된 소스 모두 Context의 분리 사용 및 메모리 누수 방지라는 동일한 아키텍처 원칙을 지지하고 있습니다.
+
+## 🛠️ 적용 사례 (Applied in summary)
+현재 발견된 실제 적용 사례가 없습니다. (소스 내에 구체적인 코드 파일 경로, Git 커밋 해시, 또는 의사결정 기록(decision_id)이 포함되어 있지 않습니다.)
+
+## 💻 코드 패턴 (Code patterns)
+소스에 코드 예시 없음
+
+## ✅ 검증 상태 및 신뢰도
+- **상태:** draft
+- **검증 단계:** conceptual
+- **출처 신뢰도:** A
+- **신뢰 점수:** 0.90
+- **중복 검사 결과:** 신규 생성 (New discovery)
+
+## 🔗 관련 문서 링크 (Related document links)
+
+### 상위/유사 개념
+- [[Application Context]] — 연결 이유: 앱 전역 생명주기에 종속된 Context의 하위 분류
+- [[Activity Context]] — 연결 이유: 액티비티 생명주기에 종속된 Context의 하위 분류
+- [[Memory Leak]] — 연결 이유: Context의 잘못된 참조로 인해 발생하는 주요 시스템 장애 현상
+- [[Android Lifecycle]] — 연결 이유: Context의 유효 범위를 결정짓는 안드로이드의 근본 메커니즘
+
+### 심층 후속 질문 (Deeper Research Questions)
+- ViewModel 내부에서 Application Context가 아닌 Activity Context가 반드시 필요한 예외적인 상황이 존재하는가?
+- Android 프레임워크 내부에서 Activity Context와 Application Context는 어떤 구조적 차이로 인해 GUI 기능 지원 여부가 갈리는가?
+- 메모리 누수 방지를 위해 Context를 주입하는 대신 사용할 수 있는 의존성 주입(DI) 라이브러리(Hilt, Dagger 등)의 모범 사례는 무엇인가?
+- Jetpack Compose 환경에서는 Context를 어떻게 관리하며, 선언형 UI에서의 Context 생명주기는 기존 View 시스템과 어떻게 다른가?
+- Memory Leak을 추적하기 위해 LeakCanary와 같은 도구를 사용할 때 Context 누수를 식별하는 가장 전형적인 시그니처는 무엇인가?
+
+### 실무 적용 맥락 (Practical Application Contexts)
+- **Implementation:** Toast 메세지 출력, 다이얼로그 팝업 렌더링, SharedPreference 초기화
+- **System Design:** MVVM 아키텍처 설계 시 Repository나 ViewModel 계층에서의 Context 참조 방향 설정
+- **Operation / Maintenance:** 앱 크래시 로그 분석 시 뷰모델 등에서의 OOM(Out of Memory) 현상 및 Context 누수 추적
+- **Learning Path:** 안드로이드 컴포넌트 생명주기 이해 -> 메모리 누수 원리 파악 -> 올바른 Context 주입 패턴 체득
+
+### 인접 주변 주제 (Adjacent Topics)
+- [[ViewModel]] — 확장 방향: Context 없이 비즈니스 로직과 UI 상태를 관리하는 아키텍처 패턴 설계
+- [[Room Database]] — 확장 방향: 로컬 데이터베이스 접근 시 Application Context를 안전하게 주입하여 사용하는 방법
+
+## 🔗 지식 그래프 (Knowledge Graph)
+- **상위/루트:** [[context 이해 규칙]]
+- **관련 개념:** [[Application Context]], [[Activity Context]], [[Memory Leak]]
+- **참조 맥락:** 안드로이드 앱 설계 시 UI 조작과 비동기 데이터 처리 계층 간의 안전한 메모리 참조 규범을 설정할 때 참조됨.
+
+## 📚 출처 (Sources)
+- [1] Application Context, Activity Context and Memory leaks | by Shashank Mistry | Medium
+- [2] [Android/안드로이드] Context, 뭐하는 녀석인지 알고 사용하자! - 코딩스토리
+
+## 📝 변경 이력 (Change history)
+- 2026-07-11: Initial draft generated via Datacollector_MAC P-Reinforce engine.