TODO는 실제로 '처리하기 위한 것'이 아님

• 일부 팀은 모든 TODO 주석을 버그 트래커에 등록하거나, 1년 이상 된 TODO는 자동 삭제하는 정책을 쓰지만, 이러한 관행을 권장하지 않음
• TODO 주석은 반드시 완수해야만 가치가 있는 것이 아니라, 코드 작성 시점의 맥락·아이디어를 남기는 뇌의 스냅샷 역할
• 중요한 TODO는 이슈로 관리해야겠지만, 대부분은 우선순위가 낮거나 엣지케이스를 기록하는 메모임
• 잘 배치된 TODO는 미래의 코드 리더가 "이 부분을 리팩터링해도 될까?" 고민할 때 당시 저자의 의도를 파악하는 힌트 제공
• TODO의 가치는 완수 여부가 아니라, 맥락·의도·가능성을 기록해 미래의 유지보수와 협업에 도움을 주는 점에 있음

TODO 주석, 꼭 처리해야만 할까?

• 일부 조직에서는 코드 내 모든 TODO를 버그 트래커에 등록하거나, 일정 기간(1년 이상) 지나면 자동 삭제하는 규칙을 적용
• 그러나 이런 접근은 실제로 비효율적이며, TODO의 본질을 놓침 - 실제로 처리되어야만 가치가 생기는 것은 아님

TODO의 진짜 가치

• 예를 들어,

  // TODO: 다음 주 출시 전에 이 파일의 뒷부분을 완성해야 함

  같은 주석은 실제로 트래킹할 필요가 있을 수 있음

• 하지만 좋은 TODO는 대개

  // TODO: 사용자가 이 버튼을 트리플 클릭할 경우, 핸들러에서 \[xyz] 오류 발생

  처럼 엣지케이스를 기록하거나, 지금 당장 하지 못한 구조 개선 아이디어, 놓친 상황 등을 맥락과 함께 기록하는 용도

TODO는 '계획'이 아니라 '창구'

• 대부분의 TODO는 실제로 즉시 처리될 필요가 없는 낮은 우선순위
• 작성 시점의 저자의 고민과 판단, 컨텍스트를 미래의 코드 리더에게 전달하는 역할
• 훗날 코드를 읽는 사람이 "여기 구조를 바꿔도 될까?" 고민할 때, TODO가 당시 저자의 의도를 파악하는 데 도움이 됨

잘 작성된 TODO의 효과

• 코드 내 TODO는 때로 문제의 여지, 구조 개선 가능성, 미처리된 엣지케이스 등 중요한 힌트를 제공
• 반드시 해결을 위한 계획이 아니더라도, 협업과 유지보수에서 미묘한 맥락 전달에 큰 역할
• 결국 TODO 주석은 코드의 이해도와 향후 유지보수성을 높이는 소중한 기록물 역할임

결론

• TODO는 꼭 완료해야만 가치를 갖는 것이 아니라, 저자의 생각·의도·컨텍스트를 남겨 미래의 코드 리더와의 소통 창구가 됨