 | |
|
난이도 : 중급 Benjamin Lieberman, 선임 소프트웨어 아키텍트, BioLogic Software Consulting， LLC
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 6 월 17 일 전사적 아키텍처를 구축하는 과정에서는 다양한 응용 프로그램을 모델링하게 됩니다. 이러한 작업을 효율적으로 수행하려면 관련 부서가 협력하기 좋도록 모든 모델링 부산물을 정리하고 관리할 프레임워크가 필요합니다. 우수한 프레임워크는 두 가지 장점을 제공합니다. 하나는 모델을 일관성 있게 관리하므로 유지보수가 편합니다. 다른 하나는 모델 사이 관계를 관리하기가 쉬워집니다. 이 기사에서는 탄탄한 전사적 아키텍처 저장소를 만드는 과정에서 고려할 구조 문제와 관리 문제를 살펴봅니다. 탄탄한 전사적 아키텍처 저장소는 기업 내 현존하는 모든 자산을 100% 활용합니다.
어느 조직에서든 가장 귀중한 자산은 비즈니스 프로세스, 응용 프로그램, 자료 설계다. 특히 소프트웨어 시스템을 직접 개발해 사용하는 조직은 이러한 자산이 수백만 달러에 달하는 투자를 뜻한다. 그러나 대다수 조직에서는 이렇듯 귀중한 자산과 관련한 핵심 정보가 소수 인물들 머리 속에 들어 있다. 따라서 핵심 인물이 있어야만 정보를 얻을 수 있고, 핵심 인물이 사라지면 정보도 함께 사라진다. 해결책은 이러한 정보를 자료, 프로세스, 소프트웨어 모델 등과 같은 형태로 기업 저장소에 저장하는 방법이다. 이 기사에서는 전사적 아키텍처 저장소를 설계하고, 조직하고, 관리하는 방법을 소개한다.
전사적 아키텍처 저장소는 지역 도서관과 비슷하다. 도서관은 책, 참조 색인표, 테이프, CD, 사진, 지도, 저널, 신문, 잡지 등 다양한 형태로 정보를 저장한다. 그러나 도서관이 제공하는 가치는 단순한 정보 모음 이상이다. 도서관에서는 누구든 일관적인 체계와 표준화된 색인으로 원하는 정보를 쉽게 찾을 수 잇다. 반면에 모든 자료가 도서관 바닥에 쌓여있어서 정보를 찾아낼 방법이 없다면 도서관 가치는 급격하게 떨어지리라. 마찬가지로, 자료를 분류한다 쳐도 열람자들이 아무 데나 꽂아넣어서 정보를 찾기가 극심하게 어려워진다면 역시 도서관 가치는 급격히 떨어질 것이다. 그런데 많은 대기업, 특히 소프트웨어 개발 부문에서 이런 상황이 빈번히 벌어진다.
흔히 문서를 작성하고, 검토하고, 승인한 후에는 공유 드라이브에 저장한다. 그러고 나면 문서는 백발백중 자료 바다라는 망망대해 속으로 사라진다. (혹시라도 모델을 생성했다면) 모델은 로컬 드라이브나 공유 드라이브로 저장한 후 한두 번 사용한 다음 쓸모없이 버려진다. 사실 이러한 자료는 상당한 돈과 시간과 노력을 투자한 결과물이다. 그러니까 아주 귀중한 회사 자산이라는 말이다. 이런 자료를 폐기하는 행동은 돈을 가져다 버리는 행동과 같다. 흔히 주된 원인은 시간이다. 자료를 찾는 시간, 자료가 정확한지 확인하는 시간, 자료를 갱신하고 저장하는 시간이 주범이다. 프로젝트 일정에 쫒기다 보면 문서나 모델을 그냥 새로 만드는 편이 오히려 쉽고 빠르다. 그래서 결국은 매번 매번 매번 다시 만들게 된다.
이러한 악순환의 고리를 끊으려면 (요구사항, 모델, 설계 문서 등) 재사용을 목적으로 제작한 자료는 재사용이 가능한 자산으로 취급해야 한다. 재사용이 가능한 자료를 내다버릴 프로젝트 부산물로 취급해서는 안 된다. 명확한 분류 기준을 세워 저장해야 찾기가 쉬워진다. 예를 들어, 현재 개발 중인 시스템에서 유스케이스 문서를 작성했다고 치자. 이 문서를 저장소에 저장하지 않는다면 다음 개발 주기에서 사용할 확률이 희박하다. 특히 상당한 시간이 흐른 후에 다음 개발 주기를 시작한다면 가능성은 더더욱 희박하다. 그래서 전사적 아키텍처 저장소가 필요하다. 전사적 아키텍처 저장소는 구조, 색인, 관리 체계를 총체적으로 한 곳에서 제공하며, 영구적인 파일 접근과 통제를 위한 IBM® Rational® ClearCase®나 CVS(Concurrent Version System) 등과 같은 파일 버전 제어 시스템만 있으면 충분하다. 전사적 아키텍처 저장소를 구축하려면 가장 먼저 조직의 비즈니스 운영 방식을 지원하는 안정적인 구조를 마련해야 한다. 그런 다음, 장기적으로 도서관을 관리하고 유지할 절차와 프로세스를 수립해야 한다.
기술과 역량
모델 구조를 만들고 파일 제어 시스템을 설치하는 작업은 엔터프라이즈 아키텍처 저장소 확립 과정에서 첫 단계에 불과하다. 좀 더 어려운 작업은 지속적으로 구조를 관리하고 보수하는 단계다. 특히 모델러 수가 증가할수록 유지보수는 어려워진다. 시간이 지날수록 저장소 구조와 내용을 변경하는 횟수와 속력이 늘어나기 마련이다. 물론, 자료를 찾아서 살펴보려는 팀원 수도 늘어난다. 그러므로 일관성을 유지하려면 담당 팀을 두어 모든 변경을 관리하고 저장소를 감시해야 한다.
이러한 목적에 필요한 새로운 조직적인 역할 세 가지를 소개한다. 표 1을 참고한다.
표 1. 모델 관리 역할
| 역할 | 책임 |
|---|
| 관련자 | 저장소에서 버전 제어 시스템을 통해 자료를 추가, 갱신, 수정하려는 조직 내 사람 | | 저장소 관리자 | 저장소 주요 부분의 구조를 관리하고 보수하는 책임자(예: 응용 프로그램 아키텍트) | | 모델 소유자 | 특정 모델 영역을 관리하고 감시하는 책임자(예: 특정 응용 프로그램) |
저장소 관리자는 저장소 구조를 최종적으로 책임진다. 도서관에서 보듯이, 일반 열람자는 자료가 저장되는 방식과 시기를 맘대로 정하지 못한다. 저장소 관리자는 도서관장과 같다. 즉, 핵심적인 저장소 구조를 변경하거나, 추가하거나, 재배열하자는 요청을 검토하고 수용한다. 저장소 관리자가 변경에 동의하면 구현 일정을 잡고 모든 저장소 사용자에게 이 사실을 알린다. 대개 이러한 결정은 아키텍처 변경일 확률이 높으므로 아키텍처 팀이 결정하는 편이 바람직하다. 그러므로 (적어도 처음에는) 해당 시스템 아키텍처 팀이나 비즈니스 아키텍처 팀에 속한 사람이 저장소 관리자 역할을 맡아야 한다.
반면, 모델 소유자는 저장소 내용을 책임진다. 예를 들어, 응용 프로그램 아키텍트는 특정 응용 프로그램의 모델 구조와 내용을 책임진다. 모델 소유자는 저장소 관리자와 밀접하게 협력하면서 초기 모델 구조를 잡는다. 모델 파일이 소스 제어 시스템 아래 있는 경우에는 협력이 특히 중요하다. 저장소가 일관성을 유지하려면 (응용 프로그램, 자료, 비즈니스, 서비스 등) 각 저장소 영역은 공동 모델 템플릿 하나를 기반으로 각 팀이 초기 모델을 작성하도록 만들 필요가 있다.
저장소 내 모든 내용은 버전 제어 시스템으로 보호해야 한다. 실제로 사용하는 도구에 따라 데이터베이스나 파일 제어 시스템이나 파일 버전 제어 시스템 등 무엇이라도 좋다. 한 가지 강력한 조합은 Rational ClearCase, Rational Software Manager, Rational RequisitePro®로, 요구사항과 모델, 기타 아키텍처 관련 부산물을 저장하기에 적합하다. 이 경우 Rational Software Modeler로 작성한 모델은 Rational ClearCase가 버전을 관리하며 Rational RequisitePro에 저장된 요구사항과 구조적으로 일치한다. 각 도구를 밀접하게 통합하면 비즈니스, 응용 프로그램, 서비스, 자료 요구사항을 아우르는 빈틈없는 단일 모델을 생성하기 쉽다. 또한 저장소 일부 또는 전체를 버전 제어 시스템 아래 두면 분기-병합 전략을 사용하여 같은 시스템 모델에서 병렬로 개발을 진행할 수도 있다.
도구와 기술
전사적 아키텍처 저장소는 어느 조직이든 이익을 제공하지만, 특히 소프트웨어 개발 조직에 가장 큰 이익을 제공한다. 대개 소프트웨어 개발 업체는 코드만 관리할 뿐 문서나 모델 등 기타 개발 부산물을 공식적으로 관리하는 방법이 부실하거나 전무하다. 그래서 도서관 바닥에 쌓아놓은 자료 더미와 비슷한 상황이 벌어진다. 공유 드라이브에 해독 불가능한 파일 이름과 폴더 이름으로 문서가 쌓여 있고, 이런 문서 중 어느 하나라도 빛을 볼 가망성은 희박하다. 규율을 추가해 개발 프로세스를 조금만 더 엄격히 지키고 공식 저장소를 생성하여 장기적인 개발 부산물을 모두 관리한다면 상황을 개선하기가 어렵지 않다.
그림 1은 전형적인 전사적 아키텍처가 보이는 최상위 구조다. 응용 프로그램 아키텍처(application architecture), 비즈니스 프로세스 아키텍처(business process architecture), 자료 아키텍처(data architecture), 서비스 중심 아키텍처(service-oriented architecture, SOA)로 이루어진 핵심 프레임워크 네 개에 주목한다. 이 외에도 통신 회사라면 물리적인 공장 모델 등 특정 비즈니스 영역을 지원하는 몇 가지 범주를 추가하기도 한다. 이러한 추가 범주는 (물리적인 구조라고 불러도 좋겠다) 네트워크 하드웨어, 케이블 배선, 물리적 공장, 기타 기반 구조 정보와 관련한 모델을 저장한다.
그림 1. 전사적 아키텍처 최상위 구조
전사적 아키텍처 프레임워크를 구현하는 방식은 모델 정보를 저장할 때 사용하는 도구에 따라 달라진다. 예를 들어, Rational RequisitePro로 요구사항을 관리한다면 관계형 데이터베이스로 저장소 구조를 구현한다. Rational Software Modeler로 모델을 생성한다면 (Rational ClearCase와 같은) 버전 제어 시스템으로 모델 파일을 관리한다. 심지어 다양한 모델링 도구로 파일을 생성한 후 CVS와 같은 공개 소스 도구로 관리해도 괜찮다. 어떤 방식으로든 버전을 관리하고 아키텍처 구조를 참조하기 쉬워야 한다는 사실이 가장 중요하다.
비즈니스 프로세스
일반적으로 조직은 개개인이 비즈니스 목표를 달성하기 위해 수행하는 프로세스를 좀 더 잘 이해하기 위해 비즈니스 모델링을 수행한다. 개개인은 이러한 프로세스를 수동으로 수행할 수도 있고 몇몇 소프트웨어나 하드웨어로 자동화할 수도 있다. 전사적 아키텍처에서 비즈니스 프로세스를 지원하는 방식은 다른 영역과 비슷하다. 구체적으로, 그림 2에서 보듯이 비즈니스 기능에 따라 워크플로를 나눈다. 그러나 모든 과정이 자동화를 염두에 두고 있지 않으므로 비즈니스 프로세스에서 저장소 폴더 구조는 다른 영역과 크게 다르다. 예를 들어, 그림 3에서 보듯이 Coporate 도메인에 속한 하위 폴더 구조는 application Coporate 도메인에 속한 하위 폴더 구조와 일치하지 않는다. 기업 측정, SOX(사베인즈 옥슬리) 법안 보고서 작성 등 수동으로 수행할 프로세스가 있기 때문이다.
그림 2. 비즈니스 프로세스 모델링 구조
저장소에 저장된 자료는 어느 한 프로젝트 범위를 넘어선다는 사실에 주목한다. 이러한 자료가 진정한 회사 자산이다. 요구사항, 시스템 아키텍처, 자료 구조 등은 어느 한 프로젝트에 국한하지 않으며 재사용이 가능하다. 특정 프로젝트 생명 주기에만 정말로 유용한 프로젝트 단위 자료는 프로젝트 위키나 공유 웹 사이트 등과 같은 공간에 저장하면 그만이다.
응용 프로그램 아키텍처
응용 프로그램 아키텍처 구조는 조직이 수행하는 비즈니스에 따라 크게 달라진다. 조직이 ITIL(IT Infrastructure Library®) 권장 구조를 따른다면 그림 3과 같은 응용 프로그램 아키텍처를 보이리라.
그림 3. 예제 응용 프로그램 아키텍처 폴더와 파일 구조
회사 지원 시스템용으로 다음과 같은 분야를 추가해도 좋겠다.
- Product management:
- Product pricing
- Quoting
- Product catalog
- Sales and order management:
- Sales force management
- Order entry
- Order fulfillment
- Workforce management
위와 같은 범주 하에서 응용 프로그램을 주된 기능에 따라 분류한다. 예를 들어, 주문을 입력 받는 응용 프로그램은 '영업과 주문 관리 > 주문 입력' 도메인에 속한다. 주문 처리, 재고 관리, 사전 준비 등 여러 기능을 처리하는 시스템은 논리적인 하위 시스템으로 나누어 해당 기능 영역에 저장한다. 비슷하게, 기능이 중복되는 응용 프로그램이 여러 개 존재한다면 공통 응용 이름으로 그룹을 지어 병합할 필요를 강조한다.
각 응용 폴더 아래서는 그림 4와 같이 파일 관리 구조를 똑같이 잡는 편이 유용하다. 특히, 이런 방식은 IEEE 1471 표준에서 주창하는 모델 조직 구조인 관점(Viewpoints)을 활용한다. 이 방식은 두 가지 장점을 제공하는데, 하나는 (논리적 분석을 진행하는 동시에 유스케이스를 개발하는 등) 모델을 여러 영역으로 나눠 병렬 모델링을 지원한다는 점이고, 다른 하나는 (예를 들어, 지원 팀과 설치 팀 관점에서) 모델이나 특정 이해 관계자의 필요에 초점을 맞춘다는 점이다.
그림 4. 응용 프로그램 아키텍처 폴더와 모델 파일 구조
같은 구조를 사용해 모델과 함께 코드를 관리해도 무방하다. 아니면 모델과 별도로 프로그램 코드 기반을 관리하되 서로 참조해도 좋겠다.
자료 아키텍처
자료 아키텍처 영역은 영구적인 데이터베이스 구조를 저장할 목적으로 쓰인다. 여기서는 두 가지 데이터베이스가 중요하다. 하나는 응용 프로그램에 종속적인 데이터베이스고, 다른 하나는 응용 프로그램에 독립적인 데이터베이스다. 응용 프로그램에 종속적인 데이터베이스는 (주문 입력 시스템이 받아들인 주문을 저장하는 등) 특정 응용 프로그램을 지원한다. 응용 프로그램에 독립적인 데이터베이스는 (청구 시스템처럼) 여러 응용 프로그램을 지원한다. 그림 5는 응용 프로그램에 독립적인 자료를 위해 모델과 지원 파일을 관리하는 한 방식이다. 자료 아키텍처 영역 아래 구조가 응용 프로그램 영역 아래 구조를 모방하다는 사실에 주목한다. 응용 프로그램에 종속적인 자료는 응용 프로그램 영역과 구조가 거의 비슷하다. 반면, 응용 프로그램에 독립적인 청구 시스템은 개별 응용 프로그램을 나타내는 하위 패키지가 없다.즉, 독립적인 모델과 지원 파일 관리로 끝난다.
그림 5. 자료 아키텍처 폴더와 파일 구조
시스템에 독립적이든 종속적이든 하위 폴더 구조는 똑같다. 자료 필드를 기술하는 자료 사전, (응용 프로그램 설계에 유용한) 논리적 자료 모델, (DDL로 데이터베이스 스크립트를 생성할 때 필요한) 물리적 자료 모델이 필요하다.
SOA
전사적 아키텍처 프레임워크에서 마지막으로 살펴볼 영역은 IBM WebSphere ESB와 같이 ESB(Enterprise Service Bus)가 제공하는 서비스다. 이 아키텍처 영역을 정의하는 목적은 응용 프로그램이 제공하거나 소모하는 기업 서비스를 정의하기 위해서다. 모델과 기타 부산물을 지원하는 구조 또한 기능적 영역에 기반을 두지만, 여기서는 서비스 자체를 하위 폴더 구조로 정의한다. 그림 6을 참조한다.
그림 6. SOA 폴더 구조
각 서비스마다 하위 폴더 구조는 그림 6과 비슷하다. ApplicationGateway(adapter) 폴더는 서비스 제공자/소비자와 인터페이스 역할을 한다. 구현 폴더는 WSDL(Web Service Description Language) 파일과 기타 구현 부산물을 포함한다. 모델 구조는 응용 프로그램과 비슷하지만, (자료 전송 객체를 위한 기업 객체 모델처럼) 해당 서비스 설계 정보를 잡아내는 관점에서 구성한다.
중간 목표
전사적 아키텍처 저장소를 구축하는 작업은 쉽지 않다. 조직 전체가 사용할 구조를 유지하는 작업만으로도 어려운데, 거기다 장기간에 걸쳐 저장소를 관리하고 확장하는 작업은 더욱 어렵다. 모든 자료가 정확하고, 최신이고, 유용하도록 유지한다고 상상해 보라. 이러한 목적을 달성하려면 다음 몇 가지 핵심 중간목표를 고려한다.
-
핵심 비즈니스 아키텍처 찾아내기: 조직을 기능적 영역으로 나눈다. 제품을 생산하는 방식, 포장하는 방식, 판매하는 방식, 청구하는 방식을 파악한다. 조직이 구성되고 관리되는 방식을 파악한다. 언제 어디서 (소프트웨어와 같은) 기반 구조를 개발하는지 찾아낸다.
-
저장소 구조 만들기: 초기 구조를 만들어 버전 제어 시스템 아래 저장한다. 구조는 기능 비즈니스 운영 부문에서 가장 안정적인 부분을 반영해야 한다.
-
저장소 관리하기: 주기적으로 저장소 내 모든 자료를 검토하고 평가한다. 정확성, 일관성, 연관성을 확인한다. 낡은 자료만큼 도서관을 빨리 문 닫게 만드는 지름길도 없다.
이 기사에서 보았듯이, 어느 정도 규모가 되는 기업이라면 개발 부산물을 재사용할 경우 상당한 이익을 얻는다. 개발 부산물을 가져다 버리는 회사는 돈을 낭비하는 셈이다. 아니, 단순히 처음에 들인 노력만 낭비하는 데 그치지 않는다. 나중에 변경이 필요할 때 잃어버린 정보를 다시 찾느라 시간과 돈을 또 낭비한다. 많은 조직이 핵심 정보를 머리 속에 넣고 있는 몇몇 개인에게 절대적으로 의존한다는 사실이 놀랍지 않은가? 회사 정보를 재사용 가능한 자산 라이브러리로 정리하면 (핵심 비즈니스 기능을 중심으로 라이브러리를 생성하면) 상황은 변한다. 회사 돈을 어떻게 쓰고 싶은가? 시스템을 변경할 때마다 혹은 고객을 확보하고 제품을 개발할 때마다 잃어버린 정보를 찾아 다니느라 낭비하고 싶은가? 선택은 여러분에게 달려 있다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | Benjamin A. Lieberman은 BioLogic Software Consulting 사에서 선임 아키텍트로 일하고 있다. Lieberman은 요구사항 분석, 소프트웨어 분석과 설계, 설정 관리, 개발 프로세스 향상 등 다양한 소프트웨어 개발 주제를 대상으로 컨설팅과 교육 서비스를 제공한다. 또한 10년 이상 통신, 항공 여행, 전자 상거래, 재정 서비스, 생명 공학 등 다양한 분야에 소프트웨어 아키텍처와 정보 기술을 도입하는 데 일조했다. Lieberman은 객체 지향 아키텍처와 분산 컴퓨팅 분야에 역점을 두고 소프트웨어 개발 기법을 조언한다. 특히, 자바(Java™) 기반 시스템과 분산 웹 사이트 개발(J2EE), XML/XSLT, 펄, C++ 기반 클라이언트-서버 시스템이 전문 분야다. Lieberman 박사는 EchoStar, Jones Cyber Solutions, Blueprint Technologies, Trip Network Inc., Galileo International, Duke University, University of Colorado 등과 같은 기업과 조직에 아키텍처 컨설팅 서비스를 제공했다. 또한 많은 소프트웨어 기사와 책을 집필한 전문 집필가이기도 하다. 그는 콜로라도 주 덴버 시에 있는 University of Colorado, Health Service Center에서 생물물리학과 유전학 박사 학위를 획득했으며, 연락 가능한 전자편지 주소는 blieberman@biologicsoftwareconsulting.com이다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
