4월 30일 TIL (아키텍처)

아키텍처?

• 공식적인 의미로는

  소프트웨어 시스템 전체의 구조와 조직을 결정하는 프로세스로, 시스템의 기본적인 구조를 설계하고 이를 컴포넌트로 분할하며, 컴포터는 간의 상호 작용 및 데이터 흐름을 정의하는 것

• 사실 위에만 보고 이해를 할 수 있다면, 추가적인 공부를 할 필요가 없다고 생각한다.
• 당연히 나도 무슨 의미인지 직접 공부를 해보기 전까지는 이해를 할 수 없었지만, 공부를 하기 전의 나의 아키텍쳐의 대한 정의는 아래와 같다.

  아키텍처를 신경을 쓰지 않고도 어떤 기능을 만들어내는데는 전혀 문제가 없을수 있지만, 비교적 효율적으로 관리, 유지보수, 개발자간의 소통을 위해 우리끼리 정한 특정 룰(?), 구조

• 내가 이해한 바로는, 어떤 소프트웨어든 버그를 수정해야 될 상황이 있을수도 있고, 기능을 추가 변경을 할 수 도 있는데, 그런 상황들을 고려해서, 아키텍처를 채용해서, 개발하는 사람이 조금 더 편하게 도와주는 그런 구조인 것 같다.
• 다른 블로그에서 봤던 글을 통해 아키텍처의 중요성을 조금 알게 되었다.

  기능 GOOD + 구조 BAD = 당장은 좋지만, 개선하기 힘듦, 좋은 프로그램 X
  기능 BAD + 구조 GOOD = 당장은 아쉬울수 있지만, 개선 가능성 높음, 미래가 밝은 프로그램 O
  기능 GOOD + 구조 GOOD = 우리가 추구해야할 좋고, 미래가 밝은 프로그램

• 여기서 구조의 역할을 딱 아키텍처가 해준다고 생각하면 된다!

아키텍처을 사용하는 이유?

• 다양한 아키텍처가 있지만 궁극적으로 아키텍처를 정하고 사용하는것은 아래와 같은 요소들을 고려해야 하기 때문이다.
  1. Scalability : 확장성
     • 어플의 확장성을 고려해서 간단하고, 쉽게 확장할 수 있는 아키텍처를 선택해야 합니다.
  2. Maintainability : 유지 관리
     • 유지 보수를 하기 쉬운 아키텍처를 선택해야 합니다.
  3. Reliability : 신뢰성(?)
     • 신뢰성은 정확한 표현이 아니고, 사용자가 어플을 사용할때 어떤 오류가 나올수 있는데, 그런 오류들을 대처할 수 있는 방법을 쉽게 구현할 수 있는 아키텍처를 선택해야 합니다.
• 그러면 위에서 말한 확장성, 유지 관리, 신뢰성을 높일 수 있는 방법은? (좋은 아키텍처는?)

• Separation of Concerns (SoC) : 시스템 요소가 단일 목적이고, 즉 각각의 개체가 책임이 분리가 되어 있어야한다는 의미다
• Code reusability : 코드 재활용성을 고려해서 구현이 되어야 한다는 의미다.
• Testability : 테스트하기 용이해야 한다는 의미이다.
• Independence : Soc랑 비슷한 개념이지만, 각각의 기능들이 분리가 되어 있어야 한다는 의미이다.

---

Swift에서 흔히 사용하는 아키텍처

MVC (Model - View - Contrller) [ CocoaMVC ]

MVVM (Model - View - ViewModel)

등등

MVC

• MVC는
  • Model : 데이터와 비즈니스 로직을 관리
  • View : 레이아웃과 화면을 관리
  • Controller : View에 과 Model 명령을 전달
• 전체적인 프로세스는 아래와 같다.
  1. View에서 사용자한테 화면을 보여주고 사용자로 부터 상호작용을 받는다
  2. 상호작용 받은 정보를 Controller에 전달한다
  3. Controller에서 받은 정보를 토대로 Model에 전달해서 데이터를 업데이트 하라고 전달한다.
  4. Model에서 데이터를 업데이트 하고 다시 View로 전달한다.
• 기존 MVC는 사실 Swift에서 사용하기에는 문제점이 있다
  - Swift에서는 ViewController가 하나로 묶여있다, 물론 UIView 가 따로 있지만, 애초에 분리 해서 구현하는게 더 복잡해진다.
  • 유지보수 측면에서도 그림만봐도, View, Controller, Model이 서로 엮여있기 때문에, 하나를 고치면 두개를 다 고쳐야하는 상황이 발생한다.
  • 그림에서 나온거는 웹페이지 처럼 데이터를 받고 Model에서 받고, Controller를 통해 다시 한번 Rendering 하는 상황에서 유용한 구조이지만, Swift에서는 화면 전체를 다시 Rendering 보다는 하나의 View만 업데이트 하는 경향이 많다
• 그러면 Swift에서 이상적인 MVC구조를 상상한다면 어떤 모습이 될까?

APPLE에서 고려한 "개선된 MVC"

• 해당 MVC도 마찬가지로 Model,View,Controller로 구성이 되어 있다.
• 다만 다른점은 View와 Model은 더이상 연결이 되어 있지 않고, Controller가 중간에서 매개체 역할을 하고 정보를 전달/수신 업데이트를 해준다.
• Controller가 제일 중요하고 많은 역할을 하기 때문에 Controller에서 대부분의 로직을 구현하면된다.
  • 다만 제일 큰 문제는 장점이자 단점인 Controller의 역할이다.
  • Controller가 모든 로직 구현을 담당하다보니깐 기능이 많아 질수록 Controller의 코드 복잡도가 어마어마하게 상승하게 된다.
  • (뮤직컬 오디션에서 "지금 이순간" 부르는 것처럼) MVC의 단점을 말할때는 "Massive View Controller"라는 말이 무조건 나온다
  • Controller의 역할이 너무 많다보니깐 유지보수 측면에서도 좋다고 말하기는 어렵다.
• 그리고 사실 우리가 SWift로 구현을 하면 View랑 controller가 분리되어 있다고 말하기는 조금 그렇다, 우리는 ViewController를 사용하기 때문이다.
• 따라서 실제 Apple MVC를 다이어그램으로 그려보면 아래와 같다.

• View, Controller가 하나로 된 ViewController와 Model이렇게 나눠져 있는 것이다.
• 결과적으로 보면 기존의 MVC랑 비슷하게 View와 Model이 직접적으로 소통을 하는것이다. (물론 Controller인 ViewController를 통해서 하는거지만, swift에서는 하나로 생각하기 때문에..)
• 그러면 앞서 말한 좋은 아키텍처 정의로 한번 해당 아키텍처를 분석해보자.
  • Separation of Concerns (SoC) : Controller가 거의 모든 책임을 갖고 있다.
  • Code reusability: Model만 재활용할 수 있지 않을까?..
  • Testability : 마찬가지로 ViewController가 하나이기 때문에 테스트하기에도 쉽지 않다.
  • Independence : 기능들이 나눠져 있다고 보기에는 힘들다.
• 정리해서 말하자면,
• MVC의 장점:
  • Apple에서 고려한 아키텍처이기 때문에, 처음 사용하기에는 간편하고 쉽다.
  • ViewController - Model 이렇게 두개만 고려를 하면되기 때문에 간편하다.
  • 추가적인 코드가 필요하지 않다.
• MVC의 단점:
  - View, Controller가 분리되어 있지 않아서 유지보수, 테스트하기에는 적합하지 않다.
  • Controller가 대부분의 역할을 하고 있다.

MVVM

MVC는
- Model : 데이터만 관리
- View (ViewController) : 레이아웃과 화면을 관리
- ViewModel : Model에서 변경사항을 ViewModel에서 View로 전달하는 매개체, 반대로도 마찬가지다.

• 전체적인 프로세스는 아래와 같다.
  1. View에서 사용자한테 화면을 보여주고 사용자로 부터 상호작용을 받는다
  2. 상호작용에서 데이터를 수정한다면, ViewModel로 변경사항을 보내준다.
  3. ViewModel에서 다시 Model을 접근해서 변경한다.
  4. ViewModel에서 다시 View로 변경된 Data를 전달한다.
• 정말 어마어마하게 헷갈리지만, 정리한 예시 코드와 다이어그램으로 약간의 이해를 해볼려고 노력해봤다.

• 위 그림은 간단한 시계를 보여주는 어플을 만든것을 MVVM 아키텍처를 사용해서 구현한걸 보여주는 다이어그램이다.
• MVVM의 제일 큰 장점인 View과 Model은 직접적으로 연결이 되어 있지 않고, 모든 Data는 ViewModel를 거쳐서 업데이트가 된다.
• Data Binding이 MVVM에서의 제일 중요한 키 포인트인건 맞지만, Model과 View를 분리하고, ViewModel에서 전체적으로 관리하자라는게 MVVM의 제일 핵심 포인트이기 때문에, Data Binding이 안되어 있더라도 MVVM구조라고 말할수 있다.

참고 :

https://ios-daniel-yang.tistory.com/59
https://blog.canapio.com/43
https://medium.com/@dev.omartarek/mvp-vs-mvvm-in-ios-using-swift-337884d4fc6f