클린 아키텍처 이해하기

개요

지금까지 여러 프로젝트를 진행하면서 레이어드 아키텍처를 사용해 왔습니다. 가장 처음 접한 아키텍처였고, 익숙했기 때문에 자연스럽게 선택해 왔습니다. 하지만 시간이 지날수록 레이어드 아키텍처에 대한 의문이 생겼습니다.

 

패키지 구조가 한눈에 들어오지 않았고, 새로운 클래스를 생성할 때마다 어디에 위치시켜야 할지 고민하는 시간도 많아졌습니다. 기능을 추가하거나 수정할 때도 같은 문제가 반복되었습니다.

이런 경험이 쌓이면서 자연스럽게 다른 아키텍처에 관심이 생겼습니다. 클린 아키텍처와 헥사고날 아키텍처, 이전부터 많이 들어봤지만, 당시에는 크게 와닿지 않았고, 이해 없이 적용하려 하니 어렵게만 느껴져 미뤄두었습니다.

 

하지만 앞서 언급한 문제들이 계속되면서 이제는 제대로 이해하고 적용해 봐야겠다는 생각이 들었습니다. 그러다 우연히 만들면서 배우는 클린 아키텍처라는 책을 알게 되었고, 이 책을 읽으며 클린 아키텍처에 관한 내용과 저의 생각을 정리해 보려 합니다.

 

레이어드 아키텍처의 문제점

책에서는 레이어드 아키텍처가 가지는 몇 가지 문제점을 지적합니다. 그중 가장 와닿는 부분은 데이터베이스 주도 설계로 흐르기 쉽다는 점이었습니다. 예를 들어, 흔히들 사용하는 ORM 프레임워크의 @Entity, @JoinColumn 등의 어노테이션이 적용된 엔티티 클래스가 대표적입니다.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class HouseWork {

	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;

	private String name;

	@ManyToOne
	@JoinColumn(name = "place_id")
	private Place place;

	@ManyToOne
	@JoinColumn(name = "house_work_group_id")
	private Group group;

    ...
    
}

 

이처럼 엔티티가 JPA 어노테이션에 묶여 있다 보니 서비스 계층이 영속성 모델을 곧 비즈니스 모델처럼 사용하는 문제가 생기고, 결국 영속성 계층과 도메인 계층 사이에 강한 결합이 형성됩니다. 또한 JPA 스펙상 private가 아닌 기본 생성자가 반드시 필요하다는 점도 프레임워크에 대한 의존성을 드러내는 예시라 할 수 있습니다. 

 

이런 식으로 도메인이 영속성에 의존하게 된다면, 서비스가 JPA 엔티티를 직접 다루기 때문에 데이터베이스 구조가 바뀌었을 때 그 변화가 곧바로 도메인과 비즈니스 로직에 영향을 미치게 됩니다. 즉, 의존성의 방향이 안쪽(도메인)으로 향하지 않고 바깥쪽으로 향하는 상태입니다.

 

또 다른 문제는 레이어드 아키텍처의 단순한 규칙성입니다. "특정 계층은 같은 계층이나 하위 계층에만 접근할 수 있다."는 정도의 규칙만 존재하다 보니, 구조적 제약이 약하고 편의 위주의 방향으로 흘러갈 수 있습니다. 이는 결국 코드를 지저분하게 만들어 유지보수성을 떨어뜨리게 되는데, 대표적인 예가 다음과 같이 비대해진 서비스 클래스입니다.

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class HouseWorkService {

	private final HouseWorkRepository houseWorkRepository;
	private final HouseWorkTagRepository houseWorkTagRepository;
	private final HouseWorkMemberRepository houseWorkMemberRepository;
	private final EmotionCardRepository emotionCardRepository;

	private final MemberService memberService;
	private final GroupService groupService;

	public List<HouseWorkStatusByPeriodResponse> getHouseWorkStatusByPeriod(
		Long groupId,
		LocalDate from,
		LocalDate to
	) {
		List<HouseWorkStatusByPeriodResponse> responses = new ArrayList<>();
		List<LocalDate> result = houseWorkRepository.findTaskDatesBetween(groupId, from, to);
		for (LocalDate date = from; !date.isAfter(to); date = date.plusDays(1)) {
			responses.add(new HouseWorkStatusByPeriodResponse(date, result.contains(date)));
		}
		return responses;
	}
    
    @Transactional
	public void completeHouseWork(Long memberId, Long houseWorkId) {
		if (!houseWorkMemberRepository.existsByHouseWorkIdAndMemberId(houseWorkId, memberId)) {
			throw new IllegalStateException("Not authorized");
		}

		HouseWork houseWork = findById(houseWorkId);
		houseWork.markCompleted();
	}
    
    ...
    
}

(실제 코드 전체는 약 500줄에 달하는 상당히 뚱뚱한 서비스 클래스입니다.)

 

이처럼 비대해진 서비스는 여러 영속성 계층에 의존하게 되고, 많은 웹 계층 또한 이 서비스에 의존하게 됩니다. 그 결과, 각 기능(유스케이스)의 책임이 어디에 있는지 찾기 힘들어지고, 새로운 기능을 추가하거나 기존 로직을 수정할 때 영향받는 범위를 예측하기 힘들어집니다.

 

저 역시 프로젝트를 진행하며 비대해진 서비스로 인해 직접 겪은 문제점이 있습니다. 팀 단위로 개발할 경우, 서로 다른 기능을 구현하더라도 같은 서비스 클래스 내에서 작업하다 보니 코드 충돌이 빈번하게 발생했습니다. 그로 인해 병합 시 충돌을 해결해야 하는 번거로운 상황을 자주 만났던 경험이 있습니다.

 

이 외에도 여러 문제점이 존재하는데, 결국 공통된 문제는 코드의 이해와 테스트를 어렵게 만들고, 그로 인해 유지보수가 어려워진다는 점입니다.

 

클린 아키텍처란

클린 아키텍처는 앞서 언급한 레이어드 아키텍처의 문제점들을 해결할 수 있는 방향을 제시합니다.

 

가장 핵심적인 원칙은 의존성에 대한 것으로, 도메인 계층을 중심으로 계층 간의 모든 의존성이 안쪽으로만 향해야 한다는 것입니다. 도메인은 비즈니스의 본질을 표현하는 영역으로, 다른 계층에 비해 변경 가능성이 가장 낮은 안정적인 영역입니다. 반면 외부 요소(UI나 데이터베이스 등)는 기술 변화나 요구사항에 따라 자주 바뀌는 영역입니다.

따라서 의존성을 안쪽으로 향하게 함으로써 외부 계층의 변경이 도메인에 영향을 미치지 않도록 해야 합니다. 예를 들어, 어떤 데이터베이스가 사용되는지, UI에 대한 요구사항이 어떻게 바뀌는지 등, 도메인에서는 이런 것들을 전혀 알 필요가 없습니다.

 

또한 클린 아키텍처에서는 유스케이스(서비스)를 기존보다 세분화합니다. 이를 통해 단일 책임 원칙(SRP)을 준수할 수 있고, 각 기능이 명확히 분리되어 테스트가 쉬워집니다.

 

이전처럼 하나의 거대한 서비스 클래스에서 여러 기능을 함께 다룰 때 겪던 불편함도 줄어듭니다. 그 결과, 코드의 구조가 명확해지고, 기능 추가나 변경이 쉬워지며, 팀 단위 협업에서도 동시 작업이 훨씬 수월해집니다.

 

물론 클린 아키텍처에도 단점은 존재합니다. 의존성 방향을 지키고 각 계층의 책임을 명확히 하다 보면 구조가 다소 복잡해지고, 구현 과정이 번거로워질 수 있습니다. 예를 들어, JPA 엔티티는 영속성 계층에서 관리해야 하므로 도메인 계층에는 별도의 엔티티 클래스를 따로 관리해야 하는 번거로움이 있습니다. 또한 프로젝트의 규모가 크지 않거나 주어진 개발 기간이 짧을 경우, 이러한 구조적 복잡함이 오히려 개발 효율을 떨어뜨리는 원인이 될 수도 있습니다.

 

마무리

결국 클린 아키텍처를 지향하되, 맹신하지는 말아야 한다고 생각합니다. 클린 아키텍처가 제시하는 원칙들은 모두 깨끗한 구조를 유지하는 데 큰 도움이 되지만, 상황에 따라서는 오히려 비효율을 초래할 수도 있습니다.

 

저의 경험을 예로 들면 8주간의 IT 동아리 활동 중 실제 개발 기간이 약 3주 정도밖에 되지 않았습니다. 만약 그 상황에서 클린 아키텍처를 꼼꼼히 적용하려 했다면 아마 마감 기한을 맞추기 어려웠을 것입니다.

 

이처럼 시간이 촉박한 상황에서는 단순한 구조로 빠르게 구현하는 것도 충분히 좋은 선택지라고 생각합니다. 예를 들어, 웹 계층과 서비스 계층 간의 의존성은 이미 도메인 방향으로 향해있기 때문에 굳이 포트를 두지 않는 방식으로 단순화할 수 있습니다.

이후 프로젝트가 좀 더 복잡해지거나 유지보수에 여유가 생긴 시점에 클린 아키텍처를 점진적으로 적용하는 접근이 더 현실적인 방안이 될 수 있다고 생각합니다.

 

하지만 유지보수에 용이한 코드가 좋은 코드라는 생각에는 변함이 없습니다. 책에서는 "깨진 유리창 이론"을 언급하는데, 이는 깨진 유리창 하나를 방치하면 그 주변으로 범죄가 확산된다는 이론입니다. 코드 역시 마찬가지입니다. 사소해 보이는 규칙 위반을 방치하다 보면 그 누적이 쌓여 코드 품질이 점점 떨어지고, 결국 레거시 코드로 변하게 될 것입니다. 저 또한 프로젝트를 진행하면서 이런 과정을 직접 경험했기에 이 부분에 특히 공감이 됐습니다.

 

앞으로 진행할 프로젝트에서는 레이어드 아키텍처에서 벗어나, 클린 아키텍처의 핵심 원칙을 바탕으로 시간이 지나도 견고하고 유지보수하기 쉬운 구조를 만들어가고자 합니다.