TCA 1.0 - Hello, TCA (ch.01)

안녕하세요. 그린입니다 🍏

 

이번부터 TCA에 대한 포스팅을 간간히 학습하면서 해보려하는데요!

 

메이저 업데이트가 된 1.0을 기준으로 우선 ReducerProtocol을 사용하기전인 기존 버전들과 어떤 차이가 있는지들을 알아보기 위함이 가장 큽니다 😃

 

사실, 현재 TCA 최신 버전이 1.7까지 올라가면서 Observation의 사용으로 더 많은 변화들이 생겼고 앞으로도 매크로 등 더 많은 변화들로 제가 학습하는 속도보다 훨씬 더 빠르게 변화하고 있을 수 있습니다.

 

그럼에도 불구하고 왜 1.0으로 학습을 해보려하냐..?

 

가장 큰 이유는 TCA 공식 사이트의 강의나 문서들 외에 정말 괜찮게 톺아볼 수 있는 강의 자료를 찾았기 때문입니다 🙋🏻

(다시 한번 저자분들께 감사드립니다 🙇🏻)

 

SwiftUI 상태 관리부터 테스트까지 iOS 개발자를 위한 TCA 1.0 | Notion

 

국내 개발자분들께서 TCA의 공식문서와 Point-Free의 공식 세션 및 문서들을 기반으로 저자분들이 깨달은 부분이나 의견들도 같이 겸비되어 나온 자료인데 초반 쓱 훑어보는데 너무 괜찮아서 이걸로 1.0 버전을 전체적으로 학습해보려고 합니다ㅎㅎ

 

또, 최신 1.7이라고 하더라도 기조 자체는 1.0과 다르지 않기에 1.0을 학습하고 변화되는 최신 버전들의 변경점들을 습득하는것이 더 나은 학습이 되고 문제가 없을거라 생각했습니다 😀

 

이렇게 노션으로 퍼블릭하게 여러분들도 보실 수 있고, 리디에서 e-book으로도 다운받아 PDF로도 볼 수 있습니다!

 

그렇기에 TCA 1.0을 학습하면서 포스팅되는 글들의 모든 원본 자료들은 위 레퍼런스를 기반으로 제가 학습하면서 정리되거나 느낀 부분들을 끄적이려합니다 🙋🏻

 

당연히 포스팅들이 제가 정리하고 제 의견들로 이뤄져있기에, 제가 잘못 알고 있거나 생각들이 다른 부분이 충분히 있을 수 있어요!

그런것들이 있다면, 같이 의견 교류해보면 너무 좋겠습니다 🥹

 

본문 내용을 그대로 옮기거나 가져오는것이 아니라, 블로그 포스팅만으로 어떤 내용을 지금 정리하고 의견들을 말하는지 헷갈릴 수 있으니 해당 원본 레퍼런스를 먼저 읽고 오시거나 같이 참고하시는걸 추천드립니다 🙏🏻

 

그럼 우선 Chapter 1인 Hello, TCA 시작해볼까요~?

---

Chapter 1은 어떤 내용들이 담겨 있나 🤔

챕터 1은 TCA에 대해 전반적으로 나타난 배경과 소개 그리고 앞으로의 챕터들에 대한 짧은 소개들로 이뤄져있어요.

챕터 1인 만큼 그냥 가볍게 TCA가 뭔지 그리고 앞으로 우린 어떻게 뭘 배워가는지 서론이라고 생각하면 좋아요.

visionOS 발표전에 써진 문서라 해당 언급은 딱히 없더라구요!ㅋㅋ

 

자 그럼 이제 챕터 1을 본격적으로 톺아보겠습니다.

---

TCA 1.0 - Hello, TCA

---

TCA(The Composable Architecture)도 결국 추상화된 비지니스적 문제 해결 관점에서 바라보는 하나의 아키텍쳐 패턴의 범주에 속하기에 매번 정답인 은총알이 아닌, 단순한 하나의 방법론

• 그렇기에 모든 프로젝트에 상황에 딱 잘 맞고 가장 좋은 아키텍처라고 생각하는것은 위험합니다.
• 현재 가장 핫한 아키텍쳐 중 하나인건 부정할 수 없지만, TCA가 모든것을 해결해줄 수는 없습니다.
• 결국 상태관리가 핵심이기에 이 상태관리를 더 정형화 해놓고 내부적으로 잘 구성하였기에 사용하는것이지 상태관리를 위해서 꼭 TCA를 사용해야 하는것은 아니다.
• 정형화된 하나의 규칙을 사용하는 디자인 패턴과 혼동하면 안됩니다.

---

아키텍쳐 패턴 vs 디자인 패턴

• 아키텍쳐 패턴이 보통 디자인 패턴보다 범위가 더 넓음
• 아키텍쳐 패턴은 아이디어의 추상적 관점에 중점 (MVVM, MVC, MVP, VIPER, MVI 등)
• 디자인 패턴은 아이디어의 구현 관점에 중점 (Delegate, Singleton, Proxy, Composite 등)
• 쉽게 생각하면 아키텍쳐 패턴은 전체적은 구조 설계에서 사용되기에 초반에 다잡고 가야하지만, 디자인 패턴은 언제든 구현하면서 필요에 따라 자유롭게 사용하면 됨
• 하나의 아키텍쳐 패턴에 여러개의 디자인 패턴을 사용하여 구현 가능 (1:N 관계)
• 결국 정리하자면 아키텍쳐 패턴은 소프트웨어 디자인에서 추상화 레벨이 디자인 패턴보다 더 높고 디자인 패턴은 특정 모듈에 대해 하나의 구현 솔루션이라고 볼 수 있음

---

SwiftUI(선언형 UI)로 뷰 드로잉 하는 환경에서는 MVVM 패턴이 가장 일반적으로 사용

• 이 외에도 RIBs, VIPER, MVP, Clean Architecture 등의 아키텍쳐 패턴도 많이 활용
• 논점은 뷰와 로직을 확실히 잘 분리하고 더 나아가 관심사에 맞춰 더 잘게 쪼개 추상화 단계를 거치는것이 핵심이라고 생각합니다.

---

SwiftUI에 MVVM?

• 초반 SwiftUI가 나왔을때는 MVVM 아키텍쳐를 당연시하게 적용하는 분위기였고 지금도 어느정도 이어지고 있다고 생각합니다.
• 다만, 지금 기준으로 SwiftUI가 계속 발전함에 따라 MVVM을 적용하는것에 대해 의문이 생기기 시작함
• ViewModel의 핵심이던 State-Binding의 역할이 이미 SwiftUI에서 반영되어 있다는 점이 포인트
• Reactive Programming 관점에서보면 사실 ViewModel이 데이터를 바인딩하고 처리하는것이 핵심적이여서 MVVM이 당연시 되었지만, SwiftUI에선 비동기 처리를 위한 데이터 바인딩 자체를 View에서 할 수 있기에 ViewModel을 그런 의미로 사용하는것이 적절할까란 의문들이 최근 많이 제기되고 있습니다.
• 결국 ViewModel을 데이터 바인딩을 하기 위한 역할로 쓰이는것은 이중 MVVM 구조가 될 수 있기에 조금 더 본질적으로 들어가 상태 관리를 하고 로직을 나누는 역할로 쓰이는것이 적절하지 않을까 생각합니다.

---

TCA 탄생 설화 및 특징

• TCA는 값 타입을 기반하고 객체를 모듈화함으로 앱 전체의 상태를 일관적으로 관리할 수 있는 구조를 제안하게 됩니다.
• 즉, Composable하다는것은 나뭇잎을 생각해보면 각 최소 기능 단위로 구성된 모듈 혹은 유닛이라 불리는 컴포넌트들이 다른 나뭇잎들과 서로 결합 및 분리가 자유롭게 일어날 수 있다는것이 핵심!
• 이는 많은 장점들을 가져오지만 특히 테스트 유연성에도 영향을 끼칩니다.
• 실제로 테스트에 어떤 극대화된 장점을 가져올까? 생각해보면, 아무래도 atomic한 유닛 단위이니까 테스트 구성 시 쉽게 이 유닛들을 원하는만큼 조합하고 테스트할 수 있다는것을 의미하지 않을까 생각이 드는데 더 이후 테스트 챕터에서 알아보시죠 😃

---

TCA의 대표적인 장점

• State, 즉 상태 자체가 값 타입이기에 안정적입니다.
• Action, Effect의 일관성 (정형화된 구조를 통해 개발자마다 동일한 형태를 구현하게됨)
• 객체 즉, 모듈 간의 결합과 분리가 아주 유연함
• 테스트 짱 👍

---

마무리

• 확실히 외부 프레임워크인만큼 불안함은 있지만, 이 프레임워크를 꼭 써야한다기보다는 상태 관리를 어떻게 효율적으로 구성하고 구조를 제공하는지에 대해 앞으로 하나씩 이해해보는것이 가장 키 포인트일거라고 생각이 들었습니다.
• SwiftUI로 MVVM을 사용하는것이 어울리지 않고 사용하면 안된다는것이 전혀 아니라, TCA를 통해 상태 기반 단방향 구조에 대해 Point-free에서 어떻게 생각하고 만들어내는지를 파악해봐야 할것 같다고 느껴졌습니다.
• 가장 좋은건 사실 이것들을 이해하고 직접 순수하게 만들어내는것이겠지만....?
• 보다 안정적인 UI 상태 변경과 객체의 유연한 소통에 초점을 잘 맞춰서 앞으로의 챕터들을 학습해보는것을 목표로 삼아보려 합니다!

---

레퍼런스

Chapter 1. Hello, TCA | Notion