개발 외주 계약 전 확인할 것들

계약서가 지켜 주는 것

계약서를 ‘문제가 생겼을 때 상대를 압박하는 문서’로 생각하면 오해가 생깁니다. 실제로 계약서가 하는 일의 90퍼센트는 소송이 아니라 예방입니다. 계약서를 쓰는 과정에서 양쪽은 어쩔 수 없이 구체적인 질문에 답해야 합니다. 언제까지 무엇을 만들 것인가, 어떤 상태가 되면 완료인가, 중간에 요구사항이 바뀌면 비용은 어떻게 되는가. 이 질문들에 계약 단계에서 답을 맞춰 두면, 프로젝트 중반에 같은 질문으로 다투는 일이 크게 줄어듭니다.

반대로 계약서가 짧을수록 프로젝트는 위험해집니다. ‘쇼핑몰 웹사이트 개발’ 한 줄과 금액, 기간만 적힌 계약서는 아무것도 정하지 않은 것과 같습니다. 발주자는 상품 옵션과 쿠폰과 리뷰까지 당연히 포함이라고 생각하고, 개발사는 기본 장바구니와 결제까지라고 생각합니다. 둘 다 자기 해석이 상식적이라고 믿기 때문에 이 상황은 감정 싸움으로 번지기 쉽습니다.

그래서 계약서를 잘 쓰는 방법은 법률 용어를 많이 아는 것이 아니라, 만들 것을 구체적으로 적어 두는 것입니다. 이 준비가 잘 되어 있을수록 계약 협의도 빨라집니다. 기능 목록과 화면 구성을 정리하는 방법은 아이디어를 요구사항으로 정리하는 가이드에서 따로 다뤘습니다.

산출물 범위를 명확히

개발이 끝나면 무엇을 받게 되는지를 목록으로 적어야 합니다. 많은 발주자가 ‘완성된 서비스’를 받으면 끝이라고 생각하지만, 실제로 이후에 필요한 것은 서비스 그 자체가 아니라 그것을 계속 운영하고 수정할 수 있게 해 주는 부속물들입니다. 아래 항목들은 계약서 산출물 조항에 이름을 붙여 명시하는 편이 좋습니다.

디자인 원본은 특히 놓치기 쉬운 항목입니다. 화면은 다 나왔는데 원본 파일이 없으면, 나중에 이벤트 배너 하나를 바꾸는 데도 처음 만든 개발사를 다시 찾아야 합니다. 문서화 역시 ‘문서를 제공한다’는 문구만으로는 부족하고, 어떤 문서를 어느 수준으로 제공할지 예시를 정해 두는 편이 안전합니다.

소스코드 소유권과 저작권

외주 개발에서 가장 분쟁이 잦은 항목입니다. 많은 발주자가 ‘돈을 냈으니 당연히 내 것’이라고 생각하지만, 저작권은 원칙적으로 창작자에게 발생합니다. 별도의 약정이 없으면 개발사가 저작권을 보유한 상태로 발주자에게 사용을 허락한 형태가 될 수 있습니다. 이 차이는 평소에는 드러나지 않다가, 다른 개발사로 옮기거나 서비스를 매각하거나 투자 실사를 받을 때 갑자기 문제가 됩니다.

개발사가 기존 자산을 쓰는 경우

개발사가 여러 프로젝트에서 재사용하는 자체 프레임워크나 공통 모듈을 가진 경우가 많습니다. 이때 전체 소스코드의 저작권을 통째로 양도하기 어렵다는 답을 들을 수 있는데, 그 자체가 부당한 요구는 아닙니다. 현실적인 절충은 프로젝트를 위해 새로 작성한 부분은 발주자에게 양도하고, 개발사의 기존 자산은 영구적이고 비독점적인 사용권을 부여하는 방식입니다. 중요한 것은 이 구분이 계약서에 적혀 있는지, 그리고 그 사용권이 계약 종료 후에도 유지되는지입니다.

오픈소스와 외부 라이선스

요즘 개발에서 오픈소스를 전혀 쓰지 않는 경우는 거의 없습니다. 문제는 라이선스 조건입니다. 일부 라이선스는 이를 사용한 소프트웨어의 소스코드도 공개하도록 요구합니다. 상용 서비스에서 이런 조건이 붙은 구성 요소가 섞이면 나중에 대응이 번거로워지므로, 계약서에 사용된 오픈소스 목록과 라이선스를 산출물과 함께 제출하도록 하고, 상용 이용에 제약이 있는 라이선스는 사전 협의 없이 사용하지 않는다는 조항을 두는 편이 좋습니다. 유료 플러그인이나 폰트, 이미지 소스를 쓴 경우 그 라이선스 명의가 누구인지도 확인 대상입니다.

검수 기준과 절차

‘완료’의 정의가 없으면 프로젝트는 끝나지 않습니다. 발주자는 계속 수정을 요청하고 개발사는 이미 끝났다고 말하는 상황이 여기서 생깁니다. 검수는 감상이 아니라 미리 정한 기준과의 대조 작업이어야 합니다.

• 검수 기준 문서 — 요구사항 정의서나 기능 목록을 검수의 기준으로 삼는다고 계약서에 명시합니다. 기준이 되는 문서의 이름과 버전까지 적어 두면 더 좋습니다.
• 검수 기간 — 납품 후 검수 의견을 회신할 기간을 정합니다. 통상 7일에서 14일 정도가 많고, 규모가 크면 더 길게 잡습니다.
• 기간 경과의 효과 — 정해진 기간 안에 의견이 없으면 검수에 합격한 것으로 본다는 조항이 일반적입니다. 발주자 입장에서는 이 기간을 흘려보내지 않도록 담당자를 지정해야 합니다.
• 재검수 절차 — 불합격 시 개발사가 며칠 안에 수정하고 다시 검수를 받는지, 이 과정을 몇 회까지 반복하는지 정합니다.
• 테스트 환경 — 어떤 기기와 브라우저에서 확인할지 범위를 정합니다. 범위가 없으면 오래된 특정 기기 하나 때문에 검수가 무한정 지연될 수 있습니다.

검수 의견은 구두나 전화 대신 문서나 이슈 트래커 같은 기록이 남는 형태로 주고받는 것이 양쪽 모두에게 유리합니다. 나중에 ‘그때 말씀드렸는데’라는 대화가 오가는 것을 막아 줍니다.

대금 지급 구조

전액 선불도, 전액 후불도 한쪽에 위험이 몰립니다. 그래서 대부분의 개발 계약은 분할 지급을 씁니다. 분할 비율에 절대적인 정답은 없고 프로젝트 규모와 기간, 양측의 신뢰 수준에 따라 달라집니다. 아래는 실무에서 자주 보이는 형태입니다.

기간이 6개월 이상으로 길면 2회가 아니라 3~4회로 나누어 진행률에 맞춰 지급하기도 합니다. 비율보다 중요한 것은 각 지급의 조건이 무엇인지가 분명한가입니다. ‘중간에 지급’ 같은 표현보다는 ‘디자인 시안 확정 승인 후 5영업일 이내’처럼 누가 봐도 판정 가능한 사건으로 적어야 합니다. 부가세 별도 여부, 세금계산서 발행 시점, 지연 시 이자나 지연손해금도 함께 정해 두면 정산 단계에서 실랑이가 줄어듭니다.

착수금 비율이 지나치게 높은 계약은 발주자에게 불리하고, 반대로 착수금이 거의 없는 계약은 개발사가 초기 인력을 투입하기 어렵게 만듭니다. 어느 쪽도 좋은 신호는 아니므로, 비율이 통상 범위에서 크게 벗어난다면 그 이유를 설명해 달라고 요청해 보는 것이 좋습니다.

하자보수 기간

하자보수는 납품한 결과물이 약속한 대로 동작하지 않을 때 개발사가 무상으로 고쳐 주는 의무입니다. 기간은 통상 검수 완료일로부터 3개월에서 12개월 사이로 정하며, 3개월이나 6개월이 가장 흔합니다. 기간 자체보다 중요한 것은 무엇이 하자에 해당하는지의 구분입니다. 이 구분이 없으면 발주자는 모든 요청을 하자라고 부르고, 개발사는 모든 요청을 추가 개발이라고 부르게 됩니다.

마지막 줄의 ‘협의 필요’ 영역이 실무에서 가장 자주 문제가 됩니다. 개발사가 잘못한 것은 없지만 서비스는 실제로 동작하지 않는 상황이기 때문입니다. 결제 대행사가 연동 방식을 바꾸거나, 모바일 OS가 올라가면서 기존 방식이 막히는 경우가 여기에 해당합니다. 이런 외부 요인에 의한 수정을 하자보수에 포함할지, 유지보수 계약으로 처리할지를 계약 단계에서 정해 두면 나중에 서로 억울해질 일이 줄어듭니다.

유지보수는 별도 계약

하자보수와 유지보수는 다릅니다. 하자보수는 약속한 것이 약속대로 되지 않았을 때의 무상 수정이고, 유지보수는 서비스를 계속 살아 있게 하는 지속적인 작업입니다. 서버 관리, 라이브러리 업데이트, 장애 대응, 백업, 앱 스토어 정책 대응, 소규모 개선까지 포함되며 별도의 유료 계약으로 진행하는 것이 일반적입니다.

개발 계약을 체결할 때 유지보수 조건도 함께 논의해 두는 편이 낫습니다. 개발이 끝난 뒤에 협상하면 선택지가 사실상 하나뿐이라 조건이 불리해질 수 있기 때문입니다. 월 정액인지 시간 단위 정산인지, 정액이라면 월 몇 시간까지 포함되는지, 장애 발생 시 연락 가능한 시간대와 대응 시작까지의 목표 시간은 얼마인지를 확인하면 좋습니다. 운영 단계에서 실제로 무슨 일이 벌어지는지는 출시 이후의 운영과 유지보수 가이드에 정리했습니다.

계정과 인프라 명의

기술적으로는 사소해 보이지만 실제 피해가 가장 큰 항목입니다. 도메인이 개발사 명의로 등록되어 있고 그 개발사와 연락이 끊기면, 서비스 주소를 잃을 수 있습니다. 앱 스토어 계정이 개발사 소유이면 앱의 통제권이 그쪽에 있습니다. 결제 대행 계약이 개발사 명의라면 정산 흐름 자체가 남의 계정을 거칩니다.

특히 애플과 구글의 스토어 계정은 개발자 등록 명의를 나중에 바꾸는 과정이 번거롭고, 사업자 정보 심사가 다시 필요할 수 있습니다. 처음부터 발주자 명의로 등록하고 개발사를 팀 멤버로 초대하는 방식이 훨씬 간단합니다. 인계 시점에 계정 목록과 접속 정보를 문서로 정리해 전달받고, 인계 후에는 비밀번호를 변경하고 더 이상 필요하지 않은 접근 권한을 회수하는 것까지가 마무리입니다.

요구사항 변경 처리 방식

프로젝트 중간에 요구사항이 바뀌지 않는 경우는 거의 없습니다. 시장 상황이 바뀌기도 하고, 화면을 직접 보고 나서야 더 나은 방법이 떠오르기도 합니다. 변경 자체는 자연스러운 일이므로, 계약서가 할 일은 변경을 금지하는 것이 아니라 변경을 처리하는 절차를 만들어 두는 것입니다.

• 변경 요청은 문서로 — 구두 요청이 그대로 개발에 반영되면 나중에 누구도 경위를 재구성할 수 없습니다. 간단한 양식이나 이슈 등록으로 통일합니다.
• 영향 산정 후 결정 — 개발사가 추가 공수와 일정 변동을 먼저 산정해 회신하고, 발주자가 그 내용을 보고 진행 여부를 결정하는 순서로 진행합니다.
• 경미한 변경의 기준 — 문구 수정이나 색상 조정처럼 작은 변경까지 매번 절차를 밟으면 프로젝트가 느려집니다. 일정 시간 이하는 별도 정산 없이 처리한다는 식의 기준을 두면 실무가 편해집니다.
• 일정 연장의 처리 — 변경으로 일정이 밀렸을 때 지연배상 조항이 적용되지 않도록, 승인된 변경만큼 납기가 자동 조정된다는 내용을 넣어 둡니다.
• 변경 이력 관리 — 승인된 변경 요청은 원래 요구사항 문서에 반영해 최신 상태를 유지합니다. 그래야 검수 기준이 흔들리지 않습니다.

계약 전 체크리스트

아래 항목에 대해 계약서를 읽으면서 답을 찾을 수 있다면 대체로 안전한 계약입니다. 답이 나오지 않는 항목이 있다면 그 부분이 나중에 문제가 될 지점입니다.

• 범위 — 만들 기능과 화면이 목록으로 첨부되어 있는가. 포함되지 않는 것도 적혀 있는가.
• 산출물 — 소스코드, 디자인 원본, 문서, 계정 중 무엇을 언제 받는지 적혀 있는가.
• 저작권 — 저작재산권 양도 여부와 시점이 명시되어 있는가. 개발사 기존 자산의 사용권 범위는 정해졌는가.
• 검수 — 검수 기준 문서, 검수 기간, 무응답 시 처리, 재검수 절차가 있는가.
• 대금 — 분할 비율과 각 지급의 조건, 부가세 별도 여부, 세금계산서 시점이 있는가.
• 하자보수 — 기간이 있는가. 하자와 추가 개발의 구분 기준이 있는가.
• 유지보수 — 별도 계약임이 명확한가. 예상 조건을 미리 확인했는가.
• 계정 — 도메인, 서버, 스토어, 외부 서비스 명의가 발주자로 되어 있는가.
• 변경 — 요구사항 변경의 요청·산정·승인 절차가 있는가. 일정 조정 규정이 있는가.
• 비밀유지 — 양방향으로 적용되는가. 기간과 예외 사유가 있는가.
• 중도 해지 — 어떤 사유로 해지할 수 있고, 그때까지의 작업물과 기지급금은 어떻게 정산하는가.
• 분쟁 해결 — 관할 법원이나 조정 절차가 정해져 있는가.
• 책임 한도 — 손해배상 범위에 상한이 있는가. 그 상한이 계약 금액 대비 합리적인가.

마지막으로, 계약서를 꼼꼼히 쓰는 것과 상대를 의심하는 것은 다릅니다. 오히려 계약 논의에서 이런 항목들을 먼저 정리해 오는 개발사라면 프로젝트 경험이 있다는 신호로 볼 수 있습니다. 반대로 ‘그건 나중에 알아서 해 드리겠다’는 답만 반복된다면, 그 ‘나중’에 어떤 대화가 오갈지 미리 생각해 보는 편이 좋습니다.

※ 이 글은 개발 외주 실무에서 자주 문제가 되는 항목을 정리한 참고 자료이며 법률 자문이 아닙니다. 비율과 기간은 일반적으로 통용되는 범위를 소개한 것으로 프로젝트 규모와 상황에 따라 달라집니다. 금액이 크거나 기간이 긴 계약, 지식재산권이 핵심인 계약은 체결 전 변호사 등 전문가의 검토를 받으시길 권합니다.