Flux와 MVC (단방향 데이터 흐름) (1)

리덕스는 기본적으로 "단방향 데이터 흐름"을 갖고 있다. (혹은 Flux 아키텍쳐를 채택한다고도 한다.)

이 흐름을 이해하기 위해서는 소프트웨어 개발이 어떤 구조에 기반하는지부터 시작해야 한다.

 

다음은 소프트웨어 개발에서부터 단방향 데이터 흐름 vs 양방향 데이터 흐름까지 본 글을 목차화한 것이다.

1. 소프트웨어 개발에서의 아키텍쳐(architecture)
2. 웹 소프트웨어 개발에서의 Model과 View
3. Flux 아키텍쳐 (단방향 데이터 흐름)
4. MVC 아키텍쳐 (양방향 데이터 흐름)
5. 단방향 데이터 흐름 vs 양방향 데이터 흐름

 

유의할 점은 본인이 상당히 컴퓨터 공학에 대한 지식이 부족하다는 점(🤣)과 함께 각 개념들이 대립되는 개념이라기보다는 상황에 맞게 선택되어야 하는 개념이라는 것이다.

 

특히 소프트웨어 아키텍쳐는 단순히 Flux와 MVC만 있는게 아니라는 것,

본 글의 시작인 Redux의 이해에 있어서 Redux는 Flux아키텍쳐를 기반으로 재설계된 개념이라기 보다는 우리가 사용하고 있는 모든 시스템에서는 자연스레 사용되고 있는 데이터 흐름을 개발자들이 사용하기 더 용이하도록 만들어진 "라이브러리"에 불과하다는 것

 

이 두 가지를 미리 언급하고 생각을 전개해보고자 한다.

 

스압으로 인해,,, 3.Flux 아키텍쳐부터 다음 포스팅에서 정리했다!

: https://whaleinmilktea.tistory.com/77

소프트웨어 개발에서의 아키텍쳐(architecture)

소프트웨어에서의 아키텍쳐란, 소프트웨어 개발을 위해 설계하고 구축하기 위한 기본적인 구조와 원칙을 말한다.

건축에서 아키텍쳐 개념을 사용하는 이유는, 건축물이 무너지지 않고 제 기능을 발휘하도록 설계하기 위한 여러 기준을 말한다.

 

소프트웨어는 0,1 (혹은 true/false)로 이뤄진 신호의 집합이고 단위 컴포넌트가 이 신호들을 주고받으며 구성되어 진다이다. 아키텍쳐는 이러한 신호들이 제각기 다른 로직으로 꼬이는 걸 방지하고 여러 사람들이 협업함에 있어서, 사용자가 데이터를 사용함에 있어서 중요한 역할을 맡는다.

 

소프트웨어는 설계되는 시점부터 충분한 재정적 지원을 바탕으로 한 지식정보 집약 작업에 해당하기 때문에, 무엇보다 효율적이고 확정적인 설계가 중요하다. 그렇기 때문에 적절한 아키텍쳐를 기반으로 한 소프트웨어 설계가 중요하다.

 

다음은 소프트웨어 아키텍쳐 설계에 있어서 기본적으로 고려되는 요소들이다.

1. 컴포넌트(Component) : 소프트웨어 시스템을 구성하는 기본 단위
2. 인터페이스(Interface) : 컴포넌트 간의 상호 작용을 정의
3. 패턴(Pattern) : 재사용성을 높이고, 유지보수성을 향상시키기 위한 규칙
4. 계층(Hierarchy) : 시스템의 확장성과 함께 단위 기능의 확실한 통제를 위해 각기 독특한 계층을 설계

위의 내용은 소프트웨어 구성에 있어서 아키텍쳐를 설계할 때에 개발자들(정확하게는 실리콘밸리, 판교에 계신 큰 형님들께서..)이 고려해야 하는 기본적은 구성일 뿐, 사실 아키텍쳐에 있어서 고려해야 하는 것은 사용성, 유지보수성 등 여러 기초 실무의 요소가 고려되어야 한다.

---

아키텍쳐의 Model과 View

Model과 View는 데이터 베이스에 저장된 정형화된 데이터를 프론트엔드 개발자가 받아와서 사용자가 사용가능한 인터페이스로 만드는 과정에서 빼놓을 수 없는 개념이다.

 

Model(모델)은 데이터를 나타내는 객체 또는 데이터 구조를 말한다. 

모델은 데이터 베이스에 저장된 정형화된 데이터를 데이터 계층으로 가져와 프론트엔드와 소통할 수 있는 객체 형식으로 변환해주는 역할을 맡는다. 데이터 베이스에 저장된 정형화된 데이터와 API를 통해 접근할 수 있는 배열/객체 데이터와 차이가 있는걸까?

다음의 코드를 통해 살펴보고자 한다.

// React.js에서 설계된 person 객체 정의
const person = {
  name: "John",
  email: "john@example.com",
};

person.age = 30;

console.log(person); // { name: "John", email: "john@example.com", age: 30 }

// MongoDB에서 설계된 데이터 베이스

const { MongoClient } = require("mongodb");  // MongoDB Node.js Driver를 불러온다.

const uri = "mongodb://localhost:27017/mydb";  // MongoDB 연결 정보를 uri 상수에 저장한다.

const client = new MongoClient(uri);  // MongoClient 인스턴스를 생성한다.

async function getUsers() {  // 비동기 함수 getUsers()를 생성한다.
  await client.connect();  // MongoDB 서버와 연결을 수행한다.

  const collection = client.db("mydb").collection("users");  // MongoDB의 mydb 데이터베이스의 users 컬렉션을 찾는다.

  const users = await collection.find().toArray();  // users 컬렉션에 있는 모든 document를 배열로 가져온다.

  console.log(users);  // 가져온 document를 출력한다.
}

getUsers();  // getUsers 함수를 호출한다.

위의 코드에서 살펴볼 수 있는 것과 같이 프론트단에서 설계되는 객체는 비교적 가독성이 높고 구조를 이해하기 쉽게 작성되어있으나, 데이터베이스는 단순히 소포물을 저장하는 걸 넘어 각 소포에 태그를 달아 여러 상황에서 사용하는 것처럼 만들어져야 되기 때문에 상당히 통신/저장 방식이 정형화되고 구조적인 형태로 작성되어 있다.

 

이렇듯 여러 데이터를 행과 열로 구조화하여 정리한 데이터 베이스의 형식을 "스키마"라고 하며, 이 스키마가 설계되어 있어야 회원 가입을 통해 얻은 유저정보를 로그인 상황 뿐만 아니라 여러 연계 로그인 / 게시글 작성자 정보 전달 등의 다른 유형으로 활용이 가능한 것이다.

 

다만, 이러한 데이터 베이스를 그대로 사용할 경우 프론트 단에서 이해하고 고려해야 하는 객체가 상당히 복잡해지고 비대해지게 된다.

이러한 이유로 Model이라는 데이터 계층 개념이 등장한 것이다.

 

데이터 계층이란, 인터페이스를 통해 데이터 베이스에 보낸 요청을 중간에 각 단에서 이해가능한 형태로 변환하는 중간 계층을 의미한다.

프론트엔드 개발자가 API의 body를 통해 쉽게 파악할 수 있는 객체를 얻을 수 있는 이유는 백엔드 개발자 분들께서 데이터 계층을 설계했기 때문이다. (이 설계 작업을 맵핑이라 한다.)

---

View(뷰)는 사용자에게 보여지는 UI를 말한다. 뷰는 모델에서 가져온 데이터를 시각적으로 표현하고, 사용자와의 상호작용을 통해 데이터를 조작할 수 있도록 한다. 예를 들어, 게시판 어플리케이션에서 게시글 목록을 보여주는 뷰를 만들 때, 모델에서 가져온 게시글 데이터를 화면에 나타내주는 것과 같은 사용자가 조작가능하고 볼 수 있는 모든 것은 프론트 단에서 설계된다.

 

요약하면,

모델은 데이터를 나타내고 가져오는 역할을 하고,

뷰는 이를 사용자가 이해할 수 있는 시각적인 형태로 나타내주는 역할을 한다.

 

모델과 뷰는 서로 분리되어 있어야 하며, 이를 위해 데이터 계층을 사용하거나 프레임워크에서 제공하는 MVC 패턴 등을 사용하게 된다.

 

스압으로 인해,,, 이후 내용은 다음 포스팅에서...