역할 정리
- Gradle → "빌드 중심"
- Fastlane → "릴리즈 흐름 중심"
- 빌드, 테스트, 의존성 관리 등 프로젝트 내부 작업은 Gradle이 더 적합
- 스토어 업로드, 알림, 릴리즈 자동화 등 배포 프로세스 관리는 Fastlane이 편함
Gradle Tasks
장점
- 안드로이드의 기본 빌드 시스템이라 가장 표준적인 방식
- CI 환경에서 재현성과 안정성이 높음
- flavor / buildType / variant 처리에 자연스럽게 녹아 있음
- Kotlin DSL을 사용하면 프로젝트 코드와 일관성 유지가 쉬움
단점
- 스토어 업로드, 슬랙 알림, 릴리즈 노트 생성 같은 외부 연동은 직접 구성해야 함
- 배포 자동화까지 Gradle로 처리하면 스크립트가 복잡해질 수 있음
(빌드 로직과 릴리즈 로직이 한 파일에 집중될 가능성)
커스텀 Task 예시
Play 업로드를 Gradle에서 직접 처리하려면
com.github.triplet.play 플러그인을 적용한 뒤 업로드용 Task를 구성할 수 있습니다.
1️⃣ 플러그인 적용
plugins {
id("com.github.triplet.play") version "4.0.0"
}2️⃣ Play Publisher 설정
play {
serviceAccountCredentials.set(file("app/play-api-key.json"))
track.set("production")
defaultToAppBundles.set(true) // AAB 업로드
}serviceAccountCredentials: Play Console 서비스 계정 JSON 키 파일track: 업로드 대상 트랙 (production, internal, beta 등)defaultToAppBundles: AAB 기준 업로드 여부
3️⃣ Production 업로드 Task
val versionName = providers.gradleProperty("VERSION_NAME")
.orElse("unknown")
.get()
tasks.register("productionUpload") {
group = "productionUpload"
description = "프로덕션 Play 업로드"
// Release 번들 생성 + Play 업로드 Task 의존성 연결
dependsOn("bundleRelease")
dependsOn("publishReleaseBundle")
doFirst {
println("🚀 Production 업로드 시작합니다.")
println("📦 Version: $versionName")
}
doLast {
println("🎉 Production $versionName 버전 업로드 완료")
}
}bundleRelease: AAB 생성publishReleaseBundle: Play Publisher 플러그인이 제공하는 업로드 Task./gradlew productionUpload -PVERSION_NAME=1.2.3형태로 실행 가능
Fastlane
장점
- 배포 자동화에 특화된 도구
- Play Store 업로드, 버전 증가, 체인지로그 생성 등을 한 흐름으로 묶기 쉬움
- Android와 iOS를 같이 운영할 경우 하나의 도구로 통합 가능
- CI에서
lane하나로 릴리즈 프로세스를 정리할 수 있음
단점
- Ruby 기반 DSL이라 팀에 따라 낯설고 초기 세팅이 필요
- Fastlane 버전 관리/Ruby 환경 세팅 이슈 가능성
- 실제 빌드는 결국 Gradle을 호출하는 구조라, 빌드 자체를 대체하진 않음
Fastfile 파일 예시
default_platform(:android)
platform :android do
desc "Release AAB 빌드"
lane :build_release do
gradle(
project_dir: ".",
task: "bundle",
build_type: "Release"
)
end
desc "Play Console 프로덕션 업로드"
lane :publishReleaseToStore do
build_release
upload_to_play_store(
package_name: "com.fastlane.test",
track: "production",
release_status: "draft",
aab: "app/build/outputs/bundle/release/app-release.aab",
json_key: "app/play-api-key.json",
# 스토어 리소스/메타데이터 안 올릴 거면 아래 유지
skip_upload_apk: true,
skip_upload_images: true,
skip_upload_screenshots: true,
skip_upload_metadata: true
)
end
endSupply 설정 예시
json_key_file("app/play-api-key.json") # Path to the json
package_name("com.fastlane.test")🔹 Play Publisher vs Fastlane supply 차이
[Gradle Play Publisher]
- Play Console 서비스 계정으로 AAB 업로드 가능
- Gradle 중심 빌드에 자연스럽게 붙음
[Fastlane supply]
- 릴리즈 메타데이터(이미지, 설명, 체인지로그) 등 포함 배포 자동화에 편리
- 여러 트랙(qa/internal/production)을 lane으로 구성, 운영하기 좋음
CI 관점 비교
[Gradle 중심]
./gradlew productionUpload- 단순함
- 안드로이드 프로젝트에 최적화
[Fastlane 중심]
fastlane publishReleaseToStore- 하나의 lane으로 빌드 + 업로드 + 알림까지 처리
- 릴리즈 프로세스를 코드화하기 좋음
선택 기준
👉 프로젝트 구성과 팀 규모/조직 구조에 따라 선택
[Gradle]
- 안드로이드 단일 프로젝트 + 단순한 CI
- 1~2명 안드로이드 팀
[Fastlane]
- 스토어 업로드 자동화가 필요
- QA/기획/마케팅과 릴리즈 프로세스 협업 필요
- Android와 iOS를 함께 운영
- 릴리즈 승인 단계가 있는 조직
Gradle은 빌드 엔진, Fastlane은 릴리즈 자동화 도구로 역할
- Gradle은 빌드 시스템 중심으로 Play 업로드까지 확장 가능하지만, 배포 자동화가 복잡해질수록 설정과 관리 비용이 증가할 수 있음
- Fastlane은 빌드는 Gradle에 맡기고, 릴리즈·스토어 업로드·메타데이터·알림 등 배포 흐름을 통합 관리하는 데 강점이 있음
Android_Developer