BackEnd

[BackEnd]클린 아키텍쳐가 뭐임?

hej090224 2025. 9. 17. 17:58

클린 아키텍쳐의 탄생

클린 아키텍쳐란 Robert C. Martin라는 개발자 아저씨가 만든

소프트웨어 설계 원칙입니다.

이 개발자 아저씨는 기존에 개발을 하면서 

프레임워크나 라이브러리 변경 시에 비즈니스 로직까지 영향을 받아서

유지보수가 어려워지거나

DB나 웹에 너무 강하게 결합된 비즈니스 로직이 생기고,

코드가 확장될수록 기능을 추가하거나 변경할 때

코드 복잡도가 미친 수준이 되는 문제점을 발견했습니다.

 

그래서 이러한 문제점을 해결하기 위해서

비즈니스 규칙을 프레임워크 / 인프라와 독립시키고

의존성은 추상화를 통해 제어하며

테스트가 쉽고 간편한 클린 아키텍쳐라는

구조를 만들게 되었습니다.

(책과 강연 등으로 클린 아키텍쳐를 홍보하고 다니기도 했다고 하네요)

 

클린 아키텍쳐의 개념

클린 아키텍쳐는 소프트웨어를 계층으로 나누고

의존성 규칙을 지키도록 강제하게 하는

아키텍쳐 패턴입니다.

 

위 그림은 보통 클린 아키텍쳐를 설명할 때 활용되는 그림입니다.

가장 바깥쪽 원부터 안쪽으로 프로그램이 흘러가게 됩니다.

그렇다면 사진에 나와있는 핵심 계층들은 각각 어떤 역할을 할까요? 

 

안쪽부터 순서대로 설명하자면

 

1. Entities (엔티티)

시스템에서 가장 중요한 비즈니스 개념과 규칙을 담는 계층입니다.

제가 만든 예시 코드에서는 Board.java가 엔티티입니다.

이는 순수한 도메인 객체입니다.

 

2. Use Cases (유스 케이스)

사용자의 요청을 처리하는 흐름을 정의하는 계층입니다.

비즈니스 시나리오를 구현합니다.

예시 코드에서는 BoardUseCase.java가 포트와 인터페이스이고

BoardService.java가 구현체 입니다.

 

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

UI나 DB와 같은 도메인 계층 간 데이터 변환을 담당합니다.

예시 코드에서는 

BoardController.java가 Web Adapter이고 

BoardPersistenceAdapter.java는 Persistence Adapter 입니다.

 

4. Frameworks와 Drivers (프레임워크와 드라이버)

Spring이나 JPA, DB 같은 실행환경 입니다.

가장 바깥쪽에 있고 언제든지 교체가 가능해야 하며

도메인 계층을 오염시키지 않아야 합니다.

 

클린 아키텍쳐의 원칙

클린 아키텍쳐를 활용하여 간결하고 유지보수가 간편한

프로그램을 구성하기 위한 규칙이 대표적으로 3가지 존재하는데

다음과 같습니다.,

 

첫번째로 의존성 규칙입니다.

안쪽 계층은 바깥 계층을 몰라야 하며 바깥 계층만 안쪽 계층을 참조할 수 있습니다.

덕분에 핵심 비즈니스 로직은 DB나 프레임워크, UI와 같은 기술에

영향을 받지 않고 독립적으로 유지됩니다.

 

두번째로는 의존성 역전 원칙입니다.

고수준 로직은 저수준 구현에 직접 의존하지 않고 추상화된 인터페이스에 의존합니다.

실제 구현은 바깥 계층의 어댑터가 담당하며

이를 통해 데이터베이스 교체나 기술 변경이 자유로워집니다.

 

세번째는 독립성 확보입니다.

시스템은 특정 기술에 종속되지 않아야 하며

필요에 따라 UI를 웹에서 앱으로 바꾸거나 데이터베이스를

MySQL에서 MongoDB로 교체할 수 있습니다.

심지어 프레임워크도 교체할 수 있어 유지보수와 확장이 훨씬 쉬워집니다.

 

이상으로 블로그를 마치겠습니다. 읽어주셔서 감사합니다.

추가로 공부해서 예시코드나 장단점 등등

블로그를 더 길게 작성하고 싶었지만 개인적으로 조금 아쉬운 블로그라고 생각합니다.

다음에 시간적 여유가 생기면 더 보충해서 적도록 하겠습니다.