by
Jun 18. 2022
PM으로서 SQL에 익숙해지고 좋은 점
분석가는 아니지만 분석가가 없다면
전제 : 조직에 데이터가 흐르고 있을 것. DB 테이블에 대해 정리된, 비개발자가 이해할 수 있는 문서가 준비되어 있고 이에 대해 조회 권한이 있을 것.
1. 데이터로 고객에 대해 알 수 있는 건 절반 정도다. ('왜'를 모르니까.) 그런데 흔히 아는 GA, Amplitude 등으로 알 수 있는 건 다시 그중 절반이다. 나머지 절반은 DB에 있다. SQL에 익숙해지면 실은 서버 접근성이 생기는 게 아니라 고객에 대한 접근성이 증가한다.
2. 물론 쿼리는 엔지니어분들이 가장 잘 안다. 그런데 엔지니어분들은 주로 정합성, 성능에 대해 안다. '그래서 내 가설은 구체적으로 어떤 지표로, 어떤 조건으로 검증해야 하는지'는 가설을 세운 본인 몫이다. 본인 몫을 좀 더 제대로 하는 데 도움이 된다.
3. 아무리 가설이 이론상 명확해도 막상 까 보면(?) 수정이 필요하다. 가설이니까. 그래서 결국 가설과 현황 사이에 티키타카, 수정이 발생한다. 이걸 누군가에게 요청하면 매 순간이 딜레이다. 디자인이나 개발은 내가 할 수 없거나 내가 해도 느리지만, 분석은 내가 할 수 있고 내가 하는 게 제일 빠를 수 있다. SQL에 익숙해지면 기획이 빨라진다.
4. 소위 짜치는(...) 일일 수 있고 이례적일 수도 있지만 구글 옵티마이즈와 같은 툴로는 A/B 테스트 할 수 없을 걸로 생각된 가설/실험도 DB의 데이터라면 검증할 수 있다. SQL에 익숙해지면 PM은 번거롭지만 팀이 덜 번거로운 방안도 떠올릴 수 있다.
5. DB에서 정보를 불러오는 게 필요한 기획을 할 때에도 '~~ 한 콘텐츠를 가져오고/불러오고 싶은데 검토 부탁드려요'로 요청하면 엔지니어분이 제로베이스에서 고민, 검토한다. 그러다가 '아차 조건이 그거면 안 될 거 같아요' 라며 수정이 몇 차례 생긴다.
대신 기획/실험이 작동하기 위해 필요한 조건에 맞게 쿼리를 직접 짠 뒤에 검토 요청을 하면 정합성, 성능 체크면 된다. 역시나 팀이 덜 번거로운 방안을 떠올릴 수 있다.
PM이 뭔가를 안다고 문제를 100% 제대로 정의하거나 해결할 수 있는 건 아니지만, 문제를 정의하거나 해결하려고 할 때에 뭔가를 알고 있는 건 확실히 도움은 되는 듯하다. 제너럴리스트라는 건 이런 건가 싶다.
