왜 보이스봇 ‘요구사항’은 늘 추상적일까?

2

by 장연우
요구사항이 추상적인 이유는 기술이 부족해서가 아니다.
정의되지 않은 일, 기록되지 않은 흐름, 그리고 변화하지 않는 문화 때문이다.


1. 시작은 언제나 한 줄

보이스봇 프로젝트의 출발은 늘 같다.

“XX 상담을 AI가 할 수 있게 만들어주세요.”

수억 원의 예산과 수개월의 일정, 수십 명의 인력이 투입되지만, 출발점은 이 한 문장이다.
문제는 단순함 속에 방향이 없다는 것이다.
“무엇을, 어떻게, 누구를 위해 만들 것인가?”라는 질문이 빠져 있다.

마치 건축가에게 “집 하나 멋지게 지어주세요.”라고 말하는 것과 비슷하다.
예산과 일정은 있지만, 누가 살 집인지, 어떤 공간이 필요한지, 어떤 재료를 쓸 건지는 정의되지 않은 상태다.
그런 상태에서 아무리 좋은 기술을 써도 ‘무엇을 위한 시스템’인지 모른 채 프로젝트가 시작된다.

보이스봇 프로젝트의 출발점이 특히 모호한 이유는 세 가지 벽 때문이다.

정의되지 않은 일, 기록되지 않은 흐름, 변화하지 않는 문화.


2. 정의되지 않은 일: 구조의 벽

상담은 문서로 배울 수 없는 기술이다.
경험 속에서 축적된 감각, 상황에 따라 달라지는 대처, 그리고 대화의 뉘앙스를 읽어내는 섬세함이 핵심이다.

하지만 많은 조직은 이런 기술을 숫자로 관리한다.
‘평균 통화 시간’, ‘처리 건수’, ‘응답 정확도’ 같은 성과 지표만 남고 대화의 맥락이 사라진다.
대화는 여전히 살아 있는데, 시스템의 언어로는 그 온도를 설명하지 못한다.
그 순간부터 요구사항의 첫 줄은 이미 추상적으로 흐려진다.

요구사항의 기반이 되는 매뉴얼은 존재한다.
그러나 대부분 결과 중심의 지침일 뿐이다.
“진정시킨다”, “안내한다” 같은 표현은 있지만, 그 과정은 담기지 않는다.
그래서 상담사 교육은 실습 중심으로 이루어진다.
상담사들은 매뉴얼을 기반으로, 그 안에 자신의 노하우와 감각을 섞어 응대한다.
‘언제 말을 멈춰야 하는지’, ‘어떤 말이 고객의 불안을 누그러뜨리는지’는 오직 경험을 통해 체득된다.
하지만 이런 ‘감각의 기술’은 문서로 옮겨지지 않는다.
결국 ‘요구사항 정의서’에는 공백이 남는다.

또 다른 이유는 구조에 있다.
상담은 매출과 직접 연결되지 않는다는 이유로 많은 기업에서 핵심이 아닌 지원 업무로 분류된다.
효율을 명분으로 BPO(Business Process Outsourcing, 외주) 업체에 맡기면서, 상담은 조직의 전략적 시선에서 멀어진다.
지표는 남지만, 사람의 경험은 남지 않는다.
수치로만 관리되는 대화, 전략의 바깥에 놓인 사람의 감정.
그 위에서 만들어지는 AI는 필연적으로 추상적일 수밖에 없다.

결국 사람의 경험이 정의되지 않은 상태에서 기술이 설계되는 것, 그것이 첫 번째 벽이다.


3. 기록되지 않은 흐름: 시스템의 벽

상담 시스템에는 수백만 건의 데이터가 쌓인다.
그러나 그 대부분은 결과 데이터다.
주소 변경 완료, 카드 재발급 처리, 문의 없음.

이런 결과만으로는 고객이 왜 전화를 걸었는지, 상담사가 어떤 어조와 흐름으로 대화를 이끌었는지를 알 수 없다.

물론 상담을 하면 녹취가 남고, 상담사가 메모도 남긴다.
하지만 그 기록들은 시스템이 아닌 사람의 손끝에 의존한다.
녹취는 텍스트로 전환되지 않아 분석이 어렵고, 메모는 형식이 제각각이다.
누군가는 문장으로, 누군가는 키워드로 남긴다.
그래서 하나의 상담 경험이 조직의 지식으로 전환되지 못한다.

결국 시스템에는 결과만 남고, 과정은 사라진다.
대화의 흐름이 빠진 기록은 마치 결말만 남은 소설을 읽는 것과 같다.

보이스봇은 이 부족한 정보 위에서 작동해야 한다.
‘얼마나 많은 콜을 처리했는가’는 남지만, ‘무엇이 문제였는가’, ‘어떤 공감이 효과적이었는가’는 남지 않는다.
데이터는 쌓이지만, 지식은 태어나지 않는다.

결국 보이스봇이 사람의 언어를 흉내 낼 수는 있어도, 사람의 의도와 감정의 맥락을 이해하지 못하는 이유가 여기에 있다.


4. 변화하지 않는 문화: 인식의 벽

데이터는 쌓이지만, 지식은 태어나지 않는다.
그 이유는 시스템이 아니라, 시선을 바꾸지 못한 문화에 있다.

보이스봇은 ‘전화를 대신 받는 기술’이 아니다.
‘고객을 대하는 방식을 다시 묻는 기술’이다.
그러나 많은 조직은 여전히 이를 단순한 자동화로 이해한다.

“기계가 고객을 응대할 수 있나요?”라는 질문은 많지만, “우리는 어떤 경험을 지키고 싶은가?”라는 질문은 없다.
이 차이는 결정적이다.

기술의 정교함보다 중요한 건 철학의 정교함이다.
‘무엇을 자동화할 것인가’보다, ‘무엇을 지켜야 할 것인가’를 먼저 정의해야 한다.
철학이 정리되지 않은 채 기술부터 도입하면, 보이스봇은 조직의 논리 속에서 길을 잃는다.

그때 회의실에서는 이런 대화가 반복된다.

“이런 것도 되나요?”
“그건 당연히 되겠죠?”

하나는 과소평가, 하나는 과대평가.
기술은 충분히 발전했지만, 사람에 대한 이해는 제자리다.
보이스봇 요구사항이 추상적으로 남는 이유는 결국 이 간극 때문이다.


5. 함께 찾아가는 요구사항

이 간극을 메우는 일은 문서가 아니라 대화에서 시작된다.
요구사항은 문서로 전달되는 것이 아니라, 함께 찾아가는 과정이다.

“이 업무는 왜 이렇게 처리하나요?”
“고객이 가장 불편해하는 순간은 언제였나요?”
“이 말 뒤에는 어떤 감정이 숨어 있을까요?”

이런 질문이 쌓이면 비로소 문장 하나가 만들어진다.
그 문장은 기능 명세가 아닌, 사람의 경험과 판단이 녹아 있는 ‘살아 있는 요구’가 된다.

요구사항을 정의한다는 건 결국 사람의 일을 이해하는 과정이다.
기술적 정의보다 중요한 건, 현장에서 지금 무엇이 일어나고 있는지를 함께 듣는 일이다.


6. 정리하며: 사람을 위한 설계도

고객은 종종 이렇게 말한다.

“다 말할 수 없어요.”

그 한마디 뒤에는 수많은 사정과 감정이 숨겨져 있다.
그걸 끝까지 들으려는 마음, 그 마음에서 좋은 설계가 시작된다.

결국 성공적인 보이스봇은 사람의 언어를 기술의 언어로 번역할 수 있는 팀에서 태어난다.
그때 비로소 기술은 사람의 일을 이해하게 된다.


한 줄 요약
요구사항은 받아쓰는 문서가 아니라, 사람과 함께 찾아가는 대화다.
이전 01화감정을 이해하는 기술, 사람을 지키는 일