아키텍처 의사결정에 관한 쏠림 현상

쏠림 현상 (Herding effect, 혹은 Bandwagon effect) 이란, 특정 그룹이나 모임에 속한 개인이 자신의 의지나 계획된 방향에 상관없이 그 주변의 의사결정에 영향을 받아서 그대로 쫓아가는 것을 말합니다. 이러한 현상들의 대표적인 예는 주식 시장의 버블 현상과 같은 것이 있습니다. 요새 스마트폰 열풍 같은 것들도 이러한 현상의 예라고도 볼 수 있을 것 같습니다.

이러한 현상은 합리적인 의사 결정을 이끌어내는데 방해가 되기도 하지만, 어떤 일을 추진할 때에는 상당히 좋은 이점을 얻을 수도 있습니다. 하지만, 이러한 쏠림 현상이 특히 의사 결정과 관련이 될 때에는 좋지 않은 결과를 낳을 수 있다는 것입니다. 법률에서 항고심제는 이전 재판의 결과에 대해 어느 정도는 영향을 받을 수 있으며, 후속 재판의 결과에 대해 의사 결정을 하는 순간에 판사는 법률 조직이라는 테두리에서 자신이 손해를 입지 않을 정도로 판결을 내릴 확률이 높습니다. 물론, 이에 반해 판결하는 판사는 '소신이 있다'라는 표현을 하기도 합니다. 의사들 역시 특별한 질병에 걸린 환자가 이전 병원에서 어떠한 처방을 받았는지를 판단하고 의료 소송이 불거지지 않은 범위 내에서, 그리고 환자에게 도움이 되지 않지만 무난한 처방전을 내려 질병에는 아무런 차도가 없지만, 자신이나 병원으로서는 찾아온 환자에게서 수익을 얻게 됩니다.

Traffic Jam by The Wandering Angel

 
이러한 쏠림 현상은 특히, 전문적인 지식을 요하는 분야에서 흔히 나타날 수 있는 현상으로 선행 의사결정의 과정을 세밀하게 보지 못하거나 이해를 하지 못한 상태에서 이를 정설이듯 받아들여서 후행 의사결정도 선행과 유사하거나 동일하게 이루어지게 됩니다.

소프트웨어 아키텍처 분야 역시 상당히 복잡한 시스템에 대한 의사 결정일수록 이런 현상은 당연한 듯이 일어납니다. 예를 들어, 대부분의 대형 프로젝트가 본격적으로 진행되기 이전에 PI(Process Innovation) 혹은 BPR (Business Process Reengineering)과 같은 이름으로 본격적인 프로젝트를 진행하기 위한 기획 형태의 틀을 마련하는 기간을 갖습니다. 요새는 이러한 사전 기획의 내용의 대부분이 EA (Enterprise Architecture) 로 채워집니다. 이름에도 들어가 있듯이 Architecture라는 용어로 인해서 그 내용에는 자동적으로(당연하게도) SW 분야의 Architecture의 내용도 들어가게 됩니다. 이 분야에서의 작업은 대부분 비즈니스 관련 컨설팅 회사의 컨설턴트들이 작업을 하게 됩니다. 이들은 물론, IT 관련된 지식을 풍부하게 가지고 있는 사람들도 있지만, 그렇지 못한 사람들이 대부분이며, 또한, 직업의 특성상 SW 시스템을 직접 구현하지 못한 사람들도 대부분입니다. 이러한 배경 지식을 가지고 있는 사람들이 SW 관련 내용을 EA에 포함시키다보니, SW 아키텍처를 때로는 잘못 이해하고, 잘못된 방향으로 인도하는 경우가 있습니다. 

이러한 현상이 특정 프로젝트에서만 진행된다면 큰 무리가 없겠지만, 이는 그 다음 후속 프로젝트에서도 그 특수성이나 독자성이 있음에도 불구하고, 그대로 복제/변형되어서 또 다른 오류를 일으킬 가능성을 증폭시킵니다. 즉, 소프트웨어 아키텍처에 대한 본질적인 이해나 성찰이 필요함에도 불구하고, 너무나도 전문적이고 복잡한 상황에 대한 이해를 위해 긴 시간이 필요하지만, 그 짧은 프로젝트 기간 동안에 많은 성과를 내려다보니 무리하여 왜곡된 형태로 그 결과물들이 나타나게 됩니다. 특히, AA(Application Architecture)와 IA(Information Architecture)로 구분하여 이들을 각각 분석하는 방향은 추후 SW를 개발하는데 있어서 논리적인 개념의 실체화(Application)와 논리적인 정보의 실체화(Database)만을 가지고 다루기 때문에 논리적인 관점은 상당히 배제된 상태가 됩니다. 또한, EA에서 말하는 AA와 IA와의 관계가 분명 존재하고 이 둘 간의 관계도 역시 SW에서는 중요한 부분임에도 불구하고 이러한 내용은 아예 거론되지 않는 경우도 있습니다.

결과적으로, EA는 수천 페이지의 산출물을 만들어내고도 본격적인 시스템을 구축하는 단계에 들어서는 대부분의 산출물들이 큰 효과나 의미있는 입력물로 사용되지 못하는 실정입니다. 마치 SW 시스템을 수박 겉핥기 식의 모습들만을 묘사해놓고 있어서 기존 시스템의 물리적인 모습만을 정리해 놓은 정도의 수준 밖에는 안됩니다. 또한, 그러한 EA 산출물들이 나오게 되는 과정들이 생략된 채 이후의 사람들에게 넘겨져 있어서 이에 대한 올바른 시각을 주지 못하고 있습니다. 특히, 그 중에서 애플리케이션에 대한 체계를 Application Domain, Application Group, Application, Service Group 과 같이 계층적인 모습으로 목표시스템을 묘사하고 있어서 마치 이 부분이 SW 아키텍처를 보여주는 것과 보이도록 합니다. 이러한 계층적인 구조의 아키텍처를 마치 시스템에서 그대로 구현해야 하듯이 전체 시스템 내부 역시 이러한 계층화를 유도하고, 각 계층에 따른 엄격한 통제를 두어서 애플리케이션 내부 구성에 대한 SW 아키텍트나 분석/설계자, 개발자의 영역까지도 침범해버리기도 합니다. 이를 '애플리케이션 아키텍처 계층 구조'라고 부르면서 마치 SW 아키텍처인 듯한 모습으로 보여주는 내용은 이후 EA 관련 프로젝트에서 상당히 유사한 형태로 나타나고, 그러한 (잘못된) 개념(AA가 SW 아키텍처인 양)이 프레임워크라는 이름으로 변형되어서 결과적으로 기존의 많은 SW 아키텍처 원칙들을 흔들어놓고 오염을 시켜버립니다.

이러한 현상은 최초에 EA를 만들고, 이를 확대, 재생산하면서 (수많은 사람들이 EA에 대한 쏠림 현상이 발생하면서) SW 기본인 아키텍처 영역에 지대한 부분을 침범하고, 대부분의 SW 개발에 종사하는 사람들에게 엄청난 영향을 미치고 있습니다. 사실, EA에서 IT 시스템에 대한 부분이 반드시 포함되어야 하는 이유는 이전 시대와 달리 IT의 중요성과 업무에서의 필수성이 증대하면서 IT의 효과적인 사용을 위한 전략적인 차원에서만 거론되었습니다. 하지만, 이제는 좀더 나은 PI/BPR 프로젝트와 고객에게 더 충격적이고 매혹적인 결과물을 내는 경쟁적인 시장에서 다양한 개념의 오염과 그로 인한 쏠림 현상과 맞물려 이제는 더 이상 치유가 불가능한 상태까지도 몰아가고 있는 상태입니다.

SW 아키텍처에 대한 의사 결정은 궁극적으로 해당 비즈니스 영역에서 효율적으로 지원할 수 있는 형태의 기준을 가지고 이루어져야 하며, 이는 SW 개발 프로젝트가 진행되는 과정에서 진화/발전의 형태로 나타나게 됩니다. 하지만, 이러한 원칙은 쏠림 현상으로 말미암아 무시된 채, 한번 확정되고 고정된 SW 아키텍처는 변화나 진화를 선택하는 것이 아니라, 프로젝트가 진행되면 될수록 퇴행할 수 밖에 없는 경로를 선택합니다. 그로 인해, 많은 분석/설계자, 개발자들이 고통을 받고, 궁극적으로 고객에게 이전보다 못한 시스템을 인도하는 결과도 종종 나타납니다.

SW 아키텍처에 대한 의사 결정 과정에서 이러한 쏠림 현상을 주의해야 합니다. 그 근거와 명확한 타당성이 존재해야 하며, 그 과정 역시 투명하게 나타나야 됩니다. 그리고, 그 중심에는 항상 비즈니스 가치와 고객에게 전달될 수 있는 가치가 있어야 하고, SW 아키텍트는 이전에 수행했던 의사 결정과는 독립적이고 합리적인 사고를 바탕으로 지금의 SW 아키텍처 구조를 결정해야 합니다. 이러한 의사 결정은 궁극적으로 고객 뿐만 아니라, 그 프로젝트에 참여하는 모든 이해관계자들에게도 - 설사 프로젝트가 실패했다고 하더라도 - 좋은 의미로 남을 수 있습니다. SW 아키텍처는 분명 고도의 지식과 전문적인 식견을 필요로 하는 만큼, 맹목적인 추종이나 동조, 쏠림 현상을 늘 주의할 필요가 있습니다. 그렇지 않다면, 그 파장의 범위는 너무나도 광범위해질 수 있습니다.