brunch

라이킷 5 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 안영회 습작 Aug 25. 2022

개체(시스템)의 재설계와 경계의 변경

도메인 모델링 세미나 15

최근에 맥락(Context)과 경계 설정에 대해 생각하고 글을 쓰면서 얻게 된 영감이 있다. 경계를 설정하는 일이 바로 무언가를 정의하는 일이기도 하다는 점이다.

특성과 역할과 관계로 구성요소를 개체로 정의하기

<Context와 컴포넌트와 이상적인 아키텍처> 편에 단락 제목으로 '해당 개체의 중심에 무엇이 있느냐?'라는 문구를 쓴 적이 있다. 만두는 빚는 것과는 매우 다른 일이지만, 구성요소가 있고 그걸 빚어낸다는 점에서 소프트웨어를 만드는 일도 비슷하게 생각할 수 있다. 그리고 '빚어낸다'는 표현을 조금 더 정교한 문장으로 써보니 마음에 든다.

설계자는 특성과 역할과 관계로 구성요소를 개체로 정의할 수 있다.

특성은 개체가 갖는 요소이지만 관계는 그렇지 않다. 복수의 개체가 존재할 때만 관계는 성립한다. 그리고, 관계를 맺으면 그때 역할이 생겨난다. 관계 속에서 각 개체에 부여된 책임을 객체에 부여한 이름을 역할이라고 할 수도 있다.

개체를 규정하는 일과 경계

기존의 비슷한 생각을 했던 기록을 찾다가 <1 이라는 수와 경계 그리고 단위의 문제>를 찾았다. 그리고 거기서 흥미로운 질문을 발견했다.

제주도는 하나의 섬인가? 비양도나 우도는 제주도가 아닌가?

경계를 짓는 일은 구성이라는 관점에서 보면 무엇을 넣고 뺄 것인가에 대한 결정이다. 앞서 사용한 표현을 쓰면 특성 중에서 넣을 것과 뺄 것을 정하는 일이다. 그러나 개체가 단독으로 존재하는 상황이 아니라면 (사실 대부분의 경우가 그렇다) 다른 개체와의 관계를 정하는 일도 경계를 짓는 일의 일종이다.

<1 이라는 수와 경계 그리고 단위의 문제> 편에 이를 표현하는 (최봉영선생님의) 생각과 그림도 등장한다.

경계 설정은 소프트웨어 설계의 핵심 활동

물리적인 세상과 소프트웨어로 규정하는 세상의 분명한 차이가 있다. 소프트웨어는 경계를 바꾸는 일이 물리적인 세상에 비하면 너무나도 쉽다는 점이다.

출처: https://brunch.co.kr/@graypool/544

그리고 시스템이 지속적으로 생명력을 가지려면 설계 변경이 필요하다. <경계 설정은 소프트웨어 설계의 핵심 활동> 편에 쓴 대로 경계 설정은 설계의 핵심이기 때문에 종종 경계를 바꿔야 할 수도 있다. 관계에 맞춰서 개체의 역할이 달라질 수도 있고, 물리적 세계에서는 불가능하지만 특성에 따라 개체를 다시 규정할 수도 있다.

세상과 호흡하며 적절함을 찾아가기

이 글을 쓴 계기는 페북에서 박종윤님 글을 다시 읽으며 얻은 영감에서 비롯되었다. 물론, 박종윤님 글은 소프트웨어에 대한 이야기는 아니다. 마케팅에 대한 이야기라고 추정하는데, 소프트웨어가 지속할 수 있는 방법과 굉장히 유사한 교훈을 담고 있다.

앞서 설계를 하며 경계를 변경해야 할 수도 있다고 말했는데, 나는 이를 가드닝이라 부르기 좋아한다. (진짜 정원이 아니라) 소프트웨어 가드닝을 할 때 박종윤님의 교훈을 활용할 수 있을 듯하다. 세상과 호흡하며 적절함을 찾으라는 교훈[1]은 소프트웨어 가드닝 제1원칙으로 삼아도 좋을 듯하다.

소프트웨어가 세상과 호흡하기 위해 해야 할 일을 릴리스하여 피드백을 받는 일이다. 이전 글에서 나는 <일단 릴리즈를 하라>고 쓴 일이 있다. 릴리즈를 하고 얻은 피드백이 설계에 대한 충분한 영감을 준다. 박종윤님 글에서 틀과 프레임은 소프트웨어 세상에서는 경계에 바로 대응한다. 경계가 한번 지어졌다고 그걸 그대로 두지 않을 수 있어야 한다.