EAS의 역사: 앱 빌드에서 모바일 배포 플랫폼까지
EAS를 eas build 명령어의 이름으로만 이해하면 서비스의 절반만 보게 됩니다. EAS는 Expo Application Services의 약자입니다. 소스 코드를 앱 바이너리로 만들고, 스토어에 전달하고, 이미 설치된 앱에 호환되는 업데이트를 보내는 모바일 배포 과정을 여러 서비스로 나눈 플랫폼입니다.
EAS를 eas build 명령어의 이름으로만 이해하면 서비스의 절반만 보게 됩니다. EAS는 Expo Application Services의 약자입니다. 소스 코드를 앱 바이너리로 만들고, 스토어에 전달하고, 이미 설치된 앱에 호환되는 업데이트를 보내는 모바일 배포 과정을 여러 서비스로 나눈 플랫폼입니다.
성경 지도라는 앱을 만들면서 npx create-expo-app을 치지 않았습니다. 이미 두 스토어에 배포되고 있는 다른 앱의 폴더를 통째로 복사해서 시작했습니다.
앱 하나를 두 스토어에 올리면서 EAS 를 처음 제대로 썼습니다. 그 전까지는 "배포 명령을 돌리면 스토어에 올라간다" 정도로만 알고 있었는데, 실제로 해보니 그 한 문장 안에 서로 다른 세 가지 일이 섞여 있었습니다. 그걸 구분하고 나서야 어디서 막혔는지가 보였습니다.
새 Expo 앱 하나를 두 스토어에 올릴 준비를 했습니다. 필요한 항목 자체는 검색하면 다 나옵니다. 그런데 정작 저를 막은 건 항목이 아니라 순서였습니다. 앞 단계가 끝나야 뒤 단계의 값이 생기는 구간이 몇 군데 있고, 그걸 모르고 덤비면 "왜 이 필드가 비어 있지"에서 멈춥니다.
React Native와 Expo로 여러 고객 앱을 개발·배포한다면 계정, 비용, 서명 키, 스토어 권한을 어떻게 나눌지 초기에 정해야 합니다. 이 구조를 잘못 잡으면 나중에 소유권 이전, 업데이트, 보안 관리가 복잡해집니다.
모바일 앱 배포는 빌드 파일을 만드는 것에서 끝나지 않습니다. 인증서, 서명 키, 스토어 메타데이터, 심사 정보, 버전 관리, 제출 자동화까지 함께 설계해야 반복 가능한 배포가 됩니다.
Expo Application Services(EAS)는 React Native 앱을 빌드, 제출, 업데이트하는 과정을 단순하게 만들어줍니다. 하지만 팀 규모와 빌드 빈도에 따라 비용 구조를 이해하고 써야 합니다.