Atlassian 엔지니어로 근무하며 기업들의 협업 도구(Jira, Confluence 등)를 운영하다 보니, 자연스럽게 체계적인 프로젝트 관리에 많은 관심을 가지게 되었습니다.
최근 사이드 프로젝트를 시작하면서 진행 상황을 효율적으로 관리할 시스템이 필요했고, 이슈 관리 툴로 GitHub Projects를 선택하게 되었습니다.
이번 글에서는 엔지니어의 관점에서 왜 GitHub Projects를 선택했는지에 대한 고찰과, 이를 Jira의 체계적인 이슈 관리 형태처럼 구성한 방법을 기록으로 남기고자 합니다.
왜 GitHub Projects인가?
Jira는 대규모 프로젝트와 엔터프라이즈 환경에서 매우 강력한 도구입니다. 하지만 소규모 인원이 빠르게 진행해야 하는 사이드 프로젝트 환경에서는 다음과 같은 점들을 고려해야 했습니다.
- 컨텍스트 스위칭(Context Switching) 제로: 개발자에게 탭 이동은 곧 피로도입니다. GitHub Projects는 코드가 있는 레포지토리 바로 옆에 붙어 있습니다. 브랜치 생성, 커밋, PR 상태 확인을 한 곳에서 끝낼 수 있다는 게 가장 큰 매력입니다.
- 가볍고 강력한 자동화: 복잡한 워크플로우를 설계할 필요 없이, GitHub 내장 기능(Workflows)만으로 ‘PR 올리면 Review로 이동’, ‘Merge 되면 Done으로 이동’ 같은 필수 자동화를 쉽게 세팅할 수 있습니다.
- 애자일(Agile) 요소의 완벽한 대체: GitHub의 Milestone, Iteration 기능을 잘 조합하면 Jira의 Sprint나 Epic 구조를 충분히 흉내 낼 수 있습니다.
결론적으로, **"Jira의 체계적인 이슈 계층(Epic-Feature-Task) 구조의 장점은 가져오되, GitHub의 코드 밀착형 장점을 극대화하자"**는 것이 이번 구성의 핵심 목표였습니다.
2. Milestone(배포)과 Iteration(스프린트)의 분리
초기에는 GitHub의 Milestone을 스프린트처럼 쓸까 고민했지만, 프로젝트를 기획하다 보니 명확한 분리가 필요했습니다. Jira의 구조를 빌려와 다음과 같이 역할을 나눴습니다.
- Milestone(Release 목표) : 큰 단위의 배포나 프로젝트의 중요 체크포인트를 의미합니다. (Jira의 Fix Version 개념)
- 예시: v1.0.0 - MVP (핵심 기능 1차 개발), v1.0.0 - RC (출시 준비)
- Iteration(Sprint): 실제 개발이 돌아가는 짧은 주기(예: 1주~2주)를 의미합니다.
- 예시: Iteration 1 (1주차 개발 진행)
이렇게 나누면 "이번 1.0.0 배포(Milestone)를 위해, 이번 주 스프린트(Iteration)에는 이 이슈들을 처리하자"라는 입체적인 관리가 가능해집니다.
💡 Agile하게 Iterator(Sprint)를 활용하기
단순히 필드만 만들어 둔다고 애자일이 되는 것은 아닙니다. Atlassian 환경에서 수많은 팀의 스크럼(Scrum)을 가이드하면서 느낀 점은, '시간의 제약(Time-box)'을 명확히 하고 그 안에서 집중력을 끌어올리는 것이 스프린트의 핵심입니다.
GitHub Projects의 Iteration 필드를 활용해 애자일의 스프린트를 어떻게 운영하는지 그 사이클을 정리해봤습니다.
애자일(Agile)에서 말하는 스프린트/이터레이션이란?
- Time-boxing: 보통 1주에서 길면 4주 정도의 고정된 기간을 정해두고 개발을 진행합니다. (사이드 프로젝트는 주말 작업이 많아 보통 1주~2주 단위를 추천합니다.)
- 작은 성공의 반복: Milestone(예: 1.0.0 출시)을 단번에 구현하기엔 작업의 범위가 크기 때문에, 2주 단위의 이터레이션으로 쪼개어 "이번 2주 동안은 로그인/회원가입만 완벽하게 끝내자"라는 식으로 팀의 포커스를 맞춥니다.
- 유연한 대처: 2주가 끝난 뒤 회고를 통해 일정을 조정하거나, 예상치 못한 버그나 기획 변경에 빠르게 대응할 수 있습니다.
GitHub Projects에 Iteration 설정하고 운영하기
설정(Settings)에서 Iteration 필드를 추가하면, 시작일(Start Date)과 주기(Duration, 예: 2 weeks)를 지정할 수 있으며, 시스템이 자동으로 날짜를 계산해 Iteration 1, Iteration 2를 생성해 줍니다.
실제 저희 팀의 2주 단위 사이클은 다음과 같이 돌아갑니다.
1. 스프린트 플래닝 (Sprint Planning)
- 새로운 Iteration이 시작되는 날(ex. 격주 월요일), 팀원들이 모여 대시보드의 Backlog를 엽니다.
- 이번 달 목표인 Milestone(v1.0.0 - MVP)에 속한 이슈 중, 이번 2주 안에 끝낼 수 있는 만큼의 Feature와 Task를 선별합니다.
- 선별된 이슈들의 Iteration 필드를 Iteration 1로 지정하고, 상태(Status)를 Ready로 옮깁니다. "이번 주 주말 전까지 이것만큼은 꼭 끝내자!"라는 약속입니다.
2. 집중과 실행 (Daily & Execution)
- Projects 보드 상단에 있는 필터 바에 iteration:@current 라고 검색 조건을 걸어두고 뷰(View)를 저장해 둡니다.
- 이렇게 하면 수많은 백로그는 숨겨지고, 오직 '이번 스프린트(현재 기간)에 해야 할 일'만 보드에 깔끔하게 남습니다. 개발자는 이 뷰만 보며 Ready -> In Progress -> Done으로 이슈를 밀어내는 데만 집중합니다.
3. 스프린트 리뷰 및 회고
- Iteration의 마지막 날, 지금까지 작업한 내용들을 되돌아 보며 회고 진행합니다.
- 만약 예상보다 작업이 길어져서 다 끝내지 못한 이슈가 있다면? 이를 스필오버(Spillover)라고 부릅니다.
- 못 다한 이슈는 상태를 다시 점검한 뒤, 다음 스프린트인 Iteration 2로 필드 값을 수정하여 이월시킵니다. 이를 통해 우리 팀이 2주 동안 실제로 소화할 수 있는 작업량(Velocity)을 객관적으로 파악하게 됩니다.
3. Epic - Feature - Task : 3단계 이슈 계층 구조 잡기
단일 이슈 리스트만으로는 프로젝트의 큰 그림을 보기 어렵습니다. 그래서 Jira의 핵심인 계층 구조를 그대로 가져와서 Epic > Feature > Task 3단계로 명확히 나눴습니다.
아래는 User 도메인을 개발할 때의 예시입니다.
- Milestone: V1.0.0 - MVP 구현
- Epic: User 도메인 개발
- Feature: 사용자 토큰 관리 공통 Util 개발
- Task: Security 로그인 개발
- Task: JWT 토큰 발급 로직 개발
- Feature: Apple 로그인 개발
- Task: Apple 개발자 계정 등록
- Task: Apple API를 이용하여 사용자 조회
- Feature: 사용자 토큰 관리 공통 Util 개발
- Epic: User 도메인 개발
4. 대시보드 및 워크플로우 구성 (Projects Board)
위에서 잡은 뼈대를 바탕으로 실제 GitHub Projects 대시보드를 구성한 모습입니다.
Epic 단위로 묶어보기 (Swimlane 적용)
Jira 보드의 큰 장점인 Epic 단위 묶어보기를 구현했습니다.
Group by 설정을 Parent issue로 지정하면, 위 사진처럼 [EPIC] Infra / Common, [EPIC] Member 등 에픽 단위로 스윔레인(Swimlane)이 만들어집니다. 어떤 도메인의 작업이 어디까지 진행됐는지 직관적으로 보입니다.
상태(Status) 관리 및 흐름
프로젝트 진행 상태는 코딩 사이클과 맞물리도록 다음과 같이 구성했습니다.
Jira의 워크플로우와 마찬가지로 Github Action을 사용하여 자동화 로직을 구성할 수 있습니다.
- Backlog (이슈 생성) : 마크다운 템플릿을 사용하여 이슈를 생성하고, Milestone(배포 목표)과 커스텀 필드(우선순위, Estimate 등)를 입력합니다.
- Ready (계획) : Projects 보드의 Backlog에 자동 추가된 이슈들을 확인하고, 이번 스프린트(Iteration) 계획 시 Ready 컬럼으로 이동시킵니다.
- In Progress (진행) : 작업자가 할당되고 실제 작업이 시작되면 상태를 변경합니다. 이후 지정된 네이밍 규칙(feature/#<이슈번호>-<기능설명>)에 따라 브랜치를 생성합니다.
- 커밋: 커밋 컨벤션(git commit -m "feat: [#이슈번호] 기능 설명")을 철저히 준수하여 코드를 작성합니다.
- In Review (코드 리뷰) : 작업 내역을 바탕으로 PR(Pull Request)을 생성하면, 보드의 이슈가 In Review 컬럼으로 자동 이동합니다.
- Done (완료) : 코드 리뷰 및 승인(Approve) 후 메인 브랜치에 Merge가 완료되면 Done 컬럼으로 자동 이동하며 이슈가 닫힙니다. (필요시 Wiki를 업데이트하고 작업을 최종 마무리합니다.)
5. 필드(Fields) 구성과 마크다운 이슈 템플릿
이슈를 꼼꼼하게 추적하기 위해 다양한 Custom Field를 활용하고, 규격화된 문서 작성을 위해 GitHub Issue Template을 적용했습니다.
커스텀 필드(Custom Fields)
단순히 제목과 내용만 있는 이슈는 나중에 추적하기가 어렵게 됩니다. 우측 사이드바를 보시면 관리용 메타데이터를 추가해 두었습니다.
- Type (Feature, Task, Bug) / Category (도메인 분류)
- Priority: P0, P1, P2 (우선순위)
- Estimate : 예상 소요 시간(스토리 포인트)
- Iteration: 현재 진행 중인 스프린트(Iteration) 주차
- Start date / Target date: 작업 기간
이슈 템플릿 활용
이슈를 올릴 때마다 양식을 고민할 필요가 없도록 GitHub Issue Template을 적용했습니다.
마크다운을 지원하기 때문에 아키텍처 구조나 체크리스트를 미리 양식화해 두면 개발자는 내용만 채워 넣으면 됩니다.
[Feature 템플릿 적용 예시]
## 🔗 상위 Epic
- Epic: #10 User 도메인 개발
## 📋 개요
Apple ID를 이용한 소셜 로그인 기능을 개발합니다.
## 🎯 작업 목표
- iOS 사용자에게 간편한 로그인 경험 제공
- Apple 생태계 사용자 유입 확대
## ✅ 완료 조건
- [ ] Apple Developer 계정 설정 완료
- [ ] 백엔드 토큰 검증 로직 구현
- [ ] 로그인 성공/실패 케이스 테스트 완료
## 📚 참고 자료
- [Apple Sign In 공식 문서](<https://developer.apple.com/sign-in-with-apple/>)
매일 무거운 엔터프라이즈 환경의 툴만 만지다가, 사이드 프로젝트에 맞춰 가벼운 GitHub Projects의 기능으로 Jira와 유사하게 구성하는 생각보다 훨씬 재밌었습니다.
이번 기회로 다시금 Github의 기능에 대해 공부하면서, 프로젝트에 규모와 사용하는 툴을 고려하여 이슈 관리를 하는 것이 중요하다는 것을 느끼게 되었습니다.
