"클린 코드"는 항상 시간을 들일 가치가 있나요, 아니면 때로는 "충분히 좋은" 정도면 괜찮나요?

Question

IT Interview Practice · Accepted Answer

**그것은 코드의 수명과 blast radius에 달려 있습니다.** 클린 코드는 오래 살고 변하는 코드에서 큰 보상을 주고, "충분히 좋은" 정도는 일회성·프로토타입·거의 손대지 않는 코드에 맞는 선택입니다. 핵심 기술은 투자를 상황에 맞추는 것입니다 — 엉성함과 gold-plating 양쪽 모두를 피하면서.

## 원칙: 노력을 코드의 수명에 맞춰라

코드 품질은 하나의 **투자**이며, 모든 투자처럼 그 수익은 시간과 노출도에 달려 있습니다. 던져야 할 두 가지 질문:

- **이 코드는 얼마나 오래 살 것인가?** 수년간 읽히고 수정되는 코드는 명료함을 누릴 자격이 있지만, 일회성 스크립트는 그렇지 않습니다.
- **blast radius는 얼마인가?** 많은 사람이 손대고 critical path가 의존하는 핵심 모듈은 주의를 들일 가치가 있지만, 거의 변하지 않는 고립된 구석은 그렇지 않습니다.

## 클린 코드가 분명히 이기는 경우

- **자주 변하는** 코드 — 누군가 읽거나 수정할 때마다 명료함이 보상됩니다.
- **공유되거나 중심적이거나 오래 사는** 코드 — 혼란의 비용이 사람과 시간에 걸쳐 곱해집니다.
- **버그가 비싼** 모든 곳 — 결제, auth, 데이터 무결성.

## "충분히 좋은" 정도가 맞는 선택인 경우

- **일회성 코드** — 스파이크, 실험, 일회성 마이그레이션, 내일 지울 스크립트.
- 아이디어를 검증하기 위한 것이지 살아남기 위한 것이 아닌 **프로토타입**.
- 다듬어도 얻는 게 적은, **거의 손대지 않고 위험이 낮은** 코드.

## 두 가지 실패 모드

| 실패 | 어떻게 보이는가 | 비용 |
|---|---|---|
| **엉성함** | 오래 살 코드에 엉망진창을 출하 | 미래 변경 지연, 버그, 침식 |
| **Gold-plating** | 중요하지 않을 코드를 과잉 설계 | 시간 낭비, 성급한 abstraction |

둘 다 실제 낭비입니다. "충분히 좋은" 정도는 *의도적이고 맥락에 따른* 선택이지 — 부주의의 핑계도 아니고, 영원히 다듬어도 된다는 면허도 아닙니다.

## 왜 중요한가

이 질문은 품질을 **교조적으로** 적용하는 엔지니어와 **경제적으로** 적용하는 엔지니어를 가릅니다. 클린 코드를 종교처럼 다루면 일회성 코드에 노력을 낭비하고, 선택사항으로 다루면 당신이 의존하는 시스템을 썩게 만듭니다. 시니어의 판단력은 *자신이 어떤 종류의 코드를 들고 있는지*를 알고 그에 맞게 투자하는 것입니다 — 그리고 그 트레이드오프를 설명할 수 있다는 것이야말로 팀이 보고 싶어 하는 실용적 사고입니다.

실패	어떻게 보이는가	비용
엉성함	오래 살 코드에 엉망진창을 출하	미래 변경 지연, 버그, 침식
Gold-plating	중요하지 않을 코드를 과잉 설계	시간 낭비, 성급한 abstraction

원칙: 노력을 코드의 수명에 맞춰라

클린 코드가 분명히 이기는 경우

"충분히 좋은" 정도가 맞는 선택인 경우

두 가지 실패 모드

왜 중요한가

관련 질문