1# 데이터 엔지니어와 마이크로 서비스 구축 SI 프로젝트
본 글은 **이커머스 업체의 ERP 정산 시스템 노후화 개선** 에 대한 해결 가능성을 문의받고, 문제를 해결하기 위해 여러 자료를 분석 후 개인적인 경험과 함께 정리하여 남기는 글 입니다.
파일럿의 함정
디지털 변혁은 현재 피할 수 없는 유행어지만, SI 프로젝트를 통해 기업의 핵심 비즈니스를 변혁시키는 미션에서 성공한 케이스는 거의 없는 것으로 파악되고 있습니다.
이노베이션은 기존 방식을 유지한 채 기술만 덧붙이는 것 입니다. 트랜스포메이션은 조직운영의 모든 과정을 완전히 바꾸고 디지털화한다는 점에서 더 총체적 입니다. 비즈니스의 핵심기술과 시장 접근방식, 고객과의 관계 등을 근본적으로 바꾸는 것 입니다.
보통 기업들은 일부 사업부에서 SI 업체를 통한 파일럿 프로젝트를 통해 트랜스포메이션을 시도 합니다. 그런데 이 파일럿 프로젝트가 끝날 때쯤 경영진이 착각합니다. 한 번 해본 것으로 기업의 트랜스포메이션이 끝났다고 보고 멈춰버립니다. 그 수준을 뛰어넘지 못하고 방향을 잃어버리는 상태를 파일럿의 함정이라고 말합니다. 해외보다 국내 기업들 사이에서 소규모 파일럿 형태로 트랜스포메이션하려는 선호가 더 많은 것 같습니다.
SI 업체의 트랜스포메이션 사업 패턴
현재 대부분 국내 SI 업체를 통한 트랜스포메이션 프로젝트는 엄밀히 말해 아우터 아키텍트 포장형 또는 파일럿 프로젝트형 입니다. 필자가 겪어본 프로젝트의 유형을 살펴보면 크게 세가지가 있습니다.
아우터 아키텍트 포장형
레거시 부분의 코드는 그대로 둔 채 컨테이너, CI/CD, API-GW, 클라우드 등 외적으로 내보일 수 있는 아우터 아키텍처에만 집중하여 클라우드로 이전합니다. 운영 환경 개선에 어느정도 도움은 되겠지만 근본적으로는 리프트 앤 시프트와 다를 게 없습니다.
이 패턴은 코어 비즈니스에 관여하지 않기 때문에 클라우드 사업자 / SI 사업자가 진행 가능한 부분으로, 리스크가 적어 실패하는 경우가 별로 없습니다. 오늘날은 클라우드 기술의 발전으로 SA 1~2 명이서 수개월이면 구축 가능합니다. (Private 환경에서 구축하는 경우는 조금 더 시일이 걸립니다.)
파일럿 프로젝트 구축형
위에서 말한 아우터 아키텍트에 더해, 신규 사업을 처음부터 최신 트렌드 형태로 구축하는 파일럿 프로젝트 입니다 (그린 프로젝트라고 부르기도 합니다).
DDD(Domain-Driven) 개념을 일부 섞은 후 적절히 도메인 별로 서비스를 쪼개어 개발합니다. 파일럿 프로젝트 이기 때문에 기존 비즈니스에서 자유롭고, SI 업체 선에서 왠만한 의사결정이 가능합니다.
클라우드 사업자가 투입되어 플랫폼을 먼저 구축하고, 아키텍트가 투입되어 Spring Boot 기반의 코드 베이스 템플릿을 만듭니다. 그리고 관례대로 초,중,고급 개발자를 짧게 교육시킨 후 폭포수 형태의 관리를 시작합니다.
역시 기업의 핵심 비즈니스에 관여하지 않으니 리스크가 적고, 성공 사례도 많습니다. 적절한 한국형 SI MSA 프로젝트라고 할 수 있습니다.
기존 SI 프로젝트에서는 예측가능한 아키텍트의 반복으로 개발자들의 실력 평균화가 어느정도 되어 있었지만, 이 프로젝트는 신규 개발 패턴을 빠르게 학습한 일부 인원에 의해 거의 모든 것이 개발됩니다.
필자도 이러한 프로젝트에 가장 많이 투입 되었습니다.
여기저기 들리는 소식통들에 의하면 이 패턴의 프로젝트가 현재 국내에 매우 많습니다.
기업 관계자 입장에서는 내부 보고용으로 좋고, SI 업체 입장에서도 홍보용으로 좋습니다.
하지만 Devops 운영의 본래 목표인 운영 데이터에서 인사이트를 얻어 지속적 개선을 이룬다는 점은 고려하지 않은 모델이 많습니다. 그런 Next Model 까지 염두 해 두고 띄우는 프로젝트가 아니라, 엄연히 파일럿 프로젝트 이기 때문에 외적 모양을 갖추는 것에 집중됩니다.
이러한 파일럿 프로젝트의 끝은, 구축이 끝난 후 고객(대규모 조직) 업체의 복잡한 운영 프로세스, 엄격한 규제 및 법적 요구 사항, 경쟁력 떨어지는 구형 기술을 보유한 일부 레거시 조직과의 마찰등으로 인해 수많은 갈등을 일으키다 버려지게 되는 사례가 많습니다.
당분간은 이쪽 시장이 활발하기 때문에 SI 업체 입장에서는 빠르게 구축 할 수 있는 체계가 갖추어진다면 많은 매출을 올릴 수 있겠으나, 곧 근본적 문제를 해결해 주지 못한다는 기업 관계자들의 판단이 확산되면 몇년 가지 못할 것이란 예측이 듭니다.
스트랭글러 패턴 구축형
실제로 낙후된 레거시 시스템을 비즈니스 모델에 맞추어 점진적으로 개선 시키는 것 입니다. 원래 스트랭글러 패턴은 점진적 개선 후 실패를 통한 재조정 과정이 동반되어야 하지만, **SI 프로젝트에서 실패란 용납되지 않습니다**. 철저하게 계획 된 플랜 안에 단번에 성공하여야 합니다. 가장 많이 실패하는 유형의 프로젝트 중 하나입니다.
물론 가장 큰 실패 요인은 전통적 SI 프로젝트 진행 역량과 신규 아키텍트 진행 경험을 두루 갖춘 Right Person 의 부재 일 수 있습니다. 하지만 때론 마이크로 서비스로 전환하기 위한 방법론, 도구, Right Person 모든 것이 갖추어져도 종국에는 실패하고 마는 케이스가 많습니다.
실패 요인은 마이크로서비스 도입에서 가장 어려운 부분이고 앱의 구축 기반인 **데이터 구조를 리팩터링 해야 하는 과정** 이 이루어 질 수 없는 산업 구조이기 때문입니다.
SI 업체 주도로 정말 마이크로서비스 구축을 진행할 수 있을까?
마이크로서비스 구조에서 스트랭글러 패턴은 기존 시스템에서 점진적으로 기능을 분리 독립시켜 나아가는 것을 뜻하며, 모두가 이 방법론에 대해 말합니다. 하지만 이것은 애자일 기반 개발 문화가 정착된 곳에서 원할하게 돌아가도록 설계되어 있습니다. 필자는 한국 SI 문화에서 스트랭글러 패턴을 적용하기에는 치명적인 단점이 있다고 생각합니다.
아주 운이 좋아서, 프로젝트 진행 중 SI 업체가 데이터 혁신을 위한 모든 허들 (데이터베이스, 인프라, 네트워크, Devops 등을 포함한) 을 총체적으로 해결해야 하는 부분에 대해 같이 공감하고 있고 강력한 의지를 가진 현업을 만났다고 가정 해 봅니다.
신규 구축 프로젝트일 경우 문제될 게 없습니다. 그러나 현재 운영 중인 사업의 전환 프로젝트일 경우 이 현업이 고객사의 CEO 가 아닌 이상 현업도 굉장히 괴로운 상황에 마주하게 됩니다.
마이크로 서비스 구조에서는 데이터를 운용하는 방식이 기존 시스템과 많은 점에서 차이를 보이며, 필수적으로 대대적인 데이터 스키마 변경이 일어나게 됩니다.
- 한 시스템의 데이터를 참조하는 여러 시스템들이 존재하는 점
- 기존 시스템을 마이크로서비스 구조로 마이그레이션 하는 과정에서 기존 서비스가 계속 유지되어야 하는 점 (핵심 비즈니스 일수록 무중단은 용납되지 않습니다. 예를 들면 주문-결제-배송)
이 문제들 때문에, 많은 부분에서 의지력 있는 현업과 SI 수행 업체 모두 본질적인 문제를 회피하고 적당히 내부 구조를 협의하거나 겉모습(아우터 아키텍처)에 치중하는 선택을 합니다. 이런 점은 특히 데이터베이스 문제에서 두드러 집니다.
따라서, SI 업체의 모든 시도를 가로막는 근본적 이유인 데이터베이스 문제를 해결하지 않고서는 완전한 마이크로 서비스 성공사례를 만들기 어렵습니다.
단일 인터넷 서비스 회사처럼 고객사의 모든 이해 관계자가 서로 모여서 생산적인 설계를 하는 일은 결코 일어나지 않습니다.
우리는 성공적인 MSA 구축을 위해 어떻게 해서는 현업을 괴롭히지 않고 (기존 시스템 변화없이) 현업에서 사용중인 데이터베이스를 우리가 새로 설계한 데이터베이스 스키마로 마이그레이션 해야 하는지 답을 제시해야 합니다. 그리고 이 새로운 데이터베이스는 현업에서 일어나는 모든 트랜잭션이 항상 동기화 되야 합니다.
이 일련의 과정을 위해 우리가 하고자 하는 데이터 리팩터링 작업은 단순합니다. 매우 간단한 DMS 플로우 입니다.
기존 데이터 로드 -> 가공 -> 저장
대부분의 고객 데이터는 매우 많은 테이블에 걸쳐 관계가 형성되어 있습니다. 그리고 대부분의 경우 도메인 설계가 끝난 후의 어플리케이션 모습은 비정규화 된 Thin Database Layer (도메인 당 3~4 개 테이블) 들로 이루어져 있습니다.
테이블을 비정규화 하는 방식으로 리팩토링 하는 이야기를 꺼내는 것만으로도 많은 DB 관리자들은 신경이 곤두설 것입니다. 하지만 잠시 한 발 물러서서 애초에 데이터베이스 정규화가 왜 시작되었는지 생각해 봐야 합니다. 정규화는 중복을 없애 디스크 공간을 절약하기 위한 것이었으며, 예전에는 디스크 공간이 비쌌기 때문입니다.
그러나 이제는 상황이 달라졌습니다. 분석,집계,주문 등 실시간으로 데이터를 고객에게 전달해야 하는 응답 속도가 중요한 가치입니다. 쿼리에 걸리는 시간 최적화가 중요하며, 비정규화가 이를 달성하기 위한 직접적인 방법입니다.
실시간성 가치를 전달하기 위한 이벤트 드리븐 아키텍처에서 전달되는 데이터는 비정규화 된 데이터이며, 심플한 스키마가 필수적으로 동반됩니다.
SI 프로젝트를 통해 마이크로서비스 구조 전환이 가능하려면?
왜 이러한 일련의 데이터 가공 작업이 반드시 필요한 지 구체적인 예를 들어보겠습니다.
커머스 기업들은 다른 누구보다 현실의 문제를 해결하기 위해 디지털 트랜스포메이션 방법론을 적극 채용하는 산업군 입니다. 다음은 가상의 홈쇼핑 업체에서 일어나고 있는 문제입니다.
상품 주문의 폭주는 정말 예측하기 힘든 문제입니다.
이 기업의 테크리더들은 이미 CQRS 패턴을 알고 있기 때문에, 폭주하는 주문에 탄력성 있는 내성을 가지기 위하여 주문과 결제 프로세스를 메시징 프로세스로 바꾸는 전략을 세웠습니다. 그리고 당신의 회사는 수행 업체로 선정되었습니다.
우리 회사는 다음과 같은 문제를 해결해야 합니다.
- 기존 프로젝트를 스트랭글러 패턴으로 점진적으로 개선해야 함.
- 기존 데이터가 실시간으로 새로운 마이크로 서비스의 데이터베이스로 이관되고 있어야 함.
그런데 다음과 같은 문제 때문에 도무지 프로젝트를 이행할 수 없습니다.
- 기존 "주문" 도메인은 십 수개의 테이블에 걸쳐 참조되거나 참조되고 있고, 새로 설계한 "주문" 서비스는 정규화를 해제하고 핵심 칼럼들만으로 구성된 3개의 테이블 만이 필요하다.
- 이관해야 할 데이터는 TB 단위에 이른다.
- 기존의 클라우드 ETL 솔루션들은 단순히 칼럼 변경 을 통한 단일 테이블 단위의 데이터 이관만 진행 할 수 있다.
- 기존 "주문" 도메인의 십 수개의 테이블은 한 조직에만 관여된 것이 아니다. 각 조직과 커뮤니케이션 하고 데이터 보안등에 합의를 보기까지 일정은 늦어지고, 그만큼 비용은 증가한다. 앞으로도 이런 식으로 일이 진행 될 거라면 ROI 측면에서 프로젝트를 포기해야 한다.
이 실패 위기에 처한 프로젝트를 성공시키기 위해서 프로젝트 리더가 알아야 할 개념와 수행방법에 대해 설명하겠습니다.
오늘날 프로젝트에 투입된 개발자/개발 리더들은 모두 어플리케이션 제작 문제 (이너 아키텍트와 아우터 아키텍트) 에만 집중하고 실제 기반이 되는 데이터의 이관 및 가공에 대한 문제에 대해서는 기존 현업의 데이터베이스 관리자가 하는 일이거나, 특정 클라우드 플랫폼의 DMS(데이터베이스 마이그레이션) 툴로 해결할 수 있다고 믿고 있습니다.
현실은 그렇게 되지 않을 가능성이 큽니다.
이 복잡한 문제를 풀이하는 것에는 단일의 어떠한 솔루션이나 방법론으로 해결 가능하지 않습니다. 프로젝트 리더가 데이터 엔지니어링과 디지털 트랜스포메이션의 절차(DDD,이벤트 스토밍,도메인 어그리게이션) 에 모두 인사이트를 가지고 있어야 해결 가능한 문제입니다.
프로젝트 리더는 적어도 데이터 엔지니어링에 대한 개념과 오늘날 각 기술이 어떤 use case 에 쓰이는 지 알고 있을 필요가 있습니다. 이해를 한 이후에 문제 해결을 위한 응용 방안을 떠올릴 수 있을 것이고, 이제 자신이 처한 프로젝트 환경(고객의 조직 구조, 수행 회사의 데이터 엔지니어 리소스) 내에서 해결할 수 있는 부분인지, 포기해야 하는 부분인지 종합적으로 판단을 내릴 수 있게 될 것입니다.
다음글은 데이터 엔지니어링과 use case 에 대해 알아보고, 이어서 디지털 트랜스포메이션 데이터 마이그레이션 작업에 어떻게 응용될 수 있을지 살펴보도록 하겠습니다.