GN⁺: 클린 코드 vs. 소프트웨어 설계 철학
(github.com/johnousterhout)- Robert “Uncle Bob” Martin과 John Ousterhout이 2024년 9월부터 2025년 2월까지 진행한 소프트웨어 설계 관련 대화임
- 두 사람 모두 소프트웨어 디자인에 대한 저서를 집필했음
- 세 가지 주요 주제(메서드 길이, 주석, Test-Driven Development)에서 서로 견해 차이를 보였음
- 대화의 핵심은 코드의 복잡도를 줄이고 가독성을 높이는 방법, 그리고 적절한 테스트 작성 방식에 대한 것임
메서드 길이
- Uncle Bob(이하 UB)은 “짧은 함수가 좋음, 가능하다면 더 짧게 분리함”이라는 입장을 강조함
- 한 메서드는 하나의 “일(One Thing)”만 해야 함
- 단, 이는 너무 극단적으로 적용하면 과도한 분해(over-decomposition)로 이어질 수 있음
- John은 너무 작은 메서드는 오히려 전체 흐름을 이해하기 어렵게 만든다고 지적함
- “얕은(shallow) 메서드”가 많아지면, 하나의 기능을 이해하기 위해 관련 메서드를 모두 살펴봐야 하는 문제가 생김
- 메서드 간 상호 의존도(“entanglement”)가 높아져, 코드 읽기 부담이 커짐
-
PrimeGenerator예시- UB의 원 코드는 8개 정도의 작은 메서드로 나뉘었고, 메서드들이 서로 얽혀 있어 이해하기 어려웠음
- John의 버전은 하나의 메서드에 주석을 충분히 달아서 전체 흐름을 한눈에 파악할 수 있게 작성했음
- UB도 “과도한 분해가 있었다는 점”을 어느 정도 인정했음
- 결론적으로, 두 사람은 코드 분해가 중요함을 인정하지만, “너무 작게 쪼개는 것”과 “너무 크게 두는 것” 사이에서 균형을 잡는 것이 핵심임
주석
- UB는 주석에 대해 “필요 악(necessary evil)”이라는 관점을 가짐
- 주석은 업데이트가 잘 안 되거나, 잘못된 정보를 담을 위험이 있다고 봄
- 코드를 통해 최대한 의도를 드러내고, 필요하다면 매우 긴 이름을 사용하는 방식을 선호함
- John은 주석이 꼭 필요하다고 주장함
- 인터페이스(메서드)의 목적이나 구현 의도를 영어로 명확히 적어두면, 다른 개발자가 불필요한 코드를 뒤지는 시간을 줄여줌
- “가장 위험한 것은 주석이 없어서 코드를 직접 해석해야 하는 상황”이라고 봄
-
PrimeGenerator를 예로, John은 “알고리즘이 왜 그렇게 동작하는지”를 해설하는 주석이 없으면 이해하기 매우 어렵다고 지적함 - UB는 “주석이 정확하지 않으면 오히려 해가 된다”는 입장이지만, John은 “잘못된 주석보다는 없는 주석이 더 해롭다”는 쪽임
- 두 사람 모두 “팀과 상황에 따라 적절한 수준의 주석을 달아야 한다”는 데에 어느 정도 합의했지만, 전반적으로 John이 주석의 가치를 훨씬 높게 평가함
John의 PrimeGenerator 리팩토링
- John은 원래 8개 메서드로 분리된 코드를 단일 메서드, 혹은 2~3개 메서드 형태로 재구성함
- 필요한 부분에 풍부한 주석을 달아 “왜 이런 방식으로 구현하는지” 설명함
- 주석으로 주요 변수(
multiples,primes)의 의도와 알고리즘 동작 방식을 함께 서술해, 코드 이해를 빠르게 돕고자 함 - UB는 이 코드 역시 완전히 직관적이지 않았다고 밝힘
- 복잡한 알고리즘을 설명하기 위해선 여전히 시간이 필요하고, 작성자 스스로도 재검토 과정에서 어려움을 느꼈음
Bob의 PrimeGenerator2 리팩토링
- UB가 John의 코드를 약간 수정한 버전임
- 몇 가지 메서드를 추가로 분리해 “후속적인 리팩토링”을 적용함
- 반복문 부분에서 가독성을 높이는 대신, 성능 저하가 일시적으로 발생했음
- John은 “너무 작은 메서드로 분할하면 성능 문제가 생길 수 있다”는 점을 지적했고, UB는 다시 수정해 성능을 개선했음
- 다만 “주석은 최소화”하는 UB의 취향 때문에, John은 여전히 “설명을 더 달아야 이해가 쉬워진다”는 입장을 고수함
Test-Driven Development
- UB는 짧은 주기로 테스트를 먼저 작성하고, 실패하는 테스트를 통과시키기 위한 코드를 조금씩 추가해나가는 TDD 방식을 적극 권장함
- 이 방식을 통해 코드가 항상 테스트 커버리지를 유지하고, 복잡한 디버깅을 피할 수 있다고 주장함
- 코드는 자주 리팩토링하며 점진적으로 깨끗해진다는 입장임
- John은 TDD가 지나치게 “전술적인 접근”으로 흐른다고 우려함
- “설계가 먼저 선행되어야 하는데, TDD는 코드를 먼저(테스트를 위한 최소 구현) 쓰도록 유도한다”는 지적임
- 좋은 설계는 한 번에 좀 더 넓은 범위를 고민하고, 해당 코드에 대해 테스트를 묶어서 작성(bundling)하는 편이 낫다고 봄
- UB는 “TDD를 잘못 적용해서 생기는 문제”가 있을 수 있지만, 올바르게 실천하면 테스트 커버리지와 재설계(리팩토링)에 도움이 된다고 주장함
- John은 “TDD가 초보자에게는 오히려 코드가 빠르게 엉망이 될 위험이 크다”는 우려를 표함
- 최종적으로 두 사람은 “TDD도, Bundling 접근도 잘만 하면 둘 다 훌륭한 코드를 만들 수 있다”는 데 동의하지만, 어느 쪽이 더 나은지는 입장이 다름
맺음말
- John:
- “Clean Code”가 너무 작은 함수 분리와 주석 억제를 강조해, 독자들이 극단적으로 따라갈 위험이 있다고 우려함
- 주석을 충분히 달지 않으면 코드가 이해하기 어려워지고, 결과적으로 개발자가 더 많은 시간을 소비하게 됨
- TDD 역시 큰 그림의 설계를 놓칠 수 있다고 지적함
- UB:
- “Clean Code” 2판에서 어느 정도 보완했고, John의 의견을 일부 통합했다고 밝힘
- 서로 다른 경험과 관점을 존중하면서, 결과적으로 “모두가 깨끗하고 유지보수하기 좋은 코드를 지향해야 한다”는 공통점을 강조함
- 결론적으로, 두 사람은 소프트웨어 설계의 중요성과 “코드를 읽기 쉽게 만드는 것”을 최우선 가치로 둠
- 다만 메서드 분리 기준, 주석 활용 방식, 테스트 작성 순서 등에서 입장 차이가 존재함
- 핵심은 팀 환경과 코드 구조에 맞춰 균형을 잡고, 설계를 지속적으로 개선하려는 노력이 필요하다는 점임
요즘은 클린 코드보단 특정 기술 스택, 아키텍쳐의 팬이 이 기술 스택, 아키텍쳐를 도입하지 않으면 큰일 나는 것처럼 말씀하시는 것 때문에 더 많이 싸웠던 것 같네요. 상황봐서 적용해야 맞지, 무조건 좋은 건 없는듯합니다
Hacker News 의견
-
어떤 사람들은 특정한 것에 대해 매우 교조적일 수 있음. 이런 것들을 복음처럼 받아들이는 이유를 이해할 수 없음
- 80자 라인 제한을 넘길 때마다 화를 내는 사람들을 상대해야 했던 경험이 있음
- 프로그래밍 스타일, 패턴, 관용구뿐만 아니라 기술 스택과 솔루션 아키텍처에서도 이런 경향이 더 심함
- 책이나 블로그에서 읽은 내용을 그대로 인용하는 사람들과의 대화는 매우 답답함
- NoSQL과 마이크로서비스 열풍 때 특히 심했으며, PAAS/SAAS와 컨테이너화에서도 여전히 느껴짐
- 기본적인 기능을 수행하는 앱이나 람다, 변환 작업이 유지보수 부담만 늘리고 가치가 없음
- 책이나 블로그를 쓴 사람과 나의 차이는 그들이 글을 썼다는 것뿐임. 그들의 의견이 사실이 아님을 항상 염두에 두어야 함
-
Uncle Bob의 추천을 맹목적으로 따르는 프로젝트를 경험하면 그 가치가 얼마나 낮은지 알 수 있음
- 소프트웨어 엔지니어링을 개선하려는 시도에 대해 몇 가지 텍스트를 생성했지만, 끔찍한 조언으로 가득 차 있음
- 그의 성공은 가이드를 찾는 주니어 개발자들의 끝없는 필요에 의해 이루어짐
- 많은 간접성을 가진 코드가 작업하기 어려운 상태로 만들어짐
-
Clean Code는 좋은 소프트웨어 엔지니어의 도구 상자 중 하나임
-
몇몇 사람들은 함수가 재사용되거나 논리적으로 의미가 있을 때 분리하는 대신 단순히 가까이 있는 줄을 묶어 "리팩터링" 함
- 대학 시절 Clean Code를 읽었을 때, Uncle Bob의 일반적인 분위기를 느꼈음
- 함수가 X 줄이어야 한다는 사고방식에서 비롯된 것 같음
- 현대 IDE의 인라인 기능에 감사하며 코드를 이해하기 위해 재구성함
-
주석의 중요성에 대해 언급하지 않은 중요한 사례가 있음
- USB 장치 드라이버 소프트웨어를 작성할 때, 장치를 잘못된 상태로 만들기 쉬움
- 해결 방법을 구현할 때마다 주석을 추가하여 문서화함
- 주석 없이 다른 사람이 코드의 의도를 이해하기 어려움
-
"A Philosophy of Software Design"을 강력히 추천함
- 추상화의 품질을 복잡성의 비율로 측정하는 것이 핵심임
- 다른 프로그래밍 조언 책을 읽은 후 코드가 더 나아지지 않았음
-
Clean Code 운동 이전에 소프트웨어 산업의 실제 문제에 대한 반응이었음
- Clean Code는 더 나은 방향으로 나아갔지만 과도하게 수정됨
- 사람들이 다시 거대한 메서드와 깊게 중첩된 조건문으로 돌아갈지 알 수 없음
-
Bob의 주석에 대한 의견은 이상함
- 잘못된 주석에 대한 편집증은 터무니없음
- 명확하지 않은 코드로 인해 낭비한 시간이 많음
- 이상한 그림을 만드는 대신 알고리즘을 간단히 설명하거나 링크를 제공하는 것이 더 쉬울 것임
-
Uncle Bob의 책은 시간이 지나면 벗어나게 됨
- Clean Code의 가이드를 따르면서 "과도한 분해"에 대해 배움
- 작은 함수들이 결국 아무것도 하지 않게 됨
- 좋은 코드를 쓰고 싶다면 좋은 코드를 읽고, 자신에게 맞는 취향을 개발해야 함
-
Clean Code의 이름에 대한 불만이 있음
- 코드의 청결함을 객관적으로 측정할 수 없음
- "깨끗한 코드"를 쓰는 것이 당연히 좋은 것이라는 무의식적인 요소가 문제를 일으킴
- "Uncle Bob"의 기반은 처음부터 부패했음
코딩 자기계발서는 기술이나 구현방법에 대한 가치관이 없는 상태의 초급자에겐 괜찮지만 경험이 쌓일 수록 효용이 줄어든다고 생각합니다. 모든 프로젝트와 환경에 맞는 절대적인 진리는 없기도 하고 일반론이 적용되지 않는 상황도 있기 때문입니다. 다른 일반적인 분야의 자기계발서 조언처럼 적당히 거리를 두면서 상황에 맞는 조언만 적용하고, 맹목적으로 조언을 추구하지는 않는 편이 나아보입니다
John의 말에 조금 더 공감이 갑니다.
핵심은 두 사람의 말을 도그마처럼 무조건 따를 것이 아니라 왜 그러한가를 이해하고 나아가야 한다는 게 아닐까 싶습니다.