TDD와 Clean Architecture로 재구축한 fromm 라이브 서비스

fromm 라이브 서비스 소개

안녕하세요! fromm 앱의 iOS 개발을 담당하고 있는 정국희입니다. fromm 라이브 서비스는 아티스트가 원하는 시간에 라이브 방송을 시작하면, 팬들이 실시간으로 방송에 참여해 소통할 수 있는 기능입니다. 이 과정에서 채팅 기능을 통해 양방향 커뮤니케이션이 가능하도록 지원합니다.

배경

기존 모듈은 사용자 입장에서 기능적으로 문제없이 잘 작동하고 있었고, 안전성과 성능 면에서도 뚜렷한 이슈는 없었습니다. 하지만 내부적으로는 구조가 복잡하고 유지보수가 어려운 점이 있었습니다. 특히 기능 추가나 수정 시 코드 파악과 변경 범위 예측이 쉽지 않았고, 테스트 작성 또한 어려운 구조였습니다. 이러한 이유로, fromm 라이브 서비스 모듈의 전면적인 구조 개편을 결정하게 되었습니다.

유지보수 개선이 필요했던 배경

기존 구현은 TCA 프레임워크를 기반으로 구성되어 있었으며, 다음과 같은 문제점들이 있었습니다.

1. 이슈 발생 시 원인 파악이 어렵다

• 프레임워크 내부 추상화 계층이 깊고 복잡하여, 런타임에서 발생한 문제의 원인을 빠르게 추적하기 어려웠습니다.

2. 상태 변경 시 전체 뷰 업데이트 가능성

• TCA의 Store는 전체 상태를 관찰하는 구조로 되어 있어, 하나의 상태 변경이 불필요하게 전체 View 업데이트를 유발할 수 있었습니다. 이는 SwiftUI의 바디 재계산 방식과 결합되면서 성능 저하로 이어질 여지가 있다고 판단했습니다.

3. Reducer를 세분화할수록 로직 흐름이 분산됨

• 기능 단위로 Reducer를 잘게 나누다 보면, 하나의 사용자 액션이 여러 Layer를 통해 분산 처리되어 로직의 흐름을 따라가기 어렵습니다.

4. Straight-line 흐름의 부재로 인한 가독성 저하

• Reducer 내부에서 분기와 이벤트 전파가 잦아 코드가 직관적으로 읽히지 않으며, 순차적인 실행 흐름을 파악하는 데 어려움이 있었습니다.

5. 기본 Swift 기능의 추상화에 따른 학습 및 유지보수 비용 증가

• TCA는 Swift의 상태 관리, 비동기 처리, 의존성 주입 기능을 고도로 추상화하여 제공하지만, 그 구조를 이해하고 활용하는 데 추가적인 학습이 필요했습니다. 또한 디버깅 시 TCA 내부 동작까지 추적해야 하는 경우가 잦았습니다.

6. 직접 바인딩 방식보다 효율이 떨어질 수 있음

• View에 직접 상태를 바인딩하는 방식보다 중간 계층(Reducer 등)을 거치면서 UI 업데이트 성능에 영향을 줄 수 있다고 판단했습니다.

---

기능 자체는 안정적으로 동작했지만, 구조적 복잡성과 낮은 응집도로 인해 유지보수가 어렵다는 결론에 이르렀습니다. 1년간 TCA를 실험적으로 도입해 사용해 본 결과, 위와 같은 구조적 한계가 명확해졌고, 이에 따라 현재는 TCA 도입을 중단한 상태입니다.

재구축의 필요성

TCA는 상위 Reducer가 다수의 하위 Reducer를 손쉽게 조합하여 구성할 수 있도록 설계되어 있어, 일관된 아키텍처 구조 아래 기능을 모듈화할 수 있다는 장점이 있습니다. 그러나 이러한 구조가 실질적인 재사용성과 유지보수성으로 이어지기 위해서는, 각 하위 모듈이 명확하게 분리되고 높은 응집도와 낮은 결합도를 갖춘 상태여야 합니다.

기존 구현에서는 하나의 화면에 대해 최상위 Reducer가 존재하고, 하위 뷰나 유사한 Usecase 단위로 하위 Reducer가 구성되어 있었습니다. 하지만 유사한 Usecase를 서로 다른 화면 간에 재사용하려다 보니 조건 분기가 잦아졌고, 점점 코드의 복잡도가 증가했습니다. 이벤트의 흐름 또한 상위 → 하위 → 상위로 오가며 처리되는 구조여서, 특정 액션의 전후 맥락을 파악하기 위해 여러 계층을 탐색해야 하는 상황이 빈번하게 발생했습니다.

결국 단일 이벤트 흐름을 따라가기가 어려워졌고, 코드를 수정하거나 테스트할 때 전체 구조에 대한 이해가 선행되어야 하는 부담이 커졌습니다. 이러한 점이 구조적인 피로도를 유발했으며, fromm 라이브 서비스의 장기적인 확장성과 유지보수성을 고려했을 때 새로운 아키텍처로의 전환이 필요하다고 판단했습니다.

리팩터링의 핵심 도구

이번 리팩터링의 핵심 목표는 회귀 버그 없이 구조를 개선하는 것이었으며, 이를 위해 두 가지 핵심 도구를 전략적으로 활용했습니다: 테스트 주도 개발(TDD)과 Clean Architecture입니다.

TDD

TDD는 단위 테스트를 먼저 작성하고 그에 맞춰 코드를 구현하는 방식으로, 안정성과 유지보수성을 높이는 데 기여했습니다. 모든 Usecase 로직은 LiveUsecases 타겟에 작성되었고, 테스트 코드와 함께 관리되었습니다. 테스트는 주로 상태 검증 방식으로 구성하되, 상태가 명확히 드러나지 않는 경우에는 행위 기반 테스트로 보완했습니다. 이 접근 방식은 설계 개선뿐 아니라 회귀 테스트 자동화 효과도 함께 얻을 수 있었습니다.

Clean Architecture

Clean Architecture는 모듈 구조를 수평 계층으로 나누고 각 계층 간의 컴파일 타임 의존성을 바깥에서 안으로만 향하도록 제한함으로써, 변경에 유연한 구조를 구현하는 데 초점을 맞췄습니다. 각 계층은 Swift Package의 타겟으로 구성되었습니다.

반대로 실행타임 의존이 필요한 경우(예: Usecase가 Adapter를 호출해야 할 때)는 DI(의존성 주입)를 활용했습니다. DI는 Pure DI 방식을 채택하고 외부 라이브러리 없이 직접 구현하였으며, Clean Architecture의 Main Layer를  별도의 타겟으로 두어 객체 생성 및 의존성 주입을 담당하게 했습니다.

또한, Clean Swift 패턴을  채택했으며, 그대로 적용하지 않고 Clean Architecture 구조에 맞도록 변형하여 도입했습니다. 그 결과, View → Interactor → Presenter → View 로 이어지는 흐름이 명확해졌고, 이를 기반으로 기존 템플릿을 보완해 사용하여 보일러 플레이트 코드 작성을 줄이고 일관된 구조를 유지할 수 있었습니다.

Clean Swift 구조도

수직적 분리

리팩터링 전략

1. 응집도 향상

• 하나의 이벤트가 발생했을 때, 해당 이벤트의 흐름을 한 곳에서 파악할 수 있도록 Interactor 중심으로 코드를 재구성했습니다. 이로 인해 코드의 흐름이 명확해지고 디버깅이나 변경 시 추적이 쉬워졌습니다.

2. 기존 모듈의 대부분을 그대로 사용

• UI 구조와 관련된 요소(뷰 계층 구조, 화면 수), Entity 모델, 프레임워크 및 Driver, Backend API 모델 등은 그대로 유지하되, TCA에 의존하던 코드는 제거하고 재작성했습니다.

3. SwiftUI의 기본 상태 관리 방식 사용

• @State, @ObservedObject, @Binding 등의 SwiftUI 본연의 상태 관리 도구를 활용해 뷰와 상태를 직접 바인딩함으로써, 중간 계층을 제거하고 UI 반응성을 개선했습니다.

4. Reducer와 Client의 코드를 재구성

• 기존 TCA 구조에서 Reducer와 Client에 작성되어 있던 코드를 새로운 구조에 맞춰 Usecase, Adapter, Driver Layer로 역할에 따라 분리 재배치했습니다. 이 과정에서 일부 로직은 통합되고, 일부는 분리되면서 각 타입의 책임이 보다 단일해졌습니다.

5. Clean Architecture 수평 계층 분리 적용

• 수직적인 분리를 위해 라이브 모듈을 하나의 패키지로 만들었습니다.
• 그리고 수직적인 계층은 타겟으로 분리해 물리적으로 구조화했습니다. 각 계층 간 컴파일 타임 의존성은 오직 바깥에서 안쪽으로만 향하도록 Package.swift를 구성했습니다. 수평적 분리

6. @Shared 상태 제거 및 명시적 의존성 주입

• @Shared, @SharedReader처럼 간접적으로 상태를 공유하던 방식을 지양하고, 모든 의존성을 명시적으로 주입받는 방식으로 변경하여 변경 추적성과 테스트 용이성을 확보했습니다.

7. Entity 중심의 도메인 로직 재구성

• 기존 Entity 타입에는 로직이 거의 존재하지 않았습니다. 대부분 변수만 정의되어 있었고, 해당 변수를 사용하는 로직은 클라이언트 객체 내부에 분산되어 있어 중복이 발생하고 응집도가 낮았습니다.
• 이러한 분산된 로직을 Entity 내부로 이동시켜, 도메인 중심 설계 원칙에 맞게 역할을 재배치했습니다. 외부에서는 인터페이스에만 의존하도록 하여 변경에 유연하게 대응할 수 있게 되었고, 불필요한 속성은 private으로 전환해 캡슐화 수준도 높였습니다.

8. TDD 기반 Usecase 설계 및 구현

• 모든 Usecase는 테스트 코드를 먼저 작성하고 그에 맞춰 구현하는 TDD 방식으로 설계되었습니다.
• 이 과정을 통해 각 Usecase의 경계와 책임이 명확하게 드러났고, 테스트 가능성과 재사용성이 가능한 구조를 갖출 수 있었습니다.

9. 리팩터링 원칙 준수

• 리팩터링 과정에서 기능의 외형적 동작이나 결과는 변경하지 않도록 한다는 원칙을 지키고, 비정상적인 로직이라 하더라도 기존 로직을 그대로 반영한 후 테스트와 리뷰를 통해 향후 개선할 수 있도록 했습니다.

구체적인 실행 방안

이번 리팩터링 프로젝트는 3명의 iOS 개발자가 병렬적으로 진행하였습니다. 구조 개선, 테스트 커버리지 확보, 아키텍처 재설계를 동시에 달성하기 위해 실질적인 실행 전략을 수립하고 수행했습니다.

iOS 개발자를 위한 TDD 세션

저는 2020년도 부터 지금까지 TDD를 사용해서 개발을 해왔습니다. 함께하는 팀원들이 TDD를 실무에서 적용해 본 경험이 없었기 때문에, 프로젝트 초기 단계에서 4시간에 걸친 라이브 코딩 세션을 진행했습니다. 이론 설명과 함께 간단한 기능을 TDD로 구현해보는 실습을 병행했으며, 이를 통해 전체가 동일한 테스트 및 개발 방법을 익힐 수 있게 되었습니다.

오프라인 코드 리뷰 방식

각 개발자는 자신이 맡은 영역의 기능을 TDD 기반으로 구현한 후, 오프라인에서 저와 함께 리뷰하는 방식으로 빠른 피드백 사이클을 확보했습니다. 처음에는 페어 프로그래밍도 시도했으나, 작업자가 먼저 고민하고 개발 후에 리뷰를 통해 개선하는 흐름이 더 효과적이었습니다.

인수 테스트는 후순위로 진행

인수테스트는 일정상 우선순위에서 밀렸습니다. 1차로 모든 구현이 완료된 후 수행했습니다.

구현 순서: 바깥에서 안으로, 다시 안에서 바깥으로

화면 하나를 구현하는 것을 작업 단위로 정했습니다. 하나의 화면에 대한 전체 로직을 구현하는데는 다음과 같은 순서를 따랐습니다. Usecase layer에 있는 UI 이벤트가 발생하는 것을 처리하는 부분이 구현의 시작점입니다.

1. Interactor 구현: Interactor 타입을 TDD로 구현하며, UI 이벤트를 수신하는 메서드를 정의하고 테스트 코드를 작성하면서 필요한 Usecase 의 인터페이스 및 Adapter의 인터페이스를 도출했습니다. Interactor와 협력하는 새로운 다수의 타입이 도출됩니다. 
2. Usecase 구현: 1단계에서 도출된 Usecase 타입을 동일하게 TDD로 구현하며, 이 과정에서 역시 협력할 Usecase 의 인터페이스 및 Adapter의 인터페이스를 도출했습니다.
3. Adapter 구현: 2단계에서 도출된 인터페이스에 맞추어 Adapter 타입을 구현하고, 이 과정에서 Driver 의 인터페이스를 도출했습니다.
4. Driver 구현: 마지막으로 3단계에서 도출된 인터페이스에 맞추어 외부 라이브러리나 프레임워크를 사용하는  Driver 구현체를 완성합니다. 

어떤 타입을 Driver Layer에 놓일지 정하는 기준은 해당 타입이 외부 라이브러리나 프레임워크를 의존하는지 여부입니다.

Driver Layer는 외부 라이브러리나 프레임워크를 import 하는 유일한 Layer입니다. 

여기에는 표준 라이브러리 처럼 어떤 Layer에서도 필요한 것은 예외입니다.

다시 말하면 Adapter 타입을 구현하기 위해 라이브러리나 프레임워크를 사용해야 한다면 직접 import 하여 사용하는 대신 프로토콜을 정의합니다. 

이 4단계를 화면 단위로 반복했습니다.

구현 순서가 바깥에서 안으로 시작해서 다시 안에서 바깥으로 끝난다는 의미를 정리해보겠습니다.

먼저 바깥에서 안의 순으로 구현한다는 말은, 가장 바깥에 있는 Driver Layer에 놓인 뷰에서 발생한 이벤트를 안쪽의 Usecase layer에 놓인 Interactor가 처리하기 위해 Usecase 와 Adapter 프로토콜을 정의하는 것을 의미합니다.

그리고, 다시 안에서 바깥의 순으로 구현한다는 말은, Adapter 타입을 먼저 구현하고 Driver 타입을 구현하는 것을 말합니다.이러한 순서는 실질적인 요구사항 흐름을 따르는 동시에, SOLID 원칙 중 하나인 DIP(Dependency Inversion Principle)를 자연스럽게 따르게 해주었습니다. 결과적으로 도출된 타입은 모두 실제 요구로부터 출발해 불필요한 코드 작성을 막을 수 있었고, 계층 간 의존 방향도 단방향으로 구현되었습니다.

테스트 커버리지

테스트 작성 도구로는 Quick, Nimble, Cuckoo를 사용했습니다.

Usecase Layer의 테스트를 집중적으로 작성했습니다. 해당 Layer는 단위 테스트가 적용된 핵심 도메인 로직이기 때문에 안정성을 확보하는 데 중요한 위치를 차지합니다.

모든 Usecase는 개별 테스트 타겟인 LiveUsecases에서 관리되었고, 해당 타겟만을 테스트 실행 대상으로 지정하여 정확한 커버리지를 측정했습니다. 테스트 결과, 이 Layer의 커버리지는 약 99%를 기록했습니다.

수동 인수 테스트

전체 기능 구현이 완료된 이후, 수동 인수 테스트를 집중적으로 수행했습니다. 이 과정에서 약 80여 개의 버그가 발견되었으며, 그 대부분은 테스트 코드가 존재하지 않던 Adapter 또는 Driver Layer와 같은 주변부에서 발생했습니다.

발견 즉시 수정과 보완 작업을 병행하여 안정성을 점진적으로 끌어올릴 수 있었습니다.

또한, 수동 테스트 과정은 테스트 코드가 없는 영역을 식별하고 향후 테스트 보강이 필요한 지점을 파악하는 데도 유용하게 활용되었습니다.

수동 단위 테스트

자동화된 테스트의 신뢰도를 검증하고, 테스트 코드 자체에 오류가 없는지를 확인하기 위해 수동으로 Usecase에 대한 TC를 모두 테스트했습니다.

총 480여개의 테스트 케이스가 있고 테스트 커버리지는 98.6 % 입니다.

테스트 커버리지

순차적으로 테스트를 실행하면서 실제 동작이 기대한 결과와 일치하는지 하나하나 확인했습니다. 이 과정에서는 자신이 작성하지 않은 테스트 케이스를 검증하는 교차 테스트 방식을 채택하여, 선입견 없이 테스트 코드 및 구현 코드를 점검할 수 있었습니다. 그 결과, 약 15건의 크고 작은 버그를 발견하고 수정할 수 있었습니다. 테스트 코드 자체를 테스트하는 마지막 검증 단계였으며, 자동화된 테스트에 대한 신뢰도를 높이는 데 기여했습니다.

성과

이번 리팩터링을 통해 다음과 같은 주요 성과를 달성할 수 있었습니다.

유지보수성 강화

• 이벤트 발생부터 UI 반영까지의 흐름을 Interactor 중심으로 집중시켜, 코드 구조를 한눈에 파악할 수 있도록 개선했습니다.
• Clean Architecture 기반 수평 Layer 분리를 적용하여 불필요한 결합도를 제거했습니다.
• Pure DI를 100% 적용하여 코드의 의존성을 모두 드러내어 숨겨진 의존성으로 인한 가독성 저하 및 버그 유발 가능성을 줄일 수 있었습니다.
• 외부 라이브러리와 프레임워크의 변경으로 인한 영향 범위를 Driver Layer로 제한했습니다.

회귀 버그 최소화

• 거의 대부분의 Usecase에 대해 테스트 코드를 작성하여, 리팩터링 과정에서 의도치 않게 로직이 달라지는 상황을 최대한 방지했습니다.
• 특정 Usecase 타입을 리팩터링할 때 테스트 코드 덕분에 안전하고 빠르게 리팩터링 할 수 있었습니다.
• 단위 테스트 코드는 수동 단위 테스트에도 활용되어 별도의 TC 문서를 작성하는 수고를 덜어주었습니다.
• 이 후 요구사항이 변경될 때 회기 버그를 최소화하는데 도움이 될 것으로 기대합니다.

감사의 말

이번 프로젝트에서 Clean Architecture, TDD,단위 테스트, Clean Swift, Pure DI 등 처음 도입하는 기술들을 빠르게 학습하고 함께 구현해준 iOS 팀원들에게 깊은 감사를 전합니다. 새로운 방식에 열린 마음으로 임해준 덕분에 구조적인 리팩터링을 완료할 수 있었습니다. 그리고, 프로젝트를 믿고 맡겨주신 팀장님께도 감사드립니다.

또한, 본 리팩터링에서 사용된 Clean Swift 는 오리지널을 기반으로 개선하여 원티드랩에서 2020년부터 사용되고 있는 패턴입니다. 그리고, 이번 프로젝트에 맞게 Clean Architecture 관점에서 변형하고 강화하였습니다. 이 패턴의 사용을 흔쾌히 허락해주신 원티드랩 iOS 팀에도 이 자리를 빌려 감사의 마음을 전합니다.

다음 이야기

이번 글에서는 구조 개선과 테스트 기반 리팩터링을 중심으로 전체적인 흐름과 접근 방식을 공유했습니다.

다음 글에서는 실제 코드와 구체적인 예시를 함께 소개하여, 더욱 직관적으로 리팩터링 방식과 패턴을 이해할 수 있도록 도와드리고자 합니다.

또한, 리팩터링 과정에서 마주했던 현실적인 어려움과 시행착오, 그리고 그로부터 얻은 인사이트와 개선 방향도 함께 나누려 합니다. 기술적인 고민뿐만 아니라 협업 방식, 일정 제약, 우선순위 결정 등 실무적인 맥락까지 함께 짚어볼 예정입니다.

함께할 동료를 찾고 있어요

fromm iOS 팀은 함께 성장하며 서비스를 만들어갈 iOS 네이티브 개발자를 찾고 있습니다.
사용자 경험을 고민하고, 더 나은 코드를 함께 만들어가는 과정에 관심 있는 분들의 많은 지원을 기다립니다.

👉 관련 포지션 및 지원 방법은 채용 페이지 링크를 확인해주세요.