"아키텍처"라는 것을 설명해보자v0.3

아키텍처 ! 이론적이고 공학적인 방법으로 설명하는 것 말고, 다른 방법으로 할 수 없을까 고민하고 정리해도 매번 실패로 끝난다. 이번에도 다시 시도해본다. 

▣ 이해관계자와 관심사(Concerns) 그리고 요구사항

아키텍처와 직접적으로 관련있는 말은 "관심사(concerns)"이다. 즉 다양한 사람들의 관심사가 있고 그 관심있는 일 때문에 그들의 요구 사항들이 나오게 된다. 이런 요구사항들때문에 프로젝트가 시작되고 그리고  요구 사항들은 프로젝트가 해결해야 하는 직접적인 대상이 된다. 그 프로젝트가 성공하기 위해서는 프로젝트와 관련된 다양한 관심사들을 파악하는 것이 매우 중요하다. 따라서 이런 관련자들, 그들의 관심사들, 그리고 요구사항들을 검토할 수 있는 프레임워크를 정의해두는 것은 매우 큰 의미가 있게 된다. 

물론 프로젝트가 성공하기 위해서는 "프로젝트를 잘 진행시켜야 한다". 그러나 프로젝트의 관심 있는 목표들이 제대로 파악되지 못한 상태에서 프로젝트 항해가 시작되면, 결국 최종 목적지에 도착하지 못하고 중간 어디쯤에서 어중간한 곳에서 항해가 끝나게 된다. 따라서 이해관계자들의 관심사들을 빼먹지 않고 체크해 볼 수 있는 프레임워크가 필요하게 된다. 

관심사는 다양한 사람들과 조직, 역할별로 존재하게 된다. 그리고 그 관심 거리는 다시 또 계획 단계와 실행 단계별로 세분화되고 그 단계의 관련된 사람들과 역할 별로 존재한다. 그래서 관심사는 그림에서처럼 (조직과 역할, 계획 단계, 실행 단계) 등에 따라서 존재하는 것으로 그려볼 수 있다. 이 그림은 큰 차원에서의 관심사를 검토하고 정의하는데 사용할 수 있는 프레임워크라고 할 수 있겠다. 

▣ 아키텍처의 역할

이렇게 다양한 이해 관계자가 있고, 그리고 그들의 관심사가 다르고 그에 따라서 다양한 요구사항들이 나오게 되면, 이런 것들을 분석하고, 통합하기 위해서는 그것들을 관리할 도구가 필요하다. 때로는 이해 관계자들간의 상충되는 생각을 서로 이해시키고 조정해야 할 필요가 있다. "아키텍처"라는 것은 이해관계자, 관심사, 요구사항을 관리하고 그리고 그것들을 조정하기 위해서 이해 관계가 있는 다양한 사람들 사이에 합의를 도출하기 위한 도구라고 할 수 있다. 

아키텍처의 역할

이해 관계자, 관심사, 요구 사항의 관리 도구

이해 관계자간의 의사 소통 도구

▣ 아키텍처 항목의 관리 구조

전체 조직에서 바라보는 프로젝트, 계획하는 조직과 역할에서 바라보는 프로젝트, 그리고 실행하는 조직에서 바라보는 프로젝트가 모두 다를 수 있다는 것이다. 즉 조직과 역할에 따라서 프로젝트에 대해서 원하는 다양한 관심사가 있을 수 있다.

모든 일을 하려면, 계획--> 실행--> 결과(물) 단계를 거친다. 이런 "계획, 실행, 결과"도 전체 조직, 계획 역할, 실행 역할에 따라서 따라서 각각 나오게 된다.  복잡하다. 조직과 역할이 있고 그 조직과 역할별로 관심사와 요구사항들이 있고, 조직과 역할별로 "계획, 실행, 결과"가 있다. 이것들을 모두 아키텍처에서 관리해야 한다.  

현실적으로, 모든 요구 사항들을 아키텍처에 포함시킬 수는 없다. 특별히 관심을 가지고 봐야 하는 관심사들과 요구사항들만 포함되어서 관리될 것이다. 요구사항의 구현은 모두 인력이나 시간, 돈 같은 제한된 리소스들이 필요하다는 의미이기 때문이다.

▣ 미리 정의된 아키텍처

전체 조직의 관점에서 관리가 중요하다고 생각되는 뷰포인트(viewpoint)들을 특별히 관리하게 위해서 미리 정의해 놓은 아키텍처들이 있다. 만약 가장 상위의 조직이 기업이라면 가장 상위 조직에서는 결과물로 나오는 제품이나 서비스와 관련된 시장에 관심이 있을 것이다. 따라서 Time to market같은 것이 관심거리가 될 것이다. 또는 제품이나 서비스의 품질에 관심이 있을 것이다.  이런 비즈니스 관심사를 해결하기 위해 "비즈니스 아키텍처" 라는 이름으로 존재할 수 있다. 그리고 프로젝트를 실행하는 조직에서는 어떻게 하면 결과물을 해당 품질들에 적합하게 "잘 만들까"를 고민하게 될 것이고 이를 위해서 "소프트웨어 아키텍처", "보안 아키텍처" 등등의 이름으로 존재할 수도 있을 것이다.  이런 미리 정의된 아키텍처들에서는 해당 관점에 따라서 관리해야 하는 포인트들, 항목들이 미리 정의되어 있다.

▣ 의사 소통 도구로서의 아키텍처

아키텍처 관리 항목들로 정의된 이해 관계자 그리고 조직과 역할 그리고 실행 단계별로 정의된 관심사항, 요구사항 들을 분석해서 서로 상충되는 것들이 별견되면, 관련있는 사람들끼리 대화를 해야 한다.  예를 들어서, 계획과 실행을 담당하는 조직이 화려한 결과를 예상하고 있다면, 시간과 돈을 제공하는 최고 조직과 협의를 하도록 자리를 마련해야 한다. 

이처럼, 아키텍처가 정의된다는 것은 관련있는 사람들과 조직간의 의사 소통이 편하게 이뤄질 수 있도록 한다는 것을 말한다. 즉 의사 소통의 도구를 만드는 것이라고 볼 수 있게 되는 것이다. 이것이 아키텍처의 가장 큰 역할이라고 할 수 있다. 

다양한 이해 관계에 있는 사람들의 합의와 의사 소통을 위해서 아키텍처가 정의된다. 

▣ 아키텍처는 "원칙"들의 모음 

아키텍처는 이런 의사 소통을 통해서 관련자들과 합의를 하고 그래서 그 프로젝트에 대한 "원칙"이 만들어진다. 그리고 원칙에 부합하는 "규칙들"도 정의되기도 한다. 설계서가 실제 결과물을 만들기 위한 "도면"이라면, 아키텍처는 실제 결과물이 관심과 목표를 달성할 수 있도록 하는 "원칙"이라고 할 수 있다.  

설계가 도면이라면, 아키텍처는 설계 원칙이라고 할 수 있다 

따라서 아키텍처를 사용하면 구체적인 구현 차원이 아니라 좀 더 높은 수준 차원에서 대화를 할 수 있도록 하는데 중요한 역할을 한다. 다른 말로 하면, 구체적인 rules가 아니라 principles의 모음이라고 할 수 있다. 규칙은 해당 환경과 상황에 특정한 모양으로 구체화되어서 고정된다. 그러나 principles은 규칙보다 좀 더 일반적인 가치와 원리를 갖는다.  

따라서 구현과 관련된 아키텍처라고 할지라도 실제로 구현하는데 사용하는 기법이나 방법, 도구 등은 아키텍처 정의에서 거의 없을 것이다. 대신에 구현에 대한 원리와 원칙을 정의할 것이다. 즉 구현은 특정한 품질을 달성하도록 되어야 한다는 식으로. 그리고 그 품질을 달성하기 위해서 좀 더 구체적인 원칙을 정할 수도 있다. 또한 어떤 아키텍처는 경영 차원이나 또는 결과물과 관련되어 있는 조직들간의 이해 관계와 같은 대화에서도 사용된다. 

▣ 아키텍처란? 

아키텍처라는 것은 (조직과 역할, 계획 단계, 실행 단계) 그리고 결과물 등과 관련된 다양한 관심사들과 요구사항들을 구현하는 것 그리고 그와 관련이 있는 모든 것들을 계획에서 부터 실행까지 설계해 놓은 원칙, 원리라고 할 수 있을 것같다.  

또 공학적으로 가버린 기분이(-_-;;)