세 가지 날짜
| 날짜 | GitHub 기능 | Launchpad 예 | 바뀌면 의미하는 것 |
|---|---|---|---|
| 출시 마감 | 마일스톤(Milestone)의 마감일 | M1 비공개 베타 2026-11-06 | 출시 약속이 바뀐다. 이해관계자에게 알린다. |
| 작업 기간 | Project의 반복(Iteration) 필드 | Sprint 1 2026-10-12 ~ 10-23 | 업무를 다른 기간으로 옮긴다. 출시 마감은 그대로일 수 있다. |
| 업무 목표일 | Project의 날짜(Date) 필드 Target date | LP-01 2026-10-14 | 한 업무의 일정이 바뀐다. 뒤따르는 업무를 확인한다. |
예를 들어 LP-03의 목표일이 10월 23일에서 10월 28일로 바뀌면 LP-03은 Sprint 1에서 Sprint 2로 넘어간다. 그래도 Sprint 2가 11월 6일에 끝나므로 M1의 마감일은 바뀌지 않는다. 세 날짜가 분리되어 있어야 이 판단을 기록으로 보여 줄 수 있다.
관리 대상과 저장 위치
| PM이 관리하는 것 | GitHub 기능 | 이 과정의 사용 규칙 |
|---|---|---|
| 프로젝트의 업무와 문서 | 저장소(Repository) | 실습에서는 저장소 하나로 시작한다 |
| 제품 전체의 진행 상황 | Projects | 여러 저장소의 이슈도 모을 수 있는 운영 화면 |
| 출시 목표와 마감 | 마일스톤 | “M1 비공개 베타”처럼 결과 중심으로 이름 짓는다 |
| 일정한 작업 기간 | Iteration 필드 | Sprint 1처럼 기간과 계획을 관리한다 |
| 실행할 업무 | 이슈 | 담당자와 완료 조건이 있는 단위 |
| 큰 기능과 하위 작업 | 상위 이슈와 하위 이슈(sub-issues) | 필요할 때만 계층을 추가한다 |
| 작업 순서의 제약 | 이슈 의존성(Issue dependencies) | 먼저 끝나야 하는 업무를 연결한다 |
| 중요도와 작업 상태 | Project 필드 | Priority와 Status를 한 곳에서 관리한다 |
| 업무 종류와 영역 | 라벨(Labels) | kind:, area:, blocked |
| 개발 결과 | 커밋, 풀 리퀘스트(PR), 릴리스(Release) | 업무와 연결된 변경과 그 근거 |
| 논의와 회의 기록 | 운영 이슈 또는 Discussions | 결정과 후속 업무의 링크를 남긴다 |
| 오래 유지할 기준 | Wiki 또는 docs/ 폴더 | 용어, 정책, 완료 기준, 운영 규칙 |
하나의 이슈, 여러 보기
Project는 이슈의 복사본이 아니라 이슈에 연결된 관리 화면이다. Project에 추가한 이슈 하나는 백로그 표, 스프린트 보드, 로드맵에 동시에 나타나고, 한 화면에서 Status를 바꾸면 다른 화면에도 같은 값이 보인다.
- 제품 목표사전신청으로 베타 수요 확인
- 출시 마일스톤M1, M2
- 업무 이슈LP-01 ~ LP-06
- Project에 연결Status, Priority, Iteration
- 진행과 검수PR, 리뷰, 검증 근거
- 종료 보고완료, 이월, 범위 변경
소속도 다르다. 마일스톤은 저장소에 속하고, Status·Priority·Iteration 같은 필드는 Project에 속한다. 저장소 두 개에 걸친 출시를 관리하려면 두 저장소에 같은 이름의 마일스톤을 만들거나, Project에 출시 필드를 따로 두는 설계가 필요하다.
팀이 먼저 합의할 운영 규칙
Status 네 단계
| Status | 들어가는 조건 | 바꾸는 사람 |
|---|---|---|
| Todo | 완료 조건과 담당자가 있고 아직 시작하지 않았다 | PM |
| In Progress | 담당자가 작업을 시작했다 | 실행 담당자 |
| In Review | 검수 요청과 검증 근거가 있다 | 실행 담당자 |
| Done | 완료 조건을 모두 충족했고 검수자가 확인했다 | 검수자 또는 PM |
막힘은 Status 값으로 만들지 않는다. blocked 라벨과 의존성으로 표시하고, 댓글에 원인, 해결 담당자, 다음 확인일을 남긴다. 막힌 업무도 진행 단계는 그대로 유지되므로, In Progress이면서 blocked인 상태를 구분할 수 있다.
Priority 세 등급
| 등급 | 이 과정의 정의 | Launchpad 예 |
|---|---|---|
| P0 | 없으면 출시하지 못하는 업무 | LP-03 이메일 사전신청 |
| P1 | 이번 목표에 필요하지만 대체 수단이 있는 업무 | LP-04 운영자 알림 (수동 조회로 대체 가능) |
| P2 | 다음 목표로 미뤄도 되는 개선 | 유입 경로 기록 |
완료의 정의
완료는 세 조건이 모두 충족된 상태다. 체크리스트의 모든 항목을 충족했다. 검증 근거를 첨부했다. 검수자가 확인했다.
이슈의 Open·Closed와 Project의 Status는 서로 다른 값이다. 아래 두 경우는 실제로 생긴다.
| 이슈 | Status | 생기는 경우 |
|---|---|---|
| Closed | In Review | PR이 병합되어 이슈가 자동으로 닫혔지만 QA는 아직이다. |
| Open | Done | 보드에서 Done으로 옮겼지만 이슈를 닫지 않았다. |
두 값을 맞추는 자동화 규칙이 있지만, 설정하고 실제 이슈로 확인하기 전까지는 자동으로 맞춰진다고 가정하지 않는다.
기록 위치
- 업무 상태는 이슈와 Project에만 둔다. 위키에 같은 업무의 상태를 다시 적지 않는다.
- 위키나
docs/에는 정책과 운영 규칙처럼 오래 유지할 기준을 둔다. - 회의록에는 결정 내용, 이유, 결정자, 연결된 이슈를 남긴다.
역할
| 역할 | 기록하는 것 |
|---|---|
| PM | 마일스톤, 우선순위, 스프린트 범위, 결정 기록, 범위 변경 기록 |
| 실행 담당자 | Status 변경, 진행 댓글, PR, 검증 근거 |
| 검수자 | PR 리뷰, 완료 조건 확인 댓글 |
- 출시 마감, 작업 기간, 업무 목표일을 각각 어떤 기능에 두는지 말할 수 있다.
- 마일스톤은 저장소에, Status와 Priority는 Project에 속한다는 차이를 말할 수 있다.
- 이슈가 Closed인데 Status가 In Review인 경우가 언제 생기는지 예를 들 수 있다.
마치며...
이 절에서 세 가지 날짜의 저장 위치, Status 네 단계, Priority 세 등급, 완료의 정의를 정했다. 실습 1에서는 이 구조를 담을 개인 실습 저장소를 만든다.