두레이 서비스를 참조하여 계정관리 개선하기

또 다시 지난 글에 이어서 두 개발자와 대화한 내용을 공유한다. 세번째 설계 시리즈다. 우리는 2월초부터 두레이라는 훌륭한 협업 소통 도구를 쓰고 있다. 우리가 두레이에서 참조한 부분은 조직과 사용자 그리고 권한 관리 기능이다. 우리가 일종의 설계 개선 모임을 하는 2월 현재 우리는 Account라는 마이크로 서비스를 운영하고 있다. 사용자가 특별히 인지할 필요가 없는 공용 서비스라 할 수 있는데, 초대 형태로 가입하는 기능과 로그인을 ID와 password로 하거나 SNS와 같은 외부 인증으로 대신 하는 기능 정도를 제공한다. 기능상으로 두레이의 해당 기능과 큰 차이는 없다. 차이점은 Role 종류가 너무 많아 관리 어려움을 겪고 있는 중이다. 9월부터 개발해서 대략 5개월 정도만에 쌓인 빚(Technical Debt)이라고 할 수 있다. 이를 해결하려고 하는 찰나에 요다님 소개로 쓰고 있는 두레이에서 '프로젝트에 종속하는 권한 부여 방식'을 차용하기로 했다. 아주 단순하게 설계할 수 있었는데, 앞서 말한대로 이미 상당히 유사해서 Role 자체가 많은 점만 문제라 보고 이부분만 차용했기 때문이다. 문제를 명확하게 정의한 상태였기에, 단순히 두레이 관리자 기능 몇 번 쓰는 일 자체가 설계 개선 아이디어를 쉽게 얻는 기회였다.

새로운 설계 사항은 단순히 두레이의 프로젝트에 우리의 Spot을 대입시키기이다. 하지만, 개발자에게 설명하기 위해서는 약간은 객관화가 필요해 아래 그림을 그렸다.

조직과 사용자 관리를 위한 클래스도

글로 쓰다보니 하는 수 없이 한번에 써내려 가지만, 회의 과정에서는 관계 하나를 그리면 설명을 한번 하는 정도의 호흡으로 설명했다. 즉, 박스 두개와 선 하나를 그릴 때마다 설명을 하고 눈을 맞춰 개발자 둘이 이해했는지 확인하며 그려 나갔다.

그 과정을 글로 정리하면 이렇다. 태넌트(tenant)는 SaaS 형태로 공급할 때, SaaS 고객 계정 하나를 의미한다. 두레이와 같이 우리는 기업용 서비스를 만들기 때문에 두레이방식을 응용할 수 있다. 하지만, 우리는 아직 태넌트를 고정하지 않기로 했다. 지난 1년간 SaaS 개발과 릴리즈 경험을 통한 공부로 얻은 바는 판매 서비스의 태넌트 정의는 그리 간단하게 문제가 아니란 확신을 주었다. 태넌트를 경험 없이 직관으로 결정하면 마치 빅뱅으로 프로젝트를 구축하는 SI 프로젝트처럼 나중에 큰 고통을 만날 것임을 예견했다. 그래서, 조금 더 경험해보고 정하기로 했다. 그래서, 조직 설계에 더 공을 쓰기로 했다.

단지 구조상 두레이와 똑같이 태넌트가 여러 개의 조직을 갖을 수 있다고 정의했다. 태넌트와 조직(Organization) 사이 연결에 한쪽에 다이아몬드 기호가 붙은 것을 UML 합성(Composition)이라고 하는데 태넌트가 있어야만 조직이 존재한다는 의미다. 그래서, 아래 그림을 말로 풀면, '태넌트는 여러 개의 조직으로 구성되며, 조직이 존재하려면 반드시 태넌트가 필요하다'라고 한다. 조직 우측 상단에 보면 조직에서 조직으로 선이 그어져 있고, 한쪽에는 1이 반대쪽에는 *이 씌여 있는데, 이는 하나의 조직이 다수의 조직과 관련이 있다고 읽는다.

태넌트와 조직, 조직과 조직 관계를 그린 클래스도

다음으로는 조직과 Spot 관계를 그렸다. 이 부분이 두레이를 응용한 바로 그 부분이다. 두레이는 프로젝트 관리 관점에서 업무을 만들고 메일처럼 해당 내용을 할당할 수 있다. 그렇다보니 프로젝트라는 단위가 협업의 중심이 되는 단위다. 우리 SaaS는 판매용 서비스인데, 판매를 하는 주요 공간을 Spot이라 정의하고 쓰고 있었다. 두레이의 프로젝트에 우리의 Spot을 대응시키면 두레이 권한 부여 모델을 응용할 수 있다. 그래서, 여러 Spot에 사용자가 일할 수 있게 설계했다. 예를 들면, 백화점 매장에서 한 직원이 여러 매장 판매에 참여할 수 있게 하기 위해 Spot 여러 곳에 user가 속하게 한다는 식이다.

조직, Spot과 사용자 사이의 관계

위에서 특이한 사항은 의문 부호를 남겨둔 것이다. 나의 노하우인데, 모호한 것은 모호한 상태라고 명확하게 해두고 개발하는 것이다. 그림에서 조직과 사용자 사이 관계가 그렇다. 개발을 위해서는 모호함을 제거해야 하는데, 모호하게 두고 개발한다는 말은 무슨 말인가? 이는 아직 쓰임새가 없는 기능에 대해 굳이 설계 노력을 하지 않고, 릴리즈 할 필요가 없다면 개발도 하지 않는 것이다. 어차피 서비스를 일부라도 릴리즈하면, 노력하지 않아도 자연스럽게 알게되기 때문이다. (Planning over Plan 이란 말이 머리속에 떠오르지만 부연은 않겠다.)

마지막으로 사용자 유형 구분은 두레이를 그대로 따라했다. guest를 빼곤 우리도 비슷하게 되어 있어서 내용면에서 달라진 것은 손님(guest) 계정을 추가한 것이다. 임시직이 흔한 현실과 인사변동이 심한 유통업계를 생각하면 업무용 시스템에 손님 계정을 넣는 일은 꽤 유용해보인다. UML 상속 표현으로 그린 것인데, 말로 풀면 '사용자가 갖는 역할(role)은 세 가지가 있는데, 각각 관리자(admin), 회원(member)와 손님(guest)이다.'로 푼다.

user의 세 가지 유형

나중에 기회가 되면 UML 표현을 말로 푸는 법에 대한 창시자 임춘봉훈장님의 글을 소개해봐야겠다. (누군가 관심이 있다고 하면...)