모듈화를 통한 iOS프로젝트 증분빌드 시간 개선

들어가며

안녕하세요. 원더월 모바일팀에서 iOS앱 개발을 맡고 있는 정김기보라고 합니다.

올해 fromm iOS프로젝트에는 Tuist를 활용하여 지속적으로 모듈화를 진행하고 있습니다. 모듈화를 진행하면 여러 장점들에 대해 많이 들어보셨을 거라 생각합니다. 유지보수 용이성이 증가하고, 의존성 관리도 쉬워지는 등 여러 장점이 있을텐데요. 여러 장점 중 모듈화를 진행하면 빌드 속도가 빨라진다는 얘기도 들어보셨을 것 같습니다.
fromm 프로젝트에서도 모듈화를 진행하며 빌드 속도의 개선도 확인을 할 수 있었는데요.
오늘은 빌드 속도의 개선 중 증분빌드 속도의 개선에 대해서 구체적으로 어떤 것들이 개선되었는지를 공유드리고자 합니다.

모듈간 증분 빌드

iOS 개발자라면 증분 빌드에 대해서 많이 들어보셨을 것 같습니다. 증분 빌드는 전체 모듈을 빌드하는 대신 다시 컴파일해야 하는 부분들만 컴파일하는 기술입니다.
모듈들 간의 증분 빌드에 대해서만 간단히 짚고 넘어가면 모듈의 외부로 노출되는 인터페이스가 변경이 되는 수정이 일어났을 때에는 수정이 일어난 모듈과 해당 모듈에 의존성을 가지고 있는 모든 모듈들 또한 증분 빌드가 실행됩니다.
쉽게 예를 들면 만약 A라는 모듈을 B, C, D가 의존하고 있을 때, A에서 B에서만 사용하는 함수의 인터페이스만 수정이 일어나도 C, D 또한 증분 빌드의 대상이 되는 것이죠.
이를 별로 고려하지 않고 작업하였을 때 빌드 시간에 어떤 영향을 미칠 수 있는지 모듈 구조 개선 작업 진행 전 실제 사례를 통해 알아보겠습니다.

사례 1. 너무 많은 모듈이 의존하고 있는 CommonKit 모듈

CommonKit
    | Encryption-Helper
    | Resource-Helper
    | Version-Util
    | Screen-Util
    | A-Extension
    | B-Extension

CommonKit은 앱의 여러곳에서 쓰이는 것들을 파일형태로만 분리한 뒤 모아놓은 모듈입니다. 파일간에 책임분리는 분명하지만 모듈의 책임은 딱히 뭐라 설명하기 어려운 모듈이죠.
그래서 데이터 로직 관련 모듈, 비즈니스로직 관련 모듈, 그 외 여러 모듈들이 CommonKit에 의존성을 가지고 있었습니다.
이렇게 많은 모듈들이 의존하고 있는 모듈의 변경은 증분 빌드에 얼마나 영향을 미칠까요??
아래와 같이 아무도 쓰지 않는 구조체를 하나 추가해보았습니다.

import Foundation

public struct NobodyUseThis {
}

다시 증분 빌드를 하였을 때의 결과 사진입니다.


그저 아무도 쓰지 않는 구조체 하나를 추가했을 뿐인데 수많은 모듈과 ViewController들, UseCase들 같은 파일들까지 같이 빌드되고 있는 것을 볼 수 있습니다. 시간은 약 50초나 소요가 되었구요. 이런 상황이 발생한 이유는 간단합니다.
생각보다 많은 여러 모듈들이 NobodyUseThis라는 구조체를 선언하고 사용할 수 있게 하기 위해서 증분빌드의 대상이 되었기 때문입니다.


물론 어쩔 수 없이 의존성을 가져야 하는 상황이라면 이 상태를 유지해야겠지만 현재 저희는 CommonKit을 조금 더 세분화된 여러 모듈로 나눠 위 문제를 해결하는 방식으로 모듈화를 진행중입니다.

사례 2. Routing까지 같이 책임지는 Networking 모듈

위 CommonKit과 비슷하게 예상치 못한 증분 빌드 시간 증가 사례가 fromm 프로젝트에 또 있습니다. 바로 NetworkProvider모듈입니다.
이 모듈은 Network기능뿐 아니라 실제 endpoint를 enum으로 가지고 있는 모듈입니다.
따라서 endpoint의 enum case의 수정이나 추가가 일어날 경우 CommonKit과 똑같이 NetworkProvider에 종속성을 가지고 있는 모든 모듈들은 다같이 증분 빌드 프로세스의 대상이 되어버리죠.

public enum AuthNetworkRouting {
    case newEndPoint
}

enum에 newEndPoint라는 case하나만 추가해보겠습니다

enum에 case하나만 추가했을 뿐인데 약 15초의 빌드 시간이 걸리며 약 30개의 모듈들이 증분빌드 과정에 포함되고 있습니다.
(위 그림에서 보라색으로 표현된 Emitting module for NetworkProvider직후 작은 네모들이 다 모듈입니다)
실제로 AuthRequest를 사용하는 파일이 포함된 모듈은 당연히 컴파일을 해야겠지만 그와 상관없는 모듈 30개까지 검사를 하고 있는 형태입니다.
제 맥북에선 대략 한 개의 모듈 검사당 0.1초에서 0.2초 정도가 소요되므로 endpoint를 추가할 때마다 약 5초 정도의 시간을 버리고 있었습니다.
이 경우도 Routing을 다른 모듈로 분리시키는 형태로 쉽게 해결할 수 있습니다.

증분빌드 속도를 모듈화 과정에서 고려한다면..

모듈화를 진행할 때 증분 빌드 속도를 고려한다면 어떻게 모듈을 설계할 수 있을지 위에서 언급된 Network모듈에서 Routing을 분리한다는 시나리오를 예로 들어보겠습니다. fromm 프로젝트에는 데이터 로직을 담당하는 모듈이 여러개 있습니다.

• 채팅과 관련된 데이터 로직을 담당하는 모듈
• 유저와 관련된 데이터 로직을 담당하는 모듈
• 아티스트와 관련된 데이터 로직을 담당하는 모듈
• 위 모듈들이 공통적으로 의존하고 있는 것들을 모아놓은 모듈
  

등이 있을 수 있겠네요. 만약 Routing을 공통적으로 의존하는 모듈에 다 모아놓는다면 아래와 같이 작업이 진행될 수 있습니다

BaseDataModule
    | Routing
        | Artist
        | Chat
        | User

라우팅 관련된 것들이 모여있어서 한눈에 보기 쉽다는 장점이 있지만 증분빌드 측면에서는 Routing 추가 시 모든 데이터로직 관련 모듈들이 다 증분빌드가 되는 단점이 있습니다. 증분빌드의 최적화가 우선되는 가치라고 생각된다면 다음과 같은 의사결정도 있을 수 있죠.

ArtistDataModule
    | Routing

ChatDataModule
    | Routing

UserDataModule
    | Routing

증분빌드만 고려한다고 가정하고 User와 관련된 Routing만 분리 후 아래와 같은 수정을 거치고 빌드를 해보았습니다

enum UserRequest {
    case getUserDatav2

    var path: String {
        switch self {
            case .getUserDatav2:
            ...
        }
    }    
}

증분 빌드에 소요된 시간은 3.5초로 기존의 3분의 1정도로 줄어든 것을 볼 수 있었습니다.

마치며

운영중인 앱의 구조를 개선하는 과정이 결코 순탄치 않아서 생각보다 모듈화 과정이 길어지고 있는 것 같습니다. 많은 논의도 거쳐야하고 지금 fromm에 가장 알맞다고 생각되는 레퍼런스를 찾아 공부하는 과정도 시간이 꽤나 소요가 큰 것 같습니다.
그래도 팀원들과 같이 즐겁게 공부와 공유를 진행하며 앱을 만들어가고 있어서 마냥 지루하지만은 않은 것 같다는 생각이 듭니다.
빨리 프로젝트의 모듈화를 완료하여서 이런 저런 것들이 좋아졌습니다!하고 보여드릴 날이 오기를 기대해봅니다.

부족하지만 긴 글 읽어주셔서 감사합니다.