칼럼 | SQL의 굴레에서 벗어나고 싶은 9가지 이유

SQL(Structured Query Language)은 큰 인기와 성공을 거두었지만 역설의 이름이기도 하다. 투박하고 장황하지만 개발자 관점에서는 원하는 데이터를 추출하기 위한 가장 간편한 방법이 되는 경우가 많다. 쿼리가 제대로 작성되면 매우 빠른 속도를 자랑하지만 쿼리가 잘못 작성되면 답답할 만큼 느려진다. 수십 년 전에 나왔지만 새로운 기능이 계속해서 추가되고 있다.
 

 
시장에서는 이런 역설이 문제 되지 않는다. 더 새롭고 아마도 더 강력할 선택지가 많음에도 불구하고 여전히 첫 번째 선택은 SQL이기 때문이다. 가장 작은 웹사이트부터 가장 큰 대기업에 이르기까지 모든 곳의 개발자가 SQL을 안다. 이들은 모든 데이터를 체계적으로 유지하기 위해 SQL을 사용한다.

SQL의 테이블 형식 모델이 워낙 지배적이다 보니 SQL이 아닌 프로젝트에서도 사용자들의 요구에 따라 결국 SQL과 비슷한 인터페이스를 추가하는 경우가 많다. 심지어 오래된 SQL 패러다임에서 벗어나기 위해 만들어진 NoSQL에서도 이는 마찬가지다. 어느 모로 보나 결국 SQL이 승리한 것으로 보인다.

SQL에도 한계가 있지만, 그것만으로는 SQL을 쓰레기통으로 몰아넣기에 부족한 듯하다. 개발자들이 들고 일어나서 모든 데이터를 SQL에서 다른 곳으로 마이그레이션하는 일은 영영 일어나지 않을 수도 있다. 그러나 SQL의 문제는 분명히 존재하며, 개발자에게 스트레스를 주고 작업을 지연시키고 때로는 프로젝트 리엔지니어링을 요구하기도 한다. 

현실화되지 않을 가능성이 높지만, 그래도 SQL을 벗어날 수 있기를 희망하는 9가지 이유는 다음과 같다.

테이블이 확장되지 않음

관계형 모델은 테이블을 좋아한다. 그래서 우리도 계속 테이블을 만든다. 작거나 보통 크기의 데이터베이스에서는 문제가 없다. 그러나 규모가 제대로 커지면 이 모델은 무너지기 시작한다.

어떤 사람들은 오래된 오픈소스 데이터베이스에 샤딩을 통합하는 등 예전 것과 새로운 것을 섞어 이 문제를 해결하려고 시도한다. 레이어 추가는 데이터를 관리하기 쉽게 해주고 무한대의 확장을 제공하는 것처럼 보이겠지만, 추가된 레이어에는 지뢰가 숨어있을 수 있다. 샤드에 얼만큼의 데이터가 저장돼 있는지에 따라 SELECT 또는 JOIN을 처리하는 시간이 크게 달라질 수 있다.

또한 샤딩을 사용할 경우 DBA는 데이터가 다른 시스템 또는 다른 지리적 위치에 저장될 가능성도 고려해야만 한다. 경험이 부족한 관리자라면 데이터가 다른 위치에 저장되어 있다는 사실을 모른 채 테이블을 검색하다가 혼란에 빠질 수 있다. 이 모델은 종종 저장 위치를 추상화해서 볼 수 없게 한다.

일부 AWS 시스템에는 24테라바이트의 RAM이 제공된다. 이유가 무엇일까? 그 정도의 용량이 필요한 데이터베이스 사용자가 있기 때문이다. SQL 데이터베이스에 이렇게 많은 데이터를 저장해 둔다. 이 데이터베이스는 하나의 시스템, 하나의 RAM 블록에서 훨씬 더 원활하게 실행된다.

SQL은 JSON 또는 XML 네이티브가 아님

SQL은 시들지 않는 언어일지 몰라도 JSON, YAML, XML과 같은 비교적 새로운 데이터 교환 형식과는 특히 잘 맞지 않는다. 이들 형식은 모두 SQL보다 더 계층적이고 유연한 형식을 지원한다. SQL 데이터베이스의 핵심은 여전히 모든 곳에 테이블이 난무하는 관계형 모델에 갇혀 있다.

이런 일반적인 불만에 대해 시장은 미봉책을 찾는다. 적절한 글루 코드를 사용하면 비교적 쉽게 JSON과 같은 다른 데이터 형식을 추가할 수 있지만, 여기에는 시간 손실이라는 대가가 따른다. 일부 SQL 데이터베이스는 이제 네이티브 기능으로 JSON, XML, 그래프QL 또는 YAML과 같은 최신 데이터 형식을 인코딩 및 디코딩할 수 있다. 그러나 일반적으로 내부 데이터 저장 및 인덱싱에는 똑같은 오래된 테이블 모델이 사용된다.

이런 형식의 데이터를 변환하는 데 얼마나 많은 시간이 소요될까? 더 현대적인 방식으로 데이터를 저장하는 것이 더 쉽지 않을까? 영리한 데이터베이스 개발자들이 계속 실험은 하고 있지만, 이상하게도 결국 일종의 SQL 파서를 덧붙이는 것으로 끝내는 경우가 많다. 개발자들은 이게 자신들이 원하는 것이라고 말한다.

마샬링에 많은 시간 낭비

데이터베이스는 테이블에 데이터를 저장할 수 있지만 프로그래머는 객체를 다루는 코드를 작성한다. 데이터 주도 애플리케이션을 설계하는 작업 대부분은 데이터베이스에서 데이터를 추출해서 비즈니스 로직이 다룰 수 있는 객체로 변환할 최선의 방법을 찾는 것이다. 그런 다음 객체의 데이터 필드를 SQL 업서트(upsert)로 변환해서 언마샬링해야 한다. 데이터를 바로 사용할 수 있는 형식으로 남겨두는 방법은 없을까?

SQL은 실시간으로 동작하지 않음

최초의 SQL 데이터베이스는 일괄 분석 및 인터랙티브 모드에 맞게 설계됐다. 긴 처리 파이프라인을 두고 데이터를 스트리밍하는 모델은 비교적 새로운 개념이며 SQL과는 잘 맞지 않는다.

여러 주요 SQL 데이터베이스는 수십 년 전에 설계됐는데, 당시 모델에서는 데이터베이스가 마치 신탁을 받은 사제처럼 홀로 앉아 질의에 답변하는 모습을 상정했다. 응답 속도가 빠른 경우도 있고 그렇지 않은 경우도 있다. 일괄 처리라는 것이 원래 그렇다.

최신 애플리케이션 중 일부는 더 나은 실시간 성능을 요구한다. 편의성을 위해서만이 아니라 애플리케이션에 필요하기 때문이다. 산속의 은둔 고수처럼 앉아 있는 형태는 현대의 스트리밍 세계에서는 잘 통하지 않는다. 이런 시장에 맞춰 설계된 최신 데이터베이스는 속도와 응답성을 중시하며, 극심한 속도 저하를 일으킬 수 있는 종류의 정교한 SQL 쿼리를 제공하지 않는다.

골칫거리 JOIN

관계형 데이터베이스의 힘은 데이터를 더 작고 간결한 테이블로 쪼개는 데서 나온다. 문제는 그다음이다. JOIN을 사용한 즉석 데이터 재조합은 데이터베이스가 모든 데이터를 처리해야 하므로 보통 가장 많은 계산이 필요한 부분이다. 데이터가 RAM의 크기보다 커지기 시작하면 문제도 함께 시작된다.

JOIN은 SQL을 배우는 모든 사람에게 매우 혼란스럽다. 내부 JOIN과 외부 JOIN의 차이를 이해하는 것은 시작에 불과하다. 여러 JOIN을 연결하는 최선의 방법을 찾기는 더 어렵다. 내부 옵티마이저가 도움이 될 수 있지만, 데이터베이스 관리자가 특히 복잡한 조합을 요청할 때는 도움이 되지 못한다.

열 공간 낭비

NoSQL의 가장 훌륭한 아이디어 중 하나는 사용자에게 열로부터의 자유를 제공한다는 점이었다. 항목에 새로운 값을 추가하려면 원하는 태그나 이름을 선택할 수 있었다. 새 열을 추가하기 위해 스키마를 업데이트할 필요가 없었다.

SQL 옹호자들은 이 모델이 혼란스럽다고 본다. 이들은 테이블이 주는 질서를 좋아하고 개발자들이 즉석에서 새 필드를 추가하는 것을 원하지 않는다. 일리는 있다. 그러나 새로운 열 추가는 특히 큰 테이블에서 매우 값비싸고 시간도 많이 소비되는 작업이 될 수 있다. 새 데이터를 별도의 열에 넣고 JOIN으로 매칭하는 경우 시간과 복잡성이 한층 더 추가된다.

옵티마이저는 일부 경우에만 도움이 됨

데이터베이스 기업과 연구원들은 쿼리를 해부해서 작업을 지시하는 최선의 방법을 찾아주는 좋은 옵티마이저를 개발하는 데 많은 시간을 투자해 왔다. 이렇게 해서 상당한 이득을 얻을 수 있지만 옵티마이저가 할 수 있는 일에는 한계가 있다. 쿼리가 특별히 크거나 장황한 응답을 요구하더라도 옵티마이저는 그저 지시를 받은 대로 답을 조합해야 한다.

일부 DBA는 애플리케이션의 규모가 커지기 시작할 때야 이를 알아챈다. 초기 최적화는 개발 중의 테스트 데이터 집합을 처리하기에는 충분하다. 그러나 본격적인 작업에서는 옵티마이저가 쿼리에서 짜낼 수 있는 이득이 더 이상 없다.

역정규화의 비효율적인 테이블 취급 방식

개발자들은 더 빠른 성능을 원하는 사용자와 값비싼 고성능 하드웨어 돈을 지출하기를 꺼리는 회계팀 사이에 끼는 경우가 많다. 일반적인 해결 방법은 테이블을 역정규화해서 복잡한 JOIN이나 크로스 테이블 등이 필요 없도록 하는 것이다. 모든 데이터는 이미 하나의 긴 직사각형 안에 있다.

기술적으로 나쁜 해결 방법은 아니고, 디스크 가격이 처리 성능 대비 저렴해진 만큼 실제 효과를 거두는 경우도 많다. 그러나 역정규화는 SQL과 관계형 데이터베이스 이론에서 가장 빛나는 부분을 버리는 것이기도 하다. 데이터베이스가 하나의 긴 CSV 파일이 되면 데이터베이스가 가진 온갖 강력함이 사실상 사라지게 된다. 

데이터베이스를 망치는 땜질식 처방

개발자들은 오랜 시간 동안 SQL에 새로운 기능을 추가해 왔고 그중에는 꽤 괜찮은 기능도 있다. 본인이 사용할 필요가 없다 해도 멋진 기능에 대해 화를 낼 이유는 없다. 하지만 이런 화려한 기능들은 땜질식으로 덧붙인 형태인 경우가 많아 성능 문제로 이어질 수 있다. 

하위 쿼리가 모든 작업의 속도를 저하시키므로 각별히 주의해야 한다고 경고하는 개발자도 있고, 공통 테이블 식, 뷰, 창과 같은 하위 집합을 선택할 경우 코드가 지나치게 복잡해진다고 말하는 개발자도 있다. 코드를 만든 당사자는 읽을 수 있지만 다른 모든 사람들은 모든 레이어와 세대의 SQL을 일목요연하게 정리하는 데 큰 어려움을 겪게 된다. 코드로 된 크리스토퍼 놀란의 영화를 보는 것과 같다.

훌륭한 아이디어 중에는 이미 잘 동작하는 기능을 방해하는 경우도 있다. 창 함수는 평균과 같은 결과의 계산 속도를 높여 기본적인 데이터 분석을 더 빠르게 하기 위한 목적으로 설계됐다. 그러나 많은 SQL 사용자들은 이 함수 대신 땜질식으로 추가된 기능을 발견하고 사용한다. 대부분의 경우 새로운 기능을 시도해 보고 시스템 성능이 극심하게 저하된 다음에야 뭔가 잘못되었음을 인지한다. 결국 무슨 일이 일어났는지, 어떻게 해결해야 하는지 알려줄 경험 많은 노장 DBA가 필요하게 된다.
editor@itworld.co.kr