클린 코드 실전 강의 교재¶

1장 — 깨끗한 코드¶

원서: 로버트 C. 마틴 『Clean Code』 대상: Java/Spring 백엔드 입문~중급 수강생 형식: 개념 → 비유 → 현업 예제 → 함정 → 핵심 교훈 → 체크리스트 → 퀴즈

0. 이 장을 시작하기 전에¶

0.1 학습 목표¶

"왜 깨끗한 코드인가?"를 경제적·직업윤리적 관점에서 설명한다.
나쁜 코드가 시간이 지날수록 어떤 대가를 치르게 하는지 안다.
"우리는 코드의 저자"라는 관점을 받아들이고, 보이스카우트 규칙을 실천 원칙으로 삼는다.

0.2 큰 그림 — 1장은 "선언문(manifesto)"¶

1장은 기법이 아니라 태도에 관한 장입니다. 이후 모든 장(이름·함수·주석·테스트…)이 이 선언 위에 세워집니다.

[ 코드는 사라지지 않는다 ] → [ 나쁜 코드는 비싸다 ] → [ 빨리 가려면 깨끗하게 ]
                                                         → [ 우리는 저자다 / 보이스카우트 규칙 ]

0.3 현업에서 왜 중요한가¶

일정 압박 속에서 "일단 돌아가게" 짠 코드가 쌓여 기술 부채가 되고, 차세대·유지보수 단계의 속도를 갉아먹습니다.
1장은 "왜 우리가 품질을 지켜야 하는가"에 대한 직업적 근거를 줍니다. 이후 장들의 동기가 됩니다.

1.1 코드는 사라지지 않는다 (코드가 존재하리라)¶

비유 — "요구사항을 기계가 따를 만큼 정밀하게 적은 글"¶

"코드 없는 개발"이라는 말이 주기적으로 등장하지만, 결국 누군가는 요구사항을 모호함 없이, 기계가 실행할 만큼 정밀하게 적어야 합니다. 그 정밀한 명세가 바로 코드입니다. 추상화 수준이 올라가고 도구가 좋아져도, "정확한 명세"라는 본질은 사라지지 않습니다.

핵심¶

코드는 요구사항을 엄밀하게 표현한 것이다. 엄밀함이 필요한 한, 코드는 남는다.
따라서 "코드를 잘 쓰는 능력"은 사라지지 않는 핵심 역량이다.

1.2 나쁜 코드¶

비유 — "발이 빠지는 늪"¶

나쁜 코드 위에서의 개발은 늪을 걷는 것과 같습니다. 처음 몇 걸음은 괜찮지만, 갈수록 발이 빠져 한 걸음 떼는 데 온 힘이 듭니다.

핵심¶

누구나 나쁜 코드 때문에 발목 잡힌 경험이 있다. "나중에 고치자"의 그 "나중"은 오지 않는다(르블랑의 법칙: Later equals never).
급하게 출시하려고 엉망으로 짠 코드가, 정작 그 출시 이후를 더 느리게 만든다.

현업 메모: "지금은 급하니까 일단 대충"이라는 결정이 누적되면, 같은 팀이 6개월 뒤 그 코드 위에서 신음합니다. 나쁜 코드의 청구서는 반드시, 그리고 본인에게 돌아옵니다.

1.3 나쁜 코드로 치르는 대가¶

생산성 곡선 — 0으로 수렴한다¶

생산성
  │■■■■■■■
  │       ■■■■■
  │            ■■■
  │               ■■
  │                 ■■
  │                   ■■■
  └──────────────────────■■■■───▶ 시간
   (코드가 엉킬수록 같은 기능에 점점 더 오래 걸린다)

나쁜 코드가 쌓이면 팀 생산성은 시간이 지날수록 떨어져, 결국 0에 가까워집니다. (리팩터링 2장 "설계 지구력 가설"의 그늘진 곡선과 같은 이야기입니다.)

1.3.1 원대한 재설계의 꿈 — 대개 실패한다¶

생산성이 바닥나면 "처음부터 새로 짜자"는 유혹이 옵니다(타이거 팀의 전면 재설계).
하지만 새 시스템을 만드는 동안 옛 시스템도 계속 유지보수해야 하고, 요구사항은 계속 변합니다. 새 팀이 옛 시스템을 따라잡는 데 수년이 걸리기도 합니다.
교훈: 재설계 도박보다, 평소에 꾸준히 깨끗하게 유지하는 편이 싸다.

1.3.2 태도 — 프로의 책임¶

"일정이 빠듯해서"는 변명이 됩니다. 하지만 나쁜 코드를 막는 것은 개발자의 직업적 책임입니다.
의사가 "환자가 손 씻기 싫어해서 안 씻었다"고 하지 않듯, 전문가는 외부 압력에 코드 품질을 양보하지 않습니다. 좋은 코드를 사수하는 것이 프로의 일입니다.

1.3.3 원초적 난제 — "빨리 가려면 깨끗해야 한다"¶

흔한 착각: "깨끗하게 짜면 느리다."
진실: 엉망인 코드는 단기적으로도 당신을 느리게 만든다. 빠르게 가는 유일한 길은 항상 코드를 깨끗하게 유지하는 것입니다.

1.3.4 깨끗한 코드란? (대가들의 공통점)¶

이 절에서 여러 유명 개발자가 각자의 정의를 내놓습니다. 표현은 달라도 공통된 주제가 보입니다(원문 인용 대신 핵심만 정리).

우아하고 효율적이다 — 한 가지를 잘하고, 군더더기가 없다.
읽기 쉽다 — 다른 사람이 의도를 바로 파악한다. 코드가 곧 설명서.
단순하고 직접적이다 — 숨은 의도나 함정이 없다.
중복이 없다 — 한 개념은 한 곳에만.
테스트가 있다 — 검증되지 않은 코드는 깨끗하지 않다.
주의 깊게 다듬은 흔적이 있다 — 누군가 신경 써서 가꿨음이 느껴진다.

한 줄 요약: 깨끗한 코드 = 읽는 사람이 "이 사람, 신경 썼구나"라고 느끼는 코드.

1.4 우리들 생각 / 1.5 우리는 저자다¶

비유 — "코드는 글이다, 그리고 독자가 훨씬 많다"¶

코드는 쓰는 시간보다 읽히는 시간이 압도적으로 깁니다(읽기:쓰기 비율이 대략 10:1이라고들 합니다). 한 줄을 새로 쓰기 위해, 우리는 주변 코드를 수없이 다시 읽습니다.

핵심¶

@author 태그가 말하듯, 우리는 코드의 저자입니다. 저자는 독자를 위해 씁니다.
따라서 "내가 빨리 쓰기 편한 코드"가 아니라 "남이 읽기 쉬운 코드"가 목표입니다. 읽기 쉬운 코드가 결국 쓰기도 빠르게 만듭니다(다음에 읽는 시간이 줄어드니까).

현업 메모: 6개월 뒤의 나도 "남"입니다. 미래의 나를 위한 배려가 곧 좋은 코드입니다.

1.6 보이스카우트 규칙¶

비유 — "캠핑장을 처음보다 깨끗하게"¶

보이스카우트에는 "왔을 때보다 깨끗하게 두고 떠나라"는 규칙이 있습니다. 코드도 마찬가지입니다.

핵심¶

파일을 열 때마다 조금씩 개선하고 떠납니다. 이름 하나 고치기, 긴 함수 한 조각 추출하기, 죽은 코드 한 줄 지우기.
거대한 청소를 따로 잡는 게 아니라, 지나가며 줍는 습관입니다. 이 작은 개선이 쌓여 시스템의 부패를 막습니다.

교차 연결: 이 규칙은 리팩터링 2장의 "쓰레기 줍기 리팩터링"과 정확히 같은 실천입니다. 두 책이 공유하는 핵심 습관이에요.

1.7 프리퀄과 원칙 / 1.8 결론¶

이 책은 저자의 객체지향 설계 원칙(SOLID 등)을 다룬 후속 작업의 실천편(프리퀄 격)입니다. 원칙을 코드 레벨에서 어떻게 구현하는지 보여줍니다.
결론: 깨끗한 코드는 지식만으로 되지 않습니다. 그림을 보는 눈과 그리는 손이 다르듯, 코드 감각(code-sense)은 연습으로 길러집니다. 이 책의 나머지는 그 감각을 기르는 훈련입니다.

핵심 교훈¶

코드는 사라지지 않는다 — "정밀한 명세를 쓰는 능력"은 핵심 역량이다.
나쁜 코드의 청구서는 반드시, 본인에게 돌아온다(Later equals never).
빨리 가는 유일한 길은 깨끗하게 가는 것. 깨끗함은 속도의 적이 아니라 동력이다.
전면 재설계 도박보다 꾸준한 청결 유지가 싸다.
우리는 저자다 — 독자(미래의 나·동료)를 위해 쓴다(읽기 ≫ 쓰기).
보이스카우트 규칙 — 열 때마다 조금 더 깨끗하게.

체크리스트 (마음가짐)¶

"일단 돌아가게"의 결정이 누구에게 청구될지 의식하는가
일정 압박을 핑계로 코드 품질을 양보하고 있지 않은가
내 코드를 "내가 쓰기 편하게"가 아니라 "남이 읽기 쉽게" 쓰는가
파일을 닫기 전, 작은 개선 하나라도 하고 떠나는가
검증(테스트) 없는 코드를 "완성"이라 부르고 있지 않은가

퀴즈¶

Q1. "Later equals never(르블랑의 법칙)"가 뜻하는 바는?

A. "나중에 정리하자"고 미룬 코드는 결국 정리되지 않는다는 경험칙. 그래서 지금, 작게라도 깨끗하게 유지해야 합니다.

Q2. "깨끗하게 짜면 느리다"는 통념에 대한 이 책의 반박은?

A. 엉망인 코드는 단기적으로도 개발을 느리게 만든다. 빠르게 가는 유일한 길이 코드를 항상 깨끗하게 유지하는 것이다.

Q3. "원대한 재설계"가 대개 실패하는 이유는?

A. 새 시스템을 만드는 동안 옛 시스템도 유지·진화해야 해서, 새 팀이 움직이는 표적을 따라잡기 어렵습니다(수년 소요·중도 실패).

Q4. "우리는 저자다"가 코딩에 주는 실천적 함의는?

A. 코드는 쓰기보다 읽히는 시간이 훨씬 길므로, 독자(동료·미래의 나)가 읽기 쉽게 쓰는 것을 최우선으로 삼아야 한다.

Q5. 보이스카우트 규칙을 코딩에 적용하면?

A. 파일을 열 때마다 처음보다 조금 더 깨끗하게 만들고 떠난다(이름 개선, 작은 추출, 죽은 코드 제거 등). 작은 개선의 누적이 부패를 막는다.

다음 장 예고 — 2장: 의미 있는 이름¶

"깨끗함"의 가장 즉각적인 실천인 이름 짓기를 다룹니다. 의도를 드러내는 이름, 그릇된 정보 피하기, 검색·발음 쉬운 이름, 인코딩(헝가리식 표기) 회피, 클래스·메서드 명명까지. 리팩터링 3장의 "기이한 이름" 악취와 곧장 이어지는 실전 장입니다.

이어서 만들까요? (2장 의미 있는 이름으로 진행 / 3장 함수로 점프 / 지금까지의 세 권(이펙티브 자바·리팩터링·클린코드)을 한 번에 보는 통합 인덱스 만들기)