실습 10 스프린트 운영 이슈 · PM을 위한 GitHub CLI

cd ~/gh-pm-lab
source pm-lab/env.sh

1회의 네 가지와 남기는 결과

스프린트 하나에는 성격이 다른 회의 네 가지가 있다. 회의마다 운영 이슈에 남기는 것이 다르다.

회의	다룰 질문	운영 이슈에 남기는 결과
계획 회의	목표 달성에 꼭 필요한 범위인가	목표, 업무 목록, 담당자, 제외 범위, 시작 범위 기록
주간 점검	무엇이 막혀 있고 어떤 결정이 필요한가	사전 리포트, 결정 기록, 범위 변경 기록
리뷰	완료 조건을 실제로 충족했는가	시연 결과, 검수 근거, 남은 문제
회고	다음 반복에서 무엇을 바꿀 것인가	개선 업무 한두 개와 담당자

GitHub 이슈는 회의 초대장을 보내거나 화상회의를 예약하지 않는다. 일정과 화상회의 링크는 캘린더에서 만들고, 그 링크를 운영 이슈 본문에 적는다.

2운영 이슈 본문 만들기

범위에는 이슈 주소를 직접 적는다. 업무 이름만 적으면 나중에 제목이 바뀌었을 때 어떤 이슈였는지 확인하기 어렵다. 아래 블록은 backlog-map.tsv에서 Sprint 1 업무 세 개의 주소를 읽어 본문에 넣는다. <<EOF에 따옴표가 없으므로 $( ) 안의 명령이 실행되어 그 결과가 본문에 들어간다.

cat > pm-lab/sprint-1.md <<EOF
## 목표
방문자가 랜딩 페이지에서 사전신청을 마치고 결과를 확인하는 최소 흐름을 검증한다.

## 일정과 참석
- 기간: 2026-10-12 ~ 2026-10-23
- 계획 회의: 2026-10-12 10:00 / 참석자 / 화상회의 링크
- 주간 점검: 매주 목요일 10:00. 사전 리포트는 전날 이 이슈에 댓글로 올린다.

## 시작 시 합의한 범위
$(awk -F'\t' '$1=="LP-01" || $1=="LP-02" || $1=="LP-03" {print "- " $3}' pm-lab/backlog-map.tsv)

## 제외 범위
- 결제, 회원 로그인, 운영 알림의 완성은 이번 스프린트에 포함하지 않는다.

## 결정 기록
일시 / 결정 / 이유 / 결정자 / 관련 이슈 순서로 댓글에 남긴다.

## 범위 변경 기록
추가·제외 업무 / 변경 이유 / 목표·일정 영향 / 합의자 순서로 댓글에 남긴다.

## 종료 기록
완료 근거 / 미완료 업무 / 이월 이유 / 다음 스프린트 조치를 종료 회의 후 댓글에 남긴다.
EOF
cat pm-lab/sprint-1.md

...
## 시작 시 합의한 범위
- https://github.com/gildong/launchpad-pm-lab/issues/1
- https://github.com/gildong/launchpad-pm-lab/issues/2
- https://github.com/gildong/launchpad-pm-lab/issues/3
...

GitHub는 본문의 이슈 주소를 제목과 상태가 보이는 링크로 표시한다. 일반화된 양식은 키트의 templates/sprint-record.md에 있다.

3운영 이슈 등록과 고정

PM_SPRINT_URL=$(gh issue create -R "$PM_REPO" \
  --title "[Sprint 1] 계획과 진행 및 종료 기록" \
  --body-file pm-lab/sprint-1.md \
  --label "kind:meeting" --assignee "@me")
echo "PM_SPRINT_URL=\"$PM_SPRINT_URL\"" >> pm-lab/env.sh
gh issue pin "$PM_SPRINT_URL"
echo "$PM_SPRINT_URL"

✓ Pinned issue gildong/launchpad-pm-lab#8 ([Sprint 1] 계획과 진행 및 종료 기록)
https://github.com/gildong/launchpad-pm-lab/issues/8

gh issue pin은 이 이슈를 저장소 Issues 탭 맨 위에 고정한다. 고정은 저장소당 3개까지다.

마일스톤과 Project에 넣지 않는 이유

운영 이슈에는 출시 마일스톤을 붙이지 않는다. 붙이면 M1의 열린 이슈 수가 7개가 되어 업무 진행률에 회의록이 섞인다. 같은 이유로 Project에도 추가하지 않는다. 업무 조회는 label:"kind:task"로 거르므로, 혹시 추가되더라도 조회 결과에는 섞이지 않는다.

4시작 범위 기록

계획 회의 직후의 Sprint 1 범위를 두 가지 형태로 남긴다. JSON 파일은 종료 때 기계적으로 비교하는 데 쓰고, 댓글은 팀이 읽는 데 쓴다. 로컬 파일만 있으면 팀이 볼 수 없다.

gh project item-list "$PM_PROJECT" --owner "$PM_OWNER" --limit 100 \
  --query 'iteration:"Sprint 1" label:"kind:task"' --format json \
  > pm-lab/sprint-1-start.json

{
  echo "### 시작 범위 ($(date +%F) 기록)"
  gh project item-list "$PM_PROJECT" --owner "$PM_OWNER" --limit 100 \
    --query 'iteration:"Sprint 1" label:"kind:task"' --format json \
    --jq '.items[] | "- \(.content.url) · Status \(.status // "-") · Priority \(.priority // "-")"'
} > pm-lab/sprint-1-start.md

cat pm-lab/sprint-1-start.md
gh issue comment "$PM_SPRINT_URL" --body-file pm-lab/sprint-1-start.md

### 시작 범위 (2026-10-15 기록)
- https://github.com/gildong/launchpad-pm-lab/issues/1 · Status In Review · Priority P0
- https://github.com/gildong/launchpad-pm-lab/issues/2 · Status Todo · Priority P1
- https://github.com/gildong/launchpad-pm-lab/issues/3 · Status Todo · Priority P0

{ ... } > 파일은 중괄호 안 여러 명령의 출력을 한 파일에 모은다. >는 파일을 덮어쓰므로 시작 기록은 한 번만 저장한다. 다시 저장해야 하면 파일 이름에 날짜와 시각을 넣는다. 예: sprint-1-start-20261012-1030.json.

JSON에서 Status는 .status, Priority는 .priority처럼 필드 이름의 첫 글자를 소문자로 바꾼 키로 들어 있다. Target date는 .["target date"]로 읽는다.

5결정 기록 남기기

계획 회의에서 나온 결정을 정해진 순서로 댓글에 남긴다. 결정과 관련된 업무에도 같은 결정을 짧게 남기고, 서로의 주소를 적는다.

gh issue comment "$PM_SPRINT_URL" --body-file - <<EOF
**결정 기록**
- 일시: 2026-10-12 10:40
- 결정: 같은 이메일의 재신청은 기존 신청을 유지하고 안내 문구만 보여 준다.
- 이유: 베타 초대 대상 수를 정확히 세기 위해 이메일당 신청 1건을 유지한다.
- 결정자: PM, 개발 담당
- 관련: $PM_POLICY_URL, $PM_FORM_URL
EOF

Issues 탭 맨 위에 [Sprint 1] 운영 이슈가 고정되어 있다.
운영 이슈 본문의 시작 범위에 LP-01~03이 링크로 보인다.
운영 이슈에 시작 범위 댓글과 결정 기록 댓글이 있다.
pm-lab/sprint-1-start.json 파일이 있고 "items"에 3개 항목이 있다.
운영 이슈를 마일스톤에 넣지 않는 이유를 말할 수 있다.

막히면

증상	확인과 해결
시작 범위 절이 비어 있음	`pm-lab/backlog-map.tsv`가 없다. 본문 파일을 편집기로 열어 이슈 주소를 직접 적고 `gh issue edit "$PM_SPRINT_URL" --body-file pm-lab/sprint-1.md`로 고친다.
`sprint-1-start.json`의 items가 빈 목록	Iteration 배정이나 라벨 조건이 맞지 않는다. 실습 6의 CLI 확인 명령으로 Sprint 1 업무를 먼저 확인한다.
결정 기록의 관련 줄에 주소가 비어 있음	`PM_FORM_URL`이 없다. `source pm-lab/env.sh`를 실행했는지 확인한다. 실습 8에서 저장한 값이다.
`gh issue pin`이 실패함	저장소에 이미 3개가 고정되어 있을 수 있다. 웹 Issues 탭 맨 위에서 이전 스프린트의 고정을 해제하거나 `gh issue unpin 번호 -R "$PM_REPO"`를 실행한다.

마치며...

Sprint 1의 목표, 범위, 제외 범위가 운영 이슈 하나에 모였고, 계획 직후의 범위가 JSON 파일과 댓글로 남았으며, 첫 결정 기록이 업무 주소와 함께 기록되었다. 실습 11에서는 주간 점검 전날 이 운영 이슈에 올릴 사전 리포트를 만든다.