칼럼 | 모놀리틱의 '실패 공식', 마이크로서비스의 '성공 방정식'

데이터가 기업의 건강성을 관리하고 지속적인 성장을 유지하는 데 필수적이라는 사실은 아무리 강조해도 지나치지 않다. 그러나 여기서 '데이터'는 단순하게 저장하고 사용하는 것만 의미하지 않는다. 데이터의 품질과 일관성을 보장하기 위해 이를 체계적으로 저장하고 시스템화하는 것까지 포함한다. 이는 데이터 활용을 확장하는 데 가장 필요한 요소이기도 하다.
 

이런 목표를 달성하기 위해 노력할 때 기업이 자체 플랫폼을 구축하면 더 전체적인 시각을 확보하는 데 큰 도움이 된다. 즉, 모놀리틱(monolithic) 방식의 획일적인 직접 데이터 접속에서 마이크로서비스로 전환하는 것이다. 그러면 데이터와 워크플로우가 정확히 일치하도록 할 수 있고 여러 애플리케이션에서 이 마이크로서비스를 재사용할 수 있다. 신중하게 워크플로우를 개발해 장기간에 걸쳐 더 강력한 데이터를 제공하고 작업을 간소화하는 것도 가능하다. 심지어 마이크로서비스 플랫폼은 기업에 새로운 성장의 기회를 제공할 수도 있다.
 
낡은 방식의 폐해
현재 오래된 구식 인프라스트럭처에서 업무를 처리하고 있다면, 데이터 사일로가 확장의 발목을 잡는 것은 물론 기업의 건강성을 관리하는 데도 방해가 될 가능성이 크다. 동시에 플랫폼 속도를 개선하고 새로 구축할 때도 너무 큰 비용과 시간이 소요될 수 있다. 당연히 이런 작업에는 시간이 필요하다. 그러나 마이크로서비스 플랫폼을 만들면 장기적으로 '배당'을 챙길 수 있다. 오히려 이를 만들지 않으면 분명한 '비용'을 치러야 한다.
 
필자는 이러한 플랫폼 투자를 결심한 기업에서 일한 경험이 있다. 처음부터 새로 만드는 프로젝트도 경험했다. 이를 통해 내린 필자의 결론은, 많은 기업이 프로젝트를 시작한 후 핵심 애플리케이션 하나를 근거로 성공했다고 자평하는 경우가 종종 있다는 사실이다. 이 주력 앱은 핵심 고객과 관련된 주요 업무를 처리해 결과적으로 빠르게 기업 업무 프로세스에 스며든다. 정말 성공한 것처럼 보인다. 그러나 장기적으로 이 앱의 백엔드 시스템이 커지면서 데이터를 관리하거나 이를 기반으로 보고서를 만드는 것이 점점 더 힘들어지게 된다.
 
이쯤 되면 기업은 다른 애플리케이션을 또 만드는 것을 고민한다. 새로운 데이터 세트로 지원하지만 결국 같은 데이터베이스를 사용하는 그런 애플리케이션이다. 이제 데이터 사일로 문제가 본격적으로 불거지기 시작한다. 그러면 기업은 더 노련한 데이터 애널리스트를 채용하는 데 사활을 걸게 된다. 데이터 정합성과 ETL을 만드는 작업이 더 복잡하고 어려워졌기 때문이다. 그러나 결론적으로 이는 데이터 확장성을 확보하는 좋은 접근법이 아니다. 애플리케이션에 작은 변화가 있을 때마다 보고서 작업에서 오류가 발생할 수 있다.
  
더구나 비즈니스 솔루션이 복잡해질수록, 간접 접속이 늘어나고, 더 복잡한 데이터 통합 솔루션이 필요해진다.  이렇게 되면 가장 좋게 표현해도 기업의 건강성에 대한 '가시성이 떨어지게' 된다. 데이터가 수많은 애플리케이션에 분산돼 있기 때문이다.

연쇄 부작용을 피하는 방법
때때로 파괴는 시작을 위한 좋은 출발점이 된다. 어떤 의미에서 파괴란 변화를 위한 신호다. 그러나 기업 인프라에서 한 시스템을 바꾸면 모든 것이 영향을 받고 심지어 어떤 것이 영향을 받는지 모를 수도 있다. 어떤 앱이 데이터베이스에서 데이터를 가져오는지 파악하기도 힘들기 때문이다.

이럴 때 가능한 빠르게 플랫폼을 만들면 데이터에 대한 접근을 중앙화하는 API를 통해 이런 문제를 피할 수 있다. 이렇게 되면 직원이 웹 애플리케이션을 관리, 수정하는 시간을 줄일 수 있다. 애플리케이션의 기반이 되는 시스템을 개선하는 데 더 많은 시간을 쏟을 수 있다.

마이크로서비스 플랫폼을 구축하면 사람들이 임의의 SQL 선언을 실행할 필요가 없어진다. 모든 시스템이 중앙의 단일 위치에 저장된 유효한 객체와 상호작용하도록 유효하지 않은 데이터 입력을 막을 수도 있다. 예를 들어 배송 API를 만들어 두면 배송 부서와 송달 부서가 이를 이용해 필요한 애플리케이션을 개발할 수 있다. 또한, 모놀리틱 애플리케이션을 마이크로서비스로 쪼개면 이들 서비스에 데이터베이스 접속권한을 나눠줄 수 있다. 이는 백엔드시스템의 부담을 줄이고 성능 저하를 막는 데 매우 중요하다. 이들 API를 이용해 기존 자사 제품을 보완하는 혁신적인 애플리케이션을 만드는 외부 개발자에 접속권한을 주는 것도 가능해진다. 

대표적인 사례가 필자가 참여했던 스퀘어(Square)의 PoS API였다. 당시 우리는 같은 서비스를 사용하는 모든 PoS에서 결제할 수 있도록 이 API를 이용한 애플리케이션을 개발하고 있었다. 그리고 최종적으로 디지털 택시 애플리케이션, 키오스크 등 다양한 PoS를 사용하는 서드파티 개발자가 이 API를 활용하는 방식으로 목표를 달성할 수 있었다. 당시 스퀘어가 투자할 여력이 없었던 특정 업계에서도 스퀘어를 사용할 수 있게 됐다. 이처럼 마이크로서비스 플랫폼을 만들면 고객에게 완전히 다른 방식으로 서비스할 수 있다. 독립적으로 사용하면서 동시에 완전히 새로운 애플리케이션 내부에 연결할 수 있는, 이른바 '분리된 컴포넌트'의 위력이다.
 
어떻게 어디서 시작해야 할까
일단 마이크로서비스 플랫폼을 만들기로 결정해도 여전히 어려운 부분이 남아 있다. 바로 어디서 시작할 지 결정하는 일이다. 일반적인 방법은 내부 시스템을 감사해 전체 애플리케이션을 포괄하는 데이터에 대한 단일 접속 API를 만드는 '계획'을 수립하는 것이다.

특히 가장 먼저 전환해야 할 애플리케이션 관련 작업은 쉽지 않을 것이다. 시행착오를 겪을 수도 있다. 따라서 기업용 핵심 애플리케이션이 아닌 것, 기업 활동이 가장 치명적이지 않은 것부터 시작하는 것이 좋다. 정기적으로 자주 쓰는 애플리케이션이나 워크로드를 전환하고 싶은 생각도 들겠지만, 역시 첫 시작으로 잡는 것은 좋은 생각이 아니다. 작은 팀으로 우리 회사에 맞는 가장 좋은 개발 프로세스를 익히고 이 팀이 다른 팀을 훈련하도록 하는 것이 좋다.

이렇게 시작한 이후에 비로소 로드맵을 만들 준비가 된 것이다. 고객의 요구와 우리 기업의 핵심 역량이 교차하는 곳을 찾아 우리 회사에 맞는 플랫폼을 정의하면 된다. 이를 통해 기존의 업무를 간소화하는 것은 물론 고객에도 같은 가치를 돌려줄 수 있다. 이는 기업의 성장에도 장기적으로 긍정적인 효과를 가져올 것이다 ciokr@idg.co.kr