.svg)
계약서는 악마가 아니라, 당신의 무능력을 들키지 않게 감싸주는 포장지다.
당신은 아이디어 하나로 세상을 바꾸려는 야망을 품었다. 그 열정을 종이 한 장에 가둬두려는 현실이 싫다. 그래서 변호사들 이야기는 귀찮다. 하지만 들어보라. 지금 당신이 보려는 그 깔끔한 앱개발업체의 PPT 뒤에는, 당신의 무지를 이용하려는 냉철한 계산이 숨어 있다.
앱 개발 프로젝트의 90%가 넘는 분쟁이 바로 ‘계약서’ 한 줄 때문에 발생한다는 사실을 아는가? 심지어 1심에서는 90% 패소하던 발주자(클라이언트)가 2심에서 판세를 뒤집는 경우도 있는데, 그 차이는 고작 ‘과업 범위의 구체성’이었다. 계약서를 쓰기 전, 당신이 반드시 챙겨야 할 단 하나의 행동이 있다.
당신의 아이디어, 요구사항 정의서(RFP)라는 옷을 입어라
계약서 쓰기 전, 가장 먼저 할 일은 ‘요구사항 정의서(RFP)’를 완성하는 것이다. 계약서는 단지 이 RFP를 법률 문장으로 번역한 것에 불과하다. 만약 당신이 “로켓 배송 앱 만들어주세요”라는 수준으로 이야기한다면, 업체는 싸구려 자전거를 만들어 줄 것이다. 나중에 “저는 로켓을 원했어요”라고 말해봐라. 이미 계약서에는 ‘기본 배송 기능’이라고만 적혀 있다.
RFP의 핵심 무기:
- 기능의 경계: 반드시 들어갈 기능(A), 들어가면 좋은 기능(B), 절대 들어가면 안 되는 기능(C)을 구분하라.
- 기술 스택:
React Native인지,Flutter인지, 네이티브인지. 이 말을 모른다면 당신의 개발팀장이나 기술 고문을 데리고 와라. - 환경: “앱이 터지면 안 된다”는 말은 의미 없다. ‘예상 동시 접속자 수’와 ‘페이지 로딩 속도 기준(3초 이내)’을 숫자로 때려박아라.
지식재산권(IP) 조항: ‘소유권’이라는 함정
변호사들이 가장 많이 욕하는 조항이 바로 이 ‘소유권’ 조항이다. 계약서에 “소스코드의 소유권은 발주사(당신)에게 있습니다” 라고 쓰여 있다고 해서 안심하지 마라. 법조계에서는 ‘소유권’이라는 단어는 부동산이나 물건에나 쓰는 표현일 뿐, 소프트웨어처럼 무형의 결과물에 대해서는 ‘지식재산권(IP)’이라는 용어를 써야 한다.
당신이 챙겨야 할 진짜 IP 조항은 이것이다:
- 권리의 대상: 실행파일만 넘어오는가? 진정한 자산인 ‘소스코드 전체’가 넘어오는가? (대부분의 업체는 실행파일만 넘기고, 수정은 우리만 하게끔 코드를 감춘다).
- 2차 저작물: 당신이 돈 주고 만든 디자인과 로직으로 새로운 기능을 추가할 때, 그 권리도 당신에게 있는가?
- 오픈소스: 개발사가 무료 오픈소스를 갖다 붙였는데, 그 오픈소스 라이선스가 상업적 이용을 금지하는
GPL계열이라면? 당신의 앱은 출시하자마자 ‘저작권 침해’라는 미사일을 맞게 된다.
유지보수, 계약서에 ‘연인 관계’를 규정하는 법
개발이 끝났다고 해서 관계가 끝나는 게 아니다. 앱스토어 심사 정책은 매달 바뀌고, iOS가 업데이트되면 당신의 앱은 작동을 멈춘다.
‘무상 하자 보수 기간’과 ‘유상 유지보수’의 경계를 정하라.
- 하자: 내가 명시한 기능이 버그로 인해 작동 안 하는 경우.
- 유지보수: 애플이 로그인 정책을 바꿔서 코드를 고쳐야 하는 경우.
업체들이 가장 교묘하게 속이는 부분이다. “QA 기간 1달, 무상 AS 3달”이라는 말만 보고 덥썩 물지 마라. “QA 종료 후 발견된 중대한 버그에 대한 책임” 조항을 반드시 넣어라. 만약 그들이 “우리는 책임 못 진다”고 하면, 그 자리에서 계약서를 찢어버려라.
결제 조건, 감정을 빼고 숫자를 넣어라
당신이 100% 완성된 앱을 보고 나서 돈을 다 주겠다고 고집하는 것은 초보의 발상이다. 당연히 개발사는 그걸 거부한다. 정답은 ‘마일스톤(Milestone) 지급’에 있다.
| 단계 | 목표 | 지급 비율 (예시) |
|---|---|---|
| 1. 계약 및 착수 | RFP 최종 합의, 디자인 리소스 투입 | 20% |
| 2. 핵심 기능 완료 | 로그인, 메인 페이지, 핵심 로직 시연 | 30% |
| 3. 알파 테스트 | 내부 테스트 완료, 버그 수정 | 30% |
| 4. 최종 납품 및 오픈 | 앱스토어 등록, 소스코드 및 비밀번호 전달 | 20% (잔금) |
프로 팁: 절대 100%를 미리 다 주지 마라. 잔금 20%는 당신이 ‘감정적 합격’을 하는 것이 아니라 ‘기술적 승인’을 하는 순간 지급한다. 그리고 계약서에 ‘지연 손해배상 조항(LD)’을 넣어라. 일정이 하루 밀릴 때마다 공급사는 0.1%의 페널티를 물어야 한다는 식이다. 이 조항이 없으면 당신의 앱은 ‘영원히 완성되지 않는 모나리자’가 된다.
체크리스트: 계약서 싸인 전, 단 5분만 점검하라
계약서에 싸인하려고 펜을 집었다면, 잠깐 멈춰라. 당신의 권리는 이미 바닥에 떨어져 있을지 모른다.
- RFP 첨부 여부: 계약서 뒷장에 ‘요구사항 정의서’가 공식 첨부되어 있는가? (구두 약속은 증거가 아니다).
- IP 귀속: ‘소스코드 및 모든 산출물의 지식재산권은 발주사(당신)에게 귀속된다’고 명시되어 있는가?
- 제3자 하청 금지: 개발사가 ‘브랜드 A’라고 해서 계약했는데, 알고 보니 ‘프리랜서 B’에게 재하청을 줄 수 있는 조항이 숨어 있지는 않은가?
- 검수 기준: ‘감성적으로 마음에 들 때’가 아니라, ‘사전에 정의된 모든 기능이 정상 작동할 때’라고 명시되어 있는가?
지금 당신이 해야 할 일은 단 하나다. 이 글을 저장하고, 당신의 법무팀 또는 동업자에게 보내라. 혹시 아직 앱 개발사를 찾고 있는 중이라면, 계약서를 가장 깐깐하게 요구하는 업체가 실력 있는 업체다.
요구사항 정의서 하나 없이 “일단 잘 부탁드립니다”라고 악수하는 순간, 당신은 비즈니스 전쟁터에서 총도 없이 뛰어드는 격이다. 현명하게 싸워라.
