도메인 모델, Ongoing 설계 그리고 정원관리
도메인 스토리텔링 응용 6
링크드인은 자주 쓰지 않지만, Vaughn Vernon의 글은 종종 살펴보게 된다. 보통 알림으로 뜨는 여러 개의 목록 중에 저자를 훑어 보는 식으로 링크드인을 사용하는데, 보자마자 클릭하는 확실한 사람이 그다.
도면이 설계는 아니다
모델링을 하던 시절 내 마음속으로 수도 없이 외쳤던 말이다.
Digrams are not designs.
'수도 없이'라는 표현속 잦은 빈도가 말해주는 것은 UML 모델을 그리는 이들이 그림 혹은 도면에 담기는 의사결정에 초점을 두지 않거나 그렸으니 그만이라는 태도가 마음이 아팠다. 이후의 소통에 소홀히 하는 일이 잦이 주니어 컨설턴트 시절 외롭고 힘들었다.
한편, Vaughn Vernon의 글은 어떤 맥락에서 등장했을까? 알 수 없지만, 나는 이 글을 동료 도메인 스토리텔러와 토론을 위해 쓴다. 오늘 그를 만난다. 그가 몇 달간 지속해오는 경험을 배경으로 내가 제시하는 이러한 화두를 갖고 대화를 하면 흥미로울 듯하다.
[공지] 해당 주제에 흥미를 가진 개인이나 기업이 쾌적한 회의 장소를 제공해주시면 공개적인 토론을 고려해볼 수 있습니다. 관심 있는 분은 gray@bettercode.kr 로 메일 주세요.
왜 Sooner than later 인가?
그의 글에서 설계 초점은 가급적 빨리 코드로 이동해야 한다고 말한다.
Sooner than later the design takes on a code focus, and the discovery continues.
하지만 앞서 전제한 지속적인 설계(ongoing design)를 고려하면 발견은 계속 된다. 그게 무슨 의미일까? 설계 결정이 옳든 그르든 상관없이 세상은 바뀐다. 그래서 코드든 설계 결정이든, 이들 모두는 릴리즈하여 사용자나 고객 등의 시장 평가를 받는 과정을 거친다. 그리고 나면 우리는 다양한 사실을 발견할 수 있다. 당연하게도(혹은 아쉽게도) 이는 계속된다.
Model-Driven 으로 시작하는 과거의 시행착오
최근에 가까운 지인이 domain model 이 무슨 말이고, UML을 모르는 사람들이 태반인 요즘에는 어떻게 표현해야 하느냐고 물은 일이 있다. 흥미로운 주제다. 나는 그 대답을 유보했다. 왜냐 하면 나도 찾는 중이기 때문이다. 도메인 스토리텔링 연재와 연구는 그 과정의 일부다.
대신에 나는 그에게 MDA 니 Model Driven Development니 하는 말로 과거에 업계가 시도했던 UML로 시각화 한 모델을 코드로 변환하려는 긴 시행착오에 대해 설명했다. 간접 경험이 주를 이루지만 20년 넘게 이를 시도하는 이들이 아직도 있다. 심지어 그 중에는 (무려 옛날도 아닌 최근인 2020년에 수행한) 금융권 차세대 프로젝트에서 시도된 일들도 있다.
그에 대한 내 생각은 Vaughn Vernon의 입장과 정확히 일치한다.
Diagrams help, but it's nearly impossible and certainly impractical to continuously sync with code.
내가 지인에게 주장한 문구는 이렇다.
모델의 가치는 추상화인데, 코드와 일대일대응을 시도하면 그 장점을 모두 훼손한다.
정원관리 혹은 가드닝(gardening)은 어떻게 하나요?
나는 최근 연이어 CTO 역할을 맡고 있는 또 다른 지인을 만났다. 그는 내가 <실전 시스템 수준 리팩토링>이란 이름으로 브런치에 연재한 가드닝에 관심을 보였다. 나는 요즘 그의 조직에 가드닝 역량을 배양하는 방법에 대해 궁리중이다.
도면(digram)과 설계와 가드닝이 무슨 관련인가? 최근에 모델링 관련해서 나와 대화를 한 지인들의 공통점은 이벤트 스토밍 등의 형태로 일회적으로 소통을 한 후에 기획이 구체화 되고 코드가 만들어지고 나면, 그 다음에는 어떻게 하느냐는 질문을 했다.
나는 매우 흥미로웠다. 나는 그들과 가까운 사이기는 해도 10년 이상 함께 일한 일이 없다. 그럼에도 불구하고 내가 도메인 스토리텔링 연구에 담고 있는 문제 의식을 그들도 갖고 있기 때문이다. 적어도 내가 헛짓을 하고 있지 않음을 보여주었고, 반대로 그들의 내공도 알 수 있었다.
코드 규모가 커지고 응용 프로그램의 사용자가 다양하거나 이해관계자가 복잡해지면 초반의 기획서로 소통할 수는 없다. 반면 코드는 리팩토링을 할 수 있다. 그렇게 기술 부채가 치명적인 수준에 도달하는 것을 막을 수는 있다. 하지만, 개발자가 아닌 이해관계자와 그 변화를 어떻게 공유할 것인가? 그리고 리팩토링에 상당한 노력이 든다면 그것은 왜 하는 것인지 개발자가 아닌 이해관계자에게 무엇이라고 설명할 것인가? 어쩌면 이러한 질문이 내가 도메인 스토리텔링 연구를 하는 이유인 줄도 모른다.
