"아키텍처"에 대하여
쓸모 있는 모듈러 디자인
회사마다 모듈러 디자인 활동을 지칭하는 바가 다릅니다.
다 그런 건 아니지만, 모듈러 디자인이란 용어를 강조하면 제품보다는 활동을 우선시하는 경향이 있고,
모듈러 아키텍처란 용어를 강조하면 활동보다는 제품에 대한 변화를 우선시하는 경향이 있습니다.
물론, 모두 중요합니다만, 전자의 경우는 모듈러 디자인 활동 중 모듈러 오퍼레이팅 활동을 부각시키고,
후자의 경우는 모듈러 디자인 활동 중 모듈러 아키텍처링 활동을 부각시킵니다.
어쨌든, 아키텍처는 모듈러 디자인 활동의 핵심 개념 중 하나입니다. 순서를 꼽자면 모듈, 인터페이스 다음 정도 아니면 소개 순서 상 아키텍처를 가장 먼저 소개해야 맞는다고 생각합니다. 실제로 교육할 때도 아키텍처 용어부터 시작하는 경우가 많습니다.
그런데, 순서가 모듈화 다음으로 밀린 건 예전에 아키텍처에 대한 글을 쓴 적이 있기 때문에 내용이
겹치기 때문이었습니다.
아키텍처 교육 시 항상 같은 말을 합니다.
"구글에서 검색해서 아키텍처에 대한 정의가 몇 가지가 나오는지 세어보세요."
아키텍처에 대한 확실하게 세부적인 사항까지의 이해보다는 넓은 틀을 잡는 데 집중하면 좋을 것 같습니다.
1. 아키텍처의 대상은 시스템입니다.
아키텍처는 아키텍처 앞 쪽에 어떤 단어가 붙느냐에 따라서 의미가 달라집니다. 소프트웨어 아키텍처, 하드웨어 아키텍처, 조직 아키텍처, IT 아키텍처, 기업 아키텍처 등등... 영역 별, 분야 별로 동일한 단어를 쓰고 있지만, 다른 의미가 됩니다.
대신 동일한 점은 있습니다. 아키텍처의 대상은 시스템이고, 아키텍처 용어 앞에 붙는 용어는 대체로 시스템이란 점입니다. 예를 들어서, 소프트웨어 아키텍처는 소프트웨어 시스템에 대한 아키텍처, 하드웨어 아키텍처는 하드웨어 시스템에 대한 아키텍처, 조직 아키텍처는 조직이라는 시스템에 대한 아키텍처, IT 아키텍처는 IT 시스템 또는 체계에 대한 아키텍처, 기업 아키텍처는 기업이라는 시스템의 아키텍처를 의미합니다.
아키텍처에 어디에 쓰이든지 아키텍처의 대상은 시스템이다는 점을 먼저 명확히 알아두면 용어 이해에 도움이 됩니다.
2. 아키텍처는 청사진입니다.
앞서 아키텍처의 대상은 시스템이라고 했습니다. 그렇다면, 시스템과 어떤 관계일까요? 시스템을 현실에 만들기 전에, 만든 후라도 한눈에 파악하기 위해서는 어떤 도구가 필요합니다. 결국 사람과 사람이 서로 의사소통할 수 있는 시스템에 대한 조감도, 청사진 같은 게 필요한 거죠. 그것이 아키텍처입니다. 시스템은 아니지만, 시스템이 가진 핵심을 표현한 청사진이 아키텍처입니다.
3. 아키텍처는 구성입니다.
그렇다면 아키텍처가 말하는 시스템의 핵심은 무엇일까요? 그것은 시스템을 구성하는 요소와 요소 간의 관계입니다. 이것을 하나의 용어로 구성이라고 표현합니다. 아키텍처 안에는 시스템이 가지고 있는 요소들, 그리고 요소들이 어떻게 정적인 관계를 갖고, 어떻게 동적인 작용을 하는지를 표현하고 있습니다.
4. 아키텍처는 설계의 대상입니다.
시스템의 구성은 설계라는 과정을 통해서 정해집니다. 시스템이 갖추어야 하는 속성, 기능이 결정되면 설계자는 설계라는 작업을 통해서 아키텍처를 만들어 냅니다. 속성, 기능은 시스템이 갖추고 있는 언어적 표현이고 그것을 실체로 표현하는 데 그것들이 앞서 설명한 시스템의 요소와 관계, 즉 아키텍처의 내용이 됩니다.
아키텍처는 설계 중에서도 상위 설계/개념 설계의 결과물입니다. 설계 과정은 상위 설계/개념 설계, 하위 설계/상세 설계라 나눠지는데, 아키텍처는 시스템의 큰 틀을 잡는 상위 설계/개념 설계의 결과물입니다.
5. 아키텍처는 설계자의 의도를 포함합니다.
아키텍처가 상위 설계/개념 설계의 결과물이기 때문에 기본적으로 아키텍처는 시스템이 갖추길 바라는 설계자의 의도가 포함되어야 합니다. 시스템의 요구사항이 분석된 후에 가장 처음 만들어지는 시스템의 모습이 아키텍처이기 때문에 당연하게도 설계자의 의도가 직간접적으로 포함이 되어있어야 하고, 이대로 하위 설계/상세 설계 시 시스템의 살이 붙어가야 합니다.
6. 아키텍처는 설계자의 컨셉을 표현합니다.
설계자의 의도가 포함된 아키텍처는 설계자가 제시한 컨셉으로 그것을 표현합니다. 즉, 의도는 설계자의 생각, 주관이라고 한다면 컨셉은 그 생각과 주관이 표현된 것입니다. 그리고, 표현한 결과물이 아키텍처가 되는 것입니다. 보통은 설계자의 의도와 설계자의 컨셉을 구별하지 않지만, 명확히 말하면 설계자의 의도도 다양한 컨셉으로 표현될 수 있기 때문에 구별하는 것이 맞습니다.
7. 아키텍처는 디자인 규칙의 집합입니다.
설계자가 만든 아키텍처를 받아서 작업하는 참여자들에게 이걸 지켜야 한다고 매번 강제화하는 건 불가능합니다. 그래서, 만들어 둔 것이 아키텍처가 포함한 디자인 규칙입니다. 이것을 지켜서 설계하고 구현하면 최대한 초기 설계자의 의도와 컨셉을 준수하며 시스템을 만들어내는 거죠.
8. 아키텍처는 의사결정의 도구이자 결과물입니다.
복잡한 시스템은 한 명의 설계자와 개발자로 완성되지 않습니다. 다수의 이해관계자가 참여를 하고, 그것을 구현하는 과정에서 다수의 인원이 참여하게 됩니다. 그런데, 초기에 설계자의 의도대로, 컨셉대로 시스템을 만들기 위해서는 그것을 표현한 무언가 도구가 필요합니다. 그것이 아키텍처입니다. 시스템이 갖출 속성 들은 상충하는 것이 대부분입니다. 그것들을 조율하고 최적의 시스템을 만들기 위해서도 눈에 보이는 도구가 필요합니다. 그 역할을 아키텍처가 담당합니다. 아키텍처는 의사결정의 도구이자 결과물입니다.
9. 아키텍처는 진화합니다.
매번 새로운 시스템을 만드는 것이 아니라면 경험과 노하우가 쌓이면서 시스템은 진화하게 됩니다. 시스템은 진화하게 되고, 시스템의 아키텍처 또한 진화하게 됩니다. 물론, 시스템의 세부 변화보다는 아키텍처의 진화는 느립니다. 그렇지만, 어쨌든 변화한다는 것을 의미합니다.
10. 아키텍처는 표준화의 대상입니다.
아키텍처가 변화하기 때문에 표준화가 필요합니다. 하나의 시스템에서는 디자인 규칙을 정의하는 것이 표준화의 일환이라고 할 수 있습니다. 세대 간 변화하는 시스템, 다양한 시스템들은 효율성을 잃지 않기 위해서, 과거의 시스템보다 진화하기 위해서 지켜야 할 규칙들이 있습니다. 그것이 표준화의 대상입니다.
이번 글을 통해서 아키텍처에 대한 완벽한 이해보다는 틀을 잡는 데 도움이 되길 기대한다고 했습니다.
아키텍처는 명확하게 한글로 번역할 수 있는 용어가 없죠?
가장 적합하다고 생각하는 용어의 정의를 외우는 것도 도움이 되겠죠.
그렇지만, 이해가 뒷받침되지 않은 암기는 활용하기 어렵죠.
이런 용어일수록 자신만의 기준을 잡는 것이 중요합니다.
