외주나 SI 프로젝트의 인수 기준은 두 장으로 나눠야 한다. 첫 번째는 기능 검수다. 합의한 업무 흐름과 권한, 계산, 데이터 처리, 연동이 기대대로 동작하는지 본다. 두 번째는 운영 인수다. 수행사가 빠진 뒤에도 발주 조직이 소프트웨어를 수정하고 빌드하고 배포하고 복구하고 보안을 관리할 수 있는지 확인한다.
기능이 모두 동작해도 운영 인수는 실패할 수 있다. 소스가 수행사 개인 저장소에 있거나, 빌드가 특정 개발자의 노트북에서만 되거나, 클라우드 최고 관리자와 도메인 명의가 수행사에 남아 있거나, 백업은 있지만 복구해 본 적이 없다면 시스템은 아직 발주 조직의 것이 아니다. 적어도 기술·운영 관점에서는 독립적으로 통제할 수 없는 상태다.
따라서 “소스코드 전달 완료”, “매뉴얼 전달 완료” 같은 문구만으로는 부족하다. 인수 기준에는 무엇을 받을지, 어떤 증거로 확인할지, 인수자가 무엇을 직접 실행할지, 누가 승인할지, 어떤 누락이 인수 차단 사유인지가 함께 들어가야 한다.
인수 기준은 프로젝트 종료 직전에 만들면 늦다
Acceptance Criteria는 최종 검수 회의에서 새로 작성하는 요구사항 목록이 아니다. 무엇이 완료 상태인지 작업 전에 정하고 그 기준으로 테스트와 종료 여부를 판단해야 한다. Microsoft의 현재 Azure Boards 지침도 고객 Acceptance Criteria를 작업 시작 전에 최대한 명확히 정의하고 이를 Acceptance Test의 근거로 사용하라고 설명한다. (learn.microsoft.com)
인수 기준은 최소한 다음 여섯 요소를 가져야 한다.
- 대상 — 어떤 기능·시스템·환경·데이터가 범위에 포함되는가
- 통과 조건 — 어떤 결과가 나오면 완료인가
- 증거 — 테스트 결과, 로그, 저장소, 문서, 설정 내역 중 무엇을 제출하는가
- 검증 방법 — 누가 어느 환경에서 다시 확인하는가
- 판정 권한 — 누가 PASS, CONDITIONAL, HOLD를 결정하는가
- 예외 처리 — 미완료 항목을 어떤 조건으로 남길 수 있는가
이 구조가 없으면 검수 회의는 “대체로 되는 것 같다”와 “우리는 개발을 완료했다”가 충돌하는 자리가 된다.
기능 검수와 운영 인수를 분리해야 한다
두 Gate는 서로 관련되지만 같은 질문에 답하지 않는다.
기능 검수 Gate
합의한 요구사항이 구현됐는지 확인한다.
- 핵심 사용자 흐름이 완료되는가
- 권한별로 허용·차단이 맞게 동작하는가
- 계산과 데이터 변경 결과가 정확한가
- 외부 시스템 연동이 정상·오류 상황에서 합의한 방식으로 동작하는가
- 합의된 성능·호환성·접근성 등 비기능 기준을 충족하는가
- 미해결 결함과 제외된 범위가 명시됐는가
운영 인수 Gate
인수 조직이 공급자에게 의존하지 않고 시스템을 통제할 수 있는지 확인한다.
- 소스와 저장소를 소유·관리할 수 있는가
- 깨끗한 환경에서 다시 빌드할 수 있는가
- 자체 계정으로 배포할 수 있는가
- 도메인·DNS·클라우드·외부 서비스 계정을 통제하는가
- 데이터를 내보내고 다시 적재할 수 있는가
- 백업으로 실제 복구할 수 있는가
- 보안 이슈와 의존성을 파악하고 있는가
- 모니터링 경보를 받을 사람이 정해져 있는가
- 유지보수 범위 밖의 작업을 구분할 수 있는가
2026년 8월 20일 갱신된 영국 정부의 서비스 준비성 검토 지침도 UAT, 통합 테스트, 비기능 테스트와 Operational Acceptance Testing을 구분한다. 또한 테스트된 복구 계획, 미해결 결함, 보안 이슈, 데이터 이전, 인수 후 운영 책임자까지 확인한다. (gov.uk)
기능 검수가 끝났다고 운영 인수까지 자동으로 끝나는 것은 아니다. 반대로 운영 문서를 모두 받았어도 핵심 기능이 합의 기준을 충족하지 못하면 기능 검수는 통과할 수 없다.
Software Handover Acceptance Matrix
아래 표에서 F는 기능 검수, O는 운영 인수, B는 두 Gate 모두에 영향을 주는 항목을 뜻한다.
CONDITIONAL은 위험의 범위와 임시 대응책, 책임자, 완료 기한이 모두 정해졌을 때만 사용한다. HOLD는 현재 상태로는 기술·운영 인수를 완료하지 않는다는 의미다. 이 판정이 대금 지급이나 법적 소유권에 미치는 효과는 계약과 법률 검토의 영역이며 이 글에서 다루지 않는다.
| 영역 | Gate | 합의할 기준 | 필수 증거 | 인수자가 직접 확인할 것 | 대표적인 HOLD 조건 |
|---|---|---|---|---|---|
| Requirement / Acceptance Criteria | F·B | 요구사항 ID, 적용 버전, 완료 조건, 제외 범위가 고정돼 있다 | 요구사항 목록, Acceptance Test 결과, 미완료·예외 목록 | 핵심 요구와 테스트 결과를 표본 추적하고 예외 승인자를 확인 | 기준이 사후 변경됐거나 핵심 요구의 결과가 없음 |
| Source Code | O | 계약·합의 범위의 애플리케이션 코드, DB Migration, 빌드·배포 스크립트, 설정 Template, 필요한 IaC가 포함된다 | 최종 Commit·Tag, Repository 목록, Source Archive Hash, LFS·Submodule 목록 | 최종 배포 버전이 어느 Commit에서 생성됐는지 추적 | 운영 버전과 전달 소스가 다르거나 핵심 코드가 누락됨 |
| Repository Ownership | O | 개인 계정이 아닌 인수 조직이 Repository와 조직 설정을 통제한다 | 소유 조직, 관리자 목록, Team·Permission, Branch Rule, Webhook·Deploy Key 목록 | 인수 조직 Owner가 설정·권한·보호 규칙을 변경 | 수행사 개인·조직만 Owner이고 발주자는 Collaborator에 불과함 |
| Build Reproducibility | O | 지정한 Source Revision과 문서화된 환경에서 산출물을 다시 만들 수 있다 | Runtime·Compiler 버전, Lockfile, Base Image, Build Command, 로그, Artifact Hash 또는 Provenance | 깨끗한 Runner나 신규 장비에서 직접 빌드 | 특정 개발자 PC나 접근 불가능한 Private Registry에서만 빌드됨 |
| Deployment Procedure | O | 인수 조직 계정으로 테스트·운영 환경에 배포할 수 있다 | Pipeline 정의, 배포 Runbook, 환경 목록, Config·Secret 참조 방식, Health Check | 인수팀이 비운영 환경에 직접 배포하고 결과를 확인 | 문서화되지 않은 수동 작업이나 수행사 계정이 반드시 필요함 |
| Credential / Account Ownership | O | 계정은 조직 명의이며 개인 공용 계정을 사용하지 않는다. 권한·복구 수단·MFA·비밀정보 수명주기가 정해져 있다 | 계정·Role Inventory, 복구 연락처, MFA 상태, Secret Rotation·Revocation 기록 | 자체 계정으로 로그인하고 수행사 접근을 회전·폐기 | 최고 관리자·복구 이메일을 수행사만 통제하거나 Credential 출처를 모름 |
| Domain / DNS / Cloud Account | O | 등록자, 결제 주체, 복구 연락처, 최고 관리자, 갱신 책임을 인수 조직이 통제한다 | Domain Registrar·DNS Zone·Cloud Account·Billing·Support Inventory | DNS 변경, Domain 갱신, Cloud Support 요청 권한을 확인 | 도메인·Root Account·결제 계정이 수행사 명의로만 존재 |
| Data Export / Migration | B | 인수 대상 데이터의 범위·형식·보존·정합성 검증 방식이 합의돼 있다 | Data Dictionary, Schema, Export·Migration Script, 건수·합계·Hash 검증 결과 | 표본 또는 격리 환경에서 Export와 Import를 수행 | 완전한 Export 경로가 없거나 이전 후 건수·금액·관계 정합성을 확인할 수 없음 |
| Backup / Restore | O | 백업 생성뿐 아니라 합의된 데이터 시점으로 복구할 수 있다 | 정책, 저장 위치, 최근 성공 기록, Restore Test 보고서, 측정 소요 시간 | 격리 환경에서 최근 백업을 복구하고 애플리케이션을 확인 | “백업 성공” 로그만 있고 복구 시험이 없거나 인수팀이 백업에 접근할 수 없음 |
| Security Findings | B | 검증 범위·방법·버전과 모든 미해결 Findings가 공개돼 있다 | 보안 시험 보고서, Secret Scan, Open Finding, 재시험 결과, 위험 수용자·기한 | 공개된 Finding이 현재 배포 버전과 일치하는지 표본 확인 | 중대한 미해결 이슈의 영향·완화책·책임자가 없거나 비밀정보가 코드에 남아 있음 |
| Dependency / License | O | 실행에 필요한 내부·외부 구성요소와 접근 경로, 지원 종료 상태를 파악한다 | Lockfile, SBOM, Private Package 목록, Component Version·Hash·License·EOL 정보 | 신규 환경에서 모든 의존성을 내려받아 설치·빌드 | 필수 Private Package에 접근할 수 없거나 누가 유지하는지 모름 |
| Monitoring | O | 운영 상태를 볼 수 있고 경보가 행동 가능한 담당자에게 전달된다 | Dashboard, Alert Rule, 로그 접근권한·보존, Notification Route, Runbook | Test Alert를 발생시키고 수신·확인·조치 경로를 검증 | 운영 가시성이 수행사 계정에만 있거나 경보 수신자가 없음 |
| Documentation | O | 문서가 최종 버전과 일치하고 실제 작업을 재현할 만큼 구체적이다 | Architecture, Data Flow, API, Batch·Cron, Deployment, Backup, Incident, Account Inventory | 문서만 보고 빌드·배포·복구 중 하나를 수행 | 핵심 단계가 구두 지식으로만 남거나 문서가 과거 버전을 설명 |
| Known Issue | F·B | 모든 알려진 결함·제약·기술부채를 영향과 함께 공개한다 | Issue ID, 영향 버전, 재현 절차, 영향도, 우회책, 책임자, 목표일 | 표본 이슈를 재현하고 현재 상태와 우회책을 확인 | 핵심 업무·보안·데이터에 영향을 주는 이슈가 숨겨져 있거나 Owner가 없음 |
| Warranty / Maintenance Boundary | O | 결함·변경 요청·운영 작업·외부 장애를 기술적으로 분류하고 접수·판정 절차를 정한다 | 분류표, 지원 채널, 운영 시간, 증거 요건, Escalation, 외부 Vendor 경계 | 동일한 예시 티켓을 양측이 같은 유형으로 분류하는지 확인 | 장애 발생 후 어느 조직도 접수·판정·조치를 책임지지 않는 구조 |
| Operational Owner | O | 시스템, 소스, 클라우드, 데이터, 보안, 장애 대응의 책임 역할과 대체자가 지정돼 있다 | RACI 또는 Owner Register, 담당자·대체자, 접근권한 확인 기록 | 실제 Owner가 첫 배포·복구·경보 훈련에 참여 | “IT팀”처럼 추상적 조직명만 있고 실제 권한을 가진 담당자가 없음 |
소스코드를 받았다는 말만으로는 부족하다
소스코드 압축 파일을 전달받는 것과 소프트웨어를 통제하는 것은 다르다.
최종 운영 버전이 어떤 Commit과 Tag에서 만들어졌는지 알 수 있어야 하고 이슈·Pull Request·Release 기록과 설정이 남은 저장소를 인수해야 한다. GitHub를 사용하는 경우 Repository를 이전하면 새 소유자가 내용뿐 아니라 이슈, Pull Request, Release, Project와 설정을 관리할 수 있다. 다만 Webhook, Secret, Deploy Key도 연결된 채 남을 수 있으므로 이전 후 권한과 비밀정보를 별도로 감사해야 한다. (docs.github.com)
저장소가 특정 담당자 한 명에게만 종속돼서도 안 된다. GitHub는 한 명의 Owner가 연락 불가능해질 경우 프로젝트 접근이 끊길 수 있어 조직별 복수 Owner를 권고한다. 이는 GitHub만의 제품 기능이 아니라, 소스 관리 권한을 개인에게 집중하지 말아야 한다는 운영 원칙으로 읽을 수 있다. (docs.github.com)
GitHub를 사용하지 않는 프로젝트도 기준은 같다. 플랫폼이 무엇이든 인수 조직이 저장소, 접근권한, 변경 이력, 보호 정책과 패키지 저장소를 직접 통제해야 한다.
모든 프로젝트에 비트 단위 재현 빌드가 필요한 것은 아니다
Reproducible Builds의 엄격한 정의는 동일한 소스, 빌드 환경과 지침으로 누구나 비트 단위까지 동일한 산출물을 만드는 것이다. 이를 확인하려면 Source Revision, Dependency Version, Build Flag, 환경 변수와 산출물 Hash가 필요하다. (reproducible-builds.org)
하지만 모든 SI 프로젝트의 최소 인수 기준을 곧바로 비트 단위 동일성으로 정할 필요는 없다. 위험에 따라 두 단계로 나누는 편이 현실적이다.
기본 기준은 Rebuildable Build다. 깨끗한 환경에서 전달받은 Source Revision을 Checkout하고 고정된 Runtime과 Dependency를 사용해 실행 가능한 산출물을 만들 수 있어야 한다.
보안·규제·공급망 위험이 높은 시스템은 여기에 Artifact Hash와 Build Provenance를 더할 수 있다. 현재 SLSA 1.2는 소프트웨어가 변조되지 않았고 어떤 소스에서 생성됐는지 추적하는 Build Track과 Provenance 검증 구조를 제공한다. (slsa.dev)
어느 수준을 택하든 “수행사 개발자의 노트북에서 빌드가 됐다”는 설명은 인수 증거가 아니다. 인수팀이 자체 환경에서 다시 빌드해야 한다.
계정은 비밀번호 목록이 아니라 통제권으로 인수한다
인수 문서에 비밀번호를 평문으로 모아 놓는 것은 좋은 인계가 아니다. 먼저 계정과 권한의 Inventory를 만들고 조직 명의의 계정과 개인 계정을 구분해야 한다. 비밀정보는 승인된 Secret Manager나 안전한 전달 수단으로 이전하고 수행사가 알고 있던 Key와 Password는 인수 완료 후 회전하거나 폐기한다.
OWASP는 Secret을 생성, 회전, 폐기, 만료라는 수명주기로 관리하고 더 이상 필요하지 않거나 노출 가능성이 있는 Secret은 폐기하도록 권고한다. 사용 기록과 관리자 작업도 감사할 수 있어야 한다. (cheatsheetseries.owasp.org)
특히 다음 계정을 빠뜨리기 쉽다.
- Domain Registrar와 DNS
- Cloud·Hosting·Database
- CI/CD와 Package Registry
- 이메일·SMS·결제·지도 등 외부 API
- 앱스토어·모바일 서명
- 모니터링·로그·보안 도구
- Backup Storage와 암호화 Key
- SaaS의 Billing·Support 계정
각 계정에는 Owner, 관리자, 결제 주체, 복구 이메일, MFA, 갱신일, 수행사 접근 종료일이 있어야 한다.
백업 파일보다 복구 결과를 받아야 한다
백업 목록이나 “최근 백업 성공” 화면만으로는 복구 가능성을 알 수 없다. 인수 시점에 필요한 것은 실제 Restore Test의 결과다.
최소한 다음 내용을 확인한다.
- 어떤 시점의 데이터를 복구했는가
- 어느 환경에 복구했는가
- 복구에 얼마나 걸렸는가
- 애플리케이션이 복구된 데이터로 정상 기동했는가
- 사용자·권한·첨부파일·외부 저장소까지 포함됐는가
- 복구 후 데이터 정합성을 무엇으로 확인했는가
- 복구에 필요한 암호화 Key와 계정은 누가 소유하는가
운영 인수에서 Restore Test를 요구하는 이유는 별도의 복구 아키텍처를 설계하기 위해서가 아니다. 이미 납품 대상에 포함된 백업이 인수 조직의 권한과 절차로 실제 작동하는지 확인하기 위해서다. 영국 정부의 서비스 준비성 검토 역시 실행 가능하고 시험된 비상·연속성·복귀 계획을 확인 대상으로 둔다. (gov.uk)
의존성 목록은 빌드 파일만으로 끝나지 않는다
package.json, pom.xml, requirements.txt 같은 파일은 출발점이다. 실제 인수에는 다음 정보가 더 필요하다.
- 정확한 구성요소와 버전
- 직접·간접 Dependency 관계
- Private Package와 접근권한
- 구성요소의 Hash
- 적용 License
- 지원 종료 또는 폐기 상태
- 운영에 필요한 외부 SaaS·API
- Dependency 교체·업데이트 책임자
2026년 7월 갱신된 다국가 공동 SBOM 지침은 소프트웨어를 개발하는 조직뿐 아니라 구매하거나 운영하는 조직도 대상에 포함한다. 현행 최소 요소에는 Component Version, Dependency Relationship, Hash, License, SBOM 생성 도구와 버전 등이 들어간다. (media.defense.gov)
SBOM이 있다고 모든 보안 위험이 해결되는 것은 아니다. 그러나 어떤 구성요소를 운영하고 있는지 모르는 상태보다 취약점·지원 종료·라이선스 영향을 판단할 수 있는 출발점을 제공한다.
보안 검수의 목표는 “취약점 0개” 증명서가 아니다
보안 결과물에는 최소한 시험 대상 버전, 범위, 방법, 기준, 수행일, 발견 사항, 재시험 결과가 있어야 한다. 미해결 Finding은 영향, 완화책, 위험 수용자, 책임자와 처리 기한을 남긴다.
OWASP ASVS는 웹 애플리케이션과 실행 환경의 기술 보안 통제를 검증하고 조달 요구사항을 정의하는 기반으로 사용할 수 있다. 현재 안정 버전은 ASVS 5.0.0이다. (owasp.org) NIST도 공급자의 검증 활동을 수행했다는 주장뿐 아니라 검증 결과, 설정·구현 정보, 미해결 취약점과 보완 조치를 조달·인수 과정에서 확인하도록 안내한다. (nist.gov)
중요한 것은 “보안 검사를 했다”는 한 줄이 아니라 다음 질문에 답할 수 있는가다.
- 무엇을 검사했고 무엇은 검사하지 않았는가
- 어느 버전과 환경을 검사했는가
- 미해결 이슈는 무엇인가
- 현재 운영을 차단해야 하는 이슈는 무엇인가
- 누가 언제 수정하거나 위험을 수용했는가
모니터링도 계정과 사람까지 연결돼야 한다
Dashboard URL을 전달받았다고 모니터링을 인수한 것은 아니다. 인수 조직이 로그와 지표에 접근할 수 있어야 하고 경보가 실제 대응할 사람에게 전달돼야 한다.
Google SRE는 경보가 사용자의 문제를 나타내고 긴급하며 수신자가 행동할 수 있어야 한다고 강조한다. 모든 Paging Alert는 Actionable해야 한다. (sre.google)
따라서 인수 과정에서 Test Alert를 한 번 발생시키는 것이 좋다. 경보가 올바른 채널에 도착하는지, 담당자가 Runbook을 찾을 수 있는지, 필요한 운영 계정으로 접속할 수 있는지 확인한다. 경보는 울렸지만 받을 사람이 없거나, 수행사 계정에서만 Dashboard를 볼 수 있다면 운영 인수는 끝나지 않았다.
알려진 문제를 남기는 것과 숨기는 것은 다르다
모든 Known Issue를 수정한 뒤에만 인수할 수 있는 것은 아니다. 영향이 제한적이고 우회책이 있으며 담당자와 완료 기한이 정해진 문제는 조건부로 남길 수 있다.
다만 Known Issue에는 최소한 다음 정보가 있어야 한다.
- 영향을 받는 Version과 기능
- 재현 절차
- 사용자·데이터·보안·운영 영향
- 임시 우회책
- 수정 책임자
- 목표일
- 인수 판정에 미치는 영향
“추후 개선 예정”은 처리 계획이 아니다. 특히 핵심 업무 중단, 권한 우회, 데이터 손상, 복구 실패 가능성이 있는 문제는 단순한 잔여 작업으로 낮춰서는 안 된다.
하자와 유지보수의 법률적 의미보다 먼저 기술 분류를 맞춘다
다음 구분은 법적 책임을 결정하기 위한 것이 아니다. 장애나 요청이 들어왔을 때 티켓이 어느 창구로 가야 하는지를 정하는 기술·운영 분류다. 실제 비용, 책임, 기간과 법적 효과는 계약과 별도 법률 검토를 따른다.
| 발생 상황 | 기술·운영상 분류 후보 | 인수 전에 정할 내용 |
|---|---|---|
| 합의한 Acceptance Criteria와 실제 동작이 다름 | 결함 후보 | 재현 증거, Severity, 수정·재시험 절차 |
| 새로운 기능이나 변경된 업무 규칙을 요구 | 변경 요청 후보 | 영향 분석, 승인, 별도 일정·비용 산정 절차 |
| 잘못된 운영 데이터·설정 때문에 장애 발생 | 운영·데이터 지원 후보 | 설정·데이터 Owner와 복구 책임 |
| 외부 API·SaaS 장애 또는 사양 변경 | 외부 Dependency Incident | 1차 확인자, Vendor 문의, 우회·Fallback 범위 |
| Runtime·Library의 보안 패치나 지원 종료 | 유지보수·업그레이드 작업 후보 | 모니터링, 업데이트 결정권자, 회귀 검증 책임 |
양측이 같은 사건을 서로 다르게 분류하면 대응이 시작되지 않는다. 수행사는 “추가 개발”이라고 하고 발주사는 “기존 결함”이라고 주장하는 동안 운영 장애는 그대로 남는다. 따라서 분류 기준, 필요한 증거, 최초 판정자와 이견 조정 경로를 인수 전에 정해야 한다.
인수 회의에서는 시연보다 재실행이 중요하다
실무에서는 다음 순서가 효과적이다.
- 인수 후보를 고정한다.
Source Tag, Artifact Version, Database Schema, 배포 환경과 Acceptance Matrix 버전을 함께 고정한다.
- 수행사가 먼저 증거를 제시한다.
기능 결과, 빌드·배포 로그, 계정 목록, 데이터 검증, Restore Test, 보안 보고서와 Known Issue를 설명한다.
- 인수팀이 같은 작업을 다시 수행한다.
자체 계정으로 저장소를 Clone하고 Build하고 비운영 환경에 배포한다. 데이터 Export·Import, Backup Restore와 Test Alert도 표본 실행한다.
- 예외를 별도 원장에 남긴다.
누락 항목마다 영향, 우회책, 책임자, 완료일, 재검수 방법과 현재 판정을 기록한다.
- 계정 소유권을 전환한다.
인수 조직의 Owner와 복구 수단을 확인한 뒤 수행사 접근을 필요한 범위로 낮추고 Secret을 회전하거나 폐기한다.
- 기능 검수와 운영 인수에 별도 서명한다.
기능은 통과했지만 운영 인수가 HOLD인지, 어느 항목이 조건부인지 구분한다.
시연은 수행사가 할 수 있다는 사실을 보여준다. 인수팀의 재실행은 수행사가 없어도 조직이 계속 운영할 수 있다는 사실을 보여준다. 둘은 다른 증거다.
조건부 인수가 가능한 경우와 멈춰야 하는 경우
조건부 인수는 미완료 항목이 있다는 뜻만으로 허용되지 않는다. 다음 네 가지가 모두 있어야 한다.
- 영향 범위가 제한돼 있다
- 현재 운영을 유지할 우회책이 있다
- 수정 책임자와 완료 기한이 정해져 있다
- 미완료 항목이 인수 조직의 독립적인 수정·배포·복구 능력을 제거하지 않는다
반면 다음 상태는 운영 인수를 멈출 이유가 된다.
- 최종 운영 소스와 Repository를 통제하지 못한다
- 인수팀이 깨끗한 환경에서 Build할 수 없다
- 수행사 계정 없이는 배포하거나 운영 환경에 접근할 수 없다
- Domain·DNS·Cloud 최고 관리자와 복구 수단을 인수하지 못했다
- 데이터를 완전하게 Export할 수 있는지 알 수 없다
- Backup은 있지만 Restore Test가 없다
- 중대한 보안 이슈나 Hard-coded Secret의 처리 책임자가 없다
- 운영 경보를 받을 사람과 장애 대응 Owner가 없다
문서의 개수보다 중요한 것은 인수 조직이 시스템의 다음 변경과 다음 장애를 스스로 책임질 수 있는가다.
소프트웨어 인수의 완료 조건
소프트웨어 인수는 기능 목록에 체크 표시를 모두 넣는 행위가 아니다.
인수 조직이 다음 질문에 “그렇다”고 답할 수 있어야 한다.
수행사가 내일부터 참여하지 않더라도, 우리는 이 소프트웨어의 현재 상태를 설명하고 소스를 수정하고 다시 빌드하고 배포하고 데이터를 옮기고 복구하고 보안 문제와 장애에 대응할 수 있는가?
이 질문에 답하기 위해 필요한 것은 더 많은 문서가 아니라 소유권, 실행 가능한 절차, 검증 증거와 명확한 운영 책임자다. 기능 검수와 운영 인수를 분리하면 무엇이 완료됐고 무엇이 아직 위험으로 남았는지 비로소 정확하게 판단할 수 있다.