# [[Layered Architecture]]

## 📌 Brief Summary
Layered Architecture(또는 N-Tier Architecture)는 애플리케이션을 데이터 계층(Data Layer), 비즈니스 계층(Business Layer), 표현/UI 계층(Presentation/UI Layer) 등 명확한 역할과 책임에 따라 수직적으로 분리하는 소프트웨어 설계 패턴이다 [1, 2]. 이 패턴은 MVC(Model-View-Controller)와 같이 컨트롤러, 서비스, 모델/레포지토리로 역할을 나누어 시스템을 구성하는 기초적인 방법론으로 널리 사용된다 [3, 4]. 그러나 대규모 시스템에서는 계층 간의 의존성이 얽히고 유지보수가 어려워지는 한계가 있어, 최근에는 헥사고날 아키텍처나 기능 기반(Feature-based) 모듈 구조로 진화하는 추세에 있다 [1, 4].

## 📖 Core Content
* **계층별 책임의 분리 (Separation of Concerns):** 
  계층형 아키텍처는 애플리케이션을 여러 독립적인 계층으로 나눈다. 상호작용(UI/표현) 계층은 HTTP 요청이나 사용자 입력을 수신하고, 애플리케이션(유즈케이스) 계층은 입력받은 데이터를 처리하며, 인프라스트럭처 계층이나 데이터 접근 계층은 데이터베이스와 통신한다 [5, 6]. 프레임워크별 실무 적용을 보면, Django에서는 HTTP 요청을 처리하는 얇은 뷰(Thin Views)와 핵심 비즈니스 로직을 보유하는 서비스 계층(Service Layer), 데이터베이스 스키마와 관련된 뚱뚱한 모델(Fat Models) 등으로 역할을 분리하는 방식이 쓰인다 [7, 8].

* **DTO (Data Transfer Object)를 통한 계층 간 데이터 전달:** 
  외부 시스템과 상호작용하는 UI/인프라 계층과 애플리케이션 계층 사이에서 데이터를 전달할 때는 결합도를 낮추기 위해 DTO를 사용한다 [9, 10]. DTO는 주로 애플리케이션 계층에 위치하며, 도메인 객체를 인프라스트럭처의 구체적인 구현이나 직렬화(Serialization) 로직으로부터 캡슐화하고 보호하는 역할을 수행한다 [11, 12].

* **횡단 관심사 (Cross-Cutting Concerns)의 적용:**
  로깅, 예외 처리, 보안 등 여러 계층(Data, Business, UI)에 걸쳐 공통으로 필요한 기능들을 횡단 관심사라고 한다 [2]. 계층형 애플리케이션에서는 이러한 기능들이 각 계층마다 중복 작성(DRY 원칙 위배)되는 것을 막기 위해, AOP(관점 지향 프로그래밍)나 인터셉터, 베이스 클래스(Base Class) 등을 통해 인프라스트럭처 레벨에서 중앙 집중식으로 분리하여 관리한다 [13-15].

## ⚖️ Trade-offs & Caveats
* **유지보수성과 스케일링의 한계 (계층별 폴더 구조의 문제):** 
  NestJS와 같은 프레임워크에서 전통적인 계층형 폴더 구조(예: 모든 컨트롤러를 한 폴더에, 모든 서비스를 다른 폴더에 모으는 방식)는 애플리케이션 규모가 커질수록 유지보수를 극도로 어렵게 만든다 [4]. '사용자(Users)' 기능을 하나 수정하기 위해 연관성 없는 여러 계층의 폴더를 넘나들어야 하며, 계층을 가로지르는 종속성이 보이지 않게 결합될 위험이 크다 [4]. 따라서 규모가 있는 프로젝트에서는 계층형 폴더 구조를 피하고, 기능 기반(Feature-based)의 모듈 폴더 구조를 사용하는 것이 권장된다 [4].
* **수직적 종속성(Hierarchical Structure)의 위험:** 
  전통적인 N-Tier 계층형 아키텍처는 데이터베이스나 외부 인프라가 가장 하단에 위치하는 수직적 구조를 암시하는 경우가 많다 [1]. 이로 인해 핵심 비즈니스 로직(도메인)이 데이터베이스나 프레임워크 기술에 종속되는 강한 결합이 발생하기 쉽다 [1, 16]. 이러한 한계를 극복하기 위해 의존성 역전 원칙(DIP)을 활용하여 도메인을 보호하는 헥사고날 아키텍처가 대안으로 제시된다 [17].
* **보일러플레이트 코드의 증가:** 
  계층을 엄격하게 나눌 경우, 각 계층의 경계를 넘나들 때마다 DTO와 도메인 엔티티 간의 매핑(Mapping) 코드를 의무적으로 작성해야 하므로 불필요한 보일러플레이트 코드가 기하급수적으로 늘어날 수 있다 [18, 19].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Hexagonal Architecture]]
  - 연결 이유: 수직적인 계층형 아키텍처(N-Tier)가 가지는 '핵심 비즈니스 로직이 외부 인프라에 종속되는 문제'를 해결하기 위해 등장한 아키텍처 패턴이다 [1, 16].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 포트(Ports)와 어댑터(Adapters)를 사용하여 의존성의 방향을 내부로 향하게 하고, 비즈니스 로직을 보호하는 원리를 이해할 수 있다 [17, 20].

- [[Clean Architecture]]
  - 연결 이유: 계층형 구조에서 관심사를 명확히 분리하여, 프레임워크나 UI에 구애받지 않는 소프트웨어를 구축하려는 아키텍처 철학이다 [16, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 횡단 관심사(Cross-Cutting Concerns)를 인프라스트럭처 계층으로 안전하게 분리하고 모듈화를 달성하는 설계 기법을 학습할 수 있다 [21, 22].

#### [구현/활용 도구]
- [[DTO (Data Transfer Object)]]
  - 연결 이유: 계층 간 데이터를 전달할 때 도메인 모델을 보호하고 결합도를 낮추기 위해 사용되는 핵심 객체 패턴이다 [9, 10].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애플리케이션 계층과 상호작용(UI)/인프라스트럭처 계층 사이에서 입력 데이터의 검증 및 변환 로직이 어떻게 이루어지는지 알 수 있다 [5, 11].

- [[Cross-Cutting Concerns]]
  - 연결 이유: 계층형 아키텍처의 여러 계층을 수직으로 관통하며 발생하는 로깅, 예외 처리, 인증 등의 공통 관심사이다 [2, 23].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 계층 간의 코드 중복을 피하고 단일 책임 원칙(SRP)을 지키기 위해 AOP, 미들웨어 등을 어떻게 활용해야 하는지 파악할 수 있다 [13, 24].

### Deeper Research Questions
- 계층형 아키텍처(Layered Architecture)와 헥사고날 아키텍처(Hexagonal Architecture)의 의존성 흐름(Dependency Flow)은 어떻게 다르며, 이것이 대규모 애플리케이션의 유지보수성에 미치는 영향은 무엇인가?
- NestJS 프로젝트에서 MVC 형태의 전통적인 계층형 폴더 구조가 가진 한계를 기능 기반(Feature-based) 모듈 폴더 구조는 어떤 방식으로 해결하는가?
- Django 환경에서 비즈니스 로직을 구성할 때 'Fat Models, Thin Views' 패턴과 'Service Layer' 패턴은 각각 어떠한 장단점(Trade-off)을 가지는가?
- 애플리케이션 계층과 인프라스트럭처 계층 간 데이터를 주고받기 위해 DTO를 사용할 때, 매핑(Mapping) 코드로 인한 보일러플레이트를 줄일 수 있는 설계 전략은 무엇인가?
- 횡단 관심사(Cross-Cutting Concerns)를 다수의 계층에 적용할 때, 객체지향 설계 원칙(SRP, DRY)을 위배하지 않고 안정적으로 에러 핸들링과 로깅을 중앙 집중화하는 구체적인 패턴은 무엇인가?

### Practical Application Contexts
- **Implementation:** Django와 같은 백엔드 프레임워크 구현 시 뷰(View)는 얇게 유지하여 HTTP 요청 어댑터로만 사용하고, 비즈니스 로직은 별도의 서비스(Service) 계층에, 데이터베이스 구조는 모델에 위임하도록 계층을 분리하여 구현한다 [8, 25].
- **System Design:** 소프트웨어 설계 초기 단계에서 데이터베이스, 비즈니스 로직, 사용자 인터페이스 등 기능별로 티어(Tier)를 분리하여 시스템 각 부분의 역할과 책임 범위를 명확히 규정하는 데 사용된다 [2].
- **Operation / Maintenance:** 초기에는 구조가 단순해 보이나 프로젝트 규모가 커지면 계층별 분리가 수정 작업을 복잡하게 만든다. 유지보수 시 관련 파일이 여러 계층에 흩어지는 문제를 피하기 위해 운영 단계에서 기능 단위 모듈화(Feature-based)로 리팩토링하는 근거가 된다 [4].
- **Learning Path:** 소프트웨어 아키텍처 학습 시 가장 기본이 되는 MVC 패턴과 역할 기반 계층 분리를 먼저 이해한 뒤, 이를 개선한 클린 아키텍처나 헥사고날 아키텍처로 넘어가기 위한 필수 기초 지식으로 활용된다 [1, 16].
- **My Project Relevance:** NestJS나 Spring Boot 같은 프레임워크를 기반으로 프로젝트를 시작할 때, 폴더 구조를 어떻게 가져갈지, 인터페이스(Controller)와 비즈니스 핵심 로직(Service), 그리고 데이터 접근(Repository)을 어떻게 격리할지를 판단하는 핵심 아키텍처 가이드로 작동한다 [19, 26, 27].

### Adjacent Topics
- [[Dependency Injection (DI)]]
  - 확장 방향: 계층형 구조에서 상위 계층이 하위 계층에 강하게 결합되는 문제를 해결하기 위해, 객체의 생성과 의존성을 외부 컨테이너에 위임하여 결합도를 낮추는 기법으로 확장이 필요하다.
- [[Active Record Pattern vs Repository Pattern]]
  - 확장 방향: 데이터 접근 계층(Data Access Layer)에서 데이터를 저장하고 조작할 때, 도메인 비즈니스 로직과 데이터베이스 매핑 로직을 합칠 것인가 분리할 것인가에 대한 구체적인 ORM 설계 패턴 탐구로 이어진다.

---
*Last updated: 2026-05-03*