프롤로그: 왜 시스템 전환을 선택했는가
안녕하세요. ABC Platform 팀에서 플랫폼 기획자로 일하고 있는 김세리입니다. 저는 일본의 음식 배달 서비스인 데마에칸(Demaecan, 出前館)에서 MessagingHub 기획을 담당하고 있습니다.
MessagingHub는 독립적이고 범용적인 올인원 메시징 플랫폼으로, 이번 글에서는 MessagingHub의 핵심 서비스인 CS(customer service) 문의형 채팅, InquiryChat을 데마에칸에 도입한 이야기를 소개하고자 합니다. InquiryChat은 2025년 2월 드라이버용 채팅 지원을 시작으로, 같은 해 12월 데마에칸 앱 전반으로 확장돼 고객과 상담원을 잇는 핵심 채널로 안착했습니다.
InquiryChat 프로젝트는 단순히 기존 솔루션을 대체하는 것을 넘어, 자체 솔루션으로 전환하면서 연간 라이선스 비용을 0원으로 줄여 운영 효율을 극대화했으며, 기술 고도화를 통해 상담 재활성화(재질문) 비율을 약 20% 감소시키는 등 사용자 경험의 질적 성장도 이끌어냈습니다.
이 글에서는 기존에 이용하던 타사 서비스를 InquiryChat 프로젝트를 통해 자체 기술로 내재화하며 마주했던 도전 과제들을 다룹니다. 특히 일본 현지 운영 담당자들과 밀도 높게 협업하면서 프로세스 혁신을 이끌어낸 과정과, PM으로서 앞서 언급한 비용 절감 및 운영 효율화라는 실질적인 성과를 만들어낸 인사이트를 공유하고자 합니다.
기술 내재화를 향한 첫걸음
데마에칸 앱은 약 2년간 타사 솔루션을 이용해 고객 상담 서비스를 제공하고 있었습니다. 그러던 중 기존 채팅 서비스의 종료가 예정되면서 해당 업체의 후속 솔루션으로 업그레이드할 것인지 혹은 자체 기술로 전면 전환할 것인지를 두고 제로베이스에서 폭넓은 검토를 진행하게 되었습니다. 전환을 결정하기까지 여러 채팅 솔루션을 검토했지만, 최종적으로 InquiryChat을 선택한 이유는 명확했습니다. 기술을 내재화해 비용을 절감할 수 있는 것은 물론, 데마에칸의 운영 프로세스에 맞춰 유연하게 대응할 수 있다는 장점이 있었기 때문입니다.
다만 이미 안정적으로 운영하고 있는 시스템을 교체하는 작업은 단순히 기능을 옮기는 것 이상의 의미가 있었습니다. 운영 팀의 업무 프로세스가 바뀌고 상담원이 새로운 툴에 적응해야 했으며 무엇보다 서비스 중단 없이 매끄럽게 전환해야 했습니다.
다음은 InquiryChat과 타사 서비스의 라이선스 비용과 기능을 비교한 표입니다.
| 설명 |
|
|
| 라이선스 비용 | 무료 | 유료 |
| 주문 데이터 연계 | ✅ | ✅ |
| 메시지 읽음 표시 | ✅ | ❌ |
| 메시지 작성 중 표시 | ✅ | ❌ |
| 이미지 파일 첨부 기능 | ✅ | 제한적 지원 (상담원이 파일 전송 요청 시 고객이 이미지 파일 전송 가능) |
| 이미지 파일 미리보기 | ✅ | ❌ |
| 비동기 상담 | ✅ | ❌ |
| 대화 연속성 | ✅ | ❌ |
| 앱 푸시 | ✅ | ❌ |
| 시스템 메시지 | ✅ | ✅ |
| 데이터 통계 | ✅ | ✅ |
| CS 솔루션 연동 | ✅ | ✅ |
| 퀵텍스트 | ❌ | ✅ |
| 대기 순번 표시 기능 | ❌ | ✅ |
기존 서비스에는 기술 관점에서 반드시 살펴보고 해결해야 할 명확한 과제가 있었습니다. 예를 들어 사용자가 작성 중인 메시지를 상담원이 미리 볼 수 있는 보안 취약점이 있었습니다. 미발송 메시지를 상담원이 미리 열람하는 구조는 운영 효율면에서는 이점이 있었으나, 정보 활용 투명성 측면에서 개선할 필요가 있었습니다. 또한 사용자 이탈 시 세션이 유지되지 않아 상담을 처음부터 반복해야 하는 환경 또한 주요 개선 과제였습니다.
다만 이와 같은 보안 이슈나 사용자 경험 개선 과제는 본사와 사용자 관점의 과제였습니다. 매일 시스템을 사용하는 상담원들은 크게 불편함을 느끼지 못한 상태에서 '지금 잘 작동하는 익숙한 도구'를 왜 바꿔야 하는지 이해하기 어려울 수 있다고 생각했습니다.
저는 단순히 문제를 개선하는 것을 넘어 InquiryChat이 상담원 입장에서도 더 사용하기 쉬운 나은 서비스라는 것을 보여주고 싶었습니다. 그런데 이를 실현하기 위해서는 넘어야 할 벽이 있었습니다.
넘어야 할 벽: 물리적 거리와 복잡한 커뮤니케이션 구조에서 비롯된 온도차
InquiryChat이 상담원에게도 더 사용하기 쉽고 나은 서비스가 되기 위해 넘어야 할 벽은 바로 물리적 거리와 복잡한 커뮤니케이션 구조에서 비롯된 온도차였습니다. 데마에칸 본사는 도쿄에 위치하지만 실제 고객 응대를 담당하는 콜 센터는 후쿠오카의 두 지역에 분산되어 있었고, 콜 센터 운영의 일부는 외주 업체가 담당하고 있어 커뮤니케이션 구조가 복잡했습니다.
현황 파악 및 요구 사항 정리
첫 단계로 협업 부서에서 전달받은 기존 서비스의 필수 기능 목록을 보고 현황 파악에 착수했습니다. 다만 초기 목록은 현행 기능을 단순 나열한 것이어서 실제 해당 기능을 사용하고 있는지, 서비스에 맞는 기능인지, InquiryChat 기능을 그대로 사용할 수 있는지 등을 판단하기에는 한계가 있었습니다.
이에 따라 전체 기능을 기능 구현이 필요한지 여부를 기준으로 '기본 제공 기능', '커스터마이징 및 검토 필요 기능', '신규 개발 필요 기능'으로 재분류했습니다. 그 과정에서 신규 개발이 필요한 항목은 필요 여부 및 활용 목적 등의 상세 요구 사항을 면밀히 분석했습니다.
다음은 비즈니스 요구 사항을 재분류 및 분석해 정리한 목록입니다.
| 기본 설정 (채팅방 접속) | 응답 시간 설정 | 상담원이 메시지에 응답하지 않을 경우 시간 설정 가능 | ✅ | |
| 대기 인원 관리 |
대기 인원 36명 초과 시 대기 화면으로 자동 전환 | ⚠️ | MessagingHub에서는 채팅 세션이 유지되기 때문에 신규 메시지로 재접근하는 비율이 낮으므로 실제로 필요한 기능인지 확인 필요 | |
| 기본 설정 (동시 대응) | 동시 대응 건수 설정 | 상담원별 동시 대응 가능 채팅 건수 설정 | ✅ | |
| 관리자 기능 | 채팅 정보 표시 | 채팅 생성 웹사이트, 고객 이름, 요청 응답 대기 시간 표시 | ✅ | |
| 상담원 상태 관리 | 온라인/오프라인/접수 중지 상태 설정 | ✅ | 오프라인 처리 시 자동으로 매칭에서 제외하고 있어 온라인/오프라인 상태만으로 운영 가능 | |
| 채팅 모니터링 | 매니저가 상담원의 채팅을 실시간 모니터링 | ✅ | ||
| 제안 메시지 | 매니저가 상담원에게 비공개 메시지 전송 | ⚠️ | ||
| 미리보기 | 상담원이 메시지를 고객에게 보내기 전에 매니저가 확인 | ⚠️ | 상담원 채팅 미리보기가 활용도가 있을지 운영에 체크해 볼 예정 | |
| 상담원 기능 | 고객 입력 미리보기 | 고객이 메시지를 보내기 전 입력 내용 확인 가능 | ❌ | 보안 취약 사항으로 제외해야 하는 기능 |
| 요청음/알림 | 새 채팅 요청 시 음성 알림 및 데스크톱 알림 표시 | ⚠️ | 사무 공간에서 음성 알림을 인지할 수 있는지 확인 필요 | |
| 커스텀 상담원 이름 | 채팅창에 표시되는 상담원 이름 설정(현재 로마자만 표시) | ✅ | 현재 도메인별 공통 지정도 가능(예: 데마에칸 상담원) | |
| 자동 인사말 | 채팅 수락 시 고객에게 자동 인사말 전송 | ✅ | ||
| 중요 알림 대기 시간 | 고객 메시지에 상담원이 응답해야 할 경우 표시 | ⚠️ | ||
| 파일 전송 | 상담원과 고객 간 파일 전송 활성화 | ✅ | 이미지 파일 전송은 가능하며 그 외 기능이 필요한지 확인 필요 | |
| 지원 플래그 | 상담원이 매니저에게 지원 요청 전송 | ⚠️ | 현재도 사용하고 있는 기능인지 확인 필요 | |
| 연결 끊김 알림 | 채팅 연결 끊김 시 음성 경고음 재생 | ❌ | 채팅 세션이 끊기는 이슈가 해소돼 필요하지 않음 | |
| 데이터 대시보드 | CS 솔루션 통합 관리 | CS 솔루션 대시보드에서 채팅, 이메일 등 모든 문의 현황 일원화 | ⚠️ | MessagingHub → CS 솔루션으로 어떤 데이터를 연계해야 하는지 확인 필요 |
| 실시간 모니터링 | 상담원 대응 상황(온라인/접수 중단) 및 1인당 대응 건수 실시간 확인 | ✅ | ||
| 데이터 연동 | CS 솔루션 자동 연동 | 신규 채팅 시작 시 자동으로 상담 이력 생성 및 정보 연동 | ⚠️ | 어떤 정보를 연동해야 하는지 확인 필요 |
| 설문조사 | 만족도 설문 발송 | 상담 종료 후 설문 URL에 식별값을 자동으로 파싱해 삽입 | ⚠️ | 현재 상담 종료 후 설문조사 URL을 보내고 있는데 추가 식별값으로 어떤 데이터가 필요할지 확인 필요 |
여기서 문제는 시스템의 실제 사용자는 콜센터 상담원과 매니저이지만 요구 사항은 협업 부서를 거쳐 간접 전달되는 구조였다는 것입니다. 이로 인해 각 요구 사항에 해당하는 기능이 현장에서 어떻게 활용되는지 혹은 해당 요구 사항이 어떤 배경에서 도출된 것인지 구체적인 맥락을 파악하기 어려웠습니다.
문서와 미팅을 통해 많은 정보를 얻긴 했지만 정보가 여러 단계를 거쳐 전달되면서 현장의 세밀한 맥락이 희석됐습니다. 상담원들이 실제로 일하는 모습을 직접 보지 못한 상태에서는 실제 요구 사항을 그 맥락까지 온전히 파악하기 어렵다는 것을 깨달았습니다. 상담원에게 정말 필요한 것이 무엇인지, 어떤 어려움을 겪고 있는지 제대로 이해하기 위해서는 직접 현장을 봐야 한다고 판단했습니다.
후쿠오카 현장에서 찾은 답
직접 현장을 보기 위해 후쿠오카 콜 센터 두 곳을 하루씩 방문하는 일정을 잡아 각 콜센터에서 피크 시간대 모니터링을 진행한 뒤 상담원과 매니저를 인터뷰했습니다.
다음은 모니터링 시 사용한 체크 리스트입니다.
| ❏ | 한 명의 상담원이 '채팅' 상담에만 집중하고 있는지? (다른 상담을 병행하지 않는지?) |
| ❏ | 현재 사용하고 있는 타사 솔루션 외 운영 시 다른 프로그램을 사용하고 있는지? |
| ❏ | 로그인 후 채팅 대응까지 접근 화면 흐름 |
| ❏ | 신규 채팅 수신 시 알림 현황 |
| ❏ | 한 명이 동시간에 여러 채팅을 응대하는 경우가 있을지? |
| ❏ | 동시 채팅 진행 시 업무 흐름 |
| ❏ | 지난 채팅 데이터 검색 화면 흐름 |
| ❏ | 채팅 화면에 노출되는 고객 정보 내역 |
| ❏ | 채팅 진행 시 기능 체크 / 텍스트 입력, 발송 외 부가 기능이 있는지? |
| ❏ | 상담 종료 후 내부적으로 처리하는 프로세스 체크 |
| ❏ | 상담이 진행되지 않을 때 어떤 업무를 병행하는지? |
모니터링 후 진행한 인터뷰에서는 사전에 작성된 요구 사항 목록을 살펴보면서 이 요구 사항에 해당하는 실제 운영 환경이 어떤지 의문이 생겼던 부분을 중점적으로 물어봤습니다. 그 과정에서 한 콜센터나 특정 상담원의 답변만으로 전체를 판단하지 않도록 최대한 여러 상담원과 콜센터, 매니저의 의견을 취합해 공통 요구 사항을 파악하려고 노력했습니다.
인터뷰 질문 목록은 다음과 같습니다.
| 상담원이 채팅을 요청할 수 있는지?(사용자에게 직접 연락하는 서비스도 필요하다고 생각하는지?) | 먼저 적용해 사용하고 있던 Consumer쪽 InquiryChat 상담 인원은 몇 명인지? (Consumer쪽에서 InquiryChat으로 교체한 후 상담 인원에 변동이 있었는지?) |
| 전화, 이메일 등 채팅 상담 외 채널 중 채팅 상담으로 대체하면 좋을 항목이 있을지? | 상담원도 대시보드 화면에 접근할 수 있는지? |
| 사용자가 일정 시간 움직임이 없는 경우 자동으로 채팅이 종료되는지? | 채팅에서 용건을 완료하지 못하고 전화를 거는 경우 외에 채팅 검색 화면을 이용하는 경우가 있는지? |
| 사용자가 어떠한 이유로 채팅 화면을 이탈할 경우 상담원 화면에서는 바로 채팅이 종료되는 것인지? | 전화, 이메일 등 채팅 상담 외 채널 중 채팅 상담으로 대체하면 좋을 항목이 있을지? |
| 신규 채팅 서비스에서 꼭 필요하다고 생각하는 기능이 있는지?(현재 사용하고 있는 기능 포함해 기존 채팅 서비스에서는 대응할 수 없었던 기능, 상담원 채팅 및 사용자와의 채팅 포함) | 영업시간은? 영업시간을 자유롭게 조정할 수 있는지? 영업시간 외는 어떻게 표시하는지?(사용자 채팅 화면에서도 확인 필요) |
| 새로운 채팅에 꼭 표시해 줬으면 하는 항목이 있는지?(내부 관리자 화면에서 가져오면 좋겠는 항목) | 신규 채팅 서비스에서 꼭 필요하다고 생각하는 기능이 있는지?(현재 사용하고 있는 기능 포함해 기존 채팅 서비스에서는 대응할 수 없었던 기능, 상담원 채팅 및 사용자와의 채팅 포함) |
|
새로운 채팅에서 아래 기능을 제공하면 CS 솔루션 화면을 보는 일은 거의 없어지는지?
| 대시보드, 통계 화면에서 추가 필요한 기능이 있을지? |
| 사용자가 사진을 추가할 수 있게 되면 상담에 도움이 될지? | 상담원 상태 중 온라인, 오프라인, 일시정지를 사용하는 기준은? |
| 사용자가 유해한 문구를 작성할 경우 필터링이 되는지? | 상담 이력의 카테고리나 상태는 목록에서 선택하는 사양인 것으로 보이는데 이 선택지를 추가나 삭제 등 편집하는 것이 가능한지? |
사전에 준비한 질문 외에도 모니터링 중 궁금했던 점을 인터뷰 시 추가로 질문하며 현장의 맥락을 이해하려 노력했습니다. 그 과정에서 기존 서비스에는 있지만 실제로는 사용하지 않는 여러 기능을 파악할 수 있었습니다. 예를 들어, 상담원이 매니저에게 지원 요청 메시지를 보낼 수 있는 기능이 있었지만 실제로는 손을 드는 제스처로 더 빠르게 소통하고 있었고, 채팅이 끊겼을 때 음성 경고음이 발생하는 기능도 사무실에서는 소리를 켤 수 없어 무용지물이었습니다. 이러한 근거를 바탕으로 협업 부서와 논의할 때 ‘현장에서 이렇게 운영되고 있기 때문에 이 기능은 불필요하다’는 저희의 주장이 설득력을 가질 수 있었습니다.
반면 초기 검토 당시 우선순위가 낮다고 판단했던 기능이 실제 운영에서는 꼭 필요한 기능임을 확인하기도 했습니다. 대표적인 사례가 CS 솔루션과의 데이터 연계 기능입니다. 상담 현장에서는 모든 상담을 종료한 후 상담 내용을 요약 및 기록해 내부로 공유하고 이력을 관리하는 업무를 필수적으로 수행하고 있었기 때문입니다. 만약 MessagingHub에서 데이터를 연동해 주지 않으면 상담원이 수기로 모든 내용을 작성해야 했고, 이는 업무 정리 시간을 크게 늘리는 문제였습니다. 현장을 직접 보고 나서야 이 기능의 중요성을 인식했고 결국 우선순위를 높여 구현했습니다.
이 외에도 향후 추가하면 좋을 여러 기능에 대한 아이디어를 얻었습니다. 이러한 여러 인사이트는 직접 현장에 찾아가 운영 상황을 확인해 보지 않았다면 파악하기 어려웠을 내용이었기 때문에 후쿠오카 현장 방문은 여러모로 매우 의미 있는 시간이었습니다.
보이지 않는 거리의 간극을 메우는 PM의 전략
다음은 출장 이후 다시 정의한 기능 목록입니다.
| High | 채팅 상담 시 CS 솔루션에 상담 이력이 자동 생성되는 기능 | 요청음/알림 | 사무 공간 내에서 알림음 확인 어려움, 다만 웹 팝업에 대해서는 있으면 좋은 기능 |
| Middle | 채팅 모니터링 시 매니저가 코멘트할 수 있는 기능 | 상담원이 사용자에게 채팅을 요청하는 기능 | |
| 관리자 페이지에서 상담원마다 대응할 수 있는 채팅방을 조정할 수 있는 기능 | CS 솔루션에서 채팅 로그를 보는 기능 | MessagingHub에서 제공하는 관리자 페이지에서도 채팅 로그를 확인할 수 있기 때문 | |
| 상담원 기준으로 온라인/오프라인 상태 및 진행 현황을 확인할 수 있는 대시보드 기능 | 파일 전송 | 이미지 첨부 기능이 제공되는 것으로 문제 없음 | |
| 사내 관리, 컨트롤러 간단한 정보 연계 점포명, 배송 상태, 주문 일시, 배달 예정 시각, 배달 방법(비대면/대면), 비대면 배달 완료 사진, 지불 방법 | 지원 플래그 | 사무 공간 내에서 직접 문의 가능 | |
| 템플릿 메시지 | |||
| LOW | 목록에서 사용자가 작성 중임을 표시하는 기능 | ||
| 주문 번호를 기준으로 다른 도메인으로 직접 이동할 수 있는 기능 | |||
| 블랙 리스트 회원 관리 |
위 목록에 기반해 개발이 진행되는 약 2개월 동안 저는 PM으로서 프로젝트 운영 효율을 극대화하고 실행력을 높이는 데 집중했습니다. 한국과 일본의 여러 유관 부서가 얽혀 있는 복잡한 구조 속에서 모든 이해관계자가 동일한 목표를 공유하고 정교하게 움직일 수 있는 시스템을 구축하는 것이 핵심이었습니다.
매일 모든 이해관계자가 현황을 파악할 수 있도록 Slack 채널에 공유한 메시지
먼저 프로젝트를 투명하게 관리하기 위해 Jira 대시보드를 직접 설계 및 정의해 개발 진척도를 실시간으로 시각화하고 지표 기반으로 의사결정할 수 있는 환경을 조성했습니다. 파편화된 요구 사항을 통합한 마스터 사양서를 정립해서 모든 팀이 단일화된 기준(single source of truth) 아래 혼선 없이 협업할 수 있는 커뮤니케이션 가이드라인을 마련했습니다. 또한 단순히 일정을 관리하는 데 그치지 않고 기획 의도가 실제 구현물에 정확히 반영되었는지 검증하기 위해 기획 및 개발 레벨에서 진행하는 내부 QA를 주도적으로 수행하며 품질 정합성을 높였습니다. 아울러 서비스 런칭 후 현장에 즉시 투입해 사용할 수 있는 상세 운영 가이드를 제작하는 등 프로젝트의 시작부터 운영 안착 단계까지 전 단계에서 완성도를 높이기 위해 전방위적인 노력을 기울였습니다.
이와 같은 운영 체계를 구축해 프로젝트의 효율을 높였음에도 불구하고 화상 회의 중심의 소통만으로는 실제 사용자가 마주할 세밀한 경험까지 완벽히 검증하기에는 한계가 있다고 판단했습니다. 이에 현장의 실무 프로세스를 최종 점검하고 최적의 개선안을 도출하기 위해 모든 이해관계자가 참여하는 FGT(focus group test)를 기획했습니다.
직접 사용자 입장에서 경험하며 서비스의 완성도를 높이기 위한 FGT
일본 현지에서 진행된 InquiryChat FGT 진행 모습
FGT는 다음과 같은 프로세스로 진행했습니다.
| Intro | 10분 |
|
| Review & Test | 30분 |
|
| Q&A | 10분 |
|
| Break Time | 10분 |
|
| Research | 20분 |
|
| Closing | 10분 |
|
FGT 중 ‘주요 상황별 수행 과제 및 실습’을 어떻게 진행했는지 조금 더 자세히 소개하겠습니다.
주요 상황별 수행 과제 목록
주요 상황별 수행 과제 및 실습은 모든 이해관계자가 한데 모여 사용자와 CS 상담원으로 역할을 나눠 미리 준비한 시나리오를 함께 수행하도록 준비했습니다. 고객이 문의를 시작하는 것부터 문제를 해결하기까지의 전체 흐름을 실제로 체험해 보는 방식이었습니다.
FGT의 가장 큰 소득은 즉각적인 피드백과 개선이 이뤄졌다는 것입니다. 특히 데마에칸 앱 개발 담당자들은 백엔드 연동 작업에 집중하다 보니 실제로 앱에서 사용자가 어떤 경험을 하는지 직접 체험할 기회가 적었는데요. FGT를 통해 처음으로 전체 여정을 경험하면서 개선이 필요한 부분을 발견하고 QA 전에 바로 수정할 수 있었습니다.
FGT 후 시행한 FGI 결과
모든 시나리오 테스트가 끝난 후에는 참여자들의 의견을 듣기 위해 FGI(focus group interview)를 시행했습니다. 다음은 FGI 결과를 요약한 것입니다.
|
|
|
FGT 후 각 이해관계자의 입장을 조율해 원팀 만들기
FGT 세션이 끝난 후 FGI 설문 내용을 바탕으로 각 부서가 이해한 기능이 실제 구현과 일치하는지, 기획 의도가 현장의 사용자 경험과 어긋난 지점은 없는지 면밀히 검토했습니다. 이 과정에서 개발, 기획, 운영 팀이 서로 다르게 이해하고 있던 기능의 우선순위가 명확히 드러났습니다.
대표적인 사례가 기존 CS 솔루션에서 상담원이 가장 애용하던 '입력 중 메시지 미리보기' 기능이었습니다. 상담원 입장에서는 고객의 답변을 미리 예측해 응대 속도(average handling time, AHT)를 줄이는 강력한 도구였지만 플랫폼 기획자의 관점에서 이는 반드시 개선해야 할 보안 취약점이었습니다. 사용자가 아직 전송하지 않은 데이터, 즉 '삭제하거나 수정한 고민의 흔적'까지 기업이 실시간으로 열람하는 것은 정보 주권과 투명성 측면에서 큰 잠재 위험이었기 때문입니다.
FGT 현장에서도 "기존처럼 미리 볼 수 없어 답답하다"는 실무진의 피드백이 있었습니다. 이에 저는 이 기능을 단순히 삭제하는 것으로 처리하지 않고 ‘입력 중 표시기’라는 대안을 제시했습니다. 상담원이 사용자의 상태를 인지하며 응대 리듬을 유지하되 실제 데이터의 주권은 사용자에게 두는 방향으로 설득하며 합의점을 찾았습니다.
이와 같이 현장과 치열하게 조율하는 과정을 거친 덕분에 편리한 기능과 보안 원칙 사이에서 최적의 균형점을 찾아 릴리스를 준비할 수 있었습니다. 기술 내재화란 단순히 기능을 복제하는 것이 아니라 우리만의 원칙으로 서비스의 기준을 바로 세우는 과정임을 확인한 순간이었습니다.
FGT 이후에도 릴리스 전까지 베타 환경을 상시 오픈하고 운영 팀이 자유롭게 테스트할 수 있도록 계정을 지원했습니다. 사양서를 읽는 것과 실제 도구를 직접 써보며 손에 익히는 것은 완전히 다른 경험이기 때문입니다. 운영 팀은 실제 상담 환경에서 시스템을 사용해 보며 궁금한 점을 즉시 질문하고 이를 바탕으로 현장에 즉시 투입 가능한 고품질의 운영 가이드를 제작할 수 있었습니다.
데마에칸 내부에서 이처럼 유관 부서가 한자리에 모여 실전 같은 베타 테스트를 진행한 것은 이번이 처음이었습니다. 릴리스 후 진행된 개발 부서의 회고에서 FGT에 대한 평가는 압도적으로 긍정적이었습니다. 개발 및 QA 팀은 그동안에는 QA 단계에서 발견할 수 있었던 이슈를 미리 발견해 선제적으로 방어하면서 부서 간 오해를 방지했다고 평가했으며, 운영 팀 역시 직접 사용해 보며 신규 시스템에 대한 불안을 해소했고 실무 맥락이 반영된 상담 이력 관리 체계를 구축할 수 있었다는 피드백을 주었습니다.
무엇보다 중요한 성과는 서로 다른 조직과 지역에 있던 구성원들이 하나의 목표를 향해 치열하게 협력하는 경험을 공유했다는 점입니다. 이번 FGT는 단순한 기능 테스트를 넘어 파편화되어 있던 각 부서의 시각을 하나로 정렬하고 공동의 목표 의식을 공고히 하는 결속의 장이 되었습니다.
드디어 릴리스! 사용자, 상담원, 관리자, 모두를 위한 세 가지 변화
이러한 일련의 과정을 거쳐 2025년 12월 9일, 드디어 데마에칸 앱에 InquiryChat을 릴리스했습니다. 릴리스 후 사용자, 상담원, 관리자의 경험에 어떤 변화가 있었는지 소개하겠습니다.
첫 번째, 고객과 상담원를 연결하는 경험 개선
다음은 기존 채팅 솔루션에서 고객과 상담원이 연결되는 예시 흐름입니다.
- 사용자가 배달 주문한 후 문의가 생겨 FAQ 페이지에 진입해 "상품의 일부 또는 전부가 잘못되었습니다" 선택
- "상품이 도착하지 않았습니다" 선택
- 해당 주문 건 중 문의할 메뉴 선택
- 채팅 안내 사항 및 유의 사항 확인 및 동의(기존 솔루션에서는 사용자가 입력창에 입력했지만 아직 전송하지 않은 채팅 내용을 상담원이 볼 수 있었기에 이 부분을 안내하고 동의 받음)
- 상담원 매칭 대기
- 상담원 매칭 대기 인원에 대한 안내 화면
- 상담원 매칭 후 채팅 진행 화면
MessagingHub InquriyChat으로 전환한 뒤의 흐름은 다음과 같습니다.
- 사용자가 배달 주문한 후 문의가 생겨 FAQ 페이지에 진입해 "상품의 일부 또는 전부가 잘못되었습니다" 선택
- "상품이 도착하지 않았습니다" 선택
- 채팅 안내 사항 확인(InquriyChat에서는 사용자가 전송하지 않은 채팅은 상담원이 볼 수 없기에 별도 동의 절차 삭제)
- 채팅방 화면에 바로 진입해 해당 화면에서 상담원 매칭 안내 등 진행, 이때 사용자는 미리 문의할 내용 작성 가능
가장 먼저 기존 시스템에서 문제로 지적됐던 세션이 끊기는 이슈를 근본적으로 해소했습니다. 이제 사용자가 화면을 벗어났다가 다시 돌아와도 이전 대화가 그대로 유지되어 처음부터 다시 문의할 필요가 없어졌습니다. 앱 푸시 기능도 추가해 상담원이 답변을 하면 사용자가 즉시 알림을 받을 수 있게 되었고, 채팅 화면에서 주문 번호, 배달 예정 시간 등 상담에 필요한 핵심 정보를 바로 확인할 수 있게 됐습니다. 공지 사항 기능도 추가해 중요한 안내 사항을 전달할 수 있게 됐고, 상담원이 메시지를 읽었는지 혹은 지금 답변을 작성 중인지 실시간으로 확인할 수 있어 기다리는 동안의 불안감도 줄일 수 있었습니다.
약 한 달간 데이터를 분석한 결과 세션 유지 개선으로 채팅을 재활성화하는 비율이 약 20% 감소했습니다. 이는 고객이 더 이상 같은 문의를 반복하지 않아도 된다는 것을 의미하는 고객 리텐션의 질적 향상이었습니다.
두 번째, 반복 작업을 자동화해 상담원 업무 효율화
상담원 입장에서는 업무 효율을 크게 높일 수 있게 개선됐습니다. 기존에는 상담원과 고객 간 매칭을 상담원이 수동으로 진행해야 했지만 자동 매칭 시스템이 도입되면서 이제 상담원은 매칭에 신경 쓰지 않고 응대에만 집중할 수 있게 됐습니다. 또한 일정 대기 시간 이후에는 자동으로 매칭이 종료되고 고객에게 안내 메시지가 전달돼 사용자가 무한정 기다리는 상황을 방지할 수 있게 됐습니다.
UI/UX 측면에서도 전체 화면에서 진행 중인 채팅과 완료된 채팅을 탭으로 구분해 전체 채팅 사이클을 한눈에 관리할 수 있게 되었습니다. 우측 정보 탭에서는 고객의 주문 이력과 이전 채팅 기록, 배송 현황 등 상담에 필요한 모든 정보를 한 화면에서 확인할 수 있어 다른 시스템을 오가며 확인하던 번거로움이 사라졌습니다. 이미지 전송 기능도 추가돼 필요 시 고객에게 이미지를 발송해 안내할 수 있게 되었습니다.
특히 후쿠오카 현장 모니터링 과정에서 우선순위가 높다고 판단했던 CS 솔루션 내 데이터 연계 기능을 상담원이 고객과 매칭되는 순간 자동으로 상담 이력을 생성하도록 구현해 상담 종료 후 수기로 이력을 작성하던 시간을 크게 줄였습니다.
세 번째, 실시간 대시보드 자체 관리로 신속한 의사결정
관리자를 위한 기능도 새롭게 개발해 제공했습니다. 기존에는 시스템 메시지를 변경할 때 개발 팀에 요청해야 했기 때문에 반영까지 시간이 걸렸지만 이제 InquiryChat에서 제공하는 관리자 기능을 이용해 이벤트 및 시스템 메시지를 직접 관리할 수 있습니다. 그 덕분에 긴급 상황에도 즉각 대응할 수 있게 되었습니다. 사용자에게 안내할 수 있는 공지 사항 기능도 추가해 전체 채팅 상담에서 공지해야 하는 내용도 즉시 대응할 수 있습니다.
InquriyChat 관리자 기능
또한 실시간 채팅 대시보드 화면에서는 현재 진행 중인 모든 채팅의 내용과 대기 고객 수, 응대 현황을 한눈에 모니터링할 수 있어 상담 품질 관리가 훨씬 수월해졌습니다.
에필로그: 사람과 조직을 잇는 PM의 성장
InquiryChat으로 전환하는 프로젝트는 기술 내재화라는 목표를 넘어 국경을 넘는 협업과 프로세스 혁신에 대해 많은 것을 배운 여정이었습니다. 가장 큰 교훈은 ‘직접 보고, 함께 경험하는 것’의 힘이었습니다. 후쿠오카 현장에 방문해 문서와 화상 회의만으로는 파악하기 어려웠던 실무 관점의 인사이트를 얻을 수 있었고, FGT/FGI는 모든 이해관계자가 같은 경험을 공유하며 상호 이해를 높이는 계기가 되었습니다.
MessagingHub는 서버 엔지니어링 플랫폼에서 시작해 점점 더 사용자에 가까워지고 있으며, 이 과정에서 기술뿐 아니라 사람과 조직을 이해하고 연결하는 것이 얼마나 중요한지도 배울 수 있었습니다. MessagingHub InquiryChat은 앞으로 더 많은 서비스로 확장해 나갈 예정입니다. 이번 프로젝트에서 얻은 경험과 FGT 프로세스가 앞으로의 여정에서도 큰 자산이 될 것이라고 확신합니다.
English (US) · 