시니어 개발자가 다시 펼쳐든 이유
우연히 인터넷을 보다가 어느 개발자의 질문이 눈에 들어왔습니다.
"마틴 파울러 리팩토링 책, 아직 읽을 만한 가치가 있을까요?"
댓글은 예상 가능한 방향으로 갈렸습니다. "고전이니까 읽어야죠"와 "요즘 AI가 다 해주는데 굳이?"가 나란히 달려 있었죠. 그 질문을 보고 한동안 생각이 이어졌습니다. 저라면 뭐라고 답했을까.
이 책을 처음 읽었을 때와 지금 다시 펼쳤을 때의 느낌이 다릅니다. 그 차이가 무엇인지, 2026년 기준으로 이 책이 여전히 유효한 이유가 무엇인지를 제 경험에 비추어 정리해봤습니다.
이 책은 특정 언어의 문법을 가르치지 않습니다. 그보다 훨씬 근본적인 것, 즉 "어디가 잘못되어 가고 있는지"를 먼저 알아채는 직관을 훈련시킵니다.
마틴 파울러는 이를 코드 스멜(Code Smells)이라고 부릅니다. 중복 코드, 지나치게 긴 함수, 비대해진 클래스처럼 당장 버그는 아니지만 서서히 시스템을 망가뜨리는 징후들이죠.
AI 시대에 이 안목이 더 중요해진 이유
AI가 생성한 코드는 대부분 "작동"합니다. 문제는 그 코드가 6개월 뒤에도 유지보수하기 좋은 구조인가를 판단하는 건 여전히 사람의 몫이라는 겁니다. 코드 스멜을 읽어내는 능력 없이는, AI는 그냥 빠르게 기술 부채를 쌓아주는 도구가 됩니다.
...물론 정적 분석 도구나 린터를 AI 에이전트 워크플로우에 녹여서 코드 스멜 탐지를 자동화하는 파이프라인도 구성할 수 있습니다. 완전하진 않지만 생각보다 쓸만합니다. 다만 이건 글 하나를 따로 써야 할 분량이니 오늘은 여기서 접겠습니다.
저도 팀원이 AI로 작성해 온 코드를 리뷰할 때 이 관점을 자주 씁니다.
동작은 하지만 300줄짜리 함수 하나가 너무 자연스럽게 완성되어 있는 경우가 종종 있거든요.
이 책을 읽지 않았다면 "뭔가 이상한데"에서 멈췄을 상황을, "이건 Long Function 스멜이고 Extract Function이 필요해"라고 구체적으로 짚을 수 있게 됩니다.
많은 개발자가 리팩토링을 "코드를 깔끔하게 정리하는 작업" 정도로 생각합니다. 저도 한때 그랬고요.
그런데 마틴 파울러의 정의는 훨씬 엄격합니다.
"리팩토링이란 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는, 규율 있는 기법이다."
— 마틴 파울러, 『리팩토링』
첫째, 테스트가 먼저입니다. 유닛 테스트 없이 리팩토링을 시작하는 것은 안전망 없이 곡예를 하는 것과 같습니다. 테스트가 없는 레거시 코드를 다루고 있다면, 리팩토링 이전에 테스트를 먼저 작성하라고 이 책은 거듭 강조합니다.
둘째, 아주 작은 단계로 나눕니다. 한 번에 전체를 뒤집으려는 충동을 억제하고, 단계마다 테스트를 통과시키면서 점진적으로 나아가는 태도. 이걸 몸에 익히는 것이 이 책의 진짜 목적입니다. 개발자가 AI를 '제대로' 쓰는 법에서 이 원칙이 얼마나 중요한지는 굳이 설명이 필요 없을 정도입니다.
코드 리뷰에서 "이 부분이 좀... 지저분한 것 같아요"라고 말하는 것과, "여기서 Extract Function을 적용하고, 파라미터는 Introduce Parameter Object로 묶는 게 나을 것 같아요"라고 말하는 것은 전혀 다릅니다. 전자는 감상이고, 후자는 제안입니다.
팀 전체가 이 기법 이름을 공유하면 논쟁이 줄고, "잘 만든 코드"의 기준이 수렴되기 시작합니다.
그런데 요즘은 이 공통 언어가 AI와의 협업에서도 똑같이 통한다는 걸 느낍니다.
AI도 컨텍스트가 길어지면 코드가 비대해집니다.
모델 성능이 올라갈수록 기본적으로 깔끔한 코드를 쓰는 건 사실입니다.
하지만 기능이 누적되고 컨텍스트가 길어질수록 AI 생성 코드도 서서히 구조가 흐트러집니다.
처음 100줄짜리 모듈이 500줄짜리 덩어리가 되는 건 사람이 짜든 AI가 짜든 비슷합니다.
이때 리팩토링 언어를 알면 두 가지로 활용할 수 있습니다.
하나는 사후 교정입니다. "이 부분 좀 정리해줘" 대신 "Extract Function으로 나누고, 파라미터는 Introduce Parameter Object로 묶어줘"라고 지시하면 결과물 품질이 확실히 다릅니다.
하지만 더 효과적인 방법은 사전 가드입니다. AI 코딩 도구의 Ruleset에 "함수 20줄 초과 시 Extract Function 적용", "관련 파라미터 3개 이상이면 Parameter Object로 묶을 것" 같은 규칙을 박아두는 겁니다. AI가 처음부터 그 기준을 지키며 코드를 생성하기 때문에, 사후에 엉킨 코드를 풀 일 자체가 줄어듭니다.
리팩토링 언어를 안다는 건 결국 이 룰셋을 제대로 작성할 수 있다는 의미이기도 합니다. 팀원과의 소통 비용을 줄이는 동시에, AI를 더 정밀하게 부리는 능력. 그리고 그 규칙이 Ruleset에 녹아 있으면, 개발자가 자리를 비운 순간에도 코드 품질의 기준은 흔들리지 않습니다.
그리고 한 가지 더. 책 내용을 아직 모르더라도 당장 AI에게 활용할 수 있는 방법이 있습니다.
역할을 부여하는 겁니다.
"당신은 『리팩토링』의 저자 마틴 파울러입니다. 당신의 관점에서 이 코드의 리팩토링을 진행해 주세요."
이렇게 한 줄만 붙여도 AI의 응답이 달라집니다. 단순히 "코드 정리해줘"라고 했을 때와 비교하면, 코드 스멜을 명시적으로 지적하고, 각 리팩토링 기법의 이름을 붙여가며 단계적으로 개선하는 식의 응답이 나옵니다. 책을 다 읽은 뒤에 쓰면 더 좋겠지만, 읽기 전이라도 이 방법으로 먼저 감을 잡아보는 것도 괜찮은 시작입니다.
1판이 Java 중심이었다면, 2판은 JavaScript를 채택했습니다.
덕분에 함수형 스타일의 리팩토링도 다루고 React/Node.js 개발자도 바로 적용할 수 있다는 장점이 있지만, Java·Python·Kotlin 백엔드 개발자라면 예제를 자기 언어로 번역하며 읽어야 하는 수고가 따릅니다.
하지만 그 아쉬움 자체가 핵심을 찌릅니다.
Extract Function은 Java에서도, Python에서도 동일하게 적용됩니다.
이 책이 다루는 개념은 언어 문법 위가 아니라 사고 방식의 층위에 자리하고 있습니다.
AI가 문법과 보일러플레이트를 대신 써주는 시대에, 개발자에게 남는 차별점은 결국 "이 코드가 왜 문제인지"를 언어에 관계없이 판단하고 설명할 수 있는 능력입니다.
"코드가 돌아가긴 하는데, 건드리기 무섭다"는 느낌이 익숙한 분
코드 리뷰에서 "마음에 안 드는데 이유를 설명하기 힘든" 상황을 자주 겪는 분
AI 코드 생성 도구를 쓰되, 최종 품질 판단만큼은 직접 하고 싶은 분
팀 내 코드 품질 기준을 체계적으로 세우고 싶은 테크 리드, 시니어 개발자
반면, 처음 개발을 배우는 단계라면 당장의 우선순위가 되지 않아도 됩니다.
리팩토링은 "잘 동작하는 코드를 더 좋게 만드는 기술"이라, 동작하는 코드를 먼저 만들 수 있어야 온전히 체감되거든요. 다만 그렇다고 나중으로 완전히 미뤄두라는 뜻은 아닙니다. 개념서를 읽는다는 마음으로, 이해가 안 되는 부분이 있더라도 한 번 곁에 두고 읽어보길 권합니다. 당장은 와닿지 않아도 괜찮습니다. 나중에 실무에서 로직을 들여다보다 보면 "아, 그게 이 얘기였구나" 하고 자연스럽게 떠오르는 순간이 옵니다. 그때 다시 해당 챕터를 펼쳐보거나, AI에게 그 개념을 물어보면 됩니다. 처음 읽을 때 심어둔 씨앗이 있어야, 그 질문 자체를 할 수 있게 되니까요.
이 책은 한 번 읽고 꽂아두는 종류가 아닙니다.
요리할 때 레시피 책을 꺼내듯, 코드에서 냄새가 날 때마다 해당 기법을 찾아보는 방식으로 곁에 두어야 제 가치를 합니다.
AI가 코드를 대신 써주는 2026년에도, 그 코드의 품질을 판단하고 책임지는 것은 결국 사람입니다.
그 판단력을 체계화하고 싶다면, 이 책은 여전히 읽을 이유가 충분합니다.
개발 초창기, 여러 프로젝트를 거치면서 처음으로 리팩토링 충동을 강하게 느꼈습니다.
"이건 분명히 더 나은 구조가 있는데." 리더에게 조심스럽게 물었죠.
"지금 잘 돌아가고 있는데 왜 건드려요?"
틀린 말은 아닙니다.
운영 중인 시스템에서 "더 나은 구조"를 위해 멀쩡한 코드를 건드리는 건 리스크일 뿐이니까요.
그래서 기회를 기다렸습니다.
사업 기획이 추가되어 관련 로직을 어차피 건드려야 하는 상황 — 그때가 리팩토링을 자연스럽게 끼워 넣을 타이밍입니다. 그리고 그 타이밍에 반드시 테스트 케이스를 함께 작성하세요. 리팩토링과 테스트는 세트입니다.
그래도 주니어 때는 욕을 먹습니다. 저도 먹었습니다.
나름 완벽하게 리팩토링했다고 생각했는데 문제가 터지는 경우가 종종 있었습니다.
돌이켜보면 당연한 수업료였죠.
책으로 익힌 개념이 운영 코드에서 어떻게 다르게 작동하는지는, 한 번 터뜨려봐야 진짜로 이해됩니다.
다만 요즘은 이 욕먹을 확률이 확실히 줄었습니다.
내가 리팩토링 개념을 알고 있고, 그걸 AI를 통해 실현한다면 이야기가 달라집니다.
AI는 기계적인 실수 — 변수명 누락, 참조 빠뜨림, 사이드 이펙트 간과 같은 — 를 사람보다 훨씬 꼼꼼하게 잡아줍니다.
결국 "무엇을 해야 하는지"를 아는 사람이 AI라는 도구를 쓰면, 실행의 정밀도가 올라가면서 터뜨릴 일 자체가 줄어드는 셈입니다.
하지만 그 과정이 반복되면 리팩토링은 더 이상 두려운 작업이 아니게 됩니다. 코드를 고치고 나서도 두 발 뻗고 잘 수 있게 되는 거죠. 이 책은 그 감각을 얻기까지의 시간을 조금 더 체계적으로 단축시켜 줍니다.
포기하지 마세요.
첫 번째 욕은 수업료입니다.