📖 [8장] OCP: 개방-폐쇄 원칙
📘 클린 아키텍처 북스터디 정리입니다
📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장
✅ 핵심 요약 (Key Takeaways)
이 장의 핵심 문장은?
소프트웨어 개체는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다
저자가 전달하고자 하는 메세지 요약
- 요구 사항 변경 시, 구조에 대한 변경이 아닌 확장이 되어야 함
- 계층 구조 조직화, 방향성 제어, 정보 은닉을 통해 OCP 실현 가능
💡 내용 정리
서론
개방-폐쇄 원칙(OCP)
- 소프트웨어 개체는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다. (버트란트 마이어, 1988)
실패한 소프트웨어 설계
- 사소한 요구사항 변경에도 전체 구조를 대대적으로 수정해야 하는 경우
사고 실험 - 소프트웨어의 이상적인 변경량은 0
소프트웨어 변경량 최소화를 위한 원칙
- 단일 책임원칙(SRP): 서로 다른 목적으로 변경되는 요소를 적절하게 분리
- 의존성 역전 원칙(DIP): 이들 요소 사이의 의존성을 체계화
재무 보고 시스템 사례
책임 분리
- 보고서용 데이터 계산
- 보고서를 표현(웹 or 출력 등)
의존성 조직화
- 하나의 책임에서 변경이 발생하더라도 다른 책임에는 영향이 없도록 소스 코드 의존성 조직화
- 처리 과정을 클래스 단위로 분할하고 이들 클래스를 컴포넌트 단위로 구분
[기존] 재무 데이터 → 웹 출력
[개선] 재무 데이터
↓
보고서용 데이터 생성
↓ ↓
웹 출력 프린터 출력
OCP를 실현하는 아키텍처 전략
계층 구조 조직화
- 목적(why), 방식(how), 시점(when)에 따라 기능을 분리하고, 분리한 기능을 컴포넌트의 계층 구조로 조직화
- 컴포넌트 계층 구조 조직화를 통해 저수준 컴포넌트의 변경으로부터 고수준 컴포넌트 보호
- 예시
-Interactor: 업무 규칙이 담긴 가장 보호받아야 할 고수준 컴포넌트
-Controller,Database,Presenter등: 변경 가능성이 높은 저수준 컴포넌트
방향성 제어
- 의존 방향을 역전하기 위해 인터페이스 삽입
- 예:
FinancialDataGateway를 통해Interactor -> Database가 아니라Database -> Interactor로 의존성 역전
정보 은닉
- 상위 계층 변경이 하위 계층에 추이 종속성을 주지 않도록 인터페이스 삽입
- 예:
FinancialEntities에 대한 직접 의존 대신,FinancialReportRequester인터페이스를 통해 접근
결론
OCP의 목표
- 시스템을 확장에 용이하게
- 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록
목표 달성을 위한 방법
- 시스템을 컴포넌트 단위로 분리
- 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층 구조 생성
💡 용어 정리
추이 종속성(transitive dependency)
- A → B → C 의존 관계에서, A는 C에도 간접적으로 의존
- 순환 종속성이 발생하면 모든 컴포넌트가 서로 얽히게 되어 유지보수가 어려워짐
💡 인상 깊었던 문장 & 나의 인사이트
책에서 가장 기억에 남는 문장
만약 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정해야 한다면,
그 소프트웨어 시스템을 설계한 아키텍트는 엄청난 실패에 맞닥뜨린 것이다
인상 깊었던 문장과 관련된 인사이트
OCP 개념이 추상적으로 느껴져 이해가 어려웠는데
실패 사례를 표현하는 이 문장을 통해 역설적으로 OCP의 필요성과 가치를 이해할 수 있었다.
작은 기능 확장을 위해 수많은 코드와 의존 구조를 고쳐야 한다면
그 자체가 OCP가 지켜지지 않았고, 아키텍처가 유연하지 못했다는 증거임을 나타낸다는 것을 잘 표현하는 문장인 것 같다.
설계 시 기능 변경이 시스템 전체에 어떤 파급 효과를 미칠지를 고려하며 설계해야 한다.
🛠 실무 적용 아이디어 (To Action)
✅ 오늘부터 실천할 작은 실천
- 설계 시, 기능 변경이 시스템에 어떤 영향을 끼칠 지 한번 더 생각해보기
