brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Aug 22. 2022

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

도메인 모델링 세미나 12

내가 가장 에너지가 없을 때 하는 오락(시간 때우기) 행위 중에 하나는 축구 콘텐츠 보기이다. 하지만, 항상 일을 마음에 두고 있어서인지 내 일과 관련하여 보는 이른바 통섭적 관점을 나도 모르게 갖게 된다. 오늘 쓰는 글이 그런 예라고 하겠다.

사업적 관점과 축구적 관점이라는 이분법

최근 세계적으로 유명한 구단인 맨유가 급하게 선수를 영입하는 사건이 축구팬들에게는 상당한 화제다. 소문이나 기사의 진위를 따지는 콘텐츠들이 있는데, 그중 하나를 보다가 아래 화면에서 '아하' 하는 순간이 있어서 화면 캡처를 했다.

출처: 한준TV 영상

위에서 말하는 사업적인 관점은 맨유가 제시한 '파격적인 연봉의 다년 계약'을 의미한다. 카세미루라는 선수가 여러 가지 이유로 프리미어리그로 갈 가능성이 낮다고 보지만, 맨유가 아주 매력적인 제안을 해서 일말의 가능성이 있다는 내용이다.

이 영상을 보면서 이런 부분을 포착하려면 유럽 축구에 대한 지식을 요구한다. 나는 유럽 축구에 대해 해당 콘텐츠를 이해할 정도의 지식[1]은 갖고 있다고 할 수 있는데, 내가 '아하'한 이유는 사업적 관점이라는 표현이었다.

돈이 아니라 사업적 관점이라고 하면

큰돈이라고 해도 사실은 전달하는데 무리가 없다. 그런데 사업적 관점이라고 표현하니 이런 질문을 하게 된다.

사업적 관점 말고 무슨 관점이 있지?

또한, 영상에서는 '축구적인'이라는 표현이 등장해서, 내 머릿속에는 두 가지 관점이 영역으로 자리 잡는다. 이분법이라 할 수 있다. 최근에는 아래 그림처럼 교집합을 찾는 이야기를 주로 써온 터라 ‘축구적인 관점’과 ‘사업적인 관점’이 화제에 대해 경계가 모호한 가운데 두 개의 중심축을 설정하는 일로 보였다.

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

서비스는 어떻게 나누나요?

모호한 경계를 나누는 일을 떠올리니 연쇄적으로 <아키텍처 그림 가운데 있는 데이터> 편에서 했던 질문이 떠오른다.

그렇다면, 서비스는 어떻게 나누는가?

아주 유사한 질문으로 UML 모델링을 가이드하던 20여 년 전에 사이트마다 빠짐없이 듣던 질문이 있었다.

유스케이스는 어떻게 나누나요?

어떻게를 판별할 수 있는 기준은 도메인에서 나온다. 나는 흔히 쓰이는 도메인 드리븐(Domain-driven)이라는 표현이 이와 같다고 생각한다. 이쯤에서 자칫 개인적인 영감에 푹 빠져 횡설수설할 위험을 피하기 위해 주제를 제목의 문구로 좁혀서 이야기를 전개하기로 한다.

정말로 무엇이 문제인가?

지난 글인 <맥락은 어떻게 표현할 것인가?> 편의 주제를 한 마디로 요약하면, 말미에 제시한 두 가지 질문으로 압축할 수 있다.

대체 뭐가 문제인가?

누구와 소통하려고 하는가? (혹은 스스로 파악하려고 그릴 수도 있다)

무엇이 문제인가를 따지려면 먼저 누구의 문제인가부터 따져야 한다. 소프트웨어 공학이나 프로젝트 관리에서 이해관계자(stakeholder)를 강조하는 것과 같은 이치다. 맥락도에서 Actor가 꼭 등장해야 하는 이유도 같은 이치다.

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

또한, <아주 이상적인 아키텍처> 편에서 다룬 대로 변화가 적은 기성 조직에서 오너나 권력이 중요한 이유도 같은 이치다.

아키텍처는 의사소통의 문제가 아니라 조직과 권력구도의 문제입니다

참여자 공통 쟁점은 무엇인가?

이해관계자와 그들의 욕망을 파악한 후에 해야 하는 일은 공동의 주제(앞서 인용한 밴 다이어그램을 보자)를 찾고 그걸 가운데 두는 일이다. <아키텍처 그림 가운데 있는 데이터> 편에서 다룬 것처럼 참여자도 자기 입장에 따라 똑같은 현상에 대해 다른 입장을 띌 수 있다. (민주주의가 그걸 공론화하는 운영 장치이다)

그걸 가운데 쟁점으로 두고 공개적인 논의가 가능하게 하여 문제를 다각도로 보고 해결책을 만드는 방법이 소프트웨어의 지속성을 위해서도 꼭 필요하다. 주니어 개발자는 자기 기준에서 최고의 프로그램을 만들기를 꿈꾸지만, 다수가 사용하는 소프트웨어는 그런 것과는 거리가 멀다. 결국 다수에 의해 채택되는 사회적 가치(혹은 비용 지불이나 구독 등의 현상)에 의해 평가받는다.

그렇기에 설계를 위해 반드시 물어야 할 질문이 사용자 그리고 그들의 배후에 있는 이해관계자의 욕망의 공통점이 무엇인가를 따지는 것이다. 욕망은 언어로 설명할 수 있는 부분이 아니라 개념화하고 언어로 만드는 일도 설계의 범주에 들어간다고 할 수 있다.

시스템이 규모가 커지면

이때 사용자 층이 충분히 크고, 개발 조직도 규모가 커지면 덩어리를 나눠야 할 수 있다. <MSA는 서비스 병행 운영을 추구한다> 편은 이런 문제를 다룬 글이다.

그리고 여기서 인용한 그림은 페북에서 (DDD 고수인) 지인들의 유의미한 논쟁을 만든 일이 있다.

나는 얼핏 보면 충돌하는 듯한 두 분의 의견을 모두 공감한다. 하지만, 5주 전에 받은 댓글인데 뾰족한 답을 하기 힘들었다. 오늘 그 답을 할 수 있는 듯하다.

언어의 활용성을 높이려면 조직 전체가 같은 언어를 써야 한다. 마치 기성 조직에서 Silo의 폐단을 말하는 것처럼 특정 부서나 팀만의 언어가 있다면 파편화나 파벌이 만들어지는 일은 당연한 일이 아닌가? 그러나 시스템이나 업무가 충분히 복잡해지면, 각각의 영역 구분이 필요하다. 이는 마치 넓은 사무실에 파티션으로 공간을 구분하는 일과 유사하다.

DDD의 Bounded Context는 그렇게 '따로 또 같이'를 구사할 수 있는 개념일 때 가장 효과적이라고 생각한다.

맺음말

나는 오락으로 즐기는 축구 콘텐츠에서 받은 영감을 이용해서, 내가 천부적인 직업이라고 생각하는 설계에 대한 몇 가지 생각을 글로 썼다. 잘 정돈된 글은 아니지만, 통섭의 일환이고 오리지널이라고 할 수 있는 나의 생생한 이야기이다. 관심이 있는 분들의 의견과 반론, 질문이 있다면 더 발전시키고 싶다.