데이터 아키텍처
전사적 아키텍처와 데이터 아키텍처의 개념
이화식 대표이사
엔코아정보컨설팅
연/재/목/차
1회 데이터 아키텍처(이번호)
-전사적 아키텍처
-데이터 아키텍처의 개념
2회 실전 데이터 모델링 개론(12월호)
- 데이터 모델링의 접근
- 실전 데이터 모델링의 개요
3회 기본 논리적 데이터 모델링①(2004.1월호)
- 엔터티(Entites)의 정의
- 릴레이션쉽(Relationship)의 정의
- 속성의 정의
4회 기본 논리적 데이터 모델링②(2004.2월호)
- 식별자 확정
- 데이터 아키텍처 솔루션 II 미리보기
이 글은 DB 바이블로 불리는 '대용량 데이터베이스 솔루션1, 2'로 널리 알려진 이화식 엔코아정보컨설팅 대표가 최근 내놓은 국내 최초의 데이터 아키텍처 전문서인 '데이터 아키텍처 솔루션1'을 요약 정리한 것이다. 전사적 기업 데이터의 혁신으로 불리며 이미 구미 각국에서 차세대 데이터 산업의 핵심축으로 자리잡고 있는 'DA'의 정확한 의미와 가치를 조명하고, 앞으로 지향해야 할 구체적인 방향 등을 적극적으로 제시하고 있다.<편집자>
필자는 이 책을 집필하면서 단순한 사실이나 방법을 소개하기 보다는 무엇을, 어떻게, 왜 해야 하느냐의 관점에서 종합적인 사고와 합리적인 판단을 통해 구체적이고 객관적인 과정을 설명하려고 애를 썼다. 데이터 아키텍처를 수립하는 일은 매우 어려운 일이라고 할 수가 있다. 어떠한 일에 대해서 충분한 이해를 했지만 막상 자신이 시도했을 때는 마음대로 되질 않는다.
여러분이 서점에 가사 바둑책을 사서 충분히 그 내용을 이해한 줄 알았겠지만 생각 처럼 9급이 금방 9단이 될 수 있는 것이 아니라는 것을 뼈저리게 느꼈을 것이다. 이렇듯 데이터의 세계는 방법을 이해하는 정도로는 결코 정복할 수 없다.
이 책은 필자의 20년 노하우를 그대로 옮겨놓은 책이다. 정말 어렵고, 고통스러운 2년여의 집필기간이었지만 80%의 보통사람에 안주하고자 하는 사람이기 보다는 오로지 데이터의 세상을 이끌어갈 20%의 한차원 높은 무공을 익힐 준비가 되어 있는 여러분들이 있기에 각고의 노력을 소홀히 하지 않았다.
필자는 데이터 아키텍처의 패러다임 새로운 전환을 마련하기 위한 준비의 과정으로써 위의 그림과 같이 데이터 아키텍처 솔루션 방법론 정립과 데이터 아키텍처 솔루션 서적 편찬 그리고 데이터 전문 컨설턴트 양성에 촌음을 아끼며, 지속적인 데이터 아키텍처의 도구(Tool)개발로 여러분과 함께할 것이다. 국가와 기업을 구성하고 리드하는 '정보'의 바탕에 데이터가 있다. 이러한 데이터를 바로 세우는 것이 바로 혁신의 시작이라는 굳은 신념으로 여러분과 필자가 함께하길 간절한 마음으로 원한다. 스스로 오랜 기간 각고의 노력을 경주하는 것만이 여러분을 새로운 차원의 미래 세계로 인도할 수 있을 것이라는 것을 확신하며 데이터 아키텍처의 새로운 패러다임으로 한걸음 옮겨보자.
제 1 장 전사적 아키텍처
정보기술아키텍처(ITA, Information Technology architecture)는 정보시스템에 대한 요구사항을 충족시키고, 상호 운용성 및 보안성을 보장하기 위해 조직의 업무와 사용되는 정보, 그리고 이들을 지원하기 위한 정보기술 등의 구성요소를 분석하고, 이들간의 관계를 구조적으로 정리한 체계로써 전사적 아키텍처, 기술참조모델, 표준프로파일로 구성된다.
전사적 아키텍처(Enterprise architecture)는 업무와 업무실행에 필요한 정보, 이것을 지원하는 기술, 그리고 새로운 기술의 실행을 위한 전환 프로세스를 설명한 전략적 정보 자원의 기초이다. 기술참조모델은 업무 활동에 필요한 정보서비스를 규정하고 설명한 것으로서, 전사적 아키텍처의 모든 부문에서 고려된다. 기술참조 모델의 목적은 사용자 요구사항을 만족시킬 수 있도록 시스템 규격에 대한 개념적인 모델을 추상화하는 것이다. 표준프로파일은 기술참조모델에 명시된 서비스를 지원하는 정보기술 표준들의 집합을 말한다.
그러나 엄밀하게 말하면 정보기술아키텍처는 학자들의 주장에 따라 여러 가지 다양한 형태가 제시되고 있다. 물론 나름대로의 장·단점을 가지고 있으나 여기서는 어느 한쪽의 손을 들어주거나 나름의 평가를 하려는 생각은 조금도 없다. 그들이 어떠한 방법론적인 이론을 주장하든 데이터라면 반드시 지켜야 하는 올바른 형태와 체계적인 구성요소, 합리적인 접근 방법이 있을 것이다. 그러나 그렇게 해야 한다고 생각하는 사람들은 많이 있지만 구체적인 접근방법을 알지 못하기 때문에 더 이상 앞으로 나아가지 못하고 있는 것이 작금의 현실이다. 여기서는 이들을 위해 보다 실전적이고 체계적인 솔루션을 구체적으로 제시하려는 것이다.
정보기술의 기반이라 할 수 있는 데이터의 완벽한 아키텍처를 수립하기 위해서는 체계적인 접근방법과 내용의 합리성을 극대화시킬 수 있는 구체적인 판단기준들이 필요하다. 여기서는 개괄적인 데이터 집합을 정의하는 최상위 단계에서부터 데이터에 관련된 상세한 규칙과 실제 활동하고 있는 데이터를 다루는 최하위 단계에 걸쳐 지극히 체계적이고 구체적이면서도 철저히 실전적이며, 상식에 입각한 '판단의 근거와 기준'을 제시하게 될 것이다.
1.1 정보기술 아키텍처
데이터 아키텍처는 정보기술 아키텍처를 구성하는 하위개념에 불과하다고 생각할 수도 있겠지만 반드시 그렇다고 할 수만은 없다. 마치 상위부품에 구성된 볼트·너트가 비록 하위에 위치하고 있지만 그 자체만으로도 독립적인 부품이 될 수 있는 것처럼 데이터 아키텍처는 굳이 정보기술 아키텍처와 연관시키지 않고서도 독립적인 개념이 될 수 있다. 이처럼 독립적인 개념이 될 수 있다는 것은 설사 정보기술 아키텍처를 구축하겠다는 목적이 아니더라도 데이터 아키텍처는 구축되어야 할 충분한 이유와 분명한 목적이 있다는 것을 의미하는 것이다.
인간의 몸을 굳이 두 가지로 나누라고 한다면 '뼈와 살'로 구분할 수 있듯이 정보시스템 또한 '데이터(Data)와 애플리케이션(Application)'으로 나눌 수가 있다.
여기서 인간의 '뼈'에 해당하는 것을 '데이터'라고 한다면 인간(시스템)을 어떠한 측면(방법론)에 따라 조명해 보더라도 근본이 되는 뼈대(데이터)를 결코 무시할 수는 없다. 외형적인 모습은 다이어트나 운동을 해서 근육의 모습을 바꾸거나, 화장을 하거나, 다양한 옷을 착용함으로써 천차만별로 나타낼 수 있지만 몸 속의 뼈대는 잘 변하지 않는다. 물론 좋은 옷을 입고 짙은 화장을 하면 골격의 단점을 많이 제거할 수는 있겠지만 소위 '화장빨'로는 분명히 한계가 있다. 그렇지 않다면 누가 굳이 비싼 비용과 귀한 시간, 뼈를 깎는 고통을 감수하면서 성형수술을 하려고 하겠는가? 그럼에도 불구하고 여기서 정보기술 아키텍처의 한 구성요소로서 데이터 아키텍처를 언급하고자 하는데는 이유가 있다. 필자는 오랫동안 데이터 중요성을 강조해 왔고, 데이터 및 데이터베이스를 중심으로 시스템을 구현하는 구체적인 방법을 제시해 왔으며, 이를 증명하기 위해 실전에서 놀라운 기적(?)들을 보여 주었다.
가령 2,000라인이 넘으며, 10시간 이상 수행되는 배치(Batch)처리 애플리케이션을 수십 라인으로 된 하나의 SQL로 바꾸어 10여분 이내에 수행되는 기적을 수 없이 보여 왔고, 책과 교육 등을 통해 이를 열심히 전파해 왔다고 자부한다. 그러나 사람들은 데이터 중심의 접근 방법에 대해서는 충분히 공감을 하면서도 실제로는 아직도 프로세스 중심의 접근 방법을 결코 벗어나지 못하고 있다.
무엇을 우선순위로 접근하든 간에 시스템의 본질에 해당하는 데이터 아키텍처를 수박 겉핥기식으로 수립해서는 정보기술 아키텍처를 수립하는 본연의 가치가 없어질 것이다. 또한 구체적이고 객관적인 방법론이 없다면 결코 제대로 된 데이터 아키텍처를 수립할 수 없기 때문에 이를 위해서는 매우 상세하고 체계적인 접근 방법이 필요하다.
이것은 누구나 이해할 수 있고 동조할 수 있는 상식적이고 실전적인 시각에서 제시 되어야 한다. 설사 정보기술 아키텍처를 수립해야만 한다는 당위성의 위력을 빌렸다는 핀잔을 듣는 한이 있더라도 데이터 아키텍처를 제대로 수립해야 한다는 필연성이 확고해지기만 한다면 조금도 개의치 않겠다는 것이 필자의 작은 소망이다. 이러한 의미에서 정보기술 아키텍처의 힘을 빌리기 위해서라도 이에 대한 간략한 개념과 도입 필연성에 대해서 먼저 알아 보는 기회를 가지도록 하겠다.
기술참조모델은 업무활동에 필요한 정보서비스를 식별하고 설명한 것으로서 전사적 아키텍처의 모든 부문에서 고려된다. 기술참조모델은 개념을 추상화한 플랫폼을 제공하며, 구성요소간의 인터페이스를 정의한다.
기술참조 모델의 목적은 사용자의 요구사항을 만족시킬 수 있도록 시스템 규격에 대한 개념적인 모델을 추상화하는 것이다. 표준프로파일은 기술참조모델에 명시된 서비스를 지원하는 정보기술 표준들의 집합이다. 이것은 표준이 기반이 되는 서비스들 간의 인터페이스를 다루는 표준들이나 표준들에 대한 참고자료들로서 운영체계, 네트웍, 데이터 교환과 같은 서비스를 가능하게 하는 기술 표준들을 다루는 상세 규격을 포함하고 있다.
1.1.1 정보기술 아키텍처의 개요
정보기술 아키텍처의 주요 목적은 개별 정보자원의 계획, 설계, 구축 및 관리하는 방향을 제공하려는 것이다. 다시 말해서 정보시스템에 대한 요구사항을 충족시키고, 상호 운용성 및 보안성을 보장하기 위해 조직의 업무와 업무의 추진을 위해 사용하는 정보, 그리고 이들을 지원하기 위한 정보기술 등의 구성요소를 분석하고, 이들간의 관계를 구조(프레임웍, framework)적으로 정리한 체계를 말한다.
즉, 정보기술 아키텍처는 모든 정보 프로세스를 지원하는 요소들간의 관계를 구조화한 집합으로써 크게 전사적 아키텍처 (Enterprise Architecture), 기술참조모델 (Technical Reference Model), 표준 프로파일 (Standards Profile)로 구성된다.
1.1.2 정보기술 아키텍처의 등장 배경
패러다임의 변화와 IT 환경의 급격한 변화는 오늘날의 경영환경을 본격적인 정보화 시대로 도래하게 하였고, 국제화의 급속한 진전과, 기업간의 인수·합병, 소비자 요구의 고급화 등에 따라 국제화와 산업개편이 가속화 되었으며, 더욱 전문화 되고 다각화 된 형태로 나타나고 있다.
이에 따라 경영환경의 목적이 효율과 효과를 지향하는 패러다임으로 확실하게 변해 가고 있다. 이러한 변화는 필연적으로 모든 변화의 기반이 되는 정보기술 환경의 변화를 불러와 네트웍의 보편화, 전자상거래, 보안, 데이터마이닝의 필요성과 신속한 경영의사 자료의 요구성을 크게 높여 주었고, 이를 위해 클라이언트/서버 및 분산/객체 환경으로 변화가 더욱 가속되고 있다.
그럼에도 불구하고 기존의 개발 방법론의 여러 가지의 문제점으로 인해 엔터프라이즈의 목적과 아키텍처 부문의 연계는 아주 미흡하였다. 결국 이러한 문제는 경영효과의 최대화를 위한 기반이 되는 정보시스템을 근본적으로 불안하게 함으로써 빈번하게 아키텍쳐를 조정해야 하는 악순환을 반복하고 있는 실정이다. 따라서 정보시스템 활용을 통한 조직목표의 효과적인 달성과 전략적 우위 선점이라는 기업의 목적을 위해서는 체계적인 정보기술 아키텍처의 도입이 절실히 요구된다고 하겠다.
이러한 문제를 근본적으로 해결해 보자는 취지에서 대두된 것이 정보기술 아키텍처라 할 수 있다. 물론 과거에도 정보전략계획 수립에서부터 개념설계, 상세설계, 개발에 이르는 단계적인 접근도 분명히 존재했었다. 그러나 앞서 설명했던 것처럼 전사적인 시각에서 구조적으로 접근하지 못하였고, 문서적으로만 접근하였으며, 각 단계들이 서로 단절됨으로써 지금 우리가 겪고 있는 문제들을 필연적으로 떠 안게 되었다. 그러나 이제는 더 이상 그대로 방치할 수 없다는 상황을 자각해 가고 있기 때문에 어느 때 보다 이에 대한 근본적인 해결책이 절실히 요구되는 것이다.
1.1.3 정보기술 아키텍처를 통한 해결
지금 대두되고 있는 문제의 핵심이자 해결의 키 포인트는 어떻게 전사적인 영역을 '구조적'으로 접근하여, 매우 '구체적'인 전략을 문서화가 아닌 '데이터화'로 할 수 있느냐에 있다고 하겠다. 이를 위해서 필연적으로 뒤 따라야 하는 것이 바로 '시스템화'와 '전문화'라고 할 수 있다. 결국 이 키워드를 어떻게 완벽하게 만족하도록 할 것이냐에서 문제 해결의 대안을 찾아야 할 것이다.
어떤 조직에서든 프로세스를 담당하는 사람이나 조직들은 항상 존재하므로 무엇보다도 시급한 것은 데이터를 전문적으로 취급하는 조직이 필요하다고 할 수 있다.
사실 근자에 들어와서 여러 곳에서 데이터분석가(DA, data Analyst), DA팀, 데이터통제실(DCC, data control center), 데이터 아키텍트, 데이터모델러, 컨설턴트 등의 직함을 가진 사람이나 조직들의 등장이 점차 붐을 일으키고 있다. 이들이 기존의 DBA와 근본적으로 다른 것은 역할을 '데이터베이스'에 국한하지 않고 보다 큰 영역인 '데이터'에 까지 확장하였다는 것을 들 수 있겠다.
특히 시대의 흐름에 선도적인 대기업에서는 정보기술 아키텍처의 도입에 대한 외적인압력에 편승하여 자의 반 타의 반으로 이러한 조직들이 생겨나고 있다. 그러나 문제는 그리 간단해 보이지 않는다. 팀장이 존재하지만 분명히 그는 데이터 전문가라고 할 수 있는 수준이 아니다. 그 아래 팀원들이 여럿 있지만 그들 또한 전문가라고 하기에는 많이 부족해 보이는 것이 현실이다. 그러나 첫 술밥에 배가 부르랴! 이제라도 진정한 니즈(needs)를 가진 조직이 탄생되었다면 미래는 분명 희망적이다. '필요가 발명을 낳는다'는 말처럼 필요성이 증대되면 이에 대한 해결책은 반드시 나타나게 마련이기 때문이다.
이제 명백해졌다. 여러분이 보다 발전된 모습의 정보시스템을 꾸려 나가기를 원한다면 지금 당장 자급자족 형태에서 벗어나야 한다.
물론 쉽지는 않겠지만 그래도 가장 빨리 전문화된 형태로 가기 위해서는 그 역할을 담당할 조직부터 만들어야 할 것이다. 설사 그들이 지금 보유하고 있는 내공(?)이 턱없이 부족하더라도 그들은 필시 어떤 방법을 동원해서라도 반드시 자구책을 찾게 될 것이다. 이로 인해 그들은 분명 머지 않아 확실히 변모된 모습으로 나타나 기존의 패러다임을 바꾸는 중추적인 역할을 하게 될 것이 틀림없다.
1.2 전사적 아키텍처 (Enterprise Architecture)
전사적 아키텍처는 조직에서 적용하는 각종 정보기술을 활용한 아키텍처와 시스템들을 총괄한 것으로서 업무 및 관리 프로세스와 정보기술 간의 관계를 표현한 것이다. 앞서 우리는 전사적 아키텍처는 업무와, 그 업무를 실행하는데 필요한 정보, 업무 실행을 지원하는데 필요한 기술, 그리고 업무의 변경요구에 적용할 새로운 기술로 전환하는 프로세스를 설명한 전략적 정보 자원의 기초라고 정의하였다.
전사적이란 의미는 조직의 모든 정보자산, 정보환경, 관계자들을 모두 포함하는 말이며, 여기서 조직의 범위는 아키텍처를 적용하는 범위에 따라서 달라질 수 있다. 가령, A라는 은행이 전사적인 차원에서 차세대 시스템을 구축하려고 한다고 생각해 보자. 만약 이 은행이 자신이 설립한 B라는 전문 시스템관리업체(SM조직)를 가지고 있고, 이번 프로젝트를 위해 C라는 개발업체(SI업체)가 선정되었지만 컨소시엄으로 하위에 다양한 전문업체가 포함되어 있다고 생각해 보자. 이처럼 여러 업체가 존재한다는 것은 결국 최종 목표는 하나이겠지만 세부적으로는 다양한 역할이 존재한다는 것을 의미하고 있다.
만약 이들이 동일한 목표와 목적을 기반으로 하여 각자의 역할을 상세화 하지 못하고 각자가 오합지졸처럼 무원칙 하게 제각기 별도로 진행한다면 그 결과는 불을 보듯이 분명하다. 이런 문제를 피하기 위해서는 각자가 맡은 역할을 순서와 상세화 정도에 따라 구조적이고 구체적인 아키텍처의 수립을 통해 진행하여야 할 것이다. 즉, 전사적이란 말에는 참여한 전체 조직이 해야 할 역할이 모두 필요하다는 의미와 그 역할들을 최상위에서부터 최하위에 이르는 모든 영역에 대해 정의되어야 한다는 의미, 그리고 이것들이 모두 직접적으 로 연결되어 있어 전체적으로는 하나인 것처럼 일관성 있게 체계적이어야 한다는 의미가 포함되어 있는 것이다.
1.2.1 전사적 아키텍처의 구성
전사적 아키텍처의 내용에는 다음에서 제시된 기본요소들이 어떠한 형태로든 포함되어 있어야 하며, 각 요소에 대한 구체적인 내용이 제시되어야 한다. 전사적 아키텍처의 기본요소는 다음과 같다.
- 업무 프로세스 (Business Process)
- 정보 흐름 및 관계 (Information Flows and Relationships)
- 데이터 서술 및 관계 (Data Descriptions and Relationships)
- 애플리케이션 (Applications)
- 기술 기반 (Technology Infrastructure)
1.2.2 전사적 아키텍처의 프레임웍
구조적이고 체계적인 전사적 아키텍처를 수립하기 위해 여러 가지의 프레임웍이 제시되고 있다. 이들은 각자 나름의 특징과 장·단점을 가지고 있으며, 간략히 비교해보면 <표1>과 같다.
프레임웍은 <표-1>에 있는 '구성요소'를 가로축으로 하고, '상세화 범위'를 세로축으로 하여 만든 매트릭스(선반, 틀, 구조물)를 말한다. 프레임웍은 말 그대로 구조물일 뿐이며, 그 속에 관리될 내용을 구체적으로 제약하지는 않는다. 많은 구성요소를 모든 상세화 범위에 대해 체계적인 내용을 수립해 넣는다는 것은 결코 쉬운 일이 아니다. 또한 그 속의 내용물에 대해 객관적인 평가를 할 수 없다는 현실적인 한계로 인해 과연 엄청난 비용을 쏟아 부어 아키텍처를 수립했을 때 그 만큼의 투자가치가 있을지, 혹은 과연 제대로 된 내용물이 지속적으로 관리되어 원래의 목적을 달성할 수 있을지에 대해서는 많은 현실적 과제가 남아 있기도 하다.
위에서 간략하게 몇 가지 프레임웍에 대해 알아 보았지만 아키텍처를 이해하기 위해서는 좀더 상세하게 알아 볼 필요가 있다. 그러나 이들을 모두 섭렵할 수는 없으므로 가장 대표적인 쟈크만 프레임웍을 좀더 깊이 분석해 보도록 하겠다.
<그림1-1-1>은 쟈크만 프레임웍을 보여주고 있다. 쟈크만은 가로축에 아키텍처의 구성요소들을 나열하였다. 세상의 모든 현상들은 육하원칙에 의해 설명이 가능하다. 쟈크만은 아키텍처를 수립해야 할 대상을 바로 이 육하원칙에 입각해서 정의하고자 하였다. 그림에서 볼 수 있듯이 그는 'What(본질, 대상)'에 해당하는 것을 '데이터'로 인정하였다. 이것은 곧 데이터야 말로 정보시스템의 근원이라는 것을 말하는 것이 아니겠는가?
본질들로 인해 발생되는 기능(function)을 'How(방법, 기능)'로, 이들이 위치해야 할 장소(H/W, S/W, Network) 아키텍처를 'Where'로, 업무를 수행하는 사람이나 조직을 'Who'로, 비즈니스의 목적과 동기에 대한 전략수립을 위한 아키텍처를 'Why'로 하여 모든 대상에 대해 빠짐없이 체계화 해야 한다는 것을 강조하고 있다.
세로축은 상세화 수준을 정의한 것으로써 가로축에 있는 모든 구성요소들을 이처럼 최상위 단계에서부터 최하위 단계에 이르기까지 모든 셀에 대해 아키텍처를 수립해야 한다고 주장하고 있는 것이다. 물론 현실을 감안했을 때 반드시 모든 것을 그렇게 해야 하는지에 대해서는 이견이 있을 수 있다. 그러나 여기서는 굳이 조직의 특성과 상황에 맞추어 경우에 따라 일일이 어떻게 접근해 가는 것이 가장 바람직한지에 대한 해답을 찾으려 하지는 않겠다. 그것은 이 책이 데이터 아키텍처를 위한 솔루션을 제시할 뿐이지 정보기술 아키텍처의 전체를 다룰 생각은 없기 때문이다.
특히 데이터 영역은 단순히 구조만 정의해 두게 되면, 아주 쉽게 집합의 본질이 변질되므로 최대한 매우 상세한 정의를 해야 할 필요가 있다. 데이터는 정보시스템의 기반이므로 데이터가 불명확해지면 갈수록 시스템은 복잡해지고, 결국에는 반드시 부패하게 된다. 데이터 모델이 비정상적인데도 불구하고 원하는 결과가 나왔다는 것을 다른 말로 한다면 데이터의 잘못을 바로 잡기 위해 애플리케이션에다 또 다른 잘못을 저질렀다는 뜻이 된다. 이쯤 되면 이제 데이터 모델의 잘못을 알면서도 수많은 애플리케이션을 수정해야 하기 때문에 함부로 데이터 모델을 교정할 수도 없다.
애플리케이션에서는 프로그래머의 능력에 따라 구현 방법에 많은 차이가 날 수 있으므로 굳이 지나치게 상세한 내용을 기술할 필요가 없을 수도 있다. 가령 어떤 사람은 복잡한 배치처리를 하기 위해 수천 라인에 이르는 알고리즘이 필요할 수도 있을 것이다. 그러나 집합연산을 통해 전혀 다른 방법으로 접근한 사람은 수십 라인의 SQL 몇 개로 처리할 수도 있다.
1.2.3 주요 아키텍처의 개념 비교
프레임웍 내에 체계적인 아키텍처를 수립해 넣기 위해서 사용하는 아키텍처 중에서 몇 가지 대표적인 것들을 좀더 명확하게 알아보기로 하자. 특히 이들의 개념과 상호 간에 작용하는 역학관계를 보다 자세하게 규명해 보는 기회를 가져보기로 하겠다. 여기서는 비즈니스 아키텍처, 애플리케이션 아키텍처, 데이터 아키텍처에 대해서만 설명하기로 한다. 여러분의 이해를 돕기 위해서 우리가 잘 알고 있는 '소'를 등장시켜 그가 가지고 있는 업무(역할, 비즈니스)와 기능(애플리케이션), 그리고 뼈대(데이터)를 통해 주요 아키텍처들의 본질적인 개념과 상호간에 작용하는 미묘한 관계를 조명해 보도록 하겠다. <그림 1-1-2>를 살펴보자.
이들이 정말 서로 독립적이라면 각각이 어떤 모습을 하고 있느냐에 따라 매우 큰 차이가 나타난다. 사실 비즈니스는 IT를 하는 사람들이 함부로 바꿀 수 있는 것이 아니다. 그렇다면 기능을 얼마나 적절하게 정의하느냐에 따라 달라진다. 즉, 최소의 기능으로 최대의 비즈니스를 만족시킬 수 있느냐에 따라 판가름이 난다는 것이다.
기능이 독립적이지 못하면 기존의 기능을 활용할 수 있음에도 불구하고 계속적으로 유사한 기능을 만들어 내야 한다. 이처럼 유사한 기능이 자꾸만 늘어난다면 시스템은 날이 갈수록 복잡해지고 업무와 데이터 간에 일관성이 저하되면서 시스템은 점차적으로 부패되어 간다.
이러한 문제를 효과적으로 해결하기 위해서 기능의 독립성을 강조하고, 보다 쉽게 서로 결합될 수 있도록 연결성을 확장함으로써, 기능의 변경을 최소화 하면서도 업무의 변화에 효율적으로 대처하자는 것이 바로 요즈음 크게 각광을 받고 있는 컴포넌트 기반 개발(CBD, component based Development) 방법론이다. 물론 이론적인 개념이야 매우 유용하지만 깊이 들어가보면 아직도 해결해야 할 것들이 많이 산재해 있기는 하다. 그러나 미래의 방법론은 정도의 차이는 있을지언정 반드시 이 부분이 강조될 수 밖에 없음은 너무나 분명해 보인다.
1.2.4 데이터 아키텍처가 최우선적인 이유
우리는 앞서 주요 아키텍처의 개념과 특징, 상호간의 상관 관계들을 간략하게나마 살펴보았다. 물론 어느 한 가지 중요하지 않은 것이 있으랴만은 막대한 시간과 비용, 노력이 투입되어야 하는 만큼 투자대비효과(ROI)를 생각하지 않을 수가 없고, 일에 대한 시급성이나 우선순위를 좀더 따져 보지 않을 수 없다.
그렇지만 여기서는 상황에 따라 달라질 수 있는 접근방법이나 절차, 거기에 따른 이해득실들을 따져 보는 것에 대해서는 언급하지 않겠다. 다만, 데이터 아키텍처가 '왜 좀더 근본적인가?'에 대한 물음과 먼저 체계화가 되지 않을 수 없는 필연적인 이유에 대해서만 알아보기로 하겠다.
여러분의 이해를 돕고, 보다 강렬한 인상을 심어주기 위해서 우리가 잘 알고 있는 진공관과 반도체 칩의 비교를 통해서 설명해 보기로 하겠다. <그림 1-1-3>을 살펴보자.
이 그림은 진공관을 이용하여 제작한 인류 최초의 컴퓨터인 애니악(ENIAC)과 반도체 칩을 이용하여 만든 노트북 컴퓨터를 서로 비교해 본 것이다.
그림에 나타나 있듯이 애니악 컴퓨터는 무게가 30톤, 2만개가 넘는 진공관으로 구성되어 있고, 배선의 길이를 합하면 130km에 달한다. 그러나 요즈음 시중에서 흔히 볼 수 있는 노트북 컴퓨터는 약간의 차이는 있겠으나 약2~3kg의 무게, 대략 30cm 내외의 넓이, 3cm 내외의 높이로 구 성되어 있다.
그럼에도 불구하고 애니악 컴퓨터는 286AT 수준에 불과하지만 노트북은 수백 메가에서 수 기가Hz의 CPU가 장착되고, 옵션에 따라서 다르기는 하지만 수십 기가의 디스크를 붙일 수도 있다. 그러나 가격을 비교해 보면 오히려 애니악 컴퓨터는 수십억원(?)이 들었겠지만, 노트북은 수백만원이면 충분히 구입할 수 있다. 게다가 앞으로도 성능은 더욱 향상되지만 가격은 오히려 계속해서 하락하게 될 것이다. 뿐만 아니라 애니악 컴퓨터는 단지 전기적 스위치의 점멸(on-off) 신호에 의해 알고리즘이 처리되기 때문에 만약 프로그램 내용을 변경시켜고자 한다면 명령어가 아니라 전선의 배선 위치를 다르게 배치해야만 한다. 따라서 단지 수식 계산에 국한되어 사용되는 '계산기(compute + r)'에 불과했기 때문에 이 기계의 이름마저 영원히 '컴퓨터'가 되어 버리도록 했던 것이다.
우리는 이 두 가지 컴퓨터에서 매우 중요한 것들을 발견할 수가 있다. 먼저 진공관이나 반도체 칩은 데이터로, 전선으로 구성되어 있는 회로는 애플리케이션으로 가정해 보자. 만약 우리가 진공관을 그대로 두고 회로만 최적의 상태로 정비하였다면 설혹 130km의 전선이 100km정도로 감소할지는 모르겠지만 그 이상에는 반드시 한계가 있을 것이다. 기가막힌 아이디어를 생각해내어 회로를 크게 개선했더라도 2만개의 진공관이 1만개 이하로는 결코 줄어들지 않을 것이고, 무게를 10톤 이하가 되도록 한다는 것도 절대로 쉬운 일이 아닐 것이다.
이러한 문제를 획기적으로 개선할 수 있는 유일한 방법은 수백~수천 개 진공관의 역할을 통합하여 단순화시킨 반도체 칩을 사용해야 한다는 것이다. 그렇지 않고서는 30톤의 장비를 3kg로 줄인다는 것은 절대 불가능하다.
정보시스템에서도 이와 마찬가지로 진공관처럼 흩어져 있던 데이터 구조를 반도체 칩처럼 단순·명확하게 통합하지 않는다면 아무리 애플리케이션 소스코드를 최적으로 작성하였더라도 결코 그 복잡도를 줄일 수는 없을 것이다. 그렇다면 과연 반도체 칩은 정말 단순하게 생겼는가? 사람이 조작할 필요가 없는 내부는 상상을 초월할 정도로 복잡하게 되어 있지만 사람이 조작하는 외부에는 단지 수십 개의 단자가 나와 있을 뿐이다.
데이터 모델에서도 이와 다를 것이 없다. 데이터 모델의 내부에 있는 데이터는 상상을 초월할 정도로 많고 다양하다. 그러나 그것을 담는 그릇인 엔터티는 일관된 특성을 가지고 있고, 다른 엔터티와 분명히 구별되는 체계적인 규칙을 가지고 있어서 겉으로 드러난 모습은 매우 단순해졌다면 이것이 바로 반도체 칩과 닮아 있는 구조라고 할 수 있다.
반대로 데이터 모델이 마치 진공관처럼 집적되지 않고 필요에 따라 복잡하게 흩어져 있다면 그 사이를 연결하기 위해서 수많은 전선이 필연적으로 필요해지듯이 애플리케이션에서 수많은 소스코드를 사용하여 유형별로 처리절차를 일일이 기술하여야만 한다. 만약 여러분들이 작성해 놓은 애플리케이션에 수많은 IF문이 존재하고 있다면 그것은 필시 진공관 형태의 데이터 모델을 가지고 있는 것이 틀림없을 것이다.
결론적으로 말해 본질에 해당하는 부품(엔터티)의 집적도를 개선하지 않고서는 아무리 회로(애플리케이션)를 개선하더라도 분명히 한계가 있다는 것을 알 수 있다. 결국 가장 큰 영향을 미치는 데이터를 근본적으로 개선하지 않고서는 어떤 방법을 사용하더라도 그것은 단지 미봉책에 그칠 뿐이라는 것이 분명하다.