Blog·인사이트

계약서에 없는 것이 문제다

···6분 읽기
요약

계약서에 적힌 분쟁이 아니라 적히지 않은 부분에서 분쟁이 시작됩니다. 변경 절차, 산출물 정의, 인수 기준, 종료 후 협력 조건 — 이 영역이 비어있으면 양쪽이 서로 다르게 해석합니다.

외주 개발 분쟁이 생기는 이유는 계약서에 적혀있는 것 때문이 아닙니다. 적혀있지 않은 것 때문입니다. "이건 당연히 포함이죠"와 "이건 별도입니다"가 충돌하는 순간, 계약서를 펼쳐봤는데 해당 내용이 없으면 — 그때부터 분쟁입니다.

모호한 조항이 만드는 문제

계약서에 자주 등장하는 표현들이 있습니다.

"합리적인 범위 내에서"

"합리적인 범위 내에서 수정을 지원합니다." 합리적인 범위가 뭔가요? 클라이언트는 디자인 전체를 바꾸는 것도 합리적이라 생각할 수 있고, 개발사는 오타 수정 정도를 합리적이라 생각할 수 있습니다. 기준이 없으면 서로의 합리가 다릅니다.

"기술적으로 불가능한 경우 제외"

"기술적으로 불가능한 경우를 제외하고 구현합니다." 기술적으로 불가능한 것은 거의 없습니다. 다만 비용과 시간이 많이 들 뿐입니다. 이 표현은 개발사가 어려운 기능을 거절할 수 있는 포괄적인 면책 조항이 됩니다.

"상호 협의하에"

"일정 변경은 상호 협의하에 진행합니다." 한쪽이 협의를 거부하면? 협의가 안 되면 어떻게 하는지에 대한 규정이 없으면, 이 조항은 의미가 없습니다.

계약서에 반드시 명시해야 할 것

범위

기능 목록을 구체적으로 적어야 합니다. "쇼핑몰 개발"이 아니라, "상품 등록, 장바구니, 결제(카드/계좌이체), 주문 내역 조회, 관리자 상품 관리 — 이 기능을 포함한다"까지 적어야 합니다. 목록에 없는 기능은 추가 비용이라는 것도 함께 명시합니다.

일정 지연 패널티

납기일을 넘기면 어떻게 되는지. 클라이언트 귀책 사유(피드백 지연, 요구사항 변경)로 인한 지연은 어떻게 처리하는지. 양쪽 모두에게 적용되는 규정이 있어야 합니다.

소스코드 양도

프로젝트 완료 후 소스코드의 소유권이 누구에게 있는지. 잔금 지급 후 양도인지, 단계별 지급에 따라 부분 양도인지. "당연히 우리 거 아니에요?"라고 생각하지만, 계약서에 없으면 당연하지 않습니다.

사후 지원

무상 수정 기간은 얼마인지. 무상 수정의 범위는 어디까지인지. 버그 수정과 기능 추가의 기준은 무엇인지. 무상 기간 이후 유지보수 비용은 어떻게 산정하는지.

소스코드 양도 — 가장 흔한 착각이자 가장 비싼 빈칸

계약서에서 빠져서 가장 크게 터지는 항목이 소스코드 양도입니다. 대부분의 클라이언트는 "개발비를 냈으니 소스코드도 당연히 내 것"이라고 생각합니다. 하지만 계약서에 소스코드 양도가 명시되지 않으면, 양도되지 않은 것이 기본값이 됩니다. 빌드되어 돌아가는 서비스(결과물)를 받는 것과 그 소스코드를 받는 것은 별개입니다.

소스코드를 넘겨받지 못하면 그 개발사에 락인(lock-in)됩니다. 락인되면 이런 일이 벌어집니다.

  • 작은 기능 추가나 버그 수정도 그 개발사에만 맡겨야 합니다. 다른 개발사는 코드가 없으니 손댈 수 없습니다.
  • 유지보수 단가를 개발사가 부르는 대로 받아들이게 됩니다. 옮길 곳이 없으니 협상력이 없습니다.
  • 그 개발사가 폐업하거나 연락이 끊기면 서비스 전체가 그대로 멈춥니다.
  • 나중에 다른 팀으로 옮기려 해도 처음부터 다시 만드는 비용이 들어, 사실상 이전이 불가능합니다.

더 나쁜 경우는 의도적인 사기입니다. 이런 개발사는 "소스코드"라는 단어를 직접 쓰지 않습니다. 미팅에서는 "산출물 다 드리죠"처럼 모호하게 말하면서, '소스코드'라는 표현은 의도적으로 피합니다. 클라이언트가 알아서 "소스코드도 당연히 포함"이라고 받아들이도록 두는 것입니다. '산출물'은 빌드되어 돌아가는 결과물만 가리킬 수도 있어서, 나중에 "소스코드를 준다고 한 적은 없다"고 빠져나갈 여지를 남깁니다. 구두로는 다 주는 뉘앙스를 풍기고, 계약서에는 그 한 줄을 적지 않습니다. 분쟁이 생겨 펼쳐본 계약서에는 양도 조항이 없고, 말로 한 약속은 나중에 효력을 주장하기 어렵습니다.

그렇다고 소스코드 양도가 무조건 정답은 아닙니다

여기서 균형을 잡아야 합니다. 소스코드 양도가 언제나 클라이언트의 당연한 권리인 것은 아닙니다. 가격과 직접 연결돼 있기 때문입니다.

예를 들어 어떤 개발사가 자체 솔루션을 보유하고 있고, 그 솔루션을 재활용하는 대가로 개발비를 아주 낮게 책정했다고 해봅시다. 그 낮은 가격이 가능한 이유는 같은 솔루션을 다른 고객에게도 재활용하기 때문입니다. 그런데 그 저렴한 가격에 소스코드까지 통째로 넘기라고 하면, 개발사는 자기 핵심 자산을 원가 이하로 파는 셈이 되어 사업이 성립하지 않습니다. 그 가격엔 애초에 소스코드 양도가 들어있지 않은 것입니다.

그래서 소스코드 양도는 "받느냐 마느냐"가 아니라 "어떤 가격에 받느냐"의 문제입니다. 일반적으로 소스코드를 온전히 넘겨받는 정상적인 계약은 염가 덤핑 가격과는 거리가 멉니다. 소스코드까지 갖고 싶다면 그만한 비용을 지불하는 것이 맞고, 비용을 낮추고 싶다면 소스코드의 일부 또는 전부를 개발사가 보유하는 구조를 받아들이는 것이 맞습니다. 가장 나쁜 것은 가장 싼 가격을 찾으면서 소스코드 양도는 당연하게 기대하고, 정작 그 조항은 계약서에 적지도 않는 것입니다. 너무 싼 것만 좇다 보면 결국 소스코드도 협상력도 없이 락인되는 자리로 스스로 걸어 들어가게 됩니다.

우리가 직접 본 "계약서에 없어서 깨진" 사례들

프로덕트 메이커는 이전 개발사로부터 인수받은 프로젝트를 여러 건 운영해왔습니다. 그 인수인계 과정에서 계약서를 열어보면, 분쟁의 출발점은 거의 모두 앞서 짚은 "계약서에 없는 영역"이었습니다.

"기획서 외 추가 요청"의 정의가 없는 경우 — 클라이언트는 기획서에 없던 작은 화면 한두 개도 "당연히 포함"으로 보고, 개발사는 모두 "추가 견적"으로 봅니다. 화면 한 개의 추가가 다음 미팅에서 결제 보류로 이어지고, 그게 한 달짜리 분쟁으로 번집니다.

"인수인계 범위"가 없는 경우 — 프로젝트가 끝났는데 다음 운영사로 옮길 때 어떤 문서·설정·접속 권한이 함께 넘어가야 하는지 적혀있지 않습니다. 저희가 인수받은 프로젝트 중 일부는 인수인계 문서가 단 한 줄도 없는 상태로 넘어왔고, 그 자리에서 새 운영팀이 코드를 처음부터 다시 읽어야 했습니다.

우리가 계약서에 반드시 적는 것

저희가 클라이언트와 계약을 맺을 때는 다음 항목을 부속 문서로 함께 첨부합니다.

  • 기능 명세 (URL 목록 + 각 화면의 입출력 + 권한) — "쇼핑몰" 같은 큰 단어 대신 화면 단위로 정리
  • 각 마일스톤의 완료 정의 — "어떤 동작이 어떤 결과를 내면 달성"까지 적시
  • 소스코드·계정·인프라 권한 양도 일자와 형식 — 결제 단계마다 어느 자산이 어떻게 넘어가는지
  • 변경 요청 절차 — 추가 비용·일정 영향을 어떤 양식으로 합의하는지
  • 사후 지원 범위와 기간 — 무상 수정의 정의·기간·유지보수 전환 조건
  • 계약 종료 후 협력 조건 — 다음 운영사로 인수인계 시 우리가 제공할 것

좋은 계약서의 기준

좋은 계약서는 문제가 없을 때는 필요 없습니다. 서로 신뢰하고, 소통이 잘 되고, 프로젝트가 순조로우면 계약서를 꺼내볼 일이 없습니다.

하지만 문제는 반드시 생깁니다. 일정이 지연되거나, 결과물이 기대와 다르거나, 추가 비용이 발생하거나. 그때 계약서를 펼쳤을 때 명확한 기준이 적혀있으면 분쟁이 아니라 협의가 됩니다. 기준이 없으면 감정 싸움이 됩니다.

계약서는 서로를 의심하기 위한 문서가 아닙니다. 문제가 생겼을 때 서로를 보호하기 위한 문서이고, 동시에 처음 시작할 때 양쪽이 같은 것을 보고 있는지 확인하는 도구입니다. 좋은 계약서는 분쟁이 생긴 뒤에 펼쳐 보면 이미 답이 적혀 있어서, 분쟁이 협의로 끝납니다.

*외주 개발 계약에 대해 상담이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 명확한 범위와 조건으로 시작합니다.*


계약서,분쟁,외주개발,법률
다른 포스팅
Blog·인사이트

계약서에 없는 것이 문제다

···6분 읽기

외주 개발 분쟁이 생기는 이유는 계약서에 적혀있는 것 때문이 아닙니다. 적혀있지 않은 것 때문입니다. "이건 당연히 포함이죠"와 "이건 별도입니다"가 충돌하는 순간, 계약서를 펼쳐봤는데 해당 내용이 없으면 — 그때부터 분쟁입니다.

모호한 조항이 만드는 문제

계약서에 자주 등장하는 표현들이 있습니다.

"합리적인 범위 내에서"

"합리적인 범위 내에서 수정을 지원합니다." 합리적인 범위가 뭔가요? 클라이언트는 디자인 전체를 바꾸는 것도 합리적이라 생각할 수 있고, 개발사는 오타 수정 정도를 합리적이라 생각할 수 있습니다. 기준이 없으면 서로의 합리가 다릅니다.

"기술적으로 불가능한 경우 제외"

"기술적으로 불가능한 경우를 제외하고 구현합니다." 기술적으로 불가능한 것은 거의 없습니다. 다만 비용과 시간이 많이 들 뿐입니다. 이 표현은 개발사가 어려운 기능을 거절할 수 있는 포괄적인 면책 조항이 됩니다.

"상호 협의하에"

"일정 변경은 상호 협의하에 진행합니다." 한쪽이 협의를 거부하면? 협의가 안 되면 어떻게 하는지에 대한 규정이 없으면, 이 조항은 의미가 없습니다.

계약서에 반드시 명시해야 할 것

범위

기능 목록을 구체적으로 적어야 합니다. "쇼핑몰 개발"이 아니라, "상품 등록, 장바구니, 결제(카드/계좌이체), 주문 내역 조회, 관리자 상품 관리 — 이 기능을 포함한다"까지 적어야 합니다. 목록에 없는 기능은 추가 비용이라는 것도 함께 명시합니다.

일정 지연 패널티

납기일을 넘기면 어떻게 되는지. 클라이언트 귀책 사유(피드백 지연, 요구사항 변경)로 인한 지연은 어떻게 처리하는지. 양쪽 모두에게 적용되는 규정이 있어야 합니다.

소스코드 양도

프로젝트 완료 후 소스코드의 소유권이 누구에게 있는지. 잔금 지급 후 양도인지, 단계별 지급에 따라 부분 양도인지. "당연히 우리 거 아니에요?"라고 생각하지만, 계약서에 없으면 당연하지 않습니다.

사후 지원

무상 수정 기간은 얼마인지. 무상 수정의 범위는 어디까지인지. 버그 수정과 기능 추가의 기준은 무엇인지. 무상 기간 이후 유지보수 비용은 어떻게 산정하는지.

소스코드 양도 — 가장 흔한 착각이자 가장 비싼 빈칸

계약서에서 빠져서 가장 크게 터지는 항목이 소스코드 양도입니다. 대부분의 클라이언트는 "개발비를 냈으니 소스코드도 당연히 내 것"이라고 생각합니다. 하지만 계약서에 소스코드 양도가 명시되지 않으면, 양도되지 않은 것이 기본값이 됩니다. 빌드되어 돌아가는 서비스(결과물)를 받는 것과 그 소스코드를 받는 것은 별개입니다.

소스코드를 넘겨받지 못하면 그 개발사에 락인(lock-in)됩니다. 락인되면 이런 일이 벌어집니다.

  • 작은 기능 추가나 버그 수정도 그 개발사에만 맡겨야 합니다. 다른 개발사는 코드가 없으니 손댈 수 없습니다.
  • 유지보수 단가를 개발사가 부르는 대로 받아들이게 됩니다. 옮길 곳이 없으니 협상력이 없습니다.
  • 그 개발사가 폐업하거나 연락이 끊기면 서비스 전체가 그대로 멈춥니다.
  • 나중에 다른 팀으로 옮기려 해도 처음부터 다시 만드는 비용이 들어, 사실상 이전이 불가능합니다.

더 나쁜 경우는 의도적인 사기입니다. 이런 개발사는 "소스코드"라는 단어를 직접 쓰지 않습니다. 미팅에서는 "산출물 다 드리죠"처럼 모호하게 말하면서, '소스코드'라는 표현은 의도적으로 피합니다. 클라이언트가 알아서 "소스코드도 당연히 포함"이라고 받아들이도록 두는 것입니다. '산출물'은 빌드되어 돌아가는 결과물만 가리킬 수도 있어서, 나중에 "소스코드를 준다고 한 적은 없다"고 빠져나갈 여지를 남깁니다. 구두로는 다 주는 뉘앙스를 풍기고, 계약서에는 그 한 줄을 적지 않습니다. 분쟁이 생겨 펼쳐본 계약서에는 양도 조항이 없고, 말로 한 약속은 나중에 효력을 주장하기 어렵습니다.

그렇다고 소스코드 양도가 무조건 정답은 아닙니다

여기서 균형을 잡아야 합니다. 소스코드 양도가 언제나 클라이언트의 당연한 권리인 것은 아닙니다. 가격과 직접 연결돼 있기 때문입니다.

예를 들어 어떤 개발사가 자체 솔루션을 보유하고 있고, 그 솔루션을 재활용하는 대가로 개발비를 아주 낮게 책정했다고 해봅시다. 그 낮은 가격이 가능한 이유는 같은 솔루션을 다른 고객에게도 재활용하기 때문입니다. 그런데 그 저렴한 가격에 소스코드까지 통째로 넘기라고 하면, 개발사는 자기 핵심 자산을 원가 이하로 파는 셈이 되어 사업이 성립하지 않습니다. 그 가격엔 애초에 소스코드 양도가 들어있지 않은 것입니다.

그래서 소스코드 양도는 "받느냐 마느냐"가 아니라 "어떤 가격에 받느냐"의 문제입니다. 일반적으로 소스코드를 온전히 넘겨받는 정상적인 계약은 염가 덤핑 가격과는 거리가 멉니다. 소스코드까지 갖고 싶다면 그만한 비용을 지불하는 것이 맞고, 비용을 낮추고 싶다면 소스코드의 일부 또는 전부를 개발사가 보유하는 구조를 받아들이는 것이 맞습니다. 가장 나쁜 것은 가장 싼 가격을 찾으면서 소스코드 양도는 당연하게 기대하고, 정작 그 조항은 계약서에 적지도 않는 것입니다. 너무 싼 것만 좇다 보면 결국 소스코드도 협상력도 없이 락인되는 자리로 스스로 걸어 들어가게 됩니다.

우리가 직접 본 "계약서에 없어서 깨진" 사례들

프로덕트 메이커는 이전 개발사로부터 인수받은 프로젝트를 여러 건 운영해왔습니다. 그 인수인계 과정에서 계약서를 열어보면, 분쟁의 출발점은 거의 모두 앞서 짚은 "계약서에 없는 영역"이었습니다.

"기획서 외 추가 요청"의 정의가 없는 경우 — 클라이언트는 기획서에 없던 작은 화면 한두 개도 "당연히 포함"으로 보고, 개발사는 모두 "추가 견적"으로 봅니다. 화면 한 개의 추가가 다음 미팅에서 결제 보류로 이어지고, 그게 한 달짜리 분쟁으로 번집니다.

"인수인계 범위"가 없는 경우 — 프로젝트가 끝났는데 다음 운영사로 옮길 때 어떤 문서·설정·접속 권한이 함께 넘어가야 하는지 적혀있지 않습니다. 저희가 인수받은 프로젝트 중 일부는 인수인계 문서가 단 한 줄도 없는 상태로 넘어왔고, 그 자리에서 새 운영팀이 코드를 처음부터 다시 읽어야 했습니다.

우리가 계약서에 반드시 적는 것

저희가 클라이언트와 계약을 맺을 때는 다음 항목을 부속 문서로 함께 첨부합니다.

  • 기능 명세 (URL 목록 + 각 화면의 입출력 + 권한) — "쇼핑몰" 같은 큰 단어 대신 화면 단위로 정리
  • 각 마일스톤의 완료 정의 — "어떤 동작이 어떤 결과를 내면 달성"까지 적시
  • 소스코드·계정·인프라 권한 양도 일자와 형식 — 결제 단계마다 어느 자산이 어떻게 넘어가는지
  • 변경 요청 절차 — 추가 비용·일정 영향을 어떤 양식으로 합의하는지
  • 사후 지원 범위와 기간 — 무상 수정의 정의·기간·유지보수 전환 조건
  • 계약 종료 후 협력 조건 — 다음 운영사로 인수인계 시 우리가 제공할 것

좋은 계약서의 기준

좋은 계약서는 문제가 없을 때는 필요 없습니다. 서로 신뢰하고, 소통이 잘 되고, 프로젝트가 순조로우면 계약서를 꺼내볼 일이 없습니다.

하지만 문제는 반드시 생깁니다. 일정이 지연되거나, 결과물이 기대와 다르거나, 추가 비용이 발생하거나. 그때 계약서를 펼쳤을 때 명확한 기준이 적혀있으면 분쟁이 아니라 협의가 됩니다. 기준이 없으면 감정 싸움이 됩니다.

계약서는 서로를 의심하기 위한 문서가 아닙니다. 문제가 생겼을 때 서로를 보호하기 위한 문서이고, 동시에 처음 시작할 때 양쪽이 같은 것을 보고 있는지 확인하는 도구입니다. 좋은 계약서는 분쟁이 생긴 뒤에 펼쳐 보면 이미 답이 적혀 있어서, 분쟁이 협의로 끝납니다.

*외주 개발 계약에 대해 상담이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 명확한 범위와 조건으로 시작합니다.*


계약서,분쟁,외주개발,법률
다른 포스팅
WebGL프로젝트 상담