Lesson Learned (3) - 이벤트 없이 다섯 배가 됐다. 그런데 다시 오게 만들지는 못했다

저는 공동주택 관리 업무를 돕는 AI 서비스 '아파트케어'에서 PO로 일하고 있습니다. 9월에 공고문 자동작성 기능에 '이미지형'을 추가해 배포했고, 얼마 전 팀 회고를 마쳤습니다. 회고 문서에는 지표와 파트별 점수가 남았지만, 거기에 다 담지 못한 배운 점을 따로 정리해 둡니다.

결론부터 말하면, 런칭 이벤트 없이도 공고문 이용자는 약 다섯 배로 늘었습니다. 그런데 이 기능을 만든 원래 이유였던 "다시 오게 만들기"는 아직 풀지 못했습니다.

---

어떤 기능이었나

아파트 관리사무소는 소독, 점검, 명절 안내 같은 소식을 공고문으로 게시판에 붙입니다. 아파트케어는 내용을 입력하면 AI가 A4 문서 형태의 공고문을 만들어 주는 기능을 제공하고 있었습니다.

그런데 두 가지 문제가 보였습니다.

• 문서형은 눈에 잘 띄지 않았습니다. 그래서 소장님들은 만든 공고문을 외부 디자인 도구로 다시 이미지로 만들어 붙이고 있었습니다.
• 공고문을 한 번 만들고 다시 오지 않는 사용자가 절반이 넘었습니다. 재방문의 계기가 될 새로운 가치가 필요했습니다.

그래서 만든 것이 '이미지형 공고문'입니다. 공고 내용을 넣으면 AI가 한 장짜리 안내 포스터를 만들어 주고, "배경을 더 밝게"처럼 말로 수정을 요청할 수 있고, PNG로 내려받아 바로 붙일 수 있습니다. 기존 문서형과 나란히 고를 수 있게 했습니다.

---

1. 진짜 원하던 기능에는 이벤트가 필요 없었다

상황

출시에 맞춰 런칭 이벤트를 준비하고 있었습니다. 만든 포스터를 실제 게시판에 붙인 사진으로 응모하는 이벤트였고, 문자 발송 채널과 경품, 응모 기능의 개발 범위까지 합의해 둔 상태였습니다.

그런데 배포 이틀 전, 이번에는 이벤트를 진행하지 않기로 했습니다. 기능 소개만으로 출시했습니다. 대신 배포를 원래 일정보다 나흘 앞당겼습니다. 소장님들이 추석 연휴 안내문을 만드는 시기에 맞추기 위해서였습니다.

결과

배포 전 20일과 배포 후 20일을 비교했습니다.

• 공고문 이용자 약 5배, 생성 건수 약 5배, 다운로드한 사람 7배
• 서비스 활성 이용자 중 공고문을 쓴 비율 6% → 25%
• 공고문 화면에 들어온 사람 중 실제로 생성까지 간 비율 42% → 71%
• 공고문 이용자 10명 중 9명 이상이 이미지형을 썼습니다. 출시 때 잡은 목표(이미지형 사용률 30%)를 크게 넘었습니다

물론 추석 효과가 섞여 있습니다. 명절 안내문 수요가 몰리는 시기라 숫자가 부풀었을 가능성이 있습니다. 다만 같은 기간 문서형만 쓴 사람은 오히려 줄었습니다. 수요가 이미지형으로 옮겨 간 것은 분명해 보입니다.

솔직한 이야기

사실 이 기능은 소장님들을 만날 때마다 나오던 요청이었습니다. "이런 게 있으면 좋겠다"는 말을 정말 여러 번 들었습니다. 그래도 확신하지는 못했습니다. 원한다는 말이, 출시하면 쓴다는 보장은 아니니까요. 이번에는 그게 숫자로 확인됐다는 점이 가장 반가웠습니다.

배운 점

• 사용자가 이미 제품 밖에서 우회하고 있는 일(외부 도구로 이미지 만들기)을 제품 안으로 들여오면, 끌어오는 장치 없이도 쓴다.
• 이벤트는 수요를 만드는 게 아니라 있는 수요를 앞당기는 도구다. 이번에는 이벤트보다 타이밍(추석)이 더 큰 역할을 했다.
• 요청을 받은 '횟수'보다 사용자가 '이미 대신 하고 있는 행동'이 더 강한 신호다. 다음에는 출시 전에 그 행동을 숫자로 먼저 확인하고 싶다.

---

2. 기능을 쪼개 배포해도, 경계는 함께 정의해야 했다

상황

원래는 이미지형 공고문과 '단지 로고·직인' 기능을 같은 공고문 화면에 함께 넣을 계획이었습니다. 하지만 빨리 내보내기 위해 이미지형을 먼저, 로고·직인은 약 2주 반 뒤에 따로 배포하기로 나눴습니다. 그 자체는 합리적인 선택이었다고 생각합니다.

문제

쪼개고 나니 두 기능이 만나는 지점이 모호해졌습니다.

• 로고 등록 안내를 이미지형에서도 보여줄지, 포스터에 로고를 넣을지를 기획 중간에 다시 정해야 했습니다. 알고 보니 '등록을 유도하는 안내'와 '결과물에 반영하는 것'은 별개의 문제였는데, 처음에 나눠서 정의하지 않았습니다.
• 배포 전 QA에서는 생성 대기 화면의 팁 문구에 아직 출시되지 않은 직인·로고 안내가 들어가 있는 것을 발견했습니다.
• 회고에서 디자인 파트는 "연계된 부분의 기획이 부족했다. 기능을 쪼개더라도 확장될 작업을 고려할 수 있게 함께 정의해 달라"고 했습니다. 개발 파트는 "두 기능의 파일 업로드 코드를 하나로 합쳐 관리했으면 좋았겠다"고 했습니다.
• 기획이 중간에 바뀌었는데, 일정 조율과 변경 내용 전달이 함께 가지 않았다는 지적도 있었습니다.

배운 점

• 배포 단위는 쪼개도, 설계 단위는 쪼개면 안 된다.
• 기능을 나눌 때는 "이번 배포에서 보이는 것 / 숨기는 것 / 다음 배포가 끼워질 자리"를 한 장에 정리해 함께 전달한다.
• 기획이 바뀌면 변경 내역을 버전으로 정리해 디자인·개발에 보내고, 일정에 미치는 영향부터 묻는다.

---

3. 많이 쓰는 것과 다시 오는 것은 다르다

상황

숫자만 보면 성공입니다. 하지만 이 기능을 시작한 이유는 "한 번 만들고 떠나는 사용자"였습니다.

결과

• 이미지형 이용자 중 1건만 만들고 그만둔 비율 64%
• 1~7일 안에 다시 만든 비율 12%

출시 전 문제(절반이 넘는 사용자가 1건만 만들고 떠남)보다 나아졌다고 말할 수 없는 숫자입니다.

해석

공고는 명절, 소독, 점검처럼 일정이 생길 때 필요합니다. 원래 사용 주기가 깁니다. 그래서 20일, 7일 기준으로 재방문을 판정하기는 이릅니다. 출시 때 잡은 목표에도 '다음 달 재사용률'이 있었고, 그 판정은 이제부터입니다.

그래도 분명한 게 하나 있습니다. 이용자 수 그래프만 봤다면 이번 회고를 "성공"으로 닫았을 겁니다. 처음 정의한 문제를 기준으로 다시 보니, 아직 절반만 풀었습니다.

배운 점

• 성공 지표는 출시 전에 정의한 문제에서 나와야 한다. 이용자 수는 결과일 뿐 답이 아니다.
• 재방문을 보는 기간은 실제 사용 주기에 맞춘다. 공고문이라면 월 단위다.
• 좋은 기능은 첫 사용을 만든다. 다시 오게 하는 건 "다음에 필요할 때 떠올리게 하는 장치"다.

---

다음엔 이렇게 하겠다

1. 출시 전에 사용자가 이미 우회하고 있는 행동을 숫자로 먼저 확인한다
2. 기능을 쪼갤 때는 경계 정의를 한 장으로 함께 전달하고, 기획 변경은 버전으로 관리한다
3. 성공 판정은 처음 정의한 문제의 지표로, 사용 주기에 맞는 기간으로 한다

---

마치며

이벤트 없이 출시하기로 했을 때 솔직히 불안했습니다. 결과적으로는 기능 자체가 답이었습니다. 하지만 숫자가 좋을수록 "그래서 처음 문제는 풀었나?"를 다시 묻는 게 PO의 일이라는 걸 이번에 배웠습니다.

다음 회고에서는 재방문 숫자를 들고 돌아오겠습니다.