데이터아키텍처의 설계도인 논리 데이터모델이 빅데이터와 AI 기술의 활용 단계애서 비즈니스 컨텍스트(context)와의 결합을 위한 데이터 카탈로그 기능의 요구가 늘어나면서 논리 데이터모델에 대한 체계적 관리의 중요성이 부각되고 있다. 이러한 논리 데이터모델 관리의 궁극적인 목표는 물리 데이터모델과의 “정합성“을 유지하는 일이라고 할 수 있다.
논리 데이터모델은 엑셀파일 형태의 메타데이터로 생산되고, 물리 데이터모델은 DBMS에서 동작하는 언어인 DML(Database Management Language), DDL(Data Description Language) 스크립트의 형태로 데이터베이스에 내재되어 있으므로, 결국 데이터모델 간의 “정합성“이란 데이터 산출물의 메타데이터 내용이 데이터베이스의 형상(속성+구조)과 정보가 일치하는 것을 의미한다.
논리 데이터모델의 활용성을 위하여 데이터모델 간의 정합성은 정보시스템이 운영되는 동안 지속적으로 관리 및 유지되어야 한다. 그런데 SW운영환경에서는 사용자의 요구에 의한 기능 개선이나 크고 작은 고도화 사업 또는 데이터오류 발생에 대한 조치와 같이 데이터모델에 다양한 변경 소요가 끊임없이 발생한다. 이러한 요인에 의해서 데이터베이스의 메타데이터 정보 즉, 데이터모델의 구조는 언제든지 변경될 수 있다.
운영 중인 데이터베이스의 메타데이터 정보를 변경하는 일은 정보시스템의 안정적인 서비스 지속에 중대한 영향을 미치는 일이므로 데이터품질관리나 소프트웨어운영 지침에는 변경 절차를 엄격히 명시하고 있으며 이에 따라 프로세스가 통제되도록 권고하고 있다. 이러한 업무 절차의 준수는 곧 데이터품질관리 활동의 평가 지표가 될 정도로 프로세스의 통제와 절차 관리는 데이터품질관리의 유일한 활동이라고 할 수 있다.
그런데 공공기관의 정보화 개발과 운영은 프로세스의 관리와 통제에 의한 데이터품질관리 체계의 유지가 매우 어려운 환경하에서 수행되고 있다. 대개의 개발 업무는 외부 사업자에 의하여 수행되며 정보화 운영업무와 SW유지보수 또한 IT아웃소싱에 의해 관리되고 있어서 조직 간의 협업과 소통을 기본으로 하는 데이터거버넌스 업무 활동에 많은 장애 요소가 있다. 게다가 입찰에 의하여 수시로 사업자가 바뀌게 되고 상주 인력의 잦은 교체 시 업무 인수 인계나 숙련도의 이전이 어려운 열악한 사업 관리 구조속에서 절차관리에 의한 데이터품질관리 효과를 기대하기는 어려운 현실이다.
공공기관의 정보화운영관리 환경에서 절차의 관리와 통제 수단에 의한 안정된 데이터거버넌스의 확보는 기대하기가 어려운 실정이다. 따라서 SW운영환경에서 데이터산출물의 메타데이터와 데이터베이스에 존재하는 메타데이터의 정합성을 유지하고 전사적 관점에서 논리데이터모델의 변경 관리를 지원하는 소프트웨어로 자동화된 관리체계가 필요하다.
메타데이터 정보가 변경되는 것은 데이터베이스의 형상(물리데이터모델)이 바뀐다고 할 수 있다. 또한 데이터 표준의 공표에 따라 논리 데이터 모델의 테이블명칭이나 컬럼명칭 혹은 데이터타입이 변경될 수가 있다. 형상(용어,도메인)이 변경될 수도 있다. 이때 (논리/물리)데이터모델 간의 정합성을 유지하기 위한 시스템은 SW형상관리와 유사한 기능으로 이를 ‘데이터아키텍처관리체계’라고 한다.
최근 행안부에서 데이터품질관리 수준 진단의 새로운 지표로 ‘예방적 데이터품질관리’를 추가하였다. 그러나 예방적 품질관리의 세부 내용을 살펴보면 역시 요구사항에 관련 절차의 명시와 제출 문서의 적시로 이루어져 있다. 제안요청서에 각종 절차를 명시하고 이에 따른 산출물을 요구한다고 하였을 떄, 실질적으로 이러한 요구사항의 이행 여부를 측정하는 것은 산출물의 제출 여부에 지나지 않는다. 데이터산출물의 특성상 산출물의 무결성과 정합성을 육안으로 검사하는 것은 어렵고 고통스러운 일이어서 산출물 제출 여부로만 검수가 이루어지는 관행이 지속되고 있다. 이런 문제의 보완을 위하여 산출물의 정합성을 측정하기 위한 자동화 된 시스템이거나 산출물 작성과정을 시스템에 의하여 자동으로 정합성이 유지되도록 강제하는 프로세스의 관리가 필요한 것이다.
예방적 품질관리의 지침에 따라 각 부문의 지침을 명시하고 해당산출물을 요구하였더라도 데이터품질에 영향을 미치는 것은 산출물의 제출 여부가 아니라 산출물의 무결성과 정합성의 보증이다. SW개발환경에서는 무엇보다 산출물의 검수를 위한 보완적 수단인 자동화 프로그램이 필요한 것이다. SW개발단계에서 구축되는 데이터아키텍처를 문제없이 구축해야 하는 책임은 온전히 사업자에게 있는 것이다. 현행 사업관리 방식 또한 이러한 관점에서 사업자가 완성한 데이터산출물의 완벽성을 검수의 과정에서 확인하도록 되어 있다. 그러나 데이터산출물의 특성상 육안으로 검사하는 일이 쉽지 않기 때문에 데이터산출물에 있을지 모를 결함이 발견되지 않은채 검수를 통과하는 일이 비일비재하다.
현행 메타데이터관리 솔루션의 기능도 모델링 프로세스를 기반으로 구성된 것이어서 SW개발단계에서 실질적으로 모델링 작업 절차를 번거롭게만 만들뿐 완성된 데이터모델을 SW운영환경에서 활용도 할 수 없는 기형 구조로 작동되고 있는 실정이다. 현행 사업관리 방식에 비추어 볼때, 데이터모델링 프로세스를 공공기관이 관리해야 할 이유가 하나도 없다. 프로세스의 관리는 사업자가 알아서 할 일이며 사업자는 온전한 데이터 산출물을 제출해야 할 의무를 이행하면 된다. 공공기관은 온전한 데이터 산출물 여부를 확인하는 자동화 된 검사 체계의 도입을 고려해야 한다.
| 개선점 | 메타관리시스템의 구성방안(■)¹ | ||
|---|---|---|---|
| SW개발단계 | 산출물의 무결성 정합성 검수방안 | ■무결성/정합성 검사체계² | ■MDR(모델DB)⁴ ■데이터표준관리체계 |
| SW운영유지관리환경 | 논리데이터모델 변경 및 정합성관리 절차통제 수단의 부재 | ■데이터아키텍처관리체계⁵ □ITSM시스템도입⁵ | |
注.
SW운영환경에서 데이터아키텍처관리체계는 두가지 측면에서 커다란 효용성이 있다. 첫번째는 IT관리체계로서의 역할이다. 데이터아키텍처의 설계도에 해당하는 데이터산출물의 논리데이터모델과 데이터베이스 간의 상호정합성(mutual consistency)을 유지하는 현행화는 정보시스템의 운영 및 유지보수나 기능개선, 고도화 비즈니스의 체계적인 수행을 위한 중요한 업무이다. 정보시스템의 유지보수나 기능개선을 위한 구조 변경 시에는 현행 정보화체계의 데이터아키텍처 분석을 위하여 논리데이터모델을 참조하게 되는데, 이때 현행화 된 논리데이터모델이 준비되어 있어야 한다. 물론 데이터베이스로부터 DDL을 읽어 소프트웨어를 이용하여 데이터모델을 시각화 할 수 있지만 데이터모델과 논리데이터모델의 한글 용어 매핑이 제대로 되지 않은 상태의 메타데이터 정보는 식별할 수 없거나 정확하지 않은 데이터로 인해 활용에 장애가 된다.
두번째는 수요자에게 데이터의 활용을 위한 비즈니스 컨택스트와의 연결이다. 논리데이터 모델의 테이블명칭, 컬럼명칭, 데이터타입 등의 속성(attribute)정보는 비즈니스 검색을 위한 키워드로 사용되거나 빅데이터와 AI의 분석의 대상으로 활용된다. 데이터플랫폼의 검색 인터페이스는 현행화 된 논리데이터모델을 데이터카탈로그 처럼 이용하여 데이터베이스의 메타데이터를 통해 리얼 데이터로의 접근이 가능한 데이터패브릭 환경을 구현할 수 있다. 데이터패브릭이 가능한 인프라 환경을 구성하려면 데이베이스의 구축 단계부터 운영의 전 과정에서 논리데이터모델의 현행화가 유지되는 데이터거버넌스가 작동되어야 하며 이는 SW로 자동화된 관리체계에 의하여 실현될 수 있다.
데이터거버넌스의 주요 기능인 데이터아키텍처관리체계의 (기능)요건은 아래와 같다.
데이터아키텍처관리체계는 그 대략적인 기능이나 용도로 볼 때 메타데이터관리시스템이라고 할 수 있겠으나 ‘데이터아키텍처관리’ 라고 구분하는 이유는 다음과 같다.
데이터에 대하여..메타데이터이며 데이터아키텍트를 구현하는 데이타를 메타데이터라고 한다.
데이터아키텍트 비즈니스는 데이터아키텍처를 구축하는 데이터모델링과 데이터아키텍처를 운영,유지관리 하는 비즈니스로 구분된다. 데이터모델링 비즈니스관리 SW를 데이터모델관리체계라고 하며 아키텍처의 운영,유지관리 비즈니스관리 SW를 데이터아키텍처관리체계라고 한다.
한편, 데이터아키텍처를 구성하는 메타데이터에 관하여 생성, 변경, 저장, 조회 등의 기능을 하는 SW를 메타데이터관리SW라 한다면 메타데이터관리SW는 데이터모델관리체계와 데이터아키텍처관리체계 두 가지로 구분되어야 함을 알수 있다.
데이터아키텍처관리체계는 메타데이터를 생성하거나 변경하는 모델링을 지원하지는 않는다. 단지 모델링 작업의 결과로 생산된 메타데이터의 무결성과 정합성을 검증하는 일로부터 시작하여 운영 단계에서 그 무결성과 정합성이 유지되도록 관리하는 것이므로 메타데이터관리체계의 정의에 부합하지 않는다. 만약 메타데이터관리체계의 ‘관리’ 범위를 좀 더 넓혀서 생각한다면 데이터아키텍처관리는 메타데이터관리의 일부 기능이라고 할 수도 있을 것이다.
두 번 째 이유는 이미 ‘메타데이터관리’라는 솔루션의 분류가 이미 국내 시장에 형성되어 있으며 기존 메타데이터관리 솔루션의 기능이란 것이 대부분 SW개발과 유지보수 관점에서 메타데이터의 정의, 변경, 저장, 조회 기능 위주의 관리체계이지 운영 환경에서 모델간의 정합성을 유지하여 비즈니스 컨텍스트와의 결합을 지원하는 기능의 구현이 불가능한 구조이기 때문이다. ‘메타데이터와 관련된 솔루션은 여러 종류가 있으며 국내에서 유통되고 있는 해당 솔루션 또는 메타데이터관리 기능을 이용한 데이터표준관리 솔루션에 가깝다고 봐야 할 것이다.
메타데이터와 관계된 솔루션은 데이터레이크, 데이터가상화, 데이터 카탈로그와 같이 세부적인 기능과 목적에 따라 분류되어 있는 것과 같이 데이터아키텍처관리 또한 메타데이터 관리를 이용하여 데이터모델의 정합성을 관리하는 기능이 가장 커다란 특징이 되는 것이다. 데이터아키텍처관리에는 메타데이터관리에 필요한 데이터표준 프로세스도 포함되며, 데이터카탈로그와 유사한 auto connecting, …rhk과 같은 기능도 포함이 된다.
데이터아키텍처관리체계는 데이터아키텍처의 오브젝트(데이터베이스)의 형상(구조+속성)의 변경 이력을 관리하는 소프트웨어이다. 데이터 산출물과 데이터베이스에 존재하는 모델 간의 형상의 변경과 변경 이력을 관리한다는 측면에서는 소프트웨어형상관리 솔루션과 그 기능을 비교해 보면 쉽게 이해가 갈 것이다. (같지는 않음)
| 소프트웨어 형상관리 | 메타데이터 형상관리 | |
|---|---|---|
| 적용업무 | 소프트웨어개발/운영유지관리 | 데이터베이스 구축/운영 유지관리 |
| 관리대상(산출물) | 1)실행프로그램 2)소스코드원본 3)개발환경 | a)데이터오브젝트: DML/DDL b)논리데이터모델 -용어정의서, 도메인정의서 -테이블정의서, 컬럼정의서 -데이터관계도 |
| 기능검수(테스트운영) | 동작 확인으로 1)과 a)에 대한 기능 오류 검증 | |
| 산출물검수(정합성) | 1)과 2)의 정합성은 자동검증(컴파일러) | b)논리데이터모델(엑셀파일)검증 1. 범정부/전사데이터표준 적절성 2. 텍스트오류 3. a)와 b)의 정합성(매핑,구조) 여부 |
| 변경절차(순서) | 2) 소스-코드변경> 1) 실행프로그램 빌드 | b) 논리데이터모델변경> a) DML/DDL변경 |
| ※ 절차자동준수 | ※ 데이터타입, 간단한 구조는 직접 a)변경 | |
| 솔루션의 주요기능 | 1. 소스코드 변경이력관리 2. 공동작업 조정기능 | 1. 데이터표준반영 2. 물리/논리데이터모델의 정합성유지 3. 데이터아키텍처 변경이력관리 |
注.
논리 데이터 모델과 비즈니스 컨텍스트와의 결합의 측면에서 본다면 데이터 카탈로그와 그 기능이 상당히 유사함을 알 수 있다. 그러나 데아터카탈로그와 다른 점은 전사적인 관점에서 메타데이터의 관리이며 이를 통하여 데이터카탈로그와 같은 기능을 지원하는 것이다.
데이터아키텍처관리체계는 데이터 카탈로그의 기능도 가지고 있으나 데이터 카탈로그는 메타데이터와 비즈니스 컨텍스트 연결을 위한 색인 기능 위주의 단순 구성인 반면 데이터형상관리는 데이터표준 프로세스를 실시간 반영하며, 데이터 오브젝트의 구조 정보에 대한 형상 관리까지 관리하며 전사적인 관점에서의 관리 영역이 확대되는 점에서 커다란 차이가 있다. (사실 데이터카탈로그도 원칙적으로는 비즈니스메타, 기술메타, 프로세스메타를 관리함)
| | 데이터카탈로그 | 데이터아키텍처관리 |
|---|---|---|
| 데이터관리범위 | 단위 데이터베이스(정보시스템) | 전사 데이터아키텍처 |
| 데이터베이스 구조기술 | 스냅샷 | 프로세스기반 |
| 메타데이터목록관리 | 논리데이터모델관리 | |
| 데이터베이스 커넥팅 | auto connecting지원 | auto connecting지원 |
| 색인표편집기능 | Programmable색인표, 데이터표준 | |
| 대상관리시스템 | 정보시스템단위 | 전사적인단위 |
| 데이터모델관리 | N/A | 가능 |
| 데이터흐름관리 | 지원 | 지원 |
| 한글데이터관계도(ERD) | N/A | 지원 |
| 응용분야 | N/A | 데이터가상화, 데이터패브릭 |
| 관리방향 | Data Lineage중심의 관리 | 데이터거버넌스 관점의 관리 |
| 데이터타입 | N/A | 지원 |
| 데이터표준 | N/A | 지원 |
데이터 카탈로그는 데이터의 활용도 측면의 솔루션인 반면에 데이터아키텍처관리는 IT관리적 측면의 솔루션으로 데이터 레이크와 같은 엔터프라이즈 솔루션의 적용을 쉽게 하기 위한 전략으로 중요하다고 할 수 있다.
기관메타관리시스템은 데이터표준관리+산출물검수자동화+데이터형상관리 업무를 소프트웨어로 구현한 업무시스템이다. 기관메타관리시스템이 운영하는 MDR(통합메타데이터저장소)을 이용하여 정보시스템별 데이터카탈로그 시스템을 쉽게 구축할 수 있으며, MDR은 기관에서 데이터 활용의 목적으로 데이터 레이크의 구축, 데이터 가상화의 구축등을 쉽게 구현할 수 있는 인프라를 제공하는 것이다. 뿐만 아니라 행안부에서 운영하는 중앙메타관리시스템과 43개 데이터표준 관리항목을 언제든지 자유롭게 자동으로 전송할 수 있으며, 범정부데이터표준 공표 내용을 전사적으로 메타관리시스템에서 즉시 반영이 가능하며 정보시스템에의 영향도 판단을 빠르게 할 수 있다.
기관메타관리시스템의 MDR은 기능을 확장하여 데이터품질(DQ) 업무를 추가 개발할 수 있으며 ETL과 같은 데이터통합솔루션도 만들 수 있는 기반이 된다.
| 구분 | 항목명 | 항목정의 및 지침 | 관리시스템 |
|---|---|---|---|
| 정보시스템정보 | 기관명 | 정보시스템 및 데이터베이스를 운영하는 기관 | EA/CMDB |
| 정보시스템명 | 대상 데이터베이스와 연계된 정보시스템의 이름(범정부 EA시스템에 등록관리되는 시스템명과 동일하게 작성) | ||
| 관련법명(보유목적) | 정보시스템 운영 및 데이터 수집과 관련된 근거법렁 | ||
| 구축년도 | 정보시스템 구축년도 | ||
| 운영부서 | 정보시스템을 운영관리하는 담당 부서 (산하기관에 위탁관리하는 경우, 실제 해당 정보시스템을 운영관리하는 산하기관에서 등록관리) | ||
| 담당자명 | 정보시스템을 운영,관리하는 담당자 성명(직급포함) | ||
| 전화번호 | 정보시스템을 운영,관리하는 담당자 전화번호 | ||
| 이메일 | 정보시스템을 운영,관리하는 담당자 이메일 주소 | ||
| 데이터베이스정보 | 논리DB명 | 기관 자체의 명명규칙을 준수한 데이터베이스 명칭(한글명) | MDR |
| 물리DB명 | 정보시스템에서 DB를 식별하기 위하여 사용하는 물리 정보명(영문명) | ||
| DB설명 | 데이터베이스에서 관리하는 주요 정보의 내용 및 활용 연계 제공 등 데이터베이스의 주요 기능 중심으로 기술 | ||
| 적용업무 | 정보시스템(DB포함)보유근거 및 목적에 따라 해당시스템(혹은DB)를 이용하여 적용 처리하고 있는 업무 기술 | ||
| DBMS정보 | DBMS의 이름 및 버전 | EA/CMDB | |
| 운영체제정보 | 해당 DBMS가 운영되는 운영 체제의 이름 및 버전 | ||
| 구축일자 | 데이터베이스 구축일자 (고도화사업의 경우 고도화사업 구축일자) | ||
| 테이블수 | 데이터베이스에 포함되는 테이블의 개수(실제 사용하는 테이블만 기술) | ||
| 테이블정보 | 데이터용량 | 데이터베이스에 저장되는 데이터의 크기(용량)단위:MB,GB,TB | |
| 수집제외사유 | 기관메타시스템을 통한 메타데이터 수집 제외 사유 | ||
| 테이블소유자 | 테이블스키마에 대한 소유권(오너쉽)을 갖는 데이터베이스 사용자 | MDR | |
| 테이블영문명 | 물리적인 DB에 생 성할 테이블 이름 | ||
| 테이블한글명 | 논리DB에 부여할 테이블 한글 명칭 | ||
| 테이블유형 | 테이블의 논리적, 물리적 특성에 따른 테이블 유형을 기재 | ||
| 테이블설명 | 테이블의 물리적 특징에 대하여 기술 | ||
| 업무분류체계 | 정부기능분류체계(BRM) 또는 기관별 자체 BRM을 참조하여 분류레벨(4-6단계)기술 | ||
| 품질진단여부 | 행안부에서 수행하는 공공데이터 품질진단 평가 여부 | ||
| 보존기간 | 테이블의 보존기간으로 정의한 기간동안 현재 테이블이 보유하고 있는 저장량을 저장 건수로 기술 | ||
| 테이블볼륨 | 테이블의 보존기간으로 정의한 기간동안 현재 테이블이 보유하고 있는 저장량을 저장 건수로 기술 | ||
| 발생주기 | 해당 테이블의 데이터가 작성되거나 수정되는 주기를 의미함 | ||
| 공개/비공개 여부 | 테이블이 보유한 원천데이터에 대한 공개, 부분공개 또는 비공개 여부(부분공개 또는 비공개의 경우 사유 기술) | ||
| 개방데이터목록 | 공개(또는 부분공개) 대상인 N개의 테이블을 구성하여 식별 가능한 유의미한 데이터로 구성한 목록명 | ||
| 컬럼정보 | 컬럼영문명 | 컬럼의 물리적 영문 이름으로 표준용어정의서에 등 록된 용어를 사용 | |
| 컬럼한글명 | 해당 컬럼과 연관되는 속성의 이름과 동일하게 부여하며, 표준용어를 부여할 컬럼 한글 명칭 | ||
| 컬럼설명 | 컬럼에 대한 이해를 돕기 위하여 필요한 부가적인 설명 및 예외 사항 등을 기술 | ||
| 데이터타입 | 컬럼 값의 물리적 표현으로 DBMS 종속적인 데이터타입의 이름을 그대로 기술 | ||
| 데이터길이 | 해당 컬럼의 값을 표현하기 위한 데이터의 길이, DDL문에서 지정된 데이터 길이를 DBMS 종속적 |