배포 크기와 컴포넌트 크기

일반적으로 배포를 하는 시점에서는 다양한 자원들이 관여됩니다. DB 관점은 제외하더라도 Web 애플리케이션과 관련된 것만 보면, 화면에 관련된 자원들이 있으며 (html을 비롯한 이미지, 동영상, jsp 등), 비즈니스 로직을 처리하는 자원들(.class, .jar, .war, .ear 등)과 다양한 설정 파일(.xml, .properties 등)들이 있습니다.

이러한 배포 대상들은 종류에 따라서 배포되는 위치가 달라질 수도 있으며, 동일한 서버를 서로 다른 IP 주소로 운영할 경우에는 동일한 파일이라도 그 내용이 조금씩 차이가 발생할 수 있습니다. 따라서, 배포는 파일의 종류가 다양할수록, 그리고 운영하는 서버가 다양해질수록 상당히 시간이 걸리고 힘든 작업이 됩니다.

특히, class 단위로 배포하는 경우에는 배포 프로세스에 상당한 부하가 발생될 수 있습니다. 배포는 가급적 적정한 수준의 크기를 유지할 필요가 있으며, 그 단위는 컴포넌트 단위로 배포를 하는게 적당한 크기라고 봅니다. 즉, 개발에 앞서서 컴포넌트의 크기를 어느 정도 수준으로 유지할지를 결정해야 하며 (컴포넌트 정의, 컴포넌트 유형, 컴포넌트 내부구조 등) 그 단위로 관리를 하는 것이 효과적입니다.

과거의 시스템들은 이러한 컴포넌트 단위를 명확하게 하는 (구현) 장치들이 부족한 것이 사실이며, 그에 따라 class 단위로 배포했었습니다. 하지만, 지금은 컴포넌트로 묶을 수 있는 장치들이 많이 있으며, 그 중에서 가장 보편적으로 많이 사용되는 개발환경 도구로 maven을 꼽을 수 있습니다.

maven은 분석/설계 과정에서의 컴포넌트 개념을 구현에서의 물리적인 컴포넌트와 매핑을 할 수 있는 도구로 활용이 가능한데, 구현관점에서 하나의 maven 프로젝트를 하나의 컴포넌트로 매핑해볼 수 있습니다. 즉, 분석/설계 과정에서 고객(Customer)라는 컴포넌트가 식별/설계되었다면, Customer 라는 maven 프로젝트를 만들어서 이를 구현할 수 있습니다. 하지만, 고객이라는 개념에는 수많은 비즈니스 로직을 고려해볼 수 있기 때문에 하나의 컴포넌트 개념을 하나의 maven 프로젝트로 매핑하는 경우, 상당한 비즈니스와 수많은 의존관계를 유발시킬 수도 있습니다.

maven 프로젝트는 상속이라는 개념을 가지고 있기 때문에 하나의 컴포넌트는 물리적으로 n개의 maven 프로젝트로 나뉠 수 있습니다. 즉, 고객(Customer) 컴포넌트는 분석/설계시에는 하나의 컴포넌트 내에서 다양한 내용이 설계되지만, 그 내부 내용에 있어서는 인터넷고객(InternetCustomer), 내방고객(OfflineCustomer) 등으로 분리될 수 있으며, 이러한 고객 정보 역시 서로 다를 수가 있을겁니다.

일반적이고 다른 컴포넌트에서 사용되는 정보를 Customer에 위치하고, 인터넷 고객에 특수한 정보(혹은 행위)들과 내방고객에 특수한 정보들은 각각의 컴포넌트에 위치를 시킵니다. 이와 같이 하는 이유 중에 하나는 의존관계를 좀 더 가볍게 하기 위함도 있습니다. 예를 들어, 내방고객 정보를 필요로 하는 컴포넌트는 인터넷고객 컴포넌트의 변경과 상관없이 배포가 가능해야 할겁니다. 하지만, 하나의 Customer라는 컴포넌트에 이러한 모든 비즈니스를 처리하게 되면 상관없는 비즈니스 로직의 변경에 대한 영향력은 많아질 것입니다. 이러한 컴포넌트 세분화에 대한 내용은 기존 오픈소스(예를 들면, spring framework 등)를 참고하시면 이러한 추세를 보실 수 있을겁니다.

물리적인 컴포넌트인 하나의 maven 프로젝트는 그 안에 독립적으로 수행될 수 있는 컴포넌트와 관련된 모든 것들이 포함되어 있어야 합니다. 예를 들어, 해당 컴포넌트에서 DB 자원이나 기타 다른 자원을 사용하고 그에 대한 설정에 관련된 내용들은 모두 해당 프로젝트 내에 모두 위치하도록 합니다. 물론, 이러한 설정 중에는 배포의 위치에 따라서 혹은 환경적인 변화에 따라서 변경이 되는 부분에 있어서는 전역 환경 변수를 사용해서 외부에서 이를 통제할 수 있도록 구조화시켜야 합니다. 하지만, SQL을 독립적으로 분리할 수 있다고 하더라도 이러한 로직은 해당 컴포넌트 내에 위치하도록 설정하는 것이 좋습니다.

결론적으로, 배포는 컴포넌트 단위로 수행하는 것이 적당할 것이며, 이 컴포넌트는 물리적인 형태로는 n개의 maven 프로젝트와 매핑될 수 있을 겁니다. 이러한 분석/설계에서의 컴포넌트 개념과 물리적인 구현체의 컴포넌트 개념은 개발 초기부터 정의해야 하며, 이에 따라서 배포에 대한 절차에 영향을 미칠 수 있습니다.