앱 매매 계약서에는 무엇이 들어갈까요? 판매자를 위한 체크리스트

이 글은 법률 자문이 아닙니다. 저는 앱을 사는 사람이지 변호사가 아닙니다. 이 페이지는 앱 매매 계약서에 보통 어떤 내용이 들어가는지 설명해, 무엇을 살펴봐야 할지 알 수 있게 하려는 것입니다. 법은 나라마다 다르고, 적절한 조건은 거래마다 다릅니다. 어떤 계약서든 서명하기 전에 해당 관할 지역의 변호사에게 검토를 받으세요.

계약서 단계에 이르면 보통 가격은 이미 합의했고 매수자는 실사를 마친 상태입니다(앱 실사 체크리스트 참고). 계약서는 그 구두 합의를 누가 무엇을 언제 받는지, 문제가 생기면 어떻게 되는지를 적은 서면 목록으로 바꿉니다. 판매자 관점에서 계약서에 보통 들어가는 내용은 다음과 같습니다.

앱 매각에서는 무엇을 파나요?

매수자가 판매자 없이 앱을 운영하는 데 필요한 모든 것을 항목별로 나열하고, 팔 생각이 없던 것은 넣지 않습니다. 일반적인 자산 목록에는 다음이 들어갑니다.

• 앱 자체와 스토어 페이지(App Store 및/또는 Google Play 항목으로, 각 스토어의 공식 이전 기능으로 옮겨집니다).
• 소스 코드, 디자인 파일, 빌드 스크립트, 문서.
• 도메인과 웹사이트.
• 상표와 앱 이름, 로고 및 기타 브랜드 자산(등록 여부와 관계없이).
• 계정과 서비스: 백엔드와 클라우드 프로젝트, RevenueCat, 애널리틱스, 크래시 리포팅, 광고 네트워크, 고객 지원 메일함, 소셜 계정.
• 데이터: 사용자 데이터와 이메일 목록(개인정보 처리방침과 현지 법이 이전을 허용하는 경우).
• 제외되는 것: 판매자의 개발자 계정, 다른 앱, 판매자가 계속 쓰는 공용 코드 라이브러리, 거래 완료일 이전에 발생한 매출.

코드나 서비스를 다른 앱과 함께 쓰고 있다면 여기에 밝히고 어떻게 나눌지 합의하세요. 분쟁은 모호한 자산 목록에서 시작됩니다.

가격, 대금 지급, 에스크로는 계약서에 어떻게 적나요?

계약서에는 가격, 통화, 어떤 수수료를 누가 내는지, 그리고 돈과 자산이 어떤 순서로 움직이는지를 적습니다. 대부분의 거래에서는 에스크로를 씁니다. 매수자가 대금을 넣고, 판매자가 이전하고, 매수자가 확인하면, 에스크로가 대금을 지급합니다. 이 조항은 보통 다음을 다룹니다.

• 매수 가격, 그리고 그중 일부를 나중에 지급하는지 여부.
• 에스크로 업체와 에스크로 수수료를 누가 내는지. 진행 방식과 Escrow.com 수수료는 앱 매각 에스크로를 참고하세요.
• 검수 기간: 대금이 지급되기 전에 매수자가 수령을 확인할 수 있는 기간.
• 거래 완료일 전후의 매출을 어떻게 나누는지. App Store에서는 Apple이 이전일을 기준으로 양쪽에 판매와 지급을 보고하므로, 계약서도 이에 맞춰야 합니다.

마켓플레이스나 브로커를 통해 판다면 그 커미션도 판매자 몫에서 빠집니다. Flippa 수수료와 Empire Flippers, Acquire.com 비교에서 비교해 보세요.

계약서에서 이전은 어떻게 다루나요?

플랫폼별 이전 단계와 기한을 나열해, 나중에 "인도"가 무엇을 뜻하는지 다투지 않게 합니다.

• App Store: 판매자 측 계정 소유자가 매수자의 Apple 계정과 팀 ID로 App Store Connect에서 이전을 시작하고, 매수자가 수락합니다. 거래를 마무리하기 전에 Apple의 이전 기준(심사 중인 항목 없음, TestFlight 꺼짐, 중복 제품 ID 없음)을 충족해야 합니다. 자세한 내용: App Store 앱 이전.
• Google Play: 판매자가 Play Console에서 두 계정의 등록 거래 ID를 넣어 요청을 보내고, 매수자가 승인합니다. Google의 이전 페이지에 따르면 인앱 구매가 있는 앱은 매수자가 다시 게시할 때까지 게시가 취소됩니다. 자세한 내용: Google Play 앱 이전.
• 그 밖의 모든 것: 코드 저장소, 도메인, 제3자 서비스. 각각 날짜와 누가 무엇을 하는지를 적습니다.
• 인도: 무엇을 완료로 보는지, 그리고 어떤 단계가 실패하면(예: 매수자 계정이 스토어 기준을 충족하지 못하는 경우) 어떻게 되는지.

인계 지원은 어디까지 해야 하나요?

계약서에 적힌 만큼입니다. 그러니 구체적으로 적혀 있는지 확인하세요. 기한 없는 "합리적인 협조" 같은 문구는 몇 달간의 무급 노동이 될 수 있습니다. 다음을 명확히 정하세요.

• 범위: 질문에 답하기, 코드베이스 설명하기, 서비스 이전 돕기. 새 기능 개발은 아닙니다.
• 기간: 거래 완료 후 정해진 주 수.
• 소통 채널과 투입 시간: 예를 들어 이메일로만, 시간 상한을 두고.
• 유료 추가 지원: 매수자가 더 원하면 어떤 요율로 할지.

숫자와 소유권에 대해 무엇을 약속하나요?

진술·보증은 판매자가 앱에 관해 하는 말로, 매수자는 이를 믿고 거래합니다. 사실이 아닌 것으로 드러나면 책임이 생길 수 있습니다. 대표적인 것은 다음과 같습니다.

• 공유한 매출, 비용, 트래픽 수치가 정확하다.
• 판매하는 앱, 코드, 이름, 자산을 소유하고 있으며 팔 권리가 있다.
• 제3자 코드, 폰트, 이미지, 사운드는 적법하게 라이선스를 받았다.
• 밝히지 않은 스토어 경고, 분쟁, 청구가 없다.
• 판매자가 아는 한 앱은 스토어 정책과 개인정보 규정을 준수한다.

이 부분은 꼼꼼히 읽으세요. 알고 있는 문제는 서면으로 밝히고("공개 목록", disclosure schedule), 보증 기간을 제한하고 책임 한도를 두는 방법은 변호사에게 물어보세요. 바로 여기서 실사가 빛을 발합니다. 미리 밝힌 내용은 나중에 이를 근거로 청구하기가 훨씬 어렵습니다.

경업금지 약정에 서명해야 하나요?

대개는 그렇습니다. 매수자는 판매자가 다음 달에 똑같은 앱을 내놓지 않으리라는 확신을 원합니다. 확인할 점은 다음과 같습니다.

• 범위: 실제로 경쟁하는 앱에만 적용되어야 하며, 판매자의 커리어 전체가 대상이 되어서는 안 됩니다.
• 기간과 지역: 기간이 제한되어야 합니다.
• 유인 금지: 앱의 사용자나 파트너에게 연락해 다른 곳으로 옮기게 하지 않겠다는 약속.
• 강제 가능성은 나라마다 다릅니다. 변호사에게 읽혀야 할 이유가 하나 더 있는 셈입니다.

언아웃과 분할 지급에는 어떤 위험이 있나요?

앱은 넘겼는데 대금 일부를 기다려야 하므로, 위험은 판매자가 집니다. 언아웃(earn-out)은 가격 일부가 앱의 향후 실적에 따라 달라지는데, 그 실적은 이제 매수자가 좌우합니다. 분할 지급은 매수자가 이미 자산을 소유한 뒤에도 판매자에게 돈을 빚진 상태가 됩니다. 어느 쪽이든 받아들인다면 다음을 챙기세요.

• 가능한 한 많은 금액을 거래 완료 시점에 에스크로를 통해 받으세요.
• 언아웃을 정확히 어떻게 측정하는지, 누가 보고하는지, 판매자가 숫자를 볼 권리를 정하세요.
• 미지급 금액에 대한 담보와, 지급이 누락되면 어떻게 되는지를 합의하세요.

에스크로를 통한 전액 현금 거래가 판매자에게 가장 단순하고 안전한 구조입니다.

비밀 유지는 어떻게 되나요?

대부분의 계약서는 가격과 조건을 비밀로 하고, 어느 쪽이든 매각 사실을 알릴 수 있는지를 정합니다. 실사 전에 NDA를 체결했다면 계약서와 어떻게 맞물리는지 확인하세요. 포트폴리오나 LinkedIn 등에 매각 사실을 공개적으로 언급해도 되는지도 미리 합의하세요. 매물 등록부터 다니는 회사까지 더 넓은 관점은 앱을 조용히 파는 방법에 있습니다.

앱을 팔려면 변호사가 필요한가요?

아주 작은 전액 현금 매각이 아니라면 변호사 검토는 비용만큼의 값을 합니다. 대금 후불, 경업금지, 폭넓은 진술·보증이 들어간 거래라면 꼭 권합니다. 소프트웨어나 온라인 사업 매각을 다뤄 본 변호사라면 계약서를 빠르게 검토하고, 해당 나라에서 이례적인 조건을 짚어 줄 수 있습니다. 제안을 비교할 때 이 검토 비용도 예산에 넣으세요.

누구에게 팔든, 서명 전에 판매자 측 변호사에게 계약서 검토를 받는 것은 잘 쓴 돈입니다. 저는 주로 iOS 앱을 인수하고, 잘 맞는다면 Android 앱도 검토합니다. 게임, SaaS, 웹 전용 제품은 인수하지 않습니다. 거래 규모는 $10K부터 $1M+까지이며, 가장 잘 맞는 앱은 출시 후 최소 약 6개월이 지났고 꾸준한 매출이 있는 앱입니다. 첫 숫자 공유부터 인계까지 전체 과정은 앱 파는 방법을 참고하세요.