즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
한국의 마틴 파울러가 되기
지난 글에서 다음과 같은 질문을 던졌습니다.
입자와 파동의 이중성은 설계에도 적용할 수 있지 않을까?
실제 사례로 풀어 보겠다고 했으나 시작이 쉽지 않아 어떻게 시작할까 궁리하는데, 물리학 강의에서 본 원자 구조의 이미지는 최근 회의에서 제가 그린 그림[1]과 구성요소를 표현하는 양상이 비슷하다는 생각이 들었습니다.
구조는 구성요소와 이들의 관계
애초에 동료가 그린 그림을 두고 제가 구성요소와 관계를 조금 더 구체화하려는 그림이란 점을 회의시간에 언급했습니다.[2]
소프트웨어 설계든 자연 과학이든 구조를 파악한다는 일은 구성 요소와 이들 사이의 관계를 규정하는 것이란 점에서는 차이가 없는 일이란 사실을 유튜브 물리 강의를 듣다 알다니!
다시 회의 때 시도로 돌아가서 제가 더하려고 했던 요소는 무엇일까요? 지금 그림을 쑥 훑어보니 UML 용어를 빌면 Stereotype, Multiplicity 그리고 Role입니다. 갑자기 UML 용어를 썼는데 글을 쓰며 용어 뜻과 이를 소환한 이유를 생각해 보아야겠습니다. 익숙해져서 자연스럽게 한 행동이지만 저들을 동원한 이유는 분명 있었겠죠.
어떤 구성요소들을 추가했나?
먼저 UML stereotype을 쓴 이유는 밝혀 봅니다. DDD 책에서는 빌딩 블록(buiding block)이라고 했던 입자(박스 그림으로 표기한 개념)가 서로 다른 구성을 갖고 있다는 점을 표현하려 했습니다. 실용적으로 표현하면 구현 방식이 다르다는 것을 나타낸 것이죠. '구현 방식이 다르다'라고 문장으로 칭하기보다 '빌딩 블록'이라고 부르는 편이 간편해 보이네요.
오호.. 재밌네요. stereotype 부여는 일종의 주기율표의 기능과 비슷합니다. 구성요소의 메커니즘을 기준으로 분류하는 것이니까요.
물리에서 배운 '입자' 성격을 활용하는 일을 단번에 성공한 듯합니다. 과학에서도 원자마다 구성이 달라 성질도 다릅니다.
출처: https://ko.wikipedia.org/wiki/%ED%91%9C%EC%A4%80_%EB%AA%A8%ED%98%95소프트웨어도 이를 응용하면 ‘입자’를 빌딩블록이나 패턴을 분류하는 기준이나 단위로 쓸 수 있습니다.
파동은 일됨, 이벤트로 정의하기
다음으로 Multiplicity가 있습니다. 아래 그림은 Applicant 하나가 다수의 M/H를 갖는다는 의미를 나타낸 도식입니다.
파동을 여기에 대응시켜 보겠습니다. 조금 정확히 말하면 선이 파동이고, Multiplicity가 파동의 성격을 규정한 것이라고 할 수 있네요.
즉흥적으로 여러 가지 구현 방식이 떠오릅니다. 하지만, 파동 자체를 규정한 것이 아니라 조심해야 합니다.
어떻게 말로 설명할 수 있을까 궁리하는 가운데 먼저 분명히 느끼는 것은 '입자와 파동이라는 이중성'이 유용할 듯하다는 점입니다. 무엇보다 이분법은 단순함이라는 강력함을 제공하니까요.
이벤트는 변경을 알리는 표준 프로그래밍 단위
다만, 파동이라는 말이 생소해 이벤트라는 말을 쓰는 편이 좋겠습니다. 찾아보니 작년에 썼던 아이디어 <이벤트는 변경을 알리는 표준 프로그래밍 단위>를 활용할 수 있습니다. 제가 마지막으로 코딩했던 작품(?)의 설계서인 상태도가 보입니다.
UML 상태도로만 알았던 위 그림이 알고 보니 잠금(Lock)에 의존하는 트랜젝션 관리의 대안이었네요. 흔히 패러다임 전환이라고 부르기도 하는 관점 전환이 중요하다는 사실을 깨닫는 순간입니다.
이벤트가 변경을 알리는 표준 프로그래밍 단위라면, 트랜젝션은 정의가 모호한 거대한 이벤트로 보였습니다. 패러다임 전환이란 게 이런 것일까요?
이벤트는 한국말로 '일됨'의 차림
한국말을 쓰는 대부분의 우리나라 사람들에게도 생소한 표현이겠지만 이벤트(Event)는 한국말로 '일됨'에 해당합니다.
근래에 최봉영 선생님의 가르침을 따라가려고 <사람들이 한국말로써 세상을 담아내는 방식>을 쓰며 익힌 개념인데, 이벤트가 무엇인지 이해하는 데에도 분명 도움을 준다는 생각에 앞으로도 종종 활용할 생각입니다.
주석
[1] 동료이자 후배의 부정확한 표기를 보고 지적을 할지 말지 고민한 일이 있습니다. 사소한 지적에 위축될 수 있어 조심스럽게 내가 보는 과점을 설명했습니다.
[2] 2000년 즈음에 읽었던 소프트웨어 아키텍처 패턴 책에서 From Mud to Bricks로 기억하는 이름의 패턴이 있었는데 구글링 해도 찾을 수가 없네요.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
