Career profile

Dean Yu

Product Manager · 운영 문제를 제품과 프로세스로 바꾸는 PM

Spoqa에서 현장 운영과 고객 지원을 시작했고, OKPOS에서 가맹 신청·갱신 프로세스를 제품화했으며, Vendit에서 숙박 운영자의 OTA/PMS 연동과 Channel Manager 제품을 맡고 있다. 이 페이지는 포트폴리오가 아니라 실제 경력기술서에 가까운 공개 프로필이다.

Summary

요약

현장에서 반복되는 불만, 누락, 지연, 이탈 위험을 관찰하고 그것을 제품 요구사항과 운영 가능한 프로세스로 바꾸는 일을 해왔다. 지원팀에서 시작했기 때문에 고객이 실제로 어디서 막히는지, 내부 팀이 어떤 수기 업무에 지치는지, 제품이 어떤 순간에 신뢰를 잃는지를 중요하게 본다.

강점은 문제를 크게 포장하기보다 처리 흐름으로 분해하는 것이다. 월간 리포트 POC, 원격 설치 전환, 가맹 신청 자동화, 갱신 리스크 관리, Channel Manager MVP/2.0, Concierge 기능 pruning처럼 작은 검증과 운영 구조화를 반복해왔다.

Core strengths

핵심 역량

운영 문제 구조화고객 불만, 업무 누락, 설치 병목, 갱신 리스크를 원인·소유권·처리 흐름으로 나눈다.
MVP 범위 설계수요 검증과 안정성 기대치 사이의 간극을 보고, 필요한 경우 기능을 제한하거나 과감히 덜어낸다.
B2B 프로세스 제품화카카오톡, 구글시트, 수기 백오피스에 흩어진 업무를 신청서, 알림, 자동 배정, 전자계약 흐름으로 연결한다.
자동화와 문서화반복 리뷰, 번역 기준, 개인 기록 복구처럼 사람이 놓치기 쉬운 반복 작업을 재사용 가능한 시스템으로 만든다.

Experience

경력기술

2022.10–present

Vendit

Product Manager

숙박 운영자가 OTA/PMS, 재고, 요금, 예약을 안정적으로 관리할 수 있도록 Channel Manager와 Concierge 제품의 범위, 구조, 운영 흐름을 설계했다.

Channel Manager MVP

Problem: 숙박 운영자는 빈방을 줄이기 위해 여러 OTA에 판매하지만, 재고·요금·예약을 수동으로 관리하는 일은 복잡하고 스트레스가 크다. 기존 SMS/이메일 파싱 방식은 OTA 메시지 형식 변경이나 데이터 누락에 취약해 예약 식별 실패와 신뢰 문제가 생겼다.
Action: OTA 채널 범위와 동기화 기간을 단계적으로 넓혀 15개 채널, 1일에서 30일, 180일 범위까지 확장했다. 누락 예약 같은 부작용을 막기 위해 `sell-stop` MVP를 냈고, 고객 만족과 인입 수요로 정성·정량 검증을 진행했다. 이후 수량 조정과 유료화도 시도했다.
Result: 예약 동기화 성공률은 97%에 도달했고, 펜션 고객 획득과 월 300건 이상의 인입 리드로 초기 수요를 확인했다. 다만 보안, 캡차, 플랫폼 대응과 지연 증가로 일관성 기대치와 간극이 생겼다. 재고/판매 상태 기능은 제한하고 예약 동기화만 남긴 뒤 Channel Manager 2.0으로 전환했다.

Channel Manager 2.0

Problem: Channel Manager MVP는 크롤링 기반 예약 동기화와 오버부킹 방지 수요를 검증했지만 안정적인 서비스 제공에는 한계가 있었다. 로그인 변경, 보안 프로토콜, 상품 식별 문제가 신뢰와 비즈니스 위험으로 이어졌다.
Action: 글로벌 OTA/PMS 확장을 기준으로 기획과 구조를 다시 잡았다. 채널별 프로세스와 요금 동기화 스펙을 설계하고, 긴급 설정/수정 업무를 셀프온보딩 쪽으로 옮겼다. 내부/외부 알림과 빠른 수정 가능성도 함께 설계했다.
Result: 클로즈드 베타 안정성 검증을 완료했고 정식 출시와 구독 전환을 계획했다. 불안정한 예약/재고/요금 동기화 구조를 통합 구조로 개선했으며, 운영 리스크를 줄이고 공식 국내·글로벌 OTA 연동, 다국어 준비, 무설치 서비스 환경을 마련했다.

Vendit Concierge MVP Planning and Pruning

Problem: 합류 당시 Vendit Concierge는 기획과 디자인이 이미 끝나고 개발이 진행 중이었다. 결제, 룸서비스, IoT 제어처럼 아이디어 중심 범위가 컸지만 우선순위, 시장 반응, 정산 모델, 운영 검증은 분명하지 않았다.
Action: 중간에 PM으로 합류해 과도한 범위의 절반 이상을 덜어냈다. 팀 우선순위를 다시 잡고 결제 모듈을 먼저 출시했으며, 시장 규모와 중복 PG 등록 같은 구조적 위험을 분석해 리더십에 확장 리스크를 보고했다.
Result: 국내 시장은 100억 원 미만, 글로벌 시장은 1조 원 미만으로 추정되어 확장 매력이 낮다고 판단했다. 핵심 기능만 유지하고 추가 기능 개발을 멈췄으며 리소스를 재배치했다.

2019.12–2021.10

OKPOS

Product Manager

가맹 신청과 계약 갱신처럼 카카오톡·스프레드시트·수기 처리에 흩어져 있던 업무를 웹 신청, 백오피스, 자동 업무 배정 흐름으로 구조화했다.

Merchant Application Process Automation

Problem: 가맹 신청은 지원팀과 점주 사이의 카카오톡 대화로 처리됐다. 서류와 사진 누락, 신청 지연, 휴가나 퇴사 때의 인수인계 약화, 계약 지연, 지원 피로가 반복됐다.
Action: 내부 백오피스/T-board DB와 연결된 웹 신청서를 기획·구축했다. 개인/법인과 업종별 서류 체크리스트를 나누고, 카카오톡으로 링크를 보내면 백오피스 기록 생성과 담당자 배정이 자동으로 이어지게 했다.
Result: 신청 완료 시간은 3–5일에서 1–2일로 줄었다. 계약/지원팀의 서류 누락 병목이 줄었고, 접수부터 등록까지의 흐름이 자동화됐다.

Renewal Reminder and Churn-Risk Management Structure

Problem: 약 40,000개 가맹점의 반복 갱신 관리가 필요했지만 갱신 시점을 쉽게 파악할 수 없었다. 영업/지원팀이 데이터를 수동으로 구글시트에 옮겼고, 소유권과 신뢰도가 낮아 이탈 관리가 어려웠다.
Action: 계약 종료일 기준으로 갱신 업무를 만들고, 담당자를 자동 배정했다. 갱신, 이탈, 보류 같은 응답 처리를 전자계약 흐름과 연결했다.
Result: 계약 만료 전에 갱신 위험을 관리할 수 있게 되었고, 시스템/프로세스 부재 때문에 생기는 피할 수 있는 이탈 위험을 줄였다.

2014.12–2019.03

Spoqa

Partner Support Team

현장 지원에서 반복적으로 보이던 고객 불만, 설치 병목, 운영 기대치를 실험과 데이터로 바꿔 제품 제안과 표준 프로세스 전환으로 연결했다.

Monthly Report POC → Product Proposal

Problem: 고객 불만은 ‘문제가 생길 때만 연락받는다’는 말로 자주 나타났다. 매장이 제품의 가치를 먼저 느끼게 할 방법이 필요했다.
Action: 부산 300개 매장에서 시작해 6개월 동안 500개 매장으로 넓혔다. 재방문율, 신규 고객 수, 적립금, 마케팅 메시지 샘플 링크를 담은 리포트형 링크를 발송했다.
Result: 평균 SMS 클릭률은 20%를 넘었고, VOC 톤은 더 협조적으로 바뀌었다. 3개월 뒤 제품팀을 설득해 Monthly Report가 정식 제품으로 만들어졌고, 제품을 만드는 방향으로 이동하는 전환점이 됐다.

Remote Installation Experiment → Operating Standard

Problem: 전국 매장 설치는 방문 설치가 기본이었다. 한 사람이 하루 2–5개 매장만 설치할 수 있어 지연, 이탈 위험, 팀 과부하가 생겼다.
Action: 원격 전환 필요성을 내부에 공유하고, 부산 지점에서 4주 실험을 진행해 품질과 처리량 데이터를 모았다.
Result: 1인 설치 처리량은 하루 2–5개에서 최대 20개까지 늘었다. 원격 설치는 Spoqa의 표준 프로세스가 되었고, 이 프로젝트는 Spoqa Mate 선정으로 이어졌다.

Selected systems

업무 밖에서 이어가는 실험

아래 항목은 포트폴리오 카드가 아니라 작업 습관의 연장선이다. 번역 기준, 리뷰 자동화, 기억 복구, 개인 알림처럼 반복 비용을 줄이는 실험만 남긴다.

vcms-i18n — 번역 키, 정책 문장, QA 기준을 반복 가능한 단위로 관리하는 실험.
review-crew — 코드, 문서, 제품 판단을 한 사람의 체크리스트가 아니라 역할별 검토로 쪼개는 방식.
memory-os — 흩어진 기록을 다음 작업의 맥락으로 재사용하기 위한 운영 체계.
jarvis / personal automation — 여러 기기와 도구 사이에서 작업 맥락이 끊기지 않도록 보조하는 개인 운영 실험.

Writing

기록

hello.ignoramus.work를 다시 짓는 기록 — 어두운 랜딩페이지를 공개 개인 아카이브로 바꾼 빌드 로그.