외주 개발 프로젝트에서 기술적 역량만큼 중요한 것이 바로 계약서입니다. 계약서의 한 줄이 수천만 원의 차이를 만들 수 있고, 프로젝트가 끝난 뒤에야 문제를 발견하면 이미 늦습니다. 업계에서는 외주 분쟁의 상당수가 계약서 미비에서 비롯된다고 봅니다.

계약서는 법률 문서이기 이전에 프로젝트의 안전장치이자 양측 간의 기대치를 명문화하는 가장 중요한 합의서입니다. 반드시 확인해야 할 5가지 핵심 조항을 정리합니다.

1. 소스코드 및 지적재산권 귀속

가장 중요한 조항입니다. "본 프로젝트의 산출물에 대한 지적재산권은 갑(발주사)에게 귀속된다"는 문구가 반드시 명시되어야 합니다. 이 조항이 없으면 소스코드는 개발사 소유입니다. 많은 클라이언트가 "내 돈으로 만들었으니 당연히 내 것"이라고 생각하지만, 계약서에 명시되어 있지 않으면 법적으로 개발사의 것입니다. 이건 큰 오해입니다.

일부 개발사는 이걸 일부러 이용합니다. 계약서에 소유권 조항을 의도적으로 넣지 않고 저렴하게 계약합니다. IT 외주 경험이 많이 없는 분은 이게 얼마나 큰 문제인지 인지하지 못합니다. 그리고 프로젝트 완료 후 소스코드 요청이 오면 안 줍니다. 이미 서비스가 운영 중이기 때문에 클라이언트는 그 개발사에 락인(종속)된 상태입니다. 수정이 필요할 때마다 개발사에 허락을 받아야 하고, 큰 비용을 지불해야 합니다. 다른 개발사로 이전하려 해도 소스코드가 없으니 처음부터 다시 만들어야 합니다. 사실상 비즈니스가 개발사에 인질로 잡히는 구조입니다.

특히 프론트엔드 소스, 백엔드 API 코드, 데이터베이스 설계서, API 문서, 배포 스크립트, 인프라 설정 파일 등 산출물의 범위를 구체적으로 나열하는 것이 좋습니다. 제3자 라이브러리나 오픈소스 사용 부분은 별도로 명시해야 분쟁을 예방할 수 있습니다.

개발사가 자체적으로 보유한 프레임워크나 공통 모듈을 사용하는 경우, 해당 부분의 라이선스 조건과 사용 범위도 반드시 확인하세요.

2. 요구사항 변경 절차와 추가 비용 기준

프로젝트 진행 중 요구사항 변경은 필연적으로 발생합니다. 문제는 변경이 발생했을 때 어떻게 처리하느냐입니다. 계약서에 변경 요청 절차, 추가 비용 산정 기준, 일정 조정 방식이 명확해야 합니다. 다만 현실적으로 계약서에 "추가 공수의 1.2배" 같은 구체적 비율을 넣기는 어렵습니다. 소프트웨어는 기성품이 아니기 때문에, 개발사가 생각하는 1.0배의 작업이 고객 입장에서는 체감상 3~4배처럼 느껴질 수 있습니다. 숫자를 미리 정해놓으면 오히려 분쟁의 원인이 됩니다.

추가 공수가 발생하면 별도 계약을 다시 하거나 특약으로 처리하고, 양측이 원만하게 합의하는 방향으로 진행하는 것이 현실적입니다.

프로덕트 메이커의 경우, 모든 수정 요청이 추가 비용은 아닙니다. 스프린트 기간 내에 발생하는 피드백과 수정은 대부분 수용됩니다. 문제는 프로젝트의 방향 자체가 바뀌는 경우입니다. 예를 들어 자전거를 만드는 프로젝트가 자동차를 만드는 프로젝트로 바뀌는 상황이라면 불가피하게 추가 견적을 요청드립니다. 수정 범위가 스프린트 내에서 해결 가능한 수준이 아니라 프로젝트 전체에 영향을 주는 경우도 마찬가지입니다.

저희의 경우 여태까지 추가 견적이 발생한 경우는 거의 없었습니다. 화이트박스 방식으로 2주마다 동작하는 결과물을 공유하고 피드백을 받기 때문에, 방향이 크게 틀어지기 전에 잡을 수 있기 때문입니다. 만약 추가 견적이 발생하더라도 프로젝트 기간 내에서는 기존 견적과 동일한 기준으로 산정합니다. 프로젝트 견적은 연속적으로 시간이 투입되는 구조라 일반 유지보수 견적보다 할인이 반영된 단가이기 때문입니다.

3. 하자보수 기간과 범위

프로젝트 완료 후 버그가 발견되면 누가 수정하는가? 업계 표준은 납품 후 3~6개월간 무상 하자보수입니다. 여기서 핵심은 하자의 범위를 정의하는 것입니다. 개발사의 코드 오류로 인한 버그는 무상 수정이 당연하지만, 발주사가 요구사항에 명시하지 않은 기능의 부재는 하자가 아닙니다.

"합의된 요구사항 명세서 기준으로 동작하지 않는 기능에 대해 납품일로부터 6개월간 무상 수정한다"처럼 구체적으로 작성해야 합니다. 하자보수 기간 중 응답 시간(예: 긴급 버그 24시간 이내 대응, 일반 버그 72시간 이내 대응)도 명시하면 더 안전합니다.

하자보수 기간이 끝난 후의 유지보수 조건도 미리 논의해 두면 장기적인 서비스 운영에 도움이 됩니다.

4. 중도 해지 조건

프로젝트가 중간에 취소되면 이미 완료된 작업물은 어떻게 되는가? 소스코드는 누구 소유인가? 기지급 금액은 반환하는가? 이 질문에 계약서가 답할 수 있어야 합니다. 일반적으로 완료된 작업 비율에 따라 정산하고, 완성된 산출물은 대금 지급 비율에 따라 귀속을 결정합니다.

중도 해지 조항이 없으면 양측 모두 법적 분쟁에 휘말릴 수 있습니다. 해지 사유(연락 두절 30일 이상, 합의된 일정 대비 60일 이상 지연 등)와 해지 통보 기간(보통 30일 전 서면 통보)도 구체적으로 정해 두어야 합니다.

5. 비밀유지 의무(NDA)

개발 과정에서 개발사는 발주사의 사업 모델, 고객 데이터, 내부 프로세스, 기술 스택, 매출 정보 등 민감한 정보를 접하게 됩니다. 비밀유지 조항은 이러한 정보의 유출을 방지합니다. 비밀 정보의 범위, 유지 기간(통상 계약 종료 후 2~3년), 위반 시 손해배상 책임을 명시해야 합니다.

경쟁사 프로젝트 수행 제한 조항을 넣는 경우도 있지만, 현실적으로는 조심해야 합니다. IT 외주 프로젝트의 단가가 그렇게 높지 않은 경우가 많고, 업종 간 카테고리가 상당 부분 겹치기 때문입니다. 예를 들어 이커머스 프로젝트를 했다고 해서 모든 이커머스 프로젝트를 못 한다면 개발사 입장에서는 사업 자체가 불가능해집니다. 대부분의 프로젝트가 회원, 결제, 관리자 같은 공통 기능을 포함하고 있고, 이런 공통 영역까지 경쟁 제한을 걸면 범위가 비현실적으로 넓어집니다. 정말 핵심적인 비즈니스 로직(예: 독자적인 알고리즘이나 영업 비밀)에 대해서만 구체적이고 좁은 범위로 제한하는 것이 양측 모두에게 합리적입니다.

프로덕트 메이커는 이 5가지 조항을 기본 계약서에 모두 포함하고 있습니다. 계약 전 모든 조항을 고객에게 투명하게 설명드리며, 고객이 불리한 조건에 놓이지 않도록 합니다. 궁금한 조항이 있으면 수정 요청도 환영합니다. 좋은 계약서는 분쟁을 예방하는 최선의 수단이며, 양측 모두를 보호하는 신뢰의 기반입니다.