개발 빌드 공유하기

개발을 설치하여 팀과 공유하거나 여러 기기에서 실행하는 방법을 알아본다.

안드로이드와 iOS 모두 개발자가 앱의 특정 빌드를 기기에 직접 설치할 수 있는 방법을 제공한다. 이를 통해 개발자는 앱 배포 과정을 훨씬 더 유연하게 제어할 수 있다.

일반적으로 앱을 배포하려면 앱스토어를 통해야 한다. 하지만 앱스토어 심사 과정은 시간이 오래 걸리고, 심사를 통과하지 못하면 배포 자체가 불가능해진다. 또한 한 번 배포된 버전을 수정하려면 다시 심사를 받아야 하므로 빠른 반복 개발이 어렵다.

반면 기기에 직접 설치하는 방식은 이런 제약에서 자유롭다. 개발자가 원하는 빌드를 언제든 원하는 기기에 배포할 수 있다. 이는 다음과 같은 이점을 제공한다:

1. 빠른 이터레이션 - 새 빌드를 만들면 앱스토어 심사 없이 바로 테스트 기기에 배포할 수 있다. 이를 통해 개발 과정에서 매우 짧은 주기로 코드를 수정하고 테스트하는 것이 가능해진다.
2. 다양한 빌드 테스트 - 예를 들어 앱의 실험적인 기능을 특정 빌드에만 포함시켜서 일부 사용자들에게만 배포할 수 있다. 안정 버전과 베타 버전을 동시에 테스트하는 것도 가능하다.
3. 팀 협업 - 개발 중인 앱 빌드를 QA 팀, 디자이너, 매니저 등 관련 팀 구성원들의 기기에 곧바로 배포할 수 있다. 이를 통해 다양한 피드백을 빠르게 수집하고 개발에 반영할 수 있다.
4. 다양한 테스트 환경 - 앱이 다양한 기기와 OS 버전에서 어떻게 동작하는지 테스트하기 위해, 해당 기기들에 직접 설치하여 검증할 수 있다.

이런 장점들 덕분에 기기에 직접 설치하는 방식은 앱 개발 과정, 특히 개발 후반부의 테스트와 디버깅 단계에서 널리 사용된다.

안드로이드에서는 APK 또는 AAB 파일을 기기에 직접 설치할 수 있고, iOS에서는 Ad Hoc 또는 Enterprise 배포 옵션을 통해 IPA 파일을 설치할 수 있다. Expo의 경우 eas build 와 eas submit 명령을 통해 이 과정을 지원하고 있다.

다만 이 방식은 앱스토어 배포를 완전히 대체할 순 없다. 앱스토어를 통해야만 불특정 다수의 사용자에게 도달할 수 있기 때문이다. 따라서 개발 과정에서는 기기 직접 설치를 활용하되, 최종적으로는 앱스토어에 배포해야 한다.

또한 이 방식을 사용할 때는 앱 서명, 프로비저닝 프로필 관리, 인증서 관리 등 앱 배포 과정에 필요한 개념들을 잘 이해하고 있어야 한다. 앱 빌드 과정에서 이런 부분들을 적절히 처리해야 앱을 기기에 설치할 수 있게 되므로, 관련 지식을 습득하는 것이 중요하다.

Expo는 eas device:create, eas build:resign 등의 명령을 통해 이런 복잡한 과정들을 많이 추상화하고 있다. 하지만 그럼에도 기본 개념을 이해하고 있다면 개발 과정에서 맞닥뜨릴 수 있는 다양한 문제 상황들을 훨씬 수월하게 해결할 수 있을 것이다.

URL 공유

개발 빌드가 준비되면 빌드를 위한 공유 가능한 URL이 생성되며, 이를 실행하는 방법에 대한 지침이 함께 제공된다. 이 URL을 팀원과 함께 사용하거나 테스트 기기로 보내 빌드를 설치할 수 있다. 생성된 URL은 프로젝트의 빌드에 고유하다.

Expo 대시보드 사용

팀원이 직접 Expo 대시보드의 빌드 페이지에서 빌드 아티팩트를 다운로드할 수 있다.

EAS CLI 사용

팀원은 EAS CLI를 사용하여 개발 빌드를 다운로드하고 설치할 수도 있다. 개발 빌드와 연결된 Expo 계정에 로그인되어 있는지 확인한 후 다음 명령을 실행한다:

eas build:run --profile development

개발 빌드의 프로필 이름이 development 가 아닌 경우 --profile 과 함께 해당 이름을 대신 사용한다.

iOS 전용 지침

eas build:resign 은 iOS 앱 배포 과정을 크게 단순화해주는 강력한 도구다. iOS에서 앱을 기기에 설치하려면 앱에 서명된 프로비저닝 프로필이 필요한데, 이 프로필에는 앱을 실행할 수 있는 기기들의 UDID(Unique Device Identifier)가 포함되어 있다. 따라서 새로운 테스트 기기를 추가하려면 일반적으로 다음과 같은 과정을 거쳐야 한다:

1. 애플 개발자 센터에서 새 기기를 등록
2. 새 기기를 포함하는 새로운 프로비저닝 프로필 생성
3. 새 프로비저닝 프로필을 사용하여 앱을 다시 빌드
4. 새로 빌드된 앱을 테스트 기기에 설치

이 과정은 꽤 복잡하고 시간이 소요된다. 특히 3번 단계에서 앱 전체를 처음부터 다시 빌드해야 하므로, 빌드 시간이 긴 대형 앱의 경우 상당한 오버헤드가 발생할 수 있다.

바로 이런 상황에서 eas build:resign 명령이 유용하다. 이 명령을 사용하면 기존의 IPA 파일에 새로운 프로비저닝 프로필을 적용할 수 있다. 따라서 앱 자체를 다시 빌드하지 않고도 새 기기를 지원하도록 앱을 업데이트할 수 있다.

예를 들어, 다음과 같이 사용할 수 있다:

eas build:resign --platform ios --profile adhoc --provisioning-profile-path ./new-profile.mobileprovision ./my-app.ipa

이 명령은 ./my-app.ipa 파일에 ./new-profile.mobileprovision 프로비저닝 프로필을 적용하여 새로운 IPA 파일을 생성한다. 새로 생성된 IPA 파일은 프로비저닝 프로필에 포함된 모든 기기에서 실행될 수 있다.

이 방법의 장점은 다음과 같다:

1. 빌드 시간 절약 - 전체 앱을 다시 빌드할 필요가 없으므로 많은 시간을 절약할 수 있다.
2. 간편한 기기 추가 - 새 테스트 기기를 추가하는 과정이 매우 간소화된다.
3. 유연한 배포 - 다양한 테스트 그룹을 위한 맞춤형 IPA 파일을 쉽게 생성할 수 있다.

단, 이 방법은 앱 코드 자체에는 변경이 없고 프로비저닝 프로필만 변경하는 경우에 사용할 수 있다. 앱 코드를 수정했다면 반드시 앱을 다시 빌드해야 한다.

또한 eas build:resign 을 사용하려면 원본 IPA 파일과 새 프로비저닝 프로필이 모두 필요하다. 원본 IPA 파일은 Xcode나 eas build 를 통해 얻을 수 있고, 프로비저닝 프로필은 애플 개발자 센터에서 생성해야 한다.

이런 제약사항들을 고려해야 하지만, 전반적으로 eas build:resign 은 iOS 앱 배포 과정을 크게 개선해주는 유용한 도구다. 특히 많은 테스트 기기와 테스터들이 관련된 대규모 프로젝트에서 그 효용성이 돋보일 것이다. 자세한 내용은 여기를 참조한다.

다음 단계

• 동일한 기기에 여러 앱 변형 설치

app.json 을 app.config.js 로 변환하고 각 변형의 개발 서버를 시작하는 데 필요한 추가 설정을 통해, 동일한 기기에 앱의 여러 변형(개발, 미리보기, 프로덕션)을 나란히 설치하는 방법을 알아본다.

• 앱의 사전 공개 버전 공유

앱의 사전 공개 버전 공유에 대해 자세히 알아본다.