백곰술사의 IT Insight

안녕하세요

디지털 시대에 변화된 금융IT 아키텍처의 변화에 대해 적어보려 합니다.

아래는 개인적으로 업무를 하며 느낀 기반으로 작성했습니다.

[디지털 시대 이전]

금융IT의 꽃은 뭐니뭐니해도 계정계입니다.

 1) 여신/수신 등 금융 비즈니스의 필수업무 개발/운영을 수행하며
 2) 도메인 기반IT이기 때문에 업무진입장벽도 높습니다.

 3) 데이터를 생성/처리하는 업무를 담당하여 기간계/처리계라고도 불립니다.

대부분의 금융회사는 계정계가 핵심이자 갑이며 나머지 시스템은 을의 입장을 가지고 있습니다.

하지만

최근 AI, BigData의 발전으로 데이터 분석/활용이 중요해짐으로써 금융IT의 핵심 비중의 변화가 생기고 있습니다.

[디지털 시대 이후]

최근 금융IT의 화두라 하면 당연 Data Lake/BigData 기반 AI Modeling을 통한 비즈니스 전략 수립입니다.

금융 IT의 핵심인 계정계는 원래 그런 것, 당연한 것으로 오히려 고리타분한(?) 업무로 인식이 변화됨을 느낍니다.

서비스만 개발하는 비용을 줄이는 대상으로 전락당했다고나 할까요?

디지털 시대 이후에는 고객에게 개인화된 서비스를 제공하는 비즈니스가 핵심이기에 금융권에서도

그것을 가능하게 하는 빅데이터 분석 및 AI Modeling 기술에 관심을 두고 투자를 늘리고 있습니다.

[디지털 시대, 계정계과 AI와의 협업은 필수]

금융권에는 아직 계정계과 AI를 담당하는 조직 간에는 Silo가 존재합니다.

많은 금융사가 CFT(Cross-Functional Team)을 유기적으로 만들지 않았기 때문입니다.

(AI는 AI, BigData는 BigData, 계정계는 계정계로 판단하는 폐해입니다.)

조직 간 Silo로 발생할 수 있는 문제는 아래와 같습니다.

 1) AI 담당자 입장에서는 계정계 업무를 이해하지 못하면 Data를 명확히 사용할 수 없습니다.

 2) 계정계 담당자 입장에서는 AI 조직의 요청사항이 업무/Data를 이해하고 요청하는 것인지 의심스럽습니다.

하지만 우리는 조직 간 협업을 통해 우리는 아래와 같은 시너지를 낼 수 있습니다.

 1) AI 담당자 입장에서는 Data의 명확한 이해 기반으로 AI Modeling을 할 수 있다.

 2) 계정계 담당자 입장에서는 AI조직에서 추가/수정 해달라는 데이터에 대해 이해기반으로 데이터를 생성해준다.

데이터를 생성하는 계정계와 그것을 분석/활용하는 정보계/AI 등의 협업이 원활히 된다면

Fintech시대에 다양한 서비스를 제시해줄 수 있는 금융IT로 발전할 것입니다.

그렇다면 MSA전환 전략에 따라 금융IT 코어시스템 MSA전환은 어떻게 해야할까요?

3. 금융IT 시스템을 MSA로 전환하기

금융IT의 Legacy 시스템은 대부분 강결합 서비스입니다.

하나의 서비스가 다른 서비스가 제공하는 모듈들을 참조하는 것이 특징입니다.

그렇다면 금융은 어떤 기준으로 기존 Monolithic Service를 Micro Service로 전환해야할까요?

아래와 같이 3가지 기준으로 전환 할 수 있습니다.

[금융시스템 Micro Service 전환기준]

  1) Monolithic Service 중 결합도가 낮은(Loosely Coupled) 서비스

  2) Monolithic Service에 참조되는 Business Component
      (물론 Business Component도 결합도는 낮아야함)

  3) One Transaction이 필수적인 거래(입/출금거래 등)는 일정수준의 결합도를 가진 서비스로 전환

거의 대부분의 Service를 Micro Service로 전환하되

금전Data의 Commit일관성 등이 필요한 서비스는 약간의 결합도를 가진 상태로 구성하는 전략이 필요합니다.

[AS-IS : Monolithic Service]

[TO-BE : Micro Service]

4. 금융IT 코어시스템을 MSA 전환 시 고려할 점

3과 같이 금융 시스템의 MSA전환 전략 기반으로 수행한다 하더라도 기존 시스템을 MSA로 전환하는 것은 굉장히 어렵습니다.

[기술 역량 확보]

 MSA의 가장 큰 특징으로는 서비스 기준으로 아키텍처가 완전히 분리된다는 것입니다.

 대출신청은 Java, RedisDB를 쓰고, 한도확인은 Python, MongoDB를 사용할 수 있습니다.

 각 서비스에 대한 Property만 설정해두면 원활히 사용가능합니다. (Polyglot)

 기존 금융권에서는 Java/C, RDBMS 등의 기술셋 결합이 일반적이기 때문에

 MSA 효과를 배가시키기 위해 다양한 기술역량을 확보하는 것이 필요합니다.

[우선순위 기반 개발/배포]

 금융IT 코어시스템 서비스 기준으로 Risk 우선순위를 정해 개발 및 배포를 수행합니다.

 Less Critical한 서비스 기준으로 개발/배포해 Lessons Leanred를 얻고

 Mission Critical한 서비스를 개발 배포하는 방향으로 나아갑니다.

 MSA는 BigBang방식과는 다르게 각 서비스를 독립적으로 배포할 수 있기에

 유연하게 Risk를 낮추는 관점에서 개발/배포합니다.

[Cross-Functional Team 도입]

 MSA는 서비스 기준 독립적 배포 및 서비스 관리가 가능하기에

 CFT(Cross-Functional Team)도입이 필수적입니다.

 서비스에 관련된 현업/IT/Data/AI 구성원들을 한 팀으로 구성해 더 나은 서비스를

 기획하고 더 빨리 배포하고 결과를 분석하는 체계를 통해 MSA의 효과를 극대화할 수 있습니다.

안녕하세요

금융사의 IT직원으로 코어시스템을 어떤 방향으로 기획할 것인지? 최신 기술 및 동향을 어떻게 접목해 발전을 이룰것인지?

비록 제가 주니어 직급이며 기획팀은 아니지만 항상 고민이 됩니다.

20.04월 한화생명이 자사 코어 기간계 시스템을 Cloud로 전환 시 MSA로 전환했다는 소식을 듣고(with NBP)

대략 2주간 굉장히 고민했습니다. AWS 다니는 친구에게도 MSA 지식에 대해 물어보고..

어떻게 결합도가 최상이라는 금융 기간계 서비스를 MSA로 전환했지..?

구글링을 통해서는 명확한 프로젝트 내용을 알 수 없었지만, 저를 굉장한 고민을 빠뜨린 기사인 것은 확실합니다.

그러면서 금융사의 MSA 전환에 대해서 다시 한번 생각해보았습니다.

1. 금융사 같은 Mission Critical 산업을 왜 MSA로 전환해야 하는가?

금융IT는 중앙집중화로 인한 안정성이 가장 중요한 특징입니다.

따라서 MSA에 대한 유행이 2015년정도부터 시작되었음에도 불구하고 아직 금융사는 SOA를 유지하고 있습니다.

하지만

아래와 같은 배경은 금융사를 MSA로 갈 수 밖에 없게 만들고 있습니다.

  1) Fintech 등장으로 인한 기존 금융사의 서비스 다양화 및 빠른 출시(배포) 필요

  2) 중앙화된 시스템 수준으로 올라온 분산시스템의 안정성 확보

  3) 초연결 및 개방을 하지 않고서는 살아남을 수 없는 비즈니스 생태계

2. MSA 전환 전략은 어떻게 할 것인지?

그렇다면 우리는 어떻게 MSA전략을 만들어야 할까요?

금융사의 MSA전환을 생각해보기 전에 MSA전환 전략에 대해 기획과 관리자의 관점에서 구글링 해본 결과

AWS Korea 박선용 솔루션아키텍트님이 2018 AWS Summit Seoul에서 발표한 전략이 가장 좋다고 판단되어 소개드립니다.

[출처가 되는 해당 영상은 아래 첨부해 두었습니다.]

DevOps, CI/CD 등의 Cloud Native는 차치하고

철저히 서비스 분할 관점에서 현 운영되는 Monolithic Service를 어떻게 Micro Service로 전환할 것인가에 대한 전략입니다.금융사는 강결합된 서비스의 분할이 가장 큰 핵심이기 때문입니다.

[전략 출처]

youtu.be/Fp6wkP3Ofsg