계정계 1호기 원인 ‘시스템 레벨’ 문제

지난 1월 25일 발생한 우리은행 전산장애 관련, 한국IBM이 장애 책임을 인정하는 듯한 표현의 공문을 우리FIS에 발송, 파문이 일고 있다.

특히, 이 공문의 내용이 사실상 장애원인이 메인프레임 및 그 기반 CICS 그리고 시스템 레벨에 있다고 밝혀 향후 은행과 우리FIS, 우리FIS와 한국IBM간 책임공방에 적지 않은 영향을 미칠 것으로 예상된다.

아울러 한국IBM이 왜 이같이 즉각적으로 자사의 책임을 인정했는지에 대해 업계에서는 다운사이징을 염두에 둔 ‘꼼수’로 보고 있다. 논란이 예상되는 대목이다.

또 우리은행은 1월 26일 감독기관에 ‘용량부족이 원인’이라고 한 장애보고와 공문내용이 달라 당시 보고가 ‘허위’였다는 점이 밝혀졌다.

6일 업계에 따르면 한국IBM이 지난 1월 25일 장애 관련, 우리FIS에게 보낸 공문 내용 중 상당부분 내용이 장애에 대한 책임을 인정하는 내용인 것으로 전해졌다.

이 공문은 우리FIS가 장애원인을 규명하고, 방지대책을 마련해야 한다는 식으로 한국IBM에게 발송한 1차 공문에 대한 회신형식이다.

첫 장애는 2012년 1월 25일 15시 19분 발생한 것으로 공문은 적시하고 있다.

공문에서 한국IBM은 ‘우리은행 계정계 1호기 시스템 가동 중단의 원인은 CICS 하에서 기동하던 시스템 레벨 프로그램이 수행되던 중 반복적인 메모리 변환 오류가 발생함으로써 z/OS 운영체제가 자동 중단한 것’이라고 전했다.

메인프레임 전문가들에게 문의, 이 내용을 해석한 결과 소위 ‘메모리 성능이 떨어지지 않는 현상’이라고 설명했다.

서버에 있는 애플리케이션은 업로드와 변환, 소위 활성화됐다가 비활성화됐다가를 반복하면서, 메모리 사용량도 늘었다가 줄어드는 현상을 반복한다.

이 과정에서 일부 애플리케이션이 변환, 즉 비활성화되지 않고 계속 메모리 사용량을 잡고 있는 현상 ‘메모리 변환 오류’가 발생했다는 것이다.

그 원인은 다양한데 대체적으로 데이터베이스 행이 결리는 현상에서 주로 나타난다.

다른 프로그램이 아니라 한국IBM의 ‘CICS하에서 기동하던 시스템 레벨 프로그램’이라고 밝혀, 장애원인이 한국IBM 제품에 있음을 간접적으로 인정했다.

이어 이 공문에서는 ‘대응책으로 시스템레벨 프로그램에서 반복적인 메모리 변환 오류 발생시 자동적으로 감지하여 근본적인 원인 분석을 위한 덤프(DUMP)를 받도록 조치함과 아울러 CICS를 선제적으로 중단시키는 자동화조치로 업무 가동 중단을 발생하지 않도록 조치함’이라고 밝혔다.

CICS(customer information control system, 고객 정보 제어 시스템)란, 한국IBM에서 공급하는 데이터 입력이나 거래조회 등을 하기 위한 온라인트랜잭션 용 제품으로, 다수의 단말이나 초당 수백/수천건의 처리요구 등이 필요한 은행 IT시스템에 주로 사용된다.

이 문장에 대해 IT업계 한 전문가는 “아마 한국IBM이 취한 후속조치에 대한 설명인 것으로 보인다”며 “메모리 변환 오류 내용 분석(덤프 방식을 통해)에 들어갔고, CICS단에서 자동감지 기능을 추가한 것 같다”고 설명했다.

이 관계자는 이어 “CICS를 중단시키면, 계정계 메인프레임이 다운됐다는 의미와 다를 바 없는데 업무 가동 중단을 발생시키지 않도록 조치했다는 말이 무슨 말인지 모르겠다”고 덧붙였다.

다른 IT 전문가는 공문 내용의 문장 자체에 오류가 있다고 지적했다.

‘CICS를 선제적으로 중단시키는 자동화 조치’를 취했는데 어떻게 ‘업무가동 중단을 발생하지 않도록’할 수 있느냐며 정상적으로 작성된 문장은 아니라고 밝혔다.

한국IBM이 직접적인 장애원인 제공자가 아니라는 점을 우회 표현하기 위해 문장을 복잡하게 표현해 놓은 것이라는 설명이다.

공문 내용중에서는 계정계 4호기 ‘거래지연’ 사태에 대한 설명이 나타난다.

‘계정계 4호기에서 후속조치과정 중 2012년 1월 25일 16시 28분경 거래지연의 원인은, 다량의 비정상 상태 데이터 발생’이라고 적시했다.

이는 ‘시스템 플렉스’ 가동으로 1호기 중단에 따른 2~4호기 백업 처리 과정을 설명한 것으로 풀이된다.

우리은행 메인프레임은 CF(Coupling Facility, 병렬시스템간 정보 공유 장치) 형태로 1~4호기 중 하나의 시스템이 다운될 경우, 나머지 3대가 백업 처리하도록 돼 있다.

비정상 상태 데이터 발생은 1호기 다운 이후 데이터들이 2~4호기로 몰렸고, 특히 4호기 성능에 영향을 미쳐 거래지연 상황이 나타난 것으로 분석된다.

◆IBM, 우리은행 IT다운사이징 노린 ‘꼼수’ 논란 = 금융IT 업계는 한국IBM이 왜 장애원인을 신속히 인정했는지에 대해 의심의 눈초리를 보내고 있다.

다국적 IT기업의 특성상 이같이 구체적인 이유를 들어 ‘자사책임’ 내용을 소상히 밝힌 사례는 드물기 때문이다.

실제로, 여타 은행권 장애 상황마다 한국IBM은 모르쇠로 일관해 왔다.

특히 한국IBM은 장애 상황이 발생하면, 앞서 설명한 ‘덤프(DUMP)’ 즉 장애상황을 보여주는 기록과 로그 등 레지스트리 내용을 미국 본사로 보내 분석에 적어도 1~2개월 이상 걸린다고 발뺌하기 일쑤였다.

그런데, 1월 25일 장애 후, 2월 6일 공문으로 열흘만에 자사 과실(fault)을 인정해 버렸다. ‘IBM 꼼수’ 논란이 나오는 대목이다.

금융IT 업계에서는 그 배경에 대해 ‘우리은행 다운사이징 프로젝트’과 무관치 않은 것으로 추론중이다.

올해 우리은행은 총 1136억원(H/W 454억, S/W 454억, 개발비 227억)에 달하는 막대한 ‘다운사이징’ 예산을 확보했다.

이에 앞서 지난 2010년 가을, 우리은행은 한국IBM과 3년간 총 934억원(증설+Non-IBM S/W)의 OIO 계약을 체결한 바 있다.

2010년 체결한 OIO 계약으로 2010년과 2011년 기준 322억+α 등 한국IBM은 우리은행에서 수백억원을 이미 챙겼다.

그런데, 당시 우리은행과 한국IBM의 계약에는 ‘위약금 없이 계약해지 가능’이라는 단서조항이 붙었다.

즉, 이번 장애로 한국IBM은 당시 체결한 OIO 계약이 유지될 수 없을 것이라고 보고, 다운사이징 프로젝트에 집중할 것으로 예측된다.

‘매’는 빨리 맞고, 다운사이징 관련 영업에 집중해 실리를 챙기자는 뜻이 이번 공문의 진의라는게 금융IT 업계의 중론이다.

문제는, ‘CICS 하부시스템 레벨’의 장애라는 점에서 한국IBM 의도대로 될지는 미지수다.

현재 우리은행이 검토중인 메인프레임 다운사이징은 ‘리호스팅’ 방식이다. 리호스팅은 빅뱅 방식과 달리 미들웨어와 컴파일러 솔루션을 이용해 기존 업무용 애플리케이션과 데이터베이스(DB)를 유닉스로 전환, 재사용한다.

장애 원인이 된 CICS 하부 시스템 레벨을 리호스팅 방식 적용, 다운사이징 후 개방형 서버에 그대로 채택할 경우, 동일 장애 우려에 대해 은행 안팎의 논란에 부딪힐 가능성이 크다.

아울러 다운사이징 예산 1136억원 과다계산 논란, 우리FIS 친(親) IBM 행보에 대한 유착 의혹 등 한국IBM이 넘어야 할 산은 많다.

특히, 비씨카드 소송, 잇따른 농협 IT장애 등 ‘믿을 수 없는 기업(벤더 리스크)’의 대명사로 전락한 한국IBM을 우리은행이 ‘진정한 비즈니스 파트너’로 인정하기란 쉽지 않을 것으로 보인다.

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