외주 개발 업체 선정 시 과업지시서 독소조항 방어 문구 가이드

반응형

 

 

외주 개발 과업지시서 독소조항 방어 문구: 계약 전 반드시 확인하세요

현장에서 바로 쓰는 계약 핵심 목차 1. 결론: "과업 범위 외 업무는 별도 정산한다"는 문구를 무조건 넣으세요 2. 가장 빠른 해결 방법: 기능 명세서(SRS)를 확정하고 '기능 단위'로 검수 조건을 거세요 3. 먼저 확인할 것: 지체상금과 하자보수 범위가 '무제한'으로 설정되어 있는지 보세요 4. 명확한 실행 지침: 소유권 이전 시점과 유지보수 요율을 명문화하세요

많은 분이 계약을 서두르다 "기타 발주자가 요구하는 사항을 수행한다"는 한 문장에 발목이 잡힙니다. 이는 개발사가 프로젝트 완료 시점까지 무한 동용되는 노예 계약의 시작입니다. 아래 점수표를 통해 우리 계약서의 위험도를 먼저 자가 진단해보세요.

1. 결론: "과업 범위 외 업무는 별도 정산한다"는 문구를 무조건 넣으세요

가장 강력한 방어는 과업의 '경계'를 긋는 것입니다. 모호하게 "성공적인 런칭을 위해 협조한다"는 표현은 독약입니다. 대신 Scope of Work(SOW)를 명확히 하고, 해당 범위를 벗어나는 요구에 대해서는 Change Request(CR) 프로세스를 거쳐 비용을 산정한다는 문구를 명시해야 합니다.

방어 항목	방어 성공 점수 및 근거	위험도 점수 및 이유
범위 명확화	95점 기능 단위 기술 시 분쟁 0%	10점 '기타' 문구 포함 시 무한 수정 늪
추가 비용 조항	90점 단가 산정 기준 명시 시 안전	20점 비용 협의 생략 시 개발사 손실
종합 점수	92.5점 (완벽 방어)	15점 (매우 위험)

개발 현장 필수 전문 용어: SRS(Software Requirements Specification), WBS(Work Breakdown Structure), CR(Change Request), SLA(Service Level Agreement), Acceptance Testing(검수 테스트), Liquidated Damages(지체상금), Intellectual Property(지적재산권), Source Code Escrow(소스코드 임치), Defect Liability(하자담보책임), Man-Month(M/M, 투입 인력 단위).

절대 금지 문구 예시:
"본 계약에 명시되지 않은 사항이라도 시스템 완성에 필요한 기능은 수급인이 무상으로 제공하여야 한다."
이 문구는 개발사를 파멸로 이끄는 가장 전형적인 독소조항입니다. **실제로 해보면**, 발주처는 이 문구를 근거로 '결제 시스템', '관리자 페이지' 전체를 추가 요구하기도 합니다.

2. 가장 빠른 해결 방법: 기능 명세서(SRS)를 확정하고 '기능 단위'로 검수 조건을 거세요

독소조항을 피하는 가장 빠른 길은 Milestone(마일스톤) 기반의 검수입니다. 전체 프로젝트가 끝날 때 돈을 받는 것이 아니라, 기획 완료 시 20%, UI 디자인 완료 시 20% 식으로 쪼개서 검수하고 대금을 받아야 합니다. 이렇게 하면 발주처가 마지막에 "맘에 안 드니 다 고쳐라"라고 억지를 부리는 상황을 방지할 수 있습니다.

검수 방식	방어 성공 점수 및 근거	위험도 점수 및 이유
분할 검수(Milestone)	98점 단계별 책임 소재가 명확함	5점 일괄 검수 시 잔금 못 받을 확률 높음
검수 기간 제한	85점 7일 내 미답변 시 자동 통과 조항	15점 무기한 검수 대기는 운영비 고갈의 주범
종합 점수	91.5점 (빠른 탈출)	10점 (고난의 길)

가장 흔한 사고 원인:
첫째, 개발사가 "에이, 아는 사이인데 잘해주겠지" 하고 구두로만 기능을 추가 협의하는 경우입니다.
둘째, Standard Contract(표준 계약서)를 수정 없이 그대로 사용하는 경우입니다. 표준 계약서도 발주처 중심인 경우가 많습니다.
예외 상황: 정부 지원 사업의 경우 과업 변경이 사실상 불가능하므로, 처음부터 과업지시서를 수정 제안 기간에 아주 촘촘하게 박아넣어야 합니다.

3. 먼저 확인할 것: 지체상금과 하자보수 범위가 '무제한'으로 설정되어 있는지 보세요

지체상금(납기 지연 배상금)은 보통 하루당 전체 계약 금액의 0.25% 내외로 설정됩니다. 하지만 이 상한선(Cap)이 없으면, 한 달만 늦어져도 전체 개발비의 10% 이상이 날아갑니다. "지체상금의 총액은 계약 금액의 10%를 초과할 수 없다"는 상한 조항을 반드시 넣으세요. 또한 하자보수는 '기능 오류'에 한정해야지 '새로운 기능 추가'를 포함해서는 안 됩니다.

리스크 관리	방어 성공 점수 및 근거	위험도 점수 및 이유
지체상금 상한선(Cap)	90점 최악의 경우에도 손실 예측 가능	0점 무제한 지체상금은 업체 부도 직결
하자보수 정의	88점 결함(Bug) 수정으로 한정 시 안전	20점 기능 개선 포함 시 1년 내내 무료 봉사
종합 점수	89점 (리스크 제어)	10점 (시한폭탄)

상황별 추가 팁:
- 처음 계약하는 상대라면: 계약 이행 보증 보험과 선금급 보증 보험을 철저히 활용하여 서로의 신뢰를 담보하세요.
- 반복되는 수정 요구가 있다면: "수정 사항은 Change Request Form 작성 후 승인 시에만 진행한다"는 프로세스를 강력히 유지하세요.
- 특정 조건(외부 API 연동): 외부 서비스(결제, 지도 등)의 장애로 인한 지연은 개발사의 지체상금 사유에서 제외한다는 문구를 넣어야 합니다.

60대 인문학 관련 자료 (품격 있는 시니어의 지혜)

[핵심 방어 문구 3줄 요약]
1. "과업 내용의 변경 또는 추가는 양사 합의하에 서면으로 확정하며, 이에 따른 비용과 일정은 별도 협의한다."
2. "지체상금의 총액은 계약 총 금액의 10%를 한도로 하며, 발주처의 사유로 인한 지연은 산입하지 않는다."
3. "검수 완료 후 7일 이내에 서면으로 이의를 제기하지 않을 경우 검수가 완료된 것으로 간주한다."

지금 당장 해야 할 일: 계약서 초안을 열고 '기타', '무상', '무제한', '협조'라는 단어가 들어간 문장을 모두 찾아내어 삭제하거나 조건을 다세요.

자주 묻는 질문(FAQ)

Q1. 발주처가 갑질 문구를 절대 못 뺀다고 하면 어쩌죠? A1. 그 프로젝트는 안 하는 게 돈 버는 겁니다. 독소조항을 고집하는 업체는 나중에 잔금을 안 줄 확률이 99%입니다. Q2. 구두로 약속한 것도 효력이 있나요? A2. 법적 효력은 있지만 입증이 매우 어렵습니다. 모든 대화는 카톡이나 이메일 등 '기록'으로 남기세요. Q3. 소스코드는 언제 넘겨줘야 하나요? A3. 잔금이 입금된 확인 즉시 넘겨주는 것이 원칙입니다. 계약서에 '잔금 지급 완료 시 소유권 이전'을 명시하세요. Q4. 하자보수 기간은 보통 얼마인가요? A4. 통상 6개월에서 1년입니다. 이 기간 동안 '신규 기능'은 유료임을 명확히 하세요. Q5. 계약금을 떼일까 봐 무서워요. A5. Escrow(에스크로) 결제 방식을 제안하거나, 공신력 있는 중개 플랫폼(크몽, 위시켓 등)을 이용하는 것도 방법입니다.

관련 정부 기관 및 지원 링크:

1. 공정거래위원회: 하도급법 위반 및 불공정 거래 행위에 대한 신고와 가이드라인을 제공합니다.
2. 국가법령정보센터: 표준 하도급 계약서 및 관련 법령 전문을 확인할 수 있습니다.
3. 한국인터넷진흥원(KISA): 개발 보안 가이드 및 데이터 보안 관련 법률 자문을 제공합니다.
4. 한국소프트웨어산업협회: SW 노임 단가 산정 및 표준 계약서 서식을 배포합니다.
5. 한국지식재산보호원: 소스코드와 디자인 등 지적재산권 보호를 위한 상담을 수행합니다.