✅ 리팩토링 하자더니 기능부터 넣자고 한다

🔎 유용한 정보

팀장이 말했다.
“이번에 리팩토링 좀 합시다.”
“아예 구조 정리하고 가죠.”
“기능 넣기 전에 기반부터 다지자고요.”

솔직히 말해,
그 말 들으면 기대하게 된다.
“와 드디어 코드 정리 시간 주는구나!”

근데 바로 이어지는 말:
“근데 일정은 그대로입니다.”
“이번 주까지 이 기능도 같이 넣어야 해요.”

하아…

"정리? 나중에 하자고요"
"지금은 기능부터 넣고 보자"
"출시 급한 거 알잖아요"

결국 팀에선 리팩토링이
✔ 중요한 일도 아니고
✔ 급한 일도 아니고
✔ 그냥 하면 좋은 ‘장식’ 같은 느낌

근데 나중이 오질 않는다.
그게 현실이다.

“일단 저쪽에 기능 하나 붙여요”
“API 응답 구조 조금만 바꿔서 붙이죠”
“그 로직 복사해서 여기다도 넣죠”

그게 반복되면?
✔ 3중 조건문
✔ 파일 1천줄
✔ 컴포넌트 중복
✔ 도대체 어디서 뭐 타고 오는지도 모름

그냥 “새로운 코드”가 아니라
“구조 망친 코드”가 돼버린다.

✔ 새로운 기능 넣기 점점 느려짐
✔ 테스트 커버리지도 줄고
✔ 협업하는 팀원도 지쳐가고
✔ 결국 이직자 생김

그럼 남은 사람들만 다시
“리팩토링해야죠…”
얘기 꺼낸다.
근데 또 일정은 안 준다.

이건 무한 루프다.

진짜 리팩토링 원하면
✔ sprint 단위로 구조 개선 시간 넣고
✔ 기능 대신 유지보수성 지표 측정하고
✔ 의사결정권자가 일정 줄여야 한다

“하라고 했다” = 한 게 아님
시간과 범위 없이 시키는 리팩토링은
그냥 ‘책임 전가’다.

리팩토링은 구호가 아니다.
✔ 시간 줘야 하고
✔ 설계해야 하고
✔ 리뷰 받아야 한다

그게 없이 “리팩토링 해달라”고 말하는 건
**"책임은 니가 져, 나는 빠질게"**와 똑같다.

코드 정리할 기회를 안 주는 조직은,
결국 엉망진창 코드를 계속 만들게 된다.

#리팩토링현실 #기술부채폭발 #기능먼저
#개발자고민 #코드정리못함 #프로그래머일상
#기술부채지옥 #개발문화비판 #Sprint의거짓말 #코드가누더기