- 팀프로젝트
- 트레이드오프 의사결정 실습 : 번개장터의 번개페이 ▼
- +) 피드백 + 인사이트
- 트레이드오프 의사결정 실습 : 번개장터의 번개페이 ▼
- 우아한 형제들 현직 PM이 말하는, 오늘의 Q&A ▼
[오늘의 Q&A] - 답변은 하단에
1. 취준생들이 가장 많이 묻는 질문
1-1. 직무 전환이 가능할까?
1-2. 요즘 PM 채용 TO가 적은데 괜찮을까?
1-3. 인턴 경험이 없어도 괜찮을까?
1-4. 어떤 자격증을 따면 유리할까?
1-5. 스펙이 좋지 않아도 괜찮을까?
2. AI와 PM의 미래
2-1. AI는 PM에게 위기인가, 기회인가?
3. PM 직무와 커리어에 대한 질문
3-1. PM은 어떤 사람에게 맞는 직무일까?
3-2. PM은 커리어 성장 가능성이 있는 직무일까?
3-3. ERP PM과 B2C PM은 어떻게 다를까?
3-4. IT 업계에서 기획자보다 PM 연봉이 더 높을까?
3-5. 신입 PM은 도메인을 어떻게 선택하면 좋을까?
3-6. 신입 PM도 개발을 할 줄 알아야 할까?
3-7. HR 데이터 기획도 PM 역량과 연결될까?
3-8. 배민이나 카카오 같은 서비스의 PM은 화면 기획 외에 무엇을 할까?
3-9. 디자이너 경력은 PM에게 강점이 될까?
3-10. 데이터 기반 의사결정과 Zero to One 창의성 중 무엇이 더 중요할까?
트레이드오프 의사결정 실습
-
번개장터의 번개페이
STEP 1. 주제 선택
아이디어 1. 잡코리아 상단 광고 노출로 원하는 정보 찾기 어려움(광고 노출 VS 사용자 경험)
- 교육 듣고 나면 잡코리아 사용할 건데, 우선적으로 뜨는 정보가 내가 원하는 정보가 아닐 수 있음
여러 번의 확인 절차를 거쳐 피로가 있음
아이디어 2. 애플이 거의 할인을 안 하는데, UX 보다 브랜드 경험 및 가치를 유지하려는 전략으로 볼 수 있음(할인 vs 브랜드 가치)
- 애플이 항상 가격을 비싸게 내놓는 거에 대해서 많은 사람들이 금액에 대해서 불만을 이야기하지만,
그럼에도 불구하고 얼리어답터가 많다는 것은 논의해 볼 가치가 있음 - but. 기존 안드로이드 운영체제를 사용하던 운영자는 또 다른 OS에 적응할 필요성이 제기됨(OS별 제공되는 어플도 제한됨)
아이디어 3. 과거에는 계좌 거래 등 다양한 거래 방식이 혼재되어 있었으나, 현재는 안전결제(번개페이) 중심 구조로 유도되고 있음
- 이유가 명확, 시스템이 도입된 후에 유저의 불편이 생겼고 사용자들의 후기도 일관적임 문제를 정의하고 개진하기 좋을 듯함
→ 선정된 아이디어. 번개장터의 번개페이
STEP 2. 문제 정의 & 가설 설정
- 문제 상황 & 문제 정의
- 번개장터에서 안전한 거래(사기방지)를 위해 번개페이를 도입하였으나, 사용자 선택사항이 아닌 필수로 번개페이를 사용(사용자가 수수료까지 부담)해야 하는 시스템으로 사용자 불만이 제기되며 이탈이 발생
→ 번개페이 사용 비중이 높아지며, 일부 사용자에게 수수료 부담과 거래 제약에 대한 불만이 발생
→ 거래 전환율 저하 가능성(특히 가격 민감 사용자 중심)
→ 플랫폼 외 거래 유도 가능성 증가(외부 메신저 등)
- 번개장터에서 안전한 거래(사기방지)를 위해 번개페이를 도입하였으나, 사용자 선택사항이 아닌 필수로 번개페이를 사용(사용자가 수수료까지 부담)해야 하는 시스템으로 사용자 불만이 제기되며 이탈이 발생
- 가설
- 가설 1. 번개페이 선택권을 일부 사용자에게 제공하면 사용자 이탈률이 감소할 것이다
- 이유: 전면 허용은 리스크 큼 → 실험 설계와 맞추기 위해 범위 제한
- 가설 2. 사용자 신뢰도 기반으로 번개페이를 차등 적용하면 헤비유저 유지율이 증가할 것이다
- 이유 : 거래 사기 방지를 위해 어플 이용 신뢰가 기본적으로 유지가 돼야 함
거래 신뢰가 쌓이면 자연적으로 헤비유저가 증가할 것
- 이유 : 거래 사기 방지를 위해 어플 이용 신뢰가 기본적으로 유지가 돼야 함
- 가설 3. 고위험 거래(고액 거래)만 강제 번개페이 적용하면 거래 활성화 정도가 높아질 것이다
- 이유 : 고액 거래일 수록 사용자 리스크가 크게 발생하므로, 고위험 거래만 안전성을 보장하면 사용자 만족도가 높아질 것
- 가설 1. 번개페이 선택권을 일부 사용자에게 제공하면 사용자 이탈률이 감소할 것이다
- 가설 우선순위 선정
- 가설 2 선택. 사용자 신뢰도 기반으로 번개페이를 차등 적용하면 헤비유저 유지율이 증가할 것
- 사용자 이탈을 감소시키는 것이 목적(사용자의 신뢰는 유지)
- 사용자 관점과 비즈니스 관점을 가운데에서 만나게 해 줄 수 있는 대안이라고 생각
- 해당 서비스 성격 상, 고위험 거래보다는 저렴한 제품을 빠르게 판매하는 것이 목적이기 때문
- 가설 2 선택. 사용자 신뢰도 기반으로 번개페이를 차등 적용하면 헤비유저 유지율이 증가할 것
→ 신뢰도 선정 기준 : 안전 거래 성공 횟수 + 후기 + 거래 성사 시간 등을 종합적으로 평가하여 검증
STEP 4. A/B 테스트
- 실험 목표
- 신뢰 기반으로 번개페이를 차등 적용하면 앱 사용률에 영향을 미치는지를 위한 검증
- A안(기존 방식)
- 안전성 보장을 위해 사용자가 수수료를 부담하며 번개페이 사용
- B안(개선안)
- 신뢰 유저 확인 가능 UI 추가 및 신뢰 유저는 일반 거래 허용
- ☑️ 인증 완화 대상
- 최근 거래 이력 존재
- 확실한 신뢰 수단을 가진 사용자
- 신뢰도 높은 온라인 거래(비대면 거래) 사용자
- 실험 대상
- 신규 및 기존 사용자 일부 샘플 그룹(50%)
STEP 4. 지표 정의 및 성공 기준 설정
- Primary Metric(핵심 지표)
- 기존 사용자 이탈률(Retention 기반)
- 거래 완료율
- Secondary Metric(보조 지표)
- 거래 성사 시간
- 총 거래 횟수
- Guardrail Metric(안정성 지표)
- 신고/사기율
- 고객 문의량
- 채팅 이후 거래 미완료 비율
- 성공 기준
- 거래량 5~10% 증가
- 이탈률 5~10% 감소
- 추천율 2~5% 증가
- 거래 성사 시간 단축 10%
- 신고/사기율 증가율 2% 이내(리스크)
- 고객 문의량 증가율 3% 이내
- 채팅 이후 거래 미완료 30% 감소
STEP 5. 리스크 및 고려사항 도출
- 리스크
- 신뢰도 판단이 어려운 라이트 유저의 사기 피해 가능성 증가
- 보안 취약성 증가
- 외부 변수
- 제품 카테고리(저가 제품 vs 고가 제품)
- 사용자 그룹(라이트 유저 vs 헤비 유저)
- 당근 등 경쟁서비스
- 사기 거래와 관련한 사회적 이슈 및 뉴스
- 데이터 해석 주의
- 거래량 ≠ 이탈률
- 거래 전환율 ≠ 성공률(사기 거래 위험 증가)
- 신뢰도 기반 그룹 자체가 기존 우수 사용자일 가능성이 높아 결과 편향 발생 가능
- 서비스 신뢰도 증가가 장기 리텐션으로 이어지는지 확인 필요
피드백 정리
잘한 점
- 가설 구조 설계
- 문제 → 가설 → 검증 흐름이 논리적으로 연결됨
- 단순 아이디어가 아니라 검증 가능한 형태로 구성된 점은 긍정적
- Guardrail Metric 설정
- 사기율, 고객 문의량 등 안정성 지표를 포함한 점이 적절
- 거래 서비스 특성상 리스크 통제까지 고려한 설계는 좋은 접근
보완이 필요한 부분
1. 지표 정의의 모호함
- '이탈률'의 기준이 불명확
- 앱 미접속 기준인지
- 거래 미완료 기준인지
- 특정 기간 기준인지 정의 필요
- 지표는 반드시 '측정 방식 + 기준 시점'까지 포함해야 함
2. 성공 기준의 현실성 부족
- 거래량 50% 증가, 이탈률 30% 감소 등은 → A/B 테스트에서 달성하기 어려운 수준
- A/B 테스트의 목적은 성과 창출이 아니라 ‘유의미한 차이를 검증’하는 것
3. 가설 구체성 부족
- 현재 가설은 방향성은 맞지만 '어떤 사용자에게', '어떤 조건에서', '어떤 행동 변화가 발생하는지'가 빠져 있음
- ex. 신뢰 유저에게 선택권 제공 시 7일 내 재거래율 증가
4. 가설 Reasoning 부족
- 왜 이 가설이 나왔는지 근거가 약함
- 필요 요소 : 사용자 행동 데이터, 후기/불만 패턴, 기존 UX 흐름 분석
5. 실험 설계의 구체성 부족
- 현재는 A/B 구조만 존재
- 실제 실행 기준이 부족함
- 추가 필요 : 실험 기간, 샘플 수 산정 기준, 유저 세그먼트 정의
6. '신뢰 유저' 정의 부족
- 핵심 변수인데 기준이 없음
- 반드시 정의 필요 : 거래 횟수, 신고 이력, 거래 성공률, 최근 활동성
피드백 인사이트
A/B 테스트의 목적이 성과를 내는 것이 아니라
의사결정을 위한 근거를 검증하고 확보하는 과정이라는 점이 인상적이었다.
아직은 A/B 테스트에 대한 개념이 충분히 정립되지 않았을 가능성도 있다.
이는 앞으로 경험을 통해 자연스럽게 체득되고 구체화될 것이라 생각한다.
또한, ‘이탈률’이나 ‘신뢰 유저’처럼
당연하게 사용하던 개념들도 근거 없이 정의하면 해석이 달라질 수 있기 때문에
용어를 명확한 기준으로 정의하는 능력 역시 중요한 역량이라고 생각했다.
모호한 용어는 문서를 보는 사람을 혼란스럽게 할 수 있다는 점을 인지하고,
명확하게 정의하려는 노력을 지속해야겠다고 느꼈다.
우아한 형제들 현직 PM이 말하는
-
오늘의 Q&A
1. 취준생들이 가장 많이 묻는 질문
1-1. 직무 전환이 가능할까?
- 가능하다(이전 기수 사례 많음1)
- 중요한 것은 이전에 어떤 직무를 했는지보다, 그 경험이 PM 역량과 어떻게 연결되는지 설명하는 것이다
- 직무 전환의 핵심은 '이전에 무엇을 했는가'보다 '그 경험이 PM 역할에 어떻게 도움이 되는가'이다
1-2. 요즘 PM 채용 TO가 적은데 괜찮을까?
- PM 채용 TO는 원래 많지 않은 편이고, 채용 시장의 불확실성이 불안감을 더 키우는 측면이 있다
- 결국 중요한 것은 경쟁률 자체보다 채용하고 싶은 사람으로 준비되는 것이다
- 단순히 'PM이 되고 싶다'라는 관점보다, 실제 문제를 정의하고 해결해 본 경험을 보여주는 것이 중요하다
1-3. 인턴 경험이 없어도 괜찮을까?
- 인턴 경험이 없더라도 가능성은 있다(이전 기수 사례 많음2)
- 채용에서는 단순 경력 유무보다 공고에서 요구하는 역량을 갖추었는지를 본다
- 경력이 없다면, 역량을 보여줄 수 있는 프로젝트와 산출물이 더 중요해진다
1-4. 어떤 자격증을 따면 유리할까?
- SQLD, ADsP 등, SQL 자격증이 반드시 필요한 것은 아니다
- 다만 데이터 기반으로 사고하고, 기본적인 SQL을 이해하는 역량은 PM에게 도움이 된다
- AI 도구의 발전으로 단순 쿼리 작성 자체보다, 어떤 데이터를 봐야 하는지 정의하고 해석하는 능력이 더 중요해지고 있다
1-5. 스펙이 좋지 않아도 괜찮을까?
- 학벌이나 학점이 좋다면 가산점이 될 수는 있다
- 하지만 PM 채용에서 결정적인 요소는 결국 직무 적합성과 문제 해결 역량이다
- 스펙이 부족하다고 느낀다면, 오히려 프로젝트 경험과 포트폴리오를 통해 '이 사람이 실제로 문제를 풀 수 있는가'를 보여주는 것이 중요하다
→ PM 준비에서 중요한 것은 스펙의 높이보다, 문제를 해결한 경험의 밀도다
2. AI와 PM의 미래
2-1. AI는 PM에게 위기인가, 기회인가?
- AI는 PM을 대체하기보다, PM이 반복 업무에서 벗어나 더 본질적인 역할에 집중하도록 돕는 도구에 가깝다
- AI는 자료 정리, 분석 보조, 문서 초안 작성, 아이디어 확장 등에서 큰 도움을 줄 수 있다
- 하지만 왜 이 문제를 풀어야 하는지, 어떤 방향이 맞는지 판단하는 일은 여전히 PM의 영역이다
- AI가 프로젝트 관리자의 역할을 대체한다기보다, AI를 이해하고 활용하는 프로젝트 리더가 더 유리해질 것이라고 보고 있다
- AI는 what과 how를 돕지만, why를 정의하는 것은 PM의 역할이다
- 앞으로 PM은 크게 두 방향에서 경쟁력을 가질 수 있다
- AI를 잘 활용하는 PM
- AI 기반 서비스를 기획하고 만드는 PM
3. PM 직무와 커리어에 대한 질문
3-1. PM은 어떤 사람에게 맞는 직무일까?
- PM은 업무 범위가 넓어 한 문장으로 정의하기 어렵다
- 다만 공통적으로 필요한 것은 문제를 발견하고, 정의하고, 이해관계자를 설득하며 결과까지 연결하는 능력이다
3-2. PM은 커리어 성장 가능성이 있는 직무일까?
- PM은 역량을 증명할수록 커리어 가치가 높아질 수 있는 직무다
- 특히 문제 해결 경험, 비즈니스 이해도, 협업 능력, 데이터 기반 의사결정 능력이 쌓이면 이직이나 오퍼에서도 강점이 될 수 있다
- 다만 이는 직무 자체가 보장해 주는 것이 아니라, 본인이 어떤 문제를 해결했고 어떤 성과를 만들었는지에 따라 달라진다
3-3. ERP PM과 B2C PM은 어떻게 다를까?
- 기반 역량은 유사하다
- 다만 경험하는 문제의 성격과 의사결정 방식이 다르다
- ERP PM: 내부 프로세스, 업무 효율, 조직 운영 최적화 중심
- B2C PM: 사용자 경험, 전환율, 리텐션, 시장 반응 중심
- 결국 둘 다 문제 정의, 요구사항 정리, 이해관계자 조율, 데이터 기반 판단이 중요하다
3-4. IT 업계에서 기획자보다 PM 연봉이 더 높을까?
- 일반화하기 어렵다
- 회사, 산업, 역할 범위, 개인 역량에 따라 다르다
- 중요한 것은 직함보다 실제로 맡는 책임과 성과다
- PM이라는 이름을 갖고 있어도 단순 화면 기획에 머물 수 있고, 기획자라는 직함이어도 제품 전략과 성과를 책임질 수 있다
3-5. 신입 PM은 도메인을 어떻게 선택하면 좋을까?
- 처음부터 완벽한 도메인을 찾으려 하기보다, 흥미를 느끼고 계속 공부할 수 있는 영역을 선택하는 것이 현실적이다
- 흥미가 있는 도메인은 더 적극적으로 학습하고 경험을 쌓기 쉽다
- 다만 현실적으로는 시간, 채용 기회, 회사 상황도 함께 고려해야 한다
3-6. 신입 PM도 개발을 할 줄 알아야 할까?
- 회사마다 요구 수준이 다르다
- 특히 스타트업에서는 한 사람이 여러 역할을 맡기 때문에 개발 이해도나 데이터 분석 역량을 더 많이 요구할 수 있다
다만 PM이 개발자처럼 개발해야 한다는 의미는 아니다
중요한 것은 개발자와 소통할 수 있고, 기술적 가능성·일정·리스크를 이해할 수 있는 수준이다 - 데이터 분석도 마찬가지다
개발자의 분석과 PM의 분석은 목적이 다르다
PM은 데이터를 통해 사용자 행동과 비즈니스 의사결정을 연결해야 한다
3-7. HR 데이터 기획도 PM 역량과 연결될까?
- 연결될 수 있다
- HR 분야에서도 데이터를 기반으로 문제를 정의하고, 시스템이나 프로세스를 개선한다면 PM적 사고와 맞닿아 있다
- 예를 들어 인사기획에서 채용 퍼널, 조직 만족도, 이직률, 성과 데이터 등을 활용해 문제를 찾고 개선안을 설계한다면 제품 PM과 유사한 사고방식이 필요하다
3-8. 배민이나 카카오 같은 서비스의 PM은 화면 기획 외에 무엇을 할까?
- 화면과 기능 기획은 기본 업무에 가깝다
- 연차가 쌓일수록 PM은 더 넓은 범위에서 방향성을 잡는 역할을 하게 된다
- 사용자 문제 정의
- 제품 방향성 설정
- 지표 분석
- 이해관계자 조율
- 비즈니스 임팩트 관리
- 즉, 단순히 화면을 만드는 것이 아니라 제품이 어떤 방향으로 가야 하는지 결정하는 역할이 커진다
3-9. 디자이너 경력은 PM에게 강점이 될까?
- 강점이 될 수 있다
- 사용자 관점, 화면 구조, UX 흐름을 이해하고 있다는 점은 PM에게 분명한 장점이다
- 다만 주의할 점도 있다
- 디자이너 경험이 강할수록 본인의 디자인 기준으로 문제를 판단할 가능성이 있다
- PM으로서는 디자인 관점뿐 아니라 개발 가능성, 비즈니스 성과, 데이터 지표까지 함께 고려해야 한다
→ 디자이너 경험은 강점이지만, PM 관점으로 확장해서 활용해야 한다(자신의 실력을 과대평가하지 말아야 하며, 매몰되지 않아야 함/각 분야 전문가의 의견을 중점으로 문제를 해결하는 것이 적절한 방향일 것)
3-10. 데이터 기반 의사결정과 Zero to One 창의성 중 무엇이 더 중요할까?
- 데이터 기반 의사결정이 더 중요하다
- Zero to One식 창의성이 항상 필수는 아니며, 특히 신입 PM에게는 데이터를 기반으로 문제를 보고 판단하는 능력이 더 현실적인 강점이 될 수 있다
- 다만 데이터는 답을 자동으로 주는 것이 아니라, 의사결정의 근거를 제공한다
따라서 PM은 데이터를 해석하고, 맥락에 맞게 판단할 수 있어야 한다
인사이트
이번 Q&A를 통해 PM 준비에서 중요한 것은 '완벽한 스펙'보다,
문제를 정의하고 해결하는 역량을 어떻게 증명할 것인가라는 점을 다시 확인했다.
특히 AI 시대에는 단순 실행 역량보다, 문제를 발견하고 왜 해결해야 하는지 설명하며
팀을 설득해 결과로 연결하는 능력이 더 중요해지고 있음을 느꼈다.
이번 Q&A에서 전달하고자 했던 메시지는 명확했다.
▼
자신의 부족함을 인지하고 지속적으로 발전하는 PM이 결국 살아남고, 그에 맞는 기회를 얻게 된다는 점.
그리고 동료들에게 ‘함께 일하고 싶은 사람’으로 인식되는 것이 중요한 역량이라는 점이다.
내 관점에서는 디자이너로서 강점을 가질 수 있는가에 대한 질문과 답변이 특히 와닿았다.
나 또한 기존 디자이너 경력과 더불어 풀스택 과정을 거치며 프론트엔드로 전향을 고민했던 만큼,
나 자신의 역량에 매몰되지 않는 태도가 중요하다는 점을 다시 한번 인지하게 되었다.
각 분야의 전문가가 조직에 존재한다는 것은 그만큼의 역할과 필요가 있다는 의미이며,
그들의 영역에 과도하게 개입하는 것은 오히려 협업을 저해하고 팀의 방향성을 흐릴 수 있다는 점도 함께 느꼈다.
아직은 기업 면접자나 선배들의 질문에 명확히 답할 수 있는 수준은 아니지만,
본 과정을 거치며 그 질문들에 답할 수 있는 사람이 되는 것을 목표로 나아가고자 한다.
'TIL' 카테고리의 다른 글
| [팀 챌린지] ROADMAP(킥오프, 리서치, 문제정의) + TIL 작성법 (0) | 2026.05.04 |
|---|---|
| 팀프로젝트(번개장터 - 번개페이) 피드백 및 인사이트 + 성장 로드맵(러프) (0) | 2026.04.30 |
| PRD 피드백(Userfit TOP3) + 개인 Q&A (0) | 2026.04.28 |
| SQL 정리 + 오늘의 정보(기획부터 출시까지 흐름 파악) + 오늘의 Q&A (0) | 2026.04.27 |
| AARRR(Pirate Metrics) 프레임워크 + PM 관점 정리(실수+개선 방법) (0) | 2026.04.24 |