지난 12일, 국민은행(은행장 허인)의 스타뱅킹·인터넷뱅킹 거래지연 원인이 거래량 예측 오류일 가능성이 제기돼, 업계 이목이 쏠리고 있다.

덧붙여 자바 프로그래밍 구조적 문제도 동반됐다는 얘기도 전해진다. 

20일 국민은행 및 업계에 따르면, 지난 12일 당일 총 3억건 이상 거래를 처리하는데 있어 부하에 문제가 있었던 것으로 알려졌다.

국민은행 관계자는 “12일, 약 3억건 이상 거래량을 처리했다. 당시 DBMS 용량을 늘려 대응, 거래지연이 완화됐다”며 “현재 당시 상황에 대한 각종 소프트웨어, 하드웨어 기록 및 프로그램을 덤프 떠서 IBM 연구소에 보내놓은 상황”이라고 설명했다.

IBM 연구소로 보냈다고 얼핏 IBM DB2 이슈로 보이지만, 용량을 늘려 대응해 거래지연이 완화됐다는 점에서 DB2의 기능적 이슈는 아닌 것으로 추정된다.

더 케이 프로젝트에 참여했던 업체 한 관계자도 “당일, 직원들이 은행에서 전달받은 내용은 DB서버 및 디스크 용량부족으로 보고됐다”며 “국민은행은 IBM(DB2), HPE(x86서버), 효성(디스크) 등과 계약을 통해 용량이 부족할 경우 일시적으로 용량을 늘리는 방법을 택해 거래지연 상황을 넘긴 것 같다”며, 이같은 설명을 뒷받침했다. 

이른바 CoD(Capacity on Demand)를 적용, 당일 늘어난 거래량에 대응했다는 것으로 풀이된다.

국민은행이 밝힌 3억건 이상 거래량은 4일 이상 명절 연휴 이후 처리수준에 맞먹는다. 논란은 은행측이 이 정도 거래량을 왜 예측하지 못했느냐 하는 점이다. 

20일 오전 제보 및 업계의 주장을 종합해 보면, 자바 프로그래밍에 근본적인 원인이 있다는 애기와 함께 오픈뱅킹 등 과거 거래량 산정으로는 불가능한 포인트가 발생했다는 해석이 가능하다.

자바는 자바만의 실행 코드 ‘바이트코드’를 컴파일러에 의해 생성하고, 이를 자바 가상 머신(JVM)에 의해 해석돼 실행한다.

국민은행이 구성한 자바 프로그래밍에 문제가 있을 경우, 일대일로 처리되는 스타뱅킹·인터넷뱅킹 거래에 속도가 은행측이 설계한 구조보다 현격히 떨어질 수 있다는 주장이다. 

여기에 덧붙여 국민은행 관계자는 “3억건 거래량에 대한 해석이 다르다. 예컨대, 오픈뱅킹·오픈API 시행 등으로 은행 자체적으로 예측할 수 있는 용량과 차이를 보일 수 있다”고 전했다.

과거 IT시스템은 선형적으로 시스템을 늘려 그때 그때 필요한 용량을 확장했지만, 프라이빗 클라우드 구조에서 스타뱅킹(국민은행 모바일뱅킹 브랜드) 및 인터넷 뱅킹에 할당되는 소프트웨어·하드웨어 시스템 용량 총량을 단순 예측하기 어려웠다는 것이다.

국민은행 관계자는 “은행의 과거 거래량을 기준 거래 트리거(trigger)가 2~3개 정도 발생한다고 전제하면, 오픈뱅킹을 비롯한 최근의 다양한 거래처리 유형을 대응하면서 트리거가 4~5개 이상 발생한 것으로 보면 된다”고 해석했다.

정리하면, 프로그램 꼬리가 긴(garbage collection) 자바 프로그래밍 이슈에 덧붙여 숨은 거래량 예측이 빗나간 게 12일 거래지연의 원인으로 추정해 볼 수 있다.

업계에서는 이 때문에 당분간 거래지연 상황이 지속될 가능성이 적지 않다는 예측도 내놓고 있다.

그럼에도, 거래량 예측이 빗나간 이유 및 프라이빗 클라우드 모델에서 왜 로드밸런싱이 없었는지에 대한 논란은 지속중이다.

‘오픈뱅킹이던’, ’오픈 API’던 과거 국민은행 이미 운영하고 있던 통상 거래량을 기준으로 더 케이 프로젝트 이후 총 용량을 제대로 산정했어야 한다는 게 업계 일각의 주장이다. 

지난 12일 당일 거래지연으로 국민은행은 혼쭐이 났다. 

반면, ‘리눅스-x86-자바-가상화-프라이빗 클라우드’라는 국내 초유의 IT시스템을 구성한 국민은행의 이번 사례는 향후 금융권 클라우드 구축 ‘용량산정’의 새로운 바로미터가 되고 있다. 

<김동기 기자>kdk@bikorea.net