모델링에서 행위자를 뽑는 일은 시스템 맥락을 만드는 일

어떻게 하면 모델링을 잘할 수 있을까?

May 8. 2025

<사용자 경험과 연결되는 도메인 이벤트 설계 품질>을 읽고 소프트웨어 설계를 공부하는 바로 그 동료가 다시 자신의 피드백을 보냈습니다.

운전자를 모델로 드러낼 것인가?

동료의 피드백을 찬찬히 보면서 의견을 내놓고 생각할 거리를 풀어 보겠습니다.

먼저 첫 번째 내용은 제 글을 보고 동료가 배우고 익힌 내용이라 하겠습니다. 다만, 동료의 글 즉, '현실 세계에서는 운전자가 정산이라는 행위를 함'을 보면 액터(Actor)로 운전자를 모델링할 필요를 인식한 것으로 볼 수 있습니다. 행위를 하려면 행위자가 필요합니다.

시스템 맥락도/문맥도에 대한 복습

그렇다면 시스템 맥락도 혹은 문맥도에 대한 복습을 하기 좋은 타이밍입니다. 예전에 <시스템 구동의 맥락(context) 파악하기>를 쓴 일이 있습니다.

이번에는 객체지향적으로 표현해 볼까요? 객체지향에서는 시스템 전체도 하나의 객체로 볼 수 있습니다. 객체는 자신을 보호하기 위해 경계가 있어야 합니다. 그 경계 중에서 상호작용을 위한 통로가 필요한데 그 통로를 식별할 때, 사용하는 개념이 Actor입니다. 앞서 동료가 깨달은 내용을 다시 보겠습니다.

현실 세계에서는 운전자가 정산이라는 행위를 함

바로 이런 순간에 Actor를 포착합니다. 개발자[1]가 이렇게 시스템과 상호작용하는 대상인 Actor를 모두 포착하고 그 상호작용 내역을 파악하여 그린 그림이 바로 Context diagram입니다. 한국말로는 시스템 맥락도 혹은 문맥도 따위로 말할 수 있겠죠.

출처: 위키피디아

정산 과정에서 고려해야 할 사용자의 입장을 기억하는 일

그런데, 운전자는 Actor로만 등장할 수 있을까요?[2] 기술적 맥락을 벗아나 경제적 맥락[3]의 생각을 잠시 해 보겠습니다. 여러분이 모델링하는 이 시스템이 돈을 많이 벌어야 한다면 고객(혹은 사용자)의 관심과 (돈을 지불할 수준의) 애정을 충분히 받을 수 있어야 합니다. 이를 위해서 정산 과정에서 고려해야 할 사용자의 입장을 기억하는 일은 매우 중요할 수 있습니다.

가령, 제 아내가 운전할 때를 생각하면 다음 두 가지 행위가 꽤 중요한 사용자 경험(UX)으로 보였습니다.

다자녀 할인을 자동인식해 주면 좋은데, 인터폰으로 누군가와 통화를 해야 하는 경우가 있다

이마트는 전자 영수증을 받는 순간 주차할인증 대신 자동 정산해 주는 기능이 있어 (다른 곳보다) 편하다

위와 같은 사용자 경험을 구현하려면 운전자마다 주얻지는 어떤 정보를 모델링해야 합니다. 어떤 이름이 좋을지 바로 떠오르지 않아 퍼플렉시티에게 후보를 추려 달라고 했습니다.

제 바람과는 조금 다른 결과들이지만, 이다음부터는 케바케의 영역으로 두고 글을 마칩니다. 동료의 피드백은 아직 4분의 1만 다룬 것이라 다음 글에서 계속합니다.

주석

[1] 과거에는 이런 역할을 분석가라 칭했습니다만, 포괄적으로 모두 개발자라 통칭하겠습니다. 다시 말해 요즘 개발자는 분석, 설계도 모두 함께 할 수 있다는 가정을 깐 글입니다.

[2] 종종 현실과 학습 내용과 괴리가 있는 경우가 있습니다. 현실은 매우 다양한 변수로 인해 끊임없이 바뀌는 반면에 책이나 강의로 무언가 만들 때는 기준을 정해야 하기 때문에 다루기 어렵다는 말을 할 때 종종 케바케(케이스 바이 케이스)라는 말로 설명을 대신하곤 합니다. 케바케 대신에 이럴 수도 있다는 대안으로 글을 더 써 봅니다.

[3] 직접적인 연관이 있는지 확실치 않지만 아침에 본 기사에서 봤던 'AI 경제 혁명'이라는 말이 경제적 맥락으로 글을 쓰는 게 영향을 끼친 듯합니다.

이 조사에 등장하는 사람들은 모두 앤쓰로픽의 사용자들이고, 이들은 전부 ‘얼리 어답터’죠. 아직 메인스트림으로 이 추세가 이동했다고 하지는 않겠습니다. 하지만, 추세는 분명해 보입니다 - ‘코딩은 이제 사람이 주도해서 직접 수행하던’ 경제 활동이 더 이상 아닙니다 - AI 기반의 도구가 주도하거나 상당 부분을 담당하게 되는 활동이 되고 있습니다. 이건 ‘기술적 변화’가 아니라 ‘경제적 변화’ 예요. 그리고 이 변화의 물결에 ‘개발자들’이 가장 먼저 영향을 받고 있고, 만약 개발이라는 작업의 ‘워크플로우’와 그 ‘시스템 관리’를 염두에 두고 작업하는 게 아니라, 여전히 ‘코드를 몇 줄 썼나, Function Point를 몇 개 작성했나, UI 화면을 몇 본 만들었나’ 하는 생각에 빠져 있는 개발자라면, ‘미래는 이미 당신의 곁을 지나치고 있는 겁니다’.