객체 지향 프로그래밍(OOP) 5대 원칙(SOLID) (r1)

단일 책임 원칙은 하나의 클래스나 모듈이 변경되어야 하는 이유는 단 하나여야 한다는 원칙이다. 이는 "책임"을 "변경의 이유"로 정의하며, 하나의 클래스가 여러 가지 이유로 수정될 가능성을 가진다면 그 클래스는 여러 책임을 지고 있다고 판단한다. 이 원칙의 목적은 결합도를 낮추고 응집도를 높여 코드의 유지보수성과 재사용성을 향상시키는 데 있다.

개방-폐쇄 원칙은 소프트웨어 구성 요소는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 한다는 원칙이다. 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계해야 함을 의미한다. 이는 주로 추상화와 다형성을 통해 달성되며, 변경이 필요한 부분을 인터페이스나 추상 클래스로 격리함으로써 구현된다.

리스코프 치환 원칙은 상속 관계에 있는 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다는 원칙이다. 즉, 프로그램의 정확성을 깨뜨리지 않으면서 부모 클래스의 객체를 자식 클래스의 객체로 치환할 수 있어야 한다. 이 원칙은 상속이 "is-a" 관계를 올바르게 모델링하도록 유도하며, 자식 클래스가 부모 클래스의 계약을 반드시 지켜야 함을 강조한다.

인터페이스 분리 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하도록 강요받아서는 안 된다는 원칙이다. 하나의 범용적인 인터페이스보다는, 특정 클라이언트를 위한 여러 개의 구체적인 인터페이스가 더 낫다. 이 원칙은 인터페이스를 가능한 한 작고 집중적인 단위로 분리함으로써 시스템의 결합도를 낮추고 불필요한 의존성을 제거하는 데 목적이 있다.

의존관계 역전 원칙은 고수준 모듈이 저수준 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 한다는 원칙이다. 또한, 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항이 추상화에 의존해야 한다. 이 원칙은 전통적인 의존성 방향을 역전시켜, 고수준 모듈의 정책이 저수준 모듈의 구현 세부사항으로부터 독립적이도록 보장한다.

단일 책임 원칙을 위반하는 전형적인 사례는 하나의 클래스가 여러 가지 이유로 변경될 수 있는 경우다. 예를 들어, 사용자 정보를 관리하는 User 클래스가 데이터베이스 연결, 사용자 데이터 검증, 그리고 사용자 정보를 파일로 저장하는 기능을 모두 담당한다면, 이 클래스는 데이터 모델링, 영속성 로직, 비즈니스 규칙이라는 서로 다른 세 가지 책임을 지고 있는 것이다. 데이터베이스 스키마 변경, 검증 규칙 수정, 파일 저장 형식 변경 중 어떤 이유로든 이 클래스는 수정될 수 있으며, 이는 원칙 위반을 의미한다.

이를 준수하는 설계는 각 책임을 별도의 클래스로 분리하는 것이다. User 클래스는 순수한 데이터 구조나 도메인 모델의 책임만 지고, UserRepository 클래스는 데이터베이스 저장 및 조회를, UserValidator 클래스는 검증 로직을, UserFileExporter 클래스는 파일 출력을 담당하도록 구성할 수 있다. 이렇게 하면 한 책임의 변경이 다른 책임을 가진 클래스에 영향을 미치지 않으며, 코드의 응집도는 높아지고 결합도는 낮아진다.

위반 사례에서 User 클래스는 너무 많은 의존성을 가지게 되어 단위 테스트가 어려워지고, 기능 하나를 수정할 때 다른 무관한 기능까지 재컴파일 및 재배포해야 할 수 있다. 반면, 책임이 분리된 설계는 각 모듈이 명확한 역할을 가지므로 이해하기 쉽고, 유지보수성과 재사용성이 향상된다. 이 원칙의 핵심은 '변경의 축'을 기준으로 코드를 구성하는 것이다[1].

단일 책임 원칙은 하나의 클래스나 모듈은 변경할 이유가 단 하나만 가져야 한다는 원칙이다. 이 원칙에서 '책임'은 '변경의 이유'로 해석된다. 즉, 하나의 클래스는 하나의 기능 또는 하나의 액터(사용자)에 대한 일만 담당해야 한다. 여러 책임이 하나의 클래스에 결합되면, 한 책임의 변경이 다른 책임과 무관한 코드에 영향을 미쳐 시스템이 취약해진다. 이 원칙의 궁극적 목표는 결합도를 낮추고 응집도를 높여 유지보수성을 향상시키는 것이다.

개방-폐쇄 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하며, 수정에는 닫혀 있어야 한다는 원칙이다. 기존 코드를 변경하지 않고도(닫혀 있음) 새로운 기능을 추가(열려 있음)할 수 있어야 한다. 이 원칙은 주로 추상화와 다형성을 통해 구현된다. 공통적인 부분을 추상 클래스나 인터페이스로 정의하고, 구체적인 동작의 변화는 이를 상속하거나 구현하는 새로운 클래스를 만들어 처리한다. 이를 통해 기존 모듈의 안정성을 유지하면서 시스템을 확장할 수 있다.

리스코프 치환 원칙은 상속 관계에 있는 클래스들 사이의 계약을 정의한다. 이 원칙에 따르면, 프로그램에서 부모 클래스의 객체를 사용하는 모든 곳에서 그 객체를 자식 클래스의 객체로 치환해도 프로그램의 정확성이 깨지지 않아야 한다. 즉, 자식 클래스는 부모 클래스가 제공하는 행위(메서드)의 사전 조건을 더 강화하거나, 사후 조건을 더 약화시켜서는 안 된다. 상속은 'is-a' 관계가 아니라 '행위적 대체 가능성'에 기반해야 한다. 이 원칙을 위반하면 예상치 못한 오류가 발생할 수 있다.

인터페이스 분리 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하도록 강요받아서는 안 된다는 원칙이다. 하나의 범용적인 인터페이스보다는, 클라이언트의 필요에 맞게 구체적이고 작은 인터페이스 여러 개로 분리하는 것이 바람직하다. '굵은' 인터페이스는 불필요한 의존성을 생성하여, 인터페이스의 일부만 사용하는 클라이언트도 다른 부분의 변경 영향을 받게 만든다. 이 원칙은 인터페이스를 기능별로 세분화함으로써 시스템의 결합도를 낮추고 유연성을 높인다.

의존관계 역전 원칙은 다음과 같은 두 가지 선언으로 구성된다. 첫째, 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다. 둘째, 추상화는 구체적인 사항에 의존해서는 안 되며, 구체적인 사항이 추상화에 의존해야 한다. 여기서 '고수준 모듈'은 정책이나 비즈니스 로직과 같은 추상적인 개념을, '저수준 모듈'은 데이터베이스 접근이나 외부 API 호출과 같은 구체적인 구현을 의미한다. 이 원칙은 의존성 주입과 같은 기법을 통해 구체화되어, 모듈 간의 직접적인 결합을 끊고 테스트 용이성과 확장성을 제공한다.

개방-폐쇄 원칙의 핵심은 추상화를 통해 달성된다. 구체적인 구현에 의존하지 않고, 인터페이스나 추상 클래스 같은 추상적인 계층에 의존함으로써 모듈의 확장을 가능하게 한다. 이는 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있는 구조를 만드는 것을 의미한다.

확장성을 위한 일반적인 방법은 다형성을 활용하는 것이다. 예를 들어, 다양한 결제 방식을 지원하는 시스템에서 PaymentProcessor라는 인터페이스를 정의하고, CreditCardProcessor, PayPalProcessor 등 구체적인 클래스가 이를 구현하도록 설계한다. 새로운 결제 방식(예: 암호화폐 결제)이 필요할 때는 기존의 PaymentProcessor 인터펇스를 구현하는 CryptoProcessor 클래스만 새로 추가하면 된다. 기존의 결제 처리 로직은 변경되지 않으며, 새로운 클래스를 시스템에 주입하기만 하면 기능이 확장된다.

이 원칙을 적용하면 시스템의 유지보수성과 재사용성이 크게 향상된다. 모듈 간의 결합도가 낮아져, 한 부분의 변경이 다른 부분으로 전파되는 것을 최소화할 수 있다. 그러나 과도한 추상화는 불필요한 복잡성을 초래할 수 있으므로, 실제 변경 가능성이 예상되는 영역에 집중하여 적용하는 것이 중요하다[3].

단일 책임 원칙은 하나의 클래스나 모듈은 변경할 이유가 단 하나만 가져야 한다는 원칙이다. 이 원칙의 핵심은 책임을 명확히 분리하여 결합도를 낮추고 응집도를 높이는 데 있다. 여기서 '책임'이란 변경의 이유를 의미하며, 하나의 모듈이 여러 이유로 변경될 가능성을 가진다면 그 모듈은 여러 책임을 지고 있다고 판단한다.

개방-폐쇄 원칙은 소프트웨어 구성 요소는 확장에는 열려 있어야 하며, 수정에는 닫혀 있어야 한다는 원칙이다. 이는 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계해야 함을 의미한다. 주로 추상화와 다형성을 활용하여 구현하며, 변경이 필요한 부분을 인터페이스나 추상 클래스로 격리함으로써 달성한다.

리스코프 치환 원칙은 상속 관계에 있는 객체들 사이의 대체 가능성을 규정한다. 이 원칙에 따르면, 자식 클래스는 언제나 그 부모 클래스를 대체할 수 있어야 한다. 즉, 부모 클래스가 사용되는 모든 곳에서 자식 클래스를 사용해도 프로그램의 정확성이 깨지지 않아야 한다. 이는 상속이 'is-a' 관계가 아닌 단순한 코드 재사용을 위해 사용될 때 위반되기 쉽다.

인터페이스 분리 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 하나의 범용적인 인터페이스보다는, 특정 클라이언트의 요구에 맞춘 여러 개의 세분화된 인터페이스를 설계하는 것이 바람직하다. 이는 불필요한 의존성을 제거하여 시스템의 복잡성을 줄이고, 인터페이스 변경의 영향을 최소화하는 데 목적이 있다.

의존관계 역전 원칙은 고수준 모듈이 저수준 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 한다는 원칙이다. 또한, 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항이 추상화에 의존해야 한다. 이 원칙은 의존성의 방향을 전통적인 상위-하위 관계에서 역전시켜, 시스템의 유연성과 재사용성을 크게 향상시킨다.

리스코프 치환 원칙에서 말하는 '계약'은 상속 관계에 있는 부모 클래스와 자식 클래스 사이에 암묵적으로 존재하는 규칙의 집합이다. 이 계약은 주로 클래스의 공개 인터페이스를 통해 정의되며, 사전 조건, 사후 조건, 불변식으로 구성된다[5].

자식 클래스는 부모 클래스와의 이 계약을 반드시 준수해야 한다. 구체적으로, 자식 클래스는 부모 클래스의 메서드가 기대하는 사전 조건(입력 조건)을 더 강화해서는 안 되며, 보장하는 사후 조건(출력 결과나 상태)과 불변식(객체가 항상 유지해야 하는 조건)을 약화시켜서도 안 된다. 예를 들어, 부모 클래스의 calculateArea() 메서드가 음수가 아닌 정수를 반환한다는 사후 조건을 가진다면, 자식 클래스에서 이를 오버라이드하여 음수를 반환하는 것은 계약 위반이다.

이 계약 위반은 직관에 반하는 동작을 초래한다. Rectangle(직사각형) 클래스를 상속받은 Square(정사각형) 클래스가 setWidth와 setHeight 메서드를 독립적으로 변경할 수 없다는 제약을 추가하면, 이는 사전 조건을 강화한 것이 되어 클라이언트 코드의 기대를 저버린다. 클라이언트는 부모 타입인 Rectangle을 사용할 때 너비와 높이를 독립적으로 설정할 수 있다고 믿고 코드를 작성했기 때문이다. 이러한 위반은 시스템의 신뢰성을 해치고, 다형성의 이점을 무효화한다.

단일 책임 원칙은 하나의 클래스나 모듈은 변경할 이유가 단 하나만 가져야 한다는 원칙이다. 여기서 '책임'은 변경의 이유를 의미한다. 이 원칙의 핵심은 기능적 응집성을 높이고, 서로 다른 이유로 발생하는 변경이 하나의 구성 요소에 영향을 미치지 않도록 분리하는 데 있다.

개방-폐쇄 원칙은 소프트웨어 구성 요소(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙이다. 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계해야 함을 의미한다. 이는 주로 추상화와 다형성을 통해 달성된다.

리스코프 치환 원칙은 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 원칙이다. 간단히 말해, 자식 클래스는 부모 클래스가 사용되는 모든 곳에서 대체 가능해야 한다. 이 원칙은 올바른 상속 관계를 정의하고, 하위 클래스가 상위 클래스의 '계약'을 위반하지 않도록 보장한다.

인터페이스 분리 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 하나의 범용적인 인터페이스보다는, 특정 클라이언트를 위한 여러 개의 구체적인 인터페이스가 더 낫다. 이는 불필요한 의존성을 제거하여 시스템을 더욱 견고하고 유연하게 만든다.

의존관계 역전 원칙은 고수준 모듈이 저수준 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 한다는 원칙이다. 또한, 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항이 추상화에 의존해야 한다. 이 원칙은 의존성 주입과 함께 모듈 간의 결합도를 낮추는 핵심 메커니즘이다.

인터페이스 분리 원칙을 위반하는 굵은 인터페이스는 클라이언트가 필요하지 않은 메서드에 대한 의존성을 강제하게 만든다. 이는 시스템에 불필요한 결합을 초래하고, 변경의 파급 효과를 증가시키며, 유지보수성을 저하시킨다.

주요 문제점은 다음과 같다. 첫째, 사용하지 않는 메서드의 구현을 강제함으로써 인터페이스 오염이 발생한다. 클라이언트는 자신의 관심사와 무관한 메서드에 대해 더미 구현(예: 예외를 던지거나 null을 반환)을 제공해야 할 수 있다. 둘째, 인터페이스가 변경될 때, 그 변경이 해당 메서드를 실제로 사용하지 않는 모든 클라이언트에게도 영향을 미친다. 이는 변경이 국소적으로 머물러야 하는 원칙을 깨뜨린다. 셋째, 인터페이스가 지나치게 복잡해져 이해하기 어렵고, 잘못된 사용을 유발할 가능성이 높아진다.

이러한 문제를 해결하기 위해 인터페이스 분리 원칙은 하나의 범용적인 인터페이스보다는, 클라이언트의 특정 요구에 초점을 맞춘 여러 개의 세분화된 인터페이스를 사용할 것을 권장한다. 각 인터페이스는 응집된 하나의 역할을 정의하며, 클라이언트는 정확히 자신이 필요한 기능에만 의존하게 된다. 이는 결합도를 낮추고, 모듈성을 높이며, 시스템을 더 유연하고 안정적으로 만든다.

단일 책임 원칙은 하나의 클래스나 모듈은 변경할 이유가 단 하나만 가져야 한다는 원칙이다. 여기서 '책임'이란 변경의 이유를 의미한다. 이 원칙의 핵심은 기능이 아닌, 변경의 축에 초점을 맞추어 설계하는 것이다. 하나의 클래스가 여러 변경 이유를 가지면, 한 가지 이유로 인한 수정이 다른 책임과 관련된 코드에 영향을 줄 수 있어 시스템의 취약성이 증가한다.

개방-폐쇄 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하며, 수정에는 닫혀 있어야 한다는 원칙이다. 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계해야 함을 의미한다. 이는 주로 추상화와 다형성을 통해 달성된다. 예를 들어, 새로운 기능이 필요할 때 기존 코드를 수정하는 대신, 새로운 클래스를 만들어 인터페이스나 추상 클래스를 통해 시스템에 통합한다.

리스코프 치환 원칙은 상속 관계에 있는 하위 타입의 객체는 상위 타입의 객체를 대체할 수 있어야 한다는 원칙이다. 즉, 프로그램의 정확성을 깨뜨리지 않으면서 부모 클래스의 객체를 그 자식 클래스의 객체로 치환할 수 있어야 한다. 이 원칙은 하위 클래스가 상위 클래스의 행동 규약(계약)을 반드시 지켜야 함을 강조한다. 하위 클래스가 상위 클래스의 메서드 시그니처는 유지하지만, 의도된 동작을 변경하면 이 원칙을 위반하게 된다.

인터페이스 분리 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하도록 강요받아서는 안 된다는 원칙이다. 하나의 범용적인 인터페이스보다는, 클라이언트의 특정 요구에 맞춰 여러 개의 구체적이고 작은 인터페이스로 분리하는 것이 바람직하다. 이는 인터페이스를 최소한의 기능 단위로 설계하도록 유도하여, 시스템의 결합도를 낮추고 불필요한 의존성을 제거한다.

의존관계 역전 원칙은 고수준 모듈이 저수준 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 한다는 원칙이다. 또한, 추상화는 구체적인 사항에 의존해서는 안 되며, 구체적인 사항이 추상화에 의존해야 한다. 이 원칙은 전통적인 의존성 방향(고수준 → 저수준)을 역전시켜, 추상화된 인터페이스나 추상 클래스를 사이에 둠으로써 모듈 간의 결합도를 낮추고 유연성을 높인다.

의존관계 역전 원칙(DIP)에서 고수준 모듈은 핵심 비즈니스 로직이나 정책과 같은 추상적인 개념을 다루는 모듈이다. 예를 들어, 결제 처리 시스템에서 '결제를 실행한다'는 추상적인 작업이 고수준 모듈의 책임이다. 반면, 저수준 모듈은 이러한 고수준의 정책을 실행하기 위한 구체적인 세부 사항을 구현한다. 신용카드 결제, 페이팔 결제, 특정 데이터베이스에 정보를 저장하는 것 등이 저수준 모듈의 예시이다.

전통적인 설계에서는 고수준 모듈이 저수준 모듈에 직접 의존하는 형태를 띤다. 이는 시스템의 변경을 어렵게 만든다. 결제 방식을 신용카드에서 암호화폐로 변경하려면, 고수준의 결제 로직 자체를 수정해야 할 수 있다. 의존관계 역전 원칙은 이 관계를 역전시켜, 두 모듈 모두 추상화(인터페이스나 추상 클래스)에 의존하도록 만든다.

이 원칙을 적용한 구조는 다음과 같은 특징을 가진다.

이렇게 구성하면 고수준 모듈은 '결제 처리기'라는 추상화에만 의존하고, 실제로 어떤 결제 수단(신용카드, 모바일 결제 등)이 사용되는지는 알 필요가 없다. 새로운 결제 수단이 추가되더라도 고수준 모듈은 변경되지 않으며, 단지 새로운 저수준 모듈을 만들어 추상화 계약을 구현하기만 하면 된다. 이는 시스템을 확장에는 열려 있고(Open), 기존 코드의 수정에는 닫혀 있게(Closed) 만드는 개방-폐쇄 원칙(OCP)을 실현하는 핵심 메커니즘이 된다.

SOLID 원칙을 실무에 적용할 때는 맥락과 비용을 고려해야 한다. 모든 원칙을 완벽하게 준수하려는 시도는 오히려 불필요한 복잡성과 과도한 설계를 초래할 수 있다. 프로젝트의 규모, 변경 빈도, 팀의 숙련도, 개발 일정 등을 종합적으로 판단하여 적절한 수준의 적용이 필요하다. 작고 변경이 거의 없는 유틸리티성 코드보다는 핵심 비즈니스 로직이 집중된 도메인 모델에 우선적으로 적용하는 것이 효과적이다.

초기에는 단순한 설계로 시작하여, 변경 요구사항이 실제로 발생할 때 리팩토링을 통해 점진적으로 원칙을 도입하는 접근법이 권장된다. 예를 들어, 단일 책임 원칙을 지나치게 세분화하여 수많은 작은 클래스를 만들기보다는, 명확한 변경 이유가 확인된 시점에서 클래스를 분리하는 것이 실용적이다. 테스트 코드의 작성 용이성은 원칙 적용의 적절성을 판단하는 좋은 지표가 될 수 있다.

다음은 프로젝트 특성에 따른 원칙 적용 우선순위를 고려할 수 있는 요소를 정리한 표이다.

결국 SOLID 원칙은 목적이 아닌 수단이다. 이 원칙들이 궁극적으로 지향하는 것은 결합도를 낮추고 응집도를 높여 변경에 유연한 소프트웨어를 만드는 것이다. 원칙 자체에 매몰되기보다는 이러한 근본적인 목표를 상기하며, 현재 상황에서 가장 합리적인 설계 결정을 내리는 것이 중요하다.

SOLID 원칙을 지나치게 엄격하게 적용하거나 맥락을 고려하지 않고 적용하면 과잉 설계로 이어질 수 있다. 이는 불필요하게 복잡한 소프트웨어 아키텍처를 만들어 유지보수 비용을 증가시키고 개발 속도를 저하시킨다. 특히 작고 단순한 애플리케이션이나 빠른 프로토타이핑이 필요한 상황에서는 원칙의 적용이 오히려 방해가 될 수 있다.

잠재적 과잉 설계의 대표적인 예는 변경될 가능성이 거의 없는 부분에 대해 미리 추상화 계층을 과도하게 도입하는 것이다. 예를 들어, 단 하나의 데이터베이스만 사용할 것이 확실한 프로젝트에서 의존관계 역전 원칙을 적용해 데이터 접근 계층에 대한 인터페이스를 만드는 것은 불필요한 간접 참조와 파일 수의 증가를 초래한다. 마찬가지로, 현재 단일 책임을 잘 수행하는 클래스를 "미래의 변경"을 이유로 지나치게 세분화하는 것은 시스템을 파편화시킬 수 있다.

따라서 SOLID 원칙은 목적이 아닌 수단으로 여겨야 한다. 원칙의 적용은 프로젝트의 규모, 예상 수명, 변경 빈도, 팀의 역량과 같은 실용적 요소와 균형을 이루어야 한다. 가장 중요한 목표는 작동하는 소프트웨어를 효율적으로 전달하고 유지보수하는 것이며, 원칙은 이 목표를 달성하는 데 도움이 될 때만 적용되어야 한다.