Agent User Segmentation

발화 데이터 기반 사용자 분류와 A/B 테스트 파이프라인

AI Agent 서비스에서 사용자 발화 데이터를 기반으로 세그먼트를 분류하고, 세그먼트별 프롬프트 전략을 수립하며, A/B 테스트로 효과를 검증하는 전체 파이프라인을 설계한다. 언어학과 심리학 이론을 도입하여 LLM 기반 자동 태깅 시스템을 구축하고, 통계적 실험 설계로 의사결정의 근거를 확보하는 실무 방법론을 다룬다.

Agent
AI
Statistics
Experimentation
저자

Kwangmin Kim

공개

2026년 03월 07일

1 Agent User Segmentation

AI Agent 서비스에서 모든 사용자에게 동일한 프롬프트와 응답 전략을 적용하는 것은 비효율적이다. 사용자의 발화 패턴, 의도, 감정 상태에 따라 그룹을 나누고 그룹별로 최적화된 전략을 제공하면 리텐션과 만족도를 높일 수 있다.

Segmentation은 그룹 단위의 전략이다. 개별 사용자가 아니라 공통 특성을 가진 사용자 집단을 대상으로 동일한 전략을 적용한다.

1.1 왜 발화 데이터인가

전통적인 세그먼테이션은 인구통계(나이, 성별, 지역)나 행동 데이터(클릭, 구매)를 기준으로 한다. AI Agent에서는 발화 데이터 자체가 가장 풍부한 정보원이다.

  • 별도의 설문조사나 행동 추적 없이 대화 로그만으로 분류 가능
  • 사용자의 의도, 감정, 전문성 수준이 발화에 직접 드러남
  • LLM을 활용하면 대규모 발화 데이터의 자동 분류가 가능

예시 — 동일한 주제, 다른 발화 패턴:

사용자 발화 추정 가능한 정보
A “Python에서 리스트 정렬하는 함수 뭐야?” 초급, 단답 기대, 감정 없음
B “sorted()랑 .sort()가 시간 복잡도 차이가 있나요? 대규모 데이터 기준으로 벤치마크 결과도 궁금합니다” 중급 이상, 심화 정보 기대, 분석적
C “아 또 정렬 에러남ㅡㅡ 왜 자꾸 TypeError 뜨는 건데” 초중급, 좌절 상태, 즉시 해결 기대

세 사용자 모두 “Python 정렬” 관련 질문이지만, 적절한 응답 전략은 완전히 다르다.

1.2 이론적 기반

1.2.1 언어학: 화용론 (Pragmatics)

화용론은 발화의 문자적 의미가 아니라 맥락 속에서의 의미를 연구한다.

개념 설명 세그먼테이션 적용
Speech Act (화행) 발화의 기능 분류 (요청, 질문, 명령 등) Action 기준 설계
Conversational Implicature (대화 함축) 직접 말하지 않은 의도 추론 Structure(선호/비선호) 판별
Turn-taking (순서 교대) 대화 참여자 간 발언권 교대 패턴 Turn(싱글/멀티) 분류
Politeness Theory (공손 이론) 체면 유지 전략 Stance(감정/태도) 추출

Speech Act 이론 (Austin, Searle)은 발화를 다섯 가지로 분류한다:

  • Assertives (단언): 사실 진술 → 정보 검색형 (Information Seeking)
  • Directives (지시): 행동 요청 → 생성/변환 요청 (Other Action)
  • Commissives (약속): 화자의 의지 표현
  • Expressives (표현): 감정 표현 → Stance 판별
  • Declarations (선언): 상태 변경

예시 — Speech Act 분류:

발화 Speech Act TASS 매핑
“Python의 GIL이 뭐야?” Assertive (사실 요청) Action = I
“이 코드를 TypeScript로 변환해줘” Directive (행동 요청) Action = O
“덕분에 해결했어요! 감사합니다” Expressive (감정 표현) Stance = E
“이건 아무리 해도 안 되네요” Expressive (좌절) Stance = N
“sorted()는 Timsort 알고리즘을 사용합니다” (에이전트가 답한 걸 사용자가 반복) Assertive (확인) Structure = P

1.2.2 심리학: 사용자 동기 이론

이론 핵심 개념 세그먼테이션 적용
Self-Determination Theory 자율성, 유능감, 관계성 사용자 동기 유형 분류
Cognitive Load Theory 인지 부하 수준 응답 복잡도 조절
Frustration-Aggression 좌절 → 공격/이탈 부정 감정 사용자 대응

Self-Determination Theory (Deci & Ryan)에 따르면 사용자의 내재적 동기는 세 가지로 구성된다:

  • 자율성 (Autonomy): 스스로 선택하고 통제하려는 욕구 → Dispreferred Structure (AI가 먼저 질문해주길 원함)
  • 유능감 (Competence): 능력을 발휘하고 성장하려는 욕구 → 탐색형 멀티턴 사용자
  • 관계성 (Relatedness): 연결감과 소속감 → 사교형 사용자 (MIEP/MOEP)

예시 — 동기 이론과 발화 패턴:

동기 유형 발화 패턴 세그먼트 경향
자율성 중시 “내가 이렇게 생각하는데 맞아?”, “다른 방법은 없어?” MIDP — 여러 옵션 제시를 선호
유능감 중시 “이걸 더 최적화하려면?”, “근본 원리가 뭐야?” MIUP — 심화 탐색, 감정 표현 적음
관계성 중시 “오 대박! 이게 됐어!”, “너 진짜 똑똑하다” MIEP — 긍정적 상호작용 선호

1.3 분류 프레임워크: TASS

발화 데이터를 네 가지 축으로 분석한다.

1.3.1 Turn (대화 범위)

유형 코드 특징 예시
Single-turn S 한 번의 질문-답변으로 완결 “파이썬에서 현재 날짜 구하는 코드 알려줘”
Multi-turn M 여러 차례 이어지는 대화 “이 에러 해결 → 근데 왜 이런 에러가 나? → 그럼 예방하려면?”

1.3.2 Action (대화 목적)

유형 코드 특징 예시
Information Seeking I 정보 검색, 사실 확인 “React의 useEffect 훅은 언제 실행돼?”
Other Action O 생성, 변환, 분석, 조언, 창작 “이 SQL 쿼리를 최적화해줘”, “마케팅 카피 3개 만들어줘”

1.3.3 Stance (감정적 태도)

유형 코드 특징 예시
Unobserved U 감정 표현 없음, 중립적 “Docker compose 파일 작성법 알려줘”
Emotion Positive E 만족, 호의, 긍정적 표현 “오 이거 진짜 도움 됐어! 고마워”
Emotion Negative N 불만, 좌절, 부정적 표현 “이건 왜 안 되는 거야 ㅡㅡ”, “아까 알려준 거 틀렸어”

1.3.4 Structure (대화 흐름 선호)

유형 코드 특징 예시
Preferred P AI가 즉시 답변/실행해주길 기대 “그냥 코드만 줘”
Dispreferred D AI가 먼저 질문하고 맥락 확인해주길 기대 “내 상황을 설명할게 먼저 들어봐”
Zero Z 선호 불명확 (첫 번째 발화에서 판별 불가)

세그먼트 코드는 [Turn][Action][Stance][Structure] 형태로 조합한다. 예: MIEP = Multi-turn + Information Seeking + Emotion Positive + Preferred

1.3.5 실제 대화 예시별 TASS 태깅

예시 1: SIUP (Single + Info + Unobserved + Preferred)

[User] Python에서 딕셔너리를 JSON 파일로 저장하는 코드 알려줘
[Agent] (답변)
[대화 종료]
  • Turn: S — 1턴으로 완결
  • Action: I — 사실/코드 검색
  • Stance: U — 감정 표현 없음
  • Structure: P — 즉시 코드 제공을 기대

예시 2: MOEP (Multi + Other + Positive + Preferred)

[User] 우리 회사 소개 페이지 카피를 작성해줘. B2B SaaS 회사야.
[Agent] (초안 제공)
[User] 좋아! 근데 좀 더 캐주얼한 톤으로 바꿔줘
[Agent] (수정본 제공)
[User] 완벽해 이거 쓸게 고마워!
  • Turn: M — 3턴 대화
  • Action: O — 카피 생성 (창작)
  • Stance: E — “좋아!”, “완벽해”, “고마워”
  • Structure: P — AI가 즉시 생성하길 기대

예시 3: MIND (Multi + Info + Negative + Dispreferred)

[User] 배포한 API가 간헐적으로 500 에러를 뱉어. 로그 봐도 모르겠어.
[Agent] 어떤 프레임워크를 사용하고 계신가요? 에러가 발생하는 빈도와 패턴이 있나요?
[User] FastAPI인데 트래픽 많을 때 주로 발생해. 진짜 스트레스받아
[Agent] (단계별 디버깅 가이드 제공)
[User] 아 connection pool 문제였구나. 근데 왜 공식 문서에는 이런 내용이 없지?
  • Turn: M — 멀티턴 대화
  • Action: I — 원인 파악 (정보 탐색)
  • Stance: N — “모르겠어”, “스트레스받아”, 좌절감
  • Structure: D — 에이전트가 먼저 상황을 파악해주길 기대

예시 4: MIUZ (Multi + Info + Unobserved + Zero)

[User] Transformer 아키텍처에서 Multi-Head Attention의 역할이 뭐야?
[Agent] (설명 제공)
[User] 그럼 head 개수가 성능에 미치는 영향은?
[Agent] (설명 제공)
[User] head pruning에 대한 논문 중에 추천할 만한 게 있어?
  • Turn: M — 탐색적 멀티턴
  • Action: I — 개념 탐색
  • Stance: U — 감정 표현 없음, 분석적
  • Structure: Z — 선호 불명확 (AI 주도도 수용, 자기 주도도 수용)

1.4 LLM 기반 자동 태깅 시스템

1.4.1 아키텍처

사용자 발화 로그
    ↓
[LLM Classifier] ← System Prompt (TASS 분류 기준)
    ↓
세그먼트 태그 (MIEP, SIUP, ...)
    ↓
[User Profile DB] ← 태그 누적/업데이트
    ↓
세그먼트별 프롬프트 전략 적용

1.4.2 분류 프롬프트 설계

당신은 사용자 발화 분석 전문가입니다.
다음 대화를 분석하여 TASS 프레임워크에 따라 분류하십시오.

## 분류 기준

1. Turn: S(Single-turn) / M(Multi-turn)
2. Action: I(Information Seeking) / O(Other Action)
3. Stance: U(Unobserved) / E(Positive) / N(Negative)
4. Structure: P(Preferred) / D(Dispreferred) / Z(Zero)

## 대화 데이터
{conversation}

## 출력 형식 (JSON)
{
  "turn": "S" or "M",
  "action": "I" or "O",
  "stance": "U" or "E" or "N",
  "structure": "P" or "D" or "Z",
  "segment_code": "XXXX",
  "confidence": 0.0~1.0,
  "reasoning": "분류 근거 설명"
}

실제 태깅 결과 예시:

입력 대화:

[User] 이 pandas DataFrame에서 결측치 비율이 30% 이상인 컬럼을 자동으로 제거하는 함수 만들어줘
[Agent] (코드 제공)
[User] 오 깔끔하다. 근데 제거 전에 로그도 남기게 해줄 수 있어?
[Agent] (수정된 코드 제공)
[User] 완벽해!

출력:

{
  "turn": "M",
  "action": "O",
  "stance": "E",
  "structure": "P",
  "segment_code": "MOEP",
  "confidence": 0.92,
  "reasoning": "3턴 대화(M), 함수 생성 요청(O), '깔끔하다/완벽해' 등 긍정 표현(E), 즉시 코드 제공 기대(P)"
}

1.4.3 태깅 품질 관리

LLM 기반 태깅은 완벽하지 않다. 품질을 보장하기 위한 전략:

  • Inter-rater reliability: 동일 발화에 대해 2개 이상의 LLM(또는 동일 LLM의 다른 temperature)으로 태깅 → Cohen’s Kappa로 일치도 측정
  • Human-in-the-loop: 신뢰도(confidence)가 낮은 태깅 결과는 사람이 검수
  • 주기적 재검증: 태깅된 데이터의 일부를 샘플링하여 정확도 모니터링

품질 기준 예시:

지표 목표 조치
Cohen’s Kappa (LLM 간 일치도) ≥ 0.75 프롬프트 수정 또는 few-shot 예시 추가
사람 검수 일치율 ≥ 85% 분류 기준 세분화
저신뢰도 (confidence < 0.7) 비율 ≤ 15% 경계 사례에 대한 가이드라인 보강

1.5 세그먼트별 프롬프트 전략

1.5.1 SI 계열 (Single-turn + Information Seeking)

전체 사용자의 60~70%를 차지하는 가장 큰 세그먼트.

특성:

  • 빠른 답변을 원하고, 답을 얻으면 즉시 이탈
  • 대화의 깊이보다 속도를 중시
  • 재방문율이 낮음

전략:

  • 간결하고 명확한 답변 우선
  • 코드/예시 즉시 제공
  • 답변 말미에 관련 후속 질문 제안 (멀티턴 전환 유도)
[System Prompt - SI 세그먼트]
사용자는 빠르고 정확한 정보를 원합니다.
- 핵심 답변을 먼저 제시하십시오
- 부가 설명은 최소화하십시오
- 답변 후 "관련 질문: ..."으로 후속 탐색을 유도하십시오

적용 전/후 비교:

구분 사용자 질문: “Python에서 리스트 중복 제거하는 법”
Before (기본 프롬프트) “Python에서 리스트의 중복을 제거하는 방법은 여러 가지가 있습니다. 먼저, 리스트란 Python의 기본 자료구조로… (300자 설명) … 첫째, set()을 사용하는 방법이 있습니다. 둘째, dict.fromkeys()를 사용하는 방법이 있습니다. 셋째…”
After (SI 최적화) list(set(my_list)) — 순서 유지가 필요하면 list(dict.fromkeys(my_list)). 관련 질문: 대규모 데이터에서의 성능 비교가 궁금하시다면 이어서 질문해주세요.”

1.5.2 MIEP/MOEP 계열 (Multi-turn + Positive Emotion)

전체의 20~30%. AI 친화적이고 충성도가 높은 세그먼트.

특성:

  • 긍정적 대화를 선호하고 AI와의 유대감 형성에 관심
  • 대화 길이가 길고 목표가 명확
  • 재방문율과 프리미엄 전환율이 높음

전략:

  • 공감적 표현과 격려 사용
  • 단계별 가이드 제공
  • Gamification 요소 (진행률, 마일스톤)
[System Prompt - MIEP 세그먼트]
사용자는 학습과 성장에 적극적입니다.
- 공감과 격려를 포함하십시오
- 단계별로 구조화된 가이드를 제공하십시오
- 달성한 내용을 요약하고 다음 단계를 제안하십시오

적용 전/후 비교:

구분 사용자 질문: “Flask로 REST API 만드는 법 배우고 싶어”
Before “Flask REST API 구현 방법은 다음과 같습니다. 1. Flask 설치… 2. 라우트 정의… 3. JSON 응답…”
After “좋은 선택이에요! Flask는 가볍고 직관적이라 REST API 입문에 딱입니다. Step 1/4: 프로젝트 셋업 — 먼저 가상환경과 Flask를 설치하겠습니다. (코드) 여기까지 따라하신 후 알려주세요, 다음 단계로 넘어갈게요!”

1.5.3 N 계열 (Negative Emotion)

전체의 5~10%. 불만이나 좌절을 경험 중인 사용자.

특성:

  • 에러, 버그, 잘못된 답변으로 인한 좌절
  • 이탈 확률이 매우 높음
  • 공감 없는 기계적 답변에 더 분노

전략:

  • 즉각적 공감 표현
  • 문제 해결에 집중 (부가 정보 최소화)
  • 해결 후 확인 질문 (“해결되셨나요?”)
[System Prompt - N 계열 세그먼트]
사용자는 현재 어려움을 겪고 있습니다.
- 먼저 공감을 표현하십시오 ("답답하셨겠네요")
- 문제 해결에 바로 집중하십시오
- 해결 후 반드시 확인하십시오 ("이 방법으로 해결이 되셨나요?")
- 추가 문제가 없는지 물어보십시오

적용 전/후 비교:

구분 사용자 질문: “아 이거 3시간째 안 되는데 왜 자꾸 CORS 에러가 뜨냐고”
Before “CORS 에러는 Cross-Origin Resource Sharing 정책으로 인해 발생합니다. 이를 해결하려면…”
After “3시간이나 고생하셨군요, 답답하셨겠습니다. CORS 에러는 보통 서버 측 헤더 설정으로 해결됩니다. 사용 중인 프레임워크가 뭔가요? (Flask/Express/FastAPI 등) 프레임워크에 맞는 해결 코드를 바로 드릴게요.”

1.5.4 MI/MO Unobserved 계열 (Multi-turn + 감정 미관찰)

전체의 5~10%. 탐색적이고 분석적인 세그먼트.

특성:

  • 명확한 감정 표현 없이 탐색적 질문
  • 브레인스토밍, 개념 정리, 비교 분석 목적
  • 전문가 비율이 높음

전략:

  • 다각적 관점과 비교/대조 정보 제공
  • 구조화된 분석 결과 제시
  • 심화 자료 연결
[System Prompt - MI Unobserved 세그먼트]
사용자는 깊이 있는 분석을 원합니다.
- 여러 관점에서 비교/대조하십시오
- 구조화된 표나 목록으로 정리하십시오
- 추가 탐색이 가능한 방향을 제시하십시오

적용 전/후 비교:

구분 사용자 질문: “Kafka와 RabbitMQ 차이가 뭐야?”
Before “Kafka는 분산 이벤트 스트리밍 플랫폼이고, RabbitMQ는 메시지 브로커입니다…” (텍스트 나열)
After 비교표 형태로 제공: “처리 모델: Kafka=Pull 기반 로그 / RabbitMQ=Push 기반 큐, 처리량: Kafka=수백만 TPS / RabbitMQ=수만 TPS, 메시지 보존: Kafka=설정 기간 보존 / RabbitMQ=소비 후 삭제… 심화 방향: 이벤트 소싱 패턴이 궁금하시면 이어서 질문해주세요.”

1.6 A/B 테스트 설계

세그먼트별 전략의 효과를 검증하기 위해 A/B 테스트를 수행한다.

1.6.1 실험 설계

가설 예시:

  • \(H_0\): SI 세그먼트에 후속 질문 제안을 추가해도 멀티턴 전환율에 차이가 없다
  • \(H_1\): 후속 질문 제안을 추가하면 멀티턴 전환율이 증가한다

실험 구조:

구분 Control Treatment
SI 세그먼트 기존 프롬프트 (즉답만) 세그먼트 최적화 프롬프트 (즉답 + 후속 질문 제안)
MIEP 세그먼트 기존 프롬프트 Gamification + 공감 프롬프트
N 계열 기존 프롬프트 공감 + 즉시 해결 프롬프트

구체적 가설과 메트릭 매핑 예시:

세그먼트 가설 Primary Metric 기대 효과
SI 후속 질문 제안 → 멀티턴 전환 증가 멀티턴 전환율 +50% (10% → 15%)
MIEP 단계별 가이드 + 격려 → 세션 길이 증가 평균 턴 수 +30% (5턴 → 6.5턴)
N 계열 공감 표현 → 이탈률 감소 부정 감정 후 이탈률 -25% (40% → 30%)

1.6.2 핵심 메트릭

메트릭 정의 대상 세그먼트
멀티턴 전환율 싱글턴 → 멀티턴으로 전환된 비율 SI
세션 길이 평균 대화 턴 수 전체
재방문율 7일 내 재방문한 사용자 비율 MIEP
NPS Net Promoter Score 전체
이탈률 부정 감정 후 이탈한 비율 N 계열

1.6.3 샘플 크기 산정

기본 파라미터:
- 유의수준 (α): 0.05
- 검정력 (1-β): 0.80
- 최소 검출 효과 크기 (MDE): 상대적 5% 향상

예시 (멀티턴 전환율):
- 현재 전환율: 10%
- 목표 전환율: 15% (50% 상대적 향상)
- 필요 샘플: 그룹당 약 700명 (two-proportion z-test)

예시 (N 계열 이탈률):
- 현재 이탈률: 40%
- 목표 이탈률: 30% (25% 상대적 감소)
- 필요 샘플: 그룹당 약 350명 (two-proportion z-test)
- N 계열 비율이 전체의 5~10%이므로 총 트래픽 약 7,000~14,000명 필요

1.6.4 분석 방법

기본 분석:

  • Two-proportion z-test (전환율 비교)
  • Two-sample t-test (연속형 메트릭)
  • 95% Confidence Interval 보고

고급 분석:

  • CUPED (Controlled-experiment Using Pre-Experiment Data): 실험 전 데이터를 공변량으로 사용하여 분산 감소
  • Stratified analysis: 세그먼트 내 하위 그룹별 효과 차이 분석
  • Sequential testing: 조기 종료 판단을 위한 순차 검정

1.6.5 주의사항

Simpson’s Paradox 방지:

세그먼트별로 효과가 다를 수 있다. 전체 평균만 보면 잘못된 결론에 도달할 수 있다.

전체: Treatment 승리 (전환율 12% vs 10%)
그런데 세그먼트별로 보면:
- SI: Treatment 승리 (8% vs 5%)
- MIEP: Control 승리 (25% vs 30%)
- MI: 차이 없음 (15% vs 15%)

→ 전체 결과만 보면 Treatment를 채택하지만,
  MIEP에게는 오히려 역효과
→ 세그먼트별 분석이 필수

구체적 함정 예시:

SI 사용자가 80%를 차지하므로 전체 평균이 SI 결과에 끌려간다. MIEP 20%에서 전환율이 30% → 25%로 떨어져도 전체 평균에는 잘 드러나지 않는다. MIEP이 고가치 사용자(프리미엄 전환율 높음)라면, 전체 평균 기준으로 Treatment를 채택하는 것은 수익 손실로 이어진다.

Multiple comparison 보정:

여러 세그먼트에 대해 동시에 검정하면 False positive가 증가한다. Bonferroni correction이나 Benjamini-Hochberg procedure로 보정한다.

3개 세그먼트 동시 검정 시:
- 개별 α = 0.05일 때, 최소 1개 False positive 확률 = 1-(0.95)^3 ≈ 14.3%
- Bonferroni 보정: α' = 0.05/3 ≈ 0.017로 조정
- Benjamini-Hochberg: p-value를 정렬 후 단계별 기각 → Bonferroni보다 덜 보수적

1.7 구현 파이프라인

1.7.1 Phase 1: 데이터 수집 및 태깅 (1~2주)

  1. 발화 로그 수집 및 전처리
  2. LLM 기반 TASS 태깅 시스템 구축
  3. 태깅 품질 검증 (Cohen’s Kappa ≥ 0.7 목표)
  4. 세그먼트 분포 분석

1.7.2 Phase 2: 전략 수립 및 실험 설계 (1~2주)

  1. 세그먼트별 프롬프트 전략 정의
  2. A/B 테스트 가설 수립
  3. 샘플 크기 산정 및 실험 기간 결정
  4. 메트릭 정의 및 대시보드 구축

1.7.3 Phase 3: 실험 실행 (2~4주)

  1. 파일럿 테스트 (10~20% 트래픽)
  2. 단계적 확대 (30% → 60% → 100%)
  3. 실시간 모니터링 (이상 징후 탐지)

1.7.4 Phase 4: 분석 및 반복 (지속)

  1. 실험 결과 분석 (세그먼트별 분리)
  2. 승리 전략 전체 적용
  3. 새로운 가설 수립 → 다음 실험
  4. 세그먼트 정의 주기적 재검토

1.8 통합 시나리오: 코딩 교육 Agent “CodeMentor”

실무에서 Segmentation이 어떻게 적용되는지 가상 프로젝트를 통해 end-to-end로 살펴본다.

1.8.1 프로젝트 배경

  • 서비스: CodeMentor — 프로그래밍 학습을 도와주는 AI Agent 서비스
  • 현황: MAU 50,000명, 일평균 대화 15,000건
  • 문제: 전체 사용자에게 동일한 프롬프트 적용 중. 재방문율 18%, NPS 32점
  • 목표: 세그먼트별 전략 도입으로 재방문율 25%, NPS 45점 달성

1.8.2 Step 1: 발화 로그 수집 및 전처리

기존 대화 로그 DB에서 최근 30일간 데이터를 추출한다.

# 대화 로그 스키마
{
    "session_id": "sess_abc123",
    "user_id": "user_42",
    "messages": [
        {"role": "user", "content": "파이썬 클래스 상속 어떻게 해?", "timestamp": "..."},
        {"role": "assistant", "content": "...", "timestamp": "..."},
        {"role": "user", "content": "오 그럼 super()는 뭐야?", "timestamp": "..."},
        ...
    ],
    "total_turns": 4,
    "created_at": "2026-02-15T10:30:00Z"
}

전처리:

  • 1턴 이하의 빈 세션 제거
  • 테스트 계정 필터링
  • PII(개인정보) 마스킹
  • 결과: 약 420,000건의 유효 세션

1.8.3 Step 2: LLM 기반 TASS 태깅

420,000건 전체를 LLM으로 태깅하면 비용이 크므로, 층화 샘플링으로 10,000건을 먼저 태깅한다.

# 비용 추정 (GPT-4o 기준)
# 평균 대화 길이: ~800 tokens input + ~200 tokens output
# 10,000건 × ($2.50/1M input + $10/1M output)
# ≈ $20 + $20 = $40 (파일럿 비용)

파일럿 태깅 결과로 세그먼트 분포를 확인한다:

세그먼트 분포 (n=10,000):
┌────────┬───────┬──────┐
│ 세그먼트 │  비율  │  건수  │
├────────┼───────┼──────┤
│ SIUP   │ 42.3% │ 4,230│  ← 가장 큰 세그먼트
│ SIUZ   │ 18.1% │ 1,810│
│ MIEP   │ 12.7% │ 1,270│
│ MOEP   │  8.4% │   840│
│ MIUP   │  6.2% │   620│
│ MIND   │  3.8% │   380│
│ SINP   │  3.5% │   350│
│ 기타    │  5.0% │   500│
└────────┴───────┴──────┘

핵심 발견:

  • SI 계열이 60.4% → 최대 세그먼트, 후속 질문 유도가 핵심 전략
  • MIEP + MOEP = 21.1% → 충성 고객, 프리미엄 전환 타겟
  • N 계열(MIND + SINP) = 7.3% → 이탈 위험, 공감 전략 필요

1.8.4 Step 3: 태깅 품질 검증

동일 1,000건에 대해 LLM 2개 (GPT-4o, Claude)로 태깅하고 일치도를 측정한다.

Cohen's Kappa 결과:
- Turn (S/M):        κ = 0.91 (거의 완벽 일치)
- Action (I/O):      κ = 0.85 (상당히 높은 일치)
- Stance (U/E/N):    κ = 0.78 (실질적 일치)
- Structure (P/D/Z): κ = 0.68 (실질적 일치, 개선 필요)

Structure의 κ가 낮으므로, 분류 프롬프트에 few-shot 예시를 추가하여 0.75 이상으로 개선한다.

1.8.5 Step 4: 세그먼트별 프롬프트 전략 정의 및 A/B 테스트

실험 1: SI 계열 — 멀티턴 전환 유도

항목 내용
대상 SIUP + SIUZ (60.4%, 일평균 약 9,000건)
가설 답변 말미에 후속 질문 제안 → 멀티턴 전환율 +50%
Control 기존 프롬프트
Treatment “관련 질문: {LLM이 생성한 후속 질문 2개}” 추가
Primary Metric 멀티턴 전환율 (현재 10%)
샘플 크기 그룹당 700명 × 2 = 1,400명
예상 실험 기간 1,400 / 9,000 ≈ 1일 (충분한 트래픽) → 안전하게 7일

실험 2: N 계열 — 이탈 방지

항목 내용
대상 MIND + SINP (7.3%, 일평균 약 1,100건)
가설 공감 + 즉시 해결 프롬프트 → 이탈률 -25%
Control 기존 프롬프트
Treatment 공감 표현 + 해결 확인 질문 추가
Primary Metric 부정 감정 후 이탈률 (현재 40%)
샘플 크기 그룹당 350명 × 2 = 700명
예상 실험 기간 700 / 1,100 ≈ 1일 → 안전하게 7일

1.8.6 Step 5: 실험 결과 분석

7일 후 결과:

실험 1 (SI 멀티턴 전환):
┌──────────┬──────────┬────────────┬────────┐
│ 그룹      │ 전환율    │ 95% CI     │ p-value│
├──────────┼──────────┼────────────┼────────┤
│ Control  │ 10.2%    │ [8.9, 11.5]│        │
│ Treatment│ 14.8%    │ [13.3,16.3]│ 0.001  │
└──────────┴──────────┴────────────┴────────┘
→ 통계적으로 유의한 차이, +45% 상대적 향상

실험 2 (N 계열 이탈 방지):
┌──────────┬──────────┬────────────┬────────┐
│ 그룹      │ 이탈률    │ 95% CI     │ p-value│
├──────────┼──────────┼────────────┼────────┤
│ Control  │ 41.3%    │ [37.1,45.5]│        │
│ Treatment│ 29.7%    │ [25.8,33.6]│ 0.003  │
└──────────┴──────────┴────────────┴────────┘
→ 통계적으로 유의한 차이, -28% 상대적 감소

Simpson’s Paradox 체크를 위해 세그먼트별 분석도 수행:

실험 1 세부 분석:
- SIUP: 전환율 12.1% vs 16.4% (Treatment 승리)
- SIUZ: 전환율 7.8% vs 12.5% (Treatment 승리)
→ 모든 하위 세그먼트에서 일관된 효과 → Treatment 채택

1.8.7 Step 6: 전체 적용 및 모니터링

승리 전략을 전체 트래픽에 적용하고, 2주간 모니터링한다.

적용 후 2주 결과:
- 재방문율: 18% → 22.5% (+25%)
- NPS: 32 → 39 (+22%)
- 평균 세션 턴 수: 2.1 → 2.8 (+33%)

→ 목표(재방문율 25%, NPS 45)에 근접
→ 다음 실험: MIEP 대상 Gamification 전략 A/B 테스트

1.8.8 Step 7: 다음 이터레이션

[이터레이션 1] SI 멀티턴 전환 + N 이탈 방지 ← 완료
    ↓
[이터레이션 2] MIEP Gamification + 단계별 가이드 ← 다음 실험
    ↓
[이터레이션 3] MIUP 심화 자료 추천 + 비교 분석 강화
    ↓
[이터레이션 4] Personalization 도입 (개인 단위 맞춤)

1.9 Segmentation의 한계와 다음 단계

Segmentation은 그룹 단위의 전략이므로 한계가 있다:

  • 같은 세그먼트 내 개인 차이를 반영하지 못함
  • 사용자의 세그먼트는 시간에 따라 변할 수 있음
  • 신규 사용자는 데이터 부족으로 정확한 분류가 어려움 (Cold Start)

한계의 구체적 예시:

같은 SIUP 세그먼트에 속하는 두 사용자:

  • 사용자 A: Python 초보, “for문 사용법” 같은 기초 질문
  • 사용자 B: ML 엔지니어, “XGBoost의 learning_rate 튜닝” 같은 고급 질문

두 사용자 모두 Single-turn + Info + Unobserved + Preferred이지만, 최적의 응답 수준은 완전히 다르다. 이 차이를 반영하려면 Personalization이 필요하다.

이 한계를 극복하기 위해 Personalization으로 확장한다. Segmentation이 그룹별 기본 전략을 제공하고, 데이터가 축적되면 개인 단위의 맞춤화로 전환하는 구조가 이상적이다.

[신규 유저] → Segmentation 기반 기본 전략
    ↓ (데이터 축적)
[기존 유저] → Personalization 기반 개인 전략
    ↓ (실시간 컨텍스트 추가)
[활성 유저] → Hyperpersonalization

Subscribe

Enjoy this blog? Get notified of new posts by email: