개방-폐쇄 원칙(Open-Closed Principle, OCP)은 소프트웨어 공학에서 객체 지향 설계의 기본 원칙 중 하나인 SOLID 원칙의 두 번째 원칙이다. "소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다"는 내용을 담고 있다.
기원과 정의 이 원칙은 1988년 베르트랑 메이어(Bertrand Meyer)가 저서 『객체 지향 소프트웨어 생성(Object-Oriented Software Construction)』에서 처음 제시하였다. 메이어는 "모듈은 확장성에 대해서는 개방적이어야 하지만, 변경에 대해서는 폐쇄적이어야 한다"고 정의하였다. 이후 로버트 C. 마틴(Robert C. Martin)이 1990년대 후반 이 원칙을 재해석하여 "추상화와 다형성을 통해 구현체를 변경하지 않고도 기능을 확장할 수 있어야 한다"는 현대적인 관점으로 정리하며 널리 보급되었다.
핵심 개념
- 확장에 열려 있다(Open for Extension): 새로운 요구사항이나 변경 사항이 생겼을 때, 기존 코드를 수정하지 않고도 새로운 동작을 추가하거나 기존 동작을 확장할 수 있어야 한다. 주로 상속, 인터페이스 구현, 전략 패턴 등의 기법을 사용한다.
- 수정에 닫혀 있다(Closed for Modification): 이미 검증되어 동작 중인 기존 코드를 변경하지 않아야 한다. 기존 코드를 수정하면 회귀 버그(Regression Bug) 발생 위험이 높아지고, 테스트 비용이 증가하며, 의존하는 다른 모듈에 영향을 줄 수 있기 때문이다.
적용 방법 주로 추상화(Abstraction)와 다형성(Polymorphism)을 활용하여 적용한다. 구체적인 구현 클래스에 의존하는 대신 인터페이스나 추상 클래스에 의존하도록 설계하며, 새로운 기능이 필요하면 기존 클래스를 수정하는 대신 새로운 파생 클래스나 구현체를 추가하는 방식으로 확장한다.
장점
- 유지보수성 향상: 기존 코드 수정으로 인한 사이드 이펙트를 최소화한다.
- 재사용성 증대: 안정적인 추상화 계층을 통해 검증된 로직을 재사용하기 용이하다.
- 테스트 용이성: 수정 없이 확장만으로 기능 추가가 가능하므로 기존 테스트 케이스의 유효성을 유지하기 쉽다.
한계 및 고려사항 모든 클래스나 모듈에 기계적으로 적용할 경우 과도한 추상화로 인해 코드 복잡도가 증가하고 가독성이 저하될 수 있다. 변경이 빈번하게 발생하는 지점과 그렇지 않은 지점을 식별하여 선별적으로 적용하는 것이 권장된다.
