백엔드가 이정도는 해줘야 함 - 3. 개발 프로세스 정립

이번엔 백엔드 포지션에서 어떤 방식으로 개발을 진행할지를 결정하자. 개발 프로세스 정립에 대해 두 가지의 의사결정을 진행할 것이다.

도입 이유

개발 프로세스 정립

개발 프로세스는 어떻게 이슈를 관리하고, 어떤 방식으로 작업을 진행하고, 완료된 작업은 어떤 과정을 거쳐서 실제 제품에 반영시킬지와 같은 것들을 규칙화시킨 것이다. 소프트웨어 공학적으로 들어가면 이래저래 얘기할 것 많겠지만 일단 '대충' 그렇다. 개발 프로세스의 정립이 필요한 이유는 다음과 같다.

• 프로젝트 관리자 입장에서 각 개발자에게 할당된 작업들이 어떤 상태인지(준비 중/진행 중/완료)를 쉽게 알 수 있다.

• 이슈를 실제로 처리하는 입장에서, 개발 프로세스에 따라 작업을 진행하면 어느 브랜치에서 어떤 이름으로 브랜치를 생성할지/어느 브랜치로 pull request를 올리며 리뷰를 받아야 할지/master merge 후 어떤 후속 작업을 진행해야 하는지와 같은 고민을 줄일 수 있다. 실제로 작성하는 코드에만 집중하는 환경을 만들 수 있다.

• 잘 정립된 개발 프로세스는 생산성을 높이는 것에 기여하며, 작업의 진행을 매끄럽게 만들고, 결과물의 퀄리티를 높인다.

이 의사결정에는 별도의 선택지가 없다. 스크럼이고 칸반이고 하는 정해진 프로세스가 많긴 하지만, 조직의 상황에 딱 맞는 개발 프로세스를 찾기는 어렵기 때문에, 기존의 개발 프로세스를 기반으로 하나씩 직접 정립해 보자.

의사결정

이슈 관리 도구

이슈 관리 도구를 결정하자. 이슈는 작업이라고 생각하면 된다. 작업을 기술함과 함께 나열하고, 작업을 처리할 작업자를 할당하는 등의 일을 위해 사용한다. 대부분의 조직은 이슈를 기반으로 움직이고, 나도 이런 흐름이 좋다고 생각한다. 이슈 관리 도구는 이슈 트래커라고도 부른다. JIRA를 쓰기도 하고, Trello를 쓰기도 하고, Google 스프레드시트를 쓰는 조직도 봤던 기억이 있다. 나는 과거에 Asana를 많이 썼었다.

배경과 요구사항

• 이슈 각각에 대해 작업자를 assign할 수 있다.

• 이슈에 대해 커뮤니케이션할 수 있어야 한다.

• 태그/라벨 등으로 이슈의 종류를 구분할 수 있어야 한다.(feature, hotfix, enhancement 등)

• 이슈의 상태(To do, In progress 등)를 구분해서 시각화할 수 있어야 한다.

• 되도록 GitHub 내에서 해결할 수 있으면 더 좋다.

선택지

• Asana

• Jira

• Trello

• GitHub Issues & Projects

의사결정

GitHub Issues & Projects를 선택하겠다. 그 이유는,

• Jira는 무조건 돈이 들어간다. 그렇다고 큰 메리트가 따로 있다고 생각이 들진 않는다. 큰 조직에서 매니저 급이 태스크를 관리할 때나 잘 쓰일 것 같은 트래커라고 생각한다.

• Trello는 모던한 형태의 태스크 관리 보드인데, 필요한 기능들이 잘 들어가 있고 괜찮은 툴이지만 지금의 요구사항으론 GitHub 외부의 트래커를 따로 쓸만한 이유가 없다.

• 위의 요구 사항을 모두 만족한다 - assign, issue conversation 기능이 있고, customized label과 filter by label 기능을 통해 이슈 종류 구분이 원활하고, projects에 issues 기능을 연동해 이슈를 시각화 가능하며, projects의 automation 기능을 통해 이슈 구분과 이슈 상태 자동 갱신도 가능하다.(이슈가 close되면, projects에서 'Done' 컬럼으로 자동 이동시키는 등)

• GitHub Issues에서 이슈를 등록하면 해당 이슈에 대한 번호가 매겨지는데, 커밋 메시지에 #123과 같이 그 번호를 명시해 두면 자동으로 해당 이슈가 링크되며 conversation할 때도 사용할 수 있다.(참고로 이건 Jira와 BitBucket을 연동하는 경우에도 가능하다.)

• 이슈 트래커를 위해 따로 돈을 내지 않아도 된다. private repository를 생성 가능하게 만들기 위해 Organization 유료 플랜을 결제하는 경우는 있을 수 있지만, GitHub issues와 projects는 항상 무료다. 아래의 캡처들은 순서대로 각각 Projects와 Issues 기능이다.

준비

1. 저번에 만들어뒀던 레포의 Projects 탭에 들어가 새로운 프로젝트를 하나 만든다. 프로젝트 템플릿은 아무거나 고르자. 나는 None으로 설정하고 직접 구성하려고 한다.

2. Projects에서 Column을 원하는 대로 만들고 automation을 설정하자. 컬럼을 만들 때 보이는 'Automation'이나, 만들어진 컬럼의 우측 상단에 있는 ... 버튼으로 드롭다운을 열고 'Manage automation' 버튼을 누르면 보여지는 화면에서 Automation preset과 그 하위 카테고리를 선택하여 자동화를 설정할 수 있다. 나는 새롭게 생성된 이슈를 To Do, 리뷰가 요청되어 approve를 기다리고 있는 pull request를 Review Requested, approve된 pull request를 Reviewed, close된 이슈를 Done이라는 이름의 컬럼에 자동화할 것이다. 위의 자동화들은 모두 automation preset에서 제공하는 기능이니 잘 찾아서 추가하기 바란다. 진행 중인 작업을 분류하기 위해 In Progress나, 나중에 조직이 커지며 품질 관리 과정이 생긴다면 Pending QA같은 컬럼이 추가될 수도 있을 것이다. 똑같이 해둘 필요 없으니, 입맛대로 만들기 바란다.

3. 이슈에서 사용할 custom label을 설정한다. Issues 탭에서 Labels 화면에 들어가면 된다. 사람마다 다른데, 나는 우선순위 관점에서 minor/major, 종류 관점에서 feature/bug/enhancement 정도로 나눠둘 것이다. 참고로 내가 평소에 프로젝트를 할 때는 major/minor/urgent, Non-code work/On-code work/Discussion 정도로 라벨을 만들어 둔다. 이건 나중에 필요할 때 추가하면 되니 대충 하고 넘어가자.

4. 위에서 만든 프로젝트를 지정한 채 이슈를 생성하고 close했을 때 이게 Projects에 잘 동기화되는지 확인한다. 아래는 각각 이슈 라벨 설정, 이슈 아이템, automation이 설정된 Projects 화면이다.

개발 프로세스 정립

이슈의 생성부터 작업이 제품에 반영되기까지의 사이클을 정리하자. Git에서 사용할 브랜칭 모델도 함께 정리될 것이다. 우리가 위에서 했던 걸로 따지면, 이슈는 최초에 'To Do'에 입력되고, 작업의 진척에 따라 오른쪽 컬럼으로 이동하는 식이기 때문에 프로세스는 칸반 기반이라고 생각하면 될 것 같다. 칸반에 대해서는 잘 가요 스크럼, 반가워요 칸반이라는 글을 보면 좋을 것 같다.

배경과 요구사항

• 너무 복잡할 필요가 없다.

• 개발 프로세스를 브랜치 lifecycle로 대응(ex. 작업 시작은 브랜치 생성, 작업 완료 후 브랜치 제거 등)시킬 수 있어야 한다.

의사결정

개발은 아래처럼 진행해보려 한다.

1. 개발자의 공수가 필요한 작업이 생기면, 알맞는 라벨과 함께 이슈를 생성하고, 프로젝트 보드와 동기화시키기 위해 Projects를 선택해 둔다. 이슈가 'To Do'에 위치할 것이다.

2. 해당 작업을 진행할 개발자가 정해지면, assign해 둔다.

3. 개발자는 issue/<이슈 번호> 네이밍을 가진 브랜치를 master에서 체크아웃한다. 이슈 번호가 9번이라면, issue/9같은 식이다.

4. 작업이 완료되면, master 브랜치로 pull request를 올린다. 이후 reviewer 기능을 통해 동료 개발자에게 리뷰를 요청하고, Projects를 선택해 둔다. pull request가 'Review Requested'에 위치할 것이다.

5. 리뷰가 approve되면 merge하고, 문제 없이 작업이 완료되었다면 issue를 close하고 작업 브랜치를 제거한다. pull request는 'Reviewed'로, 이슈는 'Done'으로 이동할 것이다.

사실 조직에 백엔드 개발자가 한 명이라 리뷰를 요청하거나 하는 것이 불가능하므로, 실제로 어플리케이션 개발에 착수했을 땐 리뷰 단계를 제외하겠지만 일단 이를 포함시켜 두기는 하자.

pull request를 올리지 않고 그냥 git merge 커맨드로 병합한 후 push하는 방법도 있지만, 리뷰 과정을 끼워두는 것이 더 안정적이다. 리뷰가 없다면 변경을 작업자만 알게 될 것이기 때문이다. 또한 작업용 브랜치를 체크아웃하는 이유는 master 브랜치의 코드는 항상 '현재 서비스에 적용되어 있는 상태'로 두려고 하기 때문이다. master의 코드는 항상 안정적인 상태로 둔다는 것이다. 나도 옛날엔 그냥 master에서 무작정 다 작업하고 그랬었는데, 대부분의 경우 이런 버릇은 좋지 않다.

위처럼 master에서 이슈 브랜치를 따는 것과 같은 룰을 브랜칭 모델이라고 부른다. git-flow, github-flow 이런 룰들이 많은데, 일단 우린 간단하게 master와 이슈 브랜치만 다뤄보는 걸로 시작하자. 브랜칭 모델에 대해 더 알아보고 싶다면 A Successful Git Branching Model (번역) 글을 읽어보자.

지금까지

• 버전 관리 시스템으로 Git을 사용하기 시작했다.
• Git 웹호스팅 서비스로 GitHub를 사용하기 시작했다.
• GitHub Issues와 Projects로 이슈 트래킹을 시작했다.
• 개발 프로세스와 브랜칭 모델을 정립했다.