RSS

Expo EAS 운영 자격 증명, 무엇을 어떻게 백업할까

모바일 앱글: , Duolabs8분 읽기app-signingblogexpo-easmobile-deploymentmodel-openai-gpt-5technical-note

Expo EAS를 사용하면 모바일 앱의 빌드와 스토어 제출을 자동화할 수 있다. 편리한 만큼 운영에 필요한 자격 증명이 여러 곳에 나뉘어 저장되기 때문에, 각각의 역할을 구분하지 않으면 토큰 하나만 보관하고도 백업이 끝났다고 생각하기 쉽다.

핵심은 EAS 접근 권한, 앱 서명 자격 증명, 스토어 제출 자격 증명을 서로 다른 자산으로 관리하는 것이다.

먼저 구분해야 할 세 가지

구분 대표 항목 사용 시점 분실 시 영향
EAS 접근 EXPO_TOKEN CI에서 EAS Build·Update·Submit 실행 신규 빌드와 배포 자동화가 실패할 수 있음
앱 서명 Android Keystore, iOS 인증서·프로비저닝 프로파일 설치 가능한 앱 바이너리 생성 새 버전 빌드나 업데이트 제출이 막힐 수 있음
스토어 제출 Google 서비스 계정 키, App Store Connect API Key 완성된 바이너리를 스토어에 업로드 자동 제출이 실패함

EXPO_TOKEN은 EAS에 접근하기 위한 출입증이다. 이미 설치된 앱을 서명한 열쇠 자체는 아니다. 따라서 토큰을 교체해도 설치된 운영 앱이 갑자기 중단되지는 않는다. 다만 CI에 새 토큰이 반영되기 전에 기존 토큰을 폐기하면 그동안 빌드, OTA 업데이트, 스토어 제출 작업이 실패할 수 있다.

반드시 백업할 항목

1. Android 서명 자격 증명

Android 운영 빌드에서는 일반적으로 Keystore 파일과 다음 메타데이터가 한 세트다.

  • Keystore 파일(보통 .jks)
  • Keystore 비밀번호
  • Key Alias
  • Key 비밀번호
  • 위 경로와 값을 연결하는 credentials.json

EAS 원격 자격 증명을 사용한다면 다음 명령으로 관리 화면에 들어갈 수 있다.

eas credentials

Android와 운영 프로필을 선택한 뒤 자격 증명 다운로드 메뉴에서 credentials.json과 Keystore를 내려받는다. 두 파일 중 하나만 보관하면 복구가 불완전할 수 있으므로 반드시 한 세트로 백업한다.

Google Play App Signing을 사용하면 실제 앱 서명 키는 Google이 관리하고 로컬에서는 Upload Key를 사용하는 구성이 일반적이다. Upload Key 재설정 절차가 있더라도 새 배포가 지연될 수 있으므로 현재 키의 안전한 백업은 여전히 필요하다.

2. iOS 서명 자격 증명

iOS 운영 빌드에서 확인할 항목은 다음과 같다.

  • Distribution Certificate(보통 .p12)
  • 인증서 비밀번호
  • Provisioning Profile(.mobileprovision)
  • 푸시 알림을 사용한다면 APNs Key와 관련 식별자

Provisioning Profile은 만료되거나 앱 기능이 달라질 때 갱신할 수 있다. 그러나 장애 상황에서 빠르게 현재 구성을 확인하고 복구하려면 인증서와 프로파일을 함께 백업하는 것이 좋다.

3. Google Play 제출 자격 증명

EAS Submit으로 Android 앱을 올리려면 Google Play Console 접근 권한이 부여된 서비스 계정 키가 필요하다. 일반적으로 개인키가 포함된 JSON 파일이며, 소스 저장소에 커밋해서는 안 된다.

eas.json에 파일 경로가 적혀 있어도 JSON 파일 자체가 백업되는 것은 아니다. 다음 원칙을 적용한다.

  • Git ignore 대상인지 확인한다.
  • 개발 장비에서는 소유자만 읽을 수 있도록 파일 권한을 제한한다.
  • 암호화된 Vault나 비밀 파일 저장소에 원본을 보관한다.
  • 서비스 계정 권한은 제출에 필요한 최소 범위로 제한한다.

4. App Store Connect 제출 자격 증명

비대화형 iOS 제출에는 App Store Connect API Key를 사용할 수 있다. 직접 관리하는 경우 다음 항목을 한 세트로 보관한다.

  • API Key 파일(.p8)
  • Key ID
  • Issuer ID

앱의 ascAppId나 Bundle Identifier는 설정 식별자이며 개인키와는 다르다. 코드나 운영 문서에서 다시 찾을 수 있는 식별자와, 유출되면 권한이 탈취되는 비밀 값을 구분해야 한다.

안전한 백업 구조

자격 증명은 단순한 메모 한 줄보다 파일과 메타데이터가 연결된 복구 묶음으로 관리하는 편이 좋다.

  • Vault 항목: 용도, 소유 계정, 발급일, 만료일, 교체 절차
  • 암호화 파일: .jks, .p12, .mobileprovision, 서비스 계정 JSON, .p8
  • 비밀 값: 각 파일의 비밀번호, Key ID, Issuer ID, Alias
  • 비밀이 아닌 참조: EAS 프로젝트, 앱 식별자, 사용 중인 빌드 프로필

파일을 Base64 문자열로 바꿔 일반 환경변수처럼 보관할 수도 있지만, 복구 시 원본 바이너리와 정확히 일치하는지 검증해야 한다. 가능하면 파일 첨부와 버전 이력을 지원하는 암호화 저장소가 더 관리하기 쉽다.

교체할 때 지켜야 할 순서

토큰과 제출 키는 먼저 새 값을 연결하고 검증한 뒤 기존 값을 폐기한다.

  1. 새 자격 증명을 발급한다.
  2. Vault에 원본과 메타데이터를 저장한다.
  3. CI 또는 EAS에 새 값을 등록한다.
  4. 운영 프로필로 빌드와 제출 테스트를 수행한다.
  5. 새 자격 증명이 사용된 것을 확인한다.
  6. 기존 자격 증명을 폐기하고 폐기일을 기록한다.

이 순서를 따르면 설치된 앱에는 영향을 주지 않으면서 배포 자동화가 끊기는 시간을 피할 수 있다.

백업이 실제로 쓸 수 있는지 확인하기

백업은 내려받는 것으로 끝나지 않는다. 최소한 다음 항목을 정기적으로 점검해야 한다.

  • 별도의 권한 있는 계정으로 Vault에 접근 가능한가?
  • Keystore와 비밀번호, Alias가 서로 일치하는가?
  • 인증서의 만료일과 대상 앱이 기록되어 있는가?
  • 서비스 계정과 API Key가 아직 유효하며 권한이 과도하지 않은가?
  • 저장소를 새로 받은 환경에서도 비밀 파일 없이 소스가 정상 관리되는가?
  • 복구 절차가 특정 담당자의 기억에만 의존하지 않는가?

실제 스토어에 제출하지 않더라도, 격리된 환경에서 자격 증명을 복원하고 운영 빌드 준비 단계까지 검증하는 복구 훈련이 유용하다.

주의할 점

  • 자격 증명 파일을 Git에 커밋하지 않는다.
  • CI 로그나 메신저에 비밀 값을 그대로 출력하지 않는다.
  • 개발용과 운영용 서명 키를 혼용하지 않는다.
  • 자격 증명을 내려받은 임시 파일은 백업 확인 후 안전하게 정리한다.
  • 공유 계정보다 역할이 분리된 팀 계정과 최소 권한을 사용한다.
  • 푸시 알림 키와 앱 서명 키, 스토어 제출 키를 같은 것으로 오해하지 않는다.

듀오랩스가 보는 관점

모바일 앱 운영에서 중요한 것은 비밀 값을 많이 모으는 것이 아니라, 무엇이 어떤 배포 단계에 쓰이며 어떻게 복구할지를 함께 기록하는 것이다. 접근 토큰은 교체할 수 있어야 하고, 서명 자격 증명은 연속성을 보장해야 하며, 스토어 제출 키는 최소 권한으로 제한해야 한다.

운영 인수인계 문서에는 값 자체보다도 소유 주체, 저장 위치, 만료·교체 기준, 복구 검증일을 명확히 남겨야 한다. 그래야 담당자가 바뀌거나 개발 장비를 잃어도 앱 업데이트 경로를 복원할 수 있다.

참고 자료

함께 읽기