충국이의 IT 마케팅 정보

IT서비스업계 3분기 실적… 대부분 매출 하락 '희비'

DB 없는 금융 정보시스템은 햄 없는 햄버거

최상윤 sychoi@b2en.com｜(주)비투엔컨설팅 수석컨설턴트로 근무 / 현재 교육학술정보원 데이터아키텍처(Data Architecture) 전문컨설팅 수행.

금융과 통신 분야는 대단위 정보시스템 구축의 대표적인 사례이다. 금융 정보시스템에서 관리하고 있거나 관리해야 하는 데이터의 양은 수십 테라바이트의 천문학적인 규모이다. 또, 초당 트랜잭션 처리량의 요구수준 역시 3,000 TPS(Transaction Per Second)에 육박할 만큼 빠른 데이터 처리가 보장되는 시스템이어야 한다. 이런 배경 덕에 최근에는 전사 데이터 아키텍처 수립과 거버넌스 체계를 갖추고자 하는 요구가 늘고 있다. 4부에서는 금융권의 차세대 정보시스템 개발을 위한 데이터베이스의 특징과 함 께 효과적인 데이터 설계 방안에 대해 알아본다.

대단위 정보시스템의 경우 관심의 대상이 메인프레임에 서 오픈환경의 전환하는 등의 하드웨어 아키텍처의 변화가 주요 이슈인 것처럼 보이기 쉽다. 하지만 실제로 모든 정보시스템의 근간을 이루는 것은 데이터의 개혁이다. 다시 말해 업무에 유연 한 데이터 구조와 적시에 정확한 정보를 가장 빨리 제공할 수 있 는 데이터 엔진의 고도화야 말로 정보시스템의 핵심 분야인 것이 다. 이처럼 정보서비스의 품질을 고도화시키기 위해서는 대용량 데이터베이스의 운용, 대규모 트랜잭션의 처리, 업무 변화에 유 연하고 신속하게 대응할 수 있는 데이터 모델링이 필요하다. 또, 최적의 데이터베이스 설계, 데이터 품질과 고성능 보장 및 개선 등도 정보시스템 개발 및 구축에 있어서 빼놓을 수 없는 사항들 이다. 2부에서는 금융권 차세대 정보시스템 개발 동기와 금융 정 보의 데이터 요건 및 특징에 대해 알아본다. 또, 금융 데이터 모 델의 고려사항과 효과적인 데이터 모델 설계 방안에 대해 알아볼 것이다. 금융권 전체 데이터에 대한 설명에는 여러 가지 문제점 과 한계가 있으므로 은행권 업무를 중심으로 알아보자.

금융권 차세대 정보시스템의 개발 동기

금융권의 차세대 정보시스템을 개발하게 된 동기는 금융사의 특성에 따라 다양하게 존재한다. 대략적으로 정리해보면 현재 운 용중인 정보시스템의 노후, 은행사의 통폐합에 따른 정보시스템 통합 과제 해결, 업무 변화에 능동적으로 대처하기 위한 지원, 바젤II, 금융관련법규 등과 관련된 데이터 통합 및 데이터 품질 개 선 등의 요구에 의해서 기업은행, 외환은행, 우리은행 등은 이미 차세대 정보시스템을 개발 및 구축하여 안정적으로 운용하고 있 으며, 통합 신한 및 조흥은행과 같이 현재 개발 중이다. 농협 등 은 차세대 정보시스템의 개발 사전 작업을 진행 중이다. 이와 같 은 금융권 차세대 정보시스템 개발의 주요 동기는 <표 1>과 같다.

<표 1> 금융권 차세대 정보시스템 개발 동기

금융권 정보시스템의 데이터 요건과 특징

금융권 정보시스템은 대용량의 트랜잭션 처리, 대용량 데이터의 관리, 업무 수행을 위한성능 보장, 24×365와 같은 시스템의 안정성 및 가용성을 보장할 수 있어야 한다. 또, 업무 변화에 신속하고 유연하게 대응하기 위한 확장과 유연성 확보 등의 시스템적 요건에 의해서 금융권 정보시스템의 데이터는 <그림 1>과 같은 요건이 만족되어야 한다.
초당 3,000 TPS 규모의 트랜잭션에서 발생되는 데이터의 처리가 가능해야 한다. 여기에 단위 테이블 사이즈가 테라급 이상인 데이터에 대한 조회와 통계, 분석용 정보의 생성을 위한 배치 애플리케이션 및 신속한 업무 처리를 요구하는 각종 OLTP(OnLine Transaction Processing)성 애플리케이션에서의 조회, 등록, 수정, 삭제 작업의 수행 성능이 보장되어야 한다. 더불어 장애 시 업무의 중단 없이 데이터 백업과 복구를 할 수 있는 이중구조까지 갖추고 있어야 한다.
금융권 정보시스템에서 관리하고 있는 데이터를 분류하면 <그림 2>와 같이 관계자(고객), 조직, 상품, 계약, 거래, 위치, 채널, 행사, 재무 등으로 표현될 수 있다. 관리 데이터는 각 금융사의 업무 프로세스에 따라서 조금씩 차이가 있을 수 있을 것이다. 데이터를 분류하는 방법도 차이가 날 수 있겠지만 기본적인 비즈니스가 동일한 업종이므로 관리하는 데이터의 차이는 없을 것이다.
지금까지 우리가 알아본 것이 바로 <그림 2>와 같은 은행사의 데이터를 관리하기 위한 시스템과 데이터 관점의 요건, 차세대 정보시스템 개발의 구체적인 동기다. 이런 데이터들을 제대로 관리할 수 있으려면 각 데이터가 가지는 세부적인 특징을 정확히 파악하고 있어야 하는데, 가장 중요한 특징을 정리하면 <표 2>와 같이 된다.

<표 2> 금융권 정보시스템 데이터의 특징

<그림 1> 금융권 정보시스템의 시스템 및 데이터 요건 상관관계

<그림 2> 금융권 정보시스템의 관리 데이터 유형

이같은 금융권 정보시스템에서 관리하고 있는 데이터의 요건 및 특징은 이미 구축되어 있거나 향후 구축될 차세대 정보시스템에 반드시 반영되어야 할 요소들이다.

금융 데이터 모델의 주요 고려 사항

앞서 설명한 것처럼 기술 내용은 세부적인 설계의 방안보다는 데이터 모델 설계 시 주요 고려사항에 대해 알아볼 것이다.

금융 거래 데이터 모델의 패러다임 변화

과거 금융 정보시스템의 금융 거래 데이터 모델은 [고객->계좌->거래]의 형태로 이루어졌다. 이때는 금융 거래를 트랜잭션 처리 관점에서 정의하여 생성, 변경, 조회 중심의 데이터 모델로 데이터를 관리했다. 이러한 데이터 구조 하에서는 업무변화에 유연하게 대처하지 못하고 변경 및 추가되는 업무를 반영하기 위해서는 별도의 프로그램 개발과 테이블이 수정 및 추가되는 형태의 과정이 필요하다. 때문에 기업 경쟁력에 지대한 영향을 미치는 신상품의 개발과 판매가 신속하고 유연하게 지원되지 못하는 문
제가 있었다. 차세대 정보시스템은 이런 문제를 해결하기 위해 고객, 상품, 계약, 거래 간의 다양한 상호 관계를 정의함으로서업무를 효과적으로 지원할 수 있도록 하였다.
<그림 3>에서처럼 과거에는 상품 및 서비스, 수수료 관리를 위한 데이터 모델 구조의 요구와 수신, 여신, 신탁, 외환 등의 트랜잭션 데이터를 거래 정보의 범위로 보았으나 현재는 금융 거래와 고객과의 접촉에서 발생되는 모든 접촉 정보를 거래 정보로 포함시키고 있다. 이러한 변화를 통해 고객, 상품 및 서비스, 수수료, 계약 및 약정 등의 데이터 영역에 대한 모델 구조 변화를 가져왔다.
<그림 4>는 관계자(고객)와 관계자(고객)가 상품과 서비스의 이용을 위해 개설한 계약계좌간의 관계를 도표로 나타낸 것이다. 먼저, 다양한 거래 정보가 생성되고, 관계자(고객)는 민원 및 클레임의 접촉고객, 금융거래의 거래주체, 계약의 당사자, 각종 대출 및 정기예금의 납입자, 사고의 당사자 등으로 관계(역할)가 정의된다. 계약계좌도 거래관계에 의해서 다양한 관계(역할)로 정의되어 있는 것을 확인할 수 있다. 이런 거래 데이터의 논리적 통합을 고려한 형태의 데이터 모델 구조 설계를 통해 고객에게 싱글 뷰(Single View)나 싱글 보이스(Single Voice) 같은 서비스가 제공될 수 있다.

파티션 테이블로 대용량 거래 데이터 처리하기

각종 거래 데이터를 고객이 원하는 형태로 제공 하려면 많은 양의 데이터를 읽어서 애플리케이션에서 처리할 것이다. 데이터 가 아무리 정형화되어 관리가 잘되어진다고 해고 이를 효과적으 로 활용하기 위한 방법이 없다면 무용지물일 것이다. 그럼 대용 량의 거래 데이터를 효과적으로 관리하려면 어떻게 할까?
파티션 테이블은 각 DBMS 벤더 마다 지원 가능 여부 및 파티션 유형 등이 조금씩 차이를 가지고 있으나, Oracle DBMS를 예로 설명하면 파티션 테이블의 유형은 <그림 5>와 같이 Range, Hash, List, Composite Partition이 있다.
<그림 6>은 거래 데이터를 거래월별로 레인지 파티션(Range Partition)한 경우로 특정 거래월의 거래금액 합계를 구하는 SQL 조회 문을 예로 설명한 것이다. 조회 조건에 따라서 실제 DBMS의 옵티마이저가 수행하는 작업량의 차이가 엄청난 것을알 수 있으며, 인덱스 없이도 해당 데이터를 액세스 할 수 있다.
파티션 테이블은 OLTP 데이터뿐만 아니라 실적(통계) 데이터 관리에서도 큰 효과를 가져 올 수 있다. 하지만 파티션에 대한 이해가 깊지 않은 상태에서 파티션 테이블을 구성할 경우 역효과를 내기도 한다. <그림 7>은 실적 테이블의 조회 용이성을 높이기 위해 파티션하였지만 실적 데이터의 특성상 주기적인 갱신작업만 빈번히 발생하는 결과가 발생한 예이다. 빈번한 갱신작업 탓에 데이터 변경 작업 시 3백만 건 이상의 레코드를 갱신(Update)하여 다량의 Random Block I/O를 유발하여 Batch작업의 수행 성능을 보장하지 못하였다. 갱신 대상 년도의 작업은 별도의 임시 테이블을 이용하여 생성하고 생성된 테이블과 파티션 테이블에 해당하는 파티션만을 교환(Exchange)하여 작업에 소요되는 시간과 랜덤한 입출력 문제를 개선할 수 있다.

<그림 5> 파티션의 개념 및 파티션 테이블 유형

<그림 6> 파티션 테이블의 자료 조회(예제)

<그림 7> 배치 작업의 수행 성능 향상(예시)

주요 데이터 영역에 대한 모델 설계하기

이번에는 금융정보 시스템의 가장 중요한 데이터인 고객과 상품 및 수수료 데이터에 대한 모델 설계 방법에 대해 알아보자. 여기에서는 이 데이터들의 특징에 대해 먼저 알아보고 데이터 모델적인 접근 방법과 아키텍처적인 접근 방법접근 방법에 대해 알아본다.

● 고객
금융회사서 고객 데이터만큼 큰 가치를 갖는 것은 없을 것이 다. 고객 데이터 중 고객의 기본정보는 <그림 7>와 같이 전사적으 로 통합 관리되어야하고 통합된 고객의 CIF(CustomerInformation File)를 이용하여 CRM (Customer RelationshipManagement), 실적, 각 업무 영역 등에서 각각의 실정에 맞추어 관리하는 것이 바람직하다.
고객기본정보는 각 업무에서 공통으로 사용하는 속성 및 해당 기업에서 반드시 관리할 고객의 정보를 정형화하여 정의함으로서 각 업무 영역에서 공통으로 사용할 수 있다. 고객성명, 고객구분, 생년월일, 주소, 연락처 등의 기본 신상에 관련된 정보를 기본정보로 관리할 수 있고 고객의 기념일, 기타주소 및 연락처, 재무정보 등은 고객기본정보의 부가정보로 추가하여 관리할 수 있다. 고객의 통합관리는 고객정보에 대한 정합성 향상과 중복관리로 인한 데이터 품질 저하를 방지할 수 있다. 또한 수신 과 여신, 외환, 카드 등의 업무 영역에서 업무 특성에 맞는 추가적인 부가정보를 관리함으로서 업무변화와 업무요건에 능 동적이고 유연하게 대응할 수 있게 정보 시스템을 구현할 수 있다.

<그림 8> 통합 고객관리 방안(예시)

● 상품과 수수료
고객정보에 대한 통합은 비교적 오래전부터 중요시되고 관련 프로젝트가 추진되었던 반면, 상품과 서비스, 수수료 관련데이터는 근래에 관심이 커지고 있다.
<그림 9>에서와 같이 과거 상품 및 수수료 등의 정보가 애플리케이션에서 로직으로 처리되어 상품과 수수료의 신규 개발, 수수료 요율의 변화가 발생할 경우 애플리케이션의 수정 및 신규 개발을 통해서 업무를 지원해왔다. 그러나 차세대 정보시스템에서는 상품, 수수료, 계좌 등의 정보를 성격에 맞게 분류하여 관리할 수 있는 데이터 중심적 모델 설계를 통해서 상품의 신규 개발, 수수료징수 관련 규칙의 수정과 등의 업무를 신속하게 처리할 수 있다.
상품 데이터 모델의 경우 상품의 적용이율, 약정기간 같은 상품 특성 정보를 속성으로 관리할 수 있도록 설계한다. 이러한 속성들은 상품별, 고객별로 적용할 수 있도록 데이터 모델을 설계하여 업무변화에 따른 유연성을 보장할 수 있다. 수수료 데이터 모델은 수수료 징수 규칙을 정의하여 각 서비스 상품별로 적용할 수 있도록 설계해야 한다. 또, 고객과 지역, 채널 등 특정정보를 정의하여 서비스 사용에 대한 수수료 가격 정책을 유연하고 차등적으로 적용할 수 있는 모델 구조를 갖추는 것이 필수적이다. 이러한 데이터 모델의 설계는 각 금융권(은행권)의 업무 특성과 환경에 맞게 업무 요건을 분석하고 데이터 모델에 반영한다면 향후 10 여년 이상 사용하게 될 차세대 정보시스템의 데이터 영역에 대한 업무 유연성 및 확장성을 보장할 수 있을 것이다. <그림 10 참조>

<그림 10> 상품 및 서비스, 수수료 관리를 위한 데이터 모델

효과적인 데이터 모델(설계) 접근 방안
업무 변화 및 신규 업무에 대한 유연성과 확장성을 보장할 수 있는 데이터 모델의 설계하려면 분석과 설계를 위한 효과적인 접 근이 필수적이다. 차세대 정보시스템의 개발에는 다수의 데이터 모델러가 투입된다. 투입되는 데이터 모델러의 기술 수준이 일정 하지 않고 분석 및 설계할 업무 영역 역시이 광범위하고 구축된 시스템과 운용중인 데이터베이스도 다양하게 구성되었을 것이 다. 이런 현실적인 문제를 효과적으로 해결하려면 현행 데이터 모델을 분석하고 목표 데이터 모델을 설계하기 위해 체계를 분석 하고 목표 데이터 모델 설계를 위한 체계적인 관리 틀 (Framework)에 의한 아키텍처적인 접근방법과, 이러한 아키텍 처에 기반하여 각 업무 영역별로 일정한 수준의 데이터 모델을 설계할 수 있도록 원칙 및 지침의 정의, 전사 개념 데이터 모델의 정의, 논리 데이터 모델의 가이드 등의 업무를 수행하는 데이터 아키텍처(Data Architecture) 조직은 필수 조건일 것이다.

아키텍처적인 접근방법

백여 개의 정보시스템과 천여 개 이상의 이기종 DBMS로 구성된 기업의 현행 업무를 분석하여 문제점과 개선사항을 도출하 고 목표 데이터 모델을 설계 한다는 것은 생각보다 어려운 일이 다. 이러한 현행 정보시스템을 분석할 경우 아키텍처적인 접근은 필수적이다.

<그림 11> 데이터 아키텍처 프레임워크

<그림 11>에서와 같이 전사 데이터를 데이터의 성격에 따라서분류하고 분류한 데이터를 주제영역별로 전사 개념 데이터 모델로 정의한 뒤에 각 시스템별로 논리 및 물리 데이터 모델을 분석할 수 있다. 이런 접근방법을 사용하면 전사 데이터를 일관되고 체계적으로 분석할 수 있다.
또한 현행 정보시스템의 분석 대상 데이터가 광범위하고, 분석 시간과 인력이 제한적일 경우가 있다. 이럴 때에는 분석 대상 데이터를 선정하기 위한 데이터 요소(업무의 주체, 핵심 업무, 데이터 양, 정보 활용의 빈도 등)를 정의하고 정의된 요건에 따라서 주요 데이터 주제영역을 집중적으로 분석하면 된다. <그림12 참조>

<그림 12> 현행 데이터 분석을 위한 데이터 주제영역 선정 방안(예시)

데이터 아키텍처 관점에서 현행 정보시스템의 관리 및 운용 대상 데이터를 분석하여 문제점 및 개선사항을 도출하고, 비즈니스 요구사항 등을 종합적으로 고려하여 목표 정보시스템을 위한 데 이터 모델 설계의 방향성 수립 및 제시와 데이터 중심적 데이터 구조 및 데이터 흐름의 설계를 제공해야 한다. <그림 13 참조>

<그림 13> 아키텍처 기반의 시스템 구축방안(예시)

현행 금융권 정보시스템에서 관리하고 있는 데이터 유형 및 데 이터양을 고려할 때 아키텍처적인 접근에 의해서 목표 정보시스 템의 개발 및 구축을 위한 데이터 모델 설계를 추진하는 것이 가 장 효과적이다. 데이터 영역만이 아니라 업무, 응용 영역 등과의 정렬(Alignment)도 조정하거나 유지할 수 있다.
지금까지 알아본 내용들은 대부분의 개발 프로젝트에서 추진 되고 실제 설계까지 반영되어 업무 효율을 높이는 밑거름이 되는 것이 일반적이지만, 데이터 조회 성능을 개선하기 위해 적용하는 공통 모듈화가 엄청난 성능 저하의 요소로 대두되기도 한다.
이 경우 기능상의 오류 보다는 DBMS의 원리를 제대로 알지 못해서 생기는 문제가 대부분이다. <그림 14>과 같이 전표 테이 블에서 해당 조건을 만족하는 데이터를 조회하면서 부서명, 계정 코드, 지점명 등을 함수를 이용하여 처리함으로서 DBMS의 파 싱(Parsing) 부하와 테이블의 랜덤 액세스 부하를 유발하여 수 행 성능을 저하시킨다. 이는 함수를 처리하는 DBMS의 내부 알 고리즘 자체가 해당 조건을 만족하는 데이터 건수만큼 함수를 수 행하도록 되어 있기 때문이다. 즉 <그림 14>에서와 같이 해당 조 건에 만족하는 데이터 건수가 3,024건이라면 SQL문에서 사용한 함수들은 모두 3,024번 실행하는 결과를 가져오는 것이다.
이러한 경우 함수에 사용되는 컬럼 수가 적고, 함수의 장점인 모듈화 기능을 발휘할 수 있도록 스칼라 서브 쿼리를 사용하는 것이 수행 성능 향상에 효과적이다. 스칼라 서브 쿼리는 SQL문 의 Select 절 다음에 사용할 수 있다. 이 기능을 이용하면 비효율을 제거할 수 있으며 <그림 14>에 명시된 개선 후의 SQL문을 참 조하자.

<그림 14> 함수사용의 비효율 SQL문의 성능 개선(예제)

데이터 아키텍처 조직

차세대 정보시스템의 개발 및 구축 시 데이터의 일관성을 유지 하고 고품질을 보장할 수 있으려면 전사 데이터를 관리하는 조직 의 역할이 중요하다. 특히 전사 데이터의 체계적 관리를 위해 정 의한 데이터 주제영역에서 관리하고 있는 데이터를 관리하는 주 제영역별 데이터 관리자의 역할이 매우 중요하다.
데이터 관리 조직은 프로젝트의 상황에 적합하도록 구성되어 야 하며 프로젝트를 수행하는 개발 업체나 컨설팅 업체의 인력에 의해서 운용될 수도 있다. 하지만 향후 기업의 데이터를 지속적 으로 관리하고 구성된 조직을 활성화할 수 있으려면 반드시 현업 이 공동 참여해야 한다.
금융권의 대용량 데이터와 고성능 트랜잭션 처리 보장을 위해 서는 성능 보장을 위한 물리적인 데이터베이스 설계가 매우 중요 하며 업무 특성별 최적화 기술이 매우 중요하다. 모 은행은 대형 시스템 가동 전 40일 동안을 가동하지 못한 채 발을 동동 구르며 약 10여개 대형 배치작업 문제로 고심한 적이 있다. 필자에게 문 의가 와서 화인해 보니 배치작업 시간이 과다하게 소요되는 것이 문제였다. 처리시간 단축을 위해 한 달여 시간 동안 여러 가지 튜 닝 노력을 하다 결국에는 메모리와 CPU를 두 배씩 늘린 상태였다. 동일한 프로그램을 10여개로 나누어 동시에 수행시키는 등 온갖 방법을 다 취해 보았으나 목표하는 시간 5시간 이내에 약 20여개의 필수 배치 작업을 끝낼 수가 없게 되었던 것이다.
이 시스템의 가장 큰 문제는 물리적인 DB설계를 해당 DBMS 기술에 맞추어 최적화 I/O 및 관리기법 적용을 하지 못한데 있었 다. 기본적인 테이블 생성 명령으로 단순히 DB를 생성하여 단 1 초면 해결할 수 있는 기법이 있음에도 불구하고 대량 데이터 작 업을 30분씩 소요하며 비효율적으로 행하고 있으면서도 당연히 여기고 있었다. 두 번째 문제는 프로그램 구현 기법과 SQL 형태 였다. COBOL로 작성된 절차형 프로그램 방식으로 수백만 또는 천만번 반복 수행하여 SQL 13개 정도가 모두 온라인 트랜잭션 에 적합한 형태의 SQL(예:PK조건의 PK인덱스 엑세스)로 개발 되어 있었다. 때문에 천만계좌가 넘는 데이터 처리를 최단시간에 완수해야 하는 최적화(예:은행의 센터컷) 방식과는 거리가 멀었 다. 즉, 조그만 묘목 한그루를 심을 때에는 삽을 이용하는 것이 적합하지만 빌딩을 지으려면 굴삭기를 써야 하는 것처럼 수백만 건이 넘는 대량 데이터를 동시에 처리하려면 배치작업형 SQL 최적화 방식이 다르게 유도되도록 설계해야 한다.
해당 고객사의 문제는 약 한달 가량의 컨설팅으로 물리적인 DB설계의 보완과 함께 배치 프로그램은 SQL튜닝 대신시간이 많이 소요되는 프로그램은 재개발 수준의 개선 작업으로 무려 시 간을 600% 단축시킬 수 있었다.

제공 : DB포탈사이트 DBguide.net

출처명: 마이크로 소프트웨어 -[2006년 6월호]