Brain핵심 인사이트 (3줄 요약)
- 본질: SOLID는 유지보수하기 쉬운 소프트웨어를 만들기 위한 객체지향 설계의 5가지 핵심 원칙이며, '코드 냄새(Code Smell)'는 이 원칙들을 어겨서 발생하는 잠재적인 결함의 징조다.
- 가치: 코드가 복잡해지는 것을 막고 변화에 유연하게 대응하여 기술 부채를 줄이며, 리팩토링을 통해 읽기 쉽고 튼튼한 코드로 체질을 개선한다.
- 판단 포인트: 감리 시에는 하나의 클래스가 너무 많은 일을 하는지(SRP 위배), 수정할 때마다 다른 곳이 터지는지(OCP 위배) 등 '코드 냄새'를 진단하고 리팩토링 결과의 적정성을 검증한다.
Ⅰ. 개요 및 필요성
처음엔 깨끗했던 코드도 시간이 흐르면 "스파게티"가 된다. 함수 하나 고쳤는데 엉뚱한 기능이 고장 나고, 코드를 읽어도 무슨 뜻인지 모르는 상태, 즉 '코드가 썩어가는 냄새'가 나기 시작한다. SOLID 원칙은 이러한 코드의 부패를 막는 '5가지 방부제'다. 이 원칙들을 지키면 코드가 모듈화되어, 부품을 갈아 끼우듯 시스템을 쉽게 고치고 확장할 수 있다. 깨끗한 코드는 개발자의 실력을 증명하는 가장 강력한 척도다.
📢 섹션 요약 비유: SOLID 원칙은 '정리 정돈의 달인이 알려주는 수납법'과 같다. 물건(코드)을 종류별로 잘 나누고(SRP), 언제든 꺼내기 쉽게 정리해두면(OCP), 나중에 집 구조를 바꿔도 혼란이 없는 것과 같다.
Ⅱ. 아키텍처 및 핵심 원리
1. 객체지향 5원칙 (SOLID)
- S (Single Responsibility): 단일 책임 원칙. 클래스는 단 하나의 책임만 가져야 함.
- O (Open-Closed): 개방-폐쇄 원칙. 확장에는 열려 있고 수정에는 닫혀 있어야 함.
- L (Liskov Substitution): 리스코프 치환 원칙. 자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 함.
- I (Interface Segregation): 인터페이스 분리 원칙. 사용하지 않는 메서드에 의존하도록 강제하지 않음.
- D (Dependency Inversion): 의존성 역전 원칙. 구체적인 것보다 추상적인 것(인터페이스)에 의존함.
2. 코드 냄새 (Code Smell)와 리팩토링
- 냄새: 중복 코드, 거대한 클래스, 긴 메서드, 스위치 문 남용 등.
- 리팩토링: 결과의 동작은 바꾸지 않으면서 내부 구조만 SOLID 원칙에 맞게 깔끔하게 개선하는 작업.
📢 섹션 요약 비유: SRP(단일 책임)는 '맥가이버 칼 하나로 다 하기보다, 전용 칼과 가위를 따로 두는 것'이다. 칼이 고장 났다고 가위까지 못 쓰게 되는 일을 막기 위해서다.
Ⅲ. 비교 및 연결
코드 냄새 진단 및 처방
| 코드 냄새 (Symptom) | 위배된 원칙 | 리팩토링 처방 (Cure) |
|---|---|---|
| 하나의 클래스가 3,000줄임 | SRP (단일 책임) | 클래스 추출 (Extract Class) |
| 새 기능을 넣을 때마다 if문을 고침 | OCP (개방-폐쇄) | 전략 패턴 (Strategy Pattern) 적용 |
| 하위 클래스가 부모 기능을 못 씀 | LSP (리스코프 치환) | 상속 대신 합성(Composition) 사용 |
| 거대한 인터페이스를 억지로 상속함 | ISP (인터페이스 분리) | 인터페이스 쪼개기 |
📢 섹션 요약 비유: 코드 냄새 진단은 '의사의 청진기'와 같다. 겉으로는 멀쩡해 보여도 내부에서 나는 불협화음(강결합)을 찾아내어, 수술(리팩토링)을 통해 건강한 상태로 되돌리는 과정이기 때문이다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 핵심 포인트 (검증 로직):
- 응집도와 결합도: SOLID 원칙의 궁극적 목표는 '높은 응집도'와 '낮은 결합도'임을 명시하고, 이를 수치화한 지표(LCOM 등)를 언급한다.
- TDD와 리팩토링: 리팩토링 중 코드가 깨지는 것을 막기 위해 반드시 '단위 테스트'가 선행되어야 함을 강조한다. "테스트 없는 리팩토링은 그냥 사고다."
- 감리인의 시각: 정적 분석 도구(SonarQube 등)를 활용해 '기술 부채(Technical Debt)' 수치를 측정하고, 이를 줄이기 위한 사업자의 노력을 정량적으로 평가한다.
📢 섹션 요약 비유: SOLID 검증은 '건물 안전 진단'과 같다. 벽면에 금이 간 곳(코드 냄새)은 없는지, 하중을 견디는 기둥(핵심 인터페이스)은 설계 원칙대로 튼튼하게 세워졌는지 꼼꼼히 검사하는 작업이다.
Ⅴ. 기대효과 및 결론
SOLID 원칙을 준수하는 것은 단순히 코드를 예쁘게 짜는 것이 아니라 소프트웨어의 '생존 기간'을 늘리는 일이다. 기술사 시험에서는 각 원칙의 정의를 정확히 암기하여 제시하고, 코드 냄새라는 실무적 현상을 해결하기 위한 '디자인 패턴'과의 연계성을 논리적으로 서술하는 것이 고득점 전략이다.
📢 섹션 요약 비유: SOLID는 IT 세상의 '건강한 식습관'이다. 당장은 조금 귀찮고 시간이 걸려도, 평소에 이 원칙들을 잘 지키면 나중에 시스템이 '비만(복잡도)'이나 '성인병(장애)'에 걸리지 않고 오랫동안 쌩쌩하게 돌아가기 때문이다.
📌 관련 개념 맵
| 개념 | 연관 키워드 | 관계 |
|---|---|---|
| Refactoring | 구조 개선, 동작 유지 | SOLID 원칙을 실제로 구현하는 행동 지침 |
| Technical Debt | 기술 부채, 이자 | SOLID를 어겼을 때 나중에 지불해야 할 대가 |
| High Cohesion | 응집도, 집중 | SRP 원칙을 지켰을 때 나타나는 긍정적 효과 |
| Low Coupling | 결합도, 독립성 | DIP, OCP 원칙을 통해 달성하고자 하는 상태 |
👶 어린이를 위한 3줄 비유 설명
- 장난감 상자를 정리할 때, 로봇은 로봇끼리 인형은 인형끼리 따로 담는 게 '단일 책임' 규칙이에요.
- 나중에 새 장난감이 들어와도 원래 있던 상자들을 다 뒤엎지 않고 새 상자만 추가하면 되는 게 '개방-폐쇄' 규칙이죠.
- 이렇게 정해진 규칙대로 정리해두면, 나중에 내가 원하는 장난감을 1초 만에 찾을 수 있는 '똑똑한 정리왕'이 된답니다.