기획자를 위한 데이터베이스 기초

안녕하세요, IT 다이어리 독자 여러분~! 오늘부터 기획자분들을 위한 데이터베이스와 SQL 시리즈를 시작해볼게요. 회사에서 개발자들이랑 소통할 때 DB 얘기만 나오면 머리가 아픈 분들 많으시죠? 이 시리즈를 통해 개발자들과 더 원활하게 소통하고, 신뢰를 받을 수 있을 거예요!

기획자, 왜 데이터베이스를 알아야 할까요?

"아니... 난 기획자인데 데이터베이스를 왜 알아야 하냐고요?" 라고 생각하시는 분들, 잠시만요! 요즘 어떤 서비스든 데이터 기반으로 움직이고 있잖아요. 사용자가 어떤 버튼을 더 많이 클릭하는지, A/B 테스트 결과는 어떤지, 서비스 개선 방향을 어떻게 잡아야 할지... 이 모든 게 결국 데이터에서 시작된다는 거 다들 아시죠?

제가 실제로 기획자로 일하면서 데이터베이스를 알게 되니까 이런 장점들이 있더라고요:

개발자랑 회의할 때 "DB 테이블 구조 같이 봐도 될까요?"라고 물어보면 개발자들이 더 적극적으로 설명해줌 (리얼 한 팀으로 일할 수 있음!)
데이터 분석가한테 "이 테이블이랑 저 테이블 조인해서 이런 데이터 뽑아주실 수 있나요?"라고 정확하게 요청 가능
급하게 데이터가 필요할 때 개발자 스케줄 기다릴 필요 없이 직접 간단한 쿼리 날려서 확인 가능 (업무 효율성 증가!)
서비스 구조를 더 깊이 이해하게 되어 "아, 이건 DB 구조상 이렇게 하면 더 효율적이겠다" 같은 인사이트로 기획 품질 향상

IT 업계에서는 이제 기획자도 데이터를 직접 다룰 줄 알아야 해요. 특히 요즘 핫한 제품 관리자(PM)나 그로스 해커(Growth Hacker) 같은 포지션은 SQL을 기본 스킬로 생각하는 추세죠. 채용공고만 봐도 "SQL 사용 가능자 우대" 이런 문구 많이 보이잖아요!

데이터베이스가 뭔데요? 그냥 엑셀이랑 뭐가 달라요?

쉽게 말해서 데이터베이스는 체계적으로 정리된 데이터 모음이에요. "아, 그냥 엑셀 시트 같은 거구나~" 라고 생각하실 수도 있는데, 훨씬 더 강력하고 대용량 데이터를 효율적으로 관리할 수 있어요.

10만 건의 고객 데이터를 엑셀로 관리하다가 파일이 깨졌다고 생각해보세요... 진짜 끔찍하겠죠?

엑셀 vs 데이터베이스, 뭐가 다를까요?

가장 큰 차이점은 확장성과 안정성이에요. 엑셀은 개인이 소규모 데이터를 다루기에 좋지만, 서비스가 성장하면서 발생하는 방대한 데이터를 처리하기엔 한계가 있어요.

저도 학부생때 운영했던 서비스의 모든 데이터를 엑셀로 관리했다가 사용자가 늘어나면서 엑셀이 감당을 못해서 급하게 DB로 마이그레이션 했던 아찔한 경험이 있어요...

관계형 데이터베이스 vs 비관계형 데이터베이스

이왕 배우는 거 제대로 알아야겠죠? 데이터베이스에는 크게 두 가지 유형이 있어요.

관계형 데이터베이스 (RDBMS)

테이블 형태로 데이터 저장 (행과 열로 구성, 엑셀 시트랑 비슷한 느낌)
각 테이블 간의 관계를 설정할 수 있음 (이게 진짜 강력해요!)
SQL을 사용해 데이터 관리 (이번 시리즈에서 배울 내용!)
대표적인 것들: MySQL(무료), PostgreSQL(무료), Oracle(유료), SQL Server(유료)
장점: 구조화된 데이터, 정확성, 일관성 보장 (금융, 쇼핑몰 같은 곳에서 중요)
단점: 한번 구조 만들어놓으면 변경하기 어려움, 수평 확장의 한계 (서버 늘리기 어려움)

비관계형 데이터베이스 (NoSQL)

다양한 형태로 데이터 저장 (문서, 키-값, 그래프 등)
"이거 필요해? 그럼 그냥 추가해!" 식의 유연한 구조
엄청난 양의 데이터 처리에 유리 (빅데이터 처리할 때 좋음)
대표적인 것들: MongoDB(문서형), Redis(키-값), Neo4j(그래프형), Cassandra(컬럼형)
장점: 유연성, 확장성, 빠른 개발 (스타트업이나 소셜미디어에서 선호)
단점: "이 데이터 정확한 거 맞아?" 일관성 보장이 상대적으로 약함

기획자는 주로 관계형 데이터베이스를 접할 일이 많으니 이번 시리즈에서는 관계형 데이터베이스와 SQL에 집중할게요! (근데 MongoDB 같은 것도 요즘 많이 쓰이니 나중에 기회 되면 그것도 다뤄볼게요!)

데이터베이스 기본 용어 (개발자들이 자주 쓰는 용어 해석!)

개발자들이랑 회의할 때 자주 나오는 용어들을 정리해봤어요:

테이블(Table): 데이터를 저장하는 표 형태의 객체예요. 예를 들어 '사용자' 테이블, '주문' 테이블 등이 있을 수 있어요. 엑셀의 시트와 비슷하다고 생각하시면 돼요. 실제로 네이버 같은 서비스는 수백 개의 테이블이 있어요!

레코드(Record) 또는 행(Row): 테이블에서 하나의 데이터 항목이에요. 사용자 테이블에서는 한 명의 사용자 정보가 하나의 레코드가 되죠. 엑셀의 한 행과 같아요. 예를 들어 "김민준, 26세, 서울 거주" 같은 정보가 하나의 레코드죠.

필드(Field) 또는 열(Column): 각 데이터의 속성이에요. 사용자 테이블이라면 '이름', '이메일', '가입일' 등이 필드가 될 수 있어요. 엑셀의 열과 동일한 개념이에요. 필드마다 데이터 타입도 지정할 수 있어요 (텍스트인지, 숫자인지, 날짜인지 등).

스키마(Schema): 데이터베이스의 구조와 제약 조건을 정의한 것이에요. 쉽게 말해 데이터베이스의 설계도라고 할 수 있어요. "아파트 평면도" 같은 개념이라고 생각하시면 됩니다. 기획자가 이해하면 정말 도움 많이 되는 부분이에요!

기본 키(Primary Key): 각 레코드를 고유하게 식별할 수 있는 값이에요. 주민등록번호 같은 개념이죠. 보통 '사용자ID'와 같은 것이 기본 키가 돼요. 절대로 중복될 수 없고, NULL(비어있음)이 될 수 없어요. "user_123456" 같은 식별자예요.

외래 키(Foreign Key): 다른 테이블의 기본 키를 참조하는 필드예요. 이걸로 테이블 간의 관계를 설정해요. 예를 들어, 주문 테이블의 '사용자ID'는 사용자 테이블의 '사용자ID'를 참조할 수 있어요. 이게 바로 '관계형' 데이터베이스의 핵심이죠!

인덱스(Index): 데이터 검색 속도를 높이기 위한 데이터 구조예요. 책의 색인과 비슷한 개념으로, 특정 데이터를 빠르게 찾을 수 있게 해줘요. 인덱스가 없으면 천만 건의 데이터에서 한 명을 찾을 때 처음부터 끝까지 다 뒤져야 하는데, 인덱스가 있으면 빠르게 찾을 수 있어요!

쿼리(Query): 데이터베이스에 정보를 요청하는 명령어예요. SQL로 작성되며, 데이터 조회, 추가, 수정, 삭제 등의 작업을 수행할 수 있어요. 기획자라면 최소한 SELECT 쿼리는 작성할 줄 알면 좋아요 (다음 시간에 배울 거예요!)

트랜잭션(Transaction): 데이터베이스에서 하나의 논리적 작업 단위를 말해요. 예를 들어, 계좌 이체는 출금과 입금이 모두 성공해야 완료되는 하나의 트랜잭션이죠. 중간에 문제가 생기면 모든 변경사항이 취소돼요(롤백). 은행 송금할 때 "보내는 건 성공했는데 받는 건 실패했다"는 일이 없도록 해주는 거죠!

데이터베이스 관계의 종류 (이건 기획할 때 정말 중요해요!)

테이블 간의 관계는 세 가지 유형으로 나눌 수 있어요. 이거 이해하면 서비스 설계할 때 큰 도움이 된답니다!

1:1 (일대일) 관계

한 테이블의 레코드가 다른 테이블의 레코드 하나와만 연결되는 관계
예: 사용자와 사용자 상세 정보 (한 사용자는 하나의 상세 정보만 가짐)
실제 사례: 카카오톡에서 기본 프로필과 상세 프로필 정보를 분리해서 저장하는 경우
활용: 자주 사용하지 않는 데이터를 별도 테이블로 분리할 때 주로 사용 (성능 최적화 위해)

1:N (일대다) 관계

한 테이블의 레코드가 다른 테이블의 여러 레코드와 연결되는 관계
예: 사용자와 주문 (한 사용자는 여러 주문을 할 수 있음)
실제 사례: 네이버 카페에서 한 회원이 여러 개의 게시글을 작성하는 관계
활용: 가장 흔한 관계 유형으로, 대부분의 비즈니스 로직에서 발견됨

N:M (다대다) 관계

양쪽 테이블의 레코드가 서로 여러 개와 연결될 수 있는 관계
예: 학생과 강의 (한 학생이 여러 강의를 수강하고, 한 강의에 여러 학생이 참여)
실제 사례: 유튜브에서 사용자와 구독 채널의 관계 (한 사용자가 여러 채널 구독, 한 채널은 여러 구독자 보유)
활용: 직접 구현은 어려워서 보통 중간 테이블(연결 테이블)을 통해 두 개의 1 관계로 구현

예를 들어서 '사용자-강좌' 다대다 관계를 구현할 때는 '수강신청' 이라는 중간 테이블을 만들어서 해결할 수 있어요. 이렇게 하면 "언제 수강신청 했는지", "수강완료 했는지" 같은 정보도 함께 저장할 수 있거든요!

실제 서비스에서의 데이터베이스 구조 예시

실제 서비스는 어떻게 데이터베이스를 구성할까요? 인스타그램 같은 SNS 앱을 예로 들어볼게요:


사용자(Users) 테이블:
- 사용자ID (기본 키) ← "user_123456" 같은 고유 식별자
- 이름 ← "김민준"
- 이메일 ← "minjun@example.com"
- 프로필사진 ← "profile_123.jpg" (실제 이미지가 아닌 경로만 저장)
- 가입일 ← "2024-05-07 14:30:00"
- 상태 ← "active" (활성 / 휴면 / 탈퇴 등)

게시물(Posts) 테이블:
- 게시물ID (기본 키) ← "post_789012"
- 사용자ID (외래 키) ← "user_123456" (누가 작성했는지)
- 내용 ← "오늘 한강에서 피크닉 중!"
- 이미지URL ← "photo_789.jpg"
- 작성일 ← "2024-05-07 15:20:00"
- 수정일 ← "2024-05-07 15:25:00"
- 공개상태 ← "public" (전체공개 / 친구공개 / 비공개 등)

댓글(Comments) 테이블:
- 댓글ID (기본 키) ← "comment_456789"
- 게시물ID (외래 키) ← "post_789012" (어떤 게시물의 댓글인지)
- 사용자ID (외래 키) ← "user_654321" (누가 댓글 달았는지)
- 내용 ← "날씨 좋네요! 어디서 찍으셨어요?"
- 작성일 ← "2024-05-07 15:30:00"
- 수정일 ← "2024-05-07 15:30:00"

좋아요(Likes) 테이블:
- 좋아요ID (기본 키) ← "like_135790"
- 게시물ID (외래 키) ← "post_789012"
- 사용자ID (외래 키) ← "user_654321"
- 생성일 ← "2024-05-07 15:35:00"

팔로우(Follows) 테이블:
- 팔로우ID (기본 키) ← "follow_246801"
- 팔로워ID (외래 키, Users 테이블의 사용자ID 참조) ← "user_654321" (팔로우 하는 사람)
- 팔로잉ID (외래 키, Users 테이블의 사용자ID 참조) ← "user_123456" (팔로우 당하는 사람)
- 생성일 ← "2024-05-07 16:00:00"

이런 구조에서는 다음과 같은 관계가 있어요:

사용자와 게시물: 일대다 관계 (한 사용자가 여러 게시물 작성)
게시물과 댓글: 일대다 관계 (한 게시물에 여러 댓글 달림)
사용자와 댓글: 일대다 관계 (한 사용자가 여러 댓글 작성)
사용자와 게시물 좋아요: 다대다 관계 (좋아요 테이블로 구현)
사용자와 팔로우: 다대다 관계 (팔로우 테이블로 구현)

이런 데이터 관계를 이해하면 "인기 게시물 피드", "팔로우한 사람들의 최신 게시물", "내가 좋아요 누른 게시물 모아보기" 같은 기능을 기획할 때 어떤 테이블들을 어떻게 연결해야 할지 명확하게 설명할 수 있어요!

ERD(Entity-Relationship Diagram) - 개발자와 소통의 필수 도구!

ERD는 데이터베이스의 구조를 시각적으로 표현한 다이어그램이에요. 테이블(엔티티)과 그 관계를 한눈에 볼 수 있어서, 개발자와 소통할 때 매우 유용해요.

기본적인 ERD 기호:

직사각형: 엔티티(테이블)
타원: 속성(필드)
마름모: 관계
선: 엔티티 간 연결, 관계의 종류에 따라 다르게 표시

전 개인적으로 ERD를 볼 때 "아, 이 서비스는 이런 데이터 구조를 가지고 있구나!"라는 인사이트를 많이 얻어요. 특히 복잡한 서비스일수록 ERD를 보면 전체 그림을 이해하기 쉬워져요.

기획 단계에서 개발자가 만든 ERD를 함께 검토하면 "아, 이 기능을 추가하려면 이 테이블에 이런 필드가 필요하겠네요"라고 더 구체적으로 커뮤니케이션할 수 있어요!

DBMS(Database Management System) - 데이터베이스 관리 시스템

DBMS는 데이터베이스를 관리하는 소프트웨어예요. 회사마다 선호하는 DBMS가 달라요. 대표적인 DBMS로는:

MySQL

오픈 소스, 무료
가장 널리 사용되는 DBMS 중 하나
웹 애플리케이션에 많이 사용됨
장점: 사용하기 쉬움, 커뮤니티 지원 활발 (구글만 해도 자료 엄청 많아요)
단점: 대규모 데이터처리에서는 성능 한계
실제 사용 사례: WordPress, Facebook(초기 버전), 배달의민족 등

PostgreSQL

오픈 소스, 무료
고급 기능이 많고 확장성이 좋음
복잡한 쿼리와 대용량 데이터에 강점
장점: 표준 SQL 준수, 고급 데이터 타입 지원
단점: 초기 설정이 복잡할 수 있음
실제 사용 사례: 인스타그램, 우버, 넷플릭스 등

Oracle

상용 DBMS, 유료
엔터프라이즈급 애플리케이션에 많이 사용
안정성과 보안성이 뛰어남
장점: 강력한 성능, 많은 기능
단점: 고비용, 복잡한 관리
실제 사용 사례: 국내 은행들, 삼성, LG 같은 대기업, 정부 시스템 등

Microsoft SQL Server

상용 DBMS, 유료(Express 버전은 무료)
Windows 환경에 최적화
기업용 솔루션에 많이 사용
장점: Windows 통합, 사용하기 쉬운 관리 도구
단점: 주로 Windows 환경에 제한
실제 사용 사례: 스타벅스, eBay, 마이크로소프트 서비스 등

기획자가 사실 데이터베이스 종류까지 고려할 필요는 크게 없지만, 그래도 이왕 배우는 김에 알아두면 좋잖아요!!

기획자를 위한 데이터베이스 이해 TIP (실무에서 바로 써먹는 팁!)

서비스의 핵심 데이터 파악하기:
- 우리 서비스에서 가장 중요한 데이터는 뭐지? (예: 쇼핑몰이면 상품, SNS면 게시물)
- 어떤 데이터를 수집해야 사용자 경험을 개선할 수 있을까? (예: 검색 기록, 클릭 로그)
- 데이터의 생명주기는 어떻게 관리해야 할까? (예: 탈퇴 후 데이터 보관 기간)
- 개인정보는 어떻게 안전하게 저장할 수 있을까? (암호화 필요한 필드 식별)
데이터 간의 관계 생각하기:
- 사용자와 콘텐츠 사이에는 어떤 관계가 있지? (작성자, 좋아요, 구매자 등)
- 이 기능을 위해서는 어떤 테이블들이 연결되어야 하지?
- 이 데이터는 다른 데이터와 어떻게 연결되어야 의미가 있을까?
- 중복 데이터를 줄이려면 어떻게 구조를 설계해야 할까?
데이터 흐름 이해하기:
- 사용자가 회원가입하면 DB에 어떤 데이터가 어떤 순서로 저장될까?
- 결제가 완료되면 주문 상태는 어떻게 변경되고, 재고는 어떻게 조정될까?
- 게시물을 삭제하면 연관된 댓글, 좋아요는 어떻게 처리해야 할까?
- 데이터 백업과 복구는 어떤 방식으로 이루어질까?
데이터 요구사항 명확히 하기:
- 대시보드에서 보여줄 핵심 지표는 무엇일까? (DAU, WAU, 전환율 등)
- A/B 테스트를 위해 어떤 데이터를 수집해야 할까?
- 사용자 행동 분석을 위해 어떤 이벤트 로그를 남겨야 할까?
- 마케팅 효과 측정을 위해 어떤 데이터가 필요할까?
데이터 모델링에 참여하기:
- 기획 단계에서 개발자와 함께 ERD 회의에 참석해보세요!
- "이 기능을 위해서는 이런 데이터가 필요해요"라고 구체적으로 요청해보세요.
- 개발자들의 데이터 모델을 기획 관점에서 검토해보세요.
- "이 필드는 나중에 확장성을 고려해서 더 넓게 설계해두면 어떨까요?" 같은 제안도 해보세요.

예를 들어서 개발팀에게 "이런 데이터가 필요해요" 라고 말하는 것보다, "이 테이블에서 이런 조건으로 데이터를 조회하고 싶어요"라고 구체적으로 말했을 때 훨씬 더 빠르게 피드백을 받을 수 있을거에요. 데이터베이스를 이해하는 기획자와 그렇지 않은 기획자는 개발자들의 신뢰도가 확실히 달라요!!

다음 편에서는 SQL의 기본 문법과 간단한 쿼리문 작성법에 대해 알아볼 거예요. "SELECT * FROM users WHERE age > 25 ORDER BY signup_date DESC LIMIT 10" 이런 거 한 번 써보면 왠지 개발자 된 것 같은 기분이 들거든요! 😁

개발자에게 "이런 데이터가 필요해요"라고 말하는 대신, 직접 데이터를 조회해볼 수 있는 방법을 배워볼게요!

질문이나 의견이 있으시면 댓글로 남겨주세요! 특히 "이런 내용도 다뤄주세요!" 하는 요청 있으시면 알려주세요~ 다음 내용에 반영할게요! 그럼 다음 글에서 만나요!