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

이론적이고 공학적인 설명 말고, 일반적인 개념으로 설명 시도.  

아키텍처와 직접적으로 관련있는 말은 "관심사(concerns)"이다. 일과 프로젝트는 뭔가 문제를 해결하기 위한 요구사항이 있기때문에 시작된다. 그런데 그 문제를 해결하는데는 많은 관심 사항들이 존재한다. 다양한 관심사항들은 문제를 해결해나가는데 다양한 영향을 주게 된다. 일과 프로젝트에 존재하는 다양한 관심사들을 파악하는 것이 일을 성공시키기 위해서 매우 중요하다. 

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

이런 관심 거리들은 이해 관계가 있는 다양한 사람들 사이에 합의를 하고 의사 소통을 하기 위한 목적을 위해서 아키텍처라는 것을 정의하게 된다. 이론적으로는 모든 관심사를 모든 사람들과 합의해서 정의하고 지나가는 것이 맞겠으나, 인력이나 시간, 돈에 대한 리소스의 제약으로 특별히 관심을 가지고 봐야 하는 관심사만 아키텍처라는 형태로 합의가 될 것이다. 예를 들어서, 전체 조직에서 바라보는 관점에서의 계획과 실행, 결과를 바라보는 관점, 실행하는 조직에서 바라보는 계획과 실행, 결과를 바라보는 관점 등에 따라서 달라질 수 있다. 만약 기업 조직이라면 기업의 가장 상위 조직에서는 주로 결과물로 나오는 제품이나 서비스와 관련된 시장에 관심이 있을 것이다. 따라서 Time to market같은 것이 관심거리가 될 것이다. 또는 제품이나 서비스의 품질에 관심이 있을 것이다.  이런 비즈니스 관심사를 해결하기 위해 "비즈니스 아키텍처" 라는 이름으로 존재할 수 있다. 그리고 프로젝트를 실행하는 조직에서는 어떻게 하면 결과물을 해당 품질들에 적합하게 "잘 만들까"를 고민하게 될 것이고 이를 위해서 "소프트웨어 아키텍처", "보안 아키텍처" 등등의 이름으로 존재할 수도 있을 것이다.  

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

"참고로, 모든 일(프로젝트)을 하려면, 계획하는 단계를 거쳐서 실행에 옮긴다. 그리고 그 결과가 나온다.

계획--> 실행--> 결과(물)

그런데 (계획, 실행, 결과)도 수준과 차원과 관점에 따라서 같은 일, 프로젝트를 할때도 다양하게 존재한다.  (조직과 역할, 계획 단계, 실행 단계)에 따라서 다양한 관심사가 있고 그에 따라서 다양한 계획 단계와 다양한 실행 단계에서 다양한 목표가 선정된다. 그리고 다양한 목표에 따라서, (계획, 실행, 결과)도 다양한 차원에서 존재하게 된다. 

예를 들어서, 조직 차원의 전략 수립 단계에서도 (계획, 실행, 결과)가 있다. 그 조직의 최종 경영 목표와 조화를 이루도록 해당 프로젝트의 목표를 어떻게 결정할 것인가가 "계획"이라면 결정된 목표를 달성하기 위한 접근 전략과 실행 계획을 만드는 것 자체가 "실행"이라고 할 수 있을 것이다.  그리고 최종적인 실행 단계에서의 실행자(구현자)들이 작은 작업(태스크)을 할때도 나름의 (계획, 실행, 결과)가 있다. "

아키텍처라는 것은 각각의 관심사들을 어떻게 달성할 것인가 그리고 관심사에 충돌이 있다면 어떻게 해결할것인가를 설계한 결과물이다(아키텍처 설계, 구현과 프로젝트 설계,구현 그리고 결과물의 설계, 구현은 모두 차원이 다른 설계와 구현이다 ). 아키텍처가 정의된다는 것은 관련있는 사람들과 조직간의 의사 소통이 편하게 이뤄질 수 있도록 한다는 것을 말한다. 즉 의사 소통의 도구를 만드는 것이라고 볼 수 있게 되는 것이다. 이것이 아키텍처의 가장 큰 역할이라고 할 수 있다. 

아키텍처는 관심사가 다른 사람들간에 의사 소통을 할 수 있는 도구이다.

관심있는 범위를 정해서 그것을 어떻게 구현할 것인가에 대한 "원칙, 규칙, 지침" 등을 정해 놓은 것을 아키텍처라고 할 수 있다. 설계서가 실제 결과물을 만들기 위한 "도면"이라면, 아키텍처는 실제 결과물이 관심과 목표를 달성할 수 있도록 하는 "원칙"이라고 할 수 있다.  

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

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

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

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