도메인 모델링? 비즈니스 모델링 어떻게 하나요?

도메인 모델링 세미나

<토비의 스프링3>로 유명한 일민형을 만난 날 그는 '도메인 모델링을 어떻게 하느냐?'라고 하는 답이 없는 질문을 던졌다. 나는 모델링을 업으로 살기도 했고, 지금도 항상 모델링을 직업 일상에 써먹지만 어떻게 배웠는지는 설명할 수 없다. (몇 년간 개고생 하라고 할 수는 없지 않은가?)

Lean Canvas 그리고 또 모델링

어제 회의에서 사업 모델에 대한 회의를 하는데 동료가 모델링을 어떻게 하느냐고 또 묻는다. 이번에는 도메인 모델링이 아니고 비즈니스(사업) 모델링에 대한 이야기로 주제가 바뀌었지만, 나의 모델링 노하우에 대해서는 아주 제한적으로만 답할 수 있다. 그래서 일부를 즉답하고 잊었다.

그리고 <린 분석>을 읽다가 우리 회사 서비스를 정비하기 위해 책에 나오는 Lean Canvas를 대강 그려봤다. 당초에는 두레이에 메모로 썼다가 LeanStack 이란 서비스에 계정을 마들고 그들이 주는 틀에 내용을 넣어봤다.

 

그랬더니 서비스에서 자동 발송하는 이메일이 왔다. 하나 그리고 났더니 쪼개서 그려보라고 제안한다. 그림에 포함된 MODEL이란 단어를 그냥 넘어갈 수가 없어 글을 쓴다. :)

Case/Type과 Instance

객체 지향 모델링 공부할 때 쌍으로 배운 개념과 바로 연결 지을 수 있다. 약간의 시간을 투자해서 그들에게 듣고 마음이 기억(?)하는 질문에 대해 기록하면 일부라도 노하우를 끄집어내 설명할 수 있겠다.

Lean Stack 측에서 보내준 이미지를 다시 보면 아래 시간의 흐름 표시가 있다. 내가 처음 그린 Canvas를 Big Idea Canvas로 취급하고 안내를 하는 메일이다. 이제 큰 아이디어를 그렸으니 세부적으로 고민해보고 좁혀서(Narrow and specific) 구체적인 변형을 만들어보라고 제안한다.

이건 Lean Stack 서비스의 사용법이기도 하고 그들이 제안하는 혁신을 지속하는 방법이지만, 지인들이 내게 질문한 모델링과 그 실체화(Realization)의 과정이기도 하다.

정적/구조 모델과 동적/행위 검증

예전에 UML을 한참 써서 소프트웨어 모델링할 때로 돌아가 보자. 당시 Static은 Structural과 거의 같은 말이었다. 정적 관점(Static Viewpoint)은 대개 구조를 알아내는 과정이기 때문이다. 반면에 Dynamic 은 Behavioral과 동의어로 쓰였다. 소프트웨어(혹은 소프트웨어와 상호작용하는 Actor)의 동작을 묘사하는 일은 결국 소프트웨어와 그 구성요소가 해야 할 행위와 그 순서, 규칙, 제약 사항 등을 밝히기 위한 목적이기 때문이다. 그래서 모델링을 오래 하면 이 두 가지 기준이 머릿속에 명료하게 자리 잡아 습관처럼 작동한다.

오늘 내가 처음 본 이미지도 두 개의 틀을 떠올리게 한다. 이제 구조에 대해 정의했으니 다이내믹스(물론 대상이 SW가 아니라 시장과 사업을 구성하는 요소들이지만)를 들여다보면서 구조를 다시 보라는 말이다. 정적 관점과 동적 관점의 상호보완의 관계다. 동적 검증을 통해서 더욱 견고한 구조를 알아낼 수 있다.

MVP와 모델링, 실체화

위 그림에서 Specific Variants를 Canvas로 그리는 대신에 만들어서 시장에 내놓으면 MVP(Minimum Viable Product)가 될 수 있다. 사업을 하는데 반드시 추상화 한 묘사나 Canvas가 필요한 것은 아니니까. 다만, MVP는 개발이 필요하니 개발 역량이나 돈이 필요하다. 이 과정에서 머릿속으로 만든 모델은 실체화되어 시장에 드러난다.

머릿속으로 만든 모델을 시각화하는 방법은 아주 다양한다. Lean Canvas로 그릴 수도 있고, 동료들을 위해 화이트보드에 매직으로 그림으로 묘사할 수도 있다. 표현 방법에 앞서 모델을 만들고(모델링) 실체화를 위한 협업을 이끌어내는 과정에 집중해보자.

그리고 우리는 유한한 시간(그리고 돈과 능력)을 갖고 있기 때문에 중요한 변수(기능, 고객, 서비스, 쓰임새)에만 집중해야 한다. 그 변수가 무엇인지 알기 위해 모델링을 한다.