if문을 실행할 수 있는 수준이라면 모두 액터다!

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

May 19. 2025

<실환경 검증의 중요성 그리고 액터와 사용자>를 다시 링크드인에 공유했더니 이번에는 Toby 님 댓글이 달렸습니다. 페북 대신 링크드인이 오작교를 놓아주는 원격 대화가 생각을 나누는 즐거움을 줍니다. 말로만 듣던 옛날 서신 교환이 이렇게 이뤄졌나 싶은데, 또다시 <실환경 검증의 중요성 그리고 액터와 사용자>처럼 그렇게 생각을 나누는 즐거움을 누리는 글입니다.

앨리스터 코번(Alistair Cockburn) 관점의 액터 정의

이전 글에서 쓴 'UML에서 말하는 액터'가 인출(?)한 토비 님의 기억이 글로 변환된 결과로 보입니다.

'액터'라는 같은 낱말에 대해서도 전혀 다른 기억과 지식을 만나게 된다는 점은 흥미롭습니다. 관점(觀點) 혹은 Viewpoint라는 개념의 오묘함이 느껴집니다. 반면, 납기에 쫓겨 다수와 협업(혹은 분업)해 본 사람은 서로 다르게 해석하는 바람에 결과가 예상과 달라 갈등을 낳고는 합니다. 그래서 DDD 주창자들은 '구성원 모두에게 통하는 언어'를 뜻하는 소위 'Ubiquitous language'를 꿈꾸고 실현하려고 노력하기도 합니다.

그 이야기를 다룰 것은 아니고, 여기서는 토비 님이 전한 액터에 대한 새로운 관점에 대해 제 나름의 해석을 풀어봅니다. 이를 위해서는 지난 글에서 다룬 'UML에서 말하는 액터'에서 출발해야 합니다. 그래서 일부를 다시 인용합니다.

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

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

앨리스터 코번의 말을 이해하기 위한 배경 지식

앨리스터 코번(Alistair Cockburn)에 대한 배경지식도 필요할 듯합니다. 먼저 퍼플렉시티에 질문을 하여 공동의 맥락을 만들기로 합니다. 다시 말해, 저와 독자들 사이에서 공통으로 필요한 배경지식으로 삼기로 합니다.

앨리스터 코번은 애자일 소프트웨어 개발 운동의 창시자 중 한 명이기도 하지만, UML의 실용적 활용을 다룬 책도 집필했던 사람입니다.

그러니 그의 액터 정의는 'UML에서 말하는 액터'의 확장판이거나 활용법을 담은 것이라 추정할 수 있습니다.

if문을 실행할 수 있는 수준이라면 모두 액터다?

이제 배경 지식을 확인했으니 그러면 토비 님이 전한 코번의 말씀을 듣겠습니다.

시스템과 상호작용하면서 행위를 가질 수 있는, 다시 말해 if문을 실행할 수 있는 수준이라면 모든 게 다 액터.

앞서 인용한 UML 정의와 거의 일치합니다.

액터(Actor)는 주체(subject)와 상호작용하는 사용자 또는 다른 시스템이 수행하는 역할(role)을 명세하는 모델 요소입니다. <중략> 액터는 유스케이스를 실현하는 분류자(Classifier)의 인스턴스와 액터의 역할 중 하나를 수행하는 사용자가 어떻게 상호작용하는지(예: 신호 및 데이터 교환) 설명합니다. <중략> UML 모델에서 액터는 BehavioredClassifier의 한 종류로 정의됩니다.

단 하나 눈에 띄는 문구가 있기는 합니다. 그게 흥미를 끄는 방아쇠 역할을 하는 듯합니다. 바로 여기죠.

다시 말해 if문을 실행할 수 있는 수준이라면

토비 님이 언급한 책을 읽어 보지 않아 저자의 주장인지 토비 님의 설명인지는 불확실하지만, 이 글에서 중요한 점은 누가 언급했느냐가 아니라 다음 질문입니다.

왜 if문이지?

면(面)을 떠올렸더니 헥사고날 아키텍처도 함께 연상

여기서는 제 느낌에서 비롯한 것이라 사실충실성은 담보할 수 없습니다. 현장 경험은 이러한 직관을 주지만 이렇게 직관에 의한 생각은 한계를 지니기도 하죠.[1]

아무튼, if문이 포함된 문구에서 제가 느낀 것을 문장으로 표현하면 이렇습니다.

면(面)으로 보면 그렇게 표현할 수 있네!

면(面)이란 표현은 어쩌면 4년 남짓 중국어 살며 한자와 친숙해진 기간 그리고 최봉영 선생님이 가르쳐주신 씨말의 힘을 활용하는 과정에서 생긴 습성입니다. 그렇게 떠올린 면(面)을 잘 활용하는 사례를 커리어 중에 두 번 정도 보았습니다. 하나는 '4+1 뷰 모델'이고, 두 번째는 헥사고날 아키텍처(Hexagonal Architecture) 아키텍처입니다.

그리고, 우리 대화를 이어주는 인물인 앨리스터 코번이 바로 그 헥사고날 아키텍처의 창시자입니다.

헥사고날이라고 해서 꼭 6 각형일 이유는 없다

너무 길어질 우려가 있어서 다 자세한 내용은 퍼플렉시티와의 대화 기록에 맡기고, 여기서는 왜 if가 면과 연결되는지만 설명하겠습니다. 퍼플렉시티가 찾아준 문서의 부제가 제 설명을 돕는데요.

이름에도 불구하고, 실제로는 육각형(헥사곤)에 관한 것이 아니다.

이러한 부제가 생긴 이유는 사람들이 앨리스터 코번이 큰 의미를 두지 않은 도형의 구조적 특성에 의미를 두는 일이 잦은 이유라고 추측합니다.

헥사고널 아키텍처라는 이름 때문에 많은 사람들이 이 설계 패턴이 ‘육각형’이라는 도형의 구조적 특성과 직접적으로 관련이 있다고 오해할 수 있습니다.

다시 말해서, 헥사고날 아키텍처를 채택한다고 해서 꼭 6각일 필요는 없다는 것이죠. 심지어 2 각도 가능한 것이죠. 그런데, 2 각형은 없잖아요?

하지만 실제로 이 아키텍처의 핵심은 ‘육각형’이라는 도형 자체가 아니라, 비즈니스 로직과 외부 시스템을 분리하는 구조적 아이디어에 있습니다. 육각형 도형은 단지 시각적으로 여러 방향(포트)을 표현하기 위해 선택된 것일 뿐, 육각형의 수학적 특성이나 형태가 설계에 본질적인 역할을 하지는 않습니다

이런 이유로 개명을 하기도 했습니다.

이후 "facet"을 "port"로 바꾸며 "Ports and Adapters"라는 이름을 선호하게 됐다. 하지만 "Hexagonal Architecture"라는 이름도 널리 쓰이게 됐다.

면(面)은 변(邊)이기도 하고 facet이기도 하다

자, 이제 독자님들도 헥사고날 아키텍처에 대한 이해가 갖춰졌으니 제가 면(面)을 꺼낸 이유를 설명하죠. 6각과 같이 각(角)을 말할 때, 각을 이루는 구성요소인 점을 기준으로 두 점을 연결하면 선이 생깁니다. 변(邊)이라고도 하고, 앨리스터 코번은 facet이라 말한 것과 같은 대상을 지칭합니다.

만일 시스템(혹은 객체)이 if로 규정하는 어떤 조건에 따라 다른 결과를 내놓아야 한다면, 이를 별도의 면(面)으로 묘사할 수 있습니다. 면은 접점이 되기도 하여 시스템의 인터페이스interface로 구체화할 수 있어, 프로그래밍 용어나 맥락과 연결에도 별 무리가 없습니다.