1Sprint 2와 Sprint 3에 생긴 일
3회차의 기준일(10월 21일) 다음 날부터 M1을 마칠 때까지의 기록이다. 4회차 실습은 모두 이 기록을 재료로 쓴다. 날짜와 번호는 실습 시나리오이고, 같은 내용이 키트의 samples/event-log.sample.csv에 들어 있다.
| 날짜 | 일 | 남은 기록 |
|---|---|---|
| 10-22(목) | 주간 회의에서 M1 마감을 11-06에서 11-13으로 옮겼다 (실습 16 결정 요청의 선택지 3) | 운영 이슈 #8의 결정 기록 댓글 |
| 10-26(월) | 법무 의견으로 재신청 정책을 “최신 신청으로 덮어쓰기”로 바꿨다 | 토론 #17, 정책 문서 PR #18, 업무 #3의 결정 기록 |
| 10-26(월) | LP-02의 PR #9에 PM이 변경 요청 리뷰를 남겼다 (안내 문구가 바뀐 정책과 다르다) | PR #9 리뷰 |
| 10-28(수) | LP-04가 LP-03이 끝나기 전에 시작했다 | Project 스냅숏의 Status |
| 11-02(월) | LP-03이 PR #20 병합으로 닫혔다 | PR #20, 업무 #3 타임라인 |
| 11-05(목) | QA가 재신청 결함을 찾아 LP-03을 다시 열었고, LP-05를 막힘으로 표시했다 | 업무 #3, #5 타임라인, 토론 #23 |
| 11-06(금) | PR #22 병합으로 LP-03이 다시 닫혔다. 원래 M1 마감일이다 | PR #22 |
| 11-11(수) | LP-06이 닫혀 M1의 업무 6건이 모두 끝났다 | 마일스톤 M1 닫힘 |
이 기록만 놓고 보면 “M1은 계획(11-04)보다 5작업일 늦게, 바꾼 마감(11-13)보다 2작업일 일찍 끝났다”까지는 바로 말할 수 있다. 그 5작업일이 어디서 생겼는지, 결정과 논의가 어디에 흩어져 있는지는 기록을 다시 엮어야 보인다.
2질문과 기록
| 질문 | 기록 | 도구 | 실습 |
|---|---|---|---|
| 정리된 결정과 보고를 한곳에서 찾을 수 있는가 | 이슈 댓글의 결정 기록, 상태 보고 파일 | 위키, wiki-sync.sh | 17 |
| 어느 브랜치가 어느 업무이고, 멈춘 작업은 무엇인가 | 브랜치, 연결된 PR | gh issue develop, branch-report.sh | 18 |
| 업무가 언제 시작했는가 | 날마다 저장한 Project 스냅숏 | PM 데이터 브랜치, GitHub Actions | 18 |
| 지난 2주 동안 무엇을 논의했고 무엇을 정했는가 | 토론, 결정 기록, PR 리뷰 | gh discussion, discussion-digest.sh | 19 |
| 선후행 관계의 어디에서 시간이 생기고 줄었는가 | 업무별 실제 시작일과 완료일 | event-log.sh, lead-lag.sh | 20 |
| 업무가 실제로 어떤 순서로 흘렀고, 합의한 절차와 얼마나 다른가 | 이벤트 로그 | process-map.sh, PM4Py | 21 |
3기록이 남는 곳과 기간
GitHub의 기록은 종류마다 저장 위치와 조회 방법, 남는 기간이 다르다. 4회차의 도구 선택은 이 표에서 나온다.
| 기록 | 조회 방법 | 남는 기간과 제약 |
|---|---|---|
| 이슈·PR 타임라인 (라벨, 닫힘, 다시 열림, 참조, 리뷰) | gh api repos/OWNER/REPO/issues/번호/timeline | 이슈가 있는 동안 남는다 |
| 저장소 활동 이벤트 | gh api repos/OWNER/REPO/events | 최근 90일, 최대 300건까지 돌려준다. 반영까지 30초에서 6시간이 걸린다 |
| Project의 Status 변경 | 공개 API에 변경 이력을 조회하는 항목이 없다 | 현재 값만 읽을 수 있다. 이력이 필요하면 날마다 저장해 둔다 |
| 마일스톤 마감일 | gh api repos/OWNER/REPO/milestones | 현재 마감일만 남는다. 바꾼 이유와 이전 값은 결정 기록에 적는다 |
| 토론 | gh discussion list, gh discussion view (gh 2.101.0, 미리 보기 기능) | 저장소가 있는 동안 남는다 |
| 위키 | gh repo clone OWNER/REPO.wiki, git log | 별도 Git 저장소라 페이지마다 이력이 남는다. 페이지를 다루는 REST API는 없다 |
Project의 Status 이력은 2026년 10월 기준 GitHub GraphQL 공개 스키마(@octokit/graphql-schema 15.26.1)의 이슈 타임라인 항목 목록에 없다. 실습 18에서 평일마다 Project 항목을 저장하는 PM 데이터 브랜치를 만드는 이유다.
4미리 보기: 업무 6건이 흐른 길
아래는 실습 21에서 만드는 프로세스 지도다. 상자는 활동(activity), 화살표는 한 업무 안에서 바로 이어진 두 활동, 화살표의 숫자는 그 연결이 나온 횟수다. 재생하면 업무 하나가 점 하나로 나타나 기록 시각을 따라 움직인다. 점이 오래 머무는 화살표가 기다린 구간이다.
- Sprint 2와 Sprint 3의 주요 기록 8개가 각각 어느 기록 종류에 남았는지 확인했다.
- Project의 Status 이력을 나중에 조회할 수 없다는 점과 그 대안을 설명할 수 있다.
- 4회차 실습 17~21이 각각 어떤 질문에 답하는지 확인했다.
마치며...
4회차의 질문은 “얼마나 끝났는가”에서 “어떻게 흘렀는가”로 옮겨 간다. 그 답에 필요한 기록 중 일부는 이미 GitHub에 남아 있고, 일부는 지금부터 따로 쌓아야 한다. 다음 실습에서는 이슈 댓글에 흩어진 결정 기록과 PM 폴더의 상태 보고를 위키 한곳으로 모은다.