앱 스토어

앱 스토어는 개발자가 만든 앱을 사용자의 스마트폰까지 실어 나르는 창구입니다. 사용자는 여기서 앱을 찾아 설치하고 새 버전으로 업데이트합니다. 대개 운영체제를 만든 회사가 운영합니다. 그래서 어떤 앱을 받아 줄지도 그 회사가 정합니다.

상세

백화점은 가게를 들이기 전에 어떤 가게인지 먼저 살핍니다. 손님은 처음 보는 가게라도 백화점 안에 있으니 믿고 물건을 삽니다. 값은 백화점 계산대에서 치릅니다. 백화점은 그 매출에서 수수료를 뗍니다.

앱 스토어는 앱을 두고 이 일을 하는 유통 플랫폼입니다. 앱을 올리고, 찾고, 내려받고, 업데이트하는 일을 한곳에서 맡습니다. 스마트폰에 기본으로 깔린 스토어 앱이 그 입구입니다. 사용자는 그 앱에서 이름으로 검색해 설치 버튼 하나로 앱을 받습니다.

이 절은 앱 하나가 개발자의 손을 떠나 사용자의 폰에 깔리기까지를 따라갑니다. 그다음 이 경로가 백엔드 개발자에게 무엇을 남기는지 봅니다. 앱이 서버에 보내는 요청과 결제를 확인하는 일이 여기에 걸려 있습니다.

스토어가 없으면 곤란한 까닭

스토어가 없다고 해 봅니다. 사용자는 웹사이트에서 설치 파일을 받아 직접 깔아야 합니다. 그 파일을 누가 만들었는지 알 길이 없습니다. 내려받는 도중에 누군가 파일을 바꿔치기했어도 모릅니다.

업데이트도 앱마다 따로 챙겨야 합니다. 앱이 스스로 새 버전을 확인하고 받아 오는 기능을 저마다 짜야 합니다. 결제도 앱마다 카드 번호를 받는 창을 따로 만들어야 합니다. 사용자는 앱마다 카드 번호를 넘겨야 합니다.

스토어는 이 일들을 한곳에 모읍니다. 스토어는 대개 운영체제를 만든 회사가 직접 운영합니다. 운영체제가 스토어에서 온 앱의 설치와 업데이트를 믿고 맡길 수 있는 까닭입니다.

패키지 관리자와 다른 점

서버를 다뤄 본 사람에게는 패키지 관리자가 가까운 이웃입니다. 패키지 관리자는 apt install nginx 한 줄로 프로그램을 찾아 설치하고 업데이트하는 도구입니다. 정해 둔 저장소에서 설치 파일을 받아 옵니다.

앱 스토어도 뼈대는 같습니다. 한곳에 모인 설치 파일 목록이 있습니다. 설치하기 전에 서명을 확인합니다. 서명은 파일을 만든 사람이 붙이는 표시로, 누가 만들었고 중간에 바뀌지 않았는지를 보여 줍니다. 새 버전이 올라오면 받아 옵니다. 차이는 누가 저장소를 쥐고 무엇을 더 하느냐에 있습니다.

표에서 가장 큰 차이는 첫 줄입니다. 서버에서는 관리자가 믿을 저장소를 고릅니다. 폰에서는 그 선택을 스토어 운영사가 대신 합니다.

앱이 사용자에게 닿기까지

개발자는 먼저 스토어에 개발자 계정을 만듭니다. 이때 스토어에 넘기는 것은 이름이나 회사 같은 신원 정보입니다. 스토어는 이 계정으로 올라온 앱만 받아 줍니다.

서명에는 짝을 이루는 키 두 개를 씁니다. 개인 키는 개발자만 가진 비밀 키입니다. 서명은 이 키로만 만들 수 있습니다. 짝이 되는 공개 키로는 서명이 맞는지 확인만 할 수 있습니다.

앱을 올릴 때는 빌드한 설치 파일에 코드 서명을 합니다. 개인 키로 파일에 서명을 붙이는 일입니다. 설치하는 쪽은 이 서명으로 파일을 누가 만들었는지 확인합니다. 올린 뒤에 파일이 바뀌지 않았다는 것도 확인합니다.

올라온 앱은 앱 심사를 거칩니다. 심사는 스토어가 앱을 목록에 올리기 전에 살펴보는 일입니다. 몰래 개인 정보를 빼 가는지, 스토어 규칙을 어기는지 봅니다. 규칙에 어긋나면 반려됩니다. 개발자는 고쳐서 다시 올립니다.

통과한 앱은 스토어 목록에 오릅니다. 사용자는 거기서 앱을 설치합니다. 새 버전을 낼 때도 이 경로를 처음부터 다시 밟습니다. 사용자의 폰은 스토어에 새 버전이 있는지 물어 받아 옵니다. 이 흐름을 한 그림에 놓으면 아래와 같습니다.

sequenceDiagram
    participant 개발자
    participant 스토어 as 앱 스토어
    participant 폰 as 사용자의 폰
    개발자->>스토어: 개발자 계정을 만들고 신원을 밝힌다
    개발자->>스토어: 서명한 설치 파일을 올린다
    스토어->>스토어: 앱 심사
    Note over 개발자,스토어: 반려되면 고쳐서 다시 올린다
    스토어-->>개발자: 통과를 알린다
    폰->>스토어: 검색해서 설치를 누른다
    스토어-->>폰: 설치 파일을 내려보낸다
    폰->>폰: 서명을 확인하고 설치한다

개발자는 스토어를 거쳐서만 사용자에게 닿습니다. 사용자와 개발자가 직접 파일을 주고받는 선이 그림에 없습니다.

서버에 함께 들어오는 여러 버전

서버 코드는 배포하면 바로 바뀝니다. 앱은 다릅니다. 새 버전을 올려도 심사를 통과해야 사용자에게 닿습니다. 급한 버그를 고친 버전도 심사를 기다립니다.

사용자가 곧바로 업데이트한다는 보장도 없습니다. 자동 업데이트를 꺼 둔 사람이 있습니다. 몇 달 동안 앱을 안 연 사람도 있습니다. 그래서 서버에는 지난 버전의 앱들이 새 버전과 함께 요청을 보냅니다.

백엔드는 이 옛 앱의 요청도 받아 줘야 합니다. API(Application Programming Interface)를 바꿀 때 옛 형식을 계속 받아 주는 것을 하위 호환이라고 합니다. 응답에서 필드 이름을 바꾸거나 빼면 옛 앱이 그 응답을 못 읽습니다.

옛 버전을 끝없이 받아 줄 수는 없습니다. 서버는 받아 줄 가장 낮은 버전을 정해 둡니다. 이 선이 최소 지원 버전입니다. 이보다 낮은 앱의 요청은 더 받지 않겠다는 뜻입니다.

선 아래의 앱에는 업데이트를 요구합니다. 앱은 요청마다 자기 버전을 실어 보냅니다. 서버는 그 버전이 최소 지원 버전보다 낮으면 업데이트하라는 응답을 돌려줍니다. 사용자는 업데이트해야 앱을 계속 씁니다. 이 방식을 강제 업데이트라고 합니다.

아래는 서버가 버전을 견주는 모습입니다. 버전 3.1.4 를 숫자 셋으로 쪼개 두면 앞 숫자부터 차례로 비교할 수 있습니다.

MIN = (3, 2, 0)   # 최소 지원 버전 3.2.0
ver = (3, 1, 4)   # 앱이 보낸 3.1.4
ver < MIN         # True

첫 숫자는 둘 다 3이라 비깁니다. 둘째 숫자에서 1이 2보다 작습니다. 그래서 이 앱은 최소 지원 버전보다 낮습니다. 서버는 이 요청에 업데이트 안내를 돌려줍니다.

심사를 기다리지 않고 앱의 동작을 바꾸고 싶을 때도 있습니다. 그때는 기능을 켜고 끄는 스위치를 서버에 둡니다. 앱은 켜져 있는 기능만 보여 줍니다. 이 스위치를 기능 플래그라고 합니다.

새 버전에 버그가 있으면 고친 버전이 다시 심사를 거쳐 닿을 때까지 기다려야 합니다. 그동안 그 버전을 받은 사용자는 버그를 안고 씁니다. 받은 사람이 적을수록 피해도 작습니다.

그래서 새 버전을 모든 사용자에게 한 번에 내보내지 않기도 합니다. 일부 사용자에게 먼저 풀고 문제가 없으면 넓힙니다. 문제가 보이면 거기서 출시를 멈춥니다. 이 방식이 단계적 출시입니다.

결제를 스토어가 맡을 때

앱 안에서 유료 기능이나 구독 같은 디지털 상품을 팔 수 있습니다. 이때 스토어의 결제를 거치도록 규칙으로 정한 스토어가 많습니다. 이 결제를 인앱 결제라고 합니다. 사용자는 스토어에 등록해 둔 결제 수단으로 값을 치릅니다. 스토어는 매출의 일부를 수수료로 떼고 나머지를 개발자에게 넘깁니다.

백엔드에 걸리는 일은 결제 결과를 확인하는 것입니다. 결제가 끝나면 스토어는 앱에 영수증을 줍니다. 영수증은 무엇을 언제 샀는지 스토어가 서명해 적어 준 기록입니다.

앱이 「결제했다」고 보내는 말만 믿으면 안 됩니다. 앱은 사용자의 폰에서 돕니다. 폰에서 나가는 요청은 조작될 수 있습니다. 백엔드는 영수증을 스토어 서버에 보내 진짜인지 묻습니다. 이 일을 영수증 검증이라고 합니다. 검증이 끝난 뒤에야 서버가 유료 기능을 열어 줍니다.

구독은 결제가 한 번으로 끝나지 않습니다. 달마다 새로 갱신됩니다. 중간에 해지나 환불도 일어납니다. 스토어는 대개 이런 변화를 백엔드에 알림으로 보내 줍니다. 백엔드는 그 알림을 받아 사용자의 권한을 고칩니다.

스토어를 거치지 않는 길

스토어 밖에서 설치 파일을 받아 직접 까는 것을 사이드로딩이라고 합니다. 운영체제마다 허용하는 폭이 다릅니다. Android 는 설정을 바꾸면 스토어 밖의 설치 파일도 깔 수 있습니다. iOS 는 이 길을 훨씬 좁게 열어 둡니다.

회사가 직원에게만 나눠 주는 사내 앱은 공개 스토어에 올리지 않기도 합니다. 회사가 관리하는 폰에 앱을 밀어 넣는 도구를 씁니다. 이런 도구를 모바일 기기 관리 도구라고 부릅니다.

앱 대신 웹으로 가는 길도 있습니다. 프로그레시브 웹 앱은 웹사이트를 홈 화면에 설치한 앱처럼 쓰게 하는 방식입니다. 주소 하나로 퍼지고 심사를 거치지 않습니다. 서버에 올리면 모든 사용자에게 바로 새 버전이 닿습니다. 대신 폰의 기능 가운데 웹에서 못 쓰는 것이 있습니다.

치르는 값

스토어에 앱을 내면 스토어의 규칙을 따라야 합니다. 규칙은 스토어 운영사가 정하고 바꿉니다. 규칙이 바뀌면 이미 올라간 앱도 고쳐야 할 수 있습니다. 규칙을 어기면 앱이 목록에서 내려갈 수 있습니다.

심사는 출시를 늦춥니다. 서버처럼 하루에 여러 번 고쳐 내보내기가 어렵습니다. 그래서 자주 바뀌는 동작은 앱 코드보다 서버 쪽에 두려는 설계가 흔합니다.

앱 안에서 디지털 상품을 팔면 매출의 일부가 수수료로 나갑니다. 결제 정보도 스토어를 거쳐 옵니다. 백엔드는 스토어가 알려 주는 만큼만 결제 상태를 압니다.

이 이름이 가리키는 범위

흔히 앱 스토어라고 하면 두 스토어를 떠올립니다. Apple 이 iOS 기기에 두는 App Store 와 Google 이 Android 기기에 두는 Google Play 입니다. 삼성의 Galaxy Store 처럼 폰 제조사가 따로 여는 스토어도 있습니다.

같은 이름은 폰 밖에서도 쓰입니다. Windows 에 딸린 Microsoft Store 와 macOS 에 딸린 Mac App Store 가 데스크톱 운영체제의 스토어입니다. Chrome 웹 스토어는 브라우저 확장 프로그램을 나눠 줍니다. 협업 도구에 붙일 추가 기능을 모아 둔 목록도 앱 스토어라고 부릅니다. 올리고, 살펴보고, 내려받는 뼈대는 같습니다. 이 편은 그 가운데 모바일 앱 스토어를 중심으로 적었습니다.

관련 항목

앱 스토어가 앱을 실어 나르는 운영체제

Android · iOS · 운영체제 · 스마트폰 · 모바일 개발

앱 스토어를 실제로 운영하는 제품

App Store · Google Play · Galaxy Store · Microsoft Store · Mac App Store · Chrome 웹 스토어

앱 스토어가 앱을 받아 주기 전에 거치는 확인 절차

개발자 계정 · 코드 서명 · 개인 키 · 공개 키 · 앱 심사 · 자기 서명 인증서

앱 스토어로 앱을 내보내는 도구와 단계

배포 · 빌드 · 단계적 출시 · TestFlight · App Store Connect · Google Play Console

앱 스토어에 올리는 설치 파일 형식

APK · Android App Bundle · IPA

앱 스토어 탓에 백엔드가 떠안는 버전 관리 수단

하위 호환 · 최소 지원 버전 · 강제 업데이트 · 기능 플래그 · API 버전 관리 · 원격 설정

앱 스토어가 대신 받는 결제

인앱 결제 · 구독 · 영수증 검증 · 결제 대행사 · 환불

앱 스토어를 거치지 않는 설치 경로

사이드로딩 · 모바일 기기 관리 · 프로그레시브 웹 앱 · 웹 앱 · 딥 링크

앱 스토어와 닮은 배포 창구

패키지 관리자 · 아티팩트 저장소 · 컨테이너 레지스트리 · 브라우저 확장 프로그램