[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,143 +1,164 @@
|
||||
---
|
||||
id: wiki-2026-0508-스택-트레이스-stack-trace
|
||||
title: 스택 트레이스(Stack trace)
|
||||
title: 스택 트레이스 (Stack Trace)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Stack Trace, Call Stack, Backtrace, 콜스택]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [debugging, observability, error-handling, runtime]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Python/Go/JS
|
||||
framework: Sentry/OpenTelemetry
|
||||
---
|
||||
|
||||
# [[스택 트레이스 (Stack Trace)]]
|
||||
# 스택 트레이스 (Stack Trace)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
스택 트레이스(Stack Trace)는 소프트웨어에서 에러나 예외가 발생했을 때, 해당 시점까지 호출된 함수나 메서드의 순서(호출 스택)를 보여주는 정보입니다 [1, 2]. 낯선 코드베이스를 분석할 때 의도적으로 시스템 실패를 유도하여 스택 트레이스를 얻는 것은, 시스템의 내부 논리와 데이터 처리 구조를 명확히 파악할 수 있게 해주는 매우 강력한 동적 분석 기법입니다 [2, 3].
|
||||
## 매 한 줄
|
||||
> **"매 error 의 발생 시점 의 call chain 의 snapshot."**. 매 runtime 의 active frame 의 list — function name · file · line · 매 local variable (optional). 2026 modern observability 는 매 stack trace 의 distributed trace · source map · symbolication · 매 LLM-assisted root cause 의 통합.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
> 스택 트레이스(Stack trace) 자체에 대한 기술적이고 포괄적인 정의는 소스에 관련 정보가 부족합니다. 제공된 소스에 따르면, 스택 트레이스는 코드 내에서 특정 객체가 할당되거나 생성된 정확한 위치를 보여주는 기록을 의미합니다 [1, 2]. 주로 브라우저의 개발자 도구나 IDE의 프로파일링 과정에서 메모리 누수([[memory|memory]] leak) 원인을 찾거나 예외(Exception)를 분석하는 목적으로 활용됩니다 [3, 4].
|
||||
### 매 구성 요소
|
||||
- **Frame**: 매 each function call 의 record (caller info).
|
||||
- **Top of stack**: 매 error 의 throw 한 가장 안쪽 frame.
|
||||
- **Bottom**: 매 program entry (main, event loop).
|
||||
- **Symbolication**: 매 minified/compiled binary 의 readable name 의 resolve.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **코드 흐름 및 내부 논리 파악:** 크고 복잡한 시스템이나 낯선 코드베이스를 분석할 때, 서비스에 무작위 입력(Random input)이나 의도적으로 잘못된 입력을 주입하여 파싱 실패 등의 오류를 유도할 수 있습니다 [2, 3]. 이때 출력되는 에러 메시지와 스택 트레이스를 분석하면, 시스템의 보이지 않는 내부 논리와 데이터가 처리되는 구조적 흐름을 명확하게 드러낼 수 있습니다 [3].
|
||||
- **디버깅과 호출 스택(Call Stack) 역추적:** 발견된 버그를 수정하기 위해서는 먼저 문제를 재현한 뒤, 해당 버그로 이어지는 호출 스택을 코드 내에서 직접 추적(Trace)하는 방식이 권장됩니다 [1].
|
||||
- **IDE 탐색 기능과의 연계:** 스택 트레이스는 문제의 정확한 위치를 알려주는 내비게이션 역할을 합니다. 예를 들어 스택 트레이스에 "22번째 줄에서 에러 발생"과 같은 정보가 포함되어 있다면, VS Code와 같은 IDE의 명령어 팔레트에서 `:22` 등을 입력하여 즉시 해당 파일의 라인이나 열(Column)로 점프할 수 있어 코드 탐색의 효율을 극대화할 수 있습니다 [4]. 또한 스택 트레이스와 로그는 코드베이스 내에서 무엇을 검색(grep)해야 할지 알려주는 훌륭한 단서가 됩니다 [2].
|
||||
### 매 종류
|
||||
- **Native**: 매 Go panic, C++ SIGSEGV — debug symbols 의 필요.
|
||||
- **Managed**: JVM, .NET, Python — runtime 의 자동 capture.
|
||||
- **Async**: 매 promise/coroutine — 매 await chain 의 reconstruct (Python 3.11+ exception groups, V8 async stack).
|
||||
- **Distributed**: 매 trace_id + span 의 across-service stack.
|
||||
|
||||
---
|
||||
### 매 응용
|
||||
1. 매 production error 의 root cause 의 빠르게 locate.
|
||||
2. 매 performance profiling — 매 sample-based stack 의 hot path 의 reveal.
|
||||
3. 매 security forensics — 매 exploit 의 entry point 의 identify.
|
||||
|
||||
- **메모리 할당 위치 식별**: [[Chrome|Chrome]]의 할당 타임라인([[Allocation Timeline|Allocation Timeline]]) 도구는 특정 시간 동안 발생한 모든 메모리 할당 내역을 스택 트레이스와 함께 기록합니다 [1]. 개발자는 '힙 할당 스택 트레이스 기록(Record heap allocation stack traces)' 설정을 활성화하여 특정 객체를 할당하는 데 책임이 있는 코드 영역을 파악할 수 있습니다 [3].
|
||||
- **메모리 누수 디버깅 효율화**: 프로파일링 도구에서 '할당 스택(Allocation stack)' 탭을 확인하면 해당 객체(예: 문자열 등)가 정확히 어디서 생성되었는지 알려주는 스택 트레이스를 볼 수 있습니다 [2]. 이러한 스택 트레이스는 코드를 일일이 읽어가며 누수 지점을 찾는 것보다 훨씬 빠르게 수정이 필요한 코드 위치를 짚어줍니다 [5].
|
||||
- **예외(Exception) 분석**: IntelliJ IDEA와 같은 개발 환경(IDE)에서 V8 CPU 프로파일링을 분석할 때, 특정 함수 호출에 대한 스택 트레이스로 이동하여 발생한 예외를 확인하고 분석할 수 있습니다 [4].
|
||||
- *(주의: 스택 트레이스가 메모리 구조 내에서 어떻게 생성되고 유지되는지에 대한 근본적인 메커니즘 등은 소스에 관련 정보가 부족합니다.)*
|
||||
## 💻 패턴
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 관련 정보가 부족합니다.
|
||||
### Python — full traceback with locals
|
||||
```python
|
||||
import traceback, sys
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [코드 탐색 및 디버깅 기반 기술]
|
||||
- [[로그 (Logs) 및 에러 메시지 (Error Messages)]]
|
||||
- 연결 이유: 스택 트레이스는 대개 로그나 에러 메시지와 함께 출력되어 코드베이스 분석의 핵심 단서를 제공하기 때문입니다 [2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에러 발생 시 코드베이스 내에서 구체적으로 어떤 키워드를 검색(grep)하여 진입점을 찾아야 하는지 파악할 수 있습니다 [2].
|
||||
|
||||
- [[중단점 (Breakpoints)]]
|
||||
- 연결 이유: 디버깅 도구를 사용할 때 스택 트레이스(호출 스택)와 함께 변수 값의 변화를 실시간으로 관찰하기 위해 사용되는 동적 분석 도구입니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순한 에러 출력을 넘어서, 런타임 시점의 런타임 흐름과 상태 변화를 추적하는 방법을 이해할 수 있습니다 [3].
|
||||
|
||||
#### [분석 및 접근 방법론]
|
||||
- [[의도적 실패 유도 (Intentional Failure Induction)]]
|
||||
- 연결 이유: 시스템의 구조를 파악하기 위한 수단으로써, 스택 트레이스를 얻어내기 위해 개발자가 의도적으로 비정상적인 입력을 주입하는 분석 기법입니다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 정적 분석만으로는 알기 힘든 애플리케이션의 런타임 동작과 예외 처리 경로를 파악하는 전략을 학습할 수 있습니다 [2, 3].
|
||||
|
||||
### Deeper Research Questions
|
||||
- 의도적으로 잘못된 입력을 주입하여 스택 트레이스를 얻는 탐색 기법이, 복잡한 분산 시스템이나 마이크로서비스 아키텍처 환경에서는 어떤 한계점이나 이점을 가지는가?
|
||||
- 스택 트레이스와 IDE의 라인/열 단위 이동 기능(예: `:22`)을 결합했을 때, 대규모 코드베이스에서의 버그 수정 시간을 얼마나 단축시킬 수 있는가?
|
||||
- 스택 트레이스가 제공하는 호출 스택(Call Stack) 정보만으로는 파악하기 힘든 비동기(Asynchronous) 코드 흐름을 추적하려면 어떤 추가적인 동적 분석 도구를 활용해야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 단순한 버그를 수정하기 위해 버그를 재현하고, 에러를 유발하는 호출 스택을 확인하여 문제가 발생한 실제 코드를 구현 레벨에서 탐색합니다 [1].
|
||||
- **System Design:** 스택 트레이스를 분석하여 시스템 내부의 논리와 데이터 처리 구조가 어떻게 설계되어 있는지 역으로 파악할 수 있습니다 [3].
|
||||
- **Operation / Maintenance:** 완전히 낯선 레거시 시스템을 유지보수해야 할 때, 임의의 값을 넘겨 고의로 에러를 발생시키고 이때 출력되는 스택 트레이스를 분석하여 유지보수의 시작점(grep 대상)을 찾습니다 [2].
|
||||
- **Learning Path:** 새로운 코드베이스에 온보딩할 때, 시스템의 특정 경로와 호출 흐름을 직접 추적하며 실행 원리를 터득하는 실전 학습 도구로 사용됩니다 [1, 3].
|
||||
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[동적 행동 추적 (Dynamic Behavior Tracking)]]
|
||||
- 확장 방향: 소스 코드를 눈으로 읽는 정적인 방식을 넘어, 스택 트레이스, 로그, 프로파일링 등을 통해 시스템이 런타임에 어떻게 작동하는지 분석하는 넓은 범위의 역량으로 지식을 확장합니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
---
|
||||
|
||||
- **Related Topics:** Memory Leak, [[Allocation Timeline|Allocation Timeline]], V8 JavaScript Engine
|
||||
- **Projects/Contexts:** [[Chrome DevTools|Chrome DevTools]], IntelliJ IDEA V8 CPU Profiling
|
||||
- **Contradictions/Notes:** 제공된 소스는 스택 트레이스를 주로 메모리 누수 및 성능 프로파일링을 위한 '도구적 관점'에서만 다루고 있으며, 스택 트레이스의 근본적인 동작 원리에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** draft
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** Datacollector에서 자동 추출된 위키 데이터의 초기 통합.
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** None
|
||||
- **처리 방식:** CREATE
|
||||
- **처리 이유:** 신규 지식 체계 도입
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
try:
|
||||
risky_op()
|
||||
except Exception:
|
||||
tb = traceback.TracebackException.from_exception(
|
||||
sys.exc_info()[1], capture_locals=True
|
||||
)
|
||||
print("".join(tb.format()))
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Go — runtime stack
|
||||
```go
|
||||
import "runtime/debug"
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
defer func() {
|
||||
if r := recover(); r != nil {
|
||||
log.Printf("panic: %v\n%s", r, debug.Stack())
|
||||
}
|
||||
}()
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Node.js — async stack 의 enable
|
||||
```js
|
||||
// Node 22+ 매 default
|
||||
Error.stackTraceLimit = 50;
|
||||
process.on("unhandledRejection", (reason) => {
|
||||
console.error(reason instanceof Error ? reason.stack : reason);
|
||||
});
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Source map symbolication (browser)
|
||||
```js
|
||||
import { SourceMapConsumer } from "source-map";
|
||||
const raw = await fetch("app.js.map").then(r => r.json());
|
||||
await SourceMapConsumer.with(raw, null, consumer => {
|
||||
const orig = consumer.originalPositionFor({ line: 42, column: 13 });
|
||||
console.log(orig); // { source: "src/app.tsx", line: 117, name: "handleClick" }
|
||||
});
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Sentry SDK with breadcrumbs
|
||||
```python
|
||||
import sentry_sdk
|
||||
sentry_sdk.init(dsn="https://...", traces_sample_rate=0.1)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
sentry_sdk.add_breadcrumb(category="auth", message="user login", level="info")
|
||||
# 매 exception 의 자동 capture + breadcrumb chain
|
||||
```
|
||||
|
||||
### OpenTelemetry — stack 의 distributed trace 의 attach
|
||||
```python
|
||||
from opentelemetry import trace
|
||||
span = trace.get_current_span()
|
||||
span.record_exception(exc, attributes={"stack": traceback.format_exc()})
|
||||
```
|
||||
|
||||
### Java — Throwable.getStackTrace
|
||||
```java
|
||||
try { ... } catch (Exception e) {
|
||||
for (StackTraceElement el : e.getStackTrace()) {
|
||||
log.error("{}.{} ({}:{})",
|
||||
el.getClassName(), el.getMethodName(),
|
||||
el.getFileName(), el.getLineNumber());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### LLM-assisted analysis (Claude Opus 4.7)
|
||||
```python
|
||||
prompt = f"""Stack trace:
|
||||
{stack}
|
||||
|
||||
Recent commits:
|
||||
{git_log}
|
||||
|
||||
매 root cause + 매 fix candidate 의 propose."""
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Production unhandled error | Sentry/Datadog 매 자동 capture |
|
||||
| Local dev | Native debugger (gdb, dlv, pdb) |
|
||||
| Async/promise chain | Runtime async stack 의 enable |
|
||||
| Minified prod JS | Source map upload + symbolication |
|
||||
| Distributed call | OTel trace + span exception |
|
||||
|
||||
**기본값**: 매 OTel + Sentry 의 combine — 매 single trace 에서 매 service-crossing stack 의 see.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Debugging]] · [[Observability]]
|
||||
- 변형: [[Async_Stack_Trace]] · [[Distributed_Tracing]]
|
||||
- 응용: [[Error_Monitoring]] · [[Crash_Reporting]] · [[Profiling]]
|
||||
- Adjacent: [[Source_Maps]] · [[Symbolication]] · [[Logging]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 long stack trace 의 summarize, 매 framework noise 의 filter, 매 likely culprit frame 의 highlight.
|
||||
**언제 X**: 매 sensitive PII 의 local variable 의 포함 — sanitize first.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Swallow exception**: `except: pass` — 매 stack 의 lose.
|
||||
- **Re-raise wrong**: 매 `raise e` (Python) 매 traceback 의 truncate — `raise` bare 의 use.
|
||||
- **No source map**: 매 prod minified — stack 의 unreadable.
|
||||
- **Stack 의 user 의 expose**: 매 5xx response 에 raw stack 의 dump — info leak.
|
||||
- **Limit too low**: `Error.stackTraceLimit = 10` 매 root frame 의 cut off.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Python docs traceback module, V8 async stack RFC, Sentry symbolication guide 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — async stacks, symbolication, OTel integration |
|
||||
|
||||
Reference in New Issue
Block a user