앱은 어떻게 업데이트될까? 앱스토어 배포와 강제 업데이트

4 분 소요

스마트폰 앱 아이콘에 빨간 점이 떠 있거나, 앱을 열자마자 “업데이트가 필요합니다"라는 화면을 만난 적이 있을 것입니다. 어떤 날은 알아서 새 버전으로 바뀌어 있기도 하고, 어떤 날은 사용자가 직접 받아야만 다시 쓸 수 있게 막혀 있기도 합니다.

이번 글에서는 앱 업데이트가 어떤 길로 사용자에게 도착하는지, 그리고 만든 회사가 어디까지 그 흐름을 통제할 수 있는지를 코드 없이 정리하겠습니다. 앱과 웹의 큰 차이가 궁금하다면 앱 vs 웹 — 네이티브, 하이브리드, 앱스토어 심사를 먼저 읽고 오면 맥락이 잘 잡힙니다.

새 버전이 도착하기까지의 길 #

앱이 만들어지고 사용자에게 도착하기까지의 길은 대체로 비슷합니다. 회사가 새 버전을 빌드해서 앱스토어에 올리고, 앱스토어가 심사를 한 다음 통과한 버전을 사용자가 받아 가는 식입니다.

심사는 단순한 형식 점검이 아닙니다. 약속한 권한 외에 다른 권한을 몰래 쓰는지, 결제는 정해진 결제 시스템을 통해 도는지, 광고와 가이드라인에 맞지 않는 콘텐츠가 들어 있지는 않은지를 봅니다. 보통 하루에서 며칠 안에 결과가 나오는데, 거절되면 회사는 수정해서 다시 제출해야 합니다. 이 한 단계 때문에 앱은 웹사이트처럼 즉시 새 버전을 띄울 수 없고, 사고가 나도 패치가 사용자에게 닿기까지 며칠이 걸리기도 합니다.

자동 업데이트가 동작하는 방식 #

대부분의 사용자는 앱을 직접 업데이트하지 않습니다. iOS와 안드로이드 모두 기본 설정으로 자동 업데이트가 켜져 있어서, 와이파이에 연결돼 있고 충전 중이거나 한가한 시간을 골라 새 버전을 받아 둡니다. 그래서 다음에 앱을 열면 어느새 화면 구성이 살짝 달라져 있곤 합니다.

자동 업데이트가 꺼져 있거나 데이터 절약 설정이 켜져 있는 사용자에게는 빨간 점만 떠 있고, 실제 업데이트는 사용자가 직접 누를 때까지 미뤄집니다. 회사 입장에서 보면 “새 버전을 배포했다고 해서 모두가 동시에 새 버전을 쓰는 것은 아니다"라는 사실이 중요합니다. 어떤 사용자는 1년 전 버전을 그대로 쓰고 있을 수도 있고, 어느 한 시점에 회사가 추적해 보면 다섯, 여섯 가지 버전이 공존하는 경우가 흔합니다.

단계적 출시 — 1%부터 천천히 푼다 #

새 버전에 큰 변경이 있을 때, 회사는 보통 모두에게 한꺼번에 풀지 않습니다. 일부에게만 먼저 푸는 단계적 출시(rollout)를 씁니다. 처음에는 전체 사용자의 1%에만 새 버전이 보이고, 충돌률, 오류 보고, 평점이 안정적으로 들어오면 5%, 10%, 50%, 100% 식으로 비율을 천천히 올립니다.

이 구조는 사고를 작게 가두기 위한 장치입니다. 만에 하나 새 버전에 큰 버그가 있어도 5%에서 멈춰 두면 95%의 사용자는 영향 없이 이전 버전을 그대로 쓰고 있는 셈입니다. 회사는 단계적 출시를 일시 중지하거나, 더 나아가 새 버전 배포를 멈추고 이전 버전을 다시 기본으로 돌려놓을 수도 있습니다.

강제 업데이트는 어떻게 가능한가 #

가끔 앱을 열면 “이 버전은 더 이상 사용할 수 없습니다. 업데이트해 주세요"라는 화면 너머로 아무 기능도 쓸 수 없게 막힐 때가 있습니다. 흔히 강제 업데이트라고 부르는 동작입니다.

운영체제 차원에서 한 앱의 사용을 강제로 막는 권한은 없습니다. 그래서 강제 업데이트는 사실 앱 안에 미리 심어 둔 절차의 결과입니다. 앱은 시작될 때마다 자기 서버에 “지금 허용되는 최소 버전이 무엇인가"를 묻고, 사용자의 현재 버전이 그 최소 버전보다 낮으면 메인 화면 위에 “업데이트가 필요합니다” 안내를 띄우고 기능을 막습니다. 보안 사고, 데이터 구조 변경, 결제 API 폐기처럼 옛 버전을 계속 쓰게 두면 위험하거나 도리어 망가지는 경우에 이 장치가 동원됩니다.

서버 쪽 최소 버전 값만 바꾸면 즉시 모든 사용자에게 적용되므로, 앱스토어 심사 일정과 별개로 빠르게 통제할 수 있는 수단이기도 합니다.

웹은 새로고침, 앱은 한 단계 더 #

웹사이트는 회사가 서버 코드를 바꾸면 대개 다음 새로고침부터 새 버전이 보입니다. 다만 브라우저나 CDN 캐시 때문에 바로 반영되지 않는 경우도 있습니다. 그래서 사고가 나도 비교적 빠르게 되돌릴 수 있습니다. 앱은 그렇게 즉시 바뀌지 않습니다. 빌드 → 심사 → 단계적 출시 → 사용자 자동 업데이트라는 여러 단계가 사이에 있고, 그 단계마다 통제와 검증이 작동합니다. 느린 만큼 안정적인 길이지만, 사고가 났을 때 회사가 쓸 수 있는 카드는 웹보다 좁아집니다.

다음에 앱 화면에 “업데이트가 필요합니다"가 떴다면, 그 한 줄 뒤에서 빌드와 심사와 최소 버전 확인이 줄지어 도착해 있다는 뜻입니다. 새로고침 한 번으로 끝나지 않는 만큼, 앱의 업데이트 안내는 보통 한 번쯤 눌러 두는 편이 안전합니다.

X