기고 | 기술 아키텍처 평가하기 ‘11가지 핵심 기준’

기술 아키텍처(Technical Architecture)는 정보 기술의 진화를 서술하고 평가하고 계획하도록 알려주는 접근법이다. 

지난 글 ‘기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드’에서 살펴본 것처럼 기술 아키텍처를 설명하기 위한 프레임워크는 포트폴리오와 하위-포트폴리오로 나뉜다. 예를 들어 애플리케이션(기록, 통합, 위성 앱 시스템), 데이터(구조적 및 비구조적), 기술(설비, 인프라, 플랫폼) 등이 대표적인 요소다.

이 프레임워크는 IT가 가진 것을 식별하고 분류하는 것을 가능하게 한다. 그러나 이것만으로는 부족하다. IT가 가진 것이 IT가 가져야 하는 것인지를 알기 어렵다. 이 글에서는 이 난제를 다룬다. 이제 기술 아키텍처를 평가하는 핵심 기준을 살펴본다.

기술 아키텍처에 대한 2가지 시각 
기술 아키텍처에 대한 설명은 2가지 보완적 시각, 즉 홀리스틱 디자인(holistic design)과 포트폴리오 시각(portfolio view)으로 나뉜다.

홀리스틱 디자인(Holistic design)은 아키텍처의 각 구성요소가 무엇을 하는지 (구성요소가 제공하는 역량), 그리고 구성요소들이 어떻게 결합해 개별 부분으로부터 기능적 전체를 형성하는지를 설명한다. 

반면 포트폴리오 시각(Portfolio view)은 투자 이론에 뿌리를 둔다. 이는 기술 아키텍처 내의 구성요소를 투자 포트폴리오 내의 주식과 동일하게 취급한다. 투자자는 정기적으로 포트폴리오를 검토하여 어떤 주식을 더 매수할 것인지, 그대로 유지할 것인지, 매도할 것인지 결정한다.

테크니컬 아키텍트는 기술 포트폴리오의 각 구성요소의 건전성을 정기적으로 검토하여 어떤 구성요소가 표준으로서 유지되어야 하는지, 어떤 요소를 배제한 후 필요한 기능을 제공할 더 우수한 대안을 도입할 것인지 결정한다.

그러나 투자자와 달리 테크니컬 아키텍트는 매수, 보유, 매도 외에도 더 많은 선택지를 갖는다. 테크니컬 아키텍트는 이러한 선택지를 ‘배치(Dispositions)’라고 부른다.

만약 홀리스틱 디자인이 없다면 IT가 부실하게 인식된 수많은 개체를 바라볼 것이라는 사실만 유의할 필요가 있다. 포트폴리오 시각이 없다면 적절한 엔지니어링을 거친 종이 집을 보게 될 것이다. 모든 것이 맞춰졌지만, 그 안에서 살고 싶지는 않을 집이다.

비즈니스 아키텍처 및 연결 방식 
기술 아키텍처를 일관적으로 설계하고 계획하는 일은 여러 애플리케이션과 각 애플리케이션이 지원하는 비즈니스 기능에 매핑하지 않고서는 불가능하다. 따라서 비즈니스 아키텍처를 기술하는 사람은 아래의 4가지 핵심 정보를 IT 부서의 테크니컬 아키텍트에게 제공해야 한다.

분류(Taxonomy). 이는 비즈니스 기능의 분류를 의미한다. 3가지 수준, 즉 기능(Capabilities) (L1), 책임(Responsibilities) (L2), 프로세스(Processes) (L3) 정도면 충분하다. 예를 들어 HR 은 (L1) 급여 관리를 (L2) 포함하고, 이는 차례로 급여 명부를 (L3) 포함한다. 마찬가지로 재무 및 회계는 (L1) 수취 계정을 (L2) 포함하고, 이는 수금을 (L3) 포함한다. 굳이 전문용어를 사용하겠다면 분류를 BCM(Business Capability Model: 비즈니스 기능 모델)이라고 불러도 된다.

매핑(Mapping). 두 번째 핵심 정보는 BCM내의 기능이 어떤 애플리케이션에 의존하는가를 파악하는 매핑이다. 비즈니스 아키텍트는 이들을 그냥 기능(L1) 수준에서 매핑하고 싶을지 모른다. 그러나 L2와 L3의 매핑이 없다면 BCM은 효용이 제한적이다.

평가(Assessment). 3번째 핵심 정보는 각 BCM 기능의 전반적 유효성의 평가이다.

중요성(Importance). 4번째 핵심 정보는 꽤 논란의 여지가 있다. 다시 말해 각 비즈니스 기능의 상대적 중요성이다. 여기서는 두 가지 요령이 있다. (1) 중요성을 경쟁 우위에 주는 영향으로 정의하고, (2) 각 기능의 점수를 계산하지만, 순위를 정하지는 않는다.

급여 장부가 판매보다 더 중요한지 덜 중요한지에 관해서는 의견 일치에 도달하기 어려울 것이다. 그러나 5점 척도 상에서라면 쉽게 일치할 수 있다(권장). 이들은 최고 점수인 5점을 받을 만하다. 판매할 수 없다면 시장 점유율을 잃을 것이고, 직원에게 급여를 지급하지 않는다면 판매할 수 없을 것이다.

이들 4가지 정보, 다시 말해 분류, 애플리케이션 매핑, 비즈니스 기능 유효성, 비즈니스 기능 중요성은 비즈니스 및 기술 아키텍처를 서로 연결하는 요소다.

BCM은 흔히 회사의 조직도를 닮았지만, 조직도가 BCM이 아니다. 조직, 특히 대기업은, 기능 외의 기준으로 조직화되는 경우가 흔하다. 예를 들어, 지리, 고객 유형, 제품 범주 등이다. 따라서 몇몇 비즈니스 기능은 조직의 한 곳 이상에서 나타날 수 있다.

기술 아키텍처의 평가 
기술 아키텍처를 평가할 때, 아키텍트는 구성요소 및 통합 건전성, 중복 및 통합 기회, 비즈니스 기능 지원의 질을 이해해야 한다. 중복 및 비즈니스 기능 지원은 다음에 살펴보고 여기서는 구성요소 건전성 평가만을 살펴본다.

기술 아키텍처 안의 각 포트폴리오 및 하위-포트폴리오의 구성요소는 다양한 평가를 받을 수 있다. 예를 들어 긍정적 자산이라는 평가, IT가 본연의 일을 하는 능력에 대한 평가, 지원을 받는 다양한 비즈니스 분야가 본연의 업무를 하는 능력을 방해한다는 평가 등을 받을 수 있다.

아키텍처 구성요소를 평가하는 데 쓰이는 기준은 광범위하다. 프레임워크에 따라 애플리케이션 계층에만 30가지의 유망 평가 기준을 포함하기도 한다. 그러나 30가지는 단일 계층을 대상으로 할 때 너무 많다. 데이터 수집 및 관리 관점에서, 십여 가지 정도가 현실적으로 최대 수치이다.

여기서는 11가지 기준을 제시한다. 아래의 단순화된 기준 집합을 포트폴리오 및 하위 포트폴리오에 따라 조정한다면 기술 아키텍처를 평가하는 강력한 기반을 갖게 될 것이다.

• 기능(Functionality): 이는 이론의 여지가 없이 명확한 기준이다. 비즈니스가 필요로 하는 일을 구성요소가 해내는지, 또는 그렇지 않은지를 판단한다.

• 유연성(Flexibility): 구성 요소가 새롭고 변화 중인 상황에 얼마나 순조롭게 적응하는가를 판단한다.

• 안정성 및 성능(Stability and performance): 이 또한 명확한 기준이다. 애플리케이션, 플랫폼, 또는 인프라 구성요소가 충돌이 잦고 터무니없이 느리다면 문제이다. 

• 내부 엔지니어링(Internal engineering): 구성 요소가 얼마나 원활하게 통합되는지 (컴포넌트가 내부적으로 개발되었다면 판단하기 더 쉬움). 다시 말해 조직의 엔지니어링 표준에 부합하는지를 묻는 것이다.  

• 통합 및 인터페이스(Integration and interfaces): 이는 애플리케이션과 데이터 리포지터리에만 적용된다. 애플리케이션 및 데이터 리포지터리가 데이터를 서로 어떻게 교환하며 중첩 데이터를 동기화하고, 특히 고차원적으로, 중첩된 비즈니스 로직을 동기화하는 지를 평가한다.

• 아키텍처 원리에 부합(Adherence to architectural principles): 아키텍처 원리를 상세히 서술하는 데 시간을 소비했다면 기술이 이에 부합하는지 판단해야 한다. 

• 보안(Security): 오늘날 대다수의 침입은 소셜 엔지니어링의 결과이지만, 그렇다고 해서 기술을 강화하지 않아도 된다는 것은 아니다.

• 벤더 및 제품 존속 능력(Vendor and product viability): 구성요소 및 이의 벤더가 시장에서 생존 능력을 가지고 있는지 아닌지. 다시 말해 구성요소가 유통되고 지원되고 강화될 것인지, 이를 취급할 인재를 영입할 수 있는지 확인해야 한다.

• 통용(Currency): 구성요소가 이의 벤더가 현재 출하 중인 버전보다 한 버전 이상 뒤쳐서는 안 된다. 벤더가 구성요소를 더 이상 지원하지 않는지 확인해야 한다.

• 하부 계층의 건전성(Health of lower layers): 한 계층의 구성요소가 하부 계층의 구성요소에 의존한다면 하부 계층 구성요소의 건전성 또는 결함이 위 구성요소에 그대로 전이된다. 예를 들어 한 애플리케이션이 메인프레임에서 호스팅 되는 IMS 데이터베이스에서 계층적으로 저장된 데이터에 의존한다고 하자. 대다수 IT 조직은 IMS를 노후 플랫폼이고 애플리케이션에 부정적 영향을 준다고 생각한다. 아울러 계층적 데이터 설계는 구조적 데이터 설계 표준을 위반하기 때문에 애플리케이션의 평가 점수에서 불리하게 작용한다.

• 중복(Redundancy): 한 구성요소와 기능적으로 유사하면서 성능이 우월한 다른 구성요소가 기업 내의 다른 곳에서 사용되고 있다면 해당 구성요소는 중복이다. 그렇다면 중복 구성요소 가운데 하나는 지속되는 표준으로서 자리잡아야 하고 높은 순위를 받아야 한다. 다른 구성요소는 중복이기 때문에 문제가 있는 것으로 평가되어야 한다. 

채점 
아키텍처 구성요소의 건전성을 측정하는 데 사용할 속성을 무엇으로 결정하든지 아래의 요령을 참고하는 것이 좋다.

모든 속성에 대해 공통의 척도를 확립. 경험적으로 +2 ~ -2 정수 척도가 효과적이다. 이는 5점 척도이고, 우리에게 익숙한 편이다. 0점을 척도의 중앙에 두면 한층 자연스럽다. 음수는 부정적이고, 양수는 긍정적이라고 보면 되기 때문이다.

가중치 버리기. 평가 기준에 가중치를 추가하기 전에 심사 숙고해야 한다. 원칙적으로, 가중치는 적용해야 한다. 몇몇 속성은 다른 속성보다 더 중요하기 때문이다. 그러나 실무적으로, 3점 가중치 척도(높은, 중간, 낮음) 상에서 한 속성의 중요성을 높음이나 중간으로 평가할 때 그 차이는 수고를 할 만큼 충분히 결과에 영향을 주지 않는다는 것을 발견할 것이다. 마찬가지로 중요성이 낮은 속성은 아마 이들을 완전히 배제해도 무방할 정도로 중요하지 않을 것이다.

스프레드시트를 넘어서라. 기술 아키텍처에 관해 수집한 데이터를 관리하는 데 스프레드시트에 의존하지 말라. 내부에서 만든 것이든, 상업용 아키텍처 관리 시스템이든 데이터베이스를 도입하라. 여러 이유 가운데 하나는 관리해야 할 데이터 가운데 상당히 많은 데이터가 수많은 관계를 갖기 때문이다. 예를 들어 일부 애플리케이션은 하나 이상의 비즈니스 기능을 지원하고, 대다수 비즈니스 기능은 하나 이상의 애플리케이션에 의존한다.

스프레드시트 상에 구축된 기술 아키텍처 리포지터리는 이내 관리하기가 버거워진다. 또한 기술 아키텍처 데이터를 스프레드시트에서 관리한다면 오류가 생길 수밖에 없다.

앞으로의 과제 
이제 모든 필요한 데이터를 가지고 있다. 각 애플리케이션이 어떤 비즈니스 기능을 지원하는지, 어떤 하드웨어 및 소프트웨어가 각 애플리케이션을 지원하는 지 알고 있다. 제반 구성요소가 어떤 식으로 얼마나 건강한지 알고 있다.

더불어 각 구성요소와 동일한 작업을 하는 다른 구성 요소가 있는지 알고 있다. 그리고 그 경우 어떤 구성요소가 더 우수한지 알고 있다.

다음 글에서는 미래의 아키텍처가 이와 동일할 것인지, 아니라면 변화해야 하는지, 변화를 위한 우선 순위가 무엇인지 파악해보도록 한다. 

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. dl-ciokorea@foundryco.com