이슈를 혼자 쓸 때도 쓸모 있는 이유 — 개인 저장소의 이슈 활용
이슈는 협업용만이 아니다. 혼자 하는 프로젝트에서 판단 기록으로 쓰는 방법.
협업 도구라는 선입견
이슈는 여럿이 일할 때만 필요하다고 생각하기 쉽다. 그런데 혼자 하는 프로젝트에서도 두 가지 문제가 있고, 이슈가 그것을 해결한다.
- 며칠 뒤 돌아왔을 때 맥락이 사라진다
- 왜 그렇게 했는지가 코드에만 남는다
재개 지점 남기기
작업을 중단할 때 이슈에 한 줄 남긴다.
```
현재: 파서까지 완료
다음: 에러 케이스 3종 처리 (빈 입력 / 중복 키 / 순환 참조)
막힌 것: 순환 참조 감지를 어디서 할지 미정
```
며칠 뒤 이 세 줄이 30분의 재구성 시간을 없앤다. 코드만 보고 "어디까지 했더라"를 되짚는 것보다 훨씬 빠르다.
결정 기록으로 쓰기
기술 선택을 할 때 이슈에 비교를 적어두면, 나중에 같은 고민을 반복하지 않는다.
```markdown
상태 관리 도구 선택
고려
- Context: 의존성 없음. 리렌더 범위 제어가 번거로움
- Zustand: 가볍고 API 단순. 의존성 추가
- Redux: 팀 익숙함. 이 규모에는 과함
결정
Context. 공유 상태가 2개뿐이라 도구 도입 이득이 작다.
재검토 조건
공유 상태가 5개를 넘거나 리렌더 문제가 실제로 발생하면
```
'재검토 조건'을 함께 적는 것이 유용하다. 나중에 이 결정을 뒤집을지 판단하는 기준이 남는다.
라벨 최소 구성
라벨을 많이 만들면 붙이는 것 자체가 일이 된다. 혼자 쓸 때는 셋이면 충분하다.
bug— 동작이 잘못됨enhancement— 개선·추가question— 결정이 필요함
여기에 우선순위 하나(p1 같은)만 추가해도 목록 정렬이 된다.
이슈와 TODO 주석의 구분
| 상황 | 적합한 것 |
|---|---|
| 이 줄에서 나중에 처리 | // TODO: 주석 |
| 배경 설명이 필요함 | 이슈 |
| 여러 파일에 걸침 | 이슈 |
| 결정이 필요함 | 이슈 |
| 며칠 안에 처리 | 주석 |
TODO 주석은 코드를 읽을 때 보이지만 목록으로 관리되지 않는다. 쌓이면 아무도 안 본다. 오래 남을 것 같으면 이슈로 옮기고 주석에 이슈 번호를 남긴다.
```javascript
// TODO(#42): 순환 참조 감지 추가
```
닫을 때 남길 것
해결하고 닫을 때는 커밋 링크만 있어도 충분하다. 문제는 하지 않기로 한 경우다.
```
닫음 — 구현하지 않기로.
사용 빈도가 낮고 대안(수동 새로고침)이 있어 비용 대비 이득이 적음.
요청이 다시 오면 재검토.
```
이유 없이 닫으면 나중에 같은 아이디어가 다시 올라오고 같은 판단을 반복한다.
마일스톤은 언제
버전이나 목표 시점이 있을 때만 쓴다. 개인 프로젝트에서 마일스톤을 만들어놓고 방치하는 경우가 흔한데, 비어 있는 마일스톤은 관리 부담만 된다.
이슈 목록이 20개를 넘어가면 그때 묶는 정도로 충분하다.
최종 수정 2026-08-28