SQL은 죽었다. SQL이여 영원하라!
나는 30년 동안 엔터프라이즈 IT 업계에 있었습니다. 수많은 유행이 나타났다 사라지는 것도 봤고, 영업 담당자와 컨설턴트들이 기업에 진짜 판도를 바꿀 기술 혁신이라고 약속했던 것들이 결국 실패한 약속의 무덤으로 쌓이는 것도 충분히 오래 지켜봤습니다.
여기에는 일종의 성배처럼 팔렸지만 결국 하루살이처럼 지나가 버리거나 잠깐의 명성을 누린 뒤 틈새시장으로 밀려난 사례들이 있습니다.
하지만 반대 사례도 있습니다. 수십 년 전에 이미 죽었다고 선언된 기술이 AI 시대까지 살아남아 지금도 멀쩡히 살아 있는 경우입니다.

기술 도입에 대한 장기 예측은 대부분 빗나갑니다.
여기에 기여하는 요소는 많지만, 특히 하나가 눈에 띕니다. 우리는 기술 도입의 관성을, 특히 엔터프라이즈 IT에서, 악명 높을 정도로 과소평가하는 경향이 있습니다.
이것은 어느 정도 인간의 본성과 관련이 있을 수 있지만, 주로 엔터프라이즈 IT 환경에서 일하는 전문가들의 경험과 관련이 있습니다. 물론 IT는 경쟁력을 높이고 성장을 강화하기 위해 비즈니스에 실질적인 혁신을 제공해야 합니다. 하지만 IT 리더십의 핵심 기능은 적절한 균형 속에서 리스크를 관리하고 비용을 최적화해 서비스가 계속 돌아가게 만드는 데 있습니다. 여기에는 사람과 기술이 모두 포함되며, 단순한 시스템 가용성과 사이버보안을 훨씬 넘어서는 문제입니다.
엔터프라이즈 IT에서 의사결정이 이루어지는 방식
간단한 예를 들어보겠습니다. CTO인 내가 새로운 프로젝트를 위해 프로그래밍 언어를 고를 때, 그 언어 자체의 기능만 보지 않습니다. 다른 요소들이 오히려 의사결정에서 더 중요합니다. 회사 내부와 더 넓은 시장을 모두 들여다보며, 그 언어가 얼마나 대중적인지 이해해야 합니다. 해당 언어 개발자를 채용하기 쉬울까요?
예를 들어 2025년에 새로운 프로젝트에서 JavaScript와 Ruby 중 하나를 골라야 한다면, 나는 먼저 StackOverflow 설문조사 를 확인해 개발자의 66% 이상이 JavaScript를 알고 있지만 Ruby를 아는 사람은 6.4%에 불과하다는 사실을 볼 것입니다(Ruby는 서버사이드 대안이 될 수 있습니다). 그런 상황이라면 Ruby가 더 나은 선택이라 해도 나는 아마 JavaScript를 고를 것입니다. 채용이 더 쉬워질 수 있다는 점뿐 아니라, 더 큰 개발자 커뮤니티가 있으면 툴링, 지원, 전문 서비스 기업의 가용성 등 더 풍부한 생태계를 기대할 수 있기 때문입니다. 마찬가지로 기업이 채용 마케팅 도구 를 선택할 때도 견고한 사용자 기반과 강한 생태계 지원을 가진 플랫폼을 우선시하는 경우가 많으며,
그것이 장기적인 안정성과 더 쉬운 통합으로 이어집니다.
그다음에는 장기 추세를 봐야 합니다. 이 언어는 얼마나 오래 존재해 왔는가? 도입은 여전히 증가하고 있는가, 정체되었는가, 아니면 이미 감소하고 있는가? 새로운 트렌드와 혁신을 흡수하며 계속 발전할 것인가? 지금으로부터 5년, 10년 뒤에도 지원이 남아 있을까?
그리고 바로 여기서 SQL과 그 역사에 대한 이야기가 본격적으로 시작됩니다.
SQL이란 무엇인가?
SQL은 데이터 구조를 정의하고, 데이터를 조작하고, 질의하고, 제어하기 위한 목적으로 사용되는 널리 쓰이는 표준화된 프로그래밍 언어이며, 주로 선언형이고 일부 절차적 요소를 포함합니다. 관계대수에 기반하며 VSAM과 같은 이전의 질의 및 데이터 조작 기법을 크게 향상시켰습니다. 하나의 문장은 절, 표현식, 술어, 질의, 재귀적 하위 문장으로 구성됩니다.
벤더별 확장과 방언은 항상 존재했지만, 언어의 핵심 자체는 주요 구현들 전반에서 표준을 따릅니다. 비호환성은 데이터 타입과 더 고급 구성 요소들에서 주로 나타납니다.
SQL은 완벽하지 않습니다. 우아한 수학적 기초를 항상 일관되게 따르지는 않으며, 계층형 데이터와 그래프 지향 데이터에는 최적이 아니고, 객체지향 패러다임에도 결코 잘 맞지 않았습니다. 일반적으로 객체지향 언어와 절차형 언어 모두와 매끄럽게 통합되지는 않습니다(여기서 ORM, 즉 Object-Relational Mapping이 등장합니다). 더 복잡한 문장은 쓰기도 읽기도 어색해질 수 있고, 크고 복잡한 로직을 SQL이나 PL/SQL만으로 모두 작성하는 것은 효율적이지 않습니다.
그래서 시간이 지나며 많은 대안이 제안되었고, 그중 일부는 꽤 성공적이었습니다. 예를 들어 그래프 질의 언어와 키-값 저장소 및 문서 지향 데이터용 noSQL이 있습니다.
하지만 대부분의 성공적인 대안은 결국 각자의 틈새에서 정체되었고, 실제로 최근 몇 년 사이에는 그중 일부가 다시 SQL 쪽으로 후퇴하는 모습도 보입니다. 한편 JSON이나 그래프 같은 개념은 이미 최신 SQL 버전에 적용되어 대안의 필요성을 줄이고 있습니다.
SQL은 오래되었지만, 이 마라톤에서 분명한 승자입니다.
SQL의 기원
SQL의 기원은 1970년대 초반으로 거슬러 올라갑니다. 1970년 Edgar F. Codd는 A Relational Model of Data for Large Shared Data Banks 를 발표하며 관계형 데이터베이스 모델을 소개했습니다.
그것은 RDBMS의 탄생이었습니다. 당시로서는 완전히 새로운 IT 시스템 범주였고, 지금 55년이 지난 오늘날에도 여전히 전 세계 상위 3개 범주 중 하나입니다(IT 인프라와 ERP 시스템과 함께). RDBMS의 도입은 ERP의 부상에 의해 촉진되었고, SQL의 도입도 그와 나란히 진행되었습니다. 쌍둥이처럼 둘 중 하나만 따로 존재할 수 없습니다.
1974년부터 1977년 사이에는 두 개의 주요 관계형 데이터베이스 시스템 프로토타입이 만들어졌습니다. UC Berkeley(UCB)에서 개발된 Ingres와 IBM San Jose에서 만들어진 System R입니다. Ingres는 QUEL이라는 질의 언어를 사용했고, Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE, Britton-Lee와 같은 시스템의 탄생으로 이어졌습니다. 반면 System R은 SEQUEL 질의 언어를 사용했으며 SQL/DS, DB2, Allbase, Oracle, Non-Stop SQL의 발전에 기여했습니다.
또한 이 시기에 Relational Database Management System, 즉 RDBMS가 널리 인지된 용어가 되었습니다.
SQL의 표준화와 도입
SQL에 대한 거의 10년간의 연구개발 이후, 1980년대는 RDBMS의 상용화와 표준화의 시대가 되었습니다. 1980년대에는 여러 상용 데이터베이스 시스템이 출시되었습니다. Oracle V2(1979), Sybase SQL Server(1984), IBM DB2 for Mainframes(1983, System R의 후속), IBM Informix(1985), Microsoft SQL Server 1.0(1987), SAP DB(1988)가 여기에 포함됩니다.
중요한 단계는 1986년과 1987년에 ANSI와 ISO가 각각 SQL을 표준 데이터베이스 언어로 채택한 것이었습니다. 이 표준은 시간이 지나며 수많은 개정을 거쳤고, 가장 최근 개정은 2023년에 이루어졌습니다.
벤더들이 표준화에 동참한 이유에는, 이 진화하는 시장에서 표준이 있으면 전체 성장이 더 빨라질 것이라는 기대, 표준을 지원하지 않으면 경쟁에서 밀릴 것이라는 두려움, 표준에 영향을 미칠 수 있다는 점, 그리고 생태계 차원의 이점이 포함됩니다.
SQL의 초기 성공은 우연히 나온 것이 아니었습니다. 분명한 수요가 있었습니다.
하지만 대규모 성장세는 실제로 1990년대 초반부터 시작되었습니다. 하드웨어 가격 하락, UNIX와 PC 기반 클라이언트-서버 아키텍처의 부상, ERP 도입이 그 원인이었습니다. 또한 이 시기는 MySQL(1995), PostgreSQL(1996), MariaDB(1999)와 함께 오픈소스 관계형 데이터베이스가 등장한 시대이기도 했습니다.
관계형 데이터베이스의 계보는 매우 복잡합니다. 여기에서 자세한 내용을 볼 수 있습니다.

현재 환경과 전망
한마디로 SQL은 앞으로도 계속 남습니다. 그뿐 아니라 그 어느 때보다도 더 살아 있고 성장하고 있습니다. 이 공룡은 현대적인 경쟁자들을 모두 오래 버텨냈을 뿐 아니라 인기 면에서도 넘어섰습니다.
이것은 기술 채택 수명주기와 Gartner Hype Cycle의 개념이 장기적으로는 항상 적용되지 않는다는 완벽한 예입니다. SQL은 모든 정의상 이미 “후기 단계”에 들어섰지만, 그 어느 때보다 빠르게 성장하고 있습니다. 2018년 Gartner Hype Cycle을 보면 SQL은 이미 하나의 카테고리로조차 등장하지 않았고(2025년에도 마찬가지입니다).

지난 5년 동안 SQL 데이터베이스는 단지 버틴 것이 아니라 번영했습니다. 2020 Stack Overflow Developer Survey 에서 MySQL과 PostgreSQL 은 이미 전 세계에서 가장 많이 사용되는 데이터베이스 중 하나였습니다. 2025년이 되자 그 격차는 더욱 벌어졌습니다. MySQL, PostgreSQL, Microsoft SQL Server, SQLite는 이제 전문 개발자가 사용하는 상위 4대 데이터베이스를 이루며, 어떤 noSQL 대안보다도 크게 앞서 있습니다. “SQL은 죽었다”는 예측이 수년간 이어졌지만 데이터는 정반대를 보여줍니다. SQL은 여전히 현대 소프트웨어와 데이터 기반 시스템의 중추입니다.

왜 SQL은 다시 살아났을까?
SQL이 다시 크게 돌아오고 있는 이유에 대한 내 네 가지 가설을 소개하겠습니다. 얼마든지 반박해 주세요. 여러분의 의견이 정말 궁금합니다.

기반
SQL은 당시 더 일반적이던 절차형 언어와 대비되는 최초의 선언형 언어 중 하나였습니다. 선언형 언어는 어떻게 할지를 쓰는 대신 무엇을 원하는지를 기술하게 합니다. 이는 다른 프로그래밍 언어에 익숙하지 않은 사용자들에게 매우 매력적입니다. 적어도 기본적인 사용 사례에서는 배우고 적용하기가 매우 쉽고, 동시에 엄청난 수준의 유연성을 제공해 애드혹 질의부터 트랜잭션 데이터 접근과 조작까지 매우 넓은 범위의 데이터 액세스 패턴에 적합합니다.
성숙도
이처럼 오랜 시간 동안 개발되고 성숙해진 기술은 매우 안정적이고 완성도가 높다고 볼 수 있습니다. 의사결정권자가 SQL을 선택한다고 해서 기술적 리스크를 감수하는 것은 아닙니다.
도입
이 점은 이미 서론에서 언급했습니다. SQL의 도입 수준은 오랜 시간에 걸쳐 때로는 느리게, 때로는 빠르게 성장해 왔고, 지금은 데이터 접근 언어로서 압도적인 지배적 위치를 차지하고 있습니다. 이 위치 자체가 미래 성장까지 더욱 공고히 합니다.
경쟁우위에 관한 경영 이론을 잠시 빌려오면, 양면 플랫폼 기반 시장에서는 선두주자가 막대한 경쟁우위를 갖는다는 사실을 알 수 있습니다. SQL 기반 관계형 데이터베이스는 넓은 의미에서 바로 그런 양면 플랫폼을 이룹니다.
- 커뮤니티(혹은 SQL의 경우 특정 데이터베이스 시스템을 중심으로 여러 커뮤니티가 존재함) – SQL 사용자, 개발자, 기타 전문가를 포함합니다
- 산업 – 시스템 벤더, 전문 서비스 조직, 클라우드 서비스 제공업체, 기타 참여자를 포함합니다.
여기서 강한 네트워크 효과가 작동합니다. 더 큰 커뮤니티는 산업이 시장 규모를 활용하려 하기 때문에 생태계와 시스템 역량의 성장을 밀어 올립니다. 동시에 커뮤니티 자체도 계속 커집니다. 사용자나 그들이 속한 조직이 기술을 선택할 때도 리스크를 관리하고 인재에 접근하기 위해 커뮤니티 규모를 중요하게 보기 때문입니다.
이 효과는 매우 강력해서, 원래 그 목적을 위해 만들어지지 않았던 사용 사례까지 플랫폼이 “빨아들이는” 현상으로 이어질 수 있습니다. 예를 들어 관계형 데이터베이스 위의 그래프 및 벡터 데이터베이스 확장이 그렇습니다.
진화
생물학적 진화와 마찬가지로, 우리는 기술 진화에서 외부 사건을 예측할 수 없습니다. 사건이 일어난 뒤에야 적응할 수 있을 뿐입니다. 장기적으로 생존 가능성이 가장 높은 것은 가장 강한 종도, 가장 빠른 종도, 가장 큰 종도 아닙니다. 변화에 가장 잘 적응하는 종입니다. 2025년의 SQL은 더 이상 1970년의 SQL이 아닙니다.
SQL은 그 과정에서 빅데이터와 분산 시스템(샤딩과 파티셔닝, 분산 SQL 데이터베이스, 컬럼형 스토리지와 분석), 현대적인 프로그래밍 및 AI 언어와의 원활한 통합, 반정형 및 비정형 데이터 지원(json, 배열 타입, xml), 실시간 분석에 대한 적응, 고급 분석과 ML 지원(예: BigQuery ML, PostgreSQL 확장), AI 파이프라인 통합, 인메모리 처리, 벡터화된 질의 실행, GPU 가속 ML과 같은 중요한 변화를 흡수해 왔습니다.
SQL의 다음 단계는 무엇일까?
SQL은 자신이 쇠퇴할 것이라는 예측보다 더 빠르게 진화할 수 있음을 증명해 왔습니다. AI, 벡터 검색, 실시간 분석이 우리가 애플리케이션을 구축하는 방식을 재편하는 가운데서도 SQL은 사라지지 않고 계속 적응하고 있습니다. 다음 물결은 SQL을 대체하지 않을 것입니다. 오히려 SQL을 확장할 것입니다. SQL은 AI를 위한 선택의 데이터베이스 입니다. 우리는 AI 기반 데이터 처리와의 더 깊은 통합, 벡터 네이티브 확장, 그리고 데이터베이스를 그 어느 때보다 동적으로 만들어 주는 클라우드 네이티브 확장을 보게 될 것입니다.
수십 년간 수많은 하이프가 오고 가는 것을 지켜본 우리에게 SQL의 미래는 익숙하면서도 새롭게 느껴집니다. 여전히 데이터의 언어이지만, 이제는 지능의 언어도 말합니다. 제 가설과 SQL의 미래에 대한 여러분의 피드백을 듣고 싶습니다.
개인적으로 나는 SQL이 여전히 미래라고 믿습니다. 그래서 우리가 Vela 를 만들고 있는 것입니다. Vela는 Postgres 위에 구축된 현대적인 Backend-as-a-Service 플랫폼입니다. 이를 통해 Postgres가 오늘날의 클라우드와 AI 워크로드에서도 SQL을 어떻게 계속 의미 있게 만드는지 보여줄 수 있습니다.