Back to Articles
아키텍쳐architectureBackendlayered

레이어드 아키텍쳐 vs 헥사고날 아키텍쳐

구성 방식, 의존성 방향, 순환참조 해결 전략까지 실무 관점에서 비교해봅니다

2026.06.103 min read변경연
author
postNo
status
thumbnail
description
category
tags
createdAt
updatedAt

시작하며

프로젝트 구조를 이야기할 때 자주 나오는 주제가 있다.
Layered Architecture 와 Hexagonal Architecture 는 무엇이 다를까?
둘 다 코드를 역할별로 나누고 복잡도를 낮추기 위한 구조이기 때문에 비슷해 보인다.
하지만 실제로는 무엇을 중심에 두는지, 의존성이 어디를 향하는지, 외부 기술을 어떻게 격리하는지 에서 차이가 꽤 크다.
그리고 여기서 한 가지 더 중요한 질문이 있다.
이런 아키텍쳐를 쓰면 순환참조도 자동으로 사라질까?
내 생각은 아니다 이다.
좋은 아키텍쳐는 순환참조를 줄이는 데 도움을 주지만, 순환참조를 해결하는 만능 열쇠는 아니다. 결국 순환참조는 의존성의 성격 을 보고 풀어야 한다.
이번 글에서는 다음 내용을 정리해보려고 한다.
  1. Layered Architecture 는 어떻게 구성되는가
  1. Hexagonal Architecture 는 어떻게 구성되는가
  1. 둘의 핵심 차이는 무엇인가
  1. 순환참조는 왜 생기고 어떻게 해결해야 하는가

한 줄로 먼저 정리하면

  • Layered Architecture 는 역할을 층으로 나누는 구조이다.
  • Hexagonal Architecture 는 도메인을 중심에 두고 바깥과의 연결을 Port 와 Adapter 로 감싸는 구조이다.
즉, Layered 는 계층 구조 로 바라보고, Hexagonal 은 핵심 보호 구조 로 바라본다.

Layered Architecture 는 어떻게 구성되는가

Layered Architecture 는 가장 익숙한 백엔드 구조이다.
보통 아래와 같은 계층으로 나눈다.
  • Presentation Layer
  • Application Layer
  • Domain Layer
  • Infrastructure Layer
Layered Architecture 구조
Layered Architecture 구조
위 그림처럼 보통 상위 레이어가 하위 레이어를 호출하는 구조를 가진다.
Presentation -> Application -> Domain -> Infrastructure

1. Presentation Layer

사용자의 요청을 직접 받는 계층이다.
  • HTTP Controller
  • GraphQL Resolver
  • Request Validation
  • Response Mapping
여기서는 비즈니스 로직을 최대한 적게 두고, 입력과 출력의 형식을 맞추는 역할에 집중하는 것이 좋다.

2. Application Layer

유스케이스를 실행하는 계층이다.
  • 트랜잭션 처리
  • 여러 도메인 조합
  • DTO 변환
  • 흐름 제어
실무에서는 흔히 Service 라고 부르는 계층이 여기에 해당한다.
예를 들어 주문 생성, 환불 처리, 회원 탈퇴 같은 유스케이스를 조합하는 역할을 맡는다.

3. Domain Layer

핵심 비즈니스 규칙이 위치하는 계층이다.
  • Entity
  • Value Object
  • Domain Service
  • Policy
할인 규칙, 주문 가능 여부, 상태 전이 같은 비즈니스 규칙은 가능하면 여기 가까이 두는 편이 좋다.

4. Infrastructure Layer

외부 기술과 연결되는 계층이다.
  • DB 접근
  • 외부 API 호출
  • 메시지 큐
  • 메일 발송
  • 프레임워크 연동
즉, 애플리케이션을 둘러싼 기술적인 세부 구현이 위치한다.

Layered Architecture 의 장점과 한계

장점은 분명하다.
  • 구조가 직관적이다.
  • 팀원 대부분이 익숙하다.
  • 작은 프로젝트에서 빠르게 개발을 시작하기 좋다.
  • 프레임워크와 잘 맞는다.
하지만 시간이 지나면 자주 생기는 문제가 있다.
  • Service 에 비즈니스 로직이 과도하게 몰린다.
  • Domain 이 ORM 모델이나 Repository 세부사항에 끌려간다.
  • 계층은 나눴지만 핵심 로직이 흩어진다.
즉, 레이어를 나눴다고 해서 자동으로 좋은 구조가 되지는 않는다.

Hexagonal Architecture 는 어떻게 구성되는가

Hexagonal Architecture 는 Ports and Adapters Architecture 라고도 부른다.
이 구조의 핵심은 간단하다.
핵심 비즈니스 로직은 외부 기술을 몰라야 한다.
DB, 웹 프레임워크, 메시지 큐 같은 것은 바깥에 두고, 안쪽에는 도메인과 유스케이스를 배치한다.
Hexagonal Architecture 구조
Hexagonal Architecture 구조
그림처럼 Hexagonal Architecture 는 보통 아래 요소로 설명할 수 있다.
  • Application
  • Domain
  • Inbound Port / Inbound Adapter
  • Outbound Port / Outbound Adapter

1. Domain

가장 안쪽에 있는 핵심이다.
  • Entity
  • Value Object
  • Domain Rule
  • Domain Policy
여기에는 DB, HTTP, MQ, 프레임워크에 대한 코드가 들어오지 않는 것이 이상적이다.

2. Application

유스케이스를 실행한다.
  • CreateOrderUseCase
  • CancelOrderUseCase
  • IssueCouponUseCase
즉, 시스템이 제공하는 기능 단위를 표현한다.

3. Inbound Adapter

바깥에서 안쪽으로 요청을 전달하는 진입점이다.
  • REST Controller
  • GraphQL Resolver
  • Scheduler
  • Kafka Consumer
중요한 점은 이들이 바로 도메인 세부 구현을 다루는 것이 아니라, 안쪽의 유스케이스를 호출한다는 점이다.

4. Outbound Port

핵심 로직이 바깥에 요구하는 기능의 계약 이다.
예를 들면 이런 인터페이스가 될 수 있다.
LoadUserPort
SaveOrderPort
PublishEventPort
핵심은 무엇이 필요하다 를 표현하고, 어떻게 구현하는지 는 말하지 않는 것이다.

5. Outbound Adapter

Port 의 실제 구현체이다.
  • MySQL Adapter
  • Redis Adapter
  • External API Adapter
  • Message Bus Adapter
즉, Port 를 기술 세부사항으로 연결하는 부분이다.

둘의 가장 큰 차이

둘 다 결국 여러 영역으로 코드를 나누기 때문에 얼핏 보면 비슷하다.
하지만 차이는 경계를 어떻게 자르느냐 와 의존성을 어떻게 통제하느냐 에 있다.

Layered Architecture 의 관점

  • 컨트롤러
  • 서비스
  • 리포지토리
처럼 역할 을 기준으로 나눈다.

Hexagonal Architecture 의 관점

  • 안쪽은 핵심 비즈니스
  • 바깥은 연결부
처럼 중심과 외부 를 기준으로 나눈다.
그래서 Hexagonal Architecture 는 일반적으로 의존성 역전을 더 강하게 요구한다.

요청 하나가 흐르는 방식 비교

예를 들어 주문 생성 기능이 있다고 해보자.

Layered Architecture

OrderController
  -> OrderService
    -> OrderRepository
      -> MySQL
직관적이고 빠르게 구현할 수 있다.
하지만 시간이 지나면 OrderService 가 아래 역할을 모두 떠안는 경우가 많다.
  • 검증
  • 비즈니스 규칙
  • 외부 API 호출
  • 이벤트 발행
  • 저장

Hexagonal Architecture

OrderController(Adapter In)
  -> CreateOrderUseCase
    -> SaveOrderPort
      -> OrderPersistenceAdapter
        -> MySQL
여기서는 유스케이스가 저장이 필요하다는 사실만 알고, 실제 MySQL 구현은 바깥 Adapter 가 담당한다.
이 방식은 테스트 작성과 구현 교체에 유리하다.

순환참조는 왜 생길까

여기서 중요한 포인트가 있다.
Layered Architecture 든 Hexagonal Architecture 든, 구조만 도입한다고 순환참조가 없어지지는 않는다.
순환참조는 주로 아래 상황에서 생긴다.
  • 도메인 A 가 도메인 B 의 기능을 직접 호출한다.
  • 도메인 B 도 다시 도메인 A 를 호출한다.
  • 하나의 유스케이스 안에서 책임 경계가 불분명하다.
  • 읽기 전용 조회와 비즈니스 행동이 뒤섞인다.
예를 들어 이런 식이다.
OrderService -> UserService
UserService -> OrderService
처음에는 편해 보이지만, 결국 모듈 초기화 문제, 테스트 어려움, 변경 파급 증가로 이어진다.

아키텍쳐는 순환참조 해결의 만능이 아니다

Layered Architecture 를 써도 OrderService 와 UserService 가 서로를 호출하면 순환참조가 생긴다.
Hexagonal Architecture 를 써도 OrderUseCase 와 UserUseCase 가 서로의 Port 를 잘못 물고 들어가면 같은 문제가 생긴다.
즉, 문제의 핵심은 아키텍쳐 이름이 아니라 누가 누구를 왜 참조하는가 이다.
순환참조 해결 전략
순환참조 해결 전략
그래서 순환참조는 의존성의 종류 에 따라 풀어야 한다.

순환참조를 해결하는 방법

1. 하나의 유스케이스라면 상위 Orchestrator 로 올린다

가장 흔한 경우다.
OrderService 가 UserService 를 호출하고, UserService 가 다시 OrderService 를 호출하는 이유는 사실 같은 유스케이스를 서로 나눠서 처리하고 있기 때문인 경우가 많다.
이럴 때는 둘 중 하나가 다른 하나를 직접 호출하게 두지 말고, 상위 레벨의 Application Service 또는 UseCase 가 둘을 조합하도록 만드는 편이 낫다.
PlaceOrderUseCase
  -> UserDomain
  -> OrderDomain
즉, 동등한 두 서비스가 서로 부르는 구조 를 상위 조정자가 아래를 호출하는 구조 로 바꾼다.
이 방식은 Layered Architecture 에서도 유효하고, Hexagonal Architecture 에서도 유효하다.

2. 후속 반응이라면 Domain Event 로 분리한다

어떤 기능은 같은 트랜잭션 안에서 즉시 처리할 필요가 없고, 단지 무언가가 일어났음 을 다른 쪽에 알려주면 된다.
예를 들면,
  • 주문 완료 후 알림 발송
  • 회원 탈퇴 후 쿠폰 정리
  • 결제 완료 후 포인트 적립
이런 경우 A 가 B 를 직접 호출하기보다 이벤트를 발행하고, B 가 그 이벤트를 구독하게 만들면 결합도를 낮출 수 있다.
OrderDomain -> OrderPlacedEvent -> PointHandler
다만 이 방식은 같은 동기 흐름으로 강하게 묶여 있는 작업 에 무조건 쓰면 안 된다.
결국 이벤트는 후속 반응을 분리할 때 유용한 것이지, 모든 의존성을 숨기는 도구는 아니다.

3. 읽기 의존성이라면 Query Service 로 분리한다

많은 순환참조는 사실 행동 이 아니라 조회 때문에 생긴다.
예를 들어 주문 도메인이 사용자 이름이나 등급만 읽고 싶은데, 그걸 얻으려고 UserService 전체를 주입하는 식이다.
이럴 때는 아래처럼 읽기 전용 조회를 별도 Query 로 분리하는 편이 훨씬 낫다.
OrderUseCase -> UserLookupQuery
즉, 사용자에 대한 모든 기능 이 아니라 필요한 조회 계약 하나 만 의존하게 만든다.

4. 진짜 공통 규칙이라면 Shared Policy 로 추출한다

서로 다른 두 도메인이 동일한 규칙을 공유한다면, 그 규칙을 한쪽 도메인 소유로 억지로 두지 말고 공통 정책으로 추출하는 것이 낫다.
예를 들면,
  • 권한 판정 규칙
  • 금액 계산 정책
  • 공통 검증 로직
이런 것은 CommonPolicy, PricingPolicy, PermissionPolicy 처럼 별도 컴포넌트로 뽑아낼 수 있다.
단, 여기서도 무분별한 common 폴더는 위험하다.
정말로 여러 도메인이 공유하는 규칙인지 먼저 확인해야 한다.

5. Port 와 Interface 는 수단이지 정답이 아니다

Hexagonal Architecture 를 이야기하면 흔히 인터페이스를 두면 된다 고 말한다.
하지만 인터페이스는 의존성의 방향을 바꾸는 수단일 뿐, 잘못된 책임 분리를 자동으로 고쳐주지는 않는다.
예를 들어 이런 상황은 여전히 문제다.
  • OrderUseCase 가 UserPort 를 호출한다.
  • UserUseCase 가 다시 OrderPort 를 호출한다.
형태만 Port 로 바뀌었을 뿐 사실상 순환 의존성은 그대로다.
즉, 인터페이스보다 먼저 봐야 할 것은 이 호출이 정말 필요한가, 상위 조정자가 가져가야 하는가, 이벤트로 분리해야 하는가 이다.

6. NestJS 의 forwardRef() 는 마지막 수단이다

NestJS 에서는 DI 초기화 문제를 피하기 위해 forwardRef() 를 사용할 수 있다.
하지만 이건 설계 문제를 해결했다기보다, 컨테이너가 일단 뜨도록 우회하는 경우가 많다.
물론 프레임워크 레벨에서 어쩔 수 없이 써야 하는 경우도 있다.
하지만 비즈니스 서비스끼리의 순환참조를 forwardRef() 로 넘기기 시작하면 보통 구조 문제가 더 커진다.
내 기준에서는 forwardRef() 는 해결책이라기보다 경고 신호에 가깝다.

실무에서는 어떻게 선택하면 좋을까

개인적으로는 이렇게 정리한다.
  • 단순 CRUD 위주라면 Layered Architecture 로 시작해도 충분하다.
  • 도메인이 복잡하고 오래 진화해야 한다면 Hexagonal Architecture 가 유리하다.
  • 어떤 구조를 쓰든 순환참조는 별도의 설계 문제로 봐야 한다.
즉, 아키텍쳐 선택과 순환참조 해결은 연결되어 있지만 같은 문제는 아니다.

내 생각

실무에서는 둘 중 하나만 순수하게 쓰기보다, Layered Architecture 를 기본으로 가져가되 핵심 유스케이스나 외부 연동 경계에 Hexagonal 관점을 일부 도입하는 경우가 많다.
이 방식이 현실적인 이유는 다음과 같다.
  • 팀이 이해하기 쉽다.
  • 처음부터 과한 추상화를 만들지 않아도 된다.
  • 복잡도가 커지는 지점에만 의존성 역전과 Port/Adapter 를 도입할 수 있다.
그리고 순환참조가 보이기 시작하면 그때는 무조건 기술 트릭부터 찾지 말고 아래 순서로 보는 것이 좋다.
  1. 이 둘은 사실 하나의 유스케이스인가?
  1. 이 의존성은 조회인가 행동인가?
  1. 후속 반응이라면 이벤트로 빼야 하는가?
  1. 진짜 공통 규칙이라면 별도 정책으로 뽑아야 하는가?
이 질문이 정리되면 대부분의 순환참조는 생각보다 깔끔하게 풀린다.

마무리

Layered Architecture 와 Hexagonal Architecture 는 서로 완전히 대체하는 개념이라기보다, 시스템을 바라보는 다른 렌즈에 가깝다.
  • Layered Architecture 는 역할 분리에 강하다.
  • Hexagonal Architecture 는 핵심 보호에 강하다.
하지만 둘 다 순환참조를 자동으로 해결해주지는 않는다.
결국 중요한 것은 비즈니스 로직이 어디에 있어야 하는지, 의존성이 왜 필요한지, 그 의존성이 진짜 같은 레벨에서 발생해야 하는지 를 계속 점검하는 것이다.
좋은 아키텍쳐의 목적은 멋진 다이어그램이 아니라, 시간이 지나도 안전하게 바꿀 수 있는 구조를 만드는 것이라고 생각한다.

참고 자료

Buy me a bear!If you like this post..