1970년, IBM의 Edgar Codd가 11쪽짜리 논문을 발표했다. 50년이 지난 지금도 우리는 그의 SELECT 문을 쓰고 있다. 관계형 모델의 탄생부터 NoSQL의 반란, CAP 정리, ACID vs BASE까지 — 데이터 저장의 두 철학을 처음부터 이해한다.
이것은 컴퓨터 과학에서 가장 오래되고, 가장 실용적이며, 가장 논쟁적인 질문이다:
데이터를 어떻게 저장하고, 어떻게 찾을 것인가?
2026년 현재, 이 질문에 대한 답은 크게 두 갈래로 나뉜다:
이 두 철학은 단순한 기술 선택이 아니다. 데이터를 바라보는 근본적으로 다른 세계관이다. 이 글에서는 그 세계관이 어디서 시작됐고, 왜 갈라졌으며, 2026년에 어떻게 다시 수렴하고 있는지를 추적한다.
Part 1은 역사와 핵심 개념을, Part 2는 2026년 데이터베이스 현황과 실전 가이드를 다룬다.
1970년 이전, 데이터베이스는 **"미로"**였다.
당시 지배적인 두 모델이 있었다:
두 모델의 공통 문제: 프로그래머가 "항해사(navigator)"가 되어야 했다. 데이터를 찾으려면 "A 테이블에서 시작해, B 포인터를 따라가고, C 인덱스를 거쳐..." 하는 식으로 물리적 구조를 알아야 했다.
그리고 가장 치명적인 문제: 데이터 구조가 바뀌면, 모든 프로그램이 깨졌다. 저장 방식이 바뀔 때마다 의존하는 코드를 전부 수정해야 했다.
1970년 6월, IBM 산호세 연구소의 Edgar F. Codd가 ACM 학술지 Communications of the ACM에 11쪽짜리 논문을 발표했다:
"A Relational Model of Data for Large Shared Data Banks" (대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델)
핵심 아이디어는 수학의 집합론에 기반했다. 데이터를 관계(relation) = 테이블로 표현하고, 각 행(튜플)은 정의된 열(도메인)의 값들로 구성된다.
혁명적이었던 것은 데이터 독립성(data independence) 개념이다:
포인터로 데이터를 연결하는 대신, **기본 키(primary key)**와 **외래 키(foreign key)**로 테이블 간 관계를 표현했다. 항해가 아니라 **선언(declaration)**으로 데이터를 다루는 방식이다.
Codd는 이 공로로 1981년 ACM 튜링상을 수상했다.
Codd의 논문을 구현하기 위해, IBM 산호세 연구소의 Donald Chamberlin과 Raymond Boyce가 1974년 **SEQUEL(Structured English Query Language)**을 개발했다.
-- SEQUEL이 가능하게 한 것: 자연어에 가까운 질의
SELECT employee_name, salary
FROM employees
WHERE department = 'Engineering'
ORDER BY salary DESC;
"어떻게 찾을지"가 아니라 **"무엇을 원하는지"**만 말하면 된다. 이것이 혁명이었다.
그러나 비극이 있었다. Raymond Boyce는 1974년 5월, SEQUEL 논문을 발표한 직후인 6월 18일에 뇌동맥류로 사망했다. 아내와 갓난 딸을 남겨두고. 그의 나이 겨우 26세였다.
SEQUEL은 상표 문제로 SQL로 이름을 바꿨고, 1977년 IBM의 System R 프로토타입으로 구현되었다. 이후 SQL은 1986년 ANSI 표준, 1987년 ISO 표준이 되었다.
1977년, Larry Ellison이 Codd의 1970년 논문을 읽고 영감을 받아 회사를 설립했다. 그들의 첫 프로젝트는 CIA를 위한 데이터베이스로, 코드명이 **"Oracle"**이었다.
1979년, Oracle Version 2 출시 — 세계 최초의 상용 SQL 관계형 데이터베이스. 이것이 오늘날 시가총액 수백조 원 기업의 시작이었다.
관계형 데이터베이스의 핵심 약속은 ACID — 1980년대 Jim Gray가 정리한 4가지 원칙이다.
A 계좌에서 B 계좌로 100만 원을 이체한다고 하자:
원자성: 1번은 성공했는데 2번이 실패하면? 돈이 증발한다. ACID는 이런 일이 절대 일어나지 않음을 보장한다. 둘 다 성공하거나, 둘 다 취소된다.
일관성: 이체 전 총액 = 이체 후 총액. 돈이 만들어지거나 사라지지 않는다.
격리성: 같은 시각에 다른 이체가 진행 중이어도, 각 트랜잭션은 서로의 중간 상태를 볼 수 없다.
지속성: 이체가 완료("커밋")되면, 직후에 정전이 나도 데이터는 보존된다.
이것이 은행, 금융, 의료, 전자상거래가 여전히 관계형 데이터베이스를 쓰는 이유다. 돈이 오가는 곳에서 "대충 맞으면 된다"는 건 용납할 수 없다.
2004년, Facebook 사용자가 100만 명이었다. 2008년에는 1억 명이 되었다. Twitter, YouTube, Amazon — 모든 인터넷 서비스가 폭발적으로 성장했다.
관계형 데이터베이스의 한계가 드러났다:
| 문제 | SQL의 한계 |
|---|---|
| 데이터 양(Volume) | 수 페타바이트의 비정형 데이터를 테이블에 넣을 수 없음 |
| 속도(Velocity) | 초당 수백만 쓰기 연산은 단일 서버의 한계를 초과 |
| 다양성(Variety) | JSON, 이미지, 로그 등 구조가 제각각인 데이터를 고정 스키마에 맞추기 어려움 |
| 확장(Scale) | 수직 확장(서버 업그레이드)은 비싸고, 한계가 있음 |
Google Bigtable(2006): Google의 내부 데이터(웹 인덱스, Google Earth, Google Finance)를 저장하기 위한 시스템. 기존 테이블과 달리 행마다 열의 수가 다를 수 있는 유연한 컬럼 패밀리 구조를 도입했다.
Amazon Dynamo(2007): Amazon의 장바구니와 주문 시스템을 위한 키-값 저장소. 핵심 아이디어: 일관성을 약간 포기하면, 가용성과 확장성을 극적으로 높일 수 있다. "최종적 일관성(eventual consistency)" 개념을 실전에 적용했다.
2009년 6월 11일, Last.fm의 개발자 Johan Oskarsson이 샌프란시스코에서 비공식 밋업을 열었다. 주제: "오픈소스 분산 비관계형 데이터베이스." 해시태그로 쓰기 좋은 짧은 이름이 필요해서 #cassandra IRC 채널에 물어봤고, 누군가 **"NoSQL"**을 제안했다.
그 밋업에서 발표된 프로젝트: Voldemort, Cassandra, CouchDB, MongoDB, HBase — 오늘날 NoSQL 생태계의 주역들이다.
"NoSQL"은 원래 "No SQL(SQL 반대)"이 아니라 **"Not Only SQL(SQL만이 아닌)"**이라는 뜻으로 확장되었다.
MongoDB (2009): DoubleClick(초당 40만 광고 처리)을 운영한 경험에서, 관계형 DB로는 그 속도를 감당할 수 없다는 것을 깨달은 창업자들이 만든 문서형 데이터베이스. JSON과 비슷한 BSON 문서로 데이터를 저장한다.
Cassandra (2008): Facebook에서 1억 사용자의 인박스 검색을 위해 개발. Dynamo의 분산 저장 + Bigtable의 데이터 모델을 결합했다. 하루 수십억 건의 쓰기를 처리해야 했다.
Redis (2009): 이탈리아 스타트업의 Salvatore Sanfilippo가 확장성 문제를 해결하기 위해 만든 인메모리 키-값 저장소. Tcl로 프로토타입 후 C로 재작성. GitHub과 Instagram이 초기 채택자였다.
1999년, UC Berkeley의 Eric Brewer 교수가 하나의 원칙을 발표했다. 2002년, MIT의 Seth Gilbert와 Nancy Lynch가 이를 수학적으로 증명해 정리(theorem)로 승격했다.
서울과 부산에 서버가 하나씩 있다고 하자. 네트워크가 끊겼다(Partition 발생). 이 순간 두 가지 선택만 가능하다:
선택 1 — 일관성(C): 서울 서버와 부산 서버가 동기화될 수 없으므로, 요청을 거부한다. 데이터 정확성은 보장하지만, 서비스가 중단된다. (가용성 포기)
선택 2 — 가용성(A): 두 서버 모두 요청에 응답한다. 하지만 서울에서 업데이트된 데이터가 부산에 반영되지 않아, 두 서버가 다른 데이터를 반환할 수 있다. (일관성 포기)
분산 시스템에서 네트워크 파티션은 반드시 일어난다. 따라서 P는 포기할 수 없고, 결국 C와 A 중 하나를 선택해야 한다.
| 유형 | 데이터베이스 | 파티션 시 행동 |
|---|---|---|
| CP (일관성 우선) | MongoDB, HBase, Redis | 정확하지 않으면 응답 거부 |
| AP (가용성 우선) | Cassandra, DynamoDB, CouchDB | 항상 응답, 나중에 동기화 |
2010년, Yale 대학의 Daniel Abadi가 CAP의 한계를 지적했다. CAP은 파티션 상황만 다루는데, 실제로 파티션은 드물게 발생한다. 평상시의 트레이드오프도 중요하다.
PACELC 정리:
Partition이 발생하면 Availability와 Consistency 중 선택하고, Else(평상시)에는 Latency와 Consistency 중 선택한다.
| 유형 | 데이터베이스 | 의미 |
|---|---|---|
| PA/EL | Cassandra, DynamoDB | 항상 빠르고 가용하지만, 일관성 희생 |
| PC/EC | Google Spanner | 항상 일관적이지만, 느릴 수 있음 |
| PA/EC | MongoDB (기본 설정) | 파티션 시 가용, 평상시 일관 |
NoSQL 세계의 설계 원칙은 BASE — Dan Pritchett가 2008년에 정리했다.
| ACID (SQL) | BASE (NoSQL) |
|---|---|
| Atomicity — 전부 아니면 전무 | Basically Available — 기본적으로 사용 가능 |
| Consistency — 규칙 항상 유지 | Soft State — 상태가 유동적일 수 있음 |
| Isolation — 트랜잭션 간 격리 | Eventual Consistency — 최종적으로 일관됨 |
| Durability — 영구 저장 |
ACID (은행): "출금과 입금은 반드시 동시에 완료됩니다. 중간에 전원이 나가도 데이터가 보존됩니다."
BASE (SNS 좋아요): "좋아요를 누르면, 일부 사용자에게는 즉시 반영되고 다른 사용자에게는 몇 초 후에 반영될 수 있습니다. 하지만 결국 모든 사용자에게 반영됩니다."
은행 잔고가 "결국 맞아질 겁니다"라면 아무도 그 은행을 쓰지 않을 것이다. 하지만 SNS 좋아요 수가 1~2초 지연되는 것은 아무 문제 없다. 데이터의 성격에 따라 적합한 보장 수준이 다르다.
SQL은 한 번 만들어진 뒤 멈춰 있는 것이 아니다. 50년간 꾸준히 진화해 왔다:
| 표준 | 연도 | 핵심 추가 |
|---|---|---|
| SQL-86 | 1986 | SELECT, INSERT, UPDATE, DELETE 기본 문법 |
| SQL-92 | 1992 | 명시적 JOIN 문법 (LEFT/RIGHT/FULL), CASE WHEN |
| SQL:1999 | 1999 | CTE(WITH 절), 재귀 쿼리, 트리거, OLAP |
| SQL:2003 | 2004 | 윈도우 함수 (ROW_NUMBER, RANK, LAG, LEAD) |
| SQL:2016 | 2016 | JSON 지원 — SQL이 NoSQL의 유연성을 흡수하기 시작 |
| SQL:2023 | 2023 | 네이티브 JSON 타입, Property Graph 쿼리(SQL/PGQ) |
가장 주목할 변화는 SQL:2016의 JSON 지원이다. 관계형 데이터베이스가 JSON 문서를 저장하고 질의할 수 있게 되면서, SQL과 NoSQL의 경계가 흐려지기 시작했다.
**SQL:2023의 그래프 쿼리(SQL/PGQ)**는 더 극적이다. 관계형 데이터베이스 안에서 Neo4j 스타일의 그래프 쿼리를 실행할 수 있다. SQL이 그래프 데이터베이스의 영역까지 흡수하고 있는 것이다.
Part 2에서는 실전으로 들어간다: