클린 코드 2판 증정본이 담긴 택배 상자가 어제 집에 도착했다. 원래 2판 출간 소식을 먼저 전해드리려하다가 그래도 실물을 영접하고 글을 쓰면 좋겠다고 생각해서 예약 판매 사이트가 열렸는데도 꾹꾹 참았다. 책장에 꽃으려다 보니까 기존 역서들이 보여서 생각난 김에 간략하게 클린 코드 책 역사를 되집어보지 않을 수 없다. 2008년에 원서가 출간되었고, 2010년에 클린코드 번역서가 처음으로 출간되었다. 그런데 당시에 여러 가지 사정으로 첫 번역서가 절판이 되어버렸고, 다행히도 2013년에 인사이트에서 복간되어 여러분들을 다시 찾아뵙기 시작했다. 그리고 기술서로서는 보기 드물게(정말 보기 드물게...) 역주행을 거듭해서 애독자 여러분들의 많은 사랑을 받았다. 하지만 이렇게 빨리 발전하는 IT 기술의 변화 앞에 책의 구성이나 내용이 점점 현실과 괴리되기 시작했고 책 판매량도 당연히 줄기 시작했다. 하지만, 2026년 9월에 더 강한 모습으로 2판으로 여러분들을 찾아뵙게 되었다.
2판은 1판에 비해 어떤 점이 달라졌는가? 솔직히 (지금 이 글을 적고 있는 역자를 포함해...) 많은 사람들은 2판 구입을 주저한다. 1판 내용은 그대로 둔 상태로 일부 내용을 추가하거나 변경하는 선에서 그치기 때문에 신규 독자라면 모를까 기존 독자라면 책장만 차지하는 애물단지가 되기 쉽기 때문이다. 물론 역자로서 1판과 2판 차이가 많지 않으면 번역 작업이 손쉬워지므로 좋긴 하지만, 역자도 독자인 관계상 특히 클린 코드와 같은 양서인 경우에 1판과 2판 diff 결과가 그다지 크지 않다면 마냥 좋지만은 않다. 결론부터 말씀드리자면... 완전 재번역이라고 보면 된다. 과거 끝없이 이어지던 자바(원래 자바가 21세기 코봁같은 느낌인지라 간단한 프로그램도 되게 길어진다. 여기서 자바를 비난할 생각은 전혀 없다. 자바에는 나쁜 점도 있고 좋은 점도 있다.) 코드는 대부분 삭제되었고, 꼭 필요한 부분을 설명하기 위해 자바를 비롯해, 고, 파이썬, 자바스크립트 언어와 클로저 등 다양한 언어로 만들어진 예제가 등장한다. 그리고 그록을 이용한 바이브(엌!) 코딩 사례도 등장한다. 또한 클린 코드 이후에 밥이 집필한 <우리 프로그래머들>, <클린 아키텍처>, <소프트웨어 장인 정신 이야기>, <함수형 설계, 객체 지향과 만나다> 책에서 핵심을 간추려서 적재적소에 배치함으로써 안 그래도 바쁜 세상에서 이 많은 책들을 하나하나 읽지 않고서도 장인정신이 충만한 개발자로 성장하기에 필요한 영양분을 책에 꽉꽉 채워놓았다.
생성형 AI가 IT 업계 전반을 흔들어놓고 있기에 혹자는 사람에게 유효한 클린 코드가 필요한 이유에 대해 의문을 품기도 한다. 어차피 쓰지도 읽지도 않은 코드에 신경 써야 하는 이유는 무엇이며, LLM이 알아서 프로그래밍 언어도 선택하고 문서화도 하고 서브 에이전트끼리 통신도 하는 상황에서 어떻게 보면 클린 코드와 클린 아키텍처가 무슨 의미인지 의문이 드는 것도 너무나도 당연하다. 이는 사람이 코드를 바라보는 관점과 생성형 AI가 코드를 바라보는 관점이 완전히 다를 것이라는 생각에서 출발하면 맞다. 하지만, 생성형 AI가 어떤 자료를 학습해서 기존 사람들이 수십년 동안 쌓아온 소프트웨어 개발 방법을 레버리지로 쓰겠는가? 바로 사람이 만든 자료를 학습했다는 사실에 주목할 필요가 있다. 프로그래밍 설계 명세를 프롬프트로 만들어서 코딩 에이전트에게 지시를 내릴 때도 우리는 알게 모르게 사람이 쌓아온 기존의 사상과 어휘를 사용하기 마련이고, LLM도 여기에 응답해서 프로그램을 만들 것이다. 전혀 클린하지 않은 엉망 진창인 코드를 LLM에 줘도 다 이해하고 고칠 수 있다는 주장도 할 수 있다. LLM이 주변 컨텍스트에 맞춰서 결과를 내는 특성이 있다는 사실을 간과하기 전까지는 사실로 보인다. 문제는 LLM은 엉망 진창인 코드를 매우 빠르고 강력하게 더 엉망 진창으로 만들 수 있는 파괴적인 위력이 있다는 사실이다. 사람이 명시적으로 지시하지 않는 이상 LLM은 굳이 불필요한 토큰을 낭비해가면서 엉망 진창인 코드를 훌륭하게 바꿔주지 않는다. 그리고 통제 불능이 될 때까지 질주할 것이다. 그 이후에 결과는 모두 다 안다. 유뷰트와 블로그에는 될 때까지 만들어서 어떻게든 꾸역꾸역 동작하도록 만든 바이브 코딩의 성공 사례만 올라오니까 생존자 편향이 작용할뿐이지...
번역하면서 생성형AI 시대에 대비해서 생산성을 높이는 방안을 고민하지 않을 수는 없었다. 가장 좋은 방법은 (LLM과 함께) 요구 사항을 분석하고 설계하고 LLM과 의사소통하면서 프로그램을 만들고, LLM이 만든 결과물을 단위 코드나 E2E 관점에서 전반적으로 검토하고 피드백을 주는 과정에서 <클린 코드>에 담긴 여러 아이디어를 실험하고 실험 결과를 보고 개선하면서 자신만의 독특한 개발 방법론을 만들어내는 것이다. 과거에는 수 많은 사람들이 협력하면서 소프트웨어를 개발하는 방법에 집중했다면, 이제는 여러 사람은 물론이고 다양한 코딩 에이전트와 LLM과 더불어 협력하면서 소프트웨어를 개발하는 방법에 집중해야 하는 시기가 오고만 것이다.
최근에 클로드 코드가 작성하는 주석이 너무 마음에 들지 않아서, 필요한 skill을 찾다가 Reducing Code-Comment Verbosity with Claude Code를 발견했다. 가장 첫줄이 "Default to no comment. Code shows *how*; comment only to carry *why* — a non-obvious constraint, deliberate deviation, gotcha, or workaround."인데 어디서 많이 보던 내용이 아닌가?(힌트: <클린 코드> 2판 5장을 읽어보자) 이렇듯 LLM이 다 알아서 하는 세상임에도 불구하고 클린 코드와 클린 아키텍처의 핵심 내용을 준용한 다양한 skill들이 나와 있는 상황을 고려해볼 때 LLM 시대에 클린 코드의 중요성은 결코 간과해서는 안 될 것이다. LLM은 자신을 비추는 거울과 같아서 내가 아는 만큼 내게 정보를 준다는 사실을 잊어서는 안 된다. LLM을 정말 제대로 활용하려면, 내가 폭넓고 깊게 많이 알아야 한다. 프롬프트 엔지니어링과 관련된 몇 가지 테크닉만으로 손쉽게 해결될 문제는 아니라고 생각한다. 따라서 황금 같은 시간을 투자해 <클린 코드> 2판을 열심히 읽고 어떻게 사람은 물론이고 LLM과 함께 멋진 소프트웨어를 개발할지 고민해보자. 잠시 전열을 가다듬기 위해 충분히 가치 있는 시간이 되리라고 생각한다. 애독자 여러분들의 많은 성원 부탁드린다.
보너스: 책장에 꽃아두고 한 컷 찍어봤다. 주인공 좌우에 다른 애지중지하는 작품들과 친구들도 찬조출연했는데, 번역하고 세미나하고 독자들의 피드백도 많이 받고... 옛날 생각이 많이 났다.
