노션, 피그마, SQL까지 할 줄 아니까 PM이면 '무기'가 될 것 같았던 이유
- 06 Dec, 2025
개발자의 착각
PM 전환 준비한 지 6개월. 노션으로 기획 문서 30개 넘게 썼다. 피그마로 와이어프레임도 그려봤다. SQL로 데이터 뽑아서 분석도 했다.
“이 정도면 무기 아니야?”
그렇게 생각했다.
이력서에 쓴 것들
- Python, Django, FastAPI 6년
- 노션으로 프로젝트 문서화 경험
- 피그마 프로토타입 제작 가능
- SQL로 데이터 분석 및 대시보드 구축
- AWS 인프라 이해도
- Git, Jira, Confluence 능숙
“개발자 출신 PM, 기술 이해도 100%”
이렇게 어필했다.
서류 탈락 7곳.
첫 번째 의문
한 스타트업에서 1차 면접 기회가 왔다. PM 3년차 면접관이 물었다.
“SQL 잘하시네요. 근데 사용자가 왜 이탈했는지는 어떻게 알아내세요?”
“데이터 보고… 분석하면 되지 않나요?”
“어떤 데이터를요? 어떻게 가설을 세우시나요?”
말이 막혔다.
쿼리는 짤 줄 아는데. 무슨 쿼리를 짜야 할지는 몰랐다.
면접관이 웃으며 말했다. “도구는 도구일 뿐이에요.”
탈락.
회사에서 실험
다음 날 출근해서 기획자 회의에 끼어들었다. 신규 기능 우선순위 논의 중이었다.
“이거 SQL로 데이터 뽑아볼까요?”
기획자가 고맙다고 했다. 30분 만에 쿼리 짜서 결과 줬다.
“좋네요. 그런데 한기획님은 어느 기능을 먼저 해야 한다고 생각하세요?”
“음… 데이터상으론 A가 높은데요.”
“근데 B를 먼저 해야 할 것 같아요. 사용자 인터뷰 3건에서 계속 나왔거든요.”
“데이터보다 인터뷰가 중요한가요?”
“둘 다 중요하죠. 근데 ‘왜’는 숫자가 안 알려줘요.”
점심 먹으면서 생각했다. 내가 PM 하려는 이유가 뭐였지?
도구를 잘 다뤄서가 아니었다.
노션의 함정
노션으로 기획 문서 예쁘게 만들었다. 템플릿도 찾아서 적용했다. 토글, 캘린더, 데이터베이스 다 넣었다.
동료 개발자가 봤다. “와 깔끔하다.”
기획자가 봤다. “보기 좋네요. 근데 이 기능은 왜 필요한 거죠?”
“사용자가 원할 것 같아서요.”
“어떤 사용자요? 언제 원하는데요?”
대답 못 했다.
노션은 ‘정리 도구’였다. 생각을 만드는 도구가 아니었다.
이미 있는 생각을 예쁘게 담는 거.
문제는 생각이 없었다는 거.
피그마의 착각
유튜브 보고 피그마 독학했다. 컴포넌트 만들고, 오토레이아웃 배우고. 프로토타입 인터랙션도 넣었다.
“이 정도면 디자이너 부럽지 않지?”
회사 디자이너한테 보여줬다. “이거 PM이 그린 거예요? 잘 그리시네요.”
기분 좋았다.
“근데 이 플로우, 사용자가 이해할 수 있을까요?” “왜 이 버튼이 여기 있어요?” “이 화면은 어떤 문제를 해결하는 거예요?”
또 대답 못 했다.
피그마는 ‘표현 도구’였다. 문제를 찾는 도구가 아니었다.
예쁘게 그리는 건 쉬웠다. 뭘 그릴지 아는 게 어려웠다.
SQL의 역설
개발자 출신 PM 강점. “데이터 직접 뽑을 수 있다!”
맞다. 근데 그게 다였다.
어느 날 대표가 물었다. “이번 달 MAU 왜 떨어졌어요?”
쿼리 짜서 숫자 보여줬다. “15% 하락했습니다.”
“알아요. 왜 떨어졌냐고요.”
코호트 분석 했다. 리텐션 그래프 그렸다. 유입 경로별 분해했다.
“그래서요?”
”…데이터상으론 신규 유입이 줄었습니다.”
“왜 줄었는데요? 어떻게 해야 해요?”
침묵.
SQL은 ‘과거를 보는 도구’였다. 미래를 만드는 도구가 아니었다.
쿼리는 답을 안 알려줬다. 질문만 줬다.
진짜 PM이 하는 것
같이 일하는 PM 관찰했다. 도구는 나보다 못 쓴다.
노션? 그냥 텍스트만 쓴다. 피그마? 디자이너한테 맡긴다. SQL? 데이터 팀한테 요청한다.
근데 회의 때 다르다.
“이 기능 왜 만들어요?” “사용자 니즈 확인했어요?” “이거 하면 매출 어떻게 늘어요?” “우선순위는 어떻게 정했어요?” “개발 리소스는 얼마나 들어요?”
질문이 다르다.
도구로 뭘 만들지가 아니라. 왜 만들어야 하는지를 묻는다.
어느 날 그 PM이 말했다. “한기획님, 도구 잘 쓰시네요. 근데 PM은 도구 쓰는 사람이 아니에요.”
“그럼 뭐예요?”
“질문하는 사람이요.”
서점에서의 깨달음
퇴근 후 서점 갔다. PM 관련 책 뒤적였다.
- ‘노션 200% 활용하기’ - 안 샀다.
- ‘피그마 실무 가이드’ - 안 샀다.
- ‘데이터 분석 SQL’ - 안 샀다.
대신 샀다.
- ‘사용자를 이해하는 법’
- ‘좋은 질문의 힘’
- ‘제품 우선순위 결정하기’
집에 와서 읽었다.
한 줄이 박혔다. “도구는 당신의 생각을 돕는다. 생각을 대신하지 않는다.”
내가 착각한 거였다.
도구가 무기가 아니었다. 도구로 뭘 할지 아는 게 무기였다.
다시 본 공고
PM 채용 공고 다시 봤다.
전에는 이렇게 봤다. “노션, 피그마 가능자 우대” ✓ “데이터 분석 역량” ✓ “개발 이해도 있으면 좋음” ✓
“나 완벽한데?”
이제는 다르게 보인다.
“사용자 니즈 파악 능력” “문제 정의 및 우선순위 설정” “이해관계자 커뮤니케이션” “제품 비전 수립”
여기엔 체크가 없다.
노션으로 비전 못 만든다. 피그마로 우선순위 못 정한다. SQL로 이해관계자 설득 못 한다.
도구는 결과물 만드는 거였다. PM은 결과물 ‘이전’을 만드는 거였다.
개발자 친구의 말
개발자 친구한테 얘기했다. “야 나 PM 준비하는데, 도구만 배웠더니 의미 없더라.”
“당연하지. 너 개발할 때도 그랬잖아.”
“뭐가?”
“파이썬 문법 다 안다고 개발 잘하는 거 아니잖아. 뭘 만들지 아는 게 중요하지.”
맞다.
주니어 때 나도 그랬다. Django 문서 달달 외웠다. 근데 ‘뭘’ 만들지는 몰랐다.
코드 짜는 건 쉬웠다. 설계하는 게 어려웠다.
PM도 똑같았다.
도구 쓰는 건 쉽다. 무엇을 어떻게 쓸지 아는 게 어렵다.
무기의 재정의
그래도 포기는 안 한다. 개발자 출신이 무기가 될 순 있다.
근데 방식이 달라야 한다.
노션을 잘 써서가 아니라. 개발자와 소통할 수 있어서.
피그마를 잘 그려서가 아니라. 기술적 제약을 이해해서.
SQL을 잘 짜서가 아니라. 데이터로 가설을 검증할 줄 알아서.
도구는 결과다. 과정이 먼저다.
이제 질문이 바뀌었다.
“이 도구로 뭘 만들까?”가 아니라. “이 문제를 어떻게 풀까? 이 도구가 도움이 될까?“
6개월의 정리
노션 문서 30개. 피그마 프로토타입 5개. SQL 쿼리 수백 개.
시간 낭비는 아니다. 방향이 틀렸을 뿐.
도구는 배웠다. 이제 ‘쓸 줄 아는 것’과 ‘잘 쓰는 것’의 차이를 배워야 한다.
PM 준비 다시 시작한다.
이번엔 다르게.
사용자 인터뷰 3개 먼저 하기. 문제 정의부터 하기. 그다음에 도구 꺼내기.
노션은 생각을 정리할 때. 피그마는 아이디어를 테스트할 때. SQL은 가설을 확인할 때.
도구를 위한 PM이 아니라. PM을 위한 도구로.
연봉 깎이더라도 상관없다. 어차피 도구만으로는 PM 못 된다.
진짜 무기는 따로 있다.
“무기는 휘두르는 법을 아는 사람한테만 무기다.”