Overview

작년부터 브랜디 랩스는 다수의 좋은 개발자분들을 모시기 위해 코드네임 B, 스코페 등의 코딩 페스티벌을 개최하고, 이외에도 상시로 지원을 받고 있습니다. 면접을 진행하면서 지원자분들이 질문하셨던 부분을 정리해 브랜디 iOS 개발 파트는 어떻게 업무하고 있는지 소개 드리고자 합니다.

1. 업무분장 및 개발기간 산정

브랜디는 최근 PO 조직으로 변경되면서 업무 진행 방식에 변화를 주고 있습니다.

기존 방식 (WaterFall)

브랜디에서 업데이트 작업 단위를 차수라고 부릅니다. 브랜디, 하이버, 마미 각각 개별적으로 차수가 진행됩니다. 서비스별 담당자를 따로 나누진 않았고, 작업량에 따라 유동적으로 인원을 배치하였습니다. 차수에 포함될 기획과 디자인이 확정되면 업무분장 회의를 열고, 기능별로 담당자를 정합니다. 회의의 시작은 기능을 나열해 놓고, 자원을 받습니다. 보통 본인이 이전에 했던 부분이나 리펙토링을 진행하고 싶은 부분, 본인이 흥미를 가지고 있는 기술 위주로 가져갑니다. 이외 남은 기능은 업무량을 고려해 분배합니다. 브랜디에 합류하고 가장 마음에 들었던 부분은 개발 기간을 개발자가 정하는 것이었습니다. 업무분장이 끝나면 먼저 API 완료 일정을 공유 받고, 기능별 개발 완료 일정을 산정합니다. 그 후 QA 일정을 산정하고, 관련 부서들에 모두 공유되면 개발이 시작됩니다. 개발자가 직접 일정을 산정하였기 때문에 일정은 반드시 지키는 것이 원칙입니다. 개발 중 이슈가 발생하여 일정을 늘려야 하면 유관부서와 협의 후 변경합니다. 마케팅 등 타이밍 이슈가 있어 일정 변경이 불가능한 경우 우선순위가 낮은 스펙을 다음 차수로 이관하여 조정합니다.

PO (애자일)

일정 산정 시 개발자가 개발 기간 산정하는 것은 동일하지만 업무분장에 변화가 있습니다. 작은 단위로 빠르고 능동적으로 움직이기 위해 각 서비스별로 소수 인원의 담당자를 지정하였습니다. 이들을 스쿼드 멤버라 지칭하고, 담당자들은 기술적인 커뮤니케이션을 하고, 해당 서비스 위주로 개발합니다. 스쿼드에 속하지 않은 인원은 유동적으로 프로젝트에 할당됩니다. 현재 브랜디 서비스들에 대한 이해도가 높은 시니어 개발자분들을 스쿼드 멤버로 설정하고, 주니어 개발자분들은 모든 서비스를 다 경험하도록 운영 중입니다.

2. 코드리뷰

Git-Flow

iOS 파트의 Git-Flow는 아래와 같습니다

athena

develop 브랜치에서 feature 별로 feature/(기능) 브랜치를 생성하고, 작업이 완료되면 develop으로 병합합니다. 차수 작업이 완료되면 develop 브랜치를 release에 병합하고, release/(release 버전)(예: release/2.21.0)으로 브랜치를 생성합니다. 이후 내부 QA 진행 시 발생한 이슈는 새로 생성한 release 버전 브랜치에서 서브 브랜치를 생성하여 작업합니다. QA가 마무리되고, 앱이 배포되면 release 브랜치를 master, develop 브랜치에 병합 후 완료됩니다.

코드 리뷰

작업 후 부모 브랜치에 병합하기 전 반드시 코드 리뷰를 거쳐야 합니다. 브랜디는 Git 저장소를 AWS CodeCommit을 사용하고 있습니다. 코드 리뷰는 주로 온라인으로 진행되며 CodeCommit의 Pull Request(이하 PR)을 이용합니다. AWS에서 제공하는 SlackBot을 연결하여 PR 생성, 코멘트, 병합 등의 이벤트에 대한 알림을 슬랙 채널로 받고 있습니다. PR 승인 룰은 2인 이상 승인되어야만 병합 가능하도록 설정하였습니다. 온라인 코드 리뷰는 수정 부분만 보이기 때문에 전체적인 흐름을 알기 힘들고, 따라서 개발자의 의도를 파악하기 힘듭니다. 때문에 commit log와 PR 설명을 되도록 자세히 적는 것을 권장하고 있습니다. 중요한 기능의 경우 리뷰자가 직접 브랜치를 pull 받아 확인합니다.

서비스에 영향도가 크거나 중요도가 높은 작업은 오프라인 코드 리뷰를 진행합니다. 오프라인 코드 리뷰 선정은 차수 시작 전 업무분장 회의에서 결정합니다.

3. 배포

Slack의 ci 채널에 ‘/배포’ 메시지를 입력하면 배포 환경설정 팝업이 노출됩니다. 설정 후 ‘배포’ 버튼을 탭 하면 배포머신(Mac mini)에서 트리거 된 이벤트를 받아 fastlane으로 배포하고 있습니다.

athena

배포는 세 가지 방법이 있습니다.

QA 배포 (Debug)

브랜디는 앱 심사를 올리기 전 반드시 QA팀이 확인합니다. 차수 작업과 같이 수정사항이 많은 경우 대략 5일 이상의 QA 기간을 가지고, hotfix의 경우 크리티컬 테스트를 진행합니다. QA 배포는 Firebase 앱 배포를 이용합니다. SNS 로그인, 리모트 푸시 등의 테스트에 제약이 있고, 프로젝트 관리 이슈 등의 이유로 엔터프라이즈 계정은 사용하지 않고 있습니다. 브랜디는 서버 환경을 스프린트, 스테이징, 상용 세 개로 운용하고 있습니다.

  • 스프린트: 개발 중인 작업이 적용되는 서버
  • 스테이징: 테스트 서버
  • 상용

QA 진행 시 각 서버 환경으로 세 개의 앱을 배포하지 않기 위해 Settings Bundle을 사용하고 있습니다.

athena

(그림: 번들 파일들)

athena

(그림: Settings_Debug.bundle plist 구성)

폴더에 Settings.bundle, Settings_Debug.bundle, Settings_Release.bundle 세 개의 파일을 생성하고, xcworkspace에는 Settings.bundle 파일만 링크 추가하였습니다. 프로젝트 빌드 할 때 디버그인지 릴리스인지 체크하여 Settings.bundle 파일에 복사하도록 되어있습니다. Settings_Release.bundle은 서버 설정이 노출되지 않도록 아무런 내용이 없는 파일입니다. 복사하는 스크립트는 Build Phases에 추가하였습니다.

athena

(번들 복사 스크립트)

athena

(AppDelegate.swift 서버환경 설정 코드)

‘DEBUG’는 Build Settings → Swift Compiler - Custom Flags → Active Compliation Conditions에 추가한 키워드입니다. DEBUG인 경우에 UserDefaults에 저장되어 있는 Settings Bundle 설정값을 가져와 클라이언트 서버 환경을 설정합니다. 릴리스 빌드는 무조건 .production으로 설정합니다.

06
07

(Debug 빌드 설정 화면)

설정에서 서버를 변경 후 앱 재실행하면 적용됩니다.

TestFlight 배포 (Debug)

브랜디 구성원이 늘어나 최근 애플 개발자 계정에 등록 가능한 디바이스 한계인 100대에 도달하게 되었습니다. 위에서 언급한 대로 엔터프라이즈는 사용하지 않기로 하였고, TestFlight 내부 테스트는 인원에 제한이 있어 인원 제한이 10,000명인 외부 테스트를 이용하여 배포하기로 결정하였습니다. 외부 테스트는 애플 심사를 받아야 하고, 바이너리 업로드 프로세싱에 시간이 걸리므로 배포 후 테스트까지 상당한 시간이 소요됩니다. 때문에 QA팀, 디자인팀, 개발팀은 기존과 같이 개발자 계정에 등록된 기기를 사용하여 Firebase 앱 배포를 이용하고, 이외 사업 부서나 기타 테스트 버전이 필요한 인원은 외부 테스트를 이용합니다. 혹여나 Debug로 빌드 된 바이너리를 심사에 제출하는 실수를 방지하기 위해 fastlane+badge를 이용하여 앱 아이콘에 BETA 태깅을 하도록 설정하였습니다.

athena

(그림: TestFlight에 업로드 된 Debug 버전. 버전과 빌드 넘버까지 표시 가능)

상용 배포 (Release)

Settings Bundle의 서버 설정과 코드 내 디버깅용 print등을 제거하여 빌드 합니다.

4. 기술 회의

iOS 파트 인원의 성장을 위해 기술 공유 및 토론하는 시간을 가지고 있습니다.

주간 기술 회의

매주 화요일 오후에 회의를 합니다. 회의는 스터디, 기술 공유, 토론 등으로 진행됩니다. 최근 관심을 가지고 진행하는 건은 전체 리뉴얼입니다. Testability를 최우선으로 생각하여 Architecture 및 상세한 구조까지 구현 방법을 논의하고 있습니다. 그리고, 브랜디에서 서비스 중인 앱들의 deployment target을 근 시일 내에 iOS 13.0으로 변경할 예정이라 SwiftUI를 바로 적용하기 위해 관련 기술들을 스터디하고 있습니다.

CodeWorkshop

개발 중 마주쳤던 이슈나 새로 알게 된 것들을 간단하게 정리하여 공유합니다. 장대하게 문서를 작성하지 않고, 장표 1~2장 정도로 노션에 정리 후 공유합니다.

그 외…

위 두 가지 방법 이외에도 이슈들이나 앱 내 복잡한 플로우(예: 구매 절차) 등을 노션에 문서화하여 공유합니다.

마치며

브랜디 랩스에서 다양한 경험을 같이하고 성장하실 분들을 모시고 있습니다. 저희 iOS 파트는 새로운 것을 적용하는데 제한을 두지 않고, 자유롭게 개발하고 있습니다. 문제에 대해 같이 고민하며 재미있게 개발하실 분들과 함께하고자 합니다.

글
김중원 | MA팀
kimjw2@brandi.co.kr
브랜디, 오직 예쁜 옷만