공공·중견 SI 발주, 착수 전 산출물 8가지 | 과업 확정 기준

핵심 요약 — 공공이나 중견기업 SI 사업은 개발이 시작되기 전, 문서 단계에서 결과의 절반이 정해져요. 요구사항이 문장 수준으로만 적힌 채 계약하면 과업 범위를 두고 계속 부딪히거든요. 2026년 7월 소프트웨어진흥법 개정으로 과업심의위원회 개최가 의무화됐고, 조달청과 한국지능정보사회진흥원은 17억 8천만 원을 들여 AI 발주관리 플랫폼을 만들고 있어요. 착수 전에 준비하면 좋은 산출물 8가지를 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“제안요청서는 나갔는데, 막상 착수하니 서로 생각한 범위가 달랐어요.”

SI 프로젝트에서 가장 자주 듣는 말이에요. 기술 문제로 틀어지는 경우보다 무엇을 만들기로 했는지가 애매해서 틀어지는 경우가 훨씬 많아요. 그런데 이 애매함은 개발 중에 생기는 게 아니라, 착수 전 문서에서 이미 만들어져 있어요.

---

1. 왜 착수 전 문서에서 승부가 갈릴까요

SI 사업은 물건을 사는 계약이 아니라 만들어질 것을 미리 정의하고 사는 계약이에요. 그래서 정의가 흐리면 계약 자체가 흐려져요.

공공 사업에서 특히 그래요. 과업지시서가 계약 문서에 들어가기 때문에 거기 적힌 문장이 곧 판단 기준이 되거든요. “사용자 편의성을 고려한 화면 구성”처럼 적혀 있으면 착수 후에 서로 다른 그림을 그리게 돼요.

2. 2026년 7월, 제도가 한 번 바뀌었어요

2026년 7월 국회 본회의에서 소프트웨어진흥법 개정안이 통과됐어요. 발주자 입장에서 알아둘 변화는 두 가지예요.

• 과업심의위원회 개최 의무화 — 특별한 사유가 없으면 발주기관이 스스로 심의 절차를 열어야 해요. 이전에는 사업자가 요청해야 논의가 시작되는 구조였어요.
• 예산 확보 의무 — 심의 결과를 계약에 반영하는 데 그치지 않고, 거기 필요한 예산도 확보하도록 했어요.

배경은 단순해요. 과업 범위가 늘어나는 일은 흔한데, 심의가 열리지 않거나 결과가 계약·예산으로 이어지지 않아서 추가 부담이 한쪽에 쏠려온 거예요.

여기에 조달청과 한국지능정보사회진흥원은 17억 8천만 원 규모로 공공SW AI 발주관리 플랫폼을 만들고 있어요. 사업명과 목적, 주요 요구사항을 입력하면 사업 유형에 맞는 RFP 초안을 자동으로 만들고, 기능점수 산정과 과업심의 절차를 디지털로 처리하는 방향이에요.

제도가 정비되는 건 반가운 일이지만, 요구사항을 얼마나 구체적으로 적어놨는지는 여전히 발주자 몫이에요. 심의 절차가 열려도 비교할 기준선이 없으면 논의가 겉돌아요.

3. 착수 전에 준비할 산출물 8가지

순서대로 쌓아 올리는 구조예요. 아래로 갈수록 앞 문서를 근거로 삼아요.

#	산출물	무엇을 확정하나요	없으면 생기는 일
1	사업계획서	목적·기대효과·예산 근거	예산 심의에서 막혀요
2	현황 분석서	기존 시스템·데이터 상태	연동 공수가 착수 후에 튀어나와요
3	요구사항정의서	기능·비기능 요구를 항목 단위로	견적 편차가 배로 벌어져요
4	제안요청서(RFP)	사업 범위·평가 기준·일정	제안서 비교가 불가능해져요
5	과업지시서	계약상 의무 범위	과업 변경 다툼의 기준선이 없어요
6	규모 산정 자료	기능점수 등 사업비 근거	금액을 방어할 수가 없어요
7	데이터·연동 명세	이관 대상·인터페이스	이관 단계에서 일정이 밀려요
8	검수 기준서	완료 판정 조건	검수 단계에서 끝없이 붙잡혀요

여덟 개가 많아 보이지만, 3번과 5번이 제대로 서 있으면 나머지는 그걸 옮겨 담는 작업에 가까워요.

4. 요구사항정의서는 어디까지 써야 할까요

기준 하나만 기억하시면 돼요. 읽는 사람이 다르게 해석할 여지가 없으면 충분해요.

실무에서는 이 정도로 쪼개요.

• 기능 하나당 입력 → 처리 → 출력을 각각 한 줄로 적어요.
• 누가 쓰는 기능인지 사용자 유형을 붙여요.
• 처리 건수, 동시 접속, 응답 시간 같은 비기능 조건을 숫자로 적어요.
• 화면이 필요한 기능은 화면 목록만이라도 붙여요.

“관리자 통계 기능”이라고만 적힌 항목과 “관리자가 기간을 선택하면 일별 접속·처리 건수를 표와 그래프로 보여주고 엑셀로 내려받는다”라고 적힌 항목은 견적이 다르게 나와요. 뒤쪽은 SI업체마다 금액 차이가 크지 않지만, 앞쪽은 배 이상 벌어지기도 해요.

용어 정리 — RFP(Request for Proposal, 제안요청서)는 발주기관이 무엇을 원하는지 알리고 제안을 받는 문서예요. 과업지시서는 그중 확정된 범위를 계약 의무로 못 박는 문서고요. 기능점수(FP)는 소프트웨어 규모를 기능 개수와 복잡도로 환산하는 방식이에요. 실무에선 “FP로 잡았다”고 하면 화면 수가 아니라 기능 단위로 사업비를 산정했다는 뜻이에요.

5. 사업비는 어떤 근거로 잡히나요

공공 사업은 기능점수로 규모를 산정하고 여기에 단가를 곱해요. 민간 중견기업 발주도 이 방식을 참고하는 곳이 늘고 있고요.

공식 외부 기준 (참고)

항목	값	출처 유형
응용SW개발자 월 평균임금	약 712만 원	KOSA 공표 노임단가
IT PM 월 평균임금	약 953만 원	KOSA 공표 노임단가
유지관리요율 정부 권고	20% 이상	정부 권고 기준

자사 실무 기준 예시 (Creative Soft 프로젝트 경험)

상황	저희가 잡는 방식
요구사항이 항목 단위로 정리된 경우	고정가 위주, 변경분만 별도
요구사항이 개요 수준인 경우	분석 단계를 먼저 분리해서 계약
기존 시스템 연동이 있는 경우	연동 검증 기간을 별도 항목으로

⚠️ 위 표의 공식 노임단가는 정부·협회가 공표한 값이고, 아래 표는 저희 프로젝트에서 쓰는 판단 방식이에요. 두 값을 섞어서 시장 평균처럼 읽으시면 안 돼요. SI개발비용은 같은 요구사항이라도 연동 범위와 데이터 이관량에 따라 크게 달라져요.

6. 발주자가 자주 놓치는 세 가지

데이터 이관 범위를 안 적어요. 몇 년 치를, 어떤 상태로, 누가 정제해서 넘길지를 안 정하면 이 작업이 통째로 착수 후 협의 사항이 돼요. 규모가 큰 si project일수록 여기서 일정이 밀려요.

검수 기준을 결과물이 나온 뒤에 정해요. “며칠 안에 이의를 통보하지 않으면 검수 완료” 같은 조항까지 미리 넣어두셔야 검수 단계가 끝나요.

운영 인계 산출물을 목록으로 안 적어요. 소스코드, 배포 절차, 설정값, 장애 이력이 문서로 넘어오지 않으면 다음 운영사가 코드 읽는 데만 몇 달을 써요.

운영사 Tip — 저희는 착수 전에 “이 프로젝트가 끝나고 3년 뒤에 누가 이걸 고치게 될까”를 먼저 물어봐요. 그 답이 발주기관 내부 인력이면 문서와 구조를 그 사람이 읽을 수 있는 수준으로 맞춰야 하고, 다른 SI기업이면 인계 산출물 목록을 계약서에 넣어야 해요. 이 질문 하나로 산출물 범위가 꽤 정리돼요.

7. 규모가 작은 사업이면 어디까지 줄여도 될까요

공공기관홈페이지제작처럼 범위가 비교적 명확한 사업은 여덟 개를 다 갖출 필요가 없어요. 이 경우엔 세 가지만 챙기셔도 대부분 커버돼요.

1. 요구사항정의서 — 화면 목록과 관리자 기능만이라도 항목으로
2. 검수 기준서 — 완료 판정 조건
3. 운영 인계 목록 — 계정, 소스, 배포 방법

반대로 기존 시스템 연동이나 데이터 이관이 끼면 규모와 상관없이 현황 분석서와 연동 명세는 넣으시는 게 안전해요. 여기가 빠지면 작은 사업에서도 일정이 두 배로 늘어요.

8. 운영까지 보면 달라지는 것

납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. SI개발을 발주하실 때 이 차이가 문서에서 드러나요.

오픈 직후 한 달이 지나면 요청은 대부분 새 기능이 아니라 “이 화면 항목 하나 추가해주세요” 같은 것들이에요. 이걸 누가, 어떤 절차로, 어떤 비용으로 처리할지가 계약에 없으면 그때부터 매번 협의가 필요해요. 착수 전 산출물에 변경 요청 처리 절차를 한 줄이라도 넣어두시면 오픈 이후가 훨씬 조용해져요.

저희가 자체 SaaS 4종을 직접 운영하면서 배운 것도 이거예요. 초기 기능 개수보다 운영 구조가 훨씬 자주 비용을 바꿔요. 그래서 발주 문서를 볼 때도 만들 것보다 유지할 것을 먼저 봐요.

9. 마무리

SI 발주에서 착수 전 문서 작업은 시간을 쓰는 일처럼 보이지만, 실제로는 착수 후 협의 시간을 앞으로 당겨오는 일이에요. 여기서 쓴 2주가 뒤에서 2개월을 줄여줘요.

저희는 10년 이상 50개가 넘는 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논·KICT 같은 곳과도 함께해 왔고요. 발주 문서를 어디까지 정리해야 할지 감이 안 잡히신다면 지금 상황부터 편하게 이야기 나눠요 →

관련 글

• SI 개발 비용, 도급 구조부터 봐야 하는 이유
• 요구사항 정의서 어디까지 써야 하나요
• SI와 SM은 어떻게 다를까요