공공 SI 검수 절차 — 감리 대응, 검수조서, 하자보수 기간의 품질 증거

개념

공공 사업에서 "인수"는 세 개의 다른 절차다

민간 제품 조직에서 인수는 보통 한 단계다. 공공 SI 에서는 이름이 비슷한 절차가 여러 겹이고, 구분하지 못하면 어느 문서를 누구에게 언제 내야 하는지 알 수 없다.

셋은 묻는 질문이 다르고, 결과의 힘도 다르다. 테스트 결과서는 근거이고, 감리 지적은 시정 요구이며, 검수는 대금과 사업 종료를 결정한다. 수행사 QA 가 이 구조를 모르면 "테스트를 다 했는데 왜 안 끝나느냐"는 상태에 빠진다.

모듈 31과의 경계 — 모듈 31(시험성적서 작성 실무)은 시험 결과를 문서로 만드는 일 이다(범위 정의·환경 기술·판정 기준·통계·법적 효력·오류 정정). 이 레슨은 그 문서를 받아 가는 쪽, 즉 발주처의 검수 절차 다. 성적서를 어떻게 쓰는지는 모듈 31, 그 성적서가 검수조서 어디에 붙는지는 여기다.

정보시스템 감리 — 법적 근거와 대상

정보시스템 감리는 관행이 아니라 법정 절차다. 근거는 「전자정부법」 제57조(행정기관등의 정보시스템 감리) 다. 행정기관등의 장은 대통령령으로 정하는 기준에 해당하는 정보시스템에 대해 감리법인 으로 하여금 감리를 하게 하여야 하고, 정당한 사유 없이 감리원의 업무에 개입하거나 간섭해서는 안 된다.

대상 기준은 「전자정부법 시행령」 제71조(정보시스템 감리의 대상) 에 있다. 국가법령정보센터에서 확인한 범위는 정보시스템 구축사업으로서 사업비가 5억원 이상인 경우, 대국민 서비스를 위한 행정·민원 업무 처리용 시스템, 여러 중앙행정기관등이 공동으로 구축·사용하는 시스템이다. 반대로 사업비 1억원 미만의 소규모 사업 으로서 감리의 비용 대비 효과가 낮다고 기관장이 인정하면 제외된다 (여기서 사업비는 총사업비에서 HW·SW 단순 구입비용을 뺀 금액이다).

감리의 세부 기준은 행정안전부 고시 「정보시스템 감리기준」 이 정한다. 국가법령정보센터에 등재된 행정규칙이며, 이 레슨 작성 시점에 조회된 판은 행정안전부고시 제2010-30호(2010. 5. 5. 시행) 로 표시됐다. 이후 개정 여부와 현행 고시 번호는 원문 확인 대상이다 — 사업에 적용할 때는 반드시 국가법령정보센터에서 현행 판을 다시 조회한다.

실무 가이드는 한국지능정보사회진흥원(NIA)의 정보시스템 감리자료실 에서 배포한다. 자료실에서 확인되는 문서는 「정보시스템 감리 발주관리가이드」·「감리수행가이드」(2022. 4. 개정 공지), 「SW사업자를 위한 정보시스템 감리준비 및 대응 가이드」(2023. 2. 6.), 「지능정보기술 감리 실무 가이드」(2023. 2. 6.), 매년 갱신되는 감리 대가 산정 계산기(2026년 1월판까지 확인)다. 이 중 두 번째가 감리를 "받는" 쪽이 무엇을 준비해야 하는지를 정리한 문서라 수행사 QA 에게 가장 직접적이다.

감리와 QA 는 무엇이 다른가

가장 흔한 오해는 "감리는 발주처가 부르는 외부 QA"라는 것이다. 겹치는 부분이 있지만 성격이 다르다.

독립성이 핵심이다. 감리원은 수행사의 품질 활동을 대신해 주는 사람도, 발주처의 요구를 대신 전달하는 사람도 아니다. 감리가 "우리 편"이 되기를 기대하고 대응하면 거의 항상 실패한다.

감리 단계는 관행적으로 착수(사업계획·요구사항 정의의 적정성), 중간(설계·구현의 요구사항 반영·진척·품질활동), 종료(과업 이행, 시험 결과, 산출물 완비, 이관·교육)로 나뉘고, 종료 단계의 지적은 곧 검수 지연이다. 다만 단계 명칭과 의무 횟수의 법적 근거 조문은 확인하지 못했다 — 원문 확인 대상이며, 적용 시에는 해당 사업의 감리계획서와 현행 감리기준 고시를 본다.

감리 지적사항 대응 — QA 가 실제로 하는 일

감리보고서의 지적사항은 대개 세 유형으로 나뉜다. 개선권고(필수) 는 조치하지 않으면 다음 단계와 검수에 영향을 주므로 조치 계획·조치 결과·증거를 함께 제출해야 한다. 개선권고(협의) 는 조치 여부를 발주처와 협의하고 그 협의 결과를 기록으로 남긴다. 참고사항 은 판단 근거만 남기고 넘어갈 수 있다.

QA 가 준비해야 하는 증거는 대개 네 가지로 수렴한다.

1. 요구사항 추적표   요구사항 ID ↔ 설계 ↔ 구현 ↔ 테스트 케이스 ↔ 수행 결과
                     "빠짐없이 반영했다"를 주장하는 유일한 방법 (레슨 4에서 만든다)
2. 테스트 수행 증거  계획서·케이스·실행 결과·결함 목록·조치 상태·재시험 결과
                     캡처는 언제 찍었는지 알 수 있어야 한다 (파일명에 날짜·빌드번호)
3. 결함 통계와 추이  발견·조치·잔여 건수, 심각도 분포, 미조치 사유와 계획
4. 시정조치 결과서   지적 번호 ↔ 조치 내용 ↔ 증거 위치 ↔ 조치일 ↔ 담당

네 번째가 감리 대응의 실체다. 고치는 것보다 고친 것을 지적 번호에 1:1 로 매칭해 제출하는 일 이 더 많은 시간을 먹는다.

기술 검증의 범위 구분 — 전자정부 표준프레임워크 준수 점검, 웹 접근성 인증·심사 같은 기술 규격 검증 은 모듈 64(공공·기업 업무 SW)에서 다룬다. 이 레슨은 검수 절차와 증거 관리 로 범위를 좁힌다.

검사·검수와 검수조서

과업이 끝나면 발주처는 납품물이 계약·과업지시서대로인지 확인하고 결과를 문서로 남긴다. 기관과 계약 유형에 따라 검사조서·검수조서·준공검사조서 등 이름이 다르고, 검사(규격·수량 확인)와 검수(인수)를 두 단계로 나누는 기관도 있다. 서식과 단계 구분은 기관 규정을 따르므로 사업 착수 시 발주처 계약 담당 부서에 서식을 먼저 요청하는 것이 정석이다. 들어가는 항목은 대체로 이렇다.

[검수조서 본문]
  사업명·계약번호·계약금액·계약기간 / 검수 대상 범위와 검수 일자
  검수 결과: 합격 · 불합격 · 조건부(시정 후 재검수)
  검수자와 참여자, 서명·날인 / 특기사항(미완료 항목·조치 기한·차기 계획)
 
[첨부되는 증빙]
  과업 이행 내역서 (과업지시서 항목 ↔ 이행 결과 ↔ 증거 위치)
  산출물 제출본 (요구사항정의서·설계서·시험계획서·시험결과서·매뉴얼 등)
  시험 관련 문서 (자체 시험 결과서, 필요 시 시험기관 성적서 → 모듈 31)
  감리 지적사항 시정조치 결과 / 교육·이관 확인 / 라이선스·형상·소스 납품 확인

여기서 QA 가 만드는 것은 두 줄이다. 과업 이행 내역서의 "이행 결과·증거" 칸 과 시험 관련 산출물 전부 다. 이 두 줄이 비면 검수가 멈춘다.

조건부 검수 — 가장 위험한 결과

검수 결과가 "조건부"로 나오는 일은 흔하다. 미완료 항목을 기한 내 조치하는 조건으로 일단 인수하는 형태다. 대금이 걸려 있어 수행사는 반기지만, 조건부 검수는 문제를 해결한 게 아니라 하자보수 기간으로 이월한 것 이다. 조건부로 갈 때 반드시 문서에 박아야 하는 것.

1. 미완료 항목의 목록과 각각의 완료 정의   2. 조치 기한과 담당(양측)
3. 재검수 방식(전체인가 해당 항목만인가)   4. 조치 완료 판정 주체
5. 기한 내 미조치 시의 처리

1번이 없으면 재검수 때 같은 논쟁이 다시 시작되고, 3번이 없으면 "이왕 하는 김에" 범위가 늘어난다.

하자담보책임 기간의 품질 증거

검수가 끝나도 끝난 게 아니다. 「소프트웨어 진흥법」 제60조(소프트웨어사업의 하자담보책임) 는 사업자가 국가기관등과 계약을 체결한 경우 사업을 종료한 날부터 1년 이내에 발생한 하자 에 대해 담보책임을 진다고 정한다(분리발주 등에서 다른 약정 가능). 면책 사유도 두는데, 발주자가 제공한 물품의 품질·규격 미달이나 발주자의 지시에 따라 구축한 경우가 그것이다. 다만 부적절한 물품·지시라는 사실을 알면서 발주자에게 알리지 않았다면 면책되지 않는다.

마지막 단서가 QA 에게 직접적이다. "발주처가 그렇게 하라고 했다"는 방어는 그때 그렇게 말했다는 기록이 있을 때만 성립한다.

하자 기간에 살아 있어야 하는 증거는 네 갈래다.

하자 기간의 신고는 대개 "안 되던데요" 한 줄로 온다. 이때 판정해야 하는 것은 하나다.

신고 접수
  │
  ├─ 검수 시점 형상과 동일한 조건인가?
  │     아니오 → 운영 중 변경(데이터·설정·연동·OS 패치)이 원인 → 하자 아님 (근거 제시)
  │     예 ↓
  ├─ 검수 시 합의된 기준·과업 범위 안의 동작인가?
  │     아니오 → 신규 요구 → 변경·추가 계약
  │     예 ↓
  └─ 하자 → 조치 후 재현 절차로 검증, 조치 이력 기록

이 판정을 하려면 형상 기준선과 합의 기준 이 남아 있어야 한다. 둘 중 하나라도 없으면 모든 신고가 하자가 되고, 하자보수 기간은 무상 추가 개발 기간이 된다. 국내 SI 현장에서 반복되는 구조적 손실이 정확히 여기서 난다.

원문 확인이 필요한 것들

이 레슨이 조문 번호를 붙여 쓴 것은 국가법령정보센터에서 직접 확인한 것 뿐이다 — 전자정부법 제57조, 같은 법 시행령 제71조, 소프트웨어 진흥법 제60조, 행정규칙 「정보시스템 감리기준」(조회된 판 제2010-30호). 서지사항만 확인한 것은 과기정통부 고시 제2023-15호(2023. 5. 15. 시행)와 조달청 훈령 제2257호(2025. 4. 1. 시행)다. 아래는 원문 확인 대상이라 조문 번호를 쓰지 않았다.

· 「정보시스템 감리기준」 고시의 현행 개정판 번호와 시행일
· 감리 단계(착수·중간·종료) 구분과 횟수의 근거 조문
· 위 지침의 검사·검수·과업변경 관련 세부 조문
· 검사·검수 절차와 검수조서 서식의 근거(국가계약법령·지방계약법령·기관 규정)
· 하자보수보증금의 요율과 예외 사유
· 과업심의위원회의 심의 대상·절차를 정한 소프트웨어 진흥법 조문

조문 번호를 추측으로 쓰지 않는 것 은 이 분야의 기본 규율이다. 검수 협의에서 틀린 조문을 인용하면 나머지 내용의 신뢰도까지 떨어진다.

실무에서 왜 필요한가

공공 SI 에서 사업이 끝나지 않는 이유는 대개 "제품이 나쁘다"가 아니라 끝났다는 것을 증명하는 문서가 없다 이다. 테스트는 다 했는데 추적표가 없어 과업 이행 내역서를 못 채우고, 결함은 다 고쳤는데 조치 증거가 지적 번호에 매칭돼 있지 않아 종료 감리가 안 끝난다. 이 비용은 전부 수행사가 부담한다.

이 레슨의 내용은 테스트 일정을 역산하는 근거 이기도 하다. 검수일 앞에 종료 감리가 있고 지적 시정과 재시험이 필요하다면, 테스트 종료 시점은 검수일에서 최소 3~4주를 뺀 자리다. 이 역산을 착수 시점에 해 두지 않으면 레슨 1의 "개발 지연이 UAT 를 먹는" 구조가 반복된다.

실습 과제

과제 1 — 검수 일정 역산표 만들기 (20분)

다음 조건으로 사업 전체 일정의 뒷부분을 역산한다.

계약 종료일 12월 31일, 검수 완료 기한 12월 24일. 종료 감리 2주, 감리보고서는 감리 종료 후 5영업일. 지적 시정 평균 1주, 시정 결과 재시험 3일. 발주처는 검수 서류 사전 검토에 5영업일을 요구한다.

날짜가 박힌 역산표를 만든 뒤 통합 테스트가 늦어도 언제 끝나야 하는가 와 가장 먼저 무너질 칸 을 지목하고 이유를 적는다.

과제 2 — 시정조치 결과서 서식 설계 (20분)

감리 지적사항 대응용 시정조치 결과서 서식을 설계하고 다음 3건을 채운다.

지적 1 (필수) 요구사항 추적표에 비기능 요구사항 12건이 누락돼 있음
지적 2 (필수) 통합시험 결과서에 시험 환경(버전·데이터 규모)이 기재되지 않음
지적 3 (협의) 결함 조치 후 회귀 시험 범위 산정 기준이 문서화돼 있지 않음

각 행에 증거의 위치 칸을 두고, 감리원이 혼자 찾아갈 수 있을 만큼 구체적으로 쓴다. 다 채운 뒤 이 서식으로 50건을 관리할 때 무엇이 문제가 될지 적는다.

과제 3 — 하자 판정 연습 (15분)

하자담보책임 기간 4개월 차의 신고를 본문의 판정 흐름으로 처리한다. 각 건에 판정 결과와 그 판정을 뒷받침할 증거 를 적는다.

1. 월말 마감 배치가 3시간 걸린다. 검수 때는 40분이었다
2. 신규 부서가 생겨 조직도에 4단계 계층이 필요한데 3단계까지만 된다
3. 특정 결재선에서 승인 버튼이 동작하지 않는다. 검수 시 시험한 결재선이 아니다
4. 발주처 요청으로 검수 직전에 넣은 임시 배치가 계속 오류를 낸다

자가 체크리스트

• 테스트·감리·검수 세 절차의 주체와 목적, 결과의 힘을 구분해 설명할 수 있다
• 정보시스템 감리의 근거(전자정부법 제57조)와 대상 기준의 위치(시행령 제71조)를 말할 수 있다
• 감리와 수행사 QA 의 차이를 독립성·대상·결과의 힘으로 설명할 수 있다
• 감리 대응에 필요한 네 가지 증거와 시정조치 결과서의 필수 칸을 말할 수 있다
• 검수조서 본문 항목과 첨부 증빙을 구분해 나열하고, 조건부 검수에 박아야 할 것을 말할 수 있다
• 하자담보책임의 기간과 면책 사유, 면책이 깨지는 단서를 설명할 수 있다
• 하자 신고를 형상 기준선과 합의 기준으로 판정하는 흐름을 그릴 수 있다
• 검수일에서 테스트 종료일을 역산하고, 조문은 국가법령정보센터에서 확인해 인용할 수 있다

흔한 실수

• 감리 일정을 테스트 일정과 따로 잡는다. 종료 감리 시점에 통합 테스트가 안 끝나 있으면 지적은 확정이다.
• 지적사항을 고치고 증거를 매칭하지 않는다. 고쳤다는 증거가 지적 번호에 붙어 있어야 종료된다.
• 요구사항 추적표를 종료 단계에 몰아서 만든다. 사후 창작물이 되고, 감리는 그것을 알아본다.
• 조건부 검수를 성공으로 받아들인다. 완료 정의·기한·재검수 방식·판정 주체를 적지 않으면 하자 기간 내내 같은 논쟁이 반복된다.
• 발주처의 구두 지시를 기록하지 않는다. 면책 단서는 "알렸는가"를 묻는다. 기록이 없으면 알리지 않은 것과 같이 취급된다.
• 조문 번호를 기억으로 인용한다. 고시·훈령은 자주 개정된다. 인용 전에 국가법령정보센터에서 현행 판을 조회한다.

참고 자료

• 국가법령정보센터 — 전자정부법 제57조(행정기관등의 정보시스템 감리), 소프트웨어 진흥법 제60조(하자담보책임). 현행 조문을 직접 조회할 것
• 전자정부법 시행령 제71조(정보시스템 감리의 대상) — 사업비 5억원 이상 등 대상 기준
• 국가법령정보센터 — 행정규칙 「정보시스템 감리기준」 — 행정안전부 고시. 조회 시점 표시는 제2010-30호, 현행 개정판은 원문 확인
• 국가법령정보센터 — 「소프트웨어사업 계약 및 관리감독에 관한 지침」 — 과학기술정보통신부고시 제2023-15호, 2023. 5. 15. 시행. 세부 조문은 원문 확인
• 국가법령정보센터 — 「소프트웨어사업 과업심의위원회 위탁 업무 운영 규정」 — 조달청훈령 제2257호(2025. 4. 1. 시행)
• NIA 정보시스템 감리자료실 — 감리 발주관리·수행 가이드, SW사업자용 감리준비 및 대응 가이드, 감리 대가 산정 계산기
• 조달청 — 검사·검수 서식·절차는 기관과 계약 유형별로 다르다. 계약 담당 부서에 서식을 요청할 것
• 레슨 s2-m31-l01 — 시험 범위 정의와 시험 계획서 / s2-m31-l02 — 시험 환경 기술 / s2-m31-l05 — 성적서의 법적 효력
• 레슨 s2-m56-l01 — UAT 설계 / s2-m56-l04 — RFP 요구사항을 인수 케이스로, 요구사항 추적표 만들기