Photo by cottonbro studio on Pexels
외주 개발 잔금 치르기 전 반드시 확인해야 할 과업지시서의 힘
중소기업 대표가 내부 개발팀 없이 자체 업무 시스템이나 자사몰, 고객 관리 플랫폼(CRM) 등을 구축할 때 가장 흔히 선택하는 방법이 바로 '외주 개발(SI/외주 용역)'입니다. 하지만 현장에서는 프로젝트 잔금을 치르는 시점에 개발사와 기업 대표 사이에 심각한 갈등이 발생하는 경우가 적지 않습니다. 대표는 "처음 이야기했던 기능이 구현되지 않았다"고 주장하고, 개발사는 "그 기능은 초기 계약 금액에 포함되지 않은 추가 과업이므로 별도 견적을 내야 한다"고 대립하기 때문입니다.
제조업을 운영하는 A사의 실제 사례를 들어보겠습니다. A사는 재고 관리 및 주문 처리 시스템을 개발하기 위해 외주 개발사와 5,000만 원 규모의 계약을 체결했습니다. A사 대표는 당연히 스마트폰으로 외부에서 실시간 재고를 확인하고 바코드를 스캔하여 입출고 등록을 할 수 있을 것이라 생각했습니다. 그러나 잔금 지급을 앞두고 확인해 보니 웹 브라우저 PC 화면만 지원될 뿐, 모바일 화면 최적화와 바코드 스캔 연동 기능은 전혀 구현되어 있지 않았습니다. 외주 개발사는 "계약 당시 모바일 앱 연동 및 카메라 기능 제어는 과업 범위에 없었다"며 추가 개발비 1,500만 원을 요구했습니다. 결과적으로 A사는 일정 지연과 불필요한 추가 지출이라는 큰 손실을 입었습니다.
이러한 문제는 개발사의 불친절함 때문이 아니라, 프로젝트 시작 단계에서 '과업지시서(RFP 및 요구사항 정의서)'를 구체적으로 문서화하지 않았기 때문에 발생합니다. 구두로 진행된 수많은 대화는 법적, 기술적 효력을 갖기 어렵습니다. 따라서 중소기업 대표는 외주 개발 계약을 체결하기 전에 의도가 명확히 반영된 과업지시서를 직접 검토하고 잔금 지급의 기준이 되는 검수 항목을 정립해야 합니다. 본 글에서는 즉시 활용할 수 있는 과업지시서 양식과 작성 요령, 그리고 개발 완료 후 잔금을 지급하기 전 필수적으로 점검해야 할 검수 체크리스트를 상세히 제공합니다.
외주 개발 과업내역서 작성 양식 및 필수 포함 구조
과업내역서(또는 제안요청서)는 기업이 원하는 시스템의 목적, 과업 범위, 필수 기능, 납품 산출물을 명확하게 정의하는 문서입니다. 이 문서는 계약서의 첨부 서류로 활용되며, 추후 분쟁이 발생했을 때 핵심적인 판단 기준이 됩니다. 아래 양식을 복사하여 기업의 상황에 맞게 항목을 채워 넣고 개발사에 전달하시기 바랍니다.
| 구분 | 항목명 | 작성 내용 및 작성 가이드 |
|---|---|---|
| 1. 프로젝트 개요 | 추진 목적 및 배경 | 시스템을 도입하려는 이유와 최종 목표를 명시합니다. (예: 수기 엑셀 작업을 전산화하여 발주 오류율을 0%로 감소) |
| 1. 프로젝트 개요 | 개발 기간 및 예산 | 착수일로부터 완료일까지의 일정 및 부가세 포함 총 예산 범위를 명시합니다. |
| 2. 과업 범위 | 대상 사용자 및 매체 | 사용자 그룹(일반 고객, 내부 관리자, 현장 작업자) 및 지원 매체(PC 웹, 모바일 웹, Android/iOS 앱)를 지정합니다. |
| 2. 과업 범위 | 핵심 연동 시스템 | 기존에 사용 중인 외부 솔루션(PG 결제창, 문자 발송 API, 국세청 전자세금계산서, ERP 등)과의 연동 여부를 기술합니다. |
| 3. 기능 요구사항 | 기능 단위 세부 명세 | 시스템이 수행해야 하는 기능을 메뉴 단위로 분할하여 작성합니다. (상세 예시는 다음 단락 참조) |
| 4. 비기능 요구사항 | 성능, 보안 및 운영 조건 | 동시 접속자 수, 데이터 백업 주기, 보안 적용 수준, 서버 환경(AWS, KT Cloud, 자체 서버 등)을 정의합니다. |
| 5. 최종 산출물 | 인계 목록 | 소프트웨어 원천 소스코드, 시스템 설계서, 사용자/관리자 메뉴얼, 데이터베이스 명세서 등 인계받을 항목을 명시합니다. |
추가 비용 요구를 차단하는 구체적인 요구사항 명세 작성법
개발사와 외주 계약을 진행할 때 가장 경계해야 할 단어는 '일반적인 수준', '상식적인 기능', '깔끔한 디자인'과 같이 모호한 표현입니다. 대표자나 담당자가 생각하는 일반적인 수준과 개발사가 생각하는 기본 범위는 현저히 다릅니다. 문장이 모호할수록 개발사는 최소한의 기능만 구현하려 하고, 수정이나 추가 요청이 들어올 경우 추가 비용을 청구하게 됩니다.
요구사항을 명세할 때는 '주어 + 조건 + 동작 + 결과'가 명확히 드러나도록 작성해야 합니다. 또한 숫자와 구체적인 동작 방식을 포함해야 불필요한 분쟁을 예방할 수 있습니다.
잘못된 작성 예시와 올바른 작성 예시 비교
- 잘못된 예시 1: "고객이 편리하게 결제할 수 있는 시스템을 구축한다."
올바른 예시 1: "고객은 장바구니에 담긴 상품을 신용카드, 계좌이체, 카카오페이를 통해 결제할 수 있어야 하며, 결제 완료 시 즉시 주문 완료 알림톡이 고객 휴대폰 번호로 자동 발송되어야 한다." - 잘못된 예시 2: "관리자 페이지에서 재고 현황을 한눈에 파악할 수 있어야 한다."
올바른 예시 2: "관리자는 PC 브라우저에서 상품별 실시간 재고 수량을 조회할 수 있어야 하며, 재고 수량이 10개 이하로 떨어질 경우 관리자 메인 화면에 붉은색 경고 알림창이 표시되고 담당자 이메일로 알림이 발송되어야 한다." - 잘못된 예시 3: "엑셀 데이터 업로드 기능 지원."
올바른 예시 3: "관리자는 제공된 표준 엑셀 서식(.xlsx)을 통해 최대 5,000건의 대용량 거래처 데이터를 일괄 등록할 수 있어야 하며, 양식 오류가 발생할 경우 몇 번째 줄의 어떤 항목이 잘못되었는지 오류 리포트를 화면에 출력해야 한다."
위와 같이 구체적으로 기능을 정의해 두면, 개발사는 초기 견적 산정 시 작업 공수를 정확히 계산할 수 있고, 개발 완료 후 "이 기능은 원래 안 하기로 했습니다"라는 식의 오리를 발뺌할 수 없게 됩니다.
개발 완료 후 잔금 지급 기준이 되는 단계별 검수 체크리스트
프로젝트 개발이 완료되었다고 해서 개발사의 말만 믿고 잔금을 지급해서는 안 됩니다. 시스템 검수(Acceptance Testing)는 계약서에 명시된 모든 기능이 정상적으로 작동하는지 기업 측에서 직접 확인하는 단계입니다. 검수 과정에서 발견된 하자나 미비점은 '검수 지적사항 보고서'로 정리하여 개발사에 전달하고, 이에 대한 수정 조치가 완료된 후 최종 검수 확인서에 서명하고 잔금을 지급해야 합니다.
다음 체크리스트를 활용하여 항목별로 '합격(PASS)', '불합격(FAIL)', '보완 필요(N/A)'를 판정하시기 바랍니다.
| 검수 영역 | 세부 점검 항목 | 검수 방법 및 확인 기준 | 판정 |
|---|---|---|---|
| 기능성 검수 | 과업내역서 기능 일치 여부 | 과업지시서에 명시된 모든 기능이 오류 없이 정상 동작하는가? | 합격 / 불합격 |
| 기능성 검수 | 예외 처리 및 오류 메시지 | 잘못된 데이터 입력(예: 이메일 양식 오류, 빈칸 제출) 시 적절한 안내 문구가 표시되는가? | 합격 / 불합격 |
| 기능성 검수 | 외부 API 연동 상태 | PG 결제, SMS/알림톡, 지도, 외부 솔루션 연동이 실환경에서 정상 작동하는가? | 합격 / 불합격 |
| 호환성 검수 | 다양한 기기 및 브라우저 지원 | Chrome, Edge, Safari 등 주요 브라우저 및 모바일 기기 화면에서 레이아웃이 깨지지 않는가? | 합격 / 불합격 |
| 성능 및 보안 | 화면 로딩 속도 및 반응성 | 주요 페이지 진입 시 데이터 조회가 3초 이내에 완료되는가? | 합격 / 불합격 |
| 성능 및 보안 | 권한별 접근 제어 | 일반 사용자가 관리자 URL에 직접 접근할 수 없도록 권한 분리가 철저한가? | 합격 / 불합격 |
| 산출물 검수 | 소스코드 및 권한 이관 | 최신 소스코드가 Git 또는 별도 저장소로 인계되었으며, 개발자 계정이 대표 계정으로 이전되었는가? | 합격 / 불합격 |
| 산출물 검수 | 매뉴얼 및 문서화 | 관리자가 직접 시스템을 운영할 수 있는 운영 매뉴얼 및 테이블 명세서가 제출되었는가? | 합격 / 불합격 |
외주 계약서 작성 시 대표가 반드시 챙겨야 할 3가지 독소조항 방지법
과업지시서를 잘 만들었더라도 계약서 내용에 기업 측에 불리한 독소조항이 포함되어 있다면 법적으로 보호받기 어렵습니다. 외주 개발 표준계약서를 작성하거나 개발사 측의 계약서를 검토할 때 중소기업 대표가 반드시 확인해야 하는 3가지 핵심 법률·실무 항목입니다.
1. 무상 하자보수 기간 및 범위 명확화
개발 완료 후 발생하는 시스템 버그나 오류는 검수 기간에 100% 발견하기 어렵습니다. 따라서 무상 하자보수 기간을 명시해야 합니다. 일반적으로 소프트웨어 개발 용역의 무상 하자보수 기간은 검수 완료일로부터 **1년**으로 설정하는 것이 관례입니다. 계약서에 "무상 하자보수 기간은 잔금 지급일로부터 12개월로 하며, 단순 기능상의 오류 및 과업지시서 명세와 다른 동작은 무상으로 수정한다"라는 내용을 반드시 명시해야 합니다. 단순한 스펙 변경이나 신규 기능 추가는 하자보수에 해당하지 않음을 명심해야 합니다.
2. 지적재산권(IP) 및 소스코드 소유권 귀속
비용을 지불하고 개발했음에도 불구하고, 소스코드의 소유권이 개발사에 귀속된다는 계약 조항 때문에 나중에 시스템을 수정하거나 타 개발사에 이관할 때 거액의 라이선스 비용을 요구받는 피해 사례가 빈번합니다. 계약서 조항에 **"본 계약에 따라 납품된 최종 산출물 및 소스코드, 저작권, 특허권 등 일체의 지적재산권은 발주사(기업)에게 귀속된다"**라는 문구가 들어있는지 확인해야 합니다. 만약 개발사가 보유한 기존 엔진이나 솔루션을 재활용하는 방식이라면, 이에 대한 이용권(라이선스)이 영구적이고 무제한으로 제공되는지 확인해야 합니다.
3. 지체상금(일정 지연에 따른 손해배상)율 설정
외주 개발 프로젝트의 가장 큰 리스크 중 하나는 오픈 일정이 무기한 연기되는 것입니다. 일정 지연을 방지하기 위해서는 지체상금 조항이 필수적입니다. 일반적으로 지연 1일당 총 계약금액의 **1,000분의 1.25 내지 1,000분의 1.5** 수준으로 지체상금을 설정합니다. 계약서에 "개발사의 귀책사유로 인하여 정해진 납기일 내에 과업을 완료하지 못할 경우, 지연일수 1일당 총 계약금액의 0.15%에 해당하는 금액을 잔금에서 공제한다"는 조항을 포함시켜 개발사가 일정을 준수하도록 강제해야 합니다.
외주 관련 법률 및 고시 확인 시 주의사항
소프트웨어 사업 계약이나 하도급 거래와 관련된 법률, 공정거래위원회 표준약관, 과업변경에 따른 대가 증액 관련 고시는 주기적으로 개정됩니다. 따라서 계약 체결 및 법적 분쟁 예방을 위해서는 다음 사항을 유의해야 합니다.
하도급거래 공정화에 관한 법률, 소프트웨어 진흥법, 행정안전부/과학기술정보통신부의 소프트웨어사업 계약 관련 고시 등은 개정 시점에 따라 지체상금 상한선, 하도급 대금 지급 기일, 과업변경심의위원회 절차 등의 구체적인 기준이 달라질 수 있습니다. 따라서 본 글에서 제시된 비율과 절차는 표준적인 실무 기준 가이드로 참고하시되, 계약 체결 직전 최신 법령 정보 및 국가법령정보센터의 표준하도급계약서(소프트웨어사업 분야) 양식을 반드시 직접 확인하시기 바랍니다. 필요할 경우 법률 전문가나 전문 변리사의 자문을 거치는 것이 가장 안전합니다.
외주 프로젝트 성공을 위한 핵심 실행 항목 요약
외주 개발을 진행하는 중소기업 대표가 실패 없이 원하는 시스템을 안전하게 구축하기 위해 오늘 당장 실행해야 할 핵심 항목은 다음과 같습니다.
- 구체적인 과업지시서 작성: 추상적인 표현(예: 편리한, 깔끔한)을 모두 제거하고, 주어/조건/동작/결과가 명확한 요구사항 명세서를 작성하여 계약서에 첨부합니다.
- 소스코드 및 지적재산권 독점 귀속 명시: 잔금 지급 시 최신 소스코드와 개발 문서 일체를 넘겨받고, 지적재산권이 자사에 귀속됨을 계약 조항으로 확정합니다.
- 단계별 검수표에 따른 잔금 지급: 개발사의 일방적인 완료 통보에 현혹되지 않고, 대표 및 실무자가 직접 체크리스트 항목을 검수한 후 지적사항 보완이 끝난 시점에 잔금을 처리합니다.
- 1년 무상 하자보수 및 지체상금 조항 반영: 일정 지연을 막는 지체상금 비율과 오픈 후 최소 1년간 적용되는 무상 하자보수 조건이 계약서에 들어있는지 확인합니다.