리팩토링할 시간이 없다는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-08-04

#리팩토링 #성장 #백엔드

"일정이 너무 타이트해서 리팩토링할 시간이 없어요."

200명이 넘는 백엔드 주니어 개발자들을 멘토링하며 가장 자주 듣는 이야기 중 하나입니다. 당장 다음 주 배포가 다가오는데 코드를 깨끗하게 정리할 여유가 어디 있냐고 하소연합니다.

하지만 10년 넘게 실무에서 코드를 작성하고 고치며 깨달은 단 한 가지 사실이 있습니다. 리팩토링은 일정이 한가할 때 따로 날을 잡아 실행하는 이벤트가 아닙니다.

1. 리팩토링을 커다란 프로젝트로 생각합니다

멘토링했던 2년 차 개발자 A씨의 사례가 대표적입니다. A씨는 3주 동안 기능 개발을 끝낸 뒤 사수에게 "일주일만 리팩토링 기간을 달라"고 요청했다가 거절당했습니다.

회사 입장에선 당연한 결정입니다. 이미 잘 동작하는 코드인데 굳이 일주일의 공수를 들여 위험을 무릅쓸 이유가 없기 때문입니다.

A씨가 범한 오류는 리팩토링을 '나중에 크게 한 번 하는 작업'으로 본 점입니다. 진짜 리팩토링은 10분 단위로 일어납니다. 변수 이름을 명확히 바꾸고, 50줄짜리 메서드를 3개로 쪼개는 5분의 습관이 모여 코드베이스를 지킵니다.

"시간이 없다"고 말하는 개발자의 80%는 사실 "고쳤다가 장애가 날까 봐 무섭다"가 본심입니다. 실무 프로젝트 코드를 함께 리뷰할 때, 클래스명 하나 변경하는 것조차 벌벌 떠는 주니어들을 수없이 만났습니다.

안전망이 없으니 손을 대지 못하고, 손을 대지 않으니 코드는 날이 갈수록 엉킵니다. 결국 시간이 없어서 못 고치는 게 아니라, 테스트 코드가 없어서 건드리지 못하는 겁니다.

소형 단위 테스트 2-3개만 작성해 두어도 함수 내부를 다듬는 작업은 3분이면 충분합니다. 리팩토링 속도를 결정하는 것은 여유 시간이 아니라 테스트의 존재 유무입니다.

음식을 다 만들고 난 뒤 냄비와 접시를 바로 씻지 않으면 기름때가 굳어 나중에 청소하기 훨씬 어렵습니다. 코드 역시 마찬가지입니다.

기능 구현 티켓을 마무리하기 직전, 딱 15분만 투자해서 작성한 코드를 다시 읽어보세요. 변수명이 의도를 제대로 나타내는지, 한 함수가 과도하게 많은 역할을 맡지는 않았는지 확인해야 합니다.

독립된 리팩토링 티켓은 어떤 서비스 제작 현장에서도 쉽게 주어지지 않습니다. 개발자 스스로 업무 루틴 안에 15분의 '설거지 시간'을 포함시켜야만 코드의 품질을 유지할 수 있습니다.

리팩토링은 시간에 쫓기는 개발자가 가장 먼저 챙겨야 하는 생존 기술입니다. 오늘 작성한 코드에서 딱 5분만 투자해 함수 하나라도 깔끔하게 쪼개보세요. 깨끗한 코드가 가져다주는 개발 속도의 체감은 생각보다 빠르게 찾아옵니다.