어느 중국 개발자의 모델링 시작하기

사람마다 자기만의 이야기가 있다. 이제 공유할 이야기는 이제 막 모델링을 시작한 개발자 이야기다. 그는 북경에서 무려 특급 열차高铁로 7시간 떨어진 곳에 근무하는 원격 개발자이고, 내가 매우 좋아하는 중국 개발자^[1]다. 얼마 전 그는 새로운 서비스 개발 착수 미팅을 하려고, 북경에 방문했다. 그 때, 한 시니어 개발자가 그에게 작년처럼 그냥 개발하지 말고, 이번에는 모델링 하고 개발하라고 조언했다. 다음 날, 그는 데이터 모델링 책을 사왔다. 그리고 바로 적용^[2]했다. 그러던 그가 어느날 오후 메시지를 보내왔다.

원격 모델링 검토

모델링을 제안했던 시니어 개발자가 서울에 간 터라 아마 나에게 연락을 한 모양이다. 자기 모델을 보고 의견을 줄 수 있냐 물었다. 좋다고 했더니 팀뷰teamview란 프로그램으로 자신의 화면을 공유했고, 위챗 음성통화로 원격 회의 상황을 만들었다. 음성 통화가 시작되자, 나는 바로 노트북을 들고 자리에서 일어나 회의실로 이동했다.

그가 자기가 그린 모델을 설명했다. 먼저 아래와 같은 구조로 시작했는데...

새로운 요건 추가 이전

검색기록과 시즌이나 연도별 상품 조회가 추가되어야 한다고 아래와 같이 바꾸었다고 한다.

새로운 요건 수용을 위한 모델 수정

기능은 충족 했지만...

아기 발걸음을 적용하기 때문에 이 정도면 문제 없었다. 모호한 부분에 대해 가정을 더해서 출시 시간만 늦출 바에는 시험 버전이라도 얼른 사용자를 만나는 편이 좋으니까.

하지만, 의문이 하나 들었고 질문을 하지 않아도 대략 짐작이 되었으나 확인차 질문을 했다.

모호한 연관 기술 사례

그리고 간단히 두 가지를 설명해줬다. 보이지 않는 관계가 하나 더 있다는 점과 따라서 관계를 명확하게 해주기 위해서 역할(role) 이름을 붙일 수 있다는 사실을 수분이내로 설명했다. 그는 금새 알아 들었고, 바로 반영할 기세였다.

모호한 관계에 역할을 부여하여 한정하기

모호한 관계를 한정하기

자리에 돌아와서 이 친구의 도전에 대한 기쁨을 동료들에게 알렸다. 시간이 조금 흐르니 이왕이면 조금 더 친절한 설명이 필요할 수 있다는 생각이 들었다. 그래서 글을 쓴다. 다시 앞의 그림으로 돌아가보자. 용어부터 한번 읊어보자. user와 codi 객체^[3] 사이의 선은 연관association이라 부른다. 타입 간의 관계relationship를 다룰 때 쓰는 말이다. 타입이 실제 메모리상에 올라가는 인스턴스instance가 되면, 연관의 인스턴스를 링크link^[4]라고 부른다.

여기서 개선 여지가 있는 부분은 user와 code 사이 연관이 모호하다는 점이다. 물론, 다중성multiplicity이 user쪽이 1로 표기한 점 즉, 하나의 user 인스턴스만 연관에 참여한다는 사실에서 단서를 찾을 수 있기는 하다. 이런 해석의 여지를 줄이기 위해 몇 마디를 더 넣으면 오해를 줄일 수 있다.

모호한 연관 기술 사례

원격 통화로 확인한 사항을 도식화 하면 아래와 같다. 연관에 이름을 붙여 주면 명확해진다. 대안으로 역할role 이름을 연관 끝association end에 붙여도 된다. 이를 역할이라 부르는 이유는 특정 객체(여기서는 user)가 연관에 참여할 때 역할을 말하기 때문이다. 연관 이름은 붙이지 않았으나 후보로 코디codi 생성이나 업로드 등이 되겠다.

역할 이름 붙이기

여기서 개인 선호에^[5] 따라 사족을 더 붙이면 연관 이름은 그때 그때 다르다. 우리가 다루고자 하는 일의 범주가 이를 정한다. 고상한 말로 이를 도메인domain이라고 부른다. '우리가 다루고자 하는 일의 범주'라고 매번 부를 수는 없기 때문에 입에 붙이면 경제적인 말이 된다. 한편, '그때 그때 다르다'는 말도 고상하게 말하면 '도메인에 따른다', 영어로 domain-driven이라고 할 수 있다. 예를 들어, 코디를 창작한 이가 owner라면, 생성이라고 연관 이름을 붙일 수 있다. 반면에 코디를 작업한 사람은 따로 있더라도 코디를 서비스에 올리는 사람만 식별하겠다고 정하면(예컨대 서비스가 코디를 올린 이가 실제로 만들었는지 어디서 복사했는지 모르니까) 연관 명으로 업로드가 어울리겠다.

빠짐없이 망라한

컨설턴트에게 유명한 MECE란 원칙이 있다.  mutually exclusive (ME)와 collectively exhaustive (CE)를 합한 말이다. 우리말로 빠짐없이 망라한 이라고 기억하면 좋다.무언가 정리한 상황에서 경계가 모호할 때 사용하는 원칙인데, 전체집합과 여집합 확인 혹은 덩어리를 나누는 기준을 점검할 때 사용하면 좋은 기법일 수 있다.

쉽게 설명해보면 아래와 같이 질문하는 것이다.

빠짐없이 망라하기 위한 질문

쉽다. 문제는 여러분이 일에 함몰되거나 쫓기면 이렇게 질문할 여유가 없다는 사실이다. :)

대응 관계를 떠올려 숨겨진 연관 찾기

하지만, 모델의 다른 부분에서 동치를 발견할 수 있다. 점선으로 표현한 연관을 임의로 소비라고 부르면, 소비는 두 가지로 풀렸다. 둘다 현재는 익명인데, 하나는 download 객체와 연관이고, 다른 하나는 like와 연관이다. 연관 이름을 붙일 필요가 없음을 알 수 있다. 사실 이들은 객체라기 보다는 user 객체와 code 사이의 연관 테이블을 객체로 만든 인상을 받게 된다. 하지만, 이는 추정일 뿐이다.

다르게 풀어낸 소비 연관

다음 이야기

아직 결론은 없다. 나는 화상 리뷰에서 초보 모델러에게  검색기록 객체나 like, download는 공통점이 있다는 사실을 환기시켰다. 그리고, 검색 기록은 굳이 RDB에 레코드를 저장해야 할지 의문이니 데이터 핸들링 전문가인 Gold director에게 자문해보라고 했다. 다만, 당장은 기다리지 말고 RDB로 구현은 하라^[6] 했다.

초보 모델러의 다음 이야기를 애정을 가지고 지켜보자. 겨울이면 영하 20도가 넘는 지역에 사는 그가 추위를 잘 이겨내고, 동시에 모델링을 잘 활용하길 빈다. :)

주석

[1] 조선족이라 이러한 소통이 가능하다.

[2] 내가 이 친구를 좋아하는 이유다. :)

[3] 이 친구가 그린 그림은 데이터 모델이지만, 내 선호에 따라 UML 용어를 쓴다.

[4] 우리말로 연결link이라고 불러도 될 듯 하다.

[5] DDD 추종자 관점

[6] 나는 이 친구의 리뷰어이기에 앞서, 신규 서비스의 Director 겸 Agile Coach이다. 물론, Agile Coach같은 뻘줌한 직함따위를 쓰지는 않는다. 글이다보니 일반화를 위해 세상에 알려진 개념과 맞춰 쓴다.