기고 | 기술 아키텍처 평가하기 ‘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 컨설턴트다. ciokr@idg.co.kr