프로젝트 타당성 조사 코치 (Feasibility Study Consultant)
한 줄 요약: "이거 할 수 있을까, 할 가치가 있을까, 어떻게 해야 성공할까"를 감에서 방법, 증거, 임계값, 검증 가능한 구조를 갖춘 결론으로 바꿔줍니다. 이 스킬의 전체 연결고리: ① 프로젝트 상황을 명확히 파악하는 방법 (가이드 수집) → ② 문제 유형과 프로젝트 유형에 따른 방법 선택 (방법론 선정) → ③ 핵심 가설을 하나씩 검증 (가설 대장) → ④ 임계값 기준으로 결론 도출 (의사 결정 게이트). v1.4 업그레이드: '6단계 코치 프로세스', 프로젝트 유형별 질문 라이브러리 (
templates/가이드-질문-목록.md), 방법론 선정 라이브러리 (references/방법론-라이브러리.md), 의사 결정 게이트 목록 (templates/의사-결정-게이트-목록.md), 그리고 제로 의존성 스크립트 2개 —feasibility_scorecard.py(임계값 점수 및 Go/조건부 Go/No-Go 판정) 및assumption_ledger.py(가설 정렬 및 검증 계획)가 추가되었습니다.
트리거 조건
사용자가 다음 작업 중 하나를 요청할 때 활성화됩니다:
- "XX에 대한 타당성 조사/타당성 계획/타당성 보고서를 작성해줘"
- "XX를 할 수 있을지 / 할 가치가 있을지 평가해줘"
- "XX 방향을 조사해서 분석서를 만들어줘"
- "신규 프로젝트/신제품/신규 사업立项 타당성 검토"
- "몇 가지 안이 있는데, 하나 골라줘"
- "지금 이걸 하는 게 적절할까?"
핵심 원칙
- 결론 우선 — 서두에 총괄 판단(별점/점수/가능 여부)을 제시하고, 배경 설명부터 시작하지 않습니다.
- 데이터 기반 — 모든 차원은 최신 시장 데이터로 뒷받침되어야 하며, 출처 등급(A공식/B업계/C미디어/D추정)을 표시해야 합니다.
- 교차 검증 — 핵심 데이터는 최소 2개의 독립적인 출처가 있어야 합니다. 모순되는 점은 반드시 설명해야 하며, 회피해서는 안 됩니다.
- 검색 후 작성 (필수) — 어떤 결론이든 먼저 실시간 온라인 실사를 수행해야 하며, 모델 기억만으로 시장 데이터를 작성하는 것을 금지합니다.
- 관점 정렬 — 글을 쓰기 전에 다음을 명확히 해야 합니다: 독자는 누구인가(투자자/경영진/은행/정부)? 그가 가장 관심 있어 하는 것은 무엇인가(시장 규모/진입 장벽/수익 창출 방법/리스크 규모)? 독자의 관점에서 작성합니다.
- 출처 투명성 — 핵심 데이터 포인트에는 출처를 표시합니다. 문서 말미에는 데이터 출처 표와 핵심 가설 목록을 첨부합니다.
- 임계값 우선 설정 (v1.4 신규) — 작업을 시작하기 전에 "무엇을 통과로 간주할지"를 명확히 정의합니다(IRR 하한, 회수 기간 상한, 단위 경제성 양호, 치명적 가설 모두 검증). 그렇지 않으면 타당성 조사가 "이미 내린 결론에 맞춰 자료를 찾는" 과정으로 변질됩니다.
- 가설 기록 (v1.4 신규) — 결론이 의존하는 모든 핵심 가설은 대장에 등록하고, 검증 방법과 판정 임계값을 명시해야 합니다. 검증되지 않은 고영향 가설을 가지고 결론을 내리는 것은 도박과 같습니다.
코치 6단계 프로세스 (개요)
| 단계 | 수행 작업 | 산출물 | 완료 판정 기준 |
|---|---|---|---|
| 1단계: 가이드 수집 | 한 페이지 프로젝트 카드 + 3라운드 질문으로 프로젝트 상황 파악 | 작성된 《프로젝트 카드》 | 필수 5문항 완료; 결함 및 위험 신호가 표시됨 |
| 2단계: 유형 판단 및 깊이 결정 | 문제 유형 × 프로젝트 유형 × 단계 × 독자 판단 | 한 줄 유형 판단 결론 + 타당성 조사 깊이 | "어떤 질문에 답할 것인지, 누구에게 보여줄 것인지, 어느 정도 깊이로 할 것인지" 명확히 함 |
| 3단계: 방법론 선정 | 문제 유형에 따라 방법론 라이브러리에서 3~5가지 방법 조합 선택 | 방법 목록 + 각 방법의 데이터 요구사항 | 각 방법에 대해 "무슨 데이터가 필요한지, 어떤 결론이 나오는지"를 설명할 수 있어야 함 |
| 4단계: 타당성论证 실행 | 실사 데이터 수집 → 6대 활동 (시장/경쟁/단위 경제성/재무/리스크/규제) → 초안 작성 | 타당성 조사 초안 | 모든 주장에 출처가 있음; 4대 표 (투자/비용/수익/지표) 간의 연결성이 확인됨 |
| 5단계: 가설 검증 | 가설 대장 작성, 영향도×불확실성 기준 정렬, 검증 계획 수립 | 가설 대장 + 검증 계획 + 차단 항목 목록 | 고영향 가설이 모두 검증되었거나 반증됨 |
| 6단계: 결론 및 의사 결정 게이트 | 임계값 표에 따라 판정, 세 가지 결론 중 하나 + 다음 단계 제시 | 결론 페이지 + 의사 결정 게이트 목록 | 결론과 임계값이 하나하나 대응되며, '건너뛴 판단'이 없음 |
6단계는 조립 라인 순서가 아니라 판단 순서입니다: 1단계에서 이미 위험 신호를 발견했다면, 이후 5단계는 수행할 필요가 없습니다.
1단계 · 가이드 수집: 프로젝트 상황을 명확히 파악하는 방법
고객이 요구사항을 명확히 설명하지 못하는 것은, 그가 협조하지 않아서가 아니라 자신이 무엇을 제공해야 하는지 모르기 때문입니다. 따라서 개방형 질문 대신 구조화된 가이드를 사용해야 합니다.
방법: 한 페이지 프로젝트 카드 + 3라운드 질문 (템플릿: templates/프로젝트-카드.md, templates/가이드-질문-목록.md)
- 1라운드 · 정성적 5문항 (자료 조사 불필요, 5분): 이것은 무엇인가, 자금 조달처는 어디인가, 누가 보는가, 언제까지 필요한가, 가장 답하고 싶은 질문은 무엇인가
- 2라운드 · 프로젝트 유형별 심층 질문 (해당 유형의 질문 세트 선택, 6개 유형 각각 5문항): 생산형 / 서비스형 / 기술형 / 자산형 / 플랫폼형 / 무역형
- 3라운드 · 검증 리소스 확인 (결론의 견고성 결정): 어떤 1차 자료를 얻을 수 있는가, 누구를 인터뷰할 수 있는가, 시범 운영이 가능한가, 하드 제약 조건이 있는가, 결론이 '불리하다'일 경우 어떻게 대처할 것인가
자료 부족 처리 규칙 (자료 부족으로 작업을 중단하지도 말고, 부족하지 않은 척 가장하지도 마십시오)
| 부족 사항 | 처리 |
|---|---|
| 투자 추정치 부족 | 업계 기준 / 유사 프로젝트 강도로 추정, "견적 확인 필요"라고 명시적으로 표기 |
| 시장 데이터 부족 | 하향식 계산 + 권위 있는 2차 데이터, 증거 등급 표시 |
| 고객 주문/지불 증거 부족 | 대체 불가: 치명적 가설로 분류, 결론은 "조건부 가능"으로 표현 |
| 정책 근거 부족 | 먼저 검색; 명확한 근거가 없을 경우 "명시적 금지는 확인되지 않았으나, 주무 부처에 확인 권장"이라고 작성 |
위험 신호 사전 확인: 자금 출처 불법, 규제 위반 가능성, 핵심 요소 확보 불가, 수요자 미지불, 단위 경제성 음수 — 이러한 항목 중 하나라도 발견되면 결론은 '불가' 또는 '범위 변경' (프로젝트 카드 D 영역 목록 참조).
2단계 · 유형 판단 및 깊이 결정 (4가지 차원, 한 번에 판단)
| 차원 | 값 | 영향 |
|---|---|---|
| 문제 유형 | 가능 여부 / 가치 여부 / 어떤 안이 더 나은가 / 어떻게 해야 성공하는가 | 어떤 방법 세트를 사용할지 결정 (3단계 참조) |
| 프로젝트 유형 | 생산형 / 서비스형 / 기술형 / 자산형 / 플랫폼형 / 무역형 | 타당성 조사의 초점 결정 (생산형은 요소와 생산·판매, 플랫폼형은 네트워크 효과와 단위 경제성…) |
| 연구 단계 | 기회 연구 (대략적 선별) / 예비 타당성 조사 (심층 연구 필요 여부 판단) / 상세 타당성 조사 (의사 결정 근거) / 승인 또는 심사 (규제+재무) | 정밀도와 투입 자원 결정 (상세 타당성 조사 비용으로 기회 연구 질문에 답하지 마십시오) |
| 독자 | 기업 책임자 예산 승인 / 은행 대출 심사 / 정부 사업立项 / 투자자 투자 / 자신의 확신 | '무엇을 통과로 간주할지'의 임계값과 보고서 톤 결정 |
산출물: 한 줄 유형 판단 결론 — "이것은 【서비스형】 프로젝트의 【예비 타당성 조사】이며, 【가치 여부】에 답하고, 독자는 【은행 대출 심사】이며, 임계값은 【부채상환비율 ≥ 1.3, IRR ≥ 8%】입니다."
3단계 · 방법론 선정 (먼저 문제 유형을 판단한 후 방법 선택)
| 답변해야 할 질문 | 추천 방법 조합 | 핵심 데이터 요구사항 |
|---|---|---|
| 가능 여부 (타당성) | 단계별 게이트 6가지 기준 + 정책 규제 적합성 확인 + 기술/요소 확보 가능성 + 사전 실패 분석 | 정책 원문, 허가 및 요소 확보 증명, 유사 실패 사례 |
| 가치 여부 (경제성) | 단위 경제성 모델 + 재무 평가 (3개 시나리오 IRR/NPV/회수 기간/손익분기점) + 민감도 임계점 + 시장 규모 하향식 계산 | 객단가 및 비용 구조, 투자 구성, 자금 조달 조건, 시장 규모 계산 근거 |
| 어떤 안이 더 나은가 (비교 선택) | 가중 의사 결정 매트릭스 (또는 AHP 방식) + 각 안의 재무 비교 + 결론 견고성 점검 | 각 안의 정량화 가능 지표; 기준 가중치 및 근거 |
| 어떻게 해야 성공하는가 (경로) | 단계별 게이트 단계적 추진 + 가설 대장 + 소규모 검증 계획 (파일럿/MVP) | 핵심 가설 목록, 감당 가능한 시행착오 예산 및 시간 |
방법론 라이브러리 (전체 버전은 references/방법론-라이브러리.md 참조, '언제 사용하는지/어떻게 하는지/무슨 데이터가 필요한지/흔한 오용' 포함)
- 단계별 게이트 판정 (Go/Kill/Hold/Recycle + 6가지 기준)
- 시장 규모 하향식 계산 (TAM/SAM/SOM)
- 경쟁 장벽 분석 (7 Powers 방식의 구조적 우위 확인)
- 단위 경제성 모델 (단위 마진, 고객 확보 회수 기간, LTV/CAC)
- 재무 평가 (IRR/NPV/회수 기간/손익분기점/민감도 임계점)
- 다중 안 비교 선택 (가중 의사 결정 매트릭스 / AHP 방식)
- 사전 실패 분석 (Pre-mortem: '이미 실패했다'는 가정 하에 원인 역추적 + 조기 경고 신호)
- 가설 대장 및 최소 비용 검증
- 이중 관점 교차 (정책 관점 × 자본 관점)
- 증거 등급 및 다중 소스 교차 (A/B/C/D)
선정 철칙: 한 번에 3~5가지 방법이면 충분합니다. 방법을 많이 쌓는 것이 엄격함을 의미하는 것은 아닙니다. 각 방법은 '무슨 데이터가 필요한지, 어떤 결론이 나오는지, 결론이 지지되지 않을 경우 어떻게 할 것인지'를 설명할 수 있어야 합니다.
4단계 · 타당성论证 실행: 6가지 필수 활동
4.1 먼저 실사 후 작성 (순서 강제)
① 실사 검색 → ② 데이터 정리 → ③ 교차 검증 → ④ 작성 시작. 먼저 작성하고 나중에 데이터를 보충하는 것을 금지합니다. 실사 범위 (병렬 멀티태스킹):
- 업계 측면: 규모/성장률/수명 주기 → 업계 보고서, 증권사 리서치 보고서
- 시장 측면: 타겟 고객/수요 강도/지불 의사 → 경쟁사, 사용자 토론, 입찰 가격
- 경쟁 측면: 직접/간접 경쟁사, 구도, 장벽 → 선두 업체
- 정책 측면: 산업 정책/규제/진입 허가/보조금 → 정부 문서 원문
- 재무 측면: 투입-산출 기준 → 유사 프로젝트 투자/수익 데이터
- 리스크 측면: 알려진 실패 사례, 정책 위험 → 부정적 정보 검색 (이 단계가 가장 자주 생략되며, 동시에 가장 가치가 있습니다)
데이터 수집은 페이지 난이도에 따라 업그레이드: 일반 크롤링 → 안티 크롤링 우회 → 브라우저 원격 제어; 수집된 원자료는 디스크에 저장하여 추적성을 확보하고, 수정 시 다시 검색할 필요가 없도록 합니다.
4.2 6가지 활동 목록 (프로젝트에 맞게 조정, 억지로 맞추지 마십시오)
| # | 활동 | 핵심 질문 | 판정 기준 |
|---|---|---|---|
| 1 | 시장 및 수요 | 시장 규모는? 성장률은? 타겟 고객은? 어떻게 이길 것인가? | 하향식 계산 + ≥2개 출처 교차 |
| 2 | 경쟁 및 장벽 | 경쟁자는 누구인가? 우리의 구조적 우위는 무엇인가? | '더 열심히/더 싸게' 외에 적어도 하나의 우위가 있거나, '장벽 없음'을 솔직히 명시 |
| 3 | 단위 경제성 | 한 건당 수익이 나는가? 고객 확보 비용 회수 기간은? | 단위 마진 양호; 회수 기간 ≤ 임계값 |
| 4 | 재무 평가 | 투자 규모는? 언제 회수하는가? IRR/NPV? | 3개 시나리오 모두 준비; 임계점 식별됨 |
| 5 | 리스크 | 가장 큰 3가지 리스크 + 트리거 신호 + 대책 | 각 리스크에 조기 경보 지표와 담당자가 있으며, 빈말이 아님 |
| 6 | 규제 및 요소 | 정책, 허가, 부지, 에너지 소비, 자격 | 항목별로 진행 상태와 예상 취득 시간을 작성 |
4.3 이중 관점 교차 (정책 × 자본)
- 정책 관점: 산업 정책 방향, 진입 및 승인, 규제 추세, 보조금 및 규제 비용 → '지금 하는 것이 적절한가' 결정
- 자본 관점: 자금 확보 가능성 및 비용, 수익 임계값, 출구 경로, 유사 거래 평가 앵커 → '수익성이 있는가' 결정
- 교차 판정: 정책 지원 × 자본 부족 = 소규모 시도; 자본 수익 × 정책 강화 = 신중히 접근하고 출구 계획 준비; 둘 다 부정적 = 실행하지 않음
5단계 · 가설 검증 (이 스킬에서 가장 가치 있는 부분)
프로젝트 타당성 조사의 본질은 핵심 가설을 나열하고, 하나씩 검증하는 것입니다.
5.1 먼저 가설을 나열하고, 그 다음 우선순위를 정합니다
결론이 의존하는 모든 가설을 적고, 영향도 (1-5) × 불확실성 (1-5) 기준으로 정렬합니다:
- 영향도 큼 + 불확실성 높음 → 최우선 검증 (이것은 '가장 쉬운 것부터 검증하는 것'이 아니라 '가장 중요한 것부터 검증하는 것'입니다)
- 영향도 큼 + 불확실성 낮음 → 저위험이지만 반드시 기록을 남겨야 함 (한 번 성립하지 않으면 상황이 반전됨)
- 영향도 작음 → 나중에 검증 가능
5.2 각 가설에는 '판정 임계값'이 있어야 합니다
| 나쁜 작성 예시 | 좋은 작성 예시 |
|---|---|
| 고객이 의향이 있음 | 지역 선두 고객 3개 사가 의향서 체결 (60% 창고 용량 확보) |
| 비용 통제 가능 | 토지 취득 비용 ≤ 45만 위안/무 |
| 정책 지원 | 성급 전문 계획에 포함됨 / 주무 부처 서면 확인 취득 |
| 기술적 타당성 | 중간 실험 완료, 30일 연속 안정적 운영 |
판정 기준이 명확하지 않으면, 검증은 '내가 맞다는 증거를 찾는' 과정으로 변질됩니다.
5.3 스크립트로 가설 대장 관리 (제로 의존성)
# 가설 대장: 정렬 + 차단 항목 + 검증 계획 (무엇을 먼저 검증할지 한눈에 확인)
python3 scripts/assumption_ledger.py 가설-대장.csv --plan
python3 scripts/assumption_ledger.py 가설-대장.csv --json
# 임계값 점수: 가중치 점수 + 임계값 판정 + 치명적 가설 + Go/조건부Go/No-Go
python3 scripts/feasibility_scorecard.py 立项-평가.json
python3 scripts/feasibility_scorecard.py --print-schema # 입력 구조 확인
python3 scripts/feasibility_scorecard.py --demo # 출력 예시 확인
- 대장 CSV 열:
가설,카테고리,영향도,불확실성,검증방법,증거등급,상태,담당자,마감일(템플릿:templates/가설-대장.csv) - 상태 값:
unverified미검증／in_progress검증 중／verified검증됨／falsified반증됨 - 종료 코드가 0이 아니면 검증되지 않은 고영향 가설이 남아 있다는 의미이므로, 자동화에 직접 연결할 수 있습니다: 통과되지 않으면 결론을 내리지 않음
5.4 검증 수단은 비용 기준으로 정렬 (처음부터 큰돈을 쓰지 마십시오)
1차 데이터 확인 (정책/거래 공고/입찰 가격) → 인터뷰 (고객/공급업체/동종 업계 종사자) → 서면 전제 조건 확보 (의향서/신용장/견적서) → 샘플/파일럿 (최소 실행 가능 범위) → 정식 투자.
6단계 · 결론 및 의사 결정 게이트
세 가지 결론 표현 (단순히 '가능/불가능'만 쓰지 마십시오)
- 가능 (Go): 모든 임계값 통과 → 투자 리듬과 다음 조치 제시
- 조건부 가능 (Conditional Go): 주요 임계값 통과, 차단 항목 존재 → '어느 항목을 보완하면 진행 가능한지' 목록 + 검증 계획 및 일정표
- 불가 (No-Go): 반증된 치명적 가설 / 재무 기준 미달 / 위험 신호 접촉 → '방향 자체가 잘못됨 (Kill)'인지 '조건이 갖추어지지 않음 (Hold)'인지 설명
의사 결정 게이트의 4가지 출력 (출처는 문서 말미 참조): Go (통과) / Kill (중단, 이유를 기록하여 보관) / Hold (보류, 어떤 신호를 기다려 재개할지 명시) / Recycle (방향은 괜찮지만 자료가 부족하여 반려 후 보완 필요).
실무 팁: '명확하지 않은' 대부분의 프로젝트에서 정답은 Hold 또는 Recycle이지, 억지로 Go를 하는 것이 아닙니다.
결론 페이지에는 반드시 포함되어야 할 내용: 총괄 판단 + 각 차원 점수표 + 차단 항목 및 치명적 가설 상태 + 증거 등급 설명 + 다음 단계에서 검증해야 할 사항 (담당자, 시기, 판정 기준).
配套: templates/의사-결정-게이트-목록.md (6가지 기준 + 임계값 표 + 4가지 결정)
10대 타당성 모듈 (보고서 작성 시 필요에 따라 선택, 억지로 맞추지 마십시오)
| # | 모듈 | 핵심 질문 |
|---|---|---|
| 1 | 집행 요약 | 한 줄 결론 + 3~5가지 핵심 판단 (마지막에 작성) |
| 2 | 프로젝트 개요 | 무엇을 하는가? 목표는? 범위는? |
| 3 | 배경 및 필요성 | 왜 지금 하는가? 안 하면 어떻게 되는가? |
| 4 | 시장 분석 | 시장 규모는? 성장률은? 타겟 고객은? 어떻게 이길 것인가? |
| 5 | 경쟁 및 장벽 | 경쟁자는 누구인가? 우리의 해자는 무엇인가? |
| 6 | 제품/서비스 및 운영 | 어떻게 전달하는가? 팀은 충분한가? |
| 7 | 비즈니스 모델 | 어떻게 수익을 내는가? 수익 구조는? 마진은? |
| 8 | 재무 추정 | 투자 규모는? 언제 회수하는가? IRR/NPV? |
| 9 | 리스크 및 대책 | 가장 큰 3가지 리스크 + 구체적 대책 + 조기 경보 신호 |
| 10 | 결론 및 제안 | 할 것인가/말 것인가/어떻게 할 것인가 + 다음 단계 |
작성 요구사항
- 집행 요약은 마지막에 작성합니다 (결론이 있어야 정확하게 작성할 수 있습니다)
- 모든 숫자에는 출처를 표시하거나 '가정, 검증 필요'라고 표시합니다
- 재무 부분: 추정 논리 + 핵심 가설을 제시하고, 분 단위로 정확한 숫자를 조작하지 않습니다
- 리스크 장은 구체적으로 작성합니다: 트리거 조건 + 영향 + 대책, 빈말은 쓰지 않습니다
- 불확실한 부분은 명확히 '검증 필요/보충 필요'라고 표시합니다 — 한계를 인정하는 것은 전문성의 표시이지, 결함이 아닙니다
- 가설 대장과 결론 페이지는 본문과 일관성이 있어야 합니다 (같은 숫자가 요약/본문/부록/결론 페이지에서 동일한 값을 가져야 합니다)
- 전달 형태는 사용자 요구에 따릅니다 (Word/Markdown/PPT/온라인 문서), 레이아웃이 표준적이고 AI 느낌이 없어야 합니다 (「」 따옴표 불필요, Markdown 잔여 기호 없음, 단락 규정 준수)
출력 구조 권장
- 표지 (제목/버전/날짜/기밀 등급)
- 집행 요약 (1페이지 이내): 총괄 판단 + 임계값 표 + 핵심 가설 상태 + 다음 단계
- 본문 (10대 모듈에서 필요한 장 절단)
- 부록: 데이터 출처 표 (증거 등급 포함), 핵심 가설 대장, 미해결 검증 목록 (담당자/시기/판정 기준)
품질 자체 점검 목록 (전달 전)
- 검색 없이 작성된 시장 숫자가 있습니까?
- 핵심 데이터에 ≥2개의 독립적인 출처가 있습니까? 증거 등급이 표시되었습니까?
- '통과 기준'이 작성 전에 명확히 정의되었으며, 결론이 하나하나 대응됩니까?
- 결론과 증거가 일치합니까? 과도한 추론이 있습니까 (상관관계를 인과관계로, 부분을 전체로 간주)?
- 반대 의견/실패 리스크가 누락되었습니까? 사전 실패 분석을 수행했습니까?
- 핵심 가설에 모두 상태 (검증됨/미검증/반증됨)가 있습니까? 검증되지 않은 고영향 가설이 차단 항목으로 명확히 표시되었습니까?
- 재무: 3개 시나리오가 모두 준비되었습니까? 4대 표 (투자/비용/수익/지표)가 일관성이 있습니까?
- 독자 관점: 독자가 읽고 의사 결정을 내릴 수 있습니까?
- '고객의 가정'을 '확인된 사실'로 본문에 작성하지 않았습니까?
흔한 오용 및 함정
| 함정 | 결과 | 수정 |
|---|---|---|
| 결론을 먼저 내놓고 증거를 찾음 | 타당성 조사가 변론으로 변질 | 임계값 및 가설 목록을 타당성 조사 전에 명확히 정의 |
| 업계 보고서의 천장을 자신의 시장 규모로 사용 | 규모를 심각하게 과대 평가 | 하향식 계산 + TAM/SAM/SOM 구분 |
| '더 열심히/더 싸게/서비스 좋음'을 장벽으로 간주 | 프로젝트가 빠르게 따라잡힘 | 구조적 우위로 확인 (규모/네트워크/전환 비용/브랜드/프로세스/자원/독점적 정보) |
| 민감도 분석을 하나의 변수로만 수행 | 가장 취약한 지점을 놓침 | 반드시 2~3개 변수를 동시에 변화시키며 시나리오를 구성 |
| 페이지 수를 깊이로 착각 | 두껍지만 쓸모없는 보고서 | 각 페이지가 판결문의 일부여야 한다는 원칙 고수 |
| '확인되지 않은' 항목을 긍정적 미래형으로 표현 ("예상된다", "계획 중") | 결정권자에게 확실성을 오도 | '확인되지 않음', '추정', '검증 필요'를 솔직히 명시 |
힌트 (숙련자용)
- 가장 빨리 타당성 조사를 마치는 방법은 어떤 문서도 쓰지 않는 것입니다 — 많은 프로젝트에서 '생각하는 과정' 그 자체가 가치입니다. 쉬는 시간이나 회의 전에
python3 scripts/feasibility_scorecard.py --demo를 실행해 보면 가설과 임계값이 얼마나 취약한지 알 수 있습니다. - 가장 좋은 타당성 조사 보고서는 질문을 유발하는 보고서입니다 — '이것을 결정했다'고 생각하게 하는 것이 아니라 '또 다른 중요한 질문을 깨달았다'고 생각하게 하는 것입니다.
- 이 스킬의 종속성은 거의 없습니다: 스크립트는 Python 내장 라이브러리만 사용하며, 무료입니다. 인공지능 에이전트가 없는 팀 구성원도 명령줄 도구로 직접 사용할 수 있습니다:
# 같은 머신의 동료가 공유 폴더에서 실행 python3 scripts/assumption_ledger.py 공유-가설-대장.csv --plan - 파일에는 한글을 포함한 UTF-8 텍스트를 직접 사용할 수 있습니다 — CSV 파일의 열 이름과 데이터는 한글로 작성해도 문제없이 작동합니다.
마지막 조언: 타당성 조사는 예측이 아니라, 미래에 대한 대화입니다. 가장 큰 가치는 '예측 적중'이 아니라, '지금 무엇을 알아야 하는지, 무엇을 모르는지 분명히 하고, 그것을 바탕으로 검증 계획을 세우는 것'에 있습니다. 이 스킬이 그런 대화를 돕기를 바랍니다.