안녕하세요. Swift로 Apple 생태계 개발에 일조해 주시는 개발자 여러분, 모두 반갑습니다!

지금의 애플 생태계 개발자들은 iOS, MacOS, Watch OS 등등의 운영체제에서 작동할 대부분의 코드를 Swift로 작성합니다. 저희는 Swift로 작성된 코드를 기반으로 수많은 기능을 구현하고, UI도 그릴 수 있습니다. 이렇게 작성된 코드들에 대한 관리방법도 물론 프로젝트를 진행하면서 중요한 고려사항이 됩니다. 3일 뒤, 3주 뒤, 3달 뒤에 코드를 돌아볼 때 어느 파일에 어떤 코드가 있을지 보장하는 약속이 필요하기 때문이죠.

코드를 정리하고 구현하는 데에는 일정한 규칙이 있습니다. 코드가 특정 문제를 해결할 때, 정형화된 하나의 규칙을 제안하는 것을 ‘디자인 패턴(Design Pattern)’이라 일컫고, 정리된 코드들을 더 추상화된 비즈니스적 문제 해결 관점으로 정리하는 규칙을 ‘아키텍처 패턴(Architecture Pattern)’이라 합니다. 이 두 가지는 분명하게 다르기 때문에 구분할 필요가 있으며 『SwiftUI 상태 관리부터 테스트까지 iOS 개발자를 위한 TCA 1.0』 에서는 상태관리 및 의존성 라이브러리인 The Composable Architecture을 활용한 아키텍쳐 패턴에 대해 설명합니다.

• 참고: Architecture Pattern vs Design Pattern

Swift 생태계, 특히 SwiftUI로 선언형 UI를 구현하는 환경에서는 MVVM 패턴이 곧잘 채택되고는 했습니다. 그 외, 특수한 비즈니스 로직과 기업의 개발 환경 및 기능의 설계에 따라 RIBs, VIPER, MVP, Clean 등의 아키텍처 패턴이 보편적으로 사용됩니다. 대부분의 아키텍처는 기업과 개인이 프로그래밍 환경에서 자주 발생하는 비즈니스 로직의 설계를 효율적으로 하기 위해 창안되었습니다. 대표적으로 Robert C. Martin(Uncle Bob)의 **『Clean Architecture』**가 있습니다. 본 서적에서 소개하는 아키텍처 또한 Point-Free의 메인테이너 mbrandonw와 stephencelis에 의해 탄생한 아키텍처 패턴입니다.

가장 최근까지도 SwiftUI를 활용한 프로젝트의 아키텍쳐는 여러 형태로 분화되어 왔습니다. 2019년도에 진행되었던 WWDC에서 SwiftUI를 소개한 이후, 이 선언형 UI 프레임워크에 적합한 여러 아키텍쳐가 프로젝트를 진행할 때에 선택지로 거론되었습니다. MVC에서 View의 로직을 처리하는 책임을 갖는 객체, 즉 Controller는 SwiftUI에 이르러 ViewModel의 형태로 변화하게 되었고, 우리에게 익숙한 MVVM 아키텍쳐가 등장했습니다. 그러나 SwiftUI의 발전과 함께 MVVM 아키텍쳐를 적용해야 한다는 주장이 갖는 설득력이 점차 줄었습니다. 그 근거는 다음과 같습니다.

우선 ViewModel 객체의 존재 이유였던 State-Binding이 SwiftUI의 선언형 UI에 이미 반영되어 있다는 점입니다. Reactive Programming을 구성하기 위해 곧잘 활용되었던 RxSwift 환경에서, 데이터를 바인딩하고 처리하는 로직을 책임진 것이 바로 ViewModel 객체였습니다. 그러나 비동기 처리를 위한 데이터 바인딩을 View 레벨에서 처리할 수 있는 선언형 UI인 SwiftUI가 등장하면서 RxSwift가 요구하는 ViewModel은 그 의미를 잃었습니다. 이에 관련된 더 자세한 설명은 아래 블로그를 참고하면 보실 수 있습니다.

• 참고: “SwiftUI에서 MVVM 사용을 멈추자”라고 생각이 들었던 이유

이러한 배경 속에서 TCA가 등장했습니다. TCA는 값 타입에 기반하여 각 객체를 모듈화하고 애플리케이션 전체의 상태를 일관적으로 관리할 수 있게 표준을 제안하고자 합니다. 최소 기능 단위로 구성된 각 Unit 객체는 다른 기능으로의 결합-분리를 쉽게 할 수 있습니다. 이로써 TCA를 활용한 프로젝트는 일관적인 방식으로 애플리케이션의 상태를 관리할 수 있게 되고, 테스트의 유연성을 확보할 수 있게 됩니다. 이렇게 들으면 우리의 프로젝트에 적용하지 않을 이유가 없을 것처럼 보입니다.

그러나 SwiftUI가 MVVM 과 어울리지 않는다는 주장이 ‘TCA를 적용하자’를 의미하지는 않습니다. 아직도 지속적으로 업데이트 되고 있는 프레임워크에 의존적이라는 점과 이 프레임워크에 대한 러닝 커브, 하나의 프레임워크에 내재된 또 다른 외부 프레임워크의 존재 등을 생각하면 오히려 쓰지 않을 이유가 더 많을 수도 있죠. 그럼에도 불구하고 TCA를 적용할 때 얻을 수 있는 장점은 분명히 많습니다. TCA는 MVVM 아키텍쳐가 갖는 장점의 대부분을 가져오면서, 조금 더 특별한 이점들을 갖습니다.

<aside> 💡 The Composable Architecture의 특별한 장점들

1. 값 타입에 기반한 안정적인 State의 변형
2. 유저 행동에 대한 로직을 처리하는 Action과 Effect의 일관성
3. 객체 간 결합과 분리의 유용성
4. 비교적 편리한 테스트 </aside>

본론에서 진행되는 각 챕터들은 위의 장점들을 강조하는 방식으로 서술되어 있습니다. 따라서 본 서적에 대해 요구되는 사전 습득 지식은 크게 네 가지입니다. 사전 습득 지식의 정도는 필요 수준일 때 큰 어려움 없이 서적을 이해할 수 있으며, 충분 수준일 때 원활히 서적을 이해할 수 있음을 의미합니다. 본 서적에서 각 항목에 대한 자세한 설명을 제공하지 않지만, 필요 수준에 대한 내용을 알지 못하더라도 충분히 따라올 수 있으니 큰 걱정하지 않으시기를 바랍니다.

1. Swift의 타입에 대한 이해
   1. 필요: 값 타입과 참조 타입을 비교할 수 있는 수준
   2. 충분: 타입 파라미터(제네릭)에 대해 간단히 설명할 수 있는 수준
2. SwiftUI에 대한 기본적인 이해
   1. 필요: View를 렌더링하기 위해 @State , @Published 등의 프로퍼티 래퍼 혹은 @Observable 매크로를 써야하는 이유를 간단히 설명할 수 있는 수준
3. inout 키워드에 대한 이해
   1. 필요: 파라미터로 전달된 값 타입을 변형할 수 있는 수준
   2. 충분: copy-in copy-out 구조에 대해 설명할 수 있는 수준
4. KeyPath 에 대한 이해
   1. 필요: KeyPath 에 대해 들어보고 예시 코드를 읽을 수 있는 수준
   2. 충분: KeyPath 를 활용하여 타입에 대한 key-value 접근을 구현할 수 있는 수준

본 서적은 SwiftUI에서 활용하는 값 타입의 효율적이고 안정적인 관리에 초점을 맞춰서 서술되어 있습니다. 이러한 서술 방향은 Point-Free가 상태를 관리하는 태도를 일관적으로 유지하고 전달하는 데에서 채택되었습니다. The Composable Architecture를 처음 접하시는 분들을 위한 간단한 설명도 준비되어 있으나, 어느 정도 아키텍처에 대해 접하신 경험이 있고 더 깊은 이해를 원하시는 분들을 위한 정보도 함께 작성했습니다. 1.0.0 버전을 기념하여 무료 e-book으로 출간되었으며, 본 서적의 모든 내용은 1.0.0 버전에 최적화되어 있음을 밝힙니다. 추가로 각 개념들이 수행하는 역할을 영문으로 표기함으로써 서술되는 내용의 혼동을 가능한 만큼 줄였습니다.