Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

5.3 KiB

Raw Blame History

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

title

Pre-Mortem

🎯 한 줄 통찰 (One-line insight)

프로젝트가 이미 실패했다고 가정하고 그 원인을 역추적함으로써 경영진의 과잉 확신과 인지적 맹점을 강제로 제거하는 구조적 의사결정 보호 장치 [1, 2].

🧠 핵심 개념 (Core concepts)

실패의 사전 가정 (Prospective Hindsight): 프로젝트가 미래에 완전히 실패했다고 가정하고 분석을 시작함 [1].
역방향 추론 (Working Backward): 가상의 실패 지점에서 거꾸로 거슬러 올라가며 잠재적인 실패 원인들을 식별함 [1].
가용성 휴리스틱 억제 (Mitigating Availability Heuristic): 기억에 쉽게 떠오르는 시나리오를 넘어, 고려되지 않았던 다수의 위험 시나리오를 강제로 검토하게 함 [3].
과잉 확신 편향 교정 (Overconfidence Bias Correction): 자신의 능력이나 통제력을 과대평가하는 경향을 억제하고 현실적인 위험 평가를 유도함 [1].

🧩 추출된 패턴 (Extracted patterns)

속도 조절 패턴 (Slowing Down): 결론으로 직행하려는 본능을 억제하고 의도적으로 분석 속도를 늦추어 트레이드오프를 평가함 [2].
비판적 시나리오 확장 패턴: 단순히 "무엇이 잘못될 수 있는가"를 묻는 대신 "이미 잘못되었다"고 선언함으로써 비판적 사고의 심리적 장벽을 제거함 [1].
프레임워크 통합 패턴: 의사결정 체크리스트, 악마의 변호인(Devil's Advocacy) 기법과 결합하여 프로젝트 관리 프로세스에 내재화됨 [2].

📖 세부 내용 (Details)

Pre-Mortem은 가용성 휴리스틱(최근의 일이나 감정적으로 강렬한 사건을 과대평가하는 경향)에 의한 왜곡된 위험 평가를 방지하기 위해 설계된 구조화된 의사결정 기법이다 [3]. 실행 이전 단계에서 다수의 시나리오를 고려하도록 강제함으로써 의사결정의 질을 높인다 [3].

작동 메커니즘: 이 기법은 "해당 프로젝트가 비참하게 실패했다"는 가상의 미래를 설정한다 [1]. 그 후 팀은 해당 실패를 초래했을 법한 모든 가능한 원인을 역으로 추적하여 문서화한다 [1]. 이 과정은 경영진이 흔히 저지르는 '계획의 오류(Planning fallacy)'나 낙관주의 편향을 중화하는 데 효과적이다 [1].
전략적 중요성: 대규모 자본을 투입하기 전에 경영진의 핵심 가정을 검증하고, 발생 가능한 위험 요소를 선제적으로 식별하는 전략적 보호 장치(Safeguard) 역할을 한다 [2]. 이는 조직이 단순히 직관이나 과거의 성공 경험에 의존하여 결정을 내리는 'HIPPO(Highest-Paid Person's Opinion)' 역학을 견제하는 데 도움을 준다 [2, 4].
조직적 적용: 많은 기업이 의사결정 지원 도구로 Pre-Mortem을 도입하고 있으나, 공식적인 편향 탐지 및 교정 메커니즘으로 완전히 정착된 사례는 여전히 드문 편이다 [5]. 성공적인 적용을 위해서는 이를 프로젝트 관리 프레임워크에 직접 통합하고, 실패 가능성을 논의하는 것을 장려하는 문화적 토대가 필요하다 [2].

⚖️ 모순 및 업데이트 (Contradictions & updates)

이론과 실제의 격차: Pre-Mortem과 같은 디바이아싱(Debiasing) 기법의 효과성은 이론적으로 입증되었으나, 실제 기업 운영 환경에서 공식적인 절차로 사용되는 경우는 아직 드물다 [5].
자동화와의 관계: 최근에는 AI 기반의 의사결정 지원 시스템이 Pre-Mortem 기능을 보조하거나 대체할 가능성이 논의되고 있으나, 여전히 인간의 맥락 이해와 윤리적 판단이 결합되어야 최적의 결과를 낼 수 있다는 symbiosis(공생) 모델이 권장된다 [6, 7].

🛠️ 적용 사례 (Applied in summary)

현재 소스 데이터에서 특정 프로젝트 파일 경로나 Git 커밋 해시 등 기술적인 실제 적용 사례는 발견되지 않았습니다. 다만, 다음과 같은 조직적 권고 사항이 명시되어 있습니다.

임원 의사결정 프로세스: 복잡하고 이해관계가 얽힌 비즈니스 환경에서 인지적 한계를 보완하기 위한 구조적 중재 도구로 권장됨 [3, 5].
전략 프로젝트 관리: 대규모 투자 결정 전 경영진의 가정을 파괴적으로 검증하는 '레드 팀(Red Teaming)' 활동의 일환으로 제안됨 [2].

✅ 검증 상태 및 신뢰도

상태: draft
검증 단계: conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
출처 신뢰도: B (Official Documentation / Primary Source via NotebookLM)
중복 검사 결과: 신규 생성 (New discovery)

📝 변경 이력 (Change history)

2026-05-24: Initial draft generated via Datacollector_MAC P-Reinforce engine.

5.3 KiB Raw Blame History