프로젝트가 끝나갈 무렵, 발주사 담당자가 묻습니다. "그래서 지금까지 뭐가 나왔죠? 요구사항정의서는 최종본 맞나요? 설계서랑 실제 구현이 다른데, 어느 게 기준이에요? 검수는 무슨 문서로 하죠?"
신입 PM A는 폴더를 뒤집니다. 요구사항정의서가 세 버전이고 어느 게 최종인지 모릅니다. 설계서는 초안에서 멈춰 있고, 검수 기준이 어디 적혀 있는지 아무도 모릅니다. 결국 "구두로 합의했다"는 말만 남고, 대금 지급이 보류됩니다.
선임 PM B는 한 장짜리 산출물 지도를 꺼냅니다. 단계별로 어떤 문서가, 누가 작성하고, 누가 검토·승인하며, 언제 확정되는지가 적혀 있습니다. "분석 단계 산출물은 요구사항정의서 v1.2(승인 완료), 설계는 화면설계서·DB설계서, 검수 기준은 요구사항정의서의 인수 기준 표입니다." 발주사는 더 묻지 않습니다.
둘의 차이는 성실함이 아니라 문서가 곧 증거이자 인수 기준이라는 감각입니다. 이 모듈은 프로젝트와 운영에서 만들어지는 문서들을 단계별로 한 장에 지도화합니다.
- 1프로젝트(SI) 단계(착수·분석·설계·개발·테스트·검수·이행·운영)별로 어떤 산출물이 나오는지 지도를 그릴 수 있다
- 2각 문서의 목적·작성자·독자·산출 시점을 구분해 설명할 수 있다
- 3운영(SM) 단계에서 반복 생산되는 산출물(장애보고서·RCA·변경/롤백계획서·주간보고 등)을 나열하고 용도를 말할 수 있다
- 4"문서가 곧 증거이자 인수 기준"이라는 원칙과, 산출물(Output)과 결과(Outcome)의 차이를 설명할 수 있다
- 5특정 상황에서 어떤 산출물을 먼저 만들어야 하는지 판단할 수 있다
왜 문서를 단계별로 지도화하는가
문서는 일의 부산물이 아니라 '증거'이자 '인수 기준'이다
엔지니어는 문서를 "일하고 남는 부산물"로 느끼기 쉽습니다. 그러나 관리 직무에서 문서는 일 그 자체의 결과물이자, 양쪽이 무엇을 합의했는지를 증명하는 증거입니다.
세 가지 이유로 문서가 일의 기준이 됩니다.
- 증거: "했다/안 했다"의 분쟁을 막습니다. 구두 합의는 기억이 어긋나지만, 서명된 문서는 어긋나지 않습니다.
- 인수 기준: 요구사항정의서의 기능 목록과 인수 기준이 곧 "무엇을 만들면 끝인가"의 선을 긋습니다. 이 선이 없으면 범위가 끝없이 늘어납니다(스코프 크립).
- 인계와 재현: 담당자가 바뀌어도 설계서·운영절차서가 있으면 같은 품질로 일이 이어집니다. 문서가 없으면 사람이 떠날 때 지식도 함께 떠납니다.
그래서 "어느 단계에 어떤 문서를 만드는가"를 한 장으로 정리하면, 프로젝트 전체의 진척·증거·합의 상태를 한눈에 통제할 수 있습니다. 이것이 산출물 지도입니다.
그림: SI는 단계마다 한 번, SM은 살아 있는 동안 반복 생산되며, 검수확인서가 인수 기준 충족의 증거가 된다.
SI 프로젝트 단계별 산출물 지도
착수에서 운영까지, 단계마다 확정되는 문서가 다르다
SI(시스템 통합) 프로젝트는 보통 착수 → 분석 → 설계 → 개발 → 테스트 → 검수 → 이행 → 운영으로 흐릅니다. 각 단계는 고유한 산출물을 남기고, 그 산출물이 다음 단계의 입력이 됩니다.
핵심 원칙: 이전 단계 산출물이 승인되어야 다음 단계가 정당하게 시작됩니다. 요구사항이 확정되지 않았는데 설계를 시작하면, 요구사항이 바뀔 때마다 설계가 흔들립니다.
아래는 단계별 대표 산출물과, 각 문서의 목적·작성/검토 주체를 정리한 지도입니다.
| 단계 | 대표 산출물 | 문서의 목적 | 작성 / 검토·승인 |
|---|---|---|---|
| 착수(Initiation) | 사업수행계획서, 착수보고서, 프로젝트 헌장 | 범위·일정·조직·관리 방식의 큰 그림 합의 | 작성: PM · 검토: 발주사/PMO |
| 분석(Analysis) | 요구사항정의서, 현행 분석서, 인수 기준 표 | "무엇을 만들 것인가"와 "무엇을 충족하면 끝인가" 확정 | 작성: 분석가/PL · 승인: 발주사 현업 |
| 설계(Design) | 화면설계서, DB설계서, 인터페이스 정의서, 아키텍처 설계서 | "어떻게 만들 것인가"를 구현 가능한 수준으로 명세 | 작성: 설계자/아키텍트 · 검토: 발주사 IT, PMO |
| 개발(Build) | 소스코드, 단위테스트 결과, 형상관리 이력 | 설계대로 구현되었음을 증명 | 작성: 개발자 · 검토: PL |
| 테스트(Test) | 테스트계획서, 테스트시나리오, 결함관리대장, 테스트결과서 | 요구사항 충족과 품질을 검증한 증거 | 작성: QA/테스터 · 검토: PM, 발주사 |
| 검수(Acceptance) | 검수요청서, 검수확인서(인수확인), 인수 기준 충족표 | 발주사가 인수 기준 충족을 공식 확인 | 작성: PM 제출 · 승인: 발주사(서명) |
| 이행(Transition) | 이행계획서, 데이터 이관 계획/결과서, 오픈 체크리스트 | 운영 환경으로 안전하게 넘기는 절차와 증거 | 작성: PM/운영 · 검토: 발주사, 운영팀 |
| 운영(Operation) | 운영이관서, 운영절차서, SLA 합의서 | 구축에서 운영으로의 인계와 운영 기준 합의 | 작성: 운영 PL · 검토: 발주사, SM팀 |
이 지도에서 검수확인서는 특별합니다. 그 한 장이 "프로젝트가 인수 기준을 충족했다"는 공식 증거이자 대금·책임 구분의 근거이기 때문입니다. 검수확인서 없이 "끝났다"는 말은 성립하지 않습니다.
운영(SM) 단계의 반복 산출물
운영은 끝나지 않으므로, 산출물도 반복 생산된다
SI(구축)가 "한 번 만들고 끝나는" 산출물을 남긴다면, SM(운영)은 서비스가 살아 있는 한 주기적으로 반복 생산되는 산출물을 남깁니다. 매일/매주/장애 때마다 같은 종류의 문서가 다시 만들어집니다.
운영 산출물은 크게 세 묶음으로 나눠 외우면 편합니다.
- 장애 대응 묶음: 장애보고서, RCA(근본원인분석) 보고서, (재발 방지 과제)
- 변경 통제 묶음: 변경계획서, 롤백계획서, 작업절차서
- 정기 보고·관리 묶음: 주간/월간 운영보고서, 회의록, 이슈/리스크 관리대장, SLA 리포트, 릴리즈노트
각 문서의 목적·작성자·독자·산출 시점은 다음 표와 같습니다.
| 운영 산출물 | 목적 | 작성자 | 주 독자 | 산출 시점 |
|---|---|---|---|---|
| 장애보고서 | 무슨 장애가, 언제, 어떤 영향으로, 어떻게 복구됐는지 기록·보고 | 운영 담당/당직 | 발주사, 운영 관리자 | 장애 발생·복구 직후 |
| RCA(근본원인분석) 보고서 | 반복/중대 장애의 근본 원인과 재발 방지책 도출 | 문제관리 담당/운영 PL | 발주사, 운영팀 | 중대·반복 장애 후 |
| 변경계획서 | 무엇을·왜·어떻게 바꾸고 영향·일정·승인은 어떤지 사전 합의 | 변경 요청자/운영 담당 | CAB, 발주사 | 변경 적용 전 |
| 롤백계획서 | 변경 실패 시 되돌릴 트리거·절차·판단권한 사전 합의 | 작업 담당 | CAB, 운영 관리자 | 변경 적용 전(변경계획서와 짝) |
| 작업절차서(런북) | 작업을 누가 해도 같게 수행하도록 단계별 명세 | 운영 담당 | 작업자, 인수자 | 작업 전·표준화 시 |
| 주간/월간 운영보고서 | 기간 내 장애·변경·SLA·이슈를 종합 보고 | 운영 PL | 발주사, 경영진 | 주간/월간 정기 |
| 회의록 | 회의에서 결정된 사항·담당·기한을 합의 증거로 남김 | 회의 주관자/서기 | 참석자, 이해관계자 | 회의 직후 |
| 이슈/리스크 관리대장 | 미해결 이슈·잠재 리스크를 추적·관리 | PM/운영 PL | 발주사, PMO | 상시 갱신 |
| 요구사항정의서(운영 변경) | 운영 중 신규/변경 요건의 범위 확정 | 분석가/운영 담당 | 발주사, 개발 | 변경 요건 발생 시 |
| 검수확인서(운영 산출물) | 변경·과제 결과물의 인수 기준 충족 확인 | 운영 PM | 발주사 | 변경·과제 완료 시 |
| 릴리즈노트 | 배포에 무엇이 바뀌었는지 사용자/운영에 고지 | 개발/릴리즈 담당 | 사용자, 운영팀 | 릴리즈 시 |
| SLA 리포트 | 약속한 서비스 수준(가용성·응답시간 등) 달성 여부 보고 | 운영 PL | 발주사, 경영진 | 월간/분기 정기 |
여기서 보이는 패턴: 운영 산출물은 대부분 "사전 합의용(변경/롤백계획서)", "사후 증거용(장애보고서·RCA·SLA 리포트)", "상시 추적용(이슈/리스크 관리대장)" 중 하나입니다. 어떤 문서를 쓸지 헷갈릴 때는 "지금 필요한 게 합의인가, 증거인가, 추적인가"를 먼저 물으면 됩니다.
산출물 지도 — 실제 매트릭스·체크리스트 다운로드
문서 이름이나 단계를 외우는 대신 "지금 필요한 게 합의인가, 증거인가, 추적인가" 한 가지만 물으면 산출물 선택이 거의 자동으로 풀립니다. 합의 문서는 서명·승인으로 닫히고(미래 시제), 증거 문서는 사실·시각으로 닫히며(과거 시제), 추적 문서는 상태 칸을 갱신하는 동안 살아 있습니다(현재 시제).
직접 해보기 — 산출물 지도 채우기
아래 5건 각각에 대해 (1) 만들어야 할 산출물, (2) 그 문서의 성격이 사전 합의용 / 사후 증거용 / 상시 추적용 중 무엇인지, (3) 주 작성자를 적어 보세요. 정답은 ObserveBlock에 있습니다.
A. 분석 단계 끝. 발주사와 "이걸 만들면 끝"이라는 선을 긋고 서명받아야 한다.
B. 다음 주 DB 스키마 변경 예정. 실패하면 되돌릴 절차를 미리 합의해야 한다.
C. 새벽에 그룹웨어가 2시간 멈췄다가 복구됐다. 발주사에 보고해야 한다.
D. 프로젝트 진행 중 미해결 항목과 잠재 위험이 쌓여 추적이 필요하다.
E. 월말이다. 이번 달 가용성이 SLA 99.9%를 지켰는지 발주사에 보고해야 한다.
성격을 먼저 판단하면 문서 종류가 빠르게 좁혀집니다. "지금 필요한 게 합의인가, 증거인가, 추적인가?"를 먼저 물으세요.
각 건: 산출물명 + 성격(합의 / 증거 / 추적) + 작성자- A = 요구사항정의서(+인수 기준 표) · 성격: 사전 합의 · 작성: 분석가/PL, 승인: 발주사. 이 서명이 검수의 기준선이 된다
- B = 롤백계획서(변경계획서와 짝) · 성격: 사전 합의 · 작성: 작업 담당, 검토: CAB. 트리거·판단권한·복구절차를 명시
- C = 장애보고서 · 성격: 사후 증거 · 작성: 당직/운영 담당. 발생·영향·조치·복구 시각을 사실대로
- D = 이슈/리스크 관리대장 · 성격: 상시 추적 · 작성: PM/운영 PL. 항목·담당·기한·상태를 계속 갱신
- E = SLA 리포트 · 성격: 사후 증거(정기) · 작성: 운영 PL. 약속한 수준 대비 실적을 수치로
- 핵심 감각: 문서를 고를 때 "단계/시점"과 "성격(합의·증거·추적)"을 같이 보면 거의 틀리지 않는다
현장에서 자주 보는 함정
증상: 폴더에는 산출물이 가득합니다. 장애보고서도, RCA도, 변경계획서도 있습니다. 그런데 같은 장애가 또 나고, 검수 때 "이게 최종본 맞냐"는 질문에 답을 못 하고, 변경은 승인 없이 적용됩니다.
원인: 문서를 산출물(만들었다)에서 멈추고 결과(만들어 낸 변화)로 잇지 못했습니다. RCA를 썼지만 재발 방지 과제가 등록·추적되지 않았고, 요구사항정의서는 버전이 셋인데 어느 게 승인본인지 표시가 없으며, 변경계획서는 작성됐지만 승인 단계를 건너뛰었습니다. 문서가 의사결정·합의·개선의 도구가 아니라 '제출용 종이'가 된 것입니다.
해결 방향(이 트랙에서 깊어짐):
- 모든 산출물에 버전·승인 상태·승인자를 명시 → "어느 게 기준인가"를 없앤다.
- RCA의 끝은 보고서가 아니라 재발 방지 과제 등록(이슈/리스크 관리대장 연결).
- 변경계획서·롤백계획서는 CAB 승인 절차와 연결되어야 효력이 생긴다.
- 검수는 요구사항정의서의 인수 기준 표와 1:1로 대조해 충족표로 증명한다.
문서의 목적은 '존재'가 아니라 '결과'입니다. 좋은 산출물은 항상 합의·증거·추적 중 하나의 결과를 실제로 만들어 냅니다.
발주사·원청의 IT 운영 담당, PM/PMO, SI 사업관리 자리에 서면, 당신은 직접 코드를 짜기보다 **"지금 어떤 단계이고, 어떤 산출물이 나와야 하며, 그 문서가 누구의 승인으로 확정되는가"**를 통제합니다. 협력사(하도급) 엔지니어가 설계서·테스트결과서를 작성하더라도, 그 산출물이 인수 기준을 충족하는지, 버전과 승인이 맞는지, 검수확인서로 닫혔는지를 판단하는 것은 관리자의 책임입니다.
특히 공공·금융 SI에서는 산출물 목록 자체가 계약·감리의 대상입니다. 감리는 "정의된 산출물이 단계별로 빠짐없이, 적절한 품질로 생산되고 승인됐는가"를 봅니다. 그래서 산출물 지도를 머릿속에 가지고 있는 PM은 "지금 무엇이 비어 있고, 무엇이 다음 단계를 막고 있는가"를 즉시 짚어 냅니다. 이것이 협력사와 대등하게 대화하고 잘못된 보고에 속지 않는 관리자의 힘입니다.
운영(SM)으로 넘어가면, 매주·매월·장애 때마다 반복 생산되는 산출물이 곧 운영 품질의 기록이 됩니다. 잘 쓰인 장애보고서 한 장이 다음 장애의 RCA를 빠르게 만들고, 잘 관리된 SLA 리포트가 계약 갱신의 근거가 됩니다.
관련 모듈로 더 깊이:
- 장애보고서 작성 — 이 지도에서 가장 자주 쓰이는 운영 산출물의 실제 작성법
- 요구사항정의서·검수확인서·릴리즈노트·SLA 리포트 — 산출물을 인수 기준 표와 1:1로 대조해 검수로 닫는 법
- 주간보고·경영보고 — 단계별 산출물이 매주·매월 반복 생산되는 보고로 이어지는 흐름
다음 모듈에서는 이 지도에서 가장 자주 쓰이는 운영 산출물 한 장 — 장애보고서 작성을, 무엇을·언제·어떤 항목으로 채워야 발주사가 신뢰하고 다음 RCA로 이어지는지 실제 양식 중심으로 다룹니다.