TODO가 왜 썩는가 — 그리고 내가 만든 도구로 그것들을 만료시키는 방법
Source: Dev.to
내가 작업한 모든 코드베이스에는 같은 묘지가 있다.
그것은 폴더에 있는 것이 아니다.
그것은 주석에 있다.
// TODO: remove later
// FIXME: temporary hack
// HACK: this is ugly우리는 좋은 의도로 이를 작성하고, 나중에 다시 올 거라 스스로에게 말하지만 거의 절대 하지 않는다. 6개월이 지난 뒤에는 누가 그 코드가 왜 존재하는지 기억하지 못하지만, 이제는 프로덕션의 일부가 되었고—그것을 건드리는 것은 위험하게 느껴진다. 이것은 게으름이 아니라 소프트웨어 시스템이 작동하는 방식이다.
TODO의 진짜 문제
TODO는 마감일이 없는 약속이다. 마감일이 없으면:
- 소유자가 없다
- 우선순위가 없다
- 비용이 없다
그래서 조용히 썩어간다. 팀이 기술 부채를 무시하는 것은 관심이 없어서가 아니라—그것을 표면에 드러나게 하는 강제력이 없기 때문이다.
나는 TODO가 실제 작업처럼 행동하기를 원했다
버그는 무시되지 않는다 because:
- CI가 실패/경고한다
- 티켓이 생성된다
- 사람이 호출된다
기술 부채도 같은 방식으로 동작한다면 어떨까? 이 질문이 나를 **DebtBomb**이라는 작은 오픈소스 CLI를 만들게 했다.
DebtBomb 작동 방식
다음과 같이 작성하는 대신:
// TODO: remove later이렇게 작성한다:
// @debtbomb(expire=2026-02-10, owner=pricing, reason="temporary promo logic")즉, “이 코드는 존재해도 되지만, 이 날짜까지만 허용한다”는 의미다.
DebtBomb은 CI에서 코드를 스캔한다. 만료일이 지나면:
- 빌드가 실패하거나 경고한다
- Jira 티켓이 생성되거나 업데이트된다
- 팀에 Slack, Discord, Microsoft Teams 등으로 알림이 전송된다
부채가 눈에 보이고, 소유자가 지정되며, 무시할 수 없게 된다.
왜 이것이 행동을 바꾸는가
마법은 파싱에 있는 것이 아니라 압박에 있다. 개발자들이 알게 되면:
- 만료된 부채가 배포를 차단한다
- Jira에 표시된다
- 팀에 알림이 간다
그들은 모호한 TODO 작성을 멈추고 실제 결정을 내리게 된다:
- “정말 이게 필요할까?”
- “누가 담당인가?”
- “언제 제거할까?”
부채는 희망이 아니라 계약이 된다.
언어에 구애받지 않으며 매우 간단하다
DebtBomb은 코드를 이해할 필요가 없다; 주석만 읽는다. 따라서 주석을 지원하는 모든 언어와 함께 작동한다, 예를 들어:
- Go
- TypeScript
- Python
- Rust
- Java
- Bash
- 주석이 있는 모든 것
AST도, 컴파일러도 필요 없다—그냥 평문이다.
DebtBomb은 다음과 통합된다:
- Jira
- Slack
- Discord
- Microsoft Teams
그래서 만료된 부채가 조용히 실패하지 않고, 팀이 이미 사용하는 곳에 나타난다.
30초 만에 사용해 볼 수 있다
go install github.com/jobin-404/debtbomb/cmd/debtbomb@latest
debtbomb checkRepo: github.com/jobin-404/debtbomb
피드백을 기다린다. 이 도구는 개인적인 갈증에서 시작했지만, 많은 사람들이 TODO가 썩는 것을 싫어한다는 것을 알게 되었다.
프로덕션 시스템에서 기술 부채를 다뤄본 경험이 있다면, 다음을 알려 주세요:
- 오늘날 “임시” 코드를 어떻게 추적하고 있나요?
- 이와 같은 도구가 팀에서 실제로 사용 가능하게 만들려면 무엇이 필요할까요?