이미 수십 년 전에 만들어진 마이크로커널 아키텍처(microkernel architecture, 플러그인 아키텍처라고도 함)는 오늘날에도 널리 쓰이고 있다. 이 아키텍처 스타일은 (단일 모놀리식 배포 단위로 패키징해서 다운로드 및 설치가 가능하며, 보통 고객 사이트에서 서드파티 제품으로 설치되는) 제품 기반 애플리케이션에 적합하며, 비제품 고객 비지니스 애플리케이션에도 많이 사용된다.

12.1 토폴로지

마이크로커널 아키텍처 스타일은 코어 시스템(core system)과 플러그인 컴포넌트(plug-in component)라는 두 가지 아키텍처 요소로 구성된 비교적 단순한 모놀리식 아키텍처이다. 애플리케이션 로직은 독립적인 플러그인 컴포넌트와 기본 코어 시스템에 골고루 분산되어 확장성, 적응성, 애플리케이션 기능 분리, 커스텀 처리 등을 수행한다.

12.1.1 코어시스템

코어 시스템은 시스템을 실행시키는 데 필요한 최소한의 기능으로 정의한다. 이클립스 IDE가 좋은 예이다. 이클립스 코어 시스템은 파일을 열고, 텍스트를 고치고, 다시 파일을 저장하는 기본적인 텍스트 에디터에 불과하다. 플러그인을 추가해야 비로소 쓸 만한 제품이 된다. 코어시스템은 커스텀 처리가 거의/전혀 필요 없는, 애플리케이션을 관통하는 정상 경로(happy path, 일반적인 처리 흐름)라고 정의할 수 있다. 코어 시스템의 순환 복잡도를 없애고 별도의 플러그인 컴포넌트를 장착하면 확장성, 유지보수성은 물론 시험성도 좋아진다.

코어 시스템은 규모와 복잡도에 따라 레이어드 아키텍처나 모듈러 모놀리스로 구현할 수 있다. 경우에 따라 코어 시스템을 별도 배포하는 도메인 서비스로 나누어 서비스별 도메인에 특정한 플러그인 컴포넌트를 둘 수도 있다.

실제로 별도의 UI를 마이크로커널 아키텍처 스타일로 구현할 수도 있다. 위의 그림은 코어 시스템에 대해 프레젠테이션 레이어를 구성하는 세 가지 변형이다.

12.1.2 플러그인 컴포넌트

플러그인 컴포넌트는 특수한 처리 로직, 부가 기능, 그리고 코어 시스템을 개선/확장하기 위한 커스텀 코드가 구현된 스탠드얼론 컴포넌트이다. 변동성이 매우 큰 코드를 분리하여 애플리케이션 내부의 유지보수성, 시험성을 높이는 것이다. 이상적인 플러그인 컴포넌트는 상호 독립적이며 의존성이 없다.

플러그인 컴포넌트와 코어 시스템은 일반적으로 점대점(point-to-point) 통신을 한다. 즉, 코어 시스템에 플러그인을 연결하는 파이프는 대부분 플러그인 컴포넌트의 진입점 클래스를 호출하는 메서드나 함수 코드이다. 플러그인 컴포넌트는 컴파일 기반 또는 런타임 기반으로 만들 수 있다. 런타임 플러그인 컴포넌트는 런타임에 코어 시스템이나 다른 플러그인을 재배포하지 않고도 바로 추가/삭제가 가능하다. 컴파일 기반의 플러그인 컴포넌트는 관리하기는 편하지만, 변경, 추가, 삭제 시 전체 모놀리식 애플리케이션을 재배포해야 한다.

플러그인 컴포넌트가 반드시 코어 시스템과 점대점 통신을 해야 하는것은 아니다. 각 플러그인을 스탠드얼론 서비스(또는 컨테이너에 구현한 마이크로서비스)로 만들어 REST나 메시징 등 다른 방법으로 기능을 호출하는 방법도 있다. 플러그인 컴포넌트를 개별 서비스로 구현해서 원격 액세스하는 방법은 전체 컴포넌트의 커플링이 낮아져 확장성과 처리량이 개선된다.

하지만 장점이 있으면 단점도 따르는법이다. 원격 플러그인에 접속하려면 마이크로커널 아키텍처를 모놀리식 아닌 분산 아키텍처로 바꿔야 하는데, 대부분의 서드파티 온프렘 제품은 그렇게 구현/배포하기가 쉽지 않고 전반적으로 복잡도와 비용이 높아져 전체 배포 토폴로지가 상당히 난해해진다. 플러그인 컴포넌트와 코어 시스템어 점대점으로 통신할 지, 원격 액세스를 할 지는 주어진 요구사항에 따라 선택해야 할 문제이므로 장단점을 분석해서 신중히 결정해야 한다.

12.2 레지스트리

코어 시스템은 어떤 플러그인을 사용할 수 있는지, 그 플러그인을 가져오려면 어떻게 해야 하는지는 알고 있어야 한다. 가장 일반적인 구현 방법은 플러그인 레지스트리를 경유하는 것이다. 이 레지스트리에는 플러그인 명칭, 데이터 계약, 세부 원격 액세스 프로토콜 등 각 플러그인 모듈에 관한 정보가 있다.

레지스트리는 코어 시스템이 소유한 내부 맵 구조처럼 단순할 수도 있고, 레지스트리 및 디스커버리 도구가 코어 시스템이나 외부 배포된 시스템에 내장된 복잡한 형태가 될 수도 있다.

12.3 계약

플러그인 컴포넌트와 코어 시스템 간의 계약은 보통 플러그인 컴포넌트의 도메인 단위로 표준화되어 있고, 플러그인 컴포넌트가 수행하는 기능 및 입출력 데이터는 계약에 명시되어 있다. 서드파티 회사가 개발한 플러그인 컴포넌트의 계약을 여러분 마음대로 바꿀 수 없을 때에는 보통 커스텀 계약을 사용하며, 일반적으로 코어 시스템이 각 플러그인별 코드를 필요로 하지 않도록 플러그인 계약과 여러분이 정한 표준 계약 간의 어댑터를 만든다.

12.4 실제 용례

이클립스 IDE, PMD, 지라(Jira), 젠킨스(Jenkins) 등 많은 소프트웨어 개발/릴리스 도구가 마이크로커널 아키텍처를 사용해서 개발됐다. 크롬, 파이어폭스 같은 인터넷 웹 브라우저도 마이크로커널 아키텍처를 응용한 제품으로, 각종 뷰어와 플러그인을 장착하면 코어 시스템에 해당하는 기본 브라우저에 없는 부가 기능을 덧붙일 수 있다. 제품 기반의 소프트웨어 역시 용례는 무궁무진하지만, 마이크로커널 아키텍처는 대규모 비지니스 애플리케이션에도 적용할 수 있따. 예를 들어, 보험금 청구건을 처리하는 보험 회사 시스템이 있다고 하자.

보험금 청구 프로세스는 관할 구역마다 보험금 청구 시 허용/금지된 규칙과 규정이 제각각이기 때문에 아주 복잡하다. 보험금 청구 처리 애플리케이션은 대부분 아주 크고 복잡한 규칙 엔진을 이용해서 복잡한 로직을 처리하지만, 자칫 이 규칙 엔진이 진흙잡ㄴ탕이 되어 규칙 하나를 변경하면 다른 규칙들이 연쇄적으로 영향을 받거나, 단순한 규칙 하나를 바꾸려고 해도 여러 분석가, 개발자, 테스터가 한데 모여 문제가 없는지 검토하는 과정을 거쳐야 할 수 도 있다. 바로 이런 경우에 마이크로커널 아키텍처 패턴을 활용하면 많은 도움이 된다.

관할 구역별 보험금 청구 규칙을 별도의 스탠드얼론 플러그인 컴포넌트에 보관하는 것이다. 그러면 다른 시스템 파트에 영향을 주지 않고 특정 관할 구역의 규칙을 추가, 삭제, 변경할 수 있다. 코어 시스템은 바뀔 일이 거의 없는, 청구건을 접수 받아 처리하는 표준 프로세스가 될 것이다.

12.5 아키텍처 특성 등급

마이크로커널 아키텍처는 도메인 분할, 기술 분할이 모두 가능한 유일한 아키텍처 스타일이다. 마이크로커널 아키텍처는 대부분 기술분할되지만, 도메인 분할 역시 강력한 도메인 대 아키텍처 동형성(domain-to-isomorphsm)을 통해 실현된다.