AI의 슈퍼베이스 추천은 왜 우연이 아닌가
바이브 코딩을 하다 보면 AI가 자꾸 슈퍼베이스(Supabase)를 권합니다. 처음엔 단순한 유행이나 학습 데이터의 편향처럼 보이지만, 데이터베이스와 스토리지가 원래 전혀 다른 계보의 기술이었다는 사실을 떠올리면 이야기가 달라집니다. 왜 이 둘이 오늘날 한 도구 안에 묶여 나오는지를 알고 나면, 그 추천이 취향이 아니라 기술사의 필연에 가깝다는 게 보입니다.
그래서 이 글은 슈퍼베이스의 기능 목록을 나열하는 대신, 데이터베이스와 스토리지가 각각 어떤 문제에 부딪혀 어떻게 진화했는지, 그리고 그 두 흐름이 어디에서 만났는지를 따라갑니다. 이 지도가 머리에 있으면 어떤 도구를 왜 쓰는지, AI에게 무엇을 어떻게 지시해야 하는지가 함께 분명해집니다.
데이터베이스는 어떤 문제를 풀며 진화했는가
데이터 관리는 엑셀 같은 파일에서 시작했습니다. 편했지만 규모가 커지자 중복, 불일치, 검색 비효율, 그리고 여러 사람이 같은 파일을 동시에 고칠 때의 충돌이 쌓였습니다. 1970년 에드거 코드(Edgar Codd)는 데이터를 표(table)로 나눠 저장하자는 논문을 냈고, 이 관계형 모델이라는 아이디어는 이후 50년 가까이 데이터 관리를 지배했습니다.
하지만 서비스가 서버 한 대로 감당이 안 될 만큼 커지자 한계가 드러났습니다. 표의 엄격한 정확성 일부를 내주는 대신 여러 서버로 나눠 담는 확장성을 얻은 NoSQL이 등장했고, 데이터베이스를 직접 설치하고 관리하는 일 자체가 부담스러워지자 관리를 대신 맡아주는 클라우드 데이터베이스가 나왔습니다. 파일에서 표로, 표에서 분산으로, 다시 클라우드로 이어지는 이 흐름은 전부 "더 큰 규모를, 더 적은 관리 부담으로"라는 한 방향을 향합니다.
스토리지는 왜 서버에서 분리됐는가
이미지나 동영상 같은 파일을 저장하는 스토리지도 비슷한 길을 걸었습니다. 처음에는 애플리케이션이 도는 서버에 파일을 그냥 쌓았습니다. 문제는 그 서버가 죽으면 파일도 함께 사라진다는 것이었죠. 이 취약함을 겪고 나서야, 2006년 아마존 S3가 파일 저장을 애플리케이션 서버에서 아예 떼어내 별도의 전용 공간으로 분리했습니다.
파일이 서버에서 독립하자 이번엔 전 세계 사용자에게 어떻게 빠르게 전달하느냐가 과제가 됐고, 사용자와 가까운 곳에 파일 사본을 미리 깔아두는 CDN이 그 전달 속도까지 해결했습니다. 데이터베이스가 정확성과 확장성 사이에서 진화했다면, 스토리지는 안정성과 전달 속도를 차례로 풀며 서버에서 독립해 나온 셈입니다.
슈퍼베이스라는 합류점이 지시를 어떻게 바꾸는가
슈퍼베이스는 이 두 흐름이 만나는 합류점입니다. 파이어베이스(Firebase)의 손쉬운 사용성 위에 제대로 된 PostgreSQL 데이터베이스를 얹고, 사용자 인증과 파일 스토리지까지 하나의 플랫폼으로 묶었습니다. 예전에는 데이터베이스 따로, 스토리지 따로, 인증 따로 세팅하고 일일이 연결해야 했던 것들이, 이제는 처음부터 연결된 채로 나오는 시대가 된 겁니다. AI가 바이브 코딩에서 슈퍼베이스를 반복해 권하는 이유가 여기에 있습니다. 흩어져 있던 조각을 한 번에 세울 수 있는 도구이기 때문입니다.
이 지도가 머리에 있으면 AI에게 내리는 지시의 수준이 달라집니다. 예컨대 "이미지를 데이터베이스에 그대로 넣으면 느려지니, 파일은 스토리지에 올리고 데이터베이스에는 그 주소(URL)만 저장하라"고 구체적으로 말할 수 있게 되죠. 도구의 버튼 위치를 아는 것과 그 도구가 왜 그렇게 생겼는지를 아는 것은, 결국 지시의 정확도에서 갈립니다. 비개발자를 대상으로 한 바이브 코딩 교육에서 도구 사용법보다 이 계보부터 짚는 이유가 바로 그것입니다. 계보를 이해한 사람은 AI를 손이 아니라 판단으로 부립니다.