모바일 앱15분
같은 Expo 앱인데 배포 방식은 달랐습니다: iOS와 Android 심사 제출 비교기
앞선 글에서는 이미 TestFlight에 올라간 iOS 빌드를 AI가 App Store 심사까지 제출한 과정을 다뤘습니다.
앞선 글에서는 이미 TestFlight에 올라간 iOS 빌드를 AI가 App Store 심사까지 제출한 과정을 다뤘습니다.
사내에 AI를 도입하려는 회사가 가장 먼저 부딪히는 질문이 있습니다. "모델 하나면 되는 것 아닌가요?"
코드를 한 줄도 수정하지 않았는데 TestFlight에 올라가 있던 앱이 App Review 제출 상태로 바뀌었습니다. 얼핏 보면 AI가 앱을 새로 빌드해서 배포한 것처럼 보이지만, 실제로는 이미 준비된 빌드와 스토어 정보를 확인한 뒤 App Store Connect의 심사 절차를 진행한 것입니다.
빌드 모드(Debug/Release)와 배포 방식(Development/Ad Hoc/TestFlight)은 서로 다른 축입니다.
앱을 콜드 스타트하면 흰 배경과 앱 아이콘으로 구성된 iOS 스플래시가 정상보다 오래 남습니다. 같은 TestFlight 빌드에서도 빠르게 열릴 때와 약 8초 동안 멈춘 것처럼 보일 때가 섞여 간헐적으로 재현됩니다.
무료 티어에서 걸린 문제들을 Pro 요금제로 올리면 몇 개가 사라질까. 세어보니 용량 문제는 전부 지워졌는데 블로커는 오히려 하나 늘었다. 돈으로 사는 것과 못 사는 것의 경계에 대한 기록.
잘 돌아가던 개인 프로젝트를 Vercel과 Supabase 무료 티어로 옮길 수 있을지 검토했다. 요금제 한도표부터 보는 대신 코드를 먼저 읽었고, 진짜 제약은 숫자가 아니라 실행 모델 쪽에 있었다.
Expo 앱을 개발하다 보면 명령어보다 “지금 다시 빌드해야 하나?”가 더 헷갈립니다. 화면 코드만 바꿨는데 Gradle 빌드를 다시 돌리기도 하고, 반대로 스플래시 이미지를 바꾼 뒤 Metro만 재시작해서 왜 그대로인지 한참 보기도 합니다.
Vercel 같은 서버리스 환경에 백그라운드 작업 큐와 요청 제한을 붙이려고 문서를 펼치면
웹 서비스를 만들다 보면 이런 값들을 자주 다룹니다.
Next.js로 웹 서비스를 만들 때 AWS 서비스를 하나씩 고르면 꽤 긴 목록이 나온다. CDN, API 입구, 함수 실행, PostgreSQL, 인증, 파일 저장, Redis, Queue, 이벤트 예약, 배포 파이프라인이 각각 다른 서비스다.
서버리스 프로젝트에 Worker를 붙일 때 QStash가 반드시 필요한 것은 아니다. 이미 Supabase를 사용하고 있다면 PostgreSQL 기반의 Supabase Queues로 작업을 저장하고, Vercel 함수가 메시지를 가져가 처리하는 구조를 만들 수 있다.
Vercel은 코드를 실행하고, Supabase는 데이터를 영구 저장하며, QStash는 비동기 작업을 전달한다. 여기까지 이해하고 나면 Redis의 자리가 모호하게 느껴질 수 있다.
서버리스 프로젝트에 비동기 처리를 추가하려고 하면 서비스 구성이 갑자기 복잡해 보인다. Vercel, Supabase, Upstash까지 연결했는데 Worker라는 이름이 하나 더 등장하기 때문이다.
Supabase를 처음 접하면 관리형 PostgreSQL 서비스로 이해하기 쉽습니다. 실제로 PostgreSQL은 Supabase의 중심이지만, 전체 제품은 데이터베이스보다 훨씬 넓은 범위를 다룹니다.
Vercel에 앱을 올리고, Supabase에 데이터를 저장하고, Upstash Redis로 요청 제한을 걸고, QStash로 비동기 작업을 전달한다고 해보자. 서비스 이름만 네 개다. 이쯤 되면 자연스럽게 이런 생각이 든다.
홈페이지 플랫폼 이전은 새 화면을 만드는 작업만이 아닙니다. 기존 URL과 검색 노출, 도메인과 회사 메일, 게시물과 이미지, 문의 폼, 분석 태그까지 함께 옮겨야 비로소 이전이 끝납니다.
아임웹이나 카페24로 시작한 사이트가 성장하면 어느 순간 “이제 맞춤 개발을 해야 할까?”라는 질문이 생깁니다. 관리자 화면 밖의 엑셀 작업이 늘고, 앱과 외부 서비스를 계속 붙이는데도 업무가 매끄럽지 않기 때문입니다.
서버리스 서비스를 구성하다 보면 Supabase, QStash, Redis가 한 화면에 함께 등장합니다. 모두 데이터를 다루는 것처럼 보여 처음에는 무엇을 어디에 써야 하는지 헷갈리기 쉽습니다.
Flutter 프로젝트를 다른 컴퓨터로 옮길 때 가장 흔한 착각은 “Git 저장소만 clone하면 되겠지”라는 생각입니다. 소스 코드는 돌아오지만 .gitignore에 들어간 환경 파일, Firebase 설정, 앱 서명 키가 빠져 있으면 개발 빌드부터 스토어 업데이트까지 곳곳에서 막힙니다.