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

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

실전 도메인 스토리텔링 첫 시도에서는 도메인 스토리텔링이 무언지 다루기도 전에 '이게 쓸만한건지?' 혹은 '알 가치가 있는건지?' 확인하기 위해 일단 적용을 해보았다. 한 두 차례 짧은 시도에서는 효과가 있어 보어서 사둔 책을 읽기로 했다. 책은 아직 원서밖에 없어서 빠르게 보려고 킨들로 구매했다. 반가운 소식은 번역하고 있는 출판사가 있다는 사실이다.

도메인 스토리텔링으로 그린 도메인 스토리텔링 정의

책 앞부분에는 흥미롭게도 그들의 표기법으로 그들이 설명하려는 내용 즉, 도메인 스토리텔링을 정의하고 있다. 도입부에서는 글에 비해 말이 갖는 힘을 강조하는 인용문도 등장한다. 간단한 그림이지만, 짚어보면 흥미롭다.

출처: Domain Storytelling

먼저, 저자는 말로 하는 소통의 중요성을 강조한다. 그래서, 업무 전문가(domain expert)에게 구두로 듣고 개발자는 그린다. 이 과정에서 도메인 이야기(domain story)는 두 가지 성격을 띈다.

먼저, 개발자가 업무 전문가의 이야기를 잘 들었는지 확인하는 도구의 성격을 띄고

다음으로 도메인 전문가가 이해할 수 있게 그려야 한다

그래서, 이들은 쓰라(write)고 하지 않고 그리라(draw)고 한다. 2000년 초반에는 UML로 그려야만 개발이 될것처럼 프로젝트를 하던 분위기였는데, 지금은 그걸 쓰는 사람은 거의 없다. 그런데, 다시 그리라니... 역사는 반복되는구나!

이야기의 힘을 사용하기

도입부를 읽으면서 이들이 Ubiquitous Language 구현방편으로 도메인 스토리텔링을 내놓았다는 생각이 들었다. 그리고, 이렇게 대화로, 또 도식화하는 그림으로 확인하는 방식으로 해서 얻는 이점을 몇 가지 열거한다. 대부분 과거의 소프트웨어 공학의 유사방식에도 쓰일법한 내용이다. 차이점 관점에서 보면 암묵적으로 느껴지는 두 가지가 있다. 먼저 애자일 소프트웨어 개발을 전제로 한다는 점이 가장 커보이다. 그리고, 책에서 직접 언급한 내용은 없지만, 굉장히 적극적인 소프트웨어 개발자들의 문화란 점이다.

언젠가 기획이 잘 나오지 않아서 개발 진도가 안나간다고 비판하는 팀과 대화를 한 일이 있다. 이때, 기획을 책임지는 곳과 개발자들을 따로따로 만났을 때, 서로 정반대의 입장이지만 나름 일리가 있었다. 개발자들은 무엇을 해야 할지 정의하는 임무는 기획에 있다고 말한다. 기획관점에서는 (과거에 일했던) 노련한 개발자와 달리 현재 개발팀은 수동적이라고 말한다.

엉킨 실타래를 풀기 위해서는 어디서 출발하느냐가 중요하다. 그게 만약 생산의 주체인 개발자라면 이런 그림 즉 도메인 스토리텔링이 등장할 수 있다. 이런 생각의 흐름으로 나는 이들의 적극성과 주체성을 깨닫는다. (역설적으로 외주 개발 프로젝트에서 실행은 안하면서 자신들이 생산물의 주인이라 생각하는 방식의 폐단도 깨닫는다)

흐름 혹은 줄거리를 강조하기

내가 처음 그렸던 그림들과 책의 설명 그리고 인터넷의 예시(아래)를 비교해봤다. 첫 번째 다른 점은 이야기 줄거리를 따르는 도식화가 도메인 스토리텔링의 전형적인 방식이란 점이다.

나는 대화의 성격도 그랬고, 낯선 표기법이란 점도 작용했지만 시스템이 쓰이는 맥락 전체를 살피는데 썼다. 하지만, 전형적인 도메인 스토리텔링을 그리는 방식은 이야기처럼 흘러가도록 하는 일이다. 그러면 누가, 무엇을, 어떻게 하는 식으로 순서대로 이야기를 풀어가야 한다. 영어로 표기한다고 하면 위의 그림처럼 화살표가 동사가 되기도 하고 전치사 to, on 등이 되는 흐름이 자연스럽다.

일단, 이런 흐름으로 그려보는 일을 몇 번 더 시도하고 책을 읽어봐야겠다.