Chat Conversation

"클린 아키텍쳐"는 로버트 C. 마틴(Uncle Bob)이 제시한 소프트웨어 설계 철학으로, 변경에 유연하고 테스트하기 쉬우며 유지보수가 가능한 시스템을 구축하는 방법을 다룹니다. 핵심은 의존성을 안쪽으로 향하게 하는 계층형 구조를 통해 비즈니스 로직을 외부 세계로부터 독립시키는 것입니다. 로버트 마틴의 "클린 아키텍쳐"는 소프트웨어 설계의 핵심 원칙들을 체계적으로 정리한 필독서입니다. 복잡한 시스템을 어떻게 관리 가능하고 유지보수하기 쉽게 만들지에 대한 실용적 가이드를 제공합니다.

핵심 원칙: SOLID

Single Responsibility Principle (SRP)

• 모든 모듈은 단 하나의 변경 이유만 가져야 함
• 클래스나 함수가 여러 책임을 지면 결합도가 높아져 수정이 어려워짐

Open-Closed Principle (OCP)

• 확장에는 열려있고, 수정에는 닫혀있어야 함
• 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있어야 함

Liskov Substitution Principle (LSP)

• 상위 타입의 객체를 하위 타입 객체로 치환해도 프로그램이 정상 동작해야 함

Interface Segregation Principle (ISP)

• 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 됨

Dependency Inversion Principle (DIP)

• 상위 수준 모듈은 하위 수준 모듈에 의존하면 안 됨
• 둘 다 추상화에 의존해야 함

클린 아키텍쳐의 4계층 구조

엔티티 (Entities)

• 비즈니스 규칙과 데이터를 캡슐화
• 가장 안정적이며 변경 빈도가 낮음
• 외부 변화에 영향받지 않는 핵심 비즈니스 로직

유스케이스 (Use Cases)

• 애플리케이션별 비즈니스 규칙
• 엔티티의 데이터 흐름을 조율
• 시스템의 행동을 정의

인터페이스 어댑터 (Interface Adapters)

• 유스케이스와 외부 세계 사이의 변환
• 컨트롤러, 게이트웨이, 프레젠터 포함
• 데이터 형식을 내부용과 외부용으로 변환

프레임워크와 드라이버 (External Interfaces)

• 데이터베이스, 웹 프레임워크, UI 등
• 가장 바깥쪽 계층으로 변경 빈도가 높음

의존성 규칙

핵심 규칙: 의존성은 항상 안쪽으로 향해야 함

• 외부 계층이 내부 계층을 알 수 있지만, 내부는 외부를 알면 안 됨
• 내부 계층은 외부 계층의 변화에 영향받지 않음
• 이를 통해 비즈니스 로직이 기술적 세부사항으로부터 독립됨

경계선과 플러그인 아키텍쳐

아키텍쳐 경계

• 서로 다른 관심사를 분리하는 선
• 단방향 의존성 유지
• 경계를 넘나드는 데이터는 간단한 구조여야 함

플러그인 패턴

• 모든 것을 플러그인으로 취급
• 데이터베이스는 비즈니스 로직의 플러그인
• UI도 비즈니스 로직의 플러그인
• 비즈니스 로직이 중심이고 나머지는 세부사항

컴포넌트 설계 원칙

컴포넌트 응집도

• REP (Reuse/Release Equivalence): 재사용 단위 = 릴리스 단위
• CCP (Common Closure Principle): 동시에 변경되는 클래스를 묶기
• CRP (Common Reuse Principle): 함께 재사용되는 클래스를 묶기

컴포넌트 결합도

• ADP (Acyclic Dependencies Principle): 순환 의존성 금지
• SDP (Stable Dependencies Principle): 안정적 방향으로 의존
• SAP (Stable Abstractions Principle): 안정적일수록 추상적이어야 함

실무 적용 가이드

데이터베이스는 세부사항

• 비즈니스 로직이 특정 데이터베이스에 의존하면 안 됨
• Repository 패턴으로 추상화
• 언제든 MySQL에서 MongoDB로 변경 가능해야 함

웹은 입출력 장치

• 웹 프레임워크는 전달 메커니즘일 뿐
• 비즈니스 로직은 HTTP를 알 필요 없음
• REST API든 GraphQL이든 쉽게 교체 가능

테스트 가능한 아키텍쳐

• 의존성 주입을 통한 모킹
• 단위 테스트가 쉬워짐
• 외부 의존성 없이 비즈니스 로직 테스트 가능

마이크로서비스와 클린 아키텍쳐

서비스는 아키텍쳐가 아니다

• 마이크로서비스 자체가 아키텍쳐를 만들어주지 않음
• 각 서비스 내부도 클린 아키텍쳐를 적용해야 함
• 서비스 경계는 아키텍쳐 경계와 다름

적절한 분리

• 기능별 분리보다는 변경 이유별 분리
• 비즈니스 규칙에 따른 자연스러운 분할
• 팀 구조와 서비스 구조의 일치 (Conway의 법칙)

클린 아키텍쳐의 핵심은 비즈니스 로직을 기술적 세부사항으로부터 분리하는 것입니다. 이를 통해 시스템이 변화에 유연하게 대응하고, 테스트하기 쉬우며, 이해하기 쉬운 구조를 만들 수 있습니다. 단순히 계층을 나누는 것이 아니라, 의존성의 방향을 제어하여 안정적이고 확장 가능한 시스템을 구축하는 것이 목표입니다.