IT 외주 개발 계약서, 개발자가 꼭 확인할 6가지

IT 외주 계약, 개발자에게 왜 위험한가

"일단 시작하고, 계약은 나중에 정리하자." IT 업계에서 유난히 많이 들리는 말입니다. 하지만 구두 합의로 시작한 프로젝트가 분쟁으로 번지는 사례는 매우 흔합니다.

소프트웨어 개발은 업무 범위가 모호해지기 쉽고, 요구사항 변경이 빈번하며, 결과물의 품질 판단이 주관적입니다. 그래서 계약서가 더욱 중요합니다.

1. 요구사항 정의서(SRS)가 계약서에 첨부되어 있는가

IT 프로젝트 분쟁의 대부분은 **"이 기능도 포함 아니었어?"**에서 시작됩니다. 요구사항 정의서가 없으면 클라이언트가 무한정 기능을 추가 요구할 수 있습니다.

확인 포인트:

• 기능 명세서 또는 요구사항 정의서가 계약서 별첨으로 첨부되어 있는가
• "상세 기능은 추후 협의한다"는 표현이 있다면 위험 → 최소한 기능 목록이라도 확정
• 요구사항 변경 시 변경 절차(Change Request)와 비용 산정 기준이 명시되어 있는가

2. 개발 일정과 마일스톤이 현실적인가

"계약일로부터 30일 이내 모든 개발을 완료한다"처럼 비현실적인 일정은 납기 지연 → 위약금 청구의 빌미가 됩니다.

확인 포인트:

• 설계 → 개발 → 테스트 → 배포 단계별 마일스톤이 설정되어 있는가
• 각 마일스톤에 검수 기간이 포함되어 있는가
• 클라이언트 측 의사결정 지연 시 일정 연장 조항이 있는가

3. 소스코드 소유권과 지식재산권이 명확한가

개발 결과물의 소유권 문제는 IT 외주에서 가장 빈번한 분쟁 사안입니다.

일반적으로 합리적인 구조:

• 프로젝트 고유 코드: 대금 완납 시 클라이언트에게 양도
• 개발자 기존 라이브러리/프레임워크: 개발자 소유 유지, 사용 라이선스 부여
• 오픈소스 컴포넌트: 원래 라이선스 조건 따름

위험 조항: "개발 과정에서 생성된 모든 소스코드, 문서, 아이디어의 지식재산권은 갑에게 귀속된다"는 개발자의 기존 자산까지 가져가려는 독소조항입니다.

4. 검수와 하자보수 범위가 합리적인가

"검수는 갑이 만족할 때까지 진행한다"는 사실상 무한 수정을 의미합니다. 검수 기준이 객관적이어야 합니다.

확인 포인트:

• 검수 기준: 요구사항 정의서 대비 기능 충족 여부 (주관적 "만족도"가 아닌 객관적 기준)
• 검수 기간: 보통 14일 이내, 기간 내 이의 없으면 자동 승인
• 하자보수 기간: 검수 완료 후 3~6개월이 일반적
• 하자보수 범위: 기능 결함만 해당, 디자인 변경이나 기능 추가는 별도 계약

5. 대금 지급 조건이 마일스톤과 연동되는가

"프로젝트 완료 후 일시불로 지급한다"는 개발자에게 가장 위험한 구조입니다. 프로젝트가 길어지면 수개월간 무보수로 일하는 상황이 됩니다.

권장 구조:

• 착수금: 계약 금액의 30% (계약 체결 시)
• 중도금: 30~40% (핵심 기능 개발 완료 시)
• 잔금: 30% (최종 검수 완료 시)
• 지연이자: 지급 지연 시 연 15% 이자 발생 (상법 기준)

6. 유지보수와 운영 지원 범위가 구분되어 있는가

개발과 유지보수는 별개의 계약입니다. 하지만 "개발 완료 후 1년간 무상 유지보수를 제공한다"는 조항이 들어가는 경우가 많습니다.

확인 포인트:

• 유지보수 기간과 대응 범위가 명확한가
• 버그 수정과 기능 개선/추가의 구분이 되어 있는가
• 유지보수 종료 후 인수인계 절차가 있는가

IT 계약서, 서명 전에 검토하세요

요구사항 변경, 소스코드 소유권, 무한 검수 — IT 외주 계약의 함정은 다양합니다. BeforeUSign은 판례 데이터와 공정위 표준계약 기준으로 계약서의 위험 조항을 자동 분석합니다.