도입 배경: 반복적이고 번거로운 배포, 그리고 실수의 위험
프로젝트의 모듈화는 Tuist를 통해 잘 되어 있었지만, 배포 과정만큼은 여전히 사람이 직접 모든 단계를 수행해야 했다. feature 브랜치에서 개발 후 develop으로 병합, 버전/빌드 넘버 수동 증가, main으로 병합, 그리고 Xcode에서 아카이브 후 App Store Connect로 전송, 빌드 선택 및 배포까지... 이 모든 과정을 매번 반복하다 보니, 실수로 빌드 넘버를 올리지 않거나 인증서가 꼬이는 등 문제가 자주 발생했다.
무엇보다, 이런 반복적인 작업에 시간을 쏟다 보니 정작 중요한 개발에 집중하기 어려웠고, "이걸 자동화할 수 있다면 얼마나 좋을까?"라는 생각이 간절했다.
Fastlane 도입 및 Lane 설계
이러한 비효율을 해결하기 위해, 가장 먼저 Fastlane을 도입하여 로컬 환경에서의 배포 자동화를 목표로 삼았다. Fastfile에 다음과 같이 핵심적인 레인(lane)을 설계했다.
-
sync_certificateslane:match를 사용하여 Git private 레포지토리에 저장된 인증서와 프로비저닝 프로파일을 동기화한다.- CI/CD 환경을 고려하여
create_keychain으로 임시 키체인을 생성하고,app_store_connect_api_key로 App Store Connect API 인증을 처리하도록 구성했다.
-
betalane:- TestFlight 배포를 위한 메인 레인이다.
- 빌드 번호를 자동으로 증가시키고,
sync_certificates를 호출하여 인증서를 맞춘 뒤,build_ios_app으로 앱을 빌드하고upload_to_testflight로 업로드하는 전 과정을 하나로 묶었다.
이제 터미널에 bundle exec fastlane beta라는 명령어 하나만 입력하면, 이 모든 과정이 자동으로 처리되는 기반을 마련했다.
🧨 Fastlane 구축 과정의 시행착오
Fastfile을 설계하고 실제로 적용하는 과정은 순탄치 않았다. 로컬 자동화를 구축하며 겪었던 주요 시행착오는 다음과 같다.
1. Ruby 환경 설정의 늪
로컬 환경의 Ruby 및 Bundler 버전이 CI/CD 환경과 달라 생기는 충돌을 막기 위해 Gemfile을 신중하게 설정해야 했다. 특히, 초기 Gemfile의 xcodeproj 버전 제한 때문에 Tuist로 생성된 최신 프로젝트 구조와 호환성 문제가 발생했다. 버전 제한을 유연하게 풀고 bundle update를 통해 의존성을 맞추는 과정이 필요했다.
2. Tuist 프로젝트와 빌드 오류
fastlane으로 빌드 시, Tuist로 분리된 테스트 타겟의 파일들이 메인 앱 타겟에 잘못 포함되어 XCTest 관련 링크 에러가 발생했다. 이는 fastlane의 문제가 아닌 프로젝트 설정의 문제로, Xcode에서 직접 테스트 파일의 Target Membership을 정확히 분리하여 해결했다.
3. 유연한 버전 관리 전략
fastlane의 increment_version_number는 패치 버전 관리에는 유용했지만, 1.0.0 → 2.0.0과 같은 메이저/마이너 업데이트에는 유연성이 부족했다. 이를 해결하기 위해, beta lane에 아래와 같이 직접 버전을 지정하는 로직을 추가하고 상황에 따라 주석 처리하며 사용하는 방식을 고안했다.
lane :beta do
# (1) 큰 업데이트 시 원하는 버전으로 직접 지정
increment_version_number(
version_number: "2.0.0",
xcodeproj: "ToMyongJi.xcodeproj"
)
# (2) 평소에는 빌드 넘버만 자동 증가
increment_build_number(...)
# ... build & upload ...
end이를 통해 평소에는 빌드 넘버만 올리고, 필요시에는 원하는 버전으로 쉽게 업데이트할 수 있는 유연한 버전 관리 체계를 갖출 수 있었다.
결론: 로컬 자동화의 완성, 그리고 새로운 과제
Fastlane 도입을 통해, 터미널 명령어 하나로 TestFlight 배포까지의 모든 과정을 처리하는 로컬 자동화를 완성할 수 있었다. 이로써 반복 작업에서 오는 실수의 위험을 크게 줄이고, 개발자는 코드에만 집중할 수 있는 환경의 기반을 마련했다.
하지만 이것은 절반의 성공이었다. 이 강력한 로컬 자동화를 GitHub Actions와 연동하여 "PR 머지 시 자동 실행"이라는 최종 목표를 달성하는 과정에서는 또 다른 차원의 문제들이 기다리고 있었다. CI/CD 환경의 Secrets 관리, 인증 방식의 차이, pull_request와 push 트리거의 보안 정책 등 fastlane만으로는 해결할 수 없는 새로운 과제들을 마주해야만 했다.
