GitLab을 활용한 금융권 DevSecOps 사례 웨비나가 12월 11일 금요일 GitLab 한국 엔지니어인 유인철님과, 한화생명의 윤상배님 그리고 인포그랩의 신철호가 발표하였고, 발표 중에서 국내 사례 내용을 요약해보았습니다.
규제가 진입 장벽으로 작동해서 지켜주는 시장이라면 중요하지 않을 수 있습니다. 하지만 현재는 다른 인터넷 서비스와 금융도 경쟁 해야 합니다. 즉 고객이 원하는 기능을 탐색하고 요구사항이 기능 중심으로 만들어져서, 코드로 만들고 배포하는데 하루인 기업과 기능 배포가 가능한지부터 걱정해야 하는 기업의 경쟁력의 격차를 생각해보시죠. DevSecOps는 선택이 아닌 필수입니다. GitLab 으로 하면 쉽습니다. >
(윤상배님 발표 내용 중)
Gitlab을 활용한 금융권 DevSecOps 구축사례 웨비나 → 유튜브에서 다시보기
금융권의 트렌드
핵심 키워드는 디지털 전환과 데이터 기반
- 금융권의 핵심 키워드는 디지털 전환과 데이터(데이터 기반의 AI)
- 그 안에 Agile, DevOps, DevSecOps, 클라우드 네이티브와 같은 디지털 전환 달성 키워드 파생됨
- 코로나로 인한 대면영업 위축이 위기감이 커지고, 언택 트 서비스를 출시하기 시작함
- 온라인 소통이 필요하고 디지털/자동화/더 많은 데이터 필요의 의미에서 **"데이터 엔지니어링"**과 **"AI"**관심도 급 부상
- 핀테크 기업의 약진, "언번들링" 강세 (언번들링 = 기존 금융기업이 중앙집중적으로 해오던 서비스를 떼어내서 전문화해서 제공하는 것)
디지털화 트렌드
- 화폐와 자산의 디지털화 또한 기술적 테마
- 디지털 자산으로 시작했던 기업들은 DLT, 암호화폐, StableCoin(fiat), 데이터, 인터넷 친화성을 무기로 디지털 기반 지불/결제 시스탬 경쟁력을 강화중
- Fintech 2.0 의 언번들링 -> 3.0으로의 여정으로 번들링을 시작함
금융권 규제 및 변화
규제의 변화
- 금융권 클라우드 서비스 이용 범위 확대를 담은 전자 금융 감독 개정안 시행
- 클라우드 인프라를 코드로 관리하고 있으며, 1시간 이내에 쿠버네티스 플랫폼, CI/CD, 보안 설정, 로깅 분석 시스템의 인프라로 전개 능함
- 전자금융법이 14년 만에 전면 개편되어서 마이데이터, 종합지금결재업, 마이페이먼트 등의 "인터넷 기업들이 혁신 금융 서비스 만들 수 있도록" 규제 완화
변화에 따라
- 금융 서비스의 인터넷 서비스화: 금융기업 간의 경쟁이 아니라 인터넷 서비스 기업들과도 직접 경쟁
- 인터넷 테크 기업은 기술이 유리하지만, 오랜 기간 금융업을 진행해온 자체 경쟁력과 축적된 자산의 장점 있음
- 금융권의 디지털 변환이라는 것은 결과적으로 금융 기업의 강점 살리면서, 새로운 (인터넷, 고객)환경에 적응 하기 위한 여정임
금융권의 DevOps필요성 및 다른점
중점 1 : 애자일 기반 역량
- 제품/서비스의 핵심은 "고객에게 어떤 가치를 주는가" 임
- 기업의 서비스 배포는 "탐색과 기획단계에서 개발, 테스트, 배포, 피드백 다시 기획"의 반복에서 가치 흐름을 잘 설계해야 함.
- 고객 가치를 빠르게 전달 하려면 벨류스트림을 압축해야 하고, 이를 애자일을 통해 가능함
- 각 단계에서 작업 시간은 오래 걸리지 않아서, 최적화 할 요소가 많지 않음 (계속 해오던 전문 영역)
- 단계를 넘어가는 "가치 전달" 하는 대기시간에서 최적화 필요
- 가치 구현이 지연되는 문제는 구성단계가 아닌 "시스템의 문제" 즉 "조직 구조와 정보전달 및 공유와 같은 조직 문화" 에 대한 문제임
중점 2 : DevOps 와 DevSecOps 역량
- DevOps는 파이프라인을 최적화하는 것임
- 수도 파이프라인에 흐르는 물의 속도는 "가장 빠른 부분이 결정하는 것이 아니라 가장 느린부분이 결정"
- Value Stream에서도 가장 느린 부분을 최적화 해야 하며, 이 부분은 운영 쪽임
- 애자일은 개발쪽인 디지털영역에서 탄생, 운영은 "시스템", "네트워크", "보안"과 같은 물리적인 영역을 포함함. 제조업이라면 공장, 서로 다른 영역으로 엮이기 어려움
- 금융권에서도 운영의 디지털화가 필요하며, 이를 위해서는 클라우드가 필수 요소
- 클라우드 시스템은 API를 이용해서 소프트웨어 개발 하듯이 서비스 운영 환경을 만들 수 있게 됨
- 결과적으로 DevOps는 클라우드와 쌍으로 움직임
- 금융권에서는 추가로 보안의 최적화가 필요하며, 개발에서 운영까지의 value stream을 하루로 줄였다고 해도 보안에서 일주일이면 그냥 일주일임
- 금융권은 좀더 DevSecOps 에서 Security 에 대한 활동을 더 안정적으로 최적화 하기 위한 노력을 하게 됨
- 규제가 진입 장벽으로 작동해서 지켜주는 시장이라면 중요하지 않을 수 있음
- 다른 인터넷 서비스와 경쟁 하려면 생존의 이슈, 고객이 원하는 기능을 탐색하고 요구사항이 만들어져서, 코드로 만들고 배포하는데, 하루인 기업과 기능 배포가 가능한지 부터 걱정해야 하는 기업과의 경쟁력의 격차는 비교 안됨
- 코드로 배포하는데까지 하루가 가능한가? 라는 의문을 제기 할 수 있을 것 같습니다. 실제 가능하며 그렇게 하고 있음
- 디지털 전환의 주요한 기술적 키워드는 애자일 프랙티스의 적용 + 클라우드(퍼블릭이든 프라이빗이든 하이브리드이든) + DevOps 일테고 이들이 협력해서 벨류 스트림을 최적화 해야함
DevSecOps 구축하기
0단계 : 조직 구조 및 거버넌스 구성
- 애자일 조직의 바람직한 모습을 시도했고, 현재는 제품 개발팀 구조로 세분화 되어서 다양한 기술기반 금융 서비스를 개발 진행 중
모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다. -콘웨이의 법칙
- 의사소통 구조를 목표에 맞추기 위한 DevOps를 묘사하고 있으며, DevOps 활동은 기존의 SILO를 해체하면서 시작됨
- 해체한다는 것은 팀을 없앤다는 게 아니라, SILO 효과를 제거해서 각 조직간 원할한 정보소통이 가능하게 한다는 의미
- 애자일 하면 나오는 수평적인 조직문화가 여기에서 파생된 것이며, 거버넌스는 DevOps 활동이 성공적으로 수행되도록 방향을 설정하고 권한을 부여
- 이렇게 하는 목표는 높은 품질의 서비스를 고객이 원하는 시점에 출시하기 위함
1단계 : BizDevOps로 협업 기반 마련
- 가치가 만들어져서 고객에게 전달되는 그 과정에 어떤 조직적 구성요소가 있는지를 식별하는 작업을 진행
- 의사소통 과정에 어떤 조직 혹은 팀이 있는지를 알게 되며, 구성요소를 파이프로 연결하고, 정보가 효과적으로 흐르도록 설정
- 정보를 효과적으로 전달하기 위한 툴로 Jira, Confluence, GitLab을 큰 축으로 하는 시스템을 구축
- GitLab은 코드 정보들이 흘러가고 빌드, 테스트, 공유 하기 위한 목적
- Jira, Confluence는 각 구성요소(조직)간 정보들이 흘러가는 통로, 의사소통 구조를 개선하기 위한 작업을 수행
다양한 툴들이 있을 건데 깃랩을 사용한 이유가 있을까요?
DevOps는 기획, 개발, 품질관리, 배포, 운영까지의 전체 시스템을 아우르는 복잡한 체계입니다. 우리는 복잡함을 덜어내고 통합된 뷰/가시성을 제공하는 "조율하는 툴"을 찾기를 원했습니다. 이 툴은 통합과 프로그래밍 가능성 이라는 두 가지 기능을 충족해야 했습니다.
통합 측면에서 파이프라인의 주요 컴포넌트들은 여러 조직이 분산 운영 할 수 있습니다. 자칫 정보에 대한 가시성이 떨어질 수가 있는데, 통합된 뷰를 통해서 가시성을 확보 할 수 있어야 합니다. 여기에는 기획 문서, 개발 이슈 추적, 개발영역에서의 승인 시스템, CICD(개발 → 배포) 툴, 각 종 프로젝트 자산(코드, API문서, 버전별 패키지)의 저장/관리 시스템, 배포관리(배포 승인, 배포 버전, 점진적 배포, 배포 롤백, 배포 후 모니터링), 모니터링까지를 포괄합니다.
프로그래밍 가능성(유연성)측면에서 가시성을 확보했다면 흐름을 모니터링 하면서 최적화 시켜야 합니다. 각 컴포넌트들의 환경과 요구사항이 다르고 다양한 정책과 툴들이 사용되기 때문에 유연하게 작동해야 합니다. 파이프라인에 새로운 요소를 추가 하거나, 정책이 바뀔 수 있습니다. 예를 들어서 development 환경에서 staging 환경으로 정보(코드)를 보내기 위해서는 "승인" 절차가 필요하다는 요구가 있으면, 이 파이프라인의 중간에 "승인 절차와 승인 정책"을 넣을 수 있어야 합니다. 이 승인 프로세스를 완성하기 위해서 외부 시스템(Active Directory), Jira, 레포팅 툴, 보안 툴과 통합할 수 있어야 합니다. GitLab의 기본 기능(CICD, 코드 저장소, 컨테이너 저장소)와 스크립팅 기능을 포함한 파이프라인 설계 툴 LDAP, AWS 클라우드 연동, Kubernetes 플랫폼 연동 등과 같은 확장 기능을 이용해서 단일 한 환경으로 구성 할 수 있었습니다.
규제도 이슈가 됩니다. 멀지 않은 시기에 규제가 완화될 거라고 생각은 합니다만 "물리적인 망 분리"라는 규제를 지키려면 설치형 솔루션을 사용해야 합니다. 많은 도구들이 이 요구사항을 만족하지 못했습니다. GitLab은 이런 요구사항을 만족했으며, 기능도 충분했습니다.
2단계 : DevSecOps로 기술기반 마련
- DevOps는 지속적으로 탐색 → 개발 → 적용 → 모니터링 → 탐색 사이클이 반복되면서, 발전하는 것
- GitLab으로 만든 파이프라인으로 중반은 기술기반을 확보함
- 보안 영역의 파이프라인 예시로 보안 조직은 고유의 보안정책들과 시스템들을 가지고 있음
- DevOps 활동가는 보안조직, 개발조직, 인프라 운영 조직과 함께, 보안 정책을 만들고, 이 보안 정책들을 코드화
- 정보보안 정책이 작동해야 하는 변경사항이 발생하면, GitLab은 자동으로 각 보안 솔류션들을 통과 시키면서 정책을 잘 지키고 있는 지를 검토
- GitLab으로 이러한 일을 할 수 있는 이유는 IaC를 통해서 인프라/네트워크/계정 권한 정보들이 모두 코드 화되어 있기 때문
- 서비스 포트를 오픈하게 되면, 인프라코드가 변경됨, GitLab은 서비스 포트를 오픈하는 작동을 하기 전에, 네트워크 정보가 변경됐다는 것을 알리게 되고, 네트워크 변경은 실패하게 됨
DevSecOps 구축으로 얻은 것
업무 협업 관점(조직간 정보 공유)
- 자산을 많이 가진 회사에서 애자일, DevOps 성공의 키는 리더십에 있음.
- 리더십 측면에서 애자일, DevOps, 클라우드의 가치에 적극 동의 하면서 벨류 스트림을 원할히 전달하기 위한 조직 체계를 만드는데 많은 노력 수행함.
- 처음에는 교육 부터 시작했었고 그 다음 세미나, 시연이 있었으며 실제 프로젝트를 DevOps 방식으로 진행하면서 안착
개발 관점
- 먼저 인프라가 코드화, 테라폼을 이용해서 레퍼런스 아키텍처를 코드화
- 개발자가 원하면, 2-3일 안에 시스템/네트워크/K8s/로깅/모니터링/데이터베이스/계정정책/보안정책 이 반영된 인프라가 제공
- 지금은 데이터 파이프라인도 코드화를 진행 중
- 개발자는 가치의 구현에만 집중 할 수 있게 됐습니다. 기다리는 시간이 사라졌고, 코드 이외의 다른 것들을 위임할 수 있게됨
이번 웨비나에서는 금융권의 DevSecOps 관련된 배경과 큰그림을 확인 했습니다. 다음에는 Biz / Dev / Sec / Ops 영역의 실제 Before & After에 대한 인사이트를 볼 수 있기를 기대 하고 있습니다. 테크니컬한 부분을 포함하여 말이죠. :)
인포그랩은 웨비나 발표를 지원합니다.
GitLab과 DevOps에 대한 온라인 세미나, 인사이트를 공유 해주실 분이 있다면 언제든 dexter@infograb.net 으로 메일 보내주세요. 언제든 환영입니다.