---
id: M13-05
manual_id: M13-05
title: 기술을 고객 가치와 사업 언어로 바꾸기
subtitle: 기능 목록을 근거·지표·경제성·위험·다음 결정이 보이는 1쪽 사업 설명서로 번역하기
audience: 기획자, 초급 PM, 서비스 책임자, 기술 리드, 운영·사업 검토자
estimated: 90분 학습 + 90분 실습
artifacts: ["사업 가치 번역 스튜디오", "12개 value control", "24개 합성 scenario", "4개 narrative mode", "8개 business outcome", "12개 value evidence", "333개 자동 테스트", "57개 계약 감사", "6개 회귀 계약", "1쪽 Business Value Case 템플릿", "사업 가치 언어 용어집 300"]
version: 0.1.0
content_version: 0.1.0
status: pilot
updated: 2026-07-16
---
# 기술을 고객 가치와 사업 언어로 바꾸기
> **한 문장 목표:** `M12·M13 evidence 58개 → audience·customer job·current alternative → verified capability → behavior·workflow·outcome chain → metric contract → TCO·unit economics·commercial hypothesis → risk·assumption·option → 1쪽 사업 설명서 → Value Case Gate → 통합 프로젝트`를 한 trace로 연결합니다.
> **학습·권한 경계:** 이 장의 고객·조직·문제·사용·비용·가격·편익·지표·효과는 모두 합성입니다. `value_case_review_package_ready`는 실제 시장 수요 검증, 고객 효과·ROI·매출 보장, 가격·견적·계약·영업·마케팅·투자·예산·조달·production acceptance·release 승인이 아닙니다. 실제 판단은 고객 조사와 권한 있는 제품·사업·재무·법무·영업·구매·운영 책임자가 수행해야 합니다.
한눈에 보기. 기능 수보다 audience·problem·proof·metric·economics·risk·authority·decision ask가 한쪽에서 추적되는지 봅니다.
## 1. 이 장에서 완성할 것
| 산출물 | 핵심 내용 | 합성 완료 신호 |
|---|---|---|
| Value input | M12·M13 source·scope·authority | 58 linked·orphan0·conflict0 |
| Customer/problem | 5 roles·job·pain·alternative·baseline | role conflict0 |
| Capability/value | 12 claim·proof·change chain | unsupported claim0 |
| Metric/economics | baseline·target·TCO·unit·option | denominator gap0 |
| One-page brief | 8 blocks·3 visuals·decision ask | overflow0 |
| Gate | 24 scenario·12 control·risk/assumption/TBR | 24/24·0/0/2 |
## 2. 그림부터 읽는 5분 지도
| 그림 | 먼저 볼 질문 | 설명할 수 있어야 할 것 |
|---|---|---|
| 01~03 | 기술을 어떤 권한과 방식으로 설명하나 | evidence journey·authority·mode |
| 04~06 | 누구의 어떤 문제가 어떻게 바뀌나 | roles·problem·outcome chain |
| 07~09 | 주장과 숫자를 얼마나 믿을 수 있나 | confidence·adoption·metric contract |
| 10~12 | 가치·비용·가격 가설의 경계는 무엇인가 | attribution·TCO·commercial hypothesis |
| 13~15 | 어떤 대안을 무엇으로 결정하나 | option·one-page·Gate |
## 3. 합성 사례 카드
| 항목 | 합성 값 | 경계 |
|---|---|---|
| Service | 회의 후 실행 기록 서비스의 1쪽 사업 설명서 | 실제 조직·서비스 아님 |
| Source | M12 + M13-01~04 = 58 linked | 실제 고객·계약 자료 아님 |
| Reader | 고객·경영·구매·운영 검토자 | 실제 stakeholder 승인 아님 |
| Baseline | 240분/주·누락28%·cycle3.2일 | 실제 조사 결과 아님 |
| Target | 120분/주·10%·1.5일·6주 | 효과·SLA·ROI 보장 아님 |
| Portfolio | 12 controls·24 scenarios·12 evidence | 사업·투자 승인 아님 |
| Mode | BIZ-C evidence-led candidate | 실제 시장 검증 아님 |
## 4. 안전 경계와 금지선
| 이 실습이 하는 것 | 하지 않는 것 | 실제 상황의 다음 행동 |
|---|---|---|
| 합성 고객·지표·비용으로 번역 연습 | 실제 개인정보·고객·조직 자료 사용 | 승인된 research·privacy procedure 사용 |
| 교육용 Value Case Gate | 시장 수요·고객 효과 검증 | 실제 고객 research와 pilot |
| TCO·unit·price hypothesis | 견적·가격·ROI·계약 승인 | 재무·법무·영업·구매 authority 검토 |
| 공식 source를 원리 참고로 사용 | 자동 준수·인증·재무 조언 | 최신판·범위·전문가 확인 |
| 통합 프로젝트 입력 준비 | 투자·예산·조달·production 승인 | 권한 있는 조직 Gate |
## 5. 1쪽 사업 설명서의 12개 evidence 구조
| 묶음 | 포함 evidence | 독자가 답할 질문 |
|---|---|---|
| Source/reader | EVD-01~02 | 무엇을 누구에게 어떤 권한으로 설명하나 |
| Problem/capability | EVD-03~04 | 무슨 문제와 검증된 능력인가 |
| Change/operation | EVD-05~06 | 어떤 행동 변화와 도입 조건인가 |
| Metric/benefit | EVD-07~08 | 무엇을 어떻게 비교하고 누구에게 가치인가 |
| Economics/commercial | EVD-09~10 | 전체 비용과 지불·구매 가설은 무엇인가 |
| Risk/Gate | EVD-11~12 | 무엇이 불확실하고 어떤 결정을 요청하나 |
## 6. 기술 evidence를 고객·사업 판단 여정으로 바꾸기
그림 1. 기술 사실을 고객 변화 가설·측정·경제성·결정으로 단계별 번역합니다.
> **핵심 원칙:** 기능은 가치의 출발점이며, 중간 변화와 근거가 있어야 판단 가능한 사업 문장이 됩니다.
M12·M13에서 제품·architecture·검수·운영·인수인계 evidence 58개를 만들었습니다. 이제 기술 용어를 줄이는 것이 아니라 누가 어떤 문제를 겪고, 어떤 capability가 행동과 업무를 바꾸며, 무엇을 어느 기간에 측정하고, 비용·위험과 함께 어떤 결정을 요청하는지 연결해야 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Source | 58 linked artifacts | version·owner·orphan0 |
| Customer | user·buyer·payer·job | role·segment·alternative |
| Change | capability→behavior→workflow | adoption condition |
| Value | baseline→target·cost | metric·unit·risk |
| Decision | test·revise·stop | authority·owner·due |
> **흔한 오답:** AI 요약·API·dashboard·권한 기능을 한 문단에 나열하고 생산성이 높아진다고 결론냅니다.
> **고친 예:** 각 capability에 고객 job·행동 변화·운영 조건·metric·evidence·confidence·risk·decision ask를 연결합니다.
**그림을 보며 4단계 연습**
1. 58개 source의 claim 후보를 찾습니다.
2. 첫 독자와 고객 job을 고릅니다.
3. 기술→행동→outcome 사슬을 만듭니다.
4. 지표·경제성·위험·다음 결정을 붙입니다.
## 7. 설명서 준비와 실제 사업 권한을 분리하기
그림 2. 설명서·검토·고객 검증·상업 결정·production은 서로 다른 authority입니다.
> **핵심 원칙:** Evidence는 더 나은 결정 입력이지 고객·가격·계약·투자 승인을 자동으로 만드는 권한이 아닙니다.
합성 사례가 24개 scenario를 통과해도 실제 고객 수요·효과·지불 의사·가격·계약·투자·조달·production 승인은 별도 이해관계자와 절차가 판단합니다. 첫 페이지에 answered question과 unanswered authority를 함께 적으면 학습 결과가 영업 문구나 승인 문서로 오해되는 것을 막을 수 있습니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Brief | 학습용 1쪽 package | author·reviewer |
| Review | 가치 가설 검토 | service/business owner |
| Validate | 실제 고객 조사·pilot | customer research authority |
| Commercial | 가격·계약·투자 | finance·legal·sales authority |
| Release | 조달·production | qualified organizational authority |
> **흔한 오답:** Value Case Gate PASS를 시장 검증과 ROI 승인으로 표현합니다.
> **고친 예:** 교육 Gate·실제 고객 검증·가격/계약·투자/예산·조달/release를 별도 상태와 authority로 기록합니다.
**그림을 보며 4단계 연습**
1. 이 문서가 답하는 질문을 씁니다.
2. 답하지 않는 실제 결정을 나열합니다.
3. 각 결정의 authority와 source를 연결합니다.
4. 과장 가능한 완료 문구를 경계 문장으로 고칩니다.
## 8. 네 가지 사업 설명 방식의 판단 가능성 비교하기
그림 3. 같은 기술이라도 말하기 방식에 따라 근거·비용·위험·결정이 보이는 정도가 달라집니다.
> **핵심 원칙:** 짧게 쓰는 것과 중요한 불확실성을 숨기는 것은 다릅니다.
BIZ-A는 구현 범위를 빠르게 보여 주지만 고객 결과가 없고, BIZ-B는 관심을 끌지만 분모와 source가 없습니다. BIZ-C는 claim·proof·metric·cost·risk·ask를 연결합니다. BIZ-D는 임원용으로 짧지만 좋은 결과만 크게 보이고 운영 조건을 숨길 위험이 있어 별도 trigger로 관리합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| BIZ-A | 기능 나열 | 6/24·blocked |
| BIZ-B | 효과 주장 | 15/24·partial |
| BIZ-C | 근거 기반 value case | 24/24·candidate |
| BIZ-D | 임원용 광택 | risk trigger |
| 선택 | BIZ-C | 실제 사업 승인 아님 |
> **흔한 오답:** 기술 용어를 경영 용어로 바꾸고 큰 개선 수치만 넣으면 사업 설명이 된다고 봅니다.
> **고친 예:** 같은 24개 scenario로 source·role·chain·metric·cost·risk·authority·ask가 살아 있는지 검사합니다.
**그림을 보며 4단계 연습**
1. 현재 문서가 네 mode 중 어디인지 고릅니다.
2. 보이지 않는 role·metric·cost를 표시합니다.
3. 주장마다 evidence와 confidence를 붙입니다.
4. BIZ-C 기준으로 1쪽을 다시 구성합니다.
## 9. 사용자·고객·구매자·운영자·경영 독자를 구분하기
그림 4. 각 역할의 job·가치·걱정·근거·결정권을 따로 적습니다.
> **핵심 원칙:** 서비스를 쓰는 사람과 비용을 부담하고 승인하는 사람은 다를 수 있습니다.
사용자는 작업 시간을 보고, 고객은 outcome을 소유하며, 구매자는 대안을 비교하고, 운영자는 지속 가능성을 확인하며, 경영진은 전략·위험·다음 결정을 봅니다. 모두를 한 persona로 합치면 누구에게 어떤 evidence를 보여 줘야 하는지 사라집니다. 한쪽의 primary reader는 하나로 정하되 다른 역할의 영향도 map에서 유지합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| User | task·friction | behavior evidence |
| Customer | outcome·trust | baseline·target |
| Buyer/payer | option·cost·contract | TCO·commercial hypothesis |
| Operator | adoption·SLO·support | operability proof |
| Executive | strategic fit·risk·ask | option·decision record |
> **흔한 오답:** 사용자 인터뷰 한 건으로 고객·구매자·예산 owner의 요구까지 확인됐다고 봅니다.
> **고친 예:** 역할마다 job·value·concern·evidence·decision right를 분리하고 primary reader 한 역할을 지정합니다.
**그림을 보며 4단계 연습**
1. 다섯 역할의 실제·가상 담당자를 적습니다.
2. 각자의 job과 걱정을 적습니다.
3. 필요 evidence와 결정권을 연결합니다.
4. 첫 페이지의 primary reader를 한 명 정합니다.
## 10. 고객 문제·job·현재 대안·기준선을 한 카드로 만들기
그림 5. ‘협업이 불편하다’를 대상·직무·영향·대안·source가 있는 관찰로 바꿉니다.
> **핵심 원칙:** 문제는 큰 문장이 아니라 경계·현재 대안·비교 기준이 있는 관찰입니다.
합성 사례는 네 팀이 회의 후 담당·기한을 확인하는 데 주 240분을 쓰고 실행 항목 28%를 놓치며 완료 중앙값이 3.2일이라는 baseline을 둡니다. 이 숫자는 실제 고객 조사 결과가 아니라 metric contract를 배우기 위한 신호입니다. 실제 서비스에서는 관찰·인터뷰·workflow data를 교차 확인해야 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Segment | 합성 4팀 | scope·out-of-scope |
| Job | 담당·기한·근거 추적 | context·trigger |
| Pain | 240분/주·누락28% | source·기간 |
| Alternative | 문서·메신저·재확인 | switching cost |
| Evidence | synthetic baseline | confidence·next research |
> **흔한 오답:** 모든 회사는 회의 후속 관리가 어렵다고 일반화합니다.
> **고친 예:** 대상·맥락·job·현재 대안·빈도·심각도·reach·source·confidence·out-of-scope를 한 카드에 둡니다.
**그림을 보며 4단계 연습**
1. 대상 segment와 job을 한 문장으로 씁니다.
2. Pain의 빈도·심각도·reach를 적습니다.
3. 현재 대안과 장단점을 기록합니다.
4. Baseline source·기간·confidence를 붙입니다.
## 11. Capability에서 outcome까지 인과 가설을 한 칸씩 잇기
그림 6. 기능에서 큰 impact로 건너뛰지 않고 여섯 단계와 각 화살표의 가정을 확인합니다.
> **핵심 원칙:** 각 화살표마다 adoption condition·assumption·evidence가 있어야 합니다.
구조화된 실행 기록 capability가 있다고 자동으로 누락이 줄지는 않습니다. 사용자가 회의 중 담당·기한을 확정하고, 팀이 한 흐름에서 확인하며, 운영자가 교육·연계·지원을 제공해야 추적 가능한 output과 outcome이 생깁니다. 이 사슬은 인과의 확정이 아니라 시험할 theory of change입니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Capability | 구조화 capture·role·audit | technical proof |
| Behavior | 담당·기한 즉시 확정 | usage evidence |
| Workflow | 한 흐름에서 확인 | adoption evidence |
| Output | 추적 가능한 실행 항목 | count·quality |
| Outcome/impact | 누락·확인 시간 감소 | metric·counterfactual |
> **흔한 오답:** AI가 회의를 요약하므로 생산성이 50% 오른다고 씁니다.
> **고친 예:** Capability→behavior→workflow→output→outcome→impact를 분리하고 각 연결의 assumption·evidence·owner를 적습니다.
**그림을 보며 4단계 연습**
1. 핵심 capability 하나를 고릅니다.
2. 사용자 행동과 업무 흐름 변화를 적습니다.
3. Output·outcome·impact를 나눕니다.
4. 각 화살표의 가정과 반증 신호를 붙입니다.
## 12. 주장의 evidence confidence를 계단으로 표시하기
그림 7. 미확인·가정·관찰·시험·검증을 구분해 말투와 결정 범위를 조절합니다.
> **핵심 원칙:** Confidence는 자신감 있는 문체가 아니라 source·방법·독립성·최신성의 결과입니다.
같은 문서에 verified build evidence와 가정한 willingness to pay가 함께 있을 수 있습니다. 둘을 모두 확정형으로 쓰면 기술 근거의 신뢰까지 손상됩니다. Claim마다 source·method·confidence·constraint·freshness·next evidence를 붙이고 반증 자료를 적극 찾습니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Unknown | 근거 없음 | TBR·question |
| Assumed | 전제·추정 | disconfirming signal |
| Observed | 관찰·baseline | source·period |
| Tested | synthetic/pilot result | method·sample |
| Verified | 독립 evidence | owner·version·review |
> **흔한 오답:** 기술 test PASS와 고객 지불 의사를 같은 ‘검증 완료’로 표시합니다.
> **고친 예:** Claim ID별 evidence level과 confidence·constraint·next evidence를 표시하고 문장 강도를 맞춥니다.
**그림을 보며 4단계 연습**
1. 12개 claim을 나열합니다.
2. 각 claim의 현재 level을 고릅니다.
3. Source·method·freshness를 기록합니다.
4. 한 단계 높일 next evidence를 정합니다.
## 13. 도입·운영 조건을 고객 가치의 다리로 놓기
그림 8. 교육·업무 변화·데이터·지원·유지보수를 value chain 안에 넣습니다.
> **핵심 원칙:** 기술이 작동하는 것과 가치가 실제로 발생·지속되는 것은 다른 질문입니다.
정확한 기능도 사용자 onboarding이 어렵거나 process owner가 없고 integration data가 늦으며 support와 maintenance가 끊기면 outcome을 만들지 못합니다. M13-03·04의 조직 readiness와 handover evidence를 사업 설명의 management·operability proof로 다시 사용합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Training | onboarding·role practice | activation |
| Workflow | process owner·change | adoption |
| Data/integration | quality·freshness·owner | service flow |
| Support/SLO | incident·help·recovery | trust |
| Maintenance | patch·capacity·cost·exit | sustained value |
> **흔한 오답:** 기능 test가 통과했으므로 모든 팀이 바로 쓰고 가치가 지속될 것이라 봅니다.
> **고친 예:** Outcome마다 필요한 adoption·operation condition과 source·owner·failure signal을 붙입니다.
**그림을 보며 4단계 연습**
1. 사슬의 enabling condition을 찾습니다.
2. 교육·업무·데이터·지원 조건을 나눕니다.
3. 각 owner와 evidence를 연결합니다.
4. 조건이 없을 때 outcome 변화와 stop signal을 적습니다.
## 14. 기준선·목표·분모·기간이 있는 metric contract 쓰기
그림 9. ‘50% 향상’을 무엇·단위·분모·대상·기간·자료원이 있는 측정 계약으로 바꿉니다.
> **핵심 원칙:** 측정 규칙이 없으면 같은 숫자도 서로 다른 의미가 됩니다.
합성 사례는 확인 시간 `분/팀/주`, 누락률 `누락 항목/전체 실행 항목`, 완료 중앙값 `일/완료 항목`을 여섯 주 동안 네 팀에서 봅니다. Baseline 240분·28%·3.2일과 target 120분·10%·1.5일은 교육용입니다. Guardrail로 오류·지원 부담·품질 저하도 함께 확인합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| What | 확인 시간·누락률·cycle | 정의 |
| Unit/denominator | 분/팀/주·누락/전체 | 분모 gap0 |
| Baseline/target | 240→≤120·28→≤10% | source·confidence |
| Horizon/segment | 6주·합성4팀 | cohort |
| Owner/quality | service owner·data rule | review cadence |
> **흔한 오답:** 생산성 50% 향상을 목표로 잡고 측정 방법은 나중에 정합니다.
> **고친 예:** 지표마다 정의·단위·분모·baseline·target·horizon·segment·source·quality·owner·guardrail을 고정합니다.
**그림을 보며 4단계 연습**
1. Outcome 세 개를 고릅니다.
2. 단위와 분모를 적습니다.
3. Baseline·target·기간·segment를 붙입니다.
4. Source·quality rule·owner·guardrail을 정합니다.
## 15. 편익 귀속과 반사실을 함께 보기
그림 10. 결과 변화가 모두 서비스 때문인지 current alternative와 confounder를 함께 검토합니다.
> **핵심 원칙:** Outcome 변화와 서비스 사용이 함께 보였다고 곧바로 인과관계가 되지는 않습니다.
팀이 새 서비스를 쓰는 동안 교육·관리자 관심·업무량·계절성·인력 변화도 결과에 영향을 줄 수 있습니다. Do-nothing 또는 current alternative와 비교하고 attribution이 어려우면 contribution으로 표현합니다. 화폐화할 수 없는 trust·공정성·안전·접근성 가치도 정량·정성 근거로 남깁니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Alternative | 문서·메신저·수동 확인 | counterfactual |
| Intervention | service+adoption | scope·period |
| Outcome | time·miss·cycle | metric contract |
| Confounder | 교육·업무량·관리 attention | other explanation |
| Benefit | monetary·quantitative·qualitative | recipient·distribution |
> **흔한 오답:** 사용 팀의 시간이 줄었으니 모두 서비스 덕분이고 절감 시간은 곧 현금 수익이라고 계산합니다.
> **고친 예:** 현재 대안·다른 원인·수혜자·편익 유형·귀속 한계와 비화폐 가치를 함께 표현합니다.
**그림을 보며 4단계 연습**
1. 핵심 outcome과 수혜자를 적습니다.
2. Counterfactual과 비교 방법을 정합니다.
3. Confounder 세 개를 찾습니다.
4. Attribution 또는 contribution 문장으로 고칩니다.
## 16. 전 생애 비용과 unit economics 연결하기
그림 11. Build·run·change·support·exit 비용을 의미 있는 업무 단위와 연결합니다.
> **핵심 원칙:** 기술비 절감이 아니라 기술비와 제공 가치가 함께 움직이는지를 봅니다.
Cloud·AI 사용료만 보면 구현·교육·support·변경·license·exit 비용이 사라집니다. TCO 범위를 고정한 뒤 `관련 총비용 ÷ 해결된 실행 항목 수`를 추적합니다. 기술 unit인 request·token은 engineer가 통제하는 신호이고 resolved action은 business outcome과 연결되는 신호입니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Build | 설계·개발·도입 | one-time·amortize |
| Run | cloud·AI·license·인력 | fixed/variable |
| Change/support | 연계·개선·장애·교육 | owner·driver |
| Exit | 반출·전환·폐기 | residue |
| Unit | cost/resolved action | scope·trend·sensitivity |
> **흔한 오답:** API 비용만 사용자 수로 나눠 서비스 수익성이 검증됐다고 말합니다.
> **고친 예:** TCO 포함·제외 범위와 cost driver를 적고 기술 unit과 business unit의 관계를 시간 추세로 봅니다.
**그림을 보며 4단계 연습**
1. 다섯 비용 범위를 inventory합니다.
2. 고정·변동·직접·간접을 나눕니다.
3. Business unit과 technical unit을 고릅니다.
4. 민감도 세 시나리오로 cost/unit을 비교합니다.
## 17. 가격·수익·구매 문장을 상업 가설로 경계 짓기
그림 12. 지불 주체·구매 경로·가격 단위·검증 방법·승인 authority를 분리합니다.
> **핵심 원칙:** 가격은 숫자 한 개가 아니라 payer·unit·package·route·cost·value·authority의 가설입니다.
합성 사례의 가격이나 수익 구조를 적더라도 실제 willingness to pay와 구매 절차는 고객·구매·재무·법무 확인이 필요합니다. 한쪽에는 가설·source·confidence·포함/제외·민감도·next test를 쓰고, 견적·계약·영업·투자 승인이 아님을 명확히 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Payer | 고객 조직·예산 owner | role evidence |
| Route | subscription·contract·procurement | buying journey |
| Metric/package | team·usage·service level | included/excluded |
| Hypothesis | price·revenue·margin | source·confidence |
| Authority/test | finance·legal·sales | interview·pilot·sensitivity |
> **흔한 오답:** 예상 시간 절감액을 가격으로 정하고 고객이 지불할 것이라고 결론냅니다.
> **고친 예:** Payer·route·price metric·package·source·confidence·approval authority·next test를 별도 열로 둡니다.
**그림을 보며 4단계 연습**
1. Payer와 구매 경로를 적습니다.
2. Price metric과 package 범위를 고릅니다.
3. Cost·value와 가정 source를 연결합니다.
4. 승인 authority와 next test를 씁니다.
## 18. 현재 상태와 여러 option의 trade-off 비교하기
그림 13. 선호안 하나가 아니라 현재 상태·최소 변경·구축·구매 대안을 비용·편익·위험으로 비교합니다.
> **핵심 원칙:** 좋은 설명은 결론을 숨기지 않으면서도 다른 선택과 중단 조건을 공정하게 보여 줍니다.
Do-nothing은 무비용이 아니라 현재 pain·risk·예정 변화가 계속되는 대안입니다. Do-minimum은 절차 보완, build는 맞춤 capability, buy·partner는 속도와 공급자 의존을 가집니다. 각 option의 benefit·cost·risk·assumption·constraint·stop signal을 같은 기준으로 비교합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Do nothing | 현재 상태·예정 변화 | baseline risk |
| Do minimum | 절차·도구 최소 보완 | low cost·limited outcome |
| Build | 맞춤 service | fit·delivery risk |
| Buy/partner | 시장 capability | speed·dependency |
| Preferred | 현재 근거의 추천 가설 | review·stop signal |
> **흔한 오답:** 선호 솔루션의 장점만 설명하고 아무것도 하지 않는 비용과 다른 대안은 생략합니다.
> **고친 예:** 동일한 objective·success factor·cost·benefit·risk·affordability·achievability 기준으로 option을 비교합니다.
**그림을 보며 4단계 연습**
1. 네 option을 한 행씩 만듭니다.
2. 공통 success factor를 정합니다.
3. Benefit·cost·risk·assumption을 비교합니다.
4. 선호안과 stop/revise signal을 적습니다.
## 19. 1쪽 사업 설명서의 8개 block 설계하기
그림 14. 긴 보고서를 줄이는 대신 독자의 결정 순서대로 8개 block을 배치합니다.
> **핵심 원칙:** 한쪽은 정보량 제한이 아니라 판단 순서와 시각 위계를 설계하는 제약입니다.
첫 줄은 누구의 어떤 변화와 왜 지금을 말하고, 우측에는 요청할 결정을 둡니다. 중간은 문제·현재 대안, 변화 사슬, 핵심 수치 시각을 보여 줍니다. 하단은 proof·confidence, metric·economics, risk·assumption·next를 둡니다. 상세 계산과 source는 claim ID·evidence ID로 부록에 연결합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Top | one-sentence offer·decision ask | primary message1 |
| Middle | problem·alternative·change | visual story |
| Evidence | claim·proof·confidence | traceability |
| Economics | metric·TCO·unit·option | bounded estimate |
| Bottom | risk·assumption·next | authority·owner·due |
> **흔한 오답:** 긴 사업계획서의 글자 크기를 줄여 한 페이지에 모두 넣습니다.
> **고친 예:** 8개 block·세 핵심 시각·한 primary message를 유지하고 세부 evidence는 ID로 부록에 연결합니다.
**그림을 보며 4단계 연습**
1. Primary reader의 첫 질문을 씁니다.
2. 8개 block에 내용을 한 줄씩 배치합니다.
3. 세 시각과 한 primary message를 정합니다.
4. Overflow·jargon·unsupported claim을 제거합니다.
## 20. Value Case Gate를 닫고 통합 프로젝트로 넘기기
그림 15. 24개 scenario·12개 control·8개 block을 통과하고 다음 실험과 authority를 남깁니다.
> **핵심 원칙:** Gate는 문장의 매력보다 claim·evidence·metric·cost·risk·authority·ask가 판단 가능한지 봅니다.
최종 합성안은 24/24 scenario, 12/12 control, 네 lane과 12 coverage domain 100%, role conflict·unsupported claim·denominator gap·critical risk·critical assumption·one-page overflow 0, TBR 2를 요구합니다. PASS 뒤에는 실제 고객과 작은 실험으로 중요한 가정을 확인해야 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Audience/problem | 5 roles·baseline·alternative | conflict0 |
| Proof | 12 claims·12 evidence | unsupported0·confidence94% |
| Metric/economics | denominator·TCO·unit·option | gap0 |
| Risk/page | critical0·TBR2·overflow0 | owner·due |
| Decision/handoff | test·revise·stop | integration project input |
> **흔한 오답:** value_case_review_package_ready를 실제 고객 효과와 투자 승인으로 사용합니다.
> **고친 예:** 교육 Gate·잔여 TBR·authority boundary·one-page brief·claim crosswalk·next experiment·통합 project handoff를 함께 남깁니다.
**그림을 보며 4단계 연습**
1. 세 variant를 실행합니다.
2. Fixed·regressed·claim·denominator·risk를 비교합니다.
3. 8개 block과 authority boundary를 확인합니다.
4. 다음 실험과 통합 프로젝트 input을 작성합니다.
## 21. 12개 Business Value Control
| ID | 통제 | 최소 evidence |
|---|---|---|
| CTRL-01 | Source·scope·authority handoff | Value case input manifest |
| CTRL-02 | Audience·customer·buyer·user map | Audience and decision map |
| CTRL-03 | Problem·job·current alternative evidence | Problem and current-state evidence |
| CTRL-04 | Capability·quality·proof inventory | Verified capability inventory |
| CTRL-05 | Capability-to-outcome chain | Capability-to-outcome crosswalk |
| CTRL-06 | Adoption·operation·service condition | Adoption and operability proof |
| CTRL-07 | Metric·baseline·target·horizon | Outcome measurement plan |
| CTRL-08 | Benefit·attribution·counterfactual | Benefit and attribution logic |
| CTRL-09 | Cost·TCO·unit economics | Cost and unit-economics hypothesis |
| CTRL-10 | Price·revenue·commercial hypothesis | Commercial hypothesis record |
| CTRL-11 | Risk·assumption·constraint·option | Risk assumption and option register |
| CTRL-12 | One-page narrative·Value Case Gate | One-page value case and Gate |
## 22. 24개 합성 시나리오 포트폴리오
| ID | Lane | 시나리오 | 위험 | Source → Evidence | Controls |
|---|---|---|---|---|---|
| SC-01 | customer-problem-audience | M12·M13 58개 source를 value case input으로 연결 | decision-authority-overreach | product architecture delivery handover package → value case input manifest | CTRL-01 |
| SC-02 | customer-problem-audience | 학습 Gate와 실제 고객·가격·계약·투자 권한 분리 | decision-authority-overreach | value case question → authority boundary | CTRL-01, CTRL-12 |
| SC-03 | customer-problem-audience | 사용자·고객·구매자·운영·경영 독자 구분 | audience-role-confusion | stakeholder evidence → audience map | CTRL-02 |
| SC-04 | customer-problem-audience | 대상 segment와 job·pain·gain 경계 | audience-role-confusion | synthetic target team → customer profile | CTRL-02, CTRL-03 |
| SC-05 | customer-problem-audience | 현재 대안과 문제 기준선 수치 확인 | problem-evidence-gap | current follow-up workflow → problem evidence | CTRL-03 |
| SC-06 | customer-problem-audience | 문제 claim을 관찰·추정·미확인으로 분리 | problem-evidence-gap | problem statements → claim register | CTRL-03, CTRL-11 |
| SC-07 | capability-outcome-proof | 기능·품질·운영 capability를 evidence로 검증 | feature-value-leap | 58 linked artifacts → capability inventory | CTRL-04 |
| SC-08 | capability-outcome-proof | 기능에서 사용자 행동 변화까지 연결 | feature-value-leap | structured capture capability → behavior change | CTRL-04, CTRL-05 |
| SC-09 | capability-outcome-proof | Output·outcome·impact를 서로 구분 | feature-value-leap | workflow output → outcome chain | CTRL-05, CTRL-08 |
| SC-10 | capability-outcome-proof | 도입·교육·업무 변화 조건 명시 | feature-value-leap | target operating workflow → adoption plan | CTRL-05, CTRL-06 |
| SC-11 | capability-outcome-proof | 연계·데이터·지원·SLO 운영 가능성 연결 | decision-authority-overreach | M13 readiness and handover evidence → operability proof | CTRL-06 |
| SC-12 | capability-outcome-proof | Claim마다 proof·confidence·constraint·next evidence 연결 | feature-value-leap | business claims → claim evidence crosswalk | CTRL-04, CTRL-05, CTRL-12 |
| SC-13 | economics-metrics-risk | 지표의 단위·분모·segment·owner 정의 | metric-denominator-gap | desired outcomes → metric dictionary | CTRL-07 |
| SC-14 | economics-metrics-risk | 기준선·목표·기간·자료원·검토 주기 연결 | metric-denominator-gap | baseline and target → measurement plan | CTRL-07 |
| SC-15 | economics-metrics-risk | 편익 수혜자·유형·귀속과 반사실 검토 | economics-assumption-blur | outcome hypothesis → benefit logic | CTRL-08 |
| SC-16 | economics-metrics-risk | Build·run·change·support·exit TCO 범위 | economics-assumption-blur | cost evidence → TCO hypothesis | CTRL-09 |
| SC-17 | economics-metrics-risk | 업무 단위와 기술 단위의 unit economics 연결 | metric-denominator-gap | technology usage and outcome data → unit economics | CTRL-07, CTRL-09 |
| SC-18 | economics-metrics-risk | 가격·지불 주체·수익을 가설과 승인으로 분리 | decision-authority-overreach | commercial assumptions → commercial hypothesis | CTRL-10 |
| SC-19 | narrative-decision-handoff | Do-nothing·do-minimum·service·buy option 비교 | economics-assumption-blur | current alternative and proposal → option table | CTRL-08, CTRL-09, CTRL-11 |
| SC-20 | narrative-decision-handoff | 가정·제약·위험·반증 신호와 owner 연결 | economics-assumption-blur | value chain uncertainty → risk assumption register | CTRL-11 |
| SC-21 | narrative-decision-handoff | 한쪽 정보 위계와 8개 핵심 block 구성 | audience-role-confusion | claim evidence package → one-page brief | CTRL-12 |
| SC-22 | narrative-decision-handoff | 전문용어를 고객·사업 언어로 번역 | feature-value-leap | technical terms → plain-language statements | CTRL-04, CTRL-05, CTRL-12 |
| SC-23 | narrative-decision-handoff | 다음 의사결정·실험·중단 조건 요청 | decision-authority-overreach | bounded value hypothesis → decision ask | CTRL-11, CTRL-12 |
| SC-24 | narrative-decision-handoff | Value Case Gate와 통합 프로젝트 handoff | decision-authority-overreach | one-page value case package → Gate and handoff record | CTRL-01, CTRL-07, CTRL-11, CTRL-12 |
네 lane은 각각 6개 scenario를 가집니다: `customer-problem-audience`, `capability-outcome-proof`, `economics-metrics-risk`, `narrative-decision-handoff`.
## 23. 4개 mode·8개 outcome·12개 evidence 한눈표
| ID | Mode | 형태 | 강점 | 위험 | 상태 |
|---|---|---|---|---|---|
| BIZ-A | 기능 나열형 | AI·API·dashboard 기능과 기술 용어 중심 | 구현 범위를 빠르게 훑음 | 누구의 어떤 변화인지와 proof·cost·decision이 없음 | blocked-mode |
| BIZ-B | 효과 주장형 | 시간 절감·생산성 향상 수치를 근거 없이 강조 | 관심을 끄는 문장이 있음 | 분모·기준선·귀속·운영 조건이 없어 검증 불가 | partial-mode |
| BIZ-C | 근거 기반 가치 사례형 | problem→capability→change→metric→economics→risk→ask | claim마다 source·confidence·owner·next evidence가 있음 | 실제 고객·가격·투자·계약 승인은 별도 | synthetic-learning-candidate |
| BIZ-D | 임원용 광택형 | 좋은 outcome만 크게 보이고 운영·비용·불확실성은 각주로 숨김 | 짧고 시각적으로 선명함 | trade-off와 의사결정 조건을 왜곡할 수 있음 | deferred-trigger-mode |
| ID | Outcome | Stimulus | Artifact | Measure |
|---|---|---|---|---|
| OUT-01 | audience decision clarity | one reader opens the brief | audience·job·decision map | 5 roles mapped; authority conflict0; primary reader1 |
| OUT-02 | problem evidence | describes current follow-up work | job·pain·gain·alternative | 240 min/week; missed action28%; median3.2d; source and confidence present |
| OUT-03 | capability proof | a value claim cites a capability | feature·quality·operations proof | 12/12 claim evidence linked; unsupported claim0 |
| OUT-04 | behavior and workflow change | uses structured action capture | capability-to-outcome chain | five chain links; adoption owner present; alternative explanation present |
| OUT-05 | outcome measurement | reviews a six-week pilot hypothesis | metric contract | follow-up≤120 min/week; missed≤10%; median≤1.5d; denominator gaps0 |
| OUT-06 | operability and trust | checks delivery feasibility | adoption·support·SLO·risk | operability evidence12/12; critical risk0; TBR≤2 |
| OUT-07 | economics and options | compares do-minimum, service and buy options | TCO·unit cost·benefit·sensitivity | 3 options; full cost scope; cost per resolved action; sensitivity3; guarantee0 |
| OUT-08 | decision readiness | reads the final ask | one-page brief·claim crosswalk·next test | 24/24; 8/8 blocks; one-page overflow0; authority boundary present |
| ID | Evidence | 최소 proof |
|---|---|---|
| EVD-01 | Value case input manifest | M12·M13 58 linked·version·owner·orphan0·conflict0 |
| EVD-02 | Audience and decision map | user·customer·buyer·operator·executive job·value·concern·authority |
| EVD-03 | Problem and current-state evidence | segment·job·pain·gain·baseline·current alternative·source·confidence |
| EVD-04 | Verified capability inventory | feature·quality·architecture·test·security·operations proof·constraint |
| EVD-05 | Capability-to-outcome crosswalk | capability→behavior→workflow→output→outcome→impact·assumption |
| EVD-06 | Adoption and operability proof | training·workflow change·integration·support·SLO·owner·maintenance |
| EVD-07 | Outcome measurement plan | metric·unit·denominator·baseline·target·horizon·segment·source·owner |
| EVD-08 | Benefit and attribution logic | beneficiary·monetary/quantitative/qualitative·counterfactual·confounder |
| EVD-09 | Cost and unit-economics hypothesis | build·run·change·support·exit·cost per resolved action·sensitivity |
| EVD-10 | Commercial hypothesis record | payer·buying route·price/revenue hypothesis·approval authority·test |
| EVD-11 | Risk assumption and option register | risk·assumption·constraint·disconfirming signal·option·owner·due |
| EVD-12 | One-page value case and Gate | 8 blocks·claim ID·evidence ID·confidence·decision ask·next experiment |
## 24. 실습 스튜디오: 세 business narrative version 실행
실습은 loopback-only·standard-library-only이며 실제 고객·개인정보·가격·계약·production resource·외부 network를 사용하지 않습니다. 같은 24 scenario에서 기능 나열, 효과 주장, evidence-led value case의 expected/actual 차이를 비교합니다.
실습 화면 1. Candidate는 24/24, evidence12, outcome8, confidence94%, claim/denominator/risk/TBR 0/0/0/2를 표시합니다.실습 화면 2. Baseline은 6/24, evidence3, outcome2, unsupported claim9·denominator gap6·risk5·TBR8을 드러냅니다.실습 화면 3. 중간안은 15/24이며 metric·benefit attribution·TCO·unit economics·commercial hypothesis·risk·Gate가 덜 닫혔습니다.실습 화면 4. Baseline·target·horizon·source·quality rule을 나란히 비교합니다.실습 화면 5. 모바일에서도 실제 고객 효과·ROI·가격·계약·투자 승인이 아님을 먼저 확인합니다.실습 화면 6. 1쪽 정보 위계·plain language·decision ask·Gate 시나리오를 좁은 화면에서도 확인합니다.
| Version | Pass | Fail | 주요 상태 | 판정 |
|---|---|---|---|---|
| feature-dump-v1 | 6 | 18 | evidence3·outcome2·confidence34%·claim9·denom6·risk5·TBR8 | blocked_feature_dump_without_customer_value |
| claim-only-v2 | 15 | 9 | evidence8·outcome6·confidence70%·claim3·denom3·risk2·TBR4 | blocked_unproven_business_claims |
| evidence-led-value-case-v3 | 24 | 0 | evidence12·outcome8·confidence94%·claim0·denom0·risk0·TBR2 | value_case_review_package_ready |
## 25. 90분 실습 워크북
| 시간 | 행동 | 남길 evidence | 통과 질문 |
|---|---|---|---|
| 0~10분 | 58 source·scope·authority | input manifest | 교육 Gate와 실제 사업 권한을 구분했나 |
| 10~20분 | Audience·customer job·alternative | role/problem map | user·buyer·payer가 구분됐나 |
| 20~30분 | Problem baseline·claim register | problem evidence | source·confidence·반증 신호가 있나 |
| 30~40분 | Capability·proof inventory | verified capability | unsupported claim이 보이나 |
| 40~50분 | Behavior·workflow·outcome chain | crosswalk | causal leap와 adoption condition을 확인했나 |
| 50~60분 | Metric contract·guardrail | measurement plan | unit·denominator·기간·owner가 있나 |
| 60~70분 | Benefit·counterfactual·TCO | attribution/cost record | 다른 원인과 전 생애 비용을 봤나 |
| 70~80분 | Unit·commercial·option·risk | economics/risk register | 가설과 승인을 분리했나 |
| 80~90분 | 8-block one-page·Gate·handoff | brief/decision record | 24/24·overflow0·next test가 보이나 |
```text
Primary reader + decision question + authority boundary:
Customer/user/buyer/payer/operator map:
Segment + job + pain/gain + current alternative + baseline:
Claim IDs + source + evidence + confidence + constraint:
Verified capability → behavior → workflow → output → outcome → impact:
Adoption/operation conditions + owner + failure signal:
Metric + unit + denominator + baseline + target + horizon + source:
Benefit recipient + counterfactual + confounder + attribution limit:
Build/run/change/support/exit TCO + business/technical unit:
Payer + route + price/revenue hypothesis + approval authority:
Options + risk + assumption + constraint + stop/revise signal:
8-block brief + decision ask + next experiment + handoff:
```
## 26. 1쪽 Business Value Case 템플릿
별도 템플릿 `03_Templates/T13-05_one-page-business-value-case.md`를 사용합니다. 15개 section은 metadata/authority·source/claim manifest·audience/decision map·problem/job/alternative·capability proof·outcome chain·adoption/operation·metric contract·benefit/attribution·TCO/unit economics·commercial hypothesis·option appraisal·risk/assumption·one-page brief·Value Case Gate/통합 프로젝트 handoff입니다.
| 템플릿 영역 | 먼저 채울 최소 열 | 빈칸 처리 |
|---|---|---|
| Audience/problem | role·job·alternative·baseline | 미확인은 TBR+source plan |
| Claim/proof | claim ID·evidence ID·confidence | unsupported는 Gate fail |
| Metric/economics | unit·denominator·cost scope·option | 추정은 assumption 표시 |
| Risk/commercial | authority·stop signal·owner | 가격·ROI 승인 문구 금지 |
| One-page/Gate | 8 block·ask·next experiment | overflow·critical gap은 block |
## 27. 공식 자료와 적용 경계
> 아래 자료는 고객 가치·사업 사례·기술 비용·품질·위험·측정 설계의 **원리 참고용 일차 자료**입니다. 목록에 있다는 이유만으로 특정 고객·조직·가격·투자에 자동 적용되거나 사업성이 검증되는 것은 아닙니다. 확인 기준일은 2026-07-16이며 실제 적용·최신판·재무·법률 판단은 권한 있는 전문가가 재확인해야 합니다.
| 공식 자료 | 이 장에서 확인할 원리 | 적용 경계 |
|---|---|---|
| [Strategyzer Value Proposition Canvas](https://www.strategyzer.com/library/the-value-proposition-canvas) | customer jobs·pains·gains와 products·pain relievers·gain creators | template 사용이 product-market fit이나 실제 수요를 자동 증명하지 않음 |
| [UK Green Book 2026](https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026) | 목표·option의 비용·편익·위험, Five Case Model, monitoring/evaluation | 영국 공공 appraisal guidance; 다른 국가·민간 적용은 context에 맞춤 |
| [Guidance on developing business cases](https://www.gov.uk/government/publications/guidance-on-developing-business-cases) | strategic·economic·commercial·financial·management case의 반복 개발 | 전체 business case를 1쪽으로 대체한다는 뜻 아님 |
| [FinOps Framework](https://www.finops.org/framework/) | 기술 사용의 business value와 timely data-driven decision | framework 사용이 비용 최적화·수익을 자동 보장하지 않음 |
| [FinOps Quantify Business Value](https://www.finops.org/framework/domains/quantify-business-value/) | usage·cost를 stakeholder value·baseline·budget·forecast·KPI와 연결 | metric 정의와 business data quality는 조직이 검증 |
| [FinOps Unit Economics](https://www.finops.org/framework/capabilities/unit-economics/) | resource efficiency unit과 business unit metric 연결 | 서로 다른 제품을 억지로 단일 unit으로 비교하지 않음 |
| [U.S. SBA Write your business plan](https://www.sba.gov/business-guide/plan-your-business/write-your-business-plan) | lean format의 value proposition·customer·infrastructure·finance | 미국 중소기업 안내; 투자·대출·사업성 승인 아님 |
| [ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html) | ICT product quality의 9개 characteristics를 specification·measurement·evaluation에 사용 | 품질 model이 고객 가치·시장 수요를 자동 증명하지 않음 |
| [NIST CSF 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) | cybersecurity high-level outcome을 risk·priority·communication에 사용 | 구현 방법·인증·위험 수용을 자동 결정하지 않음 |
| [OECD Good Practice Principles for Public Service Design](https://www.oecd.org/en/publications/oecd-good-practice-principles-for-public-service-design-and-delivery-in-the-digital-age_2ade500b-en.html) | user need·impact·scale·accountability·transparency 중심 공공 서비스 | 각 국가 제도·서비스 context와 실제 시민 research 필요 |
| [Digital.gov Success metrics](https://digital.gov/guides/research-collaboration/testing/metrics) | outcome·정량/정성 metric·수집 방법·owner·benchmark·iteration | 미국 정부 design guidance; metric이 인과관계를 자동 증명하지 않음 |
| [소프트웨어 진흥법](https://law.go.kr/LSW/lsInfoP.do?ancYnChk=0&lsId=000751) | 한국 software 산업·사업·적정 대가·공공 사업 제도 맥락 | 적용 조문·시행일·사업 범위와 최신판을 별도 확인 |
| [KDI 공공투자관리센터 연구자료](https://pimac.kdi.re.kr/study/study_list.jsp?classcd=F2&pageNo=5&showListSize=10) | 기초자료·비용·편익·경제성·정책성·위험·종합평가의 구조 | 개별 공공투자 조사 방법을 일반 software 사업에 자동 적용하지 않음 |
## 28. 셀프 테스트 30
### 1. 기능과 고객 가치의 차이는 무엇인가요?
정답 보기
정답: 기능은 제품이 할 수 있는 일이고 고객 가치는 그 기능이 특정 고객의 행동·업무·결과를 의미 있게 바꾼 정도입니다. 기능에서 가치로 가는 중간 조건과 evidence를 확인해야 합니다.
### 2. value_case_review_package_ready가 뜻하지 않는 것을 세 가지 쓰세요.
정답 보기
정답: 실제 시장 수요 검증, 고객 효과·ROI·매출 보장, 가격·계약·투자·예산·조달·production 승인을 뜻하지 않습니다.
### 3. 합성 사례가 인수하는 이전 artifact는 몇 개인가요?
정답 보기
정답: M12와 M13-01~04에서 이어진 58개 linked artifact이며 orphan과 conflict는 각각 0입니다.
### 4. 사용자·고객·구매자·지불 주체를 구분하는 이유는 무엇인가요?
정답 보기
정답: 서비스를 쓰는 사람, 결과를 소유하는 사람, 구매를 평가하는 사람, 비용을 부담하는 사람이 다를 수 있고 각자 원하는 가치·근거·권한이 다르기 때문입니다.
### 5. Primary reader는 왜 한 명 또는 한 역할로 정하나요?
정답 보기
정답: 첫 페이지가 먼저 답할 질문과 정보 위계를 명확히 하기 위해서입니다. 다른 이해관계자의 영향은 별도 map과 근거에서 유지합니다.
### 6. 좋은 문제 문장에 필요한 다섯 요소는 무엇인가요?
정답 보기
정답: 대상 segment, 수행하려는 job, 맥락, 현재 pain·영향, current alternative와 baseline evidence가 필요합니다.
### 7. 현재 대안을 반드시 적는 이유는 무엇인가요?
정답 보기
정답: 고객은 아무것도 하지 않는 상태가 아니라 이미 쓰는 방법과 비교하며, 제안의 추가 가치·전환 비용·반사실을 판단해야 하기 때문입니다.
정답: 줄일 불확실성, 대상·기간·방법, metric baseline·target, success/failure/stop signal, owner·due, 개인정보·보안·권한 경계가 있어야 합니다.
### 30. 통합 프로젝트에 넘기는 핵심은 무엇인가요?
정답 보기
정답: 1쪽 사업 설명서, claim-evidence crosswalk, metric contract, cost·unit economics 가설, risk·assumption·option register, decision record와 다음 실험입니다.
## 29. 용어집 300 학습 순서
`04_Glossary/GLOSSARY_business_value_language.md`에는 15개 묶음·300개 unique term이 있습니다. 기술을 사업 언어로 번역하는 순서에 맞춰 역할→문제→근거→capability→변화→도입→지표→편익→비용→unit economics→상업 가설→business case→risk→one-page→decision으로 배열했습니다.
| 묶음 | 핵심 질문 |
|---|---|
| 01~03 | 누구에게 어떤 문제·근거를 설명하는가 |
| 04~06 | 무슨 capability가 어떤 변화와 운영 조건을 갖는가 |
| 07~10 | 무엇을 측정하고 편익·비용·unit을 어떻게 해석하는가 |
| 11~13 | 가격·option·위험·가정을 어떻게 경계 짓는가 |
| 14~15 | 한쪽에서 어떤 결정을 요청하고 기록하는가 |
## 30. 다음 단계 · 통합 프로젝트에서 사업 가설 검증하기
M13-05는 전체 교육과정의 47번째 매뉴얼이자 본 curriculum 표의 마지막 개별 매뉴얼입니다. 다음은 업무관리 웹 서비스·AI 문서 검토 서비스·공공 민원 지원 서비스 중 하나를 골라 product·architecture·AI·test·security·deployment·operations·business evidence를 한 통합 프로젝트로 연결하는 단계입니다.
```text
M12 problem·requirement·MVP·document package
→ M13 architecture·vendor·organization·handover evidence
→ M13-05 audience·problem·capability·outcome·metric·economics·risk
→ one-page business value case + claim/evidence crosswalk
→ bounded customer research or synthetic pilot plan
→ integrated service build·evaluate·operate·learn
```
| M13-05 output | 통합 프로젝트에서 할 일 | 권한 경계 |
|---|---|---|
| One-page brief | 첫 project review의 decision input | 투자·사업 승인 아님 |
| Claim/evidence crosswalk | 구현·시험·운영 evidence 갱신 | 고객 효과는 별도 research |
| Metric contract | baseline·target·guardrail 수집 설계 | 개인정보·자료 품질 승인 필요 |
| Cost/unit hypothesis | 실제 사용·비용으로 민감도 갱신 | 가격·ROI 승인 아님 |
| Risk/options | test·revise·stop decision record | 권한 있는 owner가 결정 |
> **마지막 확인:** 좋은 사업 설명은 기술을 숨기지 않습니다. 기술 evidence가 누구의 어떤 변화와 연결되는지, 무엇이 확인됐고 무엇이 가정인지, 비용과 위험은 어디에 있으며, 다음에 무엇을 누가 확인할지를 한눈에 보이게 합니다.
---
## 배포본 안내
- 매뉴얼 ID: `M13-05`
- 콘텐츠 버전: `v0.1.0`
- [인쇄용 PDF](../M13-05/M13-05_translate-technology-into-customer-value-and-business-language_v0.1.0.pdf)
- 그림·실습·템플릿·용어집 링크는 이 프로젝트 폴더 구조를 기준으로 합니다.
