거의 대부분의 서비스들은 회원 가입이 있을 겁니다. 그러니 당연히 ‘유저’ 테이블이 있겠죠. 당연한 말이죠? 하지만 너무나 당연해보이는 말이지만, 사실 여기에는 어폐가 하나 있습니다. 유저는 사용자라는 뜻이고, 회원은 영어로 번역하면 ‘member’ 입니다. 말하자면 유저는 비회원과 회원을 모두 아우르는 말이고, 따라서 유저 테이블은 가입을 하든 안 하든 상관없이 사용자를 기록해둬야 마땅합니다. 그러니 만약 회원가입한 대상만을 유저라고 지칭하고 있었다면, 이제부터는 그걸 ‘멤버’ 라고 불러야 합니다. ‘비회원’이 생긴다면 어떤 점이 달라질까요? 아니면, ‘비회원’을 저장하지 않는다면 어떤 문제가 있을까요?
A: “우리 서비스 유저가 몇 명이에요?” 백엔드 개발자: (SQL로 회원가입한 사람을 카운트하며) “N명이에요.” A: “…너무 적네요. 아무래도 이 서비스는 피봇(Pivot)하는 게 맞을 거 같아요.”
많은 서비스들이 유저 수를 기준으로 서비스를 지속할지 말지를 판단합니다. 대표들은 데이터를 가지고 이 서비스가 지속할 가치가 있는지, 아니면 자원이 떨어지기 전에 다른 서비스를 만들어야 할지를 고민합니다. 만약 백엔드 개발자가 회원가입한 사람 수를 가지고 유저를 판단한다면 서비스의 성공, 실패를 제대로 판단하질 못할 겁니다.
백엔드 개발자: (근데, 회원가입도 안하고 서비스 밖으로 나간 사람도 많을 텐데… 이건 집계 못하나?)
서비스의 규모를 제대로 집계하기 위해서라면 반드시 비회원 테이블이 필요해집니다. 비회원 테이블은 단순히 로그가 아니라, 유저의 행동 기록을 모두 잡아내기 위한, 유니크한 세션 단위를 의미합니다. 회원가입을 하지 않고도, 모든 비회원은 브라우저를 통해 서비스에 접속하자마자 토큰을 발급받게 됩니다. 이 과정은 로그인이 없을 뿐, 우리가 늘상 다루는 JWT 방식과 다를 게 없습니다. 간단하죠? 하지만 이 간단한 것을 서비스가 커진 다음에 하려고 하면 이미 상당히 많은 데이터를 잃은 셈이 됩니다. 미리 할 수 있다면 비즈니스에 큰 도움이 되겠죠. 그러니 이번에는 비회원/회원 테이블 설계를 해봅시다.
대부분의 커머스는 비회원 구매가 가능할 겁니다. 앞으로 모든 사용자를 User 라고 부르고, User 중 회원가입한 경우를 Member라고 부르겠습니다. 이 정의에 따르면, User N명에 대해 1명의 Member가 있거나 없거나일 것입니다. 비회원은 아직 회원가입하지 않았으니, 알고보면 여러 유저가 한 명의 회원일지도 모를 일이죠.
<aside> 💡
“한 명이 회원가입하기 까지 우리 서비스에 몇 번이나 방문할까?”
</aside>
이제 User의 정의는 ‘세션Session’이 될 겁니다. 브라우저를 통해, 우리 서비스에 들어와서 이탈할 때까지가 한 명의 유저입니다. 만약 브라우저를 껐다가 다시 켜면 새로운 비회원이 온 것으로 계산될 것이고, 비회원의 접속부터 퇴장까지만 집계하더라도 체류 시간과 방문 횟수를 모두 알 수 있겠죠. 물론 그 사람이 같은 사람일 거라고 보장할 수는 없습니다. 우리는 그 사람의 헤더 정보를 읽어 아이피라던가, 여러 User가 같은 사람일 것이라고 막연히 추측할 수는 있어도, 정말로 같은 사람이라고 확신하기는 어려울 겁니다. 왜냐하면 동일한 아이피라고 하더라도 PC방에서 접속했다던가 한 가족이 동일한 공유기를 사용하고 있었을지도 모르기 때문입니다. 하지만 그 정도 정보라고 하더라도 없는 것에 비하면 감지덕지한 일입니다.