SQL은 인기와 성공에도 불구하고 수많은 모순을 안고 있다. 다소 투박하고 장황한 문법을 지녔지만, 개발자에게는 여전히 가장 단순하고 직접적인 데이터 추출 방법이다. 잘 작성된 쿼리는 매우 빠르게 실행되지만, 조금만 잘못되면 처리 속도가 급격히 느려진다. 수십 년 된 언어임에도 불구하고 새로운 기능이 계속 추가되고 있다.
그러나 시장은 명확한 메시지를 보냈다. SQL은 여전히 수많은 개발자의 첫 번째 선택이다. 가장 작은 웹사이트부터 초대형 기업까지, 모두 SQL을 활용해 데이터를 정리하고 관리한다.
SQL의 테이블 기반 모델은 지나치게 강력해서, SQL이 아닌 프로젝트조차 사용자 요구에 따라 SQL 유사 인터페이스를 제공하게 되는 경우가 많다. NoSQL 운동조차 이 틀에서 벗어나고자 시작됐지만, 결국 SQL에 흡수되는 모습을 보였다.
SQL의 한계가 존재하더라도 완전히 사라지지는 않을 것이다. 개발자가 데이터를 완전히 옮길 가능성은 낮지만, 그로 인해 스트레스가 발생하고, 프로젝트 지연이나 구조 재설계가 필요한 경우도 적지 않다.
다음은 개발자가 SQL을 떠나고 싶어 하는 13가지 이유다. 물론 실제로 떠나진 않을 것이다.
테이블은 확장되지 않는다
관계형 모델은 테이블을 중심으로 구성된다. 이는 소규모 혹은 일반적인 규모의 데이터베이스에서는 문제가 되지 않는다. 그러나 초대형 규모에서는 구조가 무너지기 시작한다.
일부는 기존 오픈소스 데이터베이스에 샤딩을 통합해 문제를 해결하려 하지만, 이 접근법은 종종 예상치 못한 위험 요소를 숨긴다. SELECT나 JOIN의 실행 시간이 데이터의 샤드 분산 여부에 따라 천차만별로 달라질 수 있다.
샤딩은 DBA에게 데이터가 다른 머신 또는 다른 지역에 저장돼 있을 가능성을 고려하게 만든다. 이 사실을 모른 채 전역 테이블을 검색하면 혼란에 빠질 수 있다. 일부 SQL 모델은 데이터 위치를 추상화해 감추기도 한다.
AWS의 일부 인스턴스는 24테라바이트의 RAM을 제공한다. 이유는 명확하다. 단일 머신과 단일 RAM 블록에서 실행되는 거대한 SQL 데이터베이스가 더 빠르게 동작하기 때문이다.
SQL은 JSON이나 XML에 최적화되어 있지 않다
SQL은 여전히 널리 쓰이지만, JSON, YAML, XML 같은 현대적인 데이터 형식과는 잘 어울리지 않는다. 이들 형식은 SQL보다 훨씬 유연하고 계층적인 구조를 갖고 있다.
물론, 일부 SQL 데이터베이스는 이러한 형식을 지원하는 기능을 내장하고 있지만, 내부에서는 여전히 기존 테이블 구조를 따른다. JSON 처리는 일종의 외피에 불과하며, 그 이면에서는 변환 비용이 발생한다.
결과적으로 개발자는 데이터를 변환하는 데 많은 시간을 소모하게 된다. 데이터를 더 현대적인 방식으로 저장하는 편이 낫지 않을까 하는 의문이 생긴다. 하지만 대다수 개발자는 여전히 SQL 파서를 원한다.
마샬링은 시간 낭비다
데이터베이스는 테이블로 데이터를 저장하지만, 프로그래머는 객체로 코드를 작성한다. 결국 애플리케이션 설계의 많은 시간이 데이터를 객체로 변환하고, 이를 다시 SQL UPSERT로 역변환하는 데 사용된다.
데이터를 즉시 사용 가능한 형식으로 유지할 방법은 정말 없는 것일까?
SQL은 실시간 처리를 지원하지 않는다
SQL은 원래 일괄 처리와 대화형 분석을 위해 설계됐다. 스트리밍 데이터와 장시간 처리 파이프라인은 비교적 최근의 개념이다.
기존 SQL 데이터베이스는 독립된 존재로 쿼리에 응답하는 오라클 같은 모델을 기반으로 했다. 어떤 쿼리는 빠르게, 어떤 쿼리는 느리게 응답한다. 스트리밍 환경에서는 이러한 접근이 적절치 않다.
최신 애플리케이션은 실시간 성능을 요구한다. 이에 대응하기 위해 새롭게 설계된 데이터베이스는 속도와 반응성을 최우선으로 하며, 복잡한 SQL 쿼리는 오히려 배제하는 경향이 있다.
JOIN은 악몽이다
관계형 데이터베이스의 강점은 데이터를 정규화해 분리하는 데 있다. 문제는 다시 합치는 과정이다.
JOIN은 대다수 작업에서 가장 많은 연산 비용이 든다. 특히 데이터가 RAM을 초과하기 시작하면 상황은 더욱 복잡해진다.
JOIN은 초보자에게도 매우 어렵다. INNER JOIN과 OUTER JOIN의 차이를 이해하는 데서 시작해, 여러 JOIN을 효율적으로 구성하는 데까지 난이도는 높아진다.
컬럼은 공간 낭비다
NoSQL의 핵심 개념 중 하나는 컬럼에서의 해방이었다. 새로운 값을 추가할 때 태그만 붙이면 되며, 스키마를 수정할 필요가 없었다.
SQL 지지자는 이 모델을 혼란스럽다고 본다. 테이블의 질서가 무너지고, 필드가 난립한다는 것이다. 이들의 주장에도 일리는 있지만, 대규모 테이블에서 새로운 컬럼을 추가하는 작업은 매우 번거롭고 시간도 오래 걸린다.
새로운 데이터를 별도 컬럼에 저장하고, 다시 JOIN으로 연결하는 방식은 더 많은 시간과 복잡성을 요구한다.
최적화는 한계가 있다
많은 연구자와 기업이 쿼리 최적화 기술 개발에 공을 들였다. 일부 쿼리에서 성능 향상은 뚜렷하지만, 복잡한 쿼리에 대해서는 한계가 분명하다.
개발 초기에는 적은 양의 테스트 데이터에 대해 충분한 성능을 보이지만, 실제 서비스 규모로 확장되면 한계에 도달하게 된다. 최적화는 유용하지만 만능은 아니다.
비정규화는 테이블의 가치를 무시한다
성능을 요구하는 사용자와 비용을 걱정하는 경영진 사이에서, 개발자는 종종 테이블을 비정규화한다. 복잡한 JOIN 없이도 모든 데이터를 한 곳에서 조회할 수 있기 때문이다.
비정규화는 기술적으로 나쁘지 않은 선택일 수 있다. 디스크 비용이 처리 비용보다 저렴해졌기 때문이다.
하지만 이 방식은 SQL과 관계형 데이터베이스 이론의 정수를 무시하는 결과로 이어진다. 데이터베이스가 단순한 CSV 파일처럼 변해버리는 것이다.
덧붙여진 기능이 성능을 해칠 수 있다
수년간 SQL에는 다양한 기능이 추가되어 왔다. 일부는 유용하고 창의적이다. 문제는 이들 기능이 종종 기존 구조 위에 얹혀진 ‘볼트온’ 형태라는 점이다.
일례로, 서브쿼리, 공통 테이블 표현식(CTE), 뷰, 윈도 함수 등은 쿼리의 복잡도를 급격히 높일 수 있다. 작성자는 이해할 수 있겠지만, 다른 개발자는 수많은 레이어를 따라가느라 머리가 아파진다. 일종의 크리스토퍼 놀란 감독 영화 같다는 말도 나온다.
좋은 아이디어가 기존 기능을 방해한다
윈도 함수는 평균값 같은 기본 분석 결과를 빠르게 계산할 수 있도록 설계됐다. 하지만 많은 SQL 사용자는 이런 내장 기능 대신, 별도로 추가된 복잡한 기능을 선호하곤 한다.
대다수 경우, 새로운 기능을 시도해보고 나서야 시스템 속도가 급격히 느려졌다는 사실을 인지하게 된다. 결국, 원인을 파악하고 해결 방법을 알기 위해 노련한 DBA의 조언을 구해야 한다.
SQL 문법은 지나치게 취약하면서도, 충분히 취약하지 않다
SQL이 탄생했던 과거에는 오직 사람이 쿼리를 작성했다. 하지만 지금은 수많은 시스템이 자동으로 쿼리를 조합한다. 이로 인해 단순하거나 악의적인 사용자에게도 과도한 권한이 주어지는 일이 발생한다.
경험 있는 DBA는 예약어를 피해야 한다는 사실을 잘 알고 있다. 하지만 일반 사용자는 ‘SELECT GROUP’을 컬럼 이름으로 쓰고 싶을 수 있다.
이럴 때 사용되는 회피 방법은 각기 다르다. 예를 들어, MySQL은 백틱(), PostgreSQL은 큰따옴표(“)를 사용한다. 어떤 것을 써야 할지는 사용하는 SQL 버전에 따라 다르다. 문제는 여기서 끝나지 않는다. 교묘한 공격자는 이 취약점을 노려 쿼리에 악의적인 SQL 명령을 삽입할 수 있다. 예컨대, 이름 입력란에 ; DROP TABLE users; DROP TABLE products; DROP TABLE orders;–` 같은 명령을 넣을 수 있다. SQL 파서는 이런 명령도 순순히 수행한다. 어차피 사람이 직접 입력하던 시절의 설계니까 말이다.
세상 모든 데이터가 테이블에 맞지는 않는다
많은 데이터는 테이블 형태에 잘 들어맞지만, 점점 더 많은 데이터는 그렇지 않다.
예를 들어, 소셜 네트워크, 계층형 데이터, 과학적 현상은 대부분 그래프 모델로 표현된다. 이 데이터를 테이블에 저장하는 것은 가능하지만, 간단한 쿼리 외에는 매우 복잡해진다.
2차원 또는 3차원의 공간 데이터도 마찬가지다. 시간 시계열 데이터는 하나의 주요 축만 가지지만, 다른 데이터는 두세 개 또는 그 이상의 축을 갖는다.
SQL의 테이블은 행(row)이라는 하나의 축과 열(column)이라는 부차적 축만 가지고 있다. 이 구조는 위도·경도 같은 2차원 데이터 저장은 가능하지만, 거리 계산 같은 다차원 처리는 어렵게 만든다. 이를 보완하기 위한 지리 확장 기능도 있지만, 여전히 SQL 패러다임의 제약을 벗어나긴 어렵다.
SQL은 사실상 표준이 아니다
SQL이 ANSI/ISO 표준이라는 점은 사실이지만, 이를 곧바로 다른 데이터베이스에 적용할 수 있다는 뜻은 아니다. “표준”이라는 단어의 의미를 다르게 이해해야 할지도 모른다.
경험 많은 DBA는 문법적 차이를 잘 알고 있다. MySQL은 ‘CURDATE()’, 오라클은 ‘SYSDATE’, PostgreSQL은 ‘CURRENT_DATE’를 사용한다.
문자열 결합도 제각각이다. SQL Server는 ‘+’ 연산자를 사용하지만, 다른 시스템은 ‘||’ 기호를 요구한다.
이처럼 문법적 차이뿐 아니라 저장 프로시저, 트리거, 지원 함수, 데이터 타입 등의 구현 철학도 크게 다르다. 기본적인 데이터 타입조차 정밀도나 범위에서 차이를 보인다.
더 나은 대안은 있다
IT 팀은 기존에 구축된 시스템을 유지해야 하는 경우가 많다. 하지만 SQL을 버려야 할 가장 강력한 이유는, 더 나은 대안이 이미 존재한다는 점이다.
GraphQL은 웹 애플리케이션에서 자주 사용된다. 단순한 패턴으로 원하는 데이터 조합을 요청할 수 있고, 계층형 데이터도 자연스럽게 지원된다.
NoSQL 데이터베이스에도 다양한 검색 옵션이 있다. 키-값 저장소는 일치하는 노드를 찾는 방식이며, MongoDB 쿼리 언어(MQL)은 JSON 표준을 모방해 익숙함을 더했다.
SOLR, 엘라스틱서치 같은 문서 지향 솔루션은 복잡한 유사성 비교 기능까지 지원한다.
이들은 더 직관적이고 강력한 쿼리 문법을 제공한다. 데이터를 테이블 구조로 제한하지 않고 다양한 방식으로 저장하고 처리할 수 있다. 테이블만이 데이터의 전부라는 발상은 지나치게 협소한 시각이다.
dl-itworldkorea@foundryco.com
Peter Wayner editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.