PM을 위한 SQL: 데이터 분석, 왜 직접 해야 할까?

솔직히 말해볼까? PM으로서 당신은 개발자가 아니잖아. 나도 마찬가지야. 디자이너로 시작해서 6년차 PM이 된 나는, 코드를 한 줄도 짜지 않았어. 하지만 지금, 나는 매일 SQL 쿼리를 날리고 데이터 분석 결과를 바탕으로 의사결정을 내린다. AI 스타트업에서 제품을 만들면서, 이게 얼마나 강력한 무기가 되는지 뼈저리게 느꼈지.

왜냐고? 간단해. 데이터는 곧 진실이고, 그 진실을 직접 마주하는 PM은 누구보다 빠르게, 그리고 정확하게 제품을 성장시킬 수 있기 때문이야.

데이터, 왜 남에게만 맡겨야 해? (PM의 불안감 해부)

처음에는 나도 그랬어. 'SQL? 그건 개발자 형님들의 영역이지.' 데이터 분석팀에 요청하고, 기다리고, 피드백을 주고받는 과정. 때로는 내가 원하는 정보가 아니거나, 너무 늦게 도착해서 이미 타이밍을 놓쳐버린 경험, 다들 한 번쯤 있지 않아?

이런 상황은 몇 가지 문제를 야기해.

• 의사결정 지연: 데이터가 도착하기까지 기다리는 동안, 시장은 변하고 경쟁자는 앞서나간다.
• 정보의 왜곡: 내가 질문한 의도와 다르게 데이터가 가공되어 전달될 수 있다.
• 직관의 상실: 데이터를 '보여주는' 것과 데이터를 '이해하고 느끼는' 것은 완전히 다르다.

나는 이런 답답함과 불안감 속에서 '내가 직접 데이터를 볼 수 있다면?'이라는 생각을 떨칠 수 없었어. 특히 AI 스타트업에서는 데이터가 곧 서비스의 핵심인데, 이걸 남에게만 의존하는 건 마치 눈을 가리고 운전하는 것과 같았지.

디자이너 출신 PM, SQL과 사랑에 빠지다 (나의 여정)

나의 SQL 여정은 사실 '고통'에서 시작됐어. 끊임없이 발생하는 고객 문의, 예상치 못한 버그, 그리고 '이 기능, 사용자 반응은 어떨까?' 하는 끝없는 질문들. 이 모든 답을 얻기 위해선 결국 데이터를 봐야 했지.

"PM님, 어떤 데이터가 필요하신가요?" 데이터 분석팀의 질문에 명확하게 답하지 못할 때마다 자괴감이 들었어. 그래서 결심했지. 최소한 내가 원하는 질문에 대한 답을 스스로 찾을 수 있는 수준까지는 SQL을 배우겠다고.

처음에는 막막했어. 복잡한 문법, 낯선 용어들. 하지만 나는 디자이너 출신답게 '시각화'와 '직관'을 중요하게 생각했어. SQL도 마찬가지였지. '이 쿼리가 어떤 그림을 그려낼까?'를 상상하며 접근했더니, 조금씩 재미를 붙일 수 있었어.

나의 첫 SQL 쿼리: "가장 많이 클릭된 버튼은?"

가장 처음 날린 쿼리는 아마 이런 거였을 거야. "우리 서비스에서 가장 많이 클릭된 버튼은 뭐지?" 생각보다 간단했어. SELECT button_name, COUNT(*) FROM clicks GROUP BY button_name ORDER BY COUNT(*) DESC LIMIT 1; 이런 식이었지. (물론 실제로는 더 복잡했지만, 핵심은 이거야.)

이 작은 성공이 엄청난 동기 부여가 됐어. 내가 직접 던진 질문에 대한 답을 단 몇 초 만에 얻는다는 것. 이건 정말 짜릿한 경험이었지.

PM에게 SQL 기초가 필요한 이유 (실전 활용법)

자, 그럼 PM에게 도대체 어떤 SQL 기초가 필요할까? 모든 것을 알 필요는 없어. 핵심적인 몇 가지만 제대로 알아도 판도가 달라져.

1. 데이터 탐색: "우리 사용자는 누구인가?"

• SELECT: 원하는 데이터를 가져오는 가장 기본적인 명령어. SELECT * FROM users WHERE signup_date BETWEEN '2023-01-01' AND '2023-12-31'; 처럼 특정 기간 가입자를 볼 수 있지.
• WHERE: 조건을 걸어 데이터를 필터링. "서울에 사는 20대 여성 사용자만 보고 싶어!" 같은 질문에 답할 수 있어.
• GROUP BY & COUNT()/SUM(): 데이터를 그룹화하고 집계하는 능력. "지역별 사용자 수", "월별 매출액" 등을 쉽게 파악할 수 있지.

PM 활용 예시: 신규 기능 출시 후, 특정 사용자 그룹(예: 무료 사용자, 특정 지역 사용자)의 기능 사용률을 비교 분석하여 개선점을 찾을 수 있습니다.

2. 사용자 행동 분석: "이탈은 왜 일어날까?"

• JOIN: 여러 테이블의 데이터를 연결하는 능력. 사용자 정보와 구매 기록을 합쳐 "어떤 사용자가 어떤 상품을 많이 구매하는가?"를 볼 수 있지.
• ORDER BY & LIMIT: 데이터를 정렬하고 원하는 개수만큼만 가져오는 것. "가장 최근에 구매한 사용자 10명", "가장 많이 방문한 페이지" 등을 쉽게 확인할 수 있어.

PM 활용 예시: 특정 구간에서 이탈하는 사용자의 행동 패턴을 분석하여 이탈 원인을 파악하고, 이를 개선하기 위한 액션 아이템을 도출할 수 있습니다.

3. KPI 추적: "우리의 목표는 달성되고 있는가?"

• AVG() & MAX()/MIN(): 평균, 최대, 최소값을 구하는 함수. "사용자당 평균 세션 시간", "가장 높은 구매 금액" 등을 파악하는 데 유용해.
• DATE_TRUNC() (PostgreSQL 등) 또는 유사 함수: 날짜별로 데이터를 집계하는 능력. "일별, 주별, 월별 사용자 수 변화 추이"를 파악할 수 있지.

PM 활용 예시: 핵심 KPI(예: MAU, DAU, 전환율)의 일별/주별 변화 추이를 직접 모니터링하며, 목표 달성 현황을 실시간으로 파악하고 이상 징후 발생 시 빠르게 대응할 수 있습니다.

AI 도구를 활용한 SQL 학습: 똑똑한 PM의 선택

물론, 처음부터 모든 SQL 문법을 마스터할 필요는 없어. 요즘엔 AI 도구들이 정말 똑똑하잖아?

• ChatGPT, Bard 등: "이런 데이터를 보고 싶은데, 어떤 SQL 쿼리를 써야 할까?"라고 물어보면 친절하게 답해준다. 때로는 내가 원하는 결과가 나오지 않을 때, "이 쿼리가 왜 안 되는지 설명해줘"라고 묻는 것만으로도 큰 도움이 돼.
• 데이터 시각화 도구 (Tableau, Looker Studio 등)와의 연계: SQL 쿼리 결과를 바로 시각화 도구로 연결하면, 복잡한 숫자들을 한눈에 이해하기 쉬운 그래프로 볼 수 있지. 디자이너 출신인 나에게는 이게 정말 매력적이었어. 데이터를 '그림'으로 보는 거지.

중요한 건, AI에게 질문하는 '질문'을 명확하게 하는 능력이야. 어떤 데이터를 보고 싶은지, 어떤 인사이트를 얻고 싶은지 스스로 명확하게 정의하는 것. 이것 자체가 훌륭한 PM의 역량이지.

결론: 데이터와 직접 대화하는 PM이 승리한다

PM에게 SQL은 선택이 아닌 필수가 되어가고 있어. 데이터를 직접 다룰 줄 아는 PM은 단순히 '요청'하는 사람이 아니라, '발견'하고 '해결'하는 사람이 된다. 마치 의사가 환자의 맥을 직접 짚어보는 것처럼, PM은 데이터의 맥을 직접 짚어봐야 해.

나처럼 개발자가 아니어도 괜찮아. 우리에겐 디자이너로서의 시각적 사고, PM으로서의 문제 해결 능력이 있잖아. 여기에 SQL이라는 강력한 도구를 더하면, 당신은 상상 이상으로 강력한 무기를 갖게 될 거야.

그래서 묻고 싶어. 당신은 오늘, 당신의 제품에 대한 어떤 질문을 데이터에게 던져볼 건가?