비즈니스 로직의 진화와 아키텍처의 진화

SW 아키텍처는 SW를 지지하는 구조적인 측면에서 개발 초반에 어느 정도 확정이 된다면, 어느 시점까지는 해당 아키텍처 상의 SW를 지탱해줄 수 있는 여력이 만들어집니다. 개발 시점에는 비즈니스 로직의 변화가 제일 심하며, 이에 따라서 아키텍처 역시 같이 진화를 거듭하게 되며, 시스템 오픈 시점에는 SW 아키텍처가 운영을 할 수 있는 상태로 그 균형을 유지하게 만듭니다.

하지만, 운영시점에 있어서는 개발 기간 동안에 예기치 못했던 문제와 다양한 비즈니스 환경의 변화로 인해서 비즈니스 로직의 급격하지는 않지만, 서서한 변화를 겪게 됩니다. 여기에서 비즈니스 로직을 어떻게 변화시키느냐에 따라서 SW 아키텍처는 그 무게를 지탱할 수 있는지 혹은 변칙적인 변화를 수용해서 만들어진 SW 아키텍처의 원칙들이 하나 둘씩 무너지는지가 결정됩니다.

Landslips across the park have damaged roads and trails, 24 March 2011 by Parks Victoria

우선 오픈 시점의 SW 아키텍처는 한동안의 진통은 겪겠지만, 어느 정도는 시스템의 균형이 맞춰진 최적의 상태를 유지하게 됩니다. 이러한 SW 아키텍처가 더 이상 지탱하지 못하는 순간에서는 비즈니스 로직의 변화가 그 한 몫을 담당하게 됩니다.

1. 소스 코드의 클린 상태의 붕괴
SW 개발 시점에 소스 코드는 다양한 인스펙션을 거쳐서 상당히 클린 상태를 유지하게 됩니다. 하지만, 이 클린 상태가 비즈니스 로직의 변화와 다양한 모니터링 상황을 위해서 붕괴되는 시점이 발생됩니다. 가장 흔한 예가 형상관리로부터의 소스 체크아웃 시점에 빌드되지 못하는 상태입니다. 또한, 복잡한 형상관리 프로세스로 인해서 소스 코드를 깨끗하게 관리하지 못하는 상태가 계속해서 이어질 수 있습니다. 소스 코드의 클린 상태를 유지하지 못하는 SW는 아키텍처를 직접적으로 영향을 줄 가능성이 아주 높습니다. 아키텍처에서 원칙으로 삼은 내용들이 깨끗하지 못한 소스 코드로 인해서 충돌이나 변칙들이 발생하고, 이를 효과적으로 대처하지 못한다면(아키텍처가 진화하지 못한다면) 문제의 심각성은 더욱 깊어져가고 운영되는 시스템의 코드를 이러한 이유로 변경한다는 것은 엄두내기가 아주 곤란한 순간에 봉착될 수 있습니다. 또한, 에러 상태를 지니고 있는 코드를 그대로 운영하게 되어 결국 오류를 시스템이 그대로 짊어지고 끝까지 가는 경우도 있습니다.

2. 컴포넌트 비대화
컴포넌트의 비대화는 소스 코드 길이의 증가와 함께 인터페이스/오퍼레이션의 수의 증가와 같이 나타나게 됩니다. 기존 컴포넌트에 비즈니스 로직을 추가하거나 덧붙이려는 현상은 새로운 컴포넌트를 만드는 노력보다 더 쉽다는 것도 그 이유 중에 하나입니다. 여기서 기존 컴포넌트를 개발을 하거나 그 내용을 잘 알고 있는 사람이 이를 덧붙이는 것과 그렇지 못하는 사람이 이를 덧붙이는 작업에는 큰 차이가 발생됩니다. 유지보수 시점에는 컴포넌트의 내부를 잘 알고 있는 사람이 그리 많지 않기 때문에 기존 컴포넌트에 비즈니스 로직이 변경/추가되면서 상당한 비대화 작업이 발생됩니다. 컴포넌트가 비대화되는 순간 다양한 문제들이 발생되며, 이를 지탱하고 있던 아키텍처 역시 이를 감당하지 못하는 상태가 될 수 있습니다.
컴포넌트 비대화는 컴포넌트 의존관계를 해치는 가장 큰 주범이기도 합니다. 컴포넌트 의존관계가 제대로 구성되지 못하는 시스템은 궁극적으로 물리적인 배포와 직접 연관이 됩니다. 또한, 의존관계의 복잡성을 명시적이지 못한 방식으로 접근하게 되는 것을 허용하기도 하는데, 이럴 경우, 시스템의 복잡도는 더 크게 증가하여 관리할 수 있는 수준 이상을 넘어서게 됩니다.

3. 채널의 증가에 따른 비즈니스 로직의 중복
채널의 증가는 곧 다양한 접점들을 만들어내는데, 이는 결국 기존 비즈니스 로직의 변이를 만들어내게 됩니다. 기존 코드의 수정이나 변화를 어렵게 느끼는 작업 환경에서 이러한 채널의 증가는 결국 또 다른 중복 비즈니스를 만들어내게 됩니다. 중복 비즈니스는 기존 컴포넌트의 재사용에 대한 복잡성의 증가를 이유로 별도의 컴포넌트를 양산하게 되며, 결국 서로 다른 결과를 만들어내는 중복 비즈니스를 만들게 됩니다. 즉, 비즈니스 정합성에 큰 오류가 발생하며, 그 오류는 결국 수많은 배치(batch)성 작업을 만들어내는 원인이 되기도 합니다.

비즈니스 로직의 진화는 결국 아키텍처의 진화를 필요로 하며, 아키텍처가 수용하지 못하는 비즈니스 로직의 구현은 결국 이상한 형태의 시스템을 만들게 됩니다. 즉, 10층 건물인데 지하로 땅을 파서 사무실을 더 만들거나, 어느 특정 층의 면적이 아래 층의 면적보다도 더 넓은 형태로 확장을 하는 것이라고 볼 수도 있습니다. 하지만, 이러한 아키텍처가 서서히 망가지는 현상의 원인은 겉보기에 복잡해보일 수도 있지만, 궁극적인 비즈니스의 변화를 잘 관찰하면 그 해답은 오히려 단순하게 결론지을 수 있습니다.

1. 기존 문제를 반드시 해결한다.
기존에 가지고 있는 시스템의 문제는 반드시 해결해야 합니다. 컴포넌트 의존관계 원칙 위배 해결, 소스 코드의 클린 상태 유지, 컴포넌트 경량화. 최소한 이 세가지만 어느 정도의 건강한 상태로 유지시켜도 아키텍처는 충분히 이를 지원할 수 있을 것입니다. 기존 문제를 해결하지 못한 상태에서 새로운 비즈니스 로직을 추가하는 행위는 문제 영역을 확장시켜서 추후 문제 해결할 수 있는 실마리마저 제공하지 못할 수 있습니다.

2. 변이 영역을 다양화시킨다.
기존 로직의 변형이나 변이는 여러가지 비즈니스 로직에서 나타나게 됩니다. 요즘과 같이 N 스크린의 시대를 맞이하면서 UI와 플랫폼의 증가는 기존 비즈니스 로직의 변화를 유발시키며, 이는 기존에 한정된 변이 영역을 가진 경우에 그 영역 안에서 모든 것을 해결하기란 쉽지 않습니다. 따라서, 변이를 위한 영역을 다양한 비즈니스 로직의 경우에 맞추어서 충분한 공간을 확보해야 합니다. 이는 내부 업무 간의 연결이 생성되면서도 발생될 수 있는데, 이러한 영역을 확보하지 못하면, 컴포넌트나 시스템 간에 임의적이고 임시적인 상태의 연결고리를 만들어버리며, 추후 유지보수시 어떠한 부분을 손댈 수도 없는 상태를 만들게 됩니다.

3. 가능하다면 가시화시킨다.
개발 시점의 시스템은 개발 기간 동안에 충분한 접촉 시간으로 인해서 가시화가 굳이 되어 있지 않더라도 대부분의 구성은 어느 정도 머리 속에 있습니다. 하지만, 운영 이후의 시스템에서는 이러한 가시화가 반드시 필요합니다. 또한, 가시화는 그 변화의 모습이 중요하며, 그 결과에 대한 비중은 상대적으로 줄어듭니다. 즉, 어떤 컴포넌트와 다른 컴포넌트가 연결된다면 이 연결이 왜 발생했으며, 어떤 결과를 낳게 되는지를 가시화시켜야 하며, 이는 시간 순으로 혹은 기능별로 관리가 되어야 합니다. 컴포넌트의 연결이 발생하는 것에 대해서는 가시화되지 못하다면, 점점 기존의 아키텍처를 무너뜨리를 수 있는 단초를 제공할 것입니다. 가시화는 좀 더 세분화시켜서 관리할 필요도 있습니다. 예를 들면, 컴포넌트 간의 관계는 오퍼레이션 단위로 관리하게끔 세분화해서 가시화시키는 것도 한 방법입니다.

운영이나 유지보수의 시스템은 개발 시점의 조직과 다를 수 있으며, 이러한 운영 조직의 형태도 기존 아키텍처의 진화를 요구하는 부분이기도 합니다. 또한, 유지보수시 나타나게 되는 요구사항이나 그 변화는 그에 대해 맞게 유연하게 대응할 수 있는 프로세스와 조직을 구성하게끔 하는 것이 더 나을 수 있습니다. 하지만, 유지보수에 대한 비용이 개발 비용보다 더 적다는 이유로 이러한 시도를 하지 못하는 경우도 있는데, 유연한 프로세스와 조직을 갖추지 못한다면 해당 변화의 문제를 단순히 개발자에게 맡기고 그 변화를 담당하게 하는 것은 또 다른 문제를 유발시킬 수 있습니다.
또 다른 영역으로는 개발환경과 기술의 발전으로 좀더 편리하고, 유용한 도구와 라이브러리가 나타나기 때문에 이 부분의 적용도 고려해야 합니다. 기존 개발 시점의 기술이 한계에 있는 부분이 있기 때문에 버전이 올라가거나 새로운 기술이 이를 채워줄 수 있다면 새로운 개발환경이나 기술로의 이전을 시도하는 것도 문제를 해결할 수 있는 부분이기도 합니다.