세계 챗봇 생태계를 읽는 틀

 

챗봇 이야기가 나올 때마다 어떤 이야기는 메신저 안의 봇이고, 어떤 이야기는 스피커 속 음성 비서라서 같은 말인데 다른 대상을 가리키는 느낌이 들었어요.
기사를 읽다 보면 소식은 많은데 어디에 놓고 봐야 할지 감이 오지 않을 때가 있습니다.
그래서 이번에는 개별 소식이 아니라 세계 챗봇 생태계를 읽는 틀을 하나 만들어 보려고 합니다.
수치나 순위는 쓰지 않고, 구조를 나누는 기준만 정리하겠습니다.
제가 실무에서 챗봇을 기획하면서 쓰고 있는 분류이고, 틀린 부분은 계속 고쳐 나갈 생각이에요.

 

챗봇은 기술 이름이 아니라 사용 방식에 가까운 말이라고 생각해요.
대화로 무언가를 처리한다는 점은 같지만, 그 대화가 어디에서 일어나는지에 따라 사업 구조와 기획 포인트가 많이 달라집니다.
저는 세 가지 질문으로 나눠 봅니다.

• 이 대화는 어디에서 일어나는가 (채널)
• 누가 대화의 길목을 쥐고 있는가 (플랫폼 주체)
• 누가 돈을 내고 무엇을 얻는가 (수익 구조)

이 세 질문에 답하면 대부분의 챗봇을 메신저 플랫폼형, 스피커와 어시스턴트형, 기업형 세 가지 중 하나에 놓을 수 있었어요.

 

메신저 플랫폼형

메신저 서비스가 외부 개발자나 기업에 봇을 만들 수 있게 열어 주는 형태입니다.
사용자는 이미 매일 쓰는 앱 안에서 봇을 만나기 때문에, 별도 앱 설치라는 허들이 사라집니다.
기획자 입장에서 좋은 점은 사용자 확보 비용이 낮아 보인다는 점이고, 조심할 점은 플랫폼의 규칙에 종속된다는 점이에요.
메시지를 보낼 수 있는 시점, 쓸 수 있는 버튼과 카드 형태, 심사 기준을 모두 플랫폼이 정합니다.
나라마다 많이 쓰는 메신저가 다르기 때문에, 같은 봇이라도 지역마다 따로 만들어야 하는 경우가 생기기도 해요.
그리고 메신저 안의 봇은 일상 대화와 같은 공간에 있어서 알림 피로가 빠르게 쌓인다는 점도 눈여겨보고 있습니다.
그래서 이 유형에서는 먼저 알림을 보내기보다, 사용자가 필요할 때 스스로 불러 쓸 이유가 있는지를 따져 보게 돼요.
친구와 가족 사이의 대화 속에 끼어드는 만큼, 봇이 말을 거는 방식에도 예의가 필요하다고 느낍니다.

 

스피커와 어시스턴트형

이쪽은 음성 비서가 스피커나 스마트폰 같은 기기에 들어가 있는 형태예요.
채널이 화면이 아니라 목소리라서, 버튼을 누르는 대신 말로 시작하고 말로 끝내야 합니다.
플랫폼 주체는 기기와 비서를 함께 가진 회사이고, 외부 개발자는 비서의 기능을 확장하는 작은 앱 형태로 들어가는 경우가 많습니다.
사용자가 기능을 이름으로 불러야 하는 구조라서, 좋은 기능이어도 존재를 모르면 쓰이지 않는다는 어려움이 있어요.
화면이 없으니 긴 목록을 보여 줄 수 없고, 한 번에 전달할 수 있는 정보의 양이 짧아집니다.
이 형태는 대화 설계보다 발화 설계, 즉 사람이 어떤 말로 부를지를 먼저 상상하는 일이 중요하다고 느꼈어요.
집이나 차 안처럼 손을 쓰기 어려운 상황에서 힘을 낸다는 점도 이 유형의 특징입니다.
반대로 사람이 많은 공공장소에서는 기기에 말을 거는 일이 어색해서 쓰임이 줄어든다는 한계도 있어요.

 

기업형

기업이 자기 서비스의 고객 응대나 내부 업무를 위해 직접 만드는 챗봇입니다.
앞의 두 유형이 남의 플랫폼 위에서 움직인다면, 기업형은 자사 앱이나 웹, 콜센터 옆 채널 등에 심는 경우가 많아요.
목표가 구체적이어서 평가하기 쉽다는 장점이 있습니다.
예를 들어 문의 처리 시간이 줄었는지, 상담원에게 넘어가는 비율이 어떻게 변했는지 같은 지표로 볼 수 있어요.
반면 고객 데이터와 사내 시스템에 연결되어야 해서, 기술보다 연동과 권한 문제에서 일이 오래 걸리는 편입니다.
사내 직원을 위한 챗봇은 휴가 신청이나 규정 문의처럼 범위가 좁아서, 의외로 가장 먼저 쓸모를 보이는 영역이기도 해요.
또 하나, 기업형은 챗봇이 풀지 못할 때 사람에게 넘기는 경로가 거의 필수로 따라옵니다.
이 경로를 어떻게 설계하느냐가 곧 서비스 품질이라고 해도 과언이 아니에요.

 

 

가정해서 전국에 매장이 있는 카페 체인이 챗봇을 낸다고 해 볼게요.
어디서부터 시작할지를 틀로 따져 보는 겁니다.

• 메신저 플랫폼형: 주문 알림과 쿠폰을 메신저로 보낸다. 사용자 접근은 쉽지만 플랫폼 규칙에 맞춰야 한다.
• 스피커와 어시스턴트형: 말로 "늘 마시던 걸로"를 주문한다. 편하지만 메뉴를 말로만 전달하는 설계가 어렵다.
• 기업형: 자사 앱 안의 문의 봇으로 영업시간, 포인트 조회, 불만 접수를 처리한다. 데이터 연동이 핵심이다.

이 가상 사례에서는 기업형으로 시작해 쓸모를 확인하고, 이후 메신저로 확장하는 순서가 현실적으로 보입니다.
물론 실제 판단은 고객이 어느 채널에 모여 있는지, 개발 인력이 얼마나 되는지에 따라 달라지겠지요.

 

이 틀을 쓰면 새로운 챗봇 소식을 봐도 "이건 어느 유형이고, 길목은 누가 쥐고 있나"를 먼저 묻게 됩니다.
소식이 쏟아질수록 개별 기능보다 구조를 보는 눈이 더 필요하다고 생각해요.
다만 세 유형의 경계는 점점 흐려질 것 같습니다.
메신저 안에 기업형 봇이 들어가고, 스피커가 기업 서비스와 연결되는 일이 이미 늘고 있으니까요.
남은 질문은 사용자가 결국 어디에서 가장 오래 대화하게 될까, 그리고 그 길목이 소수 플랫폼으로 모이게 될까 하는 점입니다.
틀을 쓸 때 조심하는 점은, 분류가 깔끔하다고 현실도 깔끔한 것은 아니라는 사실이에요.
틀은 읽기 위한 도구이지 정답표가 아니라서, 소식을 볼 때마다 맞지 않는 부분을 메모해 두려고 합니다.
다음에 새 소식을 접하면 이 틀에 놓아 보고, 맞지 않는 부분이 생기면 분류를 다시 고쳐 쓰겠습니다.