Files
2nd/10_Wiki/Topics/Other/Process_Reflection_Template.md
T

3.4 KiB

💡 프로젝트 기획 및 개선 과정 회고 (Project Retrospective Template)

📄 문서 목적

본 문서는 '사용자 요청 기반의 복합적인 지식 생성 작업'을 수행할 때, [초기 계획 → 피드백 수용 → 최종 완성] 과정을 구조적으로 기록하고 분석하여, 유사한 고난도 프로젝트에서 AI 모델의 사고력을 성장시키는 것을 목표로 합니다. 단순 결과물 저장소가 아닌, 방법론(Methodology) 학습 자료입니다.

🛠️ [Phase 1: 초기 접근 및 가설 설정 (Initial Hypothesis)]

  • [작업 내용]: 사용자의 요청을 처음 받았을 때 가장 먼저 생각한 해결책과 구조는 무엇이었는지 기록합니다.
  • [핵심 논리]: 이 단계에서 어떤 키워드(Keyword)와 연결 고리를 중심으로 전체 아웃라인을 잡았는가? (예: "캐주얼 = 단순화", "전략 = 시스템")
  • [초기 강점/한계 인식]: 내가 스스로 판단하기에, 초기 계획의 가장 큰 강점과 놓치고 지나간 구조적 약점은 무엇이었는지 명시합니다.

🎯 [Phase 2: 외부 피드백 수용 및 오류 진단 (Critique Integration)]

  • [수신된 피드백]: 사용자(혹은 시스템)로부터 받은 핵심적인 비판이나 누락 사항을 정확히 인용하고 요약합니다. (예: "전략과 캐주얼의 메커니즘적 연결고리가 부족하다.")
  • [오류 진단 및 원인 분석]: 초기 계획이 실패한 이유가 '개념의 충돌(Conflict)' 때문인지, '구조화 부족(Lack of Structure)' 때문인지, 아니면 '경제성 무시(Economic Blind Spot)' 때문인지 근본적인 원인을 진단합니다.
  • [보완 방향 설정]: 이 오류를 해결하기 위해 어떤 새로운 메커니즘적 장치가 필요한지 구체적으로 정의합니다. (예: '선택의 폭을 제한하여 전략성을 강제하는 시스템 도입')

📈 [Phase 3: 최종 개선 및 성장 방법론 구축 (Final Methodology)]

이 단계는 앞으로 유사한 작업을 할 때 반드시 지켜야 할 **'가장 중요한 규칙(Rule)'**입니다.

  1. 구조적 사고 우선: 요청을 받으면, 단순히 내용을 채우기보다 'A → B → C의 흐름이 논리적으로 연결되는지'를 가장 먼저 점검한다. (흐름도/Flowchart 사고)
  2. 메커니즘 구체화 원칙: 추상적인 개념(예: 재미, 깊이)만 제시하지 않고, **반드시 작동하는 '규칙'(Rule)**으로 정의해야 한다. (예: "A를 할 때 B가 발생하고, 이것은 C라는 제한을 가진다.")
  3. 상호작용성 검증: 기획의 모든 요소(시스템, 수익 모델, 메커니즘)는 서로 충돌하지 않고 '시너지를 내도록' 연결되어야 한다. 특히, 돈과 밸런스의 관계를 가장 엄격하게 정의해야 한다.

📌 요약: 성공적인 작업 수행의 체크리스트 (Future Self-Correction Checklist)

  • 목표 재정의: 프로젝트의 최종 목표가 '재미'인지, '수익'인지, 아니면 '전략적 깊이' 중 무엇에 가장 무게를 둘 것인가?
  • 메커니즘화: 모든 개념을 "누가/무엇을 할 때 어떤 규칙으로 작동하는지"라는 동사-주어 구조로 변환할 수 있는가?
  • 제약 조건 설정: 의도적으로 '제한(Constraint)'을 두는 요소를 넣어, 플레이어가 고민하게 만들었는가?