본문 바로가기

Dev.../소프트웨어 아키텍처

아키텍처 스타일에 대한 짧은 메모…

 

아키텍처 스타일에 대한 말을 서술하려면 패턴에 대해서 이야기를 서술하지 않을 수 없다. 따지고 본다면, 아키텍처 스타일이란 또 다른 의미의 패턴이기 때문이다.

다만, 그 스케일과 활용성의 차이점 때문에 따로 기술하는 것이 아닐까 한다.

 

따지고 보면, 패턴이란 '지식'을 좀더 구체적으로서 서술한것이라고 볼 수 있다.

 

'지식' + '경험' + '명확한 표현'

 

이렇게 3가지의 특징으로 표현하면 좀더 구체적이지 않을까 한다.

보통 사람들이 이해하는 초보자와 전문가의 차이점은 바로 이러한 '경험'을 어떻게 활용하는가에 따라서 구분되어지는 것이고, 거기에다가 이러한 '지식' + '경험'을 '명확하게 표현'하는 것을 다르게 표현한다면 '패턴'이라고 불릴 수 있겠다.

 

'패턴'이 되려면… '명확하게'표현되므로써 혼동없이 해당 '지식'과 '경험'이 전달되어야 하기 때문이다. 다만, 차이점은 이러한 '패턴'은 그대로 Copy & Paste되는 것이 아니라 새로운 '경험'에 의해서 새로운 것이 되기 때문에 그 숙련도와 활용도에 따라서 많은 변형이 발생하기도 하기 때문이다.

 

개발자들은 '패턴'을 사용하면서도… 자기 나름대로의 해석으로 이 패턴을 활용하여 진정한 의미의 '패턴'사용을 제대로 못하는 경우도 많기 때문이다. ( 생각보다 많다. )

 

가장 많이 사용되는 패턴의 예제는 '게으르고 영악한 건축가 이야기'라는 예제에서 사람들이 가장 많이 돌아다니는 '행동'에 대한 정의라고 기술한 표현이 좀더 명확할 것이다.

 

정말 전문가들은 실제 '일'을 하는 사람들의 그러한 '경험'을 정확하게 도출하게 하는 방법을 아는 사람들이기 때문이다. 제가 요즘 잘 사용하는 Information Developer라는 ID라는 용어를 쓰기 시작했는데.

 

기존의 SW Developer와는 관념적인 차이를 좀 보인다. ~.~

 

좌우당간, 패턴은 항상 같은 방식으로 적용할 수는 없지만. 계속 반복해서 사용할 수 있는 그러한 것이다라는 것.

 

솔루션이나 해결책이란 다양한 방법으로 표현되고 기술되어진다. 패턴이란 이러한 여러 문제점들을 해결하기 위해 시도하다가 특정한 문제점에 대해서 반복해서 처리할 수 있는 해결책을 의미한다.

 

다만, 그것을 미시적인 소프트웨어 개발에서 패턴이라는 이름하에 알고리즘을 구사하는 정도의 의미로 사용되는 의미축소 때문에… 아키텍처 스타일이라는 단어가 나타났다고 생각한다.

 

따지고보면… 그냥 다 패턴이다. ~.~

 

물론, 이러한 아키텍처 스타일이나 패턴에 있어서 가장 중요한 것은 '명확한 표현'이다.

 

그것은 문서와 해결책에 대한 간단명료한 설명과 협력을 쉽게 하기 위한 논쟁을 줄이는 것이 핵심이기 때문이다.

 

자.. 그렇다면 이러한 패턴들은 어떤 형식을 이루고 있을까? 주요특징들을 알아보자.

 

  1. 패턴은 반드시 문서의 형태로 존재되어야 한다.
  2. 기본적인 구성항목은 다음과 같은 형식을 가져야 한다.
    1. 이름(name) – 패턴이 다루는 문제와 해결책을 연상하도록 하는 쉬운 단어를 사용하고 널리 사용되는 단어를 사용하는 것이 좋다.
    2. 문제(problem) – 이 패턴이 해결해야 하거나 처리해야할 목표를 명확하게 서술하여야 한다. 그래서, 문제의 세부항목에 상황(context)와 압박요인(forces)를 잘 기술하여야 한다.
      1. Context는 이 패턴을 적용할 구체적인 조건들을 의미한다.
      2. Forces는 문제가 생기게된 원인을 설명한다.
    3. 해결책(solution) – 원하는 결과를 얻는 방법을 구체적으로 서술하는 관계, 규칙을 기술한다. 머, 다이어그램도 좋고… 코드도 좋다. 중요한것은 '읽기 쉬워야 한다'는 것이다.
    4. 예제(example) – 당근 활용하기 좋은 예제를 기술해야 한다.
    5. 결과(resulting context) – 이 패턴을 적용할때에 발생되어지는 모든 변화를 기술한다.
    6. 원리(rationale) – 문제의 원인을 어떠한 방식으로 처리하고 조화시켰는지에 대해서 서술한다.
    7. 관련패턴(related patterns) – 비슷하거나 파생된, 그리고, 이용한 패턴들, 혹은 이용하게 될 패턴들을 기술한다.
    8. 알려진 사례(known uses) – 이 패턴을 잘 활용한 사례들을 기술한다.

 

하여간… 자세하게 파고들어가면 소프트웨어 공학이나 소프트웨어 개발자체의 행위 자체가 모두다 패턴이 아닌가 한다. ~.~

 

자.. 여기서 논쟁거리 하나 서술해보자.

 

본인은 서두에 아키텍처 스타일이 아키텍처 패턴이라고 선언해 버리고 글을 이어가고 있다.

하지만, 이것은 본인의 생각일 뿐… ~.~

그렇지 않다고 생각하는 수많은 개발자들이 존재한다는 것을 염두에 두자.

아키텍처 패턴과 아키텍처 스타일을 '해결책'과 '패션(fashion)'의 경쟁구도로 보는 경우도 많기 때문이다. 머, 아키텍처라는 개념 자체가 워낙에 거대하다보니… '품질'요소나 속성까지 거술해서 설명하다보면.. ~.~

 

한도 끝도 없다는 것이다.

 

머, 그것을 이론적으로 증명하려는 다양한 시도가 있지만… 그것은 전공하신분들의 숙제로 맞겨두고, 현재의 2008년 실무적인 환경에서 비교하자면… 별다른 차이가 없이 약간의 View차이만 존재하기 때문에 유사하다라고 생각하자.

 

자.. 그렇다면 이러한 아키텍처 스타일의 원조(?)인 건축용어에서는 어떠한 의미로 사용되었는지 알아보자.

 

건축에서는 이러한 아키텍처 스타일을 건물의 외관, 실내장식, 가구배치등을 결정하게 하는 중요한 결정사항으로, 건물안에서 사는 사람들의 생활방식까지도 결정하게 하는 개념이다.

 

좀 설명이 Cool하지 못하다.

그래서, 좀더 자세하게 설명하자면…

 

~.~

 

아키텍처 스타일은 '아키텍처 설계에서 반복적으로 나타나는 문제점을 해결할 수 있는 품질속성들을 어떻게 달성할 수 있는지 명확한 표현으로 문서로 만들어 놓은 것'이라고 서술해보자.

 

~.~

자 2부는… 내일.. (쿨럭~)