Gemini 사례 연구: 프로덕트 팀이 Deep Research로 200개 사용자 인터뷰를 3일 만에 종합한 방법

문제: 200개 인터뷰, 200만 단어, 종합 분석은 제로

B2B SaaS 회사의 프로덕트 팀은 사용자 리서치를 성실히 수행해 왔다. 18개월 동안 총 200건의 고객 인터뷰를 진행했다. 온보딩 인터뷰, 이탈 인터뷰, 기능 피드백 세션, 분기별 체크인 등 다양한 유형이 포함되었다. 모든 인터뷰는 녹음 후 트랜스크립트로 변환되어 Google Drive에 저장되었다. 트랜스크립트 총 분량은 약 200만 단어에 달했다.

문제는 아무도 이 자료를 종합하지 않았다는 것이다. 개별 PM은 자신이 직접 진행한 인터뷰를 참고하긴 했지만, 200건 전체를 읽은 사람은 없었다. 인터뷰 전체에 걸쳐 나타나는 패턴, 시간에 따라 변화하는 사용자 감정, 사용자가 말하는 것과 실제 행동 사이의 모순 같은 집단적 지능은 읽히지 않은 문서 속에 잠들어 있었다.

프로덕트 팀은 차년도 로드맵을 수립할 시점이었다. VP of Product는 로드맵이 개인 의견이 아니라 사용자 리서치에 기반하기를 원했다. 그러나 200만 단어의 트랜스크립트를 수동으로 읽으려면 한 사람이 약 200시간(하루 8시간 기준 5주)이 필요했다. 로드맵 워크숍까지 남은 시간은 3일이었다.

Gemini를 선택한 이유

팀은 세 가지 접근법을 검토했다.

첫째, 전문 리서치 도구(Dovetail, Condens)다. 정성적 연구 종합에 특화된 플랫폼이지만, 200건의 트랜스크립트를 임포트하고 태깅하는 초기 셋업에만 수 주가 소요될 것이었다. 시간이 부족했다.

둘째, ChatGPT나 Claude에 문서를 업로드하는 방법이다. 두 도구 모두 문서 처리가 가능하지만, 200건의 트랜스크립트(평균 1만 단어)를 하나의 대화에서 효과적으로 처리하기에는 context 한계가 있었다.

셋째, Gemini의 100만 token context window다. 한 번의 대화에서 약 50-70건의 트랜스크립트를 동시에 처리할 수 있었다. 세그먼트별로 3-4개 대화를 나누면 전체 200건을 커버할 수 있었다. 트랜스크립트가 이미 Google Drive에 있었기 때문에 업로드도 수월했다.

VP of Product는 세 가지 이유로 Gemini를 선택했다: context window 크기, 네이티브 Google Drive 연동, 정성적 데이터 종합에 대한 강력한 분석 능력.

3일 워크플로

1일차: 세그먼트 정리와 1차 분석

오전에는 200건의 트랜스크립트를 세그먼트별로 분류했다. 인터뷰 유형(온보딩/이탈/피드백/체크인), 고객 규모(소기업/중견/대기업), 산업군(이커머스/핀테크/헬스케어/교육/기타), 시기(최근 6개월/6-12개월/12-18개월)의 네 축으로 나누었다.

분류 자체는 파일명과 메타데이터를 기반으로 2시간 만에 완료했다. 이미 Drive 폴더 구조가 어느 정도 정리되어 있었기 때문이다.

오후에는 가장 큰 세그먼트인 “이탈 인터뷰”(58건)부터 분석을 시작했다. 3개 배치(약 20건씩)로 나누어 Gemini에 업로드하고, 각 배치에 동일한 분석 프롬프트를 적용했다.

"첨부된 이탈 인터뷰 트랜스크립트를 분석하고 다음을 정리해 달라:

1. 이탈 이유 분류: 각 인터뷰에서 언급된 이탈 이유를 카테고리화하고 빈도를 집계
2. 감정 강도: 단순 불만인가, 강한 분노인가, 아쉬움인가 - 감정의 강도를 구분
3. 전환 목적지: 어디로 이동했는가, 왜 그 대안을 선택했는가
4. 미련 표현: 제품에 대한 긍정적 감정이나 미련을 표현한 부분
5. 구조적 문제 vs 일시적 문제: 제품의 근본적 한계인가, 특정 시점의 이슈인가
6. 직접 인용: 각 발견에 대해 가장 대표적인 원문 인용구 포함"

3개 배치의 결과를 통합하는 작업까지 포함하여 1일차에 이탈 인터뷰 전체 분석이 완료되었다.

2일차: 전체 세그먼트 분석과 교차 패턴 식별

2일차 오전에는 나머지 세그먼트(온보딩 47건, 피드백 62건, 체크인 33건)를 같은 방식으로 분석했다. 각 세그먼트에 맞는 분석 프롬프트를 사용했다. 온보딩 인터뷰에는 “첫 인상”, “기대와 현실의 차이”, “온보딩 과정의 병목”을, 피드백 세션에는 “기능 요청 빈도”, “현재 워크플로에서의 마찰 지점”, “경쟁사 비교 언급”을 중심 축으로 설정했다.

2일차 오후에는 가장 중요한 작업인 교차 세그먼트 패턴 식별을 수행했다. 각 세그먼트의 분석 결과를 하나의 Gemini 대화에 텍스트로 입력하고, 세그먼트를 관통하는 패턴을 요청했다.

"아래는 4개 세그먼트(이탈/온보딩/피드백/체크인)의 분석 결과이다.
세그먼트를 관통하는 교차 패턴을 식별해 달라:

1. 일관된 불만: 모든 또는 대부분의 세그먼트에서 반복되는 문제
2. 모순: 한 세그먼트에서는 긍정적인데 다른 세그먼트에서는 부정적인 요소
3. 시간에 따른 변화: 오래된 인터뷰와 최근 인터뷰 사이의 감정 변화
4. 세그먼트별 특수성: 특정 고객 규모나 산업에서만 나타나는 고유한 패턴
5. 숨겨진 연결: 서로 다른 세그먼트의 발견이 실제로는 같은 근본 원인을 가리키는 경우

[이탈 분석 결과]
[온보딩 분석 결과]
[피드백 분석 결과]
[체크인 분석 결과]"

이 교차 분석에서 놀라운 발견이 나왔다. 이탈 인터뷰에서 2번째로 많이 언급된 이탈 이유(“리포트 커스터마이징이 불가능”)와 피드백 세션에서 가장 많이 요청된 기능(“대시보드 커스터마이징”)이 사실상 같은 문제의 두 가지 표현이었다. 체크인 인터뷰에서 장기 고객이 “보고서 내보내기를 매번 수동으로 해야 해서 귀찮다”고 언급한 것도 같은 근본 원인에 연결되었다.

3일차: 페르소나 검증, 우선순위 도출, 최종 보고서

3일차 오전에는 기존 페르소나를 검증했다. 팀에는 18개월 전에 만든 4개의 사용자 페르소나가 있었다. 200건의 인터뷰 분석 결과를 기존 페르소나에 대입하여 일치도를 확인했다.

"아래는 우리의 기존 4개 사용자 페르소나이다.
200건 인터뷰 분석 결과를 바탕으로 각 페르소나를 검증해 달라:

[페르소나 1: 스타트업 CEO - 빠른 의사결정, 셀프서비스 선호]
[페르소나 2: 운영 매니저 - 프로세스 효율, 팀 협업 중시]
[페르소나 3: 데이터 분석가 - 커스터마이징, 데이터 내보내기 중시]
[페르소나 4: 경영진 - 높은 수준의 대시보드, ROI 가시성]

각 페르소나에 대해:
- 인터뷰 데이터가 페르소나를 지지하는가, 반박하는가
- 페르소나 설명에서 수정이 필요한 부분
- 인터뷰에서 발견되었지만 기존 페르소나에 포함되지 않은 새로운 사용자 유형
- 각 페르소나의 핵심 니즈 우선순위(인터뷰 빈도와 감정 강도 기반)"

결과적으로 페르소나 1과 2는 대체로 정확했지만, 페르소나 3은 실제 인터뷰 데이터에서 두 개의 하위 유형으로 분리되어야 했다. “데이터를 직접 분석하는 사용자”와 “데이터를 다른 도구(Excel, BI 도구)로 내보내서 쓰는 사용자”의 니즈가 근본적으로 달랐기 때문이다. 또한 기존 페르소나에 없던 새로운 유형, “IT 관리자/도입 결정자”가 발견되었다. 이 유형은 직접 제품을 사용하지 않지만 도입과 갱신 결정에 핵심 영향력을 행사하는 사람들이었다.

3일차 오후에는 기능 요청 우선순위를 도출했다. 전체 인터뷰에서 언급된 기능 요청을 빈도(몇 번 언급되었는가), 감정 강도(얼마나 절실하게 원하는가), 세그먼트 범위(특정 세그먼트만의 니즈인가 범용적인가), 이탈 연관성(이 기능 부재가 이탈과 직접 연결되는가)의 4가지 축으로 점수화했다.

"전체 인터뷰 분석에서 식별된 모든 기능 요청을 다음 4개 축으로 점수화하여
우선순위 매트릭스를 만들어 달라:

| 기능 요청 | 언급 빈도 | 감정 강도 | 세그먼트 범위 | 이탈 연관성 | 종합 점수 |
|-----------|-----------|-----------|---------------|-------------|-----------|

빈도: 전체 인터뷰 중 해당 기능을 언급한 비율
감정 강도: 1(가벼운 제안) ~ 5(강한 불만/절실한 요청)
세그먼트 범위: 1(한 세그먼트) ~ 4(모든 세그먼트)
이탈 연관성: 이탈 인터뷰에서 직접적 이탈 이유로 언급된 경우 가중치 2배

상위 10개 기능 요청에 대해 대표 인용구도 포함해 달라."

결과

3일간의 작업으로 다음과 같은 산출물이 만들어졌다.

세그먼트별 분석 보고서 4건. 각 보고서는 해당 세그먼트의 핵심 발견, 패턴, 대표 인용구를 포함했다. 교차 세그먼트 패턴 보고서 1건. 세그먼트를 관통하는 5개의 핵심 패턴과 3개의 주요 모순이 정리되었다. 페르소나 검증 및 업데이트 문서 1건. 기존 4개 페르소나의 수정안과 신규 페르소나 1개가 추가되었다. 기능 우선순위 매트릭스 1건. 4개 축 점수에 기반한 상위 15개 기능 요청 목록이었다.

로드맵 워크숍에서 이 자료는 팀의 기대를 넘어서는 반응을 얻었다. VP of Product의 표현을 빌리면, “처음으로 데이터에 기반한 로드맵 토론을 했다.” 이전 워크숍에서는 각 PM이 자신의 경험에 기반한 주장을 하고, 누구의 목소리가 큰지에 따라 우선순위가 결정되는 경향이 있었다. 이번에는 200건의 인터뷰에서 나온 정량화된 근거가 있었기 때문에 토론의 질이 달라졌다.

부딪힌 문제들

Context 한계

100만 token이 넉넉해 보이지만, 200건의 트랜스크립트를 한 번에 처리할 수는 없었다. 50-70건씩 나누어 처리하고 결과를 통합하는 과정이 필요했다. 이 통합 과정에서 미묘한 정보 손실이 발생할 수 있다. 배치 A의 분석 결과와 배치 B의 분석 결과를 합칠 때, Gemini는 두 배치의 원본 트랜스크립트를 동시에 보지 못한다. 따라서 “배치 A에서 나온 패턴 X와 배치 B에서 나온 패턴 Y가 사실은 같은 현상이다”라는 판단을 내리기 어려울 수 있다.

이 문제를 완화하기 위해 팀은 각 배치 분석 시 가능한 한 구체적인 인용구를 포함하도록 요청했다. 추상적 요약만 모으면 통합 시 맥락이 사라지지만, 원문 인용구가 있으면 통합 단계에서도 구체적 비교가 가능했다.

과도한 일반화 경향

Gemini는 대량의 텍스트를 분석할 때 패턴을 찾으려는 경향이 강하다. 이것이 장점이기도 하지만, 때로는 존재하지 않는 패턴을 만들어내거나, 소수의 특이한 의견을 “반복되는 패턴”으로 과대 표현하는 경우가 있었다.

예를 들어, 3건의 인터뷰에서 “모바일 앱이 있으면 좋겠다”는 언급이 있었는데, Gemini는 이를 “모바일 접근성에 대한 지속적 수요”로 표현했다. 200건 중 3건(1.5%)은 “지속적 수요”라고 보기 어렵다. 팀은 이런 과장을 방지하기 위해 “반드시 빈도(전체 대비 비율)를 함께 표시하라”는 지시를 추가했고, 이후 분석의 정확도가 크게 개선되었다.

시간적 편향

200건의 인터뷰는 18개월에 걸쳐 진행되었다. 제품이 18개월 동안 상당히 변했기 때문에, 초기 인터뷰의 불만 중 일부는 이미 해결된 문제였다. Gemini는 인터뷰 시점을 자동으로 고려하지 않는다. 12개월 전의 불만과 지난달의 불만을 동일한 무게로 집계한다.

팀은 이 문제를 해결하기 위해 시기별 가중치를 도입했다. “최근 6개월 인터뷰에 가중치 3, 6-12개월에 가중치 2, 12-18개월에 가중치 1을 적용하여 빈도를 재계산해 달라”는 후속 프롬프트로 시간적 편향을 보정했다.

맥락 상실

트랜스크립트만으로는 파악할 수 없는 맥락이 있다. 인터뷰 당시 응답자의 표정, 톤의 변화, 망설임 같은 비언어적 단서는 텍스트에 담기지 않는다. 인터뷰를 직접 진행한 PM만이 알 수 있는 “이 사람은 말로는 만족한다고 했지만 표정은 그렇지 않았다” 같은 뉘앙스가 사라진다.

팀은 이 한계를 인정하고, Gemini 분석 결과를 “1차 필터”로 활용했다. 최종 보고서에는 “이 분석은 텍스트 기반이며, 인터뷰 진행자의 맥락 보충이 필요하다”는 단서를 달았다. 로드맵 워크숍에서는 Gemini 분석 결과를 보여주고, 해당 인터뷰를 직접 진행한 PM에게 보충 설명을 요청하는 방식으로 진행했다.

교훈

데이터 구조가 분석 품질을 결정한다

팀이 트랜스크립트를 Drive에 저장할 때 일관된 파일명 규칙(날짜_인터뷰유형_회사명_응답자직함)을 사용한 것이 큰 도움이 되었다. 만약 파일명이 “인터뷰1.docx”, “recording_final_v2.docx” 같은 식이었다면 분류 작업에만 하루가 더 걸렸을 것이다. AI 분석을 염두에 두지 않았더라도 데이터를 정리해 두는 습관이 나중에 큰 차이를 만든다.

AI 분석은 가설 생성기이지 결론 도출기가 아니다

Gemini가 내놓은 패턴과 인사이트를 그대로 최종 결론으로 채택하면 위험하다. AI 분석은 “이런 패턴이 보이니 확인해 보라”는 가설 생성 도구로 활용해야 한다. 가설을 검증하는 것은 사람의 역할이다. 팀이 Gemini 분석 결과를 그대로 쓰지 않고 워크숍에서 토론 자료로 활용한 것이 올바른 접근이었다.

프롬프트 설계에 시간을 투자해야 한다

3일 중 실제로 프롬프트를 작성하고 다듬는 데 상당한 시간이 소요되었다. 첫 번째 프롬프트로 나온 결과가 만족스러운 경우는 드물었다. “이탈 이유를 분석해 달라”에서 시작하여 “이탈 이유를 카테고리화하고 빈도를 집계하되 감정 강도를 구분하고 대표 인용구를 포함해 달라”로 발전하기까지 여러 차례의 반복이 필요했다. 프롬프트 설계 능력이 분석 품질을 좌우한다.

비용 대비 가치가 압도적이다

2명의 분석가가 3일간 작업하여 Gemini Advanced 구독료 약 2만 원(월 기준)으로 완료한 이 프로젝트는, 전문 리서치 에이전시에 의뢰했다면 수천만 원과 수 주가 소요되었을 것이다. 품질이 완벽히 동일하지는 않겠지만, “3일 안에 200건 인터뷰의 종합 분석을 로드맵 워크숍 자료로 만들어야 한다”는 조건에서 Gemini 외에 현실적 대안은 없었다.

인터뷰 설계부터 종합을 염두에 두어야 한다

이번 경험 이후 팀은 인터뷰 가이드를 개편했다. 모든 인터뷰에 공통 질문 5개를 포함하여 세그먼트 간 비교가 용이하도록 했다. 응답자 메타데이터(회사 규모, 산업, 사용 기간, 요금제)를 트랜스크립트 상단에 표준 형식으로 기록하도록 했다. 인터뷰 종료 시 진행자가 핵심 관찰 메모를 3-5줄로 작성하여 트랜스크립트 하단에 첨부하도록 했다. 이 변경은 다음 번 종합 분석을 훨씬 수월하게 만들 것이다.

재현을 위한 체크리스트

이 사례를 자체적으로 재현하고자 하는 팀을 위한 체크리스트다.

사전 준비 단계에서 트랜스크립트 파일이 일관된 형식으로 저장되어 있는지 확인한다. 세그먼트 분류 기준을 미리 정한다. 각 세그먼트에 맞는 분석 프롬프트를 사전에 설계한다. 분석 결과의 출력 형식을 통일한다.

실행 단계에서 세그먼트별로 배치를 나누되, 한 배치에 50-70건을 초과하지 않는다. 각 배치에 동일한 프롬프트를 적용하여 일관성을 확보한다. 반드시 빈도와 대표 인용구를 포함하도록 요청한다. 배치별 결과를 통합하는 교차 분석 단계를 별도로 수행한다. 시간적 편향을 보정하는 가중치를 적용한다.

검증 단계에서 Gemini 분석 결과를 인터뷰 진행자에게 검토받는다. 과도한 일반화가 없는지 빈도 수치를 확인한다. 최종 보고서에 AI 분석의 한계를 명시한다.

200건의 인터뷰를 3일 만에 종합한다는 것은 2년 전만 해도 불가능한 일이었다. Gemini의 대용량 context window가 이를 가능하게 했지만, 도구만으로는 충분하지 않다. 체계적인 세그먼트 설계, 정밀한 프롬프트 작성, 결과에 대한 비판적 검증이 결합되어야 실무에 쓸 수 있는 결과가 나온다.