흑백과 디지털

 내가 회사에서 사용하고 있는 CRM 툴의 경우 기본적으로 Deal, Activity, Person, Organization이라는 모델을 사용하고 있다. 
  * Deal : 판매를 하려는 일련의 동작. 보험의 경우 하나의 보험을 팔기 위한 여러 과정들을 묶은 가상의 개념으로 결과적으로 판매에 성공하면 Won 이고 실패하면 Lost 고 거래가 진행중이면 Open 상태로 구별된다. 어떤 툴의 경우 opportunity 라고 하기도 한다. 
     판매가 아닌 구매에 대해서도 Deal 개념을 적용할 수 있다. 
  * Activity : 판매를 하려는 과정 중에 발생하는 미팅, 회의, 제안, 계약 같은 행위들. Activity 는 type 을 가지고 있고 보통 고객과의 약속시간을 남기게 된다. CRM 툴에서는 이 약속 시간을 google calendar 와 공유되면서 시간 알림 기능도 제공하기도 한다. 
  * Person : 일반적으로 고객. 경우에 따라서는 협력회사 직원 일 수도 있고, 수수료를 제공하는 중간 판매자일 수도 있다. 
  * Organization : 그냥 회사(조직)라고 생각하면 된다. 하나의 Person 은 하나의  Organization 을 가질 수도 있다.  하나의 Deal도  하나의 Organization 을 가질 수 있다. 
  * Product : 판매하는 상품. Deal 의 경우 여러 상품을 한 번에 팔 수 있다. 그리고 상품은 해당 상품을 취급하는 전문 담당자가 있을 수도 있다. 
  * Note : 모든 model 에 대한 설명을 적을 수 있다. 

 이들 관계를 대략적으로 설명했는데, 이런 모델은 사용하는 업체에 맞게 잘 설계되어서 사용되어야 한다. Sales CRM 툴이 개발자 없이 운영 되는 것 처럼 판매를 하지만 사실 이건 어느 정도 모델이 갖쳐진 DB와 Admin이다. 이를 운영하는 마케터나 운영자가 어느 정도 개발 기획적인 마인드를 갖춰어야 사용할 수 있다. 

  Admin 을 개발하다보면 권한 관리를 계층적으로 할 필요를 느낀다. 처음 개발할 때에는 딱히 요구 사항이 없다가 계속 시스템을 유지보수 하게 되면 필연적으로 계정의 권한과 그룹이 필요해진다. 그리고 Admin 사이트(일반 Manager 들을 관리 할 수 있다.)/ Manage 사이트/일반 고객(유저) 사이트 씩으로 사이트를 3벌 개발할 필요까지도 생기게 된다. 이 구조는 처음부터 설계하지 않고 나중에 적용하려고 하면 모든 API 마다 권한 체크 로직이 없게 되면서 생각하지 못한 버그가 생기게 된다. 이런 버그는 보안과 직결되기 때문에 좀 critical 한 편이다.

 그래서 무엇을 만들던 계정과 계정 그룹(또는 계정 종류) 그리고 권한은 미리 설계하는게 좋다. 

 내 경험상 계정관리와 권한에 대해서 가장 잘 된 것은 리눅스 파일 시스템이라고 생각된다. 그래서 이와 유사하게 구현된 보안체계를 많이 보았다. 기본적으로 User 자체의 권한, Group의 권한, Other 의 권한으로 나누어져 있다. 이와 유사하게 User 는 Group 이 없거나 복수의 Group 을 가질 수 있어야 한다. 그리고 Other 는 로그인 한 사용자로 생각해야 한다. 
그 다음으로는 RDBMS 에서 account 들이 잘되어 있다. RDBMS 에서는 Table 별로 권한을 가질 수도 있고, 경우에 따라서는 column 별로도 가능하다. 그리고 각 데이터(테이블이나 column)에 대한 access 를 select, insert, delete 등으로 구별할 수 있다. 이 두 보안체계를 고려해서 권한을 만들어 보면 아래와 같다.

 데이터는 table 과 column 단위로 권한을 지정할 수 있고, action 은 admin 에 맞게 create, modify, list, detail,  delete, search, autofill 이 필요할 것 같다. 그리고 User 는 하나 이상의 Group 을 가질 수 있다. 만일 유저가 2개 이상의 Group 을 가지고 있다면 둘 중 하나의 Group 에서 특정 action 과 해당 데이터에 대해 permission 이 허용된다면 해당 동작은 가능하다. (쉽게 설명해서 permission 의 User 가 포함된 Group 들의 Permission 의 합집합이다.) 
 그리고 모든 model(table)의 레코드(row) 에는 owner user 와 owner group 이 있어야 한다. User 의 경우 group 이 여러개 있더라도 데이터를 생성하면 바로 적용할 수 있는 default group 이 지정되어 있어야 한다. 이 owner user 와 owner group 을 바탕으로 User, Group, Other 를 적용해서 접근 사용자나 그룹을 적용할 수 있다. 

내가 CRM 툴을 설계하기로 했는데, 사실 CRM 이라는 용어가 익숙하지 않다. CRM 이란 고객 관계 관리(https://ko.wikipedia.org/wiki/%EA%B3%A0%EA%B0%9D_%EA%B4%80%EA%B3%84_%EA%B4%80%EB%A6%AC ) 를 말한다. 위키피디아 아래 쪽에 보면 고맙게도 적용 분야도 나와있다. 
* 판매: 소매점 판매, 현장 판매, 통신 판매, 웹 판매
* 마케팅: 캠페인, 컨텐츠 개발
* 서비스: 콜센터, 웹서비스, 무선서비스
* 개발: 신상품개발, 사업개발

 판매를 하는 SaaS 툴들을 사이트에 보면 case study 라고 해서 판매하는 툴을 사용해서 구축된 시스템의 예들이 소개되어 있다. 역으로 내가 툴을 만들 때, 이러한 가상의 이용 환경을 상상하면서 만드는 것이 좋을 것 같다. 그래서 몇 가지 가상 case를 생각해 보았다. 그러기 위해서는 CRM 툴이 이용되는 환경을 생각해 봐야 한다. 그래서 아래와 같은 환경을 상상해 보았다. 
1. 보험을 판매하는 회사에서의 영업 사원
  CRM 툴이 영업하는 사람들이 사용하기 유용한 툴이라는 생각이 들었다. (물론 회사차원에서 이런 것 시키면 영업사원들이 별로 안 좋아하는 것 같긴한다. ). CRM 툴은 고객을 관리하는 것에 중점을 두어 사용하기 좋은 툴이기 때문에 이런 장점이 눈에 보인다.

2. 온라인 쇼핑몰
  이 경우에는 마케팅이라는 것에 중점을 두어 사용하는 경우 일 것이다. 사용자들 하나하나(특히 구매를 하는 고객)의 유입을 기밥으로 어디에 홍보를 집중할 것인지, 그리고 퍼널 분석을 통해 어느 단계에서 구매를 주저하는지를 분석하는 방식으로 이용할 것이라 생각된다.