개인 프로젝트를 진행하면서 해야 할 일을 메모장이나 Spreadsheet로만 관리해 왔습니다. 규모가 작을 때는 별문제가 없지만, 화면과 API가 늘어나기 시작하면 이야기가 달라집니다.
지금 구현 중인 기능이 무엇인지, 다음에 무엇을 해야 하는지, 원래 예상보다 오래 걸린 작업은 무엇인지 점점 헷갈리기 시작합니다. 그렇다고 개인 프로젝트에 Jira 등의 전문 프로젝트 관리 툴 까지 도입하는 것은 조금 무겁게 느껴졌습니다.
그래서 이번에는 GitHub에 내장된 GitHub Projects를 사용해 보기로 했습니다. GitHub Projects는 Issue와 Pull Request를 하나의 보드에서 관리할 수 있는 도구입니다. 전문 프로젝트 관리 툴 만큼 정교한 공수 관리 기능을 제공하지는 않지만, 개인 프로젝트나 소규모 개발팀에서 작업의 상태를 공유하기에는 충분해 보였습니다.
저는 현재 개발 중인 YMS SaaS 프로젝트에 먼저 적용해보겠습니다. 별도의 Projects 화면에서 시작하지 않고, 실제로 관리할 YMS 프론트엔드 저장소의 Projects 탭에서 바로 Project를 만들겠습니다. 그다음 작업 보드를 설정하고 첫 Issue 몇 개를 등록하는 과정까지 진행합니다.
1. YMS 저장소에서 새로운 Project를 만듭니다
GitHub에 로그인한 뒤 현재 개발 중인 YMS 프론트엔드 저장소로 이동합니다.
저장소 상단 메뉴에서 Projects 탭을 선택합니다.
아직 연결된 Project가 없다면 이 화면에 New project 버튼이 표시됩니다. 이 버튼을 눌러 새로운 Project를 만듭니다.
GitHub에서는 Table, Roadmap, Board 등의 형식으로 Project를 시작할 수 있습니다. 이번 목적은 작업의 진행 상태를 칸별로 확인하는 것이므로 Start from scratch 아래의 Board를 선택합니다.
프로젝트 이름을 입력하고 Create project를 누르면 빈 작업 보드가 생성됩니다. 저장소의 Projects 탭에서 시작했기 때문에 YMS 프론트엔드 저장소와 새 Project의 관계도 이 과정에서 함께 만들어집니다. 별도로 저장소로 돌아가 Link a project를 수행할 필요가 없습니다.
GitHub의 개인 계정에 만든 User Project는 해당 개인 계정이 소유한 저장소의 Issue와 Pull Request를 추적할 수 있습니다. 프론트엔드와 백엔드 저장소를 따로 관리하더라도 Project 하나에서 양쪽 작업을 함께 볼 수 있습니다.
Project의 Settings에서 Default repository도 YMS 프론트엔드 저장소로 지정되어 있는지 확인합니다. 기본 저장소로 지정하면 Project 안에서 새로운 Issue를 작성할 때 해당 저장소가 먼저 선택됩니다.
백엔드 저장소는 나중에 생성한 뒤 같은 Project를 추가로 연결하면 됩니다. 지금은 실제 개발을 시작한 프론트엔드 저장소만 연결해두겠습니다.
2. Project의 설명을 작성합니다
새 Project를 만들었으니 무엇을 위한 보드인지 간단히 적어두겠습니다.
오른쪽 위의 ··· 메뉴를 누르고 Settings로 이동합니다.
Add a description에 다음과 같은 설명을 입력합니다.
유튜브 채널 운영자와 작업자의 프로젝트·일정·채팅·정산 업무를 관리하는 YMS SaaS 개발 보드README에는 이 보드를 어떻게 사용할 것인지 짧게 적어두었습니다.
## 운영 규칙
1. 구현할 작업은 시작 전에 Issue로 등록합니다.
2. 작업을 시작하면 상태를 In Progress로 변경합니다.
3. 구현 후 직접 확인이 필요하면 Review로 이동합니다.
4. 완료 조건을 확인한 뒤 Issue를 닫습니다.
5. 작업을 마칠 때 실제 공수를 기록합니다.개인 프로젝트라 당장은 저 혼자 보는 문서입니다. 그래도 운영 규칙을 먼저 정해두면 나중에 팀 프로젝트에서 사용할 방법을 미리 연습할 수 있습니다.
3. 기본 상태를 다섯 단계로 정리합니다
Board를 선택하면 보통 Todo, In Progress, Done과 같은 기본 상태가 만들어집니다. 이것만으로도 사용할 수 있지만, 저는 아직 구현하기로 확정하지 않은 작업과 구현 후 확인 중인 작업을 구분하고 싶었습니다.
최종적으로 다음 다섯 상태를 사용합니다.
| 상태 | 의미 |
| Backlog | 언젠가 필요하지만 아직 착수 범위를 확정하지 않은 작업 |
| Todo | 작업 내용과 완료 조건이 정해진 작업 |
| In Progress | 현재 구현 중인 작업 |
| Review | 구현을 마치고 테스트 또는 확인 중인 작업 |
| Done | 완료 조건까지 확인한 작업 |
Settings에서 Status 필드를 선택합니다. 기존의 Todo, In Progress, Done은 그대로 사용하고 Backlog와 Review 옵션을 추가합니다
.
다시 Board로 돌아왔을 때 새 상태가 보이지 않는다면 보드의 가장 오른쪽으로 이동하여 + 버튼을 누르고 숨겨진 열을 표시합니다.
이제 카드가 다음 순서로 흐르게 됩니다.
Backlog → Todo → In Progress → Review → Done여기서 Review는 꼭 다른 사람의 코드 리뷰만 의미하지 않습니다. 개인 프로젝트에서는 브라우저 실행, 예외 상황 확인, 요구사항 대조처럼 제가 직접 검증하는 단계로 사용합니다.
4. 설정을 위한 Table View를 하나 추가합니다
Board는 작업 상태를 확인하기에 편하지만, 여러 필드의 값을 한꺼번에 입력할 때는 표 형태가 더 편합니다.
상단의 기존 View 오른쪽에서 New view를 누릅니다.
새 View의 View 메뉴를 열고 Layout을 Table로 변경한 뒤 이름을 전체 작업표로 바꿉니다.
기존 Board View의 이름도 작업 보드로 변경했습니다.
이제 Project 위쪽에 다음 두 개의 View가 생깁니다.
- 작업 보드: 상태별로 카드를 옮기며 사용
- 전체 작업표: 필드 입력과 전체 작업 확인에 사용
View는 같은 데이터를 서로 다른 방법으로 보여줄 뿐입니다. 전체 작업표에서 값을 수정하면 작업 보드에도 그대로 반영됩니다.
5. 필요한 필드만 추가합니다
Jira를 대신하겠다고 너무 많은 항목을 만들면 개발보다 관리가 더 번거로워질 수 있습니다. 이번에는 실제로 사용할 가능성이 높은 네 개의 필드만 추가합니다.
전체 작업표의 가장 오른쪽 열에 있는 +를 누르고 New field를 선택합니다.
우선순위
Field name은 Priority, Field type은 Single select로 지정합니다.
High
Medium
Low개인 프로젝트라고 해도 모든 작업을 동시에 할 수는 없습니다. 지금 먼저 처리해야 할 작업을 구분하기 위한 필드입니다.
작업 영역
Field name은 Area, Field type은 Single select로 지정합니다.
Frontend
Backend
Database
Common
Document
Test프론트엔드와 백엔드 저장소가 분리되어 있더라도, DB 설계나 문서처럼 저장소만으로 구분하기 어려운 작업이 있으므로 별도 필드로 만들었습니다.
예상 공수
Field name은 Estimate, Field type은 Number로 지정합니다.
단위는 시간으로 통일합니다.
2 = 약 2시간
4 = 약 4시간
8 = 약 하루처음부터 정확한 시간을 맞히는 것이 목적은 아닙니다. 구현 전에 예상해보고, 나중에 실제 결과와 비교하기 위한 기록입니다.
실제 공수
Field name은 Actual, Field type은 Number로 지정합니다.
작업을 끝냈을 때 실제로 사용한 시간을 대략 입력합니다. GitHub Projects에는 작업 시간을 재는 타이머가 없기 때문에 분 단위로 엄격하게 기록하지 않고 30분 또는 1시간 단위로 기록할 생각입니다.
GitHub Projects는 숫자 필드의 합계는 보여줄 수 있지만, Actual - Estimate를 자동 계산하는 수식 필드는 제공하지 않습니다. 우선은 두 값을 나란히 보면서 회고하는 정도로 사용하겠습니다.
날짜 필드와 Roadmap은 이번에는 추가하지 않습니다. 실제 작업 카드가 쌓인 다음 일정 시각화가 필요하다고 느껴질 때 도입해도 늦지 않습니다.
6. 첫 번째 Issue를 작성합니다
이제 실제 작업을 등록해보겠습니다.
작업 보드로 돌아가 Todo 열 아래의 +를 누릅니다. 나타나는 메뉴에서 Create new issue를 선택합니다.
상단에서 Issue를 저장할 YMS 프론트엔드 저장소를 선택하고 제목을 입력합니다.
[SCR-01] 로그인 페이지 기본 레이아웃 구현Issue 본문은 다음과 같이 작성했습니다.
## 작업 내용
SCR-01 로그인 화면의 기본 레이아웃을 구현합니다.
## 완료 조건
- [ ] 아이디 입력란이 표시된다.
- [ ] 비밀번호 입력란이 표시된다.
- [ ] 로그인 버튼이 표시된다.
- [ ] 화면 크기가 달라져도 주요 요소가 겹치지 않는다.
- [ ] 새로고침 후에도 화면이 정상적으로 표시된다.
## 관련 설계
- 화면: SCR-01
- 관련 API: POST /api/auth/login
- 관련 테이블: users
## 구현 메모
이번 작업에서는 화면 배치까지만 구현합니다. API 호출과 로그인 검증은 별도 Issue로 분리합니다.
## 확인 결과
구현 후 브라우저에서 확인한 내용을 작성합니다.
Issue를 작성할 때 가장 중요한 부분은 완료 조건이라고 생각합니다. “로그인 화면 구현”처럼 제목만 작성하면 어디까지 해야 끝난 것인지 모호해집니다. 반면 체크박스로 완료 조건을 적어두면 구현 범위를 스스로 통제하기 쉬워집니다.
Create를 누르면 Issue가 만들어지고 Todo 열에 카드가 추가됩니다. Todo 열에서 만들었기 때문에 상태도 자동으로 Todo로 지정됩니다.
카드를 열어 다음 필드도 입력합니다.
| 필드 | 입력값 |
| Assignee | 본인 계정 |
| Priority | High |
| Area | Frontend |
| Estimate | 4 |
| Actual | 작업 완료 후 입력 |
7. 작업을 몇 개 더 나눠서 등록합니다
로그인 기능 전체를 Issue 하나로 만들면 화면, 상태 관리, API 통신과 예외 처리가 모두 섞입니다. 한 번에 완료 여부를 판단할 수 있도록 몇 개의 작업으로 나눴습니다.
두 번째 Issue: 입력 상태와 검증
[SCR-01] 로그인 입력값 상태 관리 및 검증## 작업 내용
로그인 화면의 아이디와 비밀번호 입력값을 React state로 관리하고 기본 검증을 구현합니다.
## 완료 조건
- [ ] 아이디 입력값이 state에 반영된다.
- [ ] 비밀번호 입력값이 state에 반영된다.
- [ ] 필수값을 입력하지 않으면 안내 문구가 표시된다.
- [ ] 검증 실패 시 API를 호출하지 않는다.
## 관련 설계
- 화면: SCR-01
## 확인 결과
구현 후 확인한 내용을 작성합니다.추천 필드값은 다음과 같습니다.
Priority: High
Area: Frontend
Estimate: 4세 번째 Issue: 로그인 API 호출 구조
[SCR-01] 로그인 API 호출 함수 작성## 작업 내용
로그인 버튼을 누르면 인증 API를 호출할 수 있도록 프론트엔드 통신 구조를 작성합니다.
## 완료 조건
- [ ] Axios를 사용하는 로그인 요청 함수가 작성된다.
- [ ] 요청 데이터에 아이디와 비밀번호가 포함된다.
- [ ] 성공 응답과 실패 응답을 구분한다.
- [ ] 통신 중 중복 요청을 방지한다.
## 관련 설계
- 화면: SCR-01
- API: POST /api/auth/login
## 참고
백엔드 API가 완성되기 전에는 임시 응답 또는 Mock으로 동작을 확인할 수 있습니다.필드값은 다음과 같습니다.
Priority: Medium
Area: Frontend
Estimate: 4네 번째 Issue: 로그인 실패 메시지
[SCR-01] 로그인 실패 메시지 표시## 작업 내용
로그인 요청 실패 시 사용자에게 통합된 실패 메시지를 표시합니다.
## 완료 조건
- [ ] 인증 실패 시 안내 문구가 표시된다.
- [ ] 아이디 오류와 비밀번호 오류를 서로 다른 문구로 노출하지 않는다.
- [ ] 서버 오류와 인증 실패를 구분하여 처리할 수 있다.
- [ ] 다시 입력하면 기존 오류 상태를 적절히 초기화한다.
## 관련 설계
- 화면: SCR-01
- API: POST /api/auth/login
## 정책
보안을 위해 로그인 실패 사유는 하나의 메시지로 통합합니다.필드값은 다음과 같습니다.
Priority: Medium
Area: Frontend
Estimate: 2이렇게 네 개의 Issue를 만들고 나니 “로그인 화면을 만들어야 한다”는 막연한 계획이 실제로 착수할 수 있는 작업 목록으로 바뀌었습니다.
8. 첫 작업을 시작해봅니다
가장 먼저 구현할 [SCR-01] 로그인 페이지 기본 레이아웃 구현 카드를 Todo에서 In Progress로 드래그합니다.
이제 이 카드는 현재 제가 작업하고 있는 항목이라는 뜻이 됩니다. 개인 프로젝트라도 동시에 여러 카드를 In Progress로 옮기지 않고, 가능하면 하나를 끝낸 뒤 다음 작업을 시작할 생각입니다.
구현을 마치면 곧바로 Done으로 보내지 않고 Review로 옮깁니다. 그 상태에서 완료 조건을 하나씩 확인합니다.
Todo → In Progress → Review → Done모든 조건을 확인했다면 Actual에 실제 작업 시간을 입력하고 Issue를 닫습니다. Project의 기본 자동화가 활성화되어 있다면 Issue를 닫았을 때 상태도 Done으로 변경됩니다.
예상 공수가 4시간이었는데 실제로 7시간이 걸렸다고 해도 실패는 아닙니다. 왜 차이가 생겼는지 확인할 자료가 처음으로 생긴 것입니다.
- CSS 배치에서 예상보다 오래 걸렸는가?
- React 문법을 새로 익히는 시간이 포함됐는가?
- 완료 조건에 없던 작업을 중간에 추가했는가?
- 애초에 Issue의 범위가 너무 컸는가?
이 기록이 쌓이면 다음 작업의 예상도 조금씩 현실적으로 바뀔 것입니다.
GitHub Projects를 거창하게 시작하지 않기로 했습니다
이번에 만든 Project에는 아직 간트 차트도 없고, 스프린트도 없으며, 자동으로 계산되는 공수 보고서도 없습니다.
지금 필요한 것은 복잡한 프로젝트 관리 체계를 흉내 내는 것이 아니었습니다. 무엇을 해야 하는지 적고, 지금 무엇을 하고 있는지 표시하고, 완료 여부를 확인하는 기본 습관부터 만드는 것이 목적입니다.
그래서 첫 설정은 다음 정도로 끝냈습니다.
- 상태: Backlog, Todo, In Progress, Review, Done
- 사용자 정의 필드: Priority, Area, Estimate, Actual
- View: 작업 보드, 전체 작업표
- 첫 작업: SCR-01 로그인 화면 관련 Issue 네 개
일단 이 상태로 YMS SaaS를 개발해보겠습니다. 실제로 사용하면서 필요 없는 필드는 지우고, 반복해서 따로 기록하는 정보가 생기면 그때 새로운 필드나 View를 추가할 생각입니다.
GitHub Projects를 배우기 위해 프로젝트를 관리하는 것이 아니라, 프로젝트를 놓치지 않기 위해 GitHub Projects를 사용하는 것이니까요.
https://github.com/users/heebaek200/projects/3/views/1
참고 문서
'학습 > Git・프로젝트 관리' 카테고리의 다른 글
| 다른 조에는 없는 고급 정보, GitHub Projects를 도입했습니다 (0) | 2026.09.03 |
|---|---|
| GitHub Wiki로 협업 매뉴얼 만들기 (0) | 2026.08.25 |
| Git/GitHub - 조별로 브랜치를 나누고 Pull Request로 합쳐보기 (0) | 2026.08.24 |