백곰술사의 IT Insight

그렇다면 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

안녕하세요.

MyPayment와 함께 금융 혁신을 선도할 License로 일컬어지는

종합지급결제사업자에 대해 정리해 보았습니다.

[종합지급결제사업자 정의 및 특징]

1. 종합지급결제사업자의 정의

  - 단일 라이센스로 모든 전자금융업을 영위하여 다양한 핀테크 서비스를 One-stop으로 제공할 수 있는 플랫폼 사업자

  - 은행 계좌없이 간편결제, 송금, 인출 및 금융상품 중개 판매 등을 제공하는 종합 금융 플랫폼 사업자

2. 종합지급결제사업자의 특징

  - 지급결제를 위한 독자 계좌 보유(은행 보유 지급결제계좌 연동 불필요)

  - 보유계좌 활용 이자 제공 및 대출 불가능
    (은행라이센스를 보유한 것은 아니며, 향후 Small License와의 결합을 통해 제공 가능)

  - 대출, 보험 등의 금융상품 중개/판매

[종합지급결제사업자 개념도]

- 종합지급결제 플랫폼의 핵심은 기존 금융권과 차별화된 혜택/금융 서비스를 제공하는 것

[종합지급결제사업자 향후 발전방향]

1. Small License Fintech와의 제휴 연계로 다양한 서비스 제공

  금융업 인허가 단위를 작게 분할해 License를 부여하는 제도인 Small License제도 활성화에 따라

  특성있는 Fintech 서비스 상품을 제휴해 회원에게 제공하는 방향으로 발전예상

2. 대형 플랫폼사업자의 종합지급결제사업자 진입으로 경쟁력있는 자사결합 서비스 제공

  카카오, 네이버, 페이코 등의 기존 대형 플랫폼사업자들의 종합지급결제사업자 진입으로

  자사 쇼핑, SNS, Payment 등과 결합해 결제시장에서의 경쟁력있는 서비스 제공

3. 기존 금융사업자와의 경쟁으로 사용자 혜택/UX 강화

  현 결제시장의 주류인 카드사와의 지급결제시장의 경쟁촉발

  계좌기반의 Payment와 카드사 신용공여 기반의 Payment의 경쟁 심화로

  사용자들에게 발전된 UX 및 혜택 제공 가능

안녕하세요

디지털 시대에 사용자 관점에서 디지털 전환하기에 대해 써보려합니다.

디지털 전환이란?

기업에서 사물 인터넷(IoT), 클라우드 컴퓨팅, 인공지능(AI), 빅데이터 솔루션 등 정보통신기술(ICT)을 플랫폼으로 구축·활용하여 기존 전통적인 운영 방식과 서비스 등을 혁신하는 것을 의미한다. - TTA(한국정보통신기술협회)

요약하면

기존 인프라에 디지털 신기술을 적용하여 기존 운영 혁신 및 혁신  서비스를 창출하는 개념입니다.

디지털 전환의 개념은 매우 쉽지만 현실적으로 기업들에게는 큰 고민거리가 있습니다.

어떻게 창조적 파괴를 이루어 낼 수 있는 비즈니스 모델을 창출할 것인가? 입니다.

디지털 사업을 해야겠는데.. 마땅히 떠오르는 비즈니스 모델은 없고..

이 부분은 기존 기업 뿐만 아니라 스타트업에도 어려운 부분입니다.

기존 Contact기반의 비즈니스 모델 개발도 어려운데

신규 Untact기반의 디지털신기술까지 결합해서 비즈니스 모델을 만들어야 한다니

하지만

모든 성공적인 사업이 그렇듯 핵심은 사용자에게 어떤 가치를 제공할 것인가를 먼저 생각하는 것에서부터 출발합니다.

사용자 관점에서 디지털 전환을 생각해보기

1. 사용자가 평소 상상했던 서비스를 시공간에 구애받지 않는 UX로 제공하기

  간단하게 풀어쓰면 사용자의 "귀차니즘"을 분석하고 파고들자입니다.

  예를 들어 몇가지를 생각해보면 아래와 같습니다.

  "내 수준에 맞는 문제풀이 및 강의를 자동으로 제공해줬으면 좋겠어" -> EduTech

  "꼭 전화를 해서 상담을 해야 답을 들을 수 있나? 그냥 톡으로 하면 좋을텐데" -> 챗봇

  "공정을 물리적으로 점검하지 않아도 디지털트윈 가상화기반으로 품질/안전을 확인하면 좋을텐데" -> 스마트공장

  이 뿐만 아니라

  아침식사를 원하는 고객 Needs를 잘 캐치한 마켓컬리, 음악/동영상 앱들의 개인취향 AI추천 서비스 등이 있습니다

  내가 사용자으로서 평소 "이렇게 되면 좋을텐데.." 라고 무심코 넘어가는 평소 상상했던 부분을

  디지털 기술을 이용해 현실화/사업화 시키는 활동이 디지털 전환의 핵심이라고 할 수 있습니다.

  위와 같은 아이디어의 발견/Develop을 위해 최근에는 디자인씽킹(Design Thinking)이라는 방법론을 많이 사용합니다.

2. 비용절감 만으로 디지털 전환을 생각하지 않기

  신규서비스를 런칭해야하는 스타트업과는 다르게

  기존 기업에서의 디지털 전환은 사용자를 위한 서비스 개발보다는 디지털 전환을 통한 비용절감 사업이 우선이 될 수 있습니다.

  디지털 전환은 기업 입장에서 많은 부분 비용절감이 가능하게 하지만 그것만을 생각한다면 오히려 역효과가 날 수 있습니다.

  대표적인 예시가 바로 "키오스크"입니다.

  키오스크는 고객과 기업에게 비용 이익은 제공하지만 UX편의성이 떨어지며 오히려 사회취약층의 디지털 소외까지 일컬어지는

  비용절감 측면에서의 대표적 디지털전환 사업입니다.

  많은 기업 및 전문가들이 선제적으로 서비스를 출시하고 UX는 지속적으로 고도화하면 된다라고 하지만

  이는 디지털 전환의 가장 중요한 점을 생각하지 않고

  아직 산업화 시대의 관점으로 사업을 진행하는 오류라고 볼 수 있습니다.

  디지털 전환의 가장 중요한 점은 1번에서 썼듯이 고객의 상상을 현실로 만들어주는 것입니다.

  하지만

  내 상상과는 다른 UX를 제공한다면 그것은 제대로된 디지털 전환 서비스가 아닐 것 입니다.

  최근과 같이 디지털 기반의 신규 서비스 출시가 빠른 사회에서

  사용자의 UX가 보장되지 못한 서비스의 출시는 오히려 기업 이미지 및 매출을 저하시킬 수 있다는 점에서

  디지털 전환 시에는 필수적으로 사용자 UX도 같이 고려해야합니다.

3. 연결하고 개방하기

디지털 전환 시대의 사용자가 원하는 핵심 가치는 연결과 개방입니다.

디지털 세대 사용자들이 이용하는 서비스들은 상호 연결되어 생태계를 형성하고 있습니다.

스마트 TV를 통해 OTT, SNS를 확인하며

스마트 폰을 통해 단말들을 통제/관리하며

각 디지털 서비스들은 Open API를 통한 Data의 송수신, O-Auth를 통한 보안 인증을 연동합니다.

최근에는 MyData법안 통과로 각 플랫폼에서 MyData를 제공해야하므로

더더욱 연결과 개방은 중요해지고 있습니다.

기존 디지털 서비스들이 형성한 연결/개방 생태계에 하나의 구성원으로 들어가 가치를 창출하는 것

디지털 전환 시 필수적으로 고려해야할 핵심 요소입니다.

안녕하세요

정보시스템 감리 핵심에 대해 정리해 보았습니다.

1. 발주자 요구사항 필수 4가지 품질 확보(완전성, 정확성, 검증 가능성, 추적성)

사업자는 발주자 요구사항에 대해 누락 없이, 구체화하여, 추적이 가능하며, 향후 검증 가능한 수준으로

품질수준을 확보해 프로젝트를 진행해야 합니다.

발주자 요구사항에 대해 요구사항정의서(기술서)에 명확히 관리되고 있지 않다면

향후 SDLC(Software Development Life Cycle)진행 시 미구현 이슈가 발견될 것입니다.

정보시스템 감리는 위와 같은 이슈발생상황을 요구사항정의 및 설계단계 감리를 통해

사전에 방지하는 역할을 수행합니다.

2. 사실 근거 기반의 감리 활동 수행

정보시스템 감리 수행 시 기본이 되는 핵심은 명확한 사실 근거를 기반으로 지적사항을 정리하라입니다.

예를 들면 아래는 명확한 감리 사실 근거를 제시하기에 한계가 존재합니다.

  1. 데이터베이스 감리 중 명확하지 않은 정규화에 개선 의견

  2. 사업관리 감리 중 의사소통 및 인력관리 등에 대한 개선 의견

따라서

정보시스템 감리 시에는 아래와 같은 사실 근거 기반의 감리 활동 수행이 핵심입니다.

  1. 데이터베이스 감리 중 ERD 관계 매핑의 불일치

  2. 사업관리 감리 중 일정관리가 1~2 주를 넘어가는 일정 수립

  3. 하드웨어 용량산정 시 "정보시스템 하드웨어 규모산정 지침" 등을 따르지 않은 설계

3. 프로젝트 성공을 위한 Insight 제공

2번의 사실 근거 기반의 감리 활동 수행과 더불어

정보시스템 감리 가치를 높이는 핵심은 프로젝트 성공을 위한 Insight 제공입니다.

현 구축 시점에는 문제가 되지 않더라도

향후 보안, 성능 등의 관점에서 이슈가 될 수 있는 부분을 적절하게 제시하는 것입니다.

보통은 아래와 같이 제시하게 됩니다.

개선유형 "권고", 개선시점  "장기"

  권고 : 감리의 대상범위를 벗어나지만 사업목표 달성에 도움이 되는 사항

  장기 : 장기적인 관점에서 지속적으로 개선해야 하는 사항

안녕하세요

COViD-19로 인해 급격한 언택트(Untact) 시대가 도래하며

스마트 헬스케어를 활용한 원격의료 도입 논의가 진행되고 있습니다.

그에 따라 스마트 헬스케어를 활용한 원격의료의 기술, 규제 등을 생각해보았습니다.

1. 스마트 헬스케어란?

개인의 의료정보 및 라이프 로그에 AI, Cloud, BigData 등 최신 IT기술을 활용하여

사용자 및 환자에게 개인별 최적화된 의료 서비스를 제공하는 기술

2. 원격의료란?

ICT기술을 활용해 원거리에 있는 의료인/환자에게 의료지식 제공 및 원격 모니터링, 진료 처방를 하는 의료행위

3. 스마트 헬스케어를 활용한 원격의료

- 의료는 Mission Critical한 산업군이기 때문에 AI의 판단근거를 제공하는 XAI가 중요한 요소로 대두됨
- 의료 판단의 편향을 없애기 위해 초기 양질의 학습Data 확보다 중요

4. 원격의료 도입을 위한 제도적 한계점

현행 의료법 제34조(원격의료)에 따르면 의료인은 컴퓨터·화상통신 등 정보통신기술을 활용해

먼 곳에 있는 의료인에게 의료지식이나 기술을 지원하는 원격의료만 가능

5. 원격의료 도입을 위한 전략방향

1. 의료법 규제개선

   - 원격 모니터링, 처방을 위한 의료법에 대한 규제 개선
   - 규제 샌드박스를 활용한 단계적 도입

2. 정부 주도적 사업수행
   - 신기술은 일반적으로 안정적 생태계 구축 및 발전을 위해 공공기관에서 선도적으로 사업수행
   - 서울대병원 등의 공공병원을 활용해 선도적 스마트헬스케어를 통한 원격의료 시스템 구축 사업수행

3. 해외 벤치마킹

   - 원격의료는 미국, 중국 등에서 활성화 되어있는 사업
   - 해외 원격의료 생태계 구성 Best Practice를 벤치마킹하여 산업 발전 도모

1. 정보시스템감리 코드관리 도입목적

기본점검표와 해설서에 대한 체계적인 관리 및 활용

2. 정보시스템감리 코드관리 구조 

3. 정보시스템감리 코드관리표

출처 : [정보시스템 감리 점검 해설서 v3.0], 한국정보화진흥원, 2008.3.3

1. 정보시스템감리 감리영역별 지침의 표지

총 4가지로 구성 

 1) 감리영역별 지침의 코드

 2) 사업유형/개발모델/감리시점/감리영역

 3) 현재 최신버전

 4) 점검프레임워크상에서의 위치

2. 정보시스템감리 감리영역별 지침의 본문

총 7가지로 구성

 머리글

  1) 왼쪽은 감리영역별 지침의 사업유형/개발모델/감리시점/감리영역 구분

  2) 오른쪽은 감리영역별 지침의 코드

 바닥글 

  3) 왼쪽은 해당 페이지의 버전

  4) 오른쪽은 해당 페이지 번호로 구성 
 내용
  5) 가운데 내용이 존재

  6) 왼쪽은 해당 내용에 대한 제목이 배치

  7) 오른쪽은 점검항목에 대한 코드 또는 검토항목에 대한 코드를 표시

출처 : [정보시스템 감리 점검 해설서 v3.0], 한국정보화진흥원, 2008.3.3

1. 정보시스템감리 감리영역별 지침이란?

- 사업유형/감리시점/감리영역별로 작성된 세부 감리지침

- 점검항목을 점검하기 위한 세부적인 검토항목과 주요검토대상 산출물로 구성

2. 정보시스템감리 감리영역별 지침 구조

감리영역별 지침 구조는 기본점검표 항목에서

기본점검항목에 검토항목과 주요검토대상 산출물, 검토내용 세가지가 추가된 구성

[참고 - 기본점검표와 감리영역별 지침 구조의 관계]

출처 : [정보시스템 감리 점검 해설서 v3.0], 한국정보화진흥원, 2008.3.3

1. 정보시스템감리 기본점검표란?

- 점검프레임워크를 기반으로 사업유형별/감리시점별/감리영역별로 도출된 기본점검항목을 정리한 표

- 기본점검항목은 사업유형별로 다양한 특성을 지닌 사업에 대해 공통적으로 적용할 수 있는 항목

2. 정보시스템감리 기본점검표 구조

기본점검표 구조는

기본점검표와 기본점검항목 간 연관도 두가지로 구성

출처 : [정보시스템 감리 점검 해설서 v3.0], 한국정보화진흥원, 2008.3.3