SQL 처음 배우는 PM이라면
좋은 질문을 위한 소프트스킬이 더 중요할지도
01. 학생 때 책으로 시작한 SQL
PM에게 필요한 대부분의 역량은 소프트 스킬이라고 감히 생각하지만, 정말 유용한 하드 스킬이 있다면 그건 SQL인 것 같습니다. 저는 SQL을 대학생 때 처음으로 접했습니다. 당시에는 PM이라는 직군을 몰랐기 때문에 채용 공고에서 우대 역량을 살펴본다든지 하는 전략적 접근은 아니었습니다. 전공 강의로 파이썬을 배우면서 데이터 분석 과제를 수행하는데, '분석의 대상이 되는 데이터는 어디에서 어떻게 갖고 오는 걸까?'가 문득 궁금했습니다. 과제할 때야 교수님이 데이터셋을 제공해주시지만, 실제로 활용하려면 그 많은 데이터 속에서 내게 필요한 것만 가져와야 하는데 그건 어떻게 해야 하는 건지가 궁금해 이리저리 구글링을 하다가 SQL을 알게 되었습니다.
데이터가 어떻게 저장되었느냐에 따라 데이터를 뽑는 방법은 다르지만, row와 column으로 구성된 일종의 표 형태로 저장된 데이터를 추출하는 언어가 SQL (Structured Query Language)입니다. 예시 데이터가 엑셀 데이터와 비슷해보여 익숙함을 느끼고 일단 "모두의 SQL" 책을 구입해서 기본 개념부터 훑었습니다.
02. 회사에서 우당탕탕 SQL 익히기
그리고 한동안(...) SQL을 잊고 있다가, 휴학 시기에 데이터 추출/분석 계약직 자리에 지원하게 되면서 SQL 책을 다시 펼쳐 보았습니다. 면접 당시에는 select, from, where의 3단 구조 정도만 알았고, 문제 풀이 중 '틀렸다'는 걸 이미 직감한 문제가 절반 이상이었습니다. 저의 다른 점을 긍정적으로 기대해주신 덕분에 합류 기회를 얻을 수 있었고, 본격적으로 SQL을 사용해본 건 사실 입사 직후부터라고 말할 수 있습니다.
입사 전에 SQL을 이렇게나 잘 몰랐다-는 것을 설명하는 이유는, 결국 '이론보다 실제 데이터로 여러 번 실습해보는 것이 학습의 정도'라는 걸 깨달았던 경험에 대해 소개하고 싶기 때문입니다. 입사 후 첫 주에, sql로 원하는 데이터를 뽑아 tableau를 활용해 시각화 대시보드를 제작하는 과제가 주어졌는데요. 슬랙과 위키 문서를 뒤지며 테이블 명세서, 반복 사용되는 마스터 쿼리, 사내 데이터 특강 PDF 자료 등을 찾아 읽으며 겨우겨우 완성했던 기억이 있습니다. (+돌보미 선배님의 넓은 아량과 따뜻한 멘토링의 몫이 9할)
이렇게 무언가를 급하게(?), 순서 없이 배운 적은 처음이라 당시에는 '나중에 제대로 처음부터 끝까지 배워야겠다' 생각했습니다. 하지만 그 후에도 업무에서 sql을 정말 많이 활용했지만, 처음부터 끝까지의 이론을 순서대로 배울 일은 없었습니다. 제가 잘해서가 아니라 그럴 필요를 못 느끼고 있기 때문입니다. 업무 범위에 따라 당연히 다르겠지만, PM으로서 저는 이미 있는 테이블에서 사업/제품 전략 수립상 필요한 데이터만 뽑아서 보기 때문에 SQL 개론서에 나왔던 CRUD를 실무에서 접할 일은 한번도 없었습니다.
알아야 할 것도 많고, 유용한 기술도 많은 이 세상에서 무언가를 배워야 한다면- '처음부터' 배우려는 생각보다는 일단 사용해보면서 필요한 것 위주로 채우는 방식을 택해야겠다는 제 나름의 깨달음을 얻었던 순간입니다.
이번 글에서는 '우당탕탕' sql을 배우면서 '아 이런 건 더 필요하겠구나' 싶어서 스스로 채웠던 부분들을 기록하려고 합니다. 소프트스킬과 하드스킬로 나누어보았습니다.
03. Soft Skill - 좋은 질문의 토대 만들기
(1) 쿼리 작성하기 전에 테이블부터 익히기
내가 원하는 정보만 뽑아내기 위해 쿼리를 작성하는 것이기 때문에 우선 내가 가진 정보가 어떻게 생긴 녀석인지부터 파악해야 합니다. 가장 좋은 것은 사내에 테이블 명세서가 있어서 어떤 테이블이 어떤 컬럼을 갖고 있고, 다른 테이블과 join key로 사용되는 것은 어떤 컬럼인지 한눈에 파악할 수 있는 것이겠지만- 모든 팀이 명세서를 갖고 있는 것은 아닙니다. 명세서가 없더라도 테이블, 컬럼명으로 직관적인 이해가 가능한 것이 차선이겠지만 이마저도 쉽지 않은 경우가 종종 있습니다. users 테이블에 고객 정보가, orders 테이블에 주문 정보가 있을 것이라는 건 비교적 쉽게 예측할 수 있지만 enrolleds 라는 이름의 테이블이 있다면 어떤 것에 대한 등록 데이터인지 맥락 파악부터 필요하겠지요!
1) 어떤 테이블이 자주 사용되는지 동료에게 여쭤보고
2) 추린 테이블명을 사내 소통 채널(ex. 슬랙)에 검색해서 해당 테이블이 사용된 쿼리가 있다면 살펴보고
3) 쿼리에 작성된 주석이 있다면 그 설명을 중심으로 컬럼을 이해하고
4) 궁금한 컬럼만 select 하거나 desc 함수로 테이블 정보 요약만 뽑아서 보고
5) 주요 테이블의 구조를 이해했다면 테이블 명세서를 작성해보고
6) 동료에게 정합성 크로스 체크를 부탁해 내가 작성한 테이블 명세서를 동료들에게 공유
이것이 제가 경험했던 테이블 이해 절차 중 가장 잘 굴러간(?) 사례였던 것 같습니다. 제 경우에는 쿼리 함수 공부 3일 하는 것보다 테이블 정보 3시간 익히는 게 신속한 쿼리 작성에 훨-씬 큰 도움이 되었습니다. 테이블이 어떤 정보를 기준으로 분리되어 있는지 이해함에 따라 사내에서 어떤 데이터가 중요하게 다뤄지는지도 이해할 수 있었고요.
(2) where 조건 또는 limit 활용하기
저는 데이터 타입과 값을 이해하기 위해 일단 select로 뽑아보면서 테이블을 이해하는 경우가 잦았는데요. 이 때 저의 쿼리 요청이 너무 잦고 요청 범위가 너무 넓으면 분석 속도 저해에 영향을 줄 수 있습니다. '언제 결과 나오는 거야?'라며 한참 기다려야 할 수 있고, 동시에 해당 분석 DB에 접근한 다른 동료들의 업무 속도에도 의도치 않은 불편을 끼쳐드릴 수 있었습니다. 모든 데이터를 보려는 것이 아니라 데이터의 생김새만 보려는 것이라면 where과 limit을 적극 활용하는 편이 좋았던 것 같습니다.
경험상 대부분의 테이블에 해당 row의 적재 시점인 created_at 컬럼이 있었는데, where 뒤에 created_at >= {최근 2일 정도의 날짜(ex. '2024-02-03')} 를 붙여 최근 데이터만 불러오도록 요청해 쿼리의 부하를 경감시키곤 했습니다. 쿼리 마지막절에 limit 10 (결과 중 10개만 들고와라) 과 같이 결과값을 자르는 조건을 추가하는 것도 방법이었습니다.
(3) 들여쓰기
쿼리를 작성한 다음 정합성 피드백 요청을 위해 동료들에게 쿼리를 공유하는 경우도 잦을텐데요. 설명하는 나의 시간을 아끼기 위해, 기꺼이 나를 도와주는 동료의 쿼리 이해 시간을 아끼기 위해- 들여쓰기에 신경쓰는 것을 추천드리고 싶습니다. select, from, where 기준으로만 들여쓰기를 해도 쿼리의 가독성이 훨씬 높아집니다.
(4) 주석으로 쿼리 의도 설명하기
'들여쓰기'가 필요한 맥락과 동일한데요, 쿼리에 오류가 있다면 그건 본인이 직접 쿼리를 실행했을 때 이미 execute가 정상적으로 되지 않았을 것입니다. 그래서 동료들에게 피드백을 요청하는 부분은 '이 쿼리에 함수상 오류는 없는지' 가 아니라 '내가 원하는 데이터를 뽑을 수 있는 쿼리가 맞는지' 즉 의도에 부합한 쿼리인지-와 관련된 부분입니다. 그래서 내 의도를 설명하는 것이 필요합니다. 가급적 row 별로 어떤 의도인지를 작성해두면 단순 피드백 요청 뿐만 아니라 추후에 제 쿼리를 다시 보게 될 때 스스로에게도 큰 도움이 되었습니다. (예를 들어, 쿼리 재활용이 필요할 때요!)
"--" 뒤에 쿼리별 설명을 주석으로 덧붙입니다(5) 마스터 쿼리 보호 (fork 활용하기)
위에 작성한 모든 절차의 기반이 되는 것은, 동료들이 이미 작성해두었던 쿼리인 경우가 많았습니다. 감사한 마음으로 참고는 하되, 남의 것은 절대(!) 탐내면 안되겠지요. 동료가 작성한 쿼리를 바로 수정하거나 변경해 저장하는 일이 없도록 하는 것이 중요합니다. 잘 모르는 상태에서 건드렸다가 쿼리 오류가 날 수도 있고요. 또 마스터 쿼리로 공개되어 있는 것들은 반복 실행해 대시보드에 연결되어 있는 경우가 많아 정합성과 무결성이 매우 중요하기 때문입니다. 이런 경우에는 (redash의 경우) '포크 떠서 가져가주세요'라는 이야기를 많이 듣는데요, 우측 상단 fork 버튼을 눌러 쿼리 복제본을 만들고 그 복제본을 자유롭게 수정하면 됩니다. 또는 쿼리 자체를 복붙하는 것도 방법일 것 같습니다.
Frok 떠서 가져가주세요!
04. Hard Skill - 연습하기
그 외의 것은 진부한 말이지만 연습 밖에 없었던 것 같습니다. 저는 퇴근 시간을 활용해 아래 두 개의 방법을 통해 쿼리 작성을 연습했습니다.
(1) HackerRank SQL 예제 풀기
문제은행 같은 사이트인데요. 따로 프로그램을 설치하지 않아도 되고 회원가입만 하면 무료로 사용할 수 있다는 것이 장점입니다. 난이도별로 문제를 선택할 수 있다는 점이 편리하지만 고난이도 문제는 많지 않기 때문에 SQL 학습 초반에 반복 연습을 하는 데에 추천하고 싶은 사이트입니다.
(2) 책 한 권 사서 함수 사전처럼 활용하기
이 책은 개발자 입문용 도서이기 때문에 테이블 생성 및 삭제에 관련된 내용들도 나오는 터라- 모든 내용이 참고 대상은 아니었지만 '뭐를 어떻게 검색해봐야 할지도 모르겠는' 무지 상태에서는 큰 도움이 되었던 책입니다. 꼭 이 책이 아니더라도 사전처럼 갖고 있을 책이 한 권 정도 있으면 든든한 마음이 드실 것 같습니다.
05. 고마운 도구 SQL
사실 'SQL을 쓸 줄 안다'라고 말하기엔 민망할 정도로 Read 에 국한된 부분만 사용할 수 있는데요. 업무에 실제로 필요한 것을 중심으로 배웠기 때문에 '배워두니 참 좋다'라는 소감이 절로 드는 데에는 충분한 것 같습니다. (파이썬이나 R은 아직 그 장점을 충분히 체감하지는 못했습니다.) 그만큼, 조금이라도 배워두면 현상 파악에 필요한 데이터를 빠르게 / 내가 궁금한 관점 중심으로 피봇팅해가며 볼 수 있다는 장점이 체감되는 도구입니다. 그래서 저 스스로도 더 배우고 싶고, 주변에 SQL을 처음 배우고 싶어하는 분들이 계시면 도움이 되는 선에서 제 경험을 나누고 싶어 이번 글을 기록해봅니다 :-)
