레이어드 아키텍처는 소프트웨어 시스템을 관심사(Concern) 별로 수직적으로 분리하여 구성하는 아키텍처 스타일입니다. 관심사란 예를 들어 "사용자 인터페이스 처리", "비즈니스 로직", "데이터 저장/조회"처럼 유사한 책임이 모인 영역을 뜻합니다.
대표적으로는 아래의 3계층으로 구성됩니다:
1. Presentation Layer (표현 계층)
- 사용자 입력을 받고, 결과를 사용자에게 반환
- 웹의 경우 Controller가 여기에 해당
- 사용자 경험(UI/UX)과 연동되는 영역
2. Domain Layer (도메인 계층)
- 비즈니스 규칙과 로직을 담당
- Service, UseCase 등이 이 계층에 위치
- 핵심 규칙이 이곳에 모여야 유지보수에 유리함
3. Data Source Layer (데이터 소스 계층)
- 데이터베이스, 외부 API 등과 직접 통신
- Repository, DAO 등이 포함됨
- 기술적 세부사항을 이 레이어에서 추상화
🔎 이외에도 DTO 매핑을 담당하는 Application Layer를 분리하거나, CQRS 구조에서는 Read/Write Layer를 분리하는 등 확장도 가능합니다.
✅ 레이어드 아키텍처의 장점
- 관심사의 분리 (Separation of Concerns): 코드의 역할이 명확하게 나뉘어 유지보수가 쉬워짐
- 테스트 용이성: 각 레이어를 독립적으로 테스트 가능
- 유연한 변경 및 확장: 도메인 로직은 그대로 두고 표현/데이터 계층만 바꾸는 것도 가능
- 팀 간 역할 분담에 유리: 각 레이어에 따라 담당자가 나뉘는 조직에서 효율적
⚠️ 싱크홀 안티패턴(Sinkhole Anti-Pattern)
레이어드 아키텍처에서는 상위 레이어 → 중간 레이어 → 하위 레이어로 요청이 흐르는데, 가끔 중간 레이어(Service)가 아무 일도 하지 않으면서 단순히 하위 레이어의 메서드를 호출만 하는 경우가 생깁니다.
예시 코드:
@Service
public class OrderService {
private final OrderDao orderDao;
public OrderResponse getOrder(Long orderId) {
// 아무 비즈니스 로직도 없이 단순 전달
return orderDao.getOrderById(orderId);
}
}이러한 구조를 싱크홀 안티패턴이라 부릅니다.
❌ 문제점
- 단순 위임만 하는 코드가 중복됨
- CPU/메모리 자원 낭비
- 변경 시에도 의미 없이 많은 파일이 변경될 수 있음
- 중간 레이어의 존재 이유가 희미해짐
✅ 싱크홀을 무조건 피해야 할까?
항상 그런 것은 아닙니다.
- 일관된 아키텍처 구조 유지를 위해 중간 레이어를 통일적으로 두는 것도 중요할 수 있습니다.
- 중간 레이어가 나중에 로직이 추가될 수도 있고, 테스트 포인트로도 사용될 수 있습니다.
- 중요한 것은 "일관성 있는 팀의 규칙"과 "미래의 확장성 고려"입니다.
📘 추천 참고 자료
✍️ 마무리 정리
레이어드 아키텍처는 명확한 책임 분리를 통해 소프트웨어 구조를 정돈할 수 있는 강력한 도구입니다. 하지만 구조만 따르다 보면 형식적인 계층 분리에 그쳐 싱크홀 안티패턴과 같은 비효율이 발생할 수 있습니다.
중요한 것은 "왜 이 계층이 존재하는가?", "어떤 책임을 맡아야 하는가?"에 대한 고민입니다. 팀의 상황, 프로젝트의 복잡도, 유지보수 주체에 따라 유연하게 적용해보세요.
사진 출처
알고리즘은 백준 허브를 통해 github에 꾸준히 올리고 있습니다.🙂