2021.10.01

기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드

Bob Lewis | CIO
기술 아키텍처(Technical architecture)는IT부서가 소속 기업을 지원하기 위해 배치하는 것의 총합이자 본질이다. 따라서, 기술 아키텍처의 관리는 핵심IT 업무이다. 그 시작 방법에 대해서는  지난 칼럼 ‘운영보다 헬프데스크 챙겨라?!··· CIO가 집중해야 할 IT프로세스 3가지’에서 이야기했다.

그렇다면, 좋은 기술 아키텍처를 구성하는 것은 무엇일까? 보다 근본적으로는 좋든 나쁘든 그저 그렇든 간에 기술 아키텍처를 구성하는 것은 무엇일까?

먼저 이야기하자면 논의의 주제는 ‘엔터프라이즈 아키텍처’가 아닌 ‘기술 아키텍처’이다. 엔터프라이즈 아키텍처에 기술 아키텍처는 물론 비즈니스 아키텍처가 포함된다. 기술 아키텍처가 비즈니스 아키텍처를 얼마나 잘 지원하는지에 대해 이해하지 않고 기술 아키텍처를 평가할 수 있다는 이야기가 아니다. 단지 비즈니스 아키텍처의 건전성 관리는 ‘다른 문제’일 뿐이다. 

기술 아키텍처가 중요한 이유
모든 IT부서는 기술 아키텍처를 보유하고 있다. 일부 조직는 기술 아키텍처를 좀더 신중히 구체화되어 있다. 그러나 기술 아키텍처가 우연의 산물인 경우가 너무나 많다. 전체적인 계획없이 시간이 지나면서 축적된 형태인 것이다.



상기 그림에 나와 있듯이, 초기 IT 구현 과정에서 신중하게 관리된 아키텍처는 초기 비용이 많이 들지만 시간이 지나면서 비용의 본전을 뽑게 된다. 잘 관리된 아키텍처의 장점(예: 줄어든 관리 및 지원 비용, 더 수월하고 덜 취약한 통합, 새로운 비즈니스 과제 해결 시 전반적으로 개선된 유연성)이 초기 투자 비용보다 커지기 때문이다.

기술 아키텍처를 구성하는 것
시작하기에 앞서 유명한 TOGAF 아키텍처 프레임워크를 말하는 것이 아니라는 점을 확실히 해 둔다. 무슨 프레임워크를 사용하든 간에 기술 아키텍처 노력의 목적은 IT 부서에서 관리하는 것의 조각들을 지속적인 분석과 계획을 위해 유사한 요소의 포트폴리오에 분류해 넣는 것이다.


위 그림에는 기술 아키텍처의 구성요소가 나와 있다. 기술 아키텍처에 영향을 미치는 외부 요소, 기술 아키텍처의 기본 구성요소, 기술 아키텍처가 생성하는 표준 등이다. 하나씩 살펴본다.

외부 요소
외부 요소로는 비즈니스 드라이버, 아키텍처 원칙, 기술 트렌드가 있다.

• 비즈니스 드라이버: 회사의 전략적 목표에서 알 수 있는, 회사에게 필요하게 될 광범위한 IT 기능들이다. 앱 개발 차원에서 필수 요건들은 아니며 그보다 더 광범위하다. 예를 들면, 머신 러닝, 자동 언어 번역, 안면 인식 등이다. 비즈니스 드라이버는 아키텍처에 직접적인 영향을 미친다. 또한, 아키텍처 원칙 수립을 돕는 방식으로 간접적인 영향도 미친다.

• 아키텍처 원칙: ‘이 시리즈의 마지막 회’에서 설명한 것처럼, 아키텍처 원칙은 해당 비즈니스에서 무엇이 ‘좋은’ 아키텍처를 구성하는지 규정하는 광범위한 원칙이다. 무엇이 좋은 엔지니어링을 구성하는지에 대한 전반적인 지식과 회사의 비즈니스 드라이버가 결합되어 있다.

• 기술 트렌드: 트렌드에 꼭 따를 필요는 없다. 단, 외부 기술 시장의 트렌드로 인해 본인의 기술 아키텍처 중 일부 구성요소가 무효화되거나 뭔가를 다르게 더 잘할 수 있는 기회가 생길 수 있다면 이를 반드시 알아야 한다.

기술 아키텍처의 기본 구성요소
IT 아키텍처는 계층이 나눠져 있고 분할되어 있다. 구성 요소는 애플리케이션, 데이터, 기술 등이다. 각각을 자세히 살펴본다.

애플리케이션: 비즈니스 사용자들이 각자의 업무 수행을 위해 활용하는 소프트웨어 프로그램의 포트폴리오이다. 애플리케이션 계층은 다음 3개의 하위 계층으로 나뉘어져 있다.

• 기록 시스템: 정보와 비즈니스 로직의 권위 있는 공급원 역할을 하는 애플리케이션과 애플리케이션 제품군이다. 

• 통합 및 동기화: 데이터와 비즈니스 로직이 겹치는 애플리케이션이 서로 맞도록 하는 애플리케이션 간 인터페이스이다.  

• 위성 앱(Satellite apps) 및 통합 API: 기록 시스템만으로는 다양한 비즈니스 고객이 해결을 필요로 하는 세부적인 자동화 기회를 모두 해결하기에 거추장스러울 수 있다. 통합 하위 계층을 통하거나 통합 계층에 의해 드러나면서 근본 데이터 및 비즈니스 로직에 대한 이상화된 통합 뷰를 제공하는 API를 통해 기록 시스템에 연결되는 전문 앱을 구현하는 것이 더 나을 때가 있다.  

데이터: IT부서에서는 표와 양식으로 편하게 표시되는 정형 데이터와 컨텐츠와 문서처럼 형태가 사실상 더 자유로운 비정형 데이터 등 2가지 종류의 정보를 관리할 기능을 제공한다. 그런데 비즈니스 사용자는 어떤 종류든 데이터와 직접 상호작용할 일은 없다. 비즈니스 사용자가 상호작용하는 것은 데이터 보관소와 상호작용하여 데이터를 소화, 관리, 표시하는 애플리케이션이다.

데이터 계층에는 데이터가 들어 있는 문서 관리 시스템(DMS), 콘텐츠 관리 시스템(CMS), DBMS가 아닌 데이터 자체만 포함되어 있다.

기술: 기술 계층은 다음 2가지 하위 계층으로 구성되어 있다.

• 인프라 및 설비: 데이터 센터 자체(클라우드로 완전히 이주했다고 해도 어딘 가에 데이터 센터가 숨어 있음), 네트워크, 서버(실제 또는 가상), 저장 장치(SAN, NAS, 또는 직접 연결 방식), 시스템 모니터링, 관리 및 집행 툴 등등이 포함된다.

• 플랫폼: 상위 계층의 모든 것이 구축되고 실행되는 소프트웨어(서버 운영체제, 개발 언어 및 환경, DBMS, CMS, DMS, 엔터프라이즈 서비스 버스(ESB) 및 여기에 상당하는 통합 시스템 등이 포함됨)

표준
애플리케이션, 데이터, 기술 포트폴리오에 배치된 정보 기술을 평가한 결과 IT 부서는 포트폴리오가 따라야 할 지침인 표준을 수립한다. 표준은 다음 2가지 범주로 나뉜다.

• 제품 표준: 각각의 IT기능을 실현하기 위해 사용 승인을 받은 구체적인 제품들이다. 예를 들어 MS워드는 오늘날 대부분의 기업에게 문서 작성의 표준이다. 사용 중이지만 사용 승인을 받지 않은 기술, 데이터 보관소, 애플리케이션은 아키텍처 제품 표준을 위반한다.

• 엔지니어링 표준: 기술 아키텍처는 구체적인 제품뿐만 아니라 다양한 구성 요소의 구조화 목적으로 승인된 수단으로도 구성되어 있다. 예를 들면, 대부분의 IT 작업장에서는 정상화를 일반적인 정형화 데이터 정리 수단으로 간주한다. 많은 IT작업장에서 마이크로서비스를 일반적인 애플리케이션 로직 정리 수단으로 확립 중이다.

현실에 적용하기
지금까지 각자 보유한 정보 기술의 조각들을 포트폴리오로 분류하는 방법을 알아보았다. 모든 것이 포함되었지만 중요한 것은 빠졌다. 이 시리즈의 다음 기사에서는 이 결과를 활용해 사용자가 보유한 아키텍처를 평가하는 방법과 어떻게 기존 아키텍처를 필요한 아키텍처로 변환할지 계획하는 방법을 다룰 예정이다.

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 



2021.10.01

기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드

Bob Lewis | CIO
기술 아키텍처(Technical architecture)는IT부서가 소속 기업을 지원하기 위해 배치하는 것의 총합이자 본질이다. 따라서, 기술 아키텍처의 관리는 핵심IT 업무이다. 그 시작 방법에 대해서는  지난 칼럼 ‘운영보다 헬프데스크 챙겨라?!··· CIO가 집중해야 할 IT프로세스 3가지’에서 이야기했다.

그렇다면, 좋은 기술 아키텍처를 구성하는 것은 무엇일까? 보다 근본적으로는 좋든 나쁘든 그저 그렇든 간에 기술 아키텍처를 구성하는 것은 무엇일까?

먼저 이야기하자면 논의의 주제는 ‘엔터프라이즈 아키텍처’가 아닌 ‘기술 아키텍처’이다. 엔터프라이즈 아키텍처에 기술 아키텍처는 물론 비즈니스 아키텍처가 포함된다. 기술 아키텍처가 비즈니스 아키텍처를 얼마나 잘 지원하는지에 대해 이해하지 않고 기술 아키텍처를 평가할 수 있다는 이야기가 아니다. 단지 비즈니스 아키텍처의 건전성 관리는 ‘다른 문제’일 뿐이다. 

기술 아키텍처가 중요한 이유
모든 IT부서는 기술 아키텍처를 보유하고 있다. 일부 조직는 기술 아키텍처를 좀더 신중히 구체화되어 있다. 그러나 기술 아키텍처가 우연의 산물인 경우가 너무나 많다. 전체적인 계획없이 시간이 지나면서 축적된 형태인 것이다.



상기 그림에 나와 있듯이, 초기 IT 구현 과정에서 신중하게 관리된 아키텍처는 초기 비용이 많이 들지만 시간이 지나면서 비용의 본전을 뽑게 된다. 잘 관리된 아키텍처의 장점(예: 줄어든 관리 및 지원 비용, 더 수월하고 덜 취약한 통합, 새로운 비즈니스 과제 해결 시 전반적으로 개선된 유연성)이 초기 투자 비용보다 커지기 때문이다.

기술 아키텍처를 구성하는 것
시작하기에 앞서 유명한 TOGAF 아키텍처 프레임워크를 말하는 것이 아니라는 점을 확실히 해 둔다. 무슨 프레임워크를 사용하든 간에 기술 아키텍처 노력의 목적은 IT 부서에서 관리하는 것의 조각들을 지속적인 분석과 계획을 위해 유사한 요소의 포트폴리오에 분류해 넣는 것이다.


위 그림에는 기술 아키텍처의 구성요소가 나와 있다. 기술 아키텍처에 영향을 미치는 외부 요소, 기술 아키텍처의 기본 구성요소, 기술 아키텍처가 생성하는 표준 등이다. 하나씩 살펴본다.

외부 요소
외부 요소로는 비즈니스 드라이버, 아키텍처 원칙, 기술 트렌드가 있다.

• 비즈니스 드라이버: 회사의 전략적 목표에서 알 수 있는, 회사에게 필요하게 될 광범위한 IT 기능들이다. 앱 개발 차원에서 필수 요건들은 아니며 그보다 더 광범위하다. 예를 들면, 머신 러닝, 자동 언어 번역, 안면 인식 등이다. 비즈니스 드라이버는 아키텍처에 직접적인 영향을 미친다. 또한, 아키텍처 원칙 수립을 돕는 방식으로 간접적인 영향도 미친다.

• 아키텍처 원칙: ‘이 시리즈의 마지막 회’에서 설명한 것처럼, 아키텍처 원칙은 해당 비즈니스에서 무엇이 ‘좋은’ 아키텍처를 구성하는지 규정하는 광범위한 원칙이다. 무엇이 좋은 엔지니어링을 구성하는지에 대한 전반적인 지식과 회사의 비즈니스 드라이버가 결합되어 있다.

• 기술 트렌드: 트렌드에 꼭 따를 필요는 없다. 단, 외부 기술 시장의 트렌드로 인해 본인의 기술 아키텍처 중 일부 구성요소가 무효화되거나 뭔가를 다르게 더 잘할 수 있는 기회가 생길 수 있다면 이를 반드시 알아야 한다.

기술 아키텍처의 기본 구성요소
IT 아키텍처는 계층이 나눠져 있고 분할되어 있다. 구성 요소는 애플리케이션, 데이터, 기술 등이다. 각각을 자세히 살펴본다.

애플리케이션: 비즈니스 사용자들이 각자의 업무 수행을 위해 활용하는 소프트웨어 프로그램의 포트폴리오이다. 애플리케이션 계층은 다음 3개의 하위 계층으로 나뉘어져 있다.

• 기록 시스템: 정보와 비즈니스 로직의 권위 있는 공급원 역할을 하는 애플리케이션과 애플리케이션 제품군이다. 

• 통합 및 동기화: 데이터와 비즈니스 로직이 겹치는 애플리케이션이 서로 맞도록 하는 애플리케이션 간 인터페이스이다.  

• 위성 앱(Satellite apps) 및 통합 API: 기록 시스템만으로는 다양한 비즈니스 고객이 해결을 필요로 하는 세부적인 자동화 기회를 모두 해결하기에 거추장스러울 수 있다. 통합 하위 계층을 통하거나 통합 계층에 의해 드러나면서 근본 데이터 및 비즈니스 로직에 대한 이상화된 통합 뷰를 제공하는 API를 통해 기록 시스템에 연결되는 전문 앱을 구현하는 것이 더 나을 때가 있다.  

데이터: IT부서에서는 표와 양식으로 편하게 표시되는 정형 데이터와 컨텐츠와 문서처럼 형태가 사실상 더 자유로운 비정형 데이터 등 2가지 종류의 정보를 관리할 기능을 제공한다. 그런데 비즈니스 사용자는 어떤 종류든 데이터와 직접 상호작용할 일은 없다. 비즈니스 사용자가 상호작용하는 것은 데이터 보관소와 상호작용하여 데이터를 소화, 관리, 표시하는 애플리케이션이다.

데이터 계층에는 데이터가 들어 있는 문서 관리 시스템(DMS), 콘텐츠 관리 시스템(CMS), DBMS가 아닌 데이터 자체만 포함되어 있다.

기술: 기술 계층은 다음 2가지 하위 계층으로 구성되어 있다.

• 인프라 및 설비: 데이터 센터 자체(클라우드로 완전히 이주했다고 해도 어딘 가에 데이터 센터가 숨어 있음), 네트워크, 서버(실제 또는 가상), 저장 장치(SAN, NAS, 또는 직접 연결 방식), 시스템 모니터링, 관리 및 집행 툴 등등이 포함된다.

• 플랫폼: 상위 계층의 모든 것이 구축되고 실행되는 소프트웨어(서버 운영체제, 개발 언어 및 환경, DBMS, CMS, DMS, 엔터프라이즈 서비스 버스(ESB) 및 여기에 상당하는 통합 시스템 등이 포함됨)

표준
애플리케이션, 데이터, 기술 포트폴리오에 배치된 정보 기술을 평가한 결과 IT 부서는 포트폴리오가 따라야 할 지침인 표준을 수립한다. 표준은 다음 2가지 범주로 나뉜다.

• 제품 표준: 각각의 IT기능을 실현하기 위해 사용 승인을 받은 구체적인 제품들이다. 예를 들어 MS워드는 오늘날 대부분의 기업에게 문서 작성의 표준이다. 사용 중이지만 사용 승인을 받지 않은 기술, 데이터 보관소, 애플리케이션은 아키텍처 제품 표준을 위반한다.

• 엔지니어링 표준: 기술 아키텍처는 구체적인 제품뿐만 아니라 다양한 구성 요소의 구조화 목적으로 승인된 수단으로도 구성되어 있다. 예를 들면, 대부분의 IT 작업장에서는 정상화를 일반적인 정형화 데이터 정리 수단으로 간주한다. 많은 IT작업장에서 마이크로서비스를 일반적인 애플리케이션 로직 정리 수단으로 확립 중이다.

현실에 적용하기
지금까지 각자 보유한 정보 기술의 조각들을 포트폴리오로 분류하는 방법을 알아보았다. 모든 것이 포함되었지만 중요한 것은 빠졌다. 이 시리즈의 다음 기사에서는 이 결과를 활용해 사용자가 보유한 아키텍처를 평가하는 방법과 어떻게 기존 아키텍처를 필요한 아키텍처로 변환할지 계획하는 방법을 다룰 예정이다.

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 

X