선상 낚시 예약 서비스를신설하고 확장한 PO

MVP로 범위를 좁혀 공개 당일 결제를 받고 10명 팀과 통합 앱까지 출시했습니다.

사례 보기 이력서 보기

서현일O2O 플랫폼 PO, 2019.11~현재 어바웃피싱 CPO(2년 2개월)상태 Open

어바웃피싱 예약 화면. 선박 상세, 상품 선택, 주문서, 예약 완료 순서입니다.

3.75→5.77억 원

분기 예약 순거래액 +54%

2분기→3분기, 서비스 전체(대회 포함). 3분기에 통합 앱 출시 전 7~8월 포함

28.4→61.3%

Android 첫 실행 대비 가입자 비율

가입·로그인 개편 전후 각 7일(2025.02~04)

47.9→64.5%

가다 가입 대비 인증 비율

웍스메이트 근로자앱, 개편 앱 출시 전후(+16.6%p)

6→3명

청구·지급 업무 월 투입 인원

웍스메이트 ERP MVP, 감원 없이 영업·재고 업무로 재배치

예약 순거래액은 결제액에서 같은 기간 취소액을 뺀 값이며 낚시대회를 포함합니다. 첫 유효 결제 회원은 그해 첫 유효 결제일(취소되지 않은 결제 기준)이 그 기간 안에 있는 회원이며, 신규 가입 여부와 무관하고 낚시대회를 제외합니다.

수요와 공급을 잇고, 실제 거래를 만들었습니다

거래에 필요한 기능을 MVP로 먼저 출시하고, 결제와 운영 지표로 확인한 부분을 확장했습니다. 고객의 선택부터 공급자의 운영까지 하나의 흐름으로 설계했습니다.

어바웃피싱

낚시 고객선박 탐색·예약·결제

예약 플랫폼예약·취소·정산 연결

선주상품·빈자리·예약 확정

예약 MVP로 거래 확인 → 지도·조과·상품 추천을 예약 여정으로 확장

웍스메이트·가다

건설사인력 요청·출근 확인·청구

구인구직 플랫폼매칭·청구·지급 연결

근로자일자리 탐색·지원·임금 수령

근로자와 현장 연결 → 청구·지급 MVP로 거래 이후 운영까지 연결

사례 목록

대표 사례 6개와 추가 사례 8개입니다. 제목을 누르면 해당 사례로 이동합니다.

대표 사례01~06

01선상 낚시 예약 서비스 신설초기 예약 순거래액 1.40억 원(2026.02~03)어바웃피싱2024.09~2026.02
02예약 중심 통합 앱예약 순거래액 2분기 3.75억→3분기 5.77억 원어바웃피싱2026.04~2026.09
03예약 쿠폰·쿠폰팩첫 유효 결제 회원 64→172명(출시 전후 각 2주)어바웃피싱2025.07~현재
04예약 결제로 여는 낚시대회어바웃피싱 챔피언십대회 순거래액 1.33억 원(2026.04~09)어바웃피싱2026.03~현재
05청구·지급 ERP MVP월 투입 인원 6명→3명, 감원 없이 재배치웍스메이트2023.04~2023.06
06가다 근로자앱 전면 개편가입 대비 인증 비율 47.9→64.5%(출시 전후)웍스메이트2022.09~2023.03

추가 사례07~14

07AI 업무자동화 프로세스 설계고객 여정 9개 자동 점검, 도구 4종 단독 구현어바웃피싱2025.03~현재
08선주 앱 출시·모바일 리뉴얼예약 확정·상품 수정·정산을 선주가 직접 처리어바웃피싱2025.08~2026.08
09예약 취소 진단·재예약 추천직접취소 후 24시간 내 재결제 35.9%(개선 전)어바웃피싱2026.07~현재
10플랫폼개발팀 접수·QA·배포 운영요청 접수→담당·일정→QA→배포 공지를 한 흐름으로어바웃피싱2024.09~현재
11가입·로그인 흐름 개편Android 첫 실행 대비 가입자 28.4→61.3%어바웃피싱2025.02~2025.04
12예약 성장을 위한 광고 전략·예산 배분매체 비교를 GA4 예약 결제 한 기준으로 통일어바웃피싱2026.08~현재
13Noti통합 알림 시스템부서별 푸시·문자 발송을 한 곳으로(2023.11)웍스메이트2023.08~2023.11
14AI 예약 상담 SONA단독 기획·구현, 론칭 준비 중(2026.07~)어바웃피싱2026.07~현재

01. 선상 낚시 예약 서비스 신설

어바웃피싱2024.09~2026.02

공개 당일

첫 예약 결제 발생

2025년 8월

1.40억 원

초기 예약 순거래액

2026.02~03

12.3억 원

확장 후 누적 순거래액

2026.02~10.16

배경

낚시 정보와 커뮤니티의 관심을 실제 출조 예약으로 연결하는 사업 기회를 발견했습니다. 고객의 날짜·지역·어종 조건과 선주의 상품·빈자리를 연결하는 예약 서비스를 기획했습니다.

문제

전화와 단체 채팅방으로 예약을 받아 고객은 빈자리와 가격을 확인하기 어려웠고, 선주는 예약을 수기로 관리했습니다. 완성된 앱을 만들기 전에 온라인 탐색과 결제가 실제 거래로 이어지는지 확인해야 했습니다.

한 일

결제 발생 여부를 먼저 검증하기 위해 고객 예약웹과 운영 어드민을 MVP로 정하고, 선주 화면은 최소 기능으로 구성했습니다.
선박 탐색·날짜와 인원 선택·주문서·예약 완료의 주요 화면과 흐름을 직접 설계했습니다. 고객의 결제를 선주의 예약 확정과 운영자의 취소·정산 업무로 연결했습니다.
기획·디자인·개발·QA 및 공급 영업팀과 출시를 진행했습니다. 운영 중에는 날짜마다 달라지는 가격과 빈자리를 확인할 수 있도록 상품·좌석 정책과 예약 화면을 보완했습니다.

판단

정한 것: 고객 예약웹과 운영 어드민만 먼저 열고 선주 쪽은 최소 화면으로 둬, 온라인 결제가 실제로 나는지부터 확인했습니다.
감수한 비용: 선주 화면을 최소로 둔 만큼 선주 요청이 영업팀에 몰리는 것을 감수했고, 이후 선주 앱 리뉴얼로 풀었습니다.

기간·인원·역할

기간: 2025.08 첫 MVP 출시, 2026.02 공식 서비스 출시
참여: 프론트엔드·백엔드·디자인·QA·공급 영업팀과 협업.
내 역할: MVP 범위·정책·핵심 화면·사용자 흐름 직접 설계, 일정·검수·출시 총괄.

결과

첫 버전 공개 당일 결제가 발생했고, 공식 서비스 초기인 2026년 2~3월 순거래액 1.40억 원을 기록했습니다. 예약 수요가 실제 거래로 이어지는 것을 확인하며 예약 중심 통합 서비스로 확장했습니다.

이후 예약·대회를 포함한 예약 순거래액은 2026년 2월 1일~10월 16일 누적 12.3억 원을 기록했습니다.

회고

고객 화면을 완벽하게 만들기보다 결제가 나는지부터 확인한 순서는 유효했습니다. 다만 선주 화면을 최소로 둔 탓에 선주 요청이 영업팀에 몰렸고, 이것이 선주 앱 리뉴얼로 이어졌습니다.

화면과 설계 근거

선박 상세에서 날짜를 고르면 상품별 가격과 남은 자리(19/19석)가 바로 보이고, 그 자리에서 [예약하기]로 넘어가게 했습니다.
선박 상세·예약 진입날짜별 가격과 빈자리를 확인하고 예약을 시작하도록 구성했습니다.
상품의 남은 자리·이용시간·자리배정을 보여 주고, 인원과 예약일을 한 화면에서 고르게 했습니다.
예약 상품 선택상품의 남은 자리·이용시간·자리배정을 보여 주고, 인원과 예약일을 한 화면에서 고르게 했습니다.
예약자 정보·상품 정보·쿠폰·결제 수단을 한 장에 모아, 고른 상품을 앱 안에서 바로 결제하게 했습니다.
예약 주문서예약자·상품·쿠폰·결제수단을 한 화면에 모았습니다.
결제가 끝나면 예약번호·상품·예약 상태(예약대기)를 한 화면에서 확인하고 예약 내역으로 이어지게 했습니다.
예약 신청 완료결제가 끝나면 예약번호·상품·예약 상태(예약대기)를 한 화면에서 확인하고 예약 내역으로 이어지게 했습니다.

02. 예약 중심 통합 앱

어바웃피싱2026.04~2026.09
PWA 후속 2026.10

3.75 → 5.77억 원

서비스 전체 분기 예약 순거래액

2분기 → 3분기3분기에 출시 전 7~8월 포함

12.5 → 26.5%

지도 이용률

전체 앱 사용자 대비v7.0 출시 전후

배경

커뮤니티·커머스·예약·포인트맵 등 여러 MVP를 운영했습니다. 그중 결제와 거래액으로 수요가 확인된 예약을 중심에 두고 서비스를 재편했습니다.

문제

조황을 읽고 선박을 찾아 결제하려면 서비스를 오가야 했고, 레거시 코드로 오류가 반복됐습니다. 지도와 커머스도 예약 여정 안에서 어떤 역할을 할지 다시 정해야 했습니다.

한 일

여러 MVP를 각각 확장하는 대신 결제와 거래액으로 수요를 확인한 예약에 집중했습니다. 예약·지도·조과의 핵심 화면을 출조 탐색→선박 선택→결제로 연결하고 통합 범위·일정·전사 QA·출시 전환을 총괄했습니다.
지도 웹의 검색 유입에서 낚시 장소 탐색 수요를 확인해 통합 서비스에 포함했습니다. 기존 커머스는 예약 고객이 관련 상품을 자연스럽게 볼 수 있는 크로스셀링 구조로 설계했습니다.
개발팀과 레거시 코드를 정리하고 웹 중심 구조로의 전환을 진행했습니다. SEO 대응 기반을 마련하고, 고객이 다시 방문하기 쉽도록 후속으로 PWA 설치 기능을 도입했습니다.

판단

정한 것: 첫 통합 범위를 예약·조과로 정하고, 지도는 출조 탐색, 커머스는 예약 뒤 관련 상품 제안으로 역할을 좁혔습니다.
버린 대안: 모든 기능을 한 번에 통합하는 안은 전원 회의에서 접고 예약·조과를 1차 범위로 정했습니다. 그 대가로 지도는 출조 탐색 기능으로, 커머스는 예약 고객 대상 상품 제안으로 역할을 좁혔습니다.

기간·인원·역할

기간: 2026.04~09 통합 재편, 09.09 출시, 10월 PWA 후속 도입
참여: 플랫폼개발팀·공급 영업팀과 전사 QA, 기획·디자인·프론트엔드·백엔드·QA 협업.
내 역할: 예약 중심 사업·제품 재편, 통합 범위·일정·전사 QA·출시 전환 총괄.

결과

통합 출시 전후 각 2주 첫 유효 결제 회원은 534명에서 681명으로 증가했습니다. 출시 뒤 2주가 9월 성수기와 겹친 값입니다. 지도를 출조 탐색에 통합한 뒤 전체 앱 사용자 대비 지도 이용률은 12.5%에서 26.5%로 높아졌습니다.

서비스 전체 분기 예약 순거래액은 2분기 3.75억 원에서 3분기 5.77억 원으로 54% 늘었습니다. 낚시대회를 빼면 3.02억 원에서 5.17억 원으로 71% 늘었습니다. 성수기와 광고 조정이 함께 반영된 거래 규모입니다.

회고

결제와 거래액으로 수요가 확인된 예약을 중심에 두고, 지도는 출조 탐색으로, 커머스는 관련 상품 제안으로 역할을 정한 판단은 유효했습니다.

다시 추진한다면 통합 전부터 지도 탐색의 예약 연결과 예약 고객의 추가 구매를 판단할 기준을 먼저 정하겠습니다. 각 기능의 거래 기여를 확인하면서 확장했으면 더 좋았겠습니다.

지도 웹 검색 성과 — 2026.06~08, 클릭 2.4천, 노출 8.01만, CTR 3%

하나의 예약을 고객·선주·운영이 이어받는 구조

고객

출조·지도 탐색

상품·빈자리 선택

예약·결제

출조·이용

예약 요청 ↓↑ 확정·변경 안내

선주

상품·좌석 관리

예약 확인·확정

출조 운영

정산 확인

변경·취소 요청 ↓↑ 처리·지급 안내

운영

입점·상품 점검

예약·취소 처리

고객·선주 안내

정산·지급

화면과 설계 근거

지역·어종·선박과 일정을 골라 예약 탐색을 시작하도록 구성했습니다.
출조 탐색지역·어종·선박과 일정을 골라 예약 탐색을 시작하도록 구성했습니다.
낚시 포인트·조황·선박·CCTV를 지도에서 함께 탐색하도록 연결했습니다.
지도 탐색낚시 포인트·조황·선박·CCTV를 지도에서 함께 탐색하도록 연결했습니다.
통합 앱의 선박 상세에서 날짜별 남은 자리를 보고 바로 예약으로 넘어가게 했습니다.
v7.0 선박 상세통합 앱의 선박 상세에서 날짜별 남은 자리를 보고 바로 예약으로 넘어가게 했습니다.
예약자·쿠폰·결제 금액을 한 화면에서 확인하고 결제하게 했습니다.
v7.0 예약 접수예약자·쿠폰·결제 금액을 한 화면에서 확인하고 결제하게 했습니다.
새소식 홈 바로가기 첫 칸에 「내 예약」을 두고, 다가오는 출조 예약 카드를 홈 위쪽에 띄웠습니다. 쇼핑·중고장터 탭은 하단에서 뺐습니다.
새소식 홈다가오는 예약과 출조에 필요한 정보를 홈에서 확인하도록 구성했습니다.
예정된 출조를 확인하는 흐름에 준비물 상품을 제안했습니다.
예약 내역·준비물 연결예정된 출조를 확인하는 흐름에 준비물 상품을 제안했습니다.
예약을 마친 고객에게 출조에 필요한 상품을 연결했습니다.
예약 완료·크로스셀링예약을 마친 고객에게 출조에 필요한 상품을 연결했습니다.
선박을 다시 찾기 쉽도록 홈 화면 바로가기 추가를 안내했습니다.
PWA 바로가기 안내선박을 다시 찾기 쉽도록 홈 화면 바로가기 추가를 안내했습니다.

03. 예약 쿠폰·쿠폰팩

어바웃피싱2025.07~현재

64 → 172명

첫 유효 결제 회원

출시 전후 각 2주출시 전 2주는 즉시 할인 종료 직후

배경

선박·오프라인·VIP·난수 쿠폰과 주문서 적용 정책을 단계적으로 정리했습니다.

문제

쿠폰을 받는 경로와 적용 조건이 흩어져 있었고, 받은 쿠폰이 결제에 적용됐는지 확인하기 어려웠습니다. 20% 즉시 할인 종료 뒤에는 예약 결제가 감소했습니다.

한 일

쿠폰 받기·코드 등록·주문서 적용의 주요 화면과 흐름을 직접 설계했습니다. 마이페이지와 선박 상세에서 쿠폰을 받고 결제에 적용하도록 구성했습니다.
즉시 할인 종료 뒤 예약 결제가 줄자 웰컴·재구매·단체 쿠폰팩을 우선 과제로 정해 2026년 5월 21일 출시했습니다.
후속으로 상시 쿠폰·쿠폰 복권을 확장하고, 최대 할인 자동 선택과 사용 불가 쿠폰 구분을 적용했습니다. 탈퇴 후 재발급을 막는 정책도 보완했습니다.

판단

정한 것: 즉시 할인을 다시 여는 대신 첫 결제·재결제·단체 상황별 쿠폰팩을 먼저 만들었습니다.
버린 대안: 즉시 할인을 다시 여는 안은 모든 결제에 같은 할인이 붙어 첫 결제·재결제·단체처럼 상황별로 나눠 줄 수 없어 택하지 않았습니다. 탈퇴 후 재가입 악용 차단은 첫 출시에서 빼고 이후 보완했습니다.

기간·인원·역할

기간: 2025.07~현재. 정식 쿠폰 2026.03.06, 쿠폰팩 05.21, 자동 적용·쿠폰 시트 후속 배포 10.02.
참여: 기획·QA·프론트엔드·백엔드 및 쿠폰 운영 담당과 협업.
내 역할: 발급·적용 정책과 출시 우선순위 결정, 쿠폰 받기·등록·주문서 적용 화면 설계.

결과

쿠폰팩 출시 전후 각 2주 첫 유효 결제 회원은 64명에서 172명으로 증가했고, 이 중 107명이 웰컴 쿠폰팩을 사용했습니다. 발급에서 끝내지 않고 주문서에서 혜택이 바로 적용되도록 후속 개선했습니다.

회고

받은 쿠폰을 고객이 다시 찾아 적용하게 두면 발급만으로는 혜택을 전달하기 어렵습니다. 이 판단을 10월 후속 개선에 반영해 최대 할인 자동 선택과 사용 불가 쿠폰 구분을 적용했습니다. 다시 설계한다면 발급과 주문서 적용을 한 흐름으로 검토하겠습니다.

화면과 설계 근거

쿠폰 다운로드와 코드 등록을 한곳에 모았습니다.
쿠폰 받기쿠폰 다운로드와 코드 등록을 한곳에 모았습니다.
보유한 쿠폰의 사용 조건과 기한을 확인하도록 구성했습니다.
보유 쿠폰 확인보유한 쿠폰의 사용 조건과 기한을 확인하도록 구성했습니다.
최대 할인 쿠폰을 먼저 선택하고 사용할 수 없는 쿠폰을 구분했습니다.
주문서 쿠폰 선택최대 할인 쿠폰을 먼저 선택하고 사용할 수 없는 쿠폰을 구분했습니다.
주문서에 들어오면 할인이 가장 큰 쿠폰이 먼저 적용되고 할인 금액이 함께 보이게 했습니다.
주문서 쿠폰 자동 적용주문서에 들어오면 할인이 가장 큰 쿠폰이 먼저 적용되고 할인 금액이 함께 보이게 했습니다.

04. 예약 결제로 여는 낚시대회어바웃피싱 챔피언십

어바웃피싱2026.03~현재

대회 순거래액 1.33억 원(2026.04~09)

배경

예약 서비스의 결제와 거래액으로 시장 수요를 확인했습니다. 마라톤처럼 참가비를 내고 참여하는 대회 모델을 조사하고, 선주들과 함께 어바웃피싱 이름의 낚시대회를 기획했습니다.

문제

일반 출조 예약에서 참여 목적을 넓혀 브랜드 인지도를 높이고 추가 거래를 만들고자 했습니다. 대회 참가와 선박 예약을 같은 결제·운영 흐름으로 연결해야 했습니다.

한 일

참가·결제·예약 내역의 주요 화면과 흐름을 직접 설계했습니다. 기존 예약 구조를 활용해 대회 상품을 판매하고, 일반 예약과 대회 참가를 구분하도록 구성했습니다.
선주·운영·영업·협찬사와 참가 선박과 운영 방식을 조율했습니다. 대회 결제·취소 기준과 다음 회차 접수 시점을 정했습니다.
차전별·누적·개인 순위를 확인하는 랭킹과 후속 대회 화면을 설계하고, 대회 앱·어드민·환불 정책을 보완했습니다.

판단

정한 것: 대회용 별도 시스템 대신 기존 예약 상품·결제 구조로 대회를 판매하고, 결제·취소 기준을 접수 전에 확정했습니다.
버린 대안: 먼저 만든 외부 대회 접수·상금 중심 시스템을 그대로 쓰는 안은 예약 결제와 연결되지 않아 택하지 않았습니다.

기간·인원·역할

기간: 2026.03~현재. 접수 시작 2026.03.25, 후속 재설계 09월.
참여: 기획·QA·프론트엔드·백엔드·운영·영업·협찬사 협업.
내 역할: 결제·취소 정책 결정, 대회 참가·결제·예약 내역 화면 설계, 운영 협업·후속 재설계.

결과

2026년 4~9월 대회 결제 1,031건, 순거래액 1.33억 원

자체 대회 참가를 예약 결제로 연결하고, 회차별 접수와 운영을 이어갔습니다. 제2~4회 대회 결제 회원 중 47.7~63.8%는 이 대회로 첫 예약 결제를 한 회원이었습니다. 아래는 예약 결제 내역 기준 낚시대회 상품의 월별 값입니다. 결제 건수는 그 달에 결제된 건이고, 순거래액은 그 달 결제에서 그 달 취소를 뺀 값입니다. 6개월 합계는 같은 기간 예약 순거래액의 14%입니다.

월	결제 건수	순거래액
2026년 4월	186건	2,667만 원
2026년 5월	146건	2,073만 원
2026년 6월	223건	2,661만 원
2026년 7월	187건	1,811만 원
2026년 8월	146건	2,567만 원
2026년 9월	143건	1,545만 원
합계	1,031건	1억 3,324만 원

회고

대회를 반복 운영하려면 참가 신청 화면뿐 아니라 접수 일정·취소·정산을 같은 기준으로 다루는 것이 중요했습니다. 다음 회차에서는 대회 참가 고객의 일반 예약 이용까지 연결해 확장 모델의 가치를 확인하겠습니다.

화면과 설계 근거

제1회 챔피언십을 앱 안의 대회 화면으로 열어, 일정·참가 선박·참가비·대회 정보를 보고 바로 [참가 신청하기]로 결제까지 가게 했습니다.
챔피언십 대회 홈제1회 챔피언십을 앱 안의 대회 화면으로 열어, 일정·참가 선박·참가비·대회 정보를 보고 바로 [참가 신청하기]로 결제까지 가게 했습니다.
대회 참가 결제는 예약 내역에서 「낚시대회」 배지와 다른 색 카드로 일반 예약과 구분해 보이게 했습니다.
예약 내역 대회 표시대회 참가 결제는 예약 내역에서 「낚시대회」 배지와 다른 색 카드로 일반 예약과 구분해 보이게 했습니다.
차전별·누적 순위와 내 순위를 대회 화면 안에서 바로 보게 해, 여러 차전을 이어 참가할 이유를 만들었습니다.
4차 대회 랭킹 설계차전별·누적 순위와 내 순위를 대회 화면 안에서 바로 보게 해, 여러 차전을 이어 참가할 이유를 만들었습니다.
재설계안에서는 대회 상세 첫 화면에 얼리버드 마감 시각·접수 마감·준비물·심사 규정을 모으고, 하단에 남은 자리와 참가비가 붙은 신청 버튼을 고정했습니다.
제3회 대회 상세 후속 설계재설계안에서는 대회 상세 첫 화면에 얼리버드 마감 시각·접수 마감·준비물·심사 규정을 모으고, 하단에 남은 자리와 참가비가 붙은 신청 버튼을 고정했습니다.

05. 청구·지급 ERP MVP

웍스메이트2023.04~2023.06

6 → 3명

청구·지급 업무 월 투입 인원

감원 없이 재배치

배경

건설사의 노임 청구와 근로자 지급을 처리하는 내부 운영 시스템을 기획했습니다.

문제

오프라인 청구·입금·지급 확인에 매달 여러 담당자가 투입됐습니다. 회사 전체 ERP를 한 번에 만들기에는 개발 범위와 기간이 컸습니다.

한 일

청구·지급을 MVP의 첫 범위로 정하고 나머지는 후속 로드맵으로 분리했습니다. 운영 담당 세 그룹을 인터뷰해 누가 어떤 정보를 확인하고 다음 업무로 넘기는지 정리했습니다. 백엔드·프론트엔드·디자인 및 운영 담당과 정책·화면을 구체화해 2023년 6월 운영에 적용했습니다.
청구에서는 현장별 상태·계산서 발행·입금액을 확인하도록 했습니다. 지급에서는 제외할 건을 확인한 뒤 일괄 처리하고 이체용 엑셀을 내려받는 흐름을 정리했습니다. 지급이 끝난 뒤에는 공수·단가 변경을 구분해 기록을 확인하도록 설계했습니다.

판단

정한 것: 회사 전체 ERP 대신 손이 가장 많이 가던 청구·지급만 떼어 먼저 운영에 적용했습니다.
버린 대안: 전체 ERP를 한 번에 만드는 안은 범위와 기간이 커서, 나머지 기능은 후속 로드맵으로 나눴습니다.

기간·인원·역할

기간: 2023.04~06, 약 3개월. 청구 목록·지급 처리·기록 화면은 2023년 8월 후속 설계.
참여: PO로 백엔드·프론트엔드·디자인·QA 및 운영 담당 세 그룹과 협업.
내 역할: 청구·지급 MVP 범위 결정, 운영 인터뷰·정책·업무 구조·화면 설계.

결과

청구·지급 업무의 월 투입 인원이 6명에서 3명으로 줄었습니다. 해당 업무에서 이동한 인원은 감원 없이 영업·재고 업무로 재배치됐습니다.

회고

청구·지급을 먼저 운영에 적용하고 영업·고객 관리 등은 후속 로드맵으로 분리했습니다. 후속 설계에서는 청구·지급·변경 기록을 나눠 확인하도록 확장했습니다.

화면과 설계 근거

청구와 입금 확인을 연결하는 업무 설계 산출물입니다.
청구·미수·입금의 업무 구조청구와 입금 확인을 연결하는 업무 설계 산출물입니다.
건설사에 노임을 청구하는 일을 현장별 청구 목록으로 옮겨, 청구 상태·계산서 발행·입금액을 한 줄에서 처리하게 했습니다.
청구 목록건설사에 노임을 청구하는 일을 현장별 청구 목록으로 옮겨, 청구 상태·계산서 발행·입금액을 한 줄에서 처리하게 했습니다.
근로자 지급은 날짜별 목록에서 제외 건을 확인한 뒤 일괄 지급하고, 이체용 엑셀을 바로 내려받게 했습니다.
지급 처리근로자 지급은 날짜별 목록에서 제외 건을 확인한 뒤 일괄 지급하고, 이체용 엑셀을 바로 내려받게 했습니다.
지급이 끝난 건은 지급 기록 탭에 남기고, 공수 변경·단가 변경 같은 구분을 붙여 나중에 확인할 수 있게 했습니다.
지급 기록지급이 끝난 건은 지급 기록 탭에 남기고, 공수 변경·단가 변경 같은 구분을 붙여 나중에 확인할 수 있게 했습니다.

06. 가다 근로자앱 전면 개편

웍스메이트2022.09~2023.03

47.9 → 64.5%

가입 대비 인증 비율

개편 앱 출시 전후

+16.6%p

인증 비율 변화

배경

건설 일용 근로자가 가입·인증 후 일자리에 지원하고 출근·지급 상태를 확인하는 앱입니다.

문제

약 6개월간 부분 수정 후에도 가입·인증·지원 흐름에 문제가 남았습니다. 상담 기록에서는 긴 가입 절차와 지원 현장의 진행 상황 확인이 주요 문제였습니다.

한 일

부분 수정이 계속됐지만 인증과 지원 문제가 남아 설문 134명·상담 기록·GA 퍼널을 함께 검토했습니다. 개별 화면 수정 대신 가입부터 지원 이후 상태까지 전면 개편하는 범위를 정했습니다.
일자리 지원에 필요한 계좌·이수증 인증을 가입 흐름에 포함했습니다. 기본정보 입력→임금 수령 계좌 등록→이수증 확인의 핵심 화면·정책을 직접 설계했습니다.
지원 이후에는 심사·출근 확정·현장 도착·퇴근·입금을 시간순으로 보여 주도록 구성했습니다. PM으로 IA·와이어프레임·프로토타입·QA를 담당하고 앱·서버·디자인과 상세화·출시를 진행했습니다.

판단

정한 것: 6개월 이어 온 부분 수정을 멈추고 가입·인증·지원 흐름 전체를 다시 설계했습니다.
버린 대안: 문제가 된 화면만 계속 고치는 안은 부분 수정 뒤에도 같은 문의가 이어져 접었습니다.

기간·인원·역할

기간: 2022.09~2023.03, 약 7개월
참여: PM으로 앱·서버·디자인·QA 담당과 협업.
내 역할: 가입·인증·지원의 핵심 화면·사용자 흐름 직접 설계, 정책·정보 구조·프로토타입·QA.

결과

가입 대비 인증 비율이 47.9%에서 64.5%로 상승했습니다. 계좌·이수증 인증을 가입 단계에 포함해 일자리 지원에 필요한 준비를 앞단에서 마치도록 바꿨습니다. 인증을 가입 단계로 옮긴 영향이 함께 반영된 값이라, 매칭이나 장기 이용 증가로 넓혀 해석하지 않습니다.

회고

부분 수정만으로는 가입부터 지원까지 이어지는 문제를 풀기 어려웠습니다. 고객 문의와 퍼널을 함께 보고 전체 흐름을 바꾸는 판단이 필요했습니다.

화면과 설계 근거

가입 시 필요한 기본정보와 서명을 입력하는 화면입니다.
기본정보 입력가입 시 필요한 기본정보와 서명을 입력하는 화면입니다.
임금을 받을 계좌를 등록하는 인증 화면입니다.
임금 수령 계좌 등록임금을 받을 계좌를 등록하는 인증 화면입니다.
기초안전보건교육 이수증을 확인하고 등록하는 화면입니다.
이수증 확인·등록기초안전보건교육 이수증을 확인하고 등록하는 화면입니다.
지원한 현장이 지원 심사부터 출근 확정·현장 도착·퇴근·입금 확인까지 어느 단계인지 시간순으로 보이게 했습니다.
지원 이후 상태 확인지원한 현장의 심사·출근·지급 진행 상태를 시간순으로 확인하도록 설계했습니다.

추가 사례

대표 사례를 뒷받침한 운영·도구·이전 회사 사례입니다.

사례별 화면과 그 밖의 사례는 웹 포트폴리오 banns0104.github.io/seo-hyunil-portfolio에서 볼 수 있습니다.

07. AI 업무자동화 프로세스 설계

어바웃피싱2025.03~현재

4종

업무 도구 단독 기획·구현

9개

고객 여정 자동 점검

배경

지표를 확인한 뒤 개선 안건을 만들고, 개발과 배포를 거쳐 다시 고객 경험을 점검하는 제품 운영 흐름이 필요했습니다.

문제

지표·광고 리포트와 업무 요청이 여러 도구와 채팅방에 흩어져 있었습니다. 현황을 취합하는 데 시간이 들었고, 발견한 문제의 담당자·개발 일정·후속 조치를 함께 확인하기 어려웠습니다.

한 일

CPO·광고 대시보드, 팀 스케줄 대시보드, 채널 요약봇, 고객 여정 모니터링봇 4종을 직접 기획·구현했습니다.
결제·취소·GA4·광고비와 AI가 요약한 업무 기록을 검토해 개선 안건을 정했습니다. 스케줄링 대시보드에서 우선순위·담당자·직군별 일정과 QA·배포 기록을 관리하도록 구성했습니다.
개발·배포 후에는 모니터링봇이 실제 브라우저에서 고객 여정을 점검하고 구글챗으로 결과를 전달하도록 했습니다. 수집·요약·반복 점검을 자동화하고, 안건 선정과 우선순위는 담당자가 판단하는 구조로 설계했습니다.

판단

정한 것: 지표 수집·업무 요약·반복 점검만 자동화하고, 안건 선정과 우선순위는 담당자가 판단하게 했습니다.
버린 대안: 점수만으로 개발 순서를 자동 결정하는 안은 사업 맥락을 놓칠 수 있어 택하지 않았습니다.

기간·인원·역할

기간: 2025.03~현재. CPO 대시보드 2026.03, 팀 스케줄 04, 모니터링·제보 분류 09로 확장.
참여: CPO·광고 대시보드·팀 스케줄·채널 요약봇·고객 여정 모니터링봇은 단독 기획·제작. 플랫폼개발팀 10명과 운영·영업·마케팅이 활용.
내 역할: 업무 흐름·주요 화면·데이터 구성 설계 및 도구 4종 단독 구현. 팀의 우선순위 판단과 일정·운영 점검에 적용.

결과

직접 만든 도구 4종을 플랫폼개발팀과 운영·영업·마케팅 업무에 적용했습니다. 지표와 업무 기록을 확인해 안건을 정하고, 개발 일정·QA·배포 이력을 함께 관리했습니다.

고객 여정 9개를 정기적으로 자동 점검하고 구글챗으로 결과를 받아 운영 상태를 확인했습니다.

회고

다음에는 발견한 문제와 안건·배포·재점검 결과에 공통 식별자를 두겠습니다. 도구별 현황을 확인하는 데서 더 나아가, 어떤 조치가 문제를 해결했는지 한 번에 추적할 수 있도록 개선하고 싶습니다.

지표에서 실행으로, 배포 후 점검까지

01지표·업무 수집
대시보드, AI 업무 요약
02검토·안건·일정
담당자 판단, 우선순위 결정
03개발·QA·배포
직군별 일정, 변경 이력
04운영 자동 점검
모니터링봇, 구글챗 알림

점검 결과는 후속 안건 검토에 활용합니다. 아래 화면은 각 단계에서 실제 사용하는 도구의 예시입니다.

화면과 설계 근거

예약 여정의 지표를 확인하고 개선이 필요한 구간을 살펴봅니다.
01 지표 대시보드예약 여정의 지표를 확인하고 개선이 필요한 구간을 살펴봅니다.
채널에 올라온 오류·개선 제보를 모아 거래액 영향·심각도·개발 일수로 점수를 매긴 표입니다.
02 제보 자동 접수·점수화채널에 올라온 오류·개선 제보를 모아 거래액 영향·심각도·개발 일수로 점수를 매긴 표입니다.
스케줄링 대시보드에 안건을 모아 우선순위·담당자·진행 상태를 확인합니다.
03 개선 안건 관리스케줄링 대시보드에 안건을 모아 우선순위·담당자·진행 상태를 확인합니다.
결제 흐름 개선 안건의 목표일과 기획·프론트엔드 일정을 정리한 실제 화면입니다.
04 우선순위·일정 설정결제 흐름 개선 안건의 목표일과 기획·프론트엔드 일정을 정리한 실제 화면입니다.
안건마다 기획·디자인·개발·QA 진행 단계와 배포일을 한 줄로 확인합니다.
05 안건별 진행 추적안건마다 기획·디자인·개발·QA 진행 단계와 배포일을 한 줄로 확인합니다.
AI 요약봇이 채팅방의 전날 변경 사항을 정리해 매일 아침 올립니다.
06 업무 변경 자동 요약AI 요약봇이 채팅방의 전날 변경 사항을 정리해 매일 아침 올립니다.
팀이 쓰는 대시보드의 개선 내역을 버전별로 남깁니다.
07 도구 개선 기록팀이 쓰는 대시보드의 개선 내역을 버전별로 남깁니다.
고객 여정 자동 점검 결과를 구글챗으로 받아 검색·화면·로그인 상태를 확인합니다.
08 모니터링봇 결과 수신고객 여정 자동 점검 결과를 구글챗으로 받아 검색·화면·로그인 상태를 확인합니다.

08. 선주 앱 출시·모바일 리뉴얼

어바웃피싱2025.08~2026.08

예약 확정·상품 수정·정산을 선주가 직접 처리

배경

선상 예약은 선주가 예약을 확정해야 끝납니다. 첫 선주 앱은 공식 오픈에 맞춰 최소 기능으로 출시했습니다.

문제

예약이 늘자 선주가 상품과 예약을 직접 관리하려는 요청이 영업팀에 집중됐습니다. 선주가 받을 금액을 쿠폰 할인 후 금액으로 보여 주어 오해하는 문제도 있었습니다.

한 일

홈은 확정 대기 예약과 처리할 일을 빠르게 확인하고 바로 확정하는 시작점으로 설계했습니다. 선주 홈·예약·상품·정산의 주요 화면과 흐름을 직접 기획했습니다.
예약 관리에서 고객과 좌석을 확인하고, 상품 관리에서 가격·판매 일정·좌석을 수정하며, 정산에서 받을 금액과 지급 내역을 확인하도록 연결했습니다.
판매중지·마감·숨김의 기준과 선주 권한을 구분했습니다. 영업팀의 현장 요청을 반영하고 금액은 할인 전 기준으로 보여 주도록 바꿨습니다.

판단

정한 것: 공식 오픈 때는 최소 기능으로 열고, 결제가 늘어난 뒤 선주가 직접 확정·수정·정산하는 범위로 넓혔습니다.

기간·인원·역할

기간: 2025.08~2026.08. 선주 앱 2026.02.20, 리뉴얼 운영 08.05. 후속 개선은 09~10월.
참여: 기획·디자인·프론트엔드·백엔드·QA와 공급 영업팀 협업.
내 역할: 우선순위·권한·상태 정책 결정, 선주 홈·상품·예약·정산 화면 설계.

결과

예약 확정·상품 수정·정산을 선주가 직접 처리하는 구조로 전환

선주가 영업팀을 거치지 않고 예약 확정·상품 수정·정산 확인을 하나의 서비스에서 처리하는 구조로 바뀌었습니다.

회고

예약 MVP에서는 결제 검증을 위해 선주 기능을 최소화했습니다. 이후 상품·예약 관리 요청이 영업팀에 몰리자, 선주가 직접 확정·수정·정산을 처리하는 범위로 확장했습니다. 다시 시작한다면 최소 기능을 정할 때 영업팀이 대신 처리할 업무와 공급자 기능을 확장할 시점도 함께 정하겠습니다.

화면과 설계 근거

확정 대기 예약과 처리할 일을 확인하고 여러 예약을 바로 확정하도록 구성했습니다.
홈·예약 확정확정 대기 예약과 처리할 일을 확인하고 여러 예약을 바로 확정하도록 구성했습니다.
날짜별 빈자리와 예약 명단을 확인하고 직접 예약을 추가하도록 구성했습니다.
일자별 상품·예약날짜별 빈자리와 예약 명단을 확인하고 직접 예약을 추가하도록 구성했습니다.
출조 종류·운영요일·가격을 선주가 직접 관리하도록 구성했습니다.
상품 관리출조 종류·운영요일·가격을 선주가 직접 관리하도록 구성했습니다.
기간별 받을 금액과 지급 내역을 확인하도록 구성했습니다.
정산 관리기간별 받을 금액과 지급 내역을 확인하도록 구성했습니다.

09. 예약 취소 진단·재예약 추천

어바웃피싱2026.07~현재

35.9%

개선 전 기준값

회원 직접취소 후 24시간 내 재결제2026.01~08

배경

예약 취소 뒤 같은 회원이 다시 결제하는 행동을 대조해 취소 개선 과제를 정의했습니다.

문제

일정 변경·선주 초과 예약·결제 직후 취소가 같은 취소 수치에 섞여 있어 단순 취소 건수만으로 문제를 판단하기 어려웠습니다.

한 일

취소 유형을 나누고 회원별 취소와 후속 결제를 결제 내역에서 대조했습니다. 취소 사유 안내와 취소 완료 후 같은 선박의 다른 날짜·대체 선박을 추천하는 흐름을 설계했습니다.
2026.10.08 재예약·대체 선박 추천을 배포하고, 10.12 가까운 선박 조회를 후속 수정했습니다.

판단

정한 것: 취소를 막기보다 취소 완료 화면에서 다른 날짜·가까운 선박을 추천해 다시 예약하도록 했습니다.
버린 대안: 회원 취소를 선주 승인이 필요한 「취소 요청」으로 바꾸는 안은 검토 뒤 접고 즉시 취소를 유지했습니다.

기간·인원·역할

기간: 2026.07~현재. 10.08 추천 배포, 10.12 후속 수정.
참여: 기획·프론트엔드·백엔드 협업
내 역할: 취소유형·지표 재정의, 취소 화면·추천 정책, 팀 배포·후속 검토 조율.

결과

개선 전 취소 기록에서 35.9%가 24시간 안에 재결제로 이어지는 패턴을 확인했습니다. 취소를 막는 대신 다른 날짜와 대체 선박으로 예약을 이어가도록 추천 흐름을 설계·배포했습니다. 배포 후 효과는 같은 기준(취소 후 24시간 내 재결제 비율)과 추천 선박 예약 전환으로 판단합니다.

회고

취소 건수만 보면 고객이 날짜를 바꿔 다시 결제하는 행동을 놓칠 수 있었습니다. 다음에는 취소 사유별 재결제와 대체 상품 선택까지 함께 보겠습니다.

화면과 설계 근거

바꾸기 전 취소 완료 화면은 환불 안내와 [예약 내역으로] 버튼만 있어, 취소한 고객이 다시 예약으로 돌아올 길이 없었습니다.
취소 완료바꾸기 전 취소 완료 화면은 환불 안내와 [예약 내역으로] 버튼만 있어, 취소한 고객이 다시 예약으로 돌아올 길이 없었습니다.
취소 완료 화면에 같은 선박의 다른 날짜 달력을 붙여 바로 다시 예약하게 하고, 자리가 없는 날을 고르면 가까운 다른 선박을 추천하게 했습니다.
취소 후 재예약 추천취소 완료 화면에 같은 선박의 다른 날짜 달력을 붙여 바로 다시 예약하게 하고, 자리가 없는 날을 고르면 가까운 다른 선박을 추천하게 했습니다.
바꾸기 전에는 취소 버튼을 누르면 사유 목록만 나와, 날짜만 바꾸려는 고객도 취소부터 해야 했습니다.
취소 사유바꾸기 전에는 취소 버튼을 누르면 사유 목록만 나와, 날짜만 바꾸려는 고객도 취소부터 해야 했습니다.
사유 목록 위에 「날짜 변경은 취소 없이 가능」 안내와 고객센터 번호를 먼저 보여 주고, 직접 취소하면 환불 기간과 좌석이 없을 수 있다는 점을 알렸습니다.
취소 사유사유 목록 위에 「날짜 변경은 취소 없이 가능」 안내와 고객센터 번호를 먼저 보여 주고, 직접 취소하면 환불 기간과 좌석이 없을 수 있다는 점을 알렸습니다.

10. 플랫폼개발팀 접수·QA·배포 운영

어바웃피싱2024.09~현재

접수→배포

접수 → 담당·일정 → QA → 배포 공지

배경

플랫폼개발팀 10명의 제품 개발과 출시 운영을 총괄했습니다.

문제

다른 팀 요청이 개인 메시지와 구두로 흩어져 들어왔고, 기획·디자인·개발이 함께 쓰는 백로그와 QA·배포 규칙이 없었습니다.

한 일

오류는 모니터링 채널, 개선 요청은 개선사항 채널로 나눠 받도록 정했습니다. QA 정책·업무일지 규정·개발 환경 분리를 정의하고 운영 배포의 검수·마감 절차를 정했습니다.
2025년 12월에는 프론트엔드·백엔드 파트장과 PM이 모이는 회의를 열었습니다. 안건을 결정할 때 담당자와 일정을 함께 정하도록 했습니다. 2026년 개발 일정은 화면 수를 기준으로 한 개발 일수와 배포 그룹으로 관리했습니다.
통합 앱 출시일에는 전사 배포 공지 채널을 열었습니다. 운영 배포마다 버전·변경 사항뿐 아니라 서비스 영향·고객 안내·운영 할 일을 남기도록 정했습니다. 직접 만든 팀 스케줄 대시보드에서 이슈 상태·배포 기록·안건별 일정을 함께 확인했습니다.

판단

정한 것: 오류와 개선 요청의 접수 채널을 나누고, 운영 배포는 정해진 검수·마감 시각에 묶었습니다.

기간·인원·역할

기간: 2024.09~현재. 파트장 회의 2025.12부터, 전사 배포 공지 2026.09.09부터.
참여: 플랫폼개발팀 10명 총괄, 프론트엔드·백엔드 파트장·PM 및 기획·디자인·개발 협업.
내 역할: 요청 접수·QA·업무 기록·개발 환경·배포 규칙, 회의·담당·일정·우선순위 총괄.

결과

개인 메시지·구두로 흩어졌던 요청을 공통 접수·담당·일정·QA·배포 절차로 연결했습니다. 제품팀 밖에서도 처리 상태와 서비스 변경 내용을 확인하도록 운영 방식을 바꿨습니다.

회고

배포 내용을 검색으로 다시 찾을 수 있도록 텍스트 공지를 요청하고, 기획팀 외 직군도 요청을 대시보드에 등록해 공유 이력을 남기도록 운영 규칙을 보완했습니다.

화면과 설계 근거

요청을 프로젝트 단위로 묶고 기획·디자인·개발·QA의 진행 상태를 함께 확인합니다.
완료 프로젝트와 진행 단계요청을 프로젝트 단위로 묶고 기획·디자인·개발·QA의 진행 상태를 함께 확인합니다.
기획부터 QA까지 단계별 기간과 출시 목표일을 한 프로젝트에 연결합니다.
통합 출시의 단계별 일정기획부터 QA까지 단계별 기간과 출시 목표일을 한 프로젝트에 연결합니다.
심각도와 처리 상태로 이슈를 분류하고 검증·배포 대기·완료 흐름을 관리합니다.
QA 이슈의 검증·완료 흐름심각도와 처리 상태로 이슈를 분류하고 검증·배포 대기·완료 흐름을 관리합니다.
배포 버전·날짜·포함 기능을 남겨 어떤 변경이 언제 적용됐는지 추적합니다.
버전별 배포 기록배포 버전·날짜·포함 기능을 남겨 어떤 변경이 언제 적용됐는지 추적합니다.

11. 가입·로그인 흐름 개편

어바웃피싱2025.02~2025.04

28.4 → 61.3%

Android 첫 실행 대비 가입자 비율

전후 각 7일

배경

낚시 박람회를 앞두고 새로 유입될 설치 고객을 회원으로 연결할 필요가 있었습니다.

문제

비회원도 깊은 범위까지 열람할 수 있어 가입할 이유가 약했고, 가입 절차도 길었습니다.

한 일

가입·로그인의 핵심 화면과 사용자 흐름을 직접 설계하고, 앱·서버 개발과 상세화·구현을 진행했습니다.
비회원의 열람 범위를 조정하고 카카오·애플 간편 로그인 중심으로 흐름을 바꿨습니다. 카카오 전화번호 수집 승인을 받아 별도 입력 단계를 줄였습니다.
박람회 전 강제 업데이트에 우선 반영했습니다. 짧은 기간에 강제 업데이트를 반복하는 것을 피하도록 후속 수정은 선택 업데이트로 진행했습니다. 기획과 앱·서버 개발이 협업해 2월과 4월 업데이트에 반영했습니다.

판단

정한 것: 박람회 전에 필수 업데이트로 먼저 반영하고, 후속 수정은 선택 업데이트로 냈습니다.
버린 대안: 짧은 기간에 필수 업데이트를 두 번 하는 안은 사용자 이탈 위험이 커서 택하지 않았습니다.

기간·인원·역할

기간: 2025.02~04, 간편 로그인 개편 및 후속 앱 업데이트
참여: 기획과 앱·서버 개발 협업.
내 역할: 비회원 열람·간편 로그인·업데이트 범위 결정, 가입·로그인 화면 설계.

결과

간편 로그인·전화번호 입력 단축·가입 보상을 함께 적용한 뒤, Android 첫 실행 대비 가입자 비율이 28.4%에서 61.3%로 높아졌습니다.

회고

가입 기능을 고치는 일과 기존 고객의 업데이트 부담을 함께 봐야 했습니다. 필수 변경을 먼저 반영하고 후속 수정은 선택 업데이트로 나눴습니다.

화면과 설계 근거

바꾸기 전 첫 화면에는 「시작하기」와 「둘러보기」만 있어, 가입하려면 휴대폰 인증부터 차례로 거쳐야 했습니다.
바뀌기 전·이전 시작 화면바꾸기 전 첫 화면에는 「시작하기」와 「둘러보기」만 있어, 가입하려면 휴대폰 인증부터 차례로 거쳐야 했습니다.
첫 화면에 카카오·Apple로 시작하기를 맨 앞에 두고, 다른 방법 로그인과 둘러보기는 그 아래로 내렸습니다.
바뀐 뒤·간편 로그인 시작첫 화면에 카카오·Apple로 시작하기를 맨 앞에 두고, 다른 방법 로그인과 둘러보기는 그 아래로 내렸습니다.
바꾸기 전에는 휴대폰 인증·약관 동의 뒤에 닉네임과 이메일을 직접 입력해야 가입이 끝났습니다.
바뀌기 전·이전 기본정보 입력바꾸기 전에는 휴대폰 인증·약관 동의 뒤에 닉네임과 이메일을 직접 입력해야 가입이 끝났습니다.
가입이 끝나면 웰컴 기프트 도착을 바로 알려 첫 사용으로 이어지게 했습니다.
가입 완료가입이 끝나면 웰컴 기프트 도착을 바로 알려 첫 사용으로 이어지게 했습니다.

12. 예약 성장을 위한 광고 전략·예산 배분

어바웃피싱2026.08~현재

매체 비교를 GA4 예약 결제 한 기준으로 통일

배경

예약 성장을 위해 광고 실무가 집중할 소구점과 매체별 예산 우선순위를 정했습니다.

문제

매체별 보고 수치와 GA4의 귀속·집계 기준이 달라, 어떤 광고와 매체에 예산을 집중할지 공통 기준이 필요했습니다.

한 일

시즌·어종·선박별 예약 상품의 소구점을 실무진에게 제시하고, 광고에서 강조한 조건이 실제 선박 상세와 예약 흐름으로 이어지도록 방향을 조정했습니다.
광고 실무·소재 제작·측정 구현의 담당을 나누고, 매체별 자체 보고 수치 대신 GA4의 공통 예약 결제 기준으로 비교하도록 정했습니다.
성과와 측정 차이를 검토해 2026년 10월 메타 예산 축소·PMax 예산 확대 방향을 정했습니다. 개별 선박 광고의 키워드·랜딩 실험 기준과 집행 한도도 조정했습니다.

판단

정한 것: 매체별 자체 보고 수치 대신 GA4의 예약 결제 한 기준으로 매체를 비교했습니다.
버린 대안: 매체 화면 수치로 각각 판단하는 방식은 귀속 기준이 달라 같은 결제를 겹쳐 셀 수 있어 버렸습니다.

기간·인원·역할

기간: 2026.08 광고 업무 인수~현재. 개별 선박 실험 기준 공유 10.12, GA4 비교 기준 공유 10.14.
참여: 광고 방향·예산·판단 기준은 본인이 정하고, 집행·소재 제작은 마케팅 담당, 추적 구현은 측정 담당.
내 역할: 광고 소구점과 우선순위 제시, 예약 결제 기준의 매체 비교, 예산 배분 조정 및 실행 결과 검토.

결과

매체 비교를 GA4 예약 결제 한 기준으로 통일

광고 실무진이 집중할 소구점과 예약 결제 기준의 성과 판단 체계를 정리했습니다. 이를 바탕으로 2026년 10월 메타 예산 축소·PMax 예산 확대를 결정하고, 개별 선박 광고 실험 방향을 조정했습니다.

회고

매체 화면과 GA4의 귀속 기준 차이를 확인해 비교 기준을 통일했습니다. 개별 선박 광고는 키워드와 실제 선박 랜딩을 연결하는 실험 기준을 따로 정했습니다.

화면과 설계 근거

상품의 차별점·가격·시즌을 정리하고 실무진이 사용할 메시지와 표현 기준을 전달했습니다.
광고 소구점 전달상품의 차별점·가격·시즌을 정리하고 실무진이 사용할 메시지와 표현 기준을 전달했습니다.
예산과 누적 집행을 함께 보고 매체별 예산 판단에 활용했습니다.
광고 예산 페이스예산과 누적 집행을 함께 보고 매체별 예산 판단에 활용했습니다.
같은 기간의 광고비와 GA4 예약 성과를 매체별로 비교했습니다.
광고비·GA4 성과 대조같은 기간의 광고비와 GA4 예약 성과를 매체별로 비교했습니다.
매체별 비용과 성과, 월 예산과 집행 페이스를 함께 확인했습니다.
전체 매체 예산·성과 시트매체별 비용과 성과, 월 예산과 집행 페이스를 함께 확인했습니다.

13. Noti통합 알림 시스템

웍스메이트2023.08~2023.11

부서별 푸시·문자 발송을 한 곳으로(2023.11)

배경

매칭·마케팅·데이터팀이 고객에게 알림을 보내는 도구를 따로 사용했습니다.

문제

발송 대상과 이력이 흩어져 있었고 문자 중심 발송을 공통 시스템으로 바꿔야 했습니다.

한 일

푸시·문자의 발송·수정·예약·이력 화면과 대상 조회 흐름을 기획했습니다.
기본 발송 → 템플릿 → 대상 분류로 개발 범위를 나눴습니다. 동의 여부·OS·국적 등 조건으로 대상을 선택하고 반복 안내를 템플릿으로 관리하도록 구성했습니다.
부서별 알림을 하나의 화면으로 모으고 문자 중심 업무를 푸시와 함께 운영하도록 전환해 2023년 11월 출시했습니다.

판단

정한 것: 기본 발송 → 템플릿 → 대상 분류 순으로 나눠 만들고, 문자 중심 발송을 푸시 중심으로 바꿨습니다.

기간·인원·역할

기간: 2023.08~2023.11
참여: 기획·디자인·개발·QA 및 운영 담당과 협업
내 역할: PO, 범위·정책·화면·발송 대상·템플릿·출시 기획

결과

부서별로 나뉜 푸시·문자 발송과 이력을 한 시스템에서 확인

부서별로 나뉜 발송과 이력을 한 시스템에서 확인하도록 통합하고, 2023년 11월 출시했습니다. 문자 중심 업무를 푸시와 함께 운영하고 발송·템플릿·대상 분류를 공통 흐름으로 구성했습니다.

회고

알림 화면보다 누가 어떤 조건으로 발송할 수 있는지 정하는 일이 먼저였습니다. 다음에는 발송부터 수신과 후속 행동까지 이어지는 확인 기준도 함께 설계하겠습니다.

화면과 설계 근거

푸시 발송내역(통합·전체)
푸시 수정: 예약상태
발송대상 조회 모달
문자 수정: MMS·발신번호
발송대상 내역: 동의·OS·국적
푸시 템플릿 만들기
세그먼트 만들기: 타겟 조건
푸시 발송내역: 통합·성과지표

14. AI 예약 상담 SONA

어바웃피싱2026.07~현재

단독 기획·구현, 론칭 준비 중(2026.07~)

배경

축적된 낚시·예약 정보를 활용해 고객의 조건에 맞는 상품을 추천하고, 상담을 실제 예약·결제로 연결하는 AI 상담 서비스를 기획했습니다.

문제

고객이 날씨·어종·선박 정보를 따로 찾아본 뒤 예약 상품을 다시 검색해야 했습니다. 출조 선택에 필요한 정보와 구매 가능한 상품을 대화 안에서 연결하고자 했습니다.

한 일

지역·날짜·어종 등 고객 조건을 바탕으로 선박과 예약 상품을 찾는 대화 흐름을 직접 기획·구현했습니다.
날씨·물때·선박·어종 정보를 함께 제공하고, 추천한 상품의 상세와 결제 단계로 이동하는 흐름을 설계했습니다.
관광 벤처 지원사업 점검과 IR에서 시연하고, 실제 서비스 론칭을 준비하고 있습니다.

판단

정한 것: 실제 결제·로그인·실시간 연동은 빼고, 대화로 배를 찾는 경험만 시제품으로 검증했습니다.

기간·인원·역할

기간: 2026.07~현재, 론칭 준비 중
참여: 1명, 기획·개발·배포 단독 담당
내 역할: 추천·상품 탐색·예약 연결 흐름의 기획·구현 전 과정 단독 담당.

결과

단독 기획·구현, 론칭 준비 중

대화형 상품 탐색과 추천 화면을 구현해 시연했습니다. 예약 거래 확대를 목표로 론칭을 준비 중입니다.

회고

정보를 풍부하게 제공하는 것보다 고객이 예약할 수 있는 상품을 찾게 하는 것이 중요합니다. 론칭 후에는 추천 상품의 상세 진입과 예약·결제 연결을 우선 확인하겠습니다.

화면과 설계 근거

SONA 첫 화면. 전국 최근 3일 회원 조과 4건과 어종별 막대그래프, 조과 사진 카드, 조과 지도와 근처 배 보기 버튼.
첫 화면 회원 조과들어오면 최근 3일 동안 회원이 올린 조과를 어종별 건수와 사진으로 보여 줍니다. 조과 지도와 근처 배 보기로 이어집니다.
SONA 답변. 이번 주말 인천에는 맞는 배가 없어 11월 8일 충남 오천항 씨앤미호를 제안하고, 1인 90,000원, 쿠폰 적용가 160,000원, 남은 자리 2석을 카드로 보여 줌.
배 찾기 대화「이번 주말 인천 쭈꾸미」처럼 물으면 조건에 맞는 배를 찾고, 없으면 다른 날짜와 항구를 제안합니다. 카드에서 남은 자리와 쿠폰 적용가를 보고 예약하기로 넘어갑니다.
SONA 선박 요약. AI 표시가 붙은 이 배 한눈에 카드에 씨앤미호의 출항 시간, 요금, 잔여석, 시설, 대여 장비를 한 문단으로 정리하고 근거를 어바웃피싱 예약 정보로 표시.
이 배 한눈에 AI 요약배를 고르면 출항 시간, 요금, 남은 자리, 시설과 대여 장비를 AI가 한 문단으로 정리합니다. 조황 글이 없으면 없다고 쓰고 근거를 함께 표시합니다.
SONA 날씨 답변. 11월 8일 인천 바다 구름 조금, 물때 4물, 만조와 간조 시각, 일출과 일몰 시각, 11월 8일 인천 배 보기 버튼.
출조일 물때와 날씨출조일의 날씨, 물때, 만조와 간조, 해 뜨고 지는 시각을 한 화면에 보여 줍니다. 바람과 파고 예보가 아직 없으면 출항 판단은 선사 확인으로 안내합니다.

일하는 방식

회사가 바뀌어도 같았던 세 가지입니다.

01
범위를 먼저 좁힌다
자원이 적을수록 무엇을 만들지 않을지 먼저 정합니다. ERP는 청구·지급만, 예약은 고객 예약웹과 운영 어드민부터 만들었습니다.
02
숫자가 맞는지 먼저 본다
값이 서로 다르면 결제 기록까지 내려가 확인합니다. 매체별 귀속 차이를 확인하고 GA4 예약 결제 이벤트를 공통 비교 기준으로 정했습니다. 같은 이름의 숫자가 여러 개면 정의부터 정리합니다.
03
반복 확인은 자동화한다
지표 대시보드, 스케줄 대시보드, 채널 요약봇, 모니터링봇을 혼자 만들어 매주 사람이 하던 숫자 확인과 화면 점검을 도구에 맡겼습니다.