[개발 이야기] 다 빈치의 수태고지와 도메인 주도 설계(Domain-Driven Design)

이탈리아 피렌체에 시뇨리아 광장에 가면 우피치 미술관이 있다. 르네상스 시대의 메디치 가문의 연출가였던 조르조 바사리가 설계했다. 빡빡한 도리아식 열주에서 절대주의 건축의 질서감이 느껴지는 공간이다. 이곳에는 레오나르도 다 빈치의 <수태고지>가 전시되어 있다. <수태고지>는 서양 회화의 고전 주제로 예수의 잉태를 알리는 천사와 놀라는 마리아의 모습을 담고 있다. 섬세한 표정과 부드러운 채색, 밀도 있는 구도가 인상적인 그림이다. 가봤냐고? 물론 사진으로 봤다.

 

그런데 가면 보면 그림이 좀 이상하다. ‘원근법(perspective)’이 완전 엉망이다. 마리아의 오른팔이 왼팔에 비해 너무 길어 보이며, 마리아와 책상 사이의 거리는 부자연스럽게 멀리 떨어져 있다. 더 심각한 건 마리아의 뒤쪽 벽돌이다. 다시 한번 자세히 보자. 벽돌들의 각도가 수렴되는 소실점의 위치가 일치하지 않는다. 정확한 사물의 재현이 가장 큰 미덕인 르네상스 시대에서 이것은 명백하고 아주 심각한 오류다.

 

레오나르도 다 빈치의 <수태고지>, 원근법이 엉망이다.

 

다 빈치가 우리 생각보다 위대한 화가가 아니었을까? 아니다. 다행스럽게도 이 그림은 다 빈치가 명백하게 의도적으로 그린 것이다. 이 작품은 성당 앞의 높은 곳에 있었으며, 앞쪽에 재단이 있어 접근이 불가능했다. 따라서 그림은 오른쪽 아래에서만 볼 수 있었다. 그렇기에 다 빈치는 오른쪽 아래에서 그림을 보는 방향으로 소실점을 정했던 것이다. 다 빈치는 즉 누가 어디서 보는가를 고려해 그림을 그렸다. 그림을 오른쪽 아래에서 쳐다보는데, 왜 정면에 맞춰서 그림을 그려야 하냐는 의문을 제시한 것이다.

 

그렇다면 그전까지 화가들은 그림을 정면에서 바라본다는 전제하에 그렸을까? 정면에서 그렸기 때문이다. 그리는 사람이 정면에서 그리니까 그냥 당연히 정면에서 보도록 그렸던 것이다. 다 빈치는 이 당연한 사실에 당연한 의문을 제기했던 것이다. 그림을 바라보는 ‘주체’의 등장이자 인식론적 혁명 즉 관점(perspective)의 패러다임 전환이다. 이때가 1472년이다. 그리고 시간이 흘러 현재 이러한 일이 소프트웨어 세계에서도 일어나고 있다.

 

 

도메인 주도 설계 - 관점의 패러다임

도메인 주도 설계(Domain-Driven Design)는 2003년 에릭 에반스의 저서 <Domain-Driven Design: Tackling Complexity in the Heart of Software>로 처음 세상에 소개됐다. 도메인 주도 설계의 정의는 비즈니스 도메인이 소프트웨어 설계 의사결정을 주도하는 것이다. 도메인 주도 설계는 이전에도 흔히 있었던 다른 기술적 패러다임과는 다른 관점의 패러다임이다.

 

도메인 주도 설계는 우리가 시스템을 바라보는 기술적 관점에 사용자가 시스템을 바라보는 비즈니스 관점을 시스템에 도입한다. 도메인 주도 설계는 도메인 지식을 코드 베이스에 반영하고 비즈니스 관점 주도하에 시스템의 경계를 나누는 것이다.

 

기술 주도 설계

기존에 우리는 시스템을 어떻게 설계했는가? 우리는 기술적 관점으로 시스템을 경계 지어 분할했다. 기술적으로 유사한 역할을 하는 요소들을 묶어 수평적으로 시스템을 분할하였다. 사용자 인터페이스, 영속성 메커니즘과 같은 외부 구성 요소와 연동하는 부분은 인프라스트럭처 계층, 비즈니스 로직은 비즈니스 로직 계층, 시스템의 오퍼레이션을 정의하고 비즈니스 로직을 조율하는 부분은 애플리케이션 계층으로 나누는 식이다.

 

이런 기술적 관점으로의 분할은 무엇이 문제인가? 바로 ‘왜곡’이 일어난다는 점이다. 우리는 비즈니스 도메인 지식을 기술적 관점으로 ‘번역’하여 시스템에 반영한다. 이런 과정에서 필연적으로 수많은 ‘왜곡’이 발생한다. 이러한 왜곡은 사용자가 원하는 ‘진짜’ 문제에 대한 해결이 아닌 무엇도 해결하지 못하는 불명확한 시스템을 유발한다. 또한 시스템은 도메인 로직이 하나의 기술적 관점으로 묶여 뒤섞이면서 도메인 간 경계가 흐려진다. 이런 시스템은 변화가 일어났을 때 대응을 어렵게 만든다.

 

기술적 관점은 '왜곡'을 필연적으로 발생시키고, 비즈니스 로직이 뒤섞이면서 변화에 대응하기 어렵다.

 

그렇다면 왜 우리는 기술적 관점으로 시스템을 분리했는가? 우리가 개발했기 때문이다. 개발자가 개발하니까 그냥 당연히 기술적 관점으로 그렸던 것이다. 우리가 시스템을 바라보는 방식으로 개발했던 것이다. 이제는 이 당연함에 의문을 제기할 때가 되었다. 왜 우리가 사용하지도 않는데 시스템을 우리 관점으로 개발해야하는가?

 

 

도메인 주도 설계는 무엇인가?

도메인 주도 설계는 비즈니스 관점 주도로 시스템을 설계한다. 도메인 주도 설계는 도메인 지식이 ‘왜곡’ 없이 시스템으로 명확하게 흐르며, 비즈니스 관점으로 시스템의 경계가 구분된다. 시스템은 개발자가 문제를 생각하는 방식이 아닌, 도메인 전문가가 문제를 생각하는 방식인 ‘정신 모델’을 반영하고 있다. 따라서 '정신 모델'과 실제 코드사이의 갭(GAP)이 줄어든다

 

도메인 주도 설계로 분할한 시스템, 더 단순하고 명확하게 가치가 흐를 수 있다.

 

 

왜 도메인 주도 설계인가?

비즈니스 관점으로 시스템을 설계하고, 시스템에 도메인 전문가의 ‘정신 모델’을 반영하여 코드와 '정신 모델'의 갭을 줄이면 무엇이 좋은가? 사실상 모든 것이 좋다. 시스템은 더 명확해지고, 복잡성은 낮아지며, 더 기민해지고, 경제적이다.

1. 단순하고 명확한 '가치 흐름'

비즈니스 문제가 시스템에 흘러 고객에게 제공되기까지의 ‘가치 흐름’이 단순하고 명확해진다. 시스템은 비즈니스에 문제나 변화가 생기면 ‘왜곡’ 없이 시스템에 곧바로 반영할 수 있다. 또한 비즈니스 관점으로 경계 지어진 시스템은 시스템의 어느 부분을 변경해야 할지 명확하게 해준다. 우리는 더 빠르고 기민하게 고객에게 가치를 제공할 수 있다.

 

2. 고객의 '진짜' 문제를 해결하는 명확한 시스템

도메인 지식이 개발자로 인해 번역되어 반영된 시스템에서는 고객의 진짜 문제를 해결할 수 없었다. 시스템은 커질수록 어떤 문제로 해결하지 못하는 커다란 진흙 덩어리가 되었다. 시스템이 도메인 전문가의 ‘정신 모델’을 반영한다면, 시스템은 도메인의 문제를 더 명확하게 해결할 수 있다.

 

3. 비즈니스 전략이 시스템에 반영된다.

기술적 관점으로 시스템을 나누던 시절에는 비즈니스 전략과 시스템은 독립적이었다. 하지만 비즈니스 관점으로 시스템을 나누게 되면 조직의 비즈니스 전략이 시스템에 직접적으로 반영될 수 있다. 예를 들어 핵심 하위 도메인의 변경과 같은 비즈니스 전략은 시스템에 직접적으로 반영된다.

 

도메인 주도 설계 주요 개념

어떻게 시스템에 도메인 전문가의 ‘정신 모델’을 반영할 수 있을까? 이를 가능하게 하는 도메인 주도 설계의 몇 가지 개념들을 알아보자.

 

비즈니스 도메인

회사가 주력으로 하는 대표 사업을 뜻한다. 예를 들어 스타벅스는 커피, 페덱스는 배송 서비스이다. 비즈니스 도메인은 여러 개의 하위 도메인으로 구성된다.

 

하위 도메인(Sub Domain)

비즈니스 도메인의 구성요소로 비즈니스 도메인의 목표를 달성하기 위해 상호 작용하는 요소이다. 독립적으로는 비즈니스 도메인에서 가치를 지니지 못하고 모두가 필수적인 요소이며 상호 작용해야 가치를 지닌다. 하위 도메인은 3가지 유형으로 나뉜다.

 

• 핵심 하위 도메인: 비즈니스에서 핵심적인 역할을 하는 도메인으로 즉, 회사에 수익을 가져다주는 도메인이다. 핵심 하위 도메인의 특징은 복잡하면서 경쟁우위를 제공하고, 변동성이 높다.
• 일반 하위 도메인: 일반 하위 도메인은 역시 복잡하고 중요하지만, 이미 해결책이 있기에 경쟁 우위를 제공하지 않는 도메인을 말한다.
• 지원 하위 도메인: 지원 하위 도메인은 복잡하지 않다. 당연히 경쟁 우위도 제공하지 않고 쉽게 구현할 수 있다. 그렇다고 필수가 아닌 것은 아니다.

 

하위 도메인은 설계의 대상이 아닌 이미 있는 것을 ‘식별’하는 대상이다. 하위 도메인의 다소 추상적인 정의로는 ‘해결하고자 하는 문제 영역’이며 휴리스틱 적인 정의로는 응집된 유스케이스를 가진 업무 단위이다. 예를 들어 스타벅스의 하위 도메인은 주문, 제조, 마케팅, 재고 등이 있다.

 

유비쿼터스 언어

유비쿼터스 언어는 도메인 지식의 ‘왜곡’을 해결한다. 유비쿼터스 언어는 모든 이해관계자가 일관적으로 사용하는 비즈니스 언어이다. 유비쿼터스 언어를 구축하고 사용하여 도메인 지식에서 도메인 전문가가 문제를 바라보는 ‘정신 모델’로, ‘정신 모델’에서 솔루션 모델을 거쳐 시스템으로 ‘왜곡’ 없이 흐르도록 한다.

 

바운디드 컨텍스트

바운디드 컨텍스트는 시스템의 경계를 나누는 기법이다. 도메인 주도 설계는 바운디드 컨텍스트를 포함한 몇가지 기법을 통해 비즈니스 관점으로 시스템을 분할한다. 이 중 바운디드 컨텍스트는 정신 모델의 경계, 즉 유비쿼터스 언어가 일관성을 유지하는 경계다.

 

비즈니스 도메인에는 하나의 정신 모델이 아니라 여러 개의 정신 모델이 있을 수 있다. 이 경우 일관성을 유지해야 하는 유비쿼터스 언어의 정의가 깨진다. 이 경우에는 바운디드 컨텍스트로 경계를 나눠 하나의 정신 모델이 아니라 여러 개의 정신 모델을 시스템의 반영할 수 있도록 한다.

 

바운디드 컨텍스트는 독립적으로 발전할 수 있는 경계이며, 물리적 경계이기도 하다.

 

마이크로서비스 아키텍처

사실 도메인 주도 설계가 이렇게 유명해진 이유는 마틴 파울러의 마이크로서비스 아키텍처가 도메인 주도 설계와 관계를 맺고 있기 때문이다. 마이크로서비스 아키텍처는 가장 작은 유효한 서비스 단위로 시스템을 분할하여 구성하는 방법이다.

 

도메인 주도 설계는 마이크로서비스 아키텍처에서 마이크로서비스의 유효한 경계를 찾는 데 적합한 기법들을 가지고 있다. 도메인 주도 설계의 비즈니스 관점으로 경계 지어진 마이크로서비스는 적절한 로컬 복잡성과 글로벌 복잡성을 가진다.

 

 

---

 

 

거스를 수 없는 인식론적 혁명

사실 소프트웨어 세계에서는 이미 수많은 패러다임이 등장했었고 사라져 왔다. 우리는 여러 패러다임 중 적합한 것을 취사선택하면 그만이었다. 수많은 패러다임처럼 도메인 주도 설계도 잠깐 등장했다 사라지는, 필요에 따라 취사선택할 수 있는 것일까? 나는 도메인 주도 설계가 이전 패러다임들과는 다른 거스를 수 없는 패러다임이라는 생각을 하고 있다. 그 이유는 도메인 주도 설계가 기술적 패러다임이 아닌 관점의 패러다임이기 때문이다. 기술은 계속 변하지만, 인간의 관점은 변하지 않는다.

 

르네상스 시대 다 빈치의 <수태고지>란 인식론적 혁명 이후 ‘주체’에 대한 인식이 당연하게 된 것처럼, 소프트웨어 세계도 도메인 주도 설계 이후 비즈니스 도메인 관점에 대한 인식이 당연하게 될 것이다. 도메인 주도 설계는 우리 세계와 시대의 인식론적 혁명이다.

 

물론 도메인 주도 설계가 사라질 수는 있다. 하지만 그 본질인 비즈니스 관점으로 시스템을 설계하는 개념은 이제 소프트웨어 세계에서 사라지지 않을 것이다. 사실 그전에도 소프트웨어에 비즈니스 관점을 도입하려는 시도는 많이 있었다. 우리가 흔히 알고 있는 XP의 ‘스토리’가 대표적이다. 도메인 주도 설계가 특별한 것은 요구사항을 넘어 시스템에 직접적으로 비즈니스 관점이 반영된다는 것이다. 이러한 개념만 유지된다면 도메인 주도 설계보다 더 좋은 게 나오면 당연히 바뀔 수 있다.

 

나는 더 적극적으로 이러한 관점을 우리 소프트웨어 업계에서 받아들여야 한다고 생각한다. 도메인 주도 설계는 비즈니스와 기술을 더욱 가깝게 하고, 시스템의 복잡성을 줄이고, 명확하게 하고, 변화에 더 기민하게 반응하게 한다. 형편없는 소프트웨어를 만들거나, 여건이 되지 않는 경우를 제외하고는 도메인 주도 설계를 도입하지 않을 이유가 없다. 내 생각에 성장하고 합리적인 조직이 러닝 커브를 핑계로 시도조차 하지 않는 건 쓰레기 같은 변명이다. 의사소통의 문제를 핑계 삼는 건 대단한 적신호다. 나는 진심으로 우리 소프트웨어가 조금 더 훌륭해지고 조금 더 의미있어지길 바란다.