앱 개발 계약서의 주요 고려사항 

앱 개발 용역 계약서에서 가장 자주 등장하는 말은 개발 범위다. 어떤 기능을 만들고, 어떤 화면을 구현하며, 어떤 서버와 DB를 사용할 것인지 계약서와 과업지시서에 적는다. 문제는 개발 현장이 그렇게 순탄하게 흘러가지 않는다는 데 있다. 처음에는 A 방식으로 개발하기로 했지만, 실제 구현 단계에서 B 방식이 더 안정적일 수 있다. 계약서에는 특정 DB가 적혀 있었지만, 서비스 확장성이나 비용 문제 때문에 다른 DB를 쓰는 것이 합리적인 경우도 있다. 프레임워크, 클라우드 구조, API 연동 방식, 관리자 페이지 구성도 마찬가지다.

개발은 설계도대로 벽돌만 쌓는 일이 아니다. 중간에 기획이 바뀌고, 발주사의 요구가 추가되고, 기술적으로 더 나은 선택지가 발견된다. 그런데 이 변화가 계약서에 제대로 반영되지 않으면, 나중에는 전혀 다른 이야기가 된다. 발주사는 계약서와 다르니 하자라고 말하고, 개발사는 중간에 다 설명하고 진행했다고 말한다. 분쟁의 출발점은 대개 여기다.

외주 개발사들이 가장 많이 하는 실수

발주사 담당자와 회의에서 이야기했으니 괜찮다고 생각하는 것이다. 카카오톡으로 대략 동의를 받았고, 회의 때 별말이 없었고, 중간 산출물을 공유했으니 승인된 것으로 본다. 실무적으로는 이해되는 말이다. 그러나 소송에서는 위험하다.

계약서에 특정 기술 스펙이 적혀 있는데, 실제 결과물이 다르다면 발주사는 이를 채무불이행이나 하자로 주장할 수 있다. 특히 프로젝트가 지연되거나 사업 자체가 실패한 경우에는 기술 스펙 변경이 공격 포인트가 되기 쉽다. 처음에는 괜찮다고 하던 발주사도 분쟁이 생기면 계약서에 없는 방식으로 개발했다는 말을 꺼낸다.

이때 개발사가 해야 할 방어는 단순히 설명했다는 말이 아니다. 언제, 어떤 이유로, 어떤 대안을 제시했고, 발주사가 어떤 방식으로 승인했는지를 보여주어야 한다. 구두 합의는 기억의 영역이지만, 소송은 기록의 영역이다. 개발사가 설명했다고 느낀 것과, 법원이 설명되었다고 인정하는 것은 전혀 다른 문제다.

기술 스펙 변경 조항은 개발사를 지키는 방패

IT 개발 계약서 작성에서 반드시 들어가야 할 조항 중 하나가 기술 스펙 변경 조항이다. 핵심은 간단하다. 개발 과정에서 성능, 보안, 유지관리, 호환성, 비용 절감, 기술적 안정성을 위해 필요한 경우 당사자 합의로 DB, 프레임워크, 서버 구조, 개발 방식 등 기술 사양을 변경할 수 있다는 내용이다.

이 조항이 없으면 계약서에 적힌 스펙이 고정된 기준처럼 작동한다. 반대로 이 조항이 있으면 기술 변경은 계약 위반이 아니라 계약이 예정한 절차가 된다. 차이가 크다. 같은 변경이라도 조항 하나로 해석이 달라진다. 다만 단순히 변경할 수 있다고만 적어서는 부족하다. 변경 요청 방식, 승인 절차, 이의 제기 기간, 비용·기간 조정 여부, 변경된 스펙의 최종 효력을 함께 정해야 한다. 개발사 입장에서는 발주사가 일정 기간 안에 서면으로 이의를 제기하지 않으면 승인한 것으로 본다는 조항도 중요하다.

발주사가 기술 변경을 명시적으로 승인하지 않았더라도, 일정한 경우 묵시적 승인이 문제 될 수 있다. 변경된 구조를 알고 있었고, 중간 산출물을 확인했으며, 테스트 계정을 받아 검수했고, 별다른 이의를 제기하지 않은 채 계속 개발을 진행하게 했다면 사후에 이를 전면 부정하기는 쉽지 않다.

다만 묵시적 승인은 자동으로 인정되는 마법 주문이 아니다. 개발사가 변경 사실을 발주사에게 알렸다는 자료가 있어야 한다. 회의록, 이메일, 메신저, 이슈 트래커, 배포 노트, 중간 검수 확인서, 테스트 결과표가 필요하다. 특히 기술 변경의 이유가 중요하다. 단순히 개발사가 편해서 바꾼 것이 아니라 성능 개선, 보안 강화, 유지보수 용이성, 비용 절감 등 합리적 이유가 있었다는 점을 남겨야 한다.

발주사가 이의를 제기하지 않았다는 사실도 정리해야 한다. 자료를 받고도 회신하지 않았는지, 테스트를 진행했는지, 변경된 구조를 전제로 추가 요청을 했는지, 이후 대금 일부를 지급했는지가 모두 의미를 가진다. 침묵도 때로는 승인처럼 해석될 수 있다. 다만 그 침묵이 무엇을 향한 침묵인지 기록으로 보여주어야 한다.

하자보수와 추가 개발은 반드시 구별되어야 한다

개발 하자보수 범위를 둘러싼 분쟁도 자주 발생한다. 발주사는 원하는 대로 작동하지 않으면 모두 하자라고 말한다. 그러나 법적으로 하자는 계약에서 정한 기능이나 품질에 미달하는 경우를 의미한다. 처음 계약에 없던 기능을 추가하거나, 사용 편의를 위해 화면을 바꾸거나, 관리자 권한을 새로 나누는 것은 하자보수가 아니라 추가 개발에 가깝다.

이 구별이 되지 않으면 개발사는 끝없는 무상 수정 요구에 묶인다. 계약금은 정해져 있는데 요구사항은 계속 늘어난다. 심지어 개발이 거의 끝난 뒤 사업 방향이 바뀌었다며 전체 구조를 다시 바꾸라고 요구하는 경우도 있다. 이것을 모두 하자보수로 보면 개발사는 사실상 무기한 책임을 지게 된다.

앱 개발 용역 계약서에는 하자보수 범위를 명확히 적어야 한다. 계약서와 과업지시서에 명시된 기능의 오류, 정상 사용을 방해하는 버그, 납품 당시 약정된 성능 미달은 하자보수 대상이 될 수 있다. 그러나 신규 기능, 기획 변경, 디자인 취향 변경, 운영정책 변경, 외부 API 정책 변경, 발주사 내부 사정에 따른 수정은 별도 견적 대상이라고 정리해야 한다.

특히 개발 분쟁에서는 하자와 미완성, 추가 요청이 뒤섞이는 경우가 많다. 발주사가 요구하는 내용이 원래 계약 범위에 포함된 것인지, 아니면 계약 이후 새롭게 추가된 것인지부터 나누어야 한다. 이 구분이 명확하지 않으면 개발사는 이미 완료한 업무에 대해서도 계속 책임을 지는 구조에 놓일 수 있다.

부당한 계약해제는 변경 절차와 기록으로 막을 수 있다

발주사가 계약서와 다르게 개발했다는 이유로 계약해제를 주장하는 경우, 핵심은 그 차이가 계약 목적을 좌우할 정도로 중요한지다. 단순히 기술명이 다르다는 사정만으로 곧바로 계약 목적 달성 불능이 되는 것은 아니다. 실제 기능이 구현되었는지, 성능이 충족되었는지, 발주사가 변경 과정을 알고 있었는지, 변경으로 인해 손해가 발생했는지를 따져야 한다.

개발사 방어의 핵심은 두 가지다. 첫째, 변경은 임의 변경이 아니라 합리적 기술 판단이었다는 점이다. 둘째, 발주사가 변경 사실을 알고도 이의를 제기하지 않았거나, 변경된 결과물을 전제로 검수와 추가 요청을 진행했다는 점이다. 이 두 가지가 정리되면 계약해제 주장의 힘은 약해진다.

특히 발주사가 프로젝트 실패 책임을 개발사에게 전가하기 위해 사후적으로 스펙 차이를 문제 삼는 경우가 있다. 이때 변경 절차와 승인 기록은 가장 중요한 방어 자료가 된다. 개발사가 억울하다고 말하는 것보다, 발주사가 알고도 진행했다는 기록 하나가 더 강하다.

또한 계약서 조항만으로 모든 분쟁이 끝나는 것은 아니다. 개발 과정에서 변경이 생기면 반드시 기록을 남겨야 한다. 변경 사유, 변경 전후 비교, 일정 영향, 비용 영향, 발주사 확인 여부를 남기는 것이 좋다. 회의 후에는 회의록을 보내고, 답변이 없으면 일정 기간 후 해당 내용대로 진행하겠다는 확인 메일을 보내야 한다.

IT 개발 계약은 처음 정한 내용이 끝까지 그대로 유지되기 어렵다. 그래서 좋은 계약서는 변경을 금지하는 계약서가 아니라, 변경이 발생했을 때 어떻게 처리할지를 정한 계약서다. 기술 스펙 변경 조항, 승인 절차, 이의 제기 기간, 묵시적 승인, 추가비용 산정, 일정 연장, 하자보수 범위, 검수 기준은 반드시 함께 설계되어야 한다. 특히 외주 개발사라면 계약서와 과업지시서에 적힌 문장 하나가 나중에 미수금 소송, 손해배상청구, 계약해제 분쟁의 결론을 바꿀 수 있다는 점을 기억해야 한다.