디자이너가 PM 되는 법: 6년차가 말하는 진짜 전환 이야기

December 8, 2025•6 min read•0 views•By Colemearchy

PM프로덕트매니저디자이너커리어전환스타트업

피그마를 닫고 지라를 켰던 날

2019년 3월, 나는 3년차 프로덕트 디자이너였다. 매일 피그마로 인터페이스를 그리고, 개발자에게 디자인 시스템 가이드를 전달하고, 사용자 리서치를 진행했다. 그런데 어느 순간부터 답답함이 밀려왔다. 내가 그린 화면이 실제로 비즈니스에 어떤 임팩트를 주는지, 왜 이 기능이 먼저 개발되어야 하는지, ROI는 어떻게 측정되는지 알 수 없었다.

그래서 PM이 되기로 했다. 아니, 정확히는 '되어버렸다'. 스타트업이라는 환경 덕분에 디자이너 겸 PM이라는 애매한 포지션으로 시작해서, 결국 완전히 PM으로 전환했다. 지금 6년차가 됐고, AI 스타트업에서 프로덕트를 이끌고 있다.

이 글은 화려한 성공담이 아니다. 디자이너 출신 PM이 겪는 진짜 어려움과, 그럼에도 이 전환이 왜 의미 있는지에 대한 솔직한 기록이다.

디자이너 출신 PM의 3가지 착각

착각 1: "사용자를 이해하니까 PM도 잘 할 거야"

틀렸다. 정확히는 절반만 맞았다. 디자이너는 사용자의 행동 패턴을 이해한다. 어디를 클릭하고, 어디서 이탈하고, 어떤 플로우가 직관적인지. 하지만 PM은 사용자의 비즈니스 가치를 이해해야 한다.

첫 PM 프로젝트에서 나는 완벽한 온보딩 플로우를 설계했다. 7단계 인터랙티브 튜토리얼, 마이크로 인터랙션, 개인화 질문까지. 결과는? 완료율 23%. 왜? 사용자는 튜토리얼이 아니라 당장 해결할 문제가 있었기 때문이다.

교훈: 사용자 리서치 방법론을 바꿔야 했다. "이 버튼 위치가 불편하신가요?"가 아니라 "이 기능으로 얼마의 시간/비용을 절약하셨나요?"를 물어야 했다.

착각 2: "디자인 싱킹으로 다 해결할 수 있어"

디자인 싱킹은 강력한 도구다. 하지만 PM의 세계에는 디자인 싱킹만으로 해결 안 되는 문제가 산더미처럼 쌓여있다. 특히 세 가지:

기술 부채: 우리 서비스는 레거시 코드 위에 있었다. 아무리 좋은 UX를 설계해도 3개월 개발 기간이 나오면 우선순위에서 밀린다.
비즈니스 메트릭: DAU는 올랐는데 매출이 안 늘었다. 예쁜 화면이 아니라 페이월 위치가 문제였다.
이해관계자 관리: CFO는 CAC 얘기를 하는데 나는 사용자 여정 맵을 프레젠테이션하고 있었다.

2020년 Q3, 나는 완벽한 리디자인 프로젝트를 기획했다. 3개월 일정, 개발 리소스 2명 풀타임. 그런데 CTO가 말했다. "좋은데, 이거 하면 매출이 얼마나 늘어나는데?" 나는 대답하지 못했다. 프로젝트는 폐기됐다.

착각 3: "프로토타이핑 잘하면 커뮤니케이션도 잘 될 거야"

디자이너 시절, 나는 프로토타입으로 의사소통했다. 말로 설명하기 애매한 인터랙션은 프로토타입을 보여주면 끝이었다. 하지만 PM이 되니 프로토타입으로 설명할 수 없는 것들이 너무 많았다.

왜 기능 A가 B보다 먼저 개발되어야 하는가?
이 스펙이 변경되면 어떤 리스크가 있는가?
경쟁사는 어떻게 해결했고, 우리는 왜 다르게 가는가?

2021년, 엔지니어링 팀과 격한 논쟁이 있었다. 나는 피그마 프로토타입을 보여주며 "이게 더 직관적이지 않나요?"라고 물었다. 시니어 개발자가 답했다. "직관적인 건 알겠는데, 이거 구현하려면 DB 스키마를 다 뜯어고쳐야 해요. 그럴 가치가 있나요?"

나는 비즈니스 케이스를 준비하지 않았다. 숫자가 없었다. 가설만 있었다.

PM이 되려면 버려야 할 것, 채워야 할 것

버려야 할 것

1. 픽셀 퍼펙션에 대한 집착

디자이너 시절 나는 8px 그리드 시스템의 광신도였다. 1px이라도 어긋나면 다시 했다. PM이 되고 깨달았다. 완벽한 디자인보다 빠른 검증이 중요하다.

지금은 MVP를 와이어프레임 수준으로 출시하고, 데이터를 보고 개선한다. 첫 버전은 못생겨도 괜찮다. 사용자가 쓰지도 않는 기능을 예쁘게 만드는 건 자원 낭비다.

2. "사용자가 원한다"는 막연한 확신

디자이너는 종종 사용자의 대변자를 자처한다. "사용자는 이걸 원해요!" 하지만 PM이 되면 물어야 한다. "정말? 얼마나 원하는데? 돈 낼 만큼?"

나는 3개월간 사용자 인터뷰 47건을 진행했다. 모두가 다크모드를 원한다고 했다. 그래서 만들었다. 사용률? 12%. 사람들은 원한다고 말하지만, 실제로는 쓰지 않는다.

채워야 할 것

1. 숫자로 말하는 습관

디자이너 출신 PM의 가장 큰 약점. 나는 6개월간 강제로 훈련했다.

매일 GA4 대시보드 30분 분석
주간 메트릭 리포트 작성 (전주 대비 % 변화 필수)
모든 기획서에 "예상 임팩트" 섹션 추가

예시:

Before: "사용자 온보딩 개선이 필요합니다"
After: "온보딩 이탈률 67%를 40%로 낮추면, 월간 활성 사용자 약 3,200명 증가 예상 (전환율 3% 가정)"

2. 기술 리터러시

코드를 짤 필요는 없다. 하지만 기술적 제약과 트레이드오프를 이해해야 한다. 나는 이렇게 공부했다:

개발자와 주 1회 커피챗 ("이거 왜 오래 걸리는지 설명해줘")
온라인 강의로 API, DB, 프론트엔드 기초 학습
기술 블로그 구독 (특히 우리 서비스와 유사한 스택 사용하는 회사)

6개월 후, 나는 "이건 프론트만 수정하면 되니까 2일이면 되죠?"라는 멍청한 질문을 하지 않게 됐다.

3. 비즈니스 감각

PM은 결국 비즈니스 의사결정자다. 나는 CFO에게 1시간 강의를 부탁했다. "우리 회사는 어떻게 돈을 버나요?" CAC, LTV, Churn Rate, Unit Economics. 이걸 이해하니 우선순위 설정이 명확해졌다.

지금은 분기마다 P&L(손익계산서)를 본다. 내가 만든 기능이 어느 라인에 영향을 주는지 추적한다.

디자이너 출신 PM의 강점을 살리는 법

착각과 약점만 얘기했지만, 디자이너 출신이라는 배경은 명확한 강점이 있다.

1. 프로토타입 기반 의사결정

PM 중에 피그마 제대로 쓰는 사람 생각보다 적다. 나는 중요한 의사결정 전에 항상 러프 프로토타입을 만든다. 회의에서 "이렇게 하면 어때요?"라고 말로만 하면 30분 논쟁이 벌어진다. 프로토타입을 보여주면 5분 안에 결론 난다.

지금도 주 2-3개 프로토타입을 만든다. 퀄리티는 50% 수준이지만, 커뮤니케이션 효율은 300% 올랐다.

2. 사용자 공감 능력

디자이너는 수없이 많은 사용자 테스트를 본다. 어떤 표현이 혼란을 주는지, 어떤 플로우가 좌절감을 주는지 직관적으로 안다. 이건 PM이 되어도 사라지지 않는 강력한 무기다.

나는 지금도 월 1회 사용자 인터뷰를 직접 한다. 엔지니어들은 "PM이 왜 그걸 하냐"고 묻지만, 이 시간이 내 프로덕트 감각을 유지시켜준다.

3. 크로스 펑셔널 협업

디자이너는 원래 개발자, 마케터, 비즈니스 팀 사이에 낀 존재다. 이미 중간자 역할에 익숙하다. PM도 마찬가지다. 이 경험은 생각보다 큰 자산이다.

실전 가이드: 3개월 전환 플랜

진짜 PM으로 전환하고 싶다면, 이렇게 해보라.

Month 1: 기초 체력 기르기

주 5시간 데이터 분석: GA, Mixpanel, Amplitude 뭐든 좋다. 우리 프로덕트 숫자를 손에 익혀라.
비즈니스 모델 이해: 회사 재무제표 읽기, CFO에게 30분 질문 시간 받기
1개 작은 기능 처음부터 끝까지: 기획-개발-배포-측정까지 전 과정 경험

Month 2: PM 언어 배우기

PRD 5개 작성: 실제 프로젝트든 연습이든, Product Requirements Document를 써봐라. 디자인 스펙과는 다르다.
개발 스프린트 참여: 데일리 스탠드업, 스프린트 플래닝, 레트로 모두 참석
경쟁사 분석 5개: 디자인이 아니라 비즈니스 모델, 기능 우선순위, 성장 전략 분석

Month 3: 실전 프로젝트

OKR 기반 프로젝트 1개 리드: 디자인 프로젝트가 아니라 비즈니스 임팩트 있는 프로젝트
이해관계자 프레젠테이션: 디자인 리뷰가 아니라 비즈니스 케이스 발표
포스트모템 작성: 뭐가 잘됐고, 뭐가 안됐는지 숫자로 정리

매일 하면 좋은 것들

아침 30분: 우리 프로덕트 메트릭 체크
점심시간: 경쟁사 앱 하나씩 써보기
저녁: 기술/비즈니스 아티클 1개 읽기

솔직하게, 이 전환이 맞는 사람

모든 디자이너가 PM이 될 필요는 없다. 이런 사람에게 추천한다:

✅ 이런 생각 해본 적 있다면:

"이 디자인은 예쁜데, 비즈니스 임팩트가 있을까?"
"왜 우리는 이 기능을 먼저 만들지?"
"사용자가 진짜 원하는 게 뭘까? (예쁜 UI 말고)"
"이 회사는 어떻게 돈을 버는 거지?"

❌ 이런 사람에게는 비추천:

픽셀 퍼펙션이 인생의 의미인 사람
비즈니스 숫자에 알레르기 있는 사람
"개발 일정은 내 문제 아니야"라고 생각하는 사람
사용자 리서치만 하고 싶은 사람

마지막으로

6년 전 나는 불안했다. 디자이너로서의 정체성을 버리는 것 같았다. 지금 돌아보면, 버린 게 아니라 확장한 거였다.

나는 여전히 피그마를 연다. 하지만 이제 그 화면 뒤의 비즈니스 로직, 기술적 제약, ROI를 함께 본다. 더 넓은 캔버스에서 프로덕트를 그린다.

PM이 되는 건 화려하지 않다. 숫자 보고, 회의하고, 우선순위 싸우고, 트레이드오프 고민하는 지루한 일상이다. 하지만 내 결정이 비즈니스를 움직이고, 사용자에게 실제 가치를 만드는 걸 볼 때, 이 전환이 옳았다고 확신한다.

디자이너에서 PM으로 전환을 고민 중이라면, 연락주세요. 커피챗 언제든 환영입니다. @colemearchy

P.S. 이 글이 도움 됐다면, 다음 주제 중 어떤 게 궁금한지 댓글 남겨주세요:

AI 시대, PM의 역할은 어떻게 변하는가
디자인 시스템을 PM 관점에서 다시 보기
스타트업 PM의 첫 90일 생존 가이드