AI Driven Interview를 실제 리서치 활동으로 진행했다.

총 11건의 인터뷰를 AI 기반 워크플로우로 운영했고, 할 일과 일정 관리 문제에 대한 초기 제품 인사이트를 얻었다.

이 글에서는 그 결과와 함께, 인터뷰를 가능하게 만든 구체적인 과정을 정리한다. AI에게 무엇을 어떻게 요청했는지, AI가 어떤 역질문을 했는지, 맥락을 얼마나 전달했는지, 에이전트를 어떻게 나누었는지, 사람은 어디까지 개입했고 AI는 어디부터 수행했는지에 대한 기록이다.

이번 글은 AI 인터뷰를 소개하는 글이라기보다, 실제로 AI Driven Interview를 운영해본 뒤 남기는 방법론 요약본에 가깝다.

AI Driven Interview

당시 우리는 할 일과 일정 관리 문제를 보고 있었다.

표면적으로는 투두 앱, 캘린더, 리마인더, 위젯, 물리적 디스플레이 같은 도구의 문제처럼 보였다. 하지만 리서치를 하면서 점점 더 중요한 질문은 도구 자체가 아니라 사용자가 할 일을 인식하고, 붙잡고, 다시 회수하는 방식에 있다는 생각이 들었다.

우리가 보고 있던 문제는 단순히 “사용자가 할 일을 모른다”가 아니었다.

오히려 많은 사람은 해야 할 일을 알고 있었다. 다만 그 일이 시야에서 사라지는 순간, 다시 생활 흐름 안으로 돌아오지 못했다. 앱 안에 잘 저장되어 있어도 앱을 열지 않으면 사라진 것과 비슷했고, 캘린더에 들어가 있어도 사용자의 현재 주의 안으로 돌아오지 않으면 행동으로 이어지지 않았다.

이 문제를 더 잘 이해하기 위해 몇 가지 질문을 잡았다.

습관화는 의지의 문제인가, 아니면 자동화와 환경 구조의 문제인가.

할 일을 입력하는 행위는 사용자에게 허들인가, 아니면 통제감과 성취감을 주는 행위인가.

제품은 관리가 어려운 사람을 위한 것인가, 아니면 이미 관리 구조가 있는 사람을 더 잘 돕기 위한 것인가.

이 질문들은 제품 방향과 바로 연결되어 있었다.

만약 습관이 의지의 문제라면 제품은 동기부여나 streak, 보상 구조를 봐야 할 수 있다. 반대로 습관이 환경 구조의 문제라면 제품은 사용자의 시야, 외부 트리거, 자동 회수 구조를 더 봐야 한다.

입력이 허들이라면 제품은 입력을 줄여야 한다. 하지만 입력 자체가 성취감이나 통제감을 준다면, 무조건 자동화하는 것이 오히려 사용자의 중요한 감각을 빼앗을 수도 있다.

타겟도 마찬가지다. 관리가 어려운 사람을 돕는 제품과 이미 관리 습관이 있는 사람의 구조를 확장하는 제품은 완전히 다른 방향으로 설계될 수 있다.

문제는 이 질문들을 인터뷰이에게 직접 물으면 안 된다는 것이었다.

“습관은 의지라고 생각하세요, 자동화라고 생각하세요?”라고 물으면 대답은 나온다. 하지만 그 대답은 실제 행동이라기보다 자기해석일 수 있다. 사람은 자신의 행동을 설명할 때, 실제로 그렇게 행동한 이유보다 더 그럴듯한 설명을 만들어내기도 한다.

그래서 인터뷰의 목적은 연구 질문에 대한 의견을 수집하는 것이 아니었다.

참여자가 실제 일상에서 어떻게 할 일을 다루는지, 어떤 순간에 무너지는지, 기록할 때 어떤 감정을 느끼는지, 어떤 도구가 왜 작동했는지를 구체적인 경험으로 듣는 것이었다. 해석은 인터뷰이가 아니라, 인터뷰 이후 분석 단계에서 해야 했다.

이 지점에서 AI Driven Interview를 하나의 실험으로 시도했다.

첫 요청은 질문지 생성이 아니었다

AI 인터뷰라고 하면 가장 쉽게 떠올릴 수 있는 요청은 이렇다.

“할 일 관리에 대한 인터뷰 질문지를 만들어줘.”

하지만 이번에는 그렇게 시작하지 않았다.

처음 AI에게 요청한 것은 질문지가 아니라, 인터뷰를 운영할 에이전트 구조였다.

초기 요청의 핵심은 다음과 같았다.

연구자는 Context Architect와만 소통한다. Context Architect는 먼저 연구자의 맥락을 충분히 파악한다. Context Architect는 그 맥락을 바탕으로 Interview Designer, AI Interviewer, Insight Analyst의 역할과 프롬프트를 설계한다. Interview Designer는 인터뷰 총괄 기획자이자 HCI/심리학 연구 방법론 전문가로서 인터뷰 전략과 질문 흐름을 만든다. AI Interviewer는 실제 인터뷰 수행자로서 참여자와 대화한다. Insight Analyst는 질적 연구 분석가로서 원문을 분석하고 패턴을 정리한다.

이 구조에서 중요한 점은 Context Architect였다.

Context Architect는 바로 결과물을 만들지 않았다. 먼저 나를 질문했다.

이 리서치의 핵심 목적은 무엇인가. 인터뷰이는 어떤 사람들인가. 반드시 알고 싶은 질문은 무엇인가. 최종 산출물은 무엇이어야 하는가. 인터뷰 중 피해야 할 질문 방식은 무엇인가. 인터뷰이가 연구 의도를 알아도 되는가. 시간과 형식의 제약은 무엇인가.

이 과정이 이번 실험의 품질을 크게 좌우했다고 본다.

AI를 잘 쓰는 것은 단순히 “해줘”라고 잘 말하는 일이 아니었다. AI가 일을 잘하려면, 먼저 AI가 충분히 모르는 상태라는 것을 인정해야 했다. 그래서 AI가 내게 역질문을 하게 만들고, 그 질문에 답하면서 맥락을 계속 채워 넣어야 했다.

나는 Context Architect에게 상당히 많은 맥락을 전달했다.

우리는 HCI 맥락에서 할 일과 일정 관리를 돕는 물리적 제품을 탐색하고 있었다. 기존 앱이 가진 문제는 앱 안에 기능이 없다는 것이 아니라, 앱이 사용자의 시야에서 사라지면 할 일도 함께 사라진다는 점이었다. 접근성과 가시성을 높이고, 사용자가 관리 행동을 장기적으로 유지할 수 있는 구조가 필요했다.

이전 리서치에서 나온 생각도 함께 전달했다.

앱의 캐릭터나 성격이 너무 강하면 오히려 거부감이 생길 수 있다. 워크플로우는 사람마다 다르기 때문에 하나의 앱이 모든 사람의 관리 방식을 대체하기 어렵다. 할 일을 입력하는 행위는 어떤 사람에게는 귀찮은 노동이지만, 어떤 사람에게는 이미 통제하고 있다는 감각을 주기도 한다. 작은 일과 큰 milestone은 다르게 다뤄져야 하고, 외부 동기와 가시성은 습관 형성에 중요한 영향을 줄 수 있다.

인터뷰 대상에 대한 맥락도 줬다.

대부분은 Apple Developer Academy 안팎에서 접근 가능한 사람들이었다. 20대부터 50대까지 있을 수 있었고, 개발자, 디자이너, 기획자, 멘토 등 역할도 섞여 있었다. 인터뷰는 30분에서 1시간 정도의 채팅 기반으로 진행할 예정이었다. 참여자에게 링크를 보내면, 참여자는 AI 인터뷰어와 직접 대화하는 방식이었다.

가장 중요한 제약도 명확히 전달했다.

인터뷰이는 연구 의도를 직접 알아차리면 안 된다.

우리가 알고 싶은 질문은 “습관은 의지인가 자동화인가”, “입력은 허들인가 성취감인가”, “타겟은 관리가 어려운 사람인가 이미 잘하는 사람인가”였지만, 이 질문을 그대로 물으면 안 됐다. 참여자는 자신의 경험을 말해야 했고, AI 인터뷰어와 분석 에이전트가 그 경험에서 패턴을 추론해야 했다.

이렇게 보면 프롬프트는 단순한 명령문이 아니었다.

오히려 프롬프트는 연구 맥락을 AI가 일할 수 있는 구조로 번역하는 과정이었다.

Context Architect: 맥락 수집과 역할 설계

Context Architect의 역할은 프롬프트 전문가이자 맥락 수집자였다.

Context Architect는 인터뷰를 직접 하지 않았다. 질문지도 만들지 않았다. 분석도 하지 않았다. 대신 전체 리서치가 시작되기 전에, 연구자가 가진 암묵적인 맥락을 꺼내고 그것을 Interview Designer, AI Interviewer, Insight Analyst가 사용할 수 있는 형태로 바꾸었다.

Context Architect가 없었다면 AI는 아마 그럴듯한 질문지를 만들었을 것이다.

“평소 어떤 투두 앱을 사용하시나요?”
“할 일 관리를 할 때 가장 어려운 점은 무엇인가요?”
“어떤 기능이 있으면 좋겠나요?”

이런 질문은 나쁘지 않아 보일 수 있다. 하지만 이번 리서치에는 충분하지 않았다.

우리는 feature request를 모으고 싶었던 것이 아니었다. 사용자가 실제로 어떤 순간에 할 일을 놓치는지, 기록이 언제 부담이 되고 언제 통제감이 되는지, 시야 안에 돌아오는 구조가 어떻게 행동을 바꾸는지 알고 싶었다.

Context Architect는 이 차이를 먼저 정리했다.

그리고 각 에이전트의 책임을 분리했다.

Interview Designer는 방법론을 설계한다. AI Interviewer는 대화를 수행한다. Insight Analyst는 원문을 분석한다. Context Architect는 이들이 같은 맥락 위에서 일할 수 있도록 초기 프롬프트와 역할 설명을 만든다.

이 분리는 단순히 보기 좋은 구조가 아니었다.

하나의 AI에게 모든 것을 맡기면, 질문 설계와 인터뷰 수행과 분석이 한 덩어리로 섞인다. 그러면 어디에서 문제가 생겼는지 추적하기 어렵다. 질문이 잘못된 것인지, 인터뷰 수행이 얕았던 것인지, 분석이 과잉 해석한 것인지 나중에 분리해서 보기 어렵다.

역할을 나누자 각 단계의 품질을 따로 볼 수 있었다.

맥락 수집이 충분했는가. 질문 흐름이 연구 목적과 맞는가. 인터뷰어가 직접적인 질문을 피했는가. 분석자가 원문에 근거해 해석했는가.

이것이 Context Architect를 둔 가장 큰 이유였다.

Interview Designer: 질문지가 아니라 인터뷰 전략을 설계했다

Interview Designer는 인터뷰 총괄 기획자 역할이었다.

Interview Designer에게 기대한 것은 단순한 질문 목록이 아니었다. HCI와 심리학 연구 방법론을 이해하는 사람처럼, 연구 목적을 보존하면서도 참여자가 자연스럽게 자기 경험을 말할 수 있는 흐름을 만드는 것이었다.

Interview Designer가 잡은 방향은 경험 중심 내러티브 추출이었다.

참여자는 연구 질문에 답하는 사람이 아니라, 자신의 일상과 실패 경험과 감정을 말하는 사람이다. 연구 질문에 대한 답은 인터뷰 이후 분석 단계에서 도출한다.

그래서 Interview Designer는 직접 질문을 금지했다.

나쁜 질문은 이런 식이었다.

“습관은 의지의 문제라고 생각하시나요?”
“입력은 허들인가요, 성취감인가요?”
“관리를 못하는 사람을 위한 제품이 필요할까요?”

좋은 질문은 더 생활에 가까웠다.

“요즘 해야 할 일은 주로 어디에 두세요?”
“꾸준히 하다가 흐지부지된 경험이 있나요?”
“할 일을 적을 때 어떤 느낌이 드나요?”
“눈에 잘 보이면 행동이 달라지나요?”

질문 흐름은 6단계로 나뉘었다.

첫 번째는 워밍업과 기본 맥락 파악이었다. 요즘 어떤 일을 하고 있는지, 하루가 보통 어떻게 흘러가는지, 해야 할 일이 생기면 어디에 두는지 묻는다.

두 번째는 현재 할 일 관리 방식이었다. 지금 쓰는 방식이 잘 맞는지, 언제 막히는지, 스스로 정리가 잘 되는 편이라고 느끼는지 확인한다.

세 번째는 성공과 실패 경험이었다. 꾸준히 관리가 잘 됐던 경험, 흐지부지된 경험, 자연스럽게 된 일과 억지로 해야 했던 일을 비교한다.

네 번째는 기록 행위와 감정이었다. 할 일을 적을 때 어떤 느낌이 드는지, 적고 나서 후련한지 부담스러운지, 체크박스나 완료 표시가 어떤 의미를 갖는지 본다.

다섯 번째는 환경과 외부 트리거였다. 눈에 보이는 위치, 포스트잇, 캘린더, 위젯, 알림, 주변 사람의 리듬이 행동에 어떤 영향을 주는지 확인한다.

여섯 번째는 이상적인 상태였다. 완벽한 할 일 관리가 있다면 어떤 모습인지, 지금 하나만 바꿀 수 있다면 무엇을 바꾸고 싶은지 묻는다.

이 흐름은 단순한 질문 목록보다 훨씬 유용했다.

왜냐하면 각 질문이 어떤 GQ를 우회적으로 보기 위한 것인지 연결되어 있었기 때문이다.

예를 들어 “눈에 보이면 행동이 달라지나요?”는 단순한 사용성 질문이 아니었다. 습관이 의지보다 환경 구조에 더 가까운지 보기 위한 질문이었다.

“할 일을 적을 때 어떤 느낌이 드나요?”는 입력 UX의 불편함만 묻는 질문이 아니었다. 입력이 허들인지, 통제감인지, 성취감인지 보기 위한 질문이었다.

AI Interviewer: 실제 인터뷰 수행

AI Interviewer는 실제 인터뷰어 역할을 맡았다.

여기서도 중요한 것은 AI가 질문지를 기계적으로 읽지 않도록 만드는 것이었다.

AI Interviewer에게 준 지침은 명확했다.

질문을 순서대로 읽지 말 것. 참여자의 답변에 따라 순서를 바꿀 것. 연구 목적을 드러내지 말 것. “습관”, “자동화”, “제품”, “기능” 같은 단어를 먼저 꺼내지 말 것. 참여자에게 solution을 요구하지 말 것. 한 번에 두 질문을 하지 말 것. 추상적인 답이 나오면 실제 경험으로 다시 돌아갈 것.

실제 인터뷰의 시작도 제품이나 연구 질문을 바로 꺼내지 않았다.

대화는 “사람들이 일상에서 시간과 할 일을 어떻게 다루는지에 대한 이야기를 나누는 자리”라는 식으로 시작했다. 정답이 있는 것이 아니라 실제 경험과 솔직한 이야기가 중요하다고 안내했다. 첫 질문도 “요즘 어떤 일을 하고 계신가요?”와 “평소 하루가 어떻게 흘러가는 편인가요?”처럼 넓고 자연스러운 질문으로 들어갔다.

이 설계가 중요한 이유는 참여자가 방어적으로 답하지 않게 하기 위해서였다.

처음부터 “할 일 관리를 잘하시나요?”라고 물으면 사람은 자기 이미지를 의식한다. “왜 투두 앱을 오래 못 쓰나요?”라고 물으면 실패를 변명하려고 할 수 있다. “AI가 자동으로 입력해주면 좋을까요?”라고 물으면 기능 선호처럼 답할 수 있다.

하지만 하루의 흐름, 실제로 쓰는 도구, 흐지부지된 경험, 기록할 때의 감정을 묻기 시작하면 대화가 조금 달라진다.

참여자는 평가받는 사람이 아니라 자기 경험을 설명하는 사람이 된다.

AI Interviewer는 후속 질문 방식도 어느 정도 안정적으로 수행했다.

참여자가 특정 단어를 쓰면 그 단어를 다시 되돌려 물었다. 예를 들어 “머리가 복잡해져서 적는다”는 답이 나오면, “복잡하다는 느낌이 구체적으로 어떤 상황에서 생기나요?”처럼 다시 들어간다.

성공 경험과 실패 경험을 비교하기도 했다. “그때는 잘 됐는데, 흐지부지된 때와 무엇이 달랐나요?” 같은 방식이다.

감정도 물었다. “적고 나면 후련했나요, 아니면 더 부담스러웠나요?” 같은 질문은 입력 행위가 어떤 의미를 갖는지 보는 데 도움이 됐다.

이번 실험에서 AI 인터뷰어는 생각보다 안정적이었다.

물론 숙련된 중급 이상의 인터뷰어보다 잘한다고 말할 수는 없다. 그것은 별도의 비교 실험이 필요하다. 좋은 인터뷰어는 침묵의 무게, 말하지 않은 불편함, 관계의 온도, 비언어적 신호까지 다룬다. 채팅 기반 AI 인터뷰가 그 수준을 대체한다고 말하기는 어렵다.

하지만 적어도 주니어급 인터뷰어가 흔히 겪는 문제는 꽤 잘 피했다.

연구자가 알고 싶은 답을 직접 묻지 않았다. 참여자의 답을 너무 빨리 결론으로 끌고 가지 않았다. 질문지 순서에만 갇히지 않았다. 추상적인 답변을 들었을 때 그대로 넘기지 않고 다시 실제 장면을 물었다.

이 지점은 이번 실험에서 가장 인상적이었다.

AI가 인터뷰를 잘했다기보다, 좋은 인터뷰어가 해야 하는 일부 운영 원칙을 안정적으로 지켰다고 보는 편이 더 정확하다.

Insight Analyst: 원문을 GQ별 인사이트로 바꾸는 역할

Insight Analyst는 분석 역할이었다.

Insight Analyst에게 기대한 것은 단순 요약이 아니었다. 인터뷰 원문을 읽고, 표면적 발언뿐 아니라 맥락, 감정 흐름, 반복 패턴을 정리하는 것이었다.

분석 템플릿은 크게 네 가지였다.

첫째, 참여자별 기본 프로필과 관리 수준 자가 인식.
둘째, GQ1인 습관화에 대한 관련 발언과 해석.
셋째, GQ2인 입력 행위의 감정과 역할.
넷째, GQ3인 타겟 구분에 대한 행동 패턴.

그 뒤에는 인터뷰 간 공통점과 차이점, 제품 방향성 힌트, 추가 분석 필요 지점을 정리했다.

Insight Analyst 분석에서 반복적으로 나온 핵심 패턴은 몇 가지였다.

첫째, 가시성은 기억을 보조하는 수준이 아니라 기억을 대체하는 구조처럼 작동했다.

사람들은 할 일을 계속 머릿속에 들고 있어서 행동하는 것이 아니었다. 다시 보이면 돌아왔다. 보이지 않으면 사라졌다. 포스트잇, 위젯, 캘린더, 미리알림이 작동하는 이유는 기능이 완벽해서가 아니라 생활 중 다시 마주치게 하기 때문이었다.

둘째, 자동화 욕구는 하나의 기능으로 묶이지 않았다.

어떤 사람은 놓침 방지와 캘린더화를 원했다. 어떤 사람은 관리 행위 전체를 위임하고 싶어 했다. 어떤 사람은 중단된 작업을 다시 이어갈 수 있게 해주는 후처리를 원했다. 어떤 사람은 생각의 classification을 원했다.

따라서 “AI가 자동으로 입력해준다”는 말은 너무 넓었다.

자동화는 캡처, 분류, 우선순위화, 일정화, 다음 행동화, 회수 리마인드, 회고와 지식화로 나뉘어야 했다.

셋째, 입력은 세 가지 역할로 나뉘었다.

비우기, 붙잡기, 행동화.

어떤 사람에게 입력은 머릿속을 비우는 행위였다. 어떤 사람에게 입력은 잊지 않기 위해 붙잡는 행위였다. 어떤 사람에게 입력은 막연한 일을 행동 가능한 단위로 바꾸는 행위였다.

그래서 입력을 무조건 줄이는 것이 답은 아니었다.

입력은 허들이 될 수 있지만, 동시에 통제감과 성취감을 줄 수도 있었다. 제품이 입력을 자동화하려면 이 차이를 구분해야 했다.

넷째, “관리 잘함”과 “관리 못함”이라는 이분법은 부정확했다.

대부분의 사람은 자기 방식으로 어떻게든 관리하고 있었다. 다만 무너지는 지점이 달랐다. 어떤 사람은 시야에서 사라지면 무너졌다. 어떤 사람은 큰 일을 작게 쪼개지 못해 무너졌다. 어떤 사람은 변동성이 큰 환경에서 낡은 계획을 유지하는 비용 때문에 무너졌다.

그래서 초기 타겟은 “관리 못하는 사람 전체”가 아니라, “관리하고 싶지만 회수, 입력, 가시성에서 무너지는 사람”에 더 가까웠다.

이 분석은 제품 방향에도 영향을 주었다.

더 완벽한 투두 앱을 만드는 것이 아니라, 할 일이 생활 시야 안으로 다시 돌아오고, 사용자가 작게 시작할 수 있게 만들고, 입력 이후의 정리 비용을 줄이는 구조를 더 봐야 한다는 생각이 강해졌다.

사람이 어디까지 개입했고, AI는 어디부터 맡았는가

이번 실험을 “AI가 리서치를 대신했다”고 말하면 정확하지 않다.

사람이 빠진 것이 아니라, 사람의 개입 지점이 바뀌었다.

사람이 맡은 일은 분명했다.

리서치 목적을 정했다. 제품 맥락을 정의했다. GQ를 잡았다. 인터뷰 대상의 범위를 정했다. AI가 직접 물으면 안 되는 질문을 정했다. 참여자를 모집하고 링크를 보냈다. 결과를 저장했다. 마지막 해석이 과도하지 않은지 다시 봤다.

AI가 맡은 일도 분명했다.

맥락을 이해하기 위해 연구자에게 질문했다. 에이전트 역할을 설계했다. 인터뷰 전략을 만들었다. 질문 흐름을 구성했다. 참여자와 실제로 대화했다. 원문을 GQ별로 분석했다. 공통 패턴과 제품 시사점을 정리했다.

이 분리가 중요했다.

AI가 잘할 수 있는 부분과 사람이 책임져야 하는 부분을 섞어버리면, 결과가 좋아 보여도 믿기 어렵다. 반대로 역할이 분리되어 있으면 검토할 수 있다.

Context Architect가 맥락을 충분히 물었는가. Interview Designer의 질문 흐름이 연구 목적과 맞는가. AI Interviewer가 직접 질문을 피했는가. Insight Analyst가 원문에 근거해 분석했는가.

이렇게 볼 수 있어야 AI 리서치가 단순한 자동 생성 결과물이 아니라 운영 가능한 프로세스가 된다.

이번 실험의 한계

이번 실험은 가능성을 보여주었지만, 한계도 분명했다.

첫째, 표본 편향이 있었다.

참여자는 대부분 내가 접근할 수 있는 네트워크 안에 있었다. Apple Developer Academy 구성원이 많았고, 연령대와 직군도 특정 맥락에 치우쳐 있었다. 따라서 이 결과를 일반 사용자 전체로 확대해서 말하기는 어렵다.

둘째, 인터뷰 간 비교 가능성이 완벽하지 않았다.

AI Interviewer는 참여자의 답변에 따라 질문 흐름을 유연하게 바꾸었다. 이것은 자연스러운 인터뷰를 위해서는 장점이지만, 모든 참여자에게 동일한 질문을 던진 것은 아니기 때문에 비교 기준이 흔들릴 수 있다.

셋째, 저장과 후처리 방식이 일관되지 않았다.

ChatGPT와 Claude를 혼용했고, 어떤 인터뷰는 HTML 형태로 저장되었고, 어떤 인터뷰는 공유 링크나 UI 요약 형태가 섞였다. 원문을 안정적으로 보존하고 분석 가능한 형태로 정제하는 프로세스는 더 다듬어야 한다.

넷째, AI 분석은 과잉 해석할 수 있다.

AI는 패턴을 잘 찾지만, 때로는 충분히 반복되지 않은 것을 의미 있는 패턴처럼 묶을 수 있다. 그래서 AI가 만든 분석은 결론이 아니라 가설로 다뤄야 한다. 최종 판단은 사람이 다시 해야 한다.

이 한계 때문에 이번 실험은 검증 리서치라기보다 초기 탐색 리서치에 가깝다.

하지만 초기 탐색 단계에서는 충분히 의미가 있었다. 아직 무엇을 모르는지도 모르는 상황에서, 여러 사람의 경험을 빠르게 수집하고, 반복되는 패턴을 찾고, 다음 제품 질문을 만드는 데 도움이 됐다.

결론

이번 실험을 통해 AI를 리서치에 쓰는 방식에 대한 생각이 바뀌었다.

처음에는 AI가 인터뷰를 잘할 수 있는지가 궁금했다.

지금은 질문이 조금 바뀌었다.

AI가 잘 인터뷰하게 만들기 위해, 사람은 무엇을 먼저 설계해야 하는가.

내가 지금까지 얻은 답은 세 가지다.

첫째, AI에게 바로 산출물을 요구하지 말고, 먼저 AI가 나를 질문하게 해야 한다.

AI가 충분한 맥락 없이 만든 결과물은 그럴듯하지만 얕다. 반대로 AI가 연구 목적, 참여자, 제약, 금지 질문, 최종 산출물을 충분히 이해하면 결과물의 방향이 달라진다.

둘째, 역할을 나누어야 한다.

맥락 수집, 질문 설계, 인터뷰 수행, 원문 분석은 서로 다른 일이다. 이 역할을 하나로 합치면 편하지만 검토하기 어렵다. 나누면 번거롭지만 품질을 관리할 수 있다.

셋째, 사람은 판단을 놓지 않아야 한다.

AI는 인터뷰를 수행하고 분석할 수 있다. 하지만 무엇을 물어야 하는지, 무엇을 직접 물으면 안 되는지, 어떤 분석이 과잉 해석인지, 어떤 인사이트를 제품 방향으로 가져갈지는 사람이 책임져야 한다.

그래서 나는 AI Driven Interview를 “사람이 빠지는 리서치”라고 이해하지 않게 되었다.

오히려 반대에 가깝다.

AI Driven Interview는 사람이 리서치의 목적, 맥락, 역할, 판단 기준을 더 명확히 설계해야 하는 리서치 방식이었다.

AI가 인터뷰를 할 수 있다는 사실보다, AI가 인터뷰를 잘하게 만들기 위해 사람이 먼저 무엇을 정리해야 하는지가 더 중요했다.