컴포넌트 식별/구성과 빌드 프로세스, 그리고 의존관계

SW 아키텍처에서 최소한의 빌드 단위를 결정하는 것은 이제 중요한 이슈이다. 현재의 SW 아키텍처에서 빌드 단위는 하나의 애플리케이션 (자바의 경우 war) 단위 안에 물리적으로 모든 소스 코드를 위치하는 형태로는 잦은 비즈니스의 변화와 이에 따르는 응대를 하기란 쉽지 않기 때문에 재사용 가능한 단위의 컴포넌트를 최대한 많이 그리고, 최대한 확장 가능한 형태로 구성해야 한다. 이러한 컴포넌트를 식별하고 구성하는 행위들은 궁극적으로 빌드 단위에 영향을 미치게 되며, 이는 빌드 프로세스에 직접적으로 영향을 미친다.

컴포넌트는 재사용 단위를 높이고 의존관계를 최대한 느슨한 형태로 구성하게 되지만, 이는 그 말 자체가 균형을 이루기 힘든 상태임을 알 수 있다. 재사용 단위를 높이는 것은 궁극적으로 컴포넌트의 의존관계의 비율이 높아질 수 밖에 없으며, 이는 빌드 프로세스를 독립적으로 구성하기가 어렵다는 것을 의미한다. 의존관계를 최대한 느슨하게 유지하려면 결국 비즈니스 로직의 재사용성을 최대한 낮추도록 유지시키며(최대한 독립된 기능으로 구획화시키며) 각 영역에 대한 책임성을 명확하게 정의해야 한다.

즉, 컴포넌트의 생성과 개별 컴포넌트의 관계는 빌드 프로세스를 통해서 영향을 받을 수 밖에 없으며, 서로 조정하면서 궁극의 시스템을 만들어 나가아야 한다. 이러한 체계는 CI(Continuous Integration)를 도입해서 컴포넌트의 변화에 따라서 빌드 프로세스를 조정해야 함을 의미하며, 빌드 프로세스의 조정으로 컴포넌트의 의존관계들은 설계된 내용과는 또 다른 형태로 진화할 수 밖에 없다.

예를 들어, 어떤 기능이 외부 기관에서 제공하는 인터페이스를 통해서 서비스를 제공한다고 하자. 외부 기관과의 인터페이싱은 다양한 이슈를 만들어내기 때문에 최대한 독립적인 모듈(컴포넌트)로 구성하기를 원한다. 하지만, 이러한 외부 시스템과의 연계가 한 기능의 여러 지점에 나타나는 형태로 나타난다고 할 때 이러한 연계 기능은 독립된 형태의 컴포넌트로 분리하기가 쉽지 않다. 다른 말로 하면, 외부 시스템 연계 기능은 독립된 빌드 프로세스를 만들기가 힘들다는 것이다. 만일, 외부 시스템 연계 기능을 독립된 빌드 프로세스로 만들었을 때에 그 이점은 고스란히 아키텍처의 품질에 영향을 미칠 수 있다. 외부 시스템은 테스트나 트랜잭션에 관련되어서 많은 문제를 가지고 있기 때문에 이러한 지점을 독립적인 빌드 프로세스를 만들고, 여기에 다양한 부가 빌드 프로세스를 생각해볼 수 있다. 예를 들어, 외부 시스템의 스텁을 만들어놓고 빌드시 테스트를 추가해볼 수도 있을 것이다. 즉, 독립적인 개별 빌드 프로세스를 생성할 수 있게 된다면 전반적인 시스템의 품질은 향상시킬 수 있는 장치를 부가할 수 있다는 것이다.

결론적으로, 컴포넌트의 식별 및 구성은 빌드 프로세스에 영향을 미치며 (빌드 프로세스의 조정이나 변화가 필요하며) 이는 컴포넌트의 의존관계와 밀접한 관계를 가진다. 컴포넌트 의존관계가 변화할수록 빌드 프로세스 역시 같이 변화가 되어야 하며, 이는 CI 를 통해서 전반적인 시스템의 품질을 향상시킬 수 있다.

컴포넌트의 물리적인 구조를 변화하는 것만으로도 전체적인 시스템의 품질을 향상시킬 수도 있지만, 이러한 작업이 많은 시간을 요하기 때문에 짧은 시간에는 시스템의 빌드 프로세스를 조정하는 것만으로 시스템의 품질 향상에 많은 향상일 꾀해볼 수도 있다. 하지만, 이는 근본적인 시스템의 문제를 해결하는 것보다는 표면적인 현상을 해결하는 형태이기 때문에 근본적인 컴포넌트의 구조에 대한 개선을 필요로 한다. 빌드 프로세스는 단순히 제품화되는 컴포넌트에 대한 빌드만을 포함하는 것이 아니라, 테스트나 품질 검사와 같은 부가적인 프로세스를 추가하여 이를 최대한 활용하는 것도 중요하다.

특히, 주요 프로세스에 대한 테스트 (스모크 테스트와 같은) 는 배포를 위한 빌드 프로세스 내에 포함시키기에는 시간이 걸리는 작업이기에 이를 독립적인 별도의 빌드 프로세스로 구성하여 소스 코드의 변경으로 인한 영향도를 정기적으로 점검해볼 수도 있다. 시스템의 구성이 단순한 비즈니스 로직의 덩어리로 존재하는 형태보다는 보다 체계적이고 의미있는 로직의 구획화 작업을 필요로 하며, 이는 분석/설계 단계에서 식별된 큰 덩어리보다도 더 세밀한 형태로 구현/테스트 시점에 나타나게 되며, 오히려 이 단계에서 식별/생성되는 덩어리들이 더 큰 영향을 미치게 된다.

이러한 컴포넌트 식별/구성이 빌드 프로세스와 밀접하게 연결되어 있지 않다면, 통합시점에 더 많은 문제와 이슈로 개발 기간의 지연 상태를 가지고 오게 되며, 시스템의 변화에 대해 민첩하고 신속하게 대응하기가 쉽지 않다. 특히, 이러한 변화는 개발 형태의 변화도 필요로 하기 때문에 소스 코드를 작성하는 시점에서부터 빌드와 배포까지를 염두해두지 않으면 안된다.