외주 개발 계약 분쟁은 계약서에 있는 문장이 아니라 없는 문장에서 시작됩니다

계약서를 놓고 다투는 상황을 몇 번 겪고 나면 패턴이 보입니다. 문제가 되는 건 어렵게 쓰인 조항이 아닙니다. 아무도 쓰지 않은 한 줄입니다. 양쪽 다 당연하다고 생각해서 굳이 적지 않았던 것들이, 나중에 서로 정반대로 당연했다는 게 드러납니다.

아래는 저희가 계약서 문장을 하나씩 고쳐 온 계기가 된 유형들입니다. 특정 프로젝트를 지목하지 않고 유형으로만 씁니다. 계약서에 무엇을 더 써야 하는지는 [소프트웨어 개발 계약서 양식 가이드](/guide/software-development-contract-template)에 조항별로 정리해뒀습니다.

납품하고 몇 주 뒤에 연락이 옵니다. "무상 하자보수 기간이니까 이것도 해주셔야죠." 열어보면 처음에 없던 기능입니다. 발주자 쪽에서 악의가 있어서가 아닙니다. 쓰다 보니 필요해졌고, 아직 보수 기간이니 당연히 되는 줄 안 겁니다.

하자는 합의된 요구사항대로 동작하지 않는 것입니다. 그런데 이 문장을 계약서에 아무리 잘 써도, "합의된 요구사항"이 문서로 없으면 아무 힘이 없습니다. 결국 기억 대 기억의 싸움이 되고, 그러면 대체로 더 아쉬운 쪽이 집니다.

지금은 견적 단계에서 나온 기능 목록을 그대로 계약 별첨으로 붙입니다. 화려한 명세서가 아니라 화면별로 한 줄씩 적은 목록입니다. 그것만 있어도 "이건 목록에 있고, 저건 없다"로 대화가 끝납니다. 무엇을 어떻게 적을지는 [검수 체크리스트](/guide/acceptance-test-checklist)가 그대로 쓸 만합니다.

개발이 멈추는 가장 흔한 이유는 개발사가 손을 놓아서가 아니라, 물어본 것에 답이 안 와서입니다. 관리자 계정을 달라고 했는데 담당자가 휴가 중이거나, 정산 규칙을 확인해 달라고 했는데 내부 결재가 안 나거나 하는 식입니다. 그렇게 2주가 흐르고, 달력을 보면 그 2주는 개발 지연으로 기록되어 있습니다.

이건 발주자를 탓하는 얘기가 아닙니다. 기준이 없어서 생기는 일입니다. 지금 저희 계약서에는 확인 요청에 3영업일 안에 회신해 달라는 조항과, 회신이 없으면 저희가 제시한 안대로 진행하는 데 동의한 것으로 본다는 조항이 있습니다. 처음엔 발주자에게 불리해 보인다고 생각했는데, 실제로는 반대였습니다. 언제까지 무엇을 줘야 하는지가 적혀 있으니 발주자 쪽 내부에서도 일이 돌아갑니다.

납기 조항에 "발주자의 자료 미제공, 회신 지연, 요구사항 변경으로 인한 지연은 납기에서 제외한다"는 한 줄을 넣는 것으로 이 문제의 절반이 정리됩니다.

저작권 이전 시점이 계약서에 없으면 마지막에 이 대치가 나옵니다. 발주자는 물건을 받아야 돈을 준다고 하고, 개발사는 돈을 받아야 물건을 준다고 합니다. 둘 다 틀린 말이 아니라서 더 풀기 어렵습니다.

저희 계약서는 계약금액 전액 완납 시점에 저작재산권이 이전된다고 씁니다. 완납 전까지는 개발사에 유보됩니다. 발주자 입장에서 불편할 수 있는데, 이걸 뒤집으려고 협상하기보다는 잔금이 빨리 나갈 수 있게 만드는 쪽이 서로 편합니다. 검수 기준이 구체적이면 검수는 며칠 안에 끝나고, 검수가 끝나면 잔금이 나가고, 잔금이 나가면 소스가 넘어갑니다. 막히는 건 대개 "무엇이 되면 검수 통과인지"가 정해져 있지 않아서입니다.

한 가지 더. 개발사가 원래부터 갖고 있던 범용 모듈이나 프레임워크까지 통째로 넘어오는 건 아닙니다. 이 프로젝트를 위해 새로 만든 부분이 넘어오고, 기존 보유분은 쓸 수 있도록 허락받는 구조입니다. 이 구분이 계약서에 없으면 나중에 "다 준다고 했잖아요"가 나옵니다.

계약서 어디에도 없던 얘기가 진행 중에 나오는 대표적인 경우입니다. 나쁜 의도가 아니라, 옆에 앉혀놓고 얘기하면 빠를 것 같아서 하는 제안입니다. 실제로 빠른 경우도 있습니다.

다만 도급 단가로 상주를 요구하면 그건 계산이 맞지 않습니다. 원격 수행을 전제로 산정한 견적에 출퇴근과 대기 시간이 붙으면 실질 단가가 반토막 납니다. 상주가 정말 필요한 프로젝트라면 그건 도급이 아니라 인력 상주 계약이고, 단가 체계 자체가 다릅니다.

지금은 범위 조항에 "원격·비대면으로 수행하며, 발주자 사업장 상주는 포함되지 않는다"를 명시합니다. 한 줄이지만 이 대화 자체가 안 생깁니다.

개발 중 요구사항이 바뀌는 건 자연스러운 일입니다. 만들다 보면 처음 생각이 틀렸다는 걸 알게 되고, 그때 바꾸는 게 맞습니다. 문제는 그 변경이 무상이라고 암묵적으로 가정될 때입니다.

작은 변경 하나는 정말 서비스로 해드릴 수 있습니다. 다섯 개, 열 개가 쌓이면 프로젝트는 조용히 적자가 되고, 그때부터 개발사의 응답이 느려집니다. 발주자는 이유를 모른 채 "요즘 왜 이렇게 늦어지지"라고 느끼게 됩니다. 이 침묵의 악순환이 관계를 망칩니다.

깔끔한 방법은 변경의 단가를 계약 시점에 미리 정해두는 것입니다. 시간당 얼마인지, 화면 하나 추가에 얼마인지. 그러면 변경이 생길 때마다 견적을 새로 뜨거나 눈치를 볼 필요가 없어집니다. 발주자도 "이건 얼마짜리 변경이구나"를 알고 결정할 수 있습니다. 산정 방식은 [요구사항 변경 시 추가 비용](/guide/change-request-pricing)에 정리해뒀습니다.

소액 프로젝트에서 계약서 얘기를 꺼내면 관계가 딱딱해질까 봐 안 쓰는 경우가 많습니다. 저희도 초기에 그랬습니다. 그런데 겪어보면 반대입니다. 계약서가 없어서 감정이 상하지, 있어서 상하지 않습니다. 문서에 적혀 있으면 "이건 범위 밖이라 추가 견적을 드려야 합니다"라고 말하는 게 사무적인 안내가 되고, 없으면 그 말이 인색함이 됩니다.

프리시에서는 견적이 확정되면 계약서가 자동으로 만들어지고 전자서명으로 체결됩니다. 그래서 "계약서 쓰실래요?"라고 물어볼 일 자체가 없습니다. 조항 하나하나가 왜 그렇게 쓰여 있는지는 [계약서 양식 가이드](/guide/software-development-contract-template)에서 조항별로 풀어뒀습니다. 다른 업체와 계약하실 때 비교용으로 쓰셔도 됩니다.

덧붙여, 이 글은 실무 경험을 정리한 것이지 법률 자문이 아닙니다. 금액이 크거나 지식재산권·개인정보가 얽힌 계약이라면 변호사 검토를 받으세요.