cd ~/gh-pm-lab source pm-lab/env.sh
1위키의 구조
- 위키는 저장소와 따로 있는 Git 저장소(
OWNER/REPO.wiki.git)다. 페이지 하나가 Markdown 파일 하나이고, 파일 이름이 페이지 제목이 된다. 파일 이름의 하이픈은 제목에서 공백으로 보인다.결정-기록.md는 “결정 기록” 페이지다. _Sidebar.md와_Footer.md는 모든 페이지의 옆과 아래에 붙는다.- 웹에서 고치든 복제해서 고친 뒤 push하든 같은 Git 이력에 남는다. 누가 언제 어떤 줄을 바꿨는지
git log로 볼 수 있다. - 위키 페이지를 읽고 쓰는 REST API는 없다. gh에도 위키 전용 명령이 없고,
gh repo clone이OWNER/REPO.wiki형식을 받아 위키 저장소를 복제하는 기능이 전부다(gh 2.101.0 소스 기준). - 공개 저장소의 위키는 GitHub Free에서도 쓸 수 있고, 비공개 저장소의 위키는 GitHub Pro, Team, Enterprise 요금제에서 쓸 수 있다. 기본 편집 권한은 저장소 쓰기 권한이다.
- Mermaid 다이어그램과 수식이 위키 페이지에서도 그려진다. 실습 21의 프로세스 지도를 위키에 올릴 때 쓴다.
2기록을 둘 곳 나누기
위키 편집은 PR 리뷰를 거치지 않는다. 그래서 개발자가 그대로 구현해야 하는 기준은 실습 9처럼 저장소의 docs/ 폴더에 두고 PR로 바꾸고, 위키에는 그 PR과 결정 기록을 가리키는 요약을 둔다.
| 기록 | 성격 | 위치 | 검토 |
|---|---|---|---|
| 할 일과 완료 조건, 진행 댓글 | 상태가 계속 바뀐다 | 이슈 | 댓글 |
| 결정 전의 의견 수렴 | 여러 사람이 답을 달고 하나를 채택한다 | 토론 (실습 19) | 답 채택 |
| 정책 문서, API 명세처럼 구현과 같이 바뀌는 기준 | 코드와 같은 리뷰가 필요하다 | 저장소 docs/ + PR | PR 리뷰 |
| 결정 모음, 보고 보관, 용어집, 회의 규칙 | 정리된 사실이고 찾기 쉬워야 한다 | 위키 | Git 이력 |
3위키를 켜고 첫 페이지 만들기
gh repo edit "$PM_REPO" --enable-wiki gh browse -R "$PM_REPO" --wiki
열린 Wiki 탭에서 Create the first page를 누르고, 제목은 Home 그대로 두고 아래 본문을 붙여 넣은 뒤 Save page를 누른다. 첫 페이지를 저장해야 위키 Git 저장소가 생긴다. 그 전에는 복제가 실패한다.
# Launchpad 위키 Launchpad 사전신청 프로젝트의 정리된 기록을 모은다. 할 일은 이슈에, 결정 전 논의는 토론에 있다. | 페이지 | 내용 | 갱신 | | - | - | - | | [마일스톤](마일스톤) | 마일스톤별 마감, 닫힌 업무 | wiki-sync.sh, 주 1회 | | [결정 기록](결정-기록) | 이슈 댓글의 결정 기록 모음 | wiki-sync.sh, 주 1회 | | 상태 보고 | 실습 16 양식의 보고 보관 | wiki-sync.sh, 보고할 때 | | [프로세스 지도](프로세스-지도) | 업무가 흐른 길 (실습 21) | wiki-sync.sh, 마일스톤마다 | 이 페이지는 사람이 고친다. 나머지 페이지는 스크립트가 다시 만든다.
4스크립트로 페이지 만들기
wiki-sync.sh는 위키를 pm-lab/wiki로 복제하고, 저장소 기록으로 네 종류의 페이지를 만든다. --push가 없으면 파일만 만들고 올리지 않는다. 프로세스 지도 파일(pm-lab/process-map.md)은 실습 21에서 만드는 파일이다. 이 단계에서는 키트의 예시 로그로 미리 만든다.
bash github-pm-starter-kit/process-map.sh github-pm-starter-kit/samples/event-log.sample.csv --mermaid count > pm-lab/process-map.md bash github-pm-starter-kit/wiki-sync.sh "$PM_REPO" --process pm-lab/process-map.md
| 페이지 | 만드는 재료 | gh 명령 |
|---|---|---|
| 마일스톤 | 마일스톤의 마감일, 상태, 닫힌 업무 수 | gh api repos/OWNER/REPO/milestones |
| 결정 기록 | “결정 기록”이 들어간 이슈 댓글의 결정, 이유, 결정자 줄과 답을 채택한 토론 | gh api repos/OWNER/REPO/issues/comments, gh discussion list --answered |
| 상태 보고-날짜 | pm-lab/status-YYYY-MM-DD.md 파일 | 없음 |
| 프로세스 지도 | --process로 준 Mermaid 파일 | 없음 |
만든 결정 기록 페이지는 아래와 같다. 2회차 실습 10의 결정 기록 양식에서 “- 결정:”, “- 이유:”, “- 결정자:” 줄을 읽어 표로 만들었으므로, 양식을 지킨 댓글만 표에 제대로 들어간다.
# 결정 기록 > 이 페이지는 wiki-sync.sh가 2026-11-11에 만들었다. 직접 고치면 다음 실행 때 덮어쓴다. 이슈 댓글 중 “결정 기록”이 들어간 댓글을 모았다. 최신 결정이 위에 있다. | 날짜 | 결정 | 이유 | 결정자 | 위치 | | - | - | - | - | - | | 2026-11-05 | LP-03 재작업이 끝날 때까지 LP-05는 재신청 외 항목부터 검증한다 | 토론 #23 합의. 재신청 항목만 막혀 있다 | gildong, qa-park | [#16](https://github.com/gildong/launchpad-pm-lab/issues/16#issuecomment-4530) | | 2026-10-26 | 운영자 수동 확인 화면은 M2로 미룬다. M1에서는 LP-04 알림의 일일 집계로 대신한다 | Sprint 2 목표(운영 알림, QA, 베타 준비) 밖의 범위. 하루 100건 초과 근거 없음 | gildong | [#16](https://github.com/gildong/launchpad-pm-lab/issues/16#issuecomment-4430) | | 2026-10-26 | 같은 이메일로 다시 신청하면 최신 신청으로 덮어쓰고 동의 시각을 갱신한다 | 법무 검토 의견(개인정보 동의 시각은 최신 동의 기준) | gildong | [#3](https://github.com/gildong/launchpad-pm-lab/issues/3#issuecomment-4410) | | 2026-10-22 | M1 마감을 11-13으로 1주 미룬다(선택지 3) | 10-21 기준 SPI(t) 0.62, 확률 예측 50% 시점 11-13 | gildong, 개발 리드 | [#8](https://github.com/gildong/launchpad-pm-lab/issues/8#issuecomment-4210) | ## 토론에서 채택한 답 | 날짜 | 토론 | | - | - | | 2026-10-26 | [#17 재신청 정책 변경: 덮어쓰기 적용 범위](https://github.com/gildong/launchpad-pm-lab/discussions/17) |
내용을 확인한 뒤 같은 명령에 --push를 붙여 다시 실행한다. Home 페이지는 사람이 쓰는 페이지이므로 스크립트가 건드리지 않는다.
5위키 이력 읽기
위키는 Git 저장소이므로 결정 기록 페이지가 언제 어떻게 바뀌었는지 명령으로 확인할 수 있다. 주간 회의 전에 한 번씩 실행하면 커밋 하나가 한 주 동안 늘어난 결정이 된다.
git -C pm-lab/wiki log --oneline -- 결정-기록.md git -C pm-lab/wiki diff HEAD~1 -- 결정-기록.md
마일스톤 페이지의 마감일은 GitHub의 현재 값이다. GitHub는 마감일을 바꾼 이력을 남기지 않으므로, “11-06에서 11-13으로 바꿨다”는 사실은 결정 기록 페이지의 10월 22일 줄에만 있다. 마감일을 바꿀 때 결정 기록을 먼저 남기는 이유다.
비공개 저장소이고 계정이 GitHub Free이면 위키를 쓸 수 없다. 이때는 같은 페이지를 저장소의 docs/pm/ 폴더에 만들고 PR로 올린다. --no-git은 위키를 복제하지 않고 지정한 폴더에 파일만 만든다.
cd "$PM_REPO_NAME" && git switch main && git pull -q && git switch -c docs/pm-pages && cd .. bash github-pm-starter-kit/wiki-sync.sh "$PM_REPO" --no-git --dir "$PM_REPO_NAME/docs/pm" --process pm-lab/process-map.md cd "$PM_REPO_NAME" && git add docs/pm && git commit -m "docs: PM 페이지 갱신" && git push -u origin docs/pm-pages && gh pr create --fill && cd ..
이 방식은 PR 리뷰를 거치므로 갱신이 느린 대신, 결정 기록 모음도 코드와 같은 검토를 받는다.
막히면
| 메시지 | 원인과 조치 |
|---|---|
위키를 복제하지 못했다 | 첫 페이지가 없거나 위키가 꺼져 있다. 3단계를 다시 한다. |
The '…' repository does not have a wiki | 위키 기능이 꺼져 있다. gh repo edit "$PM_REPO" --enable-wiki를 실행한다. |
| 결정 기록 표의 결정 칸이 비어 있다 | 댓글에 “- 결정:”으로 시작하는 줄이 없다. 실습 10의 양식대로 댓글을 고친다. |
! [rejected] … (fetch first) | 다른 사람이 웹에서 위키를 고쳤다. 같은 명령을 다시 실행하면 먼저 최신으로 맞춘다. |
- 위키를 켜고 Home 페이지를 만들었다.
wiki-sync.sh로 만든 페이지를 확인한 뒤--push로 올렸다.- 위키의 결정 기록 페이지에서 M1 마감을 바꾼 날짜와 이유를 찾았다.
- 이슈, 토론,
docs/, 위키에 각각 무엇을 둘지 팀 규칙 한 줄로 적었다.
마치며...
위키는 새 기록을 만드는 곳이 아니라, 이슈와 PR과 토론에 남은 기록을 찾기 쉬운 형태로 모으는 곳으로 썼다. 모으는 일을 스크립트에 맡겼으므로 원본은 언제나 이슈 댓글이고, 위키는 실행할 때마다 원본에서 다시 만들어진다. 다음 실습에서는 브랜치를 업무와 연결하고, Project 스냅숏을 쌓을 PM 데이터 브랜치를 만든다.