라이브 스트리밍 구조 개편, TDD 첫 도입기

들어가며

안녕하세요. 저는 fromm 앱에서 iOS 개발을 담당하고 있는 이하연입니다.

배경: 복잡해진 구조, 그리고 변화의 필요성

작년, fromm 앱에 SwiftUI와 TCA 아키텍처를 적용해 라이브 스트리밍 기능을 처음 도입했습니다.

TCA는 다양한 기능을 제공하고, 많은 팀들이 효과적으로 활용하고 있는 아키텍처지만, 저희 팀에게는 시간이 지날수록 로직 분산, 디버깅의 어려움, 복잡한 상태 관리 등 몇 가지 측면에서 점차 어려움이 누적되기 시작했습니다.

이로 인해, 팀 내부 논의 끝에 다음과 같은 큰 결정을 내렸습니다.

1. 라이브 모듈의 전면적인 구조 개편
    - 기존 TCA 아키텍처 제거
    - 팀의 요구에 맞춰 변형한 Clean Swift 패턴 도입
2. TDD 방식 도입

Clean Swift 패턴을 채택하되, Clean Architecture를 기반으로 개선하여 적용했습니다. 이를 기반으로 구조를 전환하면서 Interactor 중심으로 로직을 모으고, View → Interactor → Presenter 간 책임을 명확히 분리할 수 있었습니다. 그 결과, 테스트 작성과 유지보수도 한결 수월해졌습니다.

특히 구조 개편과 함께, TDD 방식도 도입해봤는데요. 기존처럼 구현 위주로 작업하던 방식에서 벗어나, 테스트를 먼저 작성하고 그에 맞춰 기능을 구현하는 흐름을 실제 프로젝트에 적용해본 건 이번이 처음이었습니다.

이번 글에서는 라이브 스트리밍 구조 개편 과정에서 TDD를 실제로 어떻게 적용했는지, 그리고 저희 팀이 어떤 기준으로 테스트를 작성했는지, 그 경험을 통해 무엇을 배우고 느꼈는지 이야기해보려 합니다.

👉 참고 - 구조 개편 과정은 이전 블로그 글에서 자세히 다루었습니다. ( 링크 )

TDD, 우리 팀에선 이렇게 시작했습니다

새로운 아키텍처 도입만으로도 팀에게는 큰 변화였는데, 여기에 TDD까지 더해지니 적응이 쉽지만은 않았습니다.

팀장님 외에는 테스트 코드 경험이 없었고, 세 명의 팀원이 각자 다른 스타일로 코드를 작성하다 보니 일관성을 유지하는 데도 쉽지 않았습니다. 예를 들어, 어떤 팀원은 it 블록을 잘게 나누는 방식을 선호하는 반면, 다른 팀원은 하나의 it 블록 안에 모든 검증을 담는 방식을 사용하기도 했습니다.

이런 상황 속에서 팀장님께서 테스트 작성 가이드를 명확히 정리해주셨고, 저희는 이를 바탕으로 다음과 같은 5단계 TDD 루틴을 실천했습니다.

5단계 TDD 루틴

1. 테스트 케이스 작성하기
2. 실패하는 테스트 만들기
3. 성공하는 테스트 만들기
4. 협력 객체(router, presenter 등) 구현
5. 리팩토링 및 테스트 유지

Interactor 테스트, 이렇게 작성했습니다

이번 구조 개편에서는 Clean Swift에서 핵심 역할을 담당하는 Interactor 중심으로 단위 테스트를 작성했습니다.

또, Quick + Nimble + Cuckoo 조합을 활용해 테스트 코드를 작성 하고, 상태 검증과 행위검증을 수행했습니다.

🙋🏻‍♂️ 잠깐, Interactor가 뭔가요?

Clean Swift에서 Interactor는 사용자 이벤트를 처리하고, 비즈니스 로직을 수행하며, 상태를 관리하는 핵심 역할을 맡고 있습니다.

예를 들어, 사용자가 버튼을 누르거나 메시지를 입력하면, View는 해당 이벤트를 Interactor에 전달하고, Interactor는 필요한 로직을 수행한 뒤 Presenter나 Router를 통해 화면 갱신을 요청합니다.

저희 팀은 구조 개편 과정에서 Interactor가 하나의 이벤트 흐름을 책임지고 처리할 수 있도록 구조를 정비했습니다. 그 결과, 이벤트 단위로 테스트 흐름을 정의하고, 협력 객체와의 상호작용을 검증하기에도 적합한 구조인 Interactor를 중심으로 테스트를 진행하게 되었습니다.

🔑 정리하면, Interactor는 Clean Swift 구조 안에서 비즈니스 로직의 중심점이자, TDD 테스트 흐름에서 가장 먼저 검증이 이뤄지는 지점

🙋🏻 잠깐, Quick, Nimble, Cuckoo가 뭔가요?

• Quick: iOS 테스트 프레임워크로, describe, context, it 등의 문법을 통해 Given-When-Then 패턴을 자연스럽게 적용할 수 있습니다. 테스트를 중복되는 내용 없이 구조화하기에 유용합니다. ( 링크 )
• Nimble: iOS 테스트 프레임워크로, 상태 검증 라이브러리입니다. 다양한 matcher를 통해 기대하는 상태를 더 표현력 있게 검증할 수 있습니다. ( 링크 )
• Cuckoo: Swift용 Mock 생성 도구입니다. 빌드 시점에 Mock 객체를 자동으로 생성해주기 때문에, 테스트 코드 내에서 별도로 작성할 필요가 없습니다. 생성된 Mock은 Stub으로 활용이 가능하여, 행위 기반 검증도 손쉽게 수행할 수 있습니다. ( 링크 )

더 자세한 내용은 공식 문서를 참고해주세요!

💁🏻‍♀️ 실제로 이렇게 적용했어요!

다음은 실제로 작성한 Interactor 테스트 코드 중 일부를 각색한 예시입니다. 이 예시를 통해 5단계 TDD 루틴을 어떻게 적용했는지 구체적으로 소개해보겠습니다

1. 테스트 코드 작성

먼저 describe, context, it 구조를 사용해 테스트 시나리오를 정의합니다. 이 구조를 활용하면 조건(Given) - 이벤트(When) - 기대 결과(Then) 흐름에 따라 테스트 목적을 명확하게 표현할 수 있습니다.

그리고, 저희 팀에서는 it 블록을 여러 개로 나누기보다는 하나의 it 블록 안에서 여러 검증을 수행하고, 각 검증은 주석으로 구분하는 방식을 사용하고 있습니다. 이 방식은 describe 및 context 블록에 작성된 코드가 중복 실행되는 경우를 줄여주어, 테스트 실행 시간을 줄일 수 있다는 장점이 있습니다.

describe("메시지를 입력할 때") {
    it("동작 검증한다") {
        await sut.process(LiveChatRequest.OnChangeMessage(inputText: inputText))
        
        // 입력된 메시지가 최대 글자 수를 초과하지 않도록 제한한다
    }

    context("입력된 메시지가 최대 글자 수를 초과했다면") {        
        it("동작 검증한다") {
            await sut.process(LiveChatRequest.OnChangeMessage(inputText: inputText))
            
            // 글자수 제한 토스트를 노출한다
            
            // chatInputText를 제한한 메시지로 갱신해준다
        }
    }
}

2. 실패하는 테스트 만들기

1단계에서 작성한 시나리오에 따라 테스트 코드를 작성합니다.

이 시점에는 실제 구현이 없기 때문에 테스트는 당연히 실패하게 되는데, 이후 이를 바탕으로 테스트를 통과시키기 위해 최소한의 기능을 하나씩 구현해나가게 됩니다.

이 과정이 TDD의 핵심으로, 테스트가 요구사항을 명확히 정의해주고 구현 방향을 자연스럽게 잡아줍니다.

describe("메시지를 입력할 때") {
    
    beforeEach {
        inputText = liveChatStub.newInputText
    }

    it("동작 검증한다") {
        await sut.process(LiveChatRequest.OnChangeMessage(inputText: inputText))
        
        // 입력된 메시지가 최대 글자 수를 초과하지 않도록 제한한다
        verify(liveMessageOperation).restrictToMaxLength(text: inputText)
    }

    context("입력된 메시지가 최대 글자 수를 초과했다면") {
        var limitedText: String!
        
        beforeEach {
            limitedText = liveChatStub.limitedText

            stub(liveMessageOperation) {
                $0.restrictToMaxLength(text: inputText).thenReturn(limitedText)
            }
        }
        
        it("동작 검증한다") {
            await sut.process(LiveChatRequest.OnChangeMessage(inputText: inputText))
            
            // 글자수 제한 토스트를 노출한다
            verify(presenter).present(LiveChatResponse.toast(.limitedTextError))
            
            // chatInputText를 제한한 메시지로 갱신해준다
            verify(presenter).present(LiveChatResponse.chatInputText(limitedText))
        }
    }
}

3. 성공하는 테스트 만들기

이제 2단계에서 작성한 테스트가 통과되도록 실제 구현 코드를 작성합니다.

이 과정에서는 테스트에 맞춰 핵심 로직을 중심으로 자연스럽게 코드를 정리하게 되었고, 실제 요구사항에 맞춘 최소한의 구현을 빠르게 확보할 수 있었습니다. 또 불필요한 분기나 과도한 방어 코드를 넣지 않아도 되어, 전체 구조도 더 단순하고 명확해졌습니다.

protocol LiveMessageOperator: Sendable {
        func verifyMessage(content: String) async throws -> Bool
}

enum LiveChatRequest {
        ...
        struct OnChangeMessage {
            let inputText: String
        
        init(inputText: String) {
            self.inputText = inputText
        }
    }
}

enum LiveChatResponse: Equatable {
        ...
    case chatInputText(String)
    case toast(ToastKind)

        enum ToastKind: Equatable {
        case limitedTextError
    }
}

func process(_ request: LiveChatRequest.OnChangeMessage) async {
    if let limitedText = await dependency.liveMessageOperation.restrictToMaxLength(text: request.inputText) {
        presenter?.present(.toast(.limitedTextError))
        presenter?.present(.chatInputText(limitedText))
    }
}

4. 협력 객체(router, presenter 등) 구현

이제 실제 의존 객체들을 구현할 차례로, 다음과 같은 협력 객체 LiveMessageOperation, Presenter 등의 구성 요소를 이 시점에서 채워나갑니다.

final actor LiveMessageOperation: LiveMessageOperator {
        ...

    func restrictToMaxLength(text: String) async -> String? {
        // 구현 작성 - 생략
    }
}

extension LiveChatPresenter: LiveChatPresentationLogic {
    func present(_ response: LiveChatResponse) {
        switch response {
                case let .toast(kind):
            switch kind {
            case .messageNotSent:
                // 구현 작성 - 생략 
            }
            
            case let .chatInputText(text):
                // 구현 작성 - 생략 
        }
    }
}

5. 리팩토링 및 테스트 유지

모든 테스트가 통과한 후에는 구현 코드와 테스트 코드를 정리하고 개선합니다.

이 단계에서는 중복된 코드나 불필요한 임시 구현 등을 제거하고, 더 명확하고 일관된 구조로 리팩토링하는 작업이 이뤄집니다.

예를 들어, 테스트 코드에서는 중복되는 mock 세팅이나 assertion 코드를 beforeEach나 커스텀 헬퍼 함수로 정리해, 테스트의 목적이 더 뚜렷하게 드러나도록 개선합니다.

이러한 리팩토링 과정을 통해 테스트와 구현 코드 모두 가독성과 유지보수성을 갖춘 구조로 다듬을 수 있습니다.

이렇게 5단계 테스트 과정을 밟으면서, iOS팀은 라이브 스트리밍 구조 개편 작업을 안정적으로 마무리할 수 있었습니다.

느낀 점

TDD를 처음 도입하면서 인상 깊었던 점을 공유드리자면,

• 테스트 코드가 명확한 개발 가이드 역할을 해주어, 구현 방향을 잃지 않고 개발할 수 있었습니다.
• 테스트 코드가 마련되어 있으므로, 리팩토링 이후에도 기존 기능이 정상 동작하는지 빠르게 검증할 수 있습니다.
• 테스트를 진행하면서 기능 구현뿐만 아니라 코드의 품질과 구조까지 함께 점검할 수 있었습니다.
• 아키텍처 개편 과정에서 미처 놓칠 수 있는 부분(스펙, 사이드 이펙트 등)을 테스트 코드를 작성하여 보다 안전하게 진행할 수 있었습니다.

물론 처음에는 다소 느리고 번거롭게 느껴진 적도 있었습니다. 하지만 마지막에 테스트 커버리지를 확인하고 수동 테스트까지 진행한 결과, 큰 문제 없이 안정적으로 동작한다는 것을 확인하고나서 테스트 코드가 안정성과 유지보수성 확보에 얼마나 중요한 역할을 하는지 실감할 수 있었습니다.

마무리하며

TDD 도입뿐 아니라, 아키텍처 구조 개편, 새로운 팀원들과의 협업이라는 3가지 큰 변화를 동시에 마주한 iOS팀에게도 저에게도 의미 있는 시간이였다고 생각합니다. 이 글이 TDD를 처음 시도해보거나, 테스트 문화를 도입하려는 개발자 분들께 작게나마 도움이 되었기를 바랍니다.

끝까지 읽어주셔서 감사합니다!