Marching Towards Monolithic Hell (통짜 구조로 인한 지옥으로 행진)

불행하게도 이런 간단한 접근 방법은 심각한 한계가 있다. Application이 성공적일수록 시간이 지나면서 점차적으로 크기가 커지게 된다. 각 단계별로 개발팀은 많은 코드를 추가하여 약간 더 많은 스토리를 구현하게 된다. 몇 년 후에는 초기에 작고 간단했던 application이 괴물처럼 커지게 될 것이다. 극단적인 예를 하나 들자면, 최근에 수백만 라인의 코드로 구성된 수천개의 JAR 사이에 있는 의존성을 분석하는 Tool을 개발하는 개발자와 이야기를 나눈 적이 있다. 그런 괴물을 만들어 내기 위해서 오랫동안 수많은 개발자들이 많은 노력을 들여 협조했을 것이라고 확신한다.

한번 Application이 커지고 나면, 개발 조직은 고통의 세상에 빠지게 된다. Agile 개발 방법론과 Delivery에 대한 어떤 시도도 허우적거리게 될 것이다. 커다란 문제 중 하나는 Application이 극도로 복잡해졌다는 것이다. 간단히 말하자면, Application이 너무 커서 한 명의 개발자가 전체를 이해할 수 없다. 결과적으로 버그 수정이나 새로운 기능을 개발하는 것은 어렵고, 시간이 오래 걸리게 되었다. 한술 더 떠서 아래쪽으로 향하는 소용돌이처럼 되기 쉽다. Codebase가 이해하기 어렵다면 원하는 대로 변경을 할 수 없다. 결국에는 괴물과 같은 이해하기 어려운 거대한 진흙 덩어리(Big Ball of Mud)에 직면하게 될 것이다.

방대한 규모(Sheer size)의 Application은 개발을 느리게 할 것이다. Application이 커질수록, 시작하는데 걸리는 시간은 길어진다. 예를 들면, 최근 조사에서 어떤 개발자들은 application을 시작하는데 12분이 걸렸다고 보고되었다. Application 실행하기까지 40분이 걸렸다는 일화도 들은 적이 있다. 개발자들이 application server를 재시동해야 한다면, 동작하기까지 오랫동안 기다려야 하고, 생산성은 악화될 것이다.

규모가 커졌을 경우 또다른 문제는 복잡한 monolithic application을 지속적으로 배포할 경우 장애물이 된다는 것이다. 오늘날 SaaS Application을 예술적으로 만들기 위해서 하루에도 몇번씩 제품에 변경을 가해야 한다. 복잡한 monolith application에는 이렇게 하기가 극도로 어렵다. 왜냐하면 일부 수정사항을 업데이트 하기 위해서 전체를 재배포 해야하기 때문이다. 앞서 언급한 application 실행 시간의 길이는 더 언급할 필요도 없다. 또한 변경에 따른 영향도를 일반적으로 파악하기 어렵기 때문에 어마어마한 수동 테스트를 해야할 것이다. 따라서 지속적인 배포는 다음 작업을 불가능하게 할 것이다.

Monolithic application은 다른 모듈간에 서버의 자원 사용에 대한 충돌이 발생했을 때 확장하기 어렵다. 예를 들면, CPU를 집중적으로 사용하는 이미지 처리를 하도록 구현된 하나의 모듈이 Amazon EC2에 최적화된 instance에 배포되어 있고, 또다른 모듈은 In-Memory 데이터베이스를 사용하고, EC2 메모리 최적화 instance에 적합할 경우, 이러한 모듈들이 하나의 Application에 함께 배포되어 있기 때문에 하드웨어 선택에 있어서 타협을 해야만 한다.

Monolithic Application의 또다른 문제는  신뢰성(reliability)이다. 모든 모듈들이 동일한 프로세스 내에서 동작하기 때문에 어떤 모듈에 메모리 누수(memory leak)와 같은 버그가 있을 경우, 잠재적으로 전체 프로세스가 다운될 수 있다. 더욱이 application의 모든 instance가 동일하기 때문에 그런 버그는 전체 application의 가용성(availability)에 영향을 줄 것이다. 마지막으로, 그렇지만 앞에 이야기한 것과 마찬가지로 중요한 것은 monolithic application은 새로운 framework과 language를 받아들이기에 극도로 어렵다는 것이다. 새롭고 더 좋은 ABC framework을 사용하여 전체 application을 재개발하는 것은 시간적으로나 비용적으로나 굉장히 비싸다. 결과적으로 새로운 기술을 받아들이기에 거대한 장벽이 있다. 여러분이 처음 프로젝트 시작할 때 적용한 기술이 무엇이건 간에 새로운 기술을 받아들일 수 있는 여지가 없다.

요약하자면 : 만약 여러분이 괴물같이 거대한 통짜로 개발된 주요 비즈니스 application (business-critical application)을 가지고 있다면 개발자들은 거의 이해하기 어렵다. 재능이 뛰어난 개발자들을 고용하여 거의 쓸모가 없고, 비생산적인 기술들을 사용하여 어렵게 구현하게 된다. Application은 확장하기도 어렵고, 신뢰성도 떨어진다. 결과적으로 application의 agile 개발 및 배포가 불가능하다.

자, 그럼 이제 무엇을 할 수 있을까?