미국의 금융 시장은 4-5년전 까지는 한국과 유사한 상황이었다. “소프트웨어가 세상을 지배하고 있다”는 말이 나온 것이 2010년여경, 그리고 JP Morgan의 회장이 “실리콘 밸리 사람들이 온다”고 말한 것이 2015년임을 생각해 본다면 기술 기업과 종전의 엔터프라이즈 기업이 소프트웨어의 중요성에 인식한 시간이 그 정도 차이가 난다고 볼 수 있다.
◇ 글로벌 기업의 대처법
JP Morgan을 비롯하여 모건 스탠리, 시티 금융 그룹, 웰스 파고 및 스코티아 은행 등은 이미 수년 전부터 소프트웨어 역량 강화에 총력을 기울이고 있다. 소프트웨어 기술 관련 역량을 강화해야 한다는 핵심 사상에는 세 가지 변화가 작용한다. BaaS(Banking as a Service), Open API 와 같은 사업적 목표를 기반으로 FAANG이 사용하고 있는 기술력을 내재화 하고 있다. 이 내재화를 수행하는 방법은 일부 공통적인 부분이 있는데 아래와 같다.
• 장기적 목표로 메인프레임이나 유닉스와 같이 변경이 힘들고 안정성이 낮은 부분을 대체한다.
• 차세대와 같은 빅뱅의 방식이 아닌 작은 부분부터 하나씩, 검증된 성공을 바탕으로 확장한다.
• 소프트웨어 인력 확보에 소프트웨어 인력을 사용한다.
공통적인 요구사항은 서비스의 안정성을 높게 유지하면서도 고객 피드백을 빠르게 반영하는 것이다. 이 두가지는 서로 상충하는 것이었지만, 최근의 인터넷 관련 기술은 그렇지 않다.
대부분의 글로벌 금융회사의 접근 방식은 일단 현재의 시스템에 심각한 변경을 가하지 않는 것이다. 변화가 필요하다고 해도, 현재 기업의 생명과 같은 부분을 한꺼번에 들어내고 새로운 시스템으로 교체하는 것과 같은 방식은 취하지 않는다는 것이다. 대신 웹이나 모바일 채널과 같은 변화가 자주 필요한 부분과 기존에 동작하는 시스템 사이에 API 로 구성된 새로운 구간을 추가한다.
즉 엔드 유저가 직접 대면하는 채널, 웹이나 모바일 채널은 변화가 자주 발생해야 한다. 하지만 금융에 필요한 주요 서비스들은 로직이 자주 변경된다고 보기 힘들다. 대출 심사나 계좌 이체를 위한 동작들은 한번 만들어지면 자주 바뀌지 않는 것이지만, 이 서비스들을 사용하는 방식을 먼저 변경한다는 것이다.
전문 통신 기반의 방법에서 API 기반의 통신으로 전환하는 방법을 취하고, 이 API를 사용하도록 웹과 모바일 채널 구조를 변경하는 것이 일반적인 접근 방법이다. 이때 API를 제공하는 서비스들의 주요 역할은 뒤로는 종전의 시스템과의 인터페이스를 하고, 전면의 웹과 모바일에는 API를 통해 이 인터페이스를 사용할 수 있도록 한다.
이때 새로 만들어지는 API 부분에 FAANG(페이스북, 아마존, 애플, 넷플릭스, 구글)이 사용하는 클라우드 기술을 사용한다. 먼저 더 많은 소프트웨어 역량을 조직에 수혈하려면 더 범용적인 기술을 사용해야 하므로, 유닉스나 메인프레임 대신 x86 기반에 오픈소스 도구들을 사용한다.
빅뱅의 방식이 아닌 장기적 목표를 두고 하나씩 API로 전환한다는 점에 주목할 필요가 있다. 그리고 이런 전환의 과정에서 종전의 시스템 역시 그대로 유지되므로 그 위험 부담이 낮다. 먼저 전환이 필요한 기능을 선정하고, 위의 방식으로 구현한다. 여기에는 애자일, TDD, BDD, CI/CD, 그리고 MSA와 같은 방식이 적용된다.
처음 하나의 기능이 API로 전환되고, 잘 동작하는 것이 확인되면 그 다음 기능으로 이동한다. 이때 처음 기능을 만들었던 팀은 계속 그 기능의 유지와 보수에 집중하는 대신, 이들이 수행했던 방법을 다른 기능을 만들면서 추가된 인력이 전수 받는다. 처음에는 자산 관리 부분에 하나의 기능을 추가하는 방식으로 적용했다면, 새로운 팀이 대출 관련 기능을 개발하고 유지한다.
이런 방식으로 하나씩 기능들을 늘려가다 보면 어느 샌가 대부분의 금융 관련 기능들이 API 기반으로 전환된다. 그리고 각 API를 담당하는 기능, 즉 서비스를 유지하는 팀이 확보된다.
2년여 정도가 성공적으로 동작했다면 이미 메인프레임이나 유닉스의 상당 부분에 오프로딩이 발생하고 있을 것이다. 너무나 중요해서 절대 종료할 수 없었던 시스템들의 중요성이 단계적으로 낮아지고, 캐싱을 비롯한 다양한 마이크로서비스 관련 기술들이 적용된 구간이 존재하기에 서비스는 보다 변화에 유연하고 장애에 견고하다. 어쩌면 일부 기능은 메인프레임이나 유닉스 시스템이 중단되더라도 계속 서비스를 이어갈 수 있을 것이다.
아마 Unix to Linux 라는 U2L에 대한 언급, 그리고 상용 소프트웨어의 오픈 소스 전환에 대해 한번쯤은 검토했을 것이다. 상술한 방식을 통해 글로벌 금융 기업들은 점차 FAANG에 대한 내성과 경쟁력을 확보하고 있으며, 경우에 따라서는 애플 카드와 같이 API 제공을 통한 협업 모델을 만들기도 한다.
금융 서비스의 API 전환은 많은 것을 의미한다. API전환은 생태계로의 진입 또는 생태계의 생성과도 맞닿아 있다. 금융 회사의 서비스가 API를 통해 안전하게 제공될 수 있다면 이를 사용하는 대상은 비단 자사의 웹과 모바일 채널만이 아니라 다양한 핀테크 기업 또는 FAANG으로부터의 직접적인 협력을 이끌어 낼 수도 있을 것이다.
◇ 변화의 시작과 적용
시작은 올바른 파트너의 선정에 있다. 아마 많은 컨설팅 기업과 종전의 하드웨어 벤더들이 이런 종류의 전환에 대해 언급할 것이다. 하지만 가장 중요한 것은 바로 소프트웨어 역량이다. 실제 동작하고, 안전한 소프트웨어 코드를 작성할 수 있는 기술이 있는가의 여부가 첫 번째 선택 기준이 되어야 할 것이며, 두 번째는 내재화의 수행 방법, 세 번째는 언급된 서비스의 결과가 문서인지 동작하는 소프트웨어 서비스인지를 판가름 해야한다.
다양한 사례를 함께한 피보탈의 경험에 비추어 볼 때, 다음과 같은 요인들이 중요하게 작용했다.
• 작은 규모의 그러나 적절한 대상의 기능을 선정해야 한다.
• 내재화를 수행할 내부 인력의 선정에 호기심과 이타심이 있는 사람들로 구성해야 한다.
• C 레벨의 후원이 필요하다.
보통 프로즌 미들(Frozen middle)로 불리는 현상은 시장 환경의 전환에 따른 사업의 변화와 적용에 대해 C레벨과 실무를 처리하는 사람들은 이해하고 있지만, 그 변화를 수용하기 보다는 거부하는 사람들을 의미한다. 이들은 배움 보다는 현상 유지에 보다 관심이 있으며, 처음에 설득되는 형태의 인력은 아니다. 따라서 새로운 프로젝트에 대한 성공의 동기가 약하며, 소프트웨어 내재화를 위해 비용을 지불한 파트너를 SI 로 생각하는 경우가 많다. 프로젝트가 종료되고 나면 남은 것은 파트너사에 의해 만들어진 소프트웨어와 이들의 프로젝트 수행 결과에 대한 불만 뿐이다.
또한 처음에 너무나 거대한 프로젝트 또는 너무나 핵심적인 기능을 대상으로 한다면 성공의 가능성이 낮다. 프로즌 미들의 위치에 있는 인력들의 변화에 대한 저항이 더 거세질 것이다. 이들의 저항을 유발하는 대신 장기적으로 설득의 대상으로 만들려면 성공이 필요하다. 기능이나 서비스를 API의 방식으로 전환하는 작업을 자주 성공해야 한다. 그러기 위해서는 적절한 규모의, 하지만 매우 공통적으로 자주 사용되는 기능을 선택할 필요가 있으며, 이를 통해 새로운 변화에 설득되는 인력의 규모를 확장해야 전사적인 전환을 이루어 낼 수 있다.
C레벨의 후원은 매우 중요하다. API나 오픈소스 사용 등은 특히 종전의 금융에서 가지고 있는 업무 프로세스와 밀접한 관련이 있다. 전환의 성공을 위해서는 이런 종전의 법무, 보안, 배포, 운영과 같은 다양한 조직과 협상이 필요하다. 이 협상을 위해서 초기의 작은 팀이 작은 성공을 이루려면 지원이 필요하다.
◇ 클라우드 관련 소프트웨어 기술
첫 번째로 언급하고 싶은 것은 애자일이다. 대부분의 애자일 프로젝트나 신규 서비스 구성에서 쉽게 간과하는 것은 이것이 소프트웨어가 결과물이라는 점이다. 실패하는 애자일 관련 프로젝트들을 살펴보면 소프트웨어 역량이 충분하지 않은 상태에서 애자일 코칭을 통해 프로세스만 적용해 보는 경우다. 이런 상태의 결과물에 대한 경험은 보통 “애자일은 작은 프로젝트에서만 유효하다” 또는 “애자일은 스타트업에서만 동작한다” 와 같은 오해들이다.
애자일은 스프린트가 아니라 마라톤이다. 소프트웨어의 규모가 기하급수적으로 증가하더라도 변화를 적용할 수 있는 속도에 대해 사업에서 예측 가능해야 한다는 것이다. 어떤 기능의 추가에 대해 얼마의 시일이 소요되고, 얼마의 인력이 일하면 결과가 나온다에 대해 과거의 경험을 바탕으로 예측 가능해야 하며 ,이 예측에 사용되는 총합이 예상 가능해야 한다는 것이다.
핵심은 500개의 구현 스펙이 있으면 500개를 5년동안 개발하는 것이 아니라, 중요한 것 부터 1개, 또는 여러 개의 연관이 있는 기능들을 구현하고 배포해서 사용자의 피드백을 주단위로 활성화 하는데 있다.
현대의 차세대처럼 외부 업체를 고용해서 500개의 스펙을 전달하고 5년을 기다리는 동안 시장이 변화하지 않을 리 없으며, 당연히 시장의 변화에 대한 요구를 수용하려면 스펙의 변경이 필요하고 이 스펙의 변경은 다시 5년을 6년으로 만드는 지름길일 것이다.
두 번째는 클라우드에서는 사업 가치를 위해 사용했던 종전 기술이 많이 변화 된다는 점이다. 예를 들어, 만약 여러분의 서비스를 제공하고 있는 여러 구성 요소 중 데이터베이스를 종료한다면 무슨 일이 벌어질 것인가 생각해 보길 바란다.
많은 회사들은 이를 위해 재난 복구(Disaster Recovery)라는 방식을 도입하고 있다. 재해 복구로 알려진 RTO, RPO등의 KPI를 가진 이런 시스템들은 상당한 비용을 요구한다. 대부분 현재 존재하는 시스템을 그대로 복제해서 다른 지역에 두는 형태이기 때문이다.
하지만 막상 이 시스템을 테스트하는 사례는 본 적이 별로 없다. 재해 복구 시스템을 테스트 하려면 재해를 발생시켜야 하는데, 이 재해를 발생시키면 어떤 일이 벌어질지 보통 모르기 때문이다. 지금 당장 DR 담당자에게, 우리 데이터베이스를 종료하면 어떤 일이 벌어지나요? 하고 물어보면 그 동작을 확신할 수 있는 경우는 거의 없다.
현대의 기술에서는 이런 부분을 담당하는 것을 ‘카오스 엔지니어링’ 이라고 칭한다. 즉 혼란을 선제적으로 발생시켜 어떤 일이 발생하는지 자세하게 살피고, 이 경험을 통해 서비스를 점진적으로 강화해 가는 것이다. 극단적인 예로는 서비스중인 데이터베이스를 종료해도 서비스가 정상적으로 동작하는지 보는 것이다. 어떤 경우에는 데이터센터 전체를 종료하기도 한다.
물론 이런 것들을 한순간에 즉시 적용할 수는 없다. 하지만 앞서 언급한 바와 같이, API를 제공하는 새로운 구간에는 이와 같은 기술을 도입함으로서 서비스 시스템의 실제적 안정성을 확보할 수 있게 된다.
마지막 세 번째는 오픈 소스 기술의 사용이다. 사업적 가치 측면에서, 위에서 언급한 가치들을 충족하기 위해서는 종전의 상용 벤더가 제공하는 패키징 제품으로는 비용 충당이 불가능하다. 분산 데이터베이스 기술에서 주로 사용하는 널리 알려진 샤딩과 같은 기법에 수 억원 하는 데이터베이스를 수 백대 배치할 수는 없는 일이다.
하나의 시스템에 중요 기능을 집중하지 않고 여러 대의 시스템에 기능을 분산하는 것이 분산 시스템의 핵심이다. 따라서 그 확장의 방법이 숫자의 추가이기에, 수량의 증가에 따른 엄청난 비용 부담을 감내해야 하는 메인 프레임 또는 유닉스 기반의 시스템들은 이런 새로운 기술의 적용 대상이 아니다.
하지만 주의할 것이 있다. 현재 동작하는 서비스는 해당 시스템의 성능을 기반으로 만들어진 것들이라는 점이다. 따라서 이 시스템에서 동작하는 것들을 한꺼번에 오픈소스로 전환하는 시도는 가능하지도 않으며 동작하지 않은 매우 위험한 방식이다.
따라서 앞서 언급한 바와 같이 적절한 기능을 선정하고, 올바른 파트너를 구해 동작하는 소프트웨어 기반의 API 서비스로 한번에 하나씩 떼어내야 한다. 1만개의 테이블을 운용하는 데는 아마도 현재의 시스템이 가장 좋은 성능을 내겠지만, 만약 1개에서 수개의 테이블만을 운용하고 유지하는 데는 오픈소스를 사용할 수도 있을 것이며, 이것이 전환에서 중요한 부분을 차지한다.
◇ 중단없는 서비스를 위해
작은 것부터 하나씩 시작해서 복제의 방법을 통해 소프트웨어 인력의 확보와 이들이 개발하고 운용하는 서비스가 고객의 요구를 만족하며 고객이 언제나 접근해서 사용할 수 있도록 해야 한다. 소프트웨어의 패치가 너무 어렵고, 새로운 기능과 코드가 어떤 영향을 미칠지 영향 분석에 여섯 달씩 사용하는 것은 예전에는 맞고 지금은 틀린 방법이다.
한국의 우편번호 체계가 6자리에서 5자리의 집코드(zip code) 방식으로 변경될 때, 이 변경이 가장 빨리 적용된 곳이 아마존이었다. 실로 놀라운 일인데, 한국에 사는 한국 사람도 모르는 정책 변화를 이미 서비스에 온라인 상태로 적용한 것이다. 초당 상상할 수 없는 규모의 검색과 조회가 발생하고 수백 개의 물건을 팔고 있는 트랜잭션이 발생하는 서비스에서 소리소문 없이 필요한 기능을 적용하는 것이다.
금융을 비롯한 많은 엔터프라이즈 서비스에서 이런 기술을 적용하고 싶지만 현실적 다양한 요인으로 성공사례보다는 실패 사례가 더 많이 보인다. 이들이 반증하는 것은 실패를 경험했기 때문에 중단할 것이 아니라, 직접 자사만의 역량으로 부족할 수 밖에 없는 것이 소프트웨어 기술임을 인지하고 올바른 파트너를 선정하여 작은 규모부터 하나씩 성공해 내는 것이 중요하다는 것이다.
클라우드 네티이브건 데브옵스건 무엇이건 질문은 간단하다. 우리의 서비스는 데이터베이스를 지금 종료해도 중단 없이 서비스를 지속할 수 있는 가. 만약 그럴 수 있다면 사업에서 요구하는 서비스 기능 적용도 안전하고 빠르게 적용 될 수 있을 것이다.
정윤진 yjeong@pivotal.io 피보탈 수석 테크롤로지스트(Technologist), 커널 및 드라이버 엔지니어로 경력을 시작해 15년 이상 소프트웨어/클라우드 업계에서 일하고 있다. 호스팅 관련 연구소와 글로벌 SW회사, 국내 통신사의 클라우드 개발, AWS에서 클라우드 기술 경험을 축적했다.
