데이터베이스(DB)는 왜 기획자에게 중요한가
내가 쿼리를 짤 일은 없지만, 구조는 알아야 산다
모든 서비스는 결국 데이터를 저장하고, 불러오고, 수정하는 행위의 반복입니다. 그런데 이 데이터가 어떻게 저장되고 관리되는지 기획자가 모르면, 실제 서비스의 흐름을 제대로 설계할 수 없습니다.
“데이터베이스(DB)”라는 단어만 들어도 괜히 어렵게 느껴지죠. 테이블, 컬럼, 쿼리… 낯선 용어들 투성이니까요.
그런데 사실 기획자가 알아야 할 수준은 생각보다 간단합니다.
DB? 쉽게 말하면 엑셀표다
DB는 Database, 즉 데이터를 저장해 두는 공간이에요.
기획자 입장에선 너무 어렵게 생각하지 말고, 엑셀로 비유해 보세요.
엑셀의 한 시트 = DB의 테이블
각 열(column) = 필드명
각 행(row) = 레코드(한 사람, 한 건의 데이터)
그 안에 들어가는 값들 = 실제 데이터
예: 고객 정보 DB 테이블
우리가 기획하는 대부분의 기능은, 이 표에 뭔가를 추가하거나, 꺼내거나, 수정하거나, 삭제하는 행위입니다.
관계형 DB vs 비관계형 DB?
또 헷갈린다고요?
관계형 DB(RDB: Relational Database)
엑셀 같은 표 구조로 데이터를 나누고,
테이블 간의 관계를 연결해서 정보를 관리합니다.
예: 고객 ↔ 주문 ↔ 결제
사용하는 DB: MySQL, Oracle, PostgreSQL 등
쓰임새: 은행, 통신사, 쇼핑몰처럼 데이터 정확성이 중요한 곳
→ 실무에서는 거의 관계형 DB(RDB)가 기본입니다.
→ 기획자가 만나게 될 대부분의 서비스도 이 방식이에요.
비관계형 DB(NoSQL: Not Only SQL)
표가 아니라 JSON 같은 문서 형식으로 저장합니다.
형태가 자유로워서, 자주 바뀌는 데이터를 다룰 때 유리해요.
예: 채팅 데이터, 앱 알림, 게임 로그
사용하는 DB: MongoDB, Firebase 등
참고: JSON 형식이란?
{
"user_id": "001",
"name": "김기획",
"birth_date": "1990-01-01",
"phone": "01012345678"
}
→ 데이터를 ‘{key: value}’ 형태로 감싸서 하나의 덩어리로 저장하는 방식입니다.
기획자가 꼭 알아야 할 DB 개념
기획자가 직접 SQL을 짜거나 쿼리를 돌릴 필요는 없습니다.
하지만 아래는 반드시 알고 있어야 합니다.
데이터 구조: 고객 정보가 어느 테이블에 저장되는지
필드명/타입: 날짜인지 텍스트인지, 필수값인지 선택값인지
데이터 흐름: 어떤 액션에서 어떤 데이터가 저장되는지
실패 시 처리: 저장 오류 시 에러 메시지나 예외 처리 여부
→ 이 정도만 알아도 기획 흐름을 명확하게 잡을 수 있고, 개발자와도 대화가 됩니다.
⸻
기획자가 DB를 몰라서 생기는 흔한 실수들
기획서에는 화면이 있는데, 실제로 저장할 필드가 없음
→ "이건 어디 저장하죠?"라는 질문을 받음
이미 존재하는 DB 구조를 무시하고 기능을 새로 설계함
→ 테이블/컬럼 중복 생성 → 개발 난이도, 테스트 비용 증가
수정 버튼은 만들었는데, 수정할 대상이 정의되어 있지 않음
→ 어떤 데이터를 기준으로 수정할지 불분명
테스트 중 “값이 안 들어갔어요”만 반복
→ 어떤 필드에, 어떤 조건으로 안 들어간 건지 분석 불가
→ 이런 실수가 반복되면 "저 사람은 전체 구조를 잘 몰라"라는 평을 듣게 됩니다.
기획자가 할 수 있는 DB 관련 질문 예시
“이 데이터는 기존 테이블에 컬럼 추가인가요, 신규 테이블이 필요한가요?”
“이 필드는 NULL 허용되나요? 아니면 필수인가요?”
“수정 이력은 별도 테이블로 관리하나요?”
“삭제는 실제 삭제인가요, 상태값 변경인가요?”
이런 질문만 해도 개발자에게 신뢰감을 줍니다.
마무리하며
기획자는 DB 전문가가 아니어도 됩니다.
하지만 DB를 모르면 기능이 작동하는 ‘기반’을 이해하지 못하게 되고, 그렇게 되면 설계 단계에서 계속 허점이 발생합니다.
데이터가 어디서 태어나고, 어디로 저장되는지 이해할 수 있다면, 당신은 이미 ‘흐름이 보이는 기획자’입니다.
