Apr 3, 2026

SOLID 가이드: 객체 지향 설계 원칙은 왜 필요할까

객체 지향을 공부하다 보면 SOLID라는 단어도 거의 반드시 만나게 됩니다. 처음에는 다섯 원칙을 외워야 하는 암기 과목처럼 느껴질 수 있지만, 실제로는 “코드가 왜 점점 수정하기 어려워지는가”를 줄이기 위한 실용적인 기준에 가깝습니다.

이 글에서는 아래 내용을 정리합니다.

SOLID가 무엇인지
각 원칙을 어떻게 이해하면 좋은지
왜 유지보수성과 변경 대응에 도움이 되는지

핵심은 SOLID는 외워서 끝내는 규칙이 아니라, 코드가 변경에 덜 흔들리도록 책임과 의존성을 다듬는 사고 기준이라는 점입니다.

SOLID란 무엇인가

SOLID는 객체 지향 설계에서 자주 언급되는 다섯 가지 원칙의 앞글자를 모은 것입니다.

Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

입문 단계에서는 이 이름 자체보다, “왜 이런 원칙이 나왔는가”를 이해하는 것이 더 중요합니다.

왜 이런 원칙이 필요할까

프로젝트가 커질수록 코드는 보통 아래 문제를 겪습니다.

하나의 클래스가 너무 많은 일을 함
수정할 때 연쇄적으로 많은 코드를 건드리게 됨
구체 구현에 강하게 묶여 테스트와 확장이 어려워짐

SOLID는 이런 문제를 줄이기 위한 방향성을 제공합니다.

각 원칙을 아주 짧게 보면

1. SRP

하나의 클래스나 모듈은 하나의 주된 책임에 집중하자는 원칙입니다.

2. OCP

기존 코드를 자꾸 뜯기보다, 확장으로 요구사항 변화에 대응하자는 방향입니다.

3. LSP

상속 관계라면 하위 타입이 상위 타입을 자연스럽게 대체할 수 있어야 한다는 원칙입니다.

4. ISP

너무 큰 인터페이스 하나보다, 필요한 역할에 맞는 작은 인터페이스가 더 낫다는 원칙입니다.

5. DIP

구체 구현보다 추상에 의존하자는 원칙입니다.

입문자는 어떻게 받아들이면 좋을까

다섯 원칙을 완벽히 외우는 것보다 아래 질문이 더 실용적입니다.

이 클래스는 책임이 너무 많지 않은가
변경이 생기면 너무 많은 파일을 건드리게 되지 않는가
테스트하기 어렵게 강하게 결합되어 있지 않은가

이 질문들에 답하는 과정이 곧 SOLID 감각을 키우는 과정입니다.

SOLID를 과하게 적용하면 어떤 문제가 있을까

좋은 원칙도 과하게 적용하면 오히려 복잡도가 늘 수 있습니다.

예를 들어:

지나치게 많은 추상화
너무 잘게 쪼갠 인터페이스
아직 필요하지 않은 확장 포인트

는 작은 프로젝트에서는 오히려 부담이 될 수 있습니다.

즉, SOLID는 무조건 많이 적용하는 것이 아니라, 변화 가능성과 복잡도 사이에서 적절히 쓰는 것이 중요합니다.

자주 하는 오해

1. SOLID를 지키면 무조건 좋은 설계다

원칙을 억지로 끼워 맞추면 오히려 과설계가 될 수 있습니다.

2. 인터페이스를 많이 만들수록 SOLID하다

추상화 수보다 실제 결합도와 책임 분리가 더 중요합니다.

3. SOLID는 객체 지향 언어에서만 의미가 있다

표현 방식은 다를 수 있지만, 책임 분리와 의존성 관리라는 문제는 더 넓게 적용됩니다.

FAQ

Q. 입문자는 다섯 원칙을 다 바로 익혀야 하나

SRP와 DIP부터 감을 잡고, 나머지는 사례를 보며 넓혀가는 편이 좋습니다.

Q. SOLID는 실무에서도 진짜 쓰이나

용어를 직접 말하지 않아도, 많은 실무 설계 판단이 결국 이 원칙들과 연결됩니다.

Q. 작은 프로젝트에도 필요할까

항상 풀세트로 필요한 것은 아니지만, 책임 분리와 결합도 관점은 작은 코드에도 도움이 됩니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.