같은 시스템 구축, 두 개의 사업.
C사는 사기업 발주를 받아 자유롭게 일합니다. 발주 담당자와 구두로 범위를 맞추고, 일정은 팀 사정에 맞춰 조정하고, "되는 대로" 납품합니다. 빠르지만, 나중에 "그건 약속한 적 없다 / 했다"로 분쟁이 생기면 근거가 없습니다.
D사는 공공기관 정보화사업을 수주했습니다. 모든 단계가 문서로 통제됩니다 — 발주기관이 RFP를 공고하고, D사는 제안서로 요구 준수·수행조직·일정·품질을 약속하며, 기술·가격 평가를 거쳐 계약합니다. 사업 중에는 발주·수행 어느 쪽도 아닌 감리가 요구·설계·구현·시험 단계를 점검하고, 끝에는 검사·검수로 약속을 충족했는지 확인합니다.
D사가 느린 게 아니라, 공공의 돈(세금)을 쓰는 사업이기에 "누가 무엇을, 어떤 근거로, 누가 확인했는가" 를 절차로 못 박는 것입니다. 이 모듈은 D사의 세계 — 한국 공공 정보화사업의 흐름과, 그 사업을 제3자가 점검하는 정보시스템 감리 — 를 일반적인 절차 수준에서 다룹니다.
- 1공공 정보화사업의 전체 흐름(사업계획→RFP→제안→평가→계약→착수→감리→검사·검수)을 순서대로 설명할 수 있다
- 2RFP·제안서·감리보고서·검사검수 확인서 등 단계별 핵심 산출물과 그 통제 목적을 연결할 수 있다
- 3정보시스템 감리가 독립된 제3자로서 요구·설계·구현·시험 단계를 점검하고 시정을 권고하는 역할임을 설명할 수 있다
- 4기술 평가와 가격 평가의 차이, 제안서가 약속하는 네 가지 축(요구 준수·수행조직·일정·품질)을 구분할 수 있다
- 5공공 SI 현업에서 관리자가 통제해야 할 포인트(근거 문서·독립 점검·확인 책임)를 자기 말로 정리할 수 있다
공공 정보화사업은 왜 이렇게 절차가 많은가
세금을 쓰는 사업의 핵심은 '근거'와 '통제'
사기업의 발주는 "빨리, 알아서, 결과로" 평가받습니다. 반면 공공기관의 정보화사업은 세금을 재원으로 하기 때문에, 속도보다 먼저 묻는 질문이 있습니다 — "이 돈을 쓴 근거가 무엇이고, 그 과정이 공정했으며, 약속이 지켜졌음을 누가 확인했는가?"
그래서 공공 SI는 단계마다 문서(산출물) 를 남기고, 그 문서로 다음 단계를 통제합니다. 대체로 다음과 같은 흐름을 따릅니다.
| 단계 | 하는 일 | 대표 산출물 | 통제 목적 |
|---|---|---|---|
| 사업계획 | 무엇을·왜·얼마로 할지 기획 | 사업계획서, 예산 | 사업의 정당성·범위 확정 |
| RFP 공고 | 요구사항·평가 기준을 공식 공고 | 제안요청서(RFP) | 제안의 기준선 제시 |
| 제안서 제출 | 수행사가 수행 방법을 제시 | 제안서, 가격제안서 | 약속의 문서화 |
| 제안발표 | 제안 내용을 평가위원에게 설명 | 발표자료, 질의응답 | 제안의 검증 |
| 기술·가격 평가 | 기술과 가격을 정량·정성 평가 | 평가표, 평가결과 | 최적 수행사 선정 근거 |
| 우선협상·계약 | 협상 후 계약 체결 | 계약서, 과업지시서 | 권리·의무 확정 |
| 착수 | 사업 시작, 계획 구체화 | 착수계, 수행계획서 | 일정·조직 확정 |
| 감리 | 제3자가 단계별 점검 | 감리계획서, 감리보고서 | 적정성 독립 점검 |
| 검사·검수 | 산출물의 요구 충족 확인 | 검사·검수 확인서 | 완료·대가 지급 근거 |
여기서 핵심 감각은 "각 단계의 산출물이 다음 단계를 묶는 근거가 된다" 는 점입니다. RFP는 제안서를 묶고, 제안서는 계약을 묶고, 계약은 검사·검수를 묶습니다. 그래서 공공 SI에서 관리자의 일은 "근거 문서를 만들고, 그 근거대로 이행됐는지 확인하는 것"입니다.
기관·법령·금액 기준 등 세부 규정은 사업 유형과 시점에 따라 달라질 수 있으므로, 이 모듈은 일반적인 절차의 골격만 다룹니다. 구체적 기준은 실제 사업의 공고문과 관련 규정을 따라야 합니다.
RFP에서 제안서로 — 약속이 문서가 되는 지점
제안서가 약속하는 네 가지 축
RFP가 발주기관의 "이렇게 해 주세요"라면, 제안서는 수행사의 "이렇게 하겠습니다"입니다. 일반적으로 평가위원이 제안서에서 확인하는 약속은 크게 네 축으로 정리됩니다.
- 요구 준수: RFP의 기능·비기능 요구사항을 빠짐없이 반영했는가. 보통 요구사항 항목별로 준수 여부와 구현 방안을 표로 제시합니다.
- 수행조직: 누가(투입 인력의 등급·경력), 어떤 체계(PM·PL·파트별 조직)로 수행하는가. 핵심 인력의 이력과 역할이 중요하게 봅니다.
- 일정: 전체 일정과 단계별 마일스톤, 핵심 산출물의 시점이 현실적인가. 무리한 압축 일정은 리스크로 지적될 수 있습니다.
- 품질: 어떤 방법론·표준·테스트·검토 체계로 품질을 보장하는가. 형상관리·시험계획·결함관리 등 품질 통제 방안이 포함됩니다.
평가는 일반적으로 기술 평가(제안의 우수성을 정성·정량으로 채점)와 가격 평가(제안 가격을 점수화)로 나뉘며, 둘을 합산해 우선협상대상자를 가립니다. 정확한 배점·산식은 사업마다 다르므로, "기술과 가격을 함께 본다"는 골격만 기억하면 됩니다.
| 평가 영역 | 무엇을 보는가 | 대체적인 성격 |
|---|---|---|
| 기술 평가 | 요구 준수·수행조직·방법론·품질·이해도 | 정성+정량, 평가위원 채점 |
| 가격 평가 | 제안 가격의 적정성 | 산식 기반 정량 |
| 종합 | 기술+가격 합산으로 순위 결정 | 우선협상대상자 선정 |
정보시스템 감리 — 독립된 제3자의 단계별 점검
감리는 '편들지 않는 점검자'
사업이 계약·착수로 굴러가기 시작하면, 감리가 등장합니다. 감리는 일반적으로 발주기관·수행사 어디에도 속하지 않는 독립된 제3자(감리법인·감리원)가, 사업이 제대로 진행되는지를 단계별로 점검하고 문제점에 대해 시정·개선을 권고하는 활동입니다.
감리의 핵심 성격은 두 가지입니다.
- 독립성: 감리는 산출물을 직접 만들지 않습니다. 만들면 자기가 만든 걸 자기가 점검하는 셈이 되어 객관성이 무너집니다. 그래서 감리원은 점검·권고만 하고, 실제 조치는 수행사가 합니다.
- 단계별 점검: 사업의 흐름을 따라 요구사항 → 설계 → 구현 → 시험 등 주요 단계에서 점검을 수행합니다. 한 번에 몰아서 끝에만 보는 것이 아니라, 각 단계가 끝나는 시점에 들여다봅니다.
점검 결과는 감리보고서에 기록되고, 발견된 문제점에는 시정조치(개선권고) 가 따릅니다. 일반적인 처리 흐름은 이렇습니다 — 감리가 지적 → 수행사가 조치 → 감리가 조치 결과를 다시 확인. 이 "조치 후 재확인" 고리가 닫혀야 통제가 완성됩니다.
아래는 감리가 단계별로 무엇을 보는지에 대한 일반적인 점검영역입니다.
| 점검 단계 | 대체로 보는 것 | 핵심 질문 |
|---|---|---|
| 요구사항 | 요구사항이 RFP·과업과 일치하고 누락이 없는가 | "약속한 걸 빠짐없이 정의했나?" |
| 설계 | 설계가 요구를 충실히 반영하고 일관적인가 | "요구가 설계로 제대로 내려왔나?" |
| 구현 | 구현이 설계대로 되고 표준·품질을 지키는가 | "설계대로 만들었고 품질이 되나?" |
| 시험 | 시험이 요구를 검증하고 결함이 관리되는가 | "약속을 검증했고 결함을 닫았나?" |
| 산출물·관리 | 산출물·형상·일정·인력 관리가 적정한가 | "근거와 관리가 남아 있나?" |
감리가 "코드를 잘 짰나"만 보는 것이 아니라, 요구 → 설계 → 구현 → 시험으로 이어지는 추적성(요구가 설계로, 설계가 구현으로, 구현이 시험으로 이어지는가)을 본다는 점이 중요합니다.
그림: 각 단계의 산출물이 다음 단계를 묶는 근거가 되고, 독립된 감리는 추적성을 점검하며 "조치 후 재확인" 고리를 닫는다.
감리가 보는 핵심은 한 단계의 품질이 아니라 요구→설계→구현→시험으로 이어지는 추적성 — 즉 앞 단계의 약속이 뒷 단계로 빠짐없이 내려왔는가입니다. 그리고 감리는 점검·권고만 하고(산출물을 직접 만들면 자기 점검이 되어 객관성이 무너지므로), 실제 조치는 수행사가 합니다. 그래서 지적 → 조치 → 재확인의 고리가 닫혀야 통제가 완성됩니다. 재확인에서 미흡하면 고리는 다시 처음으로 돌아갑니다.
직접 해보기 — 사업 한 건의 단계와 산출물을 배열하기
아래 활동 7건이 순서가 섞여 있습니다. (1) 공공 정보화사업의 일반적 흐름대로 순서를 배열하고, (2) 각 활동의 대표 산출물을 짝지어 보세요. 정답은 ObserveBlock에 있습니다.
㉠ 수행사가 요구 준수·수행조직·일정·품질을 문서로 제시한다.
㉡ 발주기관이 요구사항·평가 기준을 정리해 공고한다.
㉢ 납품된 산출물이 요구를 충족하는지 확인한다.
㉣ 무엇을·왜·얼마로 할지 기획한다.
㉤ 제3자가 요구·설계·구현·시험 단계를 점검하고 시정을 권고한다.
㉥ 기술 점수와 가격 점수를 합산해 우선협상대상자를 정한다.
㉦ 협상 후 권리·의무를 확정한다.
배열 직관: "기준을 세우고(계획·RFP) → 약속을 받고(제안·평가) → 약속을 묶고(계약) → 이행을 점검하고(감리) → 완료를 확인한다(검사·검수)" 의 큰 줄기를 먼저 잡으면 순서가 보입니다.
배열: 사업계획 → ... → 검사·검수- 올바른 순서: ㉣ 사업계획 → ㉡ RFP 공고 → ㉠ 제안서 제출 → ㉥ 기술·가격 평가 → ㉦ 우선협상·계약 → ㉤ 감리 → ㉢ 검사·검수
- ㉣ 사업계획 = 사업계획서·예산 (사업의 정당성과 범위)
- ㉡ RFP 공고 = 제안요청서(RFP) (이후 모든 제안·평가의 기준선)
- ㉠ 제안서 제출 = 제안서·가격제안서 (요구 준수·조직·일정·품질의 약속)
- ㉥ 기술·가격 평가 = 평가표·평가결과 (선정의 객관적 근거)
- ㉦ 우선협상·계약 = 계약서·과업지시서 (권리·의무 확정)
- ㉤ 감리 = 감리계획서·감리보고서 (독립된 제3자의 단계별 점검과 시정 권고)
- ㉢ 검사·검수 = 검사·검수 확인서 (완료와 대가 지급의 근거)
- 핵심 감각: 각 단계의 산출물이 다음 단계를 묶는 근거가 된다 — 근거 없는 단계 이동은 공공 SI에서 통하지 않는다
현장에서 자주 보는 함정
증상: 감리보고서에 시정 권고가 여러 건 적혀 있습니다. 수행사는 "조치했습니다"라고 구두로 말했고, 일정에 쫓겨 아무도 그 조치가 실제로 반영됐는지 확인하지 않은 채 다음 단계로 넘어갑니다. 그런데 검사·검수 단계에서 같은 문제가 다시 발견되어 일정이 크게 밀립니다.
원인: 통제의 고리가 "지적"에서 끊겼습니다. 감리의 가치는 "지적"이 아니라 "조치 후 재확인" 으로 고리를 닫는 데 있는데, 재확인 단계를 생략했습니다. 구두 보고("했습니다")는 산출물 보고일 뿐, 결과(요구 충족)가 확인된 것이 아닙니다. 근거 문서로 닫지 않은 항목은 닫히지 않은 것입니다.
해결 방향(공공 SI의 일반 원칙):
- 감리 지적사항을 항목별로 대장(목록) 으로 관리하고, 각 항목의 상태(미조치/조치중/조치완료/확인완료)를 명시한다.
- "조치완료"와 "확인완료"를 분리한다 — 수행사가 조치했다고 끝이 아니라, 감리(또는 발주 담당)가 다시 확인해야 닫힌다.
- 확인은 근거 산출물(수정된 설계서·시험 결과 등)로 받는다. 구두·메신저 보고만으로 닫지 않는다.
- 닫히지 않은 항목은 검사·검수 체크리스트로 승계해, 같은 문제가 종료 단계까지 미루어지지 않게 한다.
감리는 "흠을 잡는 사람"이 아니라, 종료 시점의 분쟁을 사업 중간으로 당겨 미리 닫아 주는 장치입니다. 재확인을 생략하면 그 장치를 꺼 버리는 셈입니다.
한국에서 이 지식이 필요한 자리는 발주기관의 사업 담당(감독), 수행사의 PM·PL·사업관리(PMO), 그리고 감리원 쪽입니다. 공공 정보화사업은 대체로 발주기관·원청(수행사)·협력사(하도급)·감리가 함께 얽혀 돌아가며, 각자가 보는 문서와 책임이 다릅니다.
발주 담당은 "RFP가 요구를 제대로 담았는가, 제안 평가가 공정했는가, 감리 지적이 닫혔는가, 검사·검수가 근거대로 됐는가"를 통제합니다. 수행사 PM은 "제안서의 약속(요구 준수·조직·일정·품질)을 실제 산출물로 이행하고, 감리 지적에 대응하며, 검사·검수를 통과"시키는 책임을 집니다. 협력사 엔지니어가 실제 구현을 하더라도, 약속과 일정·품질에 대한 책임은 관리자에게 남습니다.
그래서 이 자리에서 가장 중요한 습관은 "근거 문서로 말하고, 독립적으로 점검하며, 조치 결과를 반드시 재확인한다" 입니다. 구두 합의·구두 보고는 공공 SI에서 분쟁의 씨앗이 됩니다. 기술을 아는 관리자는 감리 지적의 의미를 이해하고, 협력사의 "다 됐습니다"를 산출물로 검증하며, 잘못된 보고에 속지 않습니다. 세부 법령·기관·금액 기준은 사업과 시점에 따라 달라지므로, 실제 사업에서는 해당 공고문과 규정을 반드시 확인해야 합니다.
관련 모듈로 더 깊이:
- 계약·과업범위·M/M·검수 — 감리·검사의 바탕이 되는 계약·과업범위·검수의 경계
- PMO 운영과 벤더 관리 — 발주기관·원청·협력사·감리가 얽힌 다자 구조를 PMO가 조율하는 법
- SI 프로젝트 생애주기 — 감리가 단계별로 점검하는 SI 생애주기의 분석·설계·구현·시험 흐름
다음 모듈에서는 이렇게 얽힌 다자 구조를 실제로 굴리는 관리 체계 — 사업 전반을 조율하는 PMO 운영과 협력사(벤더) 관리의 통제 포인트를 다룹니다.