한때 우리는 모놀리식을 버려야 한다고 배웠다.
거대한 단일 애플리케이션은 느리고, 확장하기 어렵고, 배포가 고통스럽다고 했다.
그리고 마이크로서비스가 등장했다.
작게 나누고, 독립적으로 배포하고, 필요한 만큼만 확장하는 구조.
모든 문제가 해결될 것처럼 보였다.
하지만 몇 년이 지나자 분위기가 달라졌다.
이제는 이런 말이 들린다.
“마이크로서비스는 생각보다 훨씬 복잡하다.”
왜 이런 일이 벌어진 걸까.
모놀리식의 가장 큰 문제는 높은 결합도였다. 코드가 하나로 묶여 있고, 작은 수정에도 전체를 다시 배포해야 했다. 팀이 커질수록 충돌은 잦아졌고, 특정 기능만 확장하고 싶어도 애플리케이션 전체를 스케일해야 했다.
기술이 낡아서라기보다, 서비스와 조직이 커지면서 감당하기 어려워진 것이다. 그래서 우리는 쪼개기 시작했다.
마이크로서비스는 구조적 자유를 제공했다. 서비스 단위로 독립 배포가 가능했고, 팀별로 기술 스택을 선택할 수 있었으며, 필요한 기능만 따로 확장할 수 있었다. 장애도 격리할 수 있었다. DevOps 문화와 컨테이너 기술, 쿠버네티스 환경은 이러한 변화를 더욱 가속화했다.
하지만 우리는 한 가지를 과소평가했다. 모놀리식을 단순히 나눈 것이 아니라, 시스템을 분산 환경으로 바꿔버렸다는 사실이다.
마이크로서비스 복잡성
분산 시스템은 본질적으로 복잡하다. 네트워크 지연이 생기고, 일부 서비스만 실패하는 부분 장애가 발생하며, 데이터 일관성을 유지하기 어려워진다. 같은 프로세스 안에서 함수 호출로 해결되던 일이 이제는 네트워크 요청이 된다. 이 차이는 생각보다 크다.
초기에는 서비스가 분리되면서 코드 구조가 깔끔해 보인다. 하지만 운영 단계에서 복잡성은 급격히 증가한다. 로그는 여러 서비스에 흩어지고, 장애의 원인을 추적하기가 어려워진다. 배포 파이프라인은 서비스 수만큼 늘어난다. 그 결과로 관측성 도구, 서비스 메시, API 게이트웨이 같은 또 다른 계층이 추가된다.
단순함을 얻기 위해 시작했지만, 우리는 더 많은 인프라와 추상화를 얻게 되었다.
그렇다면 다시 모놀리식으로 돌아가야 할까. 최근에는 모듈형 모놀리식이나 처음에는 모놀리식으로 시작하자는 전략도 다시 주목받고 있다. 이것은 실패의 신호라기보다, 아키텍처에 대한 이해가 성숙해졌다는 의미에 가깝다.
아키텍처는 유행의 문제가 아니다. 조직 규모와 도메인 복잡도, 그리고 운영 역량의 문제다.
팀이 작고 도메인이 단순하다면 모놀리식이 더 적합할 수 있다. 반대로 팀이 여러 개로 나뉘고 도메인 경계가 명확하며, 독립적 배포와 확장성이 중요하다면 마이크로서비스가 어울린다.
결국 핵심은 기술이 아니라 우리가 감당할 수 있는 복잡도의 크기다. 분산 시스템을 운영할 준비가 되어 있지 않다면, 마이크로서비스는 자유가 아니라 부채가 된다.
모놀리식이 무너진 것은 기술이 낡아서가 아니라 우리가 더 커졌기 때문이다. 마이크로서비스가 복잡해진 것도 우리가 더 많은 문제를 해결하려 했기 때문이다.
그래서 마지막 질문은 이것이다.
우리는 이 복잡성을 감당할 준비가 되어 있는가.