시스템을 만들때에 사용자(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)를 가지는 모든 사람(요즘에 사람 뿐만 아니라, 여러 시스템이 연계되고 외부에 서비스들을 오픈해주기 때문에 이러한 범주까지도 포괄하는 형태이다.)을 통칭한다. 시스템을 사용하는 사람만 보더라도 단순히 서비스를 제공하는 수동적인 형태가 아닌 능동적으로 시스템을 조작할 수 있는 기능까지도 부여하는 추세로 본다면 그보다 범주가 더 큰 이해관계자들이 원하는 시스템에서의 기능까지를 고려한다면 너무나도 많은 기능들을 시스템에서 제공되어야 할 상황이다.


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


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


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


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


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


저작자 표시 비영리 동일 조건 변경 허락
신고

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

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

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

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

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

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

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

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

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

저작자 표시 비영리 변경 금지
신고
사회적 시스템이 복지에 대한 관심이 높아지면서 복지 혜택을 받는 사람들의 대상에 대해 많은 의견들이 있다. '잔여적 복지' 혹은 '선택적 복지'라고 하는 용어는 현재 정부에서 추진하고 있는 못가진 자를 선택적으로 국가에서 혜택을 주는 것이다. 그와 반대로 '보편적 복지'는 국민 모두를 대상으로 동일한 혜택을 주는 개념이다.

이 두가지 형태의 복지는 각각의 장단점이 분명 존재한다. 우선 '잔여적 복지'의 경우, 그 대상자가 못가진 자로 한정되어 있어서 가진 자와 못가진 자를 나누는 또 하나의 차별을 만들게 된다. 또한, 가진 자들의 수입이 못가진 자에게로 돌아가기 때문에 가진 자들의 불만이나 편법을 낳을 수 있다. '보편적 복지'는 국민 전체에게 혜택이 되기 때문에 '잔여적 복지'가 갖게되는 단점은 어느 정도 해소되겠지만, 국가 재정이 문제가 된다. 어떠한 것이 더 나은 것인지에 대한 논의는 지금도 계속되고 있으니, 한번 지켜볼 만하다.

하지만, '복지'라는 어감에는 어찌되었든 내가 제일 먼저 떠오르는 단어가 '못가진 자'라는 사실에 '복지'에 대한 개념을 나도 잘못 이해하고 있는지도 모른다. 가진 자가 조금 더 희생을 해야하는 '잔여적 복지'의 개념에는 누군가의 희생이라는 개념을 가지며, 그로 인해 상대적으로 못가진 자가 있다라는 위안으로 '복지'를 생각하고 있는건 아닌지 모르겠다. '보편적 복지'를 주장하는 쪽에서는 사회 전체 구성원의 안정성을 이야기하고 있다. 즉, 사회 구성원 모두는 최소한 비빌 언덕이 마련되어 있기 때문에 그 바탕 위에 더 나은 발전 지향적인 도전을 할 수 있다라고 한다.

소프트웨어 개발은 이러한 잔여적 복지와 보편적 복지와 같은 개념이 많은 곳에서 존재한다. 그 중에서 가장 유사하게 맞아떨어지는 것이 '역할의 상하 계층화'이다. 역할은 상하의 개념이 거의 희박함에도 불구하고, 직책과 역할을 혼동하여 상하 계층을 만드는 것이다. 예를 들어, '아키텍트'와 '개발자'는 분명 역할로 구분되지만, 경험이 많고 직책이 높은 사람들이 주로 '아키텍트'를 담당하기 때문에 이 두 역할의 관계는 상하 계층 관계가 형성된다. 이와 같은 상황에서 '아키텍트'의 말은 곧 진리요, 명령이다. 이러한 관계는 역할이 가져야할 책임을 훼손하게 된다. 즉, '아키텍트'는 아키텍트로서의 책임을 수행함과 동시에 '개발자'의 책임 영역까지 침범해버린다. 즉, 모든 '개발자'의 작업에 대해 기계적인 절차를 준수하고, 일거수 일투족을 감시하려고 하게 된다. 이를 좀 더 강하게 제약하는 경우에는 결국 모든 틀만을 제시하고, 그 틀안에서 개발자가 수행하도록 강요하게까지 한다.

이를 복지의 개념으로 비교해보면, 역할을 동등 관계가 아닌, 상하 계층 관계를 가지는 경우, 상위의 기술자(아키텍트)는 자신이 하위의 기술자(개발자)보다 더 많은 기술을 가지고 있고, 이를 하위의 기술자들에게 혜택을 부여하도록 하는 행위를 한다. 즉, '잔여적 복지'의 형태이다. 이는 잔여적 복지의 단점인 차별을 만들고, 못가진자로 하여금 상처를 주게 된다. 또한, 가진 자(아키텍트)는 자신의 기술을 못가진 자(개발자)에게 베풀었다는 생각으로 못가진 자(개발자)를 불평하고, 비난하게 된다. 또한, 자신이 가진 기술이 대단한 것인양 못가진 자(개발자)에게 베풀기를 주저하는 핵심적인 내용이 있다고 믿는다. 이러한 '잔여적 복지'의 형태는 결국 가진 자라고 생각하고 있는 역할을 가진 사람의 기술 배척 사상을 낳게 된다. 즉, 자신이 경험한 기술 이외의 것에 대해서는 전혀 인정하지도 않으며, 받아들이지도 않는다. 물론, 이러한 형태는 빠른 결정과 신속한 개발을 진행할 수도 있겠지만, 가진 자(아키텍트)의 판단에 따라 모든 것이 진행되기 때문에 전혀 고객이 원하지도 않고, 본인이 생각하지도 못한 결과를 낳는 경우가 많다. '잔여적 복지' 역시 적은 재정으로 짧은 시간 안에 보여지는 복지 정책을 취할 수는 있다. 

소프트웨어 프로젝트는 CEO나 CIO에게 당장 보고해야 하는 결과를 만들어내는 작업이 아니다. 이들의 입맛에 맞는 것을 만들려면 이들이 가진 생각만을 듣고 소프트웨어를 만드는 것이 훨씬 나을 것이다. (물론, CEO나 CIO는 중요한 이해관계자이다. 여기서 말하는 것은 CEO나 CIO가 소프트웨어가 갖는 기본적인 원리나 원칙을 제대로 이해하는 경우에는 상관없지만, 그렇지 못한 경우에는 어떻게든 올바른 소프트웨어가 만들어지도록 설득하거나 이해시키는 과정이 필요함을 뜻한다.) 당장에 눈에 보이지 않는다고 해서 '잔여적 복지'를 선택하여 포퓰리즘과 같은 효과를 보게 되면, 소프트웨어 아키텍처가 지닌 고유의 성질을 잃어버릴 가능성이 높다.

시간이 다소 걸리더라도 '보편적 복지'를 선택해서 '역할의 수평적 관계'를 이룬다면, 더 안정적인 상태에서 보다 나은 발전을 도모할 수 있을 것이다. 즉, 서로의 고유한 영역을 지키고, 책임을 침범하지 않도록 주의하면 더 창조적인 마이드를 통해 고객에게 더 가치있는 결과물을 인도할 수 있을 것이다.



저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 이거 2011.03.15 01:10 신고

    글 잘 읽고 가요~ 참고해도될까요?

    • Favicon of http://homo-ware.tistory.com BlogIcon javauser 2011.03.17 09:36 신고

      참고하셔도 됩니다만, 크리에이티브 커먼스 라이선스는 지켜주셨으면 합니다.

+ Recent posts