데이터베이스, DBMS 그리고 SQL 1탄 | 코드스테이츠 PMB 17기 W6D1

오늘은 제품에서 수집되는 고객 데이터의 종류를 사용 목적에 맞게 구분하는 방법,

고객 데이터가 실제 데이터 베이스에 수집, 가공, 구축되는 절차에 대해 학습했다. 

.

.

 

 

 

---

 

 

IT 프로덕트와 데이터베이스의 구성

 

 

IT를 모르시는 분들은 아마 없을 것으로 생각되지만, IT 프로덕트에서 데이터가 움직이는 흐름에 대해서는 잘 생각해보지 않았을 수도 있을 것 같다는 생각에... IT프로덕트에서 데이터가 움직이는 과정에 대해 정리해보았다:

 

 

먼저 클라이언트 단계로 고객 컴퓨터, 스마트폰 등 사용자가 사용하는 장치가 있고 >> 고객 장치에서 앱 서버로 데이터를 전송한다 >> 앱이 구동되는 서버에서 데이터를 받으면 >> 데이터베이스로 데이터를 전송한다 >> 데이터베이스는 고객 데이터를 받아 필요한 데이터를 정리해서 다시 서버로 보낸다 >> 서버는 받은 데이터를 다시 클라이언트로 보내고 >> 클라이언트는 데이터를 출력한다. 

 

 

우리가 봐야할 고객데이터는 모두 데이터베이스에 있다. 데이터베이스란 컴퓨터 시스템에 전자 방식으로 저장된 구조화된 데이터의 체계적인 집합이다. 우리가 사용하는 수많은 서비스들이 각각 정보, 즉 데이터를 저장하는 곳이다. 클라이언트로부터 데이터를 받는 서버가 아닌, 데이터베이스가 데이터를 관리하고 저장하는 주체이다. 데이터베이스는 크게 세가지 요소로 구성되어 있다: 데이터서버(데이터가 저장되는 공간), DBMS(데이터베이스를 관리하는 시스템), SQL(관리하고 운영하기 위해 쓰이는 언어)가 있다. 

 

 

구글 클라우드, 아마존 웹 서비스, 마이크로소프트 아주르 등이 데이터가 저장되는 공간, 데이터서버의 예시이다. 서비스는 해당 기업에 일정 비용을 제공하고 데이터 서버를 빌린다. 데이터를 다 저장할만큼 큰 서버 공간을 모든 기업이 소유하기는 어렵기 때문이다. DBMS의 대표적인 프로그램으로는 MySQL, Oracle이 있다. SQL은 이 시스템을 관리하고 운영하기 위해 사용된다. 

 

 

데이터베이스의 한 종류 - 관계형 데이터 베이스(RDBMS)

 

 

데이터를 따로 기록하되, '기본키'를 사용해 상호관계를 파악할 수 있게 한 데이터베이스를 관계형 데이터베이스라고 한다. 이때 기본키는 어떠한 항목과도 겹치지 않으면서, 다른 정보를 모두 파악할 수 있는 항목으로 설정해야 한다. 보통 회원번호, 모델명 등 고유한 값을 기본키로 설정한다. 

 

 

관계형 데이터베이스를 이해하는 열쇠는 스키마이다. 스키마란 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것이다.  스키마에는 개체의 특성을 나타내는 속성(Attribute)과 속성들의 집합으로 이루어진 개체(Entity),  개체 사이에 존재하는 관계(Relation)에 대한 정의와 이들이 유지해야 할 제약조건을 기술한다. 스키마는 관계형 데이터베이스를 논리적으로 설계하기 위한 구조로 이해하면 된다. 관계형 데이터베이스에서 데이터들이 어떻게 읽힐지 설계하는 것이다. 

 

 

관계형 데이터베이스를 구성하기 위해서는 데이터베이스별 항목 구성, 기본키 간의 관계가 중요한다. 그래서 미리 이것을 모델링을 하는데, 이러한 개체관계모델링 가운데자주 사용하는 것이 E-R 다이어그램이다. E-R 다이어그램이란 데이터베이스별 관계를 이해하기 위해 도형과 선으로 이뤄진 그림으로 표현한 것을 말한다. ER다이어그램은 설계를 위한 추상화에, 스키마는 이를 실제 데이터베이스에 적용할 때 사용한다. 즉 ER다이어그램으로 설계하고, 스키마로 적용하는 것이다. 

 

 

 

SQL

 

 

SQL은 관계형 데이터베이스를 다루는 열쇠이다. 관계형 데이터베이스는 데이터를 여러 테이블에 나누어 저장한다고 했다. 이 데이터를 불러오려면 SQL을 활용해야 한다. 

 

 

SQL은 관계형 데이터베이스 관리 시스템(RDBMS)에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다. 대부분 데이터베이스 관련 프로그램들이 SQL을 표준으로 채택하고 있다.다양한 DBMS가 각각 조금씩 다른 방식을 가졌지만, 쓰는 언어는 SQL 하나이다. 

 

 

SQL 명령어는 크게 데이터 조작어(DML, 데이터를 조회하거나 테이블 안의 데이터를 변형할 때 사용, SELECT, INSERT 등이 대표적), 데이터 정의어(DDL, 테이블과 같은 데이터 구조를 정의할 때 쓰는 명령어, CREATE, DROP이 대표적), 데이터 제어어(DCL, 데이터베이스에 접근하는 객체에 권한을 주거나 회수할 때 사용), 트랜잭션 제어어(TCL, 결과를 작업단위, 트랜잭션 별로 제어하는 트랜젝션 제어어)로 나뉜다. 

 

 

NOSQL

 

 

관계형DB의 경우 데이터 관리를 효율적으로 할 수 있다는 장점이 있지만 관계가 복잡해지면 여러가지 문제가 발생할 수 있다. 처음 관계를 파악하는 데 시간이 많이 들고, 확장성도 떨어진다. 이를 보완하기 위해 관계형 DB와 SQL을 사용하지 않고 데이터를 관리하는 NoSQL이 나오게 된다. DBMS는 거미줄처럼 데이터를 정리한다면, NoSQL은 도서관처럼, 분류된 책장에 개별로 데이터들이 꽂혀있는 것이다. 대표적인 NoSQL DBMS로는 mongoDB가 있다. 

 

 

 

SQL vs NoSQL

 

 

SQL

 

장점: 사용하고 구성하기 용이하다. 범용적으로 사용되고 있고, 높은 트래픽을 감당하기에 용이하고, 구조화된 데이터를 다루기에 용이하다.

 

단점: 구조와 디자인을 이해하는데 시간이 걸리고, 확장성이 떨어진다. 

 

 

 

NoSQL

 

장점: 디자인 절차가 필요 없다. 빠른 개발 주기. 일반적으로 SQL보다 빠르고, 클라우드 서비스에 적합하다. 

단점: 데이터간 관계가 중요한 경우 적합하지 않다. 기술적으로 성숙도가 낮고, 응답시간이 느린편이다. 

 

 

그래서 PM은 데이터베이스로 무얼하나?

 

 

PM은 일정 데이터를 남기거나 데이터베이스를 만들어달라고 요청할 수 있기 위해, 어떠한 데이터와 데이터베이스가 왜 필요한지, 관계자에게 설명하거나 때로는 설득해야 한다. 물론 개발자가 먼저 DB를 설계의 중요성을 이야기할 때도 있다. 데이터가 제품 개발과 개선의 어떤 부분에서 필요할지 그 의도를 알고 전달해야 한다. 그 다음 이렇게 구축한 데이터베이스와 남은 데이터를 활용하여 서비스의 문제를 파악할 수 있어야 한다. PM이 본인의 역량에 따라 직접 추출부터 분석까지 다 할 수도 있지만, 일부를 진행하거나, 동료에게 요청하여 받은 데이터를 분석하는 일만 하는 경우도 많다. 

 

 

Google Data Analyst Course에서 안내하는 데이터분석 과정을 보면:

 

 

첫단계-요청: 목적과 문제에 따라서 분석이 필요함을 요청, 또는 어떤 데이터가 필요한지 데이터분석가와 같이 정의. 

두번째 단계-준비: 분석 가능한지, 수집이 되고 있는지, 데이터를 분석할 수 있도록 바꾸는 전처리 과정이 필요한지 확인하는 과정. 간단히 이야기 하면, 분석을 위한 준비 과정이다. 

세번째 단계-데이터 정리: 분석할 수 있게 데이터 정리

네번째 단계-분석: 정리한 데이터 분석. 특이사항, 유의미한 패턴 등을 찾고, 나온 결과를 잘 정리해야 한다. 

다섯번째 단계-공유: 분석 결과 공유. 이해관계자가 잘 이해하도록 시각화를 하거나 그 흐름을 정리한다. 

여섯번째-실행: 분석 결과 기반으로 실제 액션을 진행. 

 

 

Product Team과 데이터 분석: 

 

 

데이터 분석에 참여하는 실무자는 다음과 같은 실무자가 있다: 

 

 

1. 데이터 분석가 – 데이터를 받아 유의미한 인사이트를 찾아내는 사람

2. 데이터 과학자 – 데이터를 다양한 기법(머신러닝, 통계 분석 등)을 사용해 유의미하게 가공하는 사람, 머신러닝, 통계 분석 등의 전문가인 경우가 많다. 

3. 데이터 엔지니어 – 데이터와 관련된 기술을 다루고 데이터베이스를 구축하는 사람

4. 소프트웨어 엔지니어 – IT 프로덕트를 개발하는 사람. 고객 데이터는 제품에서 나오기 때문에, 소프트웨어 엔지니어도 데이터 팀에 속한다.

 

 

PM은 IT 프로덕트를 개선하기 위해 필요한 데이터의 의미와 활용 방법을 이해하고, 데이터 분석 과정을 이해하며 데이터 분석가나 데이터 과학자 등과 함께 일하면서 분석 결과를 이해관계자들에게 전달하는 역할을 수행한다. 이를 통해 더 나은 제품과 서비스를 만들어 나가는 역할을 하는 것이다. 

 

 

PM이 데이터를 다룰 때 유의해야할 사항

 

 

일 잘하는 PM은 내 제품의 데이터와 DB가 어떻게 구성되었는지 완벽히 알고, 스키마 구조도 그릴 수 있어야 하며, SQL을 활용하여 분석에 필요한 csv 파일까지 불러올 수 있어야 한다고 하지만, 여기서 가장 중요한 것은 제품을 기획할 때는 어떤 데이터가 필요한지 파악해 요구사항에 반영할 수 있어야 한다. 그 다음 제품을 분석할 때는 어떤 데이터를 가져와서 볼지 파악해야 한다. 

 

PM은 관계형 DB의 특성을 이해해야 한다. 

관계형 DB 형식을 이해하고, 스키마나 기본 키를 확인해야 한다. 실제 데이터를 활용하기 시작한다면 가장 먼저 내가 보려고 하는 데이터가 어디에 있는지, 회사 DB의 구조를 파악할 수 있는 문서를 보는 등의 질문과 물음으로 시작하게 되는 경우가 많다는 것을 유념해야 한다. 

 

 

DB 스키마는 한번 정하면 바꾸는 것이 거의 불가능하다.

직접 스키마를 초기에 설계하거나 고려하지는 않을 수 있으나, 구조를 바꾼다는 얘기를 들으면 오래 걸릴 수도 있겠다는 생각을 해야 한다. 

 

 

수집된 데이터는 항상 가공이 필요하다.

수집만 고려하고 수집 형식이나 실제 데이터가 분석을 고려하지 않게 수집되고 있을 수 있어, 전처리 과정이 필요하다.

데이터가 왜 필요한지, 어떤 문제가 있는지, 어떤 관점으로 볼 것인지 등의 부분은 PM이 더 많이 고민해야하는 부분이다.

 

 

 

---

 

그럼 과제글로 다시 만나요👋