Business Operating System

사업부를 맡으며 가장 먼저 답답했던 것은 숫자와 일정이 없는 게 아니라 서로 떨어져 있다는 점이었습니다. 현황은 보였지만 무엇을 누가 언제 결정하고 실행해야 하는지는 흐렸습니다.

프로젝트 관리 문서를 하나 더 만드는 것으로 끝내고 싶지 않았습니다. 고객이 어떻게 행동했고 사업 숫자가 어떻게 바뀌었는지 확인한 뒤, 그 결과를 ‘무엇을 먼저 할지, 누가 맡을지, 언제까지 끝낼지’로 바로 연결했습니다.

2025 월평균 로그인 사용자

40.2만

2025 연간 결제

103.8만건

한 달에 한 번 이상 결제한 고객

3.27만

결제 고객 1명·1개월당 평균 구매

2.65건

2025년 월평균 로그인 사용자는 전년보다 1.2% 줄었지만 포스 매출은 25.7% 줄었습니다. 사용자 수의 변화만으로는 매출 하락 폭을 설명할 수 없어서, 저는 매출을 ‘한 달에 결제한 고객 수’와 ‘그 고객 한 명이 쓴 평균 금액(ARPPU)’으로 나눠 봤습니다.

여기서 결제자월은 한 달에 한 번이라도 결제한 사람 수를 매달 더한 값입니다. 같은 사람이 1월과 2월에 결제했다면 두 번으로 셉니다.

이 결제자월은 전년보다 18.4%, ARPPU는 8.9% 낮았습니다. 기존 사용자월은 1.9% 늘었지만 기존 고객 결제율은 1.89%p 낮아졌습니다. 그래서 신규 유입과 별개로 기존 고객의 전환·구매 빈도·구매 가치를 회복하는 일을 핵심 과제로 잡았습니다.

기존 고객 포스 매출 비중

91.1%

기존 고객 월간 재방문율

68.6%

신규 고객 다음 달 재방문율

24.8%

팀과 함께 사업 지표, 전체 프로젝트, 스프린트, 마일스톤, 심사 일정과 부서 간 의존 관계를 한 화면에서 검토했습니다.

연간 메인 과제는 CEO가 확정한 방향을 기준으로 운영했습니다. 그 안에서 최우선 과제에 자원을 집중하고 나머지 순서를 조정했습니다. 과제 수와 자원 비율은 적용 범위를 설명할 수 있을 때만 증거와 함께 제시합니다.

사업 영향에 따라 승인과 에스컬레이션 수준을 나누고, 프로젝트 안에서는 DACI로 역할을 구분했습니다. Driver는 최종 결정권자가 아니라 계획과 킥오프, 회의를 이끌고 의견을 모아 일을 배정하며 진행 상황을 추적했습니다. Approver는 최종 결정을 내리고, Contributor는 전문 정보를 보태며, Informed는 진행과 변경 사항을 공유받았습니다.

첨부 자료가 확인하는 범위는 2023년 디자인 길드에서 DACI와 Driver의 운영 원칙을 공유했다는 점입니다. 회사 전체 표준이나 특정 프로젝트의 성과로 확대해 말하지 않습니다. 아래 브리프는 그 원칙을 바탕으로 실명·프로젝트명·수치·일정을 제거해 재구성했습니다.

매주 팀과 함께 사업 지표와 프로젝트 상태를 같은 흐름에서 검토했습니다. 보고는 문서 작성이 아니라 이번 주 결정, 담당자, 기한과 실행 조건의 합의로 끝냈습니다.

팀에서는 사업 개발, 서비스 운영, 이터레이션 진행 상태를 주간 보고 보드에서 함께 확인했습니다. 아래 원본 화면은 실제로 어떤 항목을 놓고 진행 상황을 맞췄는지 보여줍니다.

액션 푸시는 유저가 특정 기능을 사용했을 때 푸시 알림으로 할인권을 선물하는 CRM 기능입니다. 어떤 행동을 조건으로 삼아야 실제 사용으로 이어지는지 확인하기 위해 타겟팅을 바꿔 봤습니다.

같은 20% 할인권을 유지한 채 검색 접점에서 ‘프리미엄 상세 3회 이용’ 접점으로 타겟팅을 좁혔습니다. 쿠폰 발급은 14,196건에서 7,305건으로 48.5% 줄었지만, 사용은 308건에서 708건으로 129.9% 늘었고 발급 대비 사용률은 2.17%에서 9.69%로 높아졌습니다.

반면 무료 아이템 1회 이용자를 3회 이용자로 좁힌 경우에는 사용률이 0.34%에서 0.70%로 올랐지만 발급이 66.8% 줄어 총사용은 31.2% 감소했습니다. 그래서 사용률만 높이는 게 아니라 도달 규모와 실제 총사용을 함께 보고 다음 타겟팅을 정했습니다.

쿠폰 발급

14,196 → 7,305

쿠폰 사용

308 → 708

발급 대비 사용률

2.17% → 9.69%

무료 아이템 타겟팅 사용률

0.34% → 0.70%

팀과 함께 2주 단위로 출시를 관리했습니다. 출시 후 2주와 4주에는 결과와 가설을 나눠 보고, 그 결과로 다음 과제를 계속할지, 고칠지, 멈출지 정했습니다.

보고서보다 더 나은 결정이 반복되게 하는 것이 이 운영 방식의 목적이었습니다.

여기 제시한 사업 규모와 고객 구조는 팀이 운영한 서비스의 기준선이며 제 개인 단독 성과가 아닙니다. 정식 Enterprise PMO 직함이나 전사 P&L·RAID·Capacity Planning 책임도 제가 맡았다고 주장하지 않습니다.

CRM 수치는 순차 관찰이며 무작위 대조군이 없습니다. 사용률의 분모는 유니크 사용자가 아니라 쿠폰 발급 건수입니다. 쿠폰 사용 뒤 귀속된 포스도 액션 푸시가 새로 만든 매출이라고 해석하지 않습니다.

의사결정 시간 단축이나 처리량 개선의 전후 수치는 아직 없습니다. 따라서 이 사례에서 말할 수 있는 범위는 Product Business 역할 안에서 데이터 진단을 실제 팀 운영으로 옮긴 방식입니다.