같은 프로젝트, 두 번의 검수일.
첫 번째 현장. 개발은 "다 만들었습니다"라고 합니다. 그런데 발주사는 "이건 우리가 원한 게 아니다"라고 합니다. 시작할 때 합의한 문서가 없으니, 무엇이 '완료'인지를 두고 말이 엇갈립니다. 검수는 감정 싸움이 되고, 잔금 청구는 미뤄지고, 누구의 책임인지 가릴 근거가 없습니다.
두 번째 현장. 같은 상황이지만 이 팀에는 요구사항정의서가 있습니다. 요구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·서비스명으로 묶이도록 어휘를 통일한다 — 그래야 분쟁 시 추적이 된다.
문서는 일을 늘리는 형식이 아니라, 돈과 책임의 경계를 미리 그어 분쟁을 없애는 장치입니다.
심화 — 문서의 빈칸은 힘이 센 쪽이 채운다
심화: 같은 달 가용성이 99.92%와 99.85%로 나오는 이유 — 측정 정의의 정치
SLA 리포트의 숫자는 하나처럼 보이지만, 측정 정의를 합의하지 않으면 같은 달에 두 개의 숫자가 존재하게 됩니다. 수행사 모니터링은 99.92%인데 발주사 APM은 99.85%를 가리키고, 목표가 99.9%라면 이 0.07%p 차이가 곧 페널티 유무를 가릅니다. 앞의 리포트 표에 '측정 정의' 칸이 있는 이유가 바로 이것입니다.
- 숫자가 갈라지는 지점은 정해져 있습니다: (1) 측정 도구와 위치 — 서버 안에서 재느냐, 사용자 쪽에서 재느냐. (2) 점검창 처리 — 사전 공지된 정기 점검 시간을 가동 시간 분모에서 제외하느냐. (3) 장애 시간의 기산점 — 장애 '발생' 시각부터냐, '신고 접수' 시각부터냐, 복구 '확인' 시각까지냐. (4) 부분 장애의 환산 — 일부 기능만 죽었을 때 전체 중단으로 치느냐. 이 네 가지가 계약서에 없으면 위반이 걸린 달마다 숫자 협상이 벌어집니다.
- 자기 채점 구조의 긴장: 통상 측정과 보고는 수행사가 합니다. 감점당할 쪽이 감점 근거를 산출하는 구조입니다. 이 구조가 신뢰를 유지하려면 측정 로직이 발주사에게 투명해야 합니다 — 어떤 지표를 어느 도구에서 어떤 계산식으로 뽑는지를 리포트에 명기하고, 발주사가 원하면 원천 데이터를 열람할 수 있어야 합니다. 결과 숫자만 적은 리포트는 충족일 때는 문제없지만, 위반선 근처에 가는 순간 숫자 자체가 다툼이 됩니다.
- 측정 정의는 운영 개시 전에 못 박습니다: SLA 본문에 지표별 측정 도구·계산식·점검창 처리·기산점을 명기하고, 첫 달 리포트에서 양쪽 숫자를 대조해 차이를 조정하는 캘리브레이션을 거치는 것이 실전 순서입니다. 인수기준과 같은 원리입니다 — 판정 기준은 판정할 일이 생기기 전에 합의되어야 기준이고, 생긴 뒤에 정하면 협상입니다.
상황: 잔금 지급이 걸린 최종 검수일이었습니다. 요구ID 46건 중 44건 합격, 2건이 조건부 합격으로 하자 목록에 올라갔습니다. 그런데 발주사 담당이 목록을 채우며 말했습니다. "이왕 하자 보수하시는 김에, 관리자 화면에 부서별 집계 엑셀 다운로드도 넣어 주세요. H-03으로 적을게요. 어차피 보수 기간에 하시면 되잖아요." PM은 순간 멈칫했지만 — 오늘 서명을 못 받으면 잔금이 다음 분기로 밀린다는 생각에 — H-03을 그대로 두고 서명을 받았습니다. 하자보수 기간 석 달 동안 이런 항목이 세 건 더 늘었고, 팀은 무상으로 신규 기능을 개발하는 처지가 됐습니다.
원인: 하자와 신규 요구의 경계가 문서에서 지워졌습니다. 하자는 '합의된 인수기준을 충족하지 못한 것'이고, 신규 기능은 '인수기준에 애초에 없던 것'입니다. 그런데 이 검수확인서의 하자 목록에는 대응 요구ID 칸이 없었고, 그 빈칸을 서명이 급한 쪽이 아니라 급하지 않은 쪽이 채웠습니다. 서명을 기다리는 쪽은 협상력이 가장 약한 상태라는 검수 절차의 힘의 비대칭이, 문서의 느슨함을 파고든 것입니다.
진단: 하자 목록의 각 항목을 요구사항정의서와 대조합니다. H-01·H-02는 각각 특정 요구ID의 인수기준 미충족으로 추적되지만, H-03(엑셀 다운로드)은 대응하는 요구ID가 없습니다 — 문서상으로도 하자가 아니라 신규 요구임이 판별됩니다. 이 대조표가 있으면 다툼은 "해주냐 마느냐"의 감정 문제에서 "이 항목의 근거 요구ID가 무엇이냐"는 문서 문제로 바뀝니다.
해결: 요구ID 대조표를 근거로 정리한 공문을 보냅니다 — H-03과 유사 항목 3건은 인수기준에 대응 근거가 없으므로 하자가 아니라 신규 요구이며, 변경 절차(비용·일정 산정 후 합의)로 전환을 요청한다는 내용입니다. 이미 서명된 검수확인서를 뒤집는 것이 아니라, 하자 목록 중 요구ID 없는 항목의 성격을 재분류하는 협의입니다. 그리고 다음 검수부터 양식을 고칩니다 — 하자 목록에 대응 요구ID 칸을 필수로 넣고, 요구ID를 적을 수 없는 항목은 하자 목록에 올리지 않는다를 검수 규칙으로 사전 합의합니다. 검수일의 즉석 협상을 막는 것은 담력이 아니라 양식입니다.
한국 SI/SM 현장에서 이 네 문서는 "있으면 좋은 자료"가 아니라 계약 이행의 증거입니다. 발주사·원청의 사업관리(PM/PMO)나 운영(SM) 담당자에게, 요구사항정의서는 범위를 묶는 닻이고, 검수확인서는 대금·하자담보의 기산점이며, 릴리즈노트는 변경의 추적 기록, SLA 리포트는 서비스 수준을 증명하는 정기 보고입니다.
협력사(하도급) 엔지니어가 실제 코드를 짜더라도, 이 문서들의 품질과 정합성에 대한 책임은 관리자에게 있습니다. 인수기준 없는 요구사항정의서는 검수에서 무력하고, 하자를 뭉뚱그린 검수확인서는 잔금·분쟁에서 발주사·수행사 모두를 위험에 빠뜨립니다. SLA 리포트를 '충족' 도장만 찍어 보내는 관리자는, 정작 위반이 누적될 때 신뢰를 잃습니다.
그래서 관리 직무 면접과 실무에서 "요구사항부터 검수·운영보고까지 산출물을 어떻게 잇느냐"는 단골 질문입니다. 기술을 아는 관리자는 협력사가 만든 문서가 형식만 갖췄는지, 실제로 추적·판정·책임을 담고 있는지를 가려낼 수 있습니다 — 그것이 이 모듈이 겨냥하는 역량입니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — 요구사항정의서가 묶어 두는 범위를 정의하는 원리
- 품질과 검수 — 인수기준으로 산출물을 합격 처리하는 품질·검수 프로세스
- 산출물 체계 지도 — 이 네 문서가 단계별로 어디에 놓이는지 보여주는 산출물 지도
다음 모듈에서는 이 문서들이 실제로 만들어지고 공유되는 무대 — 일정·이슈·산출물을 함께 굴리는 ITSM/협업 도구 지형(Jira·Redmine·ServiceNow·Confluence 등)을 한 장의 지도로 정리합니다.