요구사항 없이 일정을 세워야 하는 현실
3
요구사항이 없는 게 문제가 아니라, 요구사항을 찾는 시간이 곧 일정의 시작이다.
1. 일정은 시작부터 흔들린다
보이스봇 프로젝트가 어려운 이유는 단순하다.
명확한 요구사항이 정리되기도 전에, 일정부터 세워야 하기 때문이다.
기업은 계약·예산·기한이라는 ‘관리의 언어’로 프로젝트를 바라본다.
“언제까지 만들 수 있나요?”라는 질문은 빠르지만, “무엇을 만들어야 하나요?”라는 질문은 늘 늦게 온다.
현장은 그 사이에서 흔들린다.
요구사항이 불명확한 상태에서 세운 일정은 모든 팀을 불안하게 만든다.
그럼에도 프로젝트는 멈출 수 없다.
계약은 이미 체결됐고, 고객은 일정표를 기다리고 있기 때문이다.
결국 일정은 ‘정의된 일’을 관리하는 게 아니라, ‘정의되지 않은 일’을 함께 찾아가는 과정이다.
보이스봇의 일정은 그 역설 위에서 시작된다.
2. 불확실한 일정 속에서 살아남는 세 가지 방법
요구사항이 모호한 현실에서 일정을 세울 때, 프로젝트의 생존율을 높이는 전략은 세 가지다.
콜 분석, 학습형 오픈, 그리고 단계별 오픈 전략.
2-1. 콜 분석: 요구사항을 ‘찾는 일정’으로 시작하라
보이스봇은 인공지능(AI) 기술의 한 종류다.
사람의 음성을 인식하고, 그 속에서 의미를 찾아 응답한다.
하지만 기술보다 먼저 필요한 것은 ‘사람이 어떤 말을, 어떤 맥락에서 하는가’를 이해하는 일이다.
그래서 첫 번째 일정은 ‘콜 분석(Call Analysis)’이다.
이건 단순히 통화 녹취를 듣는 단계가 아니다.
고객의 발화와 상담사의 언어 속에서 요구사항의 실마리를 찾아내는 과정이다.
이 과정에서 얻게 되는 것은 세 가지다.
① 고객이 자주 문의하는 주제와 흐름을 구조화한다.
② 실제 발화 데이터를 기반으로 대표 시나리오를 설계한다.
③ 자동화가 가능한 영역과 사람이 직접 대응해야 하는 영역을 구분한다.
이 세 가지가 정리되어야 비로소 ‘설계’가 가능하다.
콜 분석은 ‘요구사항을 정의하기 위한 공식 일정’이다.
Insight. 콜 분석은 숫자보다 ‘감’을 되살리는 일이다.
보고서엔 없는 온도와 맥락을 듣는 순간, 우리는 다시 ‘고객의 언어’로 돌아온다.
프로젝트가 길을 잃는 건, 데이터가 부족해서가 아니라 사람의 감을 잃었을 때다.
2-2. 시범 오픈: ‘학습형 일정’으로 불확실성을 줄여라
시범 오픈(Pilot Open)은 단순한 예행연습이 아니다.
기술의 완성도를 확인하는 동시에, 현장의 언어를 배우는 시간이다.
고객이 “배송이 왜 늦죠?”, “상담 연결은 언제 돼요?”라고 말할 때, 이 문장은 단순한 문의가 아니라 ‘데이터’가 된다.
이런 말들이 쌓이면, 고객이 어떤 언어로 세상을 표현하는지가 드러난다.
설령 같은 문의라도 “택배가 안 와요”, “기사님이 연락이 없어요”처럼 표현은 제각각이다.
이런 다양성을 반영하지 않으면, 고객은 “이 봇은 내 말을 못 알아듣는다”라고 느낀다.
시범 오픈은 그 말을 수집하고, AI가 현장의 어휘를 익히는 학습 단계다.
이때 중요한 건 완벽한 모델이 아니라 빠른 피드백이다.
짧은 오픈과 빠른 수정이 반복될수록 보이스봇은 실제 고객의 언어에 가까워진다.
Insight. 완벽보다 빠른 반복
1~2주 단위의 짧은 주기를 여러 번 돌리는 것이 가장 현실적인 학습 방식이다.
2-3. 오픈 전략: 대화의 성격에 따라 다르게 설계하라
모든 대화는 동일하지 않다.
보이스봇이 다루는 대화의 성격은 크게 두 가지다.
인바운드와 아웃바운드.
결국 일정은 ‘속도’의 문제가 아니라 ‘순서’의 문제다.
보이스봇 오픈의 성패는 ‘어떤 순서로, 어디까지’ 열 것인가에 달려 있다.
2-3-1. 아웃바운드 콜: 단계적 오픈으로 안착시키기
아웃바운드는 통제가 가능한 대화다.
기업이 먼저 전화를 걸기 때문에 일부 대상부터 시작해 점진적으로 확대하는 단계적 오픈이 적합하다.
예를 들어, “예약 안내”나 “납부일 알림” 같은 반복형 응대가 대표적이다.
민감도에 따라 순서를 조정하는 것도 중요하다.
예를 들어, 자동차 사고 안내 자동화의 경우 1차 오픈은 피보험자, 이후 차량 소유자·피해자 순으로 확장한다.
단순 알림과 공지부터 시작해, 점차 복잡한 안내로 넓히는 방식이다.
작게 열고 빠르게 개선하는 리듬이 신뢰를 만든다.
2-3-2. 인바운드 콜: 완전 대비 후 전면 오픈하기
인바운드는 고객이 먼저 말을 건다.
문의의 목적이 다양하고 예측이 어렵기 때문에, 부분 오픈은 오히려 혼란을 만든다.
예를 들어 “자차 사고만 보이스봇이 받는다”라고 제한하면, 대화 시작부터 고객에게 사고 유형을 먼저 묻게 된다.
하지만 대부분의 고객은 그 구분을 명확히 이해하지 못한다.
결국 “왜 연결이 안 되죠?”라는 불편으로 돌아온다.
따라서 인바운드는 완전 대비 후 전면 오픈이 원칙이다.
이때 중요한 건 속도가 아니라 신뢰의 순서다.
- 상담사 전환 기준을 명확히 하고,
- 테스트 일정을 충분히 확보하며,
- 피크 시간대를 피해 오픈하는 것.
이 세 가지가 현장을 지키는 최소한의 안전장치다.
2-3-3. 민감도와 정책 변화: 보호를 위한 후순위
모든 업무가 동시에 자동화될 필요는 없다.
완전판매, 보험금 지급, 결제 오류, 정책 변경처럼 규제나 신뢰가 얽힌 업무는 단계적 검증이 반드시 필요하다.
이건 단순히 기업 리스크 관리가 아니다.
상담사와 고객을 보호하기 위한 절차적 안전망이다.
이 단계를 생략하면 결국 고객은 “시스템이 틀렸다”라고 말한다.
보이스봇의 일정이 느려 보이는 건 기술이 부족해서가 아니라 신뢰의 속도를 지키기 위해서다.
3. 정리하며: 일정은 전략이다
보이스봇 프로젝트의 일정은 단순한 타임라인이 아니다.
요구사항 없이 시작하고, 고객 반응을 예측할 수 없는 상황에서 일정은 곧 전략이 된다.
어떤 프로젝트는 분석 없이 오픈을 서둘렀다.
요구사항은 중간에 바뀌었고, 테스트는 줄었으며 결과는 실패였다.
다른 프로젝트는 달랐다.
1.5개월의 콜 분석, 단계적 오픈, 반복 학습.
그 결과 상담사의 부담은 줄었고, 고객의 경험은 지켜졌다.
결국 일정의 성공은 ‘얼마나 빨랐는가’가 아니라 ‘어떤 시간을 먼저 썼는가’에 달려 있다.
한 줄 요약
요구사항 없는 일정은 위험하지만, 요구사항을 찾아가는 일정은 프로젝트를 살린다.