남에게 맡겨도 앱의 주인은 내가 되어야 합니다
창업자가 첫날부터 직접 소유해야 할 계정, 식별자, 인증서, 데이터 체크리스트입니다.
On This Page
외주 개발자는 앱을 만들 수 있습니다. 하지만 제품의 주인이 되어서는 안 됩니다.
모바일 프로젝트에는 스토어 계정, 서명 인증서, 앱 식별자, 도메인, 백엔드, 분석, 결제, 소스 코드처럼 오래가는 자산이 많습니다. 하나만 잃어도 출시가 늦어지고, 여러 개를 잃으면 제품 이전 자체가 어려워집니다.
회사가 자산을 소유하고, 사람은 역할을 받으며, 외주사는 기간이 정해진 접근 권한을 받습니다. 누구에게도 창업자 비밀번호를 줄 필요는 없습니다.
소유권을 세 층으로 나누기
스토어, 결제, 도메인, 공급업체 기록에 적힌 회사입니다.
접근을 복구하고 역할을 바꿀 수 있는 내부 신뢰 인원 최소 두 명입니다.
필요한 권한과 기간만 받은 외주사 또는 개발자입니다.
회사가 직접 소유할 목록
다음 항목은 창업자 회사가 통제하는 계정으로 만드세요.
- Apple Developer Program 계정
- Google Play Console 계정
- iOS 번들 ID와 Android 패키지 이름
- 인증서, 프로비저닝 프로필, 서명 키
- 도메인과 DNS 계정
- 백엔드와 데이터베이스 프로젝트
- 분석과 크래시 추적 계정
- 소스 저장소와 CI/CD 접근 권한
- Stripe와 스토어 결제 계정
외주사에는 필요한 최소 역할만 초대하고 창업자 비밀번호를 공유하지 마세요.
| 자산 | 회사가 통제할 것 | 외주사에 보통 필요한 것 |
|---|---|---|
| 스토어 계정 | 법인, 계약, 결제, 복구 | 앱 관리자 또는 개발자 역할 |
| 소스 저장소 | 조직 소유권, 관리자, 백업 | 담당 저장소 쓰기 권한 |
| 클라우드/백엔드 | 결제, 운영 소유권, 감사 접근 | 개발 권한, 운영 변경은 리뷰 경유 |
| 도메인/DNS | 등록기관, 복구 메일, 갱신 결제 | 특정 DNS 변경 또는 위임 영역 |
| 결제 | 법인, 은행, 세금, 분쟁 | 개발·샌드박스 권한, 은행 설정은 거의 불필요 |
| 서명 | 안전한 보관과 복구 절차 | CI 서명 또는 제한된 인증서 접근 |
“Apple 계정은 저희가 만들어드립니다”, “소스는 저희 GitHub에 둡니다”, “운영은 저희 Firebase를 씁니다”, “나중에 모두 이전합니다.” 어떤 서비스는 이전이 가능하고 어떤 서비스는 까다롭지만, 어느 쪽이든 위험합니다. 처음부터 깨끗하게 시작하세요.
식별자는 특히 신중하게
번들 ID와 패키지 이름은 새 버전을 기존 스토어 앱과 연결합니다. 바꾸면 대개 새로운 앱으로 취급되어 기존 설치, 리뷰, 이력과 끊어집니다.
회사 이름을 기반으로 정하고 문서화하세요. 운영 앱 식별자에 외주사 브랜드가 들어가면 안 됩니다.
암호학자가 되지 않고 서명 이해하기
서명은 업데이트가 허가된 배포자에게서 왔음을 증명합니다. 스토어 앱을 잠긴 우편함, 서명 신원을 열쇠라고 생각하세요. 열쇠 보호뿐 아니라 빌드 시스템이 열쇠를 어떻게 쓰는지도 문서화해야 합니다.
- 복구 이메일과 전화번호는 회사가 통제합니다.
- 채팅으로 파일을 보내기보다 감사 가능한 CI 인증 정보를 사용합니다.
- 개발, 스테이징, 운영 환경을 분리합니다.
- 만료일과 갱신 담당자를 기록합니다.
- 두 번째 내부 관리자도 출시할 수 있는지 시험합니다.
계정의 생애주기 설계하기
가입은 시작일 뿐입니다. 다음 흐름을 정하세요.
- 가입과 이메일 인증
- 비밀번호 재설정과 소셜 로그인 복구
- 세션 만료와 강제 로그아웃
- 구독 취소와 구매 복원
- 앱 안에서 계정 삭제
- 데이터 내보내기와 삭제
사용자가 계정을 만들 수 있다면 Apple은 앱 안에서 삭제를 시작할 수 있기를 요구합니다. 고객센터의 수동 작업이 아니라 제품과 백엔드 흐름으로 만드세요.
인수인계 패킷 만들기
서비스마다 소유자, 관리자 주소, 복구 연락처, 결제 담당자, 식별자, 갱신일을 안전하게 기록하세요. 아키텍처 설명, 출시 절차, 환경 이름, 외부 SDK 목록도 포함합니다.
비밀번호와 원본 비밀키는 저장소나 문서에 넣지 말고 비밀번호 관리자와 시크릿 저장소를 사용하세요.
외주 종료 테스트
현재 외주사가 내일 사라져도 새 팀이 앱을 빌드하고, 서명하고, 심사에 내고, 운영하고, 결제받을 수 있습니까?
아니라면 기능 추가보다 소유권부터 고치세요.
실전 접근 권한 검토
출시 때, 분기마다, 외주 인력이 나갈 때 다음을 확인하세요.
- 내부 관리자 두 명이 모든 중요 계정에 로그인하고 복구할 수 있다.
- 회사 결제와 복구 연락처가 최신이다.
- 퇴사자와 쓰지 않는 토큰을 제거했다.
- 운영 비밀키마다 담당자와 교체일이 있다.
- 현재 소스로 스토어 빌드를 만들 수 있다.
- 식별자, 인증서, 출시 순서가 문서화되어 있다.
- 백업을 설정만 한 것이 아니라 실제 복원해봤다.
상황: 금요일에 외주사가 사라졌다
월요일에 운영 로그인 오류가 발생합니다. 건강한 소유권 구조라면 새 개발자를 초대하고, 빌드를 재현하고, 크래시 기록을 보고, 백엔드를 수정하고, 앱 업데이트에 서명하고, 스토어 심사자에게 답할 수 있습니다. 혼란을 완전히 없애는 것이 아니라 통제권 상실이 마비로 번지는 것을 막는 것이 목표입니다.
핵심 정리
소유권도 아키텍처입니다. 회사가 통제하는 계정과 문서화된 접근 경로가 있어야 외주가 영구 의존성이 아닌 교체 가능한 서비스가 됩니다.