모델링 도구 사이에서 방황하는 모습을 보면서
어떻게 하면 모델링을 잘할 수 있을까?
실험적으로 써 본 draw.io 이미지를 며칠 안 보다가 다시 쳐다보니 마음에 들지 않는 구석이 있었습니다.
그래서 자유 형식으로 다시 그리는 자신을 돌아보며 생각을 기록하는 글입니다.
자유 형식은 어떤 효용성을 주는가?
툴이 제공하는 형식을 벗어나 자유를 추구하는 이유야 기호나 편의성이라 할 수 있습니다. 하지만, 제 기호라고 하더라도 일시적이 아니라 반복되는 부분이라면 나름의 의미가 있을 듯했습니다. 이를 토대로 사람들과 의견을 나눠 보면 또 보편성을 찾을 수도 있을 것이란 기대로 글을 씁니다.
자유 형식이라고 말하기는 했지만, 말로 하는 소통보다 이점이 있으니까 그리려고 했을 것입니다. 자신을 두고 남처럼 이야기하려니 우습기도 하네요. 직관적으로 추정해 보면 흐름이 드러나게 하는 부분이나 기호와 이미지화로 내용을 강조하거나 간소화하는 효과를 덧붙인 것이 아닐까요? 기호와 더불어 나름의 규칙도 몇 개 부여했습니다. 읽는 사람과 보는 사람 사이에서 간단한 확인으로 소통이 가능한 수준의 규칙이죠. 반면 누구나 직관적으로 알 수 있는 보편적 내용이라고 할 수는 없습니다.
기획서가 모델인가?
그런데 글을 쓰려고 그림을 보면서 속말이 들리는 듯했습니다. 제가 자유 형식이라 부른 그림을 두고 상당수의 개발자들은 그건 기획서이지 모델은 아니라고 말할 듯했습니다.[1] 그분들에게 미리 하고 싶은 말이 있습니다. UML을 쓰든 안 쓰든 도식화한 그림은 모델이라는 사실입니다. 지난 글에서 인용했던 모델의 정의를 다시 볼까요?
모델은 현실 세계의 사물이나 사건의 본질적인 구조를 나타내는 모형이다. 현실 세계의 복잡한 현상을 추상화하고 단순화하여 모델로 표현한다.
모델로 표현한 것은 소통을 위한 도구로 쓰입니다. 그렇다면 첫 번째 모델과 두 번째 모델이 지향하는 소통은 다르다고 말할 수도 있을 것입니다. 지난 시간에 그린 그림을 불러와서 제가 무엇을 표현하려고 했나 돌아보았습니다.
대체적인 기능의 흐름을 형식화하려고 했습니다. 방아쇠를 당기는 사람과 일이 흘러가는 흐름이 사물에 어떻게 담길 수 있는지 개괄적으로 표현하려고 했습니다. 그러면서 자연스럽게 기능과 파라미터화 즉, 기능 구동을 위해 주고받는 내용이 나뉘게 하는데 관심이 가 있었습니다. 방금 저는 모델의 바탕을 구성하는 맥락을 설명했다 할 수 있습니다.
각각의 모델이 갖는 맥락들
기획서라고 볼 수도 있는 두 번째 모델의 맥락은 무엇일까요? 일단, 개발자에게 개발을 의뢰하기 위해서 최적의 모델을 그린 것입니다. 최적의 모델이라고 하니 거창하게 느껴지는데, 사실 가장 적은 노력으로 명확하게 전달하고 싶었습니다. 역시 지난 글에 인용한 내용을 가져온 후에 '문제 풀이' 자리에 '(프로그램) 개발'을 넣으면 대강의 의미가 통한다는 생각이 듭니다.
문제 풀이에 필요한 것만 추상적으로 표현하고, 적절한 수준으로 단순화시키는 것이 필요하다. 단순화를 적게 하면 복잡해서 수학적으로 해결할 수가 없게 되고, 반대로 지나치게 단순화시키면 해결할 문제가 현실과는 동떨어진 것이라서 효용성이 없다. 따라서 가급적 현실을 제대로 표현하면서도 문제 해결이 가능하도록 복잡도를 낮추는 것이 필요하다.
제가 그린 모델을 다시 볼까요?
그런데 이 정도만으로 충분히 개발이 가능할까요? 경험상 그렇지는 않을 듯합니다. 다만, 제 경우는 구두 소통으로 보완할 수 있는 관계이기 때문에 모델에 모두 표현할 필요는 없는 것이죠.
모델링 도구를 선택하는 기준
지금까지는 내용 면에서 두 그림을 비교했는데, 이번에는 다른 잣대로 둘을 비교하
먼저 도구를 선택하는 저의 기준부터 보겠습니다. 첫 번째로 분명한 것은 사전 준비 없이 바로 사용할 수 있는 것을 고른다는 사실입니다. '사전 준비 없이'를 더 구체화하면 별도로 배우거나 설치할 필요가 없어야 한다는 것입니다.
브라우저에 draw.io 만 입력하면 되니까 draw.io를 썼다 할 수 있습니다. 써 본 소감은 3년 전에 <도메인 스토리텔링은 무엇인가?>를 쓸 때 발견한 egon.io 에 비해 큰 장점은 확인할 수 없었다는 정도입니다. 그래서 다시 표현력이 뛰어난 키노트 앱을 쓰는 것이죠. 키노트 역시 파워포인트보다 편의성이 떨어지지만 맥북에 이미 깔려 있어서 '사전 준비 없이' 쓰고자 하는 제 의도가 반영된 선택입니다.
사전 정의한 스키마 對 일단 그리기
그런데 이들 둘을 차근차근 비교해 보았더니 굳이 따지지 않았던 본질적 차이가 분명해졌습니다. draw.io와 egon.io 모두 사전에 정의한 아이콘을 불러온 후에 위치, 레이아웃, 크기, 라벨과 관계 따위를 설정합니다. 이 단어가 어울리는지 분명하지 않지만 사전 정의한 스키마가 있는 듯한 인상을 받습니다.
마치 <비대칭적인 일상의 순간이 알려준 이벤트와 스키마 대응>에서 RDBMS에 설정한 스키마처럼 말이죠. 반면에 다음 그림의 도형은 그 자체가 스키마를 내포했다고 할 수는 있지만 사전 정의하지 않았고, 형식화가 필수적이지도 않습니다. 마치 JSON으로 스키마를 다루는 일처럼 말이죠.
개발자라면 엄격한 타입 시스템을 쓰는 일과 Duck 타이핑의 관계에 비유할 수도 있습니다.
반복 참조를 하기 위한 방안은?
마지막으로 앞서 던졌던 질문 '기획서인가? 모델인가?'를 다시 소환합니다. 제가 자유 형식을 보면서 떠올린 질문이었습니다. 그런데 그 질문 너머에는 기획서처럼 보일 수 있지만 모델을 그리고 싶었던 마음이 있습니다. 그게 과연 무엇일까요? 지난주에 잠깐 봤던 이미지가 저에게 실마리를 주었습니다.
넷플릭스의 아키텍처를 한 장으로 요약한 그림에서 API 요소에 대해 채택한 기술이 바로 GraphQL이었다는 점입니다. 무슨 말인고 하니 제가 기획서와 모델을 구분한 결정적 기준은 '현행화' 혹은 '반복 참조'의 필요성입니다.
기획서나 모델의 형식과 무관하게 모델 저장소가 있어야 하고, 그리고 그 저장소의 형식을 떠나서 마치 검색하듯이 이를 찾아볼 수 있어야 자주 쓰이고 또 현행화되어 시스템에 자리하는 규칙으로 살아남을 수 있습니다. 그것이었군요! (유레카)
주석
[1] 종종 책 속이 아닌 업계에 있는 분들과 만나면 구체적인 형식과 이름 안에서만 소통을 하기도 합니다. 생산성이 중요하고 즉각적 결과로 답을 내는 직장에서는 추상적이거나 모호한 내용을 잘 다루지 않는 일은 어찌 보면 당연한 일이라 하겠습니다. 하지만 그래서 생기는 부작용도 있습니다.
