#title 추잡한 언어 SQL
[[TableOfContents]]

데이터베이스관련 책을 보다보면 SQL을 작성할 때는 집합적 사고방식을 가져야 한다고들 쓰여져 있다. 어떤 책은 집합적 사고(90%) + 절차적 사고(10%)라고 한다. 어떤 이는 불과 몇 십줄의 코드로 매우 많은 일을 하므로 매우 좋은 언어라고 칭찬을 아끼지 않는다. 필자도 매우 훌륭한 언어라고 얼마 전까지는 생각했었다. 그러나 OREILLY사의 Lex&Yacc라는 책의 아래 글귀를 보는 순간 훌륭한 언어인 SQL은 추한 언어로 바뀌어 버렸다. 책에는 다음과 같이 쓰여져 있었다.

''SQL은 데이터베이스 계의 포트란이다. 쉽게 말하면, 아무도 SQL을 썩 좋아하지 않으며 언어 자체도 추하고 임의적이지만 모든 데이터베이스가 지원하고 있기 때문에 우리도 그저 이용할 뿐이다''

라고 쓰여져 있었다. 이 글을 읽는 순간 필자는 의자 뒤로 넘어갈 뻔했다. '언어 자체도 추하고..' 란 글귀는 DB로 먹고 사는 놈에게는 그야말로 충격이 아닐 수 없었다. 그나마 가장 자신있고, 가장 잘 다루는 언어가 SQL이었던 필자는 SQL이라는 언어 자체에 대한 편리성, 범용성, 과학성등은 생각하지도 못했던 우물안 개구리였던 것이다. 왜 그럴까? 왜 그렇게 추하다고 써 놓았까? 필자가 곰곰히 생각해 본 결과 '집합적'이라는 글에서 그 이유를 찾을 수 있었다. 집합적 사고를 하여 내 머리속에서는 다음과 같이 생각할 것이다.

  '월급을 3000만원 ~ 4000만원 받는 사람의 사원명, 월급을 얼렁! 빨리! 퍼뜩! 보여줘..ㅡㅡ^'

SQL을 작성해 보면 다음과 같을 것이다.

{{{#!geshi sql
SELECT * FROM 사원
WHERE 월급 BETWEEN 3000 AND 4000
}}}

SQL이 DBMS에서 내부적으로 어떻게 동작하는지 모두 표현해주지 않는다. 아마도 DBMS는 다음과 같이 동작 할 것이다.

 1. SQL문장이 문법에 맞는지 틀리는지 검사                    --> 내부적으로 매우 복잡
 2. 사원 테이블에 SELECT할 권한이 있는지 검사                --> 내부적으로 매우 복잡
 3. 통계정보(인덱스가 있는지, 병렬처리 할 것인지 등등) 검사  --> 내부적으로 매우 복잡
 4. 비용이 가장 적게들 만한 실행계획의 후보선정 및 작성      --> 내부적으로 매우 복잡
 5. 후보 선택 및 실행                                        --> 그나마 조금 보여줌. 그래도 복잡

간단하게 단계별로 표현했지만 대단히 복잡함을 짐작할 수 있는가? 5번에서 그나마 조금 보여준다고 했지만 그 조금보여주는 것을 해석하기 위해서 기본적으로 알아야 하는 것이 매우 많이 있다. 예를 들어 아래와 같이 동작하였다고 가정해 보자.

||"4개의 테이블은 조인한다고 가정해보자. 각각의 테이블을 Hash, Merge, Loop방식으로 조인연산을 수행한다. 인덱스는 Unique Index, Non-Unique Index를 사용했으며, 인덱스는 각각 Dense Index, Sparse Index였다"||

아주 간단한 예이다. 하지만 위의 예에서 나온 Hash, Mege, Loop방식의 조인이 무엇인가를 모른다면 당신은 불행한 개발자 또는 관리자이다. 또한 왜 4개의 테이블이 각각 다른 방식으로 연결되어 사용되었는지 알지 못한다면 더욱 불행해진다. 그러나 더더욱 불행한 것은 이러한 내부동작이 현실적으로 맞는 선택이었는지에 대한 판단을 우리가 해야 한다는 것이다. DBMS의 옵티마이저는 대부분 올바른 결정을 내려주지만 어떤 상황에서건 올바른 정답을 주지는 않기 때문이다.

데이터 몇 십건 몇 백건을 가지고 공부를 할 때는 '집합적' 사고방식으로 어떤 짓을 해도 SQL의 결과로 나온 대부분의 결과집합의 질(여기서는 응답시간)은 떨어지지 않는다. 몇 천 만건, 몇 억 건된다고 해도 대부분은 만족할 만한 결과를 얻을 수 있다. 그 만큼 DBMA 옵티마이저가 지능적이기 때문이다. 어찌보면 복잡한 내부 동작은 알 필요없이 원하는 목표 결과 집합만을 정의하면 원하는 결과를 얻을 수 있다는 것은 매우 이상적이며 데이터베니스에 접근하는 사용자로써는 매우 행복한 일이다. 그러나 DBMS 옵티마이저가 지능적이면 지능적일수록 우리는 신경 쓸 필요가 없기 때문에 더욱 행복해 질까? 아무리 생각해도 처음부터 DMBS 옵티마이저에게 의존적인 SQL은 불행하다. 

게다가 DBMS 옵티마이저의 동작방식의 표준이 있지도 않다. ANSI-SQL이라는 표준이 있어도 결과집합에 관한 표준이지 내부적인 처리에의 표준은 아니다. 물론 DBMS 제품이 달라도 이제까지 발표된 전산/수학 이론들에 기초해서 만들어지고, 실무에서 실용성이 검증된 것을 기반으로 만들어질 것이므로 기본적인 옵티마이저의 동작받식은 같을 것이다. 어쨌든 DBMS마다 옵티마이저의 동작방식이 다른 부분이 있으므로 SQL은 제품 종속적인 언어가 되버린다. 닝기리..