2025년 9월 근황
출시 한 달 소회, 수직적 확장과 AI Natives PM
목차
1. 오픈 한 달 차 데이터 분석, 퍼널 재설계
2. 수직적 확장을 시도하는 중
3. 조직에 적용할 방법론을 고민 중: AI Natives PM
1. 오픈 한 달 차 데이터 분석, 퍼널 재설계
출시 한 달 새 H.X에 많은 개선을 진행했다. 그리고 H.X의 초기 퍼널들을 다시 한 번 점검하는 시간을 가졌다. 에이치닷 플랫폼과 연동된 전략을 실행했기에 유입 자체는 어느 정도 확보했다. 그러나 전환율을 들여다보니 상황은 달랐다. 고객 획득 과정에서 CVR은 기대보다 훨씬 낮았기 때문이다. '유입=그로스'가 아니라는 걸 머리로는 알고 있었지만, 실제 데이터 앞에 서면 언제나 핏을 찾는 과정이 어렵게 다가온다.
H.X는 제품 운영 경험이 쌓인 사람들이 만든 만큼, 매 스텝마다 추적 이벤트가 잘 심겨 있다. 한 달간의 데이터를 분석하니 이탈률이 높은 구간 두 곳이 뚜렷하게 보였다. 첫째는 유입 직후 채팅 단계, 둘째는 검색 이후 인증 단계였다. 어느 쪽도 예상 밖은 아니었지만, 실제로 고객이 어디서 이해를 놓치는지를 데이터로 확인하니 설득력이 달랐다.
다행히 기존 고객사 풀을 활용해 초반 사용자 인터뷰를 병행할 수 있었다. 고객의 언어로 들어보니, 단순히 ‘버튼 위치’ 같은 UX 문제보다 ‘왜 이 과정을 거쳐야 하는지’라는 설득의 부재가 컸다. 결국 플로우를 다시 설계하여 기획·개발을 병행해 개선안을 배포했고, 지금은 그 결과를 지켜보고 있다.
한편으로는 '유의미한 타깃 고객의 유입'도 절실했다. SA나 DA 중심으로 롱테일 키워드 광고를 검토했지만, 도메인 특성상 검색량은 적고 예상 ROAS는 낮았다. 단기 노출 확대보다는 먼저 경험을 다듬고, 세그먼트를 뾰족하게 정의하는 것이 옳다고 판단해 광고는 보류했다.
이번 경험에서 다시 배웠다. 제품 초기의 그로스는 광고비만 태운다고 해결되지 않는다. 결국 고객도 스스로 표현하지 못하는 불편을 찾아내고, 경험 설계를 통해 풀어야 한다. 숫자가 보여주는 냉정함은 아팠지만, 그 덕에 다음으로 가야 할 방향이 분명해졌다. 9월은 그렇게 달린 것 같다.
2. 수직적 확장을 시도하는 중
H.X의 최초 전략은 기업 고객이 스스로 찾아와 사용하는 PLG(Product-Led Growth) 모델이었다. 기업의 자발적 유입을 전제로 했지만, 실제 시장의 반응은 (역시나 그렇듯) 희망과 다르다. 콘텐츠 발행 등과 같은 마케팅을 병행하는 것과 동시에 세일즈에서 드라이브를 걸었지만, 사업적 접근이 멈추면 이 휠 또한 금세 멈췄다. 단기간에 검증하기엔 문제의 정의도 많이 컸던 비즈니스인 것 같다.
데이터를 검증하는 과정 속에서 타깃 정의의 문제도 드러났다. 초기 설정한 고객군이 제품과 완전히 적합하지는 않았고, 실행할수록 '타깃 고객군의 폭이 넓다'는 한계가 드러났다. 결국 고객 세그먼트를 더 좁히는 것이 필요하다고 결론지었다.
다행인 점은 사업 측에서 제안하던 신사업 전략과 제품의 상황을 맞물려 보니, 특정 시장을 버티컬하게 확장하는 모델을 도출해낼 수 있었다. 다음 방향이 얼추 정해진 것인데..
기업과 구직자를 동시에 상대해야 하는 양면 시장의 구조적 특수성이란 부담은 여전히 존재한다. 그래서 아직 사업 전략의 수요 검증과 고객 인터뷰가 더 필요한 상황이다. 다만 이전처럼 막막하게 넓은 판에서 헤매는 기분은 아니니 상황은 이전보다 나은 편.
일단 할 일은 타깃한 세그먼트의 고객(기업, 구직자) 인터뷰를 더 진행하고, 제품 플로우 전체를 전방위적으로 개선하는 것이 필요하다. 최소한 방향을 좁힘으로써 실행 단위가 뚜렷해졌다는 점은 분명하다.
명절 동안 전력과 할 일을 좀 다듬어 보고, 명절 이후엔 주에 한 번 정도는 사업 담당자와 함께 기업 고객 인터뷰를 돌 생각이다. 그들이 영업하는데 동석을 요청했으니, 기술자문이란 명분으로 참여하여 고객의 니즈와 시장 온도를 피부로 느껴볼 생각. 이게 내 4분기 도전거리인 것 같다.
3. 조직에 적용할 방법론을 고민 중: AI Natives PM
최근에 두 개의 영상을 인상 깊게 봤다. Maven의 'Cursor isn’t just for coding: How AI-native PMs work'과 진용진님의 'PM을 위한 Cursor 활용법'이다. 두 영상 모두 Cursor를 단순한 개발 도구가 아닌, AI와 협업하는 문서 기반 작업 환경으로 확장해 활용하는 방법을 다룬다.
대부분의 PM은 Confluence나 Notion 같은 Wiki형 문서 툴을 사용한다. 하지만 LLM을 제품 관리에 접목하려 할 때 항상 부딪히는 지점은 ‘맥락(Context)’이다. 사실 GPTs나 Gem, Project 기능을 이용해 System Instruction과 LLM이 참고하는 문서 파일만 잘 관리해도 비슷하게 활용할 수 있다. 그러나 시간이 지남에 따라 제품의 상태나 코드베이스가 바뀌며 문서가 바뀌는데, 그런 문서를 일일이 찾아 상시 업데이트하는 건 제품과 프로젝트의 단위가 커짐에 따라 어려워진다는 것.
이 지점을 위 방법론에선 Cursor를 활용한 문서 중심 구조로 풀어낸다. 기존 LLM 클라우드 서비스들이 채팅 스레드 기반으로 컨텍스트를 이어가는 반면, Cursor는 문서를 중심으로 AI가 지속적으로 업데이트하는 구조를 갖고 있다는 게 가장 큰 차이점이다. 즉, 문서가 단순히 보관되는 파일이 아니라 AI가 함께 진화시키는 지식 자산이 된다.
영상 속 방법론은 조직 단위의 전략 문서에서 시작해 프로젝트 레벨로 연결하는 방식인데, 나는 이 구조를 현재 조직의 상황에 맞게 변형해 보고 있다. 목표는 거창한 AI 조직화보다는, 'PM 본인이 생산성을 높이고, 필요할 때 개발자나 디자이너도 기획(기획서 제작~프로토타이핑)을 수행할 수 있는 구조'를 만드는 것이다. 명절 동안 관련 자료와 우리 조직의 문서 관리 방식을 일부 사용하여 현재 작업 중인 프로젝트의 일부 PRD 제작까지 실행해 볼 계획이다.
Cursor 프로젝트 세팅 ⓒ작가편집간단히 설명하면, 현재 설계한 방식은 프로젝트 루트에 'docs/'와 'mdc/' 두 축을 두는 형태다:
docs/는 서비스의 핵심 지식과 정책을 관리한다. (core_policy, screen_policy, strategy 등)
mdc/는 Cursor용 명령어 템플릿을 관리한다.
사용 예시, 아직 출력 방식 등을 손보지 않은 상태 ⓒ작가편집이를 통해 AI 명령어를 자산화할 수 있는데, 팀이 동일한 형식으로 AI를 호출할 수 있게 된다는 장점이 있다. (개발자가 사용 타깃 중 하나인 만큼, Git 형태의 버전 관리 또한 고려 중이다.). 만약 정책 변경이 필요한 경우, Cursor에서 챗을 열고 '정책 업데이트'를 분명하게 말하면 AI가 기존 정책을 불러와 변경 범위만 업데이트한다. 기존에 사람이 수동으로 문서를 찾아 수정하던 흐름을 대체하는 것이다.
Markdown Cursor란 의미를 지닌 .mdc 확장자를 가진 파일은 커서 내에서 System Instruction(프롬프트) 역할을 한다. 직접 @를 사용해서 멘션하는 방법도 있고, mdc 파일 내에 파일에 대한 설명(description 파라미터)을 작성함으로써, 자동으로 멘션되게 할 수도 있다.
처음에는 기존에는 코드 자체를 Context로 정책서와 동기화하는 방법을 고민했으나, 코드 구조상 모듈/컴포넌트화가 잦은 만큼 Context 호출 구조상 제약이 많았다. 그래서 이번에는 제품의 백본 정책(계정, 결제, 멤버십 등)을 중심으로, Cursor 내에서 mdc 파일을 호출해 그때그때 필요한 맥락을 보강하는 방식을 시도할 생각이다.
결국 Cursor를 단순한 AI IDE가 아니라, 지속적으로 진화하는 문서 시스템 + 컨텍스트 관리 도구로 만들 생각이다. 효율적이고 효과적으로 일하는 것을 통해, 본질에만 더 집중할 수 있는 환경을 만드는 것이 목적. 좋은 영상 덕분에 새로운 시도거리가 생겨 기쁘다.
ⓒ 2025. 327roy All rights reserved.
