서비스 기획자가 알아야 할 최소한의 SQL

 

기획자가 SQL을 알아야 하냐는 질문을 종종 받는데, 저는 "몰라도 일은 되지만, 알면 일이 훨씬 빨라진다"고 답합니다.
저도 입사 초반엔 궁금한 숫자가 있으면 매번 데이터 분석팀에 요청을 넣고 며칠씩 기다렸어요.
급하지도 않은 질문 같아서 요청하기 눈치 보였던 적도 많았습니다.
SQL을 배우고 나서부터는 이런 자잘한 질문의 90% 이상을 제가 직접 확인할 수 있게 됐고, 이게 업무 속도에 생각보다 큰 차이를 만들었습니다.

 

기획자가 SQL을 직접 배워야 하는 가장 큰 이유는, 궁금한 걸 궁금한 시점에 바로 확인할 수 있다는 것입니다.
회의 중에 "이 기능 쓰는 사용자가 몇 명이나 될까요?"라는 질문이 나왔을 때, "확인해서 다시 알려드릴게요"와 "잠시만요, 지금 바로 조회해볼게요"는 회의의 흐름을 완전히 다르게 만들어요.
또 하나는, 데이터 분석팀에 요청할 때도 SQL을 조금이라도 알면 요청 자체가 훨씬 구체적이고 빨라집니다.
"이런 데이터가 필요해요"가 아니라 "이 테이블에서 이 조건으로 뽑아주시면 될 것 같아요"라고 말할 수 있으니까요.

 

거창하게 SQL 자격증을 딸 필요는 없습니다.
저는 SELECT로 원하는 컬럼을 골라내고, WHERE로 조건을 걸고, GROUP BY로 묶어서 집계하는 것, 이 세 가지만 익숙해져도 업무의 상당 부분을 해결할 수 있다고 생각해요.
예를 들어 "지난달 가입자 중 결제까지 이어진 비율"을 확인하려면, 가입 로그 테이블에서 지난달 조건으로 WHERE를 걸고, 결제 여부로 GROUP BY 해서 비율을 계산하는 정도면 충분합니다.
저는 이 세 가지를 익히는 데 주말 이틀 정도 온라인 강의를 들으면서 실제 데이터로 연습했는데, 생각보다 진입 장벽이 낮았어요.

 

문제는 여러 테이블을 엮어야 하는 JOIN부터입니다.
저도 여기서 한동안 막혀서, JOIN이 필요한 질문은 그냥 개발팀에 부탁하곤 했어요.
그런데 팀 개발자 한 명이 "저희 서비스 테이블 구조는 사실 크게 세 그룹으로 나뉜다"면서 사용자 테이블, 상품 테이블, 주문 테이블이 어떻게 연결되는지 그림으로 그려준 적이 있는데, 그걸 보고 나서야 JOIN이 갑자기 이해가 됐습니다.
결국 JOIN을 배우는 데 필요한 건 문법이 아니라, 우리 서비스의 테이블 구조를 아는 것이었어요.
저는 이후로 신규 입사자에게도 SQL 문법보다 먼저 우리 서비스의 핵심 테이블 관계도를 보여주는 걸 추천합니다.

 

제가 실무에서 가장 자주 쓰는 패턴은 크게 세 가지입니다.
첫째는 특정 기간 동안의 사용자 행동을 집계하는 쿼리, 둘째는 특정 조건을 만족하는 사용자 목록을 뽑는 쿼리, 셋째는 두 지표의 비율을 계산하는 쿼리예요.
이 세 가지 패턴을 각각 템플릿처럼 만들어두고, 날짜나 조건만 바꿔서 재사용하니까 매번 새로 쿼리를 짜는 시간이 크게 줄었습니다.
저는 자주 쓰는 쿼리는 아예 개인 노트에 "이런 질문이 나오면 이 쿼리를 쓴다"는 식으로 정리해뒀는데, 이게 은근히 유용한 자산이 되더라고요.

 

SQL을 배우고 나서 가장 크게 바뀐 건, 회의에서 주장을 할 때 근거를 대는 방식이었습니다.
예전엔 "제 생각엔 이럴 것 같아요"로 시작했던 말이, 지금은 "제가 어제 확인해보니 이런 숫자가 나왔는데요"로 시작하게 됐어요.
같은 주장이라도 이렇게 시작하면 회의 분위기가 완전히 달라집니다.
물론 SQL을 안다고 모든 판단이 정확해지는 건 아니지만, 적어도 감으로만 얘기하는 습관은 확실히 줄었습니다.

기획자가 개발자만큼 SQL을 잘 짤 필요는 없다고 생각합니다.

다만 궁금한 걸 스스로 확인할 수 있는 최소한의 도구로써 SQL을 갖고 있으면, 의사결정의 속도와 근거의 품질이 확실히 달라져요.
저도 아직 복잡한 서브쿼리나 윈도우 함수는 낯설지만, 이 정도는 필요할 때마다 조금씩 더 배워나가려고 합니다.
다음엔 제가 자주 쓰는 쿼리 템플릿들을 좀 더 구체적으로 정리해서 공유해볼까 싶어요.