Post

[System Design] Layered에서 Vertical Slice까지

Posted Updated
Preview Image
By Teno
23 min read
[System Design] Layered에서 Vertical Slice까지

우리는 흔히 아키텍처를 논할 때 모놀리식 마이크로서비스와 같은 배포 구조를 떠올립니다. 그러나 진정한 의미의 아키텍처는 단일 프로세스 내의 코드 조직화(Internal Structure)에서 시작됩니다.

내부 아키텍처의 핵심 목표는 화려한 패턴 적용이 아닙니다. 개발자가 코드를 읽을 때 겪는 인지 부하(Cognitive Load)를 줄이고, 관련된 로직을 얼마나 가깝게 두느냐 하는 응집도(Cohesion)를 높이는 싸움입니다.

🧩 Layered Architecture

엔터프라이즈 자바 생태계에서 Layered Architecture(N-Tier)는 공기처럼 자연스러운 존재입니다. 우리는 새로운 프로젝트를 시작할 때, 고민 없이 controller, service, repository 패키지를 만듭니다. 아키텍처 전문가 마크 리차즈(Mark Richards)는 이를 두고 “사실상의 표준”이라 칭했습니다. 가장 익숙하고, 팀의 조직 구조(프론트엔드/백엔드/DBA)와 정확히 일치하며, 무엇보다 빠르게 시작할 수 있기 때문입니다. 하지만 여기에는 치명적인 단점이 존재합니다.

관심 범위의 축소

우리는 왜 계층을 나눌까요? 흔히 “나중에 데이터베이스를 오라클에서 MySQL로 쉽게 바꾸기 위해서”라고 답하지만, 마틴 파울러(Martin Fowler)의 통찰은 다릅니다. 그는 계층화의 본질적인 가치를 “관심 범위의 축소”라고 정의했습니다.

  • UI 코드를 작성할 때는 복잡한 SQL 조인 쿼리를 고민하지 않아도 된다.
  • 비즈니스 로직을 구현할 때는 이것이 JSON으로 나갈지 HTML로 렌더링될지 신경 쓰지 않는다.

즉, 개발자가 한 번에 다뤄야 할 인지 부하를 줄여주고, 한 번에 하나의 문제에만 집중하게 만드는 것이 이 아키텍처의 존재 의의입니다.

데이터베이스 주도 개발

하지만 현실의 Layered Architecture는 의도와 다르게 작동합니다. 의존성의 흐름이 상위(Presentation)에서 하위(Persistence)로 흐르기 때문에, 필연적으로 최하단에 위치한 데이터베이스가 시스템의 중심이 됩니다.

우리의 개발 프로세스를 냉정하게 되돌아봅시다.

  1. ERD 설계: 화이트보드에 테이블과 관계를 먼저 그립니다.
  2. Entity 생성: 테이블과 1:1로 매핑되는 Entity 클래스를 만듭니다.
  3. CRUD 구현: 그 Entity를 읽고 쓰는 Repository, Service, Controller를 기계적으로 생성합니다.

이 과정에서 객체지향의 핵심인 객체 간의 협력과 행위는 설 자리를 잃습니다. 대신 Getter/Setter로 점철된 빈혈 도메인 모델(Anemic Domain Model)만이 남게 됩니다.

결국 Service 계층은 도메인 로직을 품은 객체가 아니라, 단순히 데이터를 꺼내서 가공하고 다시 넣는 절차지향적인 트랜잭션 스크립트(Transaction Script)의 집합소로 전락합니다. 격리를 위해 레이어를 나눴지만, 실제로는 DB 스키마가 변경되면 Service와 Controller가 줄줄이 깨지는 강한 논리적 결합 상태에 빠지는 것입니다.

Anti-Pattern: 아키텍처 싱크홀

이 아키텍처의 실패를 가장 극명하게 보여주는 증거는 아키텍처 싱크홀(Architecture Sinkhole) 현상입니다. 요청이 레이어를 통과하면서 어떠한 비즈니스적 가치도 더하지 못하고, 단순히 하위 레이어로 넘기기(Pass-through)만 하는 경우입니다.

1
2
3
4
5
6
7
8
9
10
11
12

@Service
@RequiredArgsConstructor
public class ProductService {
    private final ProductRepository productRepository;

    @Transactional(readOnly = true)
    public ProductDto getProduct(Long id) {
        return productRepository.findById(id)
                .map(Product::toDto)
                .orElseThrow(() -> new EntityNotFoundException());
    }
}

위 코드에서 서비스가 하는 일이 없습니다. 그냥 Repository의 Proxy일 뿐입니다.

아키텍처 선택과 싱크홀 비율

마크 리차즈는 “전체 요청의 20% 정도는 허용되지만, 80% 이상이 싱크홀이라면 이 아키텍처는 잘못된 선택”이라고 경고합니다.

우리는 단순히 레이어를 위한 레이어를 유지하기 위해 불필요한 객체 변환 비용, 컴파일 비용, 그리고 관리 비용을 지불하고 있는 셈입니다. 이것이 바로 “표준”이라는 이름 아래 우리가 간과해온 비효율의 실체입니다.

🧩 Hexagonal Architecture

Layered 아키텍처가 가진 태생적인 한계는 의존성의 방향입니다. 상위 계층이 하위 계층에 의존하는 구조 탓에, 우리의 소중한 비즈니스 로직은 필연적으로 데이터베이스 기술(JPA, MyBatis 등)에 오염됩니다.

앨리스테어 콕번(Alistair Cockburn)은 이 문제를 해결하기 위해 아키텍처의 위아래를 뒤집었습니다. 바로 Hexagonal Architecture이며, Ports and Adapters라고도 합니다.

의존성 역전

이 아키텍처의 핵심 철학은 “내부와 외부의 철저한 격리”입니다.

  • Inside (Domain Hexagon): 순수한 비즈니스 로직이 위치합니다. 이곳은 외부의 어떤 기술적 세부사항도 알지 못하며, 프레임워크에도 의존하지 않는 POJO(Plain Old Java Object) 상태를 유지한다.
  • Outside (Infrastructure): 웹 브라우저, 데이터베이스, 외부 API, 메시지 큐 등 애플리케이션을 둘러싼 모든 기술적 요소이다.

여기서 의존성 역전(DIP)이 일어납니다. 전통적인 방식이라면 Service가 Repository 구현체를 직접 의존했겠지만, 헥사고날에서는 도메인이 포트(Port)라는 인터페이스를 정의하고, 인프라 계층이 어댑터(Adapter)를 통해 이를 구현합니다. 즉, 의존성의 화살표가 모두 바깥에서 안쪽으로 향하게 됩니다.

Why Hexagon?

콕번은 “육각형”이라는 모양 자체에는 큰 의미가 없다고 말합니다. 단지 애플리케이션이 4면(Top-Down)뿐만 아니라 여러 면(Port)을 통해 외부와 소통할 수 있음을 시각적으로 보여주기 위한 메타포일 뿐입니다.

Netflix의 유연함

이 아키텍처의 진가는 외부 시스템을 교체할 때 드러납니다. 넷플릭스(Netflix) 엔지니어링 팀은 스튜디오 애플리케이션에 헥사고날 아키텍처를 도입하여 큰 성공을 거두었습니다.

그들은 특정 기능의 데이터 소스를 기존의 JSON API에서 GraphQL로 변경해야 했습니다. 만약 Layered 아키텍처였다면 서비스 로직을 대거 수정해야 했을 겁니다. 하지만 헥사고날 구조 덕분에, 도메인 로직은 단 한 줄도 수정하지 않고, 새로운 Secondary Adapter(Driven Adapter)를 갈아 끼우는 것만으로 단 2시간 만에 마이그레이션을 완료했습니다. 이것이 바로 포트와 어댑터가 주는 강력한 유연함입니다.

매핑 지옥

하지만 모든 선택에는 대가가 따릅니다. 도메인의 순수성(Purity)을 지키기 위해 우리가 지불해야 할 비용은 바로 인지 부하(Cognitive Load)와 매핑 비용입니다.

단순한 데이터 저장 기능을 구현하기 위해 데이터가 거쳐야 하는 여정을 살펴봅시다.

  1. Web DTO (UserController가 받음)
  2. Command 객체 (Input Port로 변환)
  3. Domain Entity (비즈니스 로직 수행)
  4. JPA Entity (Output Port를 거쳐 DB 저장용으로 변환)

필드 하나를 추가하려면 4~5개의 클래스를 수정하고, 이들 사이를 연결하는 지루한 매핑(Mapping) 코드를 작성해야 합니다. 이를 개발자들은 자조 섞인 목소리로 매핑 지옥(Mapping Hell)이라 부릅니다.

넷플릭스와 같이 복잡한 핵심 도메인(Core Domain)에는 이 비용이 정당화될 수 있습니다. 하지만 단순한 CRUD가 주를 이루는 시스템에서 헥사고날을 도입하는 것은 명백한 오버 엔지니어링입니다.

🧩 Vertical Slice Architecture

Layered와 Hexagonal은 겉보기엔 달라 보이지만, 근본적인 공통점이 있습니다. 바로 코드를 기술적 계층(Horizontal Layers)에 따라 나눈다는 점입니다.

지미 보가드(Jimmy Bogard)는 여기서 근본적인 의문을 제기합니다.

“우리는 기능을 추가할 때 UI, 로직, DB를 모두 건드린다. 즉, 변경은 수직(Vertical)으로 일어나는데, 왜 코드는 수평(Horizontal)으로 관리하는가?”

이러한 문제의식에서 출발한 것이 바로 Vertical Slice Architecture입니다.

변경의 축을 따르라

이 아키텍처의 핵심은 응집도의 재정의입니다.

전통적인 관점에서 응집도는 같은 종류의 코드(Controller끼리, Service끼리)를 모으는 것이었습니다. 하지만 Vertical Slice는 함께 변경되는 코드를 모으는 것이 진정한 응집도라고 주장합니다.

  • Before (Layered): User 관련 기능을 수정하려면 controller 패키지, service 패키지, repository 패키지를 오르내리며 탐색해야 했습니다. (Low Cohesion)
  • After (Slice): features/registerUser 패키지 안에 Controller, Command, Validator, Repository가 모두 모여 있습니다.

이제 개발자는 기능을 수정하기 위해 프로젝트 탐색기를 헤맬 필요가 없습니다. 관련된 모든 문맥이 하나의 폴더(Slice) 안에 격리되어 있기 때문입니다. 데릭 코마틴(Derek Comartin)은 이를 두고 “기술적 계층이 아닌 비즈니스 역량에 따른 격리”라고 강조합니다.

패턴으로의 리팩토링

Vertical Slice의 가장 강력한 무기는 유연함입니다. 모든 코드가 획일적인 구조를 가질 필요가 없습니다.

각 슬라이스는 문제의 복잡도에 따라 최적의 구현 방식을 선택할 권리를 가집니다.

  • 단순 조회 (Simple Query): 복잡한 도메인 모델이나 DTO 변환 없이, Controller가 JdbcTemplate이나 Raw SQL을 직접 호출하여 성능을 극대화합니다. (Layered 아키텍처였다면 ‘새치기’라고 비난받았을 구조입니다.)
  • 복잡한 비즈니스 (Complex Command): Rich Domain Model을 사용하여 엄격한 캡슐화와 테스트를 적용합니다.

불필요한 추상화를 걷어내고, 각 기능의 특성에 맞는 도구를 사용하여 실용성을 극대화합니다.

중복을 허용하라

그렇다면 공통 로직이나 중복 코드는 어떻게 할까요? Vertical Slice는 이에 대해 다소 파격적인 답을 내놓습니다.

“우발적 중복(Accidental Duplication)을 허용하라.”

우리는 습관적으로 SharedService나 CommonDTO를 만들어 중복을 제거하려 합니다(DRY 원칙). 하지만 서로 다른 변경 주기를 가진 두 기능이 하나의 공통 코드에 묶이는 순간, 우발적 결합(Accidental Coupling)이 발생합니다. A 기능을 위해 공통 코드를 수정했는데, B 기능이 망가지는 상황이 벌어지는 것입니다.

Vertical Slice는 섣부른 공통화보다는, 약간의 복사-붙여넣기(Copy-Paste)를 감수하더라도 완벽한 격리를 선택하는 것이 장기적인 유지보수에 유리하다고 봅니다. 코드를 공유하는 것보다, 지식을 공유하는 것이 더 중요하기 때문입니다.

Architecture as Code

아무리 완벽한 아키텍처를 설계해도, 시간이 지남에 따라 코드는 엉키기 시작합니다. 문서는 코드를 이길 수 없습니다. 아키텍처 제약조건은 개발자의 기억이 아닌, 실패하는 단위 테스트(Failing Unit Test)로 관리되어야 합니다.

자바 진영의 ArchUnit은 컴파일된 바이트코드(Bytecode)를 분석하여 의존성 규칙을 검증하는 강력한 도구입니다.

Layered Architecture: ‘새치기’ 방지

Layered 아키텍처가 무너지는 가장 흔한 패턴은 계층 건너뛰기(Bypass)입니다. Controller가 Service를 거치지 않고 Repository를 직접 주입받아 사용하는 순간, 트랜잭션 관리와 비즈니스 로직의 캡슐화는 깨집니다.

이를 리뷰 단계에서 눈으로 잡는 것은 불가능에 가깝습니다. 하지만 코드로 정의하면 빌드 타임에 잡아낼 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@AnalyzeClasses(packages = "com.teno.lab")
public class LayeredArchitectureTest {

    @ArchTest
    static final ArchRule layer_boundaries_are_respected = layeredArchitecture()
            .consideringOnlyDependenciesInLayers()
            // 1. 레이어 정의: 패키지 구조와 매핑
            .layer("Controller").definedBy("..controller..")
            .layer("Service").definedBy("..service..")
            .layer("Repository").definedBy("..repository..")

            // 2. 제약 조건: 화살표는 위에서 아래로만 흐른다
            .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
            .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
            .whereLayer("Repository").mayOnlyBeAccessedByLayers("Service");
}

이 테스트가 존재하는 한, 누군가 실수로 Controller에 Repository를 import 하는 순간 CI 파이프라인은 멈춥니다.

Vertical Slice Architecture: 격리의 검증

Vertical Slice 아키텍처의 핵심 리스크는 스파게티 의존성입니다. 기능 단위로 코드를 모아두었는데, A 기능이 B 기능의 내부 클래스를 참조하기 시작하면 모듈성은 파괴됩니다.

ArchUnit의 SlicesRuleDefinition을 사용하면 슬라이스 간의 격리를 수학적으로 증명할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@AnalyzeClasses(packages = "com.teno.lab")
public class SliceArchitectureTest {

    @ArchTest
    static final ArchRule slices_should_be_free_of_cycles =
        SlicesRuleDefinition.slices()
            .matching("com.teno.lab.features.(*)..") // features 하위 패키지를 하나의 슬라이스로 간주
            .should().beFreeOfCycles(); // 순환 참조 금지
            
    @ArchTest
    static final ArchRule features_should_not_depend_on_other_features =
        classes().that().resideInAPackage("..features..")
            .should().onlyAccessClassesThat()
            .resideInAnyPackage("java..", "javax..", "..shared..", "..features.."); 
            // 더 엄격하게 Shared와 JDK 외에는 서로 참조 금지 설정 가능
}

Living Documentation

이렇게 작성된 아키텍처 테스트는 그 자체로 살아있는 문서(Living Documentation)가 됩니다. 엔지니어링은 믿음이 아니라 시스템으로 문제를 해결하는 것입니다. 아키텍처 또한 예외가 아닙니다.

Summary

모든 상황에 맞는 완벽한 아키텍처는 존재하지 않습니다. 프로젝트의 성격과 팀의 상황에 맞춰 선택해야 합니다.

Selection Criteria

ArchitectureBest Fit ForKey Constraint
Layered주니어 위주 팀, 단순 CRUD, 단기 프로젝트비즈니스 복잡도가 증가하면 유지보수 비용 급증
HexagonalCore Subdomain, 외부 시스템 교체가 잦은 장기 프로젝트높은 구현 비용, 단순 기능에는 비효율적
Vertical SliceAgile 환경, 기능 변경이 잦고 복잡도 편차가 큰 경우팀원들의 높은 코드 리팩토링 역량 요구

Hybrid Modular Monolith

실무에서는 하이브리드 전략이 유효합니다. 전체 시스템을 모듈형 모놀리스(Modular Monolith)로 구성하되, 모듈의 중요도에 따라 내부 아키텍처를 달리 가져가는 것입니다.

모듈별 아키텍처 적용 전략

비즈니스의 정수가 담긴 핵심 모듈(Core Module)은 헥사고날로 방어하고, 단순 지원이나 조회 위주의 서브 모듈은 버티컬 슬라이스로 생산성을 확보하는 것이 좋습니다. 일관성보다 실용성이 우선입니다.

References

Backend Engineering, System Design
System Design Layered Architecture Hexagonal Architecture Vertical Slice Architecture
This post is licensed under CC BY 4.0 by the author.