AI 제품의 데이터는 어떻게 설계할까? (1편)

Part 4-1. 실험과 개선을 위한 PM의 '행동 데이터' 설계

May 17. 2025

Part 4-1. 핵심 요약

- AI 제품에서 행동 데이터는 사용자와 모델 간 상호작용의 해석 대상이다.
- 클릭수보다 중요한 것은 사용자의 의도, 맥락, 실패 흐름을 어떻게 포착할 수 있느냐다.
- 데이터는 기술이 아니라, 사용자 경험을 관찰하는 설계 프레임이다.

생성형 AI 기반 제품을 설계하거나 운영하다 보면 PM은 자주 이 질문과 마주한다.

"도대체 어디서부터 어떻게 측정해야 하지?"

기존 제품에서는 클릭 수, 전환율, 세션 유지 시간처럼 정해진 지표가 익숙했다. 하지만 생성형 AI, 특히 비정형 응답을 생성하거나 맥락 기반 인터랙션을 포함하는 제품에서는 그런 기준이 흔들린다.

사용자는 어떤 문제를 명확히 해결하려 하지 않고, 막연한 기대를 가지고 AI와 상호작용하기도 한다. 입력은 자유롭고, 반응은 예측 불가하며, 결과의 품질은 주관적이다.

이처럼 전통적인 퍼널 분석만으로는 설명할 수 없는 세계에서, AI 제품의 데이터란 ‘행동 로그’가 아니라 ‘해석 가능한 흐름’이어야 한다.

이 글에서는 사용자 행동을 어떻게 구조화하고 해석해야 하는지, 즉 “무엇을 어떻게 관찰할 것인가”를 중심으로 다루고 있다. 사용자 대화 데이터 등과 관련한 주제는 Part 4-2에서 이어서 다룰 예정이다.

1. 데이터는 인터랙션의 구조다 — UI 유형을 넘어

AI 제품의 데이터는 단순 클릭 로그보다 사용자의 기대와 행동의 맥락을 담고 있어야 한다. 챗 UI든 검색 기반이든, 핵심은 “사용자가 무엇을 시도했는가”, “어떻게 반응했는가”, “무엇을 느끼고 다음 행동을 결정했는가”다.

대화형 제품이라면 - 메시지, 프롬프트, 응답이 중심일 것이고,

검색형/추천형/작업수행형(AI 자동화) 제품이라면 - 요청 목적, 결과 평가, 반복 행동 등이 중요할 수 있다.

따라서 PM은 단지 “몇 번 사용했는가”가 아니라

✔️ 어떤 목적과 맥락에서 입력이 발생했고,

✔️ 어떤 응답이 주어졌으며,

✔️ 결과적으로 사용자가 신뢰를 쌓았는지, 떠났는지, 반복했는지를 추적할 수 있어야 한다.

데이터란 결국, 사용자의 기대와 모델의 반응이 만나 형성된 경험의 기록이다.

2. 로그는 동작이 아니라 의미를 남겨야 한다

AI 제품에서 수집해야 할 데이터는 단순 클릭 로그를 넘어선다. 중요한 건 사용자 행위의 '의도'와 '해석'이다. "버튼 클릭"이라는 이벤트보다 중요한 것은, 왜 클릭했는지, 무엇을 기대했는지, 결과가 어떻게 받아들여졌는 지다.

이를 위해 로그는 다음과 같은 의미 단위로 설계될 수 있다:

✔️ 사용자의 목적(Intent)

✔️ 입력 난이도 / 불확실성 정도

✔️ 실패 여부 및 사용자 반응

✔️ 기대 응답과의 거리

예를 들어, ‘오늘 저녁 뭐 먹을까’라는 질문은 텍스트로는 단순하지만, 그 의도가 레시피 탐색인지, 레스토랑 추천인지, 그냥 가벼운 대화인지에 따라 추천 로직, UX 플로우, AI의 응답 구조까지 달라진다.

PM은 이런 의미 구조를 파악하고 분류할 수 있는 데이터 설계에 관여해야 하며, 이를 통해 비즈니스 가치에 맞는 행동 흐름을 수집, 추적 및 분석할 수 있다.

이를 위해 초기 이벤트 및 로그 테이블 구조 자체를 제품의 목적과 분석 지표에 맞춰 설계해야 한다. 데이터 분석팀에만 맡기기보다는, PM이 의사결정 기준이 될 수 있는 데이터 구조 설계에 직접 참여해야 한다는 뜻이다.

3. 데이터 해석은 실험의 반복으로

어떤 지표를 추적할 것인가는 기술보다 제품 전략의 문제다. 특히 AI 제품에서는 무엇이 실패이고 무엇이 성공인지 정의하는 기준부터가 모호하다.

PM은 단순한 이벤트 트래킹을 넘어서, 아래와 같은 질문을 먼저 던져야 한다:

이 제품에서의 이상적인 사용 흐름은 무엇인가?

사용자가 혼란을 겪거나 실패로 인식하는 구간은 어디인가?

AI 응답 품질에 대한 신뢰가 구축되거나 무너지는 순간은 언제인가?

이러한 질문이 없다면, 아무리 많은 로그가 쌓여도 의미를 해석할 수 없다.

이 점은 Part 2, Part 3에서 반복 강조한 불확실성을 다루는 PM의 역할과도 연결된다. AI 제품은 입력과 맥락, 모델 반응, 사용자 기대가 끊임없이 달라지므로, 데이터 해석은 곧 실험의 반복 구조다.

예를 들어 '응답 > 반응 > 재시도'라는 단위를 묶어 하나의 세션으로 정의해 보자. 여기에 fallback 발생 여부나 유저 반응까지 함께 추적하면, 사용자의 반복 사용이 과연 성공인지 실패인지, 어느 구간에서 학습이 일어났는지를 더 분명히 해석할 수 있다.

또한 로그 설계 시엔 단순한 이벤트 나열이 아니라, 클릭 유도 메시지, 입력 시점의 맥락, fallback 발생 여부까지 함께 기록하는 것이 좋다. 실패 판단 기준도 UX 관점과 AI 관점을 동시에 설정해야 한다. 예를 들어 이탈 직전의 응답 길이와 시스템 적중률을 함께 분석하는 식이다.

데이터는 그저 쌓는 것이 아니라, 관찰하고 해석할 수 있는 구조로 설계되어야 한다.

4. 학습은 모델만의 일이 아니다

흔히 “모델을 학습시키고 있다”라고 말하지만, 실제로는 가장 먼저 학습해야 하는 주체는 제품 팀 자신이다.

AI 제품은 정적인 기능 집합이 아니라, 사용자의 입력과 맥락에 따라 계속 변화하는 ‘살아 있는 시스템’이다. 이 세계에서 무엇이 성공이고 실패인지에 대한 기준이 모호하면, 제품과 팀 모두 흔들릴 수밖에 없다.

그래서 PM은 제품 설계 단계부터 데이터를 어떻게 흐르게 할지, 어떤 지표로 해석할지를 팀과 함께 정립해 나가야 한다. 그 과정에서 데이터는 단순한 수치가 아니라, 제품과 팀을 연결하는 해석의 프레임이 된다.

중요한 건 거창한 분석 시스템이 아니라, 팀 전체가 쉽게 이해하고 대화할 수 있는 공통의 언어와 시선이다.

"이 기능은 Fallback이 자주 발생하니까 응답 개선 우선순위에 올리자."

"이 응답은 유저가 좋아했는데, 왜인지 함께 리플레이해보자."

"이 흐름은 처음엔 실패했지만, 반복 사용 후 전환이 일어났네."

이런 회의가 일상화되는 팀은 ‘데이터 기반으로 움직이는 팀’이며, 그 구조는 PM의 손에서 시작된다. 이러한 일상적 회고가 가능한 이유는, 팀 전체가 데이터를 제품의 현 상태를 보여주는 창으로 바라보기 때문이다. 이 구조는 단순히 데이터를 분석하는 기술력이 아니라, 제품에 대한 질문을 던지는 태도와 문화에서 출발한다.