견적서에는 “회원 등급별 마이페이지 구현”이라고 딱 한 줄 적혀 있었습니다. 개발사는 등급 표시 배지만 넣고 끝났다고 했고, 발주사는 등급별 할인·적립·전용 게시판까지 당연히 포함된 줄 알았습니다. 계약서를 다시 펴봐도 판단 기준이 없어 결국 추가 견적서가 날아왔습니다. 이런 다툼은 디자인이나 개발 실력 문제가 아니라 과업지시서(SOW)에 “완료”를 정의하지 않은 문제입니다.
말로 합의한 기능이 분쟁이 되는 구조
미팅에서 “이 정도는 당연히 되는 거죠?”라고 물으면 대부분 “네, 됩니다”라는 답을 듣습니다. 문제는 그 대화가 문서에 남지 않는다는 점입니다. 계약이 끝나고 검수 단계에 들어서면 발주사와 개발사는 서로 다른 기억을 근거로 이야기하게 되고, 이 시점에는 이미 감정이 섞여 협의가 어려워집니다.
SOW(Statement of Work, 과업지시서)는 견적을 뒷받침하는 서류가 아니라 “무엇이 되면 완료로 인정하는가”를 판정하는 기준 문서입니다. 기능명, 화면명이 아니라 입력값·처리 규칙·결과값·예외 상황이 적혀 있어야 실제로 쓸모가 있습니다. 아래에서는 실무에서 바로 쓸 수 있는 작성 항목과 표현 방식을 정리합니다.
기능 명세서에 반드시 들어가야 할 8개 항목
기능 하나당 아래 8개 항목이 채워져 있어야 “완료”를 다툴 여지가 줄어듭니다.
| 항목 | 내용 | 비어있을 때 생기는 문제 |
|---|---|---|
| 기능 목적 | 이 기능이 해결하는 업무·매출 문제 | 불필요한 범위까지 확장 요구 |
| 사용 주체·권한 | 비회원/회원/운영자/대리점 등 권한별 동작 | 권한 누락으로 재작업 |
| 입력값과 검증 규칙 | 필수값, 형식, 글자수, 중복 처리 | 비정상 데이터 유입 시 책임 소재 불명 |
| 정상 처리 결과 | 저장·알림·화면 반영 방식 | “됐는데 이게 아니다” 분쟁 |
| 예외·오류 처리 | 실패 시 안내, 재시도, 로그 | 운영 중 장애 대응 불가 |
| 연동 범위 | 결제·문자·ERP·CRM 등 외부 연동 유무 | 연동 비용을 “당연히 포함”으로 오해 |
| 성능·용량 기준 | 동시접속, 데이터 건수, 응답시간 | 오픈 후 느려짐 책임 다툼 |
| 완료 증빙 | 테스트 케이스, 캡처, 담당자 승인 방식 | 구두 확인만 남아 추후 재검수 불가 |
이 8개를 표로 만들어 기능 단위로 나열하면, 계약서 본문보다 이 표가 실제 분쟁 상황에서 훨씬 강한 근거가 됩니다.
모호한 표현을 계약 언어로 바꾸는 법
SOW에서 가장 흔한 사고는 “~하기 편하게”, “~를 지원” 같은 서술형 표현입니다. 이런 문장은 개발사·발주사 모두 다르게 해석할 수 있습니다.
| 모호한 표현 | 계약 언어로 수정 |
|---|---|
| 관리자가 편하게 상품을 등록 | 상품명·가격·옵션·이미지 5장을 1회 등록 화면에서 저장, 저장 후 목록 반영까지 3초 이내 |
| SEO 최적화 포함 | 페이지별 title·description·canonical 자동 생성, sitemap.xml 자동 갱신, 게시글 등록 시 메타 자동 반영 |
| 모바일 대응 | 360px~768px 구간 레이아웃 재배치, 터치 영역 44px 이상 확보 |
| 회원 등급 관리 | 등급 3단계(일반/실버/골드), 등급별 할인율 필드, 등급 변경 시 변경 이력 저장 |
| 알림 기능 | 주문 완료 시 관리자 알림톡 1건 발송, 발송 실패 시 로그 기록 |
표현을 숫자와 조건으로 바꾸면 검수 회의에서 “이게 되는 거 맞나요?”라는 질문 자체가 사라집니다.
화면 캡처가 증거가 되지 못하는 이유
발주사는 흔히 “시안 화면에 있던 버튼이니 당연히 동작하는 것”이라고 생각합니다. 그러나 화면(UI)은 겉모습일 뿐, 뒤에서 데이터를 어떻게 처리하는지는 알려주지 않습니다. 예를 들어 “즐겨찾기” 버튼이 화면에 있어도 다음 중 무엇인지 명시하지 않으면 각자 다른 것을 상상합니다.
- 클릭 시 로그인 여부만 확인하고 저장은 하지 않는 단순 UI
- 비회원은 임시저장(쿠키), 회원은 DB 저장으로 분기
- 즐겨찾기 목록을 마이페이지에서 조회·삭제 가능
- 즐겨찾기 상품 재입고 시 알림 발송까지 포함
SOW는 화면 단위가 아니라 기능 단위로 작성해야 합니다. 화면은 “이런 모습이 될 예정입니다”라는 참고 자료이고, 기능표가 “실제로 무엇이 저장·처리되는가”를 정의하는 본문입니다.
승인·검수 절차와 완료 정의(Definition of Done)
완료 정의가 없으면 검수는 끝없이 이어집니다. 실무에서는 아래 순서로 검수 절차를 SOW에 명시하는 것이 안전합니다.
- 기능별 테스트 케이스 사전 배포 — 개발 착수 전, 각 기능의 정상/예외 케이스를 발주사와 합의
- 1차 내부 검수(개발사) — 테스트 케이스 기준으로 자체 확인 후 결과 캡처 전달
- 2차 발주사 검수 — 합의된 기간(예: 5영업일) 내 케이스별 통과/보류 표기
- 보류 항목 재작업 — 신규 요구는 변경관리로 분리, 기존 합의 범위는 재작업
- 최종 승인 — 담당자 서명 또는 이메일 확인으로 완료 처리
여기서 중요한 것은 “보류”와 “신규 요구”를 섞지 않는 것입니다. 검수 기간을 명시하지 않으면 개발사는 몇 달째 대기하게 되고, 발주사는 계속 다른 의견을 추가하게 됩니다.
변경관리(체인지오더) 조항이 없으면 생기는 일
프로젝트 중 “이것도 추가해주세요”는 반드시 나옵니다. 문제는 이것이 무상 수정인지, 유상 추가인지 판단 기준이 없다는 점입니다. SOW에는 아래 조항을 넣어두는 것이 좋습니다.
- 최초 합의된 기능 명세서에 없는 항목은 변경요청서(Change Request)로 별도 문서화
- 변경요청서에는 범위·일정 영향·추가 비용을 함께 기재
- 발주사 서명(또는 이메일 확인) 후 착수, 구두 지시만으로는 진행하지 않음
- 사소한 문구·색상 수정은 무상, 로직·화면 흐름 변경은 유상으로 기준선 구분
이 조항이 있으면 “서비스 차원에서 해드릴게요”가 반복되며 프로젝트가 무한정 늘어나는 상황을 막을 수 있습니다. 견적 상담 시에도 무료 견적요청을 통해 초기 범위를 먼저 명확히 하는 것을 권장합니다.
실제 SOW 문서 목차 예시
중소 규모 홈페이지·쇼핑몰 구축 기준으로 아래 목차를 그대로 써도 충분합니다.
- 프로젝트 개요 및 목적
- 전체 사이트맵(IA)
- 페이지별 화면 요구사항(참고용)
- 기능 명세표(기능별 8개 항목 포함)
- 외부 연동 목록(결제, 문자, 지도, ERP 등)
- 비기능 요구사항(성능, 보안, 접근성)
- 일정 및 마일스톤
- 검수·승인 절차
- 변경관리 절차
- 유지보수 범위 및 비용 기준
이 중 4번 기능 명세표가 전체 문서에서 가장 중요합니다. 나머지는 이 표를 뒷받침하는 맥락 정보에 가깝습니다.
계약 체결 전 마지막으로 확인할 5가지
계약서에 도장을 찍기 전, 아래 5가지가 문서에 명시돼 있는지 확인하세요.
- 기능별로 “완료”를 판정할 기준이 숫자·조건으로 적혀 있는가
- 검수 기간과 보류 시 재작업 범위가 정해져 있는가
- 변경요청서 양식과 승인 절차가 있는가
- 소스코드·DB·디자인 원본의 소유권 귀속이 명시돼 있는가
- 오픈 이후 유지보수 범위와 SOW의 경계가 구분되어 있는가
이 5가지 중 하나라도 비어 있다면 계약서 서명 전에 반드시 보완하세요. 소유권 관련 항목은 소스·디자인 원본 소유권 확보 방안을 함께 참고하시면 좋습니다.
자주 묻는 질문 (FAQ)
SOW와 견적서는 어떻게 다른가요? +
견적서는 가격을 산정하기 위한 요약 문서이고, SOW는 그 가격이 어떤 작업 범위를 근거로 하는지 상세히 정의하는 문서입니다. 견적서만 있고 SOW가 없으면 “포함된 것”의 기준이 서로 달라 분쟁이 생기기 쉽습니다.
기능 명세서는 몇 개 항목 정도가 적당한가요? +
중소 규모 홈페이지는 보통 15~30개 기능 단위, 쇼핑몰이나 예약 시스템은 30~60개 정도가 실무적입니다. 항목 수보다 중요한 것은 각 항목에 입력·처리·예외·완료 기준이 빠짐없이 적혀 있는지입니다.
이미 계약을 체결했는데 SOW가 부실하면 어떻게 해야 하나요? +
지금이라도 개발 착수 전 단계라면 부속합의서 형태로 기능 명세표를 추가하는 것이 가능합니다. 이미 개발이 진행 중이라면 남은 기능부터 명세표를 작성해 이후 검수 기준으로 삼는 것이 현실적인 대안입니다.
개발사가 SOW 작성을 꺼려하면 어떻게 해야 하나요? +
경험 있는 개발사는 오히려 SOW 작성을 반깁니다. 명확한 범위가 곧 개발사 스스로의 책임 범위를 지켜주기 때문입니다. 반대로 SOW 작성을 계속 미루거나 형식적으로만 접근한다면 이후 검수 단계에서 분쟁 가능성이 높다는 신호로 볼 수 있습니다.
SOW 작성은 발주사와 개발사 중 누가 주도해야 하나요? +
초안은 실무를 잘 아는 개발사가 작성하고, 발주사는 업무 규칙(가격 정책, 승인 흐름, 예외 상황)을 채워주는 방식이 효율적입니다. 다만 최종 확정과 서명은 반드시 발주사 실무 담당자가 항목별로 직접 검토해야 나중에 “몰랐다”는 상황을 피할 수 있습니다.