세상에 나온 지 27년 된 책 '리팩터링'을 다시 펼치는 이유

1999년 1월 1일, 책 <리팩터링(Refactoring)>이 세상에 나왔다. 그리고 세월이 흘러 2018년 11월 30일, 책의 저자인 마틴 파울러(Martin Fowler)는 고침판(2판)을 다시 세상에 내놨다. 현재 내가 글 쓰는 시점이 2026년이니 <리팩터링> 1판이 나온 지 햇수로 대략 27년이 된 것이다.

<리팩터링>은 동작하는 코드를 고치는 법을 다루고 있다. 변화 속도가 둘째가라면 서러울 소프트웨어 분야에서 원칙이나 추상적 문제를 다루는 고전은 여럿 있다. 하지만 구체적인 코드를 다루는 책이 이토록 오래 살아남아 고침판까지 나오는 일은 쉽게 보기 어렵다.

최근 몇 년간 AI 코딩 에이전트는 소프트웨어를 만드는 사람들이 일하는 방식에 큰 변화를 주었다. 바이브 코딩(Vibe Coding)이라는 말이 일상적으로 쓰일 만큼 AI 기반 개발이 보편화됐다. 이제 더는 코드를 볼 필요가 없고, 손으로 코딩하는 시대는 끝났다고 말하는 사람도 심심치 않게 보인다.

나는 몇 주 전 함께 일하는 동료들에게 <리팩터링>을 함께 보자고 제안했다. 책을 함께 보는 동료 중 한 명은 AI 코딩 에이전트가 보편화되기 시작한 무렵에 개발을 시작했다. 자신이 만든 코드의 90% 정도를 AI로 작성한다고 내게 말했을 정도로 AI 기반 개발에 익숙하다. AI 코딩 에이전트 기반 개발이 보편화된 마당에, 손 코딩의 종말을 말하는 마당에, 코드에 관한 책이라니… 심지어 동작하는 기존 코드를 고치는 책이라니!

코드를 직접 생산하지 않는 변화된 개발 환경 속에서 동작하는 코드를 다시 고치는 법을 학습해야 하는 이유는 무엇일까? 그 속에는 어떤 가치가 있을까?

이 글에서는 <리팩터링>이 말하는 좋은 코드의 조건에서 출발해, AI 코딩 에이전트와 일하는 지금도 동작하는 코드를 고치며 배우는 일이 왜 중요한지 살펴본다.

좋은 코드의 조건, 높은 응집성과 느슨한 결합도

누구나 좋은 코드를 만들고 싶어 하고, 요즘은 AI 코딩 에이전트가 좋은 코드를 만들어 주기를 기대한다. 여기서 본질적인 질문을 해보자.

좋은 코드란 무엇인가?

‘좋다’라는 말이 추상적이고 각자가 느끼는 것도 제각각이라 정의하기 어렵다. ‘좋은 코드’를 정의하는 일도 마찬가지다. 그래도 오랜 세월 소프트웨어를 만들어 온 장인들이 경험적으로 말하는 것이 있다. 바로 ‘변경이 쉬운 코드’다.

코드를 ‘수정하기 쉬운 정도’야말로 좋은 코드를 가늠하는 확실한 방법이라고 믿는다. — <리팩터링>

코드 베이스가 작을 때에는 ‘변경’이 큰 문제가 되지 않는다. 코드 전체를 충분히 인지할 수 있는 수준이기 때문에 변경 영향도를 쉽게 추정할 수 있으며, 고쳐야 할 곳을 어렵지 않게 찾을 수 있다.

문제는 코드 베이스가 사람이 인지할 수 없는 수준으로 넘어가면서 발생한다. 나는 코드 에디터로 수만 줄의 코드를 보다가 여기가 어디쯤인지 헤맨 적이 꽤 있다. 인간은 일반적으로 뇌의 인지 한계를 넘어설 때 복잡하다고 느끼는데, 슬금슬금 늘어나는 코드 베이스에서 ‘복잡성’ 문제는 그렇게 서서히 고개를 들기 시작한다.

프로그래밍의 역사는 복잡성을 다뤄 온 역사라 해도 과언이 아니다. 따라서 복잡성을 잘 다루지 않고서는 ‘변경이 쉬운 코드’에 도달하기란 요원하다.

인류가 문자를 발명한 이후, 오랜 세월 인간은 복잡성이라는 문제를 나눠서 정복(Divide and conquer)해 왔다. 비슷한 것들은 인지할 수 있는 단위로 덩이지어(Chunking) 의미를 부여한 후 경계를 만들고 경계 간 상호작용을 최소로 줄여 인간이 가진 뇌의 용량 한계를 극복해 온 것이다.

그렇기에 우리는 프로그래밍할 때 코드를 파일 하나에 모두 넣지 않는다. 코드를 ‘함수’라는 단위로 덩이 짓고 이름으로 의미를 부여하고, ‘클래스’라는 단위로 덩이 짓고 이름으로 의미를 부여하며, ‘패키지’라는 단위로 덩이 짓고 이름으로 의미를 부여한다.

프로그램을 모듈화할 때는 코드를 여러 영역으로 나눈 뒤 영역 안에서 이뤄지는 상호작용은 최대한 늘리고 영역 사이에서 이뤄지는 상호작용은 최소로 줄이는 데 주력한다. — <리팩터링>

비슷한 코드끼리 덩이 짓고 덩이 안에서 상호작용을 최대한 늘리는 것은 응집성을 높이는 것이며, 덩이 사이의 경계를 만들고 경계 간 상호작용을 최소로 만드는 것은 덩이 사이의 의존성을 낮춰 결합도를 느슨하게 만드는 것이다. 정리하면 좋은 코드는 ‘변경이 쉬운 코드’다. 그리고 변경이 쉬운 코드가 도달하려는 궁극적인 목표는 높은 응집성과 느슨한 결합도를 달성하는 데 있다.

경험적 설계: 고치며 배우고 깨닫기

어떻게 해야 높은 응집성과 느슨한 결합도를 갖춘 코드를 만들 수 있을까? 그냥 코딩 에이전트에 “높은 응집성과 느슨한 결합도로 만들어줘”라고 지시하면 되는 것일까? 그렇게 AI가 생성한 코드가 높은 응집성이 있는지 느슨하게 결합되어 있는지 어떻게 검증할 수 있을까? 그렇게 만든 코드가 변경이 쉬운 코드가 되는 걸까? 다른 사람에게 설명할 수 있을까?

코딩 에이전트에 일을 맡기기 전에, 코드 수준에서 무엇이 높은 응집성이고 무엇이 느슨한 결합도인지 구분할 지식을 갖춰야 한다. 그렇지 않으면 초보자(개발자)가 전문가(AI)를 이끄는 역전된 학습(Inverted Learning)이 일어나고 인지적 부채만 쌓일 뿐이다.

개발자가 역량을 키우기 어렵다는 SI(System Integration) 프로젝트 환경에서 뛰어난 전문성을 지닌 개발자의 인터뷰를 읽은 적이 있다. 그에게는 남들이 하지 않는 습관이 있었다. 프로젝트가 끝나면 자신이 작성한 코드를 다시 작성하는 것이다. 경험을 토대로 이전에 작성한 코드를 고치면서 배우는 것이었다. AI가 등장하기 훨씬 전부터 뛰어난 개발자들은 동작하는 코드를 계속 고쳐 나가며 지식을 쌓아왔다.

실력 있는 프로그래머는 항상 자신의 코드를 정리하는 데 어느 정도의 시간을 할애해왔다. 복잡하고 지저분한 코드보다는 깔끔한 코드가 수정하기 쉽고, 처음부터 깔끔하게 작성하는 경우는 거의 없다는 것을 경험을 통해 알기 때문이다. — <리팩터링>

나는 높은 응집성과 느슨한 결합도를 만들 수 있는 역량은 추상적인 설명이 아니라 구체적인 코드를 고치면서 얻는 깨달음에서 시작한다고 믿는다. 그래서인지 <리팩터링>과 켄트 벡(Kent Beck)의 <Tidy First?>를 펼치면 코드를 구체적으로 고치는 예시가 가득하다. 책으로 학습하고, 일상에서 마주하는 코드에 적용해 보고, 코드를 점진적으로 개선하면서 무엇이 응집성이고 무엇이 결합도인지 서서히 깨닫는다. 그렇게 기술이 매개된 간접 경험이 아니라 직접 경험으로 지식을 차곡차곡 쌓아 가는 것이다.

저는 매시간 “코드 정리가 먼저인가?”라는 질문에 대해 논의하면서, 그 해답을 찾았습니다. 그 논의를 통해 설계자로서 제 마음에 소중한 많은 주제를 다룰 수 있었습니다. — <Tidy First?>

소프트웨어 분야에서 아주 오래된 격언 중 하나는 “잘 동작하는 것을 고치지 말라”는 것이다. 동작하는 코드를 고치며 배우는 과정은 쉽지 않다. 하지만 문제를 해결하며 겪는 마찰과 어려움이 결국 내 지식이 된다.

AI 코딩 에이전트와 함께 나아가기

나는 ‘당신의 사고까지 AI에게 외주화하지 마라’ 글에서 ‘사고의 주도권’을 강조했다. 마찬가지로 바이브 코딩을 하지 않는다면 AI가 생성한 코드의 주도권은 내가 가져야 한다. 주도권을 가진다는 것은 내가 예상하는 곳에 코드가 존재한다는 것이며 그것은 곧 내 인지 범위 안에 있다는 것이다. 반면 AI가 생성한 코드가 어떤 의미인지 모르거나 검증할 수 없으면 주도권을 잃은 것이다. 코드가 인지 범위를 벗어났고, 인지적 부채를 겪고 있다는 뜻이다.

하네스 엔지니어링은 AI에 지켜야 할 규칙이나 지침을 주어 코드 통제력을 구현한다. 문제는 지침이 남의 것, 즉 내가 이해하지 못한 것이라면 그런 지침으로 생성된 코드에 내가 주도권을 가질 수 없다는 점이다. 남들이 만든 지침을 AI에 줄 수는 있다. 하지만 그렇게 만들어진 코드를 스스로 판단할 수 없으니 결국 다시 인지적 부채의 늪에 빠진다.

앞서 나는 동작하는 코드를 고치면서 얻는 깨달음에 대해 언급했다. 깨달음에서 멈추는 것이 아니라 직접 경험을 통해 익힌 직관이나 습관을 지침으로 만들어 AI에 줄 수 있다. 이 과정은 처음부터 깔끔하게 잘될 수 없기에 점진적이며 경험적으로 접근할 수밖에 없다. 지침을 어떻게 만드는 것이 효과적일까? 일찍이 이 분야 선배들은 다음 세 단어를 많이 써왔다.

• 원칙(Principles)
• 실천 방법(Practices)
• 패턴(Patterns)

나만의 원칙, 실천 방법 그리고 패턴(이하 PPP)을 지침으로 만든다는 것은 PPP를 새롭게 창조하라는 것이 아니다. 세상에는 이미 좋은 PPP가 존재한다. PPP를 익히면서 이해한 것들을 내 것으로 만들어 모으는 것에서부터 시작해 보자.

마치며

책 <다시, 소프트웨어>의 저자가 말하듯 AI 코딩 에이전트 덕분에 코드를 생산하는 비용은 매우 싸졌다. 하지만 엔지니어링까지 싸진 것은 아니라는 점을 꼭 기억하길 바란다. 좋은 코드를 만드는 길은 먼저 깨달은 누군가가 말해 줄 수 있다. 하지만 아무도 당신을 어깨에 앉히고 그 길을 걸어가 주지 않는다. 스스로 그 길을 걸어갈 수밖에 없다.

<리팩터링> 1판은 1999년 출간되었지만 한국에는 2002년에 소개되었다. 내가 1판을 산 것은 2010년쯤으로 기억한다. 당시에는 이 책이 말하는 것을 대부분 이해하지 못했고 실천하지도 못했다. 켄트 벡은 자신의 책 <Tidy First?>에서 에드워드 요던과 래리 콘스탄틴이 1975년에 쓴 책 <Structured Design>을 언급하며 “뉴턴의 운동 법칙을 소프트웨어 설계에 적용하고 있다”라고 극찬했다. <리팩터링>을 다시 펼친 지금 나는 켄트 벡과 같은 감정을 느낀다.

<원문>

세상에 나온 지 27년이나 된 책을 다시 펼치는 이유

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.