JavaScript 클린 코드란 무엇인가 — 사고방식 정렬

---

1) 한 문단 요약 — 이 글에서 얻는 것 3가지

이 글은 클린 코드를 규칙이나 스타일이 아닌 ‘의사결정의 누적’으로 재정의한다. 자바스크립트에서 클린 코드가 특히 어려운 구조적 이유를 설명하고, 사례 기반 + 의식적 수련으로 사고방식을 교정하는 현실적인 학습 루틴을 제시한다. 마지막으로, 수강 전·후 반복해서 참고할 수 있는 재학습 인덱스와 실전 체크리스트를 제공한다.

---

2) 클린 코드가 필요한 이유 — 실무 비용 관점

클린 코드는 미학의 문제가 아니다. 비용의 문제다.

1. 변경 비용

• 요구사항은 반드시 바뀐다.
• 클린하지 않은 코드는 “어디를 고쳐야 하는지” 판단하는 데 시간이 든다.
• 변경 시 영향 범위를 예측할 수 없는 코드가 가장 비싸다.

2. 버그 비용

• 자바스크립트는 런타임까지 오류가 숨어 있는 경우가 많다.
• 읽기 어려운 코드일수록 버그가 숨어들 공간이 많다.
• 버그 자체보다, 버그의 원인을 찾는 시간이 더 비싸다.

3. 리뷰 비용

• 리뷰는 로직을 검증하는 자리이지, 해석 대회가 아니다.
• “이 코드가 뭘 하려는지” 설명이 필요하다면 이미 비용이 발생한 상태다.
• 클린 코드는 리뷰어의 인지 부하를 최소화한다.

정리하면, 클린 코드는 “예쁘게 쓰자”가 아니라 👉 변경·버그·리뷰 비용을 구조적으로 낮추는 선택의 집합이다.

---

3) 자바스크립트에서 특히 클린 코드가 어려운 이유

자바스크립트는 클린 코드에 불리한 언어다. 이유는 명확하다.

1. 암묵성 (Implicit Behavior)

• 타입, this 바인딩, 형변환, 스코프 등 많은 것이 암묵적으로 동작한다.
• 코드가 짧아질수록 의미가 사라질 위험이 커진다.

// Bad: 의도가 드러나지 않는다
if (value) { ... }

// Better: 판단 기준이 명시된다
if (value !== null && value !== undefined) { ... }

2. 과도한 유연성

• 같은 문제를 해결하는 방법이 너무 많다.
• “동작하는 코드”와 “이해 가능한 코드”의 간극이 크다.
• 스타일 가이드만으로는 이 선택을 대신해줄 수 없다.

3. 런타임 의존

• 많은 오류가 실행 전에는 드러나지 않는다.
• 결국 코드를 읽고 예측하는 능력이 핵심이 된다.
• 이 능력은 규칙 암기가 아니라 사고 훈련으로만 길러진다.

---

4) 수련 루틴 — Bad → Better → 원칙 → 재적용

(하루 30분 기준)

이 강의의 핵심은 “정답을 외우는 것”이 아니라 의식적으로 사고를 교정하는 과정이다.

Step 1. Bad Case (10분)

• 의도적으로 읽기 어려운 코드, 실제로 문제가 있었던 코드 선택
• “왜 이 코드는 위험한가”를 말로 설명해본다

// Bad
function process(a, b, c) {
  if (a && b) {
    if (!c) {
      doSomething();
    }
  }
}

Step 2. Better Case (10분)

• 같은 동작을 더 명확한 구조로 다시 작성
• 조건, 책임, 흐름을 분리

// Better
function canProcess({ a, b, c }) {
  return a && b && !c;
}

if (canProcess(params)) {
  doSomething();
}

Step 3. 원칙 추출 (5분)

• “조건은 함수로 추출하면 읽기 쉬워진다”
• “부정 조건은 의미를 숨긴다”

Step 4. 재적용 (5분)

• 오늘 작성한 코드 1곳에 같은 원칙을 강제로 적용
• 효과가 없었다면 원칙을 수정

이 루틴을 반복하면, 스타일이 아니라 의사결정 패턴이 바뀐다.

---

5) 흔한 오해 5개와 반박

1. “클린 코드는 규칙을 잘 지키는 것이다” → 규칙은 도구다. 상황 판단을 대신해주지 않는다.

2. “유명 스타일 가이드를 따르면 안전하다” → 스타일 가이드는 평균값이다. 맥락 없는 적용은 사고를 멈춘다.

3. “짧은 코드가 좋은 코드다” → 짧은 코드 ≠ 읽히는 코드. 의도가 보이지 않으면 실패다.

4. “네임드 개발자 코드가 정답이다” → 그 코드가 나온 맥락을 모르면 위험하다.

5. “클린 코드는 나중에 해도 된다” → 나중은 없다. 구조는 초기에만 싸게 바꿀 수 있다.

---

7) 오늘 코드에 바로 적용할 체크리스트 10가지

1. 이 함수의 의도를 한 문장으로 말할 수 있는가
2. 조건문이 무엇을 판단하는지 이름으로 드러나는가
3. 부정 조건을 긍정 조건으로 바꿀 수 있는가
4. 암묵적 동작에 의존하고 있지는 않은가
5. “왜 이렇게 했는지” 주석 없이 설명 가능한가
6. 하나의 함수가 하나의 결정만 내리는가
7. 스타일이 아니라 맥락을 기준으로 선택했는가
8. 리뷰어가 처음 봐도 흐름을 따라갈 수 있는가
9. 변경 시 영향 범위를 예측할 수 있는가
10. 이 코드가 6개월 뒤의 나에게도 친절한가

---

코드 리뷰에서 바로 쓰는 질문 7개

1. 이 코드의 핵심 책임은 무엇인가?
2. 이 조건이 필요한 이유를 말로 설명할 수 있는가?
3. 여기서 가장 위험한 의사결정은 무엇인가?
4. 이 코드를 더 읽기 쉽게 만들 수 있는 이름은 없는가?
5. 암묵적으로 기대하는 전제는 무엇인가?
6. 요구사항이 바뀌면 어디가 가장 먼저 깨질까?
7. 이 구조를 선택한 이유는 무엇인가?

---

• 참고: 클린코드 자바스크립트(JavaScript)