1인 개발 이슈 관리 — GitHub Projects 대신 Milestones를 선택한 이유

소재

trip-planner 프로젝트에서 speckit 기반 이슈가 늘어나며 상위 목표 묶음이 필요해짐.
GitHub Projects(칸반) vs Milestones 비교 후 Milestones 선택.

업데이트 (2026-04-19):
이후 운영하면서 CHANGELOG 중복 작성 문제를 마주함.
이슈/PR/CHANGELOG가 같은 정보를 반복 기록하는 구조였음.
마일스톤이 단순 그룹핑을 넘어 버전 관리의 단일 진실원으로 정착됨.
릴리스 자동화 도입으로 인해 마일스톤은 "있으면 좋은" 단계에서 "필수" 단계로 전환됨.

PAAR 구조

• P: 이슈 연쇄 생성 → 상위 목표 묶음 필요
• A: Projects vs Milestones 비교, 1인 개발 관리 비용 고려
• A: 순번(M7) → 버전 기반(v2.1) 전환, 독립 진행 체계
• R (1차): 마일스톤 3개 + 이슈 8개 구조화, 보드 없이 충분
• R (2차, 추가): CHANGELOG 중복 해소 + 릴리스 자동화 연결로 버전 관리용 필수 처리됨

추가 분석 포인트 (작성 시 보강)

• CHANGELOG 중복의 구체적 양상: 무엇이 어디서 중복되었는가
• "있으면 좋은" → "필수"로 전환된 분기점: 어떤 도구/프로세스의 강제 메커니즘이 작용했는가
• GitHub Release 자동화와의 연결: 릴리스 노트 생성에서 마일스톤이 어떻게 활용되는가

참고

• trip-planner 마일스톤: https://github.com/idean3885/trip-planner/milestones
• GitHub Release 자동화 포스팅 (#214): https://blog.idean.me/posts/github-release-automation-changelog/
• 단편 포스팅

Start with the existing issue and the linked GitHub Release automation post (#214), then compare the trip-planner milestones reference with the current explanation. Expand the post with concrete CHANGELOG duplication examples, the process change that made milestones required, and how release-note generation uses them; done means these three analysis points are documented without repeating the same information.