안녕하세요! [생각하는 개발자]입니다.
지난 시간 우리는 여러 브랜치(Branch)가 얽히며 발생하는 공포의 충돌(Conflict) 상황을 직접 제압하고, 특히 iOS 개발자의 골칫거리인 .xcodeproj 충돌을 물리적으로 해결하는 팁까지 조각내 보았습니다.
이제 브랜치를 쪼개고 합치는 무기를 다룰 줄 알게 되었으니, 실제 현업 대형 프로젝트에서 이 무기들을 어떤 규칙과 질서 속에서 사용하는지 배울 차례입니다. 오늘 다룰 주제는 전 세계 IT 기업의 표준 브랜치 전략인 Git-Flow(깃 플로우)와 집단 지성으로 코드의 품질을 끌어올리는 Pull Request(PR) 시스템입니다.
4.4.1 캔버스 위에 재료 얹기 (현업 브랜치의 5대 계급도)
현업에서는 main 브랜치 하나에 모두가 달라붙어 개발하지 않습니다. 언제 배포될지 모르는 불완전한 코드가 섞이면 안 되기 때문이죠. Git-Flow 전략은 역할에 따라 브랜치를 딱 5가지 재료로 엄격하게 분류합니다.
- main (혹은 master): 유저가 앱스토어에서 다운로드받는 현재 출시된 라이브러리 및 앱 상태입니다. 언제나 100% 완벽하게 빌드가 성공하는 코드만 존재해야 합니다.
- develop: 다음 버전을 위한 개발 중심 줄기입니다. 기능 개발이 완료된 브랜치들이 모이는 통합 공간입니다.
- feature/기능명: 새로운 기능을 개발하는 독립된 방입니다. (예: feature/login, feature/signup) develop에서 뻗어 나와 작업 후 다시 develop으로 들어갑니다.
- release/버전명: 출시 직전 최종 테스트(QA)를 하는 공간입니다. 버그 수정만 진행하며, 완료되면 main과 develop 양쪽으로 병합됩니다.
- hotfix/버전명: 앱스토어에 출시된 앱에 치명적인 버그가 터졌을 때 긴급 수술하는 방입니다. main에서 바로 뽑아와 고친 뒤 즉시 배포합니다.
4.4.2 [단계별 실습] 코드 리뷰의 핵심, Pull Request(PR) 날려보기
내가 feature/login 브랜치에서 로그인 기능을 끝내고 develop 브랜치에 합치고 싶을 때, 로컬 컴퓨터에서 git merge 명령어로 냅다 합쳐버리는 것은 현업에서 금기시됩니다. 내가 짠 코드에 어떤 버그가 있을지 모르니까요.
대신 Git 플랫폼(GitHub, GitLab 등)에 "제가 코드를 이렇게 짰는데, develop에 합쳐도 될지 동료분들이 검토해 주세요!" 하고 정중하게 요청을 보냅니다. 이것이 바로 Pull Request(PR)입니다.
1단계: 내 기능 브랜치를 원격(GitHub)에 Push하기
작업이 끝난 코드를 내 로컬 컴퓨터에서 원격 저장소로 쏘아 올립니다.
git checkout feature/login
git add .
git commit -m "feat: 카카오 로그인 API 연동"
git push origin feature/login
2단계: GitHub에서 Pull Request 생성하기
- GitHub 저장소 페이지에 접속하면 샛노란 띠와 함께 Compare & pull request 버튼이 활성화되어 있습니다. 클릭해 줍니다.
- Base 브랜치를 develop으로, Compare 브랜치를 내 기능 브랜치인 feature/login으로 설정합니다. (매우 중요!)
3단계: 좋은 PR 본문 작성하고 동료 리뷰 받기
PR 본문은 내가 작성한 코드를 동료들에게 설명하는 프리젠테이션입니다. 아래와 같은 구조로 친절하게 적어두면 코드 리뷰 속도가 압도적으로 빨라집니다.
## 📌 작업 내용
- 카카오톡 간편 로그인 API 연동 및 SDK 탑재
- 로그인 성공 시 Access Token을 KeyChain에 안전하게 분리 저장
## 📸 스크린샷 (UI 변경이 있는 경우 필수!)
(여기에 시뮬레이터 구동 화면이나 스크린샷 첨부)
## 🧪 테스트 방법
1. 앱 실행 후 '카카오 로그인' 버튼 클릭
2. 카카오톡 앱 인증 후 정상적으로 홈 화면으로 진입하는지 확인
이렇게 PR을 올리면 팀원들이 내 코드 라인마다 댓글로 피드백을 주고받는 코드 리뷰(Code Review)가 시작됩니다. 모든 리뷰어의 승인(Approve)을 받으면 마침내 버튼을 눌러 Merge가 완료됩니다.
👨💻 안드로이드 개발자와의 비교 조각
안드로이드 진영에서도 Git-Flow 전략과 PR 프로세스는 완전히 동일하게 돌아갑니다. 대형 IT 기업일수록 모바일 파트(iOS, Android)가 같은 브랜치 네이밍 규칙을 공유하죠.
다만, PR 이후에 일어나는 CI/CD(지속적 통합/배포) 자동화 빌드 단계에서 미묘한 툴의 차이가 있습니다.
안드로이드는 PR이 올라오면 리눅스 기반 서버 환경에서 Gradle 빌드 스크립트와 Lint 검사를 가볍게 돌려 빌드가 깨지는지 자동 검증합니다. 반면 iOS는 Apple 생태계 특성상 반드시 macOS 운영체제가 탑재된 Mac 장비(Mac mini 서버 또는 Github Actions의 macOS runner, Xcode Cloud 등) 위에서만 빌드 검증이 가능합니다. 이 때문에 iOS 팀의 CI/CD 인프라 구축 비용이나 빌드 파이프라인 대기 시간이 조금 더 까다롭고 묵직하게 운영되는 편입니다.
🎯 오늘의 요약
- Git-Flow는 main, develop, feature, release, hotfix로 브랜치의 계급과 역할을 나누어 프로덕트를 안전하게 관리하는 전략이다.
- Pull Request(PR)는 원격 저장소에 코드를 합치기 전, 팀원들에게 검토를 요청하는 협업의 관문이다.
- 모바일 개발 환경에서는 PR 검증을 위해 플랫폼별(Mac 환경 등) 독자적인 자동화 빌드 시스템을 연동하여 코드 품질을 보장한다.
코드를 잘 짜는 것만큼이나 안전한 절차 속에서 소프트웨어를 릴리스하는 프로세스를 이해하는 것이 '프로 개발자'의 자격입니다.
이로써 코드보다 더 중요할 수 있는 4부 버전 관리와 협업 파트가 모두 끝났습니다! 정말 고생 많으셨습니다.
다음 장 [iOS 5-1]부터는 다시 짜릿한 UIKit 코드로 복귀하여, 앱의 화면과 화면을 다이내믹하게 연결해 주는 화면 전환의 모든 것(Navigation Controller, TabBar Controller, Segue)으로 돌아오겠습니다. 생각의 지평을 넓히는 개발자가 됩시다!
