리팩토링은 취미가 아니라 투자입니다 — 마틴 파울러가 말하는 리팩토링의 경제학

리팩토링 하자고 하면 왜 항상 "일정 없다"는 말이 돌아올까요

"이번 스프린트에 리팩토링 좀 하면 안 될까요?"라고 물었다가 "그거 하면 매출이 올라요?"라는 대답을 들어본 적, 다들 한 번쯤 있으시죠. 마틴 파울러(Martin Fowler)의 사이트에 올라온 이번 글은 바로 그 질문에 정면으로 답하려는 시도인데요. 제목 그대로 '리팩토링의 경제적 이점'을 다뤄요. 리팩토링을 개발자의 결벽증이나 취미가 아니라, 돈으로 환산되는 투자로 설명하자는 거죠.

먼저 리팩토링이 뭔지 짚고 갈게요. 이게 뭐냐면, 소프트웨어가 겉으로 하는 동작은 그대로 두고 내부 구조만 개선하는 작업이에요. 사용자 눈에는 아무것도 안 바뀌는데, 코드를 만지는 개발자 입장에서는 훨씬 다루기 쉬워지는 거죠. 방 정리랑 비슷해요. 정리한다고 물건이 늘어나는 건 아니지만, 다음에 뭘 찾을 때 걸리는 시간이 확 줄어들잖아요.

핵심 논리: 내부 품질은 "변경 비용"을 낮추는 장치예요

파울러가 오랫동안 펼쳐온 논리의 뼈대는 이래요. 코드의 내부 품질, 그러니까 코드가 얼마나 깔끔하고 이해하기 쉬운가는 그 자체로는 고객에게 아무 가치가 없어요. 고객은 코드를 안 보니까요. 그런데 내부 품질이 좋으면 다음 기능을 추가하는 비용이 크게 줄어들어요. 반대로 품질이 나쁜 코드베이스는 처음엔 빨리 달리는 것처럼 보이지만, 시간이 지날수록 기능 하나 넣는 데 몇 주씩 걸리기 시작하죠. 어디를 고치면 어디가 터질지 모르니 다들 코드 건드리기를 무서워하게 되고요.

파울러는 이걸 '설계 지구력 가설(Design Stamina Hypothesis)'이라고 불러왔는데요. 내부 품질에 투자한 팀이 어느 시점부터는 대충 달린 팀보다 오히려 더 빨라진다는 거예요. 그리고 그 교차점이 몇 년 뒤가 아니라 보통 몇 주 안에 온다는 게 포인트예요. "품질이냐 속도냐"는 트레이드오프처럼 들리지만, 조금만 긴 호흡으로 보면 사실 품질이 곧 속도라는 얘기죠.

기술 부채라는 비유도 같은 맥락이에요. 지저분한 코드를 방치하는 건 빚을 지는 것과 같아서, 원금을 안 갚으면 이자(느려지는 개발 속도, 늘어나는 버그)를 계속 내야 해요. 리팩토링은 그 원금을 갚는 행위고요. 이렇게 경제 언어로 번역해서 이야기하면, "코드가 더러워요"라는 말로는 꿈쩍도 안 하던 의사결정권자도 고개를 끄덕이게 된다는 게 이 글의 실용적인 교훈이에요.

AI 시대라서 오히려 더 중요해졌어요

흥미로운 건 이 글이 파울러 사이트의 '생성형 AI 탐구(Exploring Gen AI)' 시리즈로 나왔다는 점이에요. AI가 코드를 쏟아내는 시대에 굳이 리팩토링 얘기를 다시 꺼낸 이유가 있거든요. AI 코딩 도구를 쓰면 코드를 만들어내는 속도는 확실히 빨라져요. 문제는 코드가 쌓이는 속도만큼, 그 코드를 이해하고 관리해야 하는 부담도 같이 쌓인다는 거예요. 사람이 제대로 읽어보지 않은 코드가 늘어날수록 코드베이스는 점점 "아무도 전체를 모르는 상태"로 가기 쉽고요.

게다가 AI 도구 자체도 잘 정리된 코드베이스에서 훨씬 좋은 결과를 내요. 구조가 명확하고 이름이 잘 지어진 코드는 AI에게도 좋은 컨텍스트가 되거든요. 그러니 "AI 덕분에 코드 생산이 싸졌으니 품질은 대충 가자"가 아니라, 오히려 "코드가 폭발적으로 늘어나는 시대일수록 구조를 다듬는 작업의 경제적 가치가 커진다"는 역설이 성립해요. 동시에 리팩토링 작업 자체를 AI가 거들 수 있게 되면서, 예전엔 엄두가 안 나던 대규모 정리 작업의 비용도 내려가고 있어요. 투자 대비 수익 계산이 리팩토링 쪽에 더 유리해진 셈이죠.

한국 개발자에게: 설득의 언어를 바꿔보세요

한국 조직에서 리팩토링 설득이 유독 어려운 건 일정 중심 문화 때문인 경우가 많은데요. 몇 가지 실전 팁을 정리하면 이래요.

• 별도 일정을 잡으려 하지 마세요. "리팩토링 스프린트"는 승인받기 어렵고, 승인받아도 우선순위에서 밀려요. 대신 기능 개발을 하면서 지나가는 코드를 조금씩 정리하는, 이른바 보이스카우트 규칙("캠핑장은 왔을 때보다 깨끗하게")을 팀의 기본 습관으로 만드는 게 현실적이에요.
• 경제 언어로 번역하세요. "이 모듈이 지저분해요"가 아니라 "이 모듈 때문에 관련 버그 수정에 매번 이틀씩 더 걸려요"라고 말하는 순간 대화가 달라져요.
• AI 도구를 리팩토링에 써보세요. 테스트가 받쳐주는 코드라면, 이름 바꾸기나 중복 제거 같은 작업은 AI와 함께할 때 비용이 훨씬 내려가요.

마무리

한 줄로 정리하면, 리팩토링은 취향의 문제가 아니라 "변경 비용을 낮추는 경제적 투자"고, AI가 코드를 쏟아내는 지금은 그 투자 수익률이 오히려 올라가고 있다는 거예요. 여러분 팀은 리팩토링 시간을 어떻게 확보하고 계신가요? 경영진이나 PM을 설득하는 데 성공했던(혹은 실패했던) 경험이 있다면 나눠주세요.