Monolith

팀 규모가 세 명에서 열다섯 명으로 늘면, 같은 코드베이스에 사람이 많아질수록 릴리스가 느려집니다. 기능 하나를 고치면 전체 테스트를 돌려야 하고, 배포 한 번에 여러 팀의 변경이 함께 나가야 합니다. 결제 기능만 빠르게 배포하고 싶어도 상품 조회와 묶여 있으면 따로 낼 수 없습니다. 트래픽이 결제 쪽에 몰려도 전체 애플리케이션을 확장해야 합니다. 결제 서비스에 장애가 생기면 상품 조회까지 영향을 받습니다. 이 압력이 커지는 시점이 Monolith의 한계가 드러나는 시점입니다.

많은 제품은 처음부터 거대한 분산 시스템으로 출발하지 않습니다. 팀이 작고 도메인 경계가 아직 불분명할 때는 하나의 코드베이스에서 빠르게 배우는 것이 더 현실적입니다. Monolith는 낡아서 남아 있는 구조가 아니라, 속도와 단순함이 중요할 때 자주 선택되는 기본 형태입니다. 문제는 규모가 커진 뒤에도 같은 방식이 계속 맞는지는 별개의 질문이라는 점입니다. 처음의 선택이 맞았어도, 팀과 기능이 달라진 뒤에는 다시 판단해야 합니다.

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

Monolith와 Microservices는 둘 다 실제 서비스를 구현하는 애플리케이션 구조입니다. 차이는 배포 단위에 있습니다. Monolith는 주문, 결제, 사용자 기능이 같은 프로세스 안에서 돌아가고 한 번에 배포됩니다. Microservices는 각 기능이 별도 프로세스로 분리되어 독립적으로 배포됩니다. 팀이 작고 도메인 경계가 아직 불분명할 때는 Monolith가 낫습니다. 네트워크 오버헤드 없이 함수를 직접 호출하고, 트랜잭션도 단순하게 유지됩니다. 반면 특정 기능만 독립적으로 확장하거나 배포해야 하는 압력이 생기면 Monolith의 단일 배포 구조가 걸립니다. 그 시점이 구조를 재검토할 때입니다.

프로덕트를 처음 만드는 팀이 선택하는 기본 구조입니다. 도메인을 어떻게 나눌지 아직 모를 때, 하나의 코드베이스에서 빠르게 실험하고 배우는 것이 분산 시스템을 운영하는 것보다 현실적입니다. 로컬에서 명령어 하나로 전체 시스템을 띄우고 디버거를 붙일 수 있다는 것은 작은 이점이 아닙니다. 팀이 커지고 서비스가 안정화된 뒤에도 Monolith로 남는 경우가 많습니다. 운영 복잡도를 올릴 만큼 독립 배포가 중요해지지 않았다면 나눌 이유가 없습니다. 문제가 드러나는 신호는 팀 경계와 코드 경계가 충돌하는 시점입니다. 여러 팀이 같은 파일을 자주 수정하거나, 특정 기능의 배포를 다른 팀이 기다려야 할 때입니다.