삭제 준비(Expiry-Ready)된 코드를 통한 기술부채 회피 전략

배경

End-to-End 연결성이 많은 서비스 환경에서는 기능 변화가 잦고 외부 인터페이스와의 연동이 복잡합니다.
다양한 예외 처리와 임시 대응 로직이 빠르게 축적됩니다.
특히 ‘일단 되게 만드는 코드’가 장기적으로 정리되지 않는경우 :

• 곧 기술부채로 고착화되고 시스템의 유지 관리성과 신뢰성을 떨어뜨리게 됩니다.

문제

• 임시 로직, 예외 대응, 테스트용 코드가 누적되며 점점 지우기 어려운 상태로 변함
• 코드의 존재 이유나 제거 조건이 명확하지 않아, 시간이 흐를수록 ‘이 코드 삭제해도 되나요?’라는 질문에 대답할 수 없게 됨
• 정리 시점을 놓치면 기술부채가 축적되고, 이는 장애나 운영 비용 증가로 이어짐

실행 전략: 삭제 준비(Expiry-Ready)를 중심으로 설계하고 운영하기

기술부채는 제거하는 것이 아니라, 애초에 쌓이지 않도록 설계하는 것이 더 중요합니다.
그 핵심은 코드를 삭제할 수 있도록 만드는 것, 다시 말해 “퇴장 가능한 구조”를 설계하는 데 있습니다.

실행 이유

• 코드의 수명과 삭제 조건이 명확하지 않으면, 기술부채는 시간에 따라 감춰진 리스크가 됨
• 다양한 시스템과 연결된 코드일수록 정리 기준이 없으면 삭제가 불가능해지고, 이는 곧 장애와 유지보수 부담으로 전이됨
• 따라서 코드 작성 시점부터 삭제 준비(Expiry-Ready)를 고려하고, 정리 루틴을 조직적으로 마련하는 것이 핵심임

실행 방법

1. 삭제 기준 명시

   • REMOVE_BY, TODO (exp:), @deprecatedUntil 등 주석 형태로 퇴장 시점과 이유를 코드에 명확히 기록
   • 리뷰 시 주석 확인 및 정기 점검을 통해 관리

2. 코드 책임 명확화

   • 왜 존재하는지, 언제까지 필요한지를 코드 내부 또는 지식베이스에 함께 기록
   • 릴리즈 노트, 팀 문서 등과 연계하여 제거 대상 코드의 히스토리 추적 가능하도록 관리

3. 자동화보다 습관화 중심으로 운영

   • 자동화 인프라 부족으로 CI/CD 연동은 미도입 상태였지만, 수동 체크리스트 기반의 반복적 리뷰 문화로 대체 운영

4. 정리 시간을 통한 퇴장 설계

   • 스프린트 일정 중 약 20%를 코드 정리, 리팩터링, 문서화에 명시적으로 할당
     https://devchan64.github.io/2025/04/14/technical-debt-is-not-about-code.html
   • 단순한 구조 개선이 아닌, “삭제 준비(Expiry-Ready)된 코드로 만들기”를 목표로 설계

결과

• 삭제 기준이 명확한 코드가 늘어나며, 기술부채가 누적되기 전 제거되는 루틴 형성
• 팀원들도 주석 기반 삭제 타이밍과 히스토리 관리에 자발적으로 참여함
• 정리 주기와 기능 개발 사이의 균형 유지 가능 → 일정 지연 없이 코드 품질 유지

인사이트

• 기술부채는 늦게 치울수록 무겁다. 퇴장을 설계하지 않은 코드는 기술 리스크다.
• 정리는 ‘아름다움’이 아닌 ‘삭제 준비(Expiry-Ready)’를 위한 활동이어야 한다
• 결국 기술부채 회피 전략은 조직적 습관, 삭제 준비(Expiry-Ready) 중심의 코드 문화, 그리고 명확한 퇴장 조건이 결합될 때 실현된다

핵심 메시지

“정리는 코드의 퇴장을 가능하게 하기 위한 준비다.”
“삭제되지 않을 코드는 쓰지 않는다.”