Files
2nd/00_Raw/Layered Architecture.md
T

3.4 KiB

Layered Architecture

📌 Brief Summary

Layered Architecture(계층형 아키텍처)는 데이터, 로직, 프레젠테이션과 같은 기술적인 역할(Technical Role)에 따라 관심사를 분리하는 전통적인 소프트웨어 아키텍처 방식입니다 [1]. React 프로젝트에서는 주로 components, hooks, services, store와 같이 파일 유형별로 폴더를 구성하는 형태로 적용됩니다 [1, 2]. 이 구조는 초기 프로젝트 설정이 직관적이고 소규모 애플리케이션에는 적합하지만, 애플리케이션이 커질수록 단일 기능(Feature)이 여러 계층에 흩어지게 되어 코드 유지보수 및 확장성이 크게 떨어지는 단점이 있습니다 [1-3].

📖 Core Content

  • 기술적 역할에 기반한 분리 (Separation by Technical Role): Layered Architecture는 MVC(Model-View-Controller), MVP(Model-View-Presenter), MVVM 등의 패턴처럼 애플리케이션을 데이터, 비즈니스 로직, 프레젠테이션 계층으로 나눕니다 [1, 4]. 프론트엔드 프로젝트에서는 주로 모든 컴포넌트를 하나의 폴더에, 모든 훅(Hooks)을 다른 폴더에, 스타일을 또 다른 폴더에 모아두는 방식(Type-Based Organization)으로 나타납니다 [1, 2].
  • 초기 직관성과 소규모 앱에 대한 적합성: 이 구조는 기술적인 명확성을 최적화하므로, 개발 초기의 작은 프로토타입이나 중소규모 애플리케이션(Small to medium applications)에서는 시작하기 쉽고 직관적인 장점이 있습니다 [1-3].
  • 확장성 및 유지보수의 한계: 프로젝트의 규모가 확장됨에 따라 여러 가지 구조적 결함이 발생합니다.
    • 단일 기능(Logical feature)에 관련된 파일들이 프로젝트 디렉토리 전체에 파편화되어 분산됩니다 [1, 2].
    • 비즈니스 로직이 쪼개져 있어, 하나의 기능을 리팩터링하거나 수정할 때 관련이 없는 수많은 폴더와 파일들을 탐색하고 수정해야 하므로 개발자의 인지 부하(Cognitive load)가 증가합니다 [1, 2].
    • 기존 백엔드 중심적인 구조를 프론트엔드에 강제하는 경향이 있어, React와 같이 모던한 컴포넌트 기반 라이브러리의 본질과 완벽하게 부합하지 않습니다 [4].
  • 현대적 대안으로의 전환: 이러한 확장성(Scalability) 문제를 해결하기 위해, 2025년 프론트엔드 생태계에서는 기술적 파일 유형이 아닌 비즈니스 기능 자체를 중심으로 코드를 그룹화하는 기능 기반 폴더 구조(Feature-Based Organization) 또는 Feature-Sliced Design(FSD) 패러다임으로 전환하고 있습니다 [5, 6].

🔗 Knowledge Connections


Last updated: 2026-04-26