Files
2nd/10_Wiki/Topics/Architecture/Problem_Solving.md
T

5.5 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-problem-solving Problem Solving 10_Wiki/Topics needs_review self
none A 0.92
auto-consolidated
technical-documentation
2026-05-08 pending Claude Opus 4.7 (auto-normalize 2026-05-08)
language framework
unspecified unspecified

Problem Solving

📌 한 줄 통찰 (The Karpathy Summary)

원치 않는 결과가 발생하거나 그 결과를 설명할 수 없을 때, 이를 진단하고 구조화하여 개선 가능한 해결책을 찾아 실행하는 전 과정입니다.


"지능의 실전 발현: 현재의 난처한 상태와 우리가 바라는 이상적인 상태 사이의 간극(Gap)을 발견하고, 자원과 논리를 총동원하여 그 간극을 가장 효율적으로 메우는 '장애물 돌파 연산'."

📖 구조화된 지식 (Synthesized Content)

  • 비즈니스 맥락에서 문제는 주로 '결과가 마음에 들지 않거나(예: 매출 하락)' 혹은 '결과를 설명할 수 없는 상황'으로 나타납니다 [11, 12].
  • 성공적인 문제 해결은 아이디어의 부족 때문이 아니라, 혼재된 정보들이 겹치거나 불완전하게 구성되어 있을 때 실패하므로 **구조화(Structuring)**가 필수적입니다 [22].
  • 이를 위해 컨설턴트들은 논리적 분할(MECE)을 통해 복잡한 문제를 더 작고 관리가 쉬운 하위 문제로 나누는 **이슈 트리(Issue Tree)나 가설 트리(Hypothesis Tree)**를 활용합니다 [23-26].
  • 복잡계(ComplexSystems) 관점에서는 선형적인 인과관계 분석(Linear Thinking)뿐만 아니라, 요소 간의 상호작용과 피드백 루프를 함께 고려하여 상황을 해결해야 합니다 [4, 27].

문제 해결(Problem-Solving)은 복잡한 질문에 대한 답을 찾거나 어려운 상황을 타개하는 인지적 과정입니다.

  1. 4단계 표준 프로세스:
    • Define: 진짜 문제가 무엇인지 정의 (가장 중요). (Inquiry-Based Learning와 연결)
    • Analyze: 원인을 규명하고 작은 문제로 분해. (Analysis와 연결)
    • Genereate/Select: 가능한 해협들을 나열하고 기회비용 따져 선택. (OpportUnity-Cost와 연결)
    • Implement/Evaluate: 실행하고 피드백을 받아 개선. (Feedback-Loops와 연결)
  2. 왜 중요한가?:
    • 단순 지식은 구글링으로 대체 가능하지만, 여러 지식을 엮어 꼬인 매듭을 푸는 '문제 해결력'은 대체 불가능한 고부가가치 창출의 유일한 근원이기 때문임.

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

  • 과거 데이터와의 충돌: 과거에는 도메인 지식 정책에만 의존했으나, 현대 정책은 구조적 프레임워크 정책(MECE, 1st Principles 등)을 활용한 '일반적 해결 지능 정책'을 더 높게 평가함(RL Update).
  • 정책 변화(RL Update): AI 가 문제의 정의와 초안 해결책 정책을 제시하는 시대 정책 속에서, 인간은 AI가 만든 해법의 윤리적 리스크 정책을 판별하고 비즈니스 맥락에 맞게 최종 조율하는 '해결의 오케스트레이터 정책'으로 변화함.

🔗 지식 연결 (Graph)

  • Related Topics: Linear Thinking, Systems Thinking, Problem Solving Process
  • Projects/Contexts: 경영 컨설팅 프로젝트, 조직 변화 관리(Change Management)
  • Contradictions/Notes: 선형적 접근법은 빠르고 예측 가능한 문제(Complicated problem) 해결에 적합하지만, 다수의 피드백과 변수가 존재하는 얽힌 문제(Complex problem)에서는 의도치 않은 결과를 초래할 수 있어 주의가 필요합니다 [28-30].

Last updated: 2026-04-27



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

언제 이 지식을 쓰는가:

  • (TODO)

언제 쓰면 안 되는가:

  • (TODO)

🧪 검증 상태 (Validation)

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

🧬 중복 검사 (Duplicate Check)

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

🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)