배경

지난 25년 9월부터 스팟의 리뉴얼 서버를 혼자 개발하게 됐다. 가장 먼저 했던 고민은 “어떤 아키텍처로 시작하는게 가장 합리적일까?” 였다. 아키텍처는 단순한 구조 선택이 아니라 이후의 개발 생산성, 유지보수성, 확장 전략을 모두 결정짓는 요소다. 이번 포스트를 통해서 고민했던 과정과 선택한 이유에 대해 공유하고자 한다.

참고로, 스팟 팀의 목표 DAU는 약 10,000명으로, 수도권 대학생 중 약 1%를 타겟으로 잡고 프로젝트 설계를 진행했다. 또한 폭발적으로 성장할 수 있는 상황 역시 고려하여 아키텍처를 선택했다.

선택지

크게 모놀리식, MSA, 모듈러 모놀리식 아키텍처, 총 3가지의 선택지를 고려했다.

모놀리식 아키텍처

먼저 모놀리식 아키텍처다.

기존 서버는 모놀리식 아키텍처로 구성 되어 있었기 때문에 가장 먼저 고려했던 선택지다. 아무래도 혼자서 개발해야 하기 때문에 배포 단순성, 개발 편의성 등 여러모로 얻을 수 있는 이점이 많았다.

하지만 기존 서버를 운영 및 개발하는 과정에서 각 서비스 간 과한 의존으로 인해서 특정 서비스에서 발생한 장애가 다른 서비스에 영향을 미치는 경우가 잦았고, 코드의 흐름을 파악하는데 어려움이 많았다. 리팩토링을 하거나 테스트 코드를 작성하면서도 의존성이 불필요하게 많이 엮여있어서 많은 시간이 소요되곤 했다.

그래서 이번에는 이런 문제점들을 해결할 수 있는 아키텍처에 대한 갈증이 있었고, 모놀리식 아키텍처는 배제하는 방향으로 선택했다.

마이크로서비스 아키텍처(MSA)

다음으로 고려한 선택지는 마이크로서비스 아키텍처다.

모놀리식 아키텍처로 개발 및 운영하면서 겪었던 페인 포인트를 해결할 수 있는 아키텍처라고 판단했다. 각 서비스 간 직접적인 의존을 피할 수 있고, 장애 전파로부터도 안전한 아키텍처다. 또한 특정 서비스만 선택적으로 확장할 수 있기 때문에 서비스가 성장하는 과정에서도 유리한 선택지가 될 수 있다.

그러나 스팟 팀의 현재 상황에서는 단점이 더 크게 다가왔다.

각 서비스를 독립적으로 배포해야 하기 때문에 배포 복잡도가 크게 상승한다. 또한 MSA에 대한 경험이 없는 상태기 때문에 학습 비용도 높았고, 각 서비스 간에는 네트워크를 통해 통신하기 때문에 개발 및 디버깅 비용도 크게 증가한다. 인프라 비용 역시 각 서비스를 독립적으로 배포해야 하기 때문에 크게 발생한다.

또한 스팟 팀이 목표로 한 사용자 수를 고려 했을 때도 MSA는 오버 엔지니어링이라고 판단했다.

모듈러 모놀리식 아키텍처

마지막으로 고려한 선택지는 모듈러 모놀리식 아키텍처다.

모듈러 모놀리식 아키텍처는 배포 단위는 하나로 유지하여 운영 비용을 낮추면서도, 코드 수준에서는 도메인 간 강한 격리를 통해 MSA의 장점을 취할 수 있다는 특징이 있다. 추후 서비스가 크게 성장하는 경우에도 MSA로 확장 하는 것 역시 유리하다.

즉, 모놀리식의 배포 단순성과 MSA의 도메인 분리와 책임 명확성 을 동시에 취할 수 있는 절충안이었다.

하지만 모듈 간 직접적인 의존이 기술적으로 완전히 차단되지는 않기 때문에 단순 모놀리식 보다는 초기 패키지 구조 설계나 의존성 관리에 대한 엄격한 규율 설정이 필요했다.

결과적으로, 확장성/유지보수성/모듈 간 독립성 등 다양한 요소들을 고려 했을 때, 모듈러 모놀리식 아키텍처가 가장 현재 스팟에 적합한 구조라고 판단했다.

적용 방식

스팟에서는 모듈 간 직접적인 구현 의존을 지양하고 반드시 API(포트 인터페이스) 를 통해서만 의존하도록 설계했다. 이를 통해 모듈 내부 구현 변경이 외부에 영향을 미치지 않도록 하고 향후 서비스 분리를 고려한 구조를 유지하고자 했다.

또한 당장 서비스의 분리를 통해 독립적으로 운영할 필요는 없지만, 추후 확장이 필요한 상황이 생길 때 이를 대처하기 위해 분리하는 것은 늦다고 생각한다. 이번 기회에 리뉴얼 하면서 확장에 유리한 아키텍처를 적용하여 빠르게 대처할 수 있는 구조를 가져가는게 더 좋은 선택이라고 생각한다.