AI가 개발 진입장벽을 깎아내리면서 제품을 만들고 출시하는 일은 쉬워졌다. 스토어에는 출시된 제품과 출시를 기다리는 제품이 쌓여 있다. 그래서 출시가 마일스톤이자 KPI이던 시대는 끝났다. 엔터프라이즈에서는 원래도 출시가 끝이 아니었다. 진짜 질문은 하나다. 이 제품을 출시 이후에 어떻게 끌고 갈 것인가.
운영은 유지보수가 아니다
운영을 보통 이렇게 생각한다. 서버를 모니터링하고, 장애에 대응하고, 출시한 뒤엔 돈을 부어 노출을 늘리는 것. 셋 다 운영의 본질이 아니다. 운영은 유지보수도 물량전도 아니라 체계적인 개선 사이클이다.
사이클은 다섯 단계다.
분석 → 발견 → 도출 → 결정 → 개선데이터를 분석해 문제를 발견하고, 개선 과제를 도출하고, 무엇을 할지 결정하고, 반복해서 개선한다. 이 다섯 단계를 매주 돌리는 게 운영이다.
데이터 없는 운영은 도박이다
IT 비즈니스를 처음 하는 팀일수록 감으로 운영하기 쉽다. 문제는 의사결정자의 직관과 실제 데이터가 어긋나는 경우가 잦다는 것이다. “이게 시급하다, 이것부터 해달라”는 요구가 올라와도 일단 데이터부터 여는 이유가 여기 있다.
예를 들어 “회원가입이 어렵다, 간편로그인만 남기자”는 요구가 들어온다. 막상 가입 전환율을 열어 보면 82%다. 이건 문제가 아니다. 82%를 90%로, 100%로 끌어올리는 데 드는 리소스 대비 효과는 거의 없다. 감에 기대 멀쩡한 구간을 손대는 건 전형적인 낭비다.
어떤 데이터를 보나
그로스해킹의 AARRR을 본다.
유입 → 활성화 → 유지 → 수익 → 추천- 유입(Acquisition): 사용자가 어디서, 어떤 경로로 들어오는가
- 활성화(Activation): 들어온 사용자가 핵심 가치를 처음 경험하는가
- 유지(Retention): 한 번 쓴 사용자가 다시 돌아오는가
- 수익(Revenue): 그 사용이 돈으로 이어지는가
- 추천(Referral): 사용자가 새 사용자를 데려오는가
트래픽이 유지되는 걸 넘어, 실제로 수익이 나는지, 추천으로 신규 유입이 들어오는지까지 본다. 가입·다운로드·MAU·DAU는 성과로 내세우기 좋아 보이지만, 오히려 진짜 문제를 가리는 함정이 되곤 한다.
퍼널을 펼치면 어디가 문제인지 드러난다. 방문 1만 명이 들어와 2천 명이 가입하고, 그중 300명이 핵심 기능을 쓰고, 50명이 다시 온다고 하자.
| 구간 | 인원 | 전환율 |
|---|---|---|
| 방문 | 10,000명 | - |
| 가입 | 2,000명 | 20% |
| 기능 사용 | 300명 | 15% |
| 재방문 | 50명 | 17% |
전환율이 가장 낮은 구간은 기능 사용(15%)이다. 그러니 첫 번째 개선 과제는 핵심 기능의 사용성이어야 한다. 가입(20%)도 낮으니 과제로 잡을 수는 있지만, 우선순위는 핵심 기능 쪽이다. 그런데 대부분은 보고하기 좋은 지표, DAU·MAU·가입 전환율을 문제라고 착각하고 거기에 매달린다. 많은 제품이 실패하는 이유가 여기 있다. 방문에서 가입까지만 꽃길로 다져 놓고, 정작 핵심 기능 사용과 재방문은 방치한다.
무엇부터 개선할 것인가
개선 과제 후보가 여럿일 때 순서를 정하는 한 가지 도구가 Impact-Effort 매트릭스다. 가로축에 투입 리소스, 세로축에 유저 임팩트를 놓고 후보를 사분면에 배치한다. 임팩트가 높고 리소스가 적게 드는 게 지금 해야 할 일(Do now)이다.
AI가 바꾼 게 하나 있다. 만들기가 너무 쉬워지다 보니, 안 해도 될 일(Do never)을 우선 과제로 잘못 잡는 오류가 잦아졌다. 쉽게 만들 수 있다는 건 해야 할 이유가 아니다.
RICE로 점수를 매긴다
매트릭스가 직관적인 배치라면, RICE는 같은 판단을 숫자로 환산한다.
RICE Score = (Reach × Impact × Confidence) ÷ Effort- Reach: 얼마나 많은 사용자가 영향을 받는가
- Impact: 사용자 경험이나 비즈니스 성과를 얼마나 바꾸는가
- Confidence: 그 효과를 얼마나 확신하는가
- Effort: 투입 리소스. 앞의 세 값을 이걸로 나눈다
표에서 눈여겨볼 건 ‘AI 추천 기능 추가’다. Impact는 매우 높음(3)으로 회원가입 간소화와 같다. 그런데 점수를 내면 4위로 밀린다. 영향받는 사용자(Reach)가 작고, 투입 노력(Effort)은 5로 가장 크며, 확신(Confidence)은 40%로 가장 낮기 때문이다. 임팩트 하나만 보고 덤비면 안 된다. RICE로 네 값을 나눠 봐야 진짜 우선순위가 드러난다. 앞서 말한 ‘Do never를 우선으로 잘못 잡는 오류’와 정확히 맞물리는 사례다. RICE 점수가 높은 과제부터 순서대로 손대면, 같은 리소스로 더 큰 효과를 낸다.
점수에는 직급이 없다
R·I·C는 결국 의사결정자와 실무자가 같이 정한다. 이때 C레벨이든 고객사든 직책자든 가중치를 두지 않는다. 직급이 높다고 점수가 더 무거워지지 않는다. 점수를 정하는 최소 단위도 직급이 아니라 역할로 짠다. 기획·디자인·개발이 각각 한 자리씩 있는 구조가 권장하는 최소 의사결정 단위다.
좋은 기획은 여기서 갈린다. 무엇을 만들 것인가보다 무엇을 만들지 않을 것인가를 정하는 사람이 좋은 PM이다. 있으면 좋아 보이는 걸 다 만드는 게 아니라, 데이터를 근거로 안 할 것을 쳐낸다.
애자일은 회의가 아니다
매일 스프린트를 돌리고 회고를 하고 칸반이나 Jira를 쓰면 애자일을 한다고 착각하기 쉽다. “애자일 하는데 속도가 안 난다”는 팀은 대개 형식만 애자일이다. 진짜 애자일은 분석·발견·도출·결정·개선 사이클을 작고 빠르게 반복하는 것이지, 회의 문화나 툴이 애자일은 아니다.
운영은 데이터로 진짜 문제를 찾고, 우선순위로 할 일과 안 할 일을 가르고, 작고 빠르게 반복하는 일이다. 있으면 좋아 보이는 것, 내가 만들고 싶은 것, 내가 보고 싶은 숫자를 만드는 건 운영이 아니라 도박이다. 그렇다면 지금 잡고 있는 과제는 데이터에서 나왔나 직관에서 나왔나. 내 퍼널에서 전환율이 가장 낮은 구간은 어디고, 그게 지금 우선으로 두는 일과 같은가.