[Challenge] 3주만에 앱스토어에 앱 출시하기 - 2부 작업 관리

Overview

본 글은 짧은 시간을 투자하여 앱스토어에 나만의 앱을 출시하고 싶은 독자를 대상으로 개발 가이드를 제공하고자 작성하였습니다. 1부에서는 앱을 기획하고 디자인하는 등 추상적 영역을 다루었습니다. 2부에서는 성과물을 만들어나가기 위해 필요한 작업 관리 방식의 전 과정을 조망시켜 드리겠습니다. 독자 여러분께서 포스팅을 읽고 "앱 개발 별거 아니네!" 생각할 수 있도록 인도할 수 있다면 본 포스팅은 목적을 달성하는 것입니다. 이전 포스팅을 읽지 않으셨다면 반드시 보고 오세요.

GoodJob!

[Challenge] 3주만에 앱스토어에 앱 출시하기 - 1부 기획과 디자인

개발 플로우

개발 작업에는 많은 관리가 필요합니다. 핵심적인 요소로 소스 코드의 형상 관리와 작업 플래닝 관리 등이 떠오르네요. 시중에는 여러가지 작업 관리 도구가 존재합니다만 우리는 시간이 부족하기 때문에 계획부터 개발까지 통합적으로 관리할 수 있는 도구를 선택해야 합니다. 아니면 분산된 자료를 동기화하는데 시간이 드니까요.

이번에 사용해볼 도구는 Git과 Github입니다. 다른 것들은 필요 없어요. 두 친구만 있으면 됩니다. Git은 소스 코드의 형상 관리를 위해 쓸 것이고요. Github 원격 저장소에 소스 코드를 형상 관리하고 작업 흐름 관리 내역과 소스 코드 개발 진척 사항 정보를 통합하여 관리하는 용도로 사용할 것이에요. 그리고 개발자의 친구이기 때문에 당장 친숙하게 사용할 수 있는 것도 큰 장점이죠.

원격 저장소 및 프로젝트 생성

서론이 좀 길었죠. 바로 들어가볼께요. 깃허브에 접속해서 자신만의 Repo를 생성해 보세요. Repo가 생성되면 상단에 코드, 이슈 등을 고를 수 있는 탭을 볼 수 있을 거예요. 여기서 프로젝트 탭에 들어가서 새로운 프로젝트를 생성해 주세요.

Github 프로젝트 생성하기

파란색으로 칠해진 New project를 선택하면 프로젝트를 생성할 때 사용될 초기 템플릿을 선택하는 창이 나와요. "테이블" 템플릿을 선택하여 주세요. 프로젝트 관리도구에 이름도 지어주세요. 프로젝트 네임 필드에 입력해 주면 됩니다.

Github 프로젝트 - 테이블 템플릿 활용 생성

작업 생성

프로젝트 생성을 마치면 눈앞에 웬 비어있는 테이블 하나가 보일 거예요. 이곳에 해야 될 작업을 적어주세요. 팀으로 구성되었다면 작업 담당자를 지정하고 진행도를 관리해 줄 수도 있으니 함께 활용해 보시면 좋아요.

이슈 전환

생성한 작업을 선택하면 "Convert to issue" 버튼을 눌러 해당 작업을 앞서 생성한 Repo의 issue로 만들어줄 수 있어요. Repo의 issue에서 체크박스를 활용한 투두 리스트를 만들어두고 완료된 작업을 소거해 나가면 프로젝트와 연계하여 작업 내용과 진척도, 담당자 등을 한 번에 추적할 수 있는 관리 환경이 구축되었습니다.

여기까지 오면 작업자의 Github 계정 혹은 프로젝트의 Repo의 issue에 관리자가 생성한 이슈 내역이 보입니다. 마일스톤 단위로 이슈를 관리하고 있다면 개별적으로 할당해 주는 등 평소에 이슈를 관리하던 방식대로 설정해 주세요.

브랜치 생성

이제 이슈와 소스 코드를 연관 지어 관리할 수 있도록 브랜치를 생성해 줄 거예요. issue 페이지의 우측 Development 섹션에 보면 이슈와 연계하여 Git 브랜치를 생성할 수 있는 기능이 보일 것이에요. 새로운 브랜치를 생성해 주세요.

브랜치 네이밍의 경우 필자는 (이슈번호)-(목적)-(작업요약내용) 형식으로 지어주었어요. 예를 들어 1-dev-buildEnvironment 이런 식으로 적으면, 1번 이슈에 대한 개발 사항으로 개발 환경 구축을 진행한다. 이런 식으로 해석할 수 있겠네요. 주의할 점이라면 브랜치 이름에 한글을 사용하지 마세요.

Github 브랜치 생성

브랜치 생성이 완료되었다면 여러분의 로컬 컴퓨터에 Github에서 생성한 브랜치를 불러오고 checkout을 통해 변경해주어야 합니다. origin에서 변경 사항을 fetch 해온 후에 checkout을 통해 생성한 브랜치로 변경해 주시면 됩니다.

git fetch origin
git checkout 1-dev-buildEnvironment

개발 진행 및 변경 사항 커밋

로컬 컴퓨터에 브랜치까지 설정이 완료되면 필요한 개발을 진행합니다. 변경 사항을 커밋할 때 커밋 메시지의 양식은 카르마 스타일을 활용합니다. 주의할 점이 있다면 커밋 메시지 subject의 마지막에 이슈 번호를 함께 넣어주어야 커밋 로그가 이슈에 함께 추적됩니다. 예를 들어 1번 이슈와 연관 지어 커밋 로그를 관리한다면 #1을 넣어주는 방식입니다.

Git 커밋 메시지 작성창

Karma - Git Commit Msg

로컬의 변경 사항을 Github Repo에 푸시하면 이슈 페이지에 커밋 로그가 다음과 같이 추적됩니다. 다음과 같이 할당된 작업을 구현하고 소거해 나갑니다.

Github 이슈에 추적되는 커밋 로그

코드리뷰 및 main 병합

이슈에 할당된 작업이 모두 완료되면 main 브랜치에 병합해야 합니다. main 브랜치는 CI/CD 연동을 통한 배포 자동화가 구현될 수 있는 브랜치이기에 병합 대상 소스코드 형상을 수차례 검토하여 병합해주어야 합니다.

코드 리뷰 과정은 Pull Request를 활용할 것입니다. Repo 상단 탭의 Pull requests 탭에 들어가서 새로운 PR을 생성하세요. 현재 브랜치의 형상을 main 브랜치에 병합하도록 설정해 주는 것이 중요합니다.

PR을 작성하는 규칙이 있다면 팀의 규약을 좋고요. 아니라면 주요 작업 사항이나 변동 사항을 기록해 둡니다. PR을 생성한 후 리뷰어와 열정적인 코드 리뷰를 거치세요. 1인 개발인 경우 GPT 등의 AI 코드 리뷰 도구가 생겨나고 있다고 하니 함께 찾아보시면 좋을 것 같아요.

코드 리뷰가 완료되면 PR 페이지 하단의 merge pull request 버튼을 선택해 주세요. 여기까지 오시면 하나의 작업이 마무리된 것입니다. 

merge 버튼

PR을 통해 main 브랜치에 병합까지 완료되면 프로젝트 페이지로 돌아왔을 때 이슈를 생성했던 작업의 상태가 "Done"으로 바뀝니다.

프로젝트 관리 페이지 변경 사항

마무리

여기까지 오시느라 수고하셨습니다. 이번 시간에는 제가 사용한 소스 코드 형상 관리와 연계한 프로젝트 작업 관리 방식을 소개해드렸습니다. 관리의 영역은 팀이나 개인의 개성과 성향을 많이 타는 영역이라고 생각합니다.

제가 초점을 두었던 부분은 익숙한 도구를 사용하여 작업 플로우 간의 통합된 경험을 구축하는 것이었습니다. 제가 사용한 방식을 참조하여 자신에게 적합한 작업 플로우를 구축해 보세요!