마이데이터 서비스 '알다'의 MSA 구현기

최근 금융정보 기반의 기업들 사이 최대 화두는 마이데이터다. 마이데이터 사업을 하기 위해서는 기존보다 많은 데이터를 수집하고 활용하기 위한 인프라와 시스템 구축은 필수다. 그러나 인력과 기술력이 부족한 스타트업은 고민이 클 수밖에 없다. 적은 인력으로도 쉽고 빠르게 마이데이터 시스템을 위한 인프라 구축을 돕는 기술이 없을까.

마이데이터 본허가를 받은 기업 팀윙크가 이러한 고민을 반영한 자사의 노하우를 소개했다. 장상규 팀윙크 CTO는 지난 2일 진행된 바이라인플러스 ‘마이데이터 시스템 구축을 위해 필요한 기술들’ 웨비나에서 MSA(마이크로 서비스 아키텍처)를 구축한 사례를 소개했다.

팀윙크는 데이터를 기반으로 금융 서비스를 하고 있는 스타트업이다. 2018년 7월 나온 자산관리 앱 ‘알다’는 신용올리기, 대출상품 추천, 소비내역 확인 등을 서비스한다. 본격적인 사업을 위해 올 초 마이데이터 본허가를 받았다.

마이데이터 본허가를 받은 기업들은 8월 4일부터 표준API를 통해 서비스를 해야 한다. 지금까지 사용자 동의 하에 금융회사에서 정보를 긁어오는 방식의 스크래핑을 썼다면, 이때부터 정해진 규격의 API를 통해 금융정보를 주고받게 된다.

현재 본허가를 받은 기업들은 표준API 시스템을 구축 중이다. 그러나 스타트업들은 리소스 한계로 인한 어려움을 겪고 있다. 개발자 인력난이 심화되고 있는 가운데, 고급 개발자가 없거나 적기 때문에 개발 역량과 시간이 부족하다. 그러다보니 소수의 개발자들이 서비스 개발 뿐만 아니라 인프라 아키텍처 구축 등의 모든 일을 담당하고 있다.

시간에 쫓겨 많은 업무를 하다보니, 기술의 완성도가 떨어지고 이는 곧 서비스 장애와 직결될 수밖에 없다. 장상규 CTO는 “시스템이 원활하게 돌아가지 않아 업무시간이 늘어나고 결국 인력교체라는 문제가 발생한다”며 “기술부재의 문제는 인력부재로 악화되고, 전체적으로 잘 돌아가지 않는 소스만 남아있게 된다”고 지적했다.

팀윙크도 같은 문제를 겪었다. 알다 서비스는 크게 맞춤대출 찾기, 신용 올리기, 신용보고서, 자산·소비내역 조회로 나뉘며, 모널리틱한 형태의 다섯 종류의 모듈로 구성됐다. 모놀리틱은 여러 서비스들이 하나의 애플리케이션 서버 안에서 구동되는 방식을 말한다.

네 서비스는 비즈니스 관점에서 봤을 때 일련의 흐름을 가지고 있으나, 모두 독립된 모듈로 기술적으로는 연관성이 없다. 알 수 없는 장애발생 등이 이어지자, 장 CTO는 굳이 네 서비스가 하나의 모듈 내에서 구동되어야 할 필요가 없다고 봤다.

장 CTO는 “모놀리틱은 하나로 구성된 서버로 인해, 여러 가지 문제들이 복합적으로 나올 수 있다”며 “결론적으로 원인을 파악하기 어렵기 때문에 오류가 자주 발생할 수밖에 없다”고 지적했다.

특히 모놀리틱 특성상, 여러 서비스가 하나의 시스템으로 구성됐기 때문에 기술 스택을 변경할 수 없다. 라이브러리를 교체할 경우 파장이 여러 군데에서 발생하기 때문에 개발 생산성을 저하시킨다는 설명이다. 결국 문제를 해결하기 위해 코드를 새로 짜거나, 기존 소스를 복사해야 한다. 하지만 이 마저도 코드가 늘어나고 문제 해결이 어렵다는 단점이 있다.

그래서 팀윙크가 선택한 것이 MSA다. MSA는 잘게 쪼개진 모듈(마이크로서비스)를 연결해 전체 시스템을 구현하는 방법이다. 따라서 서비스의 동시 접속자가 급증했을 때 전체적으로 스케일아웃을 할 필요 없이 필요한 마이크로서비스만 할 수 있다. 또 장애가 발생했을 때 해당 마이크로서비스만 조치하면 되는 장점이 있다.

이러한 효과로 아마존, 넷플릭스, 왓챠, 페이코, 카카오 등 사용자가 많은 서비스 기업에서 MSA를 채택했다. 알다 역시, 시스템 특성에 맞게 MSA를 도입했다.

그렇다면, 모놀리틱 서버와 MSA의 가장 큰 차이는 무엇일까. 장 CTO는 ‘MSA의 독립성’을 꼽았다. 그는 “기존 모놀리틱 아키텍처의 경우, 모든 비즈니스 로직이 한 서버 안에서 하나의 데이터베이스(DB)로 동작하는 구조”인 반면, “MSA는 각 서비스 별로 분리되어 있으며 독립된 DB를 보유하고 있다”고 설명했다.

따라서 장애가 발생했을 때 전체 시스템에서 문제를 찾아야 하는 모놀리틱스와 달리, MSA는 특정 부분의 문제만 해결하면 되기 때문에 간단명료하다.

그러나 팀윙크는 곧 현실적인 문제에 직면했다. 개발자 인력난이 심각한 가운데 마이데이터에 대응이 쉽지 않았기 때문이다. 소수의 개발자들이 알다 서비스를 고도화하는 동시에 모놀리틱에서 MSA로 전환하는 일을 해야 했다.

고심 끝에 팀윙크는 꼭 필요한 것에만 집중했다. 필요한 데이터만 마이그레이션을 하고, 필요없는 데이터는 과감하게 버리는 전략을 취했다. 장 CTO는 “MSA로 전환할 때 전부 다 만들기보다 할 수 있는 것을 하나씩 적용하고 점진적으로 고도화하는 전략으로 정했다”고 전했다.

팀윙크가 기존 레거시 시스템에서 MSA를 전환하기 위해 가장 먼저 한 작업은 앱에서 유입되는 엔드포인트를 API 게이트웨이로 통일한 것이다. 그런 다음, 서비스 고도화를 진행해야 할 경우 레거시에서 MSA를 별도로 구축했다. 서비스가 오픈될 경우 게이트웨이가 url을 MSA의 앨라스틱 로드밸런서로 향할 수 있도록 처리했다.

장 CTO는 “고도화되는 서비스가 하나씩 늘어나다보니 레거시 기반의 서비스는 줄어들고 MSA 비율이 늘어났다”며 “게이트웨이 덕분에 순차적으로 작업할 수 있었다”고 전했다. 서비스만 따로 떼어 작업을 했다면 혼선이 있었을 수도 있으나, 하나씩 이관할 수 있는 모듈 시스템 아키텍처의 특징을 활용한 덕에 가능했다는 설명이다.

물론, 장점만 있을 수는 없다. 서버 대수가 늘어나 인프라 비용이 늘어난다. 잘못 구성할 경우 장애가 발생했을 때 조치 포인트를 찾기 어렵다. 또 데이터 중복이 발생하고, 트랜잭션 처리가 힘든 문제가 있다.

그러나 팀윙크는 MSA의 단점을 극복했다. 인프라 비용을 절감하기 위해 트랜잭션 기준으로 서버군을 묶고, 하나의 E2C 인스턴스에 여러 개의 서버를 두는 전략을 택했다. 장애포인트를 바로 식별하기 위해 ‘ELK+슬랙’에 장애 내용을 실시간으로 전파해 원인을 바로 파악할 수 있도록 조치했다. 소스를 표준화하고 개발표준을 배포해 서버간 상이한 기술 스택이 존재하지 않게 처리했다.

아울러, 팀윙크는 마이데이터 사업자가 MSA를 활용할 경우 가장 빠르게 API를 전환할 수 있다고 설명했다. 장 CTO는 “수집할 수 있는 데이터가 늘어나는 마이데이터 특성상, 기존보다 더 많은 데이터를 가공하고 적재해야 한다”며 “MSA로 전환하면 새로운 비즈니스 프로덕트를 만들기 위해 새로운 MSA 기반의 서버를 추가해 개발하기만 하면 된다”고 밝혔다.

글. 바이라인네트워크
<홍하나 기자>0626hhn@byline.network

[box type=”download”] IT기술을 활용해 기업의 비즈니스가 혁신해 나가는 소식을 주 1회 [엔터프라이즈 테크레터]에서 전해드립니다. ;여기에서 구독을 신청해주세요. [/box]