SI 외주 개발 계약 전, 산출물과 검수 기준을 정하는 5단계

“기능 목록은 받았는데, 이 정도면 개발이 끝난 것인지 모르겠습니다.”

“테스트하다가 불편한 점이 나오면 무상 수정인지 추가 비용인지 어떻게 나누죠?”

“대표가 최종 확인하기 전에 무엇을 보고 승인해야 할지 막막합니다.”

SI 외주 계약 전에는 기능의 개수보다 어떤 결과물을 어떤 조건에서 완료로 승인할지를 먼저 정해야 합니다. 산출물과 검수 기준이 연결돼 있어야 개발 완료, 보완, 범위 변경을 같은 기준으로 판단할 수 있습니다.

크로플에서 웹·앱·업무 시스템 SI 프로젝트를 수행하며 보는 문제도 여기에 있습니다. 요구사항 문서가 길어도 실제 검수 장면이 그려지지 않으면, 막판에 “이것도 당연히 포함 아닌가요?”라는 논의가 길어집니다. 계약 전에는 기능명을 나열하는 데서 멈추지 않고, 발주자와 개발사가 같은 사용자 행동과 결과를 확인할 수 있는 문장으로 바꿔야 합니다.

기능 목록만으로 검수가 가능한가요?

어렵습니다. 기능명은 개발 범위를 가리킬 뿐, 완료 여부를 판정할 조건까지 알려 주지는 못합니다. 사용자, 시작 조건, 행동, 기대 결과, 확인 방법을 함께 적어야 검수 기준이 됩니다.

공공 소프트웨어사업 요구사항 분석·적용 가이드는 요구사항을 구체화하고, 사업수행계획서와 함께 검사·인수시험 및 사업 인수 시 점검사항을 정의하는 방향을 제시합니다. 이 가이드는 공공 사업 중심 자료이므로 민간 SI 계약에 같은 방식이 법적으로 강제된다는 뜻은 아니지만, 계약 전 확인 항목을 설계하는 참고 틀로는 활용할 수 있습니다.

예를 들어 ‘회원가입 기능’이라고만 쓰면 가입 방식, 약관 동의, 중복 이메일 처리, 가입 후 이동 화면을 알 수 없습니다. 아래 표는 이를 검수 문장으로 바꾸는 형식의 예시입니다.

이 표가 특정 서비스의 정답은 아닙니다. 디자인이 중요한 프로젝트라면 화면별 문구, 해상도별 구성, 로고 파일과 디자인 원본의 인도 범위도 적어야 합니다. 관리자 기능이라면 누가 어떤 권한으로 무엇을 조회·수정하는지 별도 기준으로 분리하는 편이 좋습니다.

검수 기준은 ‘기능이 있다’는 설명이 아니라, 정해진 조건에서 사용자가 수행한 행동과 확인 가능한 결과를 적는 문장입니다.

산출물은 무엇까지 받아야 하나요?

산출물은 화면이나 앱 설치 파일이 아니라, 발주사가 인수 후 운영하는 데 필요한 결과물의 묶음으로 정해야 합니다. 필요한 항목은 프로젝트마다 다르므로, “무엇을 받는가”와 “누가 어떤 형식으로 받는가”를 분리해 적으세요.

발주 전에는 다음 다섯 항목을 확인할 수 있습니다.

1. 사용자 결과물: 웹사이트, 앱 배포물, 관리자 페이지처럼 실제 접속할 대상
2. 기획·디자인 자료: 화면 정의서, 디자인 시안, 수정 확정본 등 계약에 포함된 문서
3. 운영 자료: 관리자 계정 전달 방식, 운영자가 알아야 할 절차나 매뉴얼의 포함 여부
4. 개발 결과물 인도 범위: 소스코드, 저장소 접근 권한, 빌드·배포 자료를 넘기는지 여부
5. 인수 시점과 형식: 검수 승인 전후 어느 때 전달하는지, 어디에 기록하는지

모든 프로젝트에 이 목록이 전부 필요한 것은 아닙니다. 단순 홍보 페이지와 내부 업무 시스템은 관리자 매뉴얼, 초기 데이터 입력, 운영자 교육의 필요성이 다를 수 있습니다. 반대로 계약 범위 밖의 지속 운영이나 콘텐츠 입력까지 산출물처럼 적으면, 개발 완료 이후 역할이 흐려질 수 있습니다.

저는 구현 전에 ‘무엇을 만들고 무엇은 만들지 않을지’를 문서로 분리하는 편입니다. 발주사도 “이 자료가 없으면 인수 후 업무가 멈추는가?”를 기준으로 보면 됩니다. 그렇다면 그 자료는 산출물 또는 별도 지원 범위로 명시할 대상입니다.

검수 시나리오는 누가, 언제, 어떻게 확인해야 하나요?

검수는 납품 직전에 처음 하는 테스트가 아니라, 계약 전에 합의한 업무 흐름을 단계별로 확인하는 과정으로 설계하는 편이 좋습니다. 대표는 사업 목적과 우선순위를 확인하고, 실사용자는 실제 입력·조회·처리 흐름을 테스트하는 방식으로 역할을 나눌 수 있습니다.

화면 단위보다 업무 흐름 단위로 시작하면 기준이 선명해집니다. ‘관리자 페이지가 열린다’보다 ‘관리자가 신청 내용을 조회하고 상태를 변경했을 때 그 결과가 사용자 화면에 반영된다’가 검수 가능한 문장에 가깝습니다.

다음 순서로 정리해 보세요.

1. 검수자를 지정합니다. 최종 승인권자와 실사용자를 구분합니다.
2. 핵심 업무 흐름을 고릅니다. 가입, 신청, 결제, 조회, 승인처럼 사업 운영에 직접 연결되는 흐름부터 확인합니다.
3. 테스트 조건을 준비합니다. 테스트 계정, 입력 데이터, 권한별 계정 등 재현에 필요한 조건을 정합니다.
4. 통과와 보완의 기준을 적습니다. 기존 기준 미충족인지, 새 요청인지 판단할 문장을 만듭니다.
5. 승인 기록 방식을 정합니다. 의견을 모을 장소와 최종 승인 의사표시 방식을 정합니다.

업무 시스템에서는 같은 정보가 사용자 화면, 관리자 화면, 다운로드 자료에서 어떻게 보여야 하는지도 중요합니다. 발주자가 기술 구조를 이해할 필요는 없지만, 등록한 정보가 각 화면에서 어떤 상태로 보여야 하는지는 검수 시나리오에 넣어야 합니다.

대법원은 도급계약에서 목적물의 인도가 단순한 점유 이전만이 아니라, 도급인이 검사 후 계약 내용대로 완성됐음을 명시적 또는 묵시적으로 시인하는 것까지 포함할 수 있다고 판단했습니다. 다만 개별 계약의 내용과 이행 경위에 따라 결론은 달라질 수 있으므로, 이를 모든 소프트웨어 계약에 동일하게 적용할 수는 없습니다.

수정 요청은 무상 보완과 추가 개발을 어떻게 나누나요?

기존 검수 기준을 충족하지 못한 보완과, 합의된 범위를 넓히는 변경 요청은 구분해야 합니다. 기준 문서와 변경 승인 절차가 있어야 요청이 생겼을 때 기능별 해석 다툼을 줄일 수 있습니다.

합의된 화면에서 버튼을 눌러도 다음 단계로 이동하지 않는다면 우선 기존 기준을 충족하는지 확인할 보완 항목입니다. 반면 원래 없던 승인 단계, 외부 서비스 연동, 새로운 사용자 유형을 더하는 요청은 화면·데이터·일정에 미치는 영향을 다시 검토할 변경 요청일 수 있습니다.

다만 경계가 늘 명확한 것은 아닙니다. 기획서에 ‘관리자 조회’만 있고 필터, 다운로드, 권한별 조회 범위가 비어 있다면 어느 한쪽의 당연한 요구라고 단정하기 어렵습니다. 변경 요청이 생기면 다음을 다시 확인하세요.

• 최초 요구사항과 검수 기준에 해당 내용이 있는가
• 화면, 데이터, 외부 연동, 일정 중 어디에 영향이 있는가
• 기존 일정 안에서 처리 가능한가
• 비용과 일정 조정을 누가 최종 승인하는가

민법은 도급 목적물에 하자가 있을 때 도급인이 상당한 기간을 정해 보수를 청구할 수 있는 기본 틀을 둡니다. 그러나 이 규정만으로 소프트웨어의 기능 결함과 계약 당시 없던 기능 추가를 자동으로 구분할 수는 없습니다. 하자 정의, 통지 방식, 보완 기한, 재검수, 무상 보완 범위는 계약 내용과 실제 합의에 따라 달라질 수 있으므로, 중요한 계약은 법률 전문가에게 검토받는 것이 안전합니다.

국가기관 등의 소프트웨어사업에는 과업 내용과 범위를 명확히 하고, 과업 확정 방법·시기와 변경 절차 등을 계약서에 정하도록 하는 규정이 있습니다. 이 규정이 민간 SI 계약에 그대로 적용되는 것은 아니지만, 민간 계약에서도 변경 사유, 영향 범위, 추가 비용·일정, 승인 주체와 효력 발생 시점을 서면으로 남기는 구조는 참고할 만합니다.

계약 전 문서는 어떤 순서로 확정하면 되나요?

모든 요구사항을 처음부터 완벽하게 확정하려 하기보다, 사업 목적부터 핵심 흐름·산출물·검수·변경 절차 순으로 정리하세요. 이 순서가 계약서에 넣을 판단 재료를 만들고, 첫 출시 범위를 지키는 기준이 됩니다.

1. 사업 목적을 한 문장으로 적습니다

‘앱 개발’이 아니라 ‘고객이 모바일에서 신청하고 담당자가 접수 현황을 처리한다’처럼 사용 흐름으로 씁니다. 이 문장이 기능 우선순위의 기준입니다.

2. 첫 출시에서 반드시 돌아가야 할 흐름을 고릅니다

기능이 많아질수록 검수 항목도 늘어납니다. 해당 기능이 없으면 첫 출시 목적이 성립하지 않는지를 기준으로, 지금 만들 기능과 다음 단계로 미룰 기능을 나눕니다.

3. 기능마다 완료 문장을 만듭니다

사용자 역할, 시작 조건, 행동, 결과, 예외 상황을 한 항목씩 씁니다. 담당자가 직접 테스트할 수 없는 문장은 다시 구체화해야 합니다.

4. 산출물과 운영 인수 범위를 붙입니다

화면, 디자인 자료, 운영 자료, 접근 권한처럼 프로젝트 성격에 맞는 인도 대상을 정합니다. 누가 인수하고 보관할지도 함께 결정합니다.

5. 검수와 변경의 의사결정자를 정합니다

검수 의견을 여러 사람이 제각각 전달하면 수정 범위가 흔들립니다. 의견 취합 담당자, 최종 승인자, 변경 승인자를 구분해 두는 편이 좋습니다.

이 과정을 거치면 개발사에 견적을 요청할 때도 질문이 달라집니다. “이 기능은 얼마인가요?”보다 “이 시나리오와 산출물 기준을 충족하려면 어떤 전제와 제외 범위가 필요한가요?”를 물을 수 있습니다.

결론

SI 외주 계약에서 먼저 정할 것은 기능의 개수가 아니라, 발주자와 개발사가 함께 확인할 수 있는 완료 기준입니다. 산출물, 검수 시나리오, 보완 범위, 변경 승인 절차를 하나의 흐름으로 연결해 두면 새 요구가 생겨도 무엇을 다시 합의해야 하는지 판단하기 쉬워집니다.

초기 기획이 아직 흔들리는 프로젝트라면 모든 기능을 한 번에 확정하기보다, 첫 출시 범위를 작게 잡고 다음 단계의 결정 시점을 분리할 수 있습니다. 반면 결제, 개인정보, 규제, 외부 시스템 연동처럼 사업상 영향이 큰 항목은 계약 체결 전에 관련 전문가의 검토가 필요할 수 있습니다.

발주 전에는 아래 질문에 답해 보세요.

“이 기능이 완료됐다는 사실을, 누가 어떤 조건에서 확인하고 승인하는가?”에 답할 수 없다면 아직 계약 범위를 더 정리해야 합니다.

자주 묻는 질문

요구사항 문서가 없으면 개발 계약을 못 하나요?

계약은 가능하지만, 최소한의 범위와 검수 기준 없이 시작하는 것은 권하지 않습니다. 긴 기획서가 아니어도 핵심 사용자 흐름, 제외 범위, 산출물, 승인 방식을 정리하면 견적과 일정의 전제가 분명해집니다.

디자인 시안이 없으면 검수 기준을 만들 수 없나요?

만들 수 있습니다. 먼저 사용자 흐름, 필요한 정보, 화면별 기능을 정하고 디자인은 별도 단계에서 확정할 수 있습니다. 다만 디자인 수정 횟수와 확정 시점은 개발 범위와 구분해 합의하는 편이 좋습니다.

검수에서 불편한 점을 발견하면 모두 수정해 주나요?

모든 요청이 자동으로 무상 수정 대상이 되는 것은 아닙니다. 최초 검수 기준을 충족하지 못한 문제인지, 새로운 기능·정책·화면을 요청하는 것인지부터 구분해야 합니다.

대표가 직접 검수해야 하나요?

최종 승인자는 대표일 수 있지만, 실제 업무 흐름의 테스트에는 실사용자가 참여하는 편이 좋습니다. 대표는 사업 목적과 우선순위를 확인하고, 담당자는 입력·조회·처리 같은 일상 업무 흐름을 확인하면 역할이 나뉩니다.

제 도움이 필요하시다면

크로플은 웹·앱·업무 시스템을 수탁 개발하며, 발주 전 단계에서 요구사항을 구현 가능한 범위로 정리하고 개발·검수 기준을 설계하는 일을 함께합니다. 아이디어 단계라면 첫 출시에서 검증할 핵심 흐름을 가르는 것부터, 이미 기획안이 있다면 산출물·제외 범위·검수 시나리오를 점검하는 방식으로 도움을 드릴 수 있습니다.

여러 부서의 요구가 섞여 있거나 관리자 업무와 고객 화면이 함께 있는 프로젝트라면 계약 전 문서 정리에 시간을 쓰는 편이 좋습니다. 현재 가진 기획 자료와 결정이 필요한 지점을 알려 주시면, 개발 전에 무엇부터 정리할지 함께 살펴보겠습니다.