앱 외주개발 배포 서명 인수인계: 키·인증서·계정을 나누는 5가지 기록
앱 외주개발 배포 서명 인수인계: 키·인증서·계정을 나누는 5가지 기록
외주사가 앱 MVP를 완성해도 “스토어에 올릴 수 있다”는 말만으로 배포 권한이 회사에 넘어온 것은 아닙니다. Android와 Apple 플랫폼에서 배포 서명에 관련된 자산은 같은 이름으로 묶기 쉽지만, 실제로는 비공개 키 또는 접근 수단, 공개 인증서, 플랫폼 계정과 역할, 앱 식별자·프로필, 그리고 이번 릴리스의 결과 기록이 서로 다릅니다. 인수 시점에 이들을 한 파일이나 한 사람의 계정으로 뭉뚱그리면, 다음 업데이트·외주사 교체·권한 회수 때 무엇을 확인해야 하는지 알기 어렵습니다.
먼저 답하면, 외주 앱 MVP 인수인계에서는 어떤 플랫폼의 어떤 앱인지, 비공개 서명 수단을 누가 보관·사용하는지, 공개 인증서나 식별 정보는 어디서 확인하는지, 플랫폼 계정의 역할은 누구에게 있는지, 다음 배포 때 누가 어떤 기록을 확인할지를 분리해 남기는 편이 좋습니다. 이 글은 특정 저장 위치·비밀번호·권한 설정을 지시하거나 보안·심사·출시 성공을 보장하지 않습니다. 회사가 실제 배포 책임을 인수하기 전에 대화를 시작할 기록 틀을 설명합니다.
공식 원문 확인일: 2026년 9월 16일 · 작성: 유인어스(UINUS)
왜 ‘서명 키를 받았다’만으로는 부족할까요?
Android 공식 문서는 Play App Signing에서 앱 서명 키와 업로드 키를 구분합니다. 업로드 키는 Play Console에 올릴 번들 또는 APK에 서명하는 데 쓰이고, 앱 서명 키는 배포용 APK 서명에 쓰입니다. 두 경우 모두 비공개 키는 공개해도 되는 인증서와 다릅니다. Android의 공개 인증서는 API 제공자 등록 등에서 공유할 수 있지만, 비공개 키 자체를 전달했다는 뜻은 아닙니다.
Apple의 Certificates, Identifiers & Profiles는 팀의 인증서·키·앱 ID·기능·기기·프로비저닝 프로필을 관리하는 영역입니다. App Store Connect용 프로필은 명시적 App ID와 배포 인증서에 연결될 수 있습니다. 따라서 iOS에서 “인증서가 있다”는 기록만으로는 어떤 앱 식별자, 어떤 팀, 어떤 배포 흐름인지 판단할 수 없습니다. 자동 서명을 쓰는지 수동으로 관리하는지도 실제 프로젝트와 계정에서 다시 확인해야 합니다.
이 차이는 개발 도구 지식의 문제가 아니라 사업자 인수 기록의 문제입니다. 외주사에게 개인 비밀번호나 비공개 키를 문서에 적어 달라고 요청하기보다, 회사가 통제하는 안전한 전달·보관 절차와 확인 가능한 공개 정보·책임자를 분리하는 편이 낫습니다.
인수인계 문서에 나눠 적을 5가지
기록 칸 | 확인 질문 | 문서에 남길 예시 |
|---|---|---|
대상 앱 | 어느 플랫폼·앱·배포 채널인가? | Android/iOS, 패키지명 또는 Bundle ID, 운영·테스트 구분 |
서명 수단 | 비공개 키 또는 사용 권한은 누가 통제하는가? | 회사 보관 절차, 접근 요청 책임자, 전달 완료 여부 |
공개 확인값 | 외부 연동에 필요한 공개 인증서·지문은 어디서 확인하는가? | 확인 화면·파일 위치, 확인일, 담당자 |
계정과 역할 | 플랫폼 콘솔과 개발자 팀에 누가 어떤 역할로 접근하는가? | 회사 소유 계정, 관리자·배포 담당 역할, 초대·회수 기록 |
다음 릴리스 | 다음 업데이트 때 무엇을 누가 확인하는가? | 대상 빌드, 서명 확인, 업로드·심사 제출 담당, 결과 링크 |
이 표는 플랫폼의 필수 양식이나 보안 인증 기준이 아닙니다. 각 앱의 기존 배포 방식과 계약 범위에 맞춰 빈칸을 채우는 작업용 기록입니다. 특히 테스트 앱과 운영 앱, Android와 iOS, 회사가 직접 관리하는 키와 플랫폼이 관리하는 키를 같은 칸에 합치지 마세요.
1. 먼저 대상 앱과 배포 채널을 특정하세요
“우리 앱”이라는 표현만으로는 인수 대상이 불명확합니다. Android라면 어떤 패키지명과 Play Console 앱인지, iOS라면 어떤 Bundle ID와 App Store Connect 앱인지처럼 플랫폼의 식별 단위를 기록합니다. 운영 출시본인지 내부 테스트용 빌드인지도 나눕니다. 동일한 기능이라도 테스트 채널과 운영 채널의 계정·서명 흐름이 다를 수 있기 때문입니다.
이 단계는 소스코드·도메인·클라우드 계정 인수와도 연결되지만, 그 목록만으로 배포 가능한 상태가 증명되지는 않습니다. 기존 소스코드·도메인·클라우드 계정 인수인계 글과 함께 보되, 이 문서에는 배포 서명 대상만 좁혀 적는 것이 좋습니다.
2. 비공개 서명 수단과 공개 인증서를 혼동하지 마세요
Android 문서에 따르면 Java keystore는 인증서와 비공개 키를 보관할 수 있으며, 앱 서명 키와 업로드 키는 구분될 수 있습니다. 공개 인증서와 지문은 API 제공자 등록에서 확인·공유할 수 있지만, 비공개 키를 대신하지 않습니다. 그러므로 인수 기록에는 실제 비공개 수단의 값이나 비밀번호를 쓰지 말고, 회사가 정한 안전한 보관 위치·접근 승인 절차·책임 역할이 확인됐는지를 남기세요.
외주사가 파일을 전달했다고 해서 그 파일이 현재 운영 앱의 다음 업데이트에 쓰이는 수단인지 자동으로 판단할 수는 없습니다. 플랫폼 콘솔의 공개 정보, 현재 빌드·배포 흐름, 외주사 설명을 대조해야 합니다. 분실·노출이 의심되는 경우에도 임의로 새 키를 만들거나 교체하지 말고, 사용 중인 플랫폼의 현재 공식 복구 절차와 담당 전문가의 판단을 확인하세요.
3. 플랫폼 계정은 개인 계정 공유가 아니라 역할 기록으로 보세요
Apple은 개발자 팀의 인증서·키·식별자·프로필을 관리하는 기능을 제공하고, App Store Connect 프로필 생성에는 Account Holder 또는 Admin 역할이 필요하다고 안내합니다. 이 사실은 모든 팀이 같은 수의 관리자를 둬야 한다는 뜻이 아닙니다. 대신 회사가 소유·회복할 수 있는 계정인지, 현재 외주사가 어떤 역할을 맡는지, 내부 담당자가 어떤 작업을 할 수 있는지 분리해 기록할 필요가 있습니다.
로그인 정보를 여러 사람이 공유하는 방식은 인수 완료를 증명하기도 어렵고, 이후 변경 책임도 흐릴 수 있습니다. 팀 규모에 맞춰 계정 소유자, 초대·승인 담당, 외주 종료 시 권한 회수 확인자를 적으세요. 일반적인 외주 착수 권한은 앱 외주개발 시작 전 접근권한에서, 배포 전 설명·지원 정보 대조는 앱 MVP 스토어 등록 전 점검에서 이어 확인할 수 있습니다.
4. 프로필·식별자·인증서의 ‘현재 상태’를 별도 확인하세요
Apple의 안내처럼 App Store Connect용 프로필은 명시적 App ID와 하나의 배포 인증서에 연결됩니다. 이 연결을 문서에서 “iOS 인증서 있음” 한 줄로 줄이면, 실제 앱 ID와 프로필의 관계를 나중에 다시 찾아야 합니다. 프로필이나 인증서의 실제 값은 공개 문서에 붙이지 말고, 확인한 콘솔 화면·확인일·권한이 있는 담당자·다음 검토 시점을 기록하면 됩니다.
Android도 Play App Signing 사용 여부에 따라 업로드 키와 앱 서명 키의 역할이 달라질 수 있습니다. 어떤 방식을 쓰는지 추측하지 말고, 현재 Play Console의 앱 서명 정보와 릴리스에 사용한 절차를 직접 읽어야 합니다. 이 글의 5칸이 모든 플랫폼 자산을 자동으로 복구하거나 앱 업데이트 가능성을 보장하지는 않습니다.
5. 인수 완료는 다음 릴리스 기록으로 다시 확인하세요
인수인계 회의가 끝난 날이 아니라, 다음 업데이트를 준비할 때 누가 대상 빌드를 확인하고 누가 업로드·제출·결과를 기록하는지까지 정해야 실제 운영 책임이 이어집니다. 배포 전에는 변경 대상·검토·검사·예외·다음 책임을 나누는 코드 병합 기준과, 출시 뒤 문제가 생길 때의 롤백 기준도 함께 연결하세요.
다음 릴리스용 체크는 짧게 시작할 수 있습니다. 대상 앱 식별자가 맞는지, 현재 책임자가 플랫폼 계정에서 필요한 상태를 읽을 수 있는지, 비공개 수단의 접근 절차가 회사 통제 아래인지, 공개 인증서·지문 확인 위치가 남아 있는지, 이번 빌드의 배포 결과 링크와 다음 확인자가 기록되는지 순서로 확인합니다. 막히는 항목은 ‘인수 완료’로 표시하지 말고 담당자와 복구 조건을 남기세요.
인수 전 짧게 점검하세요
Android/iOS와 운영·테스트 대상 앱의 식별자를 구분합니다.
비공개 서명 수단의 실제 값 대신 회사 보관·접근 절차와 책임자를 기록합니다.
공개 인증서·지문을 어디에서 확인할 수 있는지와 확인일을 남깁니다.
플랫폼 계정 소유와 역할, 외주 종료 뒤 회수 절차를 분리합니다.
다음 릴리스에서 확인할 빌드·담당자·결과 기록을 정합니다.
유인어스는 민간 사업 지원 서비스입니다. 이 글은 키 관리·보안·계약·개인정보·앱 심사·배포 또는 사업 성과를 보장하지 않습니다. 실제 앱의 서명·계정·인증서 변경은 사용 중인 플랫폼의 최신 공식 문서, 현 배포 방식, 계약과 권한 체계를 바탕으로 개발·보안·법무 등 필요한 담당자와 결정하세요.
자주 묻는 질문
외주사가 인증서 파일을 줬다면 인수는 끝난 건가요?
아닙니다. 인증서 파일은 비공개 서명 수단, 앱 식별자, 플랫폼 계정 역할, 현재 배포 흐름과 구분해 확인해야 합니다. 무엇이 확인됐고 무엇을 다음 릴리스에서 볼지 기록하세요.
Android의 앱 서명 키와 업로드 키는 같은 것인가요?
Play App Signing에서는 역할이 구분될 수 있습니다. 현재 앱이 어떤 방식을 쓰는지 Play Console의 정보와 공식 문서를 확인하고, 추측으로 키를 바꾸거나 새로 만들지 마세요.
Apple 프로필을 내려받으면 누구나 App Store Connect에 올릴 수 있나요?
프로필만으로 계정 역할과 실제 업로드 권한이 모두 확인되는 것은 아닙니다. 해당 App ID, 배포 인증서, 플랫폼 계정의 현재 역할과 사용 중인 서명 방식을 함께 확인해야 합니다.
문서에 비밀번호나 키 값을 적어야 하나요?
그럴 필요가 없습니다. 비공개 값 대신 회사가 정한 안전한 보관·접근 절차, 책임자, 확인 완료 여부를 기록하고 실제 전달은 승인된 보안 절차로 분리하세요.