아이티랩 - “마이크로서비스, 이젠 흐름이 아니라 필수”

지난 20여년 동안 다양한 IT 개념이 뜨고 사라졌다. 1990년대엔 개발 과정이 위에서 아래로 향하는 ‘폭포수 모델’(워터 폴)이란 개념이 유행이었다. 2000년대엔 ‘IT 중앙집중화’란 개념이 등장했다. 조직 안에서 어떤 부서가 무슨 일을 전문적으로 담당하는지 구분했다.

2008년 들어서면서 ‘클라우드’란 개념이 등장했다. 구글, 아마존 등 새로운 IT 거인이 나타나면서 많은 변화가 일어났다. 모바일을 비롯해 인터넷에 연결된 기기가 늘어나고 다양해졌다. 빠르게 변화하는 사업에 더 민첩하게 대응할 방법에 대한 고민은 커져갔다. 중앙에서 모든 서비스를 통제하는 방식은 모바일과 클라우드 시대에 맞지 않았다.

“마이크로서비스 아키텍처, API(애플리케이션 프로그래밍 인터페이스)에 대한 중요성이 높아진 이유입니다. 서비스를 목적에 맞게 쪼개 개발하는 방식을 통해 더 빠르고, 더 신속하게 비즈니스에 대응하기 위해서죠.”

마이크로서비스·API 분야의 구루인 마이크 아문센 CA API 아카데미 API 아키텍처 담당 이사는 왜 마이크로서비스 아키텍처에 대한 관심이 높아지고 있는지를 설명했다.

마이크 아문센 CA API 아카데미 API 아키텍처 담당 이사

마이크 아문센 CA API 아카데미 API 아키텍처 담당 이사

googletag.cmd.push(function() { googletag.defineSlot('/6357468/0.Mobile_Article_intext_1_300_250', [300, 250], 'div-gpt-ad-1468307418602-0').addService(googletag.pubads());googletag.pubads().collapseEmptyDivs();googletag.pubads().enableSyncRendering();googletag.enableServices();googletag.display('div-gpt-ad-1468307418602-0'); });

마이크로서비스 아키텍처는 소규모 서비스를 독립적으로 운영하는 방식을 말한다. 애플리케이션 구성요소를 특정 목적별로 쪼갠 뒤 독립적으로 작동하도록 극소형 서비스로 만들고, 여러 극소형 서비스를 조합해 완성된 애플리케이션으로 조립하는 개발 방식이다.

이 방식을 도입하면 전체 애플리케이션의 새로운 버전이 나올 때까지 기다릴 필요 없이 새로운 기능을 지속해서 출시할 수 있다. 애플리케이션 개발·구축·업그레이드 방식을 완전히 변화시킨다. 민첩성에 중점을 두고 변화하는 시장에 발맞춰야 하는 기업에 유용하다.

이런 방식을 가장 잘 활용한 곳이 넷플릭스와 아마존이다. 두 회사는 마이크로서비스 아키텍처를 도입해서 프로젝트를 수행했다. 하나의 서비스를 구성하는 코드는 짧고 간결하게 작성됐다. 개별적으로 존재하는 듯하면서도 서로 조화를 이룰 수 있는 형태로 서비스를 구성했다. 레고와 같은 모습으로 시스템을 구성했다고 보면 된다. 각 레고는 하나의 기능을 가지고 있고, 이 레고를 잘 엮어 시스템을 운영하면서 넷플릭스와 아마존은 안정성과 민첩성이란 두 마리 토끼를 잡았다.

“마이크로서비스 아키텍처에서 핵심은 API입니다. API가 있어야 속도를 낼 수 있지요. 민첩성을 발휘할 수 있습니다. API는 서비스 간 연결고리라고 보면 됩니다. 민첩성을 높이려면 API가 있어야 하죠.”

단순히 마이크로서비스 아키텍처를 도입한다고 해서 각종 변화에 민첩하게 대응할 순 있는 건 아니다. 아문센 이사 설명에 따르면, API가 뒷받침돼야 한다.

API는 하나의 서비스를 다양한 기기와 연결할 수 있게 해주는 역할을 맡는다. 마이크로서비스 아키텍처가 레고 블록이라면, API는 각 레고 블록의 조립을 돕는 일종의 돌기다. 개발자가 만든 서비스를 윈도우폰, 안드로이드폰, 아이폰 등 모바일 기기부터 시작해 냉장고나 토스트 기기와도 연결할 수 있게 돕는다.

“전세계적으로 많은 기업, 넷플릭스, AWS 등에서 마이크로서비스 아키텍처에서 API를 구축할 때 공통으로 3가지 원칙이 지켜지는 걸 볼 수 있었습니다. 로우 코드 서비스, 검색이 쉬운 API, 보안 입니다.”

아문센 이사는 API는 비용이 저렴하게 안전하게 만들 수 있어야 한다고 강조했다. 과거와 달리 지금은 AWS 람다 서비스나 CA에서 제공하는 API 크리에이터 툴을 이용해 간편하게 만들 수 있다. 이렇게 만든 API는 쉽게 찾아서 사용할 수 있을 정도로 색인화가 이뤄져야 한다. 보안도 빼놓을 순 없다. 코드 중심이 아니라 회사 정책 중심으로 보안 규정을 만들어 운영하는 게 필요하다.

코드가 아닌 정책 중심으로 서비스가 운영돼야 하는 이유는 서비스 개발 후 어떤 일이 벌어질지 알 수 없기 때문이다. 마이크로서비스 아키텍처가 일종의 도로다. 도로를 만들 땐 어떤 자동차가 이 도로 위를 달릴 지 모른다. 그저 목적지로 가기 위해 다양한 자동차가 도로를 이용할 것이란 걸 추측할 뿐이다. 승용차가 달릴 수도, 버스가 달릴 수도, 화물차가 도로를 이용할 수 있다. API는 이 도로 위를 달리는 일종의 자동차다. 도로를 달리면서 각 서비스를 연결한다.

“여기서 어려운 점은, 존재하지 않는 API를 위해 인프라를 만들어야 한다는 겁니다. 불확실한 미래를 생각하면서 도로를 만들어야 하지요. 코드 하나에 일희일비하면서 시스템을 운영하면 안 되는 이유이기도 합니다.”

아문센 이사는 현재는 기능과 성능 중심으로 마이크로서비스 아키텍처와 API가 운영되지만, 머신러닝 기술이 발전해 기계와 사람이 대화할 방법이 늘어나면 그때는 또 다른 방법이 필요하리라 전망했다.

“현재는 기능 중심으로 얘기하는 편입니다. 앞으로는 기능이 아니라 어떤 언어나 메시지 중심으로 서비스가 변하지 않을까 생각합니다. 머신러닝, AI, 딥러닝 등을 좀 더 쉽고 빠르게 적용할 수 있는 기능이 등장해 개발자가 이를 활용하지 않을까 생각합니다.”

의견 0 신규등록      목록