모델링 과정을 역추적하기 위한 초벌 메모
어떻게 하면 모델링을 잘 할 수 있을까?
비즈니스 절차를 시각화하기 위해서 오래간만에 그림을 그렸습니다. 무료이고 유연성이 있는 툴 같아서 draw.io로 시작했습니다. 그림을 그리다 말고 모델링할 때 제가 어떤 사고를 하는지 기록해 두면 모델링에 관심을 드러낸 사람들에게 유용할지 확인해 보기 위해 상세하게 생각의 기록을 남기는 글입니다. 그런데 막상 쓰고 보니 부연 설명이 없으면 읽기 어려운 글이 되었습니다. 향후 읽을 만한 글로 발전시키기 전에 남기는 초벌 기록입니다.
누가 시작하느냐? 그런데 누가는 뭐라고 쓸까?
일단, 여기까지 그리다가 멈추고 글을 쓰게 되었습니다.[1] 절차이기 때문에 방아쇠를 누가 당기냐 하는 시작점이 중요합니다. 오랜 경험 탓에 입에 밴 '트리거(trigger)'를 우리말로 표현하느라 방아쇠라고 말한 것이죠. 흔히 사용자라고도 하고, UML 표기법에서는 액터(Actor)라고도 합니다.
draw.io를 쓴다면 왼쪽 메뉴에서 UML 그룹 하단에서 액터 아이콘을 찾을 수 있습니다. 클릭하면 그림 속에 액터가 하나 생기고 기본 이름으로 Actor라고 쓰이는데, 이를 선택한 후에 모델러 입맛에 맞게 고쳐야 합니다.
이때 이름이 중요합니다. 모델러는 자신의 그림에 있어서 전지전능한 신의 입장이 되는 것이니까요. 그림에 등장하는 요소에도 바로 모델러가 정체성(identity)을 부여하죠. 이때 어떤 것들이 예시가 될 수 있을까요? 제가 빠르게 검토한 후보들을 드러내어 생각을 나눠 보겠습니다.
그림의 맥락을 정하는 일
처음에 이런 고민을 왜 해야 할까요? <주문과 거래 우선으로 시스템 전체 맥락 잡기>에서 이미 설명한 바 있습니다. 그림을 그리려고 마음먹었을 때 방아쇠를 당기는 사람이 바로 모델러가 하려는 이야기의 내용을 결정합니다. 시스템은 사용자가 없는데 그 자체로 주체가 되는 경우는 극히 드물다 할 수 있습니다. 그래서, 그림에 담을 이야기의 주인공이 누군지가 바로 그림의 맥락을 결정합니다. 그런 점에서 시스템 구동의 맥락(context)을 결정한다고 할 수도 있습니다. 그런 이유로 액터 관점에서 시스템을 조망하거나 접점을 그린 그림을 Context Diagram이라고 부르기도 합니다.
글쓰기로 비유하면 액터 이름 하나 정하는 일이 사실 글의 주제를 정하는 일에 상응한다고 할 수도 있습니다.
드러난 것과 사람과의 관계
다음으로 액터의 어떤 행위를 표기한 단계로 돌아가 보겠습니다. 도식화하는 그림의 형태 위주로 말해 보면 액터(사용자라는 말로 대체할 수도 있어 혼용합니다.)와 어떤 노드(혹은 도형)와 그 관계(혹은 선)로 표현하는 경우가 아주 보편적입니다.
결국 절차를 표현하는 것이 목적이기 때문에 누가 어떤 일을 하는 것에 대해서 상세하게 서술할 때 문자 대신 도식화하는 것이 이점이 있다고 판단하니 모델링을 시작했을 테니까요.
이때는 한국 사람이라면 마주하는 일의 대표가 되는 사물(interface)로부터 사태를 파악하기 마련입니다. 마땅히 매개가 있어야 하죠. 그걸 한국말로 '드러난 것'이라고 부르죠. :)
관계를 인식하고 탐색하고 표현하기
그리고 관계는 존재 이전부터 있던 것입니다. 박문호 박사님 표현에 따르면 존재 이전에 관계가 있었다고 합니다. 한국말로는 '쪽인 나'라고 하는데, 모델링의 효용성에 있어서 이 부분이 굉장히 중요하다고 할 수 있습니다.
출처: https://brunch.co.kr/@graypool/1983왜 그런지 생각이 정리되지 않았었는데, 우연하게도 <AI 최강의 수업> 내용을 인용하여 설명을 시도해 봅니다.
모델은 현실 세계의 사물이나 사건의 본질적인 구조를 나타내는 모형이다. 현실 세계의 복잡한 현상을 추상화하고 단순화하여 모델로 표현한다.
기계 학습 맥락에서 모델링을 말하는 내용이지만, 제가 경험한 소프트웨어 모델링에도 그대로 적용할 수 있었습니다. 책 내용을 조금 더 인용합니다.
문제 풀이에 필요한 것만 추상적으로 표현하고, 적절한 수준으로 단순화시키는 것이 필요하다. 단순화를 적게 하면 복잡해서 수학적으로 해결할 수가 없게 되고, 반대로 지나치게 단순화시키면 해결할 문제가 현실과는 동떨어진 것이라서 효용성이 없다. 따라서 가급적 현실을 제대로 표현하면서도 문제 해결이 가능하도록 복잡도를 낮추는 것이 필요하다.
여기서 두 가지 내용을 추리면 고스란히 제 모델링에도 유효합니다.
문제(혹은 모델에 담으려는 내용) 풀이에 필요한 것만 사물과 관계로 드러냄
문제를 단순화하기 위해서 지나치게 복잡한 내용을 역할에 맞는 사물(혹은 객체)에 포함시킴
주석
[1] 본문에서 생략한 첫 번째 고민은 다이어그램 유형을 정하는 일인데, 오랜 경험을 압축해 보면 실질적으로 기본 형식보다는 템플릿이 유용하다 할 수 있습니다. 그런데 제 경우는 딱히 그런 것이 없다고 할 수 있어서 draw.io가 제공하는 것 중에서 제 기호에 맞춰서 이것저것 쓰게 될 듯했습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
10. 업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것
13. 프로그래밍에서는 몰라도 설계에서 작명은 엄청 중요하다
14. 설계란 결국 번역인가?
15. 설계를 번역이라 한다면...
