[시스템용어] 금융권 IT시스템에 대한 이해

금융권 IT시스템에 대한 이해

 

금융권이라고 하면 화재, 생명, 은행, 상호저축은행 등이 있는데요. 시스템이 조금씩 다 다릅니다. 우선 은행만 정리했습니다. 블로그랠 위해 공개된 정보를 중심으로 정리하다 보니 약간 부족한 점이 있습니다.

 

 

은행 시스템은 어떻게 구성되어 있을까?

---

 

 

한국의 금융시장은 대부분 '여러가지 법'에 의해 통제되고 있습니다. 그래서 '은행 업무'가 대부분 동일한데 기본적으로는 고유업무, 부수업무, 겸영업무로 나뉜다고 합니다.

 

은행의 고유업무는 저축을 받고 돈을 빌려주는 업무로 수신(저축), 여신(대출), 외환으로 구성되어 있습니다. 부수업무는 보증을 서주거나 어음을 인수하는 등의 일이고 겸영업무는 채권회수(추심)을 대행하거나 기업 M&A를 중개하는 등 은행업은 아니지만 자본과 관련된 기타 일들을 말합니다. 하지만 은행의 거의 모든 업무는 금융위원회의 신고를 해야해서 실제로는 정부의 관리 감독 하에서 영업을 한ㄷ자고 볼 수 있습니다.

 

그래서 은행마다 조금씩 다르긴 하지만 대부분 아래와 같이 시스템이 구성되어 있습니다.

 

 

그림을 자세히 보십시오. 은행업무가 어떻게 구성되어 있는지 조금 이해가 되시나요? 여기에서 중요한 용어를 살펴보도록 하겠습니다.

 

 

1) 계정계(Core Banking)

은행의 전통적인 핵심 업무는 통장이 중심이 됩니다. 이 통장을 계좌, 계정이라고 합니다. 한 사람이 여러개의 통장을 만들수도 있고 돌아가신 분의 통장도 있기 때문에 기본 데이터가 1억 건이 가뿐히 넘습니다. 통장별 거래 기록을 포함하면 수백억건의 데이터들이 있습니다. 계정계 데이터는 곧 돈과 거래 기록이기 때문에 장애는 바로 금전적 피해로 이어집니다. 따라서 데이터를 이중 삼중으로 백업하며 시스템이 매우 보수적으로 운영됩니다.

 

계정계 시스템은 '공통업무, 수신업무, 신탁업무, 보험업무, 카드업무, 여신업무, 외환업무, 대행업무 시스템'등으로 구성됩니다. 대부분 마스터테이블인 거대한 원장들이 있고, 다양한 업무 처리를 보장하는 정형화된 트랜잭션들이 있습니다. 기본적으로원장들에 트랜잭션이 집중되는 구조이기때문에 안정적으로 트랜잭션을 처리하기 위한 미들웨어(Middleware)가 발달해 있습니다.

 

초기에는 IBM Mainframe을 사용했으며 2000년대 중반 차세대 프로젝트를 통해 많은 은행들이 Unix로 이전하였습니다. 과거에는 프로그래밍 언어로 COBOL을 사용했지만, 차세대를 통해 대부분 C로 옮겨갔습니다. Java가 최초로 도입된것은 2013년 (전북은행)일 정도로 굉장히 보수적으로 운용됩니다.

 

반면 기존 시스템의 운영부담이 적은 보험회사의 경우는 일찌감치 Java를 도입하기도 하였습니다.

 

2) 정보계

정보계는 거래활동 및 성과를 분석하고 측정하기 위한 목적으로 구축되었습니다. 주요시스템으로는 데이터웨어하우스를 기반으로 하는 수익관리, 고개관계관리, 성과관리, 위험관리 시스템 등이 있습니다. 정보계는 단순히 궁금증을 해결하는 수준이 아니라 영업정보에서 기업전략 정보까지 포함하기 때문에 계정계만큼 중요하며 없어서는 안될 시스템입니다.

 

정보계는 1980년대에 은행업무가 발전하면서 그 개념이 등장하기 시작했습니다. 기본적으로 통계처리 기법을 많이 사용하기 때문에 대량 데이터 결합조회(JOIN), 배치처리, 대량 데이터 전송 기술 등을 많이 사용합니다. 최근에는 빅데이터 기술의 도입이 많이 검토되고 있습니다.

 

 

 

3) 대외계

대외계는 은행 외부기관과의 연계되는 업무를 처리하기 위해 구축되었습니다. 네트워크를 통한 연계이므로 1970년대 지로공과금을 처리하기 위한 금융공동망과 함께 역사가 시작되었다고 볼 수 잇습니다. 주요 시스템으로는 인터넷뱅킹, 텔레뱅킹, 펌뱅킹, ATM 등이 있습니다. 단순한 게이트웨이가 아니라 비즈니스 기능을 포함하고 있습니다. 거래내역 기로기 및 검증, 프로토콜 변화, 네트워크 오류 시 재전송 기능까지 매우 복잡한 구조로 운영되고 있습니다. 주로 대용량 처리보다 정확성과 안정성에 중점을 준 트랜잭션 허브들이 도입되어 있습니다.

 

4) 운영계

통합관제, 네트워크 모니터링 등을 운영계라고 부릅니다.

 

5) 기타

이 외에 은행이라는 기업을 움직이기 위한 시스템들이 있습니다. 회계, 인사, 세무 시스템 등인데요. 흔히 백오피스라고 부르기도 하고 기업업무 시스템이라고 부르기도 합니다.

 

 

기술적 특징들

---

트랜잭션이 돈 처리를 의미하는 것이기 때문에 오류에 민감합니다. 소수점 처리에도 민감합니다. 0.1원 오류가 1억원의 피해로 이어질 수도 있습니다. 오류가 일결산에서 확인이 안되고 월결산이나 연결산에서 발견될 수도 있습니다. 따라서 거래 쪽은 빠른 개발이나 배포보다 안정적인 개발과 배포를 중요하게 생각합니다. 전체적으로 IT문화도 그렇다고 볼 수 있습니다.

 

은행업무는 대부분 안정되어 있어서 변화가 적고 데이터도 대부분 정형화되어 있습니다. 그래서 프로세스 설계와 데이터 설계가 매우 중요하게 다루어집니다. 기존 시스템을 쉽게 폐기할 수 없기 때문에 계속 확장을 통해 기능을 구현하는 편입니다. 이기종 DB나 복잡하게 시스템이 얽혀 있는 N-Tier 환경이 대부분입니다. 그래서 ORM이 오래전부터 사용되었습니다. 인터넷 뱅킹이 24시간*365일로 운영되긴 하지만 대부분 주간에는 금융거래 중심의 트랜잭션들이 일어나고 야간에는 대형 배치처리 시스템간 데이터 전송이 많이 일어납니다. 

 

사소한 변경이 큰 금전적 피해로 이어질 수 있기 땜누에 수정 사항이 있더라도 영향도를 체크한 후에 움직이는 편이며 가능하면 시스템 수정은 기피하는 경향이 있습니다. 유지보수가 중요하기 때문에 기술지원이 안정적인 솔루션들과 피해를 책임질 수 있는 전문 업체를 선호하는 경향이 있습니다. 그래서 신기술 도입이 더딘 편입니다.

 

그리고 차세대를 구축하는 시기에 아키텍처 패턴으로 SOA가 등장하여 많은 시스템에 적용되기도 했습니다.

 

데이터 작업이 많고 처리 속도가 중요한 편이라서 서버작업에는 Oracle과 Pro*C가 많이 사용됩니다. 최근에는 계정계를 제외하고는 Java가 많이 도입되어 있습니다.

 

꼭 필요하지 않으면 도전적인 기술을 사용하지 않기 때문에 기술보다는 '은행 업무'를 얼마나 잘 이해하고 있느냐가 경력자 채용의 중요한 기준이 됩니다. 은행업무를 모르면 비즈니스 로직을 짤 수 없기 때문입니다.

 

 

차세대 시스템이란

---

 

세계적으로 은행에 IT가 도입된 것은 1970년대였습니다. 이때 최첨단 기술은 메인프레임에 여러 대의 터미널을 붙여서 운영하는 Full Server 운용방식이었는데, 이후 전화기, ATM, 무역금융 등이 발전하면하면서 은행 전산시스템도 꾸준히 고도화되었습니다. 2000년대에 들어서 여러가지 이유로 거의 모든 시스템을 고도화 할 수 밖에 없게 되었는데 그 변경 범위가 너무 커서 차세대 프로젝트라고 이름을 붙이기 시작했습니다. 차세대가 끝난 이후에는 POST차세대로 부르면서 계속 고도화 중 입니다.

 

차세대라는 용어는 이후로 보험, 증권회사 등에도 널리 사용되고 있지만 모두 같은 시스템을 지칭하는 것은 아닙니다.

 

 

실패로부터 배운 교훈들

---

변경범위가 워낙 커서 꽤 많은 차세대들이 실패했으며 이 과정에서 차세대 프로젝트들은 개발자들에게 Hell Project로 일컬어지기도 했습니다.

 

대부분 SI프로젝트가 겪을 수 밖에 없는 한계점들이 극명하게 드러나서 관련 종사자들에게 많은 교훈을 남겼습니다. 하지만 속 시ㅏ원한 대안이 없어 아직도 많은 회사들이 시행착오를 겪고 있기도 합니다.

 

 

다른 차세대들은 어떤가요?

---

아래 시스템은 메리츠 종금종권의 차세대 시스템입니다. 당연한 이야기이지만 아래 시스템에서 수신(예금저축)은 찾아볼 수 없고 대신 주식을 사고파는 증권 서비스가 있습니다. 그리고 여신 신탁등이 있어 시스템을 보면 증권사의 업무를 짐작할 수 있습니다.

 

 

 

금융권에서 Java를 사용하는 이유

---

은행 시스템에서도 스크립트 기반의 언어가 사용되는 곳이 있습니다. 그러나 시스템이나 구현해야 할 비즈니스 특성에 따라 언어가 달라집니다. C나 COBOL은 시스템 언어라 CPU 성능을 100%까지 남김없이 끌어 내기에 좋은 언어입니다. 그러나 이식성이 떨어지므로 남은 시스템을 재활용하거나 서로 다른 기종의 컴퓨터를 하나의 시스템으로 운영해야 할 때 꽤 불편합니다. 100여 대에 가까운 서버, 무거운 Batch처리나 가벼운 조회 트랜잭션, 시스템의 다양한 관리 상태에 상관없이 운영해야 하는 Enterprise 환경에서 Java Spring만한 대안이 없기 때문입니다. 극한 성능이 요구되는 환경에서는 다른 언어를 사용하기도 합니다. 

 

참고로 금융환경에서 많이 등장하는 이슈들과 Java의 특성을 잘 이야기한 글을 링크 합니다.

 

Sun Microsystems, JAVA Enterprise - 백창현 수석(삼성SDS 프레임워크그룹)

 

물론 이론적으로 이렇게 구성한다고 해도 실제 상용화될 때 기대한 대로 움직이지 않는 경우도 적지 않으니 꼭 참고만 했으면 합니다.

 

 

핀테크란 무엇인가?

---

결제수단의 기술적 진화와 함께 금융분야의 변화도 함께 일어나야 합니다. 올해 들어 인터넷전문은행의 설립에 대한 이야기가 굉장히 활발합니다. SK C&C 부장님의 발표도 첨부합니다.

 

은생 시스템의 추세가 계정계, 정보계, 대외계를 굳이 나누기 보다 업무나 기능별로 분류하고 있음을 알 수 있습니다.