📖 [17장] 경계: 선 긋기
📘 클린 아키텍처 북스터디 정리입니다
📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장
✅ 핵심 요약 (Key Takeaways)
이 장의 핵심 문장은?
좋은 시스템 아키텍처란 이러한 결정(업무 요구사항과 무관한 결정)이 부수적이며,
결정을 연기할 수 있는 아키텍처다
저자가 전달하고자 하는 메세지 요약
- 시스템을 컴포넌트 단위로 분할하여 업무 규칙과 세부사항으로 분리
- 업무 규칙과 세부사항 간 경계를 생성하고, 세부 사항에서 업무 규칙쪽으로 화살표가 향하도록 함
💡 내용 정리
1. 서론
- 소프트웨어 아키텍처는 선(경계)을 긋는 기술
경계의 역할
- 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막음
결합(coupling)
- 너무 일찍 내려진 결정에 따른 결합은 인적자원의 효율을 떨어트림
좋은 아키텍처
- 이른 결정: 시스템의 업무 요구사항(유스케이스)와 무관한 결정
- 예시: 프레임워크, DB, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등
- 이러한 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처
2. 경계를 긋는 방법
- 관련이 있는 것과 없는 것 사이에 선을 그거야 함
업무 규칙과 데이터베이스
- DB는 업무 규칙이 간접적으로 사용할 수 있는 도구
- 업무 규칙은 스키마, 쿼리 언어, 또는 DB와 관련된 나머지 세부 사항에 대해 어떤 것도 알아서는 안됨
- 업무 규칙이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실
- 이 함수 집합을 통해서 DB를 인터페이스 뒤로 숨길 수 있음
경계선
- 경계선은 DB Interface와 DB Access 사이에 그어짐
- DB Access에서 출발하는 화살표는 DB Access 클래스로부터 바깥쪽으로 향함(DB Access가 존재한다는 사실을 아는 클래스는 없다는 의미)
화살표 방향의 의미
- 화살표의 방향을 보면 DB에서 BusinessRules로 향하고 있음
- 이를 통해 DB는 BusinessRules에 대해 알고 있지만 BusinessRules는 DB에 대해 알지 못한다는 것을 알 수 있음
- 즉, 두 컴포넌트 사이에 이러한 경계선을 긋고 화살표의 방향이 BusinessRules를 향하도록 만들었으므로, BusinessRules에서는 어떤 종류의 DB도 사용할 수 있음
- DB 컴포넌트는 다양한 구현체로 교체될 수 있으며, BusinessRules는 이에 대해 조금도 개의치 않음
업무 규칙과 GUI
- 예시: 비디오 게임
- 비디오 게임의 사용자 경험은 인터페이스에 의해 좌우됨
- 인터페이스의 뒷단에는 인터페이스를 조작하는 모델(데이터 구조와 함수로 구성된 정교한 집합)이 존재
- 모델에게 중요한 것은 인터페이스가 아닌 업무 규칙
경계선과 화살표의 방향과 의미
- GUI와 BusinessRules가 경계선에 의해 분할됨
- GUI가 BusinessRules를 신경쓰는 것을 알 수 있음
3. 플러그인 아키텍처
- 업무 규칙과 무관한 컴포넌트 추가는 시스템에서 서드파티 플러그인을 사용할 수 있도록한 패턴과 동일
- 사용자 인터페이스는 플러그인 형태로 고려되었기 때문에 수 많은 사용자 인터페이스를 플러그인 형태로 연결 가능
- DB도 마찬가지로 플러그인으로 다루기로 결정했기 때문에 다양한 임의의 DB 기술로 대체 가능
4. 플러그인과 단일책임 원칙
- 경계는 변경의 축(
axis of change)이 있는 지점에 그어짐 - 업무 규칙과 다른 시점에, 다른 속도로 변경되는 컴포넌트와 업무 규칙 사이에는 반드시 경계가 필요함
- 시스템을 플러그인 아키텍처로 배치하면 변경이 전파될 수 없는 방화벽 생성 가능
5. 결론
소프트웨어 아키텍처에 경계선 긋기
- 시스템을 컴포넌트 단위로 분할
- 컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 업무를 향하도록 이들 컴포넌트의 소스를 배치
컴포넌트 분류
- 핵심 업무 규칙
- 플러그인: 핵심 업무와는 직접적인 관련이 없지만 필수 기능 포함
소프트웨어 경계의 의미?
- 의존성 역전 원칙과 안정된 추상화 원칙 응용
- 의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치됨
용어 정리
플러그인 아키텍처
플러그인 아키텍처의 정의
- 시스템의 핵심은 고수준 정책(비즈니스 규칙)으로 구성되고, 저수준 구현(세부사항)은 나중에 ‘꽂는(plug-in)’ 방식으로 설계하는 아키텍처 패턴
- 즉, 시스템의 주요 동작은 추상화된 인터페이스에 의존하고, 구체적인 구현은 외부에서 독립적으로 연결될 수 있도록 만든 구조
예시
[ Core Application ]
↑ ↑
[ DB 구현 ] [ UI 구현 ]
[ Mail 구현 ] [ Logger 구현 ]- 핵심 정책(Core)은 인터페이스만 알고 있음
- DB, 웹서버, UI, 파일시스템 같은 외부 구현은 플러그인처럼 꽂힘
- DIP(Dependency Inversion Principle)를 통해 의존성 방향을 추상 쪽으로 역전
플러그인 아키텍처 적용 사례
| 사례 | 설명 |
|---|---|
| 스프링의 DI + @Configuration | 구체 구현체(Repository, Service 등)를 @Bean으로 등록해 플러그인처럼 주입 |
| JVM의 SPI (Service Provider Interface) | 런타임에 원하는 구현체를 꽂을 수 있게 하는 대표적인 플러그인 메커니즘 |
| IntelliJ 플러그인 구조 | 에디터 자체는 코어, 사용자 기능은 전부 플러그인으로 분리되어 로딩 가능 |
클린 아키텍처에서의 구조화
[ Entities ]
↑
[ Use Cases / Interactors ]
↑
[ Interface Adapters (Controller, Gateway) ]
↑
[ Frameworks & Drivers (DB, Web, UI, External APIs) ]- 안쪽 계층은 바깥쪽 계층을 몰라도 됨
- 바깥쪽 계층은 안쪽 계층의 인터페이스에 맞춰서 구현
- 바깥 계층은 안쪽을 의존하지 않고 “플러그인”처럼 연결됨
