PE Notes · 사업관리
공공SW 과업심의
공공 소프트웨어 발주 전 과업심의로 범위·기간·예산을 닫는 절차를 정리하고, 과업기술서와 발주자·사업자 역할, 변경 통제와 분리발주를 잇습니다.
요구가 많고 예산이 얇으면, 낙찰 뒤에 야근과 분쟁이 남습니다. 는 발주 전에 과업의 적절성·범위·비용·기간을 전문가 위원회가 보는 제도입니다. 소프트웨어진흥법과 과기정통부 가이드가 자리를 줍니다. 목적은 과다·과소 발주를 줄이고, 완료 기준을 글로 남기는 일입니다.
가이드가 보는 칸
심의는 사업 목적이 요구와 맞는지, 기술과 기간 안에 닫히는지, 예산이 규모와 맞는지, 하자·유지 조건이 한쪽에만 유리하지 않은지를 봅니다. 상용 패키지가 SI 일괄에 숨어 있으면 ·직접구매 대상인지도 같이 겁니다. 규모 감각은 와 공수로 서로 대조합니다. FP로 개발 규모를 보고, 공수로 난이도와 기간을 봅니다. 두 숫자를 한 식에 넣지 않습니다.
| 심의 칸 | 묻는 말 |
|---|---|
| 범위 | 이 요구가 사업 목적과 같은가 |
| 실현 | 제안 기술·기간에 닫히는가 |
| 예산 | FP·공수 대비 대가인가 |
| 기간 | 과업량에 달이 충분한가 |
| 유지 | 하자·운영 조건이 공정한가 |
| 조달 | 상용 SW를 일괄에서 뗄 것인가 |
절차는 사업계획 → 과업기술서 → 심의 신청 → 위원회 검토 → 적정·조건부·부적정 통보 → ·과업 수정 후 발주입니다. 위원회는 외부 전문가로 꾸리고, 발주기관·참여 예정 업체 관련자는 뺍니다.
범위 확정, 발주자와 사업자
과업기술서는 발주 쪽 에 가깝습니다. 배경과 목적, AS-IS, 기능·비기능·인터페이스, 기간·장소·보안, 산출물, 검사 기준이 한 묶음입니다. 요구사항명세서가 공학 상세라면, 과업기술서는 계약이 무엇을 살지 고르는 문장입니다. 상세 명세는 분석 단계에서 SRS로 내려갑니다.
| 비교축 | 발주자 | 사업자 |
|---|---|---|
| 닫을 것 | 목적·우선·예산·검사 | 실현 방안·공수·위험 |
| 문장 | 과업·RFP·심의 반영 | 제안·수행 계획 |
| 변경 | 추가 요구의 공식 창구 | 영향 분석·대가·일정 |
| 실패 모양 | 과다 과업, 모호한 완료 | 저가 수주, 범위 밖 침묵 |
발주자는 “있으면 좋은 것”을 필수에 넣지 않습니다. 사업자는 모호한 한 줄을 침묵으로 넘기지 않습니다. 둘 다 완료 기준을 검사 조항에 숫자로 남깁니다. 은 심의로 닫은 선을 사업 중에 구두로 여는 일에서 시작합니다.
변경과 발주 이후
사업 중 추가는 변경 요청 → 범위·일정·비용 영향 → 양측 합의 → 공식 반영입니다. 심의로 고정한 과업을 회의록 한 줄로 넓히면 제도가 없습니다. 클라우드 이전·AI 도입처럼 불확실이 큰 사업은 실현 칸을 더 두껍게 보고, 시범 범위를 본사업과 가릅니다.
답안은 목적(과다·과소 방지), 심의 칸과 6단계, 과업기술서 항목, 발주자·사업자 표, 변경 공식화, 분리발주·FP를 한 장에 닫습니다.