brunch

매거진 모듈러 디자인

라이킷 14 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김진회 May 15. 2024

이것은 아키텍처가 아니다

아키텍처 수업

최근 읽고 있는 컨셉 수업이라는 책에 “이것은 컨셉이 아니다”라는 소챕터가 있습니다. 컨셉과 유사한 용어와 구분하여 컨셉의 개념을 명확히 전달하고자 하는 목적이겠죠.

본 글에서는 컨셉 수업의 형식을 빌려서 자주 아키텍처와 혼용하는 개념과 구분함으로써 아키텍처의 개념을 명확히 하고자 합니다. 실제로도 이해하기 어려운 개념을 명확히 하기 위해서 그와 비슷하거나, 혼동하기 쉬운 개념과의 차이를 설명하는 식의 교육법도 있죠.

1. 아키텍처는 스트럭처 (Structure), 구조가 아니다.

가장 많이 혼용하고 있는 개념이고, 제가 아키텍처 교육을 할 때 자주 구분 짓는 개념 중 하나입니다. 아키텍처와 구조는 둘 다 설계라는 활동의 결과물입니다. 아키텍처는 설계 활동 중에서 상위 설계, 개념 설계의 결과로 만들어지는 결과물인 반면에 구조는 하위 설계, 상세 설계의 결과로 만들어지는 결과물입니다.

아키텍처는 시스템의 컨셉, 목적, 방향성을 지키기 위해서 활용되는 최소한의 방향 추 역할을 하는 반면에, 구조는 시스템 구현의 결과물로 볼 수 있습니다. 또는 아키텍처는 시스템이 가져야 하는 상위 기능과 하위 기능 간의 매핑 또는 기능과 구조 간의 매핑이라고 한다면, 구조는 상위 구조와 하위 구조 간의 매핑으로 볼 수 있습니다.

2. 아키텍처는 플랫폼 (Platform)이 아니다.

특정 산업 군에서는 아키텍처와 플랫폼을 동일한 개념으로, 또는 아키텍처가 플랫폼의 향상된 개념 정도로 설명하고 있습니다. 그리고, 아키텍처라는 개념이 새로운 트렌드인 것처럼 영역 관계없이 사용하다가 한물 간 개념인 듯이 기억 속에서 지우는 촌극도 벌어집니다.

사실 아키텍처와 플랫폼은 서로 비교할 수 없는 개념입니다. 아키텍처는 시스템이라면 당연히 가져야 하는 상위 수준의 시스템 구성이고, 플랫폼은 다수의 시스템 또는 제품이 공통으로 활용하는 설계, 운영, 활용 상의 자산을 의미합니다. 둘 다 없을 순 없으나, 두 가지가 서로 대치되는 개념은 아닙니다.

굳이 나눈다면, 아키텍처는 시스템이 구현되기 전, 즉 생성하기 전부터 시스템의 가치를 결정짓는 설계 산출물인 반면에, 플랫폼은 여러 시스템이 공유하는 자산이므로, 이미 구현된 결과물입니다. 제품으로 따지면 반제품 정도가 되겠죠.

3. 아키텍처는 모듈 (Module)이 아니다.

플랫폼 아키텍처를 대치하는 모듈러 아키텍처가 유행하면서 플랫폼과 모듈을 서로 대응하는 개념으로 생각하더니, 간혹 모듈이라는 개념을 아키텍처로 대치하는 경우가 발생하기도 합니다. 그래서 플랫폼과 아키텍처가 서로 비교되는 대상이 되는 상황이 발생하죠.

앞서 언급한 것처럼 아키텍처와 플랫폼이 서로 비교할 수 있는 개념이 아닌 것처럼 당연히 모듈과 아키텍처는 서로 비교할 수 없는 개념입니다. 모듈은 시스템을 구성하는 요소 단위로 시스템을 모듈 단위로 표현을 한 결과물이 모듈러 아키텍처, 플랫폼을 중심으로 표현하면 플랫폼 아키텍처라고 부릅니다. 복수의 제품을 기준으로 설명할 때는 모듈 단위로 다수의 제품을 표현한 것을 모듈 기반의 제품군 아키텍처로 모듈러 아키텍처를 정의하고, 플랫폼 단위로 다수의 제품을 표현한 것을 플랫폼 기반의 제품군 아키텍처로 플랫폼 아키텍처를 설명하죠.

당연히 모듈과 아키텍처는 서로 비교할 수 있는 단위가 아닙니다.

4. 아키텍처는 프레임워크 (Framework)가 아니다.

프레임워크와 플랫폼을 서로 혼용하는 것은 이해할 수 있습니다. 프레임워크도 반제품이라는 개념을 가지고 있거든요. 단, 정확하진 않지만 프레임워크는 구현하기 전의 반제품, 플랫폼은 구현한 후의 반제품으로 이해해도 무방합니다.

소프트웨어에서 프레임워크는 개발 환경, 개발 툴, 공통 라이브러리, 모듈을 포함한 반제품 형태로 그것을 따라서 제품을 만들면, 시스템이 갖춰야 할 아키텍처 패턴을 준수하여 개발할 수 있게 됩니다. 그래서, 프레임워크는 내부에 이미 시스템 아키텍처를 가지고 있어서, 그것을 신경 쓰지 않고 개발자가 소프트웨어를 만들 수 있습니다. 소프트웨어에서는 플랫폼은 공통 운영 환경의 개념이 강합니다. 설계, 개발하는 과정에서 활용되는 자산이 아니라, 신규로 개발할 소프트웨어가 운영되는 공통 서비스, 공통 환경 등을 플랫폼이라고 부르는 경향이 있습니다.

자, 정리하면 아키텍처와 프레임워크의 차이는 다음과 같습니다. 시스템이 가져야 할 아키텍처에 따라서 신규 소프트웨어를 개발할 수 있도록 제공한 개발 환경, 개발 툴, 공통 라이브러리, 모듈 등 반제품이 프레임워크입니다. 아키텍처가 프레임워크에 포함되어 있다고 볼 수 있죠.

5. 아키텍처는 시스템 (System)이 아니다.

아키텍처는 시스템을 대상으로 한 설계 산출물이죠. 시스템은 이미 태어난 존재인 반면에 아키텍처는 시스템이 태어나기 전부터 시스템의 존재의 가치를 결정짓는 존재입니다.

6. 아키텍처는 기능 전개도 (Function Decomposition)이 아니다.

가끔씩 시스템이 가져야만 하는 기능을 나열해 놓고, 이것을 아키텍처라고 부르는 경우가 있습니다. 물론, 아키텍처를 표현하는 산출물 중 하나가 기능 전개도 일 수도 있습니다. 그렇지만, 아키텍처는 시스템의 가치, 목적을 달성하기 위해서 설계되어야 하는 결과물입니다. 그것이 단순히 기능 전개도만으로 충분할까요? 만약 그렇다면 그것을 아키텍처로 볼 수도 있겠죠.

그것이 아니라면, 시스템 동작하는 방식을 표현해야 할 수도 있고, 시스템의 구성을 표현해야 할 수도 있고, 구현하고자 하는 시스템의 종류에 따라서 그것은 다양할 겁니다.

7. 아키텍처는 전략 (Strategy)가 아니다.

전략은 목적을 달성하기 위한 행동의 방향성을 의미하죠. 그런 의미에서는 얼핏 보면 아키텍처와 비슷하게 들립니다. 게다가 앞에 어떤 단어가 붙느냐에 따라서 어색함 없이 사용할 수 있다는 공통점도 가지고 있습니다. 그렇지만, 엄연히 다른 개념입니다. 전략은 앞으로 개시할 액션을 대상으로 합니다. 반면에 아키텍처는 대상이 시스템입니다.

8. 아키텍처는 컨셉 (Concept)이 아니다.

제가 예전에 좀 더 아키텍처를 쉽게 표현한다고 아키텍처 = 구조 + 컨셉이라고 설명한 적이 있습니다. 물론, 정확한 개념은 아닙니다. 아키텍처는 시스템의 가치를 설계하기 위해서 컨셉을 활용하고 이를 토대로 만들어진 결과물입니다. 즉, 컨셉을 통해서 만들어진 결과물이 아키텍처인 셈이죠. 둘은 떼려야 뗄 수 없는 개념이지만, 같을 순 없는 개념입니다.

9. 아키텍처는 청사진 (Blueprint)가 아니다.

많이 의아해 할 수 있습니다. 건축을 메타포로 아키텍처의 예시로 청사진을 가장 많이 활용하는 데 다른 개념이라니, 물론 청사진이 시스템 아키텍처의 하나의 표현일 순 있습니다. 그렇지만 그것은 특정 산업에서는 그럴 수 있는 것이고, 아키텍처의 표현으로는 청사진이 충분치 않을 수 있습니다. 그래서, 아키텍처의 표현 중 하나가 청사진이지만, 청사진을 아키텍처로 볼 순 없습니다. 그 속에 시스템 컨셉이 담겨 있지 않으면 그것은 설계 산출물 중 하나일 뿐입니다.