안드로이드 앱 바이브 코딩의 4단계는 키스토어를 만들고 앱에 서명을 연결하는 일입니다. 키스토어는 “이 앱을 만든 사람이 나”라는 사실을 확인하는 도장 파일이라고 생각하면 쉽습니다. 앱을 처음 출시할 때 사용한 도장을 다음 업데이트에도 이어서 사용해야 합니다. 이 글에서는 릴리즈용과 개발용 키스토어를 안전한 폴더에 만들고, AI에게 앱 서명 설정을 맡긴 뒤, 실제로 올바른 키가 사용되었는지 확인하는 순서를 설명합니다.
이 글은 키스토어를 처음 만드는 분을 대상으로 합니다. keytool이나 Gradle을 잘 몰라도 괜찮습니다. 필요한 정보를 준비하고 AI에게 작업을 맡긴 뒤 결과를 확인하는 방법에 집중합니다. 단, 키스토어와 비밀번호는 앱의 업데이트를 계속할 수 있는 중요한 자료이므로 AI의 완료 보고만 믿지 말고 파일 위치와 백업을 직접 확인해야 합니다. 실제 출시 전에는 Android 공식 앱 서명 문서와 Play Console 안내도 다시 확인합니다.
먼저 네 가지 말을 쉽게 구분한다
키스토어는 도장을 보관하는 파일입니다. 키 별칭은 그 파일 안에서 사용할 도장의 이름입니다. 앱 서명은 빌드한 앱에 그 도장을 찍는 과정입니다. SHA-1·SHA-256 지문은 도장을 구분하기 위한 확인 번호입니다. Firebase나 Google 로그인 설정에서 이 확인 번호를 요구할 수 있습니다. 지문은 외부 서비스에 등록할 수 있지만 키스토어 파일과 비밀번호는 다른 사람에게 보내면 안 됩니다.
사용자의 휴대폰은 새 버전이 정말 같은 개발자가 만든 앱인지 서명을 보고 확인합니다. 그래서 처음 출시한 앱의 서명과 이어지지 않는 새 빌드는 기존 앱 위에 업데이트할 수 없습니다. 키스토어를 잃어버리면 매우 곤란한 이유입니다. Google Play의 Play App Signing을 사용하는 앱은 개발자가 가진 업로드 키를 잃었을 때 재설정을 요청할 수 있지만, 모든 상황에서 복구되는 것은 아닙니다. 처음부터 안전하게 보관하고 백업하는 것이 가장 좋습니다.
Google Play를 사용하면 키가 두 종류일 수 있다
Google Play에 앱을 올릴 때는 업로드 키와 앱 서명 키라는 말이 나옵니다. 개발자는 업로드 키로 “이 파일은 내가 올린 것”임을 보여 줍니다. Google Play는 앱 서명 키로 사용자의 휴대폰에 전달할 앱에 최종 서명을 합니다. 처음에는 두 이름이 어렵게 느껴지지만, 개발자가 보관해 업로드할 때 쓰는 키와 Play가 실제 배포에 쓰는 키라고 기억하면 충분합니다.
Firebase나 Google 로그인에 지문을 등록할 때는 서비스 안내가 어느 지문을 요구하는지 확인합니다. Play에서 받은 앱을 위한 설정이라면 Play Console에 표시된 앱 서명 지문이 필요한 경우가 많고, 개발 중인 디버그 앱에는 디버그 지문이 필요할 수 있습니다. 잘 모르겠다면 AI에게 현재 사용 목적을 알려 주고 “어느 화면의 어떤 지문을 등록해야 하는지 단계별로 설명해 달라”고 요청하세요.
키스토어와 비밀번호 파일은 프로젝트 밖에 둔다
릴리즈 키스토어, 디버그 키스토어, 키스토어 비밀번호, 키 별칭, 키 비밀번호, 서명용 properties 파일은 Git 저장소에 올리지 않습니다. 프로젝트 디렉터리와 형제 관계인 keystores 폴더에 두면 재귀적으로 프로젝트를 커밋할 때 포함될 가능성이 줄어듭니다. 폴더 분리는 보안의 전부가 아니라 첫 번째 안전장치입니다. 별도의 암호화 백업과 접근 통제, 복구 연습도 필요합니다.
workspace/
├── app-project/
└── keystores/
├── com.siamakerlab.app_name-release.keystore
├── com.siamakerlab.app_name-release.properties
├── com.siamakerlab.app_name.debug.keystore
└── com.siamakerlab.app_name.debug.properties
앱이 여러 개라면 파일명 앞에 패키지명을 붙여 어느 앱의 키인지 쉽게 구분합니다. 비밀번호를 적지 않은 관리 메모에는 앱 이름, 패키지명, 생성일, 릴리즈용인지 디버그용인지, 백업 위치만 기록해도 도움이 됩니다. 키스토어는 한 곳에만 두지 말고 암호화된 저장소 두 곳 이상에 백업합니다. 같은 클라우드 계정 안에 사본만 여러 개 만드는 것은 계정을 잃었을 때 함께 접근하지 못할 수 있으므로 충분한 백업이 아닙니다.
생성 전에 필요한 정보를 먼저 확인한다
AI가 임의의 정보로 키를 만들게 하지 말고 먼저 필요한 값을 목록으로 받습니다. 보통 키 이름, 키스토어 비밀번호, 키 비밀번호, 유효기간, 이름 또는 회사명, 도시, 지역, 두 자리 국가 코드가 필요합니다. 모든 항목을 공개 프로필처럼 자세히 작성할 필요는 없습니다. 개인 앱인지 회사 앱인지에 맞춰 일관된 값을 정하고, 유효기간은 앱을 운영할 기간보다 충분히 길게 잡습니다.
필요 정보 확인 프롬프트
현재 앱의 릴리즈 및 디버그 키스토어를 생성하려면 어떤 정보가 필요한지 정리해 주세요.
키 별칭, 유효기간, 비밀번호, 인증서의 이름, 조직, 조직 단위,
도시, 지역, 국가 코드 등을 포함해 주세요.
입력받은 비밀번호나 비밀정보를 채팅 응답, 로그, Git,
명령 기록, 소스 코드에 그대로 기록하지 마세요.
값이 필요한 경우 안전한 로컬 입력 또는 비밀 관리 수단을 제안하고,
실제 값을 출력하지 않은 채 존재 여부만 검증하세요.실제 비밀번호를 AI 채팅창에 붙여 넣지 마세요. 화면에 글자가 보이지 않는 로컬 비밀번호 입력 방법을 사용하고, AI에게도 비밀번호를 답변이나 로그에 다시 표시하지 말라고 요청합니다. 생성이 끝난 뒤에는 비밀번호 파일이 프로젝트 폴더가 아닌 keystores 폴더에 있는지 직접 확인합니다.
릴리즈와 디버그 키스토어를 생성하고 Gradle에 연결한다
키스토어 생성 및 서명 설정 프롬프트
제공한 정보를 사용하여 릴리즈 및 디버그 키스토어를 생성해 주세요.
키스토어 파일은 프로젝트 내부가 아닌 ../keystores 폴더에 저장해 주세요.
릴리즈 키스토어:
com.siamakerlab.app_name-release.keystore
릴리즈 설정 파일:
com.siamakerlab.app_name-release.properties
디버그 키스토어:
com.siamakerlab.app_name.debug.keystore
디버그 설정 파일:
com.siamakerlab.app_name.debug.properties
Gradle은 프로젝트 외부의 properties 파일을 읽어 서명 설정을 구성하세요.
경로, 별칭, 키스토어 비밀번호, 키 비밀번호를 build.gradle.kts에 하드코딩하지 마세요.
파일이나 필수 속성이 없으면 원인을 알 수 있는 오류로 빌드를 중단하세요.
릴리즈 빌드가 기본 Android 디버그 키로 서명되는 폴백은 허용하지 마세요.
비밀 값은 응답과 로그에 출력하지 마세요.서명 설정 파일에는 키스토어 위치와 키 이름, 비밀번호가 들어갑니다. 앱의 빌드 설정은 이 외부 파일을 읽어 서명하도록 구성합니다. 파일이 없거나 값이 빠졌다면 빌드를 멈추고 “어떤 파일이 없다”는 오류를 보여 줘야 합니다. 릴리즈용 키를 찾지 못했을 때 임시로 디버그 키를 사용하는 방식은 허용하지 않습니다. 실수로 잘못된 키로 출시 파일을 만들 수 있기 때문입니다.
초보자가 이 설정 코드를 직접 작성할 필요는 없습니다. 위 프롬프트로 AI에게 맡긴 뒤 다음 세 가지만 확인하면 됩니다. 첫째, build.gradle.kts에 실제 비밀번호가 보이지 않아야 합니다. 둘째, 외부 properties 파일을 잠시 다른 이름으로 바꾸면 릴리즈 빌드가 명확한 오류와 함께 멈춰야 합니다. 셋째, 파일을 되돌린 뒤 릴리즈 빌드가 성공해야 합니다. 이 세 가지로 비밀 값 분리와 잘못된 서명 방지 설정을 대부분 확인할 수 있습니다.
프로젝트 전용 디버그 키스토어를 유지하는 이유
Android Studio와 Android Gradle Plugin은 보통 사용자 홈의 기본 디버그 키스토어를 사용합니다. 이 파일은 개발 장비 변경, 운영체제 재설치, 개발 서버 교체, Docker·CI 환경 변경, 기본 파일 삭제, 여러 개발자의 빌드 환경 차이로 바뀔 수 있습니다. 서명 인증서가 달라지면 기존에 설치된 디버그 앱 위에 새 빌드를 업데이트할 수 없고, Firebase·OAuth·Google API에 등록한 SHA-1과 SHA-256 지문도 다시 구성해야 할 수 있습니다.
디버그 빌드에도 프로젝트 전용 디버그 키스토어를 적용해 주세요.
개발 장비나 빌드 서버가 변경되어도 승인된 동일 키스토어를 사용하도록 구성하세요.
기존 디버그 앱 업데이트와 SHA-1·SHA-256 지문을 사용하는
외부 서비스 설정이 유지되는지 검증하세요.
키스토어나 설정이 없으면 임의로 새 키를 생성하지 말고 빌드를 중단하세요.디버그 키도 Git에 넣지 않는 원칙은 같습니다. 팀과 CI가 필요로 한다면 접근 권한이 있는 비밀 저장소에서 안전하게 주입합니다. 릴리즈 키와 디버그 키는 반드시 분리합니다. 디버그 키가 유출되거나 여러 개발자에게 배포되더라도 릴리즈 서명의 안전성까지 영향을 받지 않도록 경계를 유지해야 합니다.
Git 제외 규칙은 프로젝트 밖 파일에도 적용한다
*.keystore
*.jks
**/keystores/
**/*-release.properties
**/*.debug.properties
local.propertiesCode language: JavaScript (javascript)외부 폴더에 있으니 안전하다고 생각하지 말고 방어적으로 제외 규칙을 둡니다. 파일을 만들기 전과 커밋 전에 git status --ignored와 git check-ignore -v 파일경로로 규칙이 실제 적용되는지 확인합니다. 이미 Git이 추적하는 파일은 .gitignore를 추가해도 자동으로 사라지지 않습니다. 비밀이 한 번이라도 원격 저장소에 올라갔다면 파일 삭제만으로 끝내지 말고 키와 비밀번호를 폐기·교체하고 저장소 기록과 로그 노출 범위를 평가해야 합니다.
지문과 실제 빌드 결과를 확인한다
keytool -list -v
-keystore ../keystores/com.siamakerlab.app_name-release.keystore
./gradlew signingReport
./gradlew assembleDebug
./gradlew bundleReleaseCode language: PHP (php)keytool -list 명령은 키스토어의 이름, 유효기간, SHA-1·SHA-256 지문을 보여 줍니다. signingReport는 앱의 디버그 버전과 릴리즈 버전이 어떤 지문을 사용하는지 확인할 때 도움이 됩니다. 두 결과를 AI에게 비교하게 하되 비밀번호는 보여 주지 않습니다. 디버그와 릴리즈 지문이 서로 다르고, 다시 실행해도 같은 값이 나오는지 확인합니다.
마지막에는 생성된 AAB 또는 APK의 인증서를 다시 확인하고 설치 테스트를 수행합니다. 기존 디버그 앱이 있다면 데이터 삭제 없이 새 디버그 빌드를 업데이트 설치해 서명 연속성을 확인합니다. Play App Signing을 사용하는 릴리즈는 로컬 업로드 인증서와 Play 배포 앱의 앱 서명 인증서가 다를 수 있음을 테스트 문서에 기록합니다.
AdMob과 클라우드 설정도 앱별 외부 properties로 정리한다
AdMob을 사용한다면 com.siamakerlab.app_name-admob.properties처럼 패키지명 접두사를 붙인 설정 파일을 같은 외부 폴더 체계에서 관리할 수 있습니다. Google Cloud, Dropbox, Box, Google Drive 등 외부 서비스의 클라이언트 ID와 앱 식별자도 서비스별 properties 파일로 나누면 프로젝트가 많아져도 어느 값이 어느 앱에 속하는지 찾기 쉽습니다. 개발·스테이징·운영 값이 다르면 파일명이나 하위 디렉터리에서 환경도 구분합니다.
그러나 Git에 넣지 않았다고 앱에 포함되는 값이 비밀이 되는 것은 아닙니다. Gradle이 값을 BuildConfig, 리소스, 매니페스트에 넣으면 최종 APK나 AAB를 분석해 추출할 수 있습니다. AdMob 앱 ID처럼 클라이언트 앱에 포함되는 것을 전제로 한 식별값, OAuth 클라이언트 ID, 제한된 Firebase API 키와 진짜 관리자 비밀을 구분해야 합니다. AdMob 공식 설정도 앱 ID를 매니페스트에 넣도록 안내합니다.
앱에 넣어도 되는 설정과 넣으면 안 되는 비밀을 나눈다
Firebase 공식 API 키 문서는 Firebase용 API 키가 프로젝트를 식별하는 공개 값이며 데이터 권한은 Security Rules와 App Check로 보호해야 한다고 설명합니다. Supabase API 키 문서도 모바일 앱에는 publishable 키를 사용하고 RLS로 최소 권한을 적용하며, RLS를 우회하는 secret 또는 service-role 키는 백엔드에만 두라고 안내합니다. 이름에 “key”가 붙었다는 이유만으로 모두 같은 보안 등급으로 취급해서는 안 됩니다.
결제 비밀키, 관리자 계정, 데이터베이스 비밀번호, 관리자 권한이 있는 API 키와 개인 토큰은 앱에 넣으면 안 됩니다. 외부 properties 파일에서 읽더라도 앱을 만들 때 최종 파일 안에 들어가면 다른 사람이 찾아낼 수 있습니다. 이런 비밀이 필요한 기능은 앱이 직접 외부 서비스에 요청하지 않고, 우리가 관리하는 백엔드 또는 중간 서버를 거쳐 처리하도록 만듭니다.
시아메이커랩에서는 요구사항에 따라 Firebase나 Supabase 같은 관리형 서비스를 사용하고, 더 강한 통제와 비밀 처리가 필요한 경우 작업실 서버에 백엔드를 구성합니다. 중요한 것은 특정 서비스를 선택하는 일이 아니라 신뢰 경계를 먼저 정하는 것입니다. 모바일 앱은 공개 환경, 서버는 통제 가능한 환경으로 보고 요청 인증, 사용자 권한, 속도 제한, 감사 로그, 키 교체 절차를 함께 설계합니다.
키스토어는 만든 날 바로 백업한다
키스토어를 만든 직후 원본을 한 곳에만 두면 아직 작업이 끝난 것이 아닙니다. 암호화된 오프라인 백업과 접근 통제된 보조 백업을 만들고, 비밀번호는 키스토어와 다른 경로에 보관합니다. Dropbox, Box, Google Drive 같은 동기화 저장소를 사용할 수 있지만 계정 탈취, 동기화 삭제, 랜섬웨어가 모든 사본에 전파될 위험을 고려합니다. 계정 다중 인증, 복구 코드, 장치 암호화와 파일 자체 암호화를 함께 사용합니다.
백업 파일이 보인다고 안심하지 말고 실제로 열 수 있는지도 확인합니다. 다른 임시 폴더에 백업본을 복사해 지문을 확인하고 원본과 같은 값인지 비교합니다. 비밀번호를 잊지 않았는지도 안전한 장소에서 확인합니다. 이 테스트로 파일이 깨졌거나 비밀번호 기록이 잘못된 문제를 출시 전에 발견할 수 있습니다.
완료 체크리스트
- 최종 applicationId와 릴리즈·디버그 키 용도를 확정했는가
- 키스토어와 properties가 프로젝트 외부에 있는가
- 릴리즈와 디버그가 서로 다른 전용 키를 사용하는가
- 비밀번호와 별칭을 코드·채팅·로그에 노출하지 않았는가
- 파일과 필수 속성이 없을 때 빌드가 명확히 실패하는가
- 릴리즈 빌드의 디버그 키 폴백이 없는가
- .gitignore와 실제 Git 추적 상태를 확인했는가
- SHA-1·SHA-256과 유효기간을 기록했는가
- Play App Signing의 앱 서명 키와 업로드 키를 구분했는가
- Debug APK와 Release AAB가 의도한 인증서로 서명되는가
- 암호화 백업을 두 곳 이상 만들고 복구를 시험했는가
- 앱에 포함되는 공개 설정과 백엔드 비밀을 분리했는가
마무리: 키를 만드는 것보다 수명주기를 운영하는 일이 중요하다
키스토어 생성은 한 번의 keytool 명령으로 끝나지만 앱 서명은 제품 수명 전체를 따라가는 운영 체계입니다. 프로젝트 밖 보관, 비밀 값 분리, 명시적인 Gradle 실패, 전용 디버그 인증서, Play App Signing의 키 역할 구분, 백업과 복구 검증이 함께 있어야 안전합니다. 공개 인증서 지문은 필요한 서비스에 등록할 수 있지만 개인 키와 비밀번호는 저장소와 채팅에 남기지 않습니다.
다음 개발 단계로 넘어가기 전에 깨끗한 환경에서 디버그 앱 업데이트 설치와 릴리즈 AAB 생성을 재현해 보세요. 그 결과와 인증서 지문, Play Console 등록 상태를 비밀이 아닌 운영 문서에 남기면 개발 머신이나 CI가 바뀌어도 같은 서명 체계를 복구할 수 있습니다. 진짜 비밀이 필요한 외부 API는 앱 속 properties에 숨기려 하지 말고 백엔드 또는 프록시 경계로 옮기는 것이 안전한 출발점입니다.
답글 남기기