◆임태언 웹케시 상임고문 im40te10@webcash.co.kr
은행의 전산시스템 백업 문제는 어제 오늘의 일이 아니다. 온라인 시스템을 가동한 이래 줄곧 거론됐음에도 불구하고 백업시스템을 실제 활용하는 데는 여러가지 문제가 있다.
백업시스템을 구축하는 방안으로는 다음과 같은 것이 있다.
첫째, 현행 전산시스템과 똑같은 시스템을 원격지에 구축하고 동시에 거래를 처리하면서 상호 백업을 하도록 하는 방안을 들 수 있다. 예를 들면 서울과 부산에 똑같은 전산시스템을 구축하고, 평상시에는 두 시스템이 동시에 업무처리와 백업을 하다가 한 시스템이 다운되면 다른 한 시스템이 업무처리를 전담하다 시스템이 복구되면 다시 분담 하는 방식이다.
이것은 백업시스템으로서는 가장 완벽한 방안이라고 할 수 있으나, 전산시스템을 이중으로 운영해야 하기 때문에 전산처리 비용이 엄청나게 증가하게 되는 문제점이 있다.
둘째, 타 기관의 전산시스템을 백업시스템으로 이용하는 방식을 들 수 있다. 그 구성방식은 은행 전산시스템과 백업시스템으로 임차한 타 기관의 전산시스템을 연결하고, 실시간 또는 온라인 마감 후에 필요한 자료를 백업센터에 소산한다. 그리고 비상시 백업시스템의 가동을 위하여 각 지역망 센터와 임차시스템을 연결한다. 대다수 은행이 채택하고 있는 이 방식은 백업 비용을 크게 절감할 수 있는 반면 실제 운영시 적지 않은 어려움을 겪게 된다.
먼저 지역망 센터를 거치지 않는 서울 시내 영업점에 어떻게 백업라인을 구성하느냐는 것이다. 물론 서울도 몇 개의 블록으로 구분하고 각 블록망 센터를 통하여 백업시스템에 연결하거나 다이얼 업 모뎀을 설치하는 방법으로 해결할 수 있다. 하지만 상당한 비용을 감수해야 한다.
또다른 문제는 지역망 센터 다운시 특별한 대책이 없다는 점이다. 이것은 백업시스템만의 문제가 아니고 현재 운영하고 있는 시스템도 마찬가지다. 이밖에도 현업 담당자들이 파업을 할 경우에는 백업시스템으로서의 기능을 갖지 못한다는 점과 실제로는 한번도 사용하지 않으면서 매년 지불해야 하는 임차사용료도 부담이다.
셋째, 타 은행과의 업무제휴를 통하여 백업시스템을 구축하는 방식이다. 구체적으로 설명하자면, 영업점 규모가 비슷한 두 은행간에 시스템 백업을 위한 협약을 체결하고 비상시 계정처리에 필요한 최소한의 자료(계좌번호·예금잔액 등)를 실시간으로 소산함과 동시에 상대은행의 백업시스템을 서로 갖추어 놓는다. 이렇게 하면 타 기관 시스템을 임차하기 위한 비용도 절감할 수 있을 뿐만 아니라 전산요원을 포함한 직원들의 파업에도 충분히 대비할 수 있다.
여기에다 두 은행 고객들이 평상시에도 요구불예금에 대한 입출 거래를 자유롭게 할 수 있도록 하는 범위까지 협약을 확대할 경우 백업시스템의 실용성은 한층 더 높아진다. 고객의 입장에서는 거래 은행의 영업점이 배가 되는 이점을 누릴 수 있다고 생각한다. 물론 어떻게 고객정보를 경쟁 상대에 제공할 수 있느냐고 이 방식의 문제를 제기하는 사람도 있을지 모르지만, 소산하는 자료를 입출 거래에 필요한 최소한의 정보에 한정하고(이러한 정보는 지금의 타행간 거래에서도 제공되고 있음) 백업 자료에 대한 시큐리티를 한층 더 강화하면서 백업 은행간에 신의성실의 원칙에 의한 자료관리를 약속한다면 정보 유출에 따르는 피해는 발생하지 않을 것으로 본다.
한편 백업 업무의 범위도 거래점 구분없이 거래가 가능한 수신 업무로 한정하고(은행에 따라서는 수신중에도 저축성과 적립식 예금은 제외할 수 있음), 여신이나 외환 업무의 경우에는 거래점에서 직접 처리할 수 있는 체제를 갖추어 백업시스템의 규모를 최소화한다면 백업시스템의 유지를 위한 비용절감과 함께 자료제공에 따른 위험부담도 줄일 수 있다.
백업시스템이 불확실성에 대비하는 것이라는 점을 감안하면 편리함보다는 구축비용을 최소화하는 것이 바람직하다고 본다. 이런 관점에서 보면, 두 은행간의 상호 백업시스템이야말로 어떤 다른 방식보다 백업비용을 획기적으로 절감 할 수 있을 뿐만 아니라 두 은행이 동시에 다운되는 극단적인 상황을 제외하고는 어떤 상황에서도 비교적 쉽게 운영할 수 있는 백업시스템으로 적극 추진해 볼 만하다고 생각한다.