일기 slecs

앱 배포 키를 프라이빗 저장소로 안전히 분리

목차

안드로이드 앱의 서명 파일(keystore, key.properties)을 공개 저장소에서 프라이빗 저장소로 옮기고, 공개 repo의 .gitignore를 정비하는 작업을 했다. 사소한 chore처럼 보이지만, 배포 보안과 팀의 온보딩 프로세스에 꽤 큰 영향을 주는 변화다.

안드로이드 앱이 배포되기까지

안드로이드 앱을 Google Play Store나 다른 배포 채널에 올리려면 앱을 서명(signing)해야 한다. 서명은 단순한 형식 검증이 아니라, 그 앱이 진짜 내가 배포한 앱임을 암호학적으로 증명하는 과정이다.

서명에 필요한 건 두 가지:
- keystore 파일: 비공개 키를 보관하는 저장소 (.jks 파일, 암호화됨)
- key.properties 파일: 키의 alias, 암호 등 메타정보 (빌드 시 keystore를 열 때 필요)

빌드 단계에서 Gradle이 이 두 파일을 읽어 앱을 서명한다. 당연하게도, 이 파일들이 없으면 배포용 빌드가 안 된다. 그런데 여기서 문제가 생겼다.

공개 저장소에 비밀키가 있으면 뭐가 문제인가

처음엔 편의를 위해 이 키 파일들을 공개 repo에 커밋했을 것 같다. 한두 명의 개발자가 빠르게 빌드하고 배포하려면, 팀원들이 모두 같은 keystore를 접근할 수 있어야 했기 때문이다. 하지만 공개 저장소라는 건, GitHub URL을 알면 누구나 read 접근이 가능하다는 뜻이다.

만약 악의적인 제3자가 우리 repo를 발견하고 keystore를 다운받는다면:
- 그들도 우리 앱 서명으로 가짜 앱을 만들 수 있다
- 사용자가 우리 앱이라고 믿고 다운받을 수 있다
- 유저 데이터 탈취, 악성코드 주입 등의 피해가 발생한다

한 번 비공개 키가 노출되면 회수 불가능하다. Play Store의 signing key를 비공개 키로 바꾸는 데 시간이 걸리고, 그 사이 가짜 앱이 배포될 수 있다. 따라서 "편하니까 공개 repo에 넣자"는 생각은 보안 재앙이다.

Private repo로 분리하기

이 문제를 해결하기 위해 키 파일들을 별도의 프라이팃 저장소로 옮겼다. 구조는 대략:

공개 저장소 (public-repo)
├── android/
├── src/
├── .gitignore  ← key.properties, *.jks 제외 규칙 추가
└── ...

프라이빗 저장소 (private-credentials-repo)
├── android/
│   ├── key.properties
│   ├── signing/
│   │   └── upload.jks
│   └── ...
└── ...

이제 배포 프로세스는:
1. CI/CD 환경에서 프라이빗 repo를 체크아웃한다 (접근 권한 있는 서버/계정만)
2. key.properties와 upload.jks를 빌드 디렉토리에 복사한다
3. Gradle이 이 파일들을 읽어 앱을 서명한다
4. 서명된 APK/AAB를 배포한다

개발자는 공개 repo만 clone 받아도 된다. 실제 배포는 자동화된 CI 환경에서만 일어나므로, 팀원들이 로컬에서 키 파일을 전혀 다룰 필요가 없다.

.gitignore의 역할

공개 repo의 .gitignore를 수정해서:

# Android signing files
android/key.properties
android/signing/*.jks

이렇게 명시적으로 제외했다. 혹시 누군가가 실수로 키 파일을 add 하려고 해도, git이 미리 warn을 줄 수 있다 (물론 git add -f로는 강제할 수 있지만, 적어도 "아, 이건 빼야 하는 파일이구나" 하는 신호를 준다).

팀에게 주는 영향

이 변화 덕분에:

  • 보안 개선: 공개 채널에서 비밀키 노출 위험이 제거됨
  • 배포 자동화 단순화: CI/CD 환경에서 프라이팃 repo 접근만 설정하면, 나머지는 자동
  • 팀원 온보딩 간소화: 새로운 개발자가 합류할 때 "이 키는 보관하지 마세요" 같은 복잡한 설명이 필요 없다. 공개 repo clone만 하면 로컬 개발 가능
  • 실수 방지: .gitignore 덕분에 누군가가 키를 커밋하려는 실수가 사전에 차단될 가능성이 높다

회고

이 작업은 "뭔가 고장난 걸 고치는" 성격은 아니지만, 배포 보안의 기본 원칙을 지키는 일이다. 초기에 편의를 위해 공개 repo에 키를 올린 것도, 그것을 지금 분리한 것도, 모두 팀의 성장 과정에서 배운 교훈이다.

특히 인상적이었던 건, 이런 변경이 팀 전체의 작업 흐름에는 거의 영향을 주지 않으면서도 보안 태세를 크게 개선한다는 점이다. 개발자는 여전히 git clone 후 개발을 시작할 수 있고, 배포는 여전히 자동화된 파이프라인에서 일어난다. 다만, 이제 그 파이프라인은 민감한 정보에 대한 접근 제어가 명확하게 설정되어 있다.

공개 저장소의 보안은 "누가 악의적일 것 같아?"가 아니라, "공개 저장소는 기본적으로 누구나 접근할 수 있다"는 가정 위에서 설계해야 한다. 특히 배포, 인증, 결제 같은 민감한 영역은 더욱 그렇다. 이번 작업이 그런 기본을 지키는 한 걸음이었다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.