IT 프로젝트 산출물 완전 가이드: 기획부터 종료까지 모든 문서 정리

들어가며
1. 프로젝트 착수 전 — 기획/제안 단계
2. 분석 단계 — 요구사항 분석
3. 설계 단계
4. 구현 단계 — 개발
5. 테스트 단계
6. 이행/오픈 단계 — 컷오버 (Cutover)
7. 종료 단계 — 납품 및 종료
8. 공공 프로젝트 특화 산출물
9. 산출물 관리 팁
퀴즈: 실력을 확인해 보세요
마치며

들어가며

IT 프로젝트를 성공적으로 완수하려면 코드를 잘 작성하는 것만큼이나 산출물(Deliverables) 을 체계적으로 생산하고 관리하는 것이 중요합니다. 한국 IT 현장에서는 특히 공공사업을 중심으로 단계별 산출물 요건이 매우 엄격하게 규정되어 있습니다.

이 글에서는 프로젝트 착수 전 기획/제안 단계부터 분석, 설계, 구현, 테스트, 이행(오픈), 종료 단계까지 각 단계별로 생성되어야 하는 모든 산출물을 정리합니다. 각 문서의 작성 주체, 핵심 내용, 실무 주의사항도 함께 설명합니다.

1. 프로젝트 착수 전 — 기획/제안 단계

이 단계는 사업이 공식 시작되기 전 발주사와 수주 후보사 간에 이루어지는 계약 및 기획 활동입니다.

1-1. RFP (Request for Proposal, 제안요청서)

작성 주체: 발주사(고객사)
핵심 내용: 사업 목적, 범위, 요구사항 개요, 예산 한도, 납기 일정, 평가 기준
주의사항: 기술 요건과 가격 요건을 분리 작성해야 하며, 공공사업의 경우 나라장터(G2B) 공고 요건을 충족해야 합니다. 기능 요구사항을 너무 구체적으로 작성하면 경쟁을 제한할 수 있습니다.
실무 팁: RFP가 불명확할수록 제안 단계에서 리스크가 커집니다. 사전 질의응답(Q&A) 기간을 적극 활용하세요.

1-2. 제안서 (Proposal)

작성 주체: 수주 후보사(벤더)
핵심 내용: 기술제안서(방법론, 투입 인력, 일정, 기술 스택)와 가격제안서(총액, 공수 산정 근거) 분리 제출
주의사항: 가격제안서를 기술제안서와 물리적으로 분리하여 제출해야 하며, 평가위원이 가격을 모르는 상태에서 기술 평가가 이루어져야 합니다.
실무 팁: 제안서 분량은 발주사 요건에 맞추되, 핵심 차별화 포인트를 앞부분에 배치하세요.

1-3. 사업수행계획서 (Project Management Plan)

작성 주체: 수주사 PM
핵심 내용: 프로젝트 범위 정의, 적용 방법론(폭포수/애자일/하이브리드), 인력 투입 계획, WBS 초안, 산출물 목록, 리스크 관리 계획
주의사항: 계약 전 제출하는 경우와 계약 후 최종본을 제출하는 경우가 있습니다. 공공사업에서는 착수 보고 시 함께 제출합니다.

1-4. 계약서 및 NDA (비밀유지협약)

작성 주체: 양측 법무/계약 담당
핵심 내용: 계약 범위, 대금 지급 조건, 지체상금, 하자보수 기간 및 조건, 지식재산권 귀속, 기밀 정보 보호
주의사항: 하자보수 기간(통상 1년)과 SLA 조건을 계약서에 명확히 기재해야 합니다. 소프트웨어 저작권 귀속도 명시 필수입니다.

1-5. WBS (Work Breakdown Structure, 업무 분류 체계)

작성 주체: PM + 리드 개발자
핵심 내용: 프로젝트 전체 업무를 계층적으로 분류, 마일스톤 정의, 각 작업 단위의 담당자/기간/선행 관계
주의사항: WBS는 단순 Gantt 차트가 아닙니다. 작업 패키지(Work Package)까지 분해하여 담당자가 명확히 책임질 수 있는 단위로 만들어야 합니다.

1-6. 착수보고서 및 킥오프 미팅 자료

작성 주체: PM
핵심 내용: 프로젝트 공식 시작 선언, 참여 인력 소개, 전체 일정, 의사소통 계획, 주간 보고 체계, 이슈 에스컬레이션 경로
주의사항: 킥오프 미팅에서 발주사와 수주사 간 기대치 정렬(Expectation Alignment)이 이루어져야 합니다. 이 자리에서 합의된 내용은 의사록으로 남겨야 합니다.

1-7. 이해관계자 목록 (Stakeholder Register)

작성 주체: PM
핵심 내용: 발주사/수주사/외부 기관의 담당자 정보, 역할, 의사결정 권한, 연락처, 영향력/관심도 분류
주의사항: PMBOK에서는 이해관계자 참여 계획(Stakeholder Engagement Plan)까지 작성을 권장합니다.

2. 분석 단계 — 요구사항 분석

현재 상태를 파악하고 미래 시스템이 갖추어야 할 요건을 정의하는 단계입니다.

2-1. 현황 분석서 (As-Is 분석)

작성 주체: 분석가/컨설턴트
핵심 내용: 현재 업무 프로세스(BPM), 기존 시스템 기능 목록, 데이터 흐름, 운영 인력 현황, 병목 지점 및 문제점 도출
주의사항: 인터뷰와 워크숍을 통해 실무 담당자 관점에서 작성해야 하며, 현황 분석 없이 설계로 넘어가면 요구사항 누락이 빈번합니다.

2-2. 요구사항 정의서 (Software Requirements Specification, SRS)

작성 주체: 분석가 + 발주사 담당자
핵심 내용:
- 기능 요구사항(Functional): 시스템이 수행해야 하는 구체적 기능 목록
- 비기능 요구사항(Non-Functional): 성능, 가용성, 보안, 확장성, 유지보수성
- MoSCoW 우선순위: Must Have / Should Have / Could Have / Won't Have 분류
주의사항: 요구사항 ID를 부여하여 추적성(Traceability)을 확보해야 합니다. 나중에 테스트 케이스와 1:1 매핑됩니다.

2-3. 비즈니스 요구사항 명세서 (Business Requirements Specification, BRS)

작성 주체: 비즈니스 분석가(BA) + 발주사
핵심 내용: 업무 관점에서의 요구사항, 비즈니스 규칙(Business Rule), 용어 정의(Glossary), 조직 구조도
주의사항: BRS는 SRS보다 상위 개념입니다. SRS에서 기술 세부사항이 정의되기 전에 비즈니스 의도를 명확히 하는 문서입니다.

2-4. 유스케이스 명세서 (Use Case Specification)

작성 주체: 분석가
핵심 내용: 행위자(Actor) 정의, 유스케이스 다이어그램, 각 유스케이스별 기본 흐름/대안 흐름/예외 흐름, 사전/사후 조건
주의사항: UML 표기법을 준수해야 하며, 유스케이스 수가 많아질수록 관리가 어려워집니다. 복잡한 유스케이스는 시퀀스 다이어그램으로 보완하세요.

2-5. 인터뷰/설문 결과서

작성 주체: 분석가
핵심 내용: 인터뷰 대상자, 일시, 질문 목록, 답변 요약, 도출된 요구사항
주의사항: 인터뷰 결과는 반드시 인터뷰 대상자의 확인 서명을 받아야 나중에 "그런 말 한 적 없다"는 분쟁을 방지할 수 있습니다.

2-6. 법적/규제 요구사항 분석서

작성 주체: 분석가 + 법무/보안 담당
핵심 내용: 전자금융거래법, 개인정보보호법, 정보통신망법, ISMS-P, PCI-DSS, 공공기관 정보보안 지침 등 관련 법령 분석
주의사항: 규제 요구사항은 선택이 아닌 의무입니다. 설계 단계 전에 반드시 식별하여 설계에 반영해야 합니다.

2-7. 벤치마킹 보고서

작성 주체: 분석가/컨설턴트
핵심 내용: 유사 시스템/서비스 사례 분석, 기능 비교표, 기술 트렌드, 벤치마킹 대상 선정 근거
주의사항: 벤치마킹 결과가 요구사항 정의에 실질적으로 반영되어야 의미가 있습니다.

2-8. 분석 검토 결과서 (Analysis Review Report)

작성 주체: PM + 발주사 담당자
핵심 내용: 요구사항 완전성/일관성/추적성 검토 결과, 발견된 이슈 및 액션 아이템, 분석 단계 완료 승인
주의사항: 공공사업에서는 단계별 감리 보고서와 연계됩니다.

3. 설계 단계

분석된 요구사항을 실제 구현 가능한 기술 명세로 변환하는 단계입니다.

3-1. 시스템 아키텍처 설계서 (System Architecture Design)

작성 주체: 아키텍트/기술 리드
핵심 내용: 전체 시스템 구성도, HW/SW/NW 사양, 기술 스택 선정 근거, 이중화/고가용성(HA) 설계, 재해복구(DR) 방안
주의사항: 아키텍처 결정(Architecture Decision Record, ADR)을 문서화하면 나중에 설계 변경 시 근거를 추적할 수 있습니다.

3-2. 응용 아키텍처 설계서 (Application Architecture Design)

작성 주체: 아키텍트/시니어 개발자
핵심 내용: 레이어 구조(Presentation/Business/Data), 컴포넌트 다이어그램, 마이크로서비스 경계 정의, API Gateway 설계, 서비스 간 통신 방식
주의사항: 모놀리식 vs 마이크로서비스 결정은 팀 역량과 운영 능력을 함께 고려해야 합니다.

3-3. 화면 설계서 (UI 스토리보드)

작성 주체: UX 디자이너 + 분석가
핵심 내용: 모든 화면의 와이어프레임, 화면 흐름도(Screen Flow), UI 컴포넌트 설명, 유효성 검사 규칙, 오류 메시지 정의
주의사항: 화면 설계서는 발주사 승인을 받은 후에 개발을 시작해야 합니다. 승인 없이 개발하면 나중에 대규모 수정이 발생합니다.

3-4. DB 설계서 (ERD 포함)

작성 주체: DBA + 개발자
핵심 내용:
- 논리 데이터 모델: 엔티티, 속성, 관계 정의 (ERD)
- 물리 데이터 모델: 테이블명, 컬럼, 데이터 타입, PK/FK, 인덱스 전략
- 정규화 수준, 파티셔닝 전략, 아카이빙 정책
주의사항: 논리 모델과 물리 모델을 혼용하면 혼란이 생깁니다. 단계를 구분하여 작성하세요.

3-5. 테이블 정의서 (Table Definition)

작성 주체: DBA
핵심 내용: 테이블별 컬럼명/한글명/데이터 타입/길이/NULL 허용 여부/기본값/설명, PK/FK/인덱스 목록, 코드 테이블 정의
주의사항: 데이터 표준(용어 표준, 도메인 표준, 코드 표준)을 준수해야 합니다. 공공사업의 경우 행안부 데이터 표준 지침을 따라야 합니다.

3-6. 인터페이스 설계서 (Interface Design)

작성 주체: 인터페이스 개발자 + 분석가
핵심 내용: 외부 시스템 연동 목록, 각 인터페이스별 방식(REST API / SOAP / 파일 / 배치 / EAI/ESB / MQ), 요청/응답 메시지 명세, 오류 코드 정의, 연동 테스트 방법
주의사항: 외부 시스템 담당자와 협의한 내용을 문서화하고, 인터페이스 계약(API Contract)을 명확히 해야 합니다.

3-7. 코딩 표준/컨벤션 (Coding Standards)

작성 주체: 기술 리드
핵심 내용: 명명 규칙(변수/클래스/함수/DB 객체), 주석 규칙, 예외 처리 패턴, 로깅 표준, 코드 스타일 가이드, 린트(ESLint/Checkstyle) 설정
주의사항: 실제로 린트 도구로 강제하지 않으면 지켜지지 않습니다. CI 파이프라인에 린트 검사를 포함시키세요.

3-8. 보안 설계서 (Security Design)

작성 주체: 보안 아키텍트/전문가
핵심 내용: 인증/인가 체계(OAuth2, JWT, SSO), 접근 제어 설계(RBAC/ABAC), 암호화 방식(전송/저장), 보안 로그 정책, API 보안(Rate Limiting, Input Validation)
주의사항: OWASP Top 10을 기준으로 설계 단계에서 보안 위협을 식별하고 대응 방안을 수립해야 합니다.

3-9. 배포 아키텍처 설계서 (Deployment Architecture)

작성 주체: DevOps/인프라 엔지니어
핵심 내용: 서버/컨테이너(Docker/Kubernetes) 구성, 네트워크 구성도, 로드밸런서/CDN 설정, CI/CD 파이프라인 설계, 모니터링 스택(Prometheus/Grafana/ELK)
주의사항: 운영 환경과 개발/테스트 환경의 차이를 문서화해야 합니다.

3-10. 설계 검토 결과서 (Design Review Report)

작성 주체: PM + 기술 리드 + 발주사
핵심 내용: 설계 완전성/일관성/구현 가능성 검토 결과, 리뷰 의견 및 조치 계획, 설계 단계 완료 승인
주의사항: 설계 검토(Design Review)는 단순한 서류 절차가 아닙니다. 실질적인 기술 검토가 이루어져야 개발 단계 리스크를 줄일 수 있습니다.

4. 구현 단계 — 개발

설계 명세에 따라 실제 코드를 작성하고 기본 검증을 수행하는 단계입니다.

4-1. 소스 코드 (Source Code)

작성 주체: 개발자
핵심 내용: Git 저장소 관리, 브랜치 전략(GitFlow / Trunk-based Development), 커밋 메시지 컨벤션, 코드 리뷰 정책
주의사항: 소스 코드는 산출물 중 가장 핵심입니다. 최종 납품 시 정해진 버전 태그(Tag)를 기준으로 납품합니다.

4-2. 단위 테스트 케이스 및 결과서 (Unit Test)

작성 주체: 개발자
핵심 내용: 모듈/함수별 테스트 케이스, 입력값/예상 출력값, 실행 결과, 커버리지 리포트(JaCoCo/Istanbul 등)
주의사항: 테스트 커버리지 목표(예: 코드 커버리지 70% 이상)를 사전에 합의하고, CI 파이프라인에서 자동으로 측정해야 합니다.

4-3. 코드 리뷰 이력 (Code Review History)

작성 주체: 개발팀 전원
핵심 내용: PR(Pull Request)/MR(Merge Request) 기록, 리뷰어 코멘트, 수정 이력, 품질 체크리스트 준수 여부
주의사항: 코드 리뷰는 버그를 잡는 것뿐 아니라 팀 지식 공유와 코딩 표준 준수 확인을 위해서도 중요합니다.

4-4. 빌드/배포 스크립트 (Build/Deploy Scripts)

작성 주체: DevOps/개발자
핵심 내용: CI/CD 파이프라인 정의 파일(Jenkinsfile, GitHub Actions YAML, GitLab CI), Docker 이미지 빌드 스크립트, Kubernetes 매니페스트, Terraform/Ansible 인프라 코드
주의사항: "코드로서의 인프라(Infrastructure as Code)"를 적용하면 환경 구성 재현성이 보장됩니다.

4-5. 개발 이슈 관리 목록 (Issue Tracker)

작성 주체: PM + 개발자
핵심 내용: Jira/Redmine/GitHub Issues에 등록된 이슈 목록, 이슈 유형(버그/기능/개선/기술부채), 우선순위, 담당자, 완료 일자, 해결 내용
주의사항: 이슈 트래커는 프로젝트 진행 상황을 실시간으로 파악하는 가장 중요한 도구입니다. 이슈를 트래커 외부(메신저, 이메일 등)로만 처리하면 이력이 남지 않습니다.

4-6. 주간/월간 업무 보고서 (Progress Report)

작성 주체: PM
핵심 내용: 금주 완료 작업, 진척률(계획 대비 실적), 이슈 및 리스크 현황, 차주 계획, 변경 사항
주의사항: 보고서는 사실에 기반해야 합니다. 과도한 낙관 보고는 나중에 더 큰 문제를 야기합니다.

4-7. 기술 검토 회의록 (Technical Meeting Minutes)

작성 주체: 서기(기술 담당자)
핵심 내용: 회의 일시/참석자/안건, 논의 내용, 결정 사항, 액션 아이템(담당자/기한 포함)
주의사항: 기술 의사결정은 반드시 문서화해야 합니다. 구두로만 합의된 결정은 나중에 "그런 결정 한 적 없다"는 분쟁의 씨앗이 됩니다.

5. 테스트 단계

개발된 소프트웨어가 요구사항을 만족하는지 검증하는 단계입니다.

5-1. 테스트 계획서 (Test Plan)

작성 주체: QA 리드/PM
핵심 내용: 테스트 범위, 테스트 유형(단위/통합/시스템/성능/보안/UAT), 테스트 환경, 진입/종료 기준(Entry/Exit Criteria), 일정, 담당자, 테스트 도구
주의사항: 테스트 계획은 설계 단계에서부터 수립해야 합니다. 개발이 끝난 후에야 테스트를 계획하면 이미 늦습니다.

5-2. 테스트 케이스 정의서 (Test Case Definition)

작성 주체: QA 엔지니어
핵심 내용: 테스트 케이스 ID, 요구사항 ID(추적성), 테스트 시나리오, 전제 조건, 입력값, 예상 결과, 실제 결과, 판정(Pass/Fail)
주의사항: 요구사항 ID와 테스트 케이스 ID를 매핑하는 **요구사항 추적성 매트릭스(RTM)**를 함께 관리해야 합니다.

5-3. 단위 테스트 결과서

작성 주체: 개발자
핵심 내용: 개별 모듈/컴포넌트 수준 테스트 결과, 통과/실패 목록, 커버리지 수치
주의사항: 단위 테스트는 개발자 책임입니다. QA가 단위 테스트까지 담당하면 개발 품질이 낮아집니다.

5-4. 통합 테스트 결과서 (Integration Test)

작성 주체: QA 엔지니어 + 개발자
핵심 내용: 모듈 간 연동, 외부 시스템 인터페이스, 배치/스케줄러 연동 테스트 결과, 데이터 흐름 검증
주의사항: 인터페이스 연동 테스트를 위해 외부 시스템의 테스트 환경 제공 일정을 사전에 확보해야 합니다.

5-5. 시스템 테스트 결과서 (System Test)

작성 주체: QA 팀
핵심 내용: 전체 시스템 기능 테스트, 엔드-투-엔드(E2E) 시나리오, 회귀 테스트(Regression), 설치/배포 테스트
주의사항: 시스템 테스트 환경은 운영 환경과 최대한 유사하게 구성해야 합니다.

5-6. 성능 테스트 결과서 (Performance Test)

작성 주체: 성능 테스트 엔지니어
핵심 내용: 목표 TPS(초당 트랜잭션), 응답 시간(목표: 2초 이내), 동시 접속자 수, 부하 테스트(Load)/스트레스 테스트(Stress)/내구성 테스트(Soak) 결과, 병목 구간 분석
주의사항: 성능 목표는 요구사항 정의서에 사전에 명기해야 합니다. "빠르면 좋겠다"는 모호한 요건은 분쟁의 원인이 됩니다.
주요 도구: Apache JMeter, Gatling, k6, nGrinder

5-7. 보안 취약점 점검 결과서 (Security Vulnerability Assessment)

작성 주체: 보안 전문가/보안 솔루션
핵심 내용: OWASP Top 10 기반 점검(SQL 인젝션, XSS, CSRF, 인증 취약점 등), KISA 소프트웨어 보안 약점 점검 결과, 발견된 취약점 등급(Critical/High/Medium/Low), 조치 결과
주의사항: 공공사업에서는 행정안전부 "소프트웨어 보안 약점 진단 가이드" 기준을 따라야 합니다.

5-8. 결함 목록 및 조치 결과서 (Defect Tracking)

작성 주체: QA 팀 + 개발팀
핵심 내용: 발견된 결함 목록, 결함 등급(Critical/Major/Minor), 결함 유형, 조치 담당자, 조치 내용, 재검증 결과
주의사항: Critical 결함은 반드시 오픈 전에 100% 해소해야 합니다. Major 이상 결함 잔존 시 오픈 결정은 발주사와 협의해야 합니다.

5-9. UAT 결과서 (User Acceptance Test)

작성 주체: 발주사 사용자 (QA 지원)
핵심 내용: 발주사가 직접 수행한 수용 테스트 결과, 테스트 케이스별 판정, 최종 수락 서명
주의사항: UAT는 발주사의 최종 인수 근거가 됩니다. UAT 완료 서명은 법적 효력을 가질 수 있으므로 신중하게 관리해야 합니다.

5-10. 테스트 완료 보고서 (Test Completion Report)

작성 주체: QA 리드/PM
핵심 내용: 전체 테스트 요약, 결함 현황(발견/해소/잔존), 성능 측정 결과 요약, 오픈 적합성 판정 의견, 잔존 리스크
주의사항: 테스트 완료 보고서는 오픈 결정의 근거 문서입니다. "오픈 가능" 판정은 PM과 발주사가 공동으로 결정해야 합니다.

6. 이행/오픈 단계 — 컷오버 (Cutover)

개발/테스트 환경에서 실제 운영 환경으로 전환하는 단계입니다.

6-1. 데이터 이행 계획서 (Data Migration Plan)

작성 주체: DBA + 데이터 엔지니어
핵심 내용: 이행 대상 데이터 목록, 소스-타깃 매핑 테이블, 데이터 변환 규칙, 이행 방법(전체 이행/증분 이행), 이행 일정, 롤백 계획
주의사항: 대용량 데이터 이행의 경우 이행 소요 시간을 사전에 측정(Dry-Run)해야 합니다.

6-2. 데이터 이행 결과서 (Data Migration Result)

작성 주체: DBA + QA
핵심 내용: 이행 전/후 데이터 건수 비교, 오류 건수 및 유형, 예외 처리 내역, 데이터 정합성 검증 결과
주의사항: "이행은 잘 됐다"는 구두 확인은 불충분합니다. 건수 비교와 샘플 검증을 문서화해야 합니다.

6-3. 이행 시나리오 / 컷오버 계획서 (Cutover Plan)

작성 주체: PM + 인프라 팀
핵심 내용: 오픈 당일(D-Day) 작업 순서 및 타임라인, 각 단계별 담당자 및 연락처, Go/No-Go 판단 기준, 롤백(Rollback) 절차, 비상 연락망
주의사항: 컷오버 계획은 반드시 리허설(Cutover Rehearsal)을 통해 검증해야 합니다. 실전에서 처음 실행하면 문제가 발생할 가능성이 높습니다.

6-4. 컷오버 체크리스트 (Cutover Checklist)

작성 주체: PM + 각 파트 리드
핵심 내용: 오픈 전 최종 점검 항목 (서버 기동 확인, DB 연결 확인, 인터페이스 연동 확인, 사용자 계정 확인, 백업 완료 확인 등), Go/No-Go 기준별 상태
주의사항: 체크리스트 항목은 "확인했다"의 기록이 아니라 실제 측정값(예: DB 연결 응답 시간 0.5초 이내)을 포함해야 합니다.

6-5. 오픈 결과 보고서 (Go-Live Report)

작성 주체: PM
핵심 내용: 오픈 완료 확인, 초기 안정화 기간(통상 2~4주) 모니터링 결과, 오픈 후 발생한 이슈 및 조치 결과, 안정화 완료 선언
주의사항: 오픈 직후에는 집중 모니터링 체제를 유지해야 합니다. War Room 운영을 권장합니다.

7. 종료 단계 — 납품 및 종료

프로젝트를 공식적으로 마무리하고 운영팀에 인수인계하는 단계입니다.

7-1. 사용자 매뉴얼 (User Manual)

작성 주체: 기술 작가(Technical Writer)/개발자
핵심 내용: 일반 사용자 대상, 화면별 조작 방법, 자주 묻는 질문(FAQ), 오류 발생 시 대처 방법
주의사항: 사용자 매뉴얼은 실제 최종 화면을 캡처하여 작성해야 합니다. 개발 중에 작성한 매뉴얼은 화면이 바뀌면 폐기물이 됩니다.

7-2. 운영자 매뉴얼 (Administrator Manual)

작성 주체: 개발자/인프라 엔지니어
핵심 내용: 시스템 관리자 대상, 배포 절차, 설정 파일 설명, 모니터링 방법, 로그 확인, 정기 점검 항목, 장애 1차 대응 절차
주의사항: 운영자 매뉴얼 없이 인수인계하면 운영팀이 장애 시 개발팀에 의존하게 됩니다.

7-3. 시스템 운영 가이드 (System Operation Guide)

작성 주체: 인프라 엔지니어/DevOps
핵심 내용: 서버 구성 및 스펙 목록, 주요 프로세스 관리 방법, 백업/복구 정책, 용량 계획(Capacity Planning), 보안 패치 관리
주의사항: 인프라 구성도를 최신 상태로 유지하고 형상관리 도구에 저장해야 합니다.

7-4. 장애 대응 시나리오 (Runbook)

작성 주체: 인프라 엔지니어/DevOps
핵심 내용: 예상 장애 유형별 증상/원인/대응 절차, 에스컬레이션 기준, 복구 시간 목표(RTO)/복구 시점 목표(RPO)
주의사항: Runbook은 장애가 발생했을 때 경험이 없는 담당자도 따라 할 수 있도록 구체적으로 작성해야 합니다.

7-5. 소프트웨어 구성 관리 목록 (SCM, Software Configuration Management)

작성 주체: 형상관리 담당자/PM
핵심 내용: 납품 소스 코드 목록(파일명/버전), 바이너리 목록, 오픈소스 라이선스 목록, 빌드 방법, 설정 파일 목록
주의사항: 오픈소스 라이선스 위반은 법적 분쟁으로 이어질 수 있습니다. 납품 전 오픈소스 점검(SBOM 생성)을 수행해야 합니다.

7-6. 완료 보고서 (Project Completion Report)

작성 주체: PM
핵심 내용: 전체 프로젝트 요약, 목표 달성 여부, 비용 결산(계획 대비 실적), 일정 결산, 품질 결산, 주요 성과 및 도전 요인
주의사항: 완료 보고서는 납품 검수의 근거 자료입니다. 발주사 담당자의 최종 승인(인감 또는 전자 서명)을 받아야 합니다.

7-7. 하자보수 계획서 (Warranty/Maintenance Plan)

작성 주체: PM + 고객지원팀
핵심 내용: 하자보수 기간(통상 납품 후 1년), SLA 정의(응답 시간/처리 시간), 담당자 연락처, 하자 유형 구분(사용법 문의 vs 실제 결함), 패치 배포 절차
주의사항: 하자보수와 추가 개발을 명확히 구분해야 합니다. "사용법이 변경되었으니 수정해달라"는 요청은 하자보수가 아닙니다.

7-8. 프로젝트 교훈 (Lessons Learned)

작성 주체: PM + 프로젝트 팀 전원
핵심 내용: 잘된 점(Best Practices), 개선이 필요한 점, 반복하면 안 되는 실수, 적용한 도구/방법론 평가, 다음 프로젝트를 위한 권고사항
주의사항: 교훈 문서는 조직 지식 자산(Organizational Process Assets)입니다. 작성 후 팀 내부에서만 공유하지 말고 PMO(프로젝트 관리 오피스)에 등록하세요.

7-9. 지식이전 교육 자료 (Knowledge Transfer Materials)

작성 주체: 개발팀/분석팀
핵심 내용: 시스템 구조 설명 자료, 운영 팀 대상 교육 슬라이드, 실습 가이드, 자주 발생하는 문의 및 대응 방법
주의사항: 지식이전은 문서만으로는 부족합니다. 실습 교육을 병행하고, 운영팀이 독립적으로 운영할 수 있는 역량을 갖출 때까지 지원해야 합니다.

8. 공공 프로젝트 특화 산출물

공공기관이 발주하는 프로젝트에서는 법령 및 행정 지침에 따라 추가적인 산출물이 요구됩니다.

8-1. 정보화 전략계획서 (ISP, Information Strategy Plan)

개요: 중장기 IT 추진 로드맵 수립 문서
관련 지침: 행정안전부 "정보시스템 구축·운영 지침"
핵심 내용: 현황 진단, 정보화 비전/목표, 과제별 우선순위, 예산 추정, 추진 일정, 기대 효과
주의사항: ISP는 단독 사업으로 발주되는 경우가 많으며, ISP 결과를 기반으로 시스템 구축 사업이 발주됩니다.

8-2. 개인정보 영향평가서 (PIA, Privacy Impact Assessment)

법적 근거: 개인정보보호법 제33조 (일정 규모 이상 공공기관 의무)
핵심 내용: 개인정보 처리 항목, 수집 근거, 보존 기간, 보안 조치, 위험도 분석 및 개선 조치
주의사항: PIA 수행 기관은 개인정보 보호위원회가 지정한 평가 기관이어야 합니다.

8-3. 정보보호 계획서

관련 법령: 전자정부법, 정보통신망법, ISMS-P 인증 기준
핵심 내용: 보안 위협 분석, 보안 요구사항, 보안 아키텍처, 취약점 대응 계획, 보안 관제 방안
주의사항: ISMS-P 인증을 받아야 하는 시스템의 경우 인증 심사 기준과 연계하여 작성해야 합니다.

8-4. 소프트웨어 사업 대가 산정서

관련 법령: 소프트웨어 진흥법, "SW사업 대가 산정 가이드" (NIPA)
핵심 내용: 기능점수(FP, Function Point) 산정 내역, 보정 계수 적용, 투입 공수 산정, 단가 적용
주의사항: 공공사업에서 대가 산정은 제3자가 검토하는 경우가 많습니다. 산정 근거를 투명하게 작성해야 합니다.

8-5. 소프트웨어 감리 보고서 (SW Audit Report)

법적 근거: 소프트웨어 진흥법 제65조 (사업비 100억 원 이상 공공사업 의무)
핵심 내용: 단계별 감리(분석 감리 / 설계 감리 / 구현 감리 / 종료 감리), 감리 지적 사항, 조치 계획 및 결과
주의사항: 감리는 외부 감리 법인이 수행합니다. 감리 지적 사항은 반드시 조치해야 합니다.

8-7. 납품 확인서 (Delivery Acceptance)

핵심 내용: 최종 납품물 목록(소스 코드/문서/교육/라이선스 등), 각 항목별 납품 확인, 발주사 검수 담당자 서명
주의사항: 납품 확인서에 서명하면 대금 지급 조건이 충족됩니다. 미완료 항목이 있을 경우 조건부 수락 방식을 사전에 협의해야 합니다.

9. 산출물 관리 팁

9-1. 산출물 번호 체계

일관된 번호 체계는 산출물 관리의 기본입니다. 예시:

PJ-2024-001-분석-001  → 2024년 001번 프로젝트, 분석 단계, 001번 문서
PJ-2024-001-설계-005  → 2024년 001번 프로젝트, 설계 단계, 005번 문서

9-2. 형상관리 (Configuration Management)

기준선(Baseline) 설정: 각 단계 완료 시 승인된 산출물을 동결(Freeze)합니다.
변경 관리(Change Control): 기준선 이후 변경은 반드시 CCB(변경통제위원회)의 승인을 받아야 합니다.
버전 관리: 문서 버전을 v1.0, v1.1, v2.0 형식으로 관리하고, 주요 변경 이력을 문서 내에 기록합니다.

9-3. 도구 활용

용도	도구 예시
문서 협업	Confluence, Notion, Google Docs, SharePoint
소스 코드	GitHub, GitLab, Bitbucket
이슈 관리	Jira, Redmine, GitHub Issues
다이어그램	draw.io, Lucidchart, PlantUML, Mermaid
테스트 관리	TestRail, Zephyr, Xray
형상관리	SVN, Git + Git LFS

9-4. PMBOK 산출물 vs 한국형 산출물

PMBOK(PMI 프로젝트 관리 지식체계)에서 정의하는 산출물과 한국 현장에서 실제로 요구되는 산출물은 명칭과 구성이 다를 수 있습니다. 예를 들어, PMBOK의 "프로젝트 헌장(Project Charter)"에 해당하는 문서가 한국에서는 "착수보고서"나 "사업수행계획서"로 통용됩니다.

퀴즈: 실력을 확인해 보세요

퀴즈 1: RFP에서 기술제안서와 가격제안서를 분리하는 주된 이유는?

정답: 가격에 영향받지 않는 공정한 기술 평가를 보장하기 위해서입니다.

설명: 평가위원이 가격을 모른 채로 기술력을 먼저 평가하게 되면, 가격이 높더라도 기술력이 우수한 업체가 공정하게 평가받을 수 있습니다. 반대로 가격 정보가 먼저 노출되면 평가 기준이 왜곡될 수 있습니다. 이를 "이중 봉투(Two-Envelope)" 방식이라고 부릅니다.

퀴즈 2: SRS에서 MoSCoW 기법의 'M'과 'W'는 각각 무엇을 의미하나요?

정답: M = Must Have (반드시 구현해야 하는 필수 요구사항), W = Won't Have (이번 버전에서는 구현하지 않는 요구사항

설명: MoSCoW는 Must Have, Should Have, Could Have, Won't Have의 앞 글자를 딴 우선순위 결정 기법입니다. Won't Have는 "필요 없다"는 의미가 아니라 "이번 범위에서 제외한다"는 의미입니다. 나중에 다음 버전에서 구현될 수 있습니다.

퀴즈 3: 요구사항 추적성 매트릭스(RTM)의 주요 목적은 무엇인가요?

정답: 요구사항 ID와 설계/개발/테스트 산출물 ID를 매핑하여 각 요구사항이 빠짐없이 구현되고 검증되었는지 추적하는 것입니다.

설명: RTM(Requirements Traceability Matrix)을 관리하면 "이 기능이 왜 만들어졌는가", "이 요구사항은 어떤 테스트 케이스로 검증되었는가"를 즉시 확인할 수 있습니다. 공공사업 감리에서 RTM은 필수 점검 항목입니다.

퀴즈 4: 컷오버(Cutover) 계획서에서 롤백(Rollback) 계획이 반드시 필요한 이유는?

정답: 오픈 당일 예상치 못한 치명적 문제가 발생했을 때 신속하게 이전 시스템으로 되돌아가기 위해서입니다.

설명: 아무리 철저한 테스트를 거쳐도 실제 운영 환경에서만 발생하는 문제가 있을 수 있습니다. 롤백 계획이 없다면 오픈 후 장애 발생 시 복구에 수 시간에서 수십 시간이 걸릴 수 있습니다. 롤백 시점(No-Return Point), 롤백 절차, 데이터 복구 방법이 명확해야 합니다.

퀴즈 5: 소프트웨어 감리가 의무화되는 공공사업의 기준은?

정답: 소프트웨어 진흥법에 따라 사업비 100억 원 이상인 공공 정보화 사업은 단계별 감리가 의무입니다.

설명: 단계별 감리는 분석 감리, 설계 감리, 구현 감리, 종료 감리로 구성됩니다. 감리는 한국소프트웨어산업협회(KOSA) 등에 등록된 감리 법인이 수행하며, 감리 지적 사항을 조치하지 않으면 다음 단계로 진행할 수 없습니다. 100억 미만 사업도 자율적으로 감리를 수행하도록 권고합니다.

퀴즈 6: 하자보수와 유지보수(운영)의 핵심 차이는 무엇인가요?

정답: 하자보수는 납품 당시 계약 범위에 포함된 기능이 정상 동작하지 않는 결함을 무상으로 수정하는 것이고, 유지보수는 계약 범위를 벗어나는 기능 변경/추가에 대해 별도 계약을 통해 유상으로 수행하는 것입니다.

설명: 현장에서 발주사가 하자보수 기간 중 새로운 기능 추가나 요구사항 변경을 "결함 수정"으로 요구하는 경우가 잦습니다. 이를 방지하려면 계약서에 하자의 정의를 명확히 하고, UAT에서 최종 기능 범위를 확정 서명을 받아두어야 합니다.

퀴즈 7: 개인정보 영향평가(PIA)가 의무화되는 공공기관의 기준은?

정답: 개인정보보호법 제33조에 따라 5만 명 이상의 정보주체에 관한 개인정보를 처리하거나, 민감정보 또는 고유식별정보를 처리하는 공공기관은 PIA를 수행해야 합니다.

설명: PIA는 단순히 문서를 작성하는 것이 아니라 실제로 개인정보 처리 과정의 위험 요소를 분석하고 대응 방안을 수립하는 활동입니다. PIA 결과는 개인정보 보호위원회에 제출해야 하며, 미이행 시 과태료가 부과될 수 있습니다.

마치며

IT 프로젝트 산출물은 단순히 "감리를 통과하기 위한 서류"가 아닙니다. 각 산출물은 프로젝트 팀이 올바른 방향으로 나아가고 있는지 확인하는 체크포인트이며, 이해관계자 간의 합의 증거이고, 나중에 시스템을 유지보수하는 팀에게는 귀중한 지식 자산입니다.

산출물을 형식적으로 작성하는 것이 아니라, 실제로 프로젝트에 가치를 제공하는 문서를 만드는 습관을 들이세요. 그것이 좋은 PM과 평범한 PM의 차이를 만듭니다.