데이터베이스 기초 용어 완전정복

배경: 포인터를 따라가던 시대에서 표로

위키백과의 데이터베이스 항목에 따르면 1960년대의 초기 데이터베이스는 IBM의 IMS 같은 계층형 모델과 CODASYL 네트워크 모델이었고, 레코드끼리 포인터(흔히 디스크 주소)로 연결되어 있었습니다. 1970년 에드거 F. 커드가 제안한 관계형 모델은 데이터를 표(관계)로 저장하고, 표끼리는 기본 키로 잇고, 연결 경로 대신 내용으로 검색하도록 바꾸었습니다. 오늘 쓰는 '테이블', '기본 키', 'SQL'이라는 말은 대부분 이 흐름에서 나왔습니다.

표와 키가 하는 일

테이블의 한 줄이 행(레코드), 각 칸의 항목 이름이 열(속성)입니다. 위키백과의 관계형 모델 항목은 기본 키를 '행을 유일하게 식별하는 최소한의 속성 묶음(후보 키) 중에서 대표로 고른 것'으로 설명합니다. 그래서 기본 키가 중복되면 "이 주문이 어느 주문인가"를 가릴 수 없게 됩니다. 다음은 개념을 보여 주기 위한 가상 예시입니다.

이름이 같아도(동명이인) 회원번호가 다르므로 두 사람을 구분할 수 있습니다. 이름을 기본 키로 삼았다면 1001과 1003을 구분하지 못했을 것입니다. 이름이 김하나인 회원을 찾는 쿼리는 SQL에서 일반적으로 아래와 같은 모양입니다(가상 예시).

SELECT * FROM members WHERE name = '김하나';

SELECT는 조회, FROM은 어느 표에서, WHERE는 어떤 조건으로를 뜻합니다. 데이터를 지우거나 바꾸는 명령(DELETE, UPDATE)은 WHERE 조건을 빠뜨리면 표 전체에 적용될 수 있으니, 실제 데이터에서는 먼저 백업을 해 두고 조건을 두 번 확인하세요.

SQL과 NoSQL을 한눈에 비교

위키백과의 NoSQL 항목은 이 이름이 하나의 기술이 아니라 여러 데이터 모델의 묶음임을 보여 줍니다. 아래 표는 그 항목이 정리한 분류와 예시입니다.

같은 항목은 많은 NoSQL 시스템이 엄격한 일관성보다 속도와 가용성을 우선하며, 갱신이 모든 서버에 곧바로 반영되지 않는 '최종적 일관성'을 쓰기도 한다고 설명합니다. 다만 일부 제품(예: MongoDB)은 트랜잭션 지원을 주요 기능으로 내세우므로, 'NoSQL은 모두 정확성이 약하다'는 식의 일반화는 맞지 않습니다.

실제 사례 세 가지

사례 1. 1970년의 논문: 관계형 모델의 등장 (개념의 사례)

영국 출신 컴퓨터 과학자 에드거 F. 커드는 1969년 IBM 연구 보고서에 이어, 1970년 학술지 《Communications of the ACM》 13권 6호에 'A Relational Model of Data for Large Shared Data Banks'를 발표했습니다. 핵심은 데이터를 저장 방식이 아니라 표(관계)라는 논리 구조로 다루자는 것이었습니다. 위키백과는 관계형 시스템이 1990년대 초에는 대규모 데이터 처리의 주류가 되었다고 정리합니다. 배울 점은 '테이블'과 '기본 키' 같은 평범한 용어 뒤에 특정 시점의 구체적인 설계 제안이 있다는 것입니다.

사례 2. SEQUEL에서 SQL로: 질의 언어의 표준화 (제도의 사례)

SQL은 1970년대 초 IBM의 도널드 체임벌린과 레이먼드 보이스가 커드의 관계형 모델을 접한 뒤 개발했고, 처음 이름은 Structured English Query Language의 줄임말인 SEQUEL이었습니다. 위키백과에 따르면 영국 회사의 상표와 겹쳐 이름이 SQL로 바뀌었습니다. 1979년에는 Relational Software(현 오라클)가 Oracle V2를 내놓았고, IBM Db2는 1983년에 상용화되었습니다. SQL은 1986년 ANSI, 1987년 ISO 표준으로 채택된 뒤 여러 차례 개정되어 가장 최근 개정이 2023년으로 기록됩니다. 배울 점은 한 언어가 연구실의 프로젝트에서 국제 표준으로 자리 잡기까지 십 년 이상 걸렸다는 점입니다. 사용하는 제품의 세부 문법은 그 제품의 공식 문서로 확인하세요.

사례 3. 'NoSQL'이라는 이름의 두 번의 등장 (용어의 사례)

위키백과에 따르면 카를로 스트로치가 1998년 'NoSQL'이라는 이름을 표준 SQL 인터페이스가 없는 가벼운 오픈소스 관계형 데이터베이스에 붙였습니다. 2009년 초에는 Last.fm의 개발자 요한 오스카르손이 이 용어를 다시 소개했다고 서술됩니다. 즉 같은 이름이 처음에는 '표를 쓰되 SQL이 없는' 제품을, 나중에는 표 구조를 따르지 않는 다양한 제품군을 가리키게 된 셈입니다. 같은 항목의 도입부는 이 용어가 2000년대 초에 등장했다고 쓰고 있어 서술이 엇갈리므로, 정확한 시기가 필요하면 원 자료를 확인해야 합니다. 배울 점은 'NoSQL'이 엄밀한 기술 정의가 아니라 시기에 따라 가리키는 대상이 달라진 이름이라는 것입니다.

내 서비스와 일상에서 확인하기

• 데이터를 먼저 그려 보기: 저장할 정보를 종이에 표로 그려 보고, 각 행을 구분할 값(회원번호, 주문번호)이 무엇인지 정합니다.
• 선택 기준 따져 보기: 데이터 사이의 관계가 많고 정확성이 중요하면 관계형, 문서 형태로 구조가 자주 바뀌면 문서형 같은 NoSQL을 검토할 수 있습니다. 정답은 요구 사항에 따라 달라집니다.
• 백업 점검하기: 사본이 있는지, 실제로 복원해 본 적이 있는지 확인합니다. 방법은 데이터 백업 3-2-1 원칙을 참고하세요.
• 뉴스 읽을 때: 유출 사고 기사의 '데이터베이스가 노출됐다'는 저장된 정보 모음이 외부에서 접근 가능했다는 뜻입니다. 내 정보가 해당된다면 개인정보 유출 통지 대응을 보세요.

흔한 오해와 정정

• 오해: 데이터베이스는 엑셀 파일과 같다. 실제: 표 모양은 비슷하지만, 데이터베이스는 DBMS라는 소프트웨어를 통해 데이터를 입력·저장·조회·관리합니다(위키백과). 키를 통한 연결과 조건 검색이 기본 기능입니다.
• 오해: NoSQL은 SQL을 대체하려고 나왔다. 실제: 목적이 달라 함께 쓰이기도 하며, 위키백과는 관계형을 유지하면서 NoSQL 수준의 성능을 노린 NewSQL 시도도 있었다고 적습니다.
• 오해: 기본 키는 반드시 숫자다. 실제: 행을 유일하게 구분하기만 하면 됩니다. 숫자 번호가 흔할 뿐 형태가 정해져 있지는 않습니다.
• 오해: 백업이 있으면 안전하다. 실제: 백업은 이전 상태로 복원할 수 있어야 의미가 있습니다. 복원해 보지 않은 백업은 확인되지 않은 사본입니다.

한계와 더 알아볼 점

이 글은 용어 입문이며 성능 튜닝, 인덱스, 트랜잭션 설계, 보안 설정은 다루지 않습니다. 트랜잭션이 보장하려는 네 가지 성질(원자성, 일관성, 격리성, 지속성; ACID)은 데이터 정확성을 이해하는 다음 주제입니다. 어떤 데이터베이스를 고를지는 데이터 규모, 일관성 요구, 팀의 경험에 따라 달라지므로 한 가지 정답은 없습니다. 제품별 기능과 제한은 각 제품의 공식 문서에서 확인하세요.

자주 묻는 질문

이어서 읽어 보세요

• API란 무엇인가: 서비스가 데이터를 주고받는 방식
• 데이터 백업 3-2-1 원칙: 백업을 설계하는 기본 원칙
• 사이버 보안 용어: 데이터 유출·접근 통제 관련 용어
• 프로그래밍 언어 개요: SQL과 함께 쓰이는 언어들