착시 현상과 아키텍처 구조 설계

'보는 것이 믿는 것이다'라는 말이 있듯이 우리는 보는 것만을 믿고 판단하려는 경향이 강합니다. 이 말은 믿음이라는 것은 결국 보는 것을 통해서 더 강해질 수 있다는 뜻으로, 믿음이 없는 상태에서 보는 것만을 추구한다면 오히려 보이지 않는 모습에 대해서는 상상이나 제 입맛에 맞게 생각하여 잘못 판단할 수 있는 경향도 나타날 수 있습니다.

SW 아키텍처의 구조 설계는 이러한 부분에 대해 상당히 유의해야 합니다. 모든 설계가 그렇듯이 상당히 조심스럽고 하나 하나 돌다리를 두들기는 심정으로 작업을 해야 합니다. 하지만, 현실적인 제약에서 모든 경우의 수를 조사하여 판단하기에는 힘든 것이 사실입니다. 혹자는 불명확하거나 아직 뚜렷하게 나타나지 않은 것에 대해서는 아예 관심을 가지지 않고, 명확한 것만을 작업을 수행하도록 권하기도 합니다. 어떠한 측면에서는 이러한 방식도 그리 나쁘지는 않지만, 체계적이고 계획적인 프로젝트에서 이러한 방식을 추구하는 것은 아키텍트를 포함해서 이해관계를 맺은 모든 구성원들에게 불안성만을 가중시킬 우려가 있습니다.

그러다 보니, 기존의 아키텍처를 재사용하거나, 아예 다양한 솔루션/프레임워크를 사용해서 이러한 불안을 없애려고 합니다. 모든 프로젝트가 마찬가지지만, 해당 프로젝트마다의 고유성은 SW 개발시에는 누구나가 인정해야 합니다. 하지만, 이러한 고유성마저 기성(ready-made) 아키텍처를 들이밀어서 인정하지 않는다면 이는 많은 사람들(특히, 개발을 직접 수행하는 개발자들)에게 엄청난 피해가 갈 수도 있습니다.

생산성이라는 목표 아래 SW 개발 자동화는 수많은 잘못된 아키텍처를 낳는 결과를 가지고 오기도 합니다. 이러한 방식의 다양한 솔루션/프레임워크들은 잘못된 시각으로 접근해서 SW 아키텍처라는 개념을 잘못 전달하는 사례가 빈번합니다. 그 중에 가장 대표적인 사례가 분석/설계와 실현(구현)체에 대한 매핑이 1:1이라는 개념으로 접근하는 것입니다. 분석/설계를 솔루션/프레임워크가 지원하기 편하도록 작업을 수행하고 산출물을 만들어내어서 마치 이것이 분석/설계 산출물인양 왜곡을 시켜버립니다. 대표적인 오염된 단어가 '서비스'입니다. '서비스'의 다양한 계층화가 마치 시스템이 제공하는 컴포넌트의 인터페이스 단위로까지 확장되어서 비즈니스의 정의나 설명이 없는 문서만을 만들어내는 결과를 초래합니다. 분석/설계의 산출물은 각각 그 영역에서 고유한 내용이 들어가게 작업되어야 합니다. 다양한 변종 산출물들을 만들어내고, 시대에 맞지 않는 산출물들을 강요하는 개발 방법론이나 프로세스는 과감하게 고쳐야 합니다. '서비스'를 말하는 시대에 아직까지도 '클래스 다이어그램'을 고집하는 것은, (그리고, 산출물 명칭 또한 '클래스 다이어그램'이라고 말함. 클래스 다이어그램은 표현의 수단이며, 이를 사용한 서비스 명세, 인터페이스 명세, 컴포넌트 명세라는 이름을 산출물 명칭으로 사용해야 함) 스마트폰을 말하는 시대에 유선전화(그것도 버튼식이 아닌 다이얼 방식)를 말하는 것과 같습니다.

다시 정리하면, 분석/설계의 산출물과 실현/구현 산출물은 1:1 매핑이 아니라, 무한대의 매핑이 존재하며, 이는 다양한 아키텍처를 생각해볼 수 있다라는 것입니다. 기성 아키텍처(솔루션 혹은 프레임워크를 말함. 엄밀히 말하면, 아키텍처의 일종이며 새로운 프로젝트는 새로운 아키텍처를 설계해야 함)는 그 중에 한가지 방식에 불과합니다. 솔루션/패키지는 분석/설계 산출물을 강요해서도 안되며, 강요한 산출물은 이후 유지보수나 시스템 진화시에 그리 건질 것이 많지도 않습니다.

strong caipirinhas! by Susan NYC

구현 단계에서도 이러한 착시 현상은 계속해서 SW 아키텍처 구조 설계에 영향을 미칩니다. 특히, 레이어간 연결(통합)에 있어서 UI에서의 정보는 그대로 DB로 들어가는 형태로 아키텍처 구조 설계를 합니다. 이는 마치 4GL이 DB에 직접 접속해서 비즈니스를 처리하는 방식과도 흡사합니다. 각 레이어는 그 나름대로 독특하고 의미있는 비즈니스 로직이 위치하고 있어야 하며, 이는 의미있는 비즈니스 덩어리 형태로 응집되어 있어야 합니다. 그러한 아키텍처는 다대다 매핑처럼 보이며, 마치 무한대의 경로를 가진 복잡한 생태계를 이루는 것과 같은 모습을 보여 통제하거나 유지하기 어렵게만 느껴집니다. 이러한 착시 현상으로 인해 UI와 DB만을 개발자의 작업 공간으로 한정시키고, 다른 영역들은 솔루션/프레임워크가 강제하게 만들어버립니다. 동일하지만 유사한 기능에 대해서는 (논리적으로 동일하지만, 그 구현 결과가 아예 다른 형태) 재사용을 못하게 해버립니다. 즉, UI 정의가 다 되면, 비즈니스 로직, DB까지도 모든 것들이 한꺼번에 결정이 된다는 방식으로 SW 아키텍처를 바라보고 설계를 하게 됩니다.

이러한 방식으로 SW 아키텍처를 바라보게 되면, 도메인 모델이나 객체 모델은 거의 의미가 없어지고, 단순히 값을 전달해주는 더미 객체만을 만들어버립니다. 비즈니스 지식은 오로지 UI와 DB에만 있고, 많은 개발자들은 재사용을 못하는 소스만을 각자 만들어서 점점 더 프로젝트를 힘들게 합니다.

지금은 기업 내에서도 수많은 시스템들로 이미 포화상태에 있으며 그 유형도 상당히 다양해졌습니다. 이러한 시점에 통제와 관리의 이유를 앞세워서 개발자의 자유를 박탈하는 행위가 SW 아키텍처 분야에서 이루어진다는 것은 상당히 아쉬운 점입니다. 각 레이어의 고유 영역이 수많은 graph 형태의 결과를 낳는다고 해서 이러한 구조가 통제나 관리가 안되는 것은 아닙니다. 겉으로 보이기에는 복잡하게 보이지만, 일정한 원칙과 일관성을 유지한다면 오히려 더 많은 생산성을 낼 수도 있고, 확장성도 보장받을 수 있을 것입니다. 단순성만을 추구하여 복잡성(의도된 복잡성)을 아예 배제하게 되면 산만성만이 남게 됩니다. 재사용은 어느 정도 수준의 복잡성을 인정할 때 가능해집니다. 이는 마치 인터넷 세계가 무한한 거미줄로 연결된 형태와 같다고 보면 됩니다. (다만, 서로의 연결이 영향을 최소한으로 받게끔 느슨하게 연결된 형태임)