[MOBILE-011][실무] 앱에 서명하고 안전하게 스토어에 배포하기 > IT 기술 공유

• 목록

[이번 수업]

모바일 앱을 릴리스용으로 만들고 서명·스토어 심사·단계적 배포를 거쳐 사용자에게 전달하는 흐름을 배웁니다. 릴리스는 어떤 코드가 배포됐는지 확인하고 문제 발생 시 멈출 수 있게 만드는 과정입니다.

[선수지식]

MOBILE-009의 자동 테스트, MOBILE-010의 성능 점검, TOOL-010의 비밀정보 관리를 알면 좋습니다. Python 파일 하나를 실행할 수 있으면 됩니다.

[학습목표]

1. 앱 서명과 파일 해시의 역할을 구분한다.
2. 빌드·메타데이터·개인정보 항목을 점검한다.
3. 내부 테스트부터 단계적으로 배포한다.

[핵심개념]

앱 서명은 암호 기술로 배포자의 신원과 설치 파일의 무결성을 확인합니다. Android에서는 기기에 설치되는 파일의 앱 서명 키와 스토어 제출에 쓰는 업로드 키를 구분할 수 있습니다. iOS 계열은 인증서, 앱 식별자, 권한 정보가 맞는 릴리스 빌드를 제출합니다. 개인 키는 서명을 만드는 비밀이고 인증서나 공개 키는 검증에 쓰입니다.

심사는 자동 테스트를 대신하지 않습니다. 충돌, 실제 기기 동작, 설명·개인정보 표시, 요청 권한, 로그인 검토 방법을 제출 전에 맞춰야 합니다. 버전은 사용자가 보는 출시 번호이고 빌드 번호는 업로드한 결과물을 구별합니다. 디버그와 릴리스 빌드는 설정과 서명이 다르므로 별도로 검증하세요.

안전한 흐름은 ‘릴리스 후보 고정 → 테스트 → 서명 → 내부 시험 배포 → 심사 → 소수 배포 → 오류 관찰 → 확대’입니다. 이미 설치된 앱은 즉시 되돌리기 어려우므로 배포 중단 기준과 수정 빌드 절차를 미리 적습니다.

[따라하기]

빈 폴더에 release_check.py를 만들고 아래를 붙여 넣으세요. 실제 키 없이 가짜 빌드의 필수 정보와 해시를 점검합니다. 해시는 파일 변경을 비교하는 값일 뿐 서명을 대신하지 않습니다.

```python
from hashlib import sha256
from pathlib import Path
import json

artifact = Path("demo-release.bin")
artifact.write_bytes(b"local release candidate\n")

release = {
    "version": "1.2.0",
    "build": 12,
    "privacy_url": "https://example.invalid/privacy",
    "tests_passed": True,
    "signing": "store-managed",
    "permissions": ["camera"],
}

errors = []
if not release["version"] or release["build"] < 1:
    errors.append("버전 또는 빌드 번호 확인")
if not release["tests_passed"]:
    errors.append("테스트 실패")
if not release["privacy_url"].startswith("https://"):
    errors.append("개인정보 URL 확인")
if release["signing"] not in {"store-managed", "team-managed"}:
    errors.append("서명 방식 확인")

report = {
    "ready": not errors,
    "errors": errors,
    "sha256": sha256(artifact.read_bytes()).hexdigest(),
    "permissions": release["permissions"],
}
print(json.dumps(report, ensure_ascii=False, indent=2))
```

macOS·Linux에서는 `python3 release_check.py`, Windows에서는 `py release_check.py`를 실행합니다. 환경에 따라 `python`도 됩니다. 예상 결과는 `ready`가 true, `errors`가 빈 목록, `sha256`이 64자리인 것입니다. demo-release.bin도 생깁니다. Xcode를 이용한 iOS 빌드·업로드는 macOS에서 진행하며 Android 빌드 도구는 세 운영체제를 지원합니다.

[흔한 실수]

디버그 빌드를 제출하거나 빌드 번호를 올리지 않기 쉽습니다. 앱 식별자, 서명 권한, 개인정보 설명이 실제 동작과 다르면 심사나 설치가 실패할 수 있습니다. 심사 통과를 품질 보증으로 여기지 말고 내부 배포에서 설치·업데이트·로그인도 확인하세요.

[보안 주의]

키 저장 파일, 개인 키, 비밀번호, 업로드 토큰을 저장소나 채팅에 넣지 마세요. 보호된 비밀 저장소와 최소 권한 계정을 사용하고 복구·교체 절차를 문서화합니다. 검토용 계정은 실제 데이터가 없는 제한 계정으로 만들고 검토 뒤 회수하세요. 실습은 본인 소유의 로컬 환경과 가짜 파일에서만 진행합니다.

[직접 해볼 과제]

tests_passed를 false로 바꿔 준비가 막히는지 확인하세요. 이어서 각 권한의 기능 목적, 개인정보 설명 반영 여부, 담당자를 적은 릴리스 점검표를 만드세요.

[확인문제]

1. 파일 해시가 앱 서명을 대신할 수 없는 이유는 무엇인가요?
2. 버전 번호와 빌드 번호는 무엇을 구분하나요?
3. 심사 전에 내부 시험 배포가 필요한 이유는 무엇인가요?

[다음 학습]

MOBILE-012에서 오프라인 지원 앱을 설계하고 테스트와 배포 계획까지 묶어 봅니다.

[공식 참고 자료]

https://developer.android.com/studio/publish/app-signing
https://developer.android.com/studio/publish/preparing
https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/
https://developer.apple.com/app-store/review/guidelines/
https://docs.python.org/3/library/hashlib.html
https://docs.python.org/3/library/json.html