--- id: wiki-2026-0508-problem-solving-process title: Problem Solving Process category: 10_Wiki/Topics status: verified canonical_id: self aliases: [Problem Solving, Polya Method, Engineering Problem Solving] duplicate_of: none source_trust_level: A confidence_score: 0.9 verification_status: applied tags: [cognition, engineering, methodology, debugging] raw_sources: [] last_reinforced: 2026-05-10 github_commit: pending tech_stack: language: multi framework: structured-problem-solving --- # Problem Solving Process ## 매 한 줄 > **"매 a problem well-stated is half-solved."**. 매 Polya 1945 *How to Solve It* 의 4단계 (understand → plan → carry out → look back) 가 매 modern engineering, debugging, AI agent design 의 backbone. 매 2026 LLM agent (Claude, OpenAI Operator) 의 ReAct/CoT 도 매 본질적으로 Polya 의 자동화. ## 매 핵심 ### 매 Polya 4 stages - **Understand**: 매 restate, 매 identify knowns/unknowns/constraints. - **Plan**: 매 decompose, 매 analogous problems, 매 work backwards. - **Carry Out**: 매 execute, 매 verify each step. - **Look Back**: 매 check, 매 generalize, 매 alternate methods. ### 매 strategies - **Decomposition**: 매 break into sub-problems (divide & conquer). - **Analogy**: 매 find similar solved problem (case-based reasoning). - **Inversion**: 매 work backwards from goal. - **Specialization**: 매 try simpler instance (n=1, n=2 first). - **Generalization**: 매 solve more general version sometimes easier. - **Symmetry / Invariants**: 매 find quantity that doesn't change. ### 매 응용 1. Debugging: 매 reproduce → bisect → fix → verify → write test. 2. System design: 매 understand requirements → decompose → component design. 3. LLM agent: 매 ReAct loop = Polya in code. 4. Math/algorithms: 매 examples → conjecture → prove → optimize. ## 💻 패턴 ### Pattern 1: Debugging as Polya ```python def debug(bug_report): # 1. UNDERSTAND repro = build_minimal_repro(bug_report) # 2. PLAN suspected_modules = trace_stack(repro) plan = git_bisect_plan(repro, suspected_modules) # 3. CARRY OUT bad_commit = git_bisect(plan) fix = author_fix(bad_commit) # 4. LOOK BACK add_regression_test(repro) update_runbook(bug_report.symptom) return fix ``` ### Pattern 2: ReAct LLM agent (Polya 자동화) ```python SYSTEM = """For each task, follow: 1. THOUGHT: restate the problem and constraints (UNDERSTAND). 2. PLAN: decompose into 1-3 next actions. 3. ACTION: call exactly one tool. 4. OBSERVE: read result. 5. REFLECT: did this advance? if not, revise plan (LOOK BACK). Repeat until done. """ ``` ### Pattern 3: Decomposition tree ```python @dataclass class Problem: statement: str children: list["Problem"] = field(default_factory=list) solved: bool = False solution: Optional[str] = None def solve(p: Problem): if can_solve_directly(p): p.solution = direct(p); p.solved = True; return p.children = decompose(p) for c in p.children: solve(c) p.solution = combine([c.solution for c in p.children]) p.solved = all(c.solved for c in p.children) ``` ### Pattern 4: Five-Whys root cause ```text Symptom: 매 dashboard p99 latency 5x baseline. Why? — 매 DB queries slow. Why? — 매 missing index. Why? — 매 migration didn't add it. Why? — 매 PR template doesn't require index check. Why? — 매 no automated linter. → 매 Root: missing tooling, not "lazy engineer". ``` ### Pattern 5: Pre-mortem (inverted planning) ```python def pre_mortem(plan): # 매 imagine the plan failed in 6 months # 매 ask team: what went wrong? failure_modes = team_brainstorm("It's 6mo from now. Project failed. Why?") return prioritize_mitigations(failure_modes) ``` ### Pattern 6: Working-memory checkpoint ```markdown ## 매 KNOWN - API returns 500 on POST /orders > 1000 items. ## 매 UNKNOWN - Is it timeout, memory, or DB lock? ## 매 TRIED - [x] Reproduce locally → reproduces at 1500. - [x] Add timing logs → DB INSERT is slow. - [ ] Check lock contention. ## 매 NEXT - pg_stat_activity during repro. ``` ### Pattern 7: Solution generalization (look back) ```python # 매 after fixing one instance — 매 ask: where else does this pattern occur? def generalize(fix): pattern = abstract(fix) # e.g., "missing pagination in list endpoints" similar = scan_codebase_for(pattern) return apply_fix_to_all(similar) ``` ## 매 결정 기준 | 상황 | Strategy | |---|---| | 매 stuck at "understand" | Restate problem to rubber duck / LLM | | 매 plan unclear | Try simpler case (n=1) first | | 매 carry-out fails | Bisect; isolate variable | | 매 done — but is it right? | Look back; alt method; edge cases | | 매 recurring class of bugs | Generalize the fix; tooling | | 매 LLM agent loop stuck | Force REFLECT step; reduce action set | **기본값**: 매 always do Look Back — 매 most engineers skip it; 매 90% of compounding leverage lives there. ## 🔗 Graph - 부모: [[Cognitive Psychology]] - 변형: [[Polya Method]] · [[Debugging]] · [[Root Cause Analysis]] - Adjacent: [[ReAct]] · [[Chain of Thought]] ## 🤖 LLM 활용 **언제**: 매 system-prompt scaffolds, 매 incident runbooks, 매 onboarding docs, 매 interview prep. **언제 X**: 매 trivial 1-line tasks — 매 over-formalization slows. ## ❌ 안티패턴 - **Skip understanding**: 매 jump to coding → 매 wrong problem solved. - **Skip looking back**: 매 ship fix, never abstract → 매 same bug class returns. - **No working-memory log**: 매 forget what you tried. - **One strategy only**: 매 if decomposition fails, try inversion / analogy. - **LLM as oracle**: 매 use as plan-critic, not plan-author. ## 🧪 검증 / 중복 - Verified (Polya 1945, Newell & Simon 1972, Yao et al. 2022 ReAct). - 신뢰도 A (foundational). ## 🕓 Changelog | 날짜 | 변경 | |---|---| | 2026-05-08 | Phase 1 | | 2026-05-10 | Manual cleanup — Polya 4단계 + ReAct + 7 패턴 |