MVC 구조 - 옵저버 패턴 ( Observer Pattern )

 

프로그래밍을 하다 보면 “어떤 상태가 바뀌었을 때, 관련된 다른 코드들도 자동으로 반응해야 하는 상황”이 자주 발생합니다.
예를 들어, 주식 가격이 변하면 투자자들이 알림을 받아야 하고, 날씨 정보가 바뀌면 화면에 표시된 날씨 위젯도 자동으로 업데이트되어야 합니다.

이런 상황에서 자주 쓰이는 디자인 패턴이 바로 옵저버 패턴(Observer Pattern) 입니다.

 

 

---

옵저버 패턴이란?

옵저버 패턴은 한 객체의 상태 변화가 있을 때, 그 객체를 구독(관찰)하는 다른 객체들에게 자동으로 통보가 전달되는 패턴입니다.

• 상태를 가진 객체: Subject (또는 Publisher)
• 상태 변화를 감지하고 반응하는 객체: Observer (또는 Subscriber)

목적

옵저버 패턴의 목적은 모듈 간의 의존성을 낮추고 결합도를 줄이는 것입니다.

발행(Publish)–구독(Subscribe) 모델로 설명할 수 있습니다.

• 구독(Subscribe): "이 일이 발생하면 나에게 알려줘!"라고 요청하는 것
• 발행(Publish): 어떤 일이 발생했을 때 구독자들에게 알림을 보내는 것

 

예시

신문 구독을 예로 들어보겠습니다.

• 신문사(Subject)는 새로운 신문이 나오면, 구독자 리스트에 있는 사람들에게 신문을 뿌립니다.
• 구독자(Observer)는 구독을 신청했다면 자동으로 신문을 받습니다.
• 누군가 구독을 취소하면, 그 사람은 더 이상 신문을 받지 않습니다.

구독자가 신문사에 매번 “오늘 신문 나왔나요?” 하고 물어보는 방식이 아니라, 신문사가 알아서 보내주는 구조라서 훨씬 효율적입니다.

---

간단한 코드 예시 (JavaScript)

 

기본 코드 구조

옵저버 패턴을 구현하기 위해 필요한 역할은 세 가지입니다.

1. 구독자를 등록하는 기능 (subscribe)
2. 구독자를 해지하는 기능 (unsubscribe)
3. 이벤트 발생 시 알림을 보내는 기능 (notify)

class Observable {
    constructor() {
        this._observers = new Set();
    }

    subscribe(observer) {
        this._observers.add(observer);
    }

    unsubscribe(observer) {
        this._observers.delete(observer);
    }

    notify(data) {
        this._observers.forEach(observer => observer(data));
    }
}

 

여기서는 Set 자료구조를 이용해 중복 없는 구독자 리스트를 관리했습니다.

구독자는 subscribe를 통해 등록되고, notify가 호출되면 구독자들에게 데이터가 전달됩니다.

---

호출 관계 흐름

옵저버 패턴에서 호출 관계는 단순합니다.

Observable → Observer

• Observer는 데이터를 직접 요청(pull)하지 않고, Observable이 알아서 알려주기를 기다립니다.
• 따라서 Observer는 단순히 구독만 하고 결과를 전달받습니다.

이것이 바로 단방향 데이터 흐름 (Unidirectional Data Flow) 입니다.

 

 

 

MVC 패턴에 Observer Pattern 적용 :  M–V 관계

 

옵저버 패턴은 MVC(Model–View–Controller) 구조에서도 자주 사용됩니다.

• Model: 상태를 관리하고, 변화가 생기면 알림을 발행합니다. (Observable 역할)
• View: 상태를 구독하고, 변화가 생기면 화면을 업데이트합니다. (Observer 역할)

이벤트 발생 → 상태 변경(Model) → 화면 반영(View)

 

Todo App 예시

예를 들어 Todo 앱에서 Model이 todos 데이터를 관리하고, View는 이를 화면에 표시한다고 해봅시다.

Model이 Observable을 상속받으면, 구독 관리 로직을 따로 작성할 필요가 없습니다.

class TodoModel extends Observable {
    constructor() {
        super();
        this.todos = [];
    }

    addTodo(todo) {
        this.todos = [...this.todos, todo];
        this.notify(this.todos);  // Observer들에게 업데이트된 todos 전달
    }
}

• TodoModel은 새로운 todo를 추가하고,
• 상태가 바뀔 때마다 notify로 구독자(View)에 알림을 보냅니다.

 

Store-TextView 예시

// Subject (발행자)
const store = {
  state: { issueState: "open" },
  listeners: [],

  setState(patch) {
    this.state = { ...this.state, ...patch };
    this.notify();
  },

  subscribe(fn) {
    this.listeners.push(fn);
  },

  notify() {
    this.listeners.forEach(fn => fn(this.state));
  }
};

// Observer (구독자)
const TextView = {
  render(state) {
    console.log("현재 상태:", state.issueState);
  }
};

// 구독 연결
store.subscribe(TextView.render);

// 실행 예시
store.setState({ issueState: "closed" });
// 출력: "현재 상태: closed"

 

여기서 store는 Subject, TextView는 Observer 역할을 합니다.
이렇듯, store의 상태가 바뀌면, 자동으로 TextView.render가 호출되며  화면을 다시 렌더링합니다.

 

• 옵저버 패턴은 발행–구독 모델로, 모듈 간 결합도를 낮추고 단방향 데이터 흐름을 보장합니다.
• MVC 구조에서 Model은 Observable, View는 Observer가 되어 자연스럽게 상태 변화가 UI에 반영됩니다.
• 실무에서는 React, Vue 같은 프레임워크 내부에서도 옵저버 패턴이 기본 원리로 활용되고 있습니다

 

 

옵저버 패턴의 장점

1. 결합도 감소
   • Subject는 Observer의 구체적인 동작을 몰라도 됩니다. 그냥 “상태 바뀌었어!”만 알리면 끝.
2. 유연성 증가
   • 새로운 Observer를 추가하더라도 Subject 코드를 수정할 필요가 없습니다.
3. 자동화된 반응
   • 상태 변경 → 알림 → UI 업데이트가 자동으로 연결됩니다.

 

• 뷰를 직접 일일히 호출하지 않고도, 모델에 관심이 있다고 구독을 해두고, 자동으로 변경되도록 할 수 있습니다.
• = Controller 에서 이벤트 발생시 관련된 뷰를 직접 일일히 업데이트하지 않아도 됩니다.
• Model 값만 바뀌면 그와 연관한 View 가 자동으로 바뀝니다

 

 

 

---

주의할 점

• 이벤트가 어디로 흘러가는지 추적이 어려울 수 있습니다.
  Observer가 많아지면, 누가 무엇에 반응하는지 코드만 보고 파악하기 힘들어질 수 있습니다.
• 구독 해제(unsubscribe)를 관리하지 않으면 메모리 누수가 발생할 수 있습니다.
  사라진 객체도 계속 알림을 받을 수 있기 때문입니다.

---

옵저버 패턴은 “상태 변화 → 자동 반응”이라는 단순한 아이디어에서 시작합니다. 

프론트엔드 프레임워크(React, Vue)에서 상태 관리(Store–View 구조)에 많이 응용되고,
백엔드에서도 이벤트 기반 아키텍처를 설계할 때 자주 사용됩니다.

 

 

 핵심은 “내가 일일이 상태를 Pulling 하지 않아도, 상태가 바뀌면 자동으로 알림이 전달된다”는 점입니다.

 

그럼 이어서 React에서 옵저버 패턴이 어떻게 활용되는지를 예시로 보여드리겠습니다.

---

React에서의 옵저버 패턴

React는 내부적으로 옵저버 패턴과 유사한 개념을 사용합니다.

• 상태(state) 가 바뀌면,
• 이를 구독하고 있는 컴포넌트가 자동으로 다시 렌더링됩니다.

즉, store → view 구조와 거의 똑같습니다.

---

간단한 예시

import React, { useState } from "react";

function App() {
  const [issueState, setIssueState] = useState("open");

  return (
    <div>
      <TextView issueState={issueState} />
      <Menu setIssueState={setIssueState} />
    </div>
  );
}

function TextView({ issueState }) {
  return <p>현재 상태: {issueState}</p>;
}

function Menu({ setIssueState }) {
  return (
    <div>
      <button onClick={() => setIssueState("open")}>Open</button>
      <button onClick={() => setIssueState("closed")}>Close</button>
    </div>
  );
}

export default App;

---

동작 설명

1. App 컴포넌트는 상태(issueState)를 가지고 있습니다.
   → 이게 바로 Subject 역할입니다.
2. TextView 컴포넌트는 issueState를 props로 받아 화면을 렌더링합니다.
   → 이게 바로 Observer입니다.
3. 버튼을 눌러 setIssueState로 상태를 바꾸면, React는 자동으로 해당 상태를 구독하는 컴포넌트를 찾아 리렌더링합니다.

---

정리

• 전통적인 옵저버 패턴에서는 Subject → notify → Observer 구조로 동작합니다.
• React에서는 이 흐름이 state → 리렌더링 → UI 업데이트로 추상화되어 있습니다.
• 덕분에 개발자는 notify() 같은 코드를 직접 작성할 필요 없이, useState나 useReducer만으로 옵저버 패턴의 이점을 누릴 수 있습니다.

---

옵저버 패턴은 단순한 이론이 아니라, React의 근간에 녹아 있는 개념이라고 이해할 수 있습니다.