Showing Posts From

기획자가

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유

데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유 오늘도 데이터팀에 요청했다 "이 기능 사용자 몇 명이에요?" 개발자가 물었다. 나는 대답을 못 했다. 예상은 있다. 많지 않을 것 같다. 근데 숫자는 모른다. "데이터팀에 요청했어요." 개발자는 한숨을 쉬었다. 3일 걸린다는 걸 안다. 그 사이에 우선순위는 또 바뀐다.이게 3번째다. 이번 주에만. 매번 데이터팀 눈치를 본다. "저기... 혹시 이것도 가능할까요?" 하면서. 데이터팀도 바쁘다. 나만 바쁜 게 아니다. 그들은 대시보드 만들고, 경영진 보고서 쓰고, 데이터 파이프라인 관리한다. 내 요청은 우선순위에서 밀린다. 당연하다. 근데 문제는 그 사이에 일정이 간다는 거다. 직관은 있는데 증명이 안 된다 대표님이 물었다. "이 기능 왜 넣어야 해요?" 나는 설명했다. 유저 플로우를 그렸다. 경쟁사 사례를 보여줬다. 사용자 인터뷰 내용도 공유했다. "좋아요. 근데 데이터는요?" 말문이 막혔다. 직관적으로는 확신이 있다. 6년 동안 쌓인 감각이 있다. 이건 필요한 기능이다. 유저들이 원한다. 근데 숫자가 없다. "한 30%는 쓸 것 같은데요." "같은데요가 아니라 데이터로 보여주세요." 회의는 다음 주로 미뤄졌다. 데이터팀에 또 요청했다.집에 오면서 생각했다. 언제까지 이럴 건가. 내 직감을 증명할 방법이 필요하다. 스스로. SQL을 배우기로 했다 주말이다. 노션에 '공부' 페이지를 만들었다. "SQL 기초부터." 검색했다. 자료는 넘친다. 유튜브, 인프런, 유데미, 블로그. 문제는 뭐부터 봐야 하는지 모른다는 거다. 데이터 분석가가 되려는 게 아니다. 나는 기획자다. 필요한 건 복잡한 분석이 아니다.이 기능 사용자 몇 명? 이탈률 얼마? 어느 시간대에 많이 써? A/B 테스트 결과는?이 정도만 뽑을 수 있으면 된다.첫 주는 개념만 봤다. SELECT, FROM, WHERE. 테이블이 뭔지. 데이터베이스가 뭔지. 하나씩 따라 쳤다. Notion에 정리했다. SELECT user_id, created_at FROM users WHERE created_at > '2024-01-01'이게 돌아갔다. 짜릿했다. 개발자한테 부탁했다 "혹시 테스트 DB 접근 권한 받을 수 있을까요?" 개발자가 의외라는 표정을 지었다. "SQL 배우려고요?" "네. 매번 데이터팀 귀찮게 하기 싫어서요." 5분 만에 권한이 생겼다. DBeaver를 설치했다. 테이블 목록을 봤다. users, orders, payments, logs... 어지러웠다. 이게 뭐고 저게 뭔지. "이 테이블에 뭐가 들어있어요?" 개발자가 옆에 앉았다. 30분 동안 설명해줬다.users: 회원 정보 user_actions: 유저 행동 로그 feature_usage: 기능 사용 기록"여기서 대부분 뽑을 수 있을 거예요." 감사했다. 진심으로. 첫 쿼리를 짰다 "이번 달 신규 가입자 수" 손이 떨렸다. 근데 써봤다. SELECT COUNT(*) as new_users FROM users WHERE created_at >= '2024-11-01' AND created_at < '2024-12-01'실행. 3초. 숫자가 나왔다. 1,247명. 이걸 이제 내가 직접 뽑는다. 다음 쿼리. "이 기능 사용자 수" SELECT COUNT(DISTINCT user_id) as active_users FROM feature_usage WHERE feature_name = 'wishlist' AND used_at >= '2024-11-01'832명. 전체 DAU 대비 18%. 이 숫자가 내 손으로 나왔다. Notion에 정리했다. 쿼리를 저장했다. 다음에 또 쓸 거다. 회의가 달라졌다 다음 주 회의. 대표님이 물었다. "이 기능 얼마나 써요?" 노트북을 열었다. 쿼리를 돌렸다. 20초. "지난주 기준 일평균 1,200회 사용됩니다. 전체 사용자의 22%가 최소 1회 이상 이용했고요." 회의실이 조용해졌다. "시간대별로는 오후 2시에서 4시 사이가 피크고, 모바일이 73%입니다." 대표님이 고개를 끄덕였다. "좋아요. 이 방향으로 가시죠." 회의는 30분 만에 끝났다. 결론이 났다. 전에는 3일 기다리고, 데이터 받아서, 다시 회의 잡고, 그랬다. 이제는 즉석에서 확인한다. 개발자가 나중에 슬랙을 보냈다. "기획자님 SQL 하시는 거 멋있어요. 소통이 빨라져서 좋네요." 저장했다. 이 칭찬. 내가 자주 쓰는 쿼리 5개 Notion에 템플릿을 만들었다. "자주 쓰는 쿼리 모음" 1. 기능별 사용자 수 SELECT feature_name, COUNT(DISTINCT user_id) as users, COUNT(*) as total_uses FROM feature_usage WHERE used_at >= '2024-11-01' GROUP BY feature_name ORDER BY users DESC우선순위 정할 때 쓴다. 어떤 기능을 먼저 개선할지. 2. 일자별 트렌드 SELECT DATE(created_at) as date, COUNT(*) as count FROM user_actions WHERE action_type = 'purchase' AND created_at >= '2024-11-01' GROUP BY DATE(created_at) ORDER BY date그래프 그릴 때 쓴다. 트렌드를 본다. 3. 유저 세그먼트별 비교 SELECT u.user_tier, COUNT(DISTINCT o.user_id) as purchasers, AVG(o.amount) as avg_amount FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE o.created_at >= '2024-11-01' GROUP BY u.user_tier페르소나별 차이를 본다. VIP는 어떻게 쓰나. 일반 유저는 어떤가. 4. 퍼널 분석 SELECT COUNT(DISTINCT CASE WHEN step = 'view' THEN user_id END) as views, COUNT(DISTINCT CASE WHEN step = 'click' THEN user_id END) as clicks, COUNT(DISTINCT CASE WHEN step = 'purchase' THEN user_id END) as purchases FROM user_funnel WHERE date >= '2024-11-01'어디서 이탈하나. 어느 단계를 개선해야 하나. 5. 코호트 리텐션 WITH first_action AS ( SELECT user_id, MIN(DATE(created_at)) as first_date FROM user_actions GROUP BY user_id ) SELECT fa.first_date, COUNT(DISTINCT fa.user_id) as cohort_size, COUNT(DISTINCT CASE WHEN DATE(ua.created_at) = fa.first_date + INTERVAL 7 DAY THEN ua.user_id END) as week_1_retained FROM first_action fa LEFT JOIN user_actions ua ON fa.user_id = ua.user_id GROUP BY fa.first_date이건 좀 복잡하다. 개발자가 도와줬다. 근데 이제 이해한다. 이 5개면 웬만한 건 커버된다. 나머지는 응용이다. 틀리는 것도 배움이다 처음엔 많이 틀렸다. SELECT COUNT(user_id) FROM users WHERE signup_date > '2024-11-01'이게 왜 안 되지? 10분을 고민했다. 칼럼명이 틀렸다. signup_date가 아니라 created_at이었다. SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 5이건 왜 느리지? 3분이 걸렸다. 인덱스가 없었다. 개발자가 알려줬다. "WHERE 절에 자주 쓰는 컬럼은 인덱스가 있어야 빨라요." 배웠다. 메모했다. JOIN을 처음 썼을 때. SELECT u.name, o.amount FROM users u, orders o WHERE u.user_id = o.user_id결과가 이상했다. 중복이 너무 많다. LEFT JOIN을 써야 했다. INNER JOIN과 뭐가 다른지. 그때 알았다. 틀릴 때마다 검색했다. 스택오버플로우, 블로그, GPT. 그렇게 3개월이 지났다. 이제는 A/B 테스트도 직접 본다 마케터가 물었다. "A안이 나아요, B안이 나아요?" 전에는 데이터팀에 요청했다. 이제는 직접 본다. SELECT variant, COUNT(DISTINCT user_id) as users, COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) as conversions, ROUND(100.0 * COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) / COUNT(DISTINCT user_id), 2) as cvr FROM ab_test_results WHERE test_id = 'homepage_cta_test' GROUP BY variant결과가 나왔다.A안: CVR 3.2% B안: CVR 4.1%"B안이 27% 더 높네요." 마케터가 놀랐다. "어떻게 이렇게 빨리?" "SQL 좀 배웠어요." 30분이면 끝난다. 전에는 하루 이틀 걸렸다. 속도가 경쟁력이다. 빠르게 확인하고, 빠르게 결정하고, 빠르게 실행한다. SQL이 이걸 가능하게 했다. 여전히 데이터 분석가는 아니다 착각하면 안 된다. 나는 여전히 기획자다. 복잡한 통계 분석은 못 한다. 회귀분석, 머신러닝, 이런 건 데이터팀의 영역이다. 내가 하는 건 '기본 집계'다.COUNT: 몇 개 SUM: 합계 AVG: 평균 GROUP BY: 그룹별로 JOIN: 테이블 연결이 정도만 쓴다. 근데 이게 내 일의 80%를 커버한다. 나머지 20%는 여전히 데이터팀에 요청한다. 그들의 전문성이 필요한 부분. 근데 그 20%를 요청할 때도 달라졌다. "이 두 테이블을 조인해서 이런 결과를 보고 싶은데, 제 쿼리가 맞나요?" 데이터 분석가가 말했다. "거의 맞는데 여기만 수정하면 돼요." 소통이 빨라졌다. 같은 언어를 쓴다. 기획자에게 SQL이 필요한 이유 정리해봤다. 내 경험 기준으로. 1. 속도 데이터팀 요청 → 대기 → 결과 받기: 2-3일 직접 쿼리: 5분 의사결정 속도가 10배 빨라진다. 2. 자율성 "이것도 가능할까요?" 하면서 눈치 볼 필요 없다. 궁금하면 바로 확인한다. 밤 11시에도. 3. 정확성 내가 원하는 게 뭔지 정확히 안다. 설명할 필요가 없다. "아 그게 아니라 이걸로 봐주세요" 하는 왕복이 사라진다. 4. 신뢰도 "데이터 기반으로 얘기하네" 하는 인식이 생긴다. 회의에서 발언권이 달라진다. 숫자로 말하니까. 5. 성장 데이터를 보는 눈이 생긴다. 어떤 지표가 중요한지. 어떻게 측정할지. 기획 실력이 올라간다. 당연히. 시작하는 법 주변 기획자들이 묻는다. "어떻게 시작했어요?" 내 방법은 이랬다. 1주차: 기본 개념SELECT, FROM, WHERE 유튜브 '생활코딩 SQL' 시리즈 하루 30분씩2주차: 실습 환경개발자한테 테스트 DB 권한 요청 DBeaver 또는 TablePlus 설치 우리 회사 테이블 구조 파악3-4주차: 기본 쿼리COUNT, SUM, AVG GROUP BY, ORDER BY 회사 데이터로 직접 실습2개월차: JOININNER JOIN, LEFT JOIN 테이블 두 개 연결하기 실무에서 자주 쓰는 패턴 익히기3개월차: 응용서브쿼리 CASE WHEN 날짜 함수여기까지면 충분하다. 나머지는 필요할 때 찾아보면 된다. 추천 자료 내가 실제로 도움받은 것들. 온라인 강의인프런 '모두를 위한 SQL' (입문) 유데미 'SQL for Data Analysis' (실무)책'모두의 SQL' (길벗, 입문자용) 'SQL 첫걸음' (한빛미디어)도구DBeaver (무료, 추천) TablePlus (유료지만 이쁨) SQL Fiddle (온라인 연습)커뮤니티생활코딩 SQL 오픈채팅방 데이터 분석 스터디 모임혼자 하면 힘들다. 같이 하는 사람을 찾아라. 3개월 후 오늘 주간회의. 대표님이 물었다. "이번 분기 KPI 진행률은?" 노트북을 열었다. 저장해둔 쿼리를 실행했다. "가입자 목표 대비 87%, 매출은 92% 달성 중입니다. 예상대로면 이번 주 목요일에 100% 도달합니다." 5초 만에 대답했다. 대표님이 웃었다. "준비성이 좋으시네요." 준비한 게 아니다. 매일 보고 있다. SQL로. 퇴근길에 생각했다. SQL을 배우기 전과 후. 전에는 데이터가 '누군가 주는 것'이었다. 이제는 '내가 뽑는 것'이다. 이 차이가 크다.데이터로 증명할 수 있다는 건, 내 의견이 아니라 사실로 말할 수 있다는 것이다. SQL은 그 도구다.