과업지시서 작성법 2026 — 과업내용서 항목·예시와 SW 과업심의위원회 8단계

과업지시서는 발주처가 쓰는 문서다. 제안요청서를 업체에 뿌리고 나면 끝난 것 같지만, 계약서에 붙어 실제로 다툼의 기준이 되는 것은 과업지시서 쪽이다. 소프트웨어 용역에서는 특히 그렇다. 「이건 과업에 포함된 거 아닌가요」라는 대화가 오갈 때 펴 보는 문서가 이것이다.

먼저 기대를 하나 접고 시작하는 편이 낫다. 전 부처가 공통으로 쓰는 과업지시서 표준 양식은 없다. 국가법령정보센터에서 「과업지시서[표준]」을 검색하면 별지 서식이 나오는데, 그중 자주 걸리는 [별지 24]는 국립수목원 연구개발사업 관리규정의 서식이다. 연구과제용이라 소프트웨어 용역의 과업범위·검수·지식재산권 구조와 맞지 않는다. 양식을 찾는 대신 같은 분야·비슷한 규모의 실제 공고문 목차를 보는 것이 빠르다.

이 글은 소프트웨어·시스템 용역을 발주하는 쪽이 과업지시서를 쓸 때 무엇을 어떻게 적어야 하는지 정리한 것이다. 공공 발주라면 소프트웨어 진흥법이 요구하는 절차가 따로 있고, 민간 발주라도 그 구조를 빌려 쓰는 편이 안전하다. 계약 조건 쪽(지체상금·하자보수·대금 지급일 같은 것)은 과업지시서가 정하지 않는다 — 그 경계는 아래에서 따로 다룬다.

---

과업지시서·제안요청서·요구사항 정의서는 각각 다른 문서다

셋을 섞어 쓰는 경우가 많은데 작성 주체와 시점이 다르다.

실무에서는 제안요청서 안에 과업지시서를 章으로 넣거나, 별책으로 붙여 함께 공고한다. 어느 쪽이든 계약 체결 시 계약 문서의 일부로 편입된다는 점이 제안요청서와 갈리는 지점이다. 계약서에 「과업지시서에 따른다」는 문장이 들어가는 순간, 거기 적힌 문장 하나하나가 이행 의무가 된다.

요구사항 정의서와의 관계는 순서로 이해하면 된다. 과업지시서가 범위의 경계를 긋고, 요구사항 정의서가 그 안을 기능 단위로 채운다. 경계가 흐린 상태로 안을 채우기 시작하면 착수 후에 범위가 계속 늘어난다. 그 다음 단계가 WBS로, 확정된 요구사항을 일정과 담당자를 붙일 수 있는 작업 단위까지 쪼갠다. 요구사항 정의서를 실제로 어떻게 쓰는지는 요구사항정의서 쓰는 법에 항목·ID 체계·추적표까지 정리했다.

법령 용어는 「과업내용」이다

소프트웨어 진흥법 제50조는 과업심의위원회의 심의 대상을 「과업내용의 확정」과 「과업내용 변경」으로 쓴다. 「과업지시서」라는 말은 조문에 없다.

앞에서 본 표준 서식도 제목은 과업지시서인데 본문 조항에는 「과업내용서에 명기하지 아니한 사항이라도」라는 문장이 그대로 들어 있다. 같은 문서 안에서 두 표현이 섞여 있는 것이다.

정리하면 이렇다.

발주 문서를 쓸 때는 기관이 쓰는 명칭을 따르되, 계약서와 과업지시서에서 명칭을 통일하면 된다. 문제가 되는 것은 명칭이 아니라 한 프로젝트 안에서 두 이름이 섞여 어느 문서를 가리키는지 모호해지는 경우다.

소프트웨어 용역 과업지시서의 실제 목차

공공기관이 실제로 공고한 소프트웨어 용역 과업지시서는 대체로 이 구조를 따른다. 아래는 한국해외인프라도시개발지원공사(KIND)가 2024년 1월 공고한 홈페이지 개편·유지관리 용역 과업지시서의 목차다.

눈여겨볼 것은 마지막 장이다. 초보 발주 문서는 Ⅲ 과업범위만 길게 쓰고 Ⅴ를 몇 줄로 끝낸다. 그런데 분쟁은 거의 전부 Ⅴ에서 난다. 범위는 착수 후에 협의로 조정할 수 있지만, 지식재산권 귀속이나 하자담보 기간은 계약 시점에 정해 두지 않으면 나중에 되돌릴 수 없다.

과업개요에는 최소한 이 네 가지가 들어간다.

Ⅲ 과업범위를 쓸 때의 분량 배분

과업범위 장은 길게 쓰는 것이 목적이 아니다. 아래 네 묶음이 각각 있는지가 기준이다.

산출물 목록은 특히 빠뜨리기 쉽다. 「시스템 구축」이라고만 적으면 소스코드·설계서·테스트 결과서·운영 매뉴얼 중 무엇을 받는지가 정해지지 않는다. 필요한 산출물을 문서 이름으로 적어 두면 그것이 곧 검수 목록이 된다. 어떤 문서를 언제 받아야 하는지는 외주 개발 산출물 문서 정리에 단계별로 정리했다.

과업범위는 「무엇을」이 아니라 「어디까지」를 쓴다

과업범위에서 가장 많이 나오는 실수는 하고 싶은 일을 나열하는 것이다. 나열은 경계를 긋지 못한다.

왼쪽 문장들의 공통점은 수량과 상한이 없다는 것이다. 발주처는 「당연히 포함」이라 생각하고 업체는 「제안 범위 밖」이라 생각하는 지점이 여기서 생긴다.

범위를 적을 때 붙이면 좋은 세 가지가 있다.

• 수량 — 화면 몇 개, 게시물 몇 건, 연동 몇 건인지
• 제외 항목 — 포함되지 않는 것을 따로 적는다. 포함 목록보다 이쪽이 분쟁을 더 많이 막는다
• 판정 기준 — 「완료됐다」를 누가 무엇으로 판단하는지

공공 사업에서 개인정보를 다룬다면 개인정보 영향평가가 설계 일정 앞에 들어가는지도 확인한다.

제외 목록은 포함 목록보다 짧고 강하다

제외 항목은 세 줄이면 충분하지만 효과가 가장 크다. 쓰는 방법은 협의 중에 한 번이라도 나온 말을 적는 것이다.

제외 목록을 적으면 업체가 싫어할 것 같지만 반대다. 범위가 닫히면 제안가격이 내려간다. 열린 범위에는 업체가 보이지 않는 보험료를 얹는다.

판정 기준은 숫자로 쓴다

「정상 동작할 것」은 판정 기준이 아니다. 아래처럼 바꾼다.

숫자가 들어가면 검수가 회의가 아니라 확인 작업이 된다.

과업범위 한 항목을 끝까지 — 「게시판 이관」 하나가 문서에 적히는 모습

한 항목이 문서에 실제로 어떻게 적히는지 끝까지 보여 두는 편이 설명보다 빠르다. 「기존 게시판을 새 시스템으로 옮긴다」는 요구 하나를 과업지시서 문장으로 전개하면 이렇게 된다.

1단계 — 협의에서 나온 말. 「게시판은 그대로 옮겨 주세요.」

2단계 — 그대로 적으면 생기는 공백. 게시판이 몇 개인지, 첨부파일을 옮기는지, 비밀글·삭제글을 옮기는지, 작성자 계정을 어떻게 잇는지, 옛 URL로 들어오는 링크를 살리는지가 전부 비어 있다.

3단계 — 과업지시서 문장.

4단계 — 이렇게 적으면 달라지는 것. 업체는 4.2GB와 12,400건을 보고 공수를 산출할 수 있다. 발주처는 검수 때 대조표만 보면 된다. 그리고 「비밀글은 왜 안 옮겼냐」는 대화가 애초에 생기지 않는다.

5단계 — 수량을 모를 때. 실무에서는 협의 시점에 건수를 모르는 경우가 많다. 그때는 비워 두지 말고 상한과 초과 시 처리를 같이 적는다. 「게시물 15,000건을 상한으로 하며, 초과분은 건당 단가 ○○원으로 정산한다」처럼 쓰면 범위가 닫히면서도 현실을 담는다. 상한 없이 「전량 이관」이라고 적는 것이 가장 위험하다.

과업내용 확정은 과업심의위원회가 한다

공공 발주라면 여기가 절차의 핵심이다. 소프트웨어 진흥법 제50조는 국가기관등의 장이 소프트웨어사업 과업심의위원회를 두어야 한다고 정하고 있다(법률 제17348호, 2020년 12월 10일 시행).

심의 대상은 다음과 같다.

같은 조는 국가기관등의 장이 특별한 사정이 없으면 심의결과를 계약 등에 반영하여야 한다고 정한다. 즉 과업심의위원회의 결정은 참고 의견이 아니다.

그래서 실제 공고문의 과업지시서에는 다음과 같은 문장이 들어간다.

본 사업은 「소프트웨어 진흥법」 제50조에 따른 과업내용 확정을 위하여 과업심의위원회를 ( ✔ )개최 또는 ( )미개최한 사업이다.

발주처가 이 체크박스를 비워 두고 공고하는 경우가 있는데, 업체 입장에서는 과업이 확정된 것인지 아닌지를 알 수 없는 상태가 된다. 체크와 함께 개최 일자를 적어 두는 편이 낫다.

언제 열어야 하는가

조문은 「과업내용의 확정」과 「과업내용 변경의 확정」을 심의 사항으로 둔다. 시점으로 옮기면 두 번이다.

두 번째가 실무에서 더 중요하다. 범위가 늘어나는 상황은 대개 발주처도 원하지 않았던 일이고, 그때 심의 절차가 금액과 기간을 같이 조정하는 유일한 경로다. 심의 없이 구두로 추가 작업을 지시하면 조정 근거가 남지 않는다.

공고문에 적어야 하는 문장

발주처가 과업지시서에 적는 체크 문장의 문제는 체크를 비워 두는 것이다. 다음 세 가지를 같이 적으면 그 공백이 없어진다.

세 번째 문장이 있으면 계약상대자가 변경을 요청할 창구가 문서에 생긴다. 이 문장이 없으면 변경 요청을 어디에 내야 하는지부터 협의해야 한다.

과업지시서가 정하지 않는 것 — 계약 일반조건으로 넘기는 경계

과업지시서에 전부 담으려 하면 계약 일반조건과 같은 말을 두 번 쓰게 되고, 두 문서가 어긋나면 어느 쪽이 우선인지로 다툰다. 경계를 알고 쓰는 편이 낫다.

읽는 방법은 이렇다 — 계약 일반조건은 「언제·얼마나」를 정하고, 과업지시서는 「무엇을·어디까지」를 정한다. 지체상금률을 과업지시서에 또 적을 필요는 없지만, 무엇을 늦으면 지체로 보는지는 과업지시서의 일정과 산출물 목록에서 나온다.

공공 발주라면 내 계약에 붙는 일반조건이 국가계약인지 지자체계약인지부터 확인해야 한다. 조항이 다르고, 지자체 쪽에는 없는 보호장치가 있다. 그 차이는 소프트웨어 용역계약서와 일반조건에 장 단위로 정리했다.

작업장소와 원격개발을 적는 법

예전에는 발주기관 상주가 기본이었지만 지금은 상호 협의 사항이다. 과업지시서에 적어 둘 항목은 다음과 같다.

핵심 개발인력이 아닌 지원인력의 근무장소는 보안상 특별한 사유가 없으면 업체가 정할 수 있다는 것이 현재의 기준이다. 발주처가 전원 상주를 요구하려면 그 사유를 과업지시서에 적어야 한다. 근거 없이 상주를 요구하면 제안가격만 올라간다.

민간 발주에서 쓸 때

민간 발주에서는 제안요청서로 갈음하는 경우가 많다. 그래도 따로 두는 편이 나은 경우가 있는데, 판단 기준은 「범위가 바뀔 확률」이 아니라 「범위를 기억하는 사람이 바뀔 확률」이다.

민간에는 과업심의위원회 같은 절차가 없으므로 그 자리를 계약서 조항으로 대신 채운다. 변경 요청 창구, 승인권자, 승인까지의 기간 상한 세 가지를 계약서에 적어 두면 공공의 심의 절차와 비슷한 효과가 난다. 특히 기간 상한이 없으면 변경 승인이 무기한 미뤄지면서 일정만 밀린다.

흔한 실수 다섯 가지

자주 묻는 질문

과업지시서와 과업내용서는 다른 문서인가요? 같은 문서를 가리키는 다른 이름이다. 소프트웨어 진흥법 제50조는 「과업내용」이라는 용어를 쓰고, 기관 공고문은 대체로 「과업지시서」를 쓴다. 한 프로젝트 안에서 명칭을 통일하면 된다.

과업지시서 표준 양식은 어디서 받나요? 전 부처 공통 표준 양식은 없다. 국가법령정보센터에서 검색되는 [별지 24] 과업지시서[표준]은 국립수목원 연구개발사업 관리규정의 서식이라 소프트웨어 용역에는 맞지 않는다. 같은 분야·비슷한 규모의 공고문을 나라장터에서 찾아 목차를 참고하는 편이 낫다.

제안요청서만 쓰고 과업지시서는 생략해도 되나요? 민간 발주에서는 가능하다. 다만 계약서에 「제안요청서 및 제안서에 따른다」고만 적으면, 업체의 제안서 문구까지 의무가 되어 범위가 오히려 모호해진다. 확정 사항만 추린 문서를 따로 두는 편이 안전하다.

과업심의위원회는 민간 발주에도 있나요? 없다. 소프트웨어 진흥법 제50조는 국가기관등을 대상으로 한다. 민간에서는 변경 승인권자와 기간 상한을 계약서에 적어 같은 역할을 하게 만든다.

과업 범위가 늘어났는데 예산이 없으면 어떻게 하나요? 공공 사업이라면 계약상대자가 과업변경요청서를 내고 과업심의위원회 개최를 요청할 수 있으며, 발주기관은 특별한 사정이 없으면 이를 수용해야 한다. 예산을 이유로 무상 추가를 요구하는 것은 제도상 막혀 있다.

정리

과업지시서를 쓰는 일은 하고 싶은 것을 적는 작업이 아니라 경계를 긋는 작업이다. 그래서 잘 쓴 문서는 포함 목록이 아니라 제외 목록과 수량에서 구분된다.

세 가지만 남기면 된다.

수량을 적는다. 화면 몇 개, 게시물 몇 건, 연동 몇 건인지. 모르면 상한과 초과 시 정산 방법을 적는다. 비워 두는 것이 가장 비싸다.

제외를 적는다. 협의 중 한 번이라도 나왔지만 범위에 넣지 않기로 한 것을 세 줄로 남긴다. 범위가 닫히면 제안가격이 내려간다.

판정 기준을 숫자로 적는다. 「정상 동작」이 아니라 응답 시간, 결함 허용 건수, 지원 브라우저로 적는다. 그러면 검수가 협상이 아니라 확인이 된다.

공공 발주라면 여기에 하나가 더 붙는다 — 과업심의위원회를 열었는지, 언제 열었는지, 변경이 생기면 어떤 절차로 다시 여는지를 문서에 적어 두는 것. 이 세 문장이 범위 변경을 다툼이 아니라 절차로 만든다.