"코드는 작성되는 시간보다 읽히는 시간이 훨씬 길다는" 전제 아래, 어떻게 하면 읽기 쉽고 유지보수하기 좋은 코드를 작성할 수 있는지 매우 구체적인 가이드라인을 제시합니다.
본 문서에서는 책의 핵심 규칙 요약과 더불어, 현대 자바 개발자의 관점에서 바라본 솔직한 도서 리뷰 및 실무 적용 방향성을 정리했습니다.
1. 핵심 내용 요약
책은 좋은 코드의 정의부터 시작해 변수명, 함수 구성, 에러 처리, 설계 원칙(SOLID), 그리고 리팩터링 기법까지 단계별로 다룹니다.
핵심 규칙을 관통하는 가장 중요한 키워드는 가독성과 단순성입니다.
① 의미 있는 이름 (Naming)
- 의도를 명확히 드러내라: 변수, 함수, 클래스 이름은 존재 이유와 수행 역할을 명확히 드러내야 합니다. 의도를 알 수 없는 한 글자 변수(
x, y)나 의미 없는 임시 축약어는 지양합니다.
- 그릇된 정보는 피하라: 실제 List 자료형이 아님에도 변수명 끝에
List를 붙이는 등의 오해를 부르는 이름은 피해야 합니다.
- 발음하고 검색하기 쉬운 이름을 쓰라:
int d; 보다는 int daysSinceCreation;이 검색과 소통에 훨씬 유리합니다.
② 작고 한 가지만 하는 함수 (Functions)
- 작게, 더 작게 만드라: 함수의 이상적인 길이는 20줄 이내입니다.
- 한 가지만 해라 (Single Responsibility): 함수는 지정된 이름의 단 한 가지 작업만 완벽하게 수행해야 합니다. 내부에서 서브 작업이 필요하다면 별도 함수로 분리하세요.
- 인수(Arguments) 개수를 줄이라: 가장 이상적인 인수는 **0개(무항)**이며, 최대 2개를 넘지 않는 것이 좋습니다. 3개 이상이라면 객체(클래스/DTO)로 묶어서 전달하는 것을 고려해야 합니다.
③ 주석은 꼭 필요한 경우에만 (Comments)
- 코드로 표현하라: "좋은 주석은 없다. 가장 좋은 주석은 주석이 필요 없는 코드다." 주석을 달아야 할 정도로 코드가 복잡하다면, 주석을 쓸 게 아니라 코드를 리팩터링하여 의도를 투명하게 만드는 것이 맞습니다.
- 허용되는 주석: 법적인 주석(저작권), 앞으로의 계획(
// TODO), 혹은 복잡한 알고리즘의 정당성을 증명하는 불가피한 설명 정도만 유효합니다.
④ 오류 처리와 경계 (Error Handling & Boundaries)
- 오류 코드 대신 예외(Exception)를 쓰라: 리턴값으로 오류 코드를 남기면 호출부의 조건 분기가 지저분해집니다.
try-catch 블록과 커스텀 예외를 활용해 비즈니스 로직과 오류 처리 로직을 깔끔하게 분리하세요.
- Null을 반환하거나 전달하지 마라: 모든
NullPointerException(NPE)의 주범입니다. 빈 객체(Null Object 패턴)나 빈 컬렉션(Collections.emptyList())을 반환하는 것이 훨씬 안전합니다.
⑤ 객체 지향 설계 원칙 (SOLID)과 클린 코드 규칙
- SOLID 원칙 준수: 시스템 아키텍처 수준에서는 SOLID 원칙을 철저히 준수해야 코드가 썩지 않고 유연성을 유지할 수 있습니다.
- 보이스카우트 규칙: "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라." 코드를 수정할 때마다 조금이라도 더 깨끗하게 리팩터링하고 커밋하는 습관이 시스템 전체의 수명을 늘립니다.
2. 《Clean Code》 종합 리뷰
장점: 주니어를 시니어로 도약시키는 실무 지침서
- 추상적이지 않은 구체성: 단순히 "코드를 깨끗이 짜라"는 모호한 훈계에 그치지 않습니다. 자바(Java) 기반의 풍부한 전후(Before & After) 코드 예시를 통해 "이렇게 짜던 코드를 요렇게 바꾸라"고 구체적이고 밀착력 있게 가르쳐줍니다.
- 소프트웨어 장인 정신 고취: 개발자를 단순한 키보드 타이퍼가 아닌, 장인(Craftsman)의 관점으로 이끌어주어 본인의 코드 퀄리티에 대한 직업적 책임감을 심어줍니다.
- 유지보수 비용 감소: 이 책의 규칙을 준수한 코드는 기술 부채(Technical Debt)를 혁신적으로 줄여주며, 대규모 분산 개발 환경에서 팀원 간의 코드 리뷰 시간을 대폭 단축시킵니다.
한계 및 비판: 극단성과 현대 개발 트렌드와의 괴리
- 다소 극단적이고 도그마적인 규칙: "함수는 무조건 20줄 이내여야 한다", "인수는 무조건 2개 이하여야 한다" 같은 규칙은 실무에서 지나치게 경직된 제약이 되기도 합니다. 이로 인해 클래스와 함수가 너무 미세하게 쪼개져 오히려 전체적인 실행 흐름을 파악하기 힘들어지는 파편화 마술이 발생할 수 있습니다.
- 자바(Java) 중심적 아키텍처: 책의 모든 예제와 사상이 전통적인 정적 타입의 객체지향 언어(Java)에 강력히 튜닝되어 있습니다. 함수형 프로그래밍 패러다임이 대세가 된 현대 자바스크립트/타입스크립트, 파이썬 환경이나 마이크로서비스 아키텍처(MSA) 환경에서는 그대로 적용하기 어색한 규칙들이 존재합니다.
4. Clean Code에 대한 견해
Clean Code의 규칙을 무조건 도그마적으로 따르기보다는 실무 환경에 맞춘 유연하고 실용적인 적용이 중요하다고 생각합니다. 책에 제시된 함수 길이나 매개변수 개수 등의 기준에만 지나치게 얽매이면 코드가 과도하게 파편화되고 결합도가 높아져 오히려 가독성과 명확성을 해칠 수 있습니다.
따라서 무분별한 클래스 생성은 지양하되 타입 분리가 필요한 시점에는 Factory나 Adapter 같은 디자인 패턴을 유연하게 활용하며, 복잡한 테스트 도입이 어려울 때는 가벼운 main 메서드 기반의 검증을 통해 현실적으로 로직의 무결성을 지키는 구조화를 지향합니다.
핵심 요약: 진정한 클린 코드는 규칙의 맹신이 아니라 현업 상황에 맞춘 유연한 구조화에서 시작됩니다.