들어가며
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-6. 저작권 귀속 확인서
- **핵심 내용**: 프로젝트 산출물(소스 코드, 문서, 데이터)의 저작권이 발주사에 귀속됨을 확인하는 문서
- **주의사항**: 수주사가 재사용 예정인 공통 모듈/라이브러리의 저작권 처리 방식을 사전에 협의하고 명기해야 합니다.
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)"에 해당하는 문서가 한국에서는 "착수보고서"나 "사업수행계획서"로 통용됩니다.
퀴즈: 실력을 확인해 보세요
**정답:** 가격에 영향받지 않는 공정한 기술 평가를 보장하기 위해서입니다.
**설명:** 평가위원이 가격을 모른 채로 기술력을 먼저 평가하게 되면, 가격이 높더라도 기술력이 우수한 업체가 공정하게 평가받을 수 있습니다. 반대로 가격 정보가 먼저 노출되면 평가 기준이 왜곡될 수 있습니다. 이를 "이중 봉투(Two-Envelope)" 방식이라고 부릅니다.
**정답:** M = Must Have (반드시 구현해야 하는 필수 요구사항), W = Won't Have (이번 버전에서는 구현하지 않는 요구사항
**설명:** MoSCoW는 Must Have, Should Have, Could Have, Won't Have의 앞 글자를 딴 우선순위 결정 기법입니다. Won't Have는 "필요 없다"는 의미가 아니라 "이번 범위에서 제외한다"는 의미입니다. 나중에 다음 버전에서 구현될 수 있습니다.
**정답:** 요구사항 ID와 설계/개발/테스트 산출물 ID를 매핑하여 각 요구사항이 빠짐없이 구현되고 검증되었는지 추적하는 것입니다.
**설명:** RTM(Requirements Traceability Matrix)을 관리하면 "이 기능이 왜 만들어졌는가", "이 요구사항은 어떤 테스트 케이스로 검증되었는가"를 즉시 확인할 수 있습니다. 공공사업 감리에서 RTM은 필수 점검 항목입니다.
**정답:** 오픈 당일 예상치 못한 치명적 문제가 발생했을 때 신속하게 이전 시스템으로 되돌아가기 위해서입니다.
**설명:** 아무리 철저한 테스트를 거쳐도 실제 운영 환경에서만 발생하는 문제가 있을 수 있습니다. 롤백 계획이 없다면 오픈 후 장애 발생 시 복구에 수 시간에서 수십 시간이 걸릴 수 있습니다. 롤백 시점(No-Return Point), 롤백 절차, 데이터 복구 방법이 명확해야 합니다.
**정답:** 소프트웨어 진흥법에 따라 사업비 100억 원 이상인 공공 정보화 사업은 단계별 감리가 의무입니다.
**설명:** 단계별 감리는 분석 감리, 설계 감리, 구현 감리, 종료 감리로 구성됩니다. 감리는 한국소프트웨어산업협회(KOSA) 등에 등록된 감리 법인이 수행하며, 감리 지적 사항을 조치하지 않으면 다음 단계로 진행할 수 없습니다. 100억 미만 사업도 자율적으로 감리를 수행하도록 권고합니다.
**정답:** 하자보수는 납품 당시 계약 범위에 포함된 기능이 정상 동작하지 않는 결함을 무상으로 수정하는 것이고, 유지보수는 계약 범위를 벗어나는 기능 변경/추가에 대해 별도 계약을 통해 유상으로 수행하는 것입니다.
**설명:** 현장에서 발주사가 하자보수 기간 중 새로운 기능 추가나 요구사항 변경을 "결함 수정"으로 요구하는 경우가 잦습니다. 이를 방지하려면 계약서에 하자의 정의를 명확히 하고, UAT에서 최종 기능 범위를 확정 서명을 받아두어야 합니다.
**정답:** 개인정보보호법 제33조에 따라 5만 명 이상의 정보주체에 관한 개인정보를 처리하거나, 민감정보 또는 고유식별정보를 처리하는 공공기관은 PIA를 수행해야 합니다.
**설명:** PIA는 단순히 문서를 작성하는 것이 아니라 실제로 개인정보 처리 과정의 위험 요소를 분석하고 대응 방안을 수립하는 활동입니다. PIA 결과는 개인정보 보호위원회에 제출해야 하며, 미이행 시 과태료가 부과될 수 있습니다.
마치며
IT 프로젝트 산출물은 단순히 "감리를 통과하기 위한 서류"가 아닙니다. 각 산출물은 프로젝트 팀이 올바른 방향으로 나아가고 있는지 확인하는 **체크포인트**이며, 이해관계자 간의 **합의 증거**이고, 나중에 시스템을 유지보수하는 팀에게는 **귀중한 지식 자산**입니다.
산출물을 형식적으로 작성하는 것이 아니라, 실제로 프로젝트에 가치를 제공하는 문서를 만드는 습관을 들이세요. 그것이 좋은 PM과 평범한 PM의 차이를 만듭니다.
현재 단락 (1/238)
IT 프로젝트를 성공적으로 완수하려면 코드를 잘 작성하는 것만큼이나 **산출물(Deliverables)** 을 체계적으로 생산하고 관리하는 것이 중요합니다. 한국 IT 현장에서는 ...