모델링 과정의 효용성과 모델링 결과의 쓰임새
설계: 생각을 ‘차려’ 물질로 만드는 힘
<내가 아닌 다른 사람은 모델링을 왜 하게 되는가?>를 쓰고 동료 개발자와 설계에 관심이 많은 개발자분들께 피드백을 구해 보았습니다. 피드백 내용 그리고 그 과정에서 배운 내용을 글로 씁니다.
피드백은 다음 세 가지 갈래로 나눌 수 있었습니다.
형식보다는 내용과 소통을 중시하기
각자의 표준을 인식하기
모델링 표기법
이들 두 가지에 대해 간단히 설명한 후에 피드백에 포함되어 있지 않지만, 피드백을 받고 나서 추가로 깨달은 내용을 설명하는 것으로 글을 마무리하겠습니다.
형식보다는 내용을 중시하기
<내가 아닌 다른 사람은 모델링을 왜 하게 되는가?>를 쓰면서 나도 모르게 작성자가 의도한 바와 전달된 내용이 일치되기를 바라는 믿음이 마음 안에 있다는 사실을 깨달았습니다. 그래서, 우선은 대화할 때 화자에 해당하는 모델러의 생각부터 읽자고 마음먹었던 것이 아마 글에도 담긴 듯합니다. 특히 저를 자주 본 동료들은 이를 정확하게 읽어 내었습니다.
회사 동료는 다음과 같은 자기 경험으로 공감하는 부분을 피드백했습니다.
도메인 전문가가 그린 장표가 체계가 없고 엉성하기도 해 조금은 우스워 보였는데요. 설명을 듣다 보니 정말 중요한 것은 표기법이 아니라 지식을 효과적 기록할 수 있는가 그리고 상대에게 전달할 수 있는가였다는 것을 깨달았습니다. 그리고 스스로 되돌아보았습니다. 내가 UML로 모델링하는 것이 상대와 효과적으로 소통을 하고 있는지... 아니었습니다. 그 깨달음으로 상대도 익숙한 마인드맵으로 그리며 함께 소통했고 결과적으로 상대에게서도 좋은 평가를 받았습니다.
각자의 표준
한편, 또 다른 지인은 '협상론적 세계관'을 표현하는 말이기도 한 포기말(문장)을 자신의 소감에 소제목으로 사용했습니다.
상대방이 따르는 표준을 활용하라
그러면서 6년 전 제가 중국에 있던 시절 개취인정의 소중함을 깨달으며 썼던 글을 인용했습니다. 표기법 혹은 개인의 취향과 같이 드러나는 결과의 모양에만 초점을 맞추면 나의 믿음이나 기호를 중심으로 논쟁을 벌일 가능성이 높아집니다. 그렇게 되면 마주하는 대상과 협력자가 되지 못하고, 경쟁하거나 감정적 갈등을 유발할 수 있습니다.
그러니 우선 소통에 초점을 두려면 가급적 상대방의 표준을 따른 이후에 내가 중요하게 생각하는 내용을 다시 다루는 편이 좋겠다는 생각이 들었습니다. 단계를 두고 일의 순서를 세우는 것이죠.
더불어 표현 방식의 기준을 정하는 표기법에 대한 피드백도 있었는데, 모델링 표기법에 대한 내용은 이후에 별도 글로 다루겠습니다.
모델링은 대화와 구분할 수 있는 지적 작업
한편, 피드백 과정에서 뜻밖의 소득이 하나 더 있었습니다. 모델링의 소통 기능을 강조하는 것이 지나쳤다는 점을 깨달은 것이죠. 무슨 말이냐고 하면, 모델링을 하는 사람들은 대개 모델링을 하고 나서 그 결과로 대화의 효과를 높이고자 합니다. 즉석에서 그림을 그리기도 하지만, 꼭 그렇지는 않죠. 즉석 그림을 논외로 한다면 모델링 과정과 대화 과정은 구분할 수 있습니다.
그리하여 모델러는 모델링 세션이라고 부를 수 있는 독자적인 작업 시간을 갖게 됩니다. 지난 글에서는 제가 모델링을 하지 않고, 다른 사람 작업 결과를 보고 생각했던 터라 이를 간과했습니다.
암튼 모델링을 한다고 가정하면, 이때 우리가 스스로 내릴 수 있는 많은 결정 예를 들어, 내용을 이해하고 그중에서 당장 담고 싶은 내용을 고르는 판단을 한다는 사실을 간과했던 것 같습니다. 그렇게 추출한 내용은 어떤 면에서는 (지금 브런치에 쓰는) 글쓰기처럼 일종의 창작 행위기도 하여 건강한 긴장감과 즐거움을 주기도 합니다.
요약하면, 모델링을 소통 과정에 포함시켜서 보면 모델 작성 과정에서 행하는 모델링의 즐거움과 결과 이전에 모델링 과정에서 생각이 차려지는 효용성을 놓치게 될 우려가 있다는 생각을 할 수 있었습니다.
모델링을 해서 이익을 얻는 사람과 집단은?
여기에 더하여 한 가지 더 생각할 수 있었습니다. 대부분의 창작 작업이 그러하듯이 작가와 독자 혹은 크리에이터와 소비자의 비율에는 만드는 이는 소수고 보는 사람은 많다는 패턴이 있습니다. 모델링 역시 그림을 그려내는 사람은 어떤 조직이건 소수인 경우가 대부분입니다.
‘개발 표준‘을 강조하던 시절에 현장에서 UML을 쓰면서 도리어 오용 사례를 많이 보았습니다. 그런데 UML을 잘 보기 어려운 요즘 오랜만에 UML이 적절한 곳에 쓰이는 것을 보고 반가워서 기억에 남은 사례가 있습니다.
중국의 콰이쇼우(快手)라는 일종의 앱 플랫폼에서 제공하는 개발자용 API를 설명하는 문서에 등장하는 UML 순차도(sequence diagram)인데, 메소드 시그너처만으로는 구동하는 순서와 예외 사항에 대한 대처 따위를 설명할 수 없기 때문에 그려진 그림으로 추측할 수 있습니다.
출처: https://mp.kuaishou.com/docs/develop/server/epay/applyIntra-new/serverIntra-new.html
내용을 떠나 여기서 다루고 싶은 아이디어는 바로 API 제공자의 경우 다른 개발자들이 API를 쓰게 하기 위해 모델을 만들어 유지할 동기가 생길 수 있을 듯합니다.
형식적 쓰임이 아니라 모델링 결과가 효과적으로 쓰일 수 있는 전형적 사례가 될 수 있다는 생각이 듭니다. API 제공자 입장에서는 긴 텍스트로 설명하는 대신에 시각적 표현으로 정보 전달이 잘 된다면 모델링을 해서 얻는 이득이 클 테니까요.
