각 핵심서비스의 독립

대부분의 앱의 첫 출시는 내부의 기능과 콘텐츠들은 매우 심플하고 복잡하지 않습니다.

그러나 사업이 확장되고, 더 많은 서비스가 등장하고, 기존 시장과 더불어 블루오션을 찾기 위해서 앱은 다양한 서비스를 추가하게 됩니다. 이것은 나쁘다고 이야기하는 것이 아닙니다. 앱 개발자들에게는 마치 스타트업과 같이 앞에 펼쳐질 미래에 대해서 그려내기란 막연하다고 생각합니다.

앱이 출시되고 회사의 성장이 초기 때보다 점점 좋아지고, 앱 또한 다양한 서비스를 추가하여 업데이트하게 됩니다. 삶은 개구리 신드롬과 같이 서서히 앱은 기존에 설계되었던 아키텍처와 다르게 변화해가게 됩니다. 개발자 입장에서는 당연히 추가적인 기능을 개발하는 것에 그치지만 기획과 디자인 외부적인 마케팅 요소까지 추가하게 된다면, 내가 그린 그린 그림이 점점 카메라가 되어간다는 것을 눈치채기란 힘들 수밖에 없습니다. 앱의 성장은 서서히 진행되는 경우가 대부분이기 때문입니다.

앱은 어느덧 시간이 지남에 따라 다양한 서비스들이 추가되고, 기존 아키텍쳐로는 감당이 안 되는 상황이 오게 됩니다. 그와 더불어 엔터프라이즈 앱에 대한 새로운 기술과 다양한 이론들이 매년 엄청나게 쏟아져 나옵니다. 일단 먼저 새로운 것을 수용하기 이전에 우리 서비스를 다시 한걸음 이상 멀리 떨어져서 숲에 대한 고민해볼 필요가 있었습니다.

먼저 핵심서비스의 대한 정의를 한번 해보았습니다.

  • 회원 인증 서비스 : 로그인, 회원가입, 로그아웃
  • 사용자 어카운트 서비스: 사용자 프로필, 환경 설정, 푸시 설정, 지불정보 등 다양한 사용자 정보
  • 대시보드 : 대시보드는 웹의 인덱스 페이지와 동일 합니다. 다양한 정보를 앱 실행 시 다양한 서비스를 전시하는 서비스 입니다.
  • 이벤트: 딥링크, 웹이벤트 등 다양한 이벤트를 관리합니다.

여기서는 다양한 회사의 공통적인 서비스만 언급하였지만, 회사마다 추가적인 서비스들은 언급하지 않겠습니다. 이 글을 읽는 독자분들께서도 비즈니스 관점에서 더욱 세분화하게 나눌 수 있을 것이라고 믿습니다.

미리 그려본 Diagram 입니다.

먼저 각 패키지를 만들어봅시다. 각 패키지는 SPM init을 통해 만들었으며, iOS에서 사용할 수 있도록 Package에 추가적인 작업을 하였습니다.

각 패키지 모듈인 Feature의 구성도입니다

Tuist 라는 라이브러리를 사용하여, 위에서 정의한 다이어그램을 구현하였습니다.

전제적인 프로젝트 그룹화

프로젝트의 전반적인 코드의 구성은 다음 링크에서 보실 수 있습니다.

이제 여러분들은, 세부적인 Feature(핵심서비스)를 나누고 해당 패키지에서 페이지를 생성하여 개발합니다. 이제 개발 프로세스와 관련된 이야기를 한번 해보도록 하겠습니다.

여러분들은 F라는 페이지를 개발하게 됩니다. F 페이지는 A -> B -> C -> D -> E -> F라는 페이지를 거쳐서 개발하게 된다면, 매번 F 페이지에 대한 디버깅할 때 시간을 불필요하게 사용한다고 생각해본 적이 있을 것입니다. Preview에서 앱의 메인페이지를 수정하더라도 현재 출시된 앱에는 영향이 없기 때문에 빠르게 F로 이동할 수 있는 퀵 버튼을 만들어서 바로 볼 수 있도록, 일종이 개발하는 데 있어서 시간 절약을 도와주는 도움 앱이라고 보시면 될 것입니다. 이외에도 다양한 편의성을 위해 만든 개발자용 앱이지만, 각 회사 또는 사이드 프로젝트에서는 다양한 아이디어를 가지고 활용할 가치는 충분하다고 봅니다.

다음 시간에는 클린 아키텍쳐 (공통 모듈)이라는 주제로 블로그 기고하도록 하겠습니다. 감사합니다.

0 Shares:
You May Also Like
Read More

SwiftUI 기반 MVI(TCA) 아키텍쳐

일단 여기서 언급하는 아키텍쳐는 클린아키텍쳐도, 모듈 기반 아키텍쳐도 아닌, 별개로 보셔도 됩니다. 먼저 안드로이드와 iOS의 비즈니스 로직을 동일하게…