MVP 외주 개발 계약 전 꼭 확인해야 할 체크리스트 2026

MVP 외주 개발 계약 전 체크리스트는 개발사를 고른 뒤 계약서에 서명하기 직전에 조항을 하나씩 맞춰보는 점검 목록이에요. 개발 범위와 일정, 대금 지급 조건, 검수 기준, 산출물 인도, 변경 절차, 해지 조건이 문서에 어떤 문장으로 적혀 있는지를 조항 단위로 확인해요. 어떤 업체가 좋은 업체인지 고르는 기준이 아니라, 이미 고른 업체와 맺을 문서를 펼쳐놓고 읽는 단계에서 쓰는 목록이에요.

외주를 줄지 사내에서 만들지, 어떤 회사를 후보에 올릴지, 비용과 기간은 어떻게 잡을지 같은 MVP 전반의 판단은 MVP를 처음부터 끝까지 어떻게 만드는지 정리한 가이드에서 다루고 있어요. 이 글은 그다음 단계만 다뤄요. 개발사는 정해졌고, 계약서 초안이 메일로 왔고, 이제 그 파일을 한 줄씩 읽어야 하는 시간에 무엇을 확인하고 무엇이 없으면 추가를 요구하는지예요.

계약서는 어느 조항부터 읽어야 하나요?

계약서를 첫 장부터 순서대로 읽으면 목적, 용어의 정의, 신의성실 같은 총칙에서 집중력이 먼저 소모돼요. 그런데 나중에 다툼이 생길 수 있는 자리는 총칙보다 범위, 대금, 검수, 인도, 변경, 해지 쪽이에요. 그래서 계약서는 목차를 먼저 펼쳐놓고 다툼이 생길 만한 순서대로 건너뛰며 읽는 편이 나아요.

조항 이름은 계약서마다 달라요. 어떤 문서는 개발 범위라고 쓰고 어떤 문서는 용역의 내용이라고 써요. 검수라는 단어 대신 인수 또는 납품 확인이라고 적힌 문서도 있어요. 그러니 이름으로 찾지 말고 아래 표의 확인 항목을 기준으로 해당 내용이 어디에 있는지를 찾아 표시해두세요. 읽으면서 조항 번호를 옆에 적어두면 나중에 수정 요청을 보낼 때 그대로 쓸 수 있어요.

읽는 순서를 정해두면 좋은 이유가 하나 더 있어요. 위에서 아래로 읽다 보면 앞 조항에서 확인한 내용이 뒤 조항의 조건이 돼요. 범위가 문서로 고정돼야 검수 기준이 생기고, 검수 기준이 있어야 대금 지급 조건을 걸 수 있고, 지급 조건이 있어야 인도와 해지가 의미를 가져요. 순서가 곧 논리라서 중간에 빈 칸이 있으면 그 뒤가 전부 헐거워져요.

계약서에 별첨으로 붙여야 할 문서는 무엇인가요?

계약서 본문만으로 개발 범위를 적기는 어려워요. 화면이 몇 개고 각 화면에서 무엇이 되는지를 본문 문장으로 풀어 쓰면 읽을 수 없는 문서가 돼요. 그래서 범위는 별첨으로 빠지고, 본문에는 그 별첨을 가리키는 한 줄만 남아요. 이 한 줄이 있느냐 없느냐가 나중에 범위 다툼의 결과를 갈라요.

서명 전에 별첨 목록을 확인하고, 목록에 이름만 있고 파일이 비어 있는 항목이 없는지 보세요. 특히 계약을 서두르는 상황에서 별첨은 추후 협의로 확정한다고 적힌 채로 넘어가는 경우가 있어요. 추후 협의라는 말은 협의가 안 됐을 때 어떻게 되는지를 정하지 않은 상태라서, 그 부분은 사실상 범위가 없는 것과 같아요.

• 기능 명세서: 화면 목록과 화면별 동작, 예외 상황까지 적힌 문서예요. 어떤 수준까지 써야 하는지는 기능명세서에 무엇을 어디까지 적어야 하는지를 참고해 계약 전에 맞춰두면 좋아요.
• 범위 확정 문서: 이번 계약에서 만드는 것과 다음으로 미루는 것을 나눈 문서예요. MVP 범위를 어디서 끊어야 하는지를 먼저 정리해두면 별첨이 훨씬 짧아져요.
• 제안서와 견적서: 제안 단계에서 받은 문서가 계약의 일부인지 아닌지를 본문에서 밝혀야 해요. 견적서의 항목을 어떻게 뜯어봐야 하는지를 확인하고, 견적서 항목과 별첨 명세가 서로 어긋나지 않는지 대조하세요.
• 일정표: 마일스톤 이름과 각 마일스톤의 산출물이 적힌 표예요. 날짜만 있고 산출물이 없으면 검수 기준을 걸 수 없어요.
• 비기능 요건: 동시 접속, 응답 속도, 브라우저와 기기 지원 범위, 보안 요건처럼 기능 목록에 안 잡히는 조건이에요. 이 문서가 없으면 느리다는 이유로 검수를 거부하기 어려워요.
• 산출물 목록: 코드 외에 무엇을 받는지 적은 목록이에요. 뒤에서 따로 다룰게요.

발주 단계에서 요구사항을 문서로 정리해두었다면 그 문서를 그대로 별첨으로 쓸 수 있어요. 아직 정리 전이라면 RFP에 무엇을 담아야 제안이 비교 가능해지는지를 보고 요구사항을 한 번 정리한 다음 계약서로 넘어가는 편이 결과적으로 빨라요.

개발 범위는 계약서에 어떻게 적혀 있어야 나중에 다투지 않나요?

범위 조항에서 문제가 되는 문장은 거짓말이 아니라 짧은 문장이에요. 회원가입 기능 개발이라고만 적혀 있으면 발주자는 소셜 로그인과 비밀번호 찾기, 이메일 인증까지 떠올리고 개발사는 아이디와 비밀번호로 계정을 만드는 화면 하나를 떠올려요. 둘 다 계약서를 근거로 자기 해석이 맞다고 말할 수 있어요. 계약서가 짧은 문장을 허용했기 때문이에요.

그래서 범위 조항을 읽을 때는 문장마다 이 문장을 두 사람이 다르게 읽을 수 있는지를 물어보세요. 다르게 읽힐 수 있으면 그 자리에서 질문을 만들고, 답을 별첨 명세에 문장으로 넣어요.

범위를 적을 때 하나 더 챙길 것은 제외 목록이에요. 만드는 것만 적으면 목록에 없는 기능은 포함인지 제외인지가 계속 논쟁거리가 돼요. 이번 계약에서 하지 않는 것을 따로 적어두면 그 논쟁이 크게 줄어요. 데이터 이관, 기존 시스템 연동, 콘텐츠 입력, 앱 마켓 심사 대응처럼 잊기 쉬운 항목을 제외 목록에 올릴지 포함 목록에 올릴지부터 정하세요.

견적이 인월 단위로 산정됐다면 범위와 숫자가 맞물려요. 투입 인원과 기간으로 금액이 나온 견적은 범위가 늘어나면 금액도 늘어난다는 뜻이라서, 인월 산정이 타당한지 어떻게 따져보는지를 보고 견적의 전제를 계약서 별첨에 남겨두는 편이 안전해요.

일정과 지연은 계약서가 어떻게 다루나요?

일정 조항에서 먼저 볼 것은 마지막 날짜가 아니라 첫날의 기준이에요. 착수일이 계약 체결일인지, 착수금 입금일인지, 발주자가 자료를 전달한 날인지에 따라 전체 일정이 통째로 밀려요. 계약서에 착수일의 기준이 되는 사건이 적혀 있는지 확인하고, 없으면 그 문장부터 추가를 요구하세요.

그다음은 발주자 쪽 사정으로 생기는 지연이에요. 자료 전달이 늦거나 피드백이 늦으면 일정이 밀리는 것은 당연한데, 계약서가 그 경우를 어떻게 다루는지는 문서마다 달라요. 발주자 귀책 지연이 생기면 일정이 그만큼 연장된다고만 적힌 문서도 있고, 대기 기간에 대한 비용을 청구할 수 있게 적힌 문서도 있어요. 어느 쪽이든 읽고 넘어가야 서명 후에 놀라지 않아요.

지연에 대한 배상 조항이 있다면 금액 산정 방식과 상한이 함께 적혀 있는지 보세요. 산정 방식만 있고 상한이 없는 문장, 반대로 개발사 귀책 지연에는 아무 효과가 없고 발주자 귀책에만 효과가 있는 비대칭 문장은 서명 전에 짚어야 할 자리예요. 이런 한쪽으로 기운 문장을 어떻게 알아보는지는 계약서에서 어떤 문장이 독소조항이 되는지에서 유형별로 정리해두었어요.

마지막으로 일정 변경의 절차예요. 일정이 밀릴 때 메신저 대화로 넘어가는 것이 아니라, 변경된 일정표를 다시 합의해 문서로 남기는 절차가 있는지 확인하세요. 일정은 검수와 대금 지급의 기준이라서, 일정이 말로만 밀리면 지급 조건도 같이 흐려져요.

대금은 언제, 어떤 조건이 충족되면 지급하나요?

대금 조항에서 확인할 것은 금액의 크기가 아니라 금액과 조건이 묶여 있는지예요. 지급 시점만 적힌 계약서는 시간이 지나면 돈이 나가는 구조라서, 결과물이 어떤 상태든 날짜가 오면 지급 의무가 생겨요. 반대로 각 회차에 그 시점까지 무엇이 어떤 상태로 나와 있어야 하는지가 붙어 있으면, 대금이 진행 상황을 확인하는 장치가 돼요.

회차를 몇 개로 나눌지와 비율을 어떻게 할지는 프로젝트 성격과 협상에 따라 달라지니 이 글에서 숫자를 정해드리지는 않을게요. 다만 회차를 나누는 기준을 날짜가 아니라 확인 가능한 산출물로 잡는 원칙은 규모와 상관없이 쓸 수 있어요. 회차 설계 자체를 어떻게 짜는지는 대금을 단계별로 나눠 지급하는 구조를 어떻게 짜는지에서 단계별로 다루고 있어요.

세금계산서 발행 시점, 지급 기한, 계좌 명의도 함께 확인하세요. 특히 검수 통과일과 지급 기한 사이의 간격이 적혀 있는지 보면 좋아요. 검수 즉시 지급이라고만 적힌 문서는 정산 실무에서 다투기 쉬운 문장이라, 며칠 이내처럼 기간을 적어 넣는 것이 서로에게 편해요.

검수는 누가 무엇을 기준으로 통과시키나요?

검수 조항은 대금 조항과 한 몸이에요. 지급 조건에 검수 통과를 걸어두었다면, 검수가 무엇인지 정의돼 있어야 그 조건이 작동해요. 검수 조항에서는 기준, 기간, 절차, 통과하지 못했을 때의 처리까지 네 가지를 확인하세요.

• 기준: 별첨 명세서와 비기능 요건을 기준으로 한다고 적혀 있는지 보세요. 기준 문서가 지정되지 않으면 검수는 취향 싸움이 돼요.
• 기간: 개발사가 검수를 요청한 날부터 발주자가 결과를 통보하기까지의 기간이에요. 이 기간이 없으면 검수가 무한정 늘어지고, 너무 짧으면 제대로 못 보고 통과시키게 돼요.
• 절차: 무엇을 어떤 형태로 제출하고 어디서 확인하는지예요. 테스트 환경 주소, 테스트 계정, 확인 항목 목록이 함께 오는지 적어두면 검수일에 헤매지 않아요.
• 불합격 시 처리: 보완 요청을 몇 번까지, 어느 기간 안에 할 수 있는지, 보완 후 재검수는 어떻게 하는지예요.

여기서 특히 눈여겨볼 문장이 하나 있어요. 기간 안에 발주자가 아무 통보를 하지 않으면 합격한 것으로 본다는 간주 조항이에요. 이 문장 자체가 부당한 것은 아니고 프로젝트를 진행시키는 장치이기도 한데, 검수 기간이 짧게 적혀 있으면 사실상 자동 합격 장치가 돼요. 기간이 현실적인지, 통보 방법이 명확한지를 같이 확인하세요.

검수를 통과했다는 사실을 무엇으로 남기는지도 정해야 해요. 메신저에 남긴 확인 한 줄인지, 서명된 검수 확인서인지에 따라 나중에 증거의 무게가 달라져요. 산출물 검수와 확인서를 어떻게 남기는지를 보고 검수 확인서 양식을 계약 별첨으로 미리 붙여두면 검수일에 서식을 만들 일이 없어요.

소스코드와 계정은 언제 누구에게 넘어오나요?

이 항목은 합의는 있는데 문장이 없는 자리예요. 소스코드를 넘겨준다는 말은 미팅에서 오가지만, 언제 어떤 형태로 넘기는지까지 계약서에 적혀 있는지는 따로 확인해야 해요. 코드는 받았는데 배포 스크립트가 없거나, 계정 소유자가 개발사로 남아 있거나, 외부 서비스 키가 개발사 개인 계정에 묶여 있는 상황이 여기서 생겨요.

권리 귀속 시점도 함께 봐야 해요. 권리가 잔금 지급 시점에 넘어온다고 적힌 문서와 산출물 인도 시점에 넘어온다고 적힌 문서는 분쟁이 생겼을 때 결과가 달라져요. 어떤 문장이 무엇을 뜻하는지는 소스코드 소유권과 저작권이 누구에게 남는지에서 상세히 다루고 있으니 계약서를 옆에 두고 대조해보세요.

인도 목록을 계약서 별첨으로 붙이면 프로젝트가 끝나는 날 할 일이 목록 확인으로 줄어들어요. 무엇을 받아야 하는지 감이 잡히지 않는다면 인수인계 때 넘겨받아야 할 자산이 무엇인지를 보고 우리 프로젝트에 해당하는 항목만 골라 별첨을 만드세요.

기술 스택도 이 조항과 연결돼요. 나중에 다른 팀이 이어받을 수 있는 기술인지는 취향 문제가 아니라 인도 가능성의 문제예요. 계약서에 사용할 주요 기술과 실행 환경을 적어두면 인도 시점에 받아야 할 것이 자연히 정해지고, 특정 개인만 아는 구성에 묶이는 상황을 줄일 수 있어요.

계약 후 기능이 바뀌면 어떤 절차로 처리하나요?

MVP는 만드는 도중에 생각이 바뀌는 것이 정상이에요. 사용자 반응을 보고 화면을 바꾸거나, 만들다 보니 더 간단한 방법을 찾거나, 반대로 빠뜨린 조건을 발견해요. 문제는 변경 자체가 아니라 변경이 문서 없이 쌓이는 상황이에요. 메신저로 부탁한 수정이 열 개쯤 쌓이면 일정도 금액도 원래 계약과 어긋나는데, 어긋난 양을 누구도 계산하지 못해요.

그래서 계약서에는 변경 절차가 있어야 해요. 요청을 서면으로 접수하고, 개발사가 일정과 금액에 미치는 영향을 회신하고, 발주자가 승인하면 그때 작업을 시작하고, 그 합의서를 계약의 일부로 편입하는 흐름이에요. 승인 전에는 작업을 시작하지 않는다는 문장이 함께 있어야 양쪽 모두 안전해요.

변경 요청이 오갈 때마다 원래 계약 범위와 얼마나 멀어졌는지 볼 수 있도록 변경 대장을 한 곳에 쌓는 것도 계약서에 적을 수 있어요. 실무에서 이 절차를 어떻게 굴리는지는 변경 요청을 어떤 단계로 처리하는지에 단계별로 정리돼 있어요. 절차가 무거워 보이면 요청서 양식 한 장으로 줄여도 돼요. 중요한 것은 양식의 두께가 아니라 승인 전에 작업이 시작되지 않는다는 규칙이에요.

하자보수와 유지보수는 계약서에서 어떻게 구분되나요?

출시 후의 갈등은 이 두 단어가 섞이면서 시작되기 쉬워요. 하자보수는 계약한 대로 만들어지지 않은 부분을 고치는 일이고, 유지보수는 계약한 대로 만들어진 결과물을 계속 굴리고 개선하는 일이에요. 계약서가 하자보수를 개발사의 의무로 정해두었다면 전자는 이미 받은 대금 안에서 처리하는 일이 되고, 후자는 조건과 대가를 새로 정해야 하는 일이 돼요.

계약서에서 확인할 것은 이 구분의 기준이 문서에 적혀 있는지예요. 별첨 명세서에 적힌 동작과 다르게 작동하면 하자, 명세에 없던 동작을 새로 원하면 변경 요청이나 유지보수로 본다는 식의 기준이 있으면 대화가 훨씬 짧아져요. 기준 없이 하자라는 단어만 있으면 매번 같은 논쟁을 반복하게 돼요.

하자보수의 기간과 범위, 대응 시간은 계약마다 다르게 정해요. 이 글에서 몇 개월이 맞다고 말할 수는 없지만, 기간이 계약서에 숫자로 적혀 있는지, 대응 시간이 적혀 있는지, 하자보수 대상에서 빠지는 것이 무엇인지는 어떤 계약이든 확인할 수 있어요. 발주자가 임의로 코드를 수정한 경우나 외부 서비스 장애처럼 제외 사유가 적혀 있는지도 함께 보세요.

하자보수 기간이 끝난 뒤의 계약을 미리 논의해두면 출시 직후에 급하게 협상하지 않아도 돼요. 운영 계약을 어떤 형태로 맺는지는 개발이 끝난 뒤 유지보수 계약을 어떻게 맺는지에서 따로 다루고 있으니, 본계약 서명 전에 이 부분의 방향만이라도 합의해두면 좋아요.

프로젝트가 중단되거나 해지되면 계약서는 무엇을 정해두나요?

해지 조항은 읽기 불편해서 건너뛰기 쉬운 자리예요. 그런데 이 조항은 사이가 좋을 때 읽어야 의미가 있어요. 사이가 틀어진 뒤에는 협상으로 바꿀 수 없고, 그때는 이미 적혀 있는 문장대로 흘러가요.

• 해지 사유: 어떤 상황에서 계약을 끝낼 수 있는지예요. 일방이 아무 때나 해지할 수 있게 적혀 있다면 상대도 같은 권리를 갖는지 확인하세요.
• 시정 기간: 문제가 생겼을 때 바로 해지되는지, 서면 통지 후 고칠 기회를 주는지예요.
• 기 수행분 정산: 중단 시점까지의 작업을 어떻게 계산하고 정산하는지예요. 계산 기준이 없으면 정산은 감정 싸움이 돼요.
• 산출물 인도 의무: 해지 시점까지 만들어진 코드와 문서를 넘기는 의무가 있는지예요. 이 문장이 없으면 돈은 정산했는데 결과물은 못 받는 상황이 생겨요.
• 자료 반환과 파기: 서로 받은 자료를 어떻게 처리하는지, 접근 권한을 언제 회수하는지예요.
• 승계: 다른 팀이 이어받을 때 필요한 라이선스와 계정을 어떻게 넘기는지예요.

중단은 해지와 다르게 다뤄지기도 해요. 발주자 사정으로 프로젝트를 잠시 멈추는 경우, 멈출 수 있는 기간과 그동안의 비용 처리, 재개 시 일정 조정 방식이 적혀 있으면 서로 유리한 쪽으로 해석할 여지가 줄어요. 자금 상황이 유동적인 초기 팀이라면 이 문장이 실제로 쓰일 가능성이 있으니 미리 읽어두세요.

투입 인력과 재하도급은 계약서에 어떻게 적혀 있나요?

미팅에서 만난 사람과 실제로 코드를 쓰는 사람이 다른 경우가 있어요. 그 자체가 문제는 아니지만, 계약서가 인력에 대해 아무 말도 하지 않으면 확인할 방법이 없어요. 주요 인력의 역할과 참여 형태가 별첨에 적혀 있는지, 교체가 필요할 때 사전에 알리고 동등한 역량을 갖춘 인력으로 대체한다는 문장이 있는지 보세요.

재하도급 조항도 함께 확인해요. 일부 작업을 다른 팀이나 프리랜서에게 맡기는 것을 허용할지, 허용한다면 사전 서면 동의를 받게 할지, 재하도급 받은 쪽에도 같은 비밀유지와 권리 귀속 조건이 적용되는지가 핵심이에요. 특히 권리 귀속이 끊기면 소스코드 소유권 조항이 있어도 실제로는 구멍이 생겨요.

인력 구성은 견적과도 이어져요. 투입 인원 기준으로 산정된 금액이라면 계약서의 인력 조항과 견적서의 전제가 같은 것을 가리켜야 해요. 둘이 다르면 서명 전에 맞춰두세요.

비밀유지와 개인정보는 어느 조항에서 확인하나요?

비밀유지 조항에서 볼 것은 세 가지예요. 무엇이 비밀 정보인지, 얼마 동안 유지되는지, 위반했을 때 어떻게 되는지예요. 아이디어와 기획 문서, 사용자 데이터, 비즈니스 지표가 비밀 정보의 정의 안에 들어오는지 확인하세요. 계약 종료 후에도 일정 기간 유지되는지도 함께 봐요.

의무가 한쪽에만 걸려 있는지도 확인할 자리예요. 발주자만 개발사의 정보를 지키게 돼 있고 반대는 없는 문장이라면 균형을 맞춰 달라고 요청할 수 있어요.

개인정보를 다루는 서비스라면 별도로 볼 것이 더 있어요. 개발과 테스트 과정에서 실제 사용자 데이터를 쓰는지, 쓴다면 어떤 환경에서 다루는지, 종료 시 어떻게 파기하는지, 위탁 관계에 필요한 문서를 따로 작성해야 하는지를 개발사와 확인하세요. 서비스의 성격과 처리하는 데이터에 따라 필요한 문서가 달라지니, 해당 분야를 아는 전문가에게 확인받는 편이 안전해요.

보안 측면에서는 접근 권한 관리가 계약서에 적혀 있는지도 보세요. 프로젝트 기간에 개발사가 받는 계정과 권한의 목록, 프로젝트 종료 시 회수 절차가 있으면 인수인계가 훨씬 깔끔해져요.

보고와 회의는 계약서에 어떻게 적나요?

소통 방식을 정하지 않고 시작한 프로젝트는 중간에 연락이 뜸해지기 쉬워요. 그런데 소통은 계약서에 적기 애매하다고 생각해 빠지곤 해요. 실제로는 몇 줄이면 충분해요. 진행 상황을 얼마나 자주 어떤 형태로 공유하는지, 어떤 채널을 공식 창구로 쓰는지, 질문에 대한 회신 기한은 어떻게 되는지 정도면 돼요.

여기서 중요한 것은 공식 창구를 하나로 정하는 일이에요. 결정이 메신저와 메일, 통화에 흩어지면 나중에 무엇이 합의된 내용인지 아무도 몰라요. 중요한 결정은 지정한 창구에 기록으로 남긴다는 문장 한 줄이 있으면, 변경 절차와 검수 절차가 실제로 작동해요.

보고 형태도 정해두면 좋아요. 화면 시연인지, 테스트 환경 접근인지, 작업 목록 공유인지에 따라 발주자가 확인할 수 있는 깊이가 달라져요. 매주 잘 되고 있다는 말만 듣다가 마지막에 놀라는 일을 줄이려면, 매 보고마다 직접 눌러볼 수 있는 것이 있는 편이 나아요.

말로 한 약속이 계약서에 없으면 어떻게 하나요?

계약 전 미팅에서 나온 좋은 말이 거짓이라는 뜻은 아니에요. 문제는 그 말이 문서에 없으면 나중에 서로 기억이 달라진다는 점이에요. 그래서 계약 단계에서 볼 신호는 상대가 얼마나 친절한지가 아니라, 말한 내용을 문서에 넣자고 했을 때 어떻게 반응하는지예요.

• 좋은 신호: 구두로 말한 내용을 계약서나 별첨에 넣자고 하면 바로 문장을 같이 다듬어요. 범위를 줄이자는 제안을 먼저 하고, 못 하는 것을 못 한다고 말해요. 수정하기 어려운 조항이 있으면 이유를 말하고 대신 넣을 문장을 제안해요.
• 주의할 신호: 문서로 남기자는 제안에 그건 당연히 해드리는 것이라며 넘어가요. 별첨은 나중에 정하자고 하면서 서명을 먼저 요구해요. 무엇이든 다 된다고 답하고, 범위를 물어도 유연하게 대응하겠다는 말로 돌아와요. 검수와 인도 관련 문장을 수정하자고 하면 이유 설명 없이 회사 규정이라고만 답해요.

수정 요청을 모두 받아줘야 좋은 개발사라는 뜻은 아니에요. 개발사에도 지켜야 할 조건이 있고, 거절에는 합리적인 이유가 있을 수 있어요. 보는 것은 거절 여부가 아니라 이유를 설명하고 대안을 함께 찾는지예요. 이 태도는 계약 후 변경 요청이 오갈 때 그대로 반복돼요.

2026년, AI 도구를 쓰는 개발사와 계약할 때는 무엇이 달라지나요?

AI 코딩 도구를 개발 과정에 쓰는 팀과 계약하게 되는 경우가 있어요. 도구를 쓰면 같은 기간에 더 많은 화면이 나오기도 하고, 리뷰 없이 쌓인 코드가 나중에 짐이 되기도 해요. 계약 단계에서 확인할 것은 도구를 쓰느냐 아니냐가 아니라, 그 코드를 누가 책임지고 무엇으로 검증하느냐예요. 도구 이름은 계약서에 적을 필요가 없지만, 책임과 권리는 적을 수 있어요.

그래서 판단 기준은 도구 목록이 아니에요. AI 활용 여부보다 코드 리뷰 문화, 테스트, 문서화 수준이 더 정확한 지표예요. 여기에 계약 단계에서 추가로 볼 것은 비밀 정보의 처리와 제3자 권리 문제예요.

빨리 만든다는 말 자체는 계약서에서 아무 효력이 없어요. 빨리 만든 결과를 무엇으로 확인하고, 문제가 생기면 누가 고치는지가 조항으로 남아 있어야 속도가 발주자에게도 이익이 돼요.

서명 전 마지막으로 확인할 것은 무엇인가요?

여기까지 조항을 다 읽었다면 마지막은 문서 자체를 보는 단계예요. 내용이 아니라 형식 때문에 생기는 사고도 있어요. 별첨이 빠진 채로 서명되거나, 협의한 수정이 최종본에 반영되지 않았거나, 서로 다른 버전에 각자 서명하는 일이 실제로 일어나요.

마지막으로 권해드리고 싶은 것은 계약서를 혼자 읽지 않는 일이에요. 조항의 뜻을 아는 사람과 서비스의 내용을 아는 사람은 서로 다른 곳을 봐요. 사업 내용을 아는 동료가 범위와 산출물을 읽고, 계약 문서를 다뤄본 사람이 해지와 배상, 권리 귀속을 읽는 식으로 나눠 읽으면 놓치는 자리가 줄어요. 금액이 크거나 데이터 민감도가 높은 프로젝트라면 전문가의 검토를 받는 편이 안전해요.

계약서를 잘 쓰는 목적은 나중에 이기기 위해서가 아니라 다툴 일을 미리 줄이기 위해서예요. 범위가 문서로 고정되고, 검수 기준이 있고, 대금이 검수에 묶여 있고, 변경이 절차를 타고, 인도 목록이 정해져 있으면 프로젝트가 진행되는 동안 판단할 일이 훨씬 줄어들어요. 서명 전 하루를 더 쓰는 것이 개발 기간 내내 벌 시간을 만들어줘요.

자주 묻는 질문

계약서 초안을 개발사가 보내줬는데 그대로 서명해도 되나요?

초안은 보내는 쪽 기준으로 쓰이기 마련이라 그대로 서명하기보다 읽고 수정 요청을 보내는 편이 좋아요. 범위, 검수, 대금 조건, 산출물 인도처럼 다툼이 생기는 조항부터 확인하고, 수정 요청은 조항 번호와 바꿀 문장을 함께 적어 보내면 협의가 빨라져요.

표준계약서 양식을 그대로 써도 되나요?

표준 양식은 빠뜨리기 쉬운 조항을 채워주는 데 도움이 되지만, 양식만으로 이번 프로젝트의 범위와 산출물까지 채워지지는 않아요. 별첨에 들어갈 기능 명세, 일정표, 산출물 목록은 결국 직접 만들어야 하고, 양식의 문장도 프로젝트 사정에 맞게 고쳐 써야 해요.

제안서와 견적서도 계약의 일부가 되나요?

자동으로 그렇게 되지는 않아요. 계약서 본문에 제안서와 견적서를 계약의 일부로 본다는 문장이 있는지, 본문과 내용이 어긋날 때 어느 문서가 우선하는지가 적혀 있는지 확인하세요. 우선순위를 정한 문장이 없으면 나중에 서로 다른 문서를 근거로 이야기하게 돼요.

계약서에 서명하기 전에 개발을 먼저 시작해도 되나요?

일정이 급하면 착수를 서두르고 싶어지지만, 서명 전 작업은 범위와 대금의 근거가 없는 상태예요. 꼭 먼저 시작해야 한다면 착수 범위와 기간, 정산 방법을 적은 짧은 합의서라도 남기고, 본계약에서 그 기간의 작업을 어떻게 처리할지 함께 정하세요.

회의에서 합의한 내용은 계약서에 어떻게 반영하나요?

회의록을 남기는 것만으로 계약 내용이 바뀌지는 않아요. 계약서에 변경은 서면 합의로 한다는 조항이 있다면 그 절차를 따라야 하고, 별첨 수정이 필요한 합의라면 수정된 별첨을 다시 확정해 서로 확인해두는 편이 안전해요.

개발사가 계약서 수정 요청을 거절하면 어떻게 하나요?

거절 자체보다 이유를 듣는 것이 먼저예요. 회사 내부 기준 때문인지, 그 조항이 개발사에 큰 위험이 되는지에 따라 대안이 달라져요. 문장을 바꾸기 어렵다면 별첨에 조건을 적거나 위험을 줄이는 다른 조항을 넣는 방법도 있어요. 이유 설명 없이 거절만 반복된다면 계약 후 협의도 비슷하게 흘러갈 수 있어요.

비밀유지계약서는 본계약 전에 따로 써야 하나요?

제안 단계에서 아이디어나 데이터, 사업 계획을 공유해야 한다면 본계약 전에 비밀유지계약을 먼저 맺기도 해요. 본계약에도 비밀유지 조항이 들어간다면 앞서 맺은 계약과 어느 쪽이 우선하는지, 기간이 어떻게 이어지는지를 정리해두세요.

계약서 분량이 짧으면 문제가 되나요?

분량 자체가 문제는 아니에요. 확인할 것은 범위, 검수, 대금 조건, 산출물 인도, 변경 절차, 해지가 어디에든 적혀 있는지예요. 본문이 짧아도 별첨이 촘촘하면 괜찮고, 본문이 길어도 이 항목들이 비어 있으면 서명 전에 채워야 해요.