데이터 관리는 왜 파일에서 표로 옮겨갔는가
데이터 관리는 엑셀 같은 파일에서 시작했습니다. 고객 파일, 주문 파일, 직원 파일을 따로 만들다 보면 네 가지 문제가 쌓입니다. 같은 사람의 정보가 여러 파일에 중복되고, 파일마다 재고 숫자가 달라 어느 쪽이 맞는지 알 수 없고, 검색하려면 파일 전체를 훑어야 하고, 두 사람이 동시에 저장하면 한쪽의 수정이 사라집니다.
1970년 IBM의 수학자 에드거 코드가 해법을 내놨습니다. 데이터를 행과 열이 있는 표로 저장하고, 표끼리 조인으로 연결하고, 같은 정보는 한 곳에만 두는 정규화로 중복을 없애자는 겁니다. 이 관계형 모델과 SQL이 이후 50년을 지배했고, 1977년 오라클, 1995년 MySQL, 그리고 PostgreSQL이 이 토대 위에서 나왔습니다.
NoSQL과 클라우드 DB는 무엇을 맞바꿨는가
2000년대 중반 소셜 미디어가 등장하면서 서버 한 대를 더 좋은 장비로 바꾸는 수직 확장이 한계에 부딪혔습니다. 표를 여러 서버에 쪼개면 조인이 느려지기 때문에, 정확성 일부를 내주는 대신 속도와 수평 확장성을 얻은 NoSQL이 나왔습니다. 그래서 정확성이 생명인 은행은 지금도 관계형 DB를 쓰고, 소셜 미디어는 NoSQL을 씁니다.
2010년대에는 설치와 백업, 용량 관리를 클라우드가 대신하는 관리형 DB가 일반화됐습니다. DB가 직접 설치하는 것에서 전기처럼 꽂아 쓰는 것으로 바뀐 겁니다.
스토리지는 왜 서버에서 분리됐는가
파일 저장도 같은 길을 걸었습니다. 초기 웹 서비스는 서버의 업로드 폴더에 사용자 파일을 쌓았는데, 서버가 죽으면 파일이 함께 사라지고, 서버를 늘리면 어느 파일이 어디 있는지 꼬이고, 파일 전송만으로 트래픽이 막혔습니다. 2006년 아마존 S3가 파일 저장을 서버에서 떼어냈습니다. 파일을 올리면 여러 서버에 복제해 보관하고 접근용 URL 하나를 돌려주는 객체 스토리지 방식입니다. 여기에 CDN이 전 세계 엣지 서버에 파일을 미리 복사해 두면서 전달 속도 문제까지 해결됐습니다.
슈퍼베이스는 무엇을 하나로 묶었는가
2020년에 나온 슈퍼베이스는 이 두 흐름의 합류점입니다. 파이어베이스가 인증·DB·스토리지를 한 번에 주면서 인기를 얻었지만, NoSQL 기반이라 복잡한 관계 데이터와 정교한 쿼리에 약했습니다. 슈퍼베이스는 같은 편리함을 제대로 된 PostgreSQL 위에 얹었습니다. 테이블을 만들면 API가 자동 생성되고, 파일 접근 권한도 DB의 사용자 정보와 연동해 관리합니다. 서비스를 하나씩 따로 붙이던 시대에서, 필요한 것들이 처음부터 연결된 채로 나오는 시대로 바뀐 겁니다.
비개발자가 이 계보를 알면 무엇이 달라지는가
지시의 수준이 달라집니다. 이미지를 DB에 넣으면 느려지니 스토리지에 올리고 URL만 저장하라고 말할 수 있고, 정확성이 우선인 데이터와 속도가 우선인 데이터를 구분해 요구할 수 있습니다. SH Consulting이 비개발자 바이브 코딩 교육에서 도구 사용법보다 이 계보부터 짚는 이유가 여기에 있습니다.