iOS

iOS 개발에서 MFA 패턴 활용하기: with SampleApp

2025년 1월 24일

안녕하세요, 여기어때컴퍼니 iOS개발팀의 엔비입니다.

오늘은 여기어때가 MFA(Micro Feature Architecture)를 도입하게 된 배경과 실제 활용 사례에 대해 소개해드리려고 합니다.

1. MFA의 도입배경

여기어때는 국내숙소만을 제공하는 서비스에서 해외숙소, 레저 티켓, 공간대여 등 더 다양한 서비스들을 제공하는 앱으로 성장하였습니다. 그에 맞추어 최근 몇 년간 저희 iOS 개발팀의 인원 또한 늘어나게 되었습니다.

점점 커지는 앱의 규모와 점점 복잡해지는 앱의 코드로 인해 여러 문제점들이 발생하기 시작했습니다. 그 중 대표적인 문제점들은 빌드 시간의 증가, 코드 간의 의존성증가로 인한 유지보수의 난이도 증가, 여러 팀원들이 동시에 작업할 때 코드 충돌이 잦아지고 사이드 이펙트가 발생하는 이슈입니다.

여기어때의 모듈화 여정

이러한 문제들을 해결하기 위해 저희 팀은 모듈화의 필요성을 느꼈고, MFA(Micro-Feature-Architecture) 아키텍처를 도입하기로 결정했습니다.

지난 글에서 iOS개발팀이 어떻게 모듈화를 진행했는지 소개해드렸는데요, 이번에는 MFA를 도입한 후 실제 이를 어떻게 활용하고 있는지 소개해드리려고 합니다.

여기어때의 개발은 크게 두 가지로 나뉩니다. 앱의 코어 로직을 리팩토링하고 유지보수하는 작업과, 비즈니스 요구사항에 따른 피처 개발로 구분됩니다. 피처 개발의 경우, 담당자가 해당 프로젝트의 오너십을 가지고 특정 버전 배포를 목표로 프로젝트를 리드하며 개발을 진행하게 됩니다.

iOS 앱개발 인원이 1 ~2명이었던 시절에는 소수의 개발자가 모든 작업을 담당했기에 외부 피처의 작업 상황을 크게 신경 쓸 필요가 없었고, 대부분의 피처를 담당하고 있었습니다. 그러다 보니 사이드 이펙트가 어느 곳에서 발생할지 예측 가능한 상황에서 개발할 수 있었습니다. 하지만 팀원이 늘어나고 동시에 진행되는 피처가 많아지면서, 동일 타겟 버전의 피처들 간에 코드 의존성과 사이드 이펙트 이슈가 발생하게 되었습니다. 그래서 버전을 출시할 때마다 이러한 이슈들을 해결하는 것이 항상 큰 과제였습니다.

하지만 MFA 아키텍처를 도입한 후 iOS개발팀의 상황은 많이 달라졌습니다. 피처개발자는 더 이상 자신의 개발 피처 외에 다른 피처의 개발진행 상황을 신경쓰지 않게 되었습니다. 다만 기존의 작업과는 조금 다른 방식으로 개발하게 되었습니다. 이번에 출시된 찜 개편 프로젝트에서 MFA를 사용한 개발방식이 어떻게 사용되어 개발시간을 단축시키고, 피처간의 사이드이펙트를 줄이게 되었는지 이야기드려보겠습니다.

2. 찜 개편 프로젝트에서 활용된 MFA의 장점들

2.1 협업하기 좋은 환경

이번에 진행한 찜 개편의 한 화면입니다. 찜 폴더안의 상품 PLP(Product List Page)에서 지도보기 페이지로 이동하는 개발이 필요하고, 지도보기 페이지에서 날짜를 변경했을 때 상품PLP에도 같은 날짜로 적용하는 개발이 필요합니다. 이 때, 지도보기 페이지 개발자와 상품 PLP 개발자가 협업을 한다고 가정해보겠습니다.

2.1.1 모놀리틱 구조에서 개발하는 방식

먼저 두 명의 개발자가 각각의 피처를 작업할 때 기존에는 UI 선행개발을 진행하고, 두 피처의 비즈니스 로직이 모두 완성될 때까지 비즈니스 로직의 연동 작업을 할 수 없었습니다.

MFA 도입 전 협업방식

이는 굉장히 비효율적인 구조이고 전체적인 개발 일정을 딜레이 시키는 큰 이슈였습니다.

2.1.2 MFA 구조에서 개발하는 방식

하지만 MFA를 도입하고 나서는 상황이 많이 변화되었습니다. 먼저 두 명의 개발자가 기획을 확인합니다. 그리고 Interface 모듈을 먼저 정의하고, 해당 모듈에 각 피처를 연동할 Protocol을 선언합니다. 이제 각 피처의 개발자는 다른 피처의 외부 코드와 상관없이 본인 피처의 Protocol에만 업데이트 진행해주면 됩니다.

MFA 도입후 협업방식

MFA의 도입과 피처단위의 개발작업을 통하여 개발자는 이제 더 이상 외부피처의 개발 일정을 신경쓰지 않아도 되며 동시에 사이드 이펙트의 위험성을 줄일 수 있습니다.

3. 샘플앱을 활용한 개발 생산성의 향상

MFA의 가장 큰 장점은 샘플앱에 있습니다.

iOS 개발자들은 일반적으로 코드를 수정할 때마다 앱 전체를 다시 빌드하고, 확인이 필요한 화면까지 단계별로 이동해야 하는 번거로운 과정을 거쳐왔습니다. 이 과정은 간단해 보이지만 프로젝트가 크거나, 확인이 필요한 화면까지 도달하는 플로우가 복잡한 경우 매번 반복하기에는 많은 시간이 소요되었습니다. 이러한 비효율적인 과정의 반복은 개발 생산성을 크게 저하시켰고 iOS개발팀을 피곤하게 만들었습니다.

찜목록에 도달하기 위한 화면 전환 플로우

3.1 개선된 개발 프로세스

개선된 개발 프로세스

위에서 이야기드린 방해요소들은 MFA를 도입한 후 제거되었습니다. 샘플앱을 통해 앱 전체가 아닌 필요한 피처만을 빌드할 수 있게 되었고, 일부 화면 전환 플로우는 과감하게 생략할 수 있는 구조를 만들었습니다. 현재 프로젝트와 무관한 피처들을 제외하고 빌드하니 베스트케이스에서는 약 10분 -> 약 1 ~ 2분 정도로 그 소요시간이 대폭 줄어들게 되었고, 불필요한 화면 플로우는 모두 사라졌습니다.

추가로 기존의 개발방식을 이용할 때에는 앱의 시작시점에서 개발자가 어떤 서버 환경에서 개발할지 체크하고 빌드까지 해야했습니다. 그런데 샘플앱에서는 서버 선택창을 도입하여 화면 전환을 간소화하고 빌드 횟수 또한 줄일 수 있었습니다.

3.2 샘플앱의 또 다른 장점

샘플앱의 장점은 이 뿐만이 아닙니다. 앱 개발 과정에서는 실제 서버 데이터가 아닌 Mock 데이터나 Mock 서비스를 활용해야 하는 경우가 자주 발생합니다. 기존의 모놀리틱 구조앱에서는 이러한 Mock 객체들과 개발용 코드가 메인 앱에 포함될 수밖에 없었습니다.

특히 Mock 데이터에 민감한 정보가 포함되어 있거나, 테스트를 위한 API 엔드포인트가 노출될 수 있다는 점에서 보안상의 우려도 존재했습니다. 물론 배포 시에는 개발 환경 체크를 통해 앱스토어 버전에서 이 코드들이 동작하지 않도록 할 수 있지만, 개발용 코드가 프로덕션 앱에 포함된다는 사실 자체가 개발자들에게는 항상 불안 요소로 작용해왔습니다.

이러한 개발용 코드들이 앱 크기를 불필요하게 증가시키고, 빌드 시간을 늘리는 원인이 되기도 했습니다. 하지만 샘플앱이 도입되고 난 후 메인앱에는 불필요한 개발용 코드가 들어가지않아 불안요소가 모두 해소되었습니다.

3.3 샘플앱 자동화

샘플앱을 만드는 것은 기존 여기어때 앱과 동일한 구조의 새로운 앱을 구성하는 작업입니다. 만약 이 과정을 모두 수동으로 진행해야 한다면, 앞서 언급한 불필요한 과정들보다 더 복잡하고 비효율적일 수 있습니다. 그렇기 때문에 샘플앱 생성 과정은 최대한 간단해야 합니다.

다행히도 여기어때 iOS개발팀은 이미 이 문제를 해결할 수 있는 도구를 사용하고 있었습니다. 프로젝트 생성 도구인 Tuist 입니다**.** Tuist에서 제공하는 Scaffold 기능을 활용하면, 단 1초 만에 필요한 모듈과 샘플앱 환경을 구성할 수 있습니다.

Tuist Scaffold Feature — Name “피처명”

새로운 모듈을 만들기 위해서는 위의 명령어 한 줄이면 됩니다. 위의 명령어를 입력하면 새로운 모듈을 만들어주고 개발에 필요한 환경을 구축한 샘플앱을 만들어주게 됩니다.

protocol DemoAppMainProtocol {
    ///추가로 필요한 피처를 등록해주세요
    func featureInject()
    ///Mock네트워크가 필요하다면 등록해주세요
    func mockNetworkInject()
    func startView(navigationController: UINavigationController)
}

featureInject() 함수를 통해 현재 개발 중인 피처와 연관된 다른 피처들을 데모앱에 등록하여 테스트할 수 있습니다. 모든 피처는 Protocol 기반으로 개발되어 있어, 실제 구현체가 아닌 인터페이스를 통해 상호작용합니다. 이러한 구조 덕분에 개발자는 연관된 피처의 등록 여부를 자유롭게 선택할 수 있으며, 데모앱에서 구현할 화면이나 기능의 범위도 개발자의 판단에 따라 결정할 수 있습니다.

네트워크 통신 역시 같은 Protocol을 따릅니다. 모든 네트워크 객체들이 Protocol 기반의 인터페이스로 구성되어 있어, 개발자는 샘플앱 개발 시 Mock 네트워크를 사용할지, 실제 네트워크를 사용할지만 결정하면 됩니다. 이러한 구조는 개발자에게 더 큰 자율성과 유연성을 제공하며, 필요한 부분에만 집중할 수 있게 해줍니다.

3.4 처음부터 완벽했나?

로그인을 못해 화면 확인이 어려움

최초의 여기어때 샘플앱은 사용성이 좋은 편은 아니었습니다. 기본적인 빌드 환경은 갖추고 있었지만, 실제 개발 과정에서 많은 한계점이 드러났습니다. 가장 큰 문제점은 로그인 토큰 관리였습니다. 초기 버전에서는 로그인 기능 없이 개발자가 직접 토큰을 수동으로 관리해야 했고, 이는 오히려 개발 시간을 증가시키는 요인이 되었습니다. 샘플앱을 도입하는 목적인 ‘개발 효율성 향상’을 전혀 달성하지 못하고 있었습니다.

토큰 문제를 해결하기 위해 샘플앱에 기본적인 로그인 기능을 추가했습니다. 또한 개발 및 스테이징 환경에서 발생하는 다양한 이슈들을 해결하기 위한 보조 기능들도 점진적으로 도입했습니다. 이러한 개선들은 실제 개발 환경을 크게 향상시켰고, 결과적으로 개발 효율성 측면에서 큰 성과를 거둘 수 있었습니다.

4. 디자이너와 협업에서 활용 되는 샘플앱

이렇게 다양한 장점을 가진 샘플앱을 단순히 개발 단계에서만 활용하기에는 너무나 아쉬운 기술입니다. 이러한 이유로 여기어때는 샘플앱의 활용 범위를 적극적으로 넓히고 있습니다.

가장 대표적인 예는 여기어때 디자인 시스템(YDS)의 샘플앱 적용입니다. 그 간 디자이너분들은 디자인 도구에서만 컴포넌트를 확인할 수 있었고, 앱에서 확인하기 위해서는 실제 서비스되는 상용 앱을 통해야만 했습니다. 그러나 최근에는 디자인 컴포넌트 전용 샘플앱을 별도로 배포하여 운영하고 있습니다. 이를 통해 디자이너분들도 피그마가 아닌 실제 iOS 앱과 동일한 환경에서 직접 컴포넌트들을 확인하고 테스트할 수 있습니다.

YDS 샘플앱

더 나아가, 이 샘플앱은 디자이너와 개발자 간의 명확한 커뮤니케이션을 위한 디자인 미리보기 도구로도 유용합니다. 각 컴포넌트의 실제 동작과 다양한 상태를 먼저 확인할 수 있어 디자인 리뷰나 QA 과정에서도 효율적인 협업이 가능합니다. 이처럼 YDS 샘플앱은 팀 전체의 생산성을 향상시키는 핵심 도구로 자리잡았습니다.

5. 마무리

여기어때 앱이 출시된 지 어느덧 10년이라는 시간이 흘렀고, 그동안 수많은 사용자분들이 여기어때 앱과 함께 해주셨습니다. 앱의 역사가 깊어질수록 자연스럽게 내부 코드의 레거시도 축적되어 왔습니다. iOS개발팀은 이러한 환경에서도 MFA와 모듈화를 성공적으로 도입하며 기술적인 성장을 이뤄냈습니다. 이를 통해 코드의 유지보수성을 크게 향상시켰고, 새로운 기능 개발 시 발생하는 사이드 이펙트도 최소화할 수 있게 되었습니다. 특히 개발자 간의 협업이 더욱 원활해졌으며, 각 피처의 독립성을 보장함으로써 더 안정적인 개발 환경을 구축할 수 있었습니다.

앞으로도 iOS개발팀은 사용자들에게 더 나은 서비스를 제공하기 위해 지속적인 기술 혁신을 추구할 것입니다. 이번 MFA 도입은 그 시작점일 뿐이며, 더 나은 개발 환경과 개발 문화를 만들어가기 위해 iOS개발팀의 노력은 계속될 것입니다.