실환경 검증의 중요성 그리고 액터와 사용자

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

May 16. 2025

<모델링에서 행위자를 뽑는 일은 시스템 맥락을 만드는 일>을 페이스북에 공유했더니 다음과 같이 황건구 님의 댓글이 달렸습니다. 페북이 릴레이 하는 원격 대화가 생각을 나누는 즐거움을 줍니다. 말로만 듣던 옛날 서신 교환이 이렇게 이뤄졌나 싶은데, 아무튼 그 생각을 나누는 즐거움을 누리는 글입니다.

실존하는 액터라는 아이디어 살펴보기

그사이 제가 질문을 했고, 추가로 답변을 주셨습니다.

수긍이 가는 면도 있지만 다소 모호하게 느껴지는 부분도 있었습니다. 그런데 황건구 님의 또 다른 페북 대화가 있어 이를 함께 살펴보았습니다.

김성박: 실존하고 대화가 가능하다는 게 무슨 뜻인가요?
황건구: 유즈케이스는 우리에게 의견을 줄 수 없고 어디까지가 어디라고 관찰하거나 정의하기까지 불분명(예: 입차는 언제 시작해서 언제 완료인가(주차 공간에 자리를 잡는다면? 회차를 할 수 있는 30분은 아예 입차로 안치면 어떨까 등), 출차와 정산은 어떤 관계인가 등)한 부분이 있지만, 실존하는 액터(운전자나 차량은 이미 현실 세계에 정의가 되어 있으니)는 현실 세계에서 관찰하거나 아예 불러서 직접 의견을 들어볼 수도 있다는 의미였습니다.

실존의 뜻을 두 가지 측면에서 보면 좋겠다는 생각이 들었습니다. 더불어 액터와 사용자에 대한 구분이 필요할 수도 있다는 생각이 들었습니다. 실제 그럴까요? 글로써 생각을 나눠보도록 하겠습니다.

먼저 황건구 님의 주장(主張)[1]에서 동의하는 측면을 살펴보겠습니다. 그의 주장을 드러내는 가장 두드러진 표현은 '실존(實存)하는 액터'입니다. 그 예로 운전자와 차량을 들었습니다. 이미 현실에 있으니 관찰하거나 불러서 직접 의견을 들어볼 수 있다고 말합니다.

총체적인 유효성 확인 or 엄격하고 정교한 유효성 확인

제 말습관에서는 '릴리즈를 빨라 하자' 혹은 '릴리즈 먼저 계획하자'[2]라고 표현했던 생각과 대체로 일치합니다. 사고의 공간에서 즉, 사용자의 경험과 입장을 확인하거나 물리적인 현상을 확인하지 않고 생각으로 너무 많은 것을 개발하는 일을 지양하자는 주장이었죠. 마치, 과거 제조 중심의 기업들이 생산계획 중심으로 물건을 만들던 관행이 이제는 악성 재고를 만들고, 주문 생산이나 시장 니즈에 따른 빠른 생산계획이 가능한 기업이 강자가 되는 흐름과도 맥이 닿는 일입니다.

다만, 릴리즈는 시스템의 총체적 결과를 확인하는 반면, '실존하는 액터'는 개발 시점 즉, 릴리즈 이전에 관찰과 대화로 확인하는 방법을 담습니다. 관점을 검증으로 한정하면, 액터가 유효한 테스트 기준을 제공하는 것이죠. 이와 같이 검증을 강조하면, 실존하지 않는 개념들도 똑같이 검증 가능하게 만들 수 있습니다. 테스트를 엄격하게 규정하는 것인데, 현실에서는 이를 TDD(Test Driven Development) 같은 방법에서 관찰할 수 있습니다. 잘 (관찰하고) 생각해 보면 실제 (제품에 속하는) 코드가 아닌 테스트 코드는 액터와 비슷하게 어떤 개념의 유효성을 확인시켜 주는 주체가 됩니다. 어떤 개념이나 그 개념의 후속 결과물인 코드가 구체화되기 이전에 유효성을 확인하는 방법은 액터 이외에도 여러 가지가 있다는 말을 드리고 싶었습니다.

멀리 온 듯한데, 다시 돌아가서 '실존하는 액터'라는 표현에서 제가 동의하는 지점은 두 개로 보입니다. 하나는 실존한다면 상상하지 말고 바로 확인해 보자. 이때, 실험실 속의 결과처럼 제약조건이 많으면 현실에 릴리즈했을 때, 예기치 못한 일을 만납니다. 그래서, 가급적이면 빨리 작게 릴리즈하는 편이 좋다는 점도 '실존하는 액터'라는 주장과 생각이 닮아 있습니다. 또한, 액터를 엄격하게 규정하는 대신에 실제로 대화를 하자고 강력하게 주장하던 사람들이 초기 애자일 운동을 했던 사람들입니다. 하지만, 그들은 '액터'라는 말을 쓰는 대신에 사용자User나 고객Customer이라고 불렀죠. 액터는 명세를 구성하는 요소이고, 사용자나 고객은 사람이니까요. 그리고 그러한 애자일 프랙티스는 엄격한 쓰임새Use case 규정과 작성 대신에 사용자의 언어로 간결하게 쓴 '사용자User 스토리' 형태를 권고하며 대화를 통한 상호작용과 피드백 반영을 강조했습니다.

UML에서 말하는 액터

마지막으로 UML명세(v2.5.1 기준)에서 말하는 액터는 무엇인지 다루는 것으로 글을 마치겠습니다. 요즘 자주 쓰는 구글 노트북LM에 UML명세를 넣은 후에 액터 정의에 대해 물었습니다.

주어진 자료에 따르면, 액터(Actor)는 주체(subject)와 상호작용하는 사용자 또는 다른 시스템이 수행하는 역할(role)을 명세하는 모델 요소입니다. 액터는 인간 사용자, 외부 하드웨어, 또는 다른 시스템이 수행하는 역할을 나타낼 수 있습니다.

하지만, UML 정의에 따르면, 액터와 사용자는 다르다는 점을 알 수 있습니다.

액터는 특정 물리적 개체를 나타내는 것이 아니라, 관련된 유스케이스의 명세와 관련된 어떤 엔터티의 특정 역할을 나타냅니다. 단일 물리적 인스턴스는 여러 다른 액터의 역할을 수행할 수 있으며, 반대로 주어진 액터는 여러 다른 인스턴스에 의해 수행될 수도 있습니다.

다음 내용은 UML 배경 지식을 조금 더 요하는 내용입니다.

액터는 유스케이스를 실현하는 분류자(Classifier)의 인스턴스와 액터의 역할 중 하나를 수행하는 사용자가 어떻게 상호작용하는지(예: 신호 및 데이터 교환) 설명합니다. 이러한 상호작용은 주체의 상태 변화 및 환경과의 통신을 유발할 수 있습니다. UML 모델에서 액터는 BehavioredClassifier의 한 종류로 정의됩니다.

핵심만[3] 다른 말로 바꾼다면 외부의 역할을 액터로 규정하고, 그 규정에 따라 시스템의 상호작용을 통해 주체의 상태 변화까지 추론하는 근거를 만들어 가는 방법이라는 것이죠.

마지막은 제약 조건입니다.

액터에 대한 제약 조건으로는 다음과 같은 내용이 있습니다:
- 액터는 유스케이스(UseCase), 컴포넌트(Component) 및 클래스(Class - 비헤이비어는 제외)에 대해서만 이진(binary) 연관(Association)을 가질 수 있습니다.
- 액터는 이름을 가져야 합니다.

맺음말

생각을 나누는 즐거움을 누리는 글이라고 했으니 분명한 결론은 필요하지 않습니다. 다만, 읽는 분들을 생각해서 요약하면 '액터'라는 말을 매개로 서로 다른 생각을 나누었는데, 그 과정에서 황건구 님의 '실존하는 액터'는 실증의 중요성과 경제성을 강조한 측면에 공감할 수 있었습니다. 반면에 액터란 어휘가 UML 명세에서 나온 것인데, 그에 따르면 액터와 사용자는 구분하는 편이 오해를 줄일 듯하다는 생각이 들었습니다. 또한, 생각해 보지 않던 생각이 떠올랐는데, TDD의 테스트와 액터가 공통적인 기능을 하는 부분이 있다는 점이었습니다.