SQL을 원래 하셨나요? 전공이 관련 분야이신가요?
데이터 기반으로 기획을 하거나, 의사결정을 하는 실무자들이 증가하고 있습니다. 저희 회사만 봐도, 조직 내 최고 리더들이 데이터를 토대로 사업 및 제품 기획에 대한 보고를 요청하는 경우가 증가했습니다. 이는 자연스럽게 조직 내 구성원들이 데이터에 대해 관심을 갖도록 만들었습니다.
그 과정에서 많은 구성원들이 간단한 데이터를 직접 추출해보거나, 혹은 쿼리 기반으로 작성된 대시보드를 직접 튜닝하는 등의 작업을 시도하는 경우가 많아졌습니다. 이 과정에서 어려움을 겪으면서, 어떻게 SQL 실력을 향상시킬 수 있었는지에 대한 질문을 많이 받았습니다.
여전히 공부를 하고 있고, 부족한 점도 많지만 이런 이야기가, 2020년 11월의 저처럼 처음 SQL을 접하는 분들에게는 도움이 될 수 있다 생각해서 글을 작성해보게 되었습니다.
앞선 글에서 작성한 것처럼, SQL을 잘 활용한다면 엑셀만으로 작업할 때보다 훨씬 더 효율적인 작업이 가능해집니다. 다만, 문제는 많은 사람들에게 엑셀이 매우 친숙하다보니, 이 불편함을 견디지 못하는 경우가 많은 것 같습니다. 예를 들면, SQL을 통해서 GROUP BY 등을 설정하는 것 등이 번거롭다고 생각해서, 엑셀로 로우 데이터를 받아서 피벗 테이블을 돌리는 형태로 보는 것입니다.
저도 비슷했습니다. 2019년에 퍼포먼스 마케팅 회사에서 인턴으로 시작하면서, 정말 엑셀 스킬을 비약적으로 올릴 수 있었습니다. 특히, 선임 마케터분들은 빠른 보고서 정리 등을 위해서 엑셀에서 마우스를 사용하지 않고 작업하는 경우가 비일비재했습니다. 이런 회사에서 인턴 생활을 하면서, 엑셀 스킬을 크게 향상되었고 이후에 일을 할 때 엑셀을 잘 활용한다는 칭찬을 받는 일도 많았습니다.
그러다보니 처음 SQL을 활용할 때는 저도 유혹에 여러번 넘어갔습니다. 새로운 함수를 활용해보고 할 생각보다는 엑셀로 로우 데이터를 받아서 처리하는 식으로도 작업을 했습니다. 하지만, 대용량 데이터를 다루다보면 이 과정에서 오류가 자주 발생했고, 기왕하는거 잘하고 싶다는 생각에 SQL을 꾸역꾸역 시도했습니다.
특히, 만약 출력하고 싶은 데이터값이 있다면 구글에 검색해서 활용할 수 있는 함수가 있는지 등을 찾아봤습니다. 이런 과정을 거치면서, 나중에는 출력해야하는 결과물이 있으면 바로 SELECT부터 막힘없이 내려갈 수 있게 되었습니다.
이것은 초기에 잡아야 할 습관인 것 같습니다. 뒤에서 얘기하겠지만, SQL은 정말 다양한 기능들이 많기 때문에 공부하면 할수록 효율을 높일 수 있습니다. 하지만 엑셀에 많은 부분 의존한다면 장기적으로 나의 데이터 처리 역량에 한계가 생길 수 있기 때문에, 최대한 SQL로 처리를 끝내려고 시도해보시기 바랍니다.
위에서 언급한 것은 SQL을 다루는 것 중 활용도 및 작업속도 측면에서 잘하는 것으로 볼 수 있습니다. 원하는 것을 출력할 수 있고, 필요한 쿼리를 빠르게 작성하는 것도 매우 우수하다고 할 수 있습니다. 다만, '잘한다'고 말하기 위해서 필요한 것들을 꼽는다면 몇가지가 더 있습니다.
하나는 스타일에 대한 부분입니다. 이 딱딱한 SQL에 무슨 폰트 스타일이나 폰트 칼라를 말하는 것인가 생각할 수도 있습니다. 여기서 말하는 SQL 스타일은 작성 가이드라인을 말합니다. 즉, 작성할 때 가급적이면 '이런이런 형태로 작성하자'라는 약속입니다. 공부 초기에는 컴퓨터가 이해할 수 있는 쿼리를 작성하는 것에 집중해야 하지만, 시간이 지나면 컴퓨터뿐만 아니라 다른 사람도 이해할 수 있는 형태로 쿼리를 작성하는 것이 필요합니다.
쿼리를 이해하기 쉽게 작성할 때의 장점은 커뮤니케이션 비용이 줄어든다는 점입니다. 저도 누군가의 쿼리를 갖다가 응용할 때도 있고, 누군가 제 쿼리를 갖다가 응용하는 경우가 비일비재합니다. 그런데 이 쿼리를 복잡하게 작성한다면, 이용하려는 사람은 제게 쿼리를 설명해달라 질문할 것이고 이것은 모두의 시간을 낭비하는 결과를 가져오게 됩니다. 따라서 쿼리를 모두가 이해하기 쉽게 작성해야합니다.
이를 위해 가장 좋은 것은 우선 Style Guide를 찾아보는 것입니다. Style Guide는 스타일을 통일시켜서 직관적인 코드를 짤 수 있도록 지원하기 위한 문서입니다. 예약어를 대문자로 작성하거나, subqueries를 잘 작성하는 방법 등이 대표적입니다. 해당 문서를 읽어보고, 최대한 스타일 가이드에서 언급하는 내용을 준수하면서 쿼리를 작성하다 보면 나중에는 무의식적으로도 깔끔하게 작성할 수 있을 것입니다.
또한 주석을 최대한 활용해야 합니다. 쿼 내에 설명, 문서화 또는 표시 용도로 사용되는 텍스트입니다. 주석은 SQL 코드를 읽기 쉽게 만들고 코드의 동작 및 의도를 이해하기 쉽게 돕는 중요한 요소입니다.
누군가 보지 않을 수 있는 이 쿼리에 주석을 단다는 것은 자칫 비효율적인 과정으로 보일 수 있습니다. 하지만 주석을 잘 달아놓으면, 나중에 본인에게도 도움이 됩니다. 코드 이해 및 유지 측면에서 왜 이런 형태로 쿼리를 작성했는지 등에 대해, 우리의 부족한 기억력도 함께 보완해 줄 수 있습니다. 또한 쿼리를 활용하는 다른 실무자들이 코드의 동작 및 의도를 이해하기 쉽게 만들어줍니다.
따라서 SQL 실력을 올리기 위해서는 남이 봤을 때도 이해할 수 있도록 작성해보는 것입니다. 또한 남들이 이해하기 쉽게 작성해야, 나에게 돌아오는 질문보다 피드백이 많아지고, 이것이 내 실력을 향상시키는 것이 기여할 수 있게 됩니다.
비개발 직군에서 SQL을 할 때 간과하는 부분은 바로 쿼리의 성능과 관련된 부분입니다. 여기서 말하는 쿼리의 성능은 속도와 관련된 부분입니다. 같은 결과값을 출력하더라도, 성능이 좋은 쿼리는 시스템의 성능과 응답 시간에 더 크게 기여합니다. 이런 이유에서 쿼리 성능을 최적화하고 개선시키는 것은 데이터가 많아질수록 더욱 중요한 과제입니다.
예를 들면, 가장 기본적으로는 테이블에서 필요한 칼럼만 추출해서 분석하는 방법이 있습니다. 모든 칼럼을 추출해서 가공을 진행하면, 불필요한 리소스를 낭비하기 때문에 필요한 칼럼만 추출해서 작업하는 것이 효과적입니다. 또는 특정 조건을 걸어야 하는 경우, Join을 활용하는 것이 Subquery를 활용하는 것보다 mysql에 더 최적화가 되어 있는 등 속도를 개선할 수 있는 방법은 다양합니다.
데이터의 양이 무겁지 않거나, 대시보드 등을 활용하는 조직이 적은 상태에서는 큰 문제가 되지 않습니다. 하지만 데이터를 활용하는 조직이 많아지는 경우, 저성능 쿼리를 활용하는 경우 대시보드 로딩 속도가 느려지거나 서버에 부하를 주어 502 에러를 일으키는 등 문제가 될 수 있습니다.
저도 여전히 SQL에 대한 공부를 계속해서 하고 있고, SQL을 공부하면 할수록 활용할 수 있는 기능도 다양하며 더 '좋은 쿼리'를 위해 개선해야 할 사항들도 많다는 점을 느끼고 있습니다.
처음에는 '낯선' 느낌 때문에 어려움이 있겠지만, 어떻게 하면 원하는 결과값을 출력할 수 있을지, 어떻게 작성하면 다른 사람들도 이해할 수 있을지, 어떻게 작성하면 속도가 더 매끄러워질지 고민하면서 쿼리를 작성해본다면 분명 실력이 비약적으로 향상될 것이라 생각합니다.