[코드스테이츠 PMB 10기] 데이터 PM으로서 데이터 베이스 설계하기
서비스 기획자가 되기 위해 알아야 할 것 들은 끝이 없다. 좋은 프로덕트를 만들기 위한 모든 과정에 필요한 경영, 마케팅, 디자인, 기획, 개발 등의 지식을 쌓아야 하고, 서비스 기획의 Specialist가 되기 위해서는 제품 개발 모든 분야의 Jeneralist가 되어야 할 것 같다.
이번에는 데이터 PM으로서 데이터 베이스에 대해 공부하고, 이커머스 프로덕트에서 많이 볼 수 있는 '찜 하기' 기능 flow를 통해 어떤 데이터를 생성하고 수집해야 하는지 DB를 설계해 보면서 알아보자.
관계형 데이터 베이스란 열(컬럼,column)과 행(row)으로 이루어진 2차원 데이터 테이블로 고유한 값 (기본키,Primary Key)를 연결고리로 서로 다른 테이블에서 참조하여 관계를 형성하는 구조를 가진 데이터 베이스를 말한다.
열(컬럼,column)은 데이터의 속성을 대표하는 한 종류의 데이터 타입(자료형)만을 갖는다. 하나의 열에서 문자와 숫자 타입의 데이터를 섞어 쓸 수 없다는 의미이다. 행(row)은 각 항목의 개별 값이 저장되어 있다. 예를 들어 학생 테이블에는 학생 번호, 이름, 부서, 직급 등의 개별 값이 행으로 저장되어 있는 형태를 말한다.
엑셀이나 구글 스프레드시트를 이용해서 테이블을 설계한다면 이런 구조를 가진다.
물론 수집할 데이터 컬럼을 정하고 바로 엑셀 테이블을 만들어도 되지만,
관계형 데이터 베이스로 표현 되기 이전까지 '데이터 모델링' 과정을 거쳐야 한다.
데이터 모델링은 고객 task 프로세스를 이해하고 데이터 모델링 표기법으로 간략하게 도식으로 표현한 것에서 실제 데이터베이스 구축까지의 과정을 말한다.
데이터 모델링은 개념적 모델링-논리적 모델링-물리적 모델링 3단계로 이루어진다. ERD(Entity Relationship Diagram)를 그리는 단계는 개념적 모델링, 정규화하는 단계는 논리적 모델링, oracle, mysql로 DB 시스템을 구축하는 단계는 물리적 모델링이라고 할 수 있다.
( 더 자세한 내용은 이 블로그를 읽어보기를 추천한다. SQLD 자격증 이론 내용인데 데이터 베이스를 이해하는데 조금 더 도움이 될 것이다.)
데이터 베이스 설계에서 또 중요한 개념은 Key 정의와 제약조건이다.
-중복된 값을 가질 수 없다.
-Null 값을 가질 수 없다.
-컬럼 중 반드시 존재해야 하며, 후보키들 중 유일한 값이다.
(후보키(candidate key): 행(=튜플)을 구분할 수 있는 속성의 집합체, 한 마디로 PK를 제외한 컬럼(=속성) 이라고 생각하면 된다.)
-두 테이블을 연결한다.
-참조 테이블의 기본키이다.
-테이블 내에서 컬럼 값이 유일하다.
-PK와 유사하나, null 값을 허용한다.
-테이블 내에서 여러 번 생성 가능하다.
- 컬럼에 저장 가능한 데이터 값의 범위나 조건을 지정한다.
- 컬럼에 입력되는 데이터를 검사해서 조건에 맞는 데이터만 입력되도록 한다.
이 정도 개념만 알아도 관계형 DB 테이블을 설계할 수 있다.
다음으로 '카카오톡 선물하기'의 찜 하기 기능의 DB 테이블을 간단하게 만들어보자.
우선 카카오톡 선물하기에 있는 찜 기능을 이용하려면 어떤 여정을 거치게 되는지 살펴보자.
처음 메인 화면에서 시작해 전체 상품 리스트를 보고 원하는 카테고리를 선택한다. 그리고 카테고리별 상품 리스트 중 원하는 상품을 클릭한 후 제품 상세정보를 보게 된다. 여기서 상품이 마음에 들어 찜 하기를 누르면, 마이 페이지 찜하기 목록에서 내가 좋아하는 상품 리스트를 볼 수 있다. 플로우 차트로 만들면 다음과 같은 흐름을 갖는다.
내가 만약 카카오톡 선물하기에서 찜 기능을 개발하라는 기획을 맡았다면, 전체 플로우에 맞게 데이터 수집 범위를 정하고 수집해야 한다.
이때 개발자에게 DB에 필요한 컬럼과 요구사항을 어떻게 설명할까? 우선 고객의 여정에 맞게 데이터 시나리오를 의논한다.
그리고 최종 요구사항은 이렇게 될 것이다.
" 사용자가 전체 상품을 리스트를 보고 원하는 카테고리 분류를 선택한 후
분류된 상품 리스트에서 원하는 상품을 찜하기 합니다.
찜 하기 후 마이페이지에서 내 찜 목록을 볼 수 있어야 합니다."
'시나리오는 이렇게 됩니다'라고 말해도 개발자는 그래서 정확히 어떤 기능을 설계해야 하는지 난감할 수 있다.
데이터 생성이 어디서 발생하는지는 설명한 후, 수집할 데이터 컬럼 종류와 약속된 데이터 ID 값, 데이터 타입을 정의하고 DB 정의서를 만들어 보여준다. 이때 주의할 점은 DB는 생성되고 데이터가 쌓이면 수정하기 까다로운 작업이기 때문에 충분한 커뮤니케이션을 거친 후 테이블을 정의해야 한다. 테이블에 추가 컬럼이 필요할 수도 있고 데이터 타입이 코드 오류를 일으킬 수 있기 때문에 신중하고 꼼꼼하게 작업해야 한다.
찜 하기에 필요한 DB 테이블은 회원 계정 정보, 전체 상품 리스트 정보, 찜 목록 이렇게 3가지로 정했다.
회원정보는 사용자가 로그인 후 나의 찜 목록을 볼 수 있어야 하기 때문에 필요하고, 전체 상품 리스트는 Select 해서 상품들을 보여주고 카테고리 컬럼을 생성해 해당되는 카테고리를 선택 후 체크박스처럼 선택 기능이 Y/N 중 Y로 바뀌면 카테고리의 리스트가 Select 되도록 해야 한다. 그리고 원하는 상품을 선택하면 제품 상세 정보를 볼 수 있어야 하기 때문에 '상품 상세 이미지'를 컬럼에 넣었다. 이때 이미지는 주소나 파일 명으로 따로 가져와야 한다.(DB에는 문자와 숫자만 저장 가능하기 때문이다.) 그리고 찜 목록 테이블은 한정적인 DB 용량을 효율적으로 사용하기 위해 회원 정보의 PK와 상품 리스트의 PK를 FK로 받아서 동작하도록 설계했다.
개발자, 디자이너 등 다양한 이해관계자들과 소통하려면 해당 포지션에서 쓰는 전문 용어와 지식을 공부해야 설득할 수 있는 힘을 가지게 되는 것 같다. 기획자로서 장황한 아이디어만 내세울 것이 아니라 구체적으로 어떻게 적용할 건지 업무 프로세스에 맞는 논리적인 설명을 할 수 있도록 노력해야 한다. 또 습득한 지식으로 갖춰진 관점으로 동료가 보지 못했던 새로운 시작을 제공해 주는 것이 기획자로서 할 일이 아닐까 생각한다. 이야기할 가치가 있는 동료, 공부 부족으로 우유부단하게 끌려가지 않는 기획자가 되기 위해 생각의 힘을 길러야겠다.