[소프트웨어 아키텍처] 레이어드 아키텍처(Layered Architecture)란?

1. 개요

Spring Boot로 애플리케이션을 개발할 때, 흔히 `Controller` -> `Service` -> `Repository` 구조를 사용한다.

서비스가 확장되어 도메인이 복잡해질수록 Service 레이어의 불분명한 책임으로 인해 코드 복잡도가 증가하고, 그로 인해 유지보수에 어려움을 겪을 수 있다.

이처럼 불분명한 계층 구조는 유지보수성과 확장성 모두에 걸림돌이 될 수 있다.

 

실무 관점에서 이러한 복잡성 문제를 어떻게 관리할 수 있을지 인사이트를 얻기 위해, 레이어드 아키텍처에 대해서 정리해보자.

 

2. 레이어드 아키텍처란?

레이어드 아키텍처는 애플리케이션을 관심사를 분리하기 위해 책임 단위로 계층화하여 설계하는 방법이다.

관심사를 분리하면, 특정 로직이 변경되더라도 해당 로직이 속한 레이어만 수정하면 되므로 유지보수성이 향상된다.

 

또한, 상위 레이어는 하위 레이어를 의존하지만 하위 레이어는 상위 레이어를 의존하지 않는다. (단방향)

하위 레이어는 상위 레이어에 대해서 몰라야 하며, 하위 레이어는 단지 인터페이스만 제공할 뿐이다.

이를 통해 계층 간 결합도를 줄이고 유연성을 확보할 수 있다.

 

흔히 사용하는 `Controller` -> `Service` -> `Repository` 구조도 사실상 레이어드 아키텍처의 한 형태이다.

 

레이어드 아키텍처의 장점에 대해서 정리해보면

• 계층 간 책임이 명확해진다.
• 코드의 일관성과 유지보수성이 향상된다.
• 확장에 용이하며 복잡성을 낮춘다.

 

3. 레이어드 아키텍처의 구성

레이어드 아키텍처에는 정답은 없으며, 프로젝트 요구사항과 복잡도에 따라 계층을 나누는 기준은 달라진다.

가장 대표적인 레이어 구성은 다음과 같다. 다시 한 번 강조하지만 정답은 없다!!

 

Presentation -> Business -> Persistence -> Database

Presentation Layer

• 사용자와 시스템 간의 상호작용을 담당
• 요청을 받아 처리하고 응답을 반환
• 예) Controller, RestController

Business Layer

• 핵심 비즈니스 로직을 구현하는 부분
• Presentation Layer로 부터 받은 요청을 실제로 처리
• 예) Service, UseCase

Persistence Layer

• 데이터 영구 저장과 관리를 담당
• 데이터베이스와 직접 상호작용
• 예) JpaRepository, MyBatis, DAO

Database Layer

• 실제 데이터가 저장되는 물리적 데이터베이스
• 예) MySQL, Redis, AWS RDS 등

 

4. 느낀점

레이어를 무작정 나누는 것보다 팀 구성, 프로젝트 규모, 도메인 복잡도 등을 고려하여 책임을 명확히 정의하고 계층을 설계하는 것이 핵심이다.

특히, 프로젝트 규모가 커질수록 레이어 설계는 점점 더 중요해지며, 명확한 아키텍처 설계가 장기적인 유지보수성과 확장성에 큰 차이를 만든다.