감리를 앞둔 PM이 두 번째로 묻는 것은 “감리원이 실제로 뭘 지적하나요”입니다. 답이 될 공개 자료는 뜻밖에 적습니다. 감리수행결과보고서는 발주기관 내부 문서라 밖으로 나오지 않고, 지적사항을 모아 센 통계는 제가 찾은 범위에서 두 건입니다. 하나는 1997년 감리보고서 26건, 다른 하나는 2012년 감리 169건입니다. 둘 다 오래됐고 표본이 한 기관 것이라 한계가 분명합니다. 그래도 방향은 같고, 현행 감리 수행 가이드가 감리원에게 정해 준 점검 절차와도 맞습니다. 셋을 출처 그대로 놓습니다.
1997년, 한국전산원 감리보고서 26건
한국전산원(지금의 한국지능정보사회진흥원)이 1997년에 수행한 감리 26건의 보고서를 프로젝트관리 · 응용시스템 · 데이터베이스 세 분야로 나눠 지적사항을 센 「감리결과분석보고서」입니다. 대비표와 요구사항추적표가 감리기준에 들어오기 전(2012년 개정 이전) 자료입니다.
| 분야 | 단계별 지적 건수 | 1순위 지적 |
|---|---|---|
| 프로젝트관리 (158건) | 계획 10 · 분석 8 · 설계 32 · 구현 108 | 과업내용서 이행여부 |
| 응용시스템 (95건) | 분석 1 · 설계 5 · 구현 89 | 기능구현 미흡, 산출물 간 연계성 |
개선유형은 긴급개선 53건 · 통상개선 98건이고, 사업비 규모로는 대형 8건 · 중형 38건 · 소형 103건입니다. 보고서는 긴급 · 통상개선의 1순위를 이렇게 적었습니다.
과업내용서 이행여부(과업내용서 대비 기능을 수행하지 않았거나 미흡한 경우)
같은 보고서의 연구 배경 문장 하나가 오늘 읽어도 그대로입니다.
정보시스템 감리의 대상인 … 분석, 설계, 구현단계 산출물과 시스템에 대한 대조 · 추적 작업 대부분이 수작업으로 이루어져 프로젝트 감리 시 개발생산성을 저하시키고 지적사항이 단편적인 경향이 있다.
지적의 대다수가 구현 단계에서 나온 점도 눈에 띕니다. 2012년 논문은 이 보고서를 인용하며 “주요 지적사항의 문제점이 앞 단계에서는 거의 드러나지 않다가 구현이 마무리되고 난 다음에야 드러난다 … 예방이 아닌 이미 발생한 문제에 대한 지적과 수정 요구라는 점에서 수정에 따른 많은 비용이 필요하게 된다”고 풀었습니다.
2012년, 대형 SI 한 곳의 감리 169건
이돈희 · 정홍섭 · 이기영 · 한기준, 「정보시스템 감리사례 분석을 통한 품질 향상 방안에 관한 연구」(한국컴퓨터정보학회논문지 17권 10호, 2012). 국내 대형 SI 업체 한 곳이 4년간 받은 감리 169건(공공 77 · 금융 39 · 제조서비스 38 · SOC 15)의 지적사항과, 같은 기간 위험이 발생한 프로젝트 367건을 영역별로 셌습니다.
영역마다 1순위 지적사항과 영역 안 비율입니다.
| 영역 | 1순위 지적사항 | 건수 | 영역 내 비율 |
|---|---|---|---|
| 프로젝트관리 · 품질관리 | 요구사항 기준선 설정 및 변경관리(범위) | 80 | 19.2% |
| 사용자 요구사항 | 요구사항 정의 완전성 | 51 | 48.1% |
| 응용시스템 | 요구분석과 설계와의 일관성 | 56 | 21.8% |
| 데이터베이스 | 엔터티 간 관계 정의의 타당성 | 27 | 12.4% |
| 아키텍처 · 보안 | 장애 및 백업대책 적정성 | 25 | 23.2% |
공공 업종만 보면 프로젝트관리 1순위(요구사항 기준선 설정 및 변경관리)가 31건으로 네 업종 중 가장 많고, 응용시스템 1순위(요구분석과 설계와의 일관성)도 공공 · 금융에서 가장 높습니다. 응용시스템에서 세 번째로 많은 “요구사항 대비 기능반영 완전성”(41건, 16.0%)에 논문이 붙인 세부내용이 이것입니다.
요구사항 추적표에 대한 보완이 필요 / 정의된 요구사항에 대해 적절한 분석과 설계가 필요
위험 발생 프로젝트 367건을 대분류로 나눈 표에서는 차이가 더 큽니다.
| 대분류 | 공공 | 금융 | 제조서비스 | SOC |
|---|---|---|---|---|
| 요구사항 | 118 | 98 | 136 | 87 |
| 설계 | 10 | 17 | 21 | 5 |
| 개발(코드 · 단위시험) | 11 | 21 | 16 | 4 |
| 통합 및 테스트 | 8 | 21 | 5 | 7 |
요구사항이 설계나 개발의 다섯 배에서 열 배입니다. 논문은 같은 결론을 7년간 공공 감리 결과를 분석한 앞선 연구(김영진, 석사논문)에서도 인용합니다. 요구사항 관련이 전 업종 1순위이고, 발생 빈도가 수년간 줄지 않았다는 것입니다.
현행 절차 — 감리원은 대비표를 세 번 본다
통계는 오래됐지만 절차는 현행입니다. NIA 「정보시스템 감리 수행 가이드」(2022. 2.) 설계단계 절은 감리원이 사업자의 대비표(과업대비표와 요구사항추적표를 묶어 부르는 감리기준의 말이고, 이 사이트에서 “감리 대비표”라고 쓰는 것)를 어떤 순서로 점검하는지 적어 두었습니다. 셋입니다.
- 형식 요건. “개별 요구사항에 대한 설계내용을 반영하고 있는 설계 산출물 정보가 누락되지 않았는지, 각 요구사항 ID에 대응하는 세부 검사항목과 검사기준이 빠짐없이 작성되었는지.”
- 추적성. “대비표에 명시된 요구사항이 요구정의 단계 대비표와 비교하여 특별한 사유 없이 누락되지 않았는지, 설계단계에서 추가 또는 제외된 요구사항이 관련 설계 산출물에 반영되어 추적이 가능한지.”
- 설계 산출물 내용 적정성. 요구사항 관점과 산출물 관점으로 나눠 봅니다. 개선권고 작성 사례의 원문은 “요구사항1에 대한 설계서 반영 여부를 점검한 결과 ~의 반영이 미흡하므로 개선이 필요함”입니다.
국가직무능력표준 「IT감리」 능력단위(2013 v1)는 같은 일을 감리원의 수행준거로 적었습니다. “확인된 요구사항추적표에 따라 추적항목으로 기술된 설계산출물들의 추적 가능 여부를 점검할 수 있다.” 표에 적힌 화면 ID와 프로그램 ID가 실제 화면정의서 · 프로그램명세서에 있고 내용이 맞는지를 감리원이 직접 따라간다는 뜻입니다.
개선권고는 이렇게 쓰입니다. 대비표 점검 결과의 작성 사례입니다.
(1) 대비표의 요구사항ID별 관련 산출물 및 검사기준 정보 작성 현황을 점검한 결과, ○○의 문제점이 발견되므로 보완할 필요가 있음. [현황 및 문제점] … [개선방향] …
유형은 필수 · 협의 · 권고, 시점은 장기 · 단기입니다. 종료단계의 과업이행 판정은 적합 · 부적합 · 점검제외이고, 부적합에는 관련 증빙이 붙어야 합니다. 시정조치 결과는 조치완료 · 조치중 · 반영불가로 보고합니다.
세 자료를 겹쳐 읽으면
- 1997년의 1순위는 “과업내용서 대비 이행”, 2012년의 1순위는 “요구사항 기준선 · 정의 완전성 · 분석과 설계의 일관성”, 현행 절차의 두 번째 · 세 번째 겹은 “추적성”과 “설계 반영 적정성”입니다. 이름은 바뀌었지만 같은 축입니다. 요구사항이 어디에 어떻게 반영됐는지의 연결이 끊긴 자리가 지적됩니다.
- 1997년에는 그 대조를 감리원이 손으로 했습니다. 2012년 감리기준 개정 이후에는 사업자가 대비표를 만들어 내고 감리원이 검증합니다. 대조 노동의 위치가 바뀌었을 뿐 대조 자체는 남았습니다.
- 지적은 대개 구현이 끝난 뒤에 드러납니다. 설계단계 감리에서 추적표의 세 번째 겹, 즉 “가리킨 설계 절이 요구사항을 실제로 채우는가”를 스스로 먼저 보면 종료단계 부적합을 줄일 수 있습니다. 준비 순서와 양식은 앞 글 정보시스템 감리 산출물 — 누가 언제 무엇을 내나에 있습니다.
이 자료의 한계
- 1997년 자료는 26건이고 대비표 제도 이전입니다. 2012년 자료는 대형 SI 한 곳의 감리라 중소 수행사 사업의 분포와 다를 수 있고, 2012년 감리기준 개정과 2021년 · 2024년 개정 이전 데이터입니다.
- 현행 기준으로 지적사항을 집계한 공개 통계는 찾지 못했습니다. 감리법인이나 발주기관이 최근 결과를 공개하면 이 글을 갱신하겠습니다.
출처
- 한국전산원, 「감리결과분석보고서」(1997년 감리보고서 26건 분석) — NIA 정보시스템 감리자료실
- 이돈희 외, 「정보시스템 감리사례 분석을 통한 품질 향상 방안에 관한 연구」, 한국컴퓨터정보학회논문지 17(10), 2012
- 정보시스템 감리 수행 가이드 (NIA, 2022. 2.) — 설계단계 감리, 대비표 점검결과 작성 사례
- 국가직무능력표준 IT감리 능력단위 (2013 v1)
- 정보시스템 감리기준, 행정안전부고시 제2024-53호