1890년 미국 통계국 서기들은 인구조사 표를 제때 끝내지 못해 애를 먹었습니다. 허먼 홀러리스가 펀치 카드 기계를 들고 와 “구멍으로 답을 세어 보죠”라고 제안하면서
데이터가 처음 전기 장비를 타고 흘렀습니다. 몇십 년 뒤에는 은행 창구 직원과 로켓 조립 관리자도 “기록 좀 빨리 찾게 해 주세요”라며 자기 디스크와 계층형 모델을
시험했습니다.
1970년대 E.F. Codd와 Peter Chen은 데이터를 표와 그림으로 설명하는 법을 정리했고, Oracle 같은 팀이 “현장에서도 통한다”는 걸 보여 줬습니다.
1990년대 MySQL과 PostgreSQL은 오픈소스 선택지를 넓혔고, 2000년대 Dynamo와 MongoDB는 분산 웹 서비스를 위해 새로운 저장 방식을 탐색했습니다.
연도 버튼을 누르면 각 세대가 어떤 문제를 풀고 싶었는지, 그 해법이 오늘날 서비스에 어떻게 이어졌는지 차근차근 만나 볼 수 있습니다. 낯선 용어가 나와도 괜찮아요. 사람과
상황 중심으로 쉽게 풀어 드릴게요.
연도 버튼을 누르면 새 창 없이 팝업 대화 상자가
열리고, 그 자리에서 자세한 이야기를 이어서 읽을 수 있습니다.
1890s
인구조사와 펀치 카드 실험
통계국 서기와 엔지니어가 종이 표 대신 펀치 카드와 전기 집계기를 들여와 반복 계산을 기계에 맡겼습니다.
1950s
자기 디스크와 실시간 업데이트
은행과 보험사 팀은 테이프를 갈아 끼우는 시간 대신, 회전하는 디스크로 “필요할 때 바로 고치자”는 새 흐름을
열었습니다.
1960s
로켓과 은행이 그린 계층 지도
아폴로 부품과 항공 예약처럼 복잡한 정보를 다루던 팀은 데이터를 층층이 쌓거나 링크로 묶는 모델을
실험했습니다.
1970s
관계형 사고와 그림 언어
연구자와 설계자는 “조건만 말하면 원하는 표를 보자”는 목표로 SQL과 ER 다이어그램을 정착시켰습니다.
1980s
표준화와 병렬 엔진의 확장
대형 은행과 제조사가 관계형 DB를 기본 도구로 삼자 SQL 표준과 대규모 병렬 엔진이 빠르게 보급됐습니다.
1990s
오픈소스와 데이터 웨어하우스
웹 서비스와 전자상거래 팀이 가볍고 무료인 DB를 고르고, 경영진은 분석을 위한 별도 창고를 세웠습니다.
2000s
웹 규모와 NoSQL 실험
인터넷 기업은 수천 대 서버에 로그를 나눠 저장하고 문서형·키값 저장소를 시험하며 유연성을 확보했습니다.
2010s
전 세계 일관성과 스트리밍 파이프라인
다국적 서비스는 지구 반대편에서도 같은 데이터를 보려 했고, 이벤트 스트림을 흘려보내며 실시간 분석을
준비했습니다.
2020s
레이크하우스와 벡터 검색 도입
데이터 레이크와 웨어하우스를 잇는 설계가 확산되고, 생성형 AI를 돕는 벡터 데이터베이스가 업무에 들어오기
시작했습니다.
참고 자료
관계형 이론, 분산 DB 설계, 레이크하우스 전략을 소개한 대표 문헌을 모았습니다. 원문을 읽어 보면 당시 엔지니어가 어떤 제약을 풀려고 했는지 더 잘 느낄 수 있습니다.
통계국 서기는 “이번엔 제때 끝낼 수 있을까?”라며 걱정했지만, 허먼 홀러리스의 펀치 카드와 전기 집계기가 기다리던 답을
내놓았습니다.
1880년 미국 정부는 인구조사 결과를 집계하는 데 무려 7년이라는 시간을 썼습니다. 다음 조사가 다가오는데도 이전 결과가 나오지 않자, 통계청은 큰 고민에 빠졌습니다. 이때 허먼 홀러리스라는 발명가가 종이 카드와 전기 집계기를 들고 나타났습니다.
그는 종이 카드에 구멍을 뚫어 사람들의 정보를 기록하고, 기계가 이 구멍을 전기로 읽어 자동으로 숫자를 세도록 만들었습니다. 이 획기적인 발명 덕분에 1890년 인구조사는 단 2년 만에 끝날 수 있었습니다. 인류가 처음으로 방대한 데이터를 기계의 힘을 빌려 처리한 역사적인 순간이었습니다.
천공 카드(Punch Card)는 종이에 뚫린 구멍의 위치로 데이터를 저장하는 방식입니다. 오늘날 우리가 사용하는 엑셀의 행과 열처럼, 카드의 특정 위치가 나이, 성별 등의 정보를 의미했습니다. 기계가 전기를 이용해 이 구멍들을 빠르게 읽어내면서, 수작업으로 하던 계산을 자동화할 수 있었습니다.
1956
IBM 305 RAMAC · 자기 디스크 도입
샌프란시스코 은행 창구 직원은 회전하는 디스크가 계좌 기록을 즉시 불러오는 모습을 보고 “이제 줄을 줄일 수 있겠다”고
안도했습니다.
1950년대 은행 창구는 고객들의 계좌 정보를 확인하고 갱신하느라 항상 붐볐습니다. 당시에는 데이터를 테이프에 저장했기 때문에, 원하는 정보를 찾으려면 테이프를 처음부터 끝까지 감아야만 했습니다. 이때 IBM이 'RAMAC'이라는 새로운 기계를 선보였습니다.
RAMAC은 회전하는 원판(디스크)에 데이터를 저장했습니다. 직원이 고객 번호를 입력하면, 기계 팔이 디스크 위를 빠르게 움직여 필요한 정보만 즉시 찾아냈습니다. 테이프를 감을 필요 없이 원하는 데이터를 바로 읽고 쓸 수 있게 되면서, 기업들은 비로소 '실시간 데이터 처리'라는 개념을 도입할 수 있었습니다.
RAMAC은 현대 하드 디스크의 조상 격인 장치입니다. 카세트테이프처럼 순서대로 들어야 하는 방식(순차 접근)에서 벗어나, LP 레코드판의 바늘을 원하는 노래 위치에 바로 올려놓듯 데이터를 찾는 방식(임의 접근)을 최초로 상용화했습니다. 이 기술 덕분에 데이터베이스는 필요한 정보를 즉각적으로 검색하고 수정할 수 있게 되었습니다.
1959
CODASYL DB 위원회
보험사와 제조사 대표들은 “파일 구조가 다르면 서로 못 알아들어요”라며 모여, 레코드와 링크를 표준화하는 규칙을 정했습니다.
컴퓨터가 보급되면서 기업들은 각자의 방식으로 데이터를 저장하기 시작했습니다. 하지만 회사마다 데이터를 정리하는 규칙이 달라, 서로의 시스템을 연결하거나 호환하기가 매우 어려웠습니다. 이를 해결하기 위해 정부와 기업의 전문가들이 한자리에 모였습니다.
이들은 'CODASYL'이라는 위원회를 만들고, 데이터를 어떻게 연결하고 저장할지에 대한 공통된 규칙을 논의했습니다. 여기서 만들어진 표준안은 이후 데이터베이스 시스템들이 데이터를 체계적으로 구조화하고 관리하는 데 중요한 밑거름이 되었습니다.
CODASYL 위원회는 데이터 간의 관계를 '포인터(Pointer)'라는 연결 고리로 묶는 방식을 제안했습니다. 이는 마치 문서에 하이퍼링크를 달아 다른 문서로 이동할 수 있게 만든 것과 비슷합니다. 비록 데이터를 찾기 위해 복잡한 경로를 직접 따라가야 하는 단점이 있었지만, 데이터를 구조적으로 연결하려는 최초의 의미 있는 시도였습니다.
1966
IMS · 아폴로 부품을 추적하다
아폴로 부품을 관리하던 팀은 IMS 덕분에 “어떤 공정에서 어떤 부품이 필요한지”를 계층 구조로 바로 확인했습니다.
1960년대, 인류를 달에 보내기 위한 아폴로 프로젝트에는 수백만 개의 부품이 필요했습니다. 부품 하나라도 누락되면 전체 일정이 흔들릴 수 있는 상황에서, 수많은 부품의 재고와 조립 단계를 정확히 관리할 시스템이 절실했습니다.
이를 위해 IBM은 'IMS'라는 데이터 관리 시스템을 개발했습니다. IMS는 로켓이라는 큰 범주 아래에 엔진, 그 아래에 밸브와 볼트가 있는 식으로 데이터를 조직도처럼 계층화하여 저장했습니다. 이 시스템 덕분에 엔지니어들은 필요한 부품의 위치와 수량을 즉시 파악할 수 있었고, 이후 이 기술은 은행과 항공사의 대규모 데이터 관리에도 널리 쓰이게 되었습니다.
IMS는 데이터를 나무의 뿌리에서 가지로 뻗어나가는 형태(계층형 모델)로 정리했습니다. '회사-부서-직원'처럼 상하 관계가 명확한 데이터를 위에서 아래로 검색할 때는 매우 빠르고 효율적입니다. 하지만 반대로 특정 직원이 어느 부서에 속해 있는지 아래에서 위로 검색하거나, 복잡하게 얽힌 관계를 표현하기에는 구조적인 한계가 있었습니다.
1969
IDS 네트워크 모델
항공기 제조사 설계자는 같은 부품이 여러 제품에 쓰일 때를 표현하려고, 링크로 얽힌 IDS 네트워크 모델을 받아들였습니다.
기존의 계층형 시스템은 상하 관계가 뚜렷한 데이터에는 적합했지만, 현실의 데이터는 훨씬 복잡하게 얽혀 있었습니다. 예를 들어, 하나의 나사가 자동차 엔진에도 쓰이고 문짝에도 쓰이는 것처럼 다대다(多對多) 관계를 표현하기가 어려웠습니다.
컴퓨터 과학자 찰스 바크만은 이 문제를 해결하기 위해 'IDS'라는 새로운 시스템을 고안했습니다. 데이터를 그물망처럼 자유롭게 연결할 수 있게 만든 것입니다. 덕분에 특정 부품이 어떤 제품들에 사용되는지 양방향으로 쉽게 추적할 수 있게 되었고, 데이터베이스는 현실 세계의 복잡한 관계를 한층 더 정교하게 반영할 수 있게 되었습니다.
IDS가 도입한 '네트워크형 모델'은 데이터 간의 관계를 그물망처럼 다중으로 연결할 수 있게 해 주었습니다. 데이터의 유연성은 크게 높아졌지만, 원하는 정보를 찾으려면 개발자가 이 복잡한 그물망의 경로를 직접 코드로 작성해야만 했습니다. 이러한 복잡성은 훗날 더 직관적이고 사용하기 쉬운 데이터베이스 모델이 등장하는 계기가 되었습니다.
1970
관계형 모델 논문
E.F. Codd는 “데이터를 표로, 포인터 대신 수학으로 다루자”고 제안하며 선언형 SQL 사고를 열었습니다.
당시의 데이터베이스는 데이터를 찾기 위해 컴퓨터 내부의 저장 위치나 연결 경로를 개발자가 일일이 지정해 주어야 했습니다. IBM의 연구원 에드거 커드(E.F. Codd)는 이런 복잡한 방식에 한계를 느끼고, 수학적 이론을 바탕으로 한 혁신적인 논문을 발표했습니다.
그는 데이터를 우리가 흔히 아는 '표(Table)' 형태로 정리하고, 사용자는 "어떤 데이터가 필요한지" 조건만 입력하면 시스템이 알아서 찾아주는 방식을 제안했습니다. 이 '관계형 모델'의 등장으로 개발자들은 복잡한 경로 탐색에서 해방되었고, 데이터베이스는 현대적인 모습을 갖추기 시작했습니다.
관계형 모델(Relational Model)은 데이터를 행(Row)과 열(Column)로 이루어진 2차원 표 형태로 관리합니다. 사용자가 SQL이라는 표준 언어를 통해 "30대 이상인 고객 명단을 보여줘"라고 요청하면, 데이터베이스 엔진이 최적의 검색 방법을 스스로 찾아 결과를 반환합니다. 오늘날 우리가 사용하는 대부분의 데이터베이스 시스템이 이 이론을 바탕으로 작동하고 있습니다.
1976
Peter Chen의 ER 모델
Peter Chen은 “업무를 그림으로 설명하게 도와 줄게요”라며 개체와 관계를 나란히 보여 주는 ER 다이어그램을
발표했습니다.
데이터베이스가 복잡해지면서, 개발자와 비즈니스 담당자가 시스템의 구조를 놓고 소통하는 데 어려움을 겪기 시작했습니다. 이때 피터 첸(Peter Chen)이라는 학자가 데이터를 시각적으로 표현하는 'ER 모델(Entity-Relationship Model)'을 발표했습니다.
그는 고객, 상품 같은 핵심 대상(개체)과 이들 사이의 상호작용(관계)을 도형과 선으로 그리는 방법을 제안했습니다. 이 직관적인 다이어그램 덕분에 기술 전문가가 아닌 사람도 데이터의 구조를 쉽게 이해할 수 있게 되었고, 시스템을 구축하기 전 설계도를 그리는 과정이 업계의 표준으로 자리 잡았습니다.
ER 다이어그램은 건축물의 설계도와 같은 역할을 합니다. 사각형으로 데이터의 주체(예: 고객, 주문)를 그리고, 마름모와 선을 이용해 이들이 어떻게 연결되는지(예: 고객이 주문을 한다)를 시각화합니다. 이를 통해 실제 데이터베이스를 구축하기 전에 논리적인 오류나 누락된 부분을 미리 발견하고 수정할 수 있습니다.
1979
Oracle V2 · 상용 SQL 데이터베이스
Oracle은 “연구실 말고 현장에서도 관계형 DB를 쓰자”며 SQL 제품을 출시해 실용성을 증명했습니다.
에드거 커드가 제안한 관계형 모델은 이론적으로는 완벽했지만, 당시 컴퓨터 성능으로는 실제 비즈니스 환경에서 빠르게 작동하게 만들기가 매우 어려웠습니다. 많은 기업이 주저하고 있을 때, 래리 엘리슨이 이끄는 작은 소프트웨어 회사가 최초의 상용 관계형 데이터베이스인 'Oracle V2'를 출시했습니다.
이들은 복잡한 코딩 없이 영단어 몇 개만으로 데이터를 다룰 수 있는 SQL 언어를 제품에 성공적으로 구현했습니다. 초기에는 성능의 한계가 있었지만, 지속적인 개선을 통해 관계형 데이터베이스가 실제 기업 환경에서도 충분히 강력하고 유용하다는 것을 증명해 냈습니다.
Oracle의 성공은 학술적 이론에 머물러 있던 관계형 데이터베이스를 산업의 표준으로 끌어올린 결정적 계기가 되었습니다. 특히 시스템에 장애가 발생하더라도 데이터의 일관성과 안전성을 보장하는 기술을 고도화함으로써, 금융권이나 대기업의 핵심 시스템에서도 관계형 데이터베이스를 믿고 사용할 수 있는 환경을 조성했습니다.
1981
IBM DB2 베타
IBM은 메인프레임 고객에게 DB2를 소개하며 “대형 업무도 표 기반으로 전환할 수 있다”는 확신을 심어 줬습니다.
관계형 데이터베이스의 이론을 처음 만들었던 IBM도 마침내 자사의 대형 컴퓨터(메인프레임)를 위한 상용 제품인 'DB2'를 선보였습니다. 당시 대기업들은 방대한 양의 데이터를 기존의 낡은 방식으로 관리하며 성능 문제로 골머리를 앓고 있었습니다.
DB2는 사용자가 데이터를 요청하면, 시스템 내부에서 가장 빠르고 효율적인 검색 경로를 스스로 찾아내는 지능적인 기술을 탑재했습니다. 이 기술 덕분에 대규모 데이터를 다루는 은행과 보험사들도 안심하고 관계형 데이터베이스로 시스템을 전환하기 시작하며, 데이터 관리의 새로운 시대가 열렸습니다.
DB2에 적용된 핵심 기술 중 하나는 '옵티마이저(Optimizer)'입니다. 이는 자동차의 내비게이션과 같습니다. 사용자가 목적지(원하는 데이터)를 입력하면, 옵티마이저가 현재 데이터의 분포와 시스템 상태를 분석하여 가장 빠르고 효율적인 경로를 계산해 냅니다. 이 기술은 관계형 데이터베이스의 성능을 비약적으로 끌어올렸습니다.
1986
ANSI SQL-86
ANSI 승인을 받은 SQL-86 덕분에 개발자들은 제품을 바꿔도 익숙한 문법을 유지할 수 있다고 안심했습니다.
관계형 데이터베이스 시장이 커지면서 여러 기업이 각자의 제품을 내놓았습니다. 하지만 회사마다 데이터를 다루는 명령어(SQL)가 조금씩 달라, 사용자들이 큰 불편을 겪었습니다. 특정 회사의 제품을 쓰다가 다른 회사 제품으로 바꾸려면 시스템을 처음부터 다시 만들어야 했기 때문입니다.
이에 미국 국가표준협회(ANSI)는 업계 전문가들을 모아 SQL의 공통 문법을 제정했습니다. 이 'SQL-86' 표준 덕분에 개발자들은 하나의 언어만 배우면 어떤 데이터베이스든 다룰 수 있게 되었고, 기업들은 특정 소프트웨어에 종속되지 않고 자유롭게 시스템을 선택할 수 있게 되었습니다.
SQL(Structured Query Language) 표준화는 IT 역사에서 매우 중요한 이정표입니다. 전 세계 어디서나 영어를 공용어로 사용하듯, 데이터베이스 세계에서는 SQL이 공용어가 되었습니다. 이 표준 덕분에 데이터베이스 관련 교육, 도구, 생태계가 폭발적으로 성장할 수 있는 기반이 마련되었습니다.
1988
Teradata DBC/1012
Teradata의 DBC/1012는 수십 대 노드를 나란히 돌려 “이만한 데이터도 나눠서 계산할 수 있다”는 자신감을 줬습니다.
대형 마트나 통신사처럼 매일 엄청난 양의 데이터가 쌓이는 기업들은 기존의 단일 컴퓨터로는 데이터를 분석하는 데 며칠씩 걸리는 한계에 부딪혔습니다. 이때 테라데이타(Teradata)라는 회사가 여러 대의 컴퓨터를 연결해 하나의 거대한 시스템처럼 작동하게 만드는 기술을 선보였습니다.
이 시스템은 방대한 데이터를 여러 컴퓨터에 잘게 나누어 저장하고, 분석 요청이 들어오면 모든 컴퓨터가 동시에 계산을 수행한 뒤 결과를 하나로 합쳐주었습니다. 이 '병렬 처리' 기술 덕분에 수십억 건의 데이터 분석도 단 몇 시간 만에 끝낼 수 있게 되었고, 기업들은 데이터를 활용해 더 빠르고 정확한 의사결정을 내릴 수 있게 되었습니다.
테라데이타가 도입한 '대규모 병렬 처리(MPP, Massively Parallel Processing)' 아키텍처는 현대 빅데이터 분석의 근간이 되었습니다. 하나의 초고성능 컴퓨터를 만드는 대신, 적당한 성능의 컴퓨터 여러 대를 연결해 작업 부하를 분산시키는 이 방식은 데이터가 늘어나면 컴퓨터를 추가하기만 하면 되는 뛰어난 확장성을 제공합니다.
1995
MySQL 공개
웹 개발자들은 “가볍고 공짜면 좋겠어”라고 말했고, MySQL이 LAMP 스택의 기본 선택이 되었습니다.
1990년대 중반, 인터넷이 대중화되면서 누구나 웹사이트를 만들고자 했습니다. 하지만 상용 데이터베이스 소프트웨어는 개인이나 작은 스타트업이 구매하기에는 너무 비쌌습니다. 이때 스웨덴의 개발자들이 누구나 무료로 사용할 수 있는 'MySQL'을 세상에 공개했습니다.
MySQL은 설치가 매우 간단했고, 웹 개발 언어들과 뛰어난 호환성을 자랑했습니다. 비용 부담 없이 빠르고 가볍게 작동하는 데이터베이스의 등장에 전 세계 개발자들이 열광했습니다. 오늘날 우리가 아는 수많은 블로그, 게시판, 초기 인터넷 서비스들이 바로 이 MySQL을 기반으로 탄생할 수 있었습니다.
MySQL은 소스 코드가 공개되어 누구나 자유롭게 사용하고 수정할 수 있는 '오픈소스' 소프트웨어입니다. 초기에는 복잡한 기능보다는 웹사이트에서 데이터를 빠르게 읽어오는 데 집중하여 인터넷의 폭발적인 성장을 뒷받침했습니다. 이후 전 세계 개발자들의 기여로 기능이 점차 고도화되며 기업용으로도 손색없는 시스템으로 발전했습니다.
1996
PostgreSQL 6 프리뷰
버클리 POSTGRES 연구는 커뮤니티와 합쳐져 PostgreSQL이 확장 가능한 오픈소스 데이터베이스로 자리 잡게 했습니다.
대학 연구실에서 시작된 데이터베이스 프로젝트가 전 세계 개발자들의 손을 거쳐 'PostgreSQL'이라는 이름으로 새롭게 태어났습니다. 이 시스템의 가장 큰 특징은 사용자가 자신의 필요에 맞게 데이터베이스의 기능을 자유롭게 뜯어고치고 확장할 수 있다는 점이었습니다.
예를 들어, 지도 서비스를 만드는 회사는 위치 정보를 계산하는 기능을 추가하고, 검색 엔진을 만드는 회사는 텍스트 분석 기능을 덧붙일 수 있었습니다. 이처럼 필요한 모듈을 블록처럼 조립하여 유연하게 확장할 수 있는 구조 덕분에, 복잡하고 특수한 데이터를 다루는 전문가와 기업들에게 큰 사랑을 받게 되었습니다.
PostgreSQL은 상용 데이터베이스에 버금가는 강력한 기능과 안정성을 자랑하는 오픈소스 시스템입니다. 특히 수많은 사용자가 동시에 데이터를 읽고 쓸 때 데이터가 엉키지 않도록 정교하게 제어하는 기술이 탁월합니다. 또한, 표준 SQL을 가장 엄격하게 준수하면서도 최신 기술 트렌드를 빠르게 수용하는 것으로 유명합니다.
1998
데이터 웨어하우스 참고 모델
랄프 킴벌과 빌 인몬은 “운영 데이터와 보고 데이터는 다르게 다뤄야 한다”며 데이터 웨어하우스 설계를 정리했습니다.
기업들은 고객의 주문을 처리하는 시스템에서 곧바로 매출 통계를 내려고 시도했습니다. 하지만 복잡한 통계 계산을 시작하면 시스템 전체가 느려져, 정작 중요한 고객의 결제가 지연되는 문제가 발생했습니다. 이를 해결하기 위해 '데이터 웨어하우스(Data Warehouse)'라는 개념이 정립되었습니다.
전문가들은 일상적인 업무를 처리하는 시스템과 데이터를 분석하는 시스템을 완전히 분리할 것을 제안했습니다. 업무 시스템에 쌓인 데이터를 주기적으로 복사해 '분석 전용 창고'에 보기 좋게 정리해 두는 방식입니다. 이 설계 덕분에 기업들은 서비스 속도 저하 없이 방대한 데이터를 마음껏 분석하여 비즈니스 전략을 세울 수 있게 되었습니다.
데이터 웨어하우스를 구축하기 위해서는 원본 데이터를 추출(Extract)하고, 분석하기 좋은 형태로 변환(Transform)하여, 창고에 적재(Load)하는 'ETL' 과정이 필수적입니다. 이렇게 잘 정제된 데이터 창고가 마련되면서, 경영진이 데이터를 시각화된 대시보드로 확인하고 의사결정을 내리는 비즈니스 인텔리전스(BI) 시대가 본격적으로 열렸습니다.
2004
Google MapReduce 논문
Google 엔지니어는 수천 대 서버에 흩어진 로그를 “나눠 계산하고 다시 합치자”며 MapReduce 모델을 선보였습니다.
구글은 전 세계의 웹페이지를 수집하고 검색 결과를 만들어내기 위해 상상할 수 없을 만큼 거대한 데이터를 다뤄야 했습니다. 기존의 데이터베이스 기술로는 이 엄청난 양을 감당할 수 없자, 구글의 엔지니어들은 '맵리듀스(MapReduce)'라는 새로운 데이터 처리 방식을 고안해 논문으로 발표했습니다.
이 방식은 거대한 작업을 수천 대의 평범한 컴퓨터에 잘게 쪼개어 동시에 처리하게 한 뒤, 그 결과를 하나로 모으는 혁신적인 기술이었습니다. 중간에 컴퓨터 몇 대가 고장 나도 시스템이 알아서 다른 컴퓨터에 작업을 넘겨주어 멈추지 않고 돌아갔습니다. 이 논문은 훗날 '빅데이터' 시대를 여는 결정적인 방아쇠가 되었습니다.
맵리듀스는 이름 그대로 데이터를 나누어 처리하는 '맵(Map)' 단계와, 그 결과를 요약하고 합치는 '리듀스(Reduce)' 단계로 이루어집니다. 구글의 이 논문을 바탕으로 '하둡(Hadoop)'이라는 오픈소스 소프트웨어가 탄생했고, 전 세계 수많은 기업이 값비싼 슈퍼컴퓨터 없이도 빅데이터를 분석할 수 있는 길을 열어주었습니다.
2006
Amazon Dynamo 설계
Amazon은 “쇼핑 카트는 절대 사라지면 안 돼”라며 가용성과 일관성 균형을 설명한 Dynamo 설계를 공유했습니다.
세계 최대의 온라인 쇼핑몰 아마존은 연말 할인 행사 때마다 몰려드는 접속자 때문에 서버가 다운될까 봐 노심초사했습니다. 특히 고객이 장바구니에 담은 물건이 시스템 오류로 사라지는 것은 치명적이었습니다. 아마존은 어떤 상황에서도 장바구니가 멈추지 않도록 '다이나모(Dynamo)'라는 새로운 데이터 저장 방식을 설계했습니다.
이들은 완벽한 정확성을 조금 양보하더라도, 시스템이 절대 멈추지 않고 항상 응답하도록 만드는 데 집중했습니다. 데이터를 여러 서버에 중복으로 저장해, 한 서버가 고장 나도 다른 서버가 즉시 역할을 대신하도록 한 것입니다. 이 설계 철학은 이후 유연하고 확장성 높은 'NoSQL' 데이터베이스들이 탄생하는 데 큰 영감을 주었습니다.
전통적인 데이터베이스는 모든 데이터가 한 치의 오차도 없이 정확하게 일치하는 것(일관성)을 최우선으로 삼았습니다. 하지만 다이나모는 대규모 인터넷 서비스에서는 시스템이 멈추지 않고 항상 작동하는 것(가용성)이 더 중요할 수 있다는 발상의 전환을 보여주었습니다. 이는 데이터의 성격에 따라 알맞은 저장 방식을 선택해야 한다는 현대적인 아키텍처의 기반이 되었습니다.
2009
MongoDB 1.0
스타트업 개발자들은 매일 바뀌는 필드를 감당하려고, 스키마를 느슨하게 다루는 MongoDB 문서 저장소를 도입했습니다.
스마트폰 시대가 열리면서 앱 서비스들은 하루가 다르게 새로운 기능을 추가하고 변경해야 했습니다. 하지만 기존의 관계형 데이터베이스는 엑셀 표처럼 미리 정해진 틀(스키마)에 맞춰 데이터를 넣어야 했기 때문에, 구조를 바꾸려면 번거로운 작업이 필요했습니다.
이러한 불편함을 해소하기 위해 '몽고DB(MongoDB)'가 등장했습니다. 몽고DB는 정해진 표 대신, 유연한 '문서(Document)' 형태로 데이터를 저장했습니다. 사용자마다 저장하는 정보의 종류나 개수가 달라도 아무 문제 없이 그대로 저장할 수 있었습니다. 이처럼 개발 속도를 획기적으로 높여주는 유연성 덕분에 몽고DB는 스타트업과 최신 웹 개발 생태계에서 폭발적인 인기를 끌었습니다.
몽고DB는 대표적인 'NoSQL(Not Only SQL)' 데이터베이스입니다. 데이터를 표 형태가 아닌, 웹 개발에서 널리 쓰이는 JSON과 유사한 형태로 저장합니다. 구조를 미리 엄격하게 정의할 필요가 없어, 요구사항이 빠르게 변하는 현대의 애자일(Agile) 소프트웨어 개발 방식에 매우 적합합니다.
2012
Spanner · 글로벌 일관성
Google은 세계 곳곳 데이터센터에서 같은 트랜잭션이 실행되도록, 원자 시계와 정밀한 시간 동기화를 갖춘 Spanner를
구축했습니다.
구글처럼 전 세계를 무대로 서비스하는 기업은 데이터센터가 여러 대륙에 흩어져 있습니다. 만약 한국과 미국에서 동시에 같은 계좌의 돈을 출금하려 한다면, 물리적인 거리 때문에 서버 간의 시간 차이가 발생해 데이터가 꼬일 위험이 컸습니다.
구글은 이 문제를 해결하기 위해 '스패너(Spanner)'라는 놀라운 데이터베이스를 개발했습니다. 이들은 각 데이터센터에 GPS와 원자시계를 설치하여, 전 세계 서버의 시간을 1,000분의 1초 단위까지 완벽하게 동기화했습니다. 덕분에 지구 반대편에 있는 서버들도 마치 한 방에 있는 컴퓨터처럼 오차 없이 정확하게 데이터를 주고받을 수 있게 되었습니다.
스패너는 기존 데이터베이스의 한계를 뛰어넘은 '뉴SQL(NewSQL)'의 대표적인 사례입니다. NoSQL처럼 전 세계로 무한히 확장할 수 있는 능력을 갖추면서도, 전통적인 관계형 데이터베이스처럼 금융 거래에 필수적인 완벽한 데이터 정확성(ACID)을 동시에 보장하는 혁신적인 기술적 성취를 이루어냈습니다.
2014
Apache Kafka 0.8
LinkedIn 엔지니어는 “이벤트를 한 번 쓰고 여러 팀이 나눠 듣게 하자”며 Kafka 스트리밍 플랫폼을 오픈소스로
공개했습니다.
링크드인(LinkedIn) 같은 대형 소셜 미디어에서는 사용자의 클릭, 메시지 전송 등 1초에도 수백만 건의 데이터가 쏟아집니다. 이 엄청난 데이터를 여러 부서의 시스템이 동시에 가져다 쓰려다 보니, 시스템들이 복잡하게 얽혀 자주 고장이 났습니다.
이를 해결하기 위해 링크드인 엔지니어들은 '카프카(Kafka)'라는 거대한 데이터 정거장을 만들었습니다. 모든 데이터는 일단 카프카로 모이고, 데이터를 필요로 하는 시스템들은 각자 원하는 속도로 카프카에서 데이터를 꺼내 가도록 설계했습니다. 이 방식은 데이터의 흐름을 깔끔하게 정리해 주었고, 오늘날 실시간 데이터 처리를 위한 업계의 핵심 표준이 되었습니다.
카프카는 데이터를 저장하는 전통적인 데이터베이스라기보다는, 끊임없이 발생하는 데이터를 실시간으로 전달하는 '스트리밍 플랫폼'입니다. 마치 우체국이 수많은 편지를 분류해 각 목적지로 안전하게 배달하듯, 시스템 간의 데이터 전송을 중개하여 전체 IT 인프라가 안정적이고 유연하게 작동하도록 돕습니다.
과거에는 데이터를 분석하려면 비싼 장비를 직접 사서 구축해야 했습니다. 데이터가 늘어나면 장비를 계속 추가해야 했고, 분석 작업이 몰릴 때는 시스템이 느려져 직원들이 하염없이 기다려야만 했습니다. '스노우플레이크(Snowflake)'는 클라우드 기술을 이용해 이 문제를 완전히 해결했습니다.
스노우플레이크는 데이터를 보관하는 '저장소'와 데이터를 분석하는 '컴퓨터 엔진'을 분리했습니다. 평소에는 저렴하게 데이터만 보관하다가, 복잡한 분석이 필요할 때만 클라우드에서 수백 대의 컴퓨터를 순간적으로 빌려 쓰고 쓴 만큼만 돈을 내는 방식을 도입한 것입니다. 이 혁신 덕분에 규모가 작은 기업들도 대기업 못지않은 강력한 데이터 분석 환경을 쉽게 누릴 수 있게 되었습니다.
스노우플레이크는 클라우드 환경에 맞춰 처음부터 새롭게 설계된 데이터 웨어하우스입니다. 여러 부서가 동시에 무거운 분석 작업을 실행해도, 각자 독립된 클라우드 컴퓨팅 자원을 할당받기 때문에 서로의 작업 속도에 전혀 영향을 주지 않습니다. 이는 데이터 분석의 효율성과 경제성을 극대화한 모델로 평가받습니다.
2020
레이크하우스 전략
Databricks와 커뮤니티는 “호수와 창고를 잇자”며 트랜잭션을 지원하는 레이크하우스 아키텍처를 제안했습니다.
기업들은 모든 종류의 원본 데이터를 저렴하게 쏟아부어 보관하는 '데이터 레이크(호수)'와, 정제된 데이터만 비싸게 관리하는 '데이터 웨어하우스(창고)'를 따로 운영하며 불편을 겪고 있었습니다. 두 시스템 간에 데이터를 옮기는 과정이 복잡하고 오류도 잦았기 때문입니다.
이에 데이터브릭스(Databricks)를 비롯한 기술 기업들은 두 시스템의 장점만 결합한 '레이크하우스(Lakehouse)'라는 새로운 개념을 제시했습니다. 저렴하고 방대한 호수 같은 저장소 위에, 창고처럼 데이터를 체계적이고 안전하게 관리하는 기능을 얹은 것입니다. 이제 기업들은 하나의 통합된 공간에서 인공지능 학습부터 정밀한 통계 분석까지 모든 작업을 효율적으로 처리할 수 있게 되었습니다.
레이크하우스 아키텍처는 사진, 영상, 로그 같은 비정형 데이터와 엑셀 표 같은 정형 데이터를 한곳에서 관리합니다. 과거에는 데이터 레이크에 저장된 데이터의 품질을 보장하기 어려웠지만, 레이크하우스는 데이터가 수정되거나 삭제될 때 오류가 발생하지 않도록 보호하는 기술을 적용하여 데이터의 신뢰성을 크게 높였습니다.
2023
벡터 데이터베이스 상용화
생성형 AI 팀은 답변 품질을 높이기 위해 의미 기반 검색을 돕는 벡터 데이터베이스를 실무에 들여놓기 시작했습니다.
챗GPT 같은 생성형 인공지능이 등장하면서, AI가 똑똑하게 대답하려면 방대한 지식을 빠르고 정확하게 찾아주는 새로운 형태의 데이터베이스가 필요해졌습니다. 기존의 검색 방식은 단어가 정확히 일치해야만 결과를 찾아주었기 때문에, 문맥이나 숨은 의미를 파악하는 데는 한계가 있었습니다.
이를 해결하기 위해 '벡터 데이터베이스(Vector Database)'가 본격적으로 도입되었습니다. 이 시스템은 텍스트, 이미지, 소리 등의 데이터를 인공지능이 이해할 수 있는 복잡한 숫자 좌표(벡터)로 변환하여 저장합니다. 덕분에 사용자가 모호하게 질문해도 문맥과 의도를 정확히 파악하여 가장 유사한 정보를 찾아 AI에게 전달할 수 있게 되었습니다.
벡터 데이터베이스는 데이터 간의 '의미적 거리'를 계산합니다. 예를 들어 '강아지'와 '고양이'는 좌표상에서 가깝게 배치되고, '자동차'는 멀리 떨어지게 됩니다. 이 기술은 AI가 환각 현상(거짓 정보를 지어내는 현상)을 줄이고, 기업의 내부 문서나 최신 정보를 바탕으로 정확한 답변을 생성하도록 돕는 핵심 인프라로 자리 잡고 있습니다.
