숏컷 코드

- [ ] 로그인 화면 구현
- [x] API 응답 형식 정리
- [ ] 문서 업데이트

## 릴리스 준비
- [x] 버전 태그 정리
- [ ] 변경 로그 작성
- [ ] 배포 후 smoke test

문법

task list는 GFM 확장이라 GitHub 이외 환경에서는 체크박스가 렌더링되지 않을 수 있다

- [ ], - [x] 형태의 task list는 GitHub Flavored Markdown 확장 문법이다. GitHub 이슈, PR, 위키, 릴리스 노트에서는 실제 체크박스 UI로 렌더링된다. 반면 CommonMark 표준 파서, 일부 정적 사이트 빌더, Markdown 뷰어에서는 - [ ] 텍스트 가 그냥 일반 bullet 목록으로 처리되거나 대괄호가 그대로 노출될 수 있다. 이식성이 필요한 문서라면 렌더러 지원 여부를 먼저 확인해야 한다.

- [x] 완료된 작업 (GitHub에서 체크 표시)
- [ ] 미완료 작업 (GitHub에서 빈 체크박스)
<!-- CommonMark만 지원하는 환경에서는 일반 목록으로 보일 수 있음 -->

GitHub 이슈와 PR에서는 UI로 체크 상태를 바꿀 수 있어 협업 도구 역할을 한다

GitHub 이슈 또는 PR 본문에 task list를 작성하면, 해당 권한을 가진 사용자가 체크박스를 클릭해 완료 상태를 바로 바꿀 수 있다. 이 클릭은 Markdown 소스를 직접 수정하는 것과 동일하게 처리된다. GitHub는 이슈·PR 목록에서 완료된 task 개수도 함께 보여 주므로, 작업 진행 상황을 빠르게 파악하는 협업 도구로 효과적이다. 단, README 파일의 task list는 클릭이 불가능하고 시각적 표시만 된다.

<!-- 이슈/PR 본문: 클릭 가능한 체크박스 -->
- [ ] 코드 리뷰
- [x] 테스트 작성
- [ ] 문서 업데이트

task list 항목은 실행 가능한 단위로 쪼개야 체크 여부가 의미를 갖는다

task list는 작업의 실행 상태를 드러내는 도구다. 항목이 "백엔드 개발 완료"처럼 모호하고 크면 체크 여부만으로 실제 진행 상황을 알기 어렵고, 협업자가 무엇이 완료됐는지 판단할 수 없다. 릴리스 체크리스트, PR 머지 전 점검, 온보딩 단계처럼 항목이 명확하고 독립적으로 완료 가능한 상황에서 task list가 가장 효과적이다. 항목이 너무 크다면 이슈를 분리하거나 sub-task로 쪼개는 것을 먼저 고려해야 한다.

<!-- 나쁜 예: 항목이 모호하고 큼 -->
- [ ] 백엔드 개발
- [ ] 프론트엔드 작업

<!-- 좋은 예: 독립적으로 완료 가능한 단위 -->
- [x] API 엔드포인트 /users GET 구현
- [x] 응답 스키마 문서화
- [ ] 에러 핸들링 추가
- [ ] 통합 테스트 작성

중첩 task list는 지원되지만 렌더러 간 일관성이 낮다

GFM은 들여쓰기로 중첩 task list를 표현하는 것을 허용하지만, GitHub에서도 중첩 체크박스의 클릭 동작이 최상위 체크박스에 영향을 주지 않는다. 중첩 task list를 과하게 사용하면 이슈 진행 상황 파악이 오히려 복잡해진다. 하위 작업이 많다면 task list 중첩보다 별도 이슈를 만들어 상위 이슈에 참조하는 방식이 GitHub 협업 도구와 더 잘 맞는다.

또한 README의 task list는 "보여 주기용"인지 "실제 진행 추적용"인지 먼저 구분해야 한다. 클릭 가능한 이슈/PR 체크박스와, 정적 문서 안 진행 표시는 운영 방식이 다르다.

선택 기준

주의할 점

- [ ] 서비스 안정화

이런 항목은 체크돼도 무엇이 끝났는지 알기 어렵습니다. task list는 "완료 정의가 짧게 말해지는 단위"일 때만 효과가 큽니다.