brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Apr 21. 2022

도메인 스토리텔링에 문법 입히기

도메인 스토리텔링 연구 No. 8

지난 글에서 예고한대로 나는 동료와 함께 도메인 스토리텔링에 문법을 입힐 예정이다.

UX 전문가가 구어체로 읽으면서 시각화 한 표현이 술술 읽히기를 바라는 마음에 몇 가지 제안을 했다. 나는 마치 <Ubiquitous Language>가 만들어지는 장면을 보는 듯했다. 긴 시간 애정을 갖고 있던 <Ubiquitous Language> 가능성이 보이자 나는 개입하지 않을 수 없었다. 그래서 잠시지만 스토리텔러와 표기법을 문법처럼 만드는 시도를 했고 가능성을 엿보았다. 우리의 앞으로 여정해서 복잡하지 않은 그렇지만 쓸만한 문법이 만들어지지 않을까 기대할 수 있던 장면이었다.

문법을 입힌다는 말은 무엇일까? 명확하게 정의하고 일을 하는 타입은 아니지만, 머릿속에서 꺼낼 수 있는 몇 가지 의도나 가정은 다음과 같다.

화살표에 문구만 잘 붙여도 소통이 훨씬 좋아진다

이왕이면 가지런하고 일관성있게 표현하자

우리만의 관용표현으로 의미를 농축할 수 있다


첫 번째 문법 개발 광장

먼저 동료 스토리텔러가 질문 두 개를 들고 왔다. 그의 질문 방식이 흥미로웠다. 어려움을 느끼거나 마음에 들지 않는 부분 두 개를 지적하더니 뒤이어 <Domain Storytelling>책 에 나오는 매끄러운 표기법처럼 할 수 없냐고 묻는 것이었다.

답을 하기 전에 나는 짜릿함을 느끼지 않을  없었다. 사회 초년시절 5 이상 ~하게 모델링을 했고, 열심히 이론 공부도 했지만 이미 15년도 넘은 이야기다. 스타트업 경영을 하는 입장에서 진득하게 이런 책을 읽을 여유는 없다. 그런데 이렇게 질문을 받으니 마치 어린 새가 둥지에서 모이를 받아먹듯 내용을 흡수할  있었다.


나는 책의 문구와 그림을 보자마자 구체적으로 읽지 않아도 그 의미를 알 듯했다. 그리고 두 상황이 다른 점에 기초하여 동료에게 설명했다


동일 Work object에 Load와 Show 관계로 구분하기

허락없이 책을 인용할 수 없어 예시를 붙이지 못하는 것이 아쉽지만, 도메인 스토리텔링에는 Work Object 개념이 있다. 객체지향이 떠오른다. 시스템과 사용자의 상호작용에서 개체로 분명히 드러나는 것을 칭한다고 할 수 있다. 동료는 책에서 동일한 work object에 대해 사용자가 Load 하고 Show 하는 관계선을 매력적으로 느꼈다. 간결함과 대칭 때문이었을까?


그에 반해 동료의 그림에는 동일 대상을 아래와 같이 표현하고 있다. 나는 옳고 그름으로 보기 보다 그가 바라는 방향으로 피드백을 주려고 했다.


나는 Load 하고 Show 하는 시나리오가 극장 예약을 배경으로 하고 있음에 착안해 추정하여 설명했다. 책을 읽은 상태가 아니기 때문에 저자의 의도라기 보다 '나라면' 혹은 '모델러가 그렇게 할 근거'를 설명하는 일이었다. 대체로 Load는 프로그램이 후보를 추출하는 과정이다. SQL의 Select 문장을 포함한 구현이 있기 쉽다. 그리고 나타난 대상(주로 목록으로 보이는)을 가지고 사용자가 의사결정을 한다. 그 앞의 과정에서 Show가 필수적으로 필요하기 마련이다. 이렇게 동일 대상에 대한 비대칭적인 조작이 시스템 구축에서 흔히 일어나는 패턴이다.


사용자의 시스템 진입 경로

두 번째는 사용자가 알림톡을 통해 인지하여 화면을 보는 경우와 같은 화면을 보지만 스스로 찾는 경우를 간결하게 표현하고 싶어했다.

여기에 대해서는 20년 가까운 내 경력에서 배운 패턴을 설명했다. 대체로 시스템 사용자들은 세 가지 경로를 쓴다. 하나는 메뉴가 제시하는 차림표를 보고 사용한다. 마치 인터넷 초창기에 야후가 대세였던 것처럼. 그리고 MS-DOS를 써본 분들은 숫자로 누르는 메뉴들로 꽉 짜여진 화면을 기억하실 수도 있을 것이다.


두 번째는 바로 검색을 통한 방법이다. 구글이라는 회사가 세상을 지배하는 일의 시작은 누구나 알다시피 거대한 인터넷의 검색 엔진 역할을 통해서다. 세 번째가 바로 채팅이나 알림톡을 통한 통지 방식이다.


유익한 시간, 그리고...

짧지만 굉장히 유익한 토론 세션이었다. 동료는 흡족해하며 자신이 배운 바를 기록했고, 토론 이후에 책에 내가 설명한 내용이 그대로 나온다며 흥분했다. 옆에서 나는 이런 방식으로 책을 읽는 방법이 매우 효과적이라는 사실을 깨달았다. 안 그랬다면 얼마나 지루할텐가?


그가 흥분에 취한 동안 나는 그림에서 아래 부분을 주목했다. 하나의 시스템으로 향하는 화살표가 몰려있는데 저걸 하나로 두면 Monolithic 이고 둘로 명시적으로 나누면 BoundedContext 혹은 마이크로 서비스를 지칭할 수 있다. 하지만, 경험상 정리되지 않은 아이디어로 토론 후의 깔끔할 기분을 망칠까봐 후일로 묻어 두었다.



지난 도메인 스토리텔링 연구

1. 실전 도메인 스토리텔링 첫 시도

2. 도메인 스토리텔링은 무엇인가?

3. 도메인이 무엇인가요?

4. 설계서가 아니라 의사소통

5. 동료의 도메인 스토리텔링 활용

6. 도메인 스토리로 대화하기

7. 도메인 스토리로 비즈니스 규칙 발견하기


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari