Monolith

기능이 적을 때는 한 애플리케이션 안에 모으는 편이 가장 빠를 수 있습니다. 하지만 기능 수가 늘면 릴리스 한 번이 전체 서비스 위험이 되고, 특정 기능만 따로 확장하기도 어려워집니다. 작은 변경도 전체 테스트와 전체 배포를 통과해야 하니 속도 병목이 생깁니다. Monolith는 단순함의 이점과 함께 이런 운영 압력을 같이 품는 구조입니다.

많은 제품은 처음부터 거대한 분산 시스템으로 출발하지 않습니다. 팀이 작고 문제 정의가 아직 흔들릴 때는 하나의 코드베이스에서 빠르게 배우는 편이 더 현실적입니다. 그래서 Monolith는 낡아서 남아 있는 구조가 아니라, 학습과 속도를 우선할 때 자주 선택되는 기본 형태이기도 합니다. 문제는 규모가 커진 뒤에도 같은 방식이 계속 적합한지는 별개의 질문이라는 점입니다.

Monolith 내부에는 주문, 사용자, 결제 같은 여러 모듈이 있을 수 있지만, 빌드와 배포에서는 하나의 산출물로 움직입니다. 모듈 간 호출이 프로세스 내부에서 일어나므로 네트워크 비용은 적고 디버깅 경로도 비교적 단순합니다. 대신 한 모듈의 변경이 전체 배포와 함께 움직이기 쉬워, 기술적 연결과 조직적 연결이 같이 강해집니다.

Monolith와 Microservices는 둘 다 실제 제품 기능을 구현하는 구조입니다. 차이는 경계가 프로세스 안에 머무르느냐, 네트워크를 사이에 두고 분리되느냐에 있습니다. Monolith는 처음에는 운영과 개발을 단순하게 만들 수 있지만, 독립 배포와 독립 확장이 중요해질수록 제약이 드러납니다.

제품 초기, 팀 규모가 작고 변경 속도가 중요할 때 Monolith는 강력한 기본값이 됩니다. 전체를 로컬에서 쉽게 띄우고 한 번에 디버깅할 수 있어 학습 비용이 낮기 때문입니다. 다만 팀 경계와 기능 경계가 커지면 릴리스 충돌, 느린 배포, 스케일링 불균형 같은 문제가 곧 운영 이슈로 드러납니다.

다음에 볼 개념

함께 보면 좋은 개념