DDD 제한적 컨텍스트와 마이크로서비스의 크기

지난 6월달에 열린 DDD eXchange의 키노트에서 에릭 에반스가 도메인 주도 설계의 개요를 설명하면서 모델이란 무엇이고 책 출간 이후 기술 변천에 따라 DDD는 어떤 의미가 되었는지 발표했습니다. 모델이 무엇인지 지도를 사용해서 설명하는 데 모델은 현실을 그대로 반영하는 게 아닐 뿐 아니라 완벽할 필요도 없다는 얘기가 인상적입니다.

발표 내내 이벤트 소싱은 여러번 강조했고, 역시나  (요즘 인기있는) 마이크로서비스를 가지고 제한적 컨텍스트(Bounded Context) 약 파는 것도 잊지 않았습니다.

약 한 달 전에 회사 동료와 마이크로서비스와 제한적 컨텍스트를 두고 가볍게 토론을 했습니다. 동료의 팀에서 마이크로서비스 아키텍처로 애플리케이션을 만들었는데 잘 안 풀렸고 나중에 보니 제한적 컨텍스트를 적용하지 않았기 때문이라고 말했습니다. 하지만 저는 이 의견에 동의하지 않았습니다.

 에릭 에반스는 2003년에 DDD를 출간한 이후에 DDD도 변화와 발전을 했고 그 대표가 이벤트 소스이며 제한적 컨텍스트도 중요도가 바뀌었다고 합니다. 자신이 다시 책을 쓴다면 기존처럼 제한적 컨텍스트를 책 후반부에 두지 않고 보편적 언어와 함께 핵심 요소로 강조할 거라고 했었던 것으로 기억합니다. 그러면서 마이크로서비스 마다 제한적 컨텍스트를 두고 독립된 보편적 언어를 만들어야 한다고 주장합니다.

제가 제 동료의 생각에 반대한 이유는 제한적 컨텍스트가 중요하지 않다고 생각해서가 아니라 마이크로서비스의 크기 때문입니다.

제가 알기로 동료가 말한 애플리케이션 개발 프로젝트는 잘 해야 네댓 명이 단기간에 만든 소규모 서비스인데 그 안에서 만든 마이크로서비스의 크기라는 게 독립적인 보편적 언어(ubiquitous language)를 갖을 정도로 크다고 판단되지 않았습니다.

마이크로서비스와 관련한 논란 중 대표적인 것이 마이크로서비스는 얼마나 마이크로해야 하느냐, 즉 얼마나 작아야 마이크로서비스냐는 문제입니다.

어떤 사람은 마이크로서비스는 컴포넌트가 아니라고 말하면서 마이크로서비스는 생각보다 크다고 말합니다.

한편으로 마이크로서비스는 한 스크럼 팀이 한 스프린트에 개발할 정도의 규모여야 한다고 말하는 사람도 있습니다.

마이크로서비스 하나는 한 팀 정도가 담당하는 규모라는 의견도 있습니다.

에릭 에반스가 마이크로서비스 아키텍처의 유행을 틈타서 제한적 컨텍스트가 마이크로서비스의 문제를 해결해 줄거라고 약 팔고 다닌 건 작년에 인지했습니다. 닐 포드는 마이크로서비스 아키텍처가 DDD를 물리적인 아키텍처로 현실화 한 것이라고 말하면서 에릭 에반스를 응원합니다.에릭 에반스의 이 주장과 함께 인터넷에는 이에 동조하는 글이 많이 생겨났습니다. 하지만 저는 이 주장에 선뜻 동의하지 못합니다.

도메인 주도 설계에서 에릭 에반스는 대규모 조직에서 너무 큰 단위 모델을 일관되게 유지하는 것이 비현실적이라면서 독립적인 보편적 언어를 개발할 수 있도록 도메인 영역을 제한하도록 권합니다. 그러면서 제한적 컨텍스트라는 개념을 소개합니다. 그런데 책에서 이 때 말한 “너무 큰”의 규모는 기업 전체 규모입니다. 한 회사 전체가 단일 언어를 유지할 수 없다는 말입니다. 한 회사라는 기준도 회사의 크기가 천차 만별이라서 절대적인 기준은 아니겠지만 한 언어를 유지할 수 없을 정도로 충분히 큰 조직이라는 사실만은 분명합니다.

아무리 그 동안 제한적 컨텍스트를 적극적으로 활용하는 방향으로 DDD가 발전했다고 해도 소수의 인원이 단기간에 마이크로서비스 아키텍처로 개발했다는 애플리케이션의 마이크로서비스가 독립적인 보편적 언어를 갖는다는 건 지나친 적용이라고 생각합니다.

거꾸로 에릭 에반스의 주장을 적극 받아 들여서 마이크로서비스의 크기를 정하는 방식도 가능합니다. 어차피 마이크로서비스의 크기에 대해 합의가 안 되고 논란이 계속된다면 보편적 언어를 갖을 만큼 크고 독립적인 단위라는 기준을 사용하는 것도 나쁘지 않아 보입니다.

좋은 설계를 강조하는 전문가들은 너무 엄격한 기준을 제시하는 경향이 있습니다. 저는 아무리 에릭 에반스가 제한적 컨텍스트를 강조하더라도 지나치게 작은 제한적 컨텍스트를 설정함으로서 컨텍스트 매핑을 복잡하게 만들고 한 팀에서 여러 독립적인 언어(모델)를 사용하도록 해서는 안 된다고 생각합니다.

커뮤니케이션의 문제를 극복하는 게 DDD의 목적 중 하나인데 오히려 DDD 때문에 커뮤니케이션이 복잡해진다면 이는 DDD의 애초 목적에도 맞지 않습니다.

DDD 책을 보면 제한적 컨텍스트와 모듈의 차이에 대한 박스 글이 있습니다. “제한적 컨텍스트는 모듈이 아니라”라는 이 글에서 에릭 에반스는 제한적 컨텍스트 안에 여러 모듈을 둘 수 있다고 말합니다. 저는 이 모듈이 마이크로서비스로 보입니다.