AI에게 답 말고 질문을 시켜라: 클라이언트 인터뷰 자동화의 새로운 접근

한줄 요약

AI를 답변 생성기가 아닌 질문 생성기로 뒤집으면, 외주 개발 요구사항 정의의 품질이 달라진다.

외주 개발에서 프로젝트가 틀어지는 원인 1위는 기술 실력이 아니라 요구사항 오해다. 클라이언트가 원하는 것과 개발사가 만든 것 사이의 간극은 대부분 초기 인터뷰 단계에서 메워지지 못한 빈칸에서 비롯된다.

그런데 지금까지 AI를 활용하는 방식은 대부분 반대 방향이었다. 요구사항 문서를 넣으면 기능 목록을 뽑아주고, 회의록을 넣으면 요약을 만들어주는 식이다. AI가 답을 만들어주는 역할에 머물러 있었다.

여기서 역할을 뒤집으면 어떨까. AI가 답을 쓰는 게 아니라, 클라이언트가 아직 꺼내지 못한 맥락을 질문으로 끌어내는 역할을 맡으면 어떻게 달라질까.

왜 클라이언트는 요구사항을 다 말하지 못하나

클라이언트 대부분은 자신이 원하는 것을 완전한 언어로 표현하지 못한다. 이는 능력의 문제가 아니다. 구조적인 문제다.

자신이 매일 겪는 불편은 너무 당연해서 굳이 설명해야 한다는 생각을 못 한다. 이미 머릿속에 완성된 그림이 있다고 착각하기 때문에 빠진 부분을 인식하지 못한다. 개발 용어를 모르니 어디까지 말해야 할지도 모른다.

그래서 경험 있는 개발사는 인터뷰를 단순한 정보 수집 시간으로 보지 않는다. 클라이언트가 미처 언어화하지 못한 부분을 질문으로 꺼내는 시간으로 운영한다. 문제는 이 과정이 담당자의 개인 역량에 지나치게 의존한다는 점이다. 노련한 PM이 들어가면 잘 되고, 경험이 부족한 담당자가 들어가면 구멍이 생긴다.

AI를 '질문 생성기'로 뒤집는 방법

요구사항 초안이 들어왔을 때 AI에게 기능 목록을 뽑아달라고 하는 게 아니라, 빠진 맥락을 찾아 질문 목록을 만들어달라고 하면 다른 결과가 나온다.

실제로 다음과 같은 구조로 프롬프트를 설계하면 효과가 있다.

• 클라이언트가 제출한 요구사항 문서 또는 인터뷰 녹취를 AI에게 전달한다.
• "이 내용을 바탕으로 개발 범위를 정의하지 말고, 빠진 정보를 파악하기 위한 질문 목록을 만들어라"고 지시한다.
• AI가 생성한 질문을 다음 인터뷰 세션의 가이드로 활용하거나, 클라이언트에게 사전 질문지로 전달한다.

이때 AI에게 좋은 질문을 만들게 하려면, 어떤 종류의 빈칸을 채워야 하는지 명시해주는 것이 핵심이다. 예를 들면 이런 방식이다.

• 이 기능이 없을 때 사용자는 지금 어떻게 이 문제를 해결하고 있는가
• 성공 기준이 숫자로 측정 가능한가, 가능하다면 어떤 지표인가
• 이 기능이 가장 먼저 필요한 사용자는 누구인가
• 예산과 일정 중 절대 양보할 수 없는 쪽은 어느 쪽인가
• 이전에 비슷한 시도를 한 적이 있다면 왜 중단됐는가

이런 질문들은 담당 PM이 경험으로 체득하는 항목들이다. 하지만 AI에게 역할과 탐색 방향을 명확히 지시하면 이 과정의 상당 부분을 자동화할 수 있다.

인터랙티브 요구사항 정의서: 정적 문서에서 대화형 구조로

외주 개발 과정에서 요구사항 정의서는 대부분 정적인 문서다. 클라이언트가 채우고, 개발사가 읽고, 미팅에서 확인한다. 이 구조의 문제는 문서를 작성하는 시점에 빈칸이 보이지 않는다는 점이다.

이걸 대화형 구조로 바꾸면 다르다. 클라이언트가 서비스 아이디어를 자유롭게 입력하면, AI가 그 내용을 읽고 구체화가 필요한 지점마다 질문을 던진다. 클라이언트는 그 질문에 답하면서 자신의 생각을 점점 정밀하게 다듬는다. 충분한 답변이 쌓이면 구조화된 요구사항 초안이 완성된다.

이 방식은 두 가지 이점이 있다.

첫째, 클라이언트의 인지 부담이 줄어든다. 빈 양식을 채우는 것보다 질문에 답하는 쪽이 훨씬 쉽다. 무엇을 써야 할지 몰라 막막해하는 시간이 사라진다.

둘째, 개발사 입장에서는 인터뷰 전에 이미 1차 정제된 자료가 준비된다. 미팅 시간을 기초 정보 수집이 아니라 진짜 중요한 의사결정에 쓸 수 있다.