[데이터넷] 디지털 전환의 모범 사례로 꼽히는 기업들의 IT 전략을 보면 한 가지 공통점이 있다. MSA를 기반으로 비즈니스 민첩성과 유연성을 빠르게 높이고 있다는 것이다. 이처럼 디지털 전환의 엔진 역할을 하는 MSA는 언제부터 IT 커뮤니티의 관심을 끌었고, 어떤 과정을 거쳐 프로덕션 환경의 DNA를 바꿀 파괴적 기술로 성장했을까? 4회의 연재를 통해 MSA 개념의 등장부터 구축 방안 그리고 레거시를 보유한 조직의 경우 어떻게 모놀리식 아키텍처를 점진적으로 마이크로서비스로 만들어 갈 수 있는 지 방안을 알아보겠다. <편집자>

연재 순서 1. 제임스 루이스와 마틴 파울러의 MSA (이번호) 2. 산업계의 MSA 구축 방안 3. 벤더의 MSA 구축 방안 4. 레거시 현대화와 MSA 구축 방안

마이크로서비스 아키텍처라는 개념은 2014년 5월 25일 마틴 파울러(Martin Fowler)의 홈페이지 게시물을 통해 공론화됐다. 해당 게시물에서 마틴 파울러는 마이크로서비스 아키텍처를 다음과 같이 정의했다.

“‘마이크로서비스 아키텍처’라는 용어는 소프트웨어 애플리케이션을 독립적으로 배포 가능한 서비스 모음으로 설계하는 특정 방법을 설명하기 위해 지난 몇 년 동안 생겨났다. 이 아키텍처 스타일에 대한 정확한 정의는 없지만, 비즈니스 기능, 자동화된 배포, 엔드포인트의 인텔리전스, 언어 및 데이터의 탈중앙화 제어를 중심으로 조직과 관련된 확실한 공통 특성이 있다.”

그러나 마이크로서비스 개념은 스루아웃웍스(ThoughtWorks)의 수석 컨설턴트이자 기술 자문 위원회 일원인 제임스 루이스(James Lewis)가 2012년 자바존(JavaZone)의 ‘Micro-Services - Java, the UNIX way’라는 강연에서 처음으로 등장했다. 그는 해당 강연에서 마이크로서비스에 대해 다음과 같이 소개했다.

“40년 전에는 ‘한 가지 업무를 잘 하는 프로그램을 작성하고, 그 프로그램들이 함께 잘 동작하도록 하라’는 말이 당연시됐지만, 지난 10년 동안 무어의 법칙처럼 하드웨어의 발전은 모놀리식 애플리케이션을 구축하고 비대한 미들웨어를 통해 통신하는 것을 가능하게 했다. 마이크로서비스는 웹 표준 인터페이스를 통해 통신하고 잘 작동하는 운영체제 서비스로 설치된 단일 책임을 갖는 작은 애플리케이션이라 할 수 있다. 간단한 한 줄의 코드를 변경하기 위해 수만 줄의 코드와 모든 XML을 이해해야 하는 것이 지겨웠다면, 지금부터 마이크로서비스가 얼마나 멋지고 무엇을 하는지는 물론 자바 도구를 사용해 마이크로서비스를 구축하는 방법에 대해 알아보자.”

모놀리식 vs. 마이크로서비스
마이크로서비스 아키텍처는 점점 비대해지며 하나씩 문제점이 드러나는 모놀리식 아키텍처의 단점을 해결하기 위해 나온 개념이다. 제임스 루이스가 2012년 자바존에서 발표한 것처럼, 작고 단순한 유닉스의 철학에 따라 비대해진 애플리케이션을 단일 책임을 갖는 작고 모듈성이 높은 마이크로서비스 단위로 애플리케이션을 분리하자는 것이 핵심이다.

현대의 엔터프라이즈 애플리케이션은 클라이언트 사용자 인터페이스(사용자 컴퓨터의 브라우저에서 실행되는 HTML 페이지 및 자바스크립트로 구성), 서버 애플리케이션, 데이터베이스 시스템 등 세 가지 주요 부분으로 나뉘어 구축된다.

서버 애플리케이션은 ▲HTTP 요청 처리 ▲도메인 로직 수행 ▲데이터베이스 조회 및 업데이트 ▲브라우저에 응답할 HTML 생성 등의 작업을 수행한다. 이러한 서버 애플리케이션은 하나의 단위(자바의 경우 WAR 형태)로 배포돼 실행되는 모놀리스로, 애플리케이션에 새로운 수정사항이 발생하면 서버 애플리케이션 전체를 빌드하고 배포하는 작업을 해야 한다.

이러한 모놀리식 아키텍처는 서버 애플리케이션을 구축하는 가장 단순한 방법이지만, 요청을 처리하기 위한 모든 로직이 단일 프로세스에서 실행된다. 따라서 언어의 기본 기능을 사용해 애플리케이션을 클래스, 함수 및 네임스페이스로 나눌 수 있다.

개발자는 자신의 로컬PC에서 간단하게 애플리케이션을 수정하고 실행 및 테스트할 수 있으며, 배포 파이프라인을 사용해 변경 사항이 올바르게 테스트되고 프로덕션에 배포되도록 할 수 있다. 또 로드밸런서를 구성해 서버 애플리케이션을 여러 인스턴스로 실행, 모놀리스를 수평으로 확장할 수 있다.

그러나 애플리케이션의 작은 부분이 변경되더라도 전체 모놀리스를 다시 빌드하고 배포해야 하며, 시간이 지남에 따라 좋은 모듈 구조를 유지하는 것이 어렵다. 이런 이유로 해당 모듈 내에서 하나의 모듈에만 영향을 미쳐야 하는 변경 사항을 유지하기가 더 어려워진다. 확장하려면 더 많은 리소스가 필요한 부분이 아니라 전체 애플리케이션 확장이 필요하다.

이러한 모놀리스 애플리케이션의 문제점이 마이크로서비스 아키텍처가 나오게 된 가장 큰 이유다. 애플리케이션을 프로젝트가 아닌 서비스 제품으로 구축하자는 것이다. 각 서비스는 독립적으로 배포 가능하고 확장이 가능할 뿐만 아니라, 확고한 모듈 경계를 제공해 다른 서비스를 다른 프로그래밍 언어로 작성할 수도 있으며, 팀 단위로 개발하고 운영한다.

현존하는 애플리케이션 아키텍처는 다음과 같이 구분된다.

• 레거시 모놀리식 아키텍처: 이는 메인프레임 애플리케이션 아키텍처를 특별하게 구분해 표현한 것이다.
• 모던 모놀리식 아키텍처: 현대의 엔터프라이즈 애플리케이션 아키텍처이며, 일반적으로 이야기하는 모놀리식 아키텍처를 의미한다.
• 마이크로서비스 아키텍처: 현대의 엔터프라이즈 애플리케이션을 서비스 제품으로 분리해 각 서비스를 독립적으로 배포 가능하다. 각 서비스는 팀 단위로 개발하고 운영한다.

모놀리식 아키텍처는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합돼 있는 형태로, 모든 프로세스가 긴밀하게 결합돼 단일 서비스로 실행된다. 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 하며, 코드 베이스가 증가하게 되면 기능을 추가하거나 개선하기가 더 복잡해진다.

마이크로서비스 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처다. 각 마이크로서비스는 상호 통신이 가능하며 이를 통해 전체 서비스를 구성한다. 애플리케이션이 독립적인 구성요소로 구축돼 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 마이크로서비스 아키텍처의 장단점에 대해 살펴보면 [표 2]와 같다.

마이크로서비스 아키텍처 특성
마이크로서비스 아키텍처 특성을 기술적인 측면, 아키텍처 측면, 조직적 측면으로 나눠 살펴보자. 먼저 기술적인 측면은 다음과 같다.

• 자체 프로세스로 실행 실행된다.
• 마이크로서비스 내에서 발생한 결함은 다른 마이크로서비스에 영향을 미치지 않는다.
• 마이크로서비스는 API 형태로 실행되며, 상태(state)를 갖지 않는다.
• 마이크로서비스는 독립적으로 배포된다.
• 마이크로서비스는 독립적으로 스케일링 된다.
• 마이크로서비스 단위로 데이터베이스를 구성한다.

마이크로서비스를 아키텍처 측면에서 살펴보면 다음과 같다.

• 마이크로서비스는 제한된 컨텍스트가 있는 느슨하게 결합된 서비스이다. DDD(Domain Driven Design) 방식을 이용해 경계 컨텍스트를 명확하게 구분할 수 있다.
• 마이크로서비스 간의 호출은 API 게이트웨이를 통해 실행된다.
• 마이크로서비스는 해당 서비스를 위한 최적의 언어로 개발된다.
• 마이크로서비스는 단일 책임을 갖는다.
• 마이크로서비스 간의 실행은 동기 방식(Request/Response)이 아닌 이벤트 처리 방식(Publish/Subscribe)으로 비동기 처리된다.
• 마이크로서비스를 스마트하게 잘 만들고, 마이크로서비스 간의 통신을 제어하기 위해 ESB(Enterprise Service Bus) 같은 스마트한 통신 파이프가 아니라 REST 방식 또는 RabbitMQ 및 ZeroMQ와 같은 단순한(dump) 통신 파이프를 활용하자는 것이다.

마이크로서비스 간의 작동 방식은 ‘오케스트레이션(Orchestration)’과 ‘안무(Choreography)’ 등 두 가지 접근 방식이 있다. 오케스트레이션은 지휘자가 오케스트라의 음악가를 지휘하는 것처럼 하나의 서비스 컨트롤러가 마이크로서비스 간의 모든 통신을 처리하고, 각 서비스가 의도한 기능을 수행하도록 지시하는 요청/응답(Request/Response) 방식을 의미한다.

반면에 안무는 감독과 지시 없이 음악이 연주될 때 마이크로서비스가 처리할 이벤트에 따라 동작하는 비동기 이벤트 처리(Publish/Subscribe) 방식으로 동작하는 것을 의미한다. 이는 [그림 3]과 같이 표현될 수 있다.

반지의 제왕 3부작에서 반지를 파괴하기 위한 긴 여정을 함께 할 반지원정대를 구성하는 과정에 1부를 할애한 것처럼, 마이크로서비스 아키텍처 역시 디지털 트랜스포메이션이라는 긴 여정을 함께 할 팀 조직을 꾸려야 한다는 것을 대단히 강조한다. 마이크로서비스를 조직적 측면에서 살펴보면 다음과 같다.

• 단일 마이크로서비스를 위해 비즈니스 기능 중심으로 팀을 구성한다.
• 마이크로서비스는 프로젝트처럼 개발되지 않고, 하나의 제품으로서 개발되고 운영된다.
• 아마존의 ‘당신이 구축하고 실행한다’는 사상처럼 개발 팀이 프로덕션 소프트웨어에 대한 전적인 책임을 지고 개발 및 운영한다.
• 데브옵스(DevOps)와 같이 개발, 테스트, 배포, 운영 프로세스를 자동화한다.
• 마이크로서비스를 책임지는 팀은 콘웨이(Conway)의 법칙에 따라 최소한의 인원으로 구성한다 마이크로서비스 팀의 가장 큰 규모는 아마존의 피자 두 판의 원칙에 따라 12명 이하가 적당하다.
• 탈중앙화 거버넌스는 각 팀이 전문 지식을 사용해 특정 문제를 해결하기 위한 최상의 도구(개발 언어, 데이터베이스 등)를 선택할 수 있도록 해준다.

필자의 경우, 마이크로서비스 아키텍처에서 가장 중요한 것은 아마존의 ‘당신이 구축하고 실행한다’는 사상처럼 개발 팀이 프로덕션 소프트웨어에 대한 전적인 책임을 지고 개발 및 운영한다는 것이라 본다. 그리고 이 팀을 구성하기 위해 아마존의 피자 두 판의 원칙처럼 구성원 간의 커뮤니케이션을 가장 효율적으로 할 수 있도록 인원을 구성해야 한다.

또 콘웨이의 법칙은 제품이 기능하기 위해서는 구성 부품의 작성자와 설계자가 구성요소 간의 호환성을 보장하기 위해 서로 커뮤니케이션해야 한다는 추론에 기반한 것이다. 이 법칙은 주로 소프트웨어 아키텍처 분야에 적용되지만, 그 가정과 결론은 대부분의 기술 분야에 적용된다.

디지털 여정 함께 할 팀 구성 중요
디지털 트랜스포메이션에 대해 이야기할 때 흔히 ‘여정(Journey)’이라는 표현을 쓰는데, 이를 함께 할 비즈니스 중심의 조직 구성을 반드시 갖춰야 할 조건으로 꼽는다. 영화 반지의 제왕은 ‘반지 원정대’, ‘두 개의 탑’, ‘왕의 귀환’ 등 3 부작으로 구성돼 있는데, 1부인 ‘반지 원정대’는 중간계를 구하기 위해 사우론이 반지를 만들어낸 장소인 모르도르에 있는 운명의 산의 불구덩이에 절대반지를 던져 파괴하기 위한 여정을 함께 할 반지 원정대를 구성하는 과정을 담고 있다.

프로도가 반지 운반자로 자원하고, 프로도를 도울 반지 원정대로 프로도의 세 호빗 친구들과 간달프, 아라고른, 곤도르의 보로미르, 난쟁이 김리, 엘프 레골라스가 함께 싸운다. 이처럼 디지털 여정을 함께 하기 위한 팀을 구성하는 것이 가장 중요하다.