도메인 모델링에서 맥락은 왜 필요한가?
도메인 모델링 세미나 9
<도메인 모델링 활용의 기본 아이디어> 편에서 소개한 대로 도메인 모델링의 새로운 방법에 대한 연구를 진행하는 동료가 있다. 그에게 먼저 맥락도를 그려보자고 제안했고, 그 과정에서 만들어진 맥락도와 주고받은 대화에 기초해서 글을 쓴다.
맥락은 왜 잡는가?
나는 동료에게 Context diagram을 그려보라고 했다. 그는 내가 알려준 간단한 가이드에 기초해 Use Case 문법으로 맥락도(Context diagram)를 그린 후 스스로의 관점으로 자유형식으로 개선한 그림을 나에게 보여주었다.
나는 직관적으로 그가 무엇을 지향했는지 느낄 수 있다. 하지만 이는 모델러로 일한 경험에 기초한 것이다. 모델러로 훈련받거나 직업이 전문 설계자가 아닌 경우 이 그림에서 얻을 수 있는 메시지는 매우 희박하다. 대부분의 사람들은 자신의 직관에 따라 무엇이 떠오르는지 느낌을 추출한 후에 별다른 내용이 없으면 대략 이런 질문에 부합하는 내용에 대해서만 인내심을 갖고 상대의 말을 듣는다.
나와 무슨 관련이 있지?
나보고 무엇을 하라는 것이지?
어떤 (나에게) 이점이 있다는 것이지?
하지만, 나는 그의 그림이 잘 그려진 것이라 생각한다. 다만, 자신의 어휘와 사고방식으로 그려진 그림을 그대로 노출하여 동료들과 대화를 시도하는 일은 어리석은 시도다. 개발자들이 앞뒤 없이 복잡한 프로그래밍 용어를 남발하며 개발자가 아닌 사람들과 대화를 시도하는 장면을 종종 본다. 그런 경우 보통 '맥락 없이' 말한다고 할 수 있다.
내가 문제로 삼으려는 맥락과 대화를 위한 맥락
<성공적 대화를 돕는 그림> 편에서 다수의 동료들에게 써먹었던 그림을 정형화 한 바 있다. 업무 대화가 잘 이루어지지 않을 때 어떻게 풀어가느냐를 그린 그림이다. 이는 논리적으로 세 가지 맥락이 있다는 전제를 그린 것이다. 나와 듣는 이가 갖는 맥락은 기본적으로 따로 있고, 공통의 맥락을 형성했을 때만이 성공적인 대화가 이뤄진다는 믿음을 도식으로 표현한 것이다.
반면 동료의 그림은 복잡한 현황 파악을 하는 모델러 자신의 맥락을 잡아가는 과정이다. 나를 위한 맥락이 필요하다. 현상을 바라보는 기준을 설정하는 일이고, 다른 말로 문제를 정의하는 과정이기도 하다.
이런 경우 대략 이런 질문들이 사고의 배경에 흘러 다닌다.
누가 이해관계자인가?
무엇을 중심에 둘 것인가? 무엇을 넣고, 무엇을 뺄 것인가?
등장하는 요소들의 연관 관계는 어떻게 되는가?
이쯤에서 한번 정리하면 맥락은 분석을 위한 맥락 혹은 분석가(모델러와 같은 말로 쓰고 있다) 자신의 스케치 형태로 만들어질 수 있다. 다만, 그것을 분석가나 모델러가 아닌 다른 사람과 효과적으로 대화하려면 적절한 형식의 소통방식과 언어가 필요하다.
맥락을 기준으로 설명하면, 맥락은 모델링이나 분석을 위한 맥락이 있을 수가 있고, 대화나 회의를 위한 맥락이 있을 수 있다. 각각 그에 걸맞은 형식과 형태를 띠는 것이 좋다.
관련 글
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
