학습 정리+오늘의 인사이트/KPT 회고+Q&A(PM의 SQL 접근 권한)

 

 

월요병을 물리치는 효과적인 방법이 무엇인지 아는가?

주말에도 뭔가 하고 있으면 된다.

출퇴근이 프리했던 프리랜서의 경험담이다.

(사실 이렇게 해도 월요일은 좀 두렵다)

 

---

 

• 오늘의 인사이트+KPT 회고 ▼

• 오늘의 Q&A(현업에서 PM의 SQL 권한이 어디까지 가능한지) ▼

 

 

활동 내역(주말 포함)

• 서비스 기획 입문 정리
  • 4. PM은 어떻게 문제를 발견하고 해결하는가?
  • 5. PM의 문제 정의 방법 → 해결 방안 도출 및 검증
• 영상 인사이트 : [너진똑] AI시대, 덜 가난해지는 법(부의 추월차선)
• 추천 아티클 3개 더 보기
  • 모두가 알지만 누구도 제대로 쓰지 못하는, PRD
  • 교도소 수감자에게 AI 챗봇을 보내, 20억 틈새시장을 만든 1인 창업가
  • 모든 광고는 자신의 무가치함과 싸우고 있다
• 아티클 카타 2개
  • 아티클 카타) AI는 왜 자꾸 틀리는가(AI PM/기획)
  • 아티클 카타) 이커머스 플랫폼의 수익성은 상품 데이터 구조에서 갈린다
• 통계학 기초 정리
  • Chapter 3. 실험 설계와 통계적 의사결정(A/B 테스트, t검정, 다중검정)
• 정보처리기사 실기 공부(D+47)

 

---

 

오늘의 인사이트

 

PM 공부를 하며 자주 느끼는 부분은 결국 모든 내용이 하나의 목적지로 향하는 느낌이라는 것이다.

처음엔 망망대해에 표류하는 돛단배 같은 느낌이었다면,

지금은 배도 업그레이드하고 가끔 오류도 나긴 하지만 나침반도 생긴 그런 느낌.

 

문제 정의, 사용자 리서치, PRD, 데이터 구조, A/B 테스트, AI 서비스 etc...

겉으로는 전부 다른 주제처럼 보이지만,

결국은 '무엇을 해결할 것인가'와 '그게 정말 효과가 있는가'를 검증하는 과정이었다.

 

PRD 역시 정답 문서가 아니라 팀이 같은 문제를 바라보게 만드는 도구였고,

AI 역시 정답을 주는 기술이 아니라 확률적으로 답을 생성하는 도구였다.

(특히 '확률적 생성'이라는 표현이 굉장히 와닿았다

GPT는 같은 질문에도 매번 조금씩 다른 답을 생성하기 때문에, 그 과정에서 오차가 발생할 수 있다)

 

아직은 모르는 것이 훨씬 많지만, 여러 주제를 학습하다 보니

조각난 톱니바퀴 같던 각각의 개념들이 조금씩 연결되며 돌아가기 시작하는 느낌이다.

 

 

---

 

오늘의 KPT 회고

 

Keep	• 서비스 기획 입문 강의 내용을 정리하며 문제 정의 → 가설 → 검증 흐름을 다시 복기했다 • PRD, AI PM, 이커머스 데이터 구조, 광고 플랫폼 등 서로 다른 주제의 아티클을 꾸준히 읽고 아티클 카타를 진행했다 • 통계학(A/B 테스트)과 정보처리기사 공부도 병행하며 기본기를 놓치지 않으려 했다 • 단순히 내용을 읽는 데서 끝나지 않고, PM 관점에서 왜 중요한지 스스로 해석해보려 노력했다
Problem	• 여전히 KPI, ROI, Retention 같은 비즈니스 지표와 실제 서비스 운영을 연결하는 감각은 부족하다 • 이커머스 상품 구조나 광고 플랫폼의 데이터 구조처럼 운영 관점의 내용은 아주 조금... 이해는 되지만 아직 실무 경험과 연결되진 않는다 • PM이 알아야 하는 범위가 생각보다 훨씬 넓다 보니, 학습할수록 모르는 것이 더 많이 보이는 시기인 것 같다
Try	• 아티클을 읽을 때 '그래서 이걸 실제 서비스에서는 어떤 의사결정에 활용할 수 있을까?'를 한 번 더 생각해보기 • 데이터 구조, KPI, 리텐션처럼 아직 감이 부족한 영역은 관련 아티클을 추가로 찾아보기

 

 

---

 

오늘의 Q&A
-
현업에서 PM의 SQL 권한이 어디까지 가능한지

 

 

SQL 강의를 수강하며 궁금증이 생겼다.

강의에서는 주로 SELECT를 활용한 조회 위주로 학습했는데, 실제 현업에서도 PM은 조회만 하는지, 아니면 CREATE·INSERT·DELETE 같은 작업도 수행하는지 궁금했다.

 

개인적으로는 DB를 잘못 건드렸을 때 파급력이 워낙 크기 때문에,

신입 PM에게 그런 권한을 쉽게 부여할까?라는 생각도 들었지만... 너무 궁금했다.

 

[Question]

1. PM의 SQL 접근 권한은 어디까지 허용되는지?(어떤 상황에서 어디까지 접근 가능한지?)
2. 기본 지급된 SQL 강의에서는 SELECT만 했는데 현업에서 다른 작업을 요구받으면 어떻게 대처하는지?
3. 데이터 아키텍처 분석 역량 강화를 해야 한다면 어느 정도까지 학습하는 것이 좋을지?
(ex. ERD를 대략적으로 읽고 구조를 이해하는 정도면 충분한지?(기본키, 외래키 연관 관계 등))
질문 의도 : 취업 전에 미리 준비할 수 있는 부분은 최대한 학습해 두는 것이 좋지 않을까 싶었습니다.
4. 혹시 조회 접근 권한 자체가 부여되지 않는 경우에는 데이터 기반 의사결정을 어떤 방식으로 진행하시는지?

 

[Answer]

1. PM의 DB 권한은 회사 정책에 따라 다르다. 권한은 보통 C레벨 또는 DB 관리자 권한을 가진 담당자가 업무 범위에 맞게 부여한다(회사마다 다름).

2. PM은 조회(SELECT) 중심으로 사용하는 경우가 많으며, JOIN 정도는 활용할 수 있어야 한다(JOIN 연습을 좀 더 해야겠다).

3. 주니어 PM에게 데이터 아키텍처 설계를 요구하는 경우는 드물다. 실제 DB 설계는 주로 백엔드 개발자가 담당하며, PM은 요구사항과 비즈니스 관점의 의견을 전달하는 역할에 가깝다.

4. PM에게 조회 권한 자체를 제한하는 경우는 많지 않으며, 데이터 기반 의사결정을 위해 필요한 수준의 접근 권한은 제공되는 편이다.

 

[개인적인 해석]

JOIN을 잘 하려면 결국 테이블 구조를 어느 정도는 이해해야 한다.

ERD를 읽을 수 있고, 기본키(PK)와 외래키(FK)의 관계를 이해할 수 있으며,
어떤 데이터가 어떤 흐름으로 저장되고 활용되는지 파악할 수 있는 정도가 현재 시점에서는 더 중요해 보인다.

아키텍처는 개발자에게 의견을 원활하게 전달하기 위해서라도
대략적으로 읽고(리딩) 흐름을 이해할 수 있는 정도까지는 학습해야 할 것 같다(직접 설계까지는 X).