백곰술사의 IT Insight

안녕하세요.

23.11.08일 금융감독원이 '금융 IT 안전성 강화를 위한 가이드라인'을 발표하였습니다.

아래와 같이 크게 두 가지 관점에서 나누어 볼 수 있습니다.

하드웨어 관점에서는 자원 임계치 구분 및 DR 인프라 확보(그에 따른 BCP 훈련)

소프트웨어 관점에서는 개발·변경 내용 검증을 위한 제3자 검증·통제 별도 조직 구성

두 가지 관점에서 금융사가 고민하는 부분은 소프트웨어 관점입니다.

임계치 및 DR은 비용을 투입하여 수행하면 끝이지만

제3자 검증·통제를 위한 별도 조직 구성은 각 금융사에 맞는 도입 전략이 필요하기 때문입니다.

이번 글은 제 3자 검증 조직 도입을 위해 현 시점 가장 빠르게 해야하는 실행 과제를 도출하려 합니다.

금융IT 안전성 강화를 위한 제 3자 검증 조직 도입 이슈트리

금융IT 안전성 강화를 위한 제3자 검증 조직을 어떻게 구성할 것인가?

이슈트리 구성 후에는 실행용이성/효과 측면에서 우선순위를 산정해 보면 아래와 같습니다.

결론적으로

내부 팀 생성/기존 임직원 교육을 통한 인력풀 확보/경력직 채용을 통한 인력풀 확보

이 세가지가 현 시점 가장 시급하게 수행되어야 할 과제라고 할 수 있습니다.

이후

SR/개발 프로세스에 제 3자 검수 단계 적용 및 솔루션/컨설팅을 통한 외부 역량 도입을 수행하는 것이

한정된 자원에서 가장 효율적으로 '금융 IT 안전성 강화를 위한 가이드라인'을 구현하는 전략이라고 할 수 있습니다.

금융IT 직원으로서 개인 디지털 역량 발전 측면에서 고민하고 있는 부분을 적어봅니다.

아래 3가지는 어떻게 보면 보수적인 금융문화의 결과물이 아닐지 생각합니다.

추후 시니어가 되었을 때 Insight를 보여줄 수 있는 사람이 되기 위해 열심히 공부해야겠습니다.

1. 신기술 스터디의 부재 및 무관심

 개인차원에서 신기술에 대해 스터디를 결성하거나, 회사차원에서 기술지원 사내 모임을 지원하는 부분이 적습니다.

 회사 내 스터디모임이 존재해 현 사내 금융 아키텍처 및 데이터 기반으로 유행하는 기술Stack을 적용해

 Toy Project를 진행한다든지하는 역량 발전과 관련된 모임을 해보고 싶은데 많은 관심들이 없는 게 안타깝습니다.

 이건 개인과 조직 모두의 문제인데 아무래도 IT자체도 보수적인 분야라 그런 부분이 한 몫하는 것 같습니다.

2. 도메인 기반의 IT가 최고

 금융 IT는 신기술 기반의 카카오, 네이버 및 여러 스타트업과는 다르게 도메인 지식 기반 IT입니다.

 수신, 여신, 회계 등 업무를 더 잘 알아야 인정받는 IT라고 할까요..?

 그런데 이게 참.. 아이러니 한 것이 있습니다.

 도메인 기반의 IT이다보니 업무를 잘 이해해서 소스로 그것을 빈틈없이 구현되는 것만이 최고이고

 정작 IT전반을 둘러싸고 있는 거대한 변화 흐름엔(ex. Cloud Native, DevOps) 많이 무지합니다.

 결국엔 금융IT 아키텍처도 대세로 흐를 건데 말이죠.

 오히려 이제는 도메인의 이해는 기본이고 여기에 최신 기술에 대한 고민을 더하는 논의가 활발히 되어야 합니다.

3. 훌륭한 멘토가 많이 없다

 IT업계를 보게되면 신기하게도 기술기반의 IT업계 사람들은 자신들의 업무 뿐만 아니라

 Side Project를 통해서도 신기술을 습득하고 개발력을 높이는 것을 당연하게 생각하고 노력합니다.

 그런데 부끄럽게도 금융업에 있는 IT직원들은 많이들 그렇게 노력을 안하고 있는 것 같아요.(제 기준에서는)

 물론 금융IT에 추가적인 기술Stack이 필요하지 않은 부분이 가장 크겠지만요.

 개인적인 생각으로는 업계 진입의 높은 허들을 동반한 현직자들의 안일한 자기계발의 결과일 것입니다.

 사실 금융IT에는 디지털시대에 우리가 나아가야할 Insight에 대해 깊이있는 애기를 주고 받을 수 있는 사람이 거의 없습니다.

 이 부분은 정말 카카오나 네이버같은 회사와 비교되는 바입니다.

 카카오뱅크/페이나 네이버페이가 UX가 좋고 기술적으로 안정되는 것은 다른 이유가 아닐 것 입니다.

안녕하세요

디지털 시대에 변화된 금융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