[소프트웨어 아키텍처] 소프트웨어 개발/배포에 대한 고찰

개발

개발하기 힘든 시스템이라면 수명이 길지도 않고 건강하지도 않을 것이다. 따라서 시스템 아키텍처는 개발팀(들)이 시스템을 쉽게 개발할 수 있도록 뒷 받침 해야 한다.

팀 구조가 다르면 아키텍처 과련 결정에서도 차이가 난다. 일례로 팀이 개발자 다섯 명으로 구성될 정도로 작다면, 잘 정의된 컴포넌트나 인터페이스가 없더라도 서로 효율적으로 협력하여 모노리틱 시스템을 개발 할 수 있다. 사실 이러한 팀이라면 개발 초기에는 아키텍처 관련 제약들이 오히려 방해가 된다고 여길 가능성이 높다. 수많은 시스템에서 좋은 아키텍처가 결여된 이유는 바로 이 때문 이다. 다시 말해 이런한 팀은 아키텍처 없이 시작하는데, 팀 규모가 작은 데다가 상위 구조로 인한 장애물이 없기를 바라기 때문이다.

다른 한편으로 일곱명씩으로 구성된 총 다섯 팀이 시스템을 개발하고 있다면 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다. 다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 다섯 개의 컴포넌트로 발전될 가능성이 높다.

이러한 ‘팀별 단일 컴포넌트’ 아키턱처가 시스템으로 배포, 운영, 유지보수하는데 최적일 가능성은 거의 없다. 그럼에도 여러 팀이 순전히 일정에만 쫓겨 일한다면, 결국 이 아키텍처로 귀착될 것이다.

배포

소프트웨어 시스템이 사용될 수 있으려면 반드시 배포 할 수 있어야 한다. 배포 비용이 높을수록 시스템의 유용성은 떨어진다. 따라서 소프트웨어 아키텍처는 시스템을 단 한번에 쉽게 배포할 수 있또록 만드는데 그 목표를 두어야 한다.

개발 초기 단계에서는 배포 전략을 거의 고려하지 않는다. 이로 인해 개발하기는 쉬울지 몰라도 배포하기는 상당히 어려운 아키텍처가 만들어진다. 예를들어 MSA로 개발을 한다고 가정하자 이 접근법을 사용하면 컴포넌트별 경계가 뚜렷해지고 인터페이스가 대체로 안정화되므로 시스템을 매우 쉽게 개발할 수 있다고 판단했을지도 모른다. 하지만 배포할 시기가 되면 위협적일 만큼 늘어난 수많은 마이크로 서비스를 발견하게 될지도 모른다. 마이크로서비스들은 서로 연결하기 위해 설정하고 작동 순서를 결정하는 과정에서 오작동이 발생할 원천이 스며들 수도 있기 때문이다.

만약 아키텍트가 배포문제를 초기에 고려했다면 이와는 다른 결정을 내렸을 것이다. 더 적은 서비스를 사용하고, 서비스 컴포넌트와 프로세스 수준의 컴포넌트를 하이브리드 형태로 융합하며, 좀 더 통합된 도구를 사용하여 상호 연결을 관리했을 것이다.