국내 시중은행 중 유일하게 프레임워크를 갖고 있는 은행이 있다. 국민은행이다.

지난 2004년부터 국민은행은 프레임워크 등에 대한 논쟁을 종식하고자 오라클 ‘플렉스 큐브’ 제품 사상을 들여와 지난 2006년경 완성한 ‘케사(KESA, KB 엔터프라이즈 서비스 아키텍처)’를 개발한 바 있다.

당시 아이플렉스가 이후 오라클로 인수됐고, 이 아이플렉스사 인도 전문인력을 국내에 초빙, 막대한 자금을 들여 개발했다.

2016년 현재 버전을 지속 업그레이드 해 ‘KESA 2.2’ 버전까지 업그레이드 된 상태고, 적용되는 업무도 2011년 60여개 업무에서 90개 이상으로 늘어 사용 중이다.

2.0 버전 이상을 사용 중인 업무는 고정자산관리, 구매관리, 상품팩토리(PDM), 전행 공통(KJI), 경영정보시스템 26개 이상 업무, 해외 영업점 시스템(KFI), 신용카드 분석, 신용카드 심사, 개인고객자산관리, 퇴직연금 등이다.

케사 프레임워크는 메인프레임용 z-케사와 개방형 표준 계열 u-케사로 구분된다.

이중 국민은행이 차세대시스템 개발 관련 언어를 ‘자바’로 채택할 경우, u-케사 프레임워크 검토가 가능할 것으로 보인다.

◆u-케사 프레임워크 특성은 = u-케사 프레임워크는 은행의 J2EE 기반 소프트웨어로, 기술적인 기반 메카니즘과 더불어 개발자 가이드, 교육, 필수 UI 등 SW 뿐만 아니라 국민은행 IT직원들의 업무 개발방식 및 품질을 표준화할 수 있는 방안을 제공한다.

아울러 국민은행 케사 프레임워크는 차세대 아키텍처에서 정의한 다양한 표준처리 방안이 적용돼 있고, MCI 및 EAI 등 KB IT 인프라 시스템과 애플리케이션이 인터페이스 할 수 있도록 지원하는 애플리케이션 프레임워크다. <그림1 ‘u-케사 프레임워크의 특성’ 참조>

▲ 그림1 ‘u-케사 프레임워크의 특성’

컴포넌트 설계 구조의 u-케사 프레임워크는 각 모듈별 R&R(Role & Responsibility)에 따라 수개의 레이어로 구분되며, 역참조 및 모듈간 커플링을 방지하기 위해 상호 호출이 아닌 항상 상위에서 하위 컴포넌트를 참조하고 사용한다.

이같은 특성으로 인해 재사용 및 유지보수를 용이하게 하며, 애플리케이션 스타일에 따라 다양하게 적용하고, 쉽게 관리할 수 있다.

특히 하위 컴포넌트 재사용율이 높다. <그림2 ‘u-케사 프레임워크 컴포넌트 설계’ 참조>

▲ 그림2 ‘u-케사 프레임워크 컴포넌트 설계’

케사 프레임워크는 기본적으로 MCI 및 EAI에서 수신한 내부 표준전문을 애플리케이션에서 이용할 객체로 변환하고, 트랜잭션을 시작한 다음 애플리케이션을 호출하는 구성이다.

또한 애플리케이션에서 필요로 하는 DB 액세스 처리와 EAI와의 인터페이스를 위한 API를 제공한다.

이어 u-케사 프레임워크는 업무 컴포넌트에서 필요로 하는 기초 메카니즘, 예를 들어 로깅, 예외 등 기능을 지원한다. <그림3 ‘u-케사 프레임워크 vol.2 구조’ 참조>

▲ 그림3 ‘u-케사 프레임워크 vol.2 구조’

u-케사 프레임워크의 기능은 ①서비스 리스너(Service Listener) ②서비스 디스패처(Service Dispatcher) ③거래관리 ④애플리케이션 인보커(Application Invokor) ⑤데이터 액세스 서비스(Data Acess Service) ⑥서비스 리퀘스터(Service Requester) ⑦펀더멘탈 퍼실러티(Fundamental Facility) 등이다. <그림4 ‘u-케사 프레임워크 주요 기능’ 참조>

▲ 그림4 ‘u-케사 프레임워크 주요 기능’

차세대 UI에서 요청된 전문은 MCI를 거쳐 KB 내부 표준전문으로 변환되며, 케사 프레임워크의 ‘서비스 리스너’로 수신된다. <그림5 ‘표준 전문과 자바 객체의 변환’ 참조>

▲ 그림5 ‘표준 전문과 자바 객체의 변환’

EAI에서 요청 역시 동일한 형태로 케사 기반 시스템에 전문이 전달된다.

또한 케사 프레임워크 내에서 처리된 거래 결과는 메시지 빌더(Message Builder)에 의해 다시 KB 내부 표준 전문으로 변환돼 요청한 시스템에 MCI/EAI를 거쳐 회신된다.

MCI나 EAI는 각 클라이언트 또는 시스템의 전문을 내부 표준 전문으로 변환하는데 이는 MCI나 EAI의 역할이기 때문에 각 시스템에 정의된 입출력 맵(Map) 정보를 바탕으로 변환된다. <그림6 ‘케사 프레임워크 EAI시스템 연결 구조’ 참조>

▲ 그림6 ‘케사 프레임워크 EAI시스템 연결 구조’

시스템 트랜잭션 관리 관련, 케사 프레임워크의 트랜잭션 매니저(Transaction Manager)는 WAS의 JTS(자바 트랜잭션 서비스)를 이용해 거래 정합성을 관리한다.

‘거래관리’ 컴포넌트는 애플리케이션이 투명하게 트랜잭션을 관리하기 위해 애플리케이션 호출 전에 트랜잭션을 시작하고, 애플리케이션 트랜잭션 호출이 반환되면 트랜잭션을 commit/rollback 한다.

따라서 애플리케이션은 필요한 데이터 액세스를 수행하기만 하면 해당 액세스는 트랜잭션과 묶여서 수행하게 된다.

거래관리 컴포넌트의 commit/rollback 여부는 애플리케이션에서 예외를 던지느냐 그렇지 않느냐에 달려 있다.

즉, 애플리케이션에서 예외를 던지면 해당 트랜잭션은 롤백 된다.

금융회사에서 하나의 거래를 처리할 때 특정 데이터들은 거래 전체에 걸쳐 동일한 정보가 유지되고 빈번하게 참조돼야 한다.

케사 프레임워크에서는 이같은 정보들을 애플리케이션의 모든 레이어에서 공통적으로 사용할 수 있도록 공통영역(Common Area)를 제공한다.

공통영역의 정보는 거래일자, 조작자번호, 부점코드 등의 정보를 저장할 수 있으며 거래가 끝날 때까지 애플리케이션의 모든 레이어에서 동일한 정보를 동일한 방법으로 참조할 수 있다.

이 공통영역의 각 항목 값을 세팅하는 주체는 프레임워크의 전행 공통 프로그램이며, 프레임워크는 내부 표준 전문의 공통부 값을 공통영역에 세팅하게 된다. <그림7 ‘케사 프레임워크의 공통영역 참조방법’ 참조>

▲ 그림7 ‘케사 프레임워크의 공통영역 참조방법’

마지막으로, 케사 프레임워크는 sql매퍼(Mapper)를 이용한 데이터 액세스를 제공한다.

이 sql매퍼의 기능은 ‘객체<-->SQL 파라미터 매핑’ 그리고 ‘SQL 실행결과<-->객체’간 매핑을 수행한다.

한편 케사 프레임워크는 최근 이슈가 되고 있는 API 관련 고도화된 기능도 제공한다.

타 시스템 인터페이스를 위한 케사 프레임워크 API는 프로토콜 등 메카니즘을 하부로 숨기고, 애플리케이션에서는 API를 이용해 행당 시스템에 전송·수신할 전문에 대한 읽기·쓰기 기능만 수행한다.

◆국민은행 ‘자바’ 채택 가능성은 = 이같은 강점의 케사 프레임워크를 가진 국민은행이 향후 추진할 포스트 차세대시스템 기간언어로 자바를 채택할 지는 미지수다.

기업은행이 시중은행 구축 사례를 갖고 있지만, 국민은행과 비교해 프로그램 본수에서 큰 차이를 보이기 때문에 국민은행이 ‘계정 시스템에 자바’를 채택할 경우 시스템이 견뎌낼 수 있느냐 하는 점 등 이슈가 예상된다.

물론 막대한 시스템 리소스로 이같은 난제를 해소할 수 있지만 수십년전 ‘국민주택채권’ 업무까지 운용중인 국민은행 입장에서는 자바를 채택하는데 적지 않은 고심을 기울여야 할 것으로 보인다.

그렇다고, 최근 트렌드를 무시하고 C 기반 차세대를 고집하면, 십수년 후 또 시스템을 손대야 한다는 난제도 국민은행의 전략적 판단에 적지 않은 영향을 미칠 것으로 보인다.

지난 2010년 메인프레임 기간 시스템 구축 이후 고작 6년만에 또 플랫폼 논쟁에 불을 지핀 현 상황이 재현될 수 있다는 우려다.

컨설팅을 시작으로 막을 올린 국민은행 차세대 프레임워크의 미래 청사진은 ‘안개속’이다.

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