시스템 구동의 맥락(context) 파악하기
도메인 스토리텔링 응용 9
<입장에 맞춰 맥락을 나눈 BoundedContext>편에서 소개한 맥락 활용은 DDD 고유 개념은 아니다. 이 글에서는 시스템을 정의할 때 맥락(context)이 어떻게 활용되는지 설명하려고 한다. 그런데, <도메인 모델링? 비즈니스 모델링 어떻게 하나요?>편에서 소개한 대로 모델링이라는 활동은 소프트웨어 개발이나 비즈니스 모두에 활용하는 행위다. 그래서 Lean Canvas 작성 후에 Lean Stack이 보내준 가이드를 비즈니스 모델링이 아닌 도메인 모델링 맥락에서 소개하는 과정으로 맥락(contex)라는 개념에 친숙해지는 것이 목표다.
시스템 맥락도
UML을 활용하던 시절 가장 먼저 그린 그림은 시스템 문맥도(System Context Diagram)이었다. 모르는 업무를 대상으로 하기 때문에 해당 업무 종사자들이나 전문가를 대상으로 인터뷰를 진행하며 시스템을 둘러싼 맥락을 그려낸다.
출처: 위키피디아UML을 사용하는 경우는 위 그림과 조금 다른데 가운데 시스템을 그리고 주변에 사용자와 연동 시스템을 Actor라는 표기로 그린다. 여하튼 가운데 대상 시스템을 그리고 상호작용(혹은 입출력)하는 대상을 쓴다는 점에서는 동일하다.
맥락도를 그릴 때 무엇을 넣고 뺄 것인가 결정해야 한다. 중요한 것은 꼭 포함되어야 하지만, 중요하지 않은 요소를 모두 포함하면 초점이 희석되지 않는가? 이런 관계를 상충관계 혹은 트레이드오프라고 하는데 모델링에서 이를 다루는 일은 매우 중요하다. 모델링은 적절하게 쟁점을 드러내는 추상화하여 실체화(realization)를 위한 의사소통(정보전달과 의사결정)을 위한 활동이기 때문이다.
주요 이해관계자는 누구인가?
트레이드오프 판단 과정에서 가장 중요한 질문은 누가 주요 이해관계자인가 하는 질문을 던지는 일이다. 또한, 어떠한 공동체든 모든 이해관계자의 영향력이 같은 경우는 없다. 그리고 갈등이 발생한다. 이를 잘 포착하여 시스템이 담아내도록 해야 한다.
Lean Stack이라는 서비스에 비즈니스 모델 결과를 저장했더니 안내 메일이 왔다. 메일 제목은 3개의 비즈니스 모델 전형(The 3 Basic Business Model Archetypes)이었다. 참조할 수 있는 3가지 전형을 예시로 보여줬다. 직접(Direct), 양면(Multisided), 마켓플레이스(Marketplace)인데 이를 보면서 이해관계자와 시스템의 관계로 볼 수 있었다.
맥락(Context)이란 무엇인가?
시스템을 소프트웨어가 아니라 사업 자체로 보면 맥락을 파악하는 방식은 똑같았다. 아래 비즈니스 캔버스 예시가 바로 직접(판매) 비즈니스 모델의 예시다.
맥락이 무엇이고 어떻게 나타내는지 이해하기 위해 위 그림을 시스템 맥락도로 변환해본다. 누구(CoffeeDrinkers)에게 시스템(Starbucks)이 어떤 효능(집과 회사 사이의 제3의 공간 제공)을 제공할 것인지를 표현했다. 이것이 바로 맥락(Context)이다.
맥락을 이해하면 전체를 총괄하려는 입장이 단일 맥락을 선호하게 만든다는 사실도 유추할 수 있다. WBS 나 하나의 간트차드로 전체 구축 일정을 알고 싶어하는 프로젝트 관리자는 하나의 맥락으로 시스템 구축 과정을 보고 싶어 한다.
단일 맥락에서 벗어나야 하는 외부 요인
PM이 시스템을 모노리식 시스템으로 만든다는 의미는 아니지만, 모노리식일 때 관리와 소통이 유리하다. 전사적 데이터 모델링으로 전성기(?)를 구가하던 전문가들과 관련 기업은 모노리식에 절대적인 영향을 끼쳤다고 볼 수 있다. 고가의 컴퓨터와 CPU 나 인스턴스 등의 컴퓨팅 자원별로 라이선스를 요구하던 SAP, 오라클 DBMS 등의 외산 솔루션도 모노리식과 한편(?)이라 할 수 있다. 갑자기 불어닥친 클라우드 바람이 이 모든 결합(?)에 변화를 요구한다.
글이 길어져 이에 대한 이야기는 후속편으로 다룬다
지난 도메인 스토리텔링 응용
6. 도메인 모델, Ongoing 설계 그리고 정원관리
