전사 데이터 관리 반드시 피해야 할 7가지 실수

Enterprise Data Management

전사 데이터 관리:

반드시 피해야 할

7가지 실수

ER/Studio 를 통해 실수를 피해가는 방법

Karen Lopez I.S.P

InfaAdvisors, Inc.

InfoAdvisors 2005ⓒ InfoAdvisors, Inc. All Rights Reserved

11066 Sheppard Ave East Toronto, ON MIB 1G2

Phone 416-410-2937

www.infoadvisors.com

Helping You Add Business Value to Your Information Management Resources

ER/Studio is a registered trademark of Embarcadero Technologies, Inc.

Enterprise Data Management (전사 데이터 관리): 7 가지 실수

ⓒ InfoAdvisors, Inc. 2005 2

요약

오늘날의 IT 전문가는 법규정의 변화, 조직 변경, 기술 혁신의 속도 등 다양한 변화에 늘 직면하고

있다. 내 경험 상 전사 데이터 관리를 처음 시작하는 조직이라면 우선 어마어마하게 느껴지는 규모에

압도당한다. 그리고 새로 받아들여야 하는 방법(또는 절차), 도구, 기술의 복잡성에 대해 다시

긴장하게 된다. 전사 아키텍처를 잘 관리함으로써 얻게 되는 혜택을 근사하게 도출하여 제공하고

싶지만, 그 결과에 도달하는 과정에서 발생될 수 있는 잘못에 대한 걱정이 먼저 앞선다. 전사 데이터

관리를 이제 막 시작했든지, 아니면 이미 경험을 가지고 있든지 몇 가지 함정이 결국 성공의

장애물로 바뀔 여지는 있기 마련이다.

이러한 함정에 대해 말하기에 앞서 “용어”에 대해 먼저 논의해야 한다. 전사 데이터를 관리한다는

것은 다시 말해서 다음과 같은 방식으로 정보를 관리함을 의미한다:

전사 관점과 프로젝트 관점 사이의 실질적인 균형을 도모

전사 데이터 아키텍처가 발전하도록 기여

IT 그룹이 비즈니스 요구사항에 대해 보다 신속하고 효과적으로 응답할 수 있도록 구축

비즈니스 상 가장 유용한 정보를 제공

프로젝트 산출물을 인수하기에 알맞은 도구와 기술을 사용

전사 데이터 관리 상에서 논리/물리 데이터 모델은 전사 데이터 아키텍처를 구성하는 중요한

요소이다. 이 모델들은 비즈니스 전반에 걸쳐 요구되는 정보와 데이터에 대한 지식 기반을 형성한다.

이 글에서는 가장 먼저 효과적인 전사 데이터 관리가 제공하는 혜택에 대해 살펴 볼 것이다. 위험이

존재할 수 있음에도 불구하고, 조직은 왜 데이터 관리에 대해 전사적 관점을 가지고 접근해야 할까?

정보기술은 수작업 절차를 통해서는 거의 불가능한 비즈니스 목표를 달성할 수 있도록 만들어 주기

때문에 존재한다. 그리고 전사 아키텍처는 팀 간의 의사소통을 향상시키고, IT 관련 지출을 보다 잘

정렬하고 줄여 주며, 프로젝트 예산과 계획을 보다 잘 준비할 수 있게 해준다. 하지만, 전사 데이터

관리 프로그램이 제공하는 가장 큰 혜택은 바로 IT 부서가 비즈니스 부서에게 해법을 제공하는

능력에 대해 보다 확고한 자신감을 불어넣어 준다는 점이다.

이 글의 두 번째 섹션에서는 전사 데이터 아키텍처를 개발하면서 저지를 수 있는 7 가지 흔한 실수에

관해서 살펴볼 것이다. 이런 실수들은 프로젝트와 IT 조직에게 모두에게 부정적인 영향을 끼치는

비용을 발생시킨다. 이러한 각각의 잠재적인 실수와 관련하여 여러분의 팀들이 비스니스 부서에 과연

정확한 결과를 제공하고 있는 지를 ER/Studio 를 통해 어떻게 확인할 수 있는지를 살펴보겠다.



전사 데이터 관리가 제공하는 혜택

전사 데이터 아키텍처를 발전시키는 이유는?

데이터 관리 전문가의 대부분은 프로젝트 수준의 모델링 경험을 가지고 있다. 이들은 분명히

프로젝트에 알맞은 데이터 모델을 만들어서 새로운 데이터베이스를 구축할 때 매우 성공적으로

업무를 수행할 것이다. 하지만, 이러한 활동을 보다 통합된 협력의 일환으로 활용하여 전사 차원의

혜택을 제공하려고 할 때에는 많은 어려움이 발생한다. 효과적인 전사 데이터 관리 프로세스가

없이는 사실상 불가능하기 때문이다.

전사 데이터 관리라고 하면, 우리는 정보 관리를 통해 전사 관점과 프로젝트

관점 사이에 실질적인 균형을 도모하고, 총체적인 엔터프라이즈 아키텍처에

기여하며, 비즈니스 그룹에게 가장 유용한 정보를 제공하고, 성공적인

프로젝트 산출물을 제공할 수 있도록 알맞은 도구와 기술을 사용하는 것을

의미한다. 또한 전사 아키텍처를 구성하는 하나의 요소로서 논리 데이터

모델과 물리 데이터 모델이 사용되어야 한다. 이 모델들은 비즈니스 전반에 걸쳐 요구되는 정보와

데이터에 대해 지식 기반을 형성하게 된다. 각 프로젝트에서 전사 수준의 엔터프라이즈 급 모델을

만들 수 있도록 관리체계를 확립하는 것이 전사 데이터 관리 프로그램이 성공할 수 있는

핵심열쇠이다.

하나의 전사 데이터 아키텍처는 비즈니스 데이터와 정보 자산에 대한 하나의

체계화된 모델이다. 전사 데이터 관리는 정형화된 전사 데이터 아키텍처를

만들게 된다. 모든 아키텍처가 그렇듯이, 전사 데이터 아키텍처는 데이터와

정보에 대하여 “설명해주는 정보”, 그리고 아키텍처를 구성하고 있는

항목들을 도식화하여 표현한다. 이 “설명해주는 정보”를 우리는 메타데이터

(metadata) 라고 한다. 하나의 전사 데이터 아키텍처에는 전사 데이터 관리를 위한 속성, 규칙, 정책이

명시된다.

자 이제 성공적인 전사 데이터 관리 노력을 통한 산출물과 그 혜택을 살펴보자.

커뮤니케이션 향상

전사 메타데이터를 관리함으로써 비즈니스 정보의 가치가 증가하게 된다. 즉 비즈니스 정보 자체가

하나의 공통어 또는 표준어가 되므로, 비즈니스 부서뿐만 아니라 애플리케이션 개발자와

데이터베이스 관리자에 이르기까지 모두가 쉽게 이해할 수 있다.

데이터는 다양하게 흩어져 있는 많은 비즈니스 시스템에서 만들어진다. 이 각각의 시스템 또한 매우

다양한 기술들을 사용한다. 정보 소통이라는 차원에서 소프트웨어는 이러한 다양성으로 인해 하나의

전사 데이터 관리란

비즈니스 목표와 목

적을 지원하기 위한

방편으로써 데이터와

정보를 관리하는 것

을 의미한다.

하나의 전사 데이터

아키텍처에는 전사

데이터 관리를 위한

속성, 규칙, 정책이

명시된다.



“바벨탑”이 되어버린다. 즉 비즈니스 사용자들이 자신들에게 필요한 정보를 활용하는 데에 오히려

방해가 되는 것이다.

기업에서 새로 오픈한 서비스의 수익성에 대한 정보를 찾으려고 했지만, 이에 대한 분기

매출액을 찾을 수가 없었다. 그 이유를 찾아보니 새로 오픈한 서비스의 경우 외부에서

구입한 소프트웨어 패키지에서 관리되기 때문에 새 서비스에 대한 모든 분석 정보는

별도의 데이터베이스와 엑셀 파일 안에 흩어진 채 숨어있었다. 그는 이 새로운 데이터에

접근하고 그 구조를 이해하려고 몇일 동안이나 노력하였지만, 여전히 매출액에 대한 분기

보고서 작성을 할 수 있게 신뢰성 있는 방안을 만들 수 없었다.

또 다른 사용자의 사례를 들어 보자. 그는 기업의 경영진과 수많은 파트너사 앞에서

파트너사들의 서비스 수준이 SLA(Service Level Agreement)의 특정 항목의 기준 치에

도달하지 못하고 있고, 꽤 오랫동안 그래왔다는 것을 보여주며, 가차없이 혹평하는

내용의 보고서를 배포하였다. 이 긴급 회의 도중에 그는 그가 작성한 보고서에서 사용된

데이터의 시간이 잘못되었다는 것을 알게 되었다. 즉 실제로 서비스가 완료된 시간이

아니라 해당 업무가 종료 정보를 시스템에 입력한 시간을 가지고 보고서가 작성되었던

것이다. 그는 당혹스러웠고, 해당 파트너사는 크게 실망했으며, 경영진은 자사의 직원이

적절한 보고를 할 수 있는 능력이 있다는 믿음을 버리게 되었다.

전사 데이터 관리가 효과적이었다면, 방금 언급한 사례의 주인공 들의 경우 “일원화된” 경로만으로

기업에서 만들어진 모든 정보와 이에 대한 설명과 정의를 파악할 수 있게 됨으로써 자신들과 관련된

데이터를 더 잘 접근할 수 있었을 것이다.

비용의 조절과 절감

프로젝트가 전사(Enterprise) 아키텍처 전반에 대해 독립적으로 진행되는 경우, 팀원들은 엄청나게

많은 시간을 프로젝트와 관련된 데이터를 찾고, 그 의미를 이해하며, 데이터의 정확성과 적절성을

확인하는 일에 사용하게 된다. 팀원들 개별적으로는 기업의 데이터를 이해하게 되겠지만, 프로젝트의

기간이 부족하고 적절한 도구가 없다면, 자신들이 이해한 데이터를 팀 차원에서 공유할 확률은 거의

없다. 아무리 문서 산출물이 만들어진다고 해도, 산출물 안에 기록된 지식을 통합하기는 어렵다.

처음부터 재사용을 목적으로 만들어졌다면 모르겠지만 재사용을 목적으로 만드는 문서 산출물은

실제로 별로 없다.

그러나 전사적인 차원에서 데이터를 관리하는 팀의 경우라면, 기 작업된 모델을 재사용할 확률이

보다 높고, 그 결과 몇 주 혹은 몇 달의 수고를 덜 수도 있다.

데이터 웨어하우스 기능을 지원하는 애플리케이션을 개발하는 초기 단계에 있는 프로젝트 팀은

프로젝트와 관련된 오브젝트에 대해 전사 모델을 조사한다. 이 프로젝트 팀에게 전사차원

모델링이라는 개념이 낯설지만, 이전의 프로젝트 팀이 작성한 프로젝트 모델링 오브젝트 중에서

사원, 위치, 조직, 회계, 재고, 제품, 제조사 정보 등 약 35%정도는 재사용이 가능하다. 이전

프로젝트 팀이 모델링 작업을 할 때, 전사적 차원의 관점을 가지고 있다면, 현 프로젝트 팀 작업의

상당 부분이 이미 완료된 것이다.

다른 프로젝트 팀은 기업의 인보이스 프로세스 기능을 지원할 소프트웨어 구입 업무를 고려

중이다. 이 팀은 위에서 언급된 두개의 프로젝트에서 만들어진 모델링 오브젝트를 사용할 수 있다.

비록 이 팀은 데이터베이스를 직접 구축하지는 않지만, 앞서 만들어진 모델링 오브젝트를

사용하여 구입할 소프트웨어의 입력값으로 활용하는 것 뿐만 아니라, 해당 소프트웨어가 기업의



업무 요구사항에 부합하는 지를 검증할 수도 있다. 모델의 각 오브젝트가 곧 충족되어야 하는

요구사항이 된다.

전사적인 차원의 접근이 되는 이와 같은 환경에서 작업하는 프로젝트 팀이라면 분석과 설계 시간이

단축될 뿐 아니라 결국 비용 절감으로 이어진다. 또한 팀원들은 모델 재사용으로 절약된 시간을

소프트웨어의 품질 향상에 집중 할 수 있다.

프로젝트에서 전사 아키텍처 수준에서 모델을 사용하고 또 제공한다는 것은, 향후의 프로젝트에서

사용될 수 있도록 오브젝트의 중앙 리포지토리(Repository)에 공헌하는 것이 된다. 프로젝트 예산 산출

단계에서 모델러는 모델링 오브젝트 목록에 근거하여 시간과 인력을 산출할 수 있다. 만약 해결해야

할 과제가 이전 프로젝트에서 이미 대부분 커버되었다면, 그렇지 못한 경우에 비해 프로젝트에서

해당 데이터 모델을 완성하기 위한 노력이 훨씬 적게 들 것이다.

앞서 살펴본 개발 프로젝트에 있는 모델러가 기존에 만들어진 모델을 기반으로 하여 확장하게 되는

새 프로젝트의 개발 범위를 검토하게 된다면, 기 구축된 작업의 정도를 기반으로 시간과 인력을

산출할 수 있을 것이다. 도구를 사용하여 무슨 데이터 컨셉이 구현 되었으며, 무슨 데이터 컨셉이

설계는 되었으나, 아직 구현되지 못하였는 지, 또는 어느 팀이 유사한 데이터 컨셉을 사용하고 있는

지를 통해 설계 투입 인력과 구현에 대한 계획을 보다 정교하게 할 수 있게 된다.

또한 우리의 모델러는 해당 프로젝트 범위를 검토하면서 어떠한 다른 모델링과 설계 기법이

사용되어야 하는 지를 검토할 것이다. 모델링 환경에서 이러한 기술이 어느 정도 수준으로 지원되는

지를 파악하고 나서 하나 이상의 기술을 사용하는 데 드는 수고를 추정할 수 있게 된다.

명확하고 일관성있게 만들어져 가는 전사(Enterprise) 아키텍처는 곧 프로젝트 팀이 명확하고 일관성

있게 예측과 계획을 할 수 있다는 것을 의미한다.

IT 조직 내부의 자신감 증가

효율적인 전사 데이터 관리를 통해 얻게 되는 가장 중요한 이점은 IT 조직 내부 직원들의 자신감이

증가하게 된다는 것이다. 비용 절감과 고품질 모델이 이러한 자신감의 한 부분이다. 하지만 IT 부서가

기업 비즈니스를 위해 그 역할을 올바르게 수행하고 있다는 믿음을 줄 수 있는 것은 단지 이것들만이

아니다.

자신감 문제는 왜 발생하는가?

현실을 들여다 보자 – 많은 IT 부서들은 사업부서의 사용자들, 제한된 예산, 프로젝트 위험에 대한

민감한 사항, 새로운 프로젝트를 착수하는 것에 대한 사업부서의 막연한 공포 등을 해쳐나가고 있다.

이러한 두려움은 예전에 수행한 개발과정에서 겪은 수많은 어려움과 노력에 대한 기억의 결과이다.

그 노력에 있어서 대부분의 시간과 비용은 시스템에 반영할 비즈니스 규칙과 비전을 찾아내는 데

사용된다. 이전의 프로젝트가 전사(Enterprise) 모델링 접근을 통한 이점이 없이 완료되었다며, 이러한

시간과 노력의 결과가 단지 개발자의 마음 속에 있거나 문서로 작성되어 아무도 알지 못하는 곳에

묻혀있을 것이다.



영역별 전문가와의 파트너쉽 향상

사업부서 사용자들은 새 프로젝트가 시작되거나 기존 프로젝트의 개선이 착수되면, 이미 과거에 IT

인원에게 전달한 비즈니스 요구 사항이 적절하게 기록되어 있지 않고, 또 다시 이들을 재교육 하고

있는 것을 발견하게 된다.

공식적인 데이터 관리 프로그램의 도움이 없다면, 지식 근로자와 사업 분석자는 어떤 데이터가 있고,

이 데이터가 어떻게 사용되는지에 대해 이해하려고 노력하는데 많은 시간을 사용한다. 사업부서

사용자들은 어떤 비즈니스가 어느 시스템 설계에 참여 되었는 지에 대해 잘 안다. 그리고 이들은 IT

부서에서 어떤 데이터가 존재하고 어디서 사용되고 왜 사용하는 지 그리고 이런 것들을 찾아내기가

왜 어려운지에 대해 이해하지 못한다.

몇 명의 사업부서 사용자들은 경쟁우위를 확보하기 위해 중요한 새로운 재고 추적 시스템을

개발하는 프로젝트에 투입된다. IT 전문가 팀 또한 이 프로젝트에 투입되어 요구사항 정의, 설계,

구현을 담당하게 된다. 몇주간 온종일 워크샵을 하고 번거로운 리뷰가 요구되고 반복되나, 결국

요구사항을 이해하지 못한 채 시작부터 잘못된 그 시스템이 그대로 출시된다.

1 년이 빠르게 지나고- 꼬여 있는 문제들은 시스템 외적으로 해결되고, 업무는 여전히 부드럽게

이어진다. 규정이 변화함에 따라, 새로운 생산라인과 조직구조는 시스템을 강화하기 위한

프로젝트로 이어진다. 많은 IT 스텝이 이미 다른 프로젝트에 투입되었거나, 새로운 기회를 찾아

이직했거나 혹은 퇴직했다. 현업에서 무엇을 결정했고, 어떤 정책을 따라야 하며, 어떤 경험을

했는지 또, 데이터 품질을 강화하기 위해 필요한 데이터 제약사항은 무엇인지에 대해서 설명하는

같은 일을 반복하는 워크숍을 하기 위해, 재일정을 잡아야 한다는 사실이 현업을 무척

실망시킨다. 많은 현업은 워크숍에 참석하지 않는데, 그 이유는 1 년 전처럼 시간만 낭비할

것이라고 믿고 있기 때문이다. 그들은 새로운 프로젝트에 참여하고 싶은 동기가 없다.

만약, 그 프로젝트 팀이 지금까지의 요구사항을 모두 제공하고, 비즈니스 규칙 변경을 염두해 두고

있는 현업 담당자들과 당시 요구 사항을 검토하고, 일정 시간 내에 수정사항이 반영된 모델을 완성할

수 있다면 어떨까? 앞으로 사업부서 사용자들에게 프로젝트를 위한 시간을 요구할 때 좀더 자신감이

생기지 않을까?

변화에 대해서 좀 더 빠르고 정확하게 대응

사업부서가 IT 조직에 대한 인식에 영향을 주는 또 다른 요소는 법규나 규제 변화에 대응하는 IT

조직의 능력이다.

새로운 법규, 그리고 사생활 정보와 반 테러 노력과 관련된 공공의 신뢰에 대한 관심은 데이터

관리에 직접적인 영향을 끼쳤다. 이제 기업이나 조직은 데이터가 어떤 방식으로 외부로부터 차단되고

보호되고, 노출되는 지에 대해 설명해야만 한다. 많은 법을 통해서 특별히 관리되어야 하는 정보

속성들이 명시되고 있다.

예를 들면, 캘리포니아 해커 법은 SSN(사회보장번호, 우리나라의 주민등록번호와 같음), 은행카드번호,

운전면허 번호 공개에 대한 공지 규정이 포함되어 있다. 여기에 명시된 속성들은 많은

정보시스템에서 발견된다. 사회보장 프로그램, 은행, 라이선스와 같은 관련 핵심 기능이 아닌 일반

비즈니스 시스템에서도 쉽게 발견할 수 있다. 사생활 보호 법규 또한 특정 개인의 신상에 관한

데이터에 중점을 두고 있다. 사베인 옥슬리(Sarbanes Oxley)와 같이, 보고서에 대한 공공의 신뢰를



향상시키기 위한 법규는 데이터 엑세스, 정보 리포팅, 데이터 품질 보장과 같은 활동에 대한 공식적인

통제를 요구한다. 이러한 법규들이 요구하는 바를 따르자면, 기업과 조직은 민감한 데이터에 대해

올바르게 관리하고, 누가 어떻게 사용했는 지를 추적해야만 한다.

불만이 차 있는 한 직원이 어느 날 밤 두 대의 운영 서버를 가지고 사라진다. 사라진 하드웨어와

저장되어 있는 정보를 수사하는 동안 경영진은 “사라진 서버에는 정확하게 어떤 데이터가

있는가?” 그리고 “우리가 데이터 보호법 조항을 준수하고 있었는가?”를 질문한다.

데이터 아키텍트는 사라진 서버 장비에 있던 데이터베이스에 대한 물리 모델과 저장되어 있던

기타 데이터를 확인한다. 그녀는 몇 몇의 민감한 데이터가 포함되어 있지만 법규에 따라

암호화되어 있었다는 것을 알아낸다. 그리고 나서, 데이터베이스에 저장된 데이터의 종류에 대한

목록을 제공한다. 그 결과 고객 서비스와 공공 사법 기관은 법무팀의 가이드라인에 맞추어

제시했던 질의를 처리하게 된다.

전사 데이터 아키텍처는 데이터의 위치와 상태에 대한 사업부서의 비즈니스 요청을 지원할 수 있는

탄탄한 기반(Framework)을 제공한다.

전문가 보고서 증가

강력한 프로세스도 중요하지만, 유연하면서도 필요한 기능이 충분한 데이터 관리 도구를 확보하는 것

또한 중요하다. 사업부서 사용자와 IT 전문가들은 읽을 수 있고, 커스터마이징할 수 있고, 유연하고,

무엇보다도 이해할 수 있는 모델을 가지기를 원한다.

데이터 모델링을 경영 관리에 지원하는데 있어서 포맷이 엉성하고,

검토하기도 어려운 프린트 출력물이 잔뜩 싸여 있는 것 보다 큰 장애물은

없다.

경험으로 볼 때, 잘 표현되고, 흐름이 훌륭하게 진행되는 모델은 IT 조직 내부의 자신감을 크게

증가시킨다. 잘 표현된 모델은 전사 아키텍처가 전문가에 의해 작업이된 산물이며, 이 전문가들은

정보 기술을 관리하는 철저한 프로세스를 확보하고 있다는 이미지를 강화 시켜준다. 잘 표현된

모델은 전사 아키텍처는 전문가 활동의 산물, 이러한 전문가가 정보기술을 관리하기 위한 전반적인

프로세스를 가지는 이미지를 강화시켜준다.

IT 활동에 대해 전사 데이터 관리 접근을 함으로써 팀원들에게 기업이 가진 지식 기반을 제공하게

된다 – 하나의 리소스가 계획, 평가, 검증, 규제 준수 활동 개발 등에 두루 사용된다. 이를 통해 사업

부서에서는 자신들의 프로젝트가 잘 진행되고, 자신들의 시간이 잘 사용되어 지고, 그 결과 전문가

수준의 완전한 결과로 이어질 것이라는 확신을 갖게된다.

잘 표현된 모델은 전

사 아키텍처가 전문

가가 작업한 결과라

는 이미지를 강화시

켜준다.



함정

어떻게 이런 함정들에 빠지게 되고, 이 함정들을 어떻게 피할 것인가….

지금까지 효율적인 전사 데이터 관리가 주는 이점에 대해 살펴보았다. 이제 반드시 피해가야 하는

함정들을 알아보자. 경험이 많은 IT 전문가도 실수는 한다. 그러나 적절한 툴과 기술을 사용하면

적어도 심각한 실수는 하지 않는 다는 것을 확신할 수 있게 된다. 각각의 실수에 대해서 살펴보면서,

실제로 이러한 실수를 피해가기 위해 ER/Studio 를 어떻게 활용하는지도 함께 보겠다.

실수 1: 전사(Enterprise) 아키텍처가 살아있는 프레임워크라는 사실을 놓친다

일부 IT 전문가들은 데이터 아키텍처를 비즈니스에 대한 다양한 버전으로 인식하는 것이 아니라

최종의 고정된 결과물이라고 생각한다. 많은 프로젝트 계획에서는 데이터 모델링 활동에 대해

시작일과 종료일을 산정한다. 예를 들면, 논리 모델은 목요일에 끝나고 물리 모델은 금요일에

시작하는 것이다. 여기에는 개선을 위한 작업이나 인원은 할당하지 않는다. 이와 같이 끝이 곧

시작이라는 사고방식은 작업과 프로젝트에 대한 불완전한 이해 그리고 사업부서의 니즈(Needs)를

충족하지 못하는 결과를 초래할 수 있다. 뒤늦게 도출된 비즈니스 요구사항은 반영하는 것과 같이

지속적인 개선과 정제 작업은 어떤 모델링 과정에 있어서도 자연스러운 현상이며, 또 추가 작업이

당연히 예견되는 것이다. 만일 데이터 관리 전문가가 아닌 사람이 혼자서 세운 프로젝트 계획이라면

이와 같은 난관은 100% 발생될 것이다.

만일 다른 프로젝트 결과물과 똑같이, 데이터 모델 또한 버전이 존재하고, 공유되고 재사용 될 수

있다는 사실을 팀원들이 이해하지 못한다면 프로젝트 라이프 사이클 동안 모델의 역할을 잘못

이해하고 있는 것이다. 프로젝트 각 단계는 외부 요인으로 인해 이전 단계에서 이루어진 결정, 이해,

변경을 지속적으로 정제해 가게 된다.

모든 팀원들이 논리 모델에서 물리 모델 그리고 물리적인 데이터베이스 구현까지 적용된 비즈니스

개념을 추적해야 할 수 있어야 한다. 이러한 추적 능력이야말로 전사 데이터 관리 프로그램의 이점을

깨우쳐주는 중요한 요소이다.

ER/Studio 는 이러한 정제와 추척 능력을 향상시킬 수 있도록 설계되어 있다.

라운드 트립 (Reverse/Forward) 모델링

ER/Studio 는 모델러와 설계자들이 논리 모델을 변경하고, 물리 모델에 필요한 만큼만 반영하며, 실제

데이터베이스에 변경 내용을 적용할 수 있게 해준다. Where Used 기능을 사용하면 누구든지 모델링된

데이터 개념이 어떻게 구현되었느지 볼 수 있다. 또한 데이터베이스에서 발생된 변경 내용을 해당

모델과 비교할 수 있다. 모델러는 비교 결과를 가지고 해당 변경 사항이 논리 모델이나, 물리 모델에

반영할 것인지 아닌지를 결정할 수 있다.



Compare and Merge (비교 / 병합)

ER/Studio 는 모델과 데이터베이스, 데이터 모델, DDL 간을 넘나들며 비교할 수 있다. 비교 결과에

대해 모델러가 상세한 수준에서 차이점들을 확인하고 어떻게 처리할 지 결정할 수 있다. 첫 번째

모델에 적용하거나 두 번째 모델/데이터베이스에 적용 및 무시 할 수 있다. Compare and Merge

기능은 모델러가 엔터프라이즈 차원에서 모델러들이 프로젝트를 넘나들며 전사 데이터 오브젝트를

공유할 수 있도록 해준다.

버전 관리 (Versioning)

모델과 오브젝트를 리포지토리에 추가할 때에는 설명(Comment)과 함께 버전 별로 관리할 수 있다.

또한 모델이 리포지토리에 하나의 스냅샷으로 체크인되어 올라가게 되면 특정 시점의 스냅샷을

완전하게 볼 수 있다.

일괄 네이밍 (Universal Naming)

모델링 작업을 하는 과정에서 용어 표준을 정제하거나, 하나의 용어를 참조하고 있는 모든 사항을

일괄적으로 다른 용어를 참조하도록 일괄 변경하기로 결정하는 경우는 흔다다. 예를 들어 기업에서

CLIENT 라고 하던 것을 CUSTOMER 로 모두 변경하기로 결정을 할 수 있는데, Universal Naming

Utility 는 이러한 변경을 쉽고 정확히 수행 해준다. 이 유틸리티는 모든 CLIENT 를 CUSTOMER 로 일괄

변경할 때 하나 하나 확인하면서 진행할 수도 있고, 한꺼번에 일괄 적용할 수도 있다.

역정규화 맵핑 (Denormalization Mapping)

ER/Studio 는 테이블 분할 (수직 분할, 수평 분할), 서브타입 롤업(rollup) 롤다운(roll down), 테이블

간의 동일한 컬럼 중복, 테이블 병합 등 흔히 발생되는 물리 모델 상의 변경 사항을 잘 지원한다.

모든 변경 사항은 역정규화 맵핑 기능을 통해 논리 모델에 있는 원천 오브젝트을 연결하여 유지하게

된다. 모델러는 Where Used 기능을 통해서 논리와 물리간의 변경과 연관 정보를 찾을 수 있다.

테이블 분할과 서브타입을 수퍼타입과 통합 혹은 분리, 테이블간 컬럼 중복 등 이와 같은 일반적인

물리모델 변경을 지원해준다. 역정규화 맵핑(Denormalization mapping) 기능을 통해 완료된 모든

변경은 논리 모델 오브젝트와 연결을 지원해 주고 모델러가 논리에서 물리로 변경을 찾아 갈 수

있도록 도와 준다.

비즈니스가 변경될 때, 기술 제약과 한계가 수정될 때, 추가 분석 작업이

완료될 때에는 현실적으로 해당 모델과 그 내용이 변경된다. 변경에 대한

적정한 대응력을 확보하면 IT 부서의 사업에 대한 자신감이 증가하게 된다.

변경에 대한 적정한

대응력을 확보하면

IT 부서의 사업에

대한 자신감이 증가

하게 된다.



실수 2: 모델이 잘 보이지 않고, 충분하지 못하다

모델을 잘 볼 수 없다면, 그것은 없는 것이나 마찬가지이다. 데이터 관리 노력이 비즈니스적인 가치를

제공하려면, 사용자가 접근할 수 있고, 이해할 수 있고, 공유할 수 있어야 한다. 모델은 쉽게 검색할

수 있는 방식으로 언제든지 사용될 준비가 되어야 한다. 의미에 대한 정의(definition)가 없는 모델은

단지 다이어그램일 뿐이며 다른 많은 방식으로 해석되게 된다. 따라서 정의와 적정한 메타데이터가

포함된 전체 모델을 제공하는 것이 중요하다.

사용될 준비가 되어 있는 모델일수록 보다 많은 IT 와 사업부서 전문가들에 의해 널리 사용되는 것은

당연하다.

ER/Studio 는 데이터 관리 팀으로 하여금 모델들이 항상 가용될 수 있는 상태가 되어 있다는 점을

확신할 수 있도록 도와준다.

보고서 문서 생성 (Document Reporting)

모델을 문서로 생성할 수 있다. 이 때의 문서는 보고서에 포함되어야 하는 메타데이터에 대해 원하는

깊이와 범위 수준으로 관리할 수 있다. 이러한 풍부한 텍스트 문서에는 메타데이터가 생생하게

표현되는 모델 다이어그램이 포함될 수도 있다.

중앙 리포지토리 (Repository)

ER/Studio 리포지토리를 활용하면, 팀 차원에서 모델들이 누구에 의해서 수정되었는지, 누가 체크아웃

할 수 있는지 누가 변경사항을 체크인 할 수 있는 권한이 있는지를 통제할 수 있으며, 이 모델은

공유될 수 있다. 이런 권한에 대한 관리자는 프로젝트 역할(role)을 만들어서 모델 권한 관리를 보다

단순화 할 수 있다. 리포지토리가 RDBMS를 사용하므로, 모델러들은 쿼리를 만들어서 원하는

데이터를 뽑아낼 수도 있다. 심지어 자신들 만의 메타데이터 검증과 품질 측정 유틸리티를 개발할

수도 있다.

전사 데이터 사전 (Enterprise Data Dictionary)

ER/Studio는 공유에 대한 필요성이 매우 높은 데이터에 대한 전사(Enterprise) 차원의 정의를

리포지토리를 통해 지원한다. 예를 들어 Person name이라는 표준 속성을 정의할 수 있다. 이렇게

정의된 내용은 전사 데이터 사전 (Enterprise Data Dictionary) 안에서 관리되고 모든 모델에서

공유된다. 이를 통해 모든 프로젝트 팀들이 통합될 수 있는 모델과 시스템을 구축하고 있다는 것을

확신할 수 있다.

모델을 보이지 않게 숨겨놓은 것에 대한 비용은 예산 작업 시 드러난다. 즉 “눈에서 멀어지면

마음에서 멀어진다”는 것과 같다. 모델은 온라인으로 그리고 프린트될 수 있게 제공해 주는 것이

최고의 해법이다.



실수 3: 업무(Business) 사용자들은 모델을 이해하거나 검토하지 못한다고 가정한다

이 함정은 주로 프로젝트 팀이 모델을 따라갈 준비가 부족할 때 빠지기 쉽다. 사업부서 사용자들은

자신들이 모델에 대한 적절한 교육을 받지 못했거나, 모델을 표현사는 방식이 불분명하고 일관성이

없다면 모델에 대해 검토조차 하지 않으려 할 것이다.

대부분의 사업부서 사용자는 모델을 이해하고 검토할 능력이 충분히 있다. 따라서 그들이 적절한 교

육을 받고, 구조적인 검토 프로세스에 따라 가이드를 제시 받고 모델에 대해 정기적으로 접근할 수

있으면 문제되지 않는다. 사용자들이 데이터 모델이 필요하다고 고집하는 경우는 우리 주변의 프로젝

트에서 흔하다. 모델 관련 교육에 참가하고, 데이터 모델의 중요성을 이해하게 되면 이들이 오히려 데

이터 모델을 고집하게 된다.

ER/Studio 뷰어

엠바카데로는 ER/Studio를 “읽기 전용”으로만 사용할 수 있는 버전을 제공한다. 따라서 사용자들은 모

델과 보고서를 보거나 출력할 수 있다. 또한 예기치 않은 변경이 발생할 위험으로부터 안전하다.

HTML 보고서 생성 (Reporting)

ER/Studio는 웹기반의 쌍방향 “인트라넷” 솔루션을 제공한다. 즉 HTML을 통해 다이어그램, 정의, 각

모델링 오브젝트에 대한 메타 데이터는 클릭을 통해 이동하고 탐색될 수 있다. 이러한 브라우저를 통

해 접근할 수 있는 사이트는 어떤 데이터가 모델링 되어 있고 어디에서 사용되는 지를 이해하고자 하

는 사람이면 누구나 접근할 수 있다. 이러한 웹 기반 모델은 메타데이터를 표현할 때 청중의 요구 수

준에 맞게 구성될 수 있다. 예를 들어 사업부서 사용자는 오브젝트와 그 정의에 대해 관심이 있을 것

이고, 개발자라면 보다 자세한 구현 속성들을 볼 필요가 있을 것이다.

사업부서 사용자는 모델들을 정기적으로 보다 보면 향후에 모델링 작업을 할 인력과 시간을 할당할

때 적극적인 지지자가 될 확률이 높다.

실수 4: 데이터 모델은 오직 테이터베이스 만을 위한 것이라고 생각한다

논리 데이터 모델과 물리 모델 모두 데이터베이스 지원 이상의 가치를 가진다. 논리 모델은 기술 독

립적이고, 데이터에 대한 요구사항을 텍스트 문서가 아닌 방식으로 정돈해준다. 물리 모델은 비즈니스

데이터 개념이 실제 어떻게 구현되어 있는지를 운영 시스템에 접근하지 않고도 보여준다.

데이터 모델은 단순히 데이터베이스를 구축하는 수단만은 아니다. 이것은 팀 전체가 수행하는 시스템

진화를 위해 사용된다. 이것은 제안요청서(RFP)를 작성하거나 검증 항목을 정할 때 사용될 수도 있

다. 신규 직원을 교육하거나 ad hoc 쿼리를 참조할 때에도 사용될 수 있다.

데이터 모델은 UML 클래스 모델, XML 스키마, 기타 인터페이스를 구축 등과 같이 모델과 관련된 개

발을 하는 팀원이면 누구나 쓸 수 있도록 만들어져야 한다..



ER/Studio는 아래와 같이 확장 기능을 제공한다:

메타데이터 가져오기 / 내보내기 (Metadata Import and Export)

모델러는 ER/Studio의 메타데이터 내보내기 기능을 통해 가치있는 메타데이터로 쉽게 익스포트 할 수

있다. 이를 통해 다른 모델링 도구, 데이터베이스 도구XML 스키마, 데스크 탑 애플리케이션 등 수 십

개의 다른 어플리케이션에서 ER/Studio로 가져올 수 있고, 또 원하는 포맷으로 저장할 수 있다. 메타

데이터 가져오기/내보내기 기능은 모델러가 협업을 통해 다른 아키텍처 전문가와 작업을 할 때 그 사

람이 어떤 도구를 사용하든지 관계없이 협업할 수 있도록 해준다.

Where Used 분석

ad hoc 쿼리를 작성하는 사용자는 모델의 “where used” 메타데이터에 대한 정의를 함께 검토할 수 있

다. 따라서 자신의 쿼리에 필요한 정보를 어디에서 가져오는 것이 가장 좋은 지 판단할 수 있다. 분석

가는 모델의 완전한 세트를 볼 수 있고 새 프로젝트에서 사용할 오브젝트를 골라낼 수 있다. 이렇게

전사(Enterprise) 자원에 대한 이해가 높으면 프로젝트 계획과 견적 작업 시 도움이 된다.

자동화 매크로 (Macros)

ER/Studio에 내장된 매크로는 메타데이터를 자동으로 추출하여 워드나 엑셀파일로 생성할 수 있도록

한다. 또한 전사(Enterprise) 메타데이터를 표현하기 위해 필요한 모든 데이터에 대해서 커스터마이징

된 리포트나 검증 스크립트 등을 개발할 수 있다.

첨부태그 (Attachments)

ER/Studio의 가장 강력한 기능 중 하나는 모델을 확장하여 커스터마이징 된 메타데이터를 추가할 수

있다는 점이다. 이 첨부태그는 모델 내의 오브젝트의 각 유형에 맞게 메타데이터를 추가하거나 각 인

스턴스에서 받아들일 수 있는 선택적 값을 사전 정의할 수 있다. 예를 들어 데이터 관리 책임자를 문

서화하고 싶다면 서브 모델 별로 전략 데이터 책임자를 태그로 붙여 놓을 수 있고, 각각의 엔티티에

대해서는 운영 데이터 책임자를 지정해 둘 수 있다. 또 다른 사례로, 사생활 규정 요구사항을 모델에

연결시켜서 각 엔티티에서 개인 신상 인식 정보가 들어있는가 아닌가를 표시해 둘 수 있다.

적용될 수 있는 값의 선택모델러가 커스터마이즈된 메타데이터를 포함하게 모델을 확장시킬 수 있게

해준다는 것이다. Attachments 기능은 팀이 모델링 오브젝트의 각 타입에 메타데이터를 첨부하여, 각

인스턴스에 선택적으로 값을 적용하는 것을 가능하게 해준다. 예를 들면, 팀이 조직 관리 정보를 문서

화하기를 원한다면, 서브모델에 전략적인 데이터 관리를 위한 Attachment를 추가할 것이다. 다른 예

를 들면, 사생활보호 법규 요구사항과 연관성이 있는 팀은 각 엔티티에 사생활 보호 관련 정보를 포

함하는지 여부에 대한 표시를 첨부할 것이다.

단지 데이터베이스만 생각한다는 것은 데이터 아키텍처 컴포넌트의 가치를 공유하는 기회를 놓치고

있다는 것을 의미한다.

실수 5: 데이터 모델은 완성 후 전달하는 것으로 끝이라고 생각한다



앞에서 살펴본 것과 같이, 일부 IT 전문가는 데이터 모델이란 프로젝트의 초기 단계에 작성하고 제출

하는 산출물 정도로 생각하고, 넘겨주고 나서는 모델이 언제 어떻게 사용될 것인지는 그 사람들 몫이

라고 생각한다.

장담하건대 이런 접근방식은 언제나 비즈니스 요구사항과 실제 구현간의 단절이 발생될 수 밖에 없다.

모델러는 어떤 요구 사항이 도출되어야 하는지 와 이것들이 어떻게 구현되어야 하는지 모두에 대해서

관여해야 한다. 그녀는 어디에 구현해야 하고 무엇을 변경해야 기술적 제약이나 성능 요구사항을 맞

출 수 있는 지에 대해서도 이해하고 있어야 한다. 데이터 모델러는 비즈니스 요구사항과 물리적 구현

간의 중재자이다

모델과 데이터베이스 동기화 (Synchronized Models and Database)

데이터베이스를 생성하고 수정하는 ER/Studio의 기능은 모델과 모델이 구현된 물리적인 데이터베이스

사이의 일관성이 확보하고 유지할 수 있도록 연결고리를 제공한다. 메타데이터 가져오기 / 내보내기는

모델 상의 요구사항에 대한 일관성있는 구현에 기여하게 된다.

역정규화 맵핑 (Denormalization Mapping)

역정규화는 물리 설계 시 자연스러운 작업이다. ER/Studio에서는 논리 모델과 이것이 적용될 수 있는

다른 물리 구조 사이에 대한 맵핑 정보를 유지한다. 따라서 물리 설계 변경이 발생할 때 이것이 논리

모델에 있는 원래의 의도를 유지하고 있는지를 확신할 때 사용될 수 있다.

실수 6: 보기 좋은 떡이 먹기도 좋다는 사실을 생각하지 않는다

효율적인 전사 데이터 관리의 주요 이점의 하나는 커뮤니케이션이 향상된 다는 것이다. 모델의 표현

이 명확하고 이해하기 쉬워야 한다는 것은 매우 중요하다. 모델 다이어그램에는 모델러가 아닌 사람

도 모델링 오브젝트의 의미와 의도를 따라 갈 수 있도록 가이드가 포함되어 있어야 한다. 모델은 읽

기 쉽고 주석이 잘 되어 있어야 한다. 모델은 재미있어야 한다. “흥미”가 가지는 가치를 절대로 우습게

여지기 말자.

모델러가 분석한 결과를 표현하는 것을 도와주게 되는 다이어그램 기술의 사례:

색상 활용 (Use of Color)

독특한 회색 그림자를 사용하거나 특정 모델링 오브젝트 만을 강조해주는 색상을 사용하면 모델을 검

토하는 사람과 보다 효과적으로 커뮤니케이션 할 수 있다. 예를 들면, 정보 책임자를 표시하거나, 변경

된 엔티티만 강조하거나, 우선 검토되어야 하는 엔티티를 표시할 때 사용될 수 있다.

ER/Studio는 고개 맞춤 색상을 지원하므로 모델러가 의도한데로 효율적으로 스키마를 다채롭게 표현

할 수 있다.

더 나아가 Macro기능을 통해 자동으로 색상을 적용할 수 있다. 즉 사용자가 선택한 오브젝트, 첨부태

그(attachment) 등 사용자 정의 메타데이터 또는 모델링의 완성도를 기준으로 해당 오브젝트에 자

동으로 색상을 표시하는 것이다.



다이어그램 오브젝트 사용 (Use of Diagramming Objects)

ER/Studio에서는 사각형, 글상자 등 드로잉 오브젝트를 그려 넣을 수 있다. 이를 통해서 다이어그램에

노트를 추가하거나, 특정 오브젝트 그룹을 강조할 수 있다.. 드로잉 오브젝트는 비즈니스 룰에 대한 의

사소통을 향상시키고, 중요한 정보에 대한 주의를 집중 시키고 사용자 검토가 보다 용이하게 해줌으

로써 모델 품질을 높일 수 있다.

자동화 사용 (Use of Automation)

자동화 매크로(macro)는 전사 전사 모델 관리나 특정 프로젝트의 고유한 요구사항을 중족 시킬 수 있

도록 확장되고 커스터마이징 될 수 있다. 따라서 모델러는 자신만의 맞춤형 자동화를 구현할 수 있다.

실수 7: 모델러 혼자 만이 모델을 소유하고 있다고 착각한다

마지막으로, 저지를 수 있는 가장 위험한 실수는 데이터 모델이 모델러 혼자만의 개인 소유물로 다루

는 것이다. 모델은 비즈니스에 종속되어서 표현되어야 한다. 즉 모델은 개방적으로 공유되고, 모델을

원하는 누구나 접근할 수 있고, 별도의 프린트물로 보관할 수 있고, 교육을 통해 읽는 훈련이 제공되

어야 하고 무엇보다 모델 자체가 명확하고 이해하기 쉽도록 노력이 해야한다는 것을 의미한다.

모델과 모델 안에 있는 메타데이터는 기업 자산으로 봐야 하며, 모델러와 현업의 파트너쉽에 의해 잘

관리되어야 한다. 만일 기술 명세처럼 표현된다면 개발자와 데이터 관리자만 이해될 수 있을 것이

고, 그 결과 전사 데이터 아키텍처로서의 이점을 가지지 못하게 될 것이다.

앞에서 설명한 ER/Studio 특징 모두는 모델이 단순히 데이터베이스에서의 사용되는 것 그 이상이 될

수 있도록 한다. 즉 사업부서 사용자들 또한 모델을 기반으로 커뮤니케이션 할 수 있도록 해준다 –

표현방식, 업무 방식, 전사(Enterprise) 아키텍처 도출, 흥미로운 사용 등이 제공되므로 사업부서와

비즈니스에 솔루션을 제공해 주는 자연스럽고 유익한 전사 데이터 모델이 될 수 있도록 도와준다.

결국 하고 싶은 이야기는…

이 글을 통해 데이터 통합과 프로젝트 협업을 향상시키면서도 프로젝트의 리스크는 줄이기 위해

전사(Enterprise) 데이터 관리가 얼마나 중요한지를 독자들이 알 수 있게 되기를 바란다.

커뮤니케이션이 강화되고, IT 조직 내에서 자신감이 증가하는 것과 같은 이점들은 비즈니스

니스(Needs)를 충족시키기 위한 결정적인 요소이다- 특히 외부로부터의 요구사항을 해결해야 하는

경우에는 더욱 그러하다. 비용 절감과 비용에 대한 신속한 대응이라는 이점이 점점 증가하게 되는

것은 데이터 관리를 전사 관점에서 접근을 하게 될 경우 자연스럽게 생성되는 결과물이다.

모든 프로젝트에 있어서 리스크가 있는 것은 자연스러운 것이다. 잠재적인 리스크를 이해하는 조직은

리스크를 피하여 보다 잘 위치를 잡을 수 있게된다. InfoAdvisors와 ER/Studio는 전사 데이터 관리를

새롭게 시작할 때 발생되는 실수와 난관을 경감시키는 중요한 역할을 담당할 수 있다.



후원사에 관하여

엠바카데로 테크놀로지는, 1993 년에 설립한 데이터베이스 툴 제작사입니다. 2008 년에 볼랜드의

개발툴 부문 「CodeGear」를 합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가

다양한 환경에서 소프트웨어 애플리케이션을 설계, 구축, 실행하기 위한 툴을 제공하는 최대 규모의

독립계 툴 제작사입니다. 미국 기업의 총수입 랭킹 「포천 100」중 90 개 기업과 전세계 300 만 이상의

고객이, 엠바카데로의 수준 높은 기술 제품을 채용하여, 생산성의 향상과 혁신적인 소프트웨어 개발을

실현하고 있습니다. 엠바카데로 테크놀로지스는, 샌프란시스코에 본사를 두고, 세계 각국에 지사를

전개하고 있습니다. 보다 자세한 것은, http://www.devgear.co.kr 를 참고하시기 바랍니다.

http://www.devgear.co.kr/



저자에 관하여

Karen Lopez 는 InfoAdvisors, Inc 의 수석 컨설턴트입니다. 저자는 20 년간 대형 멀티 프로젝트 수행

조직을 도와주는 일을 했습니다. 또한 8,000 여명의 데이터 관리 전문가로 이루어진 온라인

커뮤니티인 InfoAdvisors/ITBoards.com IRM 토론 그룹과 DM-DISCUSS, 온라인 데이터 관리 전문가

커뮤니티의 List Mistress 입니다.

InfoAdvisors는 캐나다 토론토에 위치한 데이터 관리 컨설팅 기업입니다. InfoAdvisors는 데이터 관리

이론의 응용에 강합니다. 이 기업의 철학은 비용, 이익과 고객사가 접하게 되는 기술로부터 위험을

수치화하는 것에서 시작합니다.

InfoAdvisors는 현업, 데이터 관리자, PM, 개발자와 같은 모델러가 아닌 분들을 위한 데이터 관리

이슈의 도입에 집중하는 트레이닝을 포함한 데이터 모델링 트레이닝을 제안합니다.

11066 Sheppard Ave East • Toronto, ON M1B 1G2

Phone 416-410-2937

www.infoadvisors.com

blog.infoadvisors.com

@datachick

[email protected]

전사 데이터 관리 반드시 피해야 할 7가지 실수

Technology