단방향 / 양방향 데이터 흐름

오늘은 프로젝트에서 데이터 바인딩을 설계하는 과정에서, 아래와 같은 항목에 대해 정리해볼 예정입니다.

• 데이터 바인딩이란?
• 단방향 데이터 바인딩
• 양방향 데이터 바인딩
• 현재 프로젝트에서는 무엇을 적용하게 되었는 지

---

데이터 바인딩?

데이터 바인딩 개요 - WPF .NET

데이터 바인딩 개요 - WPF .NET

 

데이터 바인딩이란 앱 UI와 해당 UI가 표시하는 데이터를 연결하는 프로세스입니다.

우리가 앱의 사용자가 된다고 생각을 해보겠습니다.

어떠한 인터렉션을 주게 되면 그에 대한 화면 변화가 일어날 상황이 있습니다.

이렇듯 데이터 소스와 UI 요소를 연결하여 데이터가 변경될 때 자동으로 UI가 업데이트되도록 하는 메커니즘을 데이터 바인딩이라고 합니다.

• 이를 통해 데이터 일관성 / UI 동기화 유지, 상호작용을 원할하게 할 수 있습니다.

---

단방향 데이터 바인딩

말 그대로 단방향 데이터 바인딩은 데이터가 한 방향으로만 흐르는 패턴입니다.

일반적으로 데이터 소스에서 UI로의 단방향 흐름을 가집니다.

• View는 데이터를 표시만 하고, 직접적인 데이터를 수정할 순 없습니다.
• Action → State → View로 이어지는 구조를 가집니다.

작동방식

흐름도

1. 데이터 소스(Model/ViewModel)에서 상태 변경을 감지합니다.
2. Observable / Publisher가 변경을 감지합니다.
3. View에 변경사항이 반영됩니다.
4. View에서 변경이 필요한 경우 Action을 통해 데이터 소스에 변경을 요청합니다.

이로 인해 아래와 같은 특징을 가집니다.

• 데이터 무결성
  • 데이터 일관성 보장
  • 예측 가능한 상태 관리
• 상태 추적
  • 명확한 데이터 흐름을 가져 디버깅이 용이

---

양방향 데이터 바인딩 (Bidirectional Data Binding)

용어 그대로 해석을 해보자면, 데이터 소스와 UI 사이에서 양쪽 모두 데이터를 업데이트할 수 있는 패턴입니다.

• 데이터가 양방향으로 자동 동기화
• View와 데이터 소스가 서로 직접적인 영향
• 상태 변경이 양쪽에서 자유롭게 발생
• View ↔ State의 직접적인 연결

작동 방식

흐름도

1. 데이터 소스나 View 어느 쪽에서든 변경 가능합니다.
2. 변경 사항이 자동으로 반대편에 반영됩니다
3. 실시간 동기화로 즉각적인 UI가 업데이트 됩니다.
4. 양방향 Observable/Publisher가 동기화를 관리합닏.

이로 인해 아래와 같은 특징을 가집니다.

• 데이터 동기화
  • 실시간 양방향 업데이트
  • UI와 데이터의 즉각적인 일치

SwiftUI에서 Binding, Published를 이용한 데이터바인딩이 대표적인 예시라고 합니다.

---

HEIM에선 어떻게 데이터 바인딩을 진행하는가?

디자인 패턴 중 MVVM을 사용하기로 결론이 나면서 ViewModel의 protocol을 아래와 같이 적용했습니다.

protocol ViewModelType {
  associatedtype Action
  associatedtype State

  var state: State { get }

  func action(_ action: Action)
}

구조는 아래와 같습니다.

1. State
   • var state: State { get }
   • 아까 전 단방향 데이터 바인딩에 관해 이야기한 읽기 전용으로 상태를 제공합니다.
   • View는 이 상태를 단방향으로 구독하여 UI를 업데이트 합니다.
   • 즉, View에서 직접적인 수정이 불가능해집니다.
2. Action
   • func action(_ action: Action)
   • View에서 상태 변경이 필요할 때는 반드시 Action을 통해 요청합니다.
   • 모든 상태 변경의 시작점입니다.

• 사용 예시는 아래와 같습니다.

// 1. State와 Action 정의
final class exampleViewModel: ViewModelType {
    // 가능한 모든 Action 정의
    enum Action {
        case 더하기
        case 빼기
    }
    
    // 화면에 표시될 모든 상태값 정의
    struct State: Equatable {
        var items: [String]
        var count: Int
    }
    
    // 상태 관리
    @Published var state: State
    
    init(dataService: DataServiceType) {
        self.state = State(items: [], count: 0)
    }
    
    // Action 처리
    func action(_ action: Action) {
        switch action {
        case .더하기:
            plus()
        case .빼기:
            minus()
        }
    }
}

// 2. Private 메서드로 실제 동작 구현
private extension SimpleViewModel {
    func plus() {
        // 더하기 작업
    }
    
    func minus() {
        // 빼기 작업
    }
}

최종 프로젝트 MVVM에서의 데이터 흐름

 

최종적으로 HEIM에서의 데이터 바인딩의 흐름을 정리하면 위의 그림과 같습니다.

위와 같이 프로토콜을 정의하여 사용한 이유는 아래와 같습니다.

1. 코드의 구조화된 설계
   • 모든 ViewModel이 동일한 패턴을 따름으로서 구성원들 간의 코드 이해도 향상
2. 디버깅
   • 모든 상태 변경이 Action을 통해 이뤄진다.
   • 디버깅 시 상태 변경 지점 파악이 용이해진다.
3. 테스트
   • Action과 State를 독립적으로 테스트 할 수 있다.
   • Mock 개체 생성에 용이해진다.

마치며

각 항목에 대해 적용해보기 까지는 프로젝트의 진행도가 올라가면서 겪어야 할 것 같습니다.

• 이에 대해선 추후 정리를 할 예정
  • • Reactive Programming이란?
  • 공부하면서 느끼는 점은 하나를 공부할 때 알게되는 부분은 빙산의 일각이라는 것..