비대면채널, 빅데이터 시대에 대비한 아키텍처 높은 평가

◆본 기사는 디지털데일리가 2016년 3월말 발행한 ‘금융IT 혁신(革新)과 도전(挑戰)’ (상반기호)에 게재된 내용중 일부를 발췌 요약한 것입니다. 보다 자세한 내용은 e북 또는 인쇄판으로 보실 수 있습니다. 바로가기 (http://www.ddaily.co.kr/news/it_ebook_down.html)

- JAVA기반 전사 표준플랫폼 도입, ‘옴니채널’ 시대 대응
- ‘비즈니스 허브'로 교차판매 등 마케팅 채널 고도화 구현

우리은행과 교보생명이 올해 차세대시스템 프로젝트에 착수함에 따라 금융권의 2기 차세대시스템 구축 경쟁도 막이 올랐다. 또한 KB국민은행도 2기 차세대시스템 프로젝트를 위한 컨설팅에 본격 착수했다.

지난 2000년대 초중반부터 시작된 1기 차세대시스템 시대가 막을 내리고, 이제 향후 4~5년간 진행될 2기 차세대시스템 구축 레이스가 본격화되고 있는 것이다.

하지만 그에 앞서 '포스트 차세대시스템'이란 이름으로 지난 20 14년 국내 은행권에서 가장 먼저 2기 차세대시스템 체제로 성공적으로 전환한 기업은행의 사례를 되짚어본다. 이 프로젝트는 기술적인 완성도를 따지기에 앞서 국내 은행권이 직면하고 있는 ‘2기 차세대시스템’ 사업의 방향성을 제시하고 있어 그 의미가 크다.<편집자>

기업은행은 2012년2월에 포스트 차세대 프로젝트에 본격 착수한다. 그러나 그 그림은 그보다 2년 앞선 2010년7월부터 그려진다. 약 4개월간의 컨설팅을 통해 포스트 차세대시스템에 대한 방향성과 실행과제가 도출된다. 이후 기업은행은 2011년5월부터 9월까지 4개월간 구축 설계 및 실행 계획이 수립됐고 업체 선정작업에 착수하게 된다.

기업은행이 포스트 차세대 프로젝트를 추진한 이유는 복합적이다. 먼저 기술적인측면이다. 기업은행은 메인프레임과 유닉스(UNIX)로 혼재된 시스템 구조를 유지하고 있었지만 인터페이스및 상호운영의 한계에 직면했다. 보유한 시스템이 다양하고 많아짐에 따라 전사적인 표준화가 필요했다. 또한 각종 IT신기술의 등장과 다양한 채널의 증가에 따른 효과적인 대응이 필요한 상황이었다.

또한 비즈니스 환경도 변화됐다. 지난 2009년 스마트폰이 첫 출현한 이후 2010년부터 모바일금융 플랫폼 분야에서 의미있는 변화들이 생겨났다. 비대면채널의 증가, 빅데이터의 중요성 등 금융 패러다임의 변화를 상징할만한 의미있는 요소들이 등장한다.

또한 기존 은행 내부의 업무 프로세스를 혁신하는데 있어서도 포스트 차세대 프로젝트가 필요했다. 복잡하고 중복된 업무에 대한 통합, 재배치 등 프로세스 개선요구가 컸다. 업무 내비게이션, 워크플로우 등 미숙련 직원도 쉽게 사용할 수 있는 업무환경 요구가 증가했다.

결국 기업은행은 계정계, 정보계, 채널, 기반 인프라 IT거버넌스 전 영역에 걸쳐 총 6개 프로그램내 17개 프로젝트 추진하기로 확정한다. 기업은행이 목표로 한 6개 프로그램은 ▲스마트 채널및 마케팅체계 구현, ▲스마트 워크 플레이스 구현, ▲사용자 정보활용 체계 개선, ▲계정계시스템 재구축, ▲비즈니스 허브 구축, ▲포스트 차세대기반 구축이다. 이와함께 코어뱅킹(Core Banking) 재구축에 따라 영향받는 130여개 레거시 시스템의 대응개발을 진행했다.

개발을 완료한 후, 시범 점포를 포함 총 5회의 전 영업점 테스트및 업무 전문가 테스트를 실시해 개발 품질을 제고했다.

기업은행의 포스트 차세대시스템에서 가장 주목해서 봐야할 것은 ‘비즈니스 허브’로 명명된 정보계시스템의 철학이다. 여러 시스템에 분산돼있는 고객, 상품정보 등 마케팅 관련 정보를 통합해 관리/제공하는 새로운 개념의 마케팅 레이어이다.

이를 통해 멀티채널 마케팅및 상담판매 업무 혁신이 가능해 졌다. 예를들면 비즈니스 허브를 통해 고객확인, 추천상품, 교차판매(Cross Selling), 프라이싱(Pricing), 시뮬레이션이 가능해졌다. 또 상품정보를 비즈니스 허브에 통합하여 관리할 수 있도록 계정계 및 서브시스템의 정보를 동기화했다.

정보계시스템의 과감한 혁신, 어떤 효과?

포스트 차세대시스템을 통한 효과는 시스템별로 각각 다른 관점에서 파악할 필요가 있다. 먼저 ‘통합고객정보 제공’ 효과다, 프로젝트를 통해 기업은행은 창구 직원의 마케팅을 지원하는 통합된 고객 360도 뷰를 제공할 수 있게 됐다. 고객기본 정보 등에 실시간 접촉정보, 상담내역과 같은 정보를 추가함으로써 효과적인 창구마케팅 지원이 가능해졌다.

이와함께 ‘표준 상담및 판매 프로세스’ 개선도 이끌어 냈다. 기업은행은 고객의 일반정보, 가입정보, 상품추천, 가입조건상담, 계약체결까지 표준화된 상담및 판매 프로세스를 시스템화시켰다. 이에따라 창구 초보자도 표준화된 절차에 의한 세일즈가 가능하게 됐다.

‘통합업무환경 제공’을 통해 현업 사용자들의 업무 생산성을 대폭 향상 시켰다. 기존 분산 제공됐던 각 개별시스템 업무를 통합시켰다. 계정성 업무는 통합단말, 정보성 업무는 업무포탈로 통합하여 제공함으로써 사용자 편리성을 획기적으로 향상시킬 수 있었다.

하지만 포스트 차세대 프로젝트 이후, 영업점 사용 업무시스템이 통합단말환경으로 전환됨에 따라 종합관리, 여신사후관리, IB종합관리, 재정기금, BPR,펀드 등의 업무를 모두 통합단말에서 처리할 수 있게 됐다. 업무포탈은 5개의 정보시스템을 통합했으며 향후 재구축 시 통합할 수 있는 기반을 마련했다.

‘여신업무 프로세스’에도 큰 변화를 가져왔다. 기존에는 직원들이 동일 업무처리를 위해 여러 업무시스템을 이용하여 처리하던 업무처리 동선을 단말 내 단일거래로 통합하여 사용자 업무처리 환경을 혁신시켰다.

이와함께 기존 영업점 여신 처리 프로세스는 개인 및 소기업, 기업에 따라 각각 처리 절차가 상이했다. 여신 프로세스 별 처리 시스템이 HOST, 여신종합, BPR로 분산되어 있어서 업무 동선이 복잡했으며, 여신 업무 처리 효율성을 저하시켰다. 그러나 포스트 차세대 프로젝트를 통해, 기존 단위시스템에 분산되어 처리하던 프로세스를 하나의 프로세스로 통합해 업무시스템 간의 데이터 불일치 문제 해소 및 사용자 UI를 개선했다.

한편으론 유사업무를 통합처리함으로써 직원들의 불편함도 크게 개선했다. 업무별 개별 거래가 필요한 유사기능을 통합함으로써 업무 효율성과 정보의 일관성 확보할 수 있게됐다. 기존에는 유사 기능이 업무별로 분리되어 사용자 불편 다수 발생했다. 고객 관점의 통합된 이력 조회가 지원되지 않았지만 포스트 차세대를 통해 사고신고, 기일관리, 제증명서, 취소거래 등 유사업무는 하나의 프로세스에서 처리할 수 있게 됐다.

IT측면에서의 개선 효과는 보다 직접적이다. 메인프레임의 벤더 종속성에 따른 고비용 구조와 탄력적인 인력 운영의 어려움이 있었다. 이기종 간의 상호 인터페이스를 위한 복잡한 기술구조에 따른 운영리스크 상존했다. 그러나 유닉스로 통합하여 시스템 연계 및 인력운영 이슈를 해결했다. 단일 기술환경에 맞은 IT인력의 체계적인 육성이 가능해졌다..

‘소프트웨어(SW)'측면에서의 유연성도 향상됐다. 자바(JAVA) 표준 프레임워크를 도입함으로써 효율적인 개발 인프라가 마련됐다. 기존 계정계 시스템의 메인프레임 프레임워크는 자체 개발 생산성은 높으나 유연성, 확장성 및 유지보수 효율성은 떨어졌다는 평가를 받았었다.

또 단위시스템 별로 각자의 프레임워크를 사용하고 각각 상이한 개발 표준으로 설계, 개발돼유지보수가 어렵다는 지적을 받았다. 또한 단위 시스템 별로 운영의 관리 수준이 상이하여 종합적 운영관리 효율화를 위한 보완이 필요했다.

프로젝트 과정서 ‘돌발 상황’ 빈발, 대응방법은?

대형 IT 프로젝트를 진행하다보면 예상치 못한 돌발 상황이 발생하기 마련이다. 기업은행 포스트 차세대 사업도 예외는 아니었다. 기업은행은 프로젝트를 진행하는 과정에서 ‘시장의 불확실성’을 가장 큰 리스크로 꼽았다.

차세대시스템 계획 수립 단계에서는 전혀 예측이 안됐던 요건이 2년여의 프로젝트 진행도중에 불거지는 경우다. 이를 프로젝트에 개발과제로 추가로 편입시킬 것인지를 결정해야 한다. 이에 기업은행측은 “대응개발에 필요한 기간을 약 1년으로 추산해 이를 역산해서 사업을 준비했다”고 밝혔다. DB의 설계변경이 거의 없고 안정화되는 시기인 개발단계 후반부에 대응 개발요건을 추가로 포함시켜 리스크를 줄이는 방식이다.

기업은행은 대응개발 범위가 작은 50여개 시스템은 운영인력에 의해 자체 개발하고, 범위가 넓은 80여개 시스템은 외주개발을 통해 극복했다. 또한 사전에 정확한 대응개발 범위산정을 위해 운영직원들을 상대로 수 차례의 설명회를 개최했다.

개발 스펙이 당초 예상했던 것보다 넓어지기도 한다. 기업은행은 특성상 여신 프로세스가 굉장히 복잡하다. 당초 개발인력을 50여명을 제안했는데 결과적으로 100여명이 투입됨으로 비용이 늘어나는 어려움을 겪었다. 이 때문에 다소 여유있는 프로젝트 예산 확보가 필요하다고 주문한다.

개발 장소를 한 곳으로 단일화하는 것이 중요하다. 협업이 중요하기 때문에 물리적으로 가급적 동일 공간에서 프로젝트를 진행하는 것이 필요하다는 것이다. 기업은행은 장소의 협소로 3군데로 나눠 시스템 개발 작업을 진행했다. 그러나 프로젝트에 참여하는 50여개 업체, 1000여명의 개발 인력을 관리하는 것이 여의치 않았다고 분석했다.

프로젝트 마무리도 중요하다. 기업은행은 핵심 점검항목인 50여개의 ‘OPEN 품질지표’를 정의하고 각 부장이 직접 관리하도록 해 오류를 최소화했다.

사업 완료 후 개발인력 철수도 세심하게 고려돼야 할 부분이다. 변경된 프레임워크 및 언어 등 개발환경의 급격한 변화로 기존 운영자들이 새로운 시스템에 적응할 수 있도록 완충역할이 필요하다는 설명이다. 기업은행은 시스템 오픈 후 3개월에서 6개월 등 단계별로 철할 수 있도록 계획을 세웠고, 시스템 안정화에 성공했다.

<박기록 기자>rock@ddaily.co.kr

Copyright ⓒ 디지털데일리. 무단전재 및 재배포 금지