[Mobile] "배포해 줘"로 끝내는 Fastlane 자동화 🚀
안녕하세요
인티그레이션의 PM 스쿼드에서 린다이어트 앱을 개발하고 있는 Mobile Engineer 한승재입니다.
앱을 배포하다 보면 더 좋은 방법이 없을까 하는 고민을 하게 됩니다. 이 글은 불편했던 배포를 편하게 개선시킨 경험을 공유하려고 합니다.
어떤 것이 문제인가
모바일 앱 개발자라면 배포 날마다 겪는 '그 시간'을 아실 겁니다. Fastlane을 도입해서 배포 과정을 자동화했지만, 여전히 터미널 앞을 떠나지는 못했죠.
🤷 개발자 A: "배포 명령어가 뭐였더라?
fastlane ios beta? 아님deploy?"
🤦 개발자 B: (오타 발생) "아...fastlane depoly라고 쳤네. 다시..."
⏰ 개발자 C: "Android 빌드 끝났나? 이제 iOS 돌려야 하는데... (멍하니 모니터 응시)"
분명 스크립트는 자동화되었는데, 그 스크립트를 실행하고 기다리고 다음 명령어를 입력하는 '나 자신'은 자동화되지 않았습니다.
그래서 발상을 바꿔봤습니다. "명령어를 외워서 치지 말고, 그냥 AI한테 말로 시키면 안 될까?"
최근 터미널 환경에서 직접 동작하는 Claude Code의 Skills(도구 사용 능력)를 활용해, 터미널에 "배포해 줘"라고 사람에게 말하듯이 입력하면 알아서 Fastlane을 구동해 주는 배포 부사수를 영입한 경험을 공유합니다.
1. 왜 Claude Code인가? (단순 챗봇 vs 에이전트)
보통의 AI에게 "배포해 줘"라고 하면 "배포 스크립트는 이렇습니다~"라며 코드를 던져주고 끝납니다. 복사해서 붙여넣는 건 결국 제 몫이죠.
하지만 터미널 기반의 Claude Code는 다릅니다. 이 친구는 내 로컬 환경에 상주하며 직접 행동(Action)을 취할 수 있는 에이전트(Agent)입니다.
Claude Code가 가진 핵심 Skills는 다음과 같습니다.
- 📂 File Read: 프로젝트 구조를 탐색하고
Fastfile을 직접 읽어 어떤 Lane이 있는지 파악합니다.
- 💻 Bash Command: 분석한 정보를 바탕으로 터미널 명령어를 직접 실행합니다.
- 🔗 MCP (Model Context Protocol): 필요한 경우 Slack, Atlassian 등 외부 도구와도 연동할 수 있습니다.
이 능력들을 조합하면, "사람이 문서를 읽고 명령어를 치는 과정" 자체를 AI에게 위임할 수 있습니다.
2. "배포해 줘"가 동작하는 과정
저희 팀(린다이어트)은 이미 iOS와 Android 배포를 위한 Fastfile이 세팅되어 있는 상태였습니다. 저는 터미널을 열고 Claude Code를 실행한 뒤, 딱 한 마디만 건넸습니다.
Prompt: "지금 dev 배포 좀 해줘."
이 한 마디에 Claude Code는 다음과 같은 사고(Thinking) 과정을 거치며 작업을 수행합니다.
① 상황 파악 및 파일 탐색 (Read Skill)
Claude는 먼저 프로젝트 구조를 훑어봅니다.
"잠깐, 배포를 하려면 설정 파일이 어디 있지?"
스스로 루트 디렉토리와 ios/, android/ 폴더를 탐색하다가 Fastfile을 발견하고 내용을 읽어들입니다. 제가 파일 경로를 알려주지 않아도 말이죠.
② Pre-flight 검증
파일을 파악한 Claude는 곧바로 명령어를 치지 않습니다. 먼저 배포 전 사전 검증(Pre-flight) 스크립트를 실행합니다.
✓ macOS 환경 확인
✓ Xcode / JDK 설치 확인
✓ FVM & Flutter SDK 확인
✓ ios/fastlane, android/fastlane 디렉토리 존재 확인
✓ .env.development 파일 존재 확인
⚠️ 커밋되지 않은 변경사항 2개 존재
📌 현재 브랜치: feature/PM-8958Xcode가 없거나 환경 파일이 빠져 있으면 여기서 배포를 중단하고, 무엇이 문제인지 알려줍니다. 빌드를 5분 돌린 뒤에야 실패를 마주하는 일이 사라진 거죠.
커밋되지 않은 변경사항이 있으면 경고를 띄워주고, "커밋하고 배포해줘"라고 하면 커밋까지 대신 처리한 뒤 배포를 이어갑니다.
③ 브랜치 기반 환경 자동 감지 — 실수 방지 가드레일
제가 "dev 배포"라고 말했지만, Claude는 한 번 더 확인합니다. 현재 체크아웃된 Git 브랜치를 기반으로 배포 환경을 자동 감지하기 때문입니다.
| 브랜치 패턴 | 감지 환경 |
|---|---|
main, release/* | production |
release/* | staging |
| 그 외 모든 브랜치 | development |
지금 제 브랜치가 feature/PM-8958이니 development 환경이 맞다고 판단하고 그대로 진행합니다.
만약 실수로 feature 브랜치에서 "prd 배포해줘"라고 했다면?
🤖 Claude: "⚠️ 현재 브랜치가
feature/PM-8958입니다. 프로덕션 배포는 보통main또는release브랜치에서 진행합니다. 정말 프로덕션으로 배포하시겠습니까?"
이런 대화형 확인은 CI/CD 파이프라인의 브랜치 보호 규칙과 비슷하지만, 실시간으로 맥락을 이해하고 되물어본다는 점에서 더 유연합니다.
④ 적절한 Lane 선택
Pre-flight과 환경 감지를 마친 Claude는 Fastfile 내부에 정의된 Lane들을 확인합니다. 저희 팀 Android 배포 방식이 여러 개라는 것을 파악하고, 저에게 명확한 의도를 다시 묻습니다.
🤖 Claude: "
Fastfile을 확인해보니 Android 배포 옵션이 여러 개네요.
- Firebase App Distribution (aab) — 권장
- Firebase App Distribution (apk)
- Play Store 내부 테스트
어떤 걸로 배포할까요?"
iOS는 TestFlight 단일 경로라 묻지 않습니다.
⑤ 명령어 직접 실행 (Bash Skill)
제가 "aab로 해줘"라고 답하면, Claude는 즉시 행동을 개시합니다.
# Claude가 스스로 타이핑하고 실행하는 명령어
$ cd android && fastlane deploy_aab --env development
$ cd ios && fastlane beta --env development터미널 화면에는 제가 직접 fastlane 명령어를 친 것처럼 빌드가 진행됩니다. 버전 코드 증가, Flutter 빌드, 코드 사이닝, 업로드까지 전부 자동입니다.
3. 결정적 차이: "순차 실행"의 해방
제가 이 방식을 도입하고 가장 편했던 점은 "기다림의 삭제"였습니다.
저희 팀은 빌드 안정성을 위해 flutter clean 명령어를 필수로 사용합니다. 이 명령어는 빌드 아티팩트(aab, ipa)를 모두 지우기 때문에, Android와 iOS를 동시에 빌드하기 어렵고 순차적으로 빌드해야만 했습니다.
[기존의 배포 루틴]
- Android 배포 명령어 입력
- (5~10분 대기) ☕️
- 빌드 끝났는지 확인하고, iOS 배포 명령어 입력
- (또 대기)
[Claude Code 도입 후]
- "Android랑 iOS 둘 다 배포해 줘." (입력 후 퇴근 준비 or 다른 업무)
- Claude가 알아서 Android 끝내고, 이어서 iOS 실행
이제 저는 모니터를 멍하니 지켜볼 필요가 없습니다. Claude가 앞 단계가 성공적으로 끝났는지(Exit Code 0) 확인하고, 다음 단계를 스스로 실행해주니까요.
4. 마무리: Mobile 개발자도 이제 '딸깍' 배포합니다
이번 적용기를 통해 인프라 자동화(DevOps)의 다음 단계가 무엇인지 명확히 느낄 수 있었습니다.
- Fastlane: 배포 과정을 코드로 정의한 '도구'
- Claude Code: 그 도구를 사람처럼 다루는 '부사수(Agent)'
이제 복잡한 Lane 이름이나 옵션을 외우지 않아도 됩니다.
그저 Claude 에게 해줘라고 하면 됩니다.
