데이터베이스의 역사: 천공카드부터 벡터 DB까지 60년의 진화

데이터베이스는 단순한 저장소가 아니라, 한 시대가 정보를 어떻게 이해했는지를 보여주는 거울이다. 1960년대 미국항공우주국이 아폴로 계획의 부품 정보를 관리하기 위해 만든 IMS부터, 2024년 거대언어모델이 수십억 개의 벡터를 검색하는 오늘의 파인콘과 pgvector까지, 데이터베이스는 약 60년에 걸쳐 다섯 번의 세대 교체를 겪었다. 흥미로운 점은 어느 세대도 완전히 사라지지 않았다는 사실이다. 메인프레임 위의 계층형 DB는 여전히 은행 코어에 살아 있고, 1970년대에 태어난 관계형 모델은 지금도 전 세계 데이터의 70% 이상을 책임진다. 이 글에서는 천공카드에서 출발한 데이터 관리의 역사를 다섯 시대로 나누어 짚고, 그 흐름이 인공지능 시대의 데이터 인프라로 어떻게 이어지는지 살펴본다.

1. 데이터 이전의 시대: 파일과 천공카드

1.1 천공카드 한 장의 무게

1950년대 후반까지 컴퓨터의 기억장치는 사람의 손으로 직접 만든 천공카드와 자기 테이프였다. IBM 80컬럼 카드 한 장에는 약 80바이트의 정보가 담겼고, 미국 인구조사국은 1950년 인구통계를 위해 1억 5천만 장 이상의 카드를 사용했다. 이 시기에는 데이터를 "저장한다"는 개념보다 "묶어둔다"는 개념이 강했고, 카드 한 묶음이 곧 데이터셋이었다.

문제는 검색이었다. 특정 사람의 정보를 찾으려면 카드 박스를 정해진 순서대로 한 장씩 넘겨야 했고, 정렬되지 않은 카드는 사실상 무용지물이었다. 데이터의 양이 늘어날수록 검색 시간은 선형으로 늘어났고, 인덱스라는 개념은 아직 등장하지 않았다.

1956년 IBM이 RAMAC 305에 세계 최초의 하드디스크를 탑재하면서 상황이 바뀐다. 5MB 용량에 약 1톤 무게의 이 장치는 임의 접근(Random Access)이라는 새 패러다임을 열었다. 데이터를 순서대로가 아니라 원하는 위치로 곧장 점프해 읽을 수 있게 되자, 비로소 "데이터베이스"라는 단어가 의미를 가질 수 있게 되었다.

1.2 파일 시스템의 한계

1960년대 초 메인프레임 위에는 COBOL 기반의 파일 시스템이 자리 잡았다. 각 애플리케이션은 자기만의 파일 포맷을 가졌고, 같은 고객 정보가 회계 부서, 영업 부서, 인사 부서 파일에 중복 저장되는 일이 흔했다. 한 미국 보험사의 1965년 내부 보고서에는 같은 고객의 주소가 평균 4.7개 시스템에 따로 저장되어 있다는 분석이 등장한다.

이 문제는 단순한 비효율이 아니라 무결성의 위협이었다. 한 곳에서 주소를 수정해도 다른 곳에는 반영되지 않아, 같은 회사 내에서 서로 다른 진실이 공존했다. 데이터 모델을 애플리케이션과 분리해야 한다는 자각이 이 시기부터 산업계 전반에 퍼지기 시작했다.

이러한 배경에서 1964년 제너럴 일렉트릭의 찰스 바흐만이 IDS(Integrated Data Store)를 발표하며 사실상 첫 번째 DBMS의 시대가 열렸다. 그는 데이터를 애플리케이션의 부속이 아니라 독립된 자산으로 다루어야 한다고 주장했고, 이 공로로 1973년 튜링상을 수상한다.

2. 계층형과 네트워크 DB: 1960~1970년대

2.1 IBM IMS와 아폴로 계획

1966년 NASA는 아폴로 계획에 들어가는 200만 개에 달하는 부품 정보를 관리할 시스템을 IBM에 의뢰했다. 그 결과물이 1968년 출시된 IMS(Information Management System)이며, 이는 부모-자식 관계만을 허용하는 계층형(hierarchical) 모델을 채택했다. 한 부모는 여러 자식을 가질 수 있지만, 한 자식은 단 하나의 부모만 가질 수 있다는 규칙이었다.

이 모델은 조직도나 부품 명세서(BOM)처럼 자연스럽게 트리 구조를 갖는 데이터에 매우 강력했다. 디스크 접근이 느리던 시절, 부모에서 자식으로의 직접 포인터 덕분에 검색 성능도 매우 좋았다. 실제로 IMS는 출시 50년이 넘은 지금까지도 일부 글로벌 은행의 코어 뱅킹에 남아 있으며, 일일 100억 건 이상의 트랜잭션을 처리한다고 알려져 있다.

하지만 한 자식이 여러 부모를 가져야 하는 경우, 예컨대 한 학생이 여러 과목을 듣는 관계 같은 데이터에서는 한계가 명확했다. 같은 데이터를 여러 번 복제하거나, 별도의 우회 경로를 만들어야 했다.

2.2 CODASYL과 네트워크 모델

1971년 CODASYL(Conference on Data Systems Languages)은 계층형의 한계를 극복하기 위해 네트워크 모델을 표준으로 채택한다. 이는 한 레코드가 여러 부모를 가질 수 있게 허용해 다대다 관계를 직접 표현한 모델이었다. 바흐만의 IDS가 이 모델의 원형이었다.

네트워크 모델은 표현력이 뛰어났지만, 개발자가 데이터 간 경로를 직접 지정해 탐색해야 했다. "고객 → 주문 → 상품"으로 가는 경로를 코드에 박아 넣어야 했고, 한 번 만들어진 스키마를 수정하기는 매우 어려웠다. 1970년대 후반 한 미국 통신사의 사례 보고서에 따르면, 단순한 컬럼 추가에 평균 6주, 비용은 약 12만 달러가 들었다.

이러한 절차적 데이터 접근의 무거움은 곧 새로운 패러다임을 요구하게 된다. 그리고 그 답은 IBM 산호세 연구소의 한 젊은 수학자에게서 나왔다.

2.3 세대별 DB 모델 비교

모델	등장 시기	대표 제품	구조	강점	약점
계층형	1968	IBM IMS	트리	빠른 부모-자식 탐색	다대다 표현 불가
네트워크	1971	IDMS	그래프	다대다 표현	경로 의존성
관계형	1970(논문)/1979(제품)	Oracle, DB2	테이블	선언적 질의, 무결성	조인 비용
객체지향	1986	ObjectStore	객체 그래프	OOP 친화성	표준 부재
NoSQL	2009	MongoDB, Cassandra	문서/KV/컬럼	스케일아웃	약한 일관성

3. 관계형 혁명: 1970~1990년대

3.1 코드의 한 편 논문이 세상을 바꾸다

1970년 6월, IBM 산호세 연구소의 에드거 F. 코드는 ACM 저널에 "A Relational Model of Data for Large Shared Data Banks"라는 11페이지짜리 논문을 발표한다. 이 논문은 데이터를 수학적 집합인 관계(relation), 즉 행과 열로 이루어진 테이블로 표현하고, 데이터 간의 연결은 미리 정해진 포인터가 아니라 값의 일치로 표현하자고 제안했다.

"데이터의 논리적 표현은 데이터의 물리적 저장 방식과 독립적이어야 한다." — E. F. Codd, 1970

이 한 문장은 향후 50년의 데이터베이스 산업을 결정지었다. 개발자는 더 이상 "어떻게 가져올지"를 기술하지 않고 "무엇을 원하는지"만 선언하면 되었고, 옵티마이저가 최적 경로를 찾아주었다. 이는 곧 SQL(Structured Query Language)의 등장으로 이어진다.

3.2 SQL과 상용 RDBMS

1974년 IBM의 도널드 챔벌린과 레이먼드 보이스는 코드의 관계형 모델을 실용적으로 다룰 수 있는 언어 SEQUEL을 발표했고, 이는 곧 SQL로 이름을 바꾼다. 1979년 래리 엘리슨이 이끈 릴레이셔널 소프트웨어(현 오라클)는 세계 최초의 상용 SQL DBMS인 Oracle V2를 출시한다. IBM은 자체 연구 프로젝트 System R을 1981년 DB2로 상용화한다.

1980년대 중반에는 마이크로소프트의 SQL Server(1989), 사이베이스, 인포믹스 등이 가세하면서 RDBMS 시장이 폭발적으로 성장했다. 1990년 전 세계 DBMS 시장은 약 50억 달러였고, 그중 70% 이상이 관계형 제품이었다. 2024년 가트너 추정에 따르면 DBMS 시장은 약 1,000억 달러를 넘어섰는데, 그중에서도 관계형 매출이 여전히 가장 큰 비중을 차지한다.

3.3 ACID와 트랜잭션의 정착

관계형 시대의 또 다른 핵심 자산은 ACID였다. 1983년 안드레아스 로이터와 테오 헤르더가 정리한 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)은 트랜잭션이 갖춰야 할 4대 속성을 의미한다. 은행 송금에서 한쪽 계좌에서 돈이 빠졌는데 다른 계좌에 들어가지 않는 일이 벌어지지 않도록 보장하는 것이 ACID의 본질이다.

WAL(Write-Ahead Logging), 2단계 잠금, MVCC 등 오늘날 우리가 당연하게 여기는 기법들이 모두 이 시기에 정립되었다. 특히 1992년 오라클 7이 도입한 MVCC(Multi-Version Concurrency Control)는 읽기와 쓰기가 서로를 막지 않는 새로운 동시성 모델을 제시했고, 이는 PostgreSQL, MySQL InnoDB로 이어진다.

4. 객체지향과 데이터 웨어하우스: 1980~1990년대

4.1 객체지향 DB의 짧은 전성기

1980년대 C++과 스몰토크가 부상하면서, "객체를 그대로 저장할 수는 없을까"라는 질문이 자연스럽게 따라왔다. 1986년 ObjectStore, 1988년 GemStone 같은 제품이 등장했고, 1989년에는 객체지향 DB 시스템의 8대 원칙을 정리한 "OODBMS 매니페스토"가 발표되었다.

객체지향 DB는 CAD, 통신망 관리, 과학 시뮬레이션 등 복잡한 객체 그래프가 중요한 영역에서 강세를 보였다. 그러나 표준화 실패, RDBMS 진영의 객체 기능 흡수(Oracle 8의 객체 타입, PostgreSQL의 사용자 정의 타입 등)로 인해 1990년대 후반 주류 자리에서 밀려난다.

흥미롭게도 객체지향 DB의 정신은 사라지지 않고 2000년대 후반 문서형 NoSQL과 GraphQL로 다시 부활한다. 데이터를 객체 단위로 다루려는 욕망은 언어가 바뀌어도 변하지 않았다.

4.2 데이터 웨어하우스의 탄생

1980년대 후반 빌 인먼은 "운영 시스템과 분석 시스템은 분리되어야 한다"는 주장을 통해 데이터 웨어하우스(DW)의 개념을 정립한다. OLTP가 초당 수천 건의 짧은 트랜잭션을 처리한다면, OLAP은 수억 행을 스캔하는 무거운 분석 질의를 다룬다. 두 워크로드의 본성은 완전히 달랐다.

1996년 랄프 킴벌은 스타 스키마와 차원 모델링을 제안하며 DW 설계의 실용적 표준을 만들었다. 테라데이터, IBM 네티자, 그린플럼, 버티카 같은 MPP(대규모 병렬 처리) 어플라이언스들이 1990~2000년대를 풍미했고, 이는 곧 클라우드 시대의 스노우플레이크, 빅쿼리, 레드시프트로 이어진다.

4.3 OLTP vs OLAP 특성 비교

구분	OLTP	OLAP
대표 작업	주문, 결제, 로그인	매출 분석, 코호트 분석
레코드 단위	1~수십 행	수백만~수십억 행
저장 방식	행 지향(Row-store)	열 지향(Column-store)
응답 시간 목표	10ms 내외	수초~수분
대표 제품	Oracle, MySQL, Postgres	Snowflake, BigQuery, Redshift

5. NoSQL 봉기: 2000~2010년대

5.1 웹 규모 데이터의 도전

2000년대 초반 구글, 아마존, 페이스북 같은 기업이 직면한 데이터 규모는 RDBMS의 수직 확장으로는 도저히 감당할 수 없는 수준이었다. 구글은 2003년 GFS, 2004년 MapReduce, 2006년 Bigtable 논문을 차례로 공개하며 분산 데이터 처리의 새 표준을 제시했다. 아마존은 2007년 Dynamo 논문을 통해 가용성을 위해 일관성을 포기하는 트레이드오프를 정식화했다.

"분산 시스템에서는 일관성, 가용성, 분할 내성 중 두 가지만 동시에 달성할 수 있다." — Eric Brewer, 2000년 CAP 정리

이 흐름 위에서 2009년 카산드라, 2009년 몽고DB, 2010년 리악, 2011년 카프카 등 NoSQL 진영의 주요 제품이 쏟아져 나온다. "Not Only SQL"이라는 슬로건 아래, 데이터 모델은 키-값, 문서, 컬럼 패밀리, 그래프 등 다양하게 분화된다.

5.2 NoSQL 4대 유형

NoSQL은 단일 기술이 아니라 가족 개념에 가깝다. 첫째, 키-값 저장소(Redis, DynamoDB)는 가장 단순한 모델로 캐시와 세션 관리에 강하다. 둘째, 문서형 DB(MongoDB, Couchbase)는 JSON 형태로 가변 스키마를 다룬다. 셋째, 컬럼 패밀리(Cassandra, HBase)는 시계열·로그성 워크로드의 쓰기 처리량을 극대화한다. 넷째, 그래프 DB(Neo4j, JanusGraph)는 관계 자체가 데이터인 영역, 예컨대 SNS 친구 추천이나 금융 사기 탐지에 쓰인다.

2015년 DB-Engines 통계에 따르면 NoSQL 제품 전체의 인기 지수는 RDBMS 대비 약 15% 수준이었으나, 2024년 기준 약 30%를 넘어선다. 다만 흥미로운 점은 NoSQL이 RDBMS를 대체한 것이 아니라, 워크로드를 분담하는 보완재로 자리 잡았다는 사실이다.

5.3 NoSQL의 그늘과 NewSQL의 등장

NoSQL은 스케일아웃을 얻은 대신 강한 일관성, 풍부한 질의, 트랜잭션 보장을 양보했다. 2010년대 중반 많은 기업이 이 비용을 뒤늦게 자각했고, "스케일과 ACID를 동시에"라는 요구가 NewSQL 진영을 낳는다. 구글 스패너(2012), 코크로치DB(2015), TiDB(2016), 유고바이트DB(2016)가 대표적이다.

특히 스패너가 TrueTime이라는 GPS·원자시계 기반의 글로벌 시각 동기화를 통해 분산 환경에서도 외부 일관성(External Consistency)을 달성한 것은 분산 DB 역사의 분수령이었다. CAP 정리의 한계를 우회하기보다 인프라 자체를 다시 설계하는 접근이었다.

6. 클라우드와 분리형 아키텍처: 2010년대 후반

6.1 저장소와 컴퓨트의 분리

2012년 등장한 스노우플레이크는 데이터베이스 아키텍처의 근본 가정 하나를 뒤집었다. 그동안 디스크와 CPU는 같은 노드에 묶여 있어야 한다는 전제가 있었지만, 클라우드의 S3 같은 객체 스토리지가 충분히 빨라지자 저장소와 컴퓨트를 분리해도 성능이 나오기 시작했다.

분리형 아키텍처는 세 가지 이점을 가져왔다. 첫째, 컴퓨트만 독립적으로 스케일아웃해 분석 시간에 비용을 집중할 수 있다. 둘째, 같은 데이터를 여러 워크로드가 동시에 분리된 컴퓨트로 처리할 수 있다. 셋째, 사용한 만큼만 과금하는 모델이 자연스럽게 성립한다. 2024년 기준 스노우플레이크의 연 매출은 약 35억 달러를 돌파했고, 이는 이 아키텍처의 시장 검증이었다.

6.2 데이터 레이크하우스

한편 데이터브릭스는 2020년 "레이크하우스" 개념을 정식화했다. 원시 데이터를 모두 데이터 레이크에 두되, Delta Lake 같은 트랜잭션 레이어를 얹어 DW의 신뢰성을 제공하자는 아이디어였다. 아이스버그, 후디 같은 오픈 테이블 포맷이 표준 후보로 경쟁 중이며, 2023년 스노우플레이크의 아이스버그 지원, 2024년 데이터브릭스의 타뷸러 인수는 이 영역이 향후 5년의 핵심 격전지가 될 것임을 시사한다.

6.3 운영 DB의 클라우드화

OLTP 영역도 클라우드 네이티브로 빠르게 이동 중이다. AWS 오로라(2014)는 MySQL/PostgreSQL 호환 위에 분리형 저장 엔진을 결합해 표준 RDS 대비 최대 5배의 처리량을 제시했고, 구글 알로이DB(2022), 마이크로소프트 하이퍼스케일도 비슷한 접근을 취한다. 사용자는 익숙한 SQL 인터페이스를 유지하면서 클라우드의 탄력성을 얻는다.

7. AI 시대의 데이터베이스: 벡터와 멀티모달

7.1 벡터 DB의 부상

2022년 챗GPT의 등장은 데이터베이스 산업에 새로운 카테고리를 만들어냈다. 거대언어모델은 검색 단계에서 키워드가 아닌 의미를 비교하기 위해 텍스트·이미지·코드를 고차원 벡터로 임베딩한 뒤, 코사인 유사도나 내적으로 가장 가까운 이웃을 찾는다. 이 작업을 효율적으로 수행하는 시스템이 벡터 데이터베이스다.

대표 주자는 파인콘, 위비에이트, 밀버스, 크로마이며, 기존 RDBMS도 빠르게 흡수 중이다. 2021년 등장한 PostgreSQL 확장 pgvector는 2024년 기준 깃허브 스타 1만 개를 돌파했고, MongoDB Atlas, Elasticsearch, Redis도 모두 벡터 검색을 기본 기능으로 통합했다. 가트너는 2026년까지 글로벌 기업의 30% 이상이 자체 벡터 인프라를 운영할 것이라고 전망한다.

7.2 RAG 아키텍처와 데이터 레이어

벡터 DB가 단독 제품으로 의미를 갖는 이유는 RAG(Retrieval-Augmented Generation) 아키텍처 때문이다. 거대언어모델이 모든 지식을 파라미터에 담을 수는 없으므로, 외부 지식을 벡터 검색으로 가져와 프롬프트에 끼워 넣는 패턴이 표준이 되었다. 이 흐름에서 데이터베이스의 역할은 단순 저장소가 아니라 "모델의 작업 기억"으로 진화한다.

"AI 모델이 더 똑똑해질수록, 그 모델에 무엇을 보여줄지 결정하는 검색 인프라가 더 중요해진다." — 2024년 a16z 인프라 리포트

7.3 시대별 주요 사건 연표

연도	사건	의의
1956	IBM RAMAC 305	임의 접근 시대 개막
1968	IBM IMS	계층형 DBMS 상용화
1970	코드의 관계형 모델 논문	관계형 패러다임 탄생
1979	Oracle V2	최초 상용 SQL DBMS
1992	오라클 7 MVCC	동시성 제어 혁신
2006	구글 Bigtable 논문	웹 규모 분산 DB의 청사진
2009	MongoDB, Cassandra 출시	NoSQL 대중화
2012	구글 스패너	NewSQL 등장
2014	AWS 오로라	클라우드 네이티브 OLTP
2022	챗GPT 공개	벡터 DB 폭발적 성장

8. 데이터베이스가 향하는 곳

8.1 멀티모달과 통합 엔진

2025년 이후 데이터베이스 시장의 키워드는 "통합"이다. 한 엔진에서 정형 데이터(SQL), 반정형 데이터(JSON), 시계열, 그래프, 벡터까지 모두 다루는 멀티모달 DB가 빠르게 늘고 있다. PostgreSQL은 이미 사실상 멀티모달 엔진이며, MongoDB도 시계열·검색·벡터를 흡수했다.

이 흐름의 끝에는 "데이터를 분산시키지 않는 것"이라는 비전이 있다. ETL로 데이터를 5개 시스템에 복제하는 대신, 데이터가 한 곳에 있고 다양한 워크로드가 그 위에서 안전하게 공존하는 모델이다.

8.2 AI 네이티브 옵티마이저

최근 학계에서는 머신러닝 기반 쿼리 옵티마이저, 학습형 인덱스, 자율 튜닝이 활발히 연구된다. 2018년 MIT의 팀 크라스카가 발표한 "The Case for Learned Index Structures" 논문은 B-트리를 신경망으로 대체할 수 있다는 가능성을 보여줬다. 오라클 자율 DB, AWS RDS의 자동 튜닝은 이 흐름의 상용 사례다.

흥미로운 점은 옵티마이저뿐만 아니라 스토리지 엔진 자체가 워크로드 패턴을 학습해 데이터 배치와 압축 방식을 스스로 조정하는 방향으로 진화하고 있다는 것이다. 1970년 코드가 약속한 "물리적 독립성"이 50년 만에 새로운 차원에서 실현되는 셈이다.

8.3 오픈소스의 지속적인 우위

마지막으로 짚을 흐름은 오픈소스의 부동의 강세다. DB-Engines 2024년 순위에서 PostgreSQL은 사상 처음으로 종합 1위에 가까이 올라섰고, MySQL, MongoDB, Redis 등 상위 10위 안에 오픈소스 제품이 절반 이상이다. 클라우드 벤더는 이들을 매니지드 서비스로 감싸 판매하지만, 핵심 엔진 자체는 점점 더 오픈된다.

이는 데이터베이스가 산업의 핵심 인프라가 될수록, 단일 벤더에 종속되지 않으려는 압력이 강해지기 때문이다. 60년 전 천공카드를 직접 들고 다니던 시대에는 상상할 수 없던 분권의 시대가 데이터의 세계에서도 자리 잡고 있다.

9. 결론: 60년의 누적 위에 다음 한 줄을 쓰다

데이터베이스의 역사는 한 패러다임이 다른 패러다임을 무너뜨리며 진행된 혁명의 연속이 아니라, 새로운 요구가 등장할 때마다 한 층씩 누적된 지층에 가깝다. 계층형은 트리 구조 데이터에 여전히 강하고, 관계형은 정형 데이터의 표준이며, NoSQL은 스케일이 필요할 때, 벡터 DB는 의미 검색이 필요할 때 등장한다. 결국 데이터베이스를 잘 다룬다는 것은 어떤 한 기술을 외운다기보다, 60년의 트레이드오프 지도를 읽고 자신의 문제에 가장 맞는 도구를 고르는 일이다. 오늘 우리가 쓰는 SQL 한 줄 뒤에는 천공카드와 RAMAC, IMS와 오라클, 카산드라와 스패너, 그리고 챗GPT의 임베딩 인덱스까지가 모두 연결되어 있다. 다음 한 줄은 우리가 어떤 데이터를 어떻게 의미 있게 다루느냐에 따라 달라질 것이다.