노머스 모바일팀이 TDD를 활용하는 법

들어가며

안녕하세요! 저는 노머스 모바일팀의 개발 리드 최대순입니다. 현재는 fromm이라는 서비스를 개발하며, 다양한 기술적 도전과제를 해결하고 있습니다.

개발자라면 누구나 한 번쯤은 TDD(Test-Driven Development)라는 용어를 접하거나, 이 방법론을 도입하려 시도해본 경험이 있을 것입니다. TDD는 많은 개발 서적과 강연에서 높은 코드 품질, 안정성, 유지보수성을 보장하는 혁신적인 방법론으로 소개됩니다. 그러나 이를 실무에서 실제로 적용하고, 특히 운영 중인 서비스의 개발 과정에서 체계적으로 활용한 경험을 가진 개발자는 많지 않을 것입니다.

특히, fromm처럼 다양한 기능을 포함하고 있으며, 복잡한 UI/UX 요구사항과 스타트업 특유의 빠른 개발 사이클을 충족해야 하는 모바일 앱 서비스의 경우 TDD를 적용하는 과정은 더욱 까다롭습니다. 이론적으로는 이상적이지만, 현실적으로는 제한된 리소스와 빠른 의사결정 속에서 TDD를 도입하고 유지하기란 쉽지 않습니다.

그럼에도 불구하고, 노머스 모바일팀은 TDD를 통해 코드 품질과 개발 생산성을 높이기 위해 꾸준히 노력해왔습니다. 이 글에서는 저희 팀이 실무에서 TDD를 어떻게 적용했는지, 겪은 어려움과 이를 극복하기 위한 과정에서의 시행착오를 공유하고자 합니다. 이 글이 여러분에게 실질적인 도움과 영감을 줄 수 있기를 바랍니다.

TDD란?

TDD(Test-Driven Development)는 켄트 벡(Kent Beck)이 고안한 소프트웨어 개발 방법론으로, “테스트 주도 개발”이라는 이름 그대로 테스트를 먼저 작성하고 이를 기반으로 코드를 작성하는 방식입니다. TDD는 다음과 같은 반복적 과정을 통해 이루어집니다.

• Red: 실패하는 테스트 작성
  • 먼저 작성한 테스트 케이스가 실패하도록 설계합니다. 이는 구현되지 않은 기능을 명확히 정의하는 단계입니다.
• Green: 테스트를 통과하는 최소한의 코드 작성
  • 테스트가 성공하도록 간단하게 코드를 구현합니다. 이 단계에서는 최소한의 기능 구현에 집중합니다.
• Refactor: 코드 개선
  • 테스트가 통과한 후, 코드를 리팩터링하여 가독성과 유지보수성을 개선합니다. 이때 테스트가 다시 실패하지 않도록 주의합니다.

TDD의 기대 효과

TDD의 주요 장점은 다음과 같습니다.

• 버그 감소: 테스트를 기반으로 코드를 작성하기 때문에 코드의 안정성이 높아집니다.
• 리팩터링 안전성: 코드 변경 시 테스트가 올바르게 동작하는지 보장합니다.
• 명확한 설계: 테스트 작성 과정에서 인터페이스와 로직이 자연스럽게 설계됩니다.

하지만 TDD는 단순한 코딩 기법을 넘어, 소프트웨어 개발의 철학이자 사고방식으로 이해되어야 합니다. 실제로 이를 실무에 성공적으로 적용하기 위해서는 서비스 특성과 팀의 상황에 맞는 전략적 접근이 필요합니다.

모바일팀에서의 TDD 적용

TDD vs BDD: 실무에서의 고민

모바일 앱 개발 환경에서는 TDD의 전통적인 방식만으로는 해결할 수 없는 문제들이 자주 발생합니다. 이를 극복하기 위해 저희 팀은 TDD와 함께 BDD(Behavior-Driven Development) 스타일을 적절히 결합하여 활용했습니다.

전통적 TDD의 한계

켄트 벡의 전통적인 TDD 방식은 작은 단위의 테스트를 기반으로 코드를 작성하는 데 중점을 둡니다. 하지만 모바일 앱 개발에서는 다음과 같은 한계점이 있었습니다.

• 테스트 케이스의 폭발적 증가 : UI/UX와 관련된 다양한 시나리오를 모두 테스트하려면 케이스가 과도하게 많아집니다.
• 변화에 따른 유지보수 부담 : 모바일 앱은 UI 변경이 빈번하며, 비즈니스 로직도 자주 수정됩니다. 모든 변화마다 테스트를 수정하는 것은 현실적으로 어렵습니다.
• 도메인 이해의 어려움 : 지나치게 세분화된 테스트는 오히려 도메인 로직을 파악하기 어렵게 만듭니다.

BDD로의 전환: 사용자 중심 테스트

이러한 문제를 해결하기 위해, 저희 팀은 Given-When-Then 패턴을 기반으로 한 BDD 방식을 병행했습니다.

예를 들어, “프로필을 클릭했을 때 해당 프로필이 존재하면 프로필 이미지 화면으로 이동한다.”라는 사용자 시나리오를 기반으로 작성한 테스트는 다음과 같습니다.

fun `OnClickProfile_Profile exist_navigate ToProfileImage`() = runTest {
  //test code
}

BDD 스타일을 통해 작성된 테스트는 다음과 같은 장점을 가집니다.

• 비즈니스 요구사항을 명확히 반영 : 테스트 케이스를 통해 실제 요구사항이 코드에 명확히 녹아들 수 있습니다.
• 변화에 유연한 설계 가능 : 빈번한 변화에도 도메인 로직을 중심으로 안정적인 테스트를 유지할 수 있습니다.

필요에 따라, 도메인 내부 로직이나 특정 유틸리티 함수 검증을 위해 전통적인 TDD 방식도 적절히 병행했습니다.

TDD의 목적은 설계의 품질 향상

TDD는 단순히 버그를 방지하는 도구, 엣지 케이스를 점검하기 위한 도구가 아니라, 설계 품질을 높이는 철학으로 이해해야 그 가치를 제대로 활용 할 수 있습니다. 저희 팀은 설계 품질의 향상을 주 목적으로 하여 TDD를 활용하였으며 다음과 같은 설계 개선 효과를 경험했습니다.

• 인터페이스 설계 : 테스트를 먼저 작성하는 과정에서 자연스럽게 인터페이스가 구조화됩니다.
• 사전 리뷰 가능 : 테스트 케이스를 작성하면서 설계 단계에서부터 리뷰를 받을 수 있습니다.
• 품질과 생산성 향상 : 잘 설계된 인터페이스는 코드 품질을 높이고, 불필요한 수정 비용을 줄입니다.

TDD에 집착하지 않는 유연함

저희 팀은 TDD를 엄격히 적용하는 대신, 효율적인 설계와 빠른 개발 주기 유지를 목표로 하고 있습니다. 모든 영역에 TDD를 적용하기보다는, 핵심 비즈니스 로직에 집중하여 효과를 극대화하고 있습니다.

저희는 “완벽한 테스트 커버리지”가 목표가 아니라, 효율적인 설계와 빠른 개발 주기를 유지하는 것을 목표로 삼고 있습니다. 서비스는 자주 변경되기 때문에, 모든 테스트를 수정하고 유지보수하는 것은 불가능합니다. TDD에 과도하게 집착할 경우, 오히려 속도가 느려지고 테스트 코드 자체가 유지보수의 대상이 될 위험이 있습니다.

저희는 TDD를 모든 범위에 적용하지 않고, 핵심 영역에만 제한적으로 도입했습니다. 예를 들어, Clean Architecture를 기반으로 한 서비스 설계에서, Usecase 레이어에만 TDD를 집중적으로 적용하고, Presentation 및 Data 레이어에서는 필요에 따라 제한적으로 테스트를 작성합니다. 이를 통해 TDD의 이점과 빠른 개발 주기 사이의 균형을 유지할 수 있었습니다.

모바일팀에서의 TDD 예시 사례

간단한 예시를 통해서 모바일팀에서 TDD를 어떻게 적용하고 있는지 소개하겠습니다. 먼저 다음과 같은 요구사항을 구현해야한다고 가정하겠습니다.

프로필 화면진입 시 프로필 데이터를 불러와서 사용자에게 노출한다.

현실에서는 위와 같은 명확한 요구사항보다 보다 복잡하고, 화면기획, 정책 등이 포함된 기획서가 전달 될 것입니다. 일단 예시 사례에서는 단순히 프로필 화면 진입 시 사용자의 프로필을 노출하는 기능을 구현한다고 가정하겠습니다. 요구사항을 전달 받으면 담당자는 Usecase를 설계하게 됩니다. 이때 Usecase 설계가 TDD와 함께 진행됩니다.

작업자는 프로필 데이터를 가져오는 FetchProfileUsecase 를 만들고자 하고 아래와 같이 테스트 케이스를 생각해 볼 수 있습니다.

@Test
fun `launch profile screen_given profile id_return profile data`() = runTest {
    
}

해당 테스트 코드는 프로필 화면에 진입했을 때, 주어진 프로필ID를 가지고 profile data 를 리턴해야하는 테스트 케이스가 됩니다. 물론 이외에도 다양한 기획적인 예외상황 (ex. 프로필 아이디가 없을 때는 오류 팝업을 노출한다 등)을 반영한 테스트 케이스도 있겠지만 해당 부분들은 생략하겠습니다. 이제 테스트 코드를 작성해야하는데 이때 Repository Interface 설계가 함께 이루어집니다. 작업자는 서버에서 프로필 데이터를 가져와야 하기 때문에 repository interface 를 구성하고 다음과 같이 테스트 코드를 작성 할 것입니다. 대략적으로는 아래와 같은 테스트 코드를 작성 할 수 있습니다. (아래 코드는 간략하게 작성 된 예시입니다.)

@Test
fun `launch profile screen_given profile id_return profile data`() = runTest {
    val mockRepository = mockk<ProfileRepository>()
    val profile = Profile("User123", "user123@example.com")
    coEvery { mockRepository.getProfile(any()) } returns profile

    val useCase = FetchProfileUseCase(mockRepository)
    val result = useCase("user123")

    assertEquals(profile, result)
}

이 과정을 통해 Repository 인터페이스와 Profile 이라는 도메인이 설계가 됩니다. 해당 코드와 인터페이스, 도메인 모델은 코드리뷰를 통해서 한번 더 검증되고 이후 Data레이어, Presentation레이어 작업이 진행됩니다.

위 예시에서는 매우 간략한 케이스로 축약해서 설명을 드렸는데요, 실제 복잡한 로직일 수록 TDD의 효과를 많이 느낄 수 있습니다. 아래 코드 저희가 사용하고 있는 테스트 케이스의 실 예시입니다.

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class ExampleUseCaseTest {

    private lateinit var useCase: ExampleUseCase

    @MockK
    private lateinit var repositoryA: RepositoryA

    @MockK
    private lateinit var repositoryB: RepositoryB

    @MockK
    private lateinit var handler: Handler

    private val fixture = kotlinFixture()

    @BeforeAll
    fun setup() {
        MockKAnnotations.init(this)
        useCase = ExampleUseCase(
            repositoryA = repositoryA,
            repositoryB = repositoryB,
            handler = handler
        )
    }

    @Test
    fun `Given repositoryB throws NotFoundException When useCase is invoked Then result is Failure`() = runTest {
        val testData: DataType = fixture()

        coEvery { repositoryA.getData(any()) } returns testData
        coEvery { repositoryB.connect(any(), any()) } throws CustomException.NotFoundException
        coEvery { handler.cleanup() } returns Unit

        val result = useCase.invoke(ExampleUseCase.Param(id = fixture(), key = fixture()))

        assertThat(result).isEqualTo(ExampleUseCase.Result.Failure)
    }

    @Test
    fun `Given repositoryA throws DataNotFound When useCase is invoked Then result is Failure`() = runTest {
        coEvery { repositoryA.getData(any()) } throws CustomException.DataNotFound
        coEvery { repositoryB.connect(any(), any()) } returns Unit
        coEvery { handler.cleanup() } returns Unit

        val result = useCase.invoke(ExampleUseCase.Param(id = fixture(), key = fixture()))

        assertThat(result).isEqualTo(ExampleUseCase.Result.Failure)
    }

    @Test
    fun `Given valid inputs When all operations succeed Then result is Success`() = runTest {
        val data: DataType = fixture()
        val metadata: MetadataType = fixture()
        val additionalInfo: AdditionalInfo = fixture()

        coEvery { repositoryA.getData(any()) } returns data
        coEvery { repositoryB.connect(any(), any()) } returns Unit
        coEvery { repositoryB.getMetadata() } returns metadata
        coEvery { repositoryB.getAdditionalInfo() } returns additionalInfo
        every { repositoryB.isConditionMet() } returns true

        val result = useCase.invoke(ExampleUseCase.Param(id = fixture(), key = fixture()))

        assertThat(result).isEqualTo(
            ExampleUseCase.Result.Success(
                data = data,
                metadata = metadata,
                additionalInfo = additionalInfo,
                conditionMet = true
            )
        )
    }

    @Test
    fun `Given metadata indicates termination When useCase is invoked Then result is Failure`() = runTest {
        val data: DataType = fixture()

        coEvery { repositoryA.getData(any()) } returns data
        coEvery { repositoryB.connect(any(), any()) } returns Unit
        coEvery { repositoryB.getMetadata() } returns MetadataType.TERMINATED

        val result = useCase.invoke(ExampleUseCase.Param(id = fixture(), key = fixture()))

        assertThat(result).isEqualTo(ExampleUseCase.Result.Failure)
    }
}

마치며

TDD는 모든 환경에서 동일하게 적용될 수 없습니다. 팀의 역량, 서비스의 특성, 회사의 상황에 따라 그 방식은 달라져야 합니다. 저희 노머스 모바일팀은 TDD와 BDD를 적절히 결합하여 핵심적인 영역에 집중함으로써, 효율적인 설계와 코드 품질을 동시에 달성하고자 노력해왔습니다.

이 글이 TDD 도입을 고민하고 계신 분들에게 조금이나마 도움이 되길 바라며, 각자의 환경에 맞는 최적의 방법을 찾아가시길 응원합니다. 감사합니다! 😊