본문 바로가기
Homo Architect

너무 많은 이해관계자들을 위한, 너무 많은 시스템을 위한 아키텍처

by javauser 2012. 2. 28.
여기에 아주 근사한 아키텍처를 기반으로 만든 시스템이 있다. 이 아키텍처는 SoC(Separation of Concerns)의 원칙에 따라서 내부 시스템 간에 느슨한 결합(loosely coupled)을 통해 서로 연결되고, 각 계층(layer)은 의존관계(dependency)의 원칙하에 내부 모듈은 호출하게 되어 있다. 다소 어쩔 수 없는 솔루션이나 외부 시스템 때문에 일부 아키텍처가 균형을 이루지 못한 부분도 있지만, 극히 일부분이고, 그리 많이 사용하지 않은 기능이라 이 부분 역시 중요한 모듈과는 최대한 의존관계를 줄이도록 설계를 했다. 기능적으로도 품질적으로도 사용자가 만족할 만한 수준의 아키텍처가 만들어졌으며, 충분히 문서화 작업도 이루어져 있다.

이제 이 시스템이 운영 단계에 접어들면서 운영에 필요한 코드가 추가되기 시작한다. 운영을 맡은 사람들은 개발에 관련된 내용을 그리 많이 알지 못하기 때문에 시스템 변경으로 인해서 코드의 어떠한 부분을 바꾸어야 하는지를 아직 잘 모른다. 예를 들어, 특정 서비스에 대해서 예외적인 로직을 추가하는 요구를 사용자로부터 받았다면, 개발은 맡은 운영자는 특정 서비스에 대한 기능을 수행하는 코드를 찾는다. 해당 코드는 통상 UI와 서버와의 접점에서 시작해서 UI에 기능을 넣을지 아니면, 서버측에 해당 기능을 수정할지를 고민하게 된다. 만일 개발자가 UI에 좀더 자신이 있는 사람이라면, UI에 해당 기능을 넣으려고 시도할 것이다.

하지만, 다양한 채널을 통해서 서비스를 제공하는 시스템이라면 이는 판단을 잘못한 것일 수도 있다. (만일, 해당 시스템이 다양한 채널에 제공하는 서비스를 가지고 있다면) 우선은 해당 기능이 채널 모두에 해당하는 기능인지를 알아봐야 한다. 이를 모르는 개발자는 UI에 수정된 기능을 추가하고, 테스트를 하고 나서야 (혹은 이미 변경 후에 타 채널에서 해당 서비스가 동일하게 동작하지 않았음을 알고) 채널에 공통적으로 제공해야 하는 기능임을 알게 된다. 이미 많은 로직을 구현한 상태라 이를 변경하기가 쉽지는 않기에 서버에도 동일한 로직을 다시 추가하게 되며, 로직은 중복되기 시작한다.

운영 중인 시스템에서의 중복은 다양한 이유로 인해서 산재하여 나타나고 통제나 관리의 범위를 넘어선다. 때로는 기존 로직의 수정을 하고 싶지만, 잘못 손을 댔다가는 기존 기능마저 잘못될 수 있기 때문에 동일한 로직의 복제와 수정을 통해 중복 코드가 발생되기도 한다. 물론, 다양한 테스트케이스를 통해서 검증을 하고 코드의 견고성이나 확장성을 높여서 중복 로직을 최소화시켜야 하겠지만, 운영 단계에 들어간 상태에서는 이러한 원칙이나 원리는 요원하기만 하다.

아키텍처라는 단어는 어찌보면 너무나도 크고 수많은 요소들을 가지고 있는 것처럼 들리지만, 그리고, 왠지 모르는 막연한 개념때문에 전체 시스템이 통일을 이루고 있어야 한다는 원칙을 고수해야 한다는 선입견을 가지고 있기 때문인 것도 있지만 구획화라는 관점에서 별도의 아키텍처를 가지고 가려는 시도는 어디에서도 보기 힘들다. 만일, 전체 시스템을 명확한 구획화를 통해서 나뉘어져 있고, 이들 간의 인터페이스 원칙을 세우는 노력만 있다고 하더라도 중복 로직의 최소화는 실현이 가능할 수도 있다. 또한, 개별 영역은 관심사에 따라서 아키텍처 구조나 원칙이 다소 상이한 형태로 존재할 수도 있다. 궁극적으로 시스템은 이러한 개별 영역이 가지는 서로 다른 아키텍처 구조의 매끄러운 통합을 통한 서비스 대응의 신속함과 유연성을 가지도록 구성되는게 바람직하며, 이는 개발 시점의 아키텍처가 아무리 좋고 훌륭하다고 하더라도 이러한 원칙이 무시되거나 붕괴되기 시작하는 운영 시점에는 점점 그 품질이 좋지 않은 형태로 시스템이 변형되기 시작한다.

개발 시점의 이해관계자와 운영 시점의 이해관계자는 분명 그 범위나 뷰가 달라지기 마련이며, 이에 따라 운영되는 시스템의 아키텍처는 개발 시점의 아키텍처와는 전혀 다른 접근 방식을 취할 필요는 있다. 아키텍처가 가지는 본질은 달라지지 않지만, 아키텍처를 구성하는 영역의 변형으로 인해서 아키텍처는 영향을 받을 수 밖에 없으며, 이러한 영향은 운영 시점에 넓어진 이해관계자의 범위와 변경된 이해관계자의 뷰로 기인되기도 한다. 즉, 개발 시점의 아키텍처만을 고수한다고 하면, 시스템은 정상적인 방법이 아닌, 비정상적인 방법으로 해당 기능의 변형 및 추가가 발생하기 시작하며, 시스템은 점점 골치아픈 문제를 품은 하나의 거대한 흉물로 변하기 시작한다.

현재의 시스템의 구조가 이러한 이해관계자들의 관점이나 범위에 영향을 어떻게 미치는지를 한눈에 파악할 수 있는 방법 중에 하나는 조직의 구조나 구성원의 속성을 얼마나 바꾸기 쉬운지를 가지고 평가해볼 수도 있다. 조직이나 구성원은 시스템을 사용하는 이해관계자들과 거의 일치하며, 이들은 시스템의 관점에서 권한이나 인가와 관련이 깊다. 이러한 로직들이 시스템의 전반적인 영역에 걸쳐서 스며들어가 있기 때문에 조직 구조나 구성원의 속성 변경과 얼마나 강력하게 결합되어 있는지를 알아봄으로써 시스템의 유연성/확장성이나 견고성을 알아볼 수도 있다. 이러한 로직들은 대부분이 개발 시점보다는 운영 시점에 더 강화되고 그 로직이 더 많아지기 때문에 그로 인한 시스템의 품질을 현저하게 저하시키기도 한다.

또한, 운영중인 시스템은 다양한 서비스와 채널의 증가로 인해서 별도의 시스템과의 연계 지점이 더 많아지고, 그로 인해서 내부 구조의 변경이 발생한다. 이러한 변경 중에서 전체적인 시스템에 악영항을 주는 경우 역시 로직의 중복을 가중시키는 경우이며, 극단적으로는 각 서비스나 채널별로 독립적인 시스템들이 나타나는 경우이다. 특히, 이는 운영 조직에 종속되어서 그러한 형태의 시스템의 구조를 가속화시키는 경우가 대부분이다. 운영 조직이 서비스나 채널별로 구성되고 해당 담당자들이 시스템을 담당할 때에 각 서비스 및 채널별로의 로직의 특화 현상이 심해지며, 점점 동일 비즈니스에 대한 중복 및 변종 코드들이 산재해서 시스템의 복잡도를 더욱 증가시킨다.

이해관계자의 범위가 증가하고, 이들의 관점이 변화할수록, 그리고, 시스템의 연계 지점들이 확대될수록 아키텍처는 점점 그 형태나 모습이 변해야 한다. 변화는 시스템의 불안정을 가속화시킬 수 밖에 없지만, 이러한 불안정을 안정화시키는 아키텍처 구조를 잡아가는 노력이 들 수 밖에 없다. 그러한 노력에는 시스템의 구조를 다양한 관점에서 지속적으로 (continuous) 투영(projection)할 수 있는 방법을 필요로 한다. 이러한 방법에는 통상 SW의 정적인 측면의 metric들도 포함되지만, 그에 못지 않게 이를 해석하여 적절한 대처 방법을 마련해야 한다. 또한, Lazy(혹은 near real time) 기법을 사용한 Monitoring 방식을 통해서 실행시점의 SW의 반응 양식에 대한 패턴을 알고 있어야 한다. 이러한 반응 패턴들이 변화를 하거나 중복의 양상을 보일때에 시스템의 이상 징후를 감지할 수 있어야 한다.

운영중인 시스템의 품질이 저하되는 현상의 원인은 단순한 사용자의 증가보다는 시스템을 바라보는 이해관계자의 범위나 관점의 변형으로 봐야 하고, 더욱 다양하고 많은 시스템들의 통합이 그러한 저하를 더욱 심화시킨다. 
반응형