DUOLABS
모바일 앱 · 반응형 웹

OTA 업데이트

앱을 고치려면 무조건 스토어 심사를 다시 받아야 한다고 아는 경우가 많습니다. 그러면 오타 하나 고치는 데 며칠이 걸립니다. 실제로는 교체할 수 있는 부분이 있습니다. 다만 기술적으로 되는 범위와 정책이 허용하는 범위가 다르고, 그 두 선을 같이 봐야 합니다.

한 문장으로

OTA 는 앱을 다시 심사받지 않고 화면과 동작 일부를 교체하는 방식입니다.

하는 일

  • 되는 것 — 화면 배치, 문구, 대부분의 동작 로직
  • 안 되는 것 — 앱 이름과 아이콘, 새 권한, 기기 기능을 쓰는 부분
  • 채널 — 시험용과 실사용을 나눠 단계적으로 내보내기
  • 되돌리기 — 문제가 생기면 이전 버전으로 즉시 복귀
  • 강제 적용 — 반드시 받아야 하는 변경을 다루는 방법
  • 정책 범위 — 어디까지가 다듬기이고 어디부터가 다른 앱인지

하지 않는 일

  • 스토어 배포 자체 — 새 버전 등록은 여전히 심사를 거칩니다
  • 기기 기능 추가 — 카메라나 블루투스를 새로 쓰려면 심사가 필요합니다
  • 앱 이름 · 아이콘 · 권한 변경 — 스토어에 등록된 정보입니다

이웃 개념과 헷갈리는 지점

스토어 배포새 버전을 심사받아 올리는 것
OTA 는 그 사이를 메웁니다. 큰 변경은 스토어로, 고치고 다듬는 것은 OTA 로 나누는 것이 보통입니다.
앱 심사정책을 지켰는지 확인하는 절차
OTA 로 앱의 성격을 크게 바꾸면 다음 심사에서 문제가 됩니다. 심사를 피하는 길이 아니라 사이를 메우는 길입니다.
원격 설정값만 서버에서 바꾸는 것
코드를 바꾸지 않고 켜고 끄는 정도라면 이쪽이 더 단순합니다. 화면이나 로직을 바꿔야 할 때 OTA 가 필요합니다.
웹뷰앱 안에서 웹 페이지를 띄우는 것
웹 부분은 원래 서버에서 바꾸면 됩니다. 다만 웹뷰가 많은 앱은 심사에서 다른 지적을 받기도 합니다.

언제 필요한가

이럴 때 필요합니다

  • 긴급 수정에 며칠씩 걸릴 때
  • 문구나 가격 표시처럼 자주 바뀌는 것이 있을 때
  • 배포 후 문제를 빨리 되돌려야 할 때
  • 일부 사용자에게 먼저 내보내 보고 싶을 때

아직 아니어도 됩니다

  • 업데이트가 드물다면 스토어 배포만으로 충분합니다
  • 기기 기능 위주의 앱이라면 OTA 로 바꿀 수 있는 범위가 좁습니다
  • 순수 네이티브로 만든 앱이라면 이 방식 자체가 맞지 않습니다

여기서부터는 갈립니다

기술적으로는 되는데 정책상 안 되는 구간이 있습니다. 스토어는 심사받은 앱의 성격이 크게 바뀌는 것을 허용하지 않는데, 어디까지가 “크게” 인지는 명확한 선이 없고 사례로만 알려져 있습니다. 그래서 기능을 통째로 바꾸는 용도로 쓰면 위험하고, 고치고 다듬는 용도로 쓰는 것이 안전합니다. 그 경계는 계속 조정되는 중입니다.

자주 묻는 질문

교체 가능한 부분에 한해서는 그렇습니다. 사용자는 앱을 다시 받지 않고, 다음에 앱을 열 때 새 내용이 적용됩니다. 다만 스토어에 등록된 정보나 기기 기능과 관련된 부분은 여전히 심사가 필요합니다.

화면 배치, 문구, 계산이나 흐름 같은 동작 대부분입니다. 앱 이름과 아이콘, 새로 요청하는 권한, 카메라 같은 기기 기능을 새로 쓰는 부분은 안 됩니다.

아닙니다. 앱을 켤 때 새 내용이 있는지 확인하고 받아 둡니다. 적용 시점은 설정하기 나름인데, 바로 반영할지 다음에 켤 때 반영할지 정할 수 있습니다.

가능합니다. 이전 버전으로 되돌리면 다음 실행부터 적용됩니다. 이게 OTA 의 큰 장점입니다. 스토어 배포는 잘못 나가면 되돌리는 데 다시 심사가 걸립니다.

고치고 다듬는 용도라면 일반적으로 쓰이는 방식입니다. 문제가 되는 것은 심사받은 것과 다른 앱처럼 만들 때입니다. 그 선을 넘지 않는 것이 중요하고, 애매하면 스토어 배포로 가는 편이 안전합니다.

범위가 애매해도 괜찮습니다

지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.