도메인 모델링 절차에 대하여
도메인 모델링 세미나 18
기억이 분명하지 않지만 아래 그림을 인상 깊게 본 계기에는 지난달에 DDD 강의를 하시는 박재성님을 만나서 나눈 대화에서 나눈 대화가 영향을 미친 듯하다.
하지만, 좋은 그림이라고 감상하는 일에서 나아가 동료의 모델링 연구를 도울 수 있다는 생각에 떠오르는 생각을 기록하고 공유하기로 한다.
모델링 절차(modeling process)는 꼭 필요한가?
<도메인 모델링? 비즈니스 모델링 어떻게 하나요?>편에서 모델링에 대해 설명했으니 그 내용은 생략한다. 대신 질문을 이렇게 해보자.
모델링은 꼭 필요한가?
나는 경제성의 원리에 입각해서 답하면 된다고 본다. 투입한 노력 대비해서 의미 있는 결과가 나오는가? 나는 북경에 살 때 옆 단지에 사는 한국인 중에서 독일차의 실사 모형을 손으로 만드는 직업이 있다는 사실을 처음 알았다. 그리고 우리 주변에서 가장 흔하게 볼 수 있는 모형은 마네킹이나 (아파트 구성을 볼 수 있는) 모델 하우스 등이 있다. 또, 핸드폰 속에서 자주 열람하는 내비게이션도 모형이라 할 수 있다.
소프트웨어 개발로 돌아오자. 모델링은 왜 필요한가? 나는 2000년대 초중반에 '방법론자'라는 타이틀로 차세대 프로젝트를 수행한 경험이 있다. 프로젝트에서 구성원들이 어떤 역할과 책임(R&R)을 수행해야 하는지, 그리고 서로 소통은 어떻게 해야 하는지, 무엇을 만들어야 하는지 등에 대한 가이드를 내려주고 모범을 보여주던 일이었다.
다수 기업에 속한 새로운 사람들이 모르는 업무를 한 방에 새로 개발하는 차세대 프로젝트의 위험을 줄이기 위해 모델링 절차를 익숙한 해결사를 이용해서 프로젝트에 적용시키는 방법이다. 나는 그때 스스로를 '해결사'라고 불렀다. 누군가 확실히 알고 있는 사람에게 의존하는 방법은 편하긴 한데, 그 일이 지속될 수 있다는 보장이 없다. 큰돈을 들여 한 번 수행하는 빅뱅 형태의 프로젝트에서나 가능한 일이다.
그럼에도 불구하고 옛날이야기를 소환한 이유는 그러한 위험을 줄이려고 절차나 모델링이 등장했다는 점을 분명하게 하기 위함이다. 자 이번에는 인용한 DDD 모델링 절차 그림을 하나씩 뜯어보자.
지속적으로 반복하며 진화하는 설계 절차
아래 붉은색으로 표기한 내용을 보면 빅뱅 즉, 한 번에 정하는 식의 설계는 DDD 커뮤니티의 지향점이 아니다. DDD가 잘 어울리는 소프트웨어 분야는 기업용 소프트웨어이거나 비즈니스를 수행하는 사람들의 지식이 개발에 매우 중요한 영역이나 조직이다.
그렇다면 비즈니스 변화를 빠르게 반영할 수 있어야 한다. 그렇게 되면 자연스럽게 반복(interative)을 피할 수 없고 비즈니스 수행 속도를 위해 진화(evloutionary)해야 한다. 그렇게 지속적인 개발이라는 맥락을 띤다.
꼭 필요한 일을 어떻게 찾을 것인가?
반복을 상징하는 세 개의 서클이 있는데, 그 첫 번째는 Align과 Discover이다. 흔히 말하는 기획 혹은 분석의 영역이다.
업계 동료들과 함께 읽고 있는 <린 분석> 내용이 떠오른다. 통계 전공에 기업에서 분석 일을 하는 지인 덕분에 통계적 모델링에 대해 들을 수 있었다. 해당 논의를 하면서 모델링의 사업적 가치에 대해 논한 일이 있는데, 글을 쓰면서 위키피디아 정의를 찾아보았다.
A statistical model is a mathematical model that embodies a set of statistical assumptions concerning the generation of sample data (and similar data from a larger population). A statistical model represents, often in considerably idealized form, the data-generating process.
통계적 가정(statistical assumption)이라는 표현과 표본 데이터 생성(generation of sample data)이라는 표현이 눈에 띈다. 위 정의를 참조해서 내 이해로 통계적 모델을 사업에서 응용하는 이유를 설명해보자. 사업은 모호함 투성이의 시장 변화에 대처해야 한다. 가치 창출을 위해 경험과 지식으로 내린 사업적 가정을 데이터를 기반으로 분석하기 위해서 통계 지식을 활용하는 것이라 생각한다.
그리고 말 그대로 <프로그램이나 사업이나 끊임없이 변한다> 그래서, 기획이나 분석은 처음 한번 하는 일이라기보다 반복적으로 진화하며 계속하는 일이 되어야 한다. 현실적으로는 피드백 반영 혹은 개선을 위한 주기가 필요할 뿐이다.
사업 모델과 사용자 필요를 어떻게 연계하나?
Align에 대한 설명을 읽으니 당장 세 가지 항목 혹은 형식의 소통이나 지식들이 떠오른다. 하나는 얼마 전에 그린 Lean Canvas 혹은 사업 관계자들과 주고받은 다양한 형식의 도식화된 그림이다.
두 번째는 우리 회사 이사들과 사업 개발 파트너들이 카톡으로 소통하는 대화들이다. 실시간으로 흘러 다니는 대화 중에서 Align이라는 분류와 연관이 있어 보이는 대화를 일반화한 질문으로 바꿔보면 이런 식이다.
오늘 생겨난 새로운 이벤트가 기회인가?
이런 문제를 시장에서 고객들이 요구하는가?
이런 제안은 시장에서 받아들여질 수 있는가?
그리고 세 번째는 OKR이라는 형식을 활용한 정렬이다.
구체적으로 무엇을 만들 것인가?
탐색(discover)은 설명하면서는 영어 '부사' 두 개로 협업(collaoratively)과 가시성을 강조한다. 글자로 쓴 문장과 코드는 한번 봐서는 쉽게 눈에 들어오지 않는 탓일까?
DDD를 사용하지 않더라고 협업 공간에서 수 없는 그림이 매직으로, 파워포인트(키노트)로, Figma로 그려지고 돌아다니고 논의된다. 우리 회사는 도메인 스토리텔링 활용 방법을 개발하고 있긴 하지만, 협업 자체가 구성원과 상황에 맞게 쓰이는 일에 비하면 특정 방법이 그다지 중요한 것은 아니다.
그냥 짧게 생각해보려고 한 일인데, 글이 길어진다. 오늘은 이만하고, 다음 편에서 이어서 써야겠다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
