저는 주로 제공하고자 하는 서비스 단위로 모노레포를 구성하여 개발해 왔습니다. 예를 들어, 블로그와 관련된 백엔드 시스템, 유저 시스템, 관리자 시스템을 하나의 레포지토리로 묶었고, 수영 관련 서비스의 경우에도 스크래핑 시스템, 백엔드 시스템, 유저 시스템, 관리자 시스템을 하나의 레포로 관리했습니다.
제가 제공하는 서비스는 서버에게 많은 부하를 줄 만큼 복잡한 작업이 없습니다. AI 기능이 있긴 하지만, 실제 AI를 자체적으로 실행시키는 것이 아니라 외부의 AI에 필요한 정보를 요청하여 얻어오는 방식이기에, 우리 서버가 직접적으로 힘든 일을 감당할 필요는 없는 상황입니다.
기껏 해봐야 데이터를 가져와 오늘 날짜와 대조하는 정도이며, 복잡한 가공 처리를 하지 않고 필요한 정보를 제공해주는 것이 제가 만든 몇 안 되는 서비스들의 전부입니다. 서비스 자체가 복잡하지 않다 보니, 기능 특화를 위해 프로그래밍 언어를 구별하거나 특정 프레임워크를 고집할 필요도 없었습니다.
물론 빅데이터 처리를 위해서는 TypeScript보다는 Python을 이용해야 한다고 이해하고 있습니다. 하지만 제 서비스에서는 그 정도로 데이터 가공에 심혈을 기울여야 하는 동작이 없습니다. 또한, 여러 프레임워크의 장단점을 구별할 만큼 다양하게 알고 있지 않아, 현재는 NestJS를 주력으로 활용하고 있습니다. 그래서 제가 운영하고 있거나 앞으로 운영하게 될 몇 안 되는 서비스들은 대부분 동일한 기술 스택을 가지고 있는 상황입니다.
제가 제공하고 있는 서비스는 아직까지는 많은 사용자가 이용하고 있지 않은, 트래픽 유입이 적은 서비스입니다. 대용량 트래픽 부하에 미리 대비한 개발을 하는 것이 현명한 접근임에는 분명하지만, 당장 태풍이 올 가능성이 1년 내로는 적다면, 굳이 지금부터 더 굳건하게 대비하는 것은 과한 것 같다는 생각이 들었습니다.
이러한 여러 생각들을 종합해보니, 블로그 시스템과 수영 시스템을 굳이 MSA로 구별하여 배포할 필요는 없다고 판단했습니다. 물론 블로그 시스템의 부하가 수영 시스템에 영향을 주거나, 그 반대의 상황이 발생할 수도 있겠지만, 여러 서비스를 하나로 뭉쳤을 때 그런 고민을 하게 되는 순간은 오히려 행복한 고민일지도 모른다는 생각이 듭니다. 간단한 기능을 가진 제 시스템이 대량의 요청으로 인해 발생하는 문제들을 고민하게 된다면, 그것은 곧 제 서비스를 많이 사용해주고 있다는 뜻일 테니까요.
물론 웹 브라우저에 보여지는 프런트엔드 부분들은 구별이 필요하겠지만, 뒷단 서버에게 요청하는 부분은 충분히 통합할 수 있겠다고 판단했습니다. 별다른 기능도 없는데 NestJS 서버를 두 개 띄우느라 불필요한 리소스를 할애하기보다는, 하나의 NestJS 서버에서 여러 요청들을 감당할 수 있도록 하는 것이 더 효율적이라는 생각이 들었습니다.
이러한 고민을 하는 것은 단순히 개발의 편의성 때문만이 아닙니다. 새로운 서비스를 배포하기 위해 컴퓨팅 자원을 매번 구성해야 하는 번거로움과 더불어, 그것들이 모두 직접적인 비용으로 이어지기 때문입니다.
세상은 좋아져서 어느 정도 작은 규모의 서비스는 평생 돈을 내지 않고도 제공할 수 있도록 지원해주는 클라우드 회사가 존재합니다. 저는 큰 뜻을 가지고 공격적으로 사업을 할 아이디어가 아직 없기 때문에, 최대한 비용을 지불하지 않고 제가 필요한 웹 서비스를 만들어가는 방향을 지향하고 있습니다. 그래서 현재의 모놀리식 아키텍처 선택은 저의 개인적인 목표와 효율성을 위한 합리적인 결정이라는 생각이 듭니다.