부도데이터의 효과적인 관리방법

리스크관리는 체계적인 데이터관리에서부터 출발

부도데이터 관리는 일관성 있는 기준 적용이 필요

모든 금융기관은 일정한 기준에 따라 현재 거래중인 차주 및 계좌의 부도 여부를 확인하고 있으며, 내부 데이터베이스(DB)에 부도 여부를 판단하기 위한 기초데이터 및 부도사유, 부도발생일 등의 정보를 기록하고 있다.
흔히 금융기관에서 부도차주 및 부도계좌의 정보를 기록하는 방법에는 다음 세 가지 방식이 존재한다.

첫번째 방법은 고객번호 또는 계좌번호에 대해서 일별/월별 부도 여부를 기록하는 방법이다. 일별 부도 테이블에 부도고객/부도계좌를 기록했다가, 월별로 스냅샷(snapshot)을 기록하면 매월말 시점의 부도 여부를 기록할 수 있다.

이 방식의 장점은 월별 배치작업 수행시 부도차주 또는 정상차주를 추출하기 쉽고, 부도발생일 또는 부도해제일이 초기화(또는 변경)되더라도, 전월 배치작업에서 사용한 데이터 셋(dataset)을 확인하기 쉽다는 점이다.

두번째는 고객 또는 계좌에 대해서 부도사유별 부도시작일/부도종료일을 관리하는 방법이 있다. 동일한 고객 또는 계좌에 대해서 한번에 여러 부도사유로 (연체부도와 개인파산이 동시에 발생한다던가) 부도가 발생했을 때 각각의 부도사유별로 부도기간이 달라질 수 있으므로 해당 정보를 모두 기록하는 방식이다.

이 방식의 장점은 부도 요건이 새로 추가되거나, 기존 부도 요건 중에 일부가 제외될 경우 새로 부도 여부를 판단하는 것이 쉽다는 것이다.
마지막으로 부도 여부를 판단하기 위한 기초데이터를 월별로 계속 보관하는 방법이 있다. 월별로 거래하는 고객 및 계좌가 계속 변경되고, 은행연합회 등에서 전달되는 부도정보도 계속 변하기 때문에 모든 기초데이터를 월별로 보관한다면, 잘못된 부도발생일(예를 들어, 2월10일에 부도발생일이 1월 20일인 부도데이터가 전달된다던가)을 예방할 수 있다. 기초데이터를 월별로 보관하게 되면 신규 요건에 따라서 과거 부도여부를 소급 작업할 경우 간편하게 작업할 수 있다.

이와 같이 여러 방법으로 부도정보를 관리할 때 중요한 점은 고객 또는 계좌에 대해서 일관성있게 관리해야 한다는 점이다. 가령 어떤 부도정보는 고객번호를 기반으로 부도여부를 판별하고, 어떤 부도정보는 주민등록번호, 사업자번호 등으로 관리를 한다면 추후 부도요건이 변경되거나, 새로운 부도요건이 추가되거나, 기존 부도요건을 삭제할 경우 새로운 요건에 따른 부도고객 또는 부도계좌를 추출하는 것이 힘들거나 불가능할 수 있다.

따라서 고객에 대한 부도정보는 한가지 기준을 정해서 해당 기준으로 관리하는 것이 월별 배치작업 및 과거 데이터 소급작업에 편리하다. 부도계좌의 경우에도 이수관, 대환 등의 사유로 계속 계좌번호가 변경되더라도, 그 이력을 추적하기 쉽도록 최초계좌번호(또는 별도의 일련번호 등)로 부도정보를 기록하는 것이 월별 배치작업 및 과거 데이터 소급작업에 편리하다.

그런데, 어떤 방식을 사용하더라도 5년 이상의 부도기록을 유지하다 보면 데이터의 일관성을 유지하는 것도 힘들고, 데이터 양의 증가에 따라 물리적인 데이터베이스 공간도 과다하게 사용하는 문제점이 발생한다. 이러한 경우, 부도데이터를 어떻게 관리하는 것이 데이터 공간도 기존 방법보다 적게 사용하면서, 부도 요건의 변동에 유연하게 대처할 수 있는지를 생각해보아야 한다.
먼저 분산 DB를 사용할 수 있는 환경이라면 데이터를 분산하여 적재함으로써 효율성을 높일 수 있을 것이다. 모든 부도 고객 및 계좌 정보와 기초데이터를 월별로 각 지점의 단위 DB에 기록하고 현재 부도중인 고객 및 계좌 정보와, 최근 1~2개월 사이에 부도해제된 고객 및 계좌 정보를 중앙 DB에 집계하는 방법이 있다. 이렇게 분산 처리하는 방식의 장점은 중앙 DB의 데이터 사용량이 줄어들고 처리속도도 빨라지며, 백업 및 복구가 간편하게 이루어진다는 점이다.

그렇지만 분산 DB를 사용할 수 없는 환경이라면, 부도 여부를 판단할 수 있는 기초데이터만 보관하고, 부도사유, 부도고객, 계좌정보는 프로그램 실행중에만 생성하고, 프로그램 완료후에 자동으로 삭제하는 방법이 있다. 예를 들어, 현재 거래중인 고객의 외부불량정보, 현재 거래중인 계좌의 연체 및 대환정보 등만 가지고 있다가 일배치 또는 월배치 작업시 부도여부를 판단하고, 현재 부도중인 고객 및 계좌 정보만 기록하고 별도의 이력은 모두 삭제할 수 있다.

이 방식의 장점은 부도이력을 관리하지 않으므로 부도요건이 자주 바뀌더라도 별도의 소급작업이 필요 없고 프로그램 진행 단계가 간단하다는 점이다. 그러나, 이 방법은 부도 고객 및 계좌에 대한 검증이 힘들고, 특정 시점의 부도 정보가 요건에 따라 어떻게 변경되는지 확인하기 힘들다는 단점이 있다.

또한, 기초데이터를 보관하고 부도 여부를 신규 생성하다 보면 고객번호 인식에 문제가 발생할 수 있다. 일반적인 경우 한 고객은 하나의 고객번호를 가지지만, 특정 고객이 일정기간 동안 거래를 중지했다가 다시 거래를 시작할 경우 새로운 고객번호를 부여받을 수 있다. 또한, 처음 거래할 때는 개인고객으로 거래하다가 일정시간 후에 개인사업자로 거래를 시작한다면 고객 속성이 변경되었으므로 예전 고객 정보와 연계하는 것이 힘들다. 그러므로, 별도의 부도이력 없이 부도여부를 생성할 경우 기초데이터 사이에 동일한 고객번호 및 고객속성을 유지할 수 있도록 데이터 일관성에 유의해야 한다.

금융기관들의 데이터관리에 대한 관심이 증대되고 있으며, 실제 기록하는 데이터 양도 급속히 증가하고 있는 추세에서 위에서 언급한 데이터관리 방법에 대한 고민은 보다 구체화하여 진행할 필요가 있을 것이다. 부도데이터를 일관성있게 또한 간편하게 관리하기 위해서는 검증이 완료된 후 불필요한 중간단계를 삭제하여 배치 프로그램의 작업단계도 낮추고, 처리속도도 높이는 방식을 고려해야 할 것이다.



관리자 기자