243. 코드 스멜 진단 (Code Smell Diagnosis)

핵심 인사이트 (3줄 요약)

1. 본질: 코드 스멜 (Code Smell) 은 설계 문제를 암시하는 코드 패턴으로, 버그는 아니지만 미래의 버그·유지보수 비용을 예고하는 경고 신호다.
2. 가치: 스멜을 명명하고 분류함으로써 팀이 공통 언어로 설계 문제를 논의하고 우선순위를 정해 리팩토링 (Refactoring) 로드맵을 수립할 수 있다.
3. 판단 포인트: "이 코드를 처음 보는 개발자가 10분 안에 이해할 수 있는가?" — No라면 스멜을 찾아야 한다.

Ⅰ. 개요 및 필요성

마틴 파울러 (Martin Fowler) 와 켄트 벡 (Kent Beck) 이 체계화한 개념으로, "코드에서 나는 나쁜 냄새"를 의미한다. 스멜은 그 자체가 결함은 아니지만, 리팩토링이 필요함을 나타내는 표면적 지시자다.

스멜을 방치하면 기술 부채 (Technical Debt) 가 복리로 쌓인다. 초기 발견 시 수정 비용 대비 후기 발견 시 수정 비용은 10~100배 차이가 난다고 알려져 있다.

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ Problem      │──▶│ Core Idea    │──▶│ Expected Gain │
└──────────────┘    └──────────────┘    └──────────────┘

• 📢 섹션 요약 비유: 냄새나는 음식은 먹으면 탈이 나기 전에 버려야 한다 — 코드 스멜도 버그가 터지기 전에 제거해야 한다.

Ⅱ. 아키텍처 및 핵심 원리

┌──────────────────────────────────────────────────────────┐
│                   코드 스멜 분류 체계                    │
├──────────────────┬───────────────────────────────────────┤
│  스멜 유형       │  영향 범위                            │
├──────────────────┼───────────────────────────────────────┤
│ Long Method      │  단일 메서드 내부                     │
│ Large Class      │  단일 클래스 내부                     │
│ Primitive        │  타입 시스템 전체                     │
│ Obsession        │                                       │
│ Shotgun Surgery  │  시스템 전체 (변경 시 파급 효과)      │
│ Feature Envy     │  클래스 간 의존 관계                  │
└──────────────────┴───────────────────────────────────────┘

[ 피처 엔비 (Feature Envy) 예시 ]
┌─────────────┐        ┌─────────────────────────┐
│  Order      │        │  Customer               │
│             │        │  - name                 │
│ printLabel()│──많이──▶│  - address              │
│  (이 메서드가│  접근   │  - postalCode           │
│  Customer   │        │  - country              │
│  데이터에   │        │                         │
│  집착)      │        │                         │
└─────────────┘        └─────────────────────────┘
        → printLabel()을 Customer로 이동해야 함

① 롱 메서드 (Long Method)

• 진단: 메서드 길이 > 20줄, 들여쓰기 > 3단
• 처방: 메서드 분리 (Extract Method)

② 라지 클래스 (Large Class)

• 진단: 필드 > 10개, 메서드 > 20개, 2000줄+
• 처방: 클래스 분리 (Extract Class), 인터페이스 추출 (Extract Interface)

③ 프리미티브 강박 (Primitive Obsession)

• 진단: String으로 전화번호·통화·상태 표현, int로 금액 표현
• 처방: 값 객체 (Value Object) 도입

④ 샷건 수술 (Shotgun Surgery)

• 진단: 기능 1개 변경 시 10개+ 클래스 수정 필요
• 처방: 메서드 이동 (Move Method), 클래스 합병 (Inline Class)

⑤ 피처 엔비 (Feature Envy)

• 진단: 메서드 내 다른 클래스 getter 5회+ 연속 호출
• 처방: 메서드 이동 (Move Method), 데이터와 행동을 같은 클래스로

• 📢 섹션 요약 비유: 의사가 X레이를 보며 "이건 폐렴 징후, 이건 골절 징후"라고 판단하듯, 코드 스멜도 각각 고유한 '증상 패턴'으로 진단한다.

Ⅲ. 비교 및 연결

프리미티브 강박
    │
    ▼
데이터 클럼프 (Data Clumps) ──▶ 라지 클래스
    │                               │
    ▼                               ▼
파라미터 목록 과다 ──────────▶ 롱 메서드
    │                               │
    └───────────────────────────────┘
                                    ▼
                            샷건 수술 / 피처 엔비

• 📢 섹션 요약 비유: 감기→폐렴→패혈증처럼 스멜도 방치하면 연쇄 악화한다 — 초기에 잡는 것이 최선이다.

Ⅳ. 실무 적용 및 기술사 판단

정적 분석 도구 (Static Analysis Tool) 를 활용하면 코드 스멜을 자동 탐지할 수 있다.

• 메서드 길이 20줄 이하인가?
• 클래스당 책임이 1개인가 (SRP 검토)?
• 원시 타입으로 도메인 개념을 표현하지 않는가?
• 변경 시 영향 범위가 최소화되어 있는가?
• 메서드가 소속 클래스의 데이터를 주로 사용하는가?

기술사 논술에서 코드 스멜 진단 도구 (SonarQube) 도입 → 스멜 분류 → 우선순위 리팩토링 로드맵 → 기술 부채 감소 정량화 순서로 서술하면 체계적인 답안이 완성된다.

판단 체크리스트

1. 변경 전 동작을 고정할 테스트가 준비되었는가?
2. 냄새의 원인이 구조 문제인지 일회성 구현인지 구분했는가?
3. 리팩토링 단위를 작게 나눠 롤백 가능하게 했는가?
4. 명명·모델·패키지 경계가 함께 개선되는가?

• 📢 섹션 요약 비유: 건강 검진 결과지에서 "고혈압 위험", "당뇨 전단계"를 보고 식단 조절 계획을 세우듯, SonarQube 리포트로 코드 개선 로드맵을 세운다.

Ⅴ. 기대효과 및 결론

코드 스멜 진단 (Code Smell Diagnosis) 은 리팩토링의 나침반이다. 스멜 없이는 무엇을, 어디서, 왜 리팩토링해야 하는지 논증할 수 없다. 팀이 스멜 어휘를 공유하면 코드 리뷰가 감정이 아닌 객관적 기준 위에 서게 되고, 기술 부채 관리가 데이터 기반으로 전환된다.

확장 방향은 ① 정적 분석 자동화, ② 아키텍처 적합성 검증, ③ 작은 단위의 상시 리팩토링 문화 정착이다.

• 📢 섹션 요약 비유: 미세먼지 농도 수치 없이 "오늘 공기 나쁜 것 같다"고 말하는 것과, PM2.5 150µg/m³ 수치를 근거로 "마스크 착용 필요"라고 말하는 것의 차이 — 코드 스멜 이름이 그 측정 수치다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

정적 분석 지표 → 코드 스멜 진단 → 리팩토링 우선순위

👶 어린이를 위한 3줄 비유 설명

1. 방이 지저분하면 "장난감이 여기저기", "옷이 바닥에", "책상 위에 뭔지 모를 것들" 처럼 문제 유형을 이름 붙여야 어디부터 치울지 알 수 있다.
2. 코드 스멜도 이름을 붙이면 "롱 메서드 먼저, 그 다음 라지 클래스" 순서로 정리할 수 있다.
3. 냄새를 맡을 줄 아는 코드 탐정이 되면 문제가 커지기 전에 예방할 수 있다.