개.알.못 PM을 위한 ERD 개념 떠먹이기
이제 백엔드 개발자와 슬기롭게 커뮤니케이션 합시다!
목차
1. 개발 지식이 없는 PM
2. 비개발자도 ERD 이해합니다!
3. ERD 볼 줄 아는 놈인가?
4. 데이터베이스로 이어지는 ERD
오피스 툴에 능숙한 일잘러가 되고 싶다면,
정식 런칭한 투두몰을 만나보세요!
개발 지식이 없는 PM
1. PM의 역할
PM은 프로덕트 팀의 허브 같은 존재다. IT 프로덕트를 만들기 위해서 다양한 직군의 협업이 필수적이다. 기획자는 서비스 와이어프레임, 정책 등을 작성하고, 디자이너는 프로덕트 UI를 그리며, 프론트 개발자는 디자이너의 완성물을 화면에 담아내고, 백엔드 개발자는 서비스에 담길 데이터를 모델링한다. 여기서 PM은 서로 다른 직군의 역할을 이해하고, 이들을 하나로 모아 같은 방향으로 나아갈 수 있도록 도와줘야 한다.
계획과 액션은 다르다. 프로덕트가 완성되기 위해서 (1) 팀원 모두가 공동의 목표를 가짐과 동시에 (2) 목표를 향해 나아가는 추진력이 있어야 한다. PM이 프로덕트 로드맵, 스프린트 계획을 열심히 세웠다고 할지라도, 이를 실현할 액션이 부재하다면 프로덕트가 성공적으로 완성되기 어렵다.
2. 개발 세상을 이해하기
계획과 액션, 모두를 챙기기 위해 PM은 각 직군의 세상을 이해해야 한다. 그렇지 않으면, 원활한 커뮤니케이션이 이루어지지 않아 모든 팀원이 같은 그림을 그리지 못하게 만들 수 있다. 설령 같은 그림을 그렸다고 해도, 각 팀원이 어떤 일을 해야 하는지 이해하지 못해 협업 효율성이 떨어질 수 있다.
논리를 지닌 PM이라면 디자이너의 소통에는 문제가 적은데, 디자이너의 작업물을 보며 개선 사항을 논리적으로 말할 수 있기 때문이다. 예를 들어, 유저의 행동 패턴에 기반해 컴포넌트의 위치를 피드백 줄 수 있고, 핵심 KPI를 고려해 버튼 컴포넌트가 추가돼야 한다고 말할 수 있다.
하지만, 개발자의 협업은 다르다. 제 아무리 논리적인 사람이라고 해도, 개발 지식이 없다면 그들과 이야기할 수 없다. 개발 영역에서 상식이라고 불릴 법한 것도 모르는 사람이 개발자와 원활히 소통하는 건 사실상 불가능하다. 물론, 개발자만큼 깊게 알 필요는 없으며, 이들을 이해하고 소통할 수준의 최소 지식이면 충분하다.
물론, 개발 지식이 없어도 좋은 PM으로 활동하는 분들도 존재한다. 다만, PM은 팀의 허브이자 숲을 보는 존재라고 생각한다. 숲을 보기 위해선 나무에 대한 이해도 필요하다. 같은 숲이라고 할지라도, 나무에 대해 자세히 알고 있는 사람과 모르는 사람의 시선은 천지차이다. 적어도 IT업계의 PM이라면, 개발자와 커뮤니케이션을 위한 개발 지식을 알고 있어야 하지 않을까?
(출처 : <오늘도 개발자가 안 된다고 말했다>)
비개발자도 ERD 이해합니다!
1. 데이터 모델링
데이터 모델 개념을 아는 것만으로, PM이 생각할 수 있는 부분은 많아진다. 데이터 모델이란 어떤 데이터가 저장되고, 각 데이터는 서로 어떤 관계를 맺고 있으며, 데이터가 어떻게 흐르는지를 보여주는 모형이다. 데이터 모델을 이해한다면, 새로운 기능을 기획할 때마다 리소스를 예상할 수 있다. 기존 모델을 그대로 활용할 수 있는지, 그렇지 않으면 어떠한 테이블이나 컬럼이 추가돼야 하는지를 생각할 수 있다. 또한, 프로덕트의 KPI 지표를 어떤 테이블의 데이터를 활용하면 되는지 직접 정의하고, 시시각각 쌓이는 데이터를 분석해 인사이트를 수집할 수도 있다.
ERD는 개체 관계도(Entity-Relation Diagram)로서, 프로덕트의 데이터 모델을 보여준다. ERD는 데이터베이스 내 존재하는 개체를 정의하고, 각 개체 간의 관계를 보여준다. 여기서 칭하는 개체(Entity)는 사람, 사물, 사건 같이 독립적으로 존재하는 대상으로, 각 개체는 고유한 특성 및 상태인 속성(property)을 갖고 있다. ERD만 이해해도 백엔드 개발자와 소통에 지장이 없다고 생각한다. 개체와 속성이라는 개념이 복잡해 보이니, 우리 마이플랜잇 팀이 만든 투두몰을 예시로 봐보자
2. ERD 기초 개념
투두몰(Todomall)은 더 쉽고 빠른 오피스 툴 학습을 위해, 일잘러의 투두리스트를 제공한다. 일잘러가 만든 투두리스트와 상세 가이드를 직접 따라 하며 학습하고, 나만의 결과물을 만들 수 있다. 여기서 투두리스트로 구성된 "투두 클래스"와 클래스를 제작하는 "일잘러"가 개체(entity)가 된다. 투두 클래스마다 "학습 기간"과 "따라만 하면 완성되는 결과물"이 존재하는데, 이들이 "투두 클래스" 개체의 속성(property)이 된다.
투두 클래스로 "노 코드 툴, 버블로 MVP 서비스 만들기"와 "노션으로 나만의 포트폴리오 만들기"가 있는데, 이렇게 개체 내 실체를 개체 인스턴스(Entity Instance)라고 칭한다. "노 코드 툴, 버블로 MVP 서비스 만들기" 클래스는 1.5주 정도의 학습 기간을 지니며, 따라 하면 MVP 서비스를 최종 결과물로 만들 수 있다. 따라서, 해당 개체 인스턴스의 속성은 {학습 기간 : 1.5주}, {따라 하면 완성되는 결과물 : MVP 서비스}가 된다.
이런 느낌이랄까?ERD 볼 줄 아는 놈인가?
1. 개체 확인하기
위와 같이 정의한 투두클래스 개체를 ERD에서 표현하면 다음과 같다. ERD에서 개체를 표기할 때, (1) 개체명과 (1) 개체가 지닌 속성 및 속성의 데이터 타입(INT, VARCHAR, FLOAT, ENUM 등)을 적는다.
(1) 개체명 : todoclass
(2) 개체 속성
- id : 개체의 고유 값 / VARCHAR type
- title : 개체의 이름 / VARCHAR type
- deadline : 투두클래스의 기간 / INT type
- expectIt : 투두클래스를 완수했을 때 따라오는 결과 / VARCHAR type
- creator : 투두클래스를 제작한 사람 / VARCHAR type
ERD에는 프로덕트 내 모든 개체를 적는다. 앞서 말한 "투두리스트로 구성된 투두 클래스"와 "콘텐츠를 제공하는 일잘러"는 서로 독립적인 개체이므로, 아래처럼 그릴 수 있다. 여기서 id 속성 옆에 적힌 PK는 기본 키(Primary Key)로서, 개체 인스턴스를 식별할 수 있는 목적으로 사용 됨을 뜻한다. 서로 다른 개체 인스턴스마다 고유 id 값이 부여되며, 이를 활용해 개체 인스턴스를 알아낸다. 예시로, "노 코드 툴, 버블로 MVP 서비스 만들기"라는 개체 인스턴스의 id 값이 "djda39134 hdjf343"이라면, 다른 개체 인스턴스는 해당 값을 id로 사용하지 못한다.
2. 관계 확인하기
ERD는 어떤 개체가 있는지와 함께, 서로 다른 개체가 어떤 관계를 맺고 있는지도 보여준다. 투두 클래스 개체는 일잘러 개체가 만드는데, 이렇게 서로 다른 개체가 개념적 관계(relationship)를 맺을 경우에 아래처럼 표기한다. todoclass 개체의 creator 속성 옆에 적힌 FK는 외래키(foreign key)로서, 해당 개체가 다른 개체와 연결 됨을 뜻한다. 개체 인스턴스의 FK 값은 연결된 개체 인스턴스의 id 값이 들어간다.
예를 들어, "FameLee"라는 사람의 id가 "dddsdfsdf33"이고, "노 코드 툴, 버블로 MVP 서비스 만들기"라는 클래스를 만들었다고 해보자. 그러면, 해당 투두 클래스 개체 인스턴스가 지닌 creator 속성은 연결된 일잘러 개체의 id인 "dddsdfsdf33"가 입력된다.
개체 간 관계를 정의할 때, 관계수도 고려해야 한다. 관계수는 서로 다른 개체가 어떻게 관계를 맺고 있는지 보여주는데, 1:1, 1:N, N:N 유형이 존재한다.
위에서 다룬 일잘러와 투두 클래스 개체를 예시로 관계수를 더 뜯어보자. 일잘러 개체는 1개의 투두 클래스 개체 혹은, 그 이상을 만들 수 있다. FameLee라는 사람은 "노 코드 툴, 버블로 MVP 서비스 만들기"와 "회사 막내의 스프레드 시트 마스터하기", 총 2개의 투두 클래스를 만들 수 있다. 이런 경우, 일잘러 개체는 N개의 투두 클래스 개체와 관계를 맺을 수 있다.
이번에 일잘러가 아닌, 투두 클래스 개체를 기준으로 봐보자. 투두 클래스 개체는 만드는 사람은 무조건 1명의 일잘러 개체다. 공동 저자가 가능하다면 상관없지만, 현재 서비스에서는 그렇지 못하다. 이런 경우, 투두 클래스 개체는 1개의 일잘러 개체와 관계를 맺을 수 있다.
개체 간 관계수를 정의할 때, 각 개체마다 살펴봐야 한다.일잘러와 투두 클래스 개체, 각각을 기준으로 관계를 봤을 때 (1) 일잘러는 N개의 투두 클래스 개체와, (2) 투두 클래스 개체는 1개의 일잘러 개체와 관계를 맺는다. 즉, 관계 수는 일잘러 : 투두 클래스 = 1 : N이며, ERD에서는 다음처럼 표현할 수 있다.
데이터베이스로 이어지는 ERD
ERD의 목적은 데이터 모델 설계 구조를 작성하는 데 있기에, 작성한 ERD는 그대로 데이터베이스 구조로 이어진다. 데이터베이스는 데이터를 저장할 수 있는 여러 테이블로 구성되며, 각 테이블은 행과 열로 구성된다. 여기서 1개의 테이블(table)은 1개의 개체(entity)를 대변하며, 열(col)은 개체의 속성(property)을 대변한다. 그리고, 각 행(row)마다 개체 인스턴스(entity instance)가 추가된다.
우리가 서로 다른 테이블을 조인할 때 사용하는 SQL문을 생각해 보자. 보통 id 컬럼을 활용해 매칭하는데, 이는 ERD의 개체 관계에 기반해서 설계했기 때문이다. ERD에서 FK 속성을 활용해 개체 관계를 표기하며, 여기서 FK 값은 관계를 맺은 개체의 PK 값(=id 값)이 들어간다. FK, PK는 모두 id 속성을 사용하므로, SQL로 데이터 테이블을 조인할 때도 id 값을 사용하는 것이다.
SELECT *
FROM todoclass
INNER JOIN creator
ON todoclass.creator = creator.id
ORDER BY creator.name ASC ;
생활 코딩도 가능한 기획자가 되고 싶다면
투두몰의 데이터 분석 코딩 클래스를 들어보세요!
