시스템을 만들때에 사용자(user)의 요구를 충족시키는 것이 제일 목적이라고 말한다. 보통 사용자라고 함은 시스템이 제공하는 서비스를 직접 사용해서 원하는 것(가치)을 얻는 행위를 하는 액터를 일컫는다. 이러한 사용자는 불특정 다수가 될 수도 있겠지만, 업무 시스템과 같이 특정 업무를 위한 시스템의 경우에는 명확한 업무 사용자가 정의된다. 어떠한 사용자이든 이들은 시스템을 직접 다루거나 처리하는 형태가 아닌 그저 수동적으로 시스템이 일방적으로 제공하는 서비스를 사용할 뿐이다.


하지만, 최근의 시스템들은 사용자들에게 어느정도는 능동적인 행위를 부여하는 형태로 서비스를 제공하기 시작한다. 예전에는 HTML을 그저 브라우저를 통해 화면에 보여지는 요소를 만드는 형태로만 쳐다보았다면, 지금의 사용자들은 직접 자신만의 HTML을 조작하기를 원하고 많은 시스템들이 그러한 서비스들을 제공하고 있다. HTML 조작이 어려운 사용자들에게는 단순한 형태의 템플릿에서부터 복잡한 조합을 할 수 있는 템플릿까지 제공하여 사용자들의 입맛에 맞게 구성하라고 내어준다. 더 나아간다면 사용자들의 행위나 형태를 분석하여 자동으로 짐작하여 다양한 화면을 보여주기도 한다.



James, I think your cover's blown!
James, I think your cover's blown! by laverrue 저작자 표시



이러한 사용자에 대한 관점(viewpoint)은 점점 시스템을 조작할 수 있는 뷰(view)까지도 확대되고 있는 것이다. 이해관계자(stakeholder)는 이러한 사용자들을 포함하여 시스템을 둘러싸고 있는 다양한 이해관계(interest)와 관심사(concern)를 가지는 모든 사람(요즘에 사람 뿐만 아니라, 여러 시스템이 연계되고 외부에 서비스들을 오픈해주기 때문에 이러한 범주까지도 포괄하는 형태이다.)을 통칭한다. 시스템을 사용하는 사람만 보더라도 단순히 서비스를 제공하는 수동적인 형태가 아닌 능동적으로 시스템을 조작할 수 있는 기능까지도 부여하는 추세로 본다면 그보다 범주가 더 큰 이해관계자들이 원하는 시스템에서의 기능까지를 고려한다면 너무나도 많은 기능들을 시스템에서 제공되어야 할 상황이다.


시스템을 운영하는 사람들은 일일히 그 많은 서버를 관리하지 않고, 한번의 클릭으로 수십, 수백, 수천대의 서비를 관리하기 원한다. 시스템에서 문제가 발생되면 어떤 문제인지, 그리고 누가 해결해야 하는지, 얼마나 빨리 복구될 수 있는지에 대해서 통지받기 원한다. 심지어 시스템의 하드웨어에 대한 수명이나 상태까지도 자동으로 납품업자에게까지 알려주어 구매 프로세스가 자동으로 발생되기까지도 원하는 경우도 있다.


이제 시스템은 가만히 두면 사람들이 알아서 모이는 그러한 서비스를 제공해서는 더 이상 그 가치를 발휘하지 못한 상태까지 진화한 것이다. 이러한 상황에서 시스템을 만드는 아키텍트에게도 여러모로 고민거리들이 점차 늘어가기만 한다. 점점 늘어만 가는 이해관계자들과 이들의 요구는 그 끝을 알기가 점점 힘들어진다.


아키텍트에게 이해관계자들의 관심사는 시스템을 만드는 가장 중요한 요소가 된다. 이해관계자들이 많아지고, 이들이 관심을 갖는 분야가 다양할수록 신경써야 하는 (혹은 만들어야 하는) 아키텍처 요소들이 늘어난다는 것이다. 사실 얼마나 많은 이해관계자들을 만족시킬 것인가에 대한 정답은 없다. 하지만, 이 물음을 역으로 생각해본다면 이해관계자들은 어떠한 시스템에 만족을 하는가로 바꿔볼 수 있을 것이다. 즉, 이해관계자들이 만족하는 시스템을 찾아서 그 속성을 분석해야 됨을 의미한다. 이해관계자들이 만족하는 시스템은 자신들이 예전에 직접 경험했던 것일 수도 있고, 혹은 광고나 컨퍼런스 같은 곳에서 마케팅 요소가 가미된 시스템일 수도 있다. 혹은 최근에 유행하는 트렌드일 수도 있고, 때로는 스스로의 상상에 의해서 만들어낸 것일 수도 있다.


그러나, 무엇보다도 이해관계자들이 만족하는 시스템은 시스템을 사용함으로 인해서 자신의 가치가 더 돋보이게 만드는 것일게다. 즉, 해당 시스템을 사용함으로써 남들보다 돋보이고 더 효과적이고 효율적인 정보를 사용하고 있다는 느낌을 받는 시스템이 이해관계자 입장에서 비용을 들인 가치를 얻게 된다. 개발자 입장에서 시스템을 다루어야 하는데 여러가지 감시 체계나 복잡한 절차를 통해 자신의 작업을 다른 이에게 잘하고 있는지를 증명하게 만든다면 그 스스로 시스템을 다룬다는 자부심보다 남의 물건에 흠집이 나지 않게 조심스럽게 다루어야 한다는 강박관념을 더 받을 것이다. 웹페이지 어디 구석에 쳐박혀 있는 정보를 보기 위해서 다양한 인증 체계와 수많은 브라우저의 종료를 거치고 나서야 원하는 것을 얻는다면 사람을 위한 시스템이 아닌 시스템을 위한 사람으로 만든다는 감정으로 스스로의 자존감에 훼손이 발생되었다는 느낌을 받을 것이다.


시스템의 아키텍처를 만드는 아키텍트로써 이해관계자들의 요구를 충족시키는 것이 가장 큰 임무이다. 그러한 임무는 결국에는 이해관계자의 자존감을 높여줄 수 있는 시스템을 만드는 일이다. 이제 기술의 한계(혹은 기술을 구현할 수 있는 당사자의 한계)를 넘어서 다시 인간답게 살기 원하는 질을 제공하는게 시스템의 목적이 되었다. 얼마나 많은 이해관계자를 만족시켜야 하는지에 대한 물음은 아키텍트 스스로 인간에게 가치를 높여주는 시스템을 만들었는가로 다시 자문하게 만든다.


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

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

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

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

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

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

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

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

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

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

+ Recent posts