서현일 · 경력기술서 2026
← 이력서 포트폴리오 덱 PDF 다운로드
경력기술서 · Senior PO · PM

서현일 Hyunil Seo

7년차 PM · PO · 예약 · 커머스 · O2O · 마켓플레이스 예약부터 결제·취소·정산까지 거래가 오가는 흐름을 기획하고 출시해 왔습니다
Emailbanns0104@gmail.com Phone010-3333-3768 Web포트폴리오 · 이력서
Career Summary§ 01
예약에서 결제까지,
이탈 구간을 고칩니다.
예약·커머스·O2O 서비스에서 7년간 일한 PM·PO입니다. 예약부터 결제·취소·정산까지 거래가 오가는 흐름을 기획하고 출시해 왔습니다. 2026년 9월에는 예약·쇼핑·커뮤니티를 합친 통합 서비스를 예정일에 출시했고, 출시 전후 같은 19일 결제 건은 1,608건에서 2,287건으로 늘었습니다. 취소 원장에서는 회원이 직접 취소한 건의 35.7%가 24시간 안에 다시 결제한다는 것을 찾아 취소 지표를 다시 정했습니다.

가다에서는 청구·지급 ERP로 월 투입 인원을 6인에서 3인으로 줄였고, 빠진 3인은 감원 없이 영업·재고 업무로 옮겼습니다. 순거래액·공급 같은 사업 지표와 전환·재결제·취소 같은 서비스 지표를 함께 보고, 그중 제품이 맡을 숫자를 정합니다. 앞으로는 팀 운영보다 거래 흐름의 문제를 직접 정의하고 해결책을 출시하는 시니어 PM·PO로 일하려 합니다.
2,287 건
출시 후 19일 예약 결제 건(원장) · 출시 전 같은 기간 1,608건
1.82%
방문자 대비 결제 비율 · 출시 전 1.31% (전후 같은 19일 비교)
35.7%
회원이 직접 취소한 건 중 24시간 안에 다시 결제
11.9억
새로 연 예약 도메인 누적 순거래액 · 2026.2 ~ 10.11
6→3 인
청구·지급 월 투입 인원 (감원 없이 재배치)
Experience 01 · Current§ 02
어바웃피싱 AboutFishing
2024.08 — 현재 · 2년 2개월 · CPO · 플랫폼개발팀장 · 예약·결제·취소·정산 기획과 출시 · 10명 팀
Current
9개 도메인 총괄
Role & Scope
  • 직접 한 일: 예약·결제·취소 흐름의 정책서와 화면 기획(Figma) 작성, 개발 범위·공수 조율, 출시 운영, 출시 전후 지표 비교
  • 팀장으로 한 일: 기획·디자인·프론트엔드·백엔드 10명 팀 운영, 매주 개발 배분을 거래액 영향·심각도·공수 기준으로 결정
  • 범위 결정: 앱 9개 도메인(홈 · 예약 · 쇼핑 · 커뮤니티 · 중고장터 · 머니 · 챔피언십 · 마이페이지 · 알림) 중 같은 시기에 진행하는 도메인을 3개 이하로 제한. 2026년 통합 개편 때는 두 도메인을 잠시 멈추고 1차 범위를 세 가지로 좁힘
서비스 정의 / 시장
  • 선박·선장이 흩어져 있고 예약을 전화·메신저로 받던 시장에서 9개 도메인을 한 앱으로 운영
  • 주요 고객 3유형: 50대 숙련 낚시인(예약), 30대 입문자(커뮤니티→쇼핑), 40대 가족(홈→예약)
  • 예약·커머스·커뮤니티·보상을 한 앱 안에서 오갈 수 있도록 서비스 구조를 설계
예약 순거래액 추이 — 2026.2 ~ 10.11 (10월*은 1~11일) 0 1억 2억 3억 2월 3월 4월 5월 6월 7월 1.61억 8월 3.39억 9월 1.00억 10월* 9/9 통합 출시
순거래액 = 결제일 기준 신청 − 그 기간 취소, 낚시대회 포함 · 누적 11.9억 · 회사 전체 2025 연매출 14.26억
운영 지표 (2년 2개월 · 사내 대시보드 기준)
  • 배포 122회 · 롤백 1회 — 배포와 롤백 기록을 한 화면에서 관리
  • 프로젝트 98건과 백로그 83건에 우선순위 등급을 매기고 기획·디자인·FE·BE·QA 트랙으로 나눠 관리

예약·쇼핑·커뮤니티를 합친 통합 서비스를 예정일에 출시

CPO2026.08 — 09전 도메인
문제 · 원인
  • 오픈 일정이 밀리면서 약관 시행일·딥링크·스토어 심사 마감이 서로 어긋났습니다.
  • 남은 작업 목록이 여러 문서에 흩어져 있어 사람마다 알고 있는 내용이 달랐습니다.
  • 앱 전체를 출시 전에 검수하려면 QA 인원만으로는 시간이 부족했습니다.
액션
  • 전환 준비서를 만들어 전환 항목 261건을 14개 분류로 정리하고 체크 상태·담당자·메모를 실시간 공유. 결정 22건과 리스크 34건도 같은 문서에서 관리
  • 출시 범위를 1차(웹 전환·앱 게시·측정 시작)와 2차로 나눔
  • 출시 직전 제보 65건을 거래액 영향·심각도·FE/BE 공수로 점수화해 주간 개발 배분 기준으로 씀
  • QA 인력 부족을 메우려고 전사 검수일을 "파트별로 기능을 익히는 날"로 제안해 14명이 참여. 검수 범위는 출시 전에 고칠 수 있는 공수에 맞춰 정함
  • 출시 후 되돌리기 어려운 항목을 미리 문서로 정하고 되돌림 기준 5가지를 확정. 앱은 재심사 때문에 당일 되돌릴 수 없어 웹부터 되돌리도록 순서를 정함
  • 연기안 4가지를 비교한 뒤 예정일 출시를 결정. 미뤄도 해결되지 않는 항목이 대부분이었고 앱을 고쳐 다시 제출할 기한도 이미 지나 있었음
결과 · KPI
  • 방문자(DAU) 대비 결제 비율 1.31% → 1.82% (출시 전후 같은 19일 비교 · 시즌·광고 영향은 분리하지 않음 · 출시일에 GA4 속성 변경)
  • 출시 뒤 5주 동안 주 단위 결제 비율이 출시 직전 2주보다 매주 높았음(원장 결제 건 ÷ GA4 활성 사용자)
  • GA4와 무관한 원장 기준으로도 같은 기간 결제 건 1,608건 → 2,287건(대회 제외, 이후 취소 포함)
  • 9월 순거래액 3.39억, 8월의 2.1배(성수기 영향 포함)
  • Android 비정상 종료율 0.17% → 0.09%
  • 앱 지도 이용률 13.5% → 23.3%
  • 웹에서 상세 화면을 본 뒤 결제한 비율 1.20% → 2.02%
  • 나빠진 지표: 같은 기간 앱 가입 42% 감소. 2차 과제로 분리해 추적 중

선상 예약 도메인 신설과 자사몰 객단가 개선

CPO2026.02 — 현재커머스 + 예약
문제 · 원인
  • 새 매출원이 필요했습니다. 선상 예약은 배·어종·가격을 한 화면에서 비교할 수 없어 전화와 단톡방으로 이뤄지고 있었습니다. 적립 머니는 비용으로만 나가고 다음 결제로 이어지지 않았습니다.
액션
  • 선상 예약 도메인을 새로 열면서 공급은 자사 선박 대신 외부 선장 입점으로 채우고, 선주용 공급자 앱 48화면을 기획
  • 자사몰 지표는 외부 채널과 나눠 따로 관리
  • 도메인마다 적립률을 다르게 정해 적립한 머니가 다음 결제에 쓰이도록 정책을 다시 설계
결과 · KPI · 2026.10.11 기준
  • 자사몰만 따로 집계한 ARPPU: 전년 67,000원 → 89,925원(+34%)
  • 예약 도메인 누적 순거래액 11.9억(2026.2 ~ 10.11, 결제일 기준 신청 − 그 기간 취소)
  • 월 순거래액 8월 1.61억 → 9월 3.39억(출시 달, 성수기 포함)
  • 순거래액을 결제가 생긴 배 × 배 한 척당 결제 × 건당 결제액으로 나눠 봄. 3~8월에 배는 102척 → 160척으로 늘었지만 배 한 척당 결제는 5.4건 → 4.6건으로 줄어, 제품 목표를 배 한 척당 결제로 정함(9월 8.8건)
  • 머니 적립·소멸·전환 정책과 어뷰징 방지 규칙을 함께 설계

취소 원장을 분석해 취소 지표와 재예약 흐름을 다시 설계

CPO2026.09 — 10예약 · 결제
문제 · 원인
  • 리포트마다 취소를 반영하는 방식이 달라 같은 달 거래액이 여러 값으로 나왔습니다.
  • 정의를 하나로 맞춰 다시 계산하니 객단가 변화는 작았고, 거래액 차이는 대부분 취소에서 생겼습니다.
액션
  • 거래액 정의를 "그달 결제일 기준 신청 − 그달에 생긴 모든 취소"로 고정
  • 취소 원장을 분석해 원인을 공급자 초과 예약, 결제 직후 취소, 회원의 날짜·선박 변경 세 가지로 나눔. 공급자 쪽은 외부 예약 채널과 재고를 자동 대조하는 작업을 다시 가동하기로 결정
  • 회원 쪽은 즉시 취소를 유지하고 세 가지를 설계: 취소 완료 화면의 재예약 추천, 같은 날짜 중복 예약 차단, 부분취소(쿠폰 복구·정산 재계산 포함)
  • 제가 처음 적용한 "취소 요청" 방식은 운영팀이 거의 하루 종일 대응해야 하는 구조여서 6일 만에 즉시 취소로 되돌림. 이후 취소를 막기보다 다시 예약하기 쉽게 만드는 쪽으로 방향을 바꿈
결과 · KPI
  • 회원이 직접 취소한 건의 35.7%가 24시간 안에 다시 결제하는 것을 확인
  • 주지표를 취소율에서 14일 유효 재결제율(14일 안에 다시 결제하고 그 결제를 취소하지 않은 비율, 기준선 28.9%)로 교체
  • 14일 안 재결제는 49.4%였고, 다시 취소한 결제를 빼면 28.9%
  • 즉시 취소 원복은 적용 · 재예약 추천은 개발 착수 · 효과 측정 전

한국관광공사 「여행가는 달」 캠페인의 신규 개발을 기능 하나로 줄여 단계별로 오픈

CPO2026.09 — 11쿠폰 · 페이백
문제 · 원인
  • 민간협업에 선정돼 쿠폰과 지역상생 페이백을 열어야 했습니다. 첫 기획서는 쿠폰 방식·다운로드 쿠폰·영수증 인증을 모두 새로 만드는 안이라 추석이 낀 영업일 11일 안에 끝낼 수 없었습니다.
액션
  • 이미 확정된 화면을 다시 살펴 "정률+상한 쿠폰"과 "다운로드형 쿠폰"이 있다는 것을 확인하고, 새로 만들 기능을 대상 선박 목록 하나로 줄임
  • 영수증 스캔 기능을 만드는 대신 이미지를 첨부하는 구글폼으로 접수하고, 이 때문에 생기는 운영 제약 4가지는 운영 규칙으로 정리
  • 오픈 일정을 이벤트 안내 → 쿠폰 발급 → 페이백 3단계로 나누고, 쿠폰 받기 버튼의 상태 8가지를 정의
  • 운영 기준은 기관에 낸 신청서로 정하고, 일정이 바뀌면 기관에 먼저 알림
결과 · KPI
  • 추정 공수 56.5 → 39.7MD(기획서 v2 대비 v3)
  • 새로 만든 기능 1개(대상 선박 목록)
  • 쿠폰 사용 시작(9/30) 후 10/11까지 507장 발급, 45장 결제에 사용
  • 쿠폰 결제 45건 중 취소 0건, 첫 결제 회원 9명
  • 운영 중 · 중간 집계(10/11)

지표 정의를 하나로 맞추고 데일리 대시보드 구축

CPO2026.08 — 09데이터 거버넌스
문제 · 원인
  • 자동 리포트가 예약 퍼널의 한 단계를 빼고 집계해 개선할 화면을 잘못 짚고 있었습니다.
  • 예약 건수는 4가지, 취소율은 3가지 정의가 함께 쓰여 같은 지표를 두고 숫자가 서로 다르게 보고됐습니다.
액션
  • 정의가 엇갈리는 지표 6종의 기준값과 제외 조건을 지표정의서로 작성. 테스트 결제를 분모에서 빼 취소율을 바로잡음
  • 원장 전체를 대조해 빠진 데이터가 없는지 확인한 뒤 대시보드에 연결
  • 원장·분석 도구·광고·관리자 데이터를 한 화면에 모으고 경보 규칙 12종을 만듦
  • 자동 리포트가 낸 개선 목표는 계산상 달성할 수 없다는 점을 확인. 뒤 단계 목표는 앞 단계 진입률을 넘을 수 없기 때문
결과 · KPI
  • 예약 건수 정의 4개 → 1개로 통일
  • 취소율 정의 3개 → 1개로 통일
  • 원장 전체 대조 결과 빠진 데이터 0건
  • 경보 규칙 12종 운영 · 계획과 실적이 크게 어긋난 항목을 바로 확인할 수 있게 함
  • 예약 원장은 관리자 API로 매일 받아 갱신
  • 예약 마켓 지표 28개를 정의하고 주간 판정 기준과 회의 순서를 정함(2026.10)

광고 예산 증액안을 원장 데이터로 검증해 기존 계획 유지

CPO2026.08 — 10마케팅 · 데이터
문제 · 원인
  • 외부 대행사가 제시한 고객 획득 단가를 근거로 광고 예산 증액안이 올라왔지만, 이 단가는 자사 데이터로 확인한 값이 아니었습니다.
  • 매체가 보고하는 전환 수와 자사 원장의 결제 건수가 달랐습니다. 같은 "전환"이라는 말로 서로 다른 것을 세고 있었습니다.
액션
  • 대행사 단가를 자사 예약 원장으로 다시 계산해 차이를 수치로 확인. 취소분이 빠져 있다는 점을 짚어 수정본을 받음
  • 전환을 결제 건과 유효 건(일정 기간 취소되지 않은 건) 두 가지로 나눔. 내부 목표는 유효 건으로, 대행사 계약은 결제 건과 단가 상한으로 잡도록 제안
  • 광고 계정 5곳을 열어 확인하고, 어느 문서에도 금액이 잡혀 있지 않던 매체와 기록이 끊긴 핵심 전환을 찾음
  • 목표에 필요한 결제 건수를 현재 활성 공급으로 거꾸로 계산해 달성 가능성을 미리 판단
결과 · KPI
  • 원장으로 다시 계산한 예약 1건당 획득 단가가 대행사 제시 단가의 5.2배임을 확인
  • 매체가 보고한 전환이 원장 결제 건의 3.8배였고, 이 차이는 공통 판정 기준이 없어서 생긴 것임을 확인
  • 목표에 못 미치는 원인을 광고 예산보다 활성 공급의 상한에서 찾음. 이후 더 큰 손실은 이미 판매된 자리의 취소라는 것을 확인해 취소 원인 분석으로 이어감
  • 대표 보고 후 증액하지 않고 기존 계획을 유지하기로 결정 (2026.09)
  • 이후 매체 성과 기준을 GA4 ROAS 하나로 맞추고 매체·캠페인·광고그룹·소재 순서로 판정해 10월 광고비를 월 1,192만원 줄이기로 결정

문서가 없던 대회 정산 계산식을 원장으로 역산해 확정

CPO2026.08결제 · 정산
문제 · 원인
  • 대회 정산 화면이 출처를 알 수 없는 상수로 금액을 계산하고 있었고, 일부 건에서 수수료가 음수로 나왔습니다.
  • 계산식이 어디에도 문서로 남아 있지 않았습니다.
액션
  • 과세표준이 될 수 있는 후보 다섯 가지를 모두 계산해 보고, 실제 원장 값과 원 단위까지 맞는 식 하나를 찾아 확정
  • 이 식을 음수 정산이 난 실제 6건에 다시 적용해 모두 일치하는 것을 확인하고, 예외 조건에서 기준 수수료율로 돌아가는지도 검증
  • 정산 대상 명단을 기준일과 함께 저장하도록 하고, 음수 정산 금지를 정책 문서에 반영
결과 · KPI
  • 후보 산식 5종 중 원장과 맞는 1종 확정 · 실제 6건 검산 모두 일치
  • 방향이 반대인 정산 오류 2가지 확인: 유효 건이 0인데 지급 예정으로 잡힘 / 취소분 원가만 남아 수수료가 음수로 나옴
  • 근본 원인은 정산 대상 명단이 저장되지 않아 두 화면이 각자 집계하던 구조였음
  • 정산 기준일 저장 · 음수 정산 금지 2건 정책 확정

주문서 단계와 예약까지의 터치 수를 줄이는 흐름 설계

CPO2026.09 — 10예약 · 결제
문제 · 원인
  • 예약 퍼널에서 이탈이 가장 많은 구간은 상품을 고른 뒤 결제를 시작하기까지였습니다.
  • 선박 상세, 예약 상품, 예약 접수 세 화면에서 인원·날짜·쿠폰을 나눠 고르느라 최소 11번을 눌러야 했습니다.
액션
  • 주문서 개편 첫 안("모든 입력을 주문서 한 장으로")은 개발팀 피드백을 받고 접음. 옵션은 선박 상세에서 고르고 주문서에는 예약자 정보와 결제만 남기는 안으로 바꿈
  • 결제 전에 예약 건을 만드는 시점은 지금 그대로 두어 백엔드 변경을 줄임
  • 출조 탭 조건 바 → 바로 예약 가능한 배 카드 → 바로 예약 시트(쓸 수 있는 가장 큰 쿠폰 자동 적용) → 결제 확인으로 이어지는 흐름을 설계하고 결정 12건을 문서로 정리
  • 좌석 배치도·부가상품·캘린더는 2차로 미룸. 출시 후 볼 주지표(출조 탭 진입 대비 결제 완료율)와 가드레일 지표(할인 비용·결제 당일 취소율)를 미리 정함
결과 · KPI
  • 주문서 개편 추정 공수: 프론트엔드 7.5 → 5.0MD(첫 안 대비)
  • 같은 개편의 백엔드 추정 공수: 5.0 → 2.0MD
  • 예약까지 최소 터치 11 → 7(설계값)
  • 일반 경로 터치 21 → 11 (설계값)
  • 설계 완료 · 개발 착수 전
그 밖의 프로젝트
  • 약관·처리방침 개정과 취소·환불 정책 (2026.07 — 08) · 규제 관점 지적 18건을 모두 처리했습니다. 취소·환불 요율은 약관 본문과 별표로 나눠, 요율을 바꿀 때 약관 전체를 고치지 않아도 되게 했습니다.
  • 전 도메인 손익 관리 (2024.12 — 2025.12) · 2025년 연매출 14.26억(어바웃피싱 인식 매출)을 도메인과 채널별로 나눠 관리했습니다.
  • 쿠폰 A/B 테스트 재설계 (2026.08) · "효과 없음"으로 끝난 실험의 원인을 표본 부족으로 보고, 잡을 수 있는 최소 효과를 +60%에서 +22%로 낮춘 설계로 바꿨습니다(승인 대기 · 미집행).
  • 기획 문서 초안 자동화 (운영 중) · AI로 기획 문서 초안을 만들고, 기존 정책과 어긋나거나 빠진 부분을 점검하는 데 씁니다(정량 측정 전).
Experience 02 · Previous§ 03
웍스메이트 Workmate · GADA
2020.12 — 2024.08 · 3년 8개월 · PM → PO · 건설 구인구직 O2O '가다'
일평균 1,000명 매칭, 월 매출 3억(연 36억) 규모 서비스에 PM으로 합류해 PO로 승격
Previous
3년 8개월
Role & Scope
  • PM으로 직접 한 일: 근로자앱·관리자앱·백오피스 v2~v4 전면 개편 기획을 맡음. PO가 된 뒤 후임 PM 2명에게 근로자·관리자 트랙을 넘김
  • PO로 한 일: PM·PD·QA 그룹을 맡아 데일리 스크럼·주간 1:1·분기 회고를 정기 일정으로 운영
  • 정부·액셀러레이터 지원사업 3건(TIPS·NH·NIPA) 사업계획서를 혼자 써서 선정. 어바웃피싱 창업도약패키지를 포함해 선정 4건

근로자앱을 v2에서 v4로 전면 개편해 가입 단계 단순화

PM 주도7개월협업 9인
문제 · 원인
  • 주 사용자는 40~50대 근로자인데 가입·이수증·일자리 매칭 화면 구조가 복잡해 가입 단계에서 이탈이 많았습니다.
액션
  • v2를 6개월간 부분 수정했지만 성과가 나지 않아 전면 개편으로 방향을 바꿈. 이후 같은 유형의 수정이 세 번 반복되면 구조부터 다시 봄
  • 근로자 134명을 설문·인터뷰해 가입이 막히는 단계를 확인
  • 회원가입·이수증 등록·일자리 매칭의 화면 구조를 다시 짜고, 40~50대가 쓰기 쉽게 글자를 키우고 흐름을 단순하게 바꿈
결과 · KPI
  • 회원가입 만족도 "매우 쉬움" 41% (근로자 설문 기준)
  • 이수증 등록 만족도 "매우 쉬움" 43% (근로자 설문 기준)

청구·지급 ERP MVP로 월 투입 인원 6인 → 3인 (감원 없이 재배치)

PM 주도3개월전체 대신 MVP
문제 · 원인
  • 청구·지급을 모두 손으로 처리해 매달 인력이 묶였고, 종이와 엑셀로 처리한 돈의 흐름은 데이터로 남지 않았습니다.
액션
  • ERP 전체를 만들기 전에 비용이 가장 큰 청구·지급만 떼어 작은 버전으로 먼저 만들어 투자 대비 효과를 확인
  • 부서마다 다르던 청구서를 공통 양식으로 맞추고, 실수령 → 청구 → 지급 결재 → 정산을 한 화면에서 처리하도록 설계
결과 · KPI
  • 월 투입 인원 6인 → 3인 — 감원 없이 3인은 영업·재고 트랙으로 재배치
  • 청구·지급 데이터화 100%
  • 다음 단계인 SCM 로드맵과 범위·순서를 맞춤

가다 근로 데이터로 건설 일용직 P2P 대출 대상자 선별 (한화 EBC × 피플펀드)

PM 주도가다 실작업 2주금융 외부협업
문제 · 원인
  • 근로 성실도가 상환 성실도로 이어지는지 확인된 적이 없어 건설 일용직은 대출을 받기 어려웠습니다.
액션
  • 한화 EBC가 주관하고 피플펀드가 대출 인프라를 맡은 협업에서 가다 근로 데이터로 대상자를 선별하는 일을 담당
  • 가다 쪽 작업은 2주 안에 끝내 가설을 먼저 확인
결과 · KPI
  • 대상 300명 전원 상환 완료
  • 이자율 6%, 기간 3개월
  • 근로 기록과 상환의 관계를 새 금융상품 가설로 정리

PO로 기획·디자인·QA 그룹의 요청 접수와 회의 방식 정비

PO2022 — 2024.08그룹 리드
문제 · 원인
  • 요청이 여러 경로로 들어와 백로그에 올리기 어렵고 담당자에게 늦게 전달됐으며, 회고는 한 번 하고 끝나는 경우가 많았습니다.
액션
  • 요청 접수를 슬랙 워크플로로 자동화해 백로그에 올리는 절차를 단순하게 만듦
  • 데일리 스크럼, 주간 1:1, 분기 회고(3Ls)를 그룹의 정기 일정으로 운영
결과 · KPI
  • 요청 접수 경로를 슬랙 워크플로 하나로 통일
  • PM·PD·QA 그룹의 정기 회의·회고 방식 정착
그 밖의 프로젝트
  • 현장 관리자앱 개편 · 등록 기본값을 자동으로 채우고 직전 정보를 불러오게 해, 현장에서 한 손으로 입력할 수 있게 했습니다.
  • 알림 도구 통합 · B2B 웹 · A/B 테스트 체계 · 발송 데이터 100%를 카테고리와 태그로 분류했고, 광고 없이 들어오는 B2B 문의 경로를 만들었습니다.
  • TIPS 사업계획서 (2021) · 약 100쪽을 혼자 썼고 회사가 선정됐습니다. 같은 방식으로 NH·NIPA 사업계획서도 써서 선정됐습니다.
Experience 03 · First§ 04
아키마켓 ArchiMarket · ArchiMan
2019.11 — 2020.12 · 1년 1개월 · 서비스 기획자 · 건설 인력 매칭 + 자재 커머스
First
1년 1개월

아키맨: 건설 기능공과 현장을 잇는 매칭 서비스 기획

서비스 기획전체 기획
문제 · 원인
  • 건설 기능공과 현장이 인맥과 전화로만 연결돼 일자리와 인력을 맞추기 어려웠습니다.
액션
  • 기능공과 현장 관리자를 연결하는 O2O 매칭 서비스의 전체 기획을 맡음
결과 · KPI
  • O2O 매칭 서비스 구조 수립
  • 이후 가다에서 O2O 매칭 서비스를 맡는 바탕이 됨

아키마켓: 건축·인테리어 자재 판매 기획과 운영

기획 + 운영B2B + B2C
문제 · 원인
  • 자재 구매가 오프라인과 여러 채널에 흩어져 있어 가격·재고를 비교하기 어렵고 판매자를 믿기도 어려웠습니다.
액션
  • 자사몰과 외부 판매 채널을 함께 운영하고 SEO·백링크·상세페이지 문구와 이미지까지 맡음
결과 · KPI
  • B2B·B2C 판매 채널을 동시에 운영
  • O2O·마켓플레이스 기획과 운영의 기본기를 익힘
Education§ 05
2017.03 — 2019.02
경희대학교 · 경영학과
2008.03 — 2016.02
중앙대학교 · 노어학과
Awards · Press · Grants§ 06

정부 · 액셀러레이터 선정 (4건, 사업계획서 단독 작성)

  • 중기부 창업도약패키지 (어바웃피싱)
  • 중기부 TIPS (웍스메이트, 2021)
  • NH 디지털챌린지플러스 (웍스메이트)
  • NIPA AI 바우처 (웍스메이트)

대외 인터뷰 · 협업

  • 동아일보 [스타트업人] 인터뷰 (2023.09)
  • 창업도약패키지 대기업 협업형 파트너로 SK텔레콤 TMAP과 매칭 (어바웃피싱)
  • 한화 EBC × 피플펀드 P2P 협업 (가다)
  • 건설 근로자 공제회 협업 (가다)
References§ 07
© Hyunil Seo · 2026 Last revised 2026.10 Set in Newsreader · Noto Serif KR · Pretendard