OCP (r1)

개방-폐쇄 원칙에서 '확장에 열려 있음'은 소프트웨어 모듈(예: 클래스, 함수, 컴포넌트)이 새로운 요구사항이나 변경 사항이 발생했을 때, 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있도록 설계되어야 함을 의미한다. 이는 모듈의 동작을 변경하거나 확장하는 것이 가능해야 한다는 것을 핵심으로 한다. 예를 들어, 새로운 결제 수단을 시스템에 추가해야 할 때, 기존의 결제 처리 로직을 직접 고치는 대신 새로운 결제 방식 클래스를 만들어 기존 구조에 통합할 수 있어야 한다.

이 원칙을 준수하는 설계는 주로 추상화와 다형성에 의존한다. 공통적인 기능을 인터페이스나 추상 클래스로 정의해 두면, 이후에 새로운 구체적인 구현체를 만들어 해당 추상화를 통해 시스템에 연결할 수 있다. 결과적으로, 기존의 코드 베이스는 안정적으로 유지된 채로, 새로운 동작을 가진 모듈을 추가함으로써 시스템 전체의 기능을 확장할 수 있게 된다. 이는 시스템의 수명 주기 동안 발생하는 지속적인 변경 요구에 유연하게 대응할 수 있는 기반을 마련해 준다.

'확장에 열려 있음'의 이점은 소프트웨어의 진화적 특성과 직접적으로 연결된다. 요구사항은 시간이 지남에 따라 변하고, 비즈니스 규칙은 추가되거나 수정된다. 이 원칙을 적용하면 이러한 변화에 대응하는 비용과 위험을 크게 줄일 수 있다. 기존 코드를 수정하지 않기 때문에, 이미 검증되고 안정적으로 동작하는 부분에 새로운 버그가 발생할 가능성이 낮아진다. 따라서 시스템은 새로운 기능을 추가하면서도 기존 기능의 안정성을 유지할 수 있게 된다.

수정에 닫혀 있음은 기존의 검증된 코드를 변경하지 않고도 새로운 기능을 추가할 수 있어야 함을 의미한다. 이는 시스템의 핵심 로직이나 기존 모듈을 직접 수정하는 대신, 새로운 클래스나 모듈을 추가하여 기능을 확장하는 방식을 지향한다. 기존 코드를 변경하지 않음으로써, 해당 코드에 의존하는 다른 부분에서 발생할 수 있는 예기치 않은 버그나 사이드 이펙트를 방지한다.

이 원칙을 준수하면, 시스템의 안정성이 크게 향상된다. 이미 테스트를 거치고 정상적으로 동작하는 모듈은 수정의 대상에서 제외되므로, 새로운 요구사항이 발생하더라도 기존 기능의 신뢰성을 훼손하지 않는다. 결과적으로 소프트웨어의 주요 구성 요소는 변경으로부터 보호되며, 이는 장기적인 유지보수 비용을 절감하는 데 기여한다.

실제 구현에서는 인터페이스나 추상 클래스를 통해 안정적인 계약을 정의하고, 구체적인 기능의 변화는 이들을 구현하는 새로운 클래스를 만들어 처리한다. 예를 들어, 보고서 생성 기능에서 PDF 출력 외에 Excel 출력을 추가해야 할 경우, 기존 PDF 생성 클래스를 수정하는 대신 공통 인터페이스를 구현하는 새로운 Excel 생성 클래스를 도입한다.

추상화는 OCP를 구현하는 핵심 메커니즘이다. 구체적인 구현 세부 사항이 아닌, 변하지 않는 핵심적인 개념이나 동작을 인터페이스나 추상 클래스로 정의하는 과정이다. 이렇게 추상화된 계층은 변경으로부터 안정적인 계층이 되어, 새로운 기능이 추가될 때 기존 코드를 수정하지 않고도 확장할 수 있는 틀을 제공한다.

예를 들어, 다양한 형태의 도형 넓이를 계산하는 시스템에서, 각 도형 클래스(예: Rectangle, Circle)가 calculateArea() 메서드를 직접 구현하면 새로운 도형이 추가될 때마다 넓이를 계산하는 로직을 수정해야 한다. 대신 Shape라는 추상 클래스나 인터페이스를 도입하고 calculateArea() 메서드를 추상 메서드로 선언한다. 이후 모든 구체적인 도형 클래스는 이 Shape를 상속하거나 구현하여 자신만의 넓이 계산 로직을 제공하면 된다. 새로운 Triangle 도형이 추가되더라도, Shape를 구현하는 새 클래스만 추가하면 되며 기존의 Shape 인터페이스나 다른 도형 클래스는 전혀 수정할 필요가 없다.

따라서 추상화를 활용한 OCP 구현의 핵심은, 변하는 것과 변하지 않는 것을 분리하고, 클라이언트 코드가 구체적인 구현이 아닌 추상적인 개념에 의존하도록 설계하는 것이다. 이는 시스템의 핵심 모듈을 변경의 영향을 받지 않게 하여 안정성을 높이고, 확장 포인트를 명확하게 정의하는 효과가 있다.

인터페이스는 OCP를 구현하는 핵심 도구이다. 인터페이스는 '무엇을 해야 하는지'에 대한 계약을 정의하지만, '어떻게 하는지'에 대한 구체적인 구현은 포함하지 않는다. 이렇게 추상화된 계약에 의존함으로써, 클라이언트 코드는 구체적인 구현 클래스의 변경으로부터 보호된다. 새로운 기능이 추가되어야 할 때, 기존 인터페이스를 구현하는 새로운 클래스를 생성하면 되며, 기존 코드를 수정할 필요가 없어진다.

다형성은 이러한 인터페이스를 통해 다양한 객체가 동일한 메시지에 대해 각기 다른 방식으로 반응할 수 있게 하는 객체지향의 특성이다. 클라이언트는 인터페이스 타입을 통해 객체를 참조하고, 런타임에 실제 구현 객체의 메서드가 호출된다. 이는 시스템이 확장에 열려 있도록 만든다. 예를 들어, Notifier라는 인터페이스가 send() 메서드를 정의한다면, EmailNotifier, SMSNotifier, PushNotifier 등 새로운 알림 방식을 추가하더라도, 알림을 요청하는 클라이언트 코드는 변경되지 않는다.

인터페이스와 다형성을 활용한 OCP의 전형적인 구조는 다음과 같다.

이 접근법의 핵심은 의존성의 방향이다. 구체적인 구현 세부사항이 추상화된 인터페이스에 의존하도록 하고, 고수준의 모듈은 추상화에 의존하도록 해야 한다. 이렇게 하면 고수준 모듈은 저수준 모듈의 변경이나 확장에 영향을 받지 않게 되어, 수정에 닫혀 있는 상태를 유지할 수 있다.

전략 패턴은 OCP를 준수하는 대표적인 설계 기법 중 하나이다. 이 패턴은 실행 중에 알고리즘을 선택할 수 있도록, 알고리즘 군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만든다[2]. 클라이언트 코드는 구체적인 알고리즘 구현이 아닌 추상적인 인터페이스에 의존하게 된다.

구현 방식은 일반적으로 다음과 같다. 먼저 공통의 연산을 정의하는 전략 인터페이스를 선언한다. 그 후, 이 인터페이스를 구현하는 다양한 콘크리트 클래스를 생성하여 각각의 구체적인 알고리즘을 구현한다. 마지막으로, 컨텍스트 클래스는 전략 인터페이스 타입의 참조를 유지하며, 필요에 따라 다른 콘크리트 전략 객체로 교체한다.

이 패턴을 적용하면 새로운 알고리즘을 추가해야 할 때, 기존의 컨텍스트나 다른 전략 클래스의 코드를 수정하지 않고도 새로운 콘크리트 전략 클래스만 작성하면 된다. 이는 시스템이 "확장에는 열려 있고, 수정에는 닫혀 있다"는 OCP의 핵심을 직접적으로 실현한다. 정렬, 결제 수단 처리, 로깅 방식 변경 등 동일한 문제에 대한 여러 해법이 존재하는 상황에서 널리 활용된다.

OCP를 준수하면 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있습니다. 이는 기존 코드의 동작이 변경되지 않음을 의미하므로, 새로운 기능 추가로 인해 기존 기능이 오작동할 가능성이 크게 줄어듭니다. 결과적으로 시스템의 유지보수성이 향상됩니다. 버그 수정이나 기능 확장 시 영향 범위를 최소화하여 테스트 부담을 줄이고, 변경 사항을 더 빠르고 안전하게 적용할 수 있습니다.

또한, 변경이 필요한 부분이 명확하게 모듈화되어 있기 때문에 코드를 이해하고 수정하는 데 드는 시간과 비용이 절감됩니다. 개발자는 변경의 파급 효과를 크게 걱정하지 않고도 특정 모듈이나 인터페이스의 구현체를 집중적으로 수정할 수 있습니다. 이는 장기적인 프로젝트 생명주기에서 코드베이스의 건강성을 유지하는 데 결정적인 역할을 합니다.

요약하면, OCP는 변경으로부터 시스템을 보호하는 설계 방어막을 제공합니다. 이는 소프트웨어의 유지보수성을 높여 개발 생산성을 증대시키고, 전체적인 프로젝트 비용을 낮추는 효과를 가져옵니다.

기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있기 때문에, OCP를 준수하는 설계는 코드 재사용성을 크게 높인다. 모듈이 특정 변경에 대해 닫혀 있고 확장 포인트를 통해 새로운 동작을 추가하도록 설계되면, 해당 확장 포인트를 활용하는 다양한 컨텍스트에서 동일한 모듈이나 인터페이스를 재사용할 수 있다.

예를 들어, 다양한 형식의 보고서를 생성하는 시스템에서 OCP를 적용했다고 가정해보자. 공통 인터페이스를 정의하고, PDF 생성, HTML 생성 등 각 구체적인 형식은 이 인터페이스를 구현하는 별도의 클래스로 만든다. 이후 CSV 형식의 보고서가 새로 필요해지면, 기존의 보고서 생성 로직이나 다른 형식 생성 클래스를 전혀 수정하지 않고, 새로운 CSV 생성 클래스만 인터페이스를 구현하여 추가하면 된다. 이렇게 되면 기존의 보고서 생성 시스템 인프라는 그대로 재사용되며, 새로운 형식만 '플러그인' 방식으로 추가된다.

이러한 재사용성은 다음과 같은 이점을 제공한다.

• 개발 효율성: 검증된 기존 모듈을 안전하게 재사용함으로써 개발 시간과 비용을 절감한다.

• 일관성: 동일한 인터페이스와 추상화를 통해 구현된 기능들은 일관된 사용법과 동작을 보장한다.

• 시스템 통합 용이성: 표준화된 확장 메커니즘을 통해 서드파티 모듈이나 라이브러리를 보다 쉽게 통합할 수 있다.

결국, OCP는 시스템을 확장 가능한 구성 요소들의 집합으로 만듦으로써, 이러한 구성 요소들이 다양한 시나리오에서 반복적으로 활용될 수 있는 기반을 마련한다. 이는 소프트웨어의 경제적 가치를 높이는 핵심 요소 중 하나이다.

기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있기 때문에, OCP는 시스템의 핵심 부분이 변경으로부터 보호받도록 합니다. 이는 기존에 정상적으로 동작하던 코드를 건드리지 않음으로써, 새로운 변경 사항이 예상치 못한 버그나 사이드 이펙트를 발생시킬 위험을 크게 줄입니다. 결과적으로 시스템의 전반적인 안정성과 신뢰성이 향상됩니다.

특히 대규모 애플리케이션이나 지속적으로 진화하는 소프트웨어에서 이 원칙은 중요합니다. 새로운 요구사항이 발생할 때마다 기존 모듈을 직접 수정하면, 변경의 영향 범위를 파악하기 어렵고 회귀 테스트의 부담이 커집니다. OCP를 준수한 설계는 새로운 기능을 독립된 확장(예: 새로운 클래스나 모듈)으로 추가하게 함으로써, 변경의 영향을 지역화하고 시스템의 나머지 부분이 안정적으로 유지되도록 보장합니다.

이러한 안정성은 테스트 용이성과도 연결됩니다. 기존 코드의 동작이 변경되지 않으므로, 해당 부분에 대한 기존 테스트 케이스는 그대로 유효합니다. 새로운 기능에 대해서만 추가적인 테스트를 집중할 수 있어, 테스트 커버리지를 유지하거나 높이는 데 도움이 됩니다. 이는 결국 소프트웨어의 품질과 배포 후의 안정성을 높이는 선순환 구조를 만듭니다.

OCP를 준수하기 위해 지나치게 많은 추상화 계층을 도입하면 오히려 설계를 복잡하게 만들고 코드의 가독성을 떨어뜨릴 수 있다. 모든 변경 가능성에 대해 미리 추상화를 시도하는 것은 불필요한 YAGNI 원칙 위반으로 이어질 수 있다. 미래의 변경 사항을 정확히 예측하기 어렵기 때문에, 실제로 필요하지 않은 추상화는 시스템에 불필요한 간접 참조와 복잡성만을 추가한다.

과도한 추상화는 다음과 같은 구체적인 문제를 발생시킨다.

따라서 OCP를 적용할 때는 현재 명확히 요구되는 확장점에 대해서만 추상화를 설계하고, 지나친 일반화를 피해야 한다. 변경이 예상되는 부분과 안정적인 부분을 구분하는 것이 중요하다. 실용적인 접근 방식은 요구사항이 명확해지고 변경이 실제로 필요해질 때 리팩토링을 통해 점진적으로 OCP를 적용하는 것이다.

OCP를 적용할 때 발생하는 주요 문제점 중 하나는 설계의 복잡도가 필요 이상으로 증가할 수 있다는 점이다. 새로운 기능을 추가하기 위해 추상화 계층과 인터페이스를 계속해서 도입하면, 시스템 구조가 지나치게 복잡해져 이해하고 관리하기 어려워진다. 특히 규모가 작거나 변경이 빈번하지 않은 프로젝트에서는 이러한 복잡도가 오히려 생산성을 저해할 수 있다.

설계 복잡도 증가는 다음과 같은 구체적인 문제를 야기한다.

따라서 OCP를 적용할 때는 프로젝트의 규모, 예상 수명, 변경 빈도 등을 종합적으로 고려하여 적절한 수준의 추상화를 결정해야 한다. 모든 부분에 원칙을 무조건적으로 적용하기보다는, 실제로 변경이 예상되는 영역에 집중하여 적용하는 것이 바람직하다. 이는 YAGNI 원칙과도 연결되는 접근 방식이다.

플러그인 아키텍처는 OCP를 구현하는 대표적인 사례이다. 이 아키텍처는 핵심 애플리케이션을 변경하지 않고도 새로운 기능을 플러그인 형태로 추가할 수 있도록 설계한다. 핵심 시스템은 안정적인 인터페이스나 추상 클래스를 정의하고, 구체적인 기능 확장은 외부 모듈인 플러그인이 담당한다. 결과적으로 기존 코드는 수정에 닫혀 있고, 새로운 플러그인을 추가함으로써 시스템은 확장에 열려 있게 된다.

이 방식의 구체적인 구현은 보통 인터페이스나 추상 클래스를 통해 이루어진다. 예를 들어, 텍스트 편집기 소프트웨어는 문서 변환기라는 인터페이스를 정의할 수 있다. 핵심 애플리케이션은 이 인터페이스를 통해 플러그인을 호출하지만, PDF 변환 플러그인이나 HTML 변환 플러그인과 같은 구체적인 구현에 대해서는 알지 못한다. 새로운 파일 형식에 대한 지원이 필요할 때는 기존 편집기 코드를 수정하는 대신, 해당 인터페이스를 준수하는 새로운 플러그인 모듈만 개발하여 추가하면 된다.

이러한 아키텍처는 이클립스 IDE, 크롬 브라우저, 다양한 미디어 플레이어 등에서 널리 사용된다. 각 애플리케이션은 코어 기능을 유지한 채로 서드파티 개발자나 사용자가 직접 기능을 확장할 수 있는 생태계를 조성한다. 따라서 플러그인 아키텍처는 OCP의 실용적 가치를 잘 보여주며, 소프트웨어의 수명과 적응성을 크게 향상시키는 전략이다.

결제 시스템에서 OCP를 적용하면 새로운 결제 수단을 추가하거나 기존 결제 로직을 변경할 때 시스템의 핵심 코드를 수정하지 않고도 확장할 수 있다. 일반적으로 인터페이스를 정의하여 다양한 결제 방식(예: 신용카드, 계좌이체, 모바일 결제)이 이 인터페이스를 구현하도록 설계한다.

구체적인 구현은 아래 표와 같다. PaymentProcessor라는 공통 인터페이스를 두고, 각 결제 방식은 이를 구현하는 독립적인 클래스로 만든다.

이 구조에서 가맹점에 새로운 결제 서비스(예: 간편결제나 암호화폐)를 도입해야 할 때, 기존의 CreditCardProcessor나 BankTransferProcessor 등의 코드는 전혀 건드리지 않는다. 대신 새로운 CryptoPaymentProcessor 클래스를 작성하여 PaymentProcessor 인터페이스를 구현하기만 하면 된다. 결제를 실행하는 주문 처리 모듈은 구체적인 클래스가 아닌 인터페이스에 의존하기 때문에, 새로운 클래스가 추가되어도 정상적으로 동작한다.

이러한 모듈화는 시스템의 안정성을 높인다. 특정 결제 채널의 API가 변경되거나 장애가 발생했을 때, 해당 모듈만 수정하거나 교체하면 되므로 영향 범위가 최소화된다. 또한 각 결제 방식의 복잡한 비즈니스 로직(예: 수수료 계산, 로깅, 재시도 메커니즘)이 하나의 모듈 내에 캡슐화되어 유지보수가 용이해진다.

단일 책임 원칙(SRP)은 로버트 C. 마틴이 명명한 SOLID 원칙 중 첫 번째 원칙이다. 이 원칙은 "하나의 모듈은 변경의 이유가 하나, 단 하나만 가져야 한다"는 것으로 요약된다[3]. 여기서 '모듈'은 일반적으로 클래스를 의미하며, '변경의 이유'는 해당 클래스가 담당하는 하나의 명확한 책임이나 역할을 가리킨다.

SRP는 OCP의 실현을 위한 필수적인 토대를 제공한다. OCP가 시스템을 확장에는 열려 있도록 설계하는 원칙이라면, SRP는 그 확장의 단위를 명확히 정의하는 역할을 한다. 하나의 클래스가 여러 책임을 지니고 있다면, 그 중 하나의 책임만 변경되어도 클래스 전체가 수정되어야 하므로, 이는 OCP의 '수정에 닫혀 있음'을 위반하게 된다. 반면, 각 클래스가 단일 책임을 가질 때, 새로운 기능 추가는 기존 클래스를 수정하는 대신 새로운 클래스를 생성하는 방식으로 이루어질 수 있어 OCP를 준수하기 쉬워진다.

예를 들어, 사용자 데이터를 처리하는 User 클래스가 데이터베이스 저장 로직과 사용자 정보 검증 로직을 모두 포함한다면, 이 클래스는 저장 방식 변경이나 검증 규칙 변경이라는 두 가지 서로 다른 이유로 수정될 수 있다. SRP에 따라 이 클래스를 User(데이터 구조), UserValidator(검증), UserRepository(저장)로 분리하면, 각 클래스는 하나의 변경 이유만 가지게 되며, 이는 더 안정적이고 확장 가능한 설계로 이어진다.

따라서 SRP는 OCP를 비롯한 다른 SOLID 원칙을 효과적으로 적용하기 위한 기초가 된다. 잘 정의된 단일 책임은 코드를 더 이해하기 쉽게 만들고, 변경의 파급 효과를 최소화하여 시스템의 전반적인 유연성과 견고성을 높인다.

리스코프 치환 원칙은 바바라 리스코프가 1987년에 제안한 원칙으로, 객체 지향 프로그래밍에서 하위 타입의 관계를 정의하는 핵심 규칙이다. 이 원칙은 "S가 T의 하위 타입이라면, 프로그램에서 T 타입의 객체를 S 타입의 객체로 치환해도 프로그램의 정확성에 아무런 영향을 미치지 않아야 한다"는 내용을 담고 있다[4]. 간단히 말해, 부모 클래스가 사용되는 모든 곳에서 자식 클래스를 문제없이 대체할 수 있어야 함을 의미한다.

이 원칙을 준수하기 위해서는 하위 클래스가 상위 클래스의 계약을 반드시 지켜야 한다. 여기서 계약은 메서드의 이름, 매개변수 타입, 반환 값, 그리고 가장 중요한 사전 조건과 사후 조건, 불변 조건을 포함한다. 하위 클래스는 상위 클래스의 메서드를 더 엄격한 사전 조건을 요구하거나, 더 약한 사후 조건을 제공하는 방식으로 재정의해서는 안 된다. 또한 상위 클래스가 보장하는 불변 조건을 훼손해서도 안 된다.

OCP와 LSP는 밀접한 상호 의존 관계에 있다. OCP를 통해 추상화에 의존함으로써 시스템을 확장에 열리게 만들 수 있지만, 그 확장(새로운 하위 클래스 추가)이 LSP를 위반한다면 시스템의 정확성이 깨질 수 있다. 즉, LSP는 OCP가 성공적으로 지속되기 위한 필수 전제 조건 역할을 한다. LSP를 위반한 하위 클래스는 기존 코드를 수정하지 않고도 확장한다는 OCP의 본질을 훼손하게 된다.