SPRi - 소프트웨어정책연구소

SW서비스의 역동적인 변화를 위한 마이크로서비스 기술

유호석산업정책연구실 책임연구원

2017.05.31

18445

글자크기

Microservices for Dynamic Change of Software Services
- 불확실한 시장환경 속에서 SW기술을 활용하여 {시제품 개발→고객반응 확인→서비스 변경}을 빠르게 반복함으로써 사업 성공률을 높이는 린스타트업 방식이 대기업까지 확산됨
- 그러나, 기존 SW서비스 기술은 사실상 전체를 한 덩어리 서비스로 구현하여, 서비스 변경 시 시스템을 셧다운하고 한꺼번에 바꿔야 하는 경우가 많아 조직 간 통합·조정 비용이 많이 드는 등 기민한 대응에 한계가 있었음
- 이의 대안으로 넷플릭스, 아마존 등은 소규모 서비스 단위로 독립성을 강화하면서도 빠른 변경이 가능한 마이크로서비스 아키텍쳐를 채택함
- 마이크로서비스는 기업 내의 경직된 기존 기술구조를 탈피하기 위해 기획 단계부터 변화를 수용하는 설계역량이 필수이며, 마이크로서비스 단위의 책임과 권한을 소규모 팀에 독립적으로 부여하는 조직구조도 뒷받침 되어야 함
- an uncertain market environment, the lean-startup strategy to rapidly repeat (prototype development → customer feedback → change of service), leading to success of a new start-up is diffusing into even large enterprises.
- However, the existing SW service technology actually implements the entire service as a monolithic structure, and when the service is changed, because it is often necessary to shut down the system and replace it at the same time, there is a limit to the agility due to the cost of integration and adjustment between the organizations.
- As an alternative to this, Netflix and Amazon have adopted a ‘microservices’ architecture that allows for rapid change while enhancing independence as a small service unit.
- Microservices require design capabilities to accommodate changes from the planning stage in order to break the rigid existing technology structure within the enterprise, it should also be supported by an organizational structure that assigns the responsibility and authority of the unit service independently to small teams.
불확실한 시장환경에 대응하는 기업의 노력
- (린스타트업) 최소기능제품(MVP; Minimum Viable Product) 를 빠르게 출시한 뒤 고객 반응을 측정해 제품을 개선하는 과정을 반복하는 데에 집중하는 경영전략
- * 사례 : GE의 패스트웍스(10명 미만 팀으로 사업가설을 검증), 구글의‘ 샌드박스’(구글X연구소), 아마존의 비즈니스모델 실험, 샤오미의 MIUI (개조된 안드로이드OS), 드롭박스 등 다수
- (애자일 개발) 사용자의 피드백을 지속적으로 받아 반복적, 점진적으로 변경하여 커다란 소프트웨어로 발전시켜 나가는 개발 방법론
- ⇒ 역동적으로 변화하는 SW서비스를 위해서 해당 전략을 뒷받침하는 조직과 기술구조의 변화 수용성이 중요한데, 안정적인 사업방식을 유지해온 중견·대기업에게는 민첩한 변화란 기술적·조직적으로 매우 어려운 문제임
기존 SW서비스 기술의 한계와 마이크로서비스의 등장
- (서비스 지향의 개념과 실제) 이론적으로는 SW서비스 단위로 유연성과 독립성을 높이는 방향으로 발전했으나, 실제로는 하나의 SW서비스가 변경되면 시스템을 셧다운하고 다른 서비스까지 조정해야 하는 구조로 구현되었음
- (서비스 지향의 개념) 기업 내 SW모듈의 재사용성을 높이기 위해 80년대 등장한 객체지향 이론이 90년대 컴포넌트 지향(CBD1)기법을 거쳐, 2000년대에는 웹 환경에서의 서비스 연결을 중시하는 SOA(Service Oriented Architecture; 서비스 지향 아키텍쳐)에 까지 발전함
- (서비스 지향의 한계) SOA는 SW를 논리적인 서비스 단위로 나누는 개념이었으나, 이를 구현하면서 기업 전체의 비즈니스 프로세스를 조정하는 역할(Service Orchestration)을 중앙에 두어 물리적으로 하나의 덩어리가 됨으로서 서비스 단위의 유연한 대응이 어려웠음
- (독립적인 팀 구성 어려움) 서비스 담당 조직 간의 협조 없이는 서비스 변경이 어려워 책임과 권한이 분산되므로, 결과적으로 환경변화에 대한 기민한 대응이 어려워짐
- (마이크로서비스의 등장) 하나의 단위 서비스에 사용자 화면, 비즈니스 프로세스 뿐 아니라 DB까지 포함할 수 있어, 소규모 팀이 주도적으로 서비스를 발전시키는 것을 용이하게 하는 기술구조임
- * 넷플릭스, e-Bay, 아마존이 마이크로서비스를 채택함
- * 마이크로서비스 커뮤니티의 조직운영 가이드는 주로 ‘소규모팀’과 관련되어 있으며, 대표적으로 아마존CEO 제프베조스의 ‘피자 2판으로 해결할 수 있는 규모(약 8명)로 팀을 구성한다’는 원칙을 참조³
- * 위 그림은 서비스 간 독립성을 강조하는 목적으로 만든 예시로서, 반드시 화면과 DB를 포함해야 마이크로 서비스가 되는 것은 아님
마이크로서비스의 산업별 활용 시나리오
- (SW산업) 패키지SW를 마이크로서비스로 구현하면 SW모듈의 유연성과 재활용성이 증가하고, 마이크로서비스로 구성된 SaaS는 지속적인 부분 업데이트가 용이하여 클라우드에 태생적으로 부합하는(Cloud-Native) 구조가 되며, IT서비스의 경우 고객의 비즈니스 변경 시 빠른 대응이 가능해짐
- (서비스 산업) 마이크로서비스의 기술적 속성을 활용하여 차별화된 서비스를 선도적으로 제공한 후 고객의 피드백을 받아 빠른 개선이 가능
- (금융) 신규 금융상품을 마이크로서비스로 구현하여 출시하면, 상품구성을 변경하거나 규제가 변화할 경우 대응력이 높아짐
- (O2O) 지역별 서비스 프로세스가 다른 경우, 기존 지역의 마이크로서비스를 복제한 후 필요한 부분만 변경하여 다른 지역에 서비스를 출시할 수 있음
- (의료) 진료과목을 마이크로서비스로 구현하면 정형외과는 영상진단 프로세스를 강화하고, 성형외과는 상담 프로세스를 강화하는 등 과목별 특화 프로세스를 구현하는 것이 가능함
마이크로서비스 도입의 장애요인과 대책
- (장애요인) 복잡도 증가, 자원소모 증대, 고급인력 필요
- 서비스의 크기가 작아지고 중앙에서 통합·조정하는 기능이 없어 마이크로서비스 간 연계시 복잡도가 증가
- 마이크로서비스 간 통신이 빈번해져 네트워크 자원을 많이 소모하며, 동일한 프로세스를 마이크로서비스 별로 구현하게 될 경우 중복된 노력을 할 가능성 상존
- SOA에서나 마이크로서비스 에서나 서비스의 경계(Boundary)를 설정하는 것은 중요한 문제이며 이를 해결하기 위해서는 경험많은 아키텍트 인력이 필요
- (대책) 자동화와 설계기법, 장기적인 인력 육성
- 복잡도에 따른 관리 노력을 줄이기 위해 자동화된 도구를 최대한 활용⁴
- 서비스 간 중복을 최소화하여 자원소모를 줄이고, 서비스 경계를 잘 정의하기 위해 도메인 주도 설계⁵인력 확보
민첩한 변화를 꿈꾸는 기업을 위한 시사점
- 시장환경 변화에 따라 기업이 민첩하게 대응하기 위해서는 이를 방해하는 경로의존적 기술구조 또는 상호의존적 조직구조가 기업 내 숨어 있는 것이 아닌지 면밀히 검토할 필요
- 경영자는 기업의 최고 아키텍트(Chief Architect)로서 기술과 조직을 동시에 고려하여 변화를 주도해야 함
- 1 Component Based Development
- 2 http://www.melconway.com/Home/Conways_Law.html
- 3 Boris scholl et al.(2016),＜Microservices with Docker on Microsoft Azure> 김도균 역, 에이콘 발간 예정
- 4 마이크로서비스 지원 오픈소스 참조: https://techbeacon.com/8-best-open-source-tools-buildingmicroservice-apps
- 5 도 메인 주도 설계(DDD；domain-driven design) : 도메인 주도 설계는 개발자가 비즈니스 도메인 모델을 상위수준에서 추상화 하여 정의하는 것을 돕는 일련의 원칙과 관례임. 이는 서비스 경계를 설정하고 비즈니스 기능에 따라 애플리케이션을 개별 마이크로서비스로 나누는데 도움을 줌 (출처 : Microservices with Docker on Microsoft Azure)