클린 코드 vs 소프트웨어 설계 철학

 

Robert “Uncle Bob” Martin과 John Ousterhout이 2024년 9월부터 2025년 2월까지 진행한 소프트웨어 설계 관련 대화로,

두 사람 모두 소프트웨어 디자인에 대한 저서를 집필

세가지 주요 주제(메서드 길이, 주석, Test-Driven Development)에 서로 다른 견해 차이를 보임

 

대화의 핵심은 코드의 복잡도를 줄이고, 가독성을 높이는 방법,

그리고 적잘한 테스트 코드 작성 방식에 대한 것

 

- Uncle Bob의 clean code

-  John의 philosophy of sw design

 

메소드 길이

Uncle Bob(이하 UB)은 “짧은 함수가 좋음, 가능하다면 더 짧게 분리함”이라는 입장

- 한 메소드는 One Thing 만 해야 함

- 단, 너무 극단적으로 적용 시, 과도한 분해(over-decomposition)

 

John은 너무 작은 메소드는 오히려 전체 흐름을 이해하기 어렵게 만든다 지적

- 얇은(shallow) 메소드가 많으면, 하나의 기능을 이해하기 위해 관련 메소드를 모두 살펴봐야 하는 문제 -> 메서드 간 상호 의존도(entanglement)가 높아져, 코드 읽기 부담이 커짐

 

PrimeGenerator 예시
- UB의 원 코드는 8개 정도의 작은 메서드로 나뉘었고, 메서드들이 서로 얽혀 있어 이해하기 어려웠음
- John의 버전은 하나의 메서드에 주석을 충분히 달아서 전체 흐름을 한눈에 파악할 수 있게 작성했음

- UB도 “과도한 분해가 있었다는 점”을 어느 정도 인정했

 

결론적으로, 두 사람은 코드 분해가 중요함 인정, “너무 작게 쪼개는 것”과 “너무 크게 두는 것” 사이에서 균형을 잡는 것이 핵심임

 

주석

UB는 주석이 "필요 악(necessary evil)"

- 주석은 업데이트가 잘 안되거나, 잘못된 정보를 담을 위험 존재

- 코드를 통해 최대한 의도를 드러내고, 필요하면 매우 긴 이름을 사용하는 방식 서호

 

John은 주석이 필수

- 인터페이스(메서드)의 목적이나 구현 의도를 영어로 명확히 적어두면, 다른 개발자가 불필요한 코드를 뒤지는 시간을 줄임

- 가장 위험한 것 : 주석이 없어 코드를 직접 해석해야 하는 상황

 

UB는 “주석이 정확하지 않으면 오히려 해가 된다”는 입장 <-> John은 “잘못된 주석보다는 없는 주석이 더 해롭다”

 

두 사람 모두 “팀과 상황에 따라 적절한 수준의 주석을 달아야 한다”는 데에 어느 정도 합의했지만, 전반적으로 John이 주석의 가치를 훨씬 높게 평가함

 

Test-Driven Development

UB는 짧은 주기로 테스트 먼저 작성, 실패하는 테스트를 통과시키기 위한 코드를 조금씩 추가하여 TDD 방식 적극 권장

- 코드가 항상 데스트 커버리지를 유지하고, 복잡한 디버깅을 피할 수 있다고 주장

- 코드는 자주 리팩토링하며 점진적으로 깨끗해진다는 입장

 

John은 TDD가 지나치게 "전술적인 접근"으로 흐른다고 우려

- "설계 먼저 선행 필수, TDD는 코드를 먼저(테스트를 위한 최소 구현) 쓰도록 유도"한다는 지적

- 좋은 설계는 한번에 좀 더 넓은 범위를 고민하고, 해당 코드에 대해 테스트를 묶어 작성(bundling)하는 편이 낫다고 함

 

UB : "TDD를 잘못 적용하여 생기는 문제"가 있을 수 있지만, 바르게 실천시 테스트 커버리지와 리팩토링에 도움이 된다 주장

John : TDD가 초보자에게 오히려 코드가 빠르게 엉망이 될 위험이 크다는 우려

 

최종적으로, 두 사람은 "TDD도, Bundling 접근도 잘만 하면 둘다 휼륭한 코드를 만들 수 있다"는데 동의하지만, 어느 쪽이 더 나은지는 입장이 다름

 

맺음말

결론적으로, 두 사람은 소프트웨어 설계의 중요성과 "코드를 읽기 쉽게 만드는 것"을 최우선 가치로 봄

다만, 메소드 분리 기준, 주석 활용 방식, 테스트 작성 순서 등에서 입장 차이 존재

=> 핵심은 팀 환경과 코드 구조에 맞춰 균형을 잡고, 설계를 지속적으로 개선하려는 노력 필요

 

 

---

 

TMI와 나의 짧은 소견

회사에서 적응하면서, 내가 맡은 두개의 테스크가 현재 회사에 없는 사람이 짠 코드라서

이것저것 혼자서 이해하는데 시간을 쏟아야 했다.

 

코드에 대한 주석을 작성하지 않는 분위기라는 것을 느꼈다.

 

그 대신에 코드를 이해하기 위해서는

해당 코드의 commit message를 통해서 확인을 하거나,

PR 요청 날린 것과 그 conversation을 확인해서 이해를 해야 한다.

 

이것을 어떤 것에 쓰일건지에 대해서는 보통 commit message를 보면 된다.

또한 commit message에 대한 convention에 대해 정보들을 필수적으로 작성되어야 해서,,

어떤 서비스에 들어가는지에 대해서는 보통 커밋메시지로 이해를 해볼 수 있었다.

 

이것을 왜 이렇게 작성했는지에 따라서는, 보통 관련된 PR 정보 내부에 존재하기 때문에 찾아봐야 한다.

 

그리고 메소드들이 잘게 나눠진 것보다는,

되게 크게크게 나눠져있어서 이것저것 타고 들어갈 필요는 없어서 이해하기 깔끔했고,

(대신에 이러한 가독성을 위해서, 코드의 중복은 어느정도 존재하는 것 같다.)

또한, 주석이 없는 대신에, 변수나 함수의 명이 대신 설명을 해주어서 좋았다.

 

나또한 메소드가 과하게 분리되지 않는 문화가 좋았고,

개인적으로 주석이 필수적이지 않으면, 최대한 지양하는게 좋다고 생각한다.

- 대신, 함수의 명과 변수 이름으로 최대한 주석을 대신할 수 있도록!

또 주석이 있더라도, 주석에 대한 길이가 길면 잘 안읽히는 것 같다는 생각이 들었다.

- 주석은 지양하지만, 작성하더라도 최대한 명확하게

- 커밋은 하나의 테스크마다 명확하게 (동일한 테스크가 중복되면 안됨)

 

 

 

 

 

출처 

- https://news.hada.io/topic?id=19431&utm_source=slack&utm_medium=bot&utm_campaign=TL0NAE2AD