같은 프로젝트, 두 번의 검수일.
첫 번째 현장. 개발은 "다 만들었습니다"라고 합니다. 그런데 발주사는 "이건 우리가 원한 게 아니다"라고 합니다. 시작할 때 합의한 문서가 없으니, 무엇이 '완료'인지를 두고 말이 엇갈립니다. 검수는 감정 싸움이 되고, 잔금 청구는 미뤄지고, 누구의 책임인지 가릴 근거가 없습니다.
두 번째 현장. 같은 상황이지만 이 팀에는 요구사항정의서가 있습니다. 요구ID마다 인수기준이 한 줄로 적혀 있고, 검수일에는 그 기준을 하나씩 짚으며 합격/조건부/불합격을 표시합니다. 합격분은 검수확인서에 서명되어 잔금 청구의 근거가 되고, 미충족분은 별도 하자 목록으로 빠져 기한과 함께 관리됩니다. 배포 내용은 릴리즈노트로, 한 달 운영 결과는 SLA 리포트로 정리되어 발주사에 전달됩니다.
차이는 일을 더 많이 한 게 아닙니다. 시작과 끝을 같은 문장으로 묶어 둔 것 — 그 문서들이 돈과 책임의 경계를 그어 줍니다. 이 모듈은 그 네 문서를 실제 양식으로 다룹니다.
- 1요구사항정의서를 요구ID·기능/비기능·인수기준·우선순위 구조로 작성하고, 그것이 곧 검수 기준이 됨을 설명할 수 있다
- 2검수확인서의 구성요소(완료 확인·서명·대금/하자 기산점)와 미충족 항목을 분리 기재하는 이유를 안다
- 3릴리즈노트에 변경사항·영향·롤백을 담아 운영 문서로 작성할 수 있다
- 4SLA 리포트를 지표·목표·실적·위반·개선 축으로 작성하고, 달성했어도 추세·리스크를 보고할 수 있다
- 5네 문서가 한국 SI/SM 계약·운영에서 갖는 무게(돈·책임·신뢰)를 설명할 수 있다
시작과 끝을 잇는 한 줄 — 요구사항정의서
요구사항정의서는 곧 검수 기준표다
프로젝트가 무너지는 가장 흔한 이유는 기술이 아니라 '완료'의 정의가 사람마다 다른 것입니다. 요구사항정의서는 그 정의를 시작 시점에 못 박는 문서입니다. 핵심은 각 요구를 '설명'이 아니라 검증 가능한 인수기준으로 적는 것입니다. 인수기준이 있으면 검수일에 누가 봐도 같은 판정이 나옵니다 — 즉 시작 문서가 그대로 끝 문서(검수)의 합격선이 됩니다.
좋은 요구사항정의서의 한 행은 이렇게 구성됩니다.
| 항목 | 뜻 | 작성 요령 |
|---|---|---|
| 요구ID | 추적용 고유번호(REQ-001) | 검수·테스트·변경에서 이 ID로 참조 |
| 구분 | 기능 / 비기능 | 기능=무엇을 한다, 비기능=얼마나 잘 한다(성능·보안·가용성) |
| 요구사항명 | 한 줄 요약 | "주문 결제 처리" |
| 상세 설명 | 동작·범위 | 무엇을 포함하고 무엇을 제외하는지까지 |
| 인수기준 | 완료로 인정하는 검증 조건 | "정상 카드로 3초 내 승인, 실패 시 사유 코드 표시" |
| 우선순위 | 필수 / 중요 / 선택(MoSCoW의 Must/Should/Could) | 일정 압박 시 무엇을 먼저 보장할지 |
비기능 요구를 빠뜨리는 것이 단골 실수입니다. "로그인된다"는 기능이지만 "1초 내, 동시 1000명, 99.9% 가용"은 비기능이며, 이것이 빠지면 검수 때 "느려도 되긴 된다"는 회색지대가 생깁니다.
그림: 하나의 요구ID가 정의→검수→릴리즈→SLA를 관통하며, 같은 요구ID·서비스명으로 어휘를 통일해야 분쟁 시 추적이 된다.
다음은 실제 양식에 가까운 요구사항정의서 표 예시입니다.
| 요구ID | 구분 | 요구사항명 | 인수기준 | 우선순위 |
|---|---|---|---|---|
| REQ-001 | 기능 | 회원 로그인 | 올바른 자격증명으로 3초 내 로그인, 5회 실패 시 계정 잠금 | 필수(Must) |
| REQ-002 | 기능 | 주문 결제 | 정상 카드로 승인 완료, 실패 시 사유 코드와 재시도 안내 표시 | 필수(Must) |
| REQ-003 | 기능 | 주문 내역 검색 | 기간·상태 조건으로 검색, 결과 페이지당 20건 정렬 노출 | 중요(Should) |
| REQ-101 | 비기능 | 성능 | 주문 조회 응답 평균 1초 이내, 피크 동시 사용자 500명 처리 | 필수(Must) |
| REQ-102 | 비기능 | 가용성 | 월 가용성 99.9% 이상, 정기 점검창 사전 공지 | 필수(Must) |
| REQ-103 | 비기능 | 보안 | 비밀번호 단방향 암호화 저장, 개인정보 전송 구간 암호화 | 필수(Must) |
이 표가 작성되어 발주사와 합의되면, 검수일에는 같은 요구ID를 그대로 가져와 합격 여부만 표시하면 됩니다. 시작 문서가 끝 문서로 흐르는 것 — 이것이 산출물 관리의 핵심입니다.
요구사항정의서의 품질은 인수기준 한 칸에서 갈립니다. "잘 된다 · 빠르다 · 안정적이다"는 검수일에 사람마다 다른 판정을 부르는 회색지대입니다. 같은 요구라도 조건(언제) + 동작(무엇을) + 기대결과(숫자·상태) + 실패 시 처리로 적으면 누가 봐도 같은 합격/불합격이 나옵니다. 특히 성능·가용성·보안 같은 비기능 요구는 반드시 숫자로 못 박아야 회색지대가 사라집니다.
끝을 확정하는 서명 — 검수확인서
검수확인서는 감정이 아니라 기준으로 서명된다
검수확인서(검수조서)는 "납품물이 합의된 인수기준을 충족했음을 발주사가 공식 인정한다"는 문서입니다. 한국 SI/SM 계약에서 이 서명은 단순한 마무리가 아니라 계약상 권리·의무가 확정되는 기준점입니다.
- 대금 기산점: 검수 합격 시점부터 잔금 청구가 가능해집니다.
- 하자담보 기산점: 하자보수(무상 유지보수) 기간이 검수일을 기준으로 시작됩니다.
- 지체상금 종료점: 납기 지연 산정이 검수 완료로 마무리됩니다.
그래서 검수확인서는 "수고했다"는 분위기가 아니라 요구ID별 인수기준 충족 여부라는 객관적 근거 위에서 서명되어야 합니다. 충족하지 못한 항목은 무리하게 합격 처리하지 말고, 별도 하자 목록으로 분리해 보수 기한과 함께 기재합니다. 그래야 조건부 검수가 가능하고, 나중에 책임 소재가 명확해집니다.
검수확인서의 기본 구조는 다음과 같습니다.
[ 검수확인서 ]
1. 사업 개요
- 사업명 / 계약번호 / 계약기간 / 발주사 / 수행사
2. 검수 대상 산출물
- 산출물 목록(소스·문서·설치 결과 등)과 버전
3. 검수 결과 (요구ID 기준)
요구ID | 인수기준 충족 | 판정 | 비고
REQ-001 | 충족 | 합격 |
REQ-002 | 충족 | 합격 |
REQ-003 | 일부 미충족 | 조건부 합격 | 하자목록 H-01 참조
REQ-102 | 충족 | 합격 |
4. 하자 목록 (미충족 항목 분리 기재)
하자ID | 내용 | 보수 기한 | 책임
H-01 | 검색 정렬 누락 | 2주 이내 | 수행사
5. 종합 판정 : 조건부 합격 (하자 보수 완료 후 최종 확정)
6. 확인
발주사 (서명/날인) ______ 일자 ______
수행사 (서명/날인) ______ 일자 ______
핵심은 3번과 4번의 분리입니다. 합격분은 대금·하자 기산점을 발생시키고, 미충족분은 기한이 걸린 하자로 따로 관리됩니다. 모호하게 전부 합격시키는 것이 분쟁의 씨앗입니다.
배포를 요약하는 문서 — 릴리즈노트
릴리즈노트는 '바뀐 것'과 '되돌리는 법'을 함께 담는다
릴리즈노트는 한 번의 배포에서 무엇이·왜·어떤 영향으로 바뀌었고, 잘못되면 어떻게 되돌리는가를 요약하는 운영 문서입니다. 변경관리의 산출물이자, 새벽 당직자가 장애 시 가장 먼저 펼치는 문서이기도 합니다.
빠지기 쉬운 두 가지가 영향 범위와 롤백입니다. "기능 추가" 한 줄만 적으면, 그 변경이 어떤 서비스·데이터에 영향을 주는지, 문제가 생겼을 때 어떻게 이전 상태로 돌아가는지 알 수 없습니다. 영향과 롤백이 없는 릴리즈노트는 변경 일기일 뿐, 운영 문서가 아닙니다.
릴리즈노트의 권장 구성은 다음과 같습니다.
[ 릴리즈노트 ] 결제 서비스 v2.3.0 (배포일: 2026-06-20 02:00, 점검창 02:00-03:00)
■ 변경사항
- [신규] 해외 카드 결제 지원
- [개선] 주문 조회 응답 속도 평균 1.8초 → 0.9초
- [수정] 5회 로그인 실패 시 계정 잠금 미동작 버그 수정
■ 영향 범위
- 영향 서비스 : 결제, 주문 조회
- DB 변경 : payment 테이블 컬럼 추가(마이그레이션 V23)
- 다운타임 : 점검창 내 약 5분(배포 순단)
■ 롤백 방법
- 애플리케이션 : 이전 태그 v2.2.4로 재배포
- DB : 마이그레이션 V23 되돌림 스크립트 실행(데이터 보존 확인)
- 확인 지점 : 결제 승인 1건 성공 + 주문 조회 정상 응답
■ 배포 담당 / 승인(CAB)
- 작업자 : 홍길동 / 승인 : 변경자문위원회 2026-06-18 승인
[신규]·[개선]·[수정] 같은 분류 태그를 붙이면 읽는 사람이 영향을 빠르게 가늠합니다. 무엇보다 롤백 확인 지점까지 적어야, 되돌린 뒤 "정상으로 돌아왔는지"를 같은 기준으로 판정할 수 있습니다.
약속을 보고하는 문서 — SLA 리포트
SLA 리포트는 '약속 대비 실제'를 판정하고 행동으로 잇는다
SLA(서비스수준협약)는 발주사와 수행사가 합의한 서비스 품질의 약속입니다. SLA 리포트는 그 약속을 주기(보통 월 단위)마다 목표 대비 실적으로 판정하고, 위반이나 추세 악화가 있으면 원인과 개선 조치로 잇는 보고서입니다.
흔한 오해는 "목표를 넘겼으니 잘했다"로 끝내는 것입니다. SLA 리포트의 가치는 숫자 자체가 아니라 판정과 다음 행동에 있습니다. 달성했어도 추세가 나빠지거나 특정 구간에 장애가 몰렸다면 그 리스크를 적어야 하고, 위반했다면 위반 시간·영향·원인·재발방지(문제관리 연계)·필요 시 서비스 크레딧까지 기재해야 합니다. 그래야 리포트가 책임 회피가 아니라 신뢰를 관리하는 도구가 됩니다.
다음은 실제 양식에 가까운 SLA 리포트 표 예시(2026년 6월 기준)입니다.
| 지표(SLA 항목) | 측정 정의 | 목표(Target) | 실적(Actual) | 판정 | 비고/개선 |
|---|---|---|---|---|---|
| 서비스 가용성 | 월 정상 가동 시간 비율 | 99.9% | 99.95% | 충족 | 추세 양호, 유지 |
| 평균 응답시간 | 주문 조회 평균 응답 | 1초 이내 | 0.9초 | 충족 | 피크 구간 1.4초 관찰, 캐시 검토 |
| 인시던트 1차 응답 | 신고 후 초동 대응까지 | 15분 이내 | 12분 | 충족 | 야간 자동 호출 도입 효과 |
| 중대장애 복구시간 | P1 장애 복구까지 | 4시간 이내 | 5시간 20분 | 위반 | H-DB 장애 1건, 아래 위반 상세 |
| 변경 성공률 | 롤백 없이 완료한 변경 비율 | 95% 이상 | 96.4% | 충족 | 점검창 준수 유지 |
위반이 발생한 항목은 표에 더해 위반 상세를 따로 적습니다.
[ SLA 위반 상세 ]
- 항목 : 중대장애 복구시간 (목표 4시간 / 실적 5시간 20분)
- 발생일시 : 2026-06-11 03:10 ~ 08:30
- 영향 : 결제 서비스 약 5시간 20분 중단, 영향 고객 약 2,400명
- 원인 : DB 디스크 용량 임계치 초과로 쓰기 실패(모니터링 임계 미설정)
- 재발방지 : 디스크 사용량 80% 경보 추가, 문제관리 PRB-073 등록
- 조치 : 계약상 서비스 크레딧 산정 대상(별첨 정산표 참조)
이렇게 적으면 발주사는 "왜 위반했고, 무엇을 바꿔 다시는 안 나게 하는지"를 한눈에 봅니다. 충족 항목조차 '피크 1.4초 관찰' 같은 신호를 남겨, 리포트가 다음 달의 선제 조치로 이어지게 만듭니다.
예시 산출물 다운로드
직접 해보기 — 요구사항에서 검수까지 한 줄로 잇기
아래 요구사항 한 건을 받아, 네 문서가 어떻게 한 줄로 이어지는지 직접 채워 보세요. 빈칸을 채운 모범 흐름은 ObserveBlock에 있습니다.
[주어진 요구]
REQ-002 기능 주문 결제
(1) 인수기준을 검증 가능한 문장으로 쓰면?
(2) 검수일, 이 요구가 '조건부 합격'이라면 검수확인서에 어떻게 기재하나?
(3) 이 결제 기능을 배포할 때 릴리즈노트에 꼭 넣을 '영향 범위'와 '롤백' 한 줄은?
(4) 운영 한 달 뒤 SLA 리포트에서 이 결제 서비스와 직접 닿는 지표 하나는?
핵심 감각: 하나의 요구ID가 시작(정의)부터 끝(검수)·운영(릴리즈·SLA)까지 같은 언어로 추적되어야 한다는 것입니다.
REQ → 인수기준 → 검수 → 릴리즈노트 → SLA- (1) 인수기준: "정상 카드로 결제 시 3초 내 승인 완료, 실패 시 사유 코드와 재시도 안내를 표시한다" — 누가 봐도 같게 판정 가능한 검증 문장
- (2) 검수확인서: REQ-002 판정란에 "조건부 합격" 표시 + 미충족분(예: 해외 카드 미지원)을 하자목록 H-xx로 분리, 보수 기한·책임 명시
- (3) 릴리즈노트 영향: "영향 서비스=결제·주문, DB=payment 컬럼 추가" / 롤백: "이전 태그 재배포 + 마이그레이션 되돌림, 결제 1건 성공으로 확인"
- (4) SLA 지표: "서비스 가용성 99.9%" 또는 "평균 응답시간 1초 이내" 등 결제 서비스 품질을 직접 측정하는 항목
- 핵심 감각: 요구ID(REQ-002) 하나가 정의→검수→릴리즈→SLA를 관통한다 — 문서가 따로 노는 게 아니라 한 줄로 추적된다
현장에서 자주 보는 함정
증상: 검수 회의에서 개발은 "요청대로 만들었다", 발주사는 "이건 우리가 원한 게 아니다"라며 평행선을 달립니다. 또는 매달 SLA 리포트를 보내지만 "다 충족"이라는 표만 있고, 정작 잦아지는 장애나 느려지는 응답에 대한 조치가 없습니다.
원인: (1) 시작 시점에 검증 가능한 인수기준을 합의하지 않아 '완료'의 정의가 사람마다 다릅니다. (2) SLA 리포트가 판정과 개선이 아니라 보고용 숫자 나열에 머물러, 위반·추세 악화가 다음 행동으로 이어지지 않습니다.
해결 방향:
- 요구사항정의서의 모든 요구에 인수기준을 1행씩 붙이고, 발주사 서명으로 합의한다. 이 표가 그대로 검수 기준표가 된다.
- 검수확인서는 요구ID별 충족 여부로 작성하고, 미충족은 별도 하자 목록으로 분리(조건부 합격)한다 — 전부 합격 처리하지 않는다.
- SLA 리포트는 충족 항목에도 추세·리스크를 남기고, 위반에는 원인·재발방지(문제관리 연계)·서비스 크레딧까지 적어 행동으로 잇는다.
- 모든 문서가 같은 요구ID·서비스명으로 묶이도록 어휘를 통일한다 — 그래야 분쟁 시 추적이 된다.
문서는 일을 늘리는 형식이 아니라, 돈과 책임의 경계를 미리 그어 분쟁을 없애는 장치입니다.
한국 SI/SM 현장에서 이 네 문서는 "있으면 좋은 자료"가 아니라 계약 이행의 증거입니다. 발주사·원청의 사업관리(PM/PMO)나 운영(SM) 담당자에게, 요구사항정의서는 범위를 묶는 닻이고, 검수확인서는 대금·하자담보의 기산점이며, 릴리즈노트는 변경의 추적 기록, SLA 리포트는 서비스 수준을 증명하는 정기 보고입니다.
협력사(하도급) 엔지니어가 실제 코드를 짜더라도, 이 문서들의 품질과 정합성에 대한 책임은 관리자에게 있습니다. 인수기준 없는 요구사항정의서는 검수에서 무력하고, 하자를 뭉뚱그린 검수확인서는 잔금·분쟁에서 발주사·수행사 모두를 위험에 빠뜨립니다. SLA 리포트를 '충족' 도장만 찍어 보내는 관리자는, 정작 위반이 누적될 때 신뢰를 잃습니다.
그래서 관리 직무 면접과 실무에서 "요구사항부터 검수·운영보고까지 산출물을 어떻게 잇느냐"는 단골 질문입니다. 기술을 아는 관리자는 협력사가 만든 문서가 형식만 갖췄는지, 실제로 추적·판정·책임을 담고 있는지를 가려낼 수 있습니다 — 그것이 이 모듈이 겨냥하는 역량입니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — 요구사항정의서가 묶어 두는 범위를 정의하는 원리
- 품질과 검수 — 인수기준으로 산출물을 합격 처리하는 품질·검수 프로세스
- 산출물 체계 지도 — 이 네 문서가 단계별로 어디에 놓이는지 보여주는 산출물 지도
다음 모듈에서는 이 문서들이 실제로 만들어지고 공유되는 무대 — 일정·이슈·산출물을 함께 굴리는 ITSM/협업 도구 지형(Jira·Redmine·ServiceNow·Confluence 등)을 한 장의 지도로 정리합니다.