[IT 기획자 가이드] 데이터의 창고를 설계하다: 기획자를 위한 데이터베이스(DB) 기초

안녕하세요, IT UI/UX 기획자 디노에디입니다.

 

지난 시간까지 API와 상태 코드를 통해 서비스 간의 '통신'을 공부했다면, 오늘은 우리 서비스의 모든 정보가 안전하게 저장되고 관리되는 거대한 창고, 데이터베이스(Database, DB) 이야기를 해보려고 합니다.

 

기획자가 DB 구조를 이해한다는 것은 단순히 기술 지식을 쌓는 것이 아닙니다. "이 기능은 현재 데이터 구조상 구현에 시간이 오래 걸립니다"라는 개발자의 피드백을 논리적으로 이해할 수 있게 되고, 나아가 데이터의 흐름을 고려한 탄탄한 서비스 설계를 할 수 있게 된다는 것을 의미합니다.

 

그럼, 복잡한 DB의 세계를 기획자의 시선으로 쉽게 풀어보겠습니다.

---

SMALL

1. 데이터베이스는 거대한 '엑셀 파일'들의 모임입니다

개발자들이 말하는 DB는 어렵게 느껴지지만, 사실 우리가 매일 사용하는 엑셀(Excel)과 구조가 매우 흡사합니다. 다음 세 가지 용어만 기억하세요.

• 테이블(Table): 엑셀 파일 내의 '시트' 하나를 의미합니다. (예: 유저 정보 시트, 상품 목록 시트)
• 컬럼(Column): 엑셀의 '열(세로줄)'입니다. 데이터의 속성을 정의합니다. (예: 유저명, 아이디, 가입일)
• 로우(Row): 엑셀의 '행(가로줄)'입니다. 실제로 쌓인 데이터 한 줄 한 줄을 의미합니다.

기획자가 화면에 "내 구매 내역" 페이지를 보여주고 싶다면, 단순히 디자인만 하는 것이 아니라 '유저 테이블'과 '주문 테이블'에서 어떤 데이터를 뽑아와야 할지 상상할 수 있어야 합니다.

---

2. 기획자가 꼭 알아야 할 핵심 개념: PK와 관계(Relationship)

DB 설계의 핵심은 '어떻게 데이터를 고유하게 식별하고, 서로 연결할 것인가'에 있습니다.

① PK (Primary Key, 기본키): 겹치지 않는 고유 번호

모든 데이터는 서로를 구분할 수 있는 고유한 주민등록번호 같은 것이 필요합니다. 이를 PK라고 부릅니다.

• 기획 포인트: 사용자가 닉네임을 바꿀 수도 있고, 동명이인이 있을 수도 있습니다. 따라서 기획자는 "유저를 구분할 때 닉네임 대신 고유한 '유저 번호(User_ID)'를 기준으로 로직을 짤게요"라고 말해야 합니다. 이것이 데이터 기반 기획의 기초입니다.

② 관계(Relationship): 테이블과 테이블을 잇는 법

하나의 테이블에 모든 정보를 넣으면 파일이 너무 무겁고 관리가 힘들어집니다. 그래서 데이터를 쪼개서 저장하고 필요할 때 연결합니다.

• 1:N (일대다) 관계: 한 명의 유저가 여러 개의 리뷰를 쓰는 경우입니다. 가장 흔한 형태죠.
• N:M (다대다) 관계: 여러 명의 학생이 여러 개의 강의를 듣는 수강신청 시스템 같은 경우입니다. 이때는 중간에 '수강신청 내역'이라는 연결 테이블이 필요합니다.
• 기획 포인트: 새로운 기능을 기획할 때 "이 데이터는 기존 테이블에 컬럼 하나만 추가하면 될까요, 아니면 새로운 테이블을 파서 연결해야 할까요?"라고 질문해 보세요. 개발자와의 대화가 훨씬 깊어질 것입니다.

---

3. DB 구조를 이해한 기획자의 '진짜' 디테일

DB를 아는 기획자의 기획서는 개발자가 수정할 부분이 거의 없습니다. 다음과 같은 디테일이 살아있기 때문입니다.

• 정렬(Sorting)과 필터: 목록 화면을 기획할 때 "이 목록은 DB의 '생성일(Created_at)' 역순으로 기본 정렬하고, '수정일(Updated_at)' 기준으로도 필터링할 수 있게 해주세요"라고 명확히 지시할 수 있습니다.
• 히스토리 및 로그 관리: 유저가 중요 정보를 수정했을 때, 예전 기록을 덮어씌울지(Update), 아니면 별도의 이력 테이블에 남길지(Log)를 미리 결정할 수 있습니다.
• 데이터 타입(Data Type) 정의: 입력창 기획 시 숫자만 들어가는지, 한글/영문 글자 수 제한은 몇 자인지(Varchar 등의 개념)를 고려하여 유효성 검사 로직을 짤 수 있습니다.

---

4. "DB 구조를 바꿔야 해요"라는 말의 무게

개발자가 기획안을 보고 "이건 DB 구조를 통째로 갈아엎어야 하는데요"라고 한다면, 그것은 이미 지어진 건물의 기초 공사를 다시 하겠다는 뜻과 같습니다.

초기 기획 단계에서 데이터 구조를 엉성하게 잡으면, 서비스가 성장하여 데이터가 수십만 건이 쌓였을 때 수정 비용이 기하급수적으로 늘어납니다. 기획자가 DB를 공부해야 하는 가장 큰 이유도 바로 여기에 있습니다. 

 

나중에 발생할 엄청난 리소스를 기획 단계에서 방어하기 위함이죠.

---

마치며: 구현 가능한 완벽한 설계도를 위하여

기획자가 직접 SQL문을 짜서 데이터를 추출할 필요는 없습니다. 하지만 우리가 설계하는 화면 뒤에서 데이터들이 어떤 규칙으로 쌓이고, 어떤 길을 따라 흐르는지 머릿속으로 그려보는 습관을 지녀야 합니다.

데이터라는 뼈대를 이해하고 그 위에 UI라는 살을 붙일 때, 여러분의 기획서는 비로소 개발자에게 '구현 가능한 완벽한 설계도'가 될 것입니다.

 

오늘의 내용이 유익하셨다면 '공감' 부탁드려요! 여러분의 응원이 다음 콘텐츠 제작에 큰 힘이 됩니다.

 

다음 포스팅에서는 기획자가 알아야 할 네트워크의 두 주인공, "클라이언트(Client)와 서버(Server)의 차이와 역할"에 대해 흥미로운 비유로 찾아오겠습니다!