2026 데이터베이스 선택 완전 가이드

PostgreSQL·MySQL·Redis·벡터DB 한국 환경 실무

이 장을 읽기 전에: 백엔드의 역할(4장 1절)을 이해하고 있는 것이 전제다. SQL 문법을 몰라도 읽을 수 있도록 작성했지만, 개념은 등장한다.
2026년 주기: 본 장은 AI 기능을 가진 앱도 시야에 넣고 있지만, 모든 시스템에서 벡터 검색이 필수라는 의미는 아니다.

애플리케이션은 "데이터"로 성립한다. 사용자의 정보, 게시물, 주문, 설정…… 이러한 데이터를 안전하게 저장하고, 필요할 때 빠르게 꺼내는 구조가 데이터베이스다. 도서관에 비유하자면, 책(데이터)을 어떻게 분류하고, 어느 선반에 놓고, 어떻게 찾아내는지를 결정하는 구조가 데이터베이스 설계에 해당한다.

1. 데이터베이스의 종류와 사용 구분

이 섹션이 답하는 질문: RDB, NoSQL, NewSQL… 무엇이 다르고, 언제 어느 것을 사용하는가?

왜 필요한가

데이터베이스는 1가지가 아니다. "어떤 데이터를, 어떻게 사용하는가"에 따라 최적의 데이터베이스는 달라진다. 잘못된 선정을 하면 앱이 성장한 후에 성능 문제나 설계의 한계에 부딪힌다. 데이터베이스 이전은 가장 비용이 높은 기술적 변경 중 하나다.

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

데이터를 "표(테이블)"의 형태로 정리하고, 표와 표의 "관계(릴레이션)"로 데이터를 연결한다. 스프레드시트의 표를 상상하면 이해하기 쉽다.

⚠️ 신규의 일반적인 웹 앱이라면 PostgreSQL은 유력한 출발점이다. 단, 기존 시스템이나 운용 지식이 MySQL에 치우쳐 있다면 MySQL도 충분히 현실적인 선택지다.

� 국내 현황: 카카오·네이버·라인 등 국내 대형 IT 기업은 MySQL 또는 PostgreSQL을 주 RDBMS로 사용한다. 금융·공공 레거시 시스템은 Oracle DB 비중이 높지만 신규 프로젝트에서는 PostgreSQL/MySQL 전환이 증가 추세다. AWS RDS/Aurora 서울 리전이 사실상 표준 운용 환경이다.

NoSQL

테이블 구조에 얽매이지 않는 유연한 데이터 저장 방식. 용도에 따라 종류가 다르다.

관리형 DB / 클라우드 DB

RDBMS를 그대로 운용하는 것이 아니라, 클라우드 서비스로 사용하는 선택지도 있다.

선정 판단 기준

실무에서의 주의점

⚠️ "MongoDB는 스키마리스라서 편하다"는 이유만으로 선택하면 후회한다. 스키마리스는 "스키마가 불필요하다"는 것이 아니라 "스키마 관리가 앱 측의 책임이 된다"는 것을 의미한다. 많은 웹 앱에서는 처음부터 PostgreSQL을 선택하는 편이 결과적으로 편하다.

⚠️ 공공기관·금융권 데이터 주권 요건: 개인정보보호법 및 금융 규제상 데이터를 국내에 보관해야 하는 경우, 글로벌 클라우드의 서울 리전(AWS ap-northeast-2, GCP asia-northeast3) 또는 NCP·KT Cloud 등 국내 CSP를 사용한다.

정리

일반적인 웹 앱에서는 RDBMS를 먼저 선택하는 것이 자연스러우며, 그 출발점으로 PostgreSQL은 강하다. 단, DB 선정은 한 번에 완결되지 않는다. 캐시, 검색, 분석, 필요에 따라 벡터 검색을 나중에 조합하는 것을 전제로 생각하는 편이 실무적이다.

2. ORM·쿼리 빌더 선정

이 섹션이 답하는 질문: SQL을 직접 작성해야 하는가? 아니면 추상화 도구를 사용해야 하는가?

왜 필요한가

애플리케이션에서 데이터베이스를 조작하려면 보통 SQL이라는 언어를 사용한다. 그러나 SQL을 문자열로서 코드에 직접 작성하면 타입 안전성이 없고, SQL 인젝션(악의적인 SQL을 주입하는 공격)의 리스크가 있다. ORM(Object-Relational Mapping) 이나 쿼리 빌더는, 프로그래밍 언어의 코드에서 SQL을 안전하게 생성하는 구조다.

---

// Prisma — TypeScript 타입 안전 쿼리 예시

import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

// 타입이 자동 추론됨 — 컴파일 시점에 오류 검출

const user = await prisma.user.findUnique({

where: { id: userId },

include: {

orders: {

where: { status: 'PENDING' },

orderBy: { createdAt: 'desc' },

take: 10,

},

},

});

// user.orders는 Order[] 타입으로 추론됨

// Drizzle — SQL에 가까운 제어

import { eq, desc } from 'drizzle-orm';

const result = await db

.select()

.from(users)

.where(eq(users.id, userId))

.limit(1);

---

선정 판단 기준

TypeScript에서는 개발 속도와 타입 생성을 중시한다면 Prisma, SQL에 가까운 제어를 유지하고 싶다면 Drizzle이 알기 쉽다.

Python에서는 SQLAlchemy가 정석이며, Go에서는 ORM을 사용하는지 생 SQL을 사용하는지를 팀 문화로 선택하는 경우가 많다.

국내 대기업·금융·공공 환경의 Java / Kotlin + Spring Boot에서는 Spring Data JPA가 표준이며, 복잡한 동적 쿼리가 많은 경우 MyBatis 또는 QueryDSL을 병용하는 패턴이 일반적이다.

⚠️ ORM을 사용해도 SQL의 이해는 불필요해지지 않는다. 인덱스, JOIN, 실행 계획, N+1 문제는 ORM 위에서도 그대로 발생한다.

⚠️ "ORM을 사용하면 SQL 인젝션을 완전히 방지할 수 있다"고는 할 수 없다. 문자열 결합으로 생 SQL을 조립하면 위험은 남는다. 파라미터화 쿼리를 철저히 할 것.

정리

ORM이나 쿼리 빌더는 생산성과 타입 안전성을 높이기 위한 도구다. 단, 복잡한 쿼리에서는 생 SQL을 사용하는 것도 보통이며, 중요한 것은 ORM을 사용하는 것이 아니라 안전하게 쿼리를 작성하는 것이다.

3. 스키마 설계의 기본 원칙

이 섹션이 답하는 질문: 데이터베이스의 "표 설계"는 어떻게 생각하는가?

왜 필요한가

스키마 설계는 애플리케이션의 기반이다. 나중에 변경하는 것이 가장 어려운 부분이기도 하다. 건물의 기초 공사에 해당하기 때문에, 처음에 충분히 생각할 가치가 있다.

RDBMS 스키마 설계에서 지켜야 할 기본 원칙:

---

-- PostgreSQL 스키마 설계 예시 — 국내 이커머스 서비스 기준

CREATE TABLE users (

id BIGSERIAL PRIMARY KEY,

email TEXT NOT NULL UNIQUE,

name TEXT NOT NULL,

phone TEXT, -- 한국 휴대폰: 010-XXXX-XXXX

ci TEXT, -- 연계정보 (본인인증 연동 시)

created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),

deleted_at TIMESTAMPTZ -- 소프트 삭제 (개인정보보호법 대응)

);

CREATE TABLE orders (

id BIGSERIAL PRIMARY KEY,

user_id BIGINT NOT NULL REFERENCES users(id),

status TEXT NOT NULL DEFAULT 'PENDING',

amount INTEGER NOT NULL, -- 원화 (소수점 없음)

pg_key TEXT, -- 토스페이먼츠 paymentKey

created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()

);

-- 자주 검색되는 컬럼에 인덱스

CREATE INDEX idx_orders_user_id ON orders (user_id, created_at DESC);

CREATE INDEX idx_orders_status ON orders (status) WHERE deleted_at IS NULL;

---

� 국내 데이터 설계 특이사항:
- 금액은 원화 기준 정수(INTEGER)로 저장. 소수점 불필요
- 개인정보보호법 대응으로 소프트 삭제(deleted_at) 패턴이 일반적
- 본인인증 연동 시 CI(연계정보)/DI(중복가입확인정보) 저장 필요
- 한국 휴대폰 번호 포맷(010-XXXX-XXXX)은 정규화 또는 숫자만 저장

실무에서의 주의점