과업지시서 작성법: 범위·산출물·검수 기준까지 실무 예시로 정리

과업지시서 작성법에서 가장 중요한 건 길게 쓰는 일이 아니다. 무엇을 만들고, 어디까지 포함하며, 무엇을 넘기고, 어떤 상태면 완료인지를 서로 같은 뜻으로 읽게 만드는 일이다. 처음 외주 개발을 맡기는 PM이라면 목적, 포함·제외 범위, 산출물, 일정, 검수 기준, 변경 절차를 먼저 고정하면 된다. 이 여섯 가지가 선명하면 견적도 비교하기 쉬워지고, 막판의 “그것도 당연히 포함인 줄 알았어요”도 크게 줄어든다!

과업지시서란 무엇이고 왜 필요한가?

과업지시서는 발주자와 수행사가 합의한 업무 범위와 완료 기준을 구체화한 문서다. 견적서가 비용을 설명한다면, 과업지시서는 그 비용으로 수행할 일을 설명한다. 계약서에 첨부되면 일정·산출물·검수와 변경 협의의 기준점 역할도 한다.

기획재정부 계약예규인 용역계약일반조건은 소프트웨어사업의 과업내용서를 계약당사자가 합의한 사업 범위를 구체적으로 적은 문서이자, 업무 범위와 과업 변경의 기준서로 설명한다. 다만 공공 SW 사업에 적용되는 절차와 민간 외주 계약은 법적 구조가 다를 수 있다. 이 글의 예시는 초보 IT PM이 실무 문서를 설계하는 방법으로 활용하고, 실제 계약은 조직의 계약 담당자나 전문가와 확인하자.

제안요청서·요구사항 정의서와 무엇이 다를까?

문서	주로 답하는 질문	작성 시점
제안요청서(RFP)	어떤 문제를 풀 업체와 제안을 찾는가?	업체 선정 전
과업지시서	누가 무엇을 어디까지 수행하고 무엇을 납품하는가?	견적·계약 협의 전후
요구사항 정의서	기능이 어떤 조건과 규칙으로 동작해야 하는가?	분석·설계 단계
검수확인서	합의한 결과가 실제로 납품되고 통과했는가?	중간·최종 검수 시

작은 프로젝트에서는 문서를 합치기도 한다. 그래도 선정 기준, 수행 범위, 기능 요구, 검수 결과가 서로 섞여 사라지지 않게 구분하는 편이 좋다.

과업지시서 작성법의 핵심 구조 6가지

좋은 과업지시서는 아래 여섯 항목이 앞뒤로 연결된다.

1. 목적과 배경: 이 일을 왜 하는가?
2. 과업 범위: 포함하는 일과 포함하지 않는 일은 무엇인가?
3. 산출물: 무엇을 어떤 형식과 상태로 넘기는가?
4. 일정과 마일스톤: 언제 무엇을 확인하고 완료하는가?
5. 검수 기준: 누가 어떤 환경과 방법으로 합격을 판단하는가?
6. 변경·역할·의사소통: 범위가 바뀌면 어떻게 승인하고 영향을 반영하는가?

핵심은 항목을 채우는 데서 끝나지 않는다. 목적에서 시작한 요구가 범위에 들어가고, 범위의 결과가 산출물로 남고, 산출물을 검수 기준으로 확인할 수 있어야 한다. 검수할 수 없는 범위와 범위에 없는 산출물은 다시 확인할 신호다.

과업지시서 작성 순서: 초보 PM도 따라 하는 6단계

1. 목적을 결과 중심 한 문장으로 쓴다

“예약 시스템 개발”처럼 명사만 쓰면 수행사가 알아서 빈칸을 채우게 된다. 프로젝트가 끝났을 때 달라져야 하는 상태를 적어 보자.

오프라인으로 받던 원데이 클래스 예약을 웹에서 접수하고, 운영자가 날짜별 신청자와 정원을 확인할 수 있는 MVP를 구축한다.

목적에는 대상 사용자, 현재 문제, 기대하는 변화가 들어가면 좋다. 다만 “매출 30% 증가”처럼 개발사가 통제할 수 없는 사업 성과를 납품 기준으로 바로 두면 곤란하다. 사업 목표와 계약상 검수 조건은 구분하자.

2. 포함 범위와 제외 범위를 나란히 적는다

범위는 기능 이름보다 사용자 행동과 운영 결과가 보이게 쓴다.

포함 범위 예시

• 사용자는 클래스 목록과 상세 정보를 볼 수 있다.
• 사용자는 날짜와 인원을 선택해 예약을 신청할 수 있다.
• 운영자는 관리자 화면에서 신청 내역을 조회하고 상태를 변경할 수 있다.
• 정원이 찬 회차에는 추가 신청이 차단되고 안내 문구가 표시된다.

제외 범위 예시

• 앱스토어·플레이스토어용 네이티브 앱 개발
• 결제 취소·부분 환불 자동화
• 다국어와 해외 결제
• 마케팅용 콘텐츠 제작 및 광고 운영

“필요한 기능 일체”나 “관리자 기능 포함”은 범위처럼 보이지만 해석의 여지가 너무 크다. 제외 범위는 일을 덜 하려는 문장이 아니라, 이번 계약과 다음 단계의 경계선을 합의하는 문장이다.

3. 산출물을 파일명·형식·권한까지 쓴다

산출물은 “웹사이트 1식”보다 구체적이어야 한다. 납품 후 다른 사람이 열고, 운영하고, 수정할 수 있는 상태인지까지 생각해 보자.

산출물	형식·제출 방식	완료 상태
운영 웹 서비스	운영 URL	합의한 도메인과 HTTPS로 접속 가능
소스코드	발주사 소유 저장소	최신 소스, 실행 안내, 환경변수 목록 포함
화면·디자인 원본	Figma 원본과 내보낸 파일	편집 권한 이전, 사용 글꼴·이미지 출처 명시
관리자 매뉴얼	PDF 또는 Markdown	계정 발급, 예약 확인, 상태 변경 절차 포함
테스트 결과	체크리스트 또는 보고서	요구사항 ID별 결과와 미해결 항목 표시

서버 계정, 도메인, 분석 도구, 디자인 원본처럼 소유권과 접근 권한을 넘겨받아야 하는 항목은 별도 줄로 적어 두는 편이 안전하다.

4. 일정은 납기일 하나가 아니라 검토 지점으로 나눈다

완료일만 있으면 잘못된 방향을 마지막에 발견하기 쉽다. 작은 프로젝트도 최소한 착수, 중간 확인, 검수본, 최종 납품으로 나눠 보자.

• D+0: 착수 회의와 자료 전달
• D+5: 사용자 흐름·화면 구조 확인
• D+12: 주요 기능 데모
• D+17: 검수본 제출
• D+20: 보완 반영과 최종 산출물 제출

날짜와 함께 누가 무엇을 승인해야 다음 단계로 넘어가는지 적으면 대기 시간도 일정에 반영할 수 있다.

5. 검수 기준을 “재현 가능한 시험”으로 바꾼다

“오류 없이 정상 동작”이나 “발주처가 만족하는 수준”은 객관적으로 확인하기 어렵다. 검수 기준은 조건, 행동, 예상 결과가 보이게 쓴다.

나쁜 예

예약 기능이 정상적으로 동작해야 한다.

좋은 예

Chrome 최신 버전과 iOS Safari에서 일반 사용자 계정으로 ① 클래스를 선택하고 ② 예약 가능 날짜와 2명을 입력해 ③ 신청을 완료하면, 예약번호가 포함된 완료 화면이 표시되고 관리자 예약 목록에 1건이 생성된다.

예외 조건도 한두 개는 꼭 적자.

잔여 정원이 1명인 회차에서 2명을 선택하면 제출이 차단되고 “신청 가능한 인원은 1명입니다”라는 안내가 표시된다.

검수표에는 요구사항 ID, 시험 환경, 입력값, 실행 절차, 예상 결과, 실제 결과, 통과 여부, 보완 기한을 두면 관리하기 쉽다. 모든 버그를 0개로 만드는 조건보다 출시를 막는 결함과 추후 보완 가능한 결함의 기준을 미리 나누는 편이 현실적이다.

6. 변경 요청과 역할을 문서 안에 연결한다

진행 중 새로운 요청이 나오는 일은 자연스럽다. 문제는 요청이 구두로 추가되고 일정·비용 영향은 기록되지 않는 경우다.

변경 요청에는 다음 항목을 남긴다.

• 기존 내용과 변경하려는 내용
• 변경 사유와 우선순위
• 영향받는 화면·기능·산출물
• 추가 비용과 일정 영향
• 승인자와 승인일

공공 SW 사업에서는 소프트웨어 진흥법 제50조가 과업내용의 확정과 변경, 그에 따른 계약금액·기간 조정을 과업심의위원회 심의 사항으로 둔다. 민간 프로젝트에 이 절차가 그대로 적용되는 것은 아니지만, 변경 범위와 비용·일정을 함께 승인한다는 원칙은 실무에서도 유용하다.

바로 복사해 쓰는 과업지시서 빈칸 템플릿

아래 템플릿은 소규모 웹·앱 외주를 시작할 때 쓸 수 있는 기본 골격이다. 조직의 계약 양식이 있다면 그 문서에 맞춰 항목을 옮기면 된다.

# [프로젝트명] 과업지시서

## 1. 목적과 배경
- 대상 사용자:
- 현재 문제:
- 과업 완료 후 기대 상태:

## 2. 과업 기간과 일정
- 전체 기간:
- 착수 회의:
- 중간 검토:
- 검수본 제출:
- 최종 납품:

## 3. 과업 범위
### 포함 범위
- [F-01]
- [F-02]

### 제외 범위
-
-

## 4. 산출물
| ID | 산출물 | 형식·제출 위치 | 제출 시점 | 완료 상태 |
|---|---|---|---|---|
| D-01 |  |  |  |  |

## 5. 검수 기준
| 요구사항 ID | 시험 환경·조건 | 실행 방법 | 예상 결과 | 통과 기준 |
|---|---|---|---|---|
| F-01 |  |  |  |  |

## 6. 역할과 의사소통
- 발주자 담당·승인자:
- 수행사 담당자:
- 정기 회의와 보고 방식:
- 자료 제공 책임과 기한:

## 7. 변경과 보완
- 변경 요청 접수 방식:
- 비용·일정 영향 검토 및 승인자:
- 검수 기간:
- 보완 범위와 기한:

## 8. 보안·권리·인수인계
- 계정과 개인정보 처리:
- 결과물·소스·디자인 원본의 권리:
- 외부 이미지·글꼴·라이브러리 목록:
- 계정·도메인·저장소 권한 이전:

과업지시서 검토 체크리스트

작성 후에는 문장이 멋진지보다 제3자가 같은 뜻으로 읽을 수 있는지 확인하자.

• 목적에 대상 사용자와 해결할 문제가 보인다.
• 포함 범위와 제외 범위가 함께 적혀 있다.
• 기능마다 식별 가능한 ID가 있다.
• 산출물의 형식, 제출 위치, 권한 이전 상태가 적혀 있다.
• 중간 검토일과 최종 납품일이 구분돼 있다.
• 검수 기준에 환경, 행동, 예상 결과가 있다.
• 예외 상황과 보완 기한이 최소 한 번 이상 등장한다.
• 변경 요청이 비용·일정 영향과 함께 승인되도록 되어 있다.
• 개인정보, 보안, 저작권, 계정 인수인계 항목을 확인했다.
• 계약서·견적서·요구사항 정의서와 용어와 범위가 맞는다.

정보통신산업진흥원의 소프트웨어사업 요구사항 분석 적용 가이드 안내도 공공 SW 사업에서 요구사항을 세부적으로 공개하고 분석하는 기준을 설명한다. 오래된 안내 자료이므로 현재 법령·고시와 함께 확인해야 하지만, “요구를 세분화하고 검증 가능한 단위로 관리한다”는 문서 작성 원칙을 이해하는 데 참고할 수 있다.

과업지시서 작성법 FAQ

과업지시서는 발주자와 수행사 중 누가 작성하나요?

보통 발주자가 초안을 만들고 수행사와 협의해 현실적인 범위·일정·산출물로 확정한다. 발주자가 업무 목적과 우선순위를 가장 잘 알고, 수행사는 기술적 난이도와 누락된 전제조건을 확인할 수 있기 때문이다. 한쪽이 혼자 완성하기보다 계약 전에 서로 문장별 해석을 맞추는 과정이 중요하다.

과업지시서와 계약서 중 하나만 있어도 되나요?

역할이 다르다. 계약서는 대금, 책임, 해지, 권리 등 거래 조건을 다루고, 과업지시서는 구체적인 수행 내용과 납품·검수 기준을 다룬다. 과업지시서를 계약서의 별첨으로 연결하고 문서명·버전·작성일을 명시하면 기준 문서가 무엇인지 분명해진다.

개발하면서 범위가 바뀌면 과업지시서를 다시 써야 하나요?

문서 전체를 매번 새로 쓰기보다 변경요청서나 변경 이력표로 기존 항목과 변경 항목을 연결하는 편이 관리하기 쉽다. 변경 전후 내용, 사유, 비용·일정 영향, 승인자를 남기고 기준 버전을 갱신하자. 메신저 합의만 남기면 나중에 어느 문장이 최종인지 찾기 어렵다.

검수 기준은 얼마나 자세히 써야 하나요?

다른 담당자가 그대로 따라 해도 같은 통과·실패 판단을 내릴 정도면 된다. 모든 클릭을 지나치게 적기보다 핵심 업무 흐름, 중요한 예외, 지원 환경, 성능·보안처럼 계약상 중요한 비기능 조건을 우선하자.

과업지시서 작성법 핵심 정리

과업지시서 작성법의 핵심은 범위와 완료의 경계를 검수 가능한 문장으로 바꾸는 것이다. 목적을 한 문장으로 정리한 뒤 포함·제외 범위를 나누고, 각 범위가 산출물과 검수 기준으로 이어지는지 확인하자. 여기에 일정의 검토 지점과 변경 승인 절차까지 붙이면 초보 PM도 “누가 알아서 해 주겠지” 대신 합의된 기준으로 프로젝트를 운영할 수 있다~

참고한 최신 출처

• 국가법령정보센터: 기획재정부 계약예규 용역계약일반조건
• 국가법령정보센터: 소프트웨어 진흥법 제50조
• 국가법령정보센터: 소프트웨어사업 계약 및 관리감독에 관한 지침
• 정보통신산업진흥원: 소프트웨어사업 요구사항 분석 적용 가이드 안내