솔직히 말해서, 개발자라면 누구나 한 번쯤 이런 꿈을 꿉니다.
"이번 스프린트는 기능 개발 멈추고 리팩토링(Refactoring)만 하시죠."
저도 왕년에 PM 하면서 개발 팀장님한테 이 소리 듣고 끄덕였다가, 임원 보고 들어가서 영혼까지 털렸습니다.
오늘은 그 뼈아픈 기억을 되살려, 왜 '리팩토링'을 백로그(Backlog)에 올리면 안 되는지 이야기해보려 합니다.
프로젝트 초기, 기억나시나요?
git init 했을 때의 그 상쾌함.
코드는 깨끗하고, 아키텍처는 완벽해 보이고, 세상은 우리 편 같죠.
기능 하나 추가하는 건 식은 죽 먹기입니다.
그런데 일정이 조금씩 밀리면서 우리는 타협을 시작합니다.
"일단 돌아가게만 짜고 나중에 고치자."
코드 구석에 // FIXME 같은 주석 하나 박고 넘어갑니다.
이게 바로 '잡초'입니다.
처음엔 티도 안 납니다.
하지만 개발을 하다 보면 이 잡초들을 피해 가느라 조금씩 우회하게 됩니다.
코드가 더러우니 건드리기 무섭고, 그러다 보니 더 엉망으로 덧덛게 되죠.
어느 순간 속도가 확 느려집니다.
발목에 넝쿨이 감기니까요.
그때 주니어 개발자들이나 의욕 넘치는 리더가 들고일어납니다.
"기술 부채(Technical Debt)가 너무 심해요. 이거 안 갚으면 앞으로 못 나갑니다."
그러면서 백로그에 '코드 리팩토링'이라는 거창한 티켓을 생성해 달라고 요구합니다.
이게 최악의 수입니다.
PM 입장에서, 그리고 경영진 입장에서 이걸 승인해 주는 건 무슨 뜻인지 아십니까?
"지난 몇 달 동안 우리가 코드를 엉망으로 만들었으니, 기능을 멈추고 청소할 시간을 주세요"라고 자백하는 꼴입니다.
냉정하게 말해서, 누가 좋아하겠습니까?
백 번 양보해서 시간을 줬다고 칩시다.
2주 동안 기능 배포 올 스톱하고 코드만 고쳐요.
결과는? 대개 망합니다.
엔드 유저 눈엔 UI 픽셀 하나 바뀐 게 없는데, 내부는 대공사를 했으니 온갖 사이드 이펙트(Side Effect)가 터집니다.
경영진은 "돈 쓰고 시간 썼는데 왜 기능은 그대로냐"라고 묻습니다.
할 말이 없죠.
신뢰는 바닥을 칩니다.
그럼 이 지저분한 레거시(Legacy)를 안고 그냥 죽으라는 거냐?
아닙니다. 방법이 잘못됐을 뿐입니다.
리팩토링은 백로그에 올리는 별도의 업무가 아닙니다.
그냥 '일하는 방식'이어야 합니다.
해결책은 의외로 간단합니다.
이번 스프린트에 할당된 기능을 개발할 때, 그 경로에 있는 잡초를 같이 뽑는 겁니다.
기획서에 있는 '로그인 개선' 기능을 맡았다고 칩시다.
그럼 로그인 모듈 코드를 열었을 때 보이는 스파게티 코드를 그때 정리하는 겁니다.
엉망인 코드를 피해 우회하지 말고, 덤불을 베어내며 길을 내면서 가세요.
내가 건드리지 않는 다른 모듈의 잡초는?
철저히 무시하세요.
오직 지금 내가 작업해야 할 기능이 지나가는 길만 닦는 겁니다.
"그럼 기능 개발 시간이 더 걸리잖아요."
주니어들이 자주 하는 걱정입니다.
하지만 해보면 압니다.
처음엔 잡초 뽑느라 시간이 좀 더 걸리는 것 같지만, 길이 닦이면 기능 붙이는 속도가 비약적으로 빨라집니다.
오히려 나중에 따로 날 잡아서 대청소하는 것보다 훨씬 효율적입니다.
게다가 요즘은 Cursor나 GitHub Copilot 같은 AI 도구들이 있잖아요?
함수 하나 정리하는 건 일도 아닙니다.
"이 함수 좀 읽기 좋게 분리해 줘"라고 AI한테 시키고, 리뷰만 꼼꼼히 하세요.
이런 게 진짜 AI 활용법입니다.
이렇게 하면 따로 리팩토링 기간을 달라고 읍소할 필요가 없습니다.
기능은 기능대로 나가고, 코드는 갈수록 깨끗해집니다.
비즈니스 팀도 좋아하고, 개발팀도 만족합니다.
따로 날 잡아서 대청소하겠다고 하지 마세요.
평소에 설거지 안 하다가 주말에 몰아서 하려다 몸살 나는 거랑 똑같습니다.
그냥 밥 먹으면 바로 치우세요.
그게 진짜 고수입니다.
이번 스프린트부터, 백로그에 '리팩토링' 티켓 만드는 대신 커밋 메시지에 'Refactor'를 자연스럽게 섞어보시길 바랍니다.
