Layered Architecture

📌 Brief Summary

계층형 아키텍처(Layered Architecture), 또는 n-tier 아키텍처는 소프트웨어 시스템을 특정 책임을 가진 수평적인 층(Layer)으로 조직하는 전통적이고 널리 사용되는 설계 패턴입니다 [1]. 각 계층은 사용자 인터페이스 처리, 비즈니스 로직 관리, 데이터 영속성 관리 등 명확한 기능적 관심사를 전담하여 시스템의 복잡성을 줄입니다 [1]. 코드베이스를 읽고 이해하는 관점에서, 이 구조는 코드가 어떻게 배치되고 의존성이 어떻게 흐르는지에 대한 명확한 규칙을 제공하므로 하향식 탐색 및 시스템 파악에 필수적인 개념입니다 [2, 3].

📖 Core Content

구조 및 주요 계층의 분리: 시스템은 통상적으로 3개 이상의 수평적 계층으로 분리되며 각자의 역할이 명확합니다 [2, 3].
- 프레젠테이션 계층 (Presentation Layer): 최상단에 위치하며 UI 및 UX 로직을 담당합니다 [2].
- 비즈니스 로직 계층 (Business Logic / Domain Layer): 시스템의 핵심 비즈니스 규칙과 워크플로우를 처리하고 데이터 접근 계층과 연계하여 프레젠테이션 계층의 명령을 조율합니다 [2].
- 데이터 접근 계층 (Data Access / Persistence Layer): 데이터베이스와 같은 데이터 소스와의 통신(CRUD 작업 등)을 책임지며, 비즈니스 로직을 데이터 저장의 세부 사항으로부터 격리합니다 [2].
엄격한 의존성 및 통신 규칙: 각 계층은 바로 아래에 있는 인접한 하위 계층에만 의존하고 통신해야 한다는 엄격한 규칙을 가집니다 [3, 4]. 상위 계층이 하위 계층을 건너뛰는 행위(예: UI 로직이 데이터베이스 쿼리를 직접 수행하는 것)는 아키텍처의 부패를 의미하므로, 코드베이스를 분석할 때는 이러한 의존성의 방향과 규칙 준수 여부를 유심히 관찰해야 합니다 [3, 4].
구현 모범 사례 및 디렉토리 구조:
- 계층 간 통신에는 명확히 정의된 인터페이스를 사용하여, 상위 계층에 영향을 주지 않고 구현체를 교체할 수 있어야 합니다 [4, 5].
- 의존성 주입(Dependency Injection, DI)을 활용해 계층 간 결합도를 낮추고 테스트 용이성을 극대화합니다 [4, 5].
- 코드베이스의 디렉토리 파일 구조 역시 프레젠테이션, 데이터 접근 등 각각의 계층별로 디렉토리를 나누어 구성(Layered Architecture 접근법)하는 경우가 많습니다 [6].

⚖️ Trade-offs & Caveats

강한 결합(Tight Coupling)의 위험성: 계층형 아키텍처는 역할이 잘 분리되어 있어 전통적인 엔터프라이즈 앱에 적합하지만, 의존성과 인터페이스를 주의 깊게 관리하지 않으면 각 계층의 코드가 강하게 결합되기 쉽습니다 [5, 6].
테스트 파일 조직의 복잡성 증가: 계층 구조를 본따 테스트 파일을 구성(Application Layer 방식)하는 것은 규모가 큰 파일에는 적합하나, 작은 규모의 테스트 파일들에는 불필요한 복잡성을 더할 수 있습니다 [7]. 하나의 테스트 파일이 다른 파일에 종속되거나 참조를 여러 계층에 걸쳐 빈번하게 수행하면 계층이 상징하는 본래의 의미가 훼손될 수 있습니다 [7].
아키텍처 무결성 훼손: 코드 리뷰나 유지보수 시 하위 계층에만 의존해야 하는 엄격한 규칙을 어기고 편의를 위해 계층 간 경계를 침범할 경우, 장기적으로 코드의 유지보수성과 테스트 가능성이 심각하게 저하됩니다 [3, 4].

🔗 Knowledge Connections

[아키텍처/기반 기술]

Separation of Concerns (SoC)
- 연결 이유: 계층형 아키텍처는 시스템의 프레젠테이션, 비즈니스 규칙, 데이터 접근 등의 '관심사'를 겹치지 않는 별도의 모듈로 분리(SoC)하는 가장 대표적이고 기본적인 사례이기 때문입니다 [1, 8, 9].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스의 복잡성을 줄이기 위해 왜 각 모듈과 계층에 단일한 책임을 부여해야 하는지 근본 원리를 파악할 수 있습니다 [1, 8].
Dependency Injection (DI)
- 연결 이유: 인접한 하위 계층과 통신할 때 외부에서 의존성을 주입하여 상위 계층과의 결합도를 낮추는 핵심 기법이기 때문입니다 [4, 10].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상화된 인터페이스 배후에 숨겨진 실제 구현체가 런타임에 어떻게 할당되는지 추적하여 코드베이스의 동적 흐름을 읽는 역량을 키울 수 있습니다 [4, 10, 11].

[코드베이스 탐색 및 분석 기법]

하향식 접근법 (Top-Down Approach)
- 연결 이유: 계층형 구조의 코드를 분석할 때는 최상위 프레젠테이션 계층(API, UI 진입점 등)에서 시작하여 비즈니스 로직, 데이터 계층 순으로 점진적으로 내려가는 하향식 탐색이 자연스럽고 효과적이기 때문입니다 [3, 8, 12].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 사용자 상호작용과 기능의 전체 가치 사슬이 하위 물리적 계층으로 어떻게 오케스트레이션(조율) 되는지 추적하는 방법을 학습할 수 있습니다 [8, 12].
디렉토리 기반 파일 조직 (Feature vs Layer Organization)
- 연결 이유: 코드베이스의 폴더 및 파일 구조가 아키텍처의 기술적 계층(Presentation, Data 등)을 따라 분리되어 있는지, 아니면 비즈니스 기능(Feature-based) 중심으로 분리되어 있는지 파악하는 것이 코드 해독의 첫걸음이기 때문입니다 [6, 13].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파일 시스템의 물리적 구조를 통해 아키텍처의 의도를 역으로 해독하고, 원하는 코드가 어디에 위치할지 예측하는 지도를 그릴 수 있습니다 [6, 14].

Deeper Research Questions

코드베이스 분석 시, 계층 간의 엄격한 통신 규칙이 무너진 부분(예: UI 계층이 영속성 계층에 직접 접근하는 경우)을 효과적으로 식별하고 기술적 부채로 추적하는 방법은 무엇인가?
모놀리식 계층형 아키텍처로 구성된 대규모 레거시 코드를 기능 중심의 모듈(Feature-based)이나 도메인 주도 설계(DDD)로 전환할 때, 의존성 방향을 어떻게 재구성해야 하는가?
의존성 주입(DI) 프레임워크가 광범위하게 사용된 계층형 시스템에서, 코드를 정적으로 읽는 것만으로 런타임에 어떤 계층의 구체적 구현체가 호출되는지 파악하기 어려운 한계를 어떻게 극복할 수 있는가?
테스트 코드의 조직 방식이 애플리케이션 계층별로 분리되어 있을 때, 여러 계층을 아우르는 기능의 실행 흐름(통합 테스트)을 코드만으로 빠르고 일관되게 추적하는 전략은 무엇인가?
장애나 버그를 수정하기 위한 목적으로 계층형 아키텍처를 탐색할 때, 하향식 접근법보다 최하위 데이터 계층에서 역추적하는 상향식(Bottom-Up) 접근법이 유리해지는 구체적인 조건은 무엇인가?

Practical Application Contexts

Implementation: 코드를 작성하거나 수정할 때, 계층을 얇게(thin) 유지하고 상/하위 계층 간 통신을 위해 명확한 인터페이스 계약을 정의 및 구현해야 합니다 [5].
System Design: 역할의 명확한 분리가 필요한 3티어(3-Tier) 웹 애플리케이션이나 전통적인 엔터프라이즈 시스템의 기본 설계 패턴으로 활용됩니다 [2, 5].
Operation / Maintenance: 기존 코드를 유지보수할 때 상위 계층이 하위 계층을 건너뛰고 상호작용하는 아키텍처의 부패 징후를 지속적으로 모니터링해야 합니다 [3].
Learning Path: 시스템 전체의 구조를 파악하기 위한 첫 단계로서, 공용 API나 UI 라우터에서 출발하여 비즈니스 로직, 데이터 계층 순으로 흐름을 파악하는 '하향식 접근법'을 훈련하는 기초 지형이 됩니다 [3, 12].
My Project Relevance: 거대한 프로젝트의 코드베이스 구조를 파악할 때 각 디렉토리 및 모듈이 어느 기술적 계층에 해당하는지 먼저 식별함으로써, 코드를 읽는 인지적 부하를 줄이고 부수 효과(Side-effects)를 추적할 수 있는 멘탈 모델을 갖추게 합니다.

Adjacent Topics

Clean Architecture
- 확장 방향: 계층형 구조에서 더 나아가, 비즈니스 중심의 도메인 로직을 핵심에 두고 모든 외부 요소(DB, UI 등)의 의존성이 코어를 향하도록 역전시키는 의존성 관리 원칙과 심화 아키텍처 패턴을 탐구합니다 [15, 16].
Domain-Driven Design (DDD)
- 확장 방향: 기술적인 수평적 계층(Layer) 기준이 아닌, '주문', '결제' 등 비즈니스 언어와 도메인의 바운디드 컨텍스트(Bounded Context)를 중심으로 모듈과 폴더를 수직적으로 나누는 대안적 아키텍처 및 코드베이스 조직 방식을 이해합니다 [16-18].

Last updated: 2026-05-02

9.7 KiB Raw Blame History