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

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

이 글은 소프트웨어·시스템 용역을 발주하는 쪽이 과업지시서를 쓸 때 무엇을 적어야 하는지 정리한 것이다. 공공 발주라면 소프트웨어 진흥법이 요구하는 절차가 따로 있고, 민간 발주라도 그 구조를 빌려 쓰는 편이 안전하다.

검색해서 나오는 「표준 양식」을 그대로 쓰면 안 된다

「과업지시서 표준」으로 검색하면 국가법령정보센터의 `[별지 24] 과업지시서[표준]` 파일이 상단에 걸린다. 구글 AI 답변도 이 파일을 표준 양식으로 안내한다.

그런데 이 파일을 열어 보면 첫 줄이 이렇다.

> ■ 국립수목원 연구개발사업 관리규정 [별지 제24호서식]

정부 공통 표준 서식이 아니라 국립수목원의 위탁연구 서식이다. 목차도 「연구목적 및 필요성 / 연구수행 방안 / 일반사항」으로 연구용역 전용이고, 본문 조항은 연구노트 작성과 위탁연구보고서 제출 의무로 채워져 있다. 소프트웨어 개발 용역에 그대로 쓰면 정작 필요한 항목이 하나도 없다.

과업지시서에는 전 부처 공통 표준 양식이 없다. 기관마다 자기 규정의 별지 서식을 쓴다. 그래서 남의 양식을 받아 오는 것보다, 아래에서 정리하는 항목이 빠지지 않았는지를 기준으로 삼는 편이 낫다.

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

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

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

요구사항 정의서와의 관계는 순서로 이해하면 된다. 과업지시서가 범위의 경계를 긋고, 요구사항 정의서가 그 안을 기능 단위로 채운다. 경계가 흐린 상태로 안을 채우기 시작하면 착수 후에 범위가 계속 늘어난다. 각 문서를 어떻게 쓰는지는 요구사항 정의서 작성법에서 다룬다.

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

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

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

정리하면 이렇다.

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

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

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

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

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

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

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

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

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

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

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

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

심의 대상은 다음과 같다.

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

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

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

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

과업변경 — 발주처가 가장 많이 다투는 지점

착수 후에 요구가 늘어나는 것은 소프트웨어 사업에서 정상이다. 문제는 그 변경을 처리하는 경로가 과업지시서에 없을 때다.

소프트웨어 진흥법 제50조 제3항과 같은 법 시행령 제47조 제1항 제2호·제3호는 이 경로를 정해 두고 있다.

발주처 입장에서 이 조항의 의미는 분명하다. 「예산이 없으니 그냥 해 달라」가 제도적으로 막혀 있다. 과업지시서에 변경 경로를 미리 적어 두면 착수 후 협의가 훨씬 빨라진다. 적어 둘 것은 세 가지다.

• 변경 요청을 접수하는 창구와 서식
• 심의까지 걸리는 기간의 상한
• 심의 전까지 해당 작업을 진행할지 중단할지

세 번째를 안 적어서 생기는 손실이 의외로 크다. 심의를 기다리는 동안 개발이 멈추면 전체 일정이 그만큼 밀린다.

하도급을 어디까지 허용할 것인가

과업지시서에 하도급 조건을 안 적으면 계약 후에 협의할 근거가 사라진다. 소프트웨어 진흥법 제51조가 정하는 제한은 다음과 같다.

승인 기준도 정해져 있다. 「소프트웨어사업 계약 및 관리감독에 관한 지침」 별표 3의 하도급계약 적정성 판단 세부기준에 따라 평가해 85점 이상인 경우에만 승인한다. 85점을 넘더라도 하도급 계약 조건 때문에 사업 수행이 어렵다고 인정되면 사유를 적어 승인을 거절할 수 있다.

발주처가 과업지시서에 적어 둘 것은 제한 조문 자체가 아니라 운영 방식이다. 하도급 계획서를 언제까지 받을지, 기술성 평가에 하도급계획 적정성을 넣을지, 승인 절차에 며칠을 쓸지를 미리 정해 둔다.

지식재산권과 산출물 반출

소프트웨어 사업의 지식재산권은 발주기관과 계약상대자의 공동 소유를 원칙으로 한다. 과업지시서에는 이 원칙을 적고, 세부는 협의로 정한다고 쓰는 것이 일반적이다.

여기서 발주처가 실제로 정해야 하는 것은 소유권 자체보다 사용 범위다.

소스코드 보관과 인도 조건은 소스코드 에스크로·하자보수 계약에서 따로 다룬다. 과업지시서에서는 「반출 절차를 둔다」는 사실과 신청 창구·소요 기간까지만 적어도 충분하다.

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

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

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

검수 기준은 과업지시서에서 정해진다

검수 단계에서 다투는 이유는 대부분 검수 기준이 검수 시점에 처음 논의되기 때문이다. 과업지시서에 아래 네 가지를 미리 넣어 둔다.

특히 결함 등급별 허용 건수를 적어 두면 「사소한 버그가 남았는데 검수를 못 해 주겠다」는 교착이 사라진다. 요구사항을 검증 가능한 문장으로 쓰는 법은 요구사항 정의서 작성법에, 화면 단위 판정 기준은 화면설계서 작성법에 정리해 두었다.

민간 발주에서 쓸 때

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

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

흔한 실수 다섯 가지

과업지시서 완성 8단계

4번이 빠진 과업지시서가 대부분이다. 포함 목록만 있는 문서는 경계를 긋지 못한다.

트리숲이 과업지시서를 다루는 방식

트리숲은 발주처가 과업지시서 초안을 들고 오면 먼저 제외 항목부터 같이 적는다. 포함 목록은 발주처가 이미 잘 적어 오는 반면, 제외 목록은 거의 비어 있기 때문이다. 이 작업만으로 착수 후 범위 협의 횟수가 눈에 띄게 줄어든다.

공공 사업이라면 과업심의위원회 일정이 전체 일정의 앞단을 잡아먹는다. 심의 개최 시점을 역산해 착수 일정을 짜고, 심의 전까지 진행할 작업과 대기할 작업을 과업지시서 단계에서 갈라 둔다.

검수 기준은 요구사항 정의서와 같은 항목 번호를 쓰도록 맞춘다. 번호가 다르면 검수 때 두 문서를 대조하는 데만 며칠이 든다. 견적 산정 근거를 함께 맞추는 방법은 기능점수(FP) 기반 비용 산정에 정리해 두었다.

자주 묻는 질문

과업지시서와 과업내용서는 다른 문서인가요?

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

과업지시서 표준 양식은 어디서 받나요?

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

제안요청서만 쓰고 과업지시서는 생략해도 되나요?

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

과업심의위원회는 민간 발주에도 있나요?

없다. 소프트웨어 진흥법 제50조는 국가기관등을 대상으로 한다. 민간에서는 변경 승인권자와 기간 상한을 계약서에 적어 같은 역할을 하게 만든다.

과업 범위가 늘어났는데 예산이 없으면 어떻게 하나요?

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

정리

과업지시서는 하고 싶은 일을 적는 문서가 아니라 어디까지 할지 경계를 긋는 문서다. 검색해서 나오는 표준 양식은 대개 다른 분야의 서식이므로 그대로 쓰지 말고, 과업개요·범위·제외 항목·일정·수행 지침·검수 기준이 빠지지 않았는지로 점검하는 편이 낫다.

공공 발주라면 소프트웨어 진흥법이 이미 상당 부분을 정해 두었다. 과업내용 확정과 변경은 과업심의위원회를 거치고(제50조), 하도급은 50% 상한과 사전승인이 걸린다(제51조). 이 절차를 과업지시서에 미리 적어 두는 것만으로 착수 후 협의가 크게 줄어든다.

발주 문서 전체를 어떤 순서로 준비하는지는 요구사항 정의서 작성법에서, 업체 선정 기준은 외주 업체 선정 스코어카드에서 다룬다.