개방 폐쇄 원칙 (r1)

확장에 열림은 개방 폐쇄 원칙의 핵심 축 중 하나로, 소프트웨어 모듈(클래스, 함수, 모듈 등)이 새로운 요구사항이나 기능이 추가될 때 기존 코드를 변경하지 않고도 확장할 수 있어야 함을 의미한다. 이는 시스템의 행위를 변경하거나 새로운 기능을 도입하는 과정에서, 기존에 잘 동작하던 코드의 수정을 최소화하거나 전혀 하지 않도록 설계하는 것을 목표로 한다.

구체적으로, 새로운 기능이 필요할 때 개발자는 기존 클래스를 수정하는 대신 새로운 클래스를 생성하여 시스템에 추가한다. 이때, 새로운 클래스는 기존의 추상화된 계약(예: 인터페이스나 추상 클래스)을 준수함으로써 시스템의 다른 부분과 무리 없이 협력할 수 있다. 예를 들어, 다양한 결제 수단을 지원하는 시스템에서 신용카드 결제 기능이 있다고 가정하자. 이후에 모바일 결제나 암호화폐 결제를 추가해야 할 경우, '확장에 열림' 원칙에 따라 기존의 결제 처리 로직을 수정하지 않고, 새로운 결제 방식 클래스를 새로 작성하여 기존의 결제 인터페이스에 맞추어 구현하면 된다.

이 원칙을 준수하면 다음과 같은 장점을 얻을 수 있다.

• 기능 추가의 용이성: 새로운 요구사항에 대해 기존 코드 베이스를 안정적으로 유지한 채로 대응할 수 있다.

• 재사용성 증가: 잘 정의된 인터페이스를 통해 새로운 컴포넌트를 쉽게 조립할 수 있다.

• 결합도 감소: 모듈 간의 의존성이 추상화에 집중되므로, 구체적인 구현 변경의 영향이 제한된다.

따라서 '확장에 열림'은 변화하는 요구사항에 유연하게 대응할 수 있는 소프트웨어 아키텍처의 기초를 제공하는 중요한 개념이다.

개방 폐쇄 원칙에서 '수정에 닫힘'은 기존의 코드, 특히 검증을 마치고 안정적으로 동작하는 핵심 모듈이나 클래스가 변경으로부터 보호되어야 함을 의미한다. 이는 새로운 기능을 추가하거나 요구사항이 변할 때, 기존의 소스 코드를 직접 수정하지 않고도 시스템을 확장할 수 있도록 하는 것을 목표로 한다. 기존 코드를 수정하지 않음으로써, 해당 코드에 의존하는 다른 부분에서 발생할 수 있는 예기치 않은 버그나 사이드 이펙트를 방지한다.

구체적으로, '닫힘'의 상태는 모듈의 행위를 변경하는 유일한 방법이 해당 모듈의 소스 코드를 편집하는 것이 아니라, 새로운 코드를 추가하는 것임을 나타낸다. 예를 들어, 인터페이스나 추상 클래스를 통해 정의된 계약을 준수하는 새로운 클래스를 생성하여 기능을 확장하는 방식이다. 이렇게 하면 기존 클래스의 내부 구현은 전혀 건드리지 않으면서도 시스템의 행위는 변경된다.

이 원칙을 준수하면 소프트웨어의 유지보수성이 크게 향상된다. 기존 코드를 수정할 필요가 없으므로, 해당 코드를 다시 테스트하거나 재검증하는 데 드는 비용과 시간이 절감된다. 또한, 변경으로 인해 새로운 결함이 도입될 위험도 현저히 낮아진다. 결과적으로 시스템의 핵심 부분은 안정성을 유지하면서도 주변 부분을 통해 유연하게 진화할 수 있는 구조가 만들어진다.

이 원칙을 따르면 새로운 기능이나 요구사항이 발생했을 때 기존 코드를 수정하지 않고도 추상화된 인터페이스를 통해 새로운 클래스를 추가하는 방식으로 시스템을 확장할 수 있습니다. 이는 시스템이 변화에 유연하게 대응할 수 있게 해줍니다. 예를 들어, 다양한 결제 수단을 지원하는 시스템에서 새로운 결제 방식이 추가되어도 기존의 결제 처리 로직을 변경하지 않고, 새로운 결제 구현 클래스만 만들면 됩니다.

이러한 유연성은 곧 높은 재사용성으로 이어집니다. 안정적인 추상 인터페이스에 의존하는 모듈은 구체적인 구현 변경으로부터 보호받으며, 해당 인터페이스를 준수하는 어떤 구현체와도 협력할 수 있습니다. 따라서 특정 도메인이나 컨텍스트에 종속되지 않고, 다른 시스템이나 새로운 맥락에서도 쉽게 재사용될 수 있습니다.

결과적으로, 개방 폐쇄 원칙은 소프트웨어 구성 요소를 마치 플러그인처럼 설계하도록 유도합니다. 이는 개발 생산성을 높이고, 장기적으로 코드베이스의 진화와 관리를 훨씬 수월하게 만듭니다.

기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있으므로, 시스템의 유지보수성이 크게 향상됩니다. 기존 모듈이 수정에 닫혀 있기 때문에, 새로운 요구사항이나 기능 확장이 발생해도 기존에 안정적으로 동작하던 코드를 건드릴 필요가 없습니다. 이는 버그 발생 가능성을 줄이고, 기존 기능에 대한 회귀 테스트 부담을 경감시킵니다.

변경이 필요한 부분이 명확히 분리되고 제한되므로, 코드 변경의 영향 범위를 쉽게 예측할 수 있습니다. 개발자는 새로운 기능을 구현할 때, 주로 새로운 클래스를 작성하거나 기존 인터페이스를 구현하는 데 집중하면 됩니다. 결과적으로 코드베이스 전체를 이해하는 데 드는 인지 부하가 줄어들고, 특정 모듈을 수정할 때 다른 부분에 미칠 부작용을 걱정하지 않아도 됩니다.

장기적인 관점에서 이 원칙을 준수한 시스템은 변경 비용이 낮아집니다. 기능 추가나 요구사항 변화에 더 민첩하게 대응할 수 있으며, 이는 소프트웨어의 수명 주기를 연장하는 데 기여합니다. 또한, 모듈 간 결합도가 낮아져 코드의 가독성과 이해도가 높아지므로, 새로운 개발자가 프로젝트에 합류했을 때의 적응 시간도 단축됩니다.

기능을 추가하거나 변경할 때 기존 코드를 수정할 필요가 없으므로, 기존에 정상 동작하던 부분에 영향을 미칠 가능성이 줄어든다. 이는 회귀 버그의 발생 위험을 낮추는 효과가 있다. 시스템의 핵심 모듈이나 안정적인 부분은 '닫혀' 있기 때문에, 새로운 요구사항이 발생하더라도 이 부분을 건드리지 않고 확장을 통해 대응할 수 있다.

결과적으로, 시스템의 기반이 되는 코드는 안정된 상태를 유지하면서도 외부의 변화에 유연하게 적응할 수 있는 구조를 갖추게 된다. 이는 장기적인 프로젝트에서 코드의 신뢰성을 높이고, 변경으로 인한 예기치 않은 사이드 이펙트를 방지하는 데 기여한다. 시스템의 안정성은 유지보수 비용을 절감하고 소프트웨어의 수명을 연장하는 핵심 요소가 된다.

추상화는 개방 폐쇄 원칙을 구현하는 핵심 메커니즘이다. 구체적인 구현 세부 사항이 아닌, 공통적인 기능이나 행위를 정의하는 추상적인 계층을 도입함으로써 시스템을 확장에 열리게 만든다. 이는 주로 추상 클래스나 인터페이스를 통해 이루어진다. 모듈은 이러한 추상 계층에 의존하도록 설계되어, 구체적인 구현이 변경되거나 추가되어도 모듈 자체의 코드는 수정할 필요가 없게 된다.

예를 들어, 다양한 형태의 알림 기능(이메일, SMS, 푸시)을 제공하는 시스템을 설계한다고 가정해 보자. 각 알림 방식의 구체적인 전송 로직을 직접 참조하는 대신, send() 메서드를 정의한 Notifier라는 인터페이스를 먼저 생성한다. 그런 다음 EmailNotifier, SmsNotifier 등은 이 인터페이스를 구현하는 구체 클래스가 된다. 시스템의 주요 흐름은 Notifier 인터페이스에만 의존하게 되어, 새로운 알림 방식(예: 슬랙 메시지)이 필요할 때 기존 코드를 건드리지 않고 SlackNotifier 클래스를 추가하기만 하면 된다.

적절한 추상화 수준을 선택하는 것이 중요하다. 너무 낮은 수준의 추상화는 변화를 수용하지 못하게 만들고, 너무 높거나 광범위한 추상화는 불필요한 복잡성을 초래할 수 있다[2]. 따라서 요구사항의 변화 포인트를 예측하거나 식별하여, 그 부분을 중심으로 추상화를 적용하는 것이 바람직하다. 추상화는 변화가 예상되는 영역을 캡슐화하는 도구로 사용되어야 한다.

인터페이스 설계는 개방 폐쇄 원칙을 실현하는 핵심적인 수단이다. 이 원칙에 따르면, 모듈은 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다. 이를 달성하기 위해서는 변경될 가능성이 있는 부분을 식별하고, 그 부분을 위한 안정적인 인터페이스를 정의하는 것이 중요하다. 구체적인 구현 클래스가 아닌, 인터페이스에 의존하도록 코드를 작성하면, 새로운 기능을 추가할 때 기존 코드를 수정하지 않고도 인터페이스를 구현하는 새로운 클래스를 도입할 수 있다.

효과적인 인터페이스 설계를 위해서는 해당 인터페이스가 하나의 명확한 책임만을 가지도록 해야 한다. 이는 단일 책임 원칙과도 연결된다. 너무 많은 메서드를 포함한 범용적인 인터페이스보다는, 특정한 행동 계약을 정의하는 집중된 인터페이스를 설계하는 것이 바람직하다. 예를 들어, 저장소라는 인터페이스는 저장()과 조회() 메서드만을 제공해야 하며, 보고서 생성이나 데이터 변환과 같은 다른 책임은 별도의 인터페이스로 분리하는 것이 좋다.

클라이언트 코드는 구체적인 구현체가 아닌, 이렇게 정의된 인터페이스 타입을 통해 객체를 사용한다. 이로 인해 시스템의 다른 부분은 변경되지 않은 채로, 인터페이스를 준수하는 새로운 구현체로 쉽게 교체하거나 추가할 수 있다. 예를 들어, 데이터베이스를 MySQL에서 PostgreSQL로 변경하거나, 파일 저장소에 클라우드 저장소를 추가하는 경우, 해당 인터페이스를 구현하는 새로운 클래스를 만들고 의존성 주입 등을 통해 연결하기만 하면 된다. 기존의 비즈니스 로직 코드는 전혀 수정할 필요가 없다.

잘 설계된 인터페이스는 시스템의 확장 포인트를 명시적으로 정의한다. 개발자는 어떤 인터페이스를 구현함으로써 기능을 확장할 수 있는지 쉽게 이해할 수 있으며, 이는 코드의 가독성과 협업 효율성을 높인다. 결과적으로, 인터페이스 설계는 개방 폐쇄 원칙을 통해 소프트웨어의 유연성과 유지보수성을 크게 향상시키는 기반을 제공한다.

의존성 역전 원칙은 개방 폐쇄 원칙을 효과적으로 준수하기 위한 핵심적인 구현 메커니즘 중 하나이다. 이 원칙은 고수준 모듈이 저수준 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 한다고 명시한다. 또한, 추상화는 구체적인 사항에 의존해서는 안 되며, 구체적인 사항이 추상화에 의존해야 한다.

구체적으로, 전통적인 계층형 아키텍처에서는 상위 계층의 정책이나 비즈니스 로직이 하위 계층의 구체적인 구현(예: 특정 데이터베이스나 외부 서비스)에 직접 의존하는 경우가 많다. 이는 하위 모듈을 변경할 때 상위 모듈까지 수정해야 할 가능성을 높여, 시스템을 수정에 닫혀 있지 않게 만든다. 의존성 역전은 이 관계를 뒤집어, 상위 모듈이 자신이 필요로 하는 기능을 인터페이스나 추상 클래스 같은 추상화로 정의하도록 한다. 이후 하위 모듈은 이 추상화를 구현하는 형태로 작성된다.

이를 구현하는 일반적인 방법은 의존성 주입이다. 상위 모듈은 생성자나 메서드를 통해 필요한 추상화 타입의 인스턴스를 외부로부터 전달받는다. 이때 실제로 주입되는 객체는 해당 인터페이스를 구현한 구체적인 하위 모듈이다. 결과적으로 상위 모듈의 소스 코드는 특정 구현체의 존재를 전혀 알지 못하게 되며, 오직 추상화에 정의된 계약만을 사용하게 된다.

이러한 구조는 개방 폐쇄 원칙이 지향하는 목표를 실현한다. 새로운 기능을 추가하려면 기존의 고수준 모듈을 수정하지 않고, 새로운 저수준 모듈 클래스를 만들어 추상화를 구현하기만 하면 된다. 시스템은 확장에 열려 있으면서도, 기존 코드의 수정에는 닫혀 있는 상태를 유지할 수 있다.

전략 패턴은 개방 폐쇄 원칙을 구현하는 대표적인 설계 패턴 중 하나이다. 이 패턴은 특정 작업을 수행하는 알고리즘군을 정의하고, 각 알고리즘을 별도의 클래스로 캡슐화하여 상호 교체가 가능하도록 만든다. 클라이언트 코드는 구체적인 알고리즘 클래스가 아닌, 공통의 인터페이스에 의존하게 된다.

패턴의 구조는 일반적으로 다음과 같은 구성 요소를 가진다.

이 패턴을 적용하면 새로운 알고리즘을 추가해야 할 때 기존의 문맥 클래스나 다른 전략 클래스를 수정하지 않고도 새로운 구체적인 전략 클래스만 추가하면 된다. 이는 시스템이 '확장에는 열려 있고, 수정에는 닫혀 있다'는 개방 폐쇄 원칙을 정확히 반영한다. 예를 들어, 다양한 정렬 알고리즘(퀵 정렬, 병합 정렬, 버블 정렬)이나 결제 수단(신용카드, 페이팔, 암호화폐)을 유연하게 교체해야 하는 상황에서 전략 패턴은 매우 효과적이다.

데코레이터 패턴은 개방 폐쇄 원칙을 준수하는 대표적인 소프트웨어 설계 패턴이다. 이 패턴은 객체에 동적으로 새로운 책임을 추가할 수 있게 하며, 기존 코드를 수정하지 않고 기능을 확장하는 방식을 제공한다. 핵심은 객체를 감싸는 래퍼 객체를 생성하여, 기본 객체의 행동을 변경하거나 보강하는 것이다.

구조적으로, 데코레이터 패턴은 구성 요소 인터페이스, 구체적인 구성 요소, 그리고 이를 상속받는 데코레이터 추상 클래스로 구성된다. 데코레이터 클래스는 구성 요소 객체를 참조하며, 클라이언트는 데코레이터 객체를 통해 구성 요소를 사용한다. 여러 데코레이터 객체를 중첩하여 연결함으로써, 다양한 기능 조합을 런타임에 유연하게 구성할 수 있다.

이 패턴의 주요 장점은 단일 책임 원칙을 준수하면서 기능을 여러 작은 클래스로 분리할 수 있다는 점이다. 예를 들어, 텍스트 출력 스트림에 압축, 암호화, 로깅 등의 기능을 데코레이터로 순차적으로 감싸서 추가할 수 있다. 이는 상속을 통한 기능 확장보다 더 유연하며, 클래스 폭발 문제를 피할 수 있다. 그러나 데코레이터 객체가 많아지면 코드 초기화 및 디버깅이 복잡해질 수 있고, 객체 식별이 어려워질 수 있는 한계도 존재한다[3].

신용카드, 계좌이체, 모바일 결제 등 다양한 결제 수단을 지원하는 시스템을 설계할 때 개방 폐쇄 원칙을 적용할 수 있다. 핵심은 새로운 결제 방식을 추가하더라도 기존의 결제 처리 로직을 수정하지 않도록 하는 것이다.

이를 위해 먼저 모든 결제 수단이 구현해야 할 공통적인 행위를 정의한 PaymentMethod 인터페이스 또는 추상 클래스를 생성한다. 이 인터페이스는 processPayment(amount)와 같은 메서드를 포함한다. 그런 다음, 각 구체적인 결제 방식(예: CreditCardPayment, BankTransferPayment)은 이 인터페이스를 구현하여 자신의 방식으로 결제를 처리하는 로직을 담는다.

주문 처리 시스템의 주요 클래스(예: OrderProcessor)는 구체적인 결제 클래스가 아닌 PaymentMethod 인터페이스에 의존한다. 이는 의존성 역전 원칙을 따르는 것이다. 시스템은 런타임에 실제 결제 객체를 인터페이스 타입으로 받아 처리한다. 따라서 새로운 결제 수단(예: 암호화폐 결제)이 필요할 때는 기존 코드를 전혀 건드리지 않고, 새로운 CryptoPayment 클래스가 PaymentMethod 인터페이스를 구현하기만 하면 된다.

이러한 설계는 시스템이 새로운 요구사항에 대해 '확장에 열려' 있으면서, 기존의 안정된 결제 처리 흐름에 대해서는 '수정에 닫혀' 있게 만든다. 결과적으로 기능 추가 시 버그 발생 가능성을 줄이고, 단위 테스트의 재사용성을 높이는 이점을 얻는다.

로깅 기능을 필요로 하는 애플리케이션에서 개방 폐쇄 원칙을 적용하면, 로그 출력 방식을 변경하거나 확장할 때 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있다. 초기 구현이 콘솔에만 로그를 출력하는 간단한 클래스였다고 가정해 보자.

이 시스템에 파일 로깅이나 데이터베이스 로깅, 네트워크를 통한 원격 로깅 등의 새로운 요구사항이 생길 경우, 원칙을 적용하지 않았다면 기존 로그 출력 클래스를 직접 수정해야 한다. 이는 기존에 동작하던 코드를 변경해야 하므로 버그 발생 위험을 초래한다.

이 문제를 해결하기 위해 추상화된 Logger 인터페이스를 도입한다. 이 인터페이스는 log(message: string)과 같은 메서드를 정의한다. 그런 다음, ConsoleLogger, FileLogger, DatabaseLogger 등의 구체적인 클래스가 이 인터페이스를 구현한다.

애플리케이션은 구체적인 로거 클래스가 아닌 Logger 인터페이스에 의존하게 된다. 따라서 새로운 로깅 방식(예: 클라우드 서비스 로깅)이 필요해지면, 기존 코드를 전혀 건드리지 않고 CloudLogger라는 새로운 클래스를 만들어 Logger 인터페이스를 구현하기만 하면 된다. 이는 시스템이 로그 출력 방식이라는 "확장에는 열려" 있으면서, 기존의 안정된 로깅 모듈에 대한 "수정에는 닫혀" 있음을 보여준다.

추상화는 개방 폐쇄 원칙을 달성하는 핵심 수단이지만, 필요 이상으로 과도하게 적용될 경우 오히려 설계를 복잡하게 만들고 성능에 부정적인 영향을 미칠 수 있다. 모든 변경 가능성을 예측하여 미리 추상화하는 것은 불가능하며, 실제로 발생하지 않는 변화에 대한 추상화는 불필요한 복잡성만을 추가한다. 이는 YAGNI 원칙과도 맞닿는 개념이다.

과도한 추상화는 다음과 같은 문제점을 초래한다.

* 코드 가독성 저하: 간단한 로직이 여러 계층의 인터페이스와 클래스를 거쳐 표현되면 코드의 흐름을 파악하기 어려워진다.

* 설계 및 유지보수 비용 증가: 실제 요구사항보다 많은 클래스와 관계가 생겨 초기 구현과 이후 이해에 더 많은 시간이 소요된다.

* 성능 오버헤드: 불필요한 간접 호출 레이어가 증가하면 런타임 성능에 미세하지만 부정적인 영향을 줄 수 있다.

적절한 추상화 수준을 결정하는 것은 중요한 설계 판단 요소이다. 변화가 예상되는 영역과 변경의 빈도, 영향 범위를 신중하게 평가한 후에 추상화를 도입하는 것이 바람직하다. 경험적으로, 세 번 이상의 유사한 변경이 발생했거나, 시스템의 핵심적인 확장 포인트가 명확한 경우에 추상화를 적용하는 것이 효과적이다.

개방 폐쇄 원칙은 모든 모듈에 항상 적용해야 하는 절대적인 법칙이 아니라, 변화 가능성이 높은 부분을 식별하여 신중하게 적용해야 하는 설계 지침이다. 이 원칙을 적용할 시기를 판단하는 것은 설계의 품질을 결정하는 중요한 요소이다.

변화가 예상되는 영역에 집중하여 적용하는 것이 효과적이다. 예를 들어, 비즈니스 규칙, 외부 시스템 연동 방식, 보고서 출력 형식 등은 요구사항 변경이 빈번하게 발생하는 전형적인 영역이다. 반면, 안정적이고 변경될 가능성이 거의 없는 핵심 도메인 로직이나 유틸리티 기능에까지 과도하게 적용하는 것은 불필요한 복잡성을 초래할 수 있다[4]. 따라서 변경의 빈도와 영향도를 예측하여 우선순위를 정하는 것이 바람직하다.

초기 설계 단계에서 모든 확장 가능성을 예측하고 대비하는 것은 불가능하며, 오히려 설계를 복잡하게 만드는 원인이 된다. 개방 폐쇄 원칙은 반복적인 리팩토링을 통해 점진적으로 달성해야 하는 목표로 보는 것이 적절하다. 시스템이 성장하고 요구사항이 구체화되면서 실제로 변경이 발생하는 지점을 확인한 후, 그 부분을 추상화하여 수정에 닫히고 확장에 열린 구조로 리팩토링하는 접근 방식이 실용적이다. 이는 변경에 대한 두 번째 또는 세 번째 반복에서 원칙을 적용하는 것을 의미할 수 있다.