[모듈화] 프로젝트에 모듈화를 진행하면서

 

현재 진행중인 프로젝트에 Tuist를 도입을 진행한 후 대규모적인 구조 개편을 진행 할 수 있는 환경이 프로젝트내에 만들어져 본격적으로 모듈화를 진행을 할 수 있게되었다.

 

모듈화를 진행하게된 이유는 현재 진행하고있는 프로젝트의 iOS 개발자들의 수도 늘어나게되고 앱이 점점 거대해짐에 따라 한번에 프로젝트 전체를 파악하기에는 큰 무리가 있고 개발을 진행할때 걸리는 제약들이 너무많아 전체적인 개발속도, 안정성등이 떨어져 이 해당부분을 보완하기위해 모듈화를 진행하게되었다.

 

처음부터 모듈화를 하지 않고 추후에 리팩토링을통해 모듈화가 진행된 이유는 처음에는 현재 프로젝트의 앱이 이렇게 큰 규모의 앱이 아니였고 iOS 개발자들의 수가 급격하게 늘어난것도 1년정도 되지않았기 때문에 모듈화의 필요성이 따로 없었다.

왼쪽의 사진을 보게되면 물건의 수가 적을때는 오히려 한번에 펼쳐놓는것이 사람들이 보기에 편한 정리방법이 되겠지만

오른쪽 전선사진을 보게되면 점차 선의 수가 많아지고 규모가 커짐에 따라 정리가 필요해짐을 느끼게 되어 모듈화를 진행하게되었다.

 

현재 프로젝트내에 모듈화를 진행하게된지는 약 반년정도 진행이 되었고 현재도 아직 많이 부족한 상태이지만 적어도 추가되는 피쳐들을 모듈화 하기에 불가능하지않은 구조로 현재 작업이 되어있다.

 

모듈화를 진행하자고 하였을때 많은 팀원들이 요즘 핫한 모듈화에 대해 관심이 많았기 때문에 동의를 받는것은 그렇게 어려운 일이아니였다.

 

모듈화 작업을 계획을 하고 구조를 잡을때 가장 큰 일정은 현재 상용에서 상당히 잘 돌아가고 있는 앱의 전반적인 구조를 왜 변경해야하는지를 윗사람들을 설득하는 일, QA조직에게 혹시나 있을 크래쉬 상황을 대비하기위한 QA일정 요청과 같은 우리팀 내부적인 문제가아닌 팀 외부적인 문제들을 먼저 해결을 하고 진행을 해야했다.

 

외부적인 문제들이 해결이 되고 프로젝트의 전반적인 모듈화가 진행이 되었는데, 시작부터 순조롭지 않았다.

기존의 프로젝트에 작게나마 모듈화가 되어있었던게 오히려 발목을 잡았다. 모듈화의 근본이되고 앱의 근본이 되는 DataLayer영역이 각 모듈에 흩어져있는게 모듈화의 발목을 붙잡았고,  그 이외의 여러가지 제약들이 걸려있었는데 아래의 처럼 모듈간의 의존성이 상당히 높은 상태였다 정도로 이해하면 될 것 같다.  

그래서 이 모든 제약들을 한번에 개선하기에는 불가능하다고 판단하여 하나씩 뜯어내기위해 작업의 근본이 되는
클린아키택처 기준 Entity(Business Model)을 가장 선행해서 작업하기로 협의가되었고 바로 모듈화 작업이 시작되었다.

 

 

Entity(Business Model)을 한곳에 모으고 빌드해서 테스트하고, 전체적인 구조를 어떻게 만들지, Tuist 셋팅은 어떻게해줘할지에 대한 고민들도 정말 많았지만 가장 큰 문제는 내가 모듈화 하려는 앱은 현재 상용에서 여러 팀원들이 피처개발이 이뤄지고 있다는 사실이다.

 

새로운 피처들이 개발을 하게 되면 새로운 모델타입도 생기게되고 해당 모델들을 내가 작업하던 모듈화 브렌치에 계속해서 머지해야하는 이슈가 생기고, 내 모듈화 피처가 머지가 되고나면 개발을 진행하고 있던 피처들이 내 작업물을 머지해서 모듈화 기반으로 작업이 이뤄져야하는데 해당 과정들에서 생기는 깃 컨플릭들과 개발자들간의 의사소통문제, 어떤 브렌치를 먼저 머지시킬지에대한 팀원들의 이야기가 정말 많이 이뤄졌고, 약 1 ~ 2 달정도의 작업시간과 약 2주정도의 QA기간을 거쳐 현재 진행중인 프로젝트의 근본이 되는 Entity(Business Model) 이 상용앱에 출시가 되었고 현재까지 아무런 무리없이 크러쉬율 증가없이 상용에서 앱이 잘 구동되어 모듈화가 다음스탭으로 진행하게되었다.