수동 APK에서 자동화된 플레이 스토어 배포까지: 단일 코드베이스로 두 개의 안드로이드 앱을 출시하면서 우리가 저지른 모든 실수
(dev.to)
단일 코드베이스로 두 개의 안드로이드 앱을 배포하는 과정에서 EAS 무료 티어의 한계를 극복하기 위해 GitHub Actions 기반의 자동화 파이프라인을 구축하며 겪은 버전 관리, 구글 플레이 오류, CI/CD 설계상의 시행착오와 해결책을 다룹니다.
이 글의 핵심 포인트
- 1EAS 무료 티어의 빌드 대기열 문제와 로컬 빌드의 개발 생산성 저하를 해결하기 위해 GitHub Actions로 전환 시도
- 2Gitignored된 로컬 카운터 사용 시 CI 환경에서 버전 번호가 일치하지 않는 문제 발생
- 3Google Play 스토어의 versionCode는 모든 트랙에 걸쳐 엄격하게 증가해야 한다는 규칙 확인
- 4구글 플레이 스토어의 잘못된 에러 메시지로 인한 디버깅의 어려움과 트랙 관리의 중요성
- 5코드 병합(Merge)과 실제 앱 배포(Release) 프로세스를 분리하여 불필요한 재배포 및 심사 지연 방지
이 글에 대한 공공지능 분석
왜 중요한가?
개발 리소스가 부족한 초기 스타트업에게 클라우드 서비스(EAS)의 비용 최적화와 자동화된 배포 파이프라인 구축은 운영 효율성을 결정짓는 핵심 요소이기 때문입니다. 단순한 코드 작성을 넘어, 인프라 구축 과정에서 발생하는 예기치 못한 오류를 해결하는 능력이 제품 출시 속도에 직결됨을 보여줍니다.
어떤 배경과 맥락이 있나?
Expo와 같은 매니지드 서비스는 초기 개발 속도를 높여주지만, 빌드 수요가 늘어나면 비용 부담이나 대기열 문제가 발생합니다. 따라서 많은 팀이 비용 절감과 제어권 확보를 위해 GitHub Actions와 같은 범용 CI/CD 도구로 전환하려는 시도를 하게 됩니다.
업계에 어떤 영향을 주나?
개발자 개인의 로컬 환경에 의존하는 '수동 빌드' 방식이 스케일업의 장애물이 될 수 있음을 경고하며, 인프라 자동화(IaC)와 파이프라인 설계가 단순 기능 구현만큼 중요하다는 인식을 확산시킵니다.
한국 시장에 어떤 시사점이 있나?
빠른 출시와 피드백 루프를 중시하는 한국 스타트업 생태계에서, 비용 효율적인 클라우드 활용 전략과 안정적인 배점 자동화 구축은 기술 부채를 줄이고 개발 생산성을 극대화하는 필수 과제입니다.
이 글에 대한 큐레이터 의견
이 글은 단순한 '성공 사례'가 아니라, 인프라 구축 과정에서의 '실패 기록'이라는 점에서 매우 가치가 높습니다. 특히 매니지드 서비스(EAS)의 편리함 뒤에 숨겨진 비용적 한계와 이를 극복하기 위해 직접 파이프라인을 설계할 때 마주하게 되는 구체적인 기술적 난제들을 생생하게 전달합니다. 이는 개발 팀이 '편리한 도구'에서 '자체 제어 가능한 시스템'으로 넘어갈 때 반드시 거쳐야 할 관문입니다.
다만, 모든 스타트업이 이처럼 복잡한 자체 파이프라인을 구축할 필요는 없다는 점을 유의해야 합니다. GitHub Actions로 전환하는 과정은 초기 설정 비용(Engineering Overhead)과 유지보수 부담을 발생시킵니다. 만약 팀의 규모가 작고 빌드 빈도가 낮다면, 오히려 EAS의 유료 티어를 사용하는 것이 개발자의 시간을 아끼는 더 경제적인 선택일 수 있습니다. 따라서 '자동화 자체'를 목표로 삼기보다, 현재 우리 팀의 비용과 리소스 상황에 맞는 적절한 기술적 타협점을 찾는 안목이 필요합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.