DB: DB 기초 1

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

원론적으론 데이터를 모아놓은 집합을 데이터베이스라 부를 수 있다. 그렇기에 단순 파일에 데이터를 저장하고 모아놓았다면 그 또한 DB라고는 할 수 있다. 그리고 이를 CRUD(Create/Read/Update/Delete)기능을 제공하여 관리/처리할 수 있도록 하는 시스템까지 결합하면 DBMS(Database Management System)이라고 한다. 초기 컴퓨터/PC 보편화 이후 단순 파일 시스템에서 우리가 익숙한 폴더구조같은 트리/그래프 형태로 정리된 파일 시스템으로 발전했고, 이후로 표 형태로 데이터를 저장해 관리하는 방식이 제시되고 보편화되면서 보통 DB를 말하면 그 종류 내지는 쿼리를 통해 데이터를 관리/처리할 수 있는 구조를 지칭하는 말로 굳어졌다.

DB/DBMS를 사용한다는 것은 여러 목적을 가진다. 그중에서도 일반적으로 이 두 가지는 핵심적으로 포함된다.

• 동시성 제어(Concurrency Control) - 여러 사용자나 프로그램이 동시에 데이터를 읽고 수정하더라도 충돌이나 잘못된 결과가 발생하지 않도록 제어할 것.
• 데이터 무결성(Data Integrity) - 데이터가 정의된 규칙과 제약조건을 만족하며 정확하고 일관된 상태를 유지하도록 할 것.

이 외에도 다른 목적성도 가질 수 있다.

• 데이터 공유(Data Sharing) - 여러 사용자와 애플리케이션이 동일한 데이터를 공동으로 사용할 수 있도록 할 것.
• 데이터 독립성(Data Independence) - 데이터의 논리적 구조와 물리적 저장 방식, 이를 사용하는 애플리케이션 코드를 가능한 한 분리해 저장 구조의 변경이 애플리케이션에 미치는 영향을 줄일 것.
• 중복 관리(Data Redundancy Management) - 불필요한 데이터 중복을 줄이고, 중복으로 인한 데이터 불일치 가능성을 관리할 것.
• 보안 및 접근 제어(Security and Access Control) - 사용자와 역할별 권한(Role/Permission)을 설정해 데이터에 대한 조회·수정·삭제 접근을 통제할 것.
• 효율적인 데이터 접근(Efficient Data Access) - 인덱스, 실행 계획, 쿼리 최적화 등을 통해 대량의 데이터를 효율적으로 검색하고 처리할 것.
• 백업과 복구(Backup and Recovery) - 장애나 오류가 발생했을 때 데이터를 복원하고 정상 상태로 되돌릴 수 있도록 할 것.

형태에 따라 크게 몇가지 종류로 나뉜다.

• 관계형 데이터베이스(Relational DBMS, RDBMS, SQL)
  • DB하면 생각났을 표 형태로 저장하는 형태이다.
  • 스키마(구조)가 고정되어 있다. 즉 한번 만들어둔 구조를 변경 가능하지만 유연하진 않다.
  • 대신 여러종류의 테이블을 구현하고 JOIN으로 여러 테이블의 정보를 결합함으로 유연성을 구현한다.
  • 때문에 종류의 확장보단 규모의 확장인 수직 확장에 더 유리하다. 일정한 형태의 정보를 대량으로, 정확하게 보관하는데 유리하다.
  • 트랜잭션은 ACID라는 핵심 속성를 따른다.
    • 원자성 (Atomicity): 트랜잭션 내의 모든 작업은 완벽하게 수행되거나, 단 하나라도 실패할 경우 전체 작업이 취소(Rollback)되어야 한다. ‘모 아니면 도’ 같은 개념이다.
    • 일관성 (Consistency): 트랜잭션이 성공적으로 완료되면 언제나 데이터베이스의 제약 조건이나 규칙을 만족하는 일관된 상태를 유지해야 한다.
    • 격리성 (Isolation): 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 다른 트랜잭션의 작업에 방해받지 않고 독립적으로 실행되는 것처럼 처리되어야 한다.
    • 영속성 (Durability): 트랜잭션이 성공적으로 완료되면, 그 결과는 시스템 장애가 발생하더라도 영구적으로 데이터베이스에 반영(Commit)되어야 한다.
  • SQL을 표준으로 사용하지만, SQL 자체가 완벽히 표준화되진 않은 언어라 세부적으로는 프로그램마다 조금씩 다를 수 있다. Oracle DB, MySQL, Maria DB, PostgreSQL등이 있다.
  • RDBMS와 SQL는 시스템과 언어로 엄밀히 말해서는 동의어는 아니지만, 밀접한 사용환경의 특성상 거의 같은 의미로 쓰일 때가 많다.
• 비관계형 데이터베이스(NoSQL)
  • 표 이외에 다른 형식, 대표적으로는 문서(JSON)나 키 등 형태로 정보를 저장한다.
  • 스키마가 유연하다. 구조가 일정하지 않고 문서마다 달라져도 이론적으론 괜찮다.
  • 테이블을 연결하여 확장하는 대신, 문서 안에 문서를 품는 형식으로 확장 가능하다.
  • 이는 정해진 규격의 정보를 갯수에서 늘리기보단 각 문서가 기능적으로 달라도 되는 수평적 확장에 더 유리하다. 다양한 정보를 유연하게 보관하는데 유리하다.
  • ACID에 대응되는 개념으로 BASE라는 핵심 속성을 따르는 편이다. 하지만 ACID 속성을 무조건적으로 충족하지 못하는건 아니다.
    • 기본 가용성(Basically Available): 일부 노드에 장애가 생겨도 시스템 전체가 중단되지 않고 가능한 범위에서 응답한다.
    • 소프트 상태(Soft State): 외부 입력이 없어도 복제·동기화 과정 때문에 데이터 상태가 일시적으로 변할 수 있다.
    • 최종 일관성(Eventually Consistent): 변경 직후에는 노드마다 데이터가 다르더라도, 추가 변경이 없다면 시간이 지나 최종적으로 같은 상태에 도달한다.
  • 또한 이 때문에 제품별로 API나 쿼리 문법이 다르다. 대표적인 종류론 MongoDB나 Redis, Firebase등이 있다.
• 디스크가 아니라 메모리에 정보를 저장하는 메모리 DB(In-Memory DB, IMDB), 다차원의 벡터(배열)에 정보를 저장하는 벡터DB(Vector DB)등도 특수한 목적에 따라 사용할 수 있다. 전자는 빠른 응답속도와 휘발성을 필요로 하는 로그인 세션, 후자는 고속 검색과 AI 개발등에 쓰이곤 한다.
• 특별히 많은 기능들을 커스텀할 필요가 없다면 Supabase가 각종 인증 시스템, 서버리스, MCP등 다양한 기능을 제공하기에 간단히 시작할 때 좋다.

종류에 따라 구조가 다르고 표준화된 용어가 없는만큼, 환경에 따라 쓰는 용어가 다를 수 있다.

의미	SQL·관계형 DB	NoSQL 문서형 DB
데이터 저장 단위	Database	Database
같은 종류의 데이터 묶음	Table	Collection
하나의 데이터 항목	Row / Record	Document
항목 내부의 속성	Column	Field
각 데이터를 구분하는 고유값	Primary Key	Document ID / Key
다른 데이터와의 연결	Foreign Key	Reference 또는 Embedded Document
여러 데이터 결합	JOIN	Lookup, Reference 조회, Embedding
데이터 구조 정의	Schema	Schema 또는 Document Structure
검색 성능 향상을 위한 구조	Index	Index
데이터 조회 명령	Query	Query

왜 DBMS를 써야하나?

DBMS를 굳이 항상 사용해야하는건 아니지만, 클라이언트-서버 구조에서 큰 규모의 서비스를 생각한다면 DBMS쪽이 관리하기 좋다.

구분	DBMS 사용	파일 등에 직접 관리
저장 구조	테이블·문서·키-값 등	JSON, CSV, 텍스트, 바이너리
검색	조건 검색, 정렬, 집계가 쉬움	직접 파일을 읽고 순회해야 함
수정	일부 레코드만 수정 가능	파일 전체를 다시 써야 하는 경우가 많음
동시 접근	여러 사용자의 접근을 관리	충돌과 덮어쓰기를 직접 처리
데이터 무결성	제약조건, 트랜잭션 지원	애플리케이션 코드가 직접 보장
대용량 처리	인덱스와 쿼리 최적화 가능	데이터가 커질수록 비효율적
백업·복구	전용 기능이 많음	파일 복사 방식이 단순함
구현 난이도	초기 설정과 운영이 필요	소규모에서는 간단함
이식성	DB 환경이 필요할 수 있음	파일 하나로 이동하기 쉬움
적합한 규모	중대형·다중 사용자	소규모·단일 사용자

온라인 게임을 기준으로 한다면 보통 클라이언트, 서버, DB까지 3개의 역할로 나뉘게 된다. 클라이언트가 서버에 처리를 요청하면, 서버에서는 DB에 요청해 데이터를 얻거나 수정하는등 처리를 진행하고, 이를 클라이언트에게 반환해주는 구조이다. DB에 클라이언트가 직접 접근해도 될텐데 왜 서버를 통해 접근하도록 해야할까?

첫번째는 무결성/보안이다. DB 자체도 계정별 권한 설정으로 어느 정도 접근을 제한할 수는 있다. 하지만 아이템 구매시 돈이 차감이나 스킬 습득을 위한 레벨 조건 같은 규칙은 DB 권한 시스템만으로는 강제할 수 없다. 클라이언트가 DB에 직접 접근하면 이런 검증 로직을 우회해 치팅이나 부정한 데이터 조작이 가능해지므로, 서버가 중간에서 모든 요청을 검증하고 나서야 DB에 반영하도록 구조를 잡는다.

두번째는 동시성이다. 여러 요청이 동시에 들어와도 서로 꼬이지 않게 처리되어야 하는데, 이 중 트랜잭션 단위의 격리(다른 트랜잭션의 중간 상태에 영향받지 않는 것)는 DB의 ACID 중 격리성(Isolation)이 기본적으로 보장하는 부분이다. 서버가 추가로 담당하는 것은 그 위에 있는 도메인 규칙 수준의 동시성이다. 같은 아이템을 여러 명이 동시에 구매 요청했을 때 재고가 1개뿐이라면 한쪽은 실패 처리해야 하는데, 이런 우선순위 판단은 DB의 격리성만으로 해결되지 않고, 서버 로직으로 설계해야 한다. 즉 DB가 트랜잭션 자체의 안전성을 보장한다면, 서버는 그 위에서 “무엇을 트랜잭션으로 묶고 어떤 순서로 처리할지”를 결정하는 역할을 한다.

이는 트래픽에 대한 안정성 보장과 처리량 확장/분산을 위해 서버를 증설하거나 나누면서 나타날 수 있는 문제들를 DB가 보조하고 검증하는 형태로 유연하고 안정하게 만들어주어, 아이템의 정보나 계정에 있는 돈이나 소유 아이템, 스킬의 정보등 MMO같이 방대한 정보를 저장/처리해야하는 상황에서 특히 빛을 발휘하게 될 것이다.