자격증 취득을 위한 SQL은 이제 그만.
“이력서 한 줄 추가하기 위해 백 날 자격증 공부하는 것보다 짧은 데이터 한 번이라도 뽑아보는 게 백배 낫다.”
– 신원 미상
|
A기업 면접관: SQL을 사용해본 경험 있으신가요? 면접자 B씨: 네..? 그게 뭐죠? … |
|
A기업 면접관: 오, SQLD 자격증이 있으시네요? SQL 사용해보셨어요? 면접자 C씨: SQLD 자격증만 취득했습니다! A기업 면접관: 자격증 말고, MySQL이나 PostgreSQL을 직접 업무에서 써본 적은 없어요? 면접자 C씨: 어..써 볼 기회가 없어서… … |
서비스 기획자, 혹은 프로덕트 매니저 면접 경험이 있는 사람들이라면 이런 질문을 한 번쯤 받아봤을 것이다.
PM/기획자는 참 피곤하다. 피그마, 지라, 슬랙, 구글 애널리틱스, 앰플리튜드 등 디자인 커뮤니케이션 툴, 협업 툴, 데이터 어트리뷰션 툴에 이어 이제 DB에서 필요한 데이터도 추출할 줄 알아야 한다니, 피곤하다 피곤해. 끝도 없이 새로운 지식, 도구를 학습해야 한다는 건 PM/기획자의 숙명과도 같다.
SQL 써봤다는 기획자를 보기 어려운 이유
대체 PM, 기획자는 실무에서 SQL을 어떻게 사용한다는 걸까? 브런치, 티스토리, 기획 커뮤니티 등 동종 업계 블로그를 죄다 뒤져봤지만, 실무에서 SQL을 이렇게 활용하고 있다는 아티클은 거의 찾아볼 수가 없었다. SQLD 시험기간 때만 바짝 SQL TIL(Today I Learned) 콘텐츠만 양산되고 있을 뿐이었다.
그 이유는 간단하다. 현업에서 SQL을 써볼 기회가 없다는 것이다. 잘못 쿼리를 돌렸다가 불필요한 스키마를 생성하거나 최악의 경우 DB를 날리게 될 수도 있다. (DROP DATABASE 한번 쳐보시길,, 데이터 사이언티스트가 좋아서 춤추는 광경을 볼 수 있을 것이다.) 그래서 DBA가 PM/기획자에게 쿼리 조회 권한을 주지 않는 것이다. 보통 데이터 사이언티스트나 DBA에게 요청하면, 필요한 데이터만 정제해서 추출해준다.
정말 SQL을 실무에서 써보고 싶지만, 안타깝게도 대부분의 회사가 PM이나 기획자에게 쿼리 조회 권한을 주지는 않는다. 가끔 카피본을 주는 경우가 있긴 하지만, 그마저도 매우 희소한 경우라 사용해 볼 기회가 거의 없다. 게다가 카피본은 현행화가 되지 않기 때문에 정확한 데이터라고 보기 어렵다.
목적 없이 무작정 배우지 말자
나 역시 그랬다. Data-driven한 의사결정을 내리는 프로페셔널한 기획자가 되려면 SQL는 마치 전공 필수처럼 느껴졌다. 그래서 이 SQL이란 것을 어떻게 쓸지도 모른 채 무작정 인강을 결제하고, SQLD 자격증에 도전했다. 있으면 나쁠 게 없다고 생각했으니까. (마치 GAIQ는 취득했지만, 제대로 된 퍼널 세팅도 못하는 그것과 같다.)
기술을 목적 없이 배우는 것만큼 시간 낭비도 없다. 내가 이걸 왜 배우는지, 이걸 어떻게 써먹을 수 있을지 정도는 생각해두어야 한다는 말이다. ‘데이터 사이언티스트에게 두 번 일 시키는 것보다 제가 직접 하는 게 더 생산적이잖아요!’라고 말할 수도 있다. 그러나, 수년을 쿼리만 날려온 사람과 겨우 기본 쿼리문 몇 개 뗀 우리 중에 누가 더 빠르고 정확하게 원하는 결과를 얻을 수 있을까?
일거리를 덜어주겠다는 목적으로, 개발자 Dependency를 줄이겠다는 목적으로 SQL을 배우는 게 오히려 독이 될 수도 있다. 모든 걸 다 해버리겠다는 전문가 의식보다 그만큼 내부 데이터에 대한 이해도와 관심을 가지고 있다는 것만으로 충분하다고 생각한다. 내가 개발자여도 당연히 데이터 아키텍처에 기본 지식과 관심이 있는 기획자를 더 선호할 테니까.
그럼에도 기업은 SQL을 다룰 줄 아는 인재를 원한다
SQLD 자격증을 꼭 취득할 필요는 없다. 그러나, 상당 수의 기업들이 SQLD 자격증이 있거나, SQL을 다룰 줄 아는 기획자를 선호하는 것은 사실이다. 참 곤란하다. 지금 회사에서 SQL 조회 권한은 안 주는데 SQL을 쓸 줄 알아야 한다니, 그럼 어떻게 실무 중심의 SQL 능력을 배양할 수 있을까?
데이터 아키텍처를 보는 눈부터 키우자
SQL을 배움으로써 가장 큰 장점은 데이터 아키텍처에 대한 이해도를 높이는 데 미약하게라도 도움이 된다는 점이다. 대부분 SQL 구문을 외우는데 집중하느라 ERD(Entity Relationship Diagram)의 중요성을 간과하고 있었을 것이다. ‘아 이건 IE 표기법, 저건 Baker 표기법이지.’, ‘이 테이블과 저 테이블은 식별자 관계구나’ 정도만 기억나도 다행일 거다.
필자는 운 좋게도 직장에서 좋은 개발자(?)를 만나 이것저것을 어깨너머로 배울 수 있었다. 개중 가장 큰 도움이 되었던 경험은 ERD를 해독하며, 서비스의 DB 구조를 이해하는 능력을 키울 수 있었다는 것이다. 최근에 콘텐츠를 공유하면 시퀀스를 발행해 공유자에게 보상을 주는 프로젝트를 하나 진행했는데, 그때 개발자와 함께 ERD를 펼쳐보며 같이 필요한 스키마들이 적절히 배치되고 연결되어 있는지 검토했었다.
쿼리를 날리는 것보다 더 중요한 것은 데이터가 어떻게 흐르는지, 어떻게 보관되고 서로 어떤 영향을 주는지 이해하는 것이다. ERD를 해독하는 능력을 키우는 것을 선행하기를 바란다. 특히 식별, 비식별 관계나 기본키, 외래키 같은 개념은 기본 상식으로 알고 있어야 한다.
SELECT, FROM, (ORDER BY) 이외에는 거의 안 쓴다
SQL 구문을 배울 때로 돌아가 보자. 그룹함수, 조인, 서브쿼리 등 어려운 SQL 구문을 머리 싸매가며 외웠던 기억이 난다. 그때만 해도 ‘나도 곧 실무에서 화려하고 복잡한 쿼리문을 날리게 되겠지?’ 라며 부푼 기대를 갖고 있었다.
그러나, 애석하게도 실무에서 그렇게 복잡한 쿼리를 날리는 일은 거의 없다. 그룹함수니 조인이니 서브쿼리니 하는 것들은 제대로 쓸 줄 모른다면 안 쓰는 것만 못하다. 괜히 이게 맞나 저게 맞나 기억을 더듬으며 수 십 번의 Syntax Error만 마주하게 된다면, 시간만 낭비하게 되는 꼴이다.
필자는 해외의 온라인 기술능력 평가기관인 HackerRank에서 SQL Basic, Intermediate 등급을 받았고, 현업에서도 가볍게 SQL을 써본 경험이 있다. 그러나, SELECT, FROM, ORDER BY 외에 더 어려운 쿼리문을 날릴 일은 거의 없었다. 전체 데이터에서 내가 필요한 데이터만 뽑아서 쓸 수 있을 정도면 충분하다.
예컨대, 자사 서비스에 결제 이력이 있는 회원 중에서 특정 결제 수단을 이용했고, 결제금액이 50만 원 이상인 회원만 결제금액별로 내림차순으로 추출한다고 가정해보자.
| SELECT CUSTNO, CUSTID … FROM USER U, PAYMENT P WHERE U.CUSTID = P.CUSTID, P.TERMS = ‘CARD’, P.ACCOUNT >= 500000 ORDER BY P.ACCOUNT DESC; |
이런 식으로 조회할 수 있을 것이다. 이 구문에서는 조인까지 포함되어 있지만, 사실 하나의 테이블에서 조회가 끝나는 케이스가 대부분이다. (엑셀로 대체할 수 있지만, 큰 서비스들은 data row가 워낙 많으니..)
면접관으로 참석하는 실무자들이 바라는 것은 SQL 전문가 수준의 DB 가공, 정제 능력이 아닐 것이다. DB에서 내가 원하는 데이터를 추출할 수 있는지(그마저도 여러 스키마에 걸쳐 있다면 Data scientist에게 요청하자), 그리고 데이터 아키텍처에 대해 이해도와 관심이 있는지 정도를 확인하기 위함이라고 필자는 생각한다.
SQLD 자격증을 취득하는 건 좋다. 그러나, 이 자격증이 없으면 좋은 회사에 못 갈 것이라는 노파심 때문에 도전하지는 말기를 바란다. SQL도 결국 도구일 뿐이니 목적 달성을 위한 정도로만 사용법을 익히면 충분하다. 피그마 마스터가 되기 위해서 피그마를 공부하지는 않지 않은가?
만약 SQL을 제대로 공부하고 싶다면
– 모든 공부는 Youtube가 출발선이다. 백그라운드로 감부터 잡고 아니다 싶으면 털어버리자.
– SQLD 자격증은 필수가 아니다. 그래도 DB에 대한 전반적인 이해도는 높일 수 있다.
– 괜히 무거운 SQL Workbench 깔지 말고 Oracle APEX에서 연습해보자.
– HackerRank에서 SQL Basic > Intermediate > Advanced 순으로 도전해보자.
채드윅 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
