GitHub Foundations #7 Domain 5: 프로젝트 관리 — Projects·자동화·인사이트
Domain 4에서 Actions, Codespaces, Copilot 같은 개발 도구를 정리했다면, Domain 5는 그 개발을 계획하고 추적하는 도구를 묻습니다. 시험 전체에서 차지하는 비중은 크지 않지만, 묻는 내용이 명확해서 준비한 만큼 그대로 득점으로 이어지는 영역입니다. 핵심은 두 갈래입니다. 이슈와 PR을 계획 단위로 묶는 GitHub Projects, 그리고 저장소의 활동을 읽는 Insights입니다.
GitHub Projects — 이슈와 PR을 계획으로 묶는 도구 #
이슈는 할 일 하나를 담고, PR은 변경 하나를 담습니다. 그런데 실제 업무는 “이번 분기에 이 기능들을 어떤 순서로 끝낼 것인가” 같은 더 큰 단위로 움직입니다. GitHub Projects는 여러 저장소에 흩어진 이슈와 PR을 하나의 계획 화면으로 모아, 상태와 우선순위를 부여하고 진행을 추적하는 도구입니다.
시험에서 먼저 구분해야 할 것은 세대입니다. 현재의 Projects는 Organization이나 개인 계정 아래에 만들어져 여러 저장소를 가로질러 항목을 모을 수 있고, 스프레드시트처럼 유연한 필드를 지원합니다. 과거의 Projects(classic)는 저장소에 종속된 단순 칸반 보드였고 이미 폐지 수순을 밟았으므로, 시험 답안 기준은 항상 현재의 Projects입니다.
세 가지 뷰 — 테이블·보드·로드맵 #
같은 항목 집합을 세 가지 형태로 볼 수 있습니다. 각 뷰의 용도를 매칭하는 문제가 단골입니다.
| 뷰 | 형태 | 잘 맞는 질문 |
|---|---|---|
| Table | 스프레드시트형 목록 | 전체 항목을 필드별로 정렬·일괄 정리하려면? |
| Board | 상태 컬럼 칸반 | 지금 무엇이 진행 중이고 무엇이 막혀 있는가? |
| Roadmap | 날짜 기반 타임라인 | 각 작업이 언제 시작해서 언제 끝나는가? |
뷰는 저장된 화면 구성일 뿐이므로 하나의 프로젝트에 여러 뷰를 나란히 만들어 둘 수 있습니다. 팀 회의용 Board 뷰와 분기 계획용 Roadmap 뷰가 같은 데이터를 다른 각도로 보여 주는 방식입니다.
커스텀 필드 — 상태·우선순위·iteration #
Projects의 항목에는 기본 정보 외에 필드를 자유롭게 추가할 수 있습니다.
- Single select — Status(Todo, In Progress, Done), 우선순위(P0, P1, P2)처럼 정해진 값 중 하나를 고르는 필드입니다.
- Iteration — 2주 스프린트처럼 반복되는 기간 단위를 만들어 항목을 배정하는 필드입니다. 시험에서 “스프린트 단위 배정에 쓰는 필드"를 물으면 답은 iteration입니다.
- 텍스트, 숫자, 날짜 — 견적 시간, 마감일 같은 자유 입력 필드입니다.
필터와 그룹은 이 필드들을 기준으로 동작합니다. status:"In Progress" 같은 필터 문법으로 뷰를 좁히고, 담당자나 우선순위로 묶어서 봅니다.
이슈·PR 연결 — 계획과 실행을 잇는 고리 #
Projects에 담기는 항목의 원천은 이슈와 PR입니다. 둘을 잇는 연결 규칙은 Domain 3에서 다룬 내용이 그대로 이어집니다.
- PR 본문에
Closes #12처럼 키워드를 쓰면 머지 시점에 해당 이슈가 자동으로 닫힙니다. - 마일스톤은 이슈와 PR을 릴리스 단위로 묶는 저장소 수준의 그룹이고, Projects는 그 위에서 저장소를 가로지르는 계획 레이어입니다.
마일스톤과 Projects의 층위 구분을 묻는 문제가 나오면, 마일스톤은 저장소 안의 릴리스 묶음, Projects는 계정·조직 수준의 계획 도구로 답하면 됩니다.
항목 추가와 프로젝트 권한 #
항목을 프로젝트에 넣는 경로는 세 가지입니다. 프로젝트 화면 하단의 입력줄에서 #저장소명으로 검색해 추가하거나, 이슈·PR 페이지의 사이드바 Projects 항목에서 지정하거나, 뒤에서 다룰 auto-add 워크플로가 자동으로 수집하게 합니다. 아직 이슈로 만들지 않은 메모를 draft item으로 먼저 적어 두었다가 나중에 이슈로 전환하는 흐름도 지원됩니다. 계획 단계의 아이디어를 draft로 쌓고, 확정되면 저장소 이슈로 승격하는 사용법이 전형적입니다.
프로젝트 자체의 공개 범위와 권한은 저장소와 별도로 관리됩니다. private 프로젝트는 초대된 사람만 보고, public 프로젝트도 항목으로 연결된 private 저장소의 내용까지 노출하지는 않습니다. 프로젝트에 대한 쓰기 권한과 저장소에 대한 쓰기 권한이 서로 독립이라는 점이 경계 문제로 나올 수 있습니다.
내장 자동화 워크플로 #
Projects에는 상태를 손으로 옮기는 수고를 줄이는 자동화가 내장되어 있습니다. 프로젝트 설정의 Workflows에서 켜고 끕니다.
- Auto-add — 지정한 저장소에서 조건에 맞는 이슈·PR이 생기면 프로젝트에 자동으로 추가합니다.
- Item added to project — 항목이 추가되면 Status를 Todo로 설정하는 식의 초기값 지정입니다.
- Item closed / PR merged — 이슈가 닫히거나 PR이 머지되면 Status를 Done으로 옮깁니다.
- Auto-archive — 완료된 지 오래된 항목을 자동으로 보관 처리합니다.
내장 워크플로로 부족한 조건은 GitHub Actions로 확장할 수 있습니다. 시험 수준에서는 “기본 자동화는 Projects 내장 워크플로, 복잡한 자동화는 Actions 연계"라는 역할 구분만 잡아 두면 충분합니다.
차트 — 프로젝트의 Insights #
프로젝트 화면의 Insights에서는 항목 데이터를 차트로 그립니다. 현재 상태의 분포를 보는 차트와, 시간에 따른 변화(번다운 형태)를 보는 차트를 만들 수 있어 스프린트 회고에 활용됩니다. 저장소의 Insights 탭과 이름이 같아 혼동하기 쉬운데, 프로젝트 Insights는 계획 항목의 차트, 저장소 Insights는 저장소 활동의 통계입니다.
저장소 Insights 탭 #
저장소의 Insights 탭은 저장소가 어떻게 움직이고 있는지를 보여 주는 통계 모음입니다. 각 항목의 용도를 한 줄씩 매칭할 수 있어야 합니다.
| 항목 | 보여 주는 것 |
|---|---|
| Pulse | 최근 기간의 활동 요약 (머지된 PR, 열린 이슈, 활동한 사람) |
| Contributors | 기여자별 커밋·추가·삭제 추이 그래프 |
| Traffic | 방문자 수, 조회 수, clone 횟수와 유입 경로 |
| Community Standards | README, LICENSE, CONTRIBUTING 같은 커뮤니티 파일 구비 체크리스트 |
| Forks / Network | 포크 목록과 브랜치 분기 그래프 |
Traffic은 push 권한이 있는 사람만 볼 수 있다는 점, Community Standards는 Domain 7에서 다룰 커뮤니티 파일과 연결된다는 점을 함께 기억해 두면 좋습니다.
마무리 #
이번 글의 핵심은 세 가지입니다.
- GitHub Projects는 여러 저장소의 이슈·PR을 모아 계획하는 도구이고, Table, Board, Roadmap 세 뷰로 같은 데이터를 다른 각도에서 봅니다.
- 상태 초기화와 완료 처리 같은 반복 작업은 내장 자동화 워크플로가 담당하고, 그 이상은 Actions로 확장합니다.
- 저장소 Insights는 Pulse, Contributors, Traffic, Community Standards로 저장소의 활동과 건강 상태를 읽는 통계 모음입니다.
다음 글 “GitHub Foundations #8 Domain 6: 프라이버시·보안·관리 — 권한·2FA·Dependabot"에서는 시험에서 경계 구분 문제가 가장 많이 나오는 영역, 곧 권한 모델과 보안 기능의 지도를 정리하겠습니다.