---
title: "외주 개발사를 선정하고 결과 검수하기"
slug: "select-outsourcing-vendor-and-inspect-delivery"
manual_id: "M13-02"
module_id: "G13"
track: ["software-acquisition", "sourcing", "rfp", "proposal-evaluation", "procurement-integrity", "vendor-due-diligence", "software-supply-chain", "commercial-model", "acceptance-testing", "delivery-inspection", "defect-management", "handover", "exit-planning"]
level: 3
summary: "M12-04의 제품·요구·문서 package와 M13-01의 architecture candidate를 공통 RFP·SOW·평가 rubric으로 바꾸고, 네 합성 proposal을 fairness·due diligence·security/privacy·IP/OSS·commercial evidence로 비교한 뒤 12개 delivery artifact와 8개 acceptance scenario를 재현 검수해 Vendor Evidence Gate와 M13-03 handoff를 만듭니다."
estimated_minutes: 300
prerequisites: ["M13-01 규모와 위험에 맞는 아키텍처 선택하기", "M12-04 PRD·화면·API·데이터 문서 연결하기", "M10-04 출시 전 전체 보안 체크리스트", "M11-03 로그·모니터링·백업·장애 대응", "M11-04 클라우드·AI 비용과 라이선스"]
outcomes: ["software acquisition과 purchasing 구분", "insource·buy·outsource·hybrid delivery model", "RFI·RFP·RFQ·SOW 목적과 version", "source→RFP→rubric→acceptance trace", "mandatory·optional·assumption·exception", "COI·역할 분리·공통 Q&A", "proposal compliance normalization", "4개 합성 proposal evidence 비교", "supplier provenance·resilience·cyber·tiers·reference due diligence", "key personnel·replacement·subcontractor", "secure by demand·SSDF·SBOM", "개인정보 위탁·IP·OSS·incident schedule", "fixed·T&M·hybrid·TCO·change control", "evidence-weighted rubric·confidence·sensitivity", "8개 acceptance scenario", "12개 delivery artifact 재현 검수", "defect severity·remediation·retest·waiver", "migration·operations·handover·exit", "24 scenario·12 control Vendor Evidence Gate", "M13-03 통합 문서 handoff"]
artifacts: ["외주 선정·납품 검수 스튜디오", "12개 발주·검수 통제", "24개 합성 시나리오", "3개 sourcing version", "4개 합성 proposal", "8개 acceptance scenario", "12개 delivery artifact", "333개 자동 테스트", "57개 계약 감사", "6개 회귀 계약", "제안요청·평가·납품검수 템플릿", "외주 선정·납품 검수 용어집 300"]
version: 0.1.0
status: pilot
updated: 2026-07-16
---
# 외주 개발사를 선정하고 결과 검수하기
> **한 문장 목표:** `M12·M13-01 source → delivery model·scope → common RFP/SOW → fair evaluation·due diligence → evidence-weighted proposal comparison → 8 acceptance scenarios·12 delivery artifacts → defect·handover → Vendor Evidence Gate → M13-03`을 한 trace로 연결합니다.
> **학습·법률 경계:** 이 장의 업체·인력·제안·가격 지수·일정·계약 조건은 모두 합성입니다. `vendor_evidence_package_ready`는 실제 업체 추천·선정·award·계약·법률 의견·예산·지출·개인정보 위탁 승인·납품 인수·지급·보안 인증·pilot·release가 아닙니다. 공공조달·계약·개인정보·IP 적용은 관할 법령과 조직 policy에 맞는 전문가 검토가 필요합니다.
한눈에 보기. 저가·demo 6/24에서 evidence 24/24로 개선하고 COI·critical risk·defect·TBR·handoff를 닫습니다.
## 1. 이 장에서 완성할 것
| 산출물 | 핵심 내용 | 합성 완료 신호 |
|---|---|---|
| Sourcing input | M12-04·M13-01 source·scope·risk | 26 linked·orphan0·conflict0 |
| Request package | RFI/RFP/RFQ/SOW·deliverable | same baseline·versioned Q&A |
| Evaluation package | mandatory·rubric·COI·due diligence | 4 proposal·COI0 |
| Acceptance package | 8 scenario·12 artifact·trace | 100% coverage |
| Inspection package | defect·retest·waiver·handover | critical defect0·TBR2 |
| M13-03 handoff | selection·acceptance evidence | not award·not acceptance |
## 2. 그림부터 읽는 5분 지도
| 그림 묶음 | 먼저 볼 질문 | 설명할 수 있어야 할 것 |
|---|---|---|
| 01~03 | 무엇을 왜 어떤 책임으로 외부에 맡기나 | evidence flow·authority·delivery model |
| 04~06 | 같은 요청과 후보를 어떻게 만드나 | RFI/RFP/RFQ/SOW·trace·4 proposals |
| 07~10 | 공정성과 공급망·권리 위험을 어떻게 확인하나 | COI·compliance·due diligence·assurance |
| 11~12 | 가격과 점수를 어떻게 과신하지 않나 | TCO·change·confidence·sensitivity |
| 13~15 | 결과를 어떻게 재현하고 인계하나 | acceptance·delivery·defect·Gate·handoff |
## 3. 합성 사례 카드
| 항목 | 합성 값 | 경계 |
|---|---|---|
| Source | M12-04 21 + M13-01 5 = 26 linked | real tender document 아님 |
| Architecture | OPT-B candidate | production architecture approval 아님 |
| Proposal | PROP-A~D | real company·recommendation 아님 |
| Price | index 70·88·95·125 | quote·budget·tax 아님 |
| Delivery | 14주 signal·4 milestones | contract schedule 아님 |
| Quality | p95 800ms·RTO4h·RPO1h | SLA·guarantee 아님 |
| Inspection | 8 acceptance·12 artifact | actual acceptance 아님 |
| Decision | PROP-B learning candidate | selection·award·payment 아님 |
## 4. 선정과 검수를 하나의 evidence 흐름으로 잇기
그림 1. 같은 요구 ID가 공통 요청·공정 비교·재현형 인수·인계까지 이동합니다.
> **핵심 원칙:** 외주 선정은 제안서 심사로 끝나지 않고 납품 결과의 재현 가능한 인수까지 설계해야 합니다.
제안 때는 좋았던 문장이 SOW·acceptance·handover에서 사라지면 발주 측은 완료를 객관적으로 판단할 수 없습니다. 합성 사례는 M12-04의 21개 문서와 M13-01의 context·quality scenario·ADR·Gate 5개를 합친 26개 source에서 출발합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Source | 26 linked artifacts | version·owner·status |
| Request | common RFP·SOW | same baseline |
| Evaluate | 4 proposals | claim→evidence |
| Inspect | 12 artifacts·8 acceptance | reproduce·retest |
| Handover | exit·M13-03 | independent operation |
> **흔한 오답:** 친분 있는 업체에 화면 목록과 예산만 보내고 demo가 좋아 보이는 제안을 선택합니다.
> **고친 예:** Goal·architecture·quality·acceptance·evidence format을 같은 package로 제공하고, proposal claim을 납품 acceptance ID까지 추적합니다.
**그림을 보며 4단계 연습**
1. Source ID와 version을 씁니다.
2. RFP requirement와 evaluation criterion을 연결합니다.
3. Acceptance와 delivery evidence를 붙입니다.
4. Handover destination과 authority를 적습니다.
## 5. Evidence package와 실제 권한 경계 구분하기
그림 2. 준비 상태·협상·award·acceptance·payment는 서로 다른 evidence와 authority를 가집니다.
> **핵심 원칙:** 좋은 평가표도 조직을 계약이나 지급으로 자동 구속하지 않습니다.
Vendor evidence package는 불확실성을 줄이는 검토 산출물입니다. 실제 선정·계약·개인정보 위탁·IP·세금·지출·납품 인수는 관할 법령과 조직 policy, 재무·법무·보안·계약 authority가 별도로 판단해야 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Package | review ready | learning authority |
| Negotiation | TBR·terms | authorized team |
| Award | selection·contract | contract authority |
| Acceptance | defect·waiver | acceptance authority |
| Payment/release | invoice·operation | finance/release authority |
> **흔한 오답:** 평가 점수가 가장 높으므로 업체 선정과 계약이 승인됐다고 기록합니다.
> **고친 예:** Candidate-for-learning-negotiation 상태와 unresolved TBR, 다음 authority·evidence를 header에 명시합니다.
**그림을 보며 4단계 연습**
1. 현재 문서가 답하는 질문을 씁니다.
2. 답하지 않는 decision 다섯 개를 적습니다.
3. 각 decision의 authority를 연결합니다.
4. 오해 가능한 ready 문장을 경계 문장으로 고칩니다.
## 6. 외주가 맞는 delivery model인지 먼저 판단하기
그림 3. Insource·buy·outsource·hybrid를 outcome·capability·control·TCO·exit로 비교합니다.
> **핵심 원칙:** 외주는 해결책이 아니라 여러 delivery model 중 하나입니다.
내부 역량이 없다는 이유만으로 모든 책임을 넘기면 요구·acceptance·운영 지식도 함께 사라집니다. Market product가 충분한데 custom build를 발주하거나, 핵심 rule까지 외주에 잠그면 불필요한 비용과 lock-in이 생깁니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Insource | 지식·통제 | capacity·hiring |
| Buy | 빠른 도입 | fit·license·lock-in |
| Outsource | 맞춤·역량 보완 | acceptance·handover |
| Hybrid | 핵심 내부·전문 외부 | boundary·coordination |
| Retained | product owner·acceptor | 항상 내부 |
> **흔한 오답:** 개발자가 없으므로 요구 정의와 검수도 외주사가 알아서 하게 합니다.
> **고친 예:** 외부가 구현해도 outcome·priority·architecture boundary·acceptance authority는 내부 역할로 유지합니다.
**그림을 보며 4단계 연습**
1. 필요 outcome을 한 문장으로 씁니다.
2. 내부·시장 capability gap을 적습니다.
3. 네 model의 TCO·control·exit를 비교합니다.
4. Retained capability와 owner를 지정합니다.
## 7. RFI·RFP·RFQ·SOW의 질문을 구분하기
그림 4. Unknown을 시장 질문·해결 제안·가격 조건·합의 업무로 차례로 좁힙니다.
> **핵심 원칙:** 문서 이름보다 무엇을 답받고 다음에 무엇을 결정할지가 중요합니다.
RFP에 가격만 쓰면 접근법·인력·risk가 보이지 않고, SOW를 제안서 표현에 맡기면 scope·deliverable·acceptance가 계약 뒤 흔들립니다. Unknown이 큰 영역은 RFI나 market sounding으로 먼저 확인하고, 비교 가능한 범위에서 RFQ를 요청합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| RFI | 시장·역량·대안 | market evidence |
| RFP | 이해·접근·팀 | proposal evidence |
| RFQ | 가격·단가·가정 | commercial evidence |
| SOW | scope·산출물·acceptance | agreement input |
| Addendum | 변경·공통 답 | versioned notice |
> **흔한 오답:** RFP·견적서·계약서를 한 파일로 섞고 어떤 문장이 binding인지 구분하지 않습니다.
> **고친 예:** 각 문서의 목적·version·precedence·authority와 다음 decision을 문서 머리에 씁니다.
**그림을 보며 4단계 연습**
1. 현재 unknown을 분류합니다.
2. RFI에서 확인할 시장 질문을 씁니다.
3. RFP와 RFQ field를 분리합니다.
4. SOW에 남을 binding item을 표시합니다.
## 8. Source 요구를 평가·인수 ID까지 추적하기
그림 5. Source ID가 요청·평가·인수·인계에서 같은 의미와 version을 유지합니다.
> **핵심 원칙:** 평가와 검수는 source requirement의 다른 표현이어야 합니다.
업체는 RFP에 없는 요구를 가격과 일정에 반영하기 어렵고, acceptance에 없는 요구는 납품 뒤 분쟁이 됩니다. 26개 source의 authoritative version과 변경 로그를 두고 REQ→criterion→test→evidence를 연결합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Goal | REQ outcome | rubric understanding |
| Scope | SOW boundary | deliverable |
| ADR | solution constraint | technical approach |
| Quality | AT scenario | test measure |
| Risk/TBR | question·exception | owner·due |
> **흔한 오답:** RFP는 source 문서를 요약했지만 ID와 version이 없어 무엇이 빠졌는지 알 수 없습니다.
> **고친 예:** 모든 P0/P1 requirement에 source·proposal response·implementation·test·result·defect link를 둡니다.
**그림을 보며 4단계 연습**
1. Source 6종의 stable ID를 만듭니다.
2. RFP requirement에 source를 붙입니다.
3. Rubric과 acceptance를 연결합니다.
4. Orphan·conflict·version gap을 확인합니다.
## 9. 네 합성 proposal을 같은 mandatory gate로 비교하기
그림 6. 가격 지수·evidence confidence·mandatory 적격을 분리해 네 제안을 비교합니다.
> **핵심 원칙:** 가격과 발표 인상은 evidence portfolio의 일부이지 적격 위반을 덮는 만능 점수가 아닙니다.
PROP-A는 가격 지수 70이지만 인수·보안·인계 필수 evidence가 부족합니다. PROP-D는 demo가 좋지만 subcontractor·SBOM·data·exit가 불투명합니다. PROP-C는 evidence가 강하지만 현재 규모에 비용·절차가 과할 수 있어 trigger 뒤 재검토합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| PROP-A | price70·confidence45% | mandatory fail |
| PROP-B | price88·confidence94% | learning candidate |
| PROP-C | price125·confidence96% | defer trigger |
| PROP-D | price95·confidence35% | mandatory fail |
| Boundary | synthetic only | not recommendation |
> **흔한 오답:** 가장 싼 A와 가장 화려한 D를 최종 두 후보로 둡니다.
> **고친 예:** Mandatory gate를 먼저 적용하고 evidence confidence·risk·TCO·sensitivity 뒤 협상 후보를 냅니다.
**그림을 보며 4단계 연습**
1. Mandatory requirement를 표시합니다.
2. 네 proposal의 assumption·exception을 씁니다.
3. Claim마다 evidence confidence를 줍니다.
4. 선택·보류·부적격 이유를 기록합니다.
## 10. COI·역할 분리·공통 Q&A로 공정성 만들기
그림 7. 다섯 역할이 독립 검토 후 COI 0·공통 Q&A·고정 rubric으로 합의합니다.
> **핵심 원칙:** 공정성은 선언이 아니라 사전 기준·같은 정보·역할·audit trail의 결과입니다.
기준을 제안서를 본 뒤 바꾸거나 특정 업체에만 해석을 주면 score가 비교 가능한 measurement가 아닙니다. Evaluator는 먼저 독립 평가하고, consensus에서는 강점·약점·risk·evidence 차이를 기록해야 합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Owner | outcome·scope | source authority |
| Tech | architecture·build | technical evidence |
| Security | privacy·supply risk | assurance evidence |
| Commercial | TCO·change | price evidence |
| Acceptor | test·defect·handover | acceptance evidence |
> **흔한 오답:** 대표 한 명이 업체 발표를 듣고 점수를 정한 뒤 다른 평가자가 맞춥니다.
> **고친 예:** COI 선언→독립 평가→common clarification→evidence consensus→authority review 순서를 versioned record로 남깁니다.
**그림을 보며 4단계 연습**
1. 평가 역할과 authority를 나눕니다.
2. COI와 recusal rule을 씁니다.
3. 공통 Q&A log를 만듭니다.
4. Rubric freeze time과 consensus evidence를 남깁니다.
## 11. 제안 문장을 compliance와 evidence로 정규화하기
그림 8. Compliant·partial·noncompliant·exception 상태를 requirement ID별로 나란히 봅니다.
> **핵심 원칙:** ‘지원 가능’은 조건·범위·owner·evidence가 붙기 전까지 PASS가 아닙니다.
제안서는 서로 다른 표현·전제·포함 범위를 사용합니다. 같은 requirement 행에 response, evidence link, assumption, exception, TBR, confidence를 넣어 normalization해야 price와 approach의 실제 차이가 보입니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Compliant | 모든 필수 조건 | direct evidence |
| Partial | 일부·조건부 | gap·change |
| Noncompliant | 필수 미충족 | mandatory fail |
| Exception | 다른 조건 제시 | authority review |
| Unknown | 답·근거 없음 | clarification/TBR |
> **흔한 오답:** 제안서에 ‘가능’이 있으면 전부 100% 충족으로 표시합니다.
> **고친 예:** Requirement 원문과 response를 분리하고, 증거가 없으면 unknown 또는 partial로 두어 clarification합니다.
**그림을 보며 4단계 연습**
1. 요구별 response를 잘라냅니다.
2. 네 상태로 normalization합니다.
3. Assumption·exception·evidence link를 붙입니다.
4. Mandatory gap과 TBR을 Gate로 보냅니다.
## 12. 공급자 due diligence를 위험 기반으로 수행하기
그림 9. 공급자의 기원·회복력·cyber·공급망 tier·reference를 source와 날짜로 확인합니다.
> **핵심 원칙:** Due diligence는 모든 위험을 없애는 인증이 아니라 계약 전 알려진 위험과 확인 공백을 드러냅니다.
NIST SP 1326은 FOCI·provenance·resilience·foundational cyber practices·supply chain tiers를 due diligence 구성요소로 제시합니다. 합성 실습은 여기에 유사성·사실 확인을 위한 reference check를 연결합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Provenance/FOCI | 소유·통제·origin | official/current source |
| Resilience | continuity·support | risk signal |
| Cyber | governance·SDLC·incident | practice evidence |
| Tiers | subcontractor·component | disclosure·change |
| References | 유사 delivery | independent confirmation |
> **흔한 오답:** 회사 소개서와 인증 logo만 보고 실사를 완료합니다.
> **고친 예:** Risk relevance에 맞는 질문을 고르고 source·date·confidence·owner·residual risk를 supplier profile에 남깁니다.
**그림을 보며 4단계 연습**
1. Due diligence scope를 정합니다.
2. 다섯 요소별 source를 수집합니다.
3. Claim과 독립 확인을 구분합니다.
4. Gap·risk·mitigation·owner를 기록합니다.
## 13. 보안·개인정보·IP·OSS 의무를 evidence로 잇기
그림 10. 다섯 obligation을 contract 질문과 verification evidence로 연결합니다.
> **핵심 원칙:** 보안과 권리는 마지막 법무 appendix가 아니라 제안·가격·구조·인수의 입력입니다.
CISA Secure by Demand는 조달 전·중·후에 product security를 요구하도록 안내합니다. 개인정보 처리 위탁은 한국 개인정보 보호법 제26조와 조직별 법무 검토가 필요하고, source 소유권과 OSS license는 수정·배포·exit 권리에 함께 영향을 줍니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Security | SSDF·verification | test·attestation |
| Privacy | 위탁·재위탁·삭제 | contract·audit |
| IP | ownership·license grant | rights schedule |
| OSS/SBOM | origin·license·version | machine record |
| Incident | notify·remediate | timeline·owner |
> **흔한 오답:** NDA와 보안서약서가 있으므로 개인정보·SBOM·incident·IP 검토를 생략합니다.
> **고친 예:** 각 obligation에 requirement·supplier response·contract location·delivery evidence·verification·exception authority를 둡니다.
**그림을 보며 4단계 연습**
1. 처리 data와 trust boundary를 씁니다.
2. Security·privacy·IP·OSS 질문을 분리합니다.
3. 각 claim의 evidence와 acceptance를 연결합니다.
4. 법률·certification 경계를 명시합니다.
## 14. 가격 구조·TCO·변경 경로를 비교하기
그림 11. Price shape→lifecycle cost→change control을 한 commercial normalization에서 봅니다.
> **핵심 원칙:** 견적 총액은 scope·가정·change·support·exit를 같은 기준으로 맞춘 뒤에야 비교할 수 있습니다.
Fixed price는 불확실한 scope에서 change request를 부르고, T&M은 outcome 없이 투입만 늘 수 있습니다. Included/excluded, role rate, volume, milestone evidence, support, migration, termination assistance까지 TCO horizon에서 비교합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Fixed | stable scope | change·quality risk |
| T&M | adaptive scope | capacity·priority control |
| Hybrid | work package fit | boundary management |
| TCO | build→operate→exit | horizon·assumption |
| Change | scope·time·cost·quality | authority·version |
> **흔한 오답:** 세 제안의 합계 금액만 나란히 두고 포함·제외와 단가를 보지 않습니다.
> **고친 예:** Relative price index와 실제 견적을 구분하고 TCO·assumption·change rate·payment evidence를 정규화합니다.
**그림을 보며 4단계 연습**
1. 가격 모델과 가정을 씁니다.
2. Included/excluded와 TCO 항목을 맞춥니다.
3. Change impact와 authority를 정합니다.
4. Budget·payment approval 경계를 적습니다.
## 15. Evidence-weighted 평가와 sensitivity 검토하기
그림 12. 일곱 기준의 score에 evidence confidence와 sensitivity를 함께 봅니다.
> **핵심 원칙:** 점수는 대화를 구조화하지만 mandatory gate·risk·authority를 대신하지 않습니다.
Criteria는 M12·M13-01 source에서 도출하고 proposal을 보기 전에 freeze합니다. Score마다 evidence link와 rating rationale을 남기며 weight ±5, confidence down, price up, key person unavailable 같은 변화에 recommendation이 얼마나 민감한지 확인합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Understanding | 20 | source trace |
| Approach | 20 | architecture fit |
| Team | 15 | named role evidence |
| Quality/assurance | 30 | test·security evidence |
| Ops/exit/price | 15 | TCO·handover |
> **흔한 오답:** PROP-B의 weighted score가 높으므로 자동 선정합니다.
> **고친 예:** Mandatory pass, score, confidence, sensitivity, residual risk, TBR와 decision authority를 Gate의 별도 행으로 둡니다.
**그림을 보며 4단계 연습**
1. Driver에서 criterion을 도출합니다.
2. Weight 합과 rating anchor를 확인합니다.
3. Score에 evidence·confidence를 붙입니다.
4. Sensitivity와 recommendation boundary를 기록합니다.
## 16. ‘작동한다’를 8개 acceptance scenario로 바꾸기
그림 13. 기능만 아니라 build·복구·security·migration·operations를 인수 기준에 포함합니다.
> **핵심 원칙:** 인수는 화면 확인이 아니라 receiving team이 합의한 환경과 oracle로 결과를 재현하는 활동입니다.
ISO/IEC 25023은 acquisition과 acceptance testing에서 product quality measure를 사용할 수 있음을 설명하고, ISO/IEC/IEEE 29119-2는 lifecycle model과 무관한 test process를 다룹니다. 합성 사례는 AT-01~08을 source·stimulus·environment·artifact·response·measure로 씁니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Trace/build | AT-01~02 | 100% P0/P1·clean build |
| Function/performance | AT-03~04 | P0 pass·p95≤800ms |
| Recovery/security | AT-05~06 | RTO/RPO·cross-org 0 |
| Migration | AT-07 | count/checksum reconcile |
| Operations | AT-08 | diagnosis≤30m·export |
> **흔한 오답:** 담당자가 demo를 보고 기능이 되는 것 같다고 인수합니다.
> **고친 예:** Test environment·synthetic data·command·oracle·result·owner·timestamp·version을 acceptance evidence로 보존합니다.
**그림을 보며 4단계 연습**
1. 중요 outcome과 risk를 고릅니다.
2. 여섯 부분 acceptance scenario를 씁니다.
3. 환경·data·oracle·evidence를 연결합니다.
4. Critical threshold와 retest rule을 정합니다.
## 17. 12개 delivery artifact를 재현·일치·인계로 검수하기
그림 14. 납품물의 presence→reproduce→reconcile→retest→handover를 순서대로 확인합니다.
> **핵심 원칙:** 납품물은 파일 이름이 아니라 receiving team이 독립적으로 사용할 수 있는 capability입니다.
Source ZIP이 있어도 dependency lock·build instruction·tag·access가 없으면 재생산할 수 없습니다. Runbook이 있어도 restore drill·teach-back이 없으면 운영할 수 없습니다. 12개 artifact의 presence·version·trace·reproducibility를 각각 판정합니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Source/build | DEL-01~03 | tag·lock·hash |
| Infra/trace | DEL-04~06 | access·requirement·test |
| Assurance/data | DEL-07~09 | SBOM·privacy·migration |
| Ops/docs | DEL-10~11 | restore·user/admin |
| Handover/exit | DEL-12 | teach-back·export |
> **흔한 오답:** 제안서의 납품 목록과 같은 이름의 파일이 있으면 검수를 완료합니다.
> **고친 예:** 각 artifact를 independent reviewer가 열고 build·deploy·test·restore·export하며 mismatch와 defect를 기록합니다.
**그림을 보며 4단계 연습**
1. 12개 deliverable의 owner·format을 확인합니다.
2. Presence와 reproduction을 분리합니다.
3. Trace·version·consistency를 검사합니다.
4. Defect·retest·handover evidence를 닫습니다.
## 18. Vendor Evidence Gate를 닫고 M13-03으로 넘기기
그림 15. 6/24→15/24→24/24로 개선해 COI·critical risk·defect를 0으로 닫습니다.
> **핵심 원칙:** Gate는 발표 인상을 versioned evidence·residual risk·authority·handoff로 바꿉니다.
최종 합성 후보는 24 scenario, 12 controls, 네 lane 각 6개, 네 proposal, 8 acceptance, 12 delivery artifact, unresolved COI 0, open critical risk 0, open critical defect 0, TBR 2를 요구합니다. M13-03에는 통합 architecture 문서에 필요한 선택·검수 evidence를 넘깁니다.
| 관점 | 합성 사례 | 확인할 evidence |
|---|---|---|
| Low-bid v1 | 6/24 | risk6·defect4 |
| Paper v2 | 15/24 | risk3·defect2 |
| Evidence v3 | 24/24 | risk0·defect0 |
| Gate | COI0·TBR2 | handover complete |
| Handoff | M13-03 | not award/acceptance |
> **흔한 오답:** vendor_evidence_package_ready이므로 계약 체결과 납품 인수를 승인합니다.
> **고친 예:** 교육용 협상 후보·open TBR·residual risk·다음 authority를 함께 넘기고 실제 decision은 별도 process로 둡니다.
**그림을 보며 4단계 연습**
1. 세 variant를 실행합니다.
2. Fixed·regressed·risk·defect를 비교합니다.
3. Gate evidence와 TBR을 기록합니다.
4. M13-03 handoff와 실제 authority 경계를 씁니다.
## 19. 12개 Vendor Selection·Inspection Control
| ID | 통제 | 최소 evidence |
|---|---|---|
| CTRL-01 | M12-04·M13-01 source handoff | Sourcing input manifest |
| CTRL-02 | Delivery model·scope·authority boundary | Delivery model and scope brief |
| CTRL-03 | RFI·RFP·RFQ·SOW·deliverable baseline | Versioned RFP and SOW pack |
| CTRL-04 | Fair evaluation·COI·clarification governance | Evaluation governance log |
| CTRL-05 | Proposal compliance·assumption normalization | Proposal compliance matrix |
| CTRL-06 | Vendor capability·team·subcontractor due diligence | Supplier due diligence record |
| CTRL-07 | Security·privacy·IP·OSS·data obligations | Assurance and rights schedule |
| CTRL-08 | Commercial model·TCO·change·payment gate | Commercial normalization sheet |
| CTRL-09 | Weighted evidence evaluation·sensitivity | Evidence-weighted evaluation matrix |
| CTRL-10 | Acceptance scenario·environment·test evidence | Acceptance test and trace pack |
| CTRL-11 | Delivery inspection·defect·retest·waiver | Delivery inspection and defect log |
| CTRL-12 | Handover·exit·Vendor Evidence Gate | Vendor Evidence Gate |
## 20. 24개 합성 시나리오 포트폴리오
| ID | Lane | 시나리오 | 위험 | Source → Evidence | Controls |
|---|---|---|---|---|---|
| SC-01 | procurement-context-scope | M12-04·M13-01 linked package를 source version으로 인수 | scope-ambiguity | product and architecture pack → sourcing input manifest | CTRL-01, CTRL-02 |
| SC-02 | procurement-context-scope | 교육용 후보와 실제 선정·계약·인수 권한 분리 | evaluation-bias | sourcing question → authority boundary | CTRL-01, CTRL-02, CTRL-12 |
| SC-03 | procurement-context-scope | 내부 개발·구매·외주 delivery model 비교 | scope-ambiguity | capability and outcome needs → delivery model brief | CTRL-02 |
| SC-04 | procurement-context-scope | RFI·RFP·RFQ·SOW 목적과 순서 구분 | scope-ambiguity | market and requirement unknowns → sourcing document map | CTRL-03 |
| SC-05 | procurement-context-scope | 모든 제안자에게 같은 RFP baseline 제공 | evaluation-bias | versioned requirements → common RFP pack | CTRL-01, CTRL-03, CTRL-04 |
| SC-06 | procurement-context-scope | 12개 납품물·4개 마일스톤·책임 정의 | acceptance-gap | scope and acceptance → deliverable responsibility map | CTRL-03, CTRL-10, CTRL-11 |
| SC-07 | fair-evaluation-due-diligence | 평가 전 적격 조건·기준·가중치 고정 | evaluation-bias | architecture drivers and risks → evaluation rubric | CTRL-04, CTRL-09 |
| SC-08 | fair-evaluation-due-diligence | 이해충돌·역할 분리·공통 질의응답 | evaluation-bias | review participants and questions → evaluation governance log | CTRL-04 |
| SC-09 | fair-evaluation-due-diligence | 제안 충족·부분·미충족·예외·가정 정규화 | scope-ambiguity | four proposals → compliance matrix | CTRL-05, CTRL-09 |
| SC-10 | fair-evaluation-due-diligence | 실제 투입 인력·교체·하도급·책임 검토 | capability-mismatch | staffing claims → team capability record | CTRL-06 |
| SC-11 | fair-evaluation-due-diligence | 공급자 due diligence와 reference 확인 | capability-mismatch | supplier assertions → due diligence record | CTRL-06, CTRL-07 |
| SC-12 | fair-evaluation-due-diligence | 보안·개인정보·IP·OSS·SBOM 조건 검토 | handover-lock-in | assurance and rights claims → assurance schedule | CTRL-07 |
| SC-13 | delivery-acceptance-evidence | 가격 지수·TCO·가정·변경 비용 정규화 | evaluation-bias | commercial proposals → commercial comparison | CTRL-08, CTRL-09 |
| SC-14 | delivery-acceptance-evidence | 동일 과제 evidence rehearsal로 제안 검증 | evidence-free-demo | common scripted exercise → evidence rehearsal record | CTRL-05, CTRL-09, CTRL-10 |
| SC-15 | delivery-acceptance-evidence | 요구·architecture·구현·시험 trace matrix | acceptance-gap | versioned source requirements → acceptance trace matrix | CTRL-01, CTRL-03, CTRL-10 |
| SC-16 | delivery-acceptance-evidence | Clean environment에서 source·dependency build 재현 | evidence-free-demo | delivery tag and build instructions → reproducible build evidence | CTRL-07, CTRL-10, CTRL-11 |
| SC-17 | delivery-acceptance-evidence | 기능·성능·복구·보안 등 8개 인수 시나리오 | acceptance-gap | acceptance environment and data → acceptance evidence pack | CTRL-10 |
| SC-18 | delivery-acceptance-evidence | 12개 납품물 재현 검수와 결함 등급 판정 | acceptance-gap | delivery artifact set → inspection and defect log | CTRL-11 |
| SC-19 | change-handover-governance | Migration dry run·rollback·reconciliation | acceptance-gap | synthetic snapshot → migration evidence | CTRL-10, CTRL-11 |
| SC-20 | change-handover-governance | 배포·관측·backup·restore·runbook 검수 | handover-lock-in | runtime failure exercise → operations handover record | CTRL-10, CTRL-11, CTRL-12 |
| SC-21 | change-handover-governance | 사용자·관리자 문서와 지식 인계 확인 | handover-lock-in | receiving user and operator → knowledge transfer record | CTRL-11, CTRL-12 |
| SC-22 | change-handover-governance | 결함 수정·재시험·예외 승인 분리 | acceptance-gap | inspection defects → remediation decision log | CTRL-10, CTRL-11 |
| SC-23 | change-handover-governance | 범위·일정·비용·품질 변경 통제 | scope-ambiguity | change request → versioned change record | CTRL-03, CTRL-08, CTRL-12 |
| SC-24 | change-handover-governance | Vendor Evidence Gate와 M13-03 handoff | evaluation-bias | selection and inspection evidence → vendor evidence gate | CTRL-01, CTRL-04, CTRL-07, CTRL-09, CTRL-10, CTRL-11, CTRL-12 |
네 lane은 각각 6개 scenario를 가집니다: `procurement-context-scope`, `fair-evaluation-due-diligence`, `delivery-acceptance-evidence`, `change-handover-governance`.
## 21. 4개 합성 Proposal 한눈표
| ID | 제안 | 형태 | 가격 지수 | Evidence confidence | 상태·이유 |
|---|---|---|---|---|---|
| PROP-A | 저가·빠른 착수안 | 12주·범용 인력·시연 중심 | 70 | 45% | not-eligible-for-case · mandatory evidence와 handover 조건 미충족 |
| PROP-B | 균형형 증거 중심안 | 14주·named lead·재현형 evidence | 88 | 94% | candidate-for-learning-negotiation · 필수 조건 통과와 높은 evidence confidence; 실제 선정 아님 |
| PROP-C | 고보증 전문팀안 | 18주·전문 인력·독립 assurance | 125 | 96% | deferred-for-case · 높은 보증이 필요한 trigger 발생 시 재검토 |
| PROP-D | 화려한 데모·불투명 공급안 | 13주·subcontractor 미공개·데모 중심 | 95 | 35% | not-eligible-for-case · mandatory transparency와 rights 조건 미충족 |
## 22. 8개 Acceptance Scenario 한눈표
| ID | 속성 | Source·stimulus | Environment·artifact | Response measure |
|---|---|---|---|---|
| AT-01 | traceability | acceptance reviewer · selects a P0 requirement | tagged candidate build · trace matrix and implementation | 100% P0 and P1 requirements linked; 0 orphan critical items |
| AT-02 | reproducibility | independent reviewer · builds from the delivery tag | clean documented environment · source and dependency lock | 1 clean build; package hash recorded; 0 undocumented manual steps |
| AT-03 | functional quality | authorized coordinator · creates, assigns, confirms, and closes an action | synthetic acceptance data · browser, API, DB | all P0 journeys pass; 0 critical functional defects |
| AT-04 | performance | load harness · applies the agreed operation mix | 20 req/s for 15 minutes · application API and DB | p95 <= 800 ms; error rate < 1% in synthetic test |
| AT-05 | recoverability | operator · declares process failure then logical data recovery | documented recovery drill · runtime, database, backup | process <= 10 min; RTO <= 4 h; RPO <= 1 h |
| AT-06 | security and privacy | cross-organization synthetic user · requests protected record and deleted-data residue | authenticated acceptance environment · authorization, audit, storage, backup | 0 cross-org exposures; deletion and retention evidence present |
| AT-07 | migration integrity | migration operator · runs dry migration and rollback | versioned synthetic snapshot · mapping, target data, reconciliation | record count and checksum reconcile; 0 unexplained exceptions |
| AT-08 | operability and handover | receiving operator · diagnoses one known failure and exports data | handover rehearsal · telemetry, runbook, accounts, export | diagnosis <= 30 min; 100% required access transferred; export readable |
## 23. 12개 Delivery Artifact 검수표
| ID | 납품물 | 최소 proof |
|---|---|---|
| DEL-01 | Source repository | tag·history·ownership·access export |
| DEL-02 | Reproducible build | clean environment build script·locked dependencies |
| DEL-03 | Deployment package | versioned config schema·rollback·environment differences |
| DEL-04 | Infrastructure and access map | resource inventory·role·credential transfer plan |
| DEL-05 | Requirement and architecture trace | M12·M13-01 ID to implementation and test |
| DEL-06 | Test and acceptance evidence | command·environment·data·result·timestamp·owner |
| DEL-07 | SBOM and license record | component·version·license·origin·known risk decision |
| DEL-08 | Security and privacy evidence | threat·verification·incident·delegation·deletion |
| DEL-09 | Migration and reconciliation pack | mapping·dry run·rollback·counts·exceptions |
| DEL-10 | Operations and recovery pack | metrics·alerts·runbook·backup·restore drill |
| DEL-11 | User and administrator documentation | task completion·accessibility·known limits·version |
| DEL-12 | Handover and exit record | training·knowledge check·accounts·support·data export |
## 24. 실습 스튜디오: 세 sourcing version 실행
실습은 loopback-only·standard-library-only이며 실제 업체·가격·계약·개인정보·source·외부 network·production resource를 사용하지 않습니다. 각 variant는 같은 24 scenario에서 expected와 actual mismatch를 계산합니다.
실습 화면 1. Candidate는 24/24, critical 100%, 4 proposal, 8 acceptance, 12 delivery artifact, risk0·defect0·TBR2를 표시합니다.
실습 화면 2. Baseline은 6/24, evidence confidence 35%, critical risk6·defect4로 낮은 가격의 숨은 공백을 드러냅니다.
실습 화면 3. 중간안은 RFP와 평가표가 있지만 due diligence·build·migration·restore·handover evidence가 덜 닫혔습니다.
실습 화면 4. 행을 선택하면 boundary·claim→evidence·acceptance oracle·actual proposal/delivery를 나란히 봅니다.
실습 화면 5. 모바일에서도 authority boundary와 proposal·acceptance·artifact·risk/defect/TBR가 먼저 보입니다.
실습 화면 6. 좁은 화면에서도 네 evidence lane과 24 scenario를 순서대로 검토합니다.
| Version | Pass | Fail | 주요 상태 | 판정 |
|---|---|---|---|---|
| low-bid-demo-v1 | 6 | 18 | acceptance2·artifact3·confidence35%·risk6·defect4 | blocked_low_bid_demo_bias |
| weighted-paper-review-v2 | 15 | 9 | acceptance6·artifact8·confidence72%·risk3·defect2 | blocked_acceptance_evidence_gaps |
| evidence-led-vendor-package-v3 | 24 | 0 | acceptance8·artifact12·confidence94%·risk0·defect0 | vendor_evidence_package_ready |
## 25. 90분 실습 워크북
| 시간 | 행동 | 남길 evidence | 통과 질문 |
|---|---|---|---|
| 0~10분 | Source·authority·delivery model | input manifest·boundary | 무엇을 왜 맡기나 |
| 10~20분 | RFI/RFP/RFQ/SOW | document map | 질문의 목적이 분리됐나 |
| 20~35분 | Requirement·deliverable·acceptance | trace matrix | 완료를 미리 판정 가능한가 |
| 35~45분 | COI·Q&A·rubric freeze | fairness log | 같은 정보·기준인가 |
| 45~55분 | Proposal normalization | compliance matrix | claim과 evidence가 분리됐나 |
| 55~65분 | Due diligence·assurance | supplier risk profile | 공급망 공백이 보이나 |
| 65~75분 | Commercial·evaluation·sensitivity | TCO+rubric | 가격·점수를 과신하지 않나 |
| 75~85분 | Acceptance·delivery·defect | test+inspection log | 재현·retest 가능한가 |
| 85~90분 | Handover·Gate·M13-03 | decision+TBR | 후보와 승인을 구분하나 |
```text
Source package IDs·versions + answered/unanswered boundary:
Delivery model + retained capability + owner:
RFI/RFP/RFQ/SOW purpose + precedence:
Requirement → proposal response → criterion → acceptance → evidence:
COI + common Q&A + rubric freeze:
Proposal compliance + assumption + exception + confidence:
Due diligence + security/privacy/IP/OSS + residual risk:
Commercial model + TCO + sensitivity + change rule:
Acceptance + delivery artifact + defect + retest + waiver:
Handover + exit + Gate result + TBR + M13-03 handoff:
```
## 26. Vendor Selection·Delivery Inspection Package 템플릿
별도 템플릿 `03_Templates/T13-02_vendor-selection-delivery-inspection-package.md`를 사용합니다. 15개 section은 metadata·source·delivery model·request docs·requirements/deliverables·fairness·proposal compliance·due diligence·assurance·commercial·evaluation·acceptance·inspection/defect·handover/exit·Gate/M13-03입니다.
## 27. 셀프 테스트 30
### 1. Software acquisition과 단순 purchasing의 차이는 무엇인가요?
정답 보기
정답: Acquisition은 요구·시장·선정·계약·인수·운영·종료의 생애주기이고, purchasing은 승인된 조건의 주문·구매·지급에 가까운 거래 활동입니다.
### 2. 외주를 주면 발주 측 책임도 이전되나요?
정답 보기
정답: 아닙니다. 수행 일부를 맡겨도 product outcome·requirement·risk·acceptance·운영 전환의 retained owner와 decision authority는 발주 측에 남습니다.
### 3. Delivery model을 고를 때 비교할 다섯 축을 쓰세요.
정답 보기
정답: Outcome fit, 내부·시장 capability, 통제 필요, lifecycle cost, portability·exit입니다.
### 4. RFI·RFP·RFQ·SOW가 답하는 질문을 각각 쓰세요.
정답 보기
정답: RFI는 시장과 capability, RFP는 해결 접근·팀·evidence, RFQ는 가격·조건, SOW는 실제 수행 범위·산출물·acceptance·책임을 답합니다.
### 5. M12-04·M13-01 source를 RFP까지 추적해야 하는 이유는 무엇인가요?
정답 보기
정답: 원래 goal·requirement·architecture·risk가 제안 질문·평가 criterion·acceptance test에서 빠지거나 왜곡되는 것을 찾아 완료 판정을 가능하게 하기 위해서입니다.
### 6. Mandatory requirement와 optional requirement의 차이는 무엇인가요?
정답 보기
정답: Mandatory는 미충족 시 score와 무관하게 적격에서 제외되는 필수 조건이고, optional은 차별화 value를 주지만 단독 미충족으로 제외하지 않는 조건입니다.
### 7. Acceptance criterion을 업체 선정 전에 써야 하는 이유는 무엇인가요?
정답 보기
정답: 완료의 환경·데이터·oracle·evidence를 같은 가격과 일정의 전제로 제시해 제안 간 scope 차이와 납품 뒤 기준 협상을 줄이기 위해서입니다.
### 8. 합성 사례의 네 proposal은 무엇인가요?
정답 보기
정답: PROP-A 저가·빠른 착수, PROP-B 균형형 evidence, PROP-C 고보증 전문팀, PROP-D 화려한 demo·불투명 공급안입니다.
### 9. 가장 낮은 가격 제안이 자동 최적안이 아닌 이유는 무엇인가요?
정답 보기
정답: Mandatory gap·낮은 evidence confidence·변경·운영·인계·exit 비용이 총액 밖에 숨어 실제 outcome risk와 TCO가 더 커질 수 있기 때문입니다.
### 10. 공통 Q&A가 공정성에 필요한 이유는 무엇인가요?
정답 보기
정답: 한 제안자만 얻은 중요한 요구 해석이 제안 quality와 가격을 다르게 만들지 않도록 모든 참여자에게 같은 version과 시점으로 공유하기 위해서입니다.
### 11. COI를 발견했을 때 최소 조치는 무엇인가요?
정답 보기
정답: 사전 선언, 실제·잠재·외관상 영향 평가, 필요 시 recusal 또는 역할 교체, 조치와 authority 기록입니다.
### 12. Proposal compliance의 네 상태를 쓰세요.
정답 보기
정답: Compliant, partially compliant, noncompliant, exception입니다. 각 상태에는 assumption과 evidence link가 붙어야 합니다.
### 13. Claim과 evidence를 구분해 보세요.
정답 보기
정답: Claim은 ‘할 수 있다’는 주장이고 evidence는 누가 어떤 version·환경·절차로 실제 결과를 재현했는지 확인 가능한 source·test·record입니다.
### 14. Evidence confidence는 무엇으로 판단하나요?
정답 보기
정답: Source 독립성, 재현성, 최근성, scope coverage, chain of custody와 claim과의 직접 관련성으로 판단합니다.
### 15. NIST SP 1326의 due diligence 핵심 요소를 쓰세요.
정답 보기
정답: FOCI, provenance, resilience, foundational cyber practices, supply chain tiers입니다. 합성 실습에서는 reference check도 별도 evidence로 둡니다.
### 16. 회사 경력보다 key personnel을 봐야 하는 이유는 무엇인가요?
정답 보기
정답: 제안서를 쓴 조직의 일반 역량과 실제 투입자의 역할 적합성·가용성·교체·인수 능력은 다를 수 있기 때문입니다.
### 17. Subcontractor disclosure에 최소 무엇이 필요한가요?
정답 보기
정답: 주체, 맡은 업무, 지역, data·system access, 책임, security/privacy 조건, 교체·재위탁 승인 절차입니다.
### 18. Secure by demand를 외주 선정에 어떻게 적용하나요?
정답 보기
정답: 조달 전 security 질문, 조달 중 contract·evidence 요구, 조달 후 취약점·incident·update·outcome의 지속 확인으로 적용합니다.
### 19. SBOM 파일 하나가 security 합격을 뜻하지 않는 이유는 무엇인가요?
정답 보기
정답: 완전성·정확성·provenance·취약점·license·update·VEX·component risk decision과 실제 delivered version 연결을 추가로 확인해야 하기 때문입니다.
### 20. 개인정보 위탁 시 기술 질문 외에 무엇을 봐야 하나요?
정답 보기
정답: 위탁 목적·범위, 목적 외 처리 금지, 보호조치, 재위탁, 공개·통지, 보존·삭제, 감독·audit, incident와 책임을 관할 법령·전문가와 검토해야 합니다.
### 21. IP와 OSS를 함께 검토해야 하는 이유는 무엇인가요?
정답 보기
정답: 맞춤 산출물의 소유·사용권과 포함된 open source의 license 의무·출처·배포 조건이 실제 수정·운영·이전 권리에 함께 영향을 주기 때문입니다.
### 22. 고정가와 T&M의 핵심 trade-off는 무엇인가요?
정답 보기
정답: 고정가는 stable scope에 예산 예측성이 있지만 변경 pricing과 품질 저하 위험이 있고, T&M은 변화 대응이 쉽지만 투입·우선순위·상한·성과 관리가 필요합니다.
### 23. 합성 가격 지수 70·88·95·125가 실제 예산 승인이 아닌 이유는 무엇인가요?
정답 보기
정답: 실제 금액·세금·단가·volume·지원·계약·조직 budget authority를 포함하지 않은 비교용 상대 신호이기 때문입니다.
### 24. Weighted score가 선정 결정을 자동화하지 못하는 이유는 무엇인가요?
정답 보기
정답: Mandatory gate·evidence confidence·sensitivity·residual risk·COI·authority·unmeasured consequence를 숫자 하나가 대신하지 못하기 때문입니다.
### 25. 합성 사례의 8개 acceptance scenario를 쓰세요.
정답 보기
정답: Traceability, reproducible build, functional quality, performance, recoverability, security/privacy, migration integrity, operability/handover입니다.
### 26. Reproducible build의 합격 evidence는 무엇인가요?
정답 보기
정답: Clean documented environment에서 delivery tag와 locked dependency로 package를 만들고 hash·provenance를 기록하며 undocumented manual step이 0인 것입니다.
### 27. Critical defect와 waiver를 어떻게 다뤄야 하나요?
정답 보기
정답: Critical defect는 Gate를 막고 remediation·retest가 원칙입니다. Waiver는 score나 일정으로 숨기지 않고 별도 authority가 조건·기간·residual risk를 기록해야 합니다.
### 28. Migration과 handover 검수의 공통점은 무엇인가요?
정답 보기
정답: 파일 존재가 아니라 receiving team이 dry run·rollback·reconciliation·diagnosis·data export를 독립적으로 재현해야 한다는 점입니다.
### 29. 세 sourcing version의 pass 수와 판정을 쓰세요.
정답 보기
정답: low-bid-demo-v1은 6/24·blocked_low_bid_demo_bias, weighted-paper-review-v2는 15/24·blocked_acceptance_evidence_gaps, evidence-led-vendor-package-v3는 24/24·vendor_evidence_package_ready입니다.
### 30. Vendor Evidence Gate가 뜻하지 않는 것과 M13-03에 넘길 것을 쓰세요.
정답 보기
정답: 실제 업체 추천·선정·award·계약·지출·납품 인수·지급·배포·인증을 뜻하지 않습니다. M13-03에는 source·RFP·proposal matrix·due diligence·acceptance·defect·handover·risk·TBR evidence를 넘깁니다.
## 28. 공식 자료와 적용 경계
| 자료 | 이 장에서 가져온 원리 | 적용 경계 |
|---|---|---|
| [ISO/IEC/IEEE 41062:2024](https://www.iso.org/standard/81503.html) | 외부 supplier software acquisition의 활동·task·practice | 표준 전문과 조직 process를 대체하지 않음 |
| [ISO/IEC/IEEE 12207:2026](https://www.iso.org/standard/90219.html) | software full lifecycle·acquisition·supply·operation·support·retirement | 특정 lifecycle·method를 강제하지 않음 |
| [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html) | requirements process·information item·content | 2026년 개정 진행 중; published edition 경계 명시 |
| [ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html) | ICT/software product quality model | quality priority와 threshold는 context에서 결정 |
| [ISO/IEC 25023:2016](https://www.iso.org/standard/35747.html) | acquisition·selection·acceptance의 quality measure | 현재판이지만 개정 진행; grade를 자동 부여하지 않음 |
| [ISO/IEC/IEEE 29119-2:2021](https://www.iso.org/standard/79428.html) | lifecycle model과 무관한 software test process | 이 장의 8 scenario는 축약 학습 적용 |
| [NIST SP 800-218 SSDF 1.1](https://csrc.nist.gov/pubs/sp/800/218/final) | supplier와 secure development 공통 언어 | 미 연방 적용 요구나 certification으로 오해 금지 |
| [NIST SP 800-161 Rev.1 Update 1](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final) | C-SCRM·supplier due diligence·acquisition risk | 조직 risk context tailoring 필요 |
| [NIST SP 1326](https://csrc.nist.gov/pubs/sp/1326/final) | FOCI·provenance·resilience·cyber·supply tiers due diligence | 2026-07 final; 모든 risk의 exhaustive assessment 아님 |
| [CISA Secure by Demand](https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf) | 조달 전·중·후 product security 질문 | 미 정부용 guide를 계약 조항으로 그대로 복제하지 않음 |
| [CISA Software Acquisition Guide V2](https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf) | supplier response·SBOM·SSDF·software assurance | risk와 규모에 맞게 질문을 줄이고 증거 보호 |
| [OWASP SAMM Supplier Security](https://owaspsamm.org/model/design/security-requirements/stream-b/) | supplier security competence·assessment·transparency | maturity model은 certification이 아님 |
| [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) | application security requirement와 verification vocabulary | scope·level·applicability를 별도 정함 |
| [OECD Public Procurement Implementation 2025](https://www.oecd.org/en/publications/implementing-the-oecd-recommendation-on-public-procurement-in-oecd-and-partner-countries_02a46a58-en/full-report/implementation-of-the-oecd-recommendation-in-member-and-partner-countries_2305bb1b.html) | COI 선언·예방·투명성·공급자 integrity | 민간 적용은 원칙 수준; 각 관할 조달법 별도 |
| [UK Sourcing Playbook 2026](https://www.gov.uk/government/publications/the-sourcing-and-consultancy-playbooks/the-sourcing-playbook-html) | delivery model·due diligence·bid evaluation·risk pricing·exit | 영국 중앙정부 guidance를 한국 계약에 직접 적용하지 않음 |
| [소프트웨어 기술성 평가기준 지침](https://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000258386) | 요구 분석에 따른 평가요소·방법·적격 기준 | 국가기관등 적용 범위; 시행 2025-04-30 확인 |
| [협상에 의한 계약체결기준](https://www.law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000272436&chrClsCd=010201) | 제안서 평가·협상 절차의 공공 계약 기준 | 시행 2026-01-02; 민간 계약·법률 자문 아님 |
| [소프트웨어사업 계약 및 관리감독에 관한 지침](https://law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000223356&chrClsCd=010201) | 공공 SW사업 기능·비기능 요구와 관리감독 | 국가기관등 적용; 2023-05-15 판 확인·최신성 재검토 필요 |
| [개인정보 보호법 제26조](https://law.go.kr/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=900079876) · [표준 개인정보처리위탁 계약서](https://law.go.kr/flDownload.do?flSeq=129867167) | 위탁 문서·목적 외 처리 금지·보호조치·수탁자 공개 | 시행일·업무·관할별 법무/개인정보 전문가 검토 필수 |
| [ISO/IEC 5230:2020 OpenChain](https://www.iso.org/standard/81039.html) | open source license compliance program 요구 | 2026 review 상태; individual license legal opinion 아님 |
## 29. 용어집 300 학습 순서
`04_Glossary/GLOSSARY_vendor_selection_delivery_inspection.md`에는 15개 묶음·300개 unique term이 있습니다.
| 묶음 | 핵심 질문 |
|---|---|
| 01~03 | Acquisition·scope·RFI/RFP/RFQ/SOW를 구분하는가 |
| 04~06 | Requirement·fairness·proposal compliance를 연결하는가 |
| 07~10 | Evaluation·due diligence·commercial·assurance를 설명하는가 |
| 11~13 | Acceptance·defect·build·migration·operations를 재현하는가 |
| 14~15 | Handover·exit·Gate·authority·M13-03을 구분하는가 |
## 30. 다음 단계 · M13-03 handoff
M13-03에서는 이 evidence package를 통합 시스템 아키텍처 문서에 결합합니다. 제품·요구·architecture candidate·supplier assumption·acceptance·delivery·defect·handover가 같은 ID와 version으로 읽혀야 future team이 왜 이 경계와 evidence를 선택했는지 이해할 수 있습니다.
```text
M12-04 linked product documents
→ M13-01 context + quality scenarios + architecture candidate + ADR
→ M13-02 common RFP + proposal compliance + due diligence
→ acceptance scenarios + delivery artifacts + defect/retest
→ handover + exit + residual risk + TBR
→ M13-03 integrated architecture document
```
| Handoff item | M13-02 source | M13-03 use |
|---|---|---|
| Sourcing context | delivery model·scope·authority | system context·ownership |
| Requirements | RFP/SOW·trace·acceptance | requirement and view linkage |
| Proposal decision | matrix·rubric·sensitivity | selected assumption·trade-off |
| Supplier risk | due diligence·assurance schedule | external dependency·trust |
| Build/delivery | 12 artifacts·version·provenance | implementation·deployment evidence |
| Acceptance/defect | 8 scenarios·retest·waiver | quality·residual risk |
| Handover/exit | account·runbook·export·TBR | operations·evolution boundary |
> **마지막 확인:** 좋은 외주 선정 자료는 어느 업체가 멋져 보였는지를 남기지 않습니다. 같은 요구를 누가 어떤 evidence로 이해했고, 어떤 risk와 TBR을 남긴 채 무엇을 재현·인계할 수 있는지를 보존합니다.
---
## 배포본 안내
- 매뉴얼 ID: `M13-02`
- 콘텐츠 버전: `v0.1.0`
- [인쇄용 PDF](../M13-02/M13-02_select-outsourcing-vendor-and-inspect-delivery_v0.1.0.pdf)
- 그림·실습·템플릿·용어집 링크는 이 프로젝트 폴더 구조를 기준으로 합니다.