'공통'은 모든 사람들이 접근하는 광장이다.

 대형이든 소형이든 대부분의 프로젝트에서는 아키텍트팀과 업무를 중심으로 한 업무 개발팀으로 나눕니다. 업무는 비즈니스로부터 구획화가 되며, 각 업무 간에는 의존관계로 연결됩니다. 하지만, 비즈니스가 칼로 자르듯이 구획화가 힘든 부분이 발생되기도 하며, 이는 비즈니스를 구현하는 IT 입장에서도 명확하게 나누는 것이 힘든 경우도 발생됩니다. 이와 같은 일이 발생되는 경우에 가장 흔하게 사용되는 것이 업무 공통이라는 영역을 나누는 방식입니다. 즉, 어느 업무 팀에도 할당하기 애매모호한 것들을 통틀어서 공통이라는 영역으로 두게 됩니다.

 일단 공통이라는 영역을 두게 되면, 수많은 애매모호한 성격의 일들이 이 영역으로 들어오게 됩니다. 심지어는 두 업무 사이에 명확하게 나누기 힘든 것 역시 이러한 공통 영역으로 들어오게 됩니다. 어떤 프로젝트에서는 기술 공통이라는 영역까지도 나눕니다. 기술의 범위가 너무나 협소해서 아키텍처 영역에 두기는 사소해서 이곳에 위치시킵니다.

 공통이라는 원래의 의미를 살펴보면, ‘여럿 사이에 다 같이 있거나 관계됨’ 이라고 정의되어 있습니다. 공통이라는 말에는 다수의 개념이 포함되어 있습니다. 여러 개의 개념들이 함께 공존하고 있다라는 의미는 표준이라는 개념을 염두해두고 있어야 한다는 것입니다. 다시 말해서, 애매모호하거나 명확하게 정의하기 힘든 영역이 공통이라는 것이 아닙니다. 공통 영역은 명확하게 정의되고, 표준화될 수 있는 영역이며, 이는 다수로부터 사용되는 영역입니다.

 공통코드, 로그인, 메뉴관리, 사용자 관리, 업무 정합성, 게시판, 달력, 팝업화면, 휴일관리, 조직관리 등 공통 업무나 기술 영역을 나누고 많은 프로젝트에서 구현했던 내용들의 예입니다. 이러한 내용들이 과연 표준화되고 명확하게 정의했던 내용들이었던가요? IT에서 구현하는 내용들은 대부분 비즈니스로부터 발생되며, 비즈니스 기준에 의해서 구획화되지만, 많은 아키텍트들은 이와 같이 애매모호한 것들을 그냥 공통이라는 이름으로 두고 관리하려고 합니다. 어찌보면 아키텍트의 역할을 제대로 하지 못해서 발생되는 영역이라는 생각이 더 듭니다. 명확한 기준과 표준을 제시하지 못했기 때문에 공통이라는 편리한 장치를 두고 이를 전가해버린 것입니다.

 컴포넌트나 클래스 명 역시 공통(common)이나 유틸리티(utility)라는 이름의 유혹을 떨쳐버릴 수가 없습니다. 그동안 이러한 이름으로 구현된 소스를 살펴보면, 과연 그 내용이 표준화되고 명확한 정의를 내릴 수 있는 기능으로 구현되었는지를 생각해보면 전혀 이와는 상관없이 구현되었다는 것을 알 수 있을 것입니다. 또한, ‘공통’ 이라는 이름 아래에 얼마나 많은 관련없는 기술과 비즈니스 로직이 구현되었는지는 바로 알 수 있습니다. 하나의 ‘공통’이라는 컴포넌트는 전혀 상관없는 인터페이스들로 구성되며, 시간이 흐르면서 이러한 공통 컴포넌트는 점점 더 많은 서로 관련이 없는 인터페이스들을 가지게 됩니다. 그로 인해서, 공통 컴포넌트 중에 일부 기능을 사용하는 다른 컴포넌트에서는 공통 컴포넌트의 인터페이스가 증가할 때마다 새로 해당 컴포넌트를 배포해야 하며, 영향도를 다시 검사해야 합니다. 즉, 공통 컴포넌트는 전혀 표준화가 되지 않은 영역입니다. 또한, 공통이라는 이름은 그 누구도 유지보수하지 않은 영역으로 변해버립니다. 늘 문제는 이러한 아무도 관리되지 않은 공통 영역에서 발생되며, 그 책임성 또한 모호해집니다.

 아키텍트는 공통이라는 단어를 주의깊게 사용해야 하며, 다음과 같은 원칙하에서 영역을 명확하게 구분해야 합니다.

1. 공통(common)이라는 단어는 가급적 사용하지 않는다. 이는 컴포넌트 명이든, 클래스 명이든, 혹은 패키지 명이든 공통이라는 단어가 들어갈 경우, 늘 애매모호한 것들이 위치할 수 있다라는 가능성을 포함하고 있음을 유의한다.
2. 항상 모든 개념에는 정확한 용어와 명확한 정의를 내려야 한다. 용어가 정확하지 않으면, 정의를 내리기가 어려우며, 그럴 경우 애매모호한 개념들이 들어갈 여지를 남겨두는 것이다. 우편번호는 그 자체로 고유한 정의로 사용되어야 하며, 공통이라는 이름으로 다른 개념들과 섞여서는 안된다.
3.  재사용성과 표준화 관점에서 공통이라는 용어를 사용해야 하며, 공통이라는 단어를 빼기 힘든 경우에는 유틸리티(utility)라는 용어를 사용하자. 재사용성은 애플리케이션/도메인/범용 등으로 나뉠 수 있으며, 표준화는 업계나 해당 기술에 대한 표준 내용이 있는지를 먼저 점검하고, 만일 있는 경우, 가급적 이러한 표준적인 내용을 수용할 수 있어야 한다.

 아키텍처에서 공통이라는 이름을 사용하는 장점들은 많습니다. 예를 들어, 레이어에서 복잡하게 얽힐 수 있는 관계를 공통 레이어로 두어서 관리하게 되면, 재사용성이나 아키텍처 건전성 측면에서 더 향상될 수도 있습니다. 하지만, 이러한 장점만을 부각하여 애매모호한 것들을 공통 영역으로 두게 된다면 오히려 시스템에 악영향을 미칠 수 있으며, 책임 영역이 모호하여 유지보수도 힘들어질 수도 있습니다.

 소프트웨어 아키텍트는 시스템의 구성요소들을 식별하고, 이들 간의 관계를 원칙과 원리 하에 규정하는 작업을 하는데, 공통이라는 요소를 식별하여 여기에 애매모호한 내용들을 넣게 된다면, 자신의 역할을 다하지 못했다는 것을 반증합니다. 아키텍트는 늘 이러한 주인없는 영역에 대해서 정확한 용어와 명확한 정의를 내리는 역할을 수행해야 합니다. 공통은 모든 사람들이 소통할 수 있는 광장과도 같으며, 그러한 광장을 모든 사람이 손쉽게 접근하고 막힘없이 교류할 수 있는 장소로 만드는 것이 아키텍트의 역할입니다.