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

IT 아키텍처를 설명할 방법을 고민한 적이 자주 있다. 검색을 해 보면 공학적인 정의들은 많이 있다. 때로는 비유를 통해서 정의를 시도하는 경우도 있다. 생각해보면, 아키텍처라는 것이 IT나 토목, 건축에서만 사용되는 것은 아니기에 좀 더 일반적인 설명이 필요할 것 같다는 생각이었다. 

 

오늘 산책을 하다가 문득 아키텍처를 어떻게 설명할까를 다시 생각해보게 되었다. 우리는 어떤 일( 보통 프로젝트라고 부른다)을 할때는 보통 분석, 설계, 수행을 하고 그러고 나서 유지 보수 및 개선 활동을 하게 된다. 이것은 뭔가 구체적인 목표를 달성하기 위한 액션들이다. 

 

아키텍처는 이런 액션 차원과는 다른 차원의 목표를 갖는 플래닝이라 할 수 있을 것 같다. 다른 차원의 목표란 보통 품질이 된다. 예를 들어서 보안, 성능, 개발 생산성, 유지 보수성, 기밀성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등등. 아키텍처의 목표는 그 프로젝트에서 달성하기 위한 목표보다도 높은 차원의 목표이다. 즉 아키텍처의 목표는 그 프로젝트만 대상으로 하는 것이 아니라 그 주변의 환경과의 관계도 고려해야 한다. 조직의 목표와 정책과도 생각해야 하고, 그리고 프로젝트에 관련된 이해관계자들과의 관계 등도 고려해야 한다.즉 아키텍처의 목표는 분석, 설계, 개발, 유지 보수같은 '액션'을 잘 해 나가기 위한 목표와는 다르다는 것이다. 

구분	목표	고려 대상
아키텍처	품질 구현	액션, 액션 결과와 주변 환경과의 고려
액션(분석,설계,수행,유지보수,개선)	프로젝트 결과 구현	프로젝트 결과

 

프로젝트의 각 단계에도 그 단계를 잘 수행하기 위한 방법론들이 많이 있다. 요구사항 분석을 잘 하기 위한 방법론, 설계를 잘 하기 위한 방법론, 프로젝트 수행을 잘 하기 위한 방법론, 유지 보수 및 개션을 잘 하기 위한 방법론. 각 방법론들도 각 단계의 작업을 잘 수행하기 위한 품질 목표가 있다. 그러나 이런 품질 목표보다 더 높은 것은 아키텍처에서 고려하는 품질 목표이다. 즉 액션을 위한 모든 방법론들은 조직의 아키텍처에서 정의하고 있는 품질 목표의 제약을 받아야 한다. 

 

아키텍처는 프로젝트 자체에도 제약을 주게 되지만, 그것과 주변 요소들과의 관계에도 제약하게 된다. 즉 아키텍처는 관련있는 주변의 요소들간의 관계를 분석하고 설계하고 그 관계를 만들고 그 관계를 유지 보수하고 개선하는 것이 아키텍처 차원에서 하는 일이다. 즉, 프로젝트는 목표로 하는 대상 그 자체를 만들어 내는 것이 최종 목표라면, 아키텍쳐는 관계를 만들고 유지 보수하는 것이 목표라고 할 수 있다. 

 

주변과의 관계를 정의한 것이 아키텍처인 이유 때문에, 아키텍처는 프로젝트와 관련있는 다른 주변의 이해관계자들과의 의사 소통을 하기 위한 도구로 사용되는 것이 주요 용도이다.