9. 트랙잭션(Transaction)

9.1 트랙잭션이란?

은행의 업무는 크게 두가지로 나뉘어 진다.

한가지는 보통 사람들이 익숙해져 있는 계정계라고 불리는 업무이고 다른 하나는 정보계라고 불리는 업무이다. 계정계라고 하면 우리가 은행의 구좌 를 만들고 돈을 입금하거나 출금하는 것과 같은 일을 처리하는 곳이며, 정보계라는 곳은 은행이 보다 많은 이익을 얻기 위한 중요한 정책 결정에 도움이 되는 여러가지 정보를 처리하는 곳이다.

이 중에서 정보계의 일은 PC나 유닉스를 사용한 중소형 컴퓨터가 많이 사용되고 있으나, 은행의 주관 업무인 계정계는 아직도 대형 컴퓨터를 벗어난 예가 국내에는 없다. 그 이유는 트랙잭션 처리, 특히 온라인 트랙잭션이라고 불리는 일의 처리를 맡는데 필수적인 몇가지 점에서 중소형 컴퓨터나 PC가 확실성을 보장해 주지 못하기 때문이다.

이 글에서는 주로 이런 일을 처리하는 온라인 트랙잭션에 대해 설명을 하고자 한다.

'트랙잭션'을 사전에서 찾아보면 '자료 파일이나 장표 내용에 증감이나 변경을 일으키는 모든 거래, 즉 입출하, 매상, 반품, 입출금, 정정 기입, 손실품 기입 등과 같은 일시적인 정보를 기록 하는 것' 혹은 '단말 조작원에 의해 입력되는 여러 가지 행위의 집합' 이라고 되어 있다.

이러한 얘기를 들으면 PC를 사용하는 입장에서는 마치 폭스 프로나 DBASE Ⅲ에서 한 항목을 입력하거나 수정, 삭제하는 일을 연상할 것이다. 물론 기본적인 입장에서는 다를 바가 없다고 생각해도 된다.

그러나 트랙잭션이라고 불리우는 것에는 보다 중요하게 다루어져야 하는 것이 있다. 그것은 자료가 일관성을 가져야 한다는 것이다. 이러한 일관성을 유지하기 위해 중대형 컴퓨터에서 사용되는 데이타베이스는 자료를 입력하거나 수정, 삭제할 경우에 이러한 자료 변경을 위한 동작이 끝났음을 표시하는 'ET(End Transaction - 거래의 끝)' 신호를 보내서 확인을 한다.

만일 자료가 제대로 변경이 되지 않았을 경우에는 자료 변경 이전의 상태로 바꾸어 주는 작업인 '롤 - 백(roll - back)'을 수행하여 일관성을 유지한다. 이런 자료의 일관성의 중요성을 보여주는 사건이 있었는데 93년 11월 16일에 모 은행의 전산망에 이상이 생겨 실제로는 송금되지 않은 1,300건이 송금된 것으로 처리가 되었다. 그 중에서 70 여건, 약 2억원 가량이 인출되는 사고가 발생했다. 약 1시간 가량에 걸친 이 이상은 송금을 하는 은행의 창구에서는 송금이 불가능한 것으로 표시가 되면서 그 은행의 전산망에는 입금이 된 것으로 처리가 된 것이다. 물론 이러한 이상은 발견이 되는 즉시 복구 작업에 들어가 1,300여건 중 아직 인출이 되지 않은 1,296건은 자료를 다시 수정했고, 이미 인출이 된 70여건의 2억원 상당은 다시 회수하였다.

자금적인 손해를 둘째치더라도 이 사건으로 그 은행의 신용도는 상당히 손상을 입었을 것이라고 보아진다. 은행은 개인에게는 일종의 금고와 같은 역할을 한다. 금고는 안전한 것을 생명으로 한다. 안전하지 않은 금고에 돈을 맡겨놓을 사람은 별로 없을 것이다. 그런데 만일 우리가 사용하는 PC에서 입력한 자료 파일에 깨져서 잘못되었을 경우(여러가지 이유로 해서 사실 빈번하게 발생하는 일이지만)에는 이를 복구하기 위해 노력하다가, 복구할 수가 없을 경우에는 새로 입력하면 그만이다. 그러나, 은행의 업무와 같은 곳에서는 이런 일은 상상할 수도 없다. 만일 그런 일이 발생한다면 은행은 문을 닫아야 할 것이다. 트랙잭션은 위와 같이 중요한 자료의 일관성을 유지하기 위해서 자료 변경을 위한 작업을 보다 명확하게 정의해 놓은 것이라고 볼 수 있다.

9.2 온라인 처리의 중요성

일반적으로 온라인이라고 하면, '단말 기기가 자료 통신 회선을 통하여 컴퓨터에 접속되어 있는 상태, 즉 저장되어 있는 정보를 단말기에서 직접 접근 가능한 상태'를 이야기 한다. 그러나 이런 표현보다는 간단하게 어떤 자료의 변경이 이루어지는 상태라고 하는 편이 여기에서는 이해 하기가 편할 것이다. 즉, 광주, 혹은 부산 혹은 외국에서 입금을 하더라도 서울에서 즉시 입금 내용을 확인하고 이를 사용할 수 있는 그런 상태를 얘기하는 것이다.

이런 처리를 하는 분야를 OLTP(On-Line Transaction Processing : 온라인 거래 처리)라고 부른다. 이 분야는 70년대 이후로 컴퓨터의 다른 응용분야보다 비교적 탄탄한 기반을 이루어 왔다. 이 분야에서 대표적으로 언급되는 회사가 바로 IBM이다. 지금도 거의 모든 은행은 IBM의 대형 컴퓨터를 사용한다. IBM은 이런 OLTP를 위해서 하드웨어와 소프트웨어를 통합적으로 제공한다. OLTP 시스템들은 80년대 후반부터 시장 증가율이 매년 30∼40%로 급속한 성장을 이루고 있다.

또한 현재 전 컴퓨터 산업의 20∼30% 정도를 차지하고 있으며 앞으로 그 시장은 더욱 커질 것으로 예측된다. 은행이 대표적인 예이기는 하지만 온라인 시스템을 사용하면 편리한 곳은 상당히 많다. 사실 모든 정보 처리에 있어서 온라인 처리만큼 편하고, 정보의 확실성을 주는 것은 없을 것이다.

지금 자신이 조회한 자료가 어떻게 변했는지에 대한 불안이 없다. 즉 정보의 시간차를 없애서 지금 그 시점에서 정확한 정보를 얻을 수가 있는 것이다. 그러나 이런 온라인 시스템이 구성되기 위해서는 현재로서는 상당한 자금과 노력이 든다. 따라서 모든 부분이 온라인으로 처리되기에는 아직도 많은 시간이 걸릴 것이다. 그러나 많은 부분이 점차적으로 이러한 온라인 시스템으로 변경이 되고 있다.

9.3 온라인 트랙잭션 처리의 요구사항

위와 같은 온라인 시스템을 구성하기 위해서는 여러가지 사항들이 만족이 되어야 한다. 이를 정리해 보면 대략 다음과 같이 구분할 수가 있다. 이해를 돕기 위해 설명은 많은 사람들이 익숙한 은행을 예를 들고자 한다.

9.3.1 대량의 자료를 유지할 수가 있어야 한다.

요즘 은행에 한 개 이상의 구좌를 갖고 있지 않은 사람은 거의 없다. 1개의 구좌를 위한 정보를 100바이트라고 가정해보자. 그리고 우리나라의 인구가 약 5천만이고 은행이 여러 곳이 있으므로 한 은행의 구좌가 약 500만개라고 가정해보자. 그러면 처리해야하는 정보의 양은 약 500메가 바이트가 된다. 데이타 파일이 500메가나 된다고 가정해보자. 이는 엄청난 양이다. 사실 실제 온라인 시스템에서는 기가 바이트 이상의 데이타를 처리하는 것이 보통이며, 수백 기가 바이트를 필요로 하는 경 우도 많다.

9.3.2 빠른 응답이 요구된다.

은행에 가면 항상 많은 사람들이 대기하고 있다. 만일 은행에서 처리가 늦어지면 돈을 찾기 위해 하루 종일을 소비해야 할지도 모른다. 그러면 자연히 은행을 이용하는 사람이 줄어들고 은행 의 이익은 감소할 것이다. 대개의 경우, 온라인을 도입하는 곳에서는 하나의 거래가 2∼3초 혹은 1초이내의 짧은 시간에 이루어 질 것을 요구한다.

9.3.3 많은 사람이 사용할 수가 있어야 한다.

필자도 그렇지만 대개는 은행을 선택할 경우에 가까운 곳에 있는 은행을 선택을 할 것이다. 따라서 은행은 여러 곳에 지점을 두고 있다. 또한 한 은행에는 한꺼번에 많은 고객을 상대하기 위해 여러 개의 단말기를 설치하고, 혹은 현금 자동 지급기를 설치하기도 한다. 이와 같이 많은 온 -라인 시스템은 엄청나게 많은 단말기와 효율적으로 통신할 수가 있어야 한다. 또한 이를 정확하게 제어해야 한다.

9.3.4 항상 사용할 수가 있는 상태이어야 한다.

만일 은행의 업무가 마비된 상태가 발생했다고 상상해 보자. 이는 은행의 입장에서나 이를 사용하는 고객의 입장에서 엄청난 손실을 줄 것임에 분명하다. 이와 같이 온라인 시스템을 사용하는 경우 시스템의 고장이나 장애는 엄청난 손실이다. 따라서 온라인 시스템은 거의 항상 사용할 수가 있음을 보장해야 한다.

9.3.5 일관성이 유지되어야 한다.

자료의 일관성에 대한 얘기는 앞서 이미 예를 들었으므로 다시 얘기하지는 않겠다. 그러나 여러 사람이 이용하는 자료는 그 일관성이 중요한 것은 기억해야 할 사항이다. 잘못된 하나의 자료가 많은 사람을 곤란하게 만들 수도 있다.

9.3.6 보안이 이루어져야 한다.

은행에서는 대부분의 경우, 은행원들이 조작을 하지만 만일 우연한 기회에 이를 사용하게 된 사람이 있다고 가정을 해보자. 보안의 중요성은 강조할 필요가 없을 것이다. 특히 요즘처럼 많은 은행이 PC 통신과 같은 곳에서도 서비스를 받을 수가 있도록 하는 경우에는 철저한 보안이 필요 하다.

9.3.7 복구 시간이 짧아야 한다.

앞서서 거의 항상 사용할 수가 있어야 한다고 얘기를 하였으나, 사실 고장이 전혀 없는 시스템은 없다. 따라서 예견하지 못한 일이 발생하여 자료에 이상이 생길 수가 있다. 이러한 경우라도 신속하게 원인을 찾고 잘못된 자료를 복구할 수가 있어야 한다. 앞서서 얘기한 모 은행의 일을 상기해 보자. 시스템의 잘못에 대한 복구가 늦어지면 그만큼 손해도 커질 것이다.

9.3.8 사용이 간편해야 한다.

온라인 시스템은 많은 사용자가 사용하는 시스템이다. 또한 컴퓨터에 대해 전문적인 지식을 갖지 않는 사용자가 조작하게 된다. 따라서 사용이 간편해야 한다. 또한 이런 사용의 간편성은 잘못된 조작에 의해 일어날 수 있는 재처리 횟수를 줄여줄 수가 있다.

9.4 온라인 거래 처리의 응용

앞서도 잠시 언급하였지만 온라인 처리를 도입하는 분야는 점차로 증가하고 있다. 이미 사용되고 있거나, 도입되고 있는 실제의 온라인 처리 분야를 얘기를 해볼까 한다.

먼저 재무 분야에서의 예를 살펴보자.

앞서 계속해서 예를 든 은행이 대표적이라고 할 수가 있으나, 매일 수백만건의 거래가 일어나는 주식 거래를 취급하는 증권회사의 경우도 만만치 않다. 또한 순간 순간 주식의 시세를 표시해야 하는 증권회사의 전광판을 보면 처리의 긴박감이나 정확한 처리의 필요성은 더욱 강조되는 분야라고 생각된다. 또한 이보다는 덜하지만 국가의 세무관계의 정보처리나 일상적인 업무분야에도 적용이 가능하다. 현재 우리 나라의 세무 관계 처리는 수작업에 의해 문서를 송부하고, 이를 받아 처리하고 있지만 이를 온라인 처리로 변경한다면 많은 시간적 이익이 있을 것이다.

사실 공공 기관에서 처리되는 많은 작업이 빠르게 처리가 되면 이를 이용하는 사용자들이 더욱 혜택을 보게 된다. 이는 개인의 경우보다는 기업에서 보다 많은 혜택이 있을 것이라고 생각이 된다. 특히 수출입에 관계 되는 일이 빠르게 처리가 된다면 많은 기업의 국제 경쟁력이 강화될 것으로 생각된다.

다음으로 예약 시스템의 예를 보자. 예약 시스템으로 가장 먼저 온라인화가 된 것은 항공기 예약 시스템일 것이다. 우리가 항공사에 전화를 걸어서 예약하고자 하면 가고자 하는 목적지와 원하는 시간대를 물어서 검색을 하고, 가능한 시간을 알려주고 예약을 받는다. 또한 발권 업무에서는 예약이 되어 있는지에 대한 확인을 하고, 티켓을 판매한다. 이러한 예약은 주로 전화를 이용하여 이루어지므로 즉각적인 응답이 필요한 온라인 처리의 대표적인 예라고 할 수가 있다. 이 외에도 철도 예약 시스템이나 비교적 처리양이 작기는 하지만 호텔이나 콘도의 예약 시스템도 온라인 처리를 필요로 한다고 할 수가 있다. 판매관리 시스템도 대표적인 예이다.

대개 '포스 (POS : Point of Sales)' 라고 불리워지는 판매 관리 시스템은 손님이 원하는 물건을 즉시 판매해야 함으로 온라인 처리가 필요하다. 포스 시스템은 손님이 원하는 물건을 즉시 판매해야 함으로 온라인 처리가 필요하다. 포스 시스템은 현재 남은 재고를 재빨리 파악하고 필요하면 주문을 하고 재고를 최적의 상태로 만들어야 한다. 포스 시스템의 경우에는 은행과 같이 단편화하여 처리할 수가 없는 문제가 있다. 은행의 경우에는 어느 은행이나 혹은 예금의 종목에 크게 구애를 받지 않고 비슷한 입출금 처리를 할 수가 있다. 그러나 포스 시스템의 경우에는 재고량의 결정을 하는데에 '경영 정보 시스템(MIS : Management Information System)'과 긴밀하게 연결이 되어 있어야 한다.

이 외에도 전력의 수요에 즉시 반응해야 하는 전력 수급 감시 시스템이나, 수없이 많은 통화에 대한 감시를 하는 통화 감시 시스템도 온라인으로 이루어져야 하는 대표적인 예라고 할 수 있다.