--- id: wiki-2026-0508-계층화-아키텍처-layered-architecture title: 계층화 아키텍처 (Layered Architecture) category: 10_Wiki/Topics status: verified canonical_id: self aliases: [Layered Architecture, N-tier, Tiered Architecture] duplicate_of: none source_trust_level: A confidence_score: 0.9 verification_status: applied tags: [architecture, layering, separation-of-concerns, n-tier] raw_sources: [] last_reinforced: 2026-05-10 github_commit: pending tech_stack: language: agnostic framework: Spring/.NET/Django --- # 계층화 아키텍처 (Layered Architecture) ## 매 한 줄 > **"매 application 을 horizontal layer (presentation / business / persistence / data) 의 stack 으로 조직"**. 매 가장 흔한 default architecture — 매 simple, 매 onboarding 쉬움. 매 large-scale 에서 coupling/performance 한계 발생 → microservice/hexagonal 로 진화. ## 매 핵심 ### 매 표준 layer - **Presentation**: UI / REST controller / GraphQL resolver. 매 input 의 validation + serialization. - **Business / Service**: domain logic, transaction boundary, orchestration. - **Persistence / Repository**: ORM, query, cache. - **Data**: DB, file, message broker. ### 매 strict vs relaxed - **Strict layering**: 매 layer N 은 layer N-1 만 호출 가능. 매 testability 좋음. - **Relaxed**: layer skip 가능 (e.g. controller → repository 직접). 매 anti-pattern 으로 간주. ### 매 응용 1. Spring Boot 의 @Controller / @Service / @Repository. 2. Django 의 view / business / model. 3. Clean Architecture 의 adapter ring 변형. 4. .NET 의 N-tier WebAPI / BLL / DAL. ## 💻 패턴 ### Spring Boot 의 표준 3-layer ```java @RestController @RequestMapping("/orders") public class OrderController { private final OrderService service; public OrderController(OrderService s) { this.service = s; } @PostMapping public OrderDto create(@RequestBody @Valid CreateOrderReq req) { return service.create(req); } } @Service public class OrderService { private final OrderRepo repo; @Transactional public OrderDto create(CreateOrderReq req) { Order o = Order.from(req); return OrderDto.from(repo.save(o)); } } @Repository public interface OrderRepo extends JpaRepository {} ``` ### DTO ↔ Domain 매 boundary ```java // 매 controller 는 DTO 만, service 는 domain entity 만 다룬다. public record CreateOrderReq(String sku, int qty) {} public record OrderDto(Long id, String sku, int qty, String status) { public static OrderDto from(Order o) { return new OrderDto(o.getId(), o.getSku(), o.getQty(), o.getStatus().name()); } } ``` ### Repository abstraction (testability) ```java public interface OrderRepo { Order save(Order o); Optional findById(Long id); } // 매 unit test 의 Stub repository 의 inject: class StubOrderRepo implements OrderRepo { /* in-memory */ } ``` ### 매 cross-cutting (logging / tx / auth) 의 AOP ```java @Aspect @Component class AuditAspect { @Around("@annotation(Audited)") public Object audit(ProceedingJoinPoint pjp) throws Throwable { long t0 = System.nanoTime(); Object result = pjp.proceed(); log.info("{} took {}ns", pjp.getSignature(), System.nanoTime() - t0); return result; } } ``` ### Layer 의 dependency rule (안티: upward call) ```java // ❌ Service 가 Controller 호출 X // ❌ Repository 가 Service 호출 X // ✅ 매 한 방향: presentation → service → persistence ``` ## 매 결정 기준 | 상황 | Approach | |---|---| | CRUD-heavy MVP | 매 layered (default 선택) | | 매 complex domain logic | hexagonal / clean architecture | | 매 high decoupling 필요 | event-driven / CQRS | | 매 large team / bounded context | microservice | | 매 simple script | 매 layer X — single file | **기본값**: 매 small/medium app 은 **3-layer (controller / service / repository)** + DI + DTO boundary. ## 🔗 Graph - 부모: [[Software Architecture]] - 변형: [[Hexagonal Architecture]] · [[Clean Architecture]] · [[Onion Architecture]] - 응용: [[Spring Boot]] · [[ASP.NET Core]] - Adjacent: [[Separation of Concerns]] · [[Dependency Injection]] ## 🤖 LLM 활용 **언제**: scaffolding generation, layer 위반 review, refactor towards layered. **언제 X**: 매 trivial CRUD — boilerplate overhead. ## ❌ 안티패턴 - **Anemic Service**: 매 service 가 단순 repo passthrough — domain logic 누락. - **Smart Controller**: business logic 의 controller 누수. - **Layer skip**: controller 가 repo 직접 호출. - **God Service**: 매 service class 가 5000+ lines — bounded context 분할 필요. ## 🧪 검증 / 중복 - Verified (Richards *Software Architecture Patterns* 2nd ed. 2022). - 신뢰도 A. ## 🕓 Changelog | 날짜 | 변경 | |---|---| | 2026-05-08 | Phase 1 | | 2026-05-10 | Manual cleanup — layered patterns + Spring example + anti-patterns |