웹 프론트엔드 클린 아키텍쳐(Clean Architecture) 의 역사

 

 

오늘은 어플리케이션 아키텍쳐를 설계할 때 쓰이는 MVC, MVP, MVVM 등의 여러가지 패턴에 대해서 어떠한 배경에서 이러한 아키텍쳐가 나왔고 어떠한 원리로 작동하는지 깊게 이해해보는 시간을 가지려고 한다.

 

 

MVC 패턴

가장 먼저, 모든 것의 원조가 되는 MVC 패턴부터 살펴보려고 한다. Model-View-Controller의 약자로, 소프트웨어 설계에서 애플리케이션을 세 가지 주요 역할로 분리하여 구성하는 아키텍처 패턴이다.

• Model(모델) : 애플리케이션의 데이터, 비즈니스 로직을 담당. 데이터베이스와 직접 통신하거나, 데이터를 저장, 처리하는 역할
• View(뷰) : 사용자에게 보여지는 화면(UI)을 담당. Model의 데이터를 읽어와서 사용자에게 보여주지만, 직접 데이터를 수정하지는 않음.
• Controller(컨트롤러) : View와 Model 사이를 연결하는 중재자 역할. 사용자 입력을 받아 처리하고, 그에 따라 Model을 업데이트하거나 View를 변경. 

뷰에서 새로운 입력이 주어지면, 이를 컨트롤러에 알리고, 컨트롤러는 모델을 업데이트한다.

모델이 업데이트 되면, 컨트롤러는 뷰에 데이터를 새로고치라고 지시한다.

 

아래는 내가 실제로 구현했던 JS 콘솔 어플리케이션의 예시이다. View 에서 사용자로부터 금액을 입력받고, 

컨트롤러가 입력받은 값을 모델에 전하여 비즈니스 로직을 처리한다. 그리고 그 결과를 View 에 전달하여 최종 결과를 출력한다. 깔끔하게 MVC 패턴이 잘 분리된 사례이다.

 async handleBuyLottos() {
    const money = await InputView.readMoney();
    this.#customer = new Customer(money);
    this.#customer.buyLottos();
    OutputView.printLottos(this.#customer.getLottos());
  }

장점

 

• 역할을 분리함으로써 코드의 유지보수와 확장성이 좋아진다.
• 개발자가 Model, View, Controller를 독립적으로 개발할 수 있어 협업에 용이하다.
• 하나의 변화가 다른 부분에 미치는 영향을 최소화하여 결합도는 낮추고, 응집도는 높인다.

=> 코드의 책임이 명확하게 분리되어, 기능을 추가하거나 수정할 때, 테스트를 작성할 때, 다른 사람과 협업할 때
훨씬 수월해진다. 특히 View와 Model을 독립적으로 변경할 수 있어, 한쪽을 수정해도 다른 쪽에 미치는 영향이 적어진다.

 

단점

- 앱이 커질수록 컨트롤러가 비대해질 수 있다.

- 초기 구조를 잡을 때 많은 설계 고민 필요 -> 작은 규모의 프로젝트에서는 오히려 복잡도를 높이거나 초기 구현 비용을 높임

 

리액트에서 MVC 패턴을 사용할 순 없을까?

FE 에서 View 는 사용자 입력값, 화면선택 및 변경, 스케쥴, 서버통신 등 온갖 이벤트가 발생하는 공간이다. 

따라서, View 가 메인이자 컨트롤러 역할을 할 수 밖에 없다.

만약 Vanila JS 를 통해 MVC 패턴으로 프론트엔드를 구현하고자 한다면,

 

 

1. View 의 변경으로 Model을 바꾸어야하고 ex) 사용자 입력 값

2. Model 의 변경으로 View를 바꾸어야한다. ex) 서버로부터 받은 데이터

3. View 는 아주 많고, Model 도 많아서 다대다 많은 의존 관계가 형성될 수 있다.

 

그러나, 이렇게 되면 몇가지 문제점들이 생기는데

 

1. 의존성이 높아지고, 양방향 데이터 바인딩이 프로그램의 복잡도를 상당히 높인다.

2. 컨트롤러가 굉장히 비대해진다. 

3. View와 Controller 간의 양방향 참조가 발생할 수 있어 결합도가 높아진다.

 

 

따라서 이를 해결하기 위해서는 복잡한 뷰와 모델간의 관계를 단순화하고, 

View는 잦은 re-rendering 으로 계층적인 구조를 통해 렌더링 효율성을 얻어야한다.

 

 

 

MVP (Model-View-Presenter)  패턴

MVC 패턴을 발전시켜 View와 비즈니스 로직의 결합을 더 강하게 분리한 구조이다.

UI 로직을 처리하는 눈에 띄는 Presenter 를 도입한다.

 

• Model: 데이터와 비즈니스 로직
• View: 사용자 인터페이스(UI)를 담당하며, 오직 Presenter에 요청만 
• Presenter: View와 Model 사이를 연결하는 중간 매개체.
  View의 입력을 받아서 처리하고, Model의 데이터를 가공해서 View에 넘김

 

모델 데이터를 display용으로 변환하고, 사용자 입력을 처리하고, 모델과 뷰 업데이트를 조정한다.

이렇게 하면, Presenter 가 UI 동작을 구동하는 동안, View 는 픽셀을 렌더링하면서 간단하게 유지된다.

즉 UI 로직을 분리함으로서, View 가 한가지 역할에만 집중할 수 있도록하고 이는 클린 코드와 테스트를 용이하게 한다.

 

MVC 와 MVP 의 차이점

 

얼핏보면, Presenter 가 하는 역할이 기존 MVC 패턴에서 Controller 가 하는 역할과 별 차이가 없어보인다. 

 

Controller (MVC)

 

• View와 Controller 서로 영향을 줄 수 있다.
  • View가 Controller를 직접 호출할 수도 있고
  • Controller가 View를 직접 조작할 수도 있다.
• Controller는 주로 요청을 받고, 필요한 로직(Model 조작 등)을 처리한 뒤, 결과를 View에 전달한다.
• 구조적으로 느슨하게 연결되어 있어서 경우에 따라 View와 Controller가 얽히기 쉽다.

예를 들어, 회원가입 폼이 있다고 해보자.

1. 사용자가 "가입" 버튼 클릭 (View)
2. View가 Controller의 handleSignUp() 메서드를 호출 ( View가 Controller를 직접 호출 )
3. Controller가 입력값을 검증 ( Controller가 View를 직접 조작 )
4. 검증 실패 시 → Controller가 View를 조작해서, "이메일이 잘못되었습니다" 라는 에러 메시지를 직접 View에 표시

Presenter (MVP)

 

• View는 Presenter에게 완전히 의존한다.
• View는 직접 아무것도 하지 않고, 모든 비즈니스 로직 요청을 Presenter에게 위임한다.
• Presenter는 결과를 가공해서, View에게 "이렇게 표시해" 라고 명령만 한다.
• View는 그 지시를 따라 단순히 화면에 표시만 한다.
  (View는 Dumb Component, Passive한 역할)

 

 

같은 회원가입 폼 제출 상황을 보자.

1. 사용자가 "가입" 버튼 클릭 (View)
2. View는 그냥 Presenter에게 "가입 요청" 메시지만 보냄
3. Presenter가 검증 로직 실행
4. 검증 실패 시 → Presenter가 View에게 "에러를 표시해라" 라고 명령
5. View는 Presenter의 지시에 따라 단순히 에러 메시지만 표시

 

	MVC	MVP
View와 Controller/Presenter 관계	양방향	View → Presenter 단방향
View 역할	이벤트 감지 + 직접 처리도 가능	이벤트 감지만 하고 로직은 모두 Presenter에 위임
Controller/Presenter 역할	로직 처리 + View 직접 조작	로직 처리 + View에게 명령만 (View는 Dumb)

 

 

 

MVC 에서는 View 와 Controller 의 역할 구분이 모호했다. 실제로 내가 JS 콘솔 어플리케이션을 구현할 때에도,

어디까지를 View의 역할로 보고, 어디까지를 Controller 의 역할로 봐야할지 모호했던 경험이 있다. 그러나 MVP 는 매우 명확하게 역할 구분이 된다.

 

MVVM(Model-View-ViewModel) 패턴

UI 코드(View)와 비즈니스 로직(Model)을 ViewModel을 통해 분리하는 아키텍처 패턴이다.

주요 목적은 관심사 분리와 양방향 데이터 바인딩을 통한 UI와 상태 관리의 효율화이다.

 

• Model: 데이터와 비즈니스 로직
• View: 사용자 UI (HTML, 화면에 보이는 것)
• ViewModel: View를 위한 데이터 가공, 상태 관리, 액션 처리 (View와 Model의 중간자)
  
  

MVVM은 View와 ViewModel 사이에 양방향 데이터 바인딩을 통해 상태를 동기화하며, View는 순수 UI 역할에 집중하고 비즈니스 로직은 ViewModel에서 담당한다. 덕분에 View와 로직이 깔끔히 분리되고, 테스트와 유지보수가 쉬워진다.

 

가장 큰 특징은 여기서 View와 ViewModel의 양방향 데이터 바인딩인데

• 사용자가 View에서 입력하면 → ViewModel에 바로 반영되고
• ViewModel이 값을 변경하면 → View도 자동으로 업데이트된다.

 

=> 명시적인 업데이트의 필요성이 줄어든다. ViewModel 은 UI 변경사항을 자동으로 반영하기 위해서

raw 한 Model 데이터를 동기화한다. 

 

 

View 에서 새로운 입력을 받으면, View 는 양방향 데이터 바인딩을 통해 ViewModel 을 업데이트한다.

그리고 ViewModel 은 이 변경사항을 Model 에 유지한다.

모든 모델 데이터 업데이트는 명시적인 새로 고침 호출 없이도 바인딩 된 뷰 속성에 자동으로 반영이 된다.

 

다시 한번, 회원가입 예제를 들면,

 

1. 사용자가 이메일 입력
2. ViewModel의 email 데이터가 자동으로 업데이트
3. "가입" 버튼 클릭
4. ViewModel이 이메일을 검증하고 Model에 저장 요청
5. Model이 저장 결과를 돌려줌
6. ViewModel이 결과에 따라 "가입 성공" 메시지 값을 업데이트
7. View는 이 값을 바인딩해 바로 "가입 성공"을 화면에 보여줌

 

장점

 

- 양방향 데이터 바인딩을 통해 보일러 플레이트 코드가 필요한 업데이트를 간소화한다.

- View는 순수 UI 역할에 집중 -> UI와 비즈니스 로직을 분리

- View와 로직이 깔끔히 분리되고, 테스트와 유지보수가 쉬워진다.

 

단점

 

- 양방향 바인딩의 복잡도 : 자동 바인딩은 간단한 UI에서는 편리하지만, 복잡한 상태 흐름에서는 예상치 못한 사이드 이펙트나 디버깅 어려움을 유발할 수 있음

- ViewModel 설계가 어려움 : View와 완전히 분리된 ViewModel을 만드는 것이 이상적이지만, UI 종속적인 상태 처리가 많을수록 경계가 애매

 

리액트에서 MVVM 철학이 어떻게 반영되었는가?

리액트는 MVVM 패턴의 ViewModel 역할 일부를 컴포넌트가 흡수한 형태로 볼 수 있다.

다만 리액트는 MVVM을 명시적으로 따르지는 않으며, 그 구조를 단방향 데이터 흐름 (unidirectional data flow) 을 중심으로 재해석한 방식이라고 보는 게 더 정확하다. MVVM은 양방향 바인딩을 지원하지만, React 는 View 가 변하면 명시적으로 상태를 변경해주어야한다.

 

Model	상태(State), API 응답, 외부 데이터
ViewModel	컴포넌트 내부 로직 (hooks 포함: useState, useEffect, custom hooks 등)
View	JSX로 표현된 UI

 

🔄 바인딩 관점에서의 차이

 

• MVVM은 양방향 바인딩을 지원 (ex. Angular, Vue)
  • View가 변하면 ViewModel에 자동 반영
  • ViewModel이 변하면 View에 자동 반영
• React는 단방향 데이터 흐름 (one-way binding)
  • 상위 → 하위로 props 전달
  • View가 변하면 setState나 이벤트 핸들러를 통해 명시적으로 상태 변경

 

 

리액트는 어떤 아키텍처로 구성되어 있을까?

리액트는 전통적인 MVC, MVVM 같은 고전 아키텍처 패턴을 엄격히 따르지 않고, 자체적으로 “컴포넌트 기반 아키텍처”와 “단방향 데이터 흐름(Unidirectional Data Flow)” 에 기반한 구조를 갖는다.

 

Component-Based Architecture (컴포넌트 기반 아키텍처)

 

• UI를 작고 독립적인 컴포넌트 단위로 구성
• 각 컴포넌트는 자체 상태(state)를 가질 수 있으며, 재사용이 가능
• 컴포넌트는 함수형 (Function Component) 또는 클래스형 (Class Component) 으로 작성 가능

Container-Presenter 패턴

• UI 구성과 로직 처리를 명확히 분리하기 위해 사용하는 프론트엔드 아키텍처 패턴
• React 환경에서 많이 활용되며, 관심사의 분리를 통해 코드의 재사용성, 가독성, 테스트 용이성을 높여준다.

// 📁 UserContainer.jsx
import { useEffect, useState } from 'react';
import UserPresenter from './UserPresenter';

export default function UserContainer() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);

  return <UserPresenter user={user} />;
}

 

// 📁 UserPresenter.jsx
export default function UserPresenter({ user }) {
  if (!user) return <p>Loading...</p>;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

 

👍 장점

• 관심사 분리 (Separation of Concerns)
  → UI 로직과 상태 관리를 나눠서 유지보수 및 테스트 용이성 확보
• 재사용성 높은 Presenter 컴포넌트 작성 가능
• 테스트가 쉬움 (Presenter는 순수 함수형 UI)

❗ 단점 / 보완점

 

• 너무 분리하면 파일 구조가 지나치게 많아져 복잡도 증가
• Hooks와 custom hooks의 발달로 최근에는 일부 로직만 hook으로 분리하여 사용하는 경향도 있음 (→ Smart-Dumb 컴포넌트 패턴으로 유사하게 발전)

 

단방향 데이터 흐름(Unidirectional Data Flow)

• 상위 컴포넌트에서 하위 컴포넌트로 props를 통해 데이터가 전달됨
• 데이터 흐름이 한 방향으로 제한되므로 상태 추적과 디버깅이 용이함

 FLUX 패턴 

리액트의 단방향 데이터 흐름(Unidirectional Data Flow) 을 체계적으로 구현하기 위해 Facebook이 제안한 아키텍처 패턴이다.

복잡한 상태 관리를 명확하고 예측 가능하게 만들기 위해 고안되었다.

 

 

리액트 자체는 상태를 useState와 props 전달로 관리하지만, 복잡한 앱에서는 외부 상태 관리 라이브러리와 아키텍처가 결합된다.

예시로 리액트의 단방향 흐름을 구조화한 것이 Flux 아키텍처이며, 이를 구현한 대표 라이브러리가 Redux 이다.

 

• Action : 사용자의 입력, 서버 응답 등 ‘무슨 일이 일어났는지’를 담은 객체 (type과 payload를 포함)
• Dispatcher : 모든 Action을 받아서 등록된 Store에 전달하는 중앙 허브 (Flux의 핵심 차별점)
• Store : 애플리케이션의 상태(State) 와 상태 변경 로직을 보관
• View : React 컴포넌트로, Store를 구독하여 상태 변경이 생기면 자동으로 다시 렌더링

리액트 패턴의 진화 (역사 흐름 정리)

1. MVC, MVVM (2010년 이전 ~ React 등장 전)

• 웹 개발에서 널리 사용된 패턴들.
• MVC는 Model-View-Controller 구조로, 데이터-UI-로직을 분리함.
• MVVM은 ViewModel을 두어 View ↔ Model 간 바인딩 자동화를 강조.
• 하지만 양방향 데이터 바인딩으로 인해 복잡도 상승, 디버깅 어려움.

2. React의 등장: Component 기반 UI (2013~)

• React는 View만 담당하며, UI를 Component 단위로 분리.
• 선언형 UI, 단방향 데이터 흐름, 가상 DOM이라는 혁신적 개념 도입.

3. Container-Presenter 패턴 (2014~2015)

• 관심사 분리를 위해 도입.
  • Container: 상태 관리 및 로직 담당
  • Presenter: UI 표현만 담당 (props만 받음)
• 재사용성과 테스트 용이성 향상을 목표

4. Flux (2014)

• 페이스북이 제안한 상태 관리 아키텍처.
• Action → Dispatcher → Store → View 흐름의 단방향 구조.
• 구조는 명확하지만 보일러플레이트가 많고 Dispatcher가 번거로움.

5. Redux (2015)

• Flux의 복잡함을 줄인 개선 버전.
• 핵심 개념: 단일 Store + 순수 Reducer 함수 + Action
• Time-travel debugging 가능, 미들웨어 도입 가능.
• 대형 프로젝트에서 널리 채택됨.