AI 제품, 출시 이후가 진짜 시작이다

Part 9. 릴리즈 이후 실험과 반복, 제품이 학습하는 구조 만들기

Jul 1. 2025

Part 9. 핵심 요약

1. AI 제품의 진짜 개선은 출시 이후 시작된다. 제품은 사용자와 '함께' 설계되어야 한다.
2. 반복적인 실험 구조와 데이터 해석, 그리고 사용자 피드백을 제품화하는 구조가 필요하다.
3. 피드백은 수집만큼 해석이 중요하며, 실험 가능한 문제로 전환하는 설계가 중요하다.

"아무 말이 없다는 건, 아무 문제 없다는 뜻일까?"

AI 제품을 만들다 보면 사용자의 침묵을 종종 문제라고 인지하지 못한다. 여행 일정을 생성해줬는데 사용자는 아무 반응 없이 나가버리고, 상담 챗봇에게 이야기를 하다가 갑자기 조용해지기도 한다.

문제는, 그 침묵이 진짜 '문제 없음'으로 기록된다는 점이다.

만족해서 나간 걸까? 아니면 목적을 포기한 걸까?

PM은 이 침묵 속에서 원인을 가늠하고, 실험하고, 다시 제품을 학습시켜야 한다.

AI 제품은 출시 이후가 진짜 시작이다.

릴리즈는 완성의 끝이 아니라, 사용자와 함께 다시 설계되는 시작점이다.

1. 반복 가능한 실험 구조

AI 제품의 실험은 다르다. A/B 테스트 하나만으로는 부족하다. 생성형 AI는 예측할 수 없고, 사용자 반응도 정형화되지 않는다. 그래서 단발 실험이 아닌 '반복 가능한' 실험 구조가 필요하다.

동일 입력에 대한 프롬프트 A/B 응답 품질 비교

사용자 세그먼트별 결과 편차 분석

모델 버전 교체 전후 비교

사용자 흐름에서 이탈이 잦은 지점의 로그 기반 추적 실험

위의 예시와 같은 실험이 반복되려면, 팀 전체가 실험-관찰-개선 루틴을 공유해야 한다. 실험은 문화가 아니라 구조다. 시스템으로서 작동하는 실험 구조는 단순히 기능을 붙이기 위함이 아니라, 핵심 경험에 대한 가설을 검증하고, 사용자의 반응을 기반으로 제품을 다듬는 방식이어야 한다.

제품이 릴리즈된 이후에도 계속 로드맵만 보고 움직이는 ‘Feature-driven’ 방식은 위험하다. 진짜 PM은 사용자와 시장 반응을 기준으로 Outcome-driven 사고를 통해 실험과 개선을 설계한다. PM은 이 구조를 팀과 함께 설계하고 실행 가능하도록 체계화해야 한다.

2. 데이터로 엿보는 제품의 상태

AI 제품은 특히 데이터 기반 운영이 중요하다. 사용자 행동, 세션 흐름, 응답 결과, 비용 구조, 모델 로그 등 — 모든 데이터는 제품 개선의 단서가 된다. (자세한 내용은 Part 4-1와 Part 4-2 참고)

그러나 중요한 것은 어떤 데이터를 어떤 기준으로 해석할 것인가다. 기능형 앱과 달리, AI 제품은 목적, 맥락, 인터페이스 형태에 따라 중요 지표가 완전히 달라질 수 있다.

예를 들어:

목적 기반 AI (예: 운동 코치, 여행 일정 생성기 등)
→ 입력-출력의 정확도, 응답 후 액션(재입력 vs. 이탈), 반복 사용률, 전환율

관계형 AI (예: 감정 기반 상담 챗봇, 커뮤니케이션 파트너 등)
→ 사용자 자발적 발화량, 맥락의 깊이(자기 노출 정도), 회차별 대화 시간, 정서적 반응(피드백 포함)

PM은 제품이 어떤 '가치'를 제공하려는지에 따라 '의미 있는 데이터'를 먼저 정의해야 한다.

그 외에 공통적으로 살펴볼 데이터는 아래와 같다.
이 데이터는 단순 수치가 아니라, 문제 정의와 실험 설계의 출발점이다.

✔️ 행동 데이터: 사용자의 실제 이용 흐름, 이탈 지점, 반복 입력, 응답 후 행동

✔️ 사용자 피드백: 직접 남긴 의견뿐 아니라, 오류 직후 행동, 도움말 탐색 등 맥락 피드백

✔️ 모델 데이터: LLM 응답 성공률, latency, 비용 대비 유용성, 프롬프트별 품질/평가(Evaluation) 결과

정답은 없더라도, 단서는 언제나 데이터에 있다.

PM은 이 단서를 해석하고 연결하여, 다음 가설을 세울 수 있어야 한다.

3. 사용자 피드백 — 수집보다 설계, 설계보다 해석

AI 제품의 피드백은 기다리는 것이 아니라 설계하는 것이다. 사용자는 그냥 탈퇴하거나 앱을 삭제하는 것이 더 쉬운 선택일 수 있다. 좋은 피드백 구조는 제품 곳곳에 자연스럽게 녹아 있어야 한다. 단순히 좋아요 버튼이나 form 제출 만으로는 부족하다. 사용자 경험과 플로우를 고려한 다양한 설계를 고민해야 한다.

특히 충분히 설계해둬야 하는 이유가 있다. AI 제품에서는 사용자가 오류를 시스템의 문제라기보다 자신의 입력 탓으로 돌리는 경향이 있다. 예를 들어, 여행 일정을 생성하는 AI가 엉뚱한 계획을 제시했을 때, 사용자는 “내가 제대로 입력하지 않았나?”라고 스스로를 의심하며 피드백 없이 이탈해버리는 경우가 많다. 문제는 이런 이탈이 실제로는 불만족에 따른 중단임에도 불구하고, 시스템 내에서는 ‘문제 없음’으로 간주된다는 점이다. 이 경우 제품의 핵심 경험이 문제인지, 응답 품질이 문제인지, 사용성의 문제인지 판단하기 어려워진다.