[SQL수다] #001. SQL을 어떻게 작성하시나요? (시작이자 끝)

1. How to write the good SQL ?

[DL] DataSQL 파트에서는 SQL을 어떻게 짜야 하는지에 대한 이야기를 하는 공간입니다.

이 파트에서는 [SQL수다] 와 [SQL Quiz] 두 섹션으로 진행하려 합니다.

 

요즘 대세인 유투브나 과거 대세였던 블로그를 보더라도 SQL의 syntax 설명이나 조인 개념에 대해 설명하는 글은 많이 있습니다. 짐작하시겠만, 기본적인 개념 설명인 SQL syntax와 함수 설명이 주를 이루고 있습니다.

그럼, 기본 개념을 이해하고 있다고 SQL을 잘 작성할 수 있는가?

저는 No. 입니다.

 

이 글을 읽고 있는 분들이라면,

"SQL을 어떻게 해야 잘 짤수 있는가?" 의 답변을 어떻게 하실까요?

 

11년 전, 차세대 프로젝트에서 데이터 이행을 위한 SQL을 작성중이었는데

제가 batch SQL 실력이 낮아서, 다른 사람들보다 SQL 작성 시간이 오래걸리는 겁니다.

데이터 컨설팅을 업으로 하시는 고수들에게

 "어떻게 하면 SQL을 잘 짤 수 있나요?"

라는 질문을 많이 묻고 다녔습니다.

답변은 대부분 "많이 짜봐야지" 였습니다.

물론, 틀린 답변은 아닙니다만 데이터 이행 중에 답답함을 해소할 수 있는 답변은 아니었습니다.

혹자는 1000개의 SQL만 짜 보면 실력이 늘어난다고 하셨는데,

질문할 당시에 데이터 이행 프로그램을 300여 개 테이블을 대상으로 작성한 SQL을 가늠하면 족히 800여개의 SQL을 작성한 것 같은데, 그 동안 작성한 SQL은 그 이상일 겁니다. 그런데, 왜 새로운 문제를 만나면 항상 SQL 작성이 어려운 걸까?

SQL 개수가 큰 영향력이 있어 보지 않다라고 판단하였고, 접근하는 생각에 초점을 맞추게 되었습니다.

 

"저들(고수)은 SQL을 짤 때, 무슨 생각을 하면서 작성하는가?"
"저들은 SQL을 작성하는데 어떤 기준으로 작성할까?"

(ㅠ.ㅠ) 사실 이렇게 물어보아도 고수들은 웃고 맙니다.

모른다고~요. 그냥 하는 거라구요~

2. Find the small difference

나도 할 만큼 해 본 것 같은데, 자신감은 떨어지고 있었죠.

결국, 저의 SQL과  고수들의 SQL의 차이점을 찾기 시작했습니다.

큰 차이를 찾아낼 수도 없었고, 큰 차이를 찾는 것을 바라는 것도 아니었기에

작은 차이가 무엇인지를 찾아내면 하나씩 보완하려 했습니다.

 

먼저, 다른 사람의 SQL을 보는게 쉽진 않습니다.

SQL의 큰 장점이라면 C/C++/Java/Python 등 다른 프로그래밍 언어에 비해 아주 많이 제약으로 가지므로써 얻는 단순성을 갖고 있다는 겁니다. 프로시저/함수 같은 로직을 제외하고, SQL 만을 놓고 보면 집합 간의 조인(Join)과 조건(Where절)을 파악하는 것은 가능합니다. SQL과 SQL 간은 종속성이 낮기 때문에 관리하기도 용이합니다.

SQL의 큰 단점이라면, 타 프로그래밍에서 갖는 처리 흐름이 없기 때문에 업무적 흐름이나 데이터 흐름을 이해하는데 한계가 있다는 겁니다. 결국, 타인의 SQL을 뚤어져라 보아도 해당 업무 지식과 데이터모델의 이해 없이 SQL을 이해하는데 한계가 있다는 것입니다. 보이는 것은 업무의 결과인 테이블과 컬럼, 그리고 데이터 뿐 입니다.

이 말들은 우리가 SQL을 검토 및 이해한다 것은 SQL에 깔린 업무적 배경을 이해와 데이터 처리의 흐름 속에 어느 시점인지를 이해하고 접근해야 한다라는 것을 미리 집고 넘어가려는 겁니다.

 

저는 업무적인 지식이 있어야만 이해할 수 있는 부분은  무시하였고, SQL의 구조와 형태를 주로 바라 보았습니다.  ,

SQL을 작성하는 패턴 속에서 작성자의 생각을 조금이나마 찾아보려는 정도랄가요?

생각보다 시간이 좀더 걸렸지만, 놀랍게도 (독자분들은 놀랍지 않으실 수 있겠지만, 저는 참으로 놀라웠습니다 ㅎㅎ) 한 가지를 발견하게 됩니다.

 

데이터의 가공으로 가상의 데이터를 만들어 간다는 사실

이것은 [SQL 수다] 섹션에서 말하고자 하는 메시지이자 전부 입니다. (참 쉽죠~~잉)

 

데이터를 가공할 줄 알아야 한다는 말이 10년 전의 저에게는 새로운 게 아니었습니다.

회사에서 들어는 왔지만, 어떻게 해야 하는지를 몰랐던 것이었습니다.

그 데이터 가공이라는 것이 무엇을 대상으로 하고, 어떤 절차에 의해 원하는 결과를 낼 것인지에 대해서 굳이~ 상세하게 설명하려드는 사람은 없었다는 것이고, 데이터 가공하는 방법에 대해서 알고자 찾는 사람도 못 봤습니다.

 

데이터 가공은 특정 업무에 필요한 요구사항에서 명시된 것도 아니고, 프로그래밍 설계서에서도 기술되지 않기 때문에, 오로지 SQL을 작성하는 사람의 아이디어에 의해 가상의 데이터를 결정하고 만들어 가는 과정이라는 것입니다. 다시 말하면, SQL 작성시, 존재하는 테이블의 컬럼에 대한 데이터들로만 처리하는 것이 아니라, 기존 데이터로부터 가상의 데이터를 만들어내고 이 가상 데이터를 SQL처리 시 활용함으로써, 다양한 문제를 해결해 나아 갈 수 있다는 것입니다.

 

"그런데, 고수들은 왜 그것을 말해주지 않았을까?"
너무 당연해서?

알면 당연하고, 모르면 당연한게 아닌데 말입니다.

3. So~ What should I do?

데이터의 가공이라는 키워드가 저에게는 크게 와 닿았던 것처럼, 유사하게 느끼실 분들도 계실테고, 아닐 분도 계실겁니다. 제가 데이터를 가공하는 개념이 부족하였다는 점과 함께, 데이터 가공에 있어 일관성을 갖는 방법을 가지고 있지 못한 점을 느끼면서, 어떻게 극복할지? 앞으로는 어떻게 접근해야하는 것인지? 어떤 기준으로 데이터에서 데이터를 만들어 낼 것인지 고민해야 했습니다.

 

요즘에서 말도 안되는 SQL이 있을까?
집계 데이블에서 소계, 총계를 내기 위해 배열에 넣어 프로그램에서 집계를 내고 있지 않을까?
테이블에 데이터를 추가하는데 한 건씩 한 건씩 INSERT 하고 있지 않을까?

이제 SQL 작성을 위해서 무엇을 이해해야 하고, 무엇을 준비해야 하는지가 [SQL 수다] 섹션의 주제라고 보시면 됩니다. [SQL 수다] 섹션에서 제가 DA로서 겪었던 프로젝트의 경험과 학습한 내용을 바탕으로 띤킹인이 어떻게  SQL을 작성하는지 설명드리려 합니다.

그리고  [SQL Quiz] 섹션에서는 다양한 퀴즈 문제를 풀면서 데이터 가공에 대해 고민하면서 자신의 것으로 만들어 보시면 좋을 것 같습니다.

 

여기에서 마무리 하겠습니다.

 

주) 본 글에 대한 저작권은 띤킹인에게 있으며, 상업적인 목적으로 사용하시면 안됩니다. 출처를 명시하시고 공유하실 수 있습니다.

주) 띤킹인' 딴생각 : "이상하게 내가 어떤 사실을 알고 있다고 느껴질 때, 다른 사람들도 그 사실을 다 알고 있는 것 같다고 느낄까?"