[개발생각] 회원구분코드(UserDvcdCode) 정의에 대해서

웹서비스에서 회원구분코드의 정의에 대한 깊은 생각을 했다.

 

좀더 전문적인 웹서비스를 만들때, 회원이라는 정의는 엄청나게 중요하다.

회원 정의를 엉성하게 설계하면, 결국 회원중심으로 돌아가는 모든 기능과 연결등이 엉성하고 어설프게 설계된다.

 

개발자는 유연과 엉성의 차이를 명확히 인지하고 있어야 한다.

유연한 설계는 수정에 닫혀있고, 확장에 열려있는 구조가 되지만,

엉성하고 어설픈 설계는 수정에 활짝 열려있고(도둑들아 모두들어오세요~), 확장에 닫혀있는(불났는데 문이 안열려..)

답답한 시스템이 되버린다..

 

이런 유연한 설계를 지향해야하고, 이런 설계를 위한 첫걸음은 회원에 대한 테이블 설계라고 할수있다.

개인적으로는 경력이 있다보니,

많은 프로젝트 설계/개발 경험이 있었고, 매번 해왔던 회원설계/회원구분에 대한것들에 그렇게 깊게 생각하지않았다.

너무 당연한것 처럼 설계를 하거나, 습관처럼 개발을 한것같아, 지금 생각해보면, 아쉽기도 하다.

 

왜 이렇게 해야하는걸까? 라는 고민을 많이 하지않았던차에,

이번주에 많은 고민을 했고, 그 해법이 나름 정리가 되어 글을 남겨두려고 한다.

 

 

1) 회원원장 데이터를 어떻게 구분하고 저장할것인가?

2) 회원구분코드를 어떻게 정의할것인가?

 

위 2가지 고민거리에 대한 나름의 해법을 정리해 두겠다. (나이드니, 잊어버릴까봐...무서워..)

 

 

1) 회원원장 데이터를 어떻게 구분하고 저장할것인가?

회원원장 즉 기본 User테이블은 최소한의 정보와 서비스내부에서 많이 사용하는 컬럼정도로 가볍게 유지를 해야한다고 생각한다.

기본 User테이블 자체의 용도는

웹서비스에서 자주 접근해야하는 테이블이 될것이며,

온라인 서비스와 더불어 수집/집계등의 배치잡과 같은 빅데이터를 사용하는 쿼리베이스 프로세스에서 기본 join테이블이 될 확률이 높기때문에, 다루는 데이터를 최소한으로 유지하여, 조회에 부담을 줄여주여 한다고 생각하기 때문이다. (성능적 이유)

 

따라서, 다른 회원관련 정보들은 적절하게 다른 테이블로 구분하여 분산 저장하는 방식이 좋은 방향이라고 생각하고,

조회는 분산된 테이블이 베이스 테이블로 접근하는 방법으로 개발은 이뤄져야한다고 생각한다.

 

예)

----------------------------------------------------

기본 User테이블

- user_id

- id

- pwd

- status

- dvcd

- reg_dtm

- login_dtm

- delete_dtm

----------------------------------------------------

User 부가테이블

- user_id

- nickname

- email

----------------------------------------------------

이 정도로 가볍게 유지를 하는게 좋을듯하다.

 

그럼 인증테이블은 어떻게 유지하면 좋을까?

휴대폰인증/신분증인증 2개 인증이 존재한다고 예를 들어보자.

 

예)

----------------------------------------------------

휴대폰인증 테이블

- user_id

- ci

- phone_num

- real_name

----------------------------------------------------

신분증인증 테이블

- user_id

- residence_id

- birth

----------------------------------------------------

 

이정도로  테이블 구성을 하면 될듯하다.

 

2) 회원구분코드(dvcd)를 어떻게 정의할것인가?

회원구분코드의 의도를 명확히 알아야 한다.

회원구분코드는 기본 User테이블에 존재해야하며,

해당 코드는 회원의 모든 구분을 표현하는것이 아닌 (특히, 모든 인증의 단계/회원의 상태를 구분하는식이 아님)

서비스내에서 경계가 명확한 큰개념의 구분으로 구분코드를 정해야한다.

회원구분코드는 기본 User테이블의 사용에서 첫 조회 조건으로 들어가는 조회범위를 결정하는 컬럼데이터가 되기때문에,

세분화보다는 경계가 명확한 개념의 구분코드정도로 정해야한다.

 

그리고 세분화한 회원의 구분은 위에서 정의한 회원정보를 분리해서 보관해둔 (인증,회원부가정보 테이블등) 다른 테이블들을 통해 구분하도록 설계한다.

 

특히 주의할것은 회원구분코드와 회원인증수단을 연결하여 모든 단계를 표현하려는 욕심을 부리는것이다.

(회원구분코드를 통해, 이 회원의 상태를 모두 구분되고, 확인할수있었으면 좋겠어!! 라는 욕심)

 

이부분이 사실 고민의 시작이였긴하였다...ㅠㅠ

 

회원구분코드로 회원의 상태/단계를 모두 표현하려는 욕심을 부렸더니,

의도치않는 복잡하고/부담되는 방법들을 생각해 내거나 (비트연산같은..나름 아이디어는 좋았지만 ㅎ),

구분코드간의 단계를 만드는 방법을 생각하게 되는 (엄청난 구분코드 갯수),

삼천포로 빠지는 상황이 오게 되었다.

 

각 인증수단에 대한 단계를 정의하려고 하니,

인증의 순서가 생기거나,

인증의 종류에 따라 dvcd의 종류가 급격히 늘어나는 케이스 또한 발생하였다.

 

회원 구분코드는 서비스의 경계가 명확한 구분으로만 간단히 정리하는것을 지향하고,

그 이외의 상세한 구분은 인증테이블이나, 부가테이블등 다른 테이블등을 통해 찾을수있는 방향으로 푸는게 좋을것같다는 결론을 내렸다.

 

이번 주말에는 회원구분코드에 대한 고민을 통해,

도메인 주도 설계에서 도메인만 생각했던 오류에서 벗어나, 그 도메인에 정의된 프로퍼티들도 많은 고민을 해야한다는것을 배우게 되었다.

도메인 주도 개발에서 프로퍼티에 대한 정의와 설계에 대한 이해가 이렇게 중요했다니..

 

최소한 위의 룰을 지킨다면,

최소한, 내가 만드는 서비스는 엉성하게 연결된 서비스가 아닌, 유연/느슨한 연결의 구조를 갖춘 서비스가 될것이라는 자신감이 있다.

 

이번 주말은, 오랜만에 설계에 대한 깊은 고민을 해봤던, 좋은 시간이었다.

개발은 역시... 어렵네..