어떻게 하면 모델링을 잘할 수 있을까?
<사고와 인식과 표현의 주체인 임자로 욕망을 바라보기>를 읽고 yeti님이 다음과 같은 의견을 주었습니다.
액터는 소프트웨어 세계에서는 트리거의 역할을 한다는 것
설계는 모델러는 이해관계자들의 욕망을 표현한다는 것에서는 공감을 했습니다.
이어서 멀티 레이어링을 적용해 봤습니다. (맞게 적용한 것인지는 모르겠습니다.)
예를 들어 소프트웨어를 설명하는 관점(소프트웨어 설계)에서 액터나 사용자의 역할은 트리거로 한정하고 관심사를 소프트웨어의 동작을 표현하는 것에 두지만
마케팅이나 서비스 의사결정(서비스 설계)에서 사용하는 액터나 사용자는 페르소나를 가진 집단으로 정의하는 것입니다.
이를 두고 모델링[1] 관점에서 생각을 쓰는 글입니다.
우선 yeti님이 멀티 레이어링 적용이라 쓴 내용을 시각화해 보겠습니다. 생각이나 대화의 맥락을 두 개의 층으로 나눈 후에 Actor를 바라보는 관심사를 두 층에 다르게 포함시켜 본 것이죠.
앞서 <모델을 그리기 전에 '생각의 종이'부터 준비하세요>에서 '진흙 같았던 사태를 구조로 차려내기'란 표현을 쓴 일이 있습니다. '진흙에서 구조를 향해From Mud to Structure'라는 패턴을 설명한 내용이었습니다. 모호한 사태를 조금씩 밝혀 나가며 구조를 만드는 패턴을 말합니다. 멀티 레이어링도 이와 관련이 있습니다.
인터넷에서 발견한 문서에 따르면, '진흙에서 구조를 향해From Mud to Structure' 패턴은 세 개의 다른 패턴으로 구성됩니다. 그중 하나가 '층을 이용한 아키텍처Layered Architecture'인데, 저자는 이렇게 설명합니다.
It helps to structure applications that can be decomposed into groups of tasks
층별로 작업(task)을 나눠서 묶을 수 있다는 말이죠.
저는 아주 공교롭게 OSI 7 layers를 배우던 때에 포토샵도 함께 배웠습니다. 그런 경험 덕분에 레이어링(layering)이라는 개념을 다룰 때 아키텍처 패턴뿐 아니라 레이어를 사용하는 도구에서 흔히 쓰던 기법도 모두 레이어링이란 개념으로 묶어서 인식할 수 있었습니다.
포토샵으로 이미지를 구성할 때 대개의 경우는 반드시 레이어(layer)를 나눠 연관 있는 요소별로 작업한 후에 마지막에 병합(merge) 해야 했습니다. 이는 복잡한 요소들을 다루거나 생각을 다룰 때 함께 다룰 것들을 일종의 층(層)으로 대응시키는 사고법입니다.
물론, 이미지를 층으로 나누어서 각각 배치하고 합치는 작업이나 생각으로 층을 만드는 일은 다른 쓰임새입니다. 하지만, 시각화하다 보면 둘이 굉장히 비슷하게 느껴지기도 합니다. 또한, 수학적으로 생각해 보면 각 레이어(혹은 층)를 집합이라고 할 때 집합에 요소를 정의하는 일로 추상화하면 같다고 할 수도 있습니다. 또한, 포토샵에서 UI 요소를 층으로 나누는 일에는 추상이 개입된 것이라 할 수 있습니다. 다소 장황한 듯도 하지만 멀티 레이어링(Layered architecture) 혹은 층을 이용하는 방법에 대해서 충분히 설명한 듯합니다.
마지막으로 yeti님 의견에 두 가지 덧붙이고 싶은 내용이 있습니다. 첫 반째로 당시 대화를 두 개의 층으로 나눠서 이해하는 것은 바람직하지만, 저런 구분이 레이어링의 전형이나 흔히 사용하는 양식으로 보기는 어렵다는 점입니다.
업무 절차나 비즈니스 프로세스는 다양한 형태의 도식화를 볼 수 있습니다. 심지어 UML 최신 스펙에도 비즈니스 절차로 보이는 그림에 대한 표현이 있습니다.
두 번째는 Actor 정의인데요. UML 정의에 따라 의미를 엄격하게 한정하면 사실은 시스템의 경계를 표현하기 위한 개념이기도 합니다.
An Actor specifies a role played by a user or any other system that interacts with the subject.
시스템이 만드는 어떤 행위(action)를 촉발하는 방아쇠(Trigger) 역할을 한다는 측면이 부각되는 것이죠. 대개 시스템은 외부 연동을 위해서는 인터페이스(Interface)가 있어야 하기 때문에 Actor 정의가 꼭 필요한 것입니다. Actor가 사람이면 User Interface를 만들어야 하고, Actor가 다른 시스템이면 API와 같이 전자적으로 소통 가능한 인터페이스가 필요하죠.
이를 알고도 <사고와 인식과 표현의 주체인 임자로 욕망을 바라보기>에서 Actor와 User의 차이를 두지 않고 소통한 이유는 정교한 표현 이전에 모델에 무엇을 담아야 하는지를 소통하려 했기 때문입니다. 액터 이면에 있는 사람들의 욕망이 시스템 행위의 출처란 점을 설명하고 싶었던 것이죠.
사람이 서로 대화를 거듭하고 알아갈수록 소통이 정교해지고 짧아지듯이 소통을 위한 도구인 모델링도 비슷하게 변화 속에서 다른 용도로 쓸 수 있고, 사실상 그렇게 되기 마련입니다.
[1] 달리 표현하면 '생각을 어떻게 차려서 시각화하는지'를 뜻합니다.
3. 모델링을 Actor로 시작한다는 의미는 무엇인가?