Post

클린 아키텍처에 대한 고찰

클린 아키텍처에 대한 고찰

🎯 배경

회사 프로젝트를 진행하면서 항상 3계층 아키텍처를 사용했습니다. 기존에는 자바 11과 스프링 부트 2.X 버전을 사용하고 있었는데, 어느 날 프로젝트의 버전을 자바 21과 스프링 부트 3.X 버전으로 업그레이드해야 했습니다. 버전을 올리면서 수많은 의존 관계가 뒤엉켜 있었습니다.

한땀한땀 의존 관계를 수정하는 작업을 해야 했고, 이 과정에서 작업이 생각보다 많은 공수를 필요로 한다는 것을 깨달았습니다. 이를 계기로 어떻게 하면 의존 관계를 최소화하면서 유지보수를 쉽게 할 수 있을지 고민하게 되었고, 그 결과 Robert C. Martin이 제안한 클린 아키텍처를 알게 되었습니다.

클린 아키텍처는 소프트웨어의 핵심 비즈니스 로직과 외부 의존성들을 명확하게 분리하여 시스템의 유연성과 확장성을 높이는 아키텍처 패턴입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 예시 코드
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private PaymentRepository paymentRepository;
    
    // ... 여러 Repository를 사용하는 복잡한 비즈니스 로직
}

이렇게 하나의 서비스에서 여러 Repository를 사용하면서 의존성이 복잡해지면, 버전 업그레이드 시 각 Repository의 변경사항을 모두 고려해야 하는 문제가 발생합니다. 이는 결국 전체 코드베이스를 수정해야 하는 상황으로 이어지게 됩니다.

이런 문제를 해결하기 위해 클린 아키텍처의 의존성 역전 원칙을 적용하면, 핵심 비즈니스 로직과 외부 계층을 명확히 분리하여 프레임워크 변경의 영향을 최소화할 수 있습니다.

⚙️ 핵심 내용 (What & How)

  • 전통적인 3계층 아키텍처의 문제점
  • 클린 아키텍처의 핵심 원칙
  • 클린 아키텍처의 장점
  • 클린 아키텍처에 대한 나의 생각

🔑 결과와 인사이트 (So what?)

전통적인 3계층 아키텍처의 문제점

전통적인 3계층은 controller, service, repository로 구성되어 있습니다. 이들은 서로가 어떤것을 표현하는지 분명하게 보여줍니다. 예를들어 Controller는 사용자 요청을 받아서 서비스로 전달하고, Service는 비즈니스 로직을 처리하고, Repository는 데이터를 저장하고 조회하는 역할을 합니다. 일반적으로 Controller는 Service를 호출하고, Service는 Repository를 호출하는 구조를 가지게 됩니다.

문제는 다음과 같습니다:

  1. 의존성 관리의 어려움
alt text
  • 하나의 서비스에서 여러 Repository를 사용하면 의존성이 복잡해짐
  • 외부에서 들어온 요청 처리가 어려워짐
  • 코드베이스가 커질수록 유지보수가 어려워짐
  1. 변경 시 전체 영향 고려
alt text
  • 하나의 Repository 변경 시 전체 서비스 영향 고려 필요
  • 버전 업그레이드 시 전체 코드베이스 수정 필요
  • 의존성 관계가 뒤엉켜 있어 추적 어려움
  1. 모듈화의 어려움
alt text
  • 비즈니스 로직과 데이터 접근이 결합되어 있음
  • 독립적인 모듈 개발이 어려움
  • 테스트 코드 작성도 어려움

즉, 의존성 관리와 모듈화를 강제적으로 해결할 방법이 필요합니다. 이것을 해결하기 위해 클린 아키텍처라는 방법을 사용할 수 있습니다. 클린 아키텍처는 강제적으로 의존관계를 분리하여 유지보수를 쉽게 할 수 있도록 도와줍니다.

클린 아키텍처에 대한 나의 생각

내가 생각하는 클린 아키텍처의 핵심 원칙은 내부와 외부의 명확한 경계라 생각합니다. 이말은 관심사의 분리라고 생각합니다.

클린 아키텍처 철학에 따라 대표적인 아키텍처는 레이어드 4계층과 헥사고날 아키텍처가 있습니다. 그렇다고해서, 저 아키텍처를 사용해야 클린 아키텍처를 사용하는 것은 아니라고 생각합니다.

클린아키텍처는 철학일뿐이고, 구현은 자유라 생각합니다. 또한, DDD와 클린아키텍처는 전혀 무관하다고 생각합니다.

DDD는 도메인으로 모델링하는 것이 목적이지만, 클린아키텍처는 철학일뿐이라 생각합니다.

결국, 저러한 패턴을 사용해야 클린 아키텍처를 사용하는것은 아니지만, 저 패턴들을 사용하게 되면 강제적으로 클린 아키텍처를 구현하는데 도움이 될뿐이라고 생각합니다.

📝 요약 (One-liner)

  • 전통적인 3계층 아키텍처의 문제점과 클린 아키텍처의 핵심 철학을 다룬 글입니다.
  • 클린 아키텍처는 내부와 외부의 명확한 경계 설정을 통해 의존성을 분리하고,
  • 이를 통해 유지보수를 용이하게 합니다.
  • 클린 아키텍처는 철학이며, 구체적인 구현 패턴은 자유롭습니다.
This post is licensed under CC BY 4.0 by the author.