TCA QnA

Q. TCA(The Composable Architecture)란 무엇인가요?

TCA는 Swift와 Apple 플랫폼을 대상으로 설계된 오픈소스 아키텍처 라이브러리입니다.

단방향 데이터 흐름과 선언형 프로그래밍 패러다임을 기반으로 하며,

애플리케이션의 상태, 로직, 사이드 이펙트를

명확하게 분리하고 예측 가능하게 관리할 수 있도록 설계되었습니다.

내부적으로는 Combine을 기반으로 구현되어 있으며,

SwiftUI의 선언형 UI 패러다임과 잘 어울리는 구조를 가지고 있습니다.

---

Q. TCA를 사용하는 이유는 무엇인가요?

TCA를 사용하는 가장 큰 이유는 복잡한 상태와 비즈니스 로직을 예측 가능하게 관리하기 위함입니다.

단방향 데이터 흐름을 강제함으로써

• 상태 변경의 흐름이 명확해지고
• 사이드 이펙트가 한 곳에서 통제되며 (모든 결과가 Action으로 환원)
• 테스트가 쉬워지고
• 대규모 프로젝트에서도 구조적 일관성을 유지할 수 있습니다.

특히 여러 화면 간 상태 공유가 많거나 비동기 로직이 복잡한 경우에 강점을 가집니다.

---

Q. TCA는 어떤 철학을 기반으로 만들어졌나요?

TCA는 Facebook의 Flux 아키텍처 개념을 기반으로 하여,

이를 SwiftUI와 Apple 생태계에 맞게 발전시킨 구조입니다.

핵심 철학은 다음과 같습니다.

• 단방향 데이터 흐름
• 상태 기반 UI
• 모든 변경은 Action을 통해서만 발생
• 사이드 이펙트의 명시적 분리

---

Q. TCA의 핵심 구성 요소는 무엇인가요?

TCA는 크게 다음 요소들로 구성됩니다.

• State
  • 애플리케이션의 상태를 나타냅니다.
  • UI를 그리기 위한 데이터와
  • 비즈니스 로직에 필요한 상태를 포함합니다.
• Action
  • 사용자 입력, 시스템 이벤트, 네트워크 응답 등
  • 애플리케이션에서 발생하는 모든 이벤트를 표현합니다.
• Reducer
  • Action을 받아
    • State를 변경하거나
    • Effect를 반환하는 순수 함수입니다.
• Store
  • State, Action, Reducer를 실제로 관리하는 객체로,
  • 애플리케이션 로직의 중심 역할을 합니다.
• Dependency(Environment)
  • 네트워크, DB, 시스템 API 등
  • 외부 의존성을 모아둔 영역입니다.

---

Q. TCA의 단방향 데이터 흐름을 설명해 주세요

TCA의 데이터 흐름은 항상 한 방향으로만 진행됩니다.

1. View → 사용자 입력으로 Action을 발생
2. Store → Action을 Reducer에 전달
3. Reducer → Action에 따라
   • State를 변경하거나
   • Effect(비동기 작업)를 반환
4. State 변경 → Store를 통해 View로 전달되어 UI 갱신
5. Effect 처리 → 비동기 작업 결과를 다시 Action으로 변환해 Reducer로 전달

이 구조를 통해 모든 상태 변경의 원인을 추적할 수 있습니다.

---

Q. TCA에서 Side Effect는 어떻게 다루나요?

TCA에서는 네트워크 요청, 타이머, 파일 IO 같은 비동기 작업을 Effect로 명확히 분리합니다.

Effect의 실행 결과는

• 성공 / 실패 여부와 상관없이
• 다시 Action으로 변환되어 Reducer로 전달됩니다.

이로 인해

• 사이드 이펙트가 예측 가능해지고
• 테스트에서 Effect를 쉽게 제어할 수 있으며
• 에러 처리 흐름도 일관되게 유지할 수 있습니다.

---

Q. Reducer는 왜 순수 함수여야 하나요?

Reducer를 순수 함수로 유지함으로써

• 같은 State와 Action이 주어지면
• 항상 같은 결과를 반환하게 되고

이로 인해

• 테스트가 쉬워지고
• 상태 변경 흐름을 예측할 수 있으며
• 디버깅이 용이해집니다.

즉, Reducer는 **“상태 변경 규칙을 정의하는 곳”**이지 외부 환경에 의존하는 곳이 아닙니다.

---

Q. TCA에서 Composable하다는 것은 어떤 의미인가요?

Composable하다는 것은 작은 단위의 기능을 독립적으로 구성하고,

이를 조합하여 더 큰 기능을 만들어갈 수 있다는 의미입니다.

• Feature 단위로 State / Action / Reducer를 분리하고
• 상위 Reducer에서 이를 조합해
• 애플리케이션 전체를 구성합니다.

이로 인해

• 기능 간 영향 범위가 줄어들고
• 재사용성이 높아지며
• 대규모 프로젝트에서도 구조를 유지하기 쉬워집니다.

---

Q. TCA는 Clean Architecture와 어떤 관계가 있나요?

TCA는 Clean Architecture를 대체하는 개념이라기보다,

Presentation 레이어의 상태 관리 아키텍처에 가깝습니다.

실제로는 다음과 같이 함께 사용했습니다.

• TCA → 화면 상태 관리, 이벤트 처리, 단방향 흐름
• Clean Architecture → 비즈니스 로직, UseCase, Repository 분리

즉, TCA + Clean Architecture는 서로 보완 관계라고 생각합니다.

---

Q. TCA를 사용하면서 어려웠던 점은 무엇인가요?

초기에는

• State / Action / Reducer 분리로 인한 코드 양 증가
• 개념 이해에 시간이 필요했습니다.

하지만 구조에 익숙해진 이후에는

• 상태 변경 흐름이 명확해지고
• 테스트 작성이 쉬워졌으며
• 기능 확장 시 안정감이 커졌습니다.

---

Q. TCA를 언제 사용하는 것이 적절하다고 생각하나요?

• 화면 간 상태 공유가 많은 경우
• 비동기 로직과 사이드 이펙트가 복잡한 경우
• 중·대규모 프로젝트
• 테스트가 중요한 프로젝트

반대로 단순한 화면 위주의 소규모 프로젝트에서는 과도한 구조가 될 수 있다고 생각합니다.

---

Q. TCA에서 가장 중요하다고 생각하는 부분은 무엇인가요?

단방향 데이터 흐름과 상태 중심 사고(State-driven design)가 가장 중요하다고 생각합니다.

모든 상태 변경이 Action → Reducer → State 흐름 안에서만 일어나도록 제한함으로써,

예측 가능하고 테스트 가능한 구조를 만드는 것이 TCA의 핵심이라고 생각합니다.

---

Q. MVVM + Clean Architecture와 TCA는 어떤 차이가 있나요?

MVVM + Clean Architecture는 책임 분리와 의존성 관리에 초점을 둔 아키텍처이고,

TCA는 상태 관리와 단방향 데이터 흐름에 초점을 둔 아키텍처입니다.

• MVVM + Clean Architecture → “어디에 어떤 로직을 둘 것인가?”
• TCA → “상태가 어떻게 흘러가고, 언제 바뀌는가?”

라는 관점의 차이가 있다고 생각합니다.

---

Q. 두 아키텍처는 서로 대체 관계인가요?

아니요. 서로 대체 관계라기보다는 관점이 다른 아키텍처라고 생각합니다.

• Clean Architecture → 시스템 전체 구조, 계층 분리, 의존성 방향
• TCA → Presentation 레이어의 상태 관리 방식

그래서 실제로는 TCA + Clean Architecture를 함께 사용하는 것도 충분히 가능하다고 생각합니다.

---

Q. MVVM + Clean Architecture를 사용할 때의 장점은 무엇인가요?

• 역할과 책임이 명확하게 분리됨
• 비즈니스 로직이 UI로부터 보호됨
• UseCase 단위로 테스트가 쉬움
• 팀원들이 구조를 이해하기 쉬움

특히 서버/도메인 로직이 복잡한 서비스에서 강점을 가진다고 생각합니다.

---

Q. 그럼 MVVM + Clean Architecture의 한계는 무엇인가요?

• 화면 상태 관리 방식이 팀마다 달라질 수 있음
• 비동기 로직과 사이드 이펙트가 분산되기 쉬움
• 상태 변경 흐름을 추적하기 어려워질 수 있음

특히 화면 간 상태 공유가 많아질수록 상태 변경의 출처를 추적하기가 어려워지는 문제를 느꼈습니다.

---

Q. 이런 문제를 TCA는 어떻게 해결하나요?

TCA는 모든 상태 변경을 Action → Reducer → State 흐름으로 강제합니다.

이로 인해

• 상태 변경의 원인이 명확해지고
• 사이드 이펙트가 Effect로 분리되며
• 비동기 로직이 일관된 방식으로 관리됩니다.

즉, “상태가 언제, 왜 바뀌었는지”를 추적하기 쉬운 구조를 제공합니다.

---

Q. 상태 관리 관점에서 두 구조의 차이를 설명해 주세요

• MVVM → ViewModel 내부에서 상태를 직접 변경
• TCA → Reducer를 통해서만 상태 변경 가능

TCA는 상태 변경 경로를 하나로 제한함으로써 예측 가능성을 높였다고 생각합니다.

---

Q. 테스트 관점에서 두 아키텍처의 차이는 무엇인가요?

• MVVM + Clean Architecture
• UseCase 테스트는 쉽지만 ViewModel의 상태 변경 테스트는 구현 방식에 따라 달라짐
• TCA
• Action을 보내고 그에 따른 State 변화를 순서대로 검증 가능

특히 TCA는 비동기 로직과 사이드 이펙트 테스트가 구조적으로 용이하다고 생각합니다.

---

Q. 그럼 TCA는 언제 사용하는 것이 적절하다고 생각하나요?

• 화면 간 상태 공유가 많은 경우
• 상태 변화가 복잡한 경우
• 비동기 로직과 사이드 이펙트가 많은 경우
• 중·대규모 프로젝트

이런 경우에는 TCA의 구조적 강점이 잘 드러난다고 생각합니다.

---

Q. 반대로 TCA를 사용하지 않는 게 더 나은 경우도 있나요?

네, 있습니다.

• 화면 수가 적고
• 상태 흐름이 단순하며
• 팀원이 TCA에 익숙하지 않은 경우

이런 상황에서는 MVVM + Clean Architecture가 구현과 학습 측면에서 더 효율적일 수 있다고 생각합니다.

---

Q. 실제 프로젝트에서는 어떤 기준으로 아키텍처를 선택하셨나요?

• 프로젝트 규모
• 상태 복잡도
• 팀의 경험치
• 테스트 요구 수준

을 기준으로 판단했습니다.

단순한 구조에서는과도한 아키텍처를 지양하고,

복잡도가 증가할 경우 점진적으로 구조를 강화하는 방향을 선호했습니다.

---

Q. TCA를 사용하면서 MVVM + Clean Architecture 대비 가장 크게 느낀 차이는 무엇인가요?

가장 크게 느낀 차이는 상태 변경의 예측 가능성이었습니다.

MVVM에서는 상태 변경 위치가 분산될 수 있지만,

TCA에서는 Reducer 하나로 상태 변경이 모이기 때문에 디버깅과 테스트가 훨씬 수월했습니다.

---

Q. 한 문장으로 두 아키텍처의 차이를 정리한다면?

MVVM + Clean Architecture는‘구조와 책임 분리’에 강점이 있고,

TCA는‘상태 흐름과 예측 가능성’에 강점이 있는 아키텍처라고 생각합니다.