객체 지향 프로그래밍 OOP 5원칙 SOLID편집자 확인

단일 책임 원칙은 하나의 클래스나 모듈이 변경되어야 하는 이유는 단 하나여야 한다는 원칙이다. 여기서 '책임'이란 변경의 이유를 의미한다. 이 원칙은 로버트 C. 마틴이 명확히 정의했으며, 응집도를 높이고 결합도를 낮추는 설계의 근간이 된다.

원칙의 핵심은 기능적 측면이 아닌 '변경의 축'에 초점을 맞추는 것이다. 예를 들어, 보고서를 생성하고 인쇄하는 클래스는 보고서의 내용이 변경될 때와 인쇄 형식이 변경될 때, 두 가지 이유로 수정될 수 있다. 이는 단일 책임 원칙을 위반한 사례로, 보고서 생성과 인쇄라는 두 책임을 분리해야 한다.

적용하면 각 모듈은 명확한 하나의 목적을 가지게 되며, 이는 시스템의 유지보수성과 재사용성을 크게 향상시킨다. 한 부분의 변경이 시스템의 다른 부분에 미치는 영향을 최소화할 수 있다.

한 클래스가 단일 책임 원칙을 위반하는 대표적인 사례는 하나의 클래스 내에 서로 다른 이유로 변경되는 여러 책임이 혼재하는 경우이다. 예를 들어, 사용자 정보를 관리하는 User 클래스가 데이터베이스에 사용자를 저장하는 로직과 사용자 정보를 포맷하여 출력하는 로직을 모두 포함하는 경우를 들 수 있다. 이 클래스는 사용자 도메인 모델의 변경, 데이터베이스 스키마 또는 접근 방식의 변경, 출력 형식(예: JSON, XML)의 변경이라는 서로 다른 이유로 수정될 수 있다. 이는 클래스가 사용자 엔티티 관리, 데이터 지속성, 표현 계층 처리라는 세 가지 책임을 지고 있음을 의미한다.

이러한 위반 사례를 개선하기 위해서는 각 책임을 명확히 분리하여 별도의 클래스로 구성해야 한다. 위 예시에서는 User 클래스는 순수한 도메인 데이터와 비즈니스 규칙만을 담당하도록 한다. 데이터 지속성 책임은 UserRepository 클래스에 위임하여 데이터베이스 저장 및 조회 로직을 처리하게 한다. 마지막으로 사용자 정보의 출력 형식 변환 책임은 UserPrinter 또는 UserFormatter와 같은 클래스에 위임한다. 이렇게 분리하면, 출력 형식을 HTML로 변경해야 할 경우 UserPrinter 클래스만 수정하면 되고, User나 UserRepository는 전혀 영향을 받지 않는다.

또 다른 흔한 위반 사례는 보고서를 생성하고 이메일로 전송하는 ReportService 클래스를 들 수 있다. 이 클래스는 보고서 생성 로직과 이메일 발송 로직이라는 두 가지 독립적인 책임을 함께 가지고 있다. 보고서 형식이 변경되거나, 이메일 대신 다른 채널(예: 파일 저장, 메시지 큐 전송)로 알림을 보내야 할 경우, 동일한 클래스를 수정해야 하므로 유지보수성이 떨어진다.

개선 방법은 각 책임을 분리하여 ReportGenerator 클래스와 EmailSender 클래스(또는 더 일반적인 NotificationService 인터페이스)를 만드는 것이다. ReportService는 이 두 의존성을 활용하여 조정(Orchestration)하는 역할만 수행한다. 이렇게 하면 이메일 발송 방식을 SMTP에서 API 호출로 변경하더라도 ReportGenerator에는 영향을 주지 않으며, 새로운 알림 수단을 추가해야 할 때도 기존 코드를 크게 변경하지 않고 확장할 수 있다. 이러한 분리는 단일 책임 원칙의 본질인 "변경의 이유"를 최소화하는 설계를 실현한다.

단일 책임 원칙은 하나의 클래스나 모듈이 변경되어야 하는 이유는 단 하나여야 한다는 원칙이다. 여기서 '책임'이란 변경의 이유를 의미한다. 이 원칙은 로버트 C. 마틴이 명확히 정의한 개념으로, 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다고 설명한다[4]. 이는 소프트웨어의 복잡성을 관리하고, 변경이 다른 부분에 미치는 영향을 최소화하는 데 목적이 있다.

개방-폐쇄 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 한다는 원칙이다. 즉, 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계해야 한다. 이 원칙을 준수하기 위해서는 추상화를 활용한다. 공통적인 부분을 인터페이스나 추상 클래스로 정의하고, 변화하는 부분은 이를 구현한 구체 클래스로 분리한다. 이를 통해 새로운 요구사항이 발생했을 때, 기존 코드를 수정하는 대신 새로운 구현체를 추가함으로써 시스템을 확장할 수 있다.

리스코프 치환 원칙은 상속 관계에 있는 객체들 사이의 호환성을 규정한다. 이 원칙에 따르면, 프로그램에서 부모 클래스의 객체를 사용하는 모든 곳에서, 그 자식 클래스의 객체로 치환해도 프로그램의 정확성이 깨지지 않아야 한다. 이는 단순히 구문적 호환성을 넘어, 의미론적 호환성을 요구한다. 자식 클래스는 부모 클래스가 정의한 계약을 반드시 지켜야 하며, 사전 조건을 더 강화하거나 사후 조건을 더 약화시켜서는 안 된다. 이 원칙은 올바른 상속 관계를 설계하는 지침을 제공한다.

개방-폐쇄 원칙은 소프트웨어 모듈이 확장에는 열려 있고(Open), 수정에는 닫혀 있어야(Closed) 한다는 설계 원칙이다. 이 원칙을 준수하면 새로운 기능을 추가할 때 기존 코드를 변경하지 않고도 시스템을 확장할 수 있다. 이를 통해 유지보수성이 향상되고, 기존 기능에 대한 회귀 테스트 부담을 줄일 수 있다.

확장성을 위한 핵심 메커니즘은 추상화이다. 공통적인 동작을 인터페이스나 추상 클래스로 정의하고, 구체적인 구현은 이를 상속하거나 구현하는 별도의 클래스에서 담당하게 한다. 새로운 기능이 필요할 때는 기존 인터페이스를 준수하는 새로운 클래스를 추가하기만 하면 된다. 예를 들어, 다양한 결제 수단을 지원하는 시스템에서는 PaymentProcessor 인터페이스를 정의하고, CreditCardProcessor, PayPalProcessor 등의 구체 클래스를 추가하여 확장할 수 있다.

유연한 설계를 위해서는 변경될 가능성이 있는 부분을 식별하고, 그 부분을 추상화 뒤로 감추는 것이 중요하다. 전략 패턴, 템플릿 메서드 패턴, 팩토리 메서드 패턴과 같은 디자인 패턴은 개방-폐쇄 원칙을 구현하는 데 자주 활용된다. 이러한 패턴들은 변하는 부분과 변하지 않는 부분을 분리하여, 변하는 부분만 독립적으로 확장할 수 있는 구조를 제공한다.

이 원칙을 지나치게 적용하면 불필요한 추상화 계층이 늘어나 복잡도가 증가할 수 있다. 따라서 실제 변경이 예상되는 영역에 대해서만 원칙을 적용하고, 변경 가능성이 낮은 부분은 단순한 설계를 유지하는 것이 현명하다.

리스코프 치환 원칙의 핵심은 상위 클래스의 객체를 하위 클래스의 객체로 치환해도 프로그램의 정확성이 깨지지 않아야 한다는 것이다. 이는 단순히 상속의 문법적 호환성을 넘어, 하위 타입이 상위 타입의 '행위적 계약'을 완전히 준수해야 함을 의미한다. 예를 들어, 사각형 클래스를 상속받은 정사각형 클래스는 높이와 너비를 독립적으로 설정할 수 있는 사각형의 기본 기대 행위를 변경하게 되어, 치환 시 예상치 못한 결과를 초래할 수 있다[7].

행위 호환성을 보장하기 위해서는 하위 클래스가 상위 클래스의 메서드를 다음 규칙에 따라 오버라이드해야 한다. 하위 클래스의 메서드는 상위 클래스 메서드보다 더 강한 사전 조건을 요구해서는 안 되며, 더 약한 사후 조건을 보장해서는 안 된다. 또한, 상위 클래스가 던지는 예외의 종류를 추가하거나 변경해서는 안 된다. 이 원칙을 위반하면, 상위 타입에 의존하여 작성된 코드는 하위 타입으로 치환되었을 때 논리적 오류나 런타임 예외를 맞닥뜨리게 된다.

따라서 리스코프 치환 원칙은 'is-a' 관계의 의미를 문법적 상속이 아닌, 대체 가능한 행위로 재정의하게 한다. 이 원칙을 준수함으로써 다형성을 안전하게 활용할 수 있고, 클라이언트 코드가 구체적인 하위 타입이 아닌 추상적인 상위 타입에 의존할 수 있는 기반이 마련된다.

계약에 의한 설계(Design by Contract, DbC)는 소프트웨어 구성 요소 간의 상호작용을 명확한 계약 조건으로 정의하는 방법론이다. 이 개념은 버트란드 메이어(Bertrand Meyer)가 에펠(Eiffel) 프로그래밍 언어를 설계하면서 제안했다. 이 접근법은 리스코프 치환 원칙을 준수하는 상속 관계를 설계하는 데 중요한 도구로 활용된다.

계약은 주로 세 가지 요소로 구성된다. 첫째, 사전 조건(Precondition)은 메서드가 호출되기 전에 클라이언트가 반드시 만족시켜야 하는 조건이다. 예를 들어, 계좌.출금(금액) 메서드의 사전 조건은 금액 > 0 그리고 잔고 >= 금액이 될 수 있다. 둘째, 사후 조건(Postcondition)은 메서드 실행이 성공적으로 종료된 후 객체가 보장해야 하는 상태나 결과이다. 위 예시의 사후 조건은 새로운 잔고 == 이전 잔고 - 금액이 될 수 있다. 셋째, 불변식(Invariant)은 객체의 생명주기 동안 항상 유지되어야 하는 조건으로, 주로 클래스 수준에서 정의된다. 예를 들어, 계좌 클래스의 불변식은 잔고 >= 0이 될 수 있다.

리스코프 치환 원칙과의 관계에서, 계약에 의한 설계는 파생 클래스가 기본 클래스의 계약을 약화시키지 않아야 함을 명시한다. 구체적으로, 파생 클래스의 메서드는 기본 클래스 메서드의 사전 조건을 더 강하게(즉, 더 제한적으로) 만들 수 없으며, 사후 조건을 더 약하게(즉, 덜 보장적으로) 만들 수 없다. 또한 기본 클래스의 불변식은 파생 클래스에서도 반드시 유지되어야 한다. 이 규칙을 지키면 클라이언트는 기본 클래스에 대해 세운 가정을 파생 클래스에 대해서도 안전하게 유지할 수 있으며, 이는 곧 치환 가능성을 보장한다.

클라이언트 중심 인터페이스 설계는 인터페이스 분리 원칙의 핵심 철학으로, 인터페이스를 사용하는 클라이언트의 관점에서 설계해야 함을 강조한다. 이는 하나의 거대한 인터페이스보다는, 각 클라이언트가 실제로 필요로 하는 메서드들만으로 구성된 세분화된 인터페이스를 정의하는 접근법이다.

설계의 출발점은 인터페이스 자체가 아니라, 그 인터페이스를 호출하는 구체적인 클라이언트 코드이다. 예를 들어, 프린터, 팩스, 스캐너 기능이 모두 포함된 MultifunctionDevice 인터페이스가 있다고 가정하자. 이 인터페이스를 단순히 인쇄만 필요로 하는 PrintClient 클래스가 사용한다면, PrintClient는 사용하지도 않는 fax(), scan() 메서드에 대한 의존성을 강제로 가지게 된다. 클라이언트 중심 설계는 Printer, Fax, Scanner라는 세 개의 독립된 인터페이스를 만들고, PrintClient는 오직 Printer 인터페이스에만 의존하도록 함으로써 불필요한 결합을 제거한다.

이러한 설계 방식은 시스템의 결합도를 낮추고 유지보수성을 높인다. 클라이언트는 자신이 이해하고 사용하는 메서드에만 의존하므로, 인터페이스의 불필요한 변경으로부터 안전해진다. 또한, 새로운 클라이언트가 등장할 때 기존의 거대한 인터페이스를 수정하기보다는, 필요한 인터페이스들을 조합(Composition)하여 사용할 수 있어 시스템의 확장성이 향상된다. 결과적으로, 인터페이스는 이를 구현하는 모듈보다는 이를 사용하는 클라이언트를 위해 분리되어 정의되어야 한다.

팻 인터페이스는 하나의 인터페이스가 지나치게 많은 메서드를 선언하여, 이를 구현하는 클래스가 사용하지도 않는 메서드에 대한 구현 책임을 강제하는 상황을 가리킨다. 이는 인터페이스 분리 원칙의 정반대에 해당하는 안티패턴이다.

팻 인터페이스의 가장 큰 문제점은 클라이언트 간의 불필요한 결합을 초래한다는 것이다. 서로 다른 클라이언트가 하나의 거대한 인터페이스를 공유할 경우, 한 클라이언트를 위한 변경이 다른 클라이언트에 영향을 미칠 수 있다. 예를 들어, 프린터, 스캐너, 팩스 기능이 모두 포함된 MultiFunctionDevice 인터페이스가 있다고 가정하자. 단순히 인쇄만 필요한 PrintClient 클래스는 스캔이나 팩스 관련 메서드의 구현 변경에 영향을 받을 수 있으며, 이는 명백한 결합도 증가로 이어진다.

또 다른 문제는 구현체의 복잡성과 불안정성을 높인다는 점이다. 인터페이스를 구현하는 구체 클래스는 사용하지 않는 메서드에 대해 의미 없는 구현(예: 빈 메서드나 예외 발생)을 제공해야 하거나, 인터페이스의 확장으로 인해 계속해서 코드를 수정해야 할 수 있다. 이는 단일 책임 원칙을 위반하고, 코드의 유지보수성을 현저히 떨어뜨린다. 이러한 문제를 해결하기 위해서는 클라이언트의 역할에 따라 인터페이스를 세분화하여, 각 클라이언트는 오직 자신이 필요로 하는 메서드만을 포함한 인터페이스에 의존하도록 설계해야 한다.

의존관계 역전 원칙의 핵심은 구체적인 모듈이 아닌 추상적인 것에 의존하도록 설계하는 것이다. 이는 상위 수준의 정책을 담당하는 모듈이 하위 수준의 세부 구현 사항에 직접 의존하는 전통적인 의존 관계를 역전시킨다. 상위 모듈은 자신의 책임을 수행하는 데 필요한 인터페이스나 추상 클래스를 정의하고, 하위 모듈은 그 추상화를 구체적으로 구현함으로써 의존 방향이 추상화를 향하게 된다.

이 원칙을 적용하면 시스템의 결합도가 낮아지고 변경에 대한 유연성이 크게 향상된다. 예를 들어, 데이터 저장소로 MySQL을 직접 사용하는 코드는 데이터베이스를 PostgreSQL로 변경할 때 상위 비즈니스 로직까지 수정해야 할 수 있다. 그러나 저장소 패턴과 같은 추상화된 인터페이스에 의존하도록 설계하면, 하위 구현체를 교체하더라도 상위 로직은 전혀 영향을 받지 않는다.

이러한 추상화에의 의존은 의존성 주입 패턴을 통해 실현되는 경우가 많다. 상위 모듈은 생성자나 메서드를 통해 필요한 추상화 타입의 인스턴스를 외부에서 전달받는다. 이로 인해 상위 모듈은 어떤 구체적인 구현체가 사용되는지 전혀 알 필요가 없어지며, 단지 정의된 계약(인터페이스)에만 의존하게 된다. 결과적으로 시스템은 더욱 테스트 가능성이 높아지고, 구성 요소의 재사용성도 증가한다.

의존관계 역전 원칙은 고수준 모듈이 저수준 모듈에 의존하지 않고, 둘 모두 추상화에 의존하도록 요구한다. 이 원칙을 실현하는 구체적인 메커니즘 중 하나가 의존성 주입이다. 의존성 주입은 객체가 필요로 하는 의존성을 외부에서 생성하여 제공하는 디자인 패턴으로, DIP를 준수하는 시스템을 구성하는 핵심 기술이다.

의존성 주입은 일반적으로 생성자, 메서드, 또는 프로퍼티를 통해 이루어진다. 이를 통해 클래스는 구체적인 의존 객체를 직접 생성(new 키워드 사용)하지 않고, 인터페이스나 추상 클래스 형태로 선언된 의존성만을 가진다. 실제 구현체는 애플리케이션의 조립 단계(예: 메인 함수 또는 DI 컨테이너)에서 결정되고 주입된다. 이는 결합도를 낮추고 테스트 용이성을 크게 향상시킨다. 예를 들어, 데이터베이스 접근 로직에 의존하는 서비스 클래스를 테스트할 때, 실제 데이터베이스 대신 가짜(Mock 객체) 구현체를 주입할 수 있게 된다.

DIP와 의존성 주입의 관계는 원칙과 실천법의 관계라고 볼 수 있다. DIP는 "추상화에 의존하라"는 지침을 제시하는 반면, 의존성 주입은 그 지침을 코드 수준에서 구현하기 위한 구체적인 방법을 제공한다. 따라서 의존성 주입을 적용한다고 해서 자동으로 DIP가 준수되는 것은 아니다. 의존성 주입의 대상이 여전히 구체 클래스라면 DIP는 위반된 상태이다. 진정한 DIP 준수를 위해서는 의존성 주입과 함께 인터페이스 또는 추상 클래스를 통한 추상화 설계가 병행되어야 한다.

SOLID 원칙을 실무에 적용할 때는 맹목적인 준수보다는 프로젝트의 맥락과 비용을 고려해야 한다. 원칙은 코드의 유지보수성과 확장성을 높이는 도구이지만, 과도한 적용은 불필요한 복잡성을 초래할 수 있다. 특히 소규모 프로젝트나 프로토타입, 변경 가능성이 매우 낮은 모듈에서는 단순함이 더 중요한 가치가 될 수 있다. 따라서 개발자는 각 원칙이 해결하려는 문제가 현재 상황에 실제로 존재하는지, 그리고 해결 비용이 기대 이익을 상회하지 않는지 판단해야 한다.

적용 과정에서는 원칙 간의 상충 관계를 인지하는 것이 중요하다. 예를 들어, 단일 책임 원칙을 지나치게 적용하여 클래스를 과도하게 분리하면, 오히려 의존관계 역전 원칙에 따라 관리해야 할 의존성이 폭발적으로 증가할 수 있다. 이는 인터페이스 분리 원칙을 적용하여 인터페이스를 세분화하는 과정에서도 발생할 수 있는 문제다. 설계는 항상 트레이드오프의 연속이며, 특정 원칙을 극단적으로 추구하면 다른 품질 속성(예: 성능, 가독성)이 저하될 수 있다.

초기 설계 단계에서 모든 유연성을 예측하여 적용하는 것은 불가능하며, 종종 과잉 설계로 이어진다. 리팩토링은 SOLID 원칙을 점진적으로 적용하는 핵심 메커니즘이다. 먼저 동작하는 단순한 코드를 작성한 후, 변경 요구사항이 발생하거나 코드의 냄새가 감지될 때 해당 문제를 해결할 수 있는 적절한 원칙을 적용하여 구조를 개선하는 접근법이 효과적이다. 이는 애자일 방법론의 점진적 설계와도 잘 부합한다.

마지막으로, 원칙의 정신을 이해하는 것이 형식적인 준수보다 중요하다. 개방-폐쇄 원칙을 준수한다고 해서 모든 클래스를 추상화할 필요는 없다. 변경될 가능성이 높은 부분을 식별하고 그 부분을 추상화에 의존하도록 설계하는 것이 본질이다. 팀 내에서 SOLID 원칙에 대한 공통된 이해와 합의된 적용 수준을 정립하는 것도 장기적인 프로젝트 건강성을 위해 필수적이다.

SOLID 원칙은 설계의 품질을 높이는 지침이지만, 맹목적 적용은 오히려 복잡성과 비용을 증가시킬 수 있다. 첫 번째 주요 트레이드오프는 복잡성과 간결성 사이의 균형이다. 원칙을 지키려면 추상화 계층이 늘어나고 클래스 수가 증가하여 초기 설계 및 이해 비용이 커진다. 작고 단순한 기능을 가진 프로토타입이나 일회성 스크립트에 과도하게 적용하는 것은 과잉 설계로 이어진다. 두 번째는 유연성과 성능 간의 고려사항이다. 예를 들어, 의존관계 역전 원칙을 적용하면 런타임에 객체를 주입할 수 있지만, 이는 간접 참조를 증가시켜 미미하나마 성능 오버헤드를 발생시킬 수 있다. 대부분의 비즈니스 애플리케이션에서는 이러한 오버헤드가 무시할 수 있지만, 초고성능이 요구되는 시스템에서는 중요한 요소가 될 수 있다.

흔한 오용 사례로는 원칙을 목적 자체로 삼는 경우를 들 수 있다. 단일 책임 원칙을 '하나의 클래스는 하나의 메서드만 가져야 한다'는 식으로 극단적으로 해석하면, 오히려 관련된 책임들이 분산되어 결합도가 낮은 대신 응집력이 없는 설계가 나올 수 있다. 인터페이스 분리 원칙을 지나치게 적용하여 변화 가능성이 희박한 영역까지 미리 인터페이스를 분리하면, 관리해야 할 인터페이스가 폭증하는 결과를 초래한다. 또한, 리스코프 치환 원칙을 문법적 상속 관계만으로 판단하는 실수가 있다. 자식 클래스가 부모 클래스의 모든 메서드를 구현하더라도, 의미론적 계약(예: 메서드 전제조건을 강화하거나 후조건을 약화시키는 행위)을 위반하면 이 원칙을 위반한 것이 된다.

결국 SOLID 원칙은 변경에 유연하게 대응해야 하는 코드, 즉 유지보수 기간이 길고 요구사항 변화가 예상되는 복잡한 도메인에 가장 큰 가치를 발휘한다. 반면, 변경 가능성이 매우 낮거나 단순한 로직에는 적용을 최소화하거나 지연시키는 것이 합리적이다. 원칙 적용의 적정선은 프로젝트의 규모, 예상 수명, 팀의 역량 등 맥락에 따라 달라지며, 원칙 뒤에 숨은 의도(변경의 격리, 결합도 낮추기, 의사소통 용이성)를 이해하고 상황에 맞게 판단하는 것이 중요하다.