updated
AI 도입은 왜 현장에서 막힐까 — 멈춘 주문 실험과 계속된 광고
실패 사례가 모든 AI 도입의 결론은 아닙니다.
시연 화면에서는 모든 일이 순조롭습니다. 고객이 묻자 AI가 바로 답하고, 긴 문서는 몇 줄로 줄어들며, 광고 영상은 순식간에 모습을 갖춥니다. 그런데 실제 업무에 넣은 다음부터 다른 질문이 생깁니다. 이 답을 고객에게 보내도 될까요. 틀렸다면 누가 고칠까요. 빨라진 만큼 정말 일이 줄었을까요.
AI 도입이 막히는 지점은 늘 같은 곳이 아닙니다. 음성을 잘못 알아듣는 문제와, 틀린 회사 규정을 정확하게 요약하는 문제는 다릅니다. 보기 좋은 광고를 만들었지만 고객이 좋아하지 않는 문제도 있습니다. 성능, 업무 연결, 사람의 반응을 한꺼번에 ‘AI 실패’라고 부르면 무엇을 고칠지 알기 어렵습니다.
도입을 멈췄다는 말도 자세히 읽어야 합니다. 특정 업체와의 시험을 끝낸 것인지, 실제 서비스의 일부 기능을 껐는지, 회사 전체가 AI 사용을 포기한 것인지에 따라 의미가 달라집니다. 시험에서 가능성이 낮은 것을 골라내는 일은 오히려 필요한 결정일 수 있습니다.
중요한 것은 AI가 결과를 만들었느냐보다, 그 결과가 현장의 다음 단계로 안전하고 유용하게 넘어갔느냐입니다. 멈춘 주문 실험과 계속된 광고를 구분해 보고, 가상의 고객문의 업무를 따라 도입의 빈틈을 살펴보겠습니다.
맥도날드가 끝낸 것은 특정 주문 시험이었습니다
2024년 6월 17일 CFO Dive에 실린 직접 취재 보도에서 맥도날드는 IBM과 진행하던 자동 주문 시험을 종료한다고 확인했습니다. 2021년부터 이어진 시험으로, 운영 비용과 주문 서비스 속도의 개선 가능성을 살피던 프로젝트였습니다.
하지만 보도에 따르면 회사는 시험의 성공 여부나 성과를 판단한 지표를 구체적으로 공개하지 않았습니다. 앞으로도 드라이브스루 음성 주문의 가능성을 살피겠다는 입장도 밝혔습니다. 따라서 이 사건을 ‘AI 음성 주문이 불가능하다고 결론냈다’고 요약하는 것은 지나칩니다.
기존 글은 웃음거리가 된 주문 영상을 앞세워 그것이 중단의 확정 원인인 것처럼 연결했습니다. 공개된 일부 오류는 문제가 존재했다는 단서이지만 전체 오류율이나 내부 투자 판단을 대신하지 않습니다. 정확히 무엇 때문에 기대에 미치지 못했는지는 확인된 범위 안에서 남겨두어야 합니다.
구글 협업의 순서도 바로잡습니다. 맥도날드의 구글 클라우드 협력 발표는 2023년 12월 6일입니다. IBM 시험 종료 보도보다 앞섭니다. 매장 기술·클라우드·AI 활용을 포괄한 계획이므로 ‘IBM 주문 시험에 실패한 뒤 구글로 갈아탔다’고 설명할 수는 없습니다.
그렇다면 이 사례에서 어떤 질문을 얻을 수 있을까요. 아래는 맥도날드의 내부 원인을 재구성한 것이 아니라 음성 주문 업무를 이해하기 위한 가상 상황입니다. 손님이 “콜라 하나, 아니 두 개요”라고 말했을 때 기계는 단어를 듣는 것뿐 아니라 앞선 수량을 고치는 의도까지 처리해야 합니다.
음성을 정확하게 문자로 바꾸어도 주문이 끝난 것은 아닙니다. 판매 중인 메뉴와 연결하고, 수량과 옵션을 정리하고, 손님이 수정할 수 있게 보여주고, 최종 주문으로 넘겨야 합니다. 사람에게는 자연스러운 한 번의 대화가 시스템 안에서는 여러 단계가 됩니다.
만약 “다시 말씀해주세요”가 반복되면 손님은 기다리고 뒤의 줄도 길어질 수 있습니다. 이때 필요한 것은 더 자연스러운 목소리만이 아닙니다. 언제 직원이 넘겨받고, 지금까지의 주문을 어떻게 보며, 잘못 들어간 항목을 어떻게 지울지까지 이어져야 합니다.
반대로 AI가 어느 부분까지 했는지 직원에게 전달하지 않으면 손님은 처음부터 주문을 반복해야 합니다. 자동화가 처리한 양이 많아도 인계 과정이 불편하면 전체 경험은 나빠질 수 있습니다. 시연의 한 문장과 실제 주문 완료는 다른 평가 대상입니다.
코카콜라는 비판을 받은 뒤에도 AI 광고를 이어갔습니다
코카콜라의 2024년 연말 AI 광고는 다른 종류의 사례입니다. 광고 전문매체 Muse by Clios의 2024년 11월 보도는 기존 연말 광고를 AI로 재해석한 영상에 비판과 엇갈린 반응이 있었다고 전했습니다. 이는 고객 반응을 다룬 보도이지 매출 손실이나 전체 소비자의 평가를 측정한 결과는 아닙니다.
이후 코카콜라의 2025년 11월 3일 공식 발표는 연말 캠페인에 AI를 활용한 영상 두 편을 다시 포함했다고 설명합니다. 그러므로 코카콜라를 ‘AI 도입을 거둬들인 회사’로 묶은 기존 제목은 부정확했습니다. 비판을 받았다는 사실과 도입을 중단했다는 사실을 분리해 제목부터 고쳤습니다.
회사가 계속했다는 사실만으로 광고가 성공했다고 단정할 수도 없습니다. 캠페인을 이어간 결정과 실제 고객 반응, 브랜드 효과, 비용 대비 성과는 각각 확인할 사항입니다. 반대로 온라인 비판만으로 모든 소비자가 싫어했거나 사업적으로 실패했다고 결론낼 수도 없습니다.
이 사례에서 얻을 수 있는 질문은 주문 시스템과 조금 다릅니다. 광고가 기술적으로 완성됐는가와 사람들이 그 광고에서 무엇을 느꼈는가는 같은 문제가 아닙니다. 제작 과정에서 편리한 도구였다고 해도, 고객에게 전달하려던 감정과 어긋날 수 있습니다.
가상의 브랜드가 손으로 정성껏 만든다는 이미지를 내세운다고 해보겠습니다. 그 브랜드의 광고가 지나치게 인공적으로 보이면 소비자는 영상의 세부 오류보다 약속과 표현의 불일치를 느낄 수 있습니다. 이 가정은 코카콜라의 실제 소비자 반응을 분석한 결과가 아니라 평가 항목의 차이를 설명하는 예입니다.
여기서 ‘사람이 만들면 진정성이 있고 AI를 쓰면 없다’는 보편 규칙을 만들 필요는 없습니다. 사람이 만든 광고도 기대를 저버릴 수 있고, AI를 사용한 결과를 좋아하는 소비자도 있을 수 있습니다. 어떤 제작 방식이든 브랜드가 약속한 경험을 실제로 전달했는지 살펴야 합니다.
두 사례를 같은 실패 목록에 넣으면 간단해 보입니다. 그러나 하나는 특정 주문 시험의 종료이고 다른 하나는 비판 속에서도 이어진 제작 방식입니다. 차이를 남겨두어야 기술을 고칠 일인지, 운영을 바꿀 일인지, 고객에게 전달하는 메시지를 다시 볼 일인지 구분할 수 있습니다.
‘기업 42%가 AI를 접었다’는 문장에서는 무엇이 빠졌을까요
S&P Global Market Intelligence의 2025년 5월 설명은 북미·유럽의 중간·고위급 IT 및 사업 담당자 1,006명을 대상으로 한 조사입니다. 운영 단계에 이르기 전에 AI 과제의 대부분을 포기한다는 조직의 비중이 전년 17%에서 42%로 늘었다고 보고했습니다.
같은 설명은 조직별로 시험 단계 과제의 평균 46%가 본격 도입 전에 폐기된다고도 전합니다. 42%는 그런 응답을 한 조직의 비중이고, 46%는 조직들이 보고한 과제 포기 비율의 평균입니다. 분모가 다르므로 같은 실패율의 다른 표현이 아닙니다.
여기서 시험 단계는 작은 범위에서 가능성을 확인하는 단계입니다. 흔히 PoC, 즉 개념검증이라고 부릅니다. 이 단계에서 멈춘 과제가 많다는 결과를 회사가 운영 중인 모든 AI를 철수했다는 뜻으로 바꾸면 안 됩니다. 2025년 조사를 오늘의 한국 전체 기업 비율로 적용할 수도 없습니다.
숫자의 차이를 가상 회사 하나로 생각해보겠습니다. 열 가지 과제를 시험한 회사가 여섯 가지를 멈추고 네 가지를 계속했다면 시험의 대부분을 중단한 회사입니다. 하지만 AI를 완전히 포기한 회사는 아닙니다. 남은 네 가지가 어느 정도 가치를 냈는지는 이 숫자만으로 알 수 없습니다.
또한 시험을 멈춘 이유도 하나가 아닐 수 있습니다. 성능이 부족했을 수도, 비용이 예상보다 컸을 수도, 같은 문제를 더 간단한 방법으로 해결했을 수도 있습니다. 중단 사유를 구분하지 않으면 필요한 실험 정리와 피할 수 있었던 운영 실패가 같은 통계 안에서 섞입니다.
이 말은 높은 중단 비율을 대수롭지 않게 넘기자는 뜻은 아닙니다. 반복해서 비슷한 과제에 돈을 쓰고 같은 이유로 멈춘다면 기획과 평가 방식에 문제가 있을 수 있습니다. 다만 ‘전부 접었다’라는 표현보다 어떤 단계에서 무엇을 중단했는지가 개선에 더 쓸모 있는 정보입니다.
회사 입장에서도 중단을 무조건 숨겨야 할 실패로 만들면 시험의 목적이 흐려집니다. 좋지 않은 결과를 확인하고도 이미 들인 돈 때문에 계속 밀어붙일 수 있기 때문입니다. 시작 전에 중단을 포함한 결정을 허용해야 시험 결과가 실제 의사결정으로 이어집니다.
가상의 고객문의 한 건을 끝까지 따라가 보겠습니다
생활용품을 파는 가상의 회사에 문의가 왔다고 해보겠습니다. “주소를 바꾸고 싶은데 아직 가능할까요?” AI는 친절하게 “물론입니다. 새 주소를 알려주세요”라고 답할 수 있습니다. 문장만 보면 자연스럽지만 실제 업무에서는 빠진 정보가 많습니다.
먼저 어느 주문인지 확인해야 합니다. 주문한 본인인지, 상품이 이미 출고됐는지, 배송지 변경을 처리할 수 있는 시스템 상태인지도 중요합니다. 여기서는 특정 회사의 환불·배송 규정을 안내하는 것이 아니라 업무의 단계가 어떻게 다른지 설명하고 있습니다.
답변을 쓰는 AI가 출고 상태를 읽지 못한다면 주소 변경 가능 여부를 단정할 수 없습니다. 반대로 주문 정보를 읽을 수 있다고 해서 배송지를 직접 고칠 권한까지 주어야 하는 것은 아닙니다. 조회, 제안, 승인, 실행은 각각 다른 행동입니다.
이 차이를 생략하면 ‘AI가 된다’는 말이 너무 넓어집니다. 고객에게 가능한 절차를 안내하는 기능과 실제 주문 정보를 변경하는 기능은 실패했을 때의 영향도 다릅니다. 어느 단계까지 맡기는지 정하지 않은 채 도구를 연결하면 권한이 업무보다 앞서갈 수 있습니다.
“주소 바꿔주세요”는 답변 한 줄로 끝나지 않습니다
이 주문, 배송지 변경이 가능한가요?
허용된 정보만 조회
아직 주소를 바꾼 것은 아님
실제 처리 권한은 별도로 제한
대화의 “완료”만 믿지 않기
확인 가능한 처리 결과까지 연결합니다.
특정 판매처의 실제 시스템이 아닌 가상 업무 설계입니다. 실제 변경 가능 시점과 본인 확인 방법은 회사마다 다릅니다. 이 그림은 자동 변경을 권하는 것이 아니라 조회·제안·승인·실행·결과 확인의 경계를 보여줍니다.
AI가 “변경했습니다”라고 말한 것과 주문 시스템의 주소가 바뀐 것은 같지 않습니다. 작업 요청이 실패하거나 오래된 주문을 조회했을 수 있기 때문입니다. 완료 여부는 실제 처리 결과로 확인해야 하며, 불확실한 상태에서 같은 요청을 반복하면 중복 처리 문제가 생길 수도 있습니다.
이 장면에서 사람에게 넘기는 기능은 실패의 표시가 아니라 설계의 일부입니다. 자동 처리하기 어려운 경우를 미리 정하고, 담당자가 이어서 볼 정보와 고객에게 안내할 대기 상태를 준비하는 것입니다. ‘모르면 상담원에게’라는 문구만 붙이는 것과는 다릅니다.
담당자가 없는 시간도 고려해야 합니다. 밤에 예외가 생기면 다음 영업시간까지 무엇을 보류할지, 고객은 어떤 안내를 받는지 정해야 합니다. 사람 검토를 약속하면서 실제로 검토할 사람이 없는 구조라면 약속과 운영 사이에 또 하나의 틈이 생깁니다.
좋은 모델도 회사 안의 모순을 대신 해결해주지는 못합니다
고객문의 AI가 잘못 답했다고 해서 원인이 항상 모델에 있는 것은 아닙니다. 가상의 회사에서 최신 배송 안내에는 주소 변경이 제한된다고 쓰여 있는데, 오래된 직원 문서에는 언제든 가능하다고 적혀 있다고 해보겠습니다. AI는 서로 다른 자료를 보고 어느 쪽이 현재 규칙인지 판단해야 합니다.
이때 질문 문장을 더 정교하게 만드는 것만으로 원본의 모순이 없어지지는 않습니다. 적용 날짜와 담당 부서가 분명한 기준 문서가 필요합니다. 자료가 많다는 것보다 어떤 자료가 현재의 공식 기준인지 알 수 있는지가 중요합니다.
품절 정보와 재고 정보가 늦게 맞춰지는 상황도 생각할 수 있습니다. AI가 가져온 자료를 충실하게 읽었어도 자료 자체가 오래됐다면 고객에게 틀린 안내를 할 수 있습니다. 문장 생성의 정확성과 원본 정보의 최신성은 별도로 확인해야 합니다.
그렇다고 모든 자료가 완벽해질 때까지 아무것도 시작할 수 없다는 뜻은 아닙니다. 범위를 좁힐 수 있습니다. 최신 기준이 분명한 자주 묻는 질문만 다루거나, 답변 초안과 근거 문서를 담당자에게 함께 보여주는 방식으로 시험할 수 있습니다.
어떤 문제에는 AI가 필요 없을 수도 있습니다. 주문번호를 입력하면 현재 배송 상태를 보여주는 일은 기존 조회 기능을 개선하는 편이 더 단순할 수 있습니다. 자연스러운 대화가 필요한 부분과 정해진 규칙대로 처리해야 할 부분을 구분하면 불필요한 복잡함을 줄일 수 있습니다.
도입의 출발점을 ‘어디에 AI를 넣을까’로 잡으면 도구에 맞춰 일을 찾게 됩니다. ‘어느 단계에서 고객과 직원이 오래 기다리는가’로 잡으면 다른 선택지도 보입니다. 안내 문구를 고치거나 중복 입력을 없애는 일이 더 큰 효과를 낼 수도 있습니다.
초안이 빨라진 시간만 재면 성과를 잘못 볼 수 있습니다
가상의 상담원이 문의 한 건의 답변을 작성하는 데 4분, 내용을 확인하고 처리 결과를 기록하는 데 2분이 걸렸다고 해보겠습니다. 전체 작업은 6분입니다. AI가 초안을 30초 만에 만들면 작성 시간만 놓고는 크게 빨라 보입니다.
하지만 초안을 확인하느라 규정을 다시 찾고 틀린 내용을 고치는 데 7분이 걸렸다면 전체는 7분 30초입니다. 초안 생성은 빨라졌지만 완료까지 걸린 시간은 1분 30초 늘었습니다. 반대로 검토와 처리가 2분으로 유지된다면 전체 2분 30초가 되어 실제로 시간이 줄어듭니다.
30초 초안, 끝나는 시간은 같지 않습니다
청록색: 확인·수정·처리 기록
모든 막대는 같은 0~7분 30초 기준
실측이 아닌 가상 작업 시간이며 같은 시작·종료 지점을 가정했습니다. 막대는 초 단위로 240+120, 30+420, 30+120을 동일 척도에 표시했습니다. 대기·교육·사후 문의 시간은 제외했으므로 실제 평가에서는 추가로 확인해야 합니다. 빠르다는 사실만으로 품질까지 같다는 뜻은 아닙니다.
실제 시험에서는 처리하는 문의의 난이도도 맞춰야 합니다. AI에 쉬운 질문만 맡기고 사람이 복잡한 질문을 처리했다면 평균 시간을 그대로 비교하기 어렵습니다. 비슷한 유형끼리 보거나 어떤 문의를 제외했는지 남겨야 결과를 해석할 수 있습니다.
처음 익숙해지는 기간과 일상적으로 쓰는 기간을 구분하는 것도 도움이 됩니다. 새 도구를 배우느라 오래 걸린 첫날과 사용법을 익힌 뒤의 하루는 다를 수 있습니다. 반대로 첫 시연에서 잘됐던 몇 건만 고르면 반복되는 예외를 놓칠 수 있습니다.
문의가 정말 끝났는지도 중요합니다. 상담 화면에서 ‘완료’를 눌렀지만 고객이 같은 문제로 다시 연락했다면 처음 처리 시간만으로 성과를 판단하기 어렵습니다. 첫 답변까지 걸린 시간과 실제 해결까지 걸린 시간은 서로 다른 지표입니다.
고객 만족도도 처리 속도와 별도로 봐야 합니다. 빠르게 온 답변이 질문과 어긋났다면 만족스럽지 않을 수 있습니다. 반대로 조금 기다렸더라도 문제가 해결되고 다음 절차를 알게 됐다면 더 좋은 경험일 수 있습니다. 어떤 목표를 개선하는지 정하지 않으면 측정값끼리 충돌합니다.
또한 절약된 시간은 곧바로 인건비 절감액이 아닙니다. 같은 직원이 다른 일을 더 잘하게 됐을 수 있고, 밀린 문의를 처리했을 수도 있습니다. 그 변화는 가치가 있지만 실제 지출이 줄었는지와는 구분해서 기록하는 편이 정확합니다.
사람이 마지막에 본다는 말만으로 충분하지 않습니다
AI 도입의 해답으로 ‘사람이 검수하면 된다’는 말을 자주 합니다. 필요한 경우가 많지만 사람을 마지막 칸에 넣는 것만으로 검토가 제대로 이루어지지는 않습니다. 검토할 사람이 무엇을 보고 어떤 권한으로 결정하는지까지 설계해야 합니다.
가상의 상담원이 답변 100개를 몇 분 안에 승인해야 한다면 하나하나 근거를 확인하기 어렵습니다. 화면에 유창한 답변만 보이고 출처와 주문 상태가 보이지 않는다면 다시 자료를 찾는 부담이 생깁니다. 검토를 맡겼다는 사실과 검토가 가능한 조건은 다릅니다.
검토자에게 필요한 정보는 업무마다 다릅니다. 고객문의라면 현재 주문 상태와 적용 규정, AI가 확신하지 못한 부분을 함께 보여줄 수 있습니다. 광고라면 실제 상품과 다른 표현이 있는지, 약속한 메시지와 맞는지, 타깃 고객에게 어떻게 보이는지 확인할 수 있어야 합니다.
모든 문장을 같은 강도로 확인할 필요가 있는지도 따져볼 수 있습니다. 인사말의 어투와 금전적 약속의 오류는 영향이 다릅니다. 다만 무엇을 낮은 위험으로 분류할지는 실제 업무와 이용자에게 생길 피해를 고려해 정해야 합니다. 이 글의 예시가 회사별 승인 기준을 대신하지는 않습니다.
중요한 것은 승인하지 않을 권한입니다. 담당자가 문제가 있다고 느껴도 실적 압박 때문에 계속 승인해야 한다면 검토 단계는 형식이 됩니다. 처리량뿐 아니라 잘못된 답을 멈추거나 적절히 넘긴 행동도 운영 평가에 반영할 수 있어야 합니다.
신입이나 외주 담당자에게 검토를 맡기는 경우에는 판단 기준과 질문할 상대가 필요합니다. 경험이 부족한 사람에게 ‘AI가 틀렸는지만 봐달라’고 하면 어려운 판단이 조용히 떠넘겨질 수 있습니다. 검토자의 교육과 지원도 도입 비용에 들어갑니다.
반대로 사람이 한다는 이유만으로 오류가 없다고 가정해서도 안 됩니다. AI 전후를 비교하려면 기존 업무의 오류와 재작업도 같은 기준으로 봐야 합니다. 좋은 평가의 목적은 어느 편이 완벽한지 증명하는 것이 아니라 실제 업무에서 더 나은 구성을 찾는 것입니다.
평균 정확도 옆에는 ‘어떤 오류인가’가 있어야 합니다
가상의 시험에서 100건 중 95건이 맞았다고 해보겠습니다. 남은 다섯 건이 모두 어색한 말투인지, 고객의 주문을 잘못 바꾸는 오류인지에 따라 받아들일 수 있는 수준은 다릅니다. 95%라는 숫자만으로 서비스에 넣어도 되는지 판단할 수는 없습니다.
그래서 오류에는 종류가 필요합니다. 사실을 틀린 경우, 필요한 정보를 못 찾은 경우, 권한 없는 행동을 제안한 경우, 잘못된 대상에게 정보를 보여준 경우는 대응이 다릅니다. 종류를 나누면 모델을 바꿀 문제와 데이터·화면·권한을 바꿀 문제가 드러납니다.
자주 생기지 않는 오류도 놓치지 않아야 합니다. 평소에는 잘 작동하지만 주문이 두 개이거나 고객이 중간에 말을 바꾸면 엉뚱한 결과가 나온다면, 그런 상황을 별도로 시험할 이유가 있습니다. 좋은 조건의 예시만 반복해서는 실제 경계를 알 수 없습니다.
그렇다고 ‘최악의 한 번이 모든 것을 결정한다’는 문장으로 평균 성능을 버리는 것도 과합니다. 빈도와 영향은 함께 봐야 합니다. 자주 발생하는 작은 오류가 전체 업무를 크게 지연시킬 수도 있고, 드문 큰 오류는 별도의 강한 통제가 필요할 수 있습니다.
이용자가 일부러 지시를 바꾸거나 규칙을 우회하려는 경우도 생각할 수 있습니다. 외부에서 들어온 문장을 모두 회사의 지시처럼 취급해서는 안 됩니다. 다만 이 글에서는 공격을 재현하지 않습니다. 고객 입력과 내부 승인 규칙을 구분해야 한다는 운영상의 경계를 설명합니다.
미국 국립표준기술연구소 NIST의 AI 위험관리 프레임워크 핵심 항목도 영향과 발생 가능성을 고려한 위험 대응, 배포 뒤의 감시, 문제가 있는 시스템을 중지하거나 대체할 책임을 다룹니다. 회사별로 적용할 자발적 관리 틀이며, 특정 도구의 안전 인증이나 법률 준수 판정을 대신하지 않습니다.
중단 버튼은 있어야 하지만, 그다음 일도 준비돼야 합니다
고객문의 AI를 끌 수 있는 기능이 있다고 해보겠습니다. 이것만으로 장애 대응이 끝나지는 않습니다. 이미 대기 중인 문의를 누가 맡는지, 잘못 안내한 고객에게 어떻게 다시 연락하는지, 진행 중인 변경 요청이 어디까지 처리됐는지를 확인해야 합니다.
가상의 주소 변경 요청이 시스템 중간에서 멈췄다면 무조건 다시 실행하는 것보다 현재 상태 확인이 먼저입니다. 주소가 이미 바뀌었는지 모르는데 같은 작업을 반복하면 기록이 복잡해질 수 있습니다. 멈추는 기능과 되돌리거나 이어받는 절차는 함께 필요합니다.
담당자를 정할 때도 ‘IT팀’이라는 이름만 적기보다 역할을 나눌 수 있습니다. 기능을 끌 사람, 고객 안내를 판단할 사람, 데이터 상태를 확인할 사람이 누구인지 정하는 것입니다. 작은 팀에서는 한 사람이 여러 역할을 맡을 수 있지만 책임이 공백으로 남아서는 안 됩니다.
기록을 남기는 이유는 누군가를 탓하기 위해서만은 아닙니다. 어떤 입력과 자료, 어떤 버전의 규칙이 사용됐는지 알아야 같은 오류가 반복되는 것을 줄일 수 있습니다. 다만 기록에 개인정보와 비밀정보를 무조건 많이 저장하는 것은 또 다른 위험이 될 수 있어 접근과 보관 범위도 정해야 합니다.
시스템이 업데이트된 뒤에는 이전 검수가 그대로 유효한지도 살펴야 합니다. 모델만이 아니라 지시문, 연결 데이터, 승인 화면이 바뀌어도 결과가 달라질 수 있습니다. 처음 잘 작동한 날의 화면을 계속 보여주는 것과 현재 운영 상태를 확인하는 것은 다른 일입니다.
중단 조건을 성과가 나쁜 때에만 두지 않는 것도 중요합니다. 예상하지 못한 정보 노출이나 승인 없는 외부 행동이 확인되면, 처리 속도가 아무리 빨라도 영향을 확인해야 합니다. 반대로 사소한 표현 오류 하나 때문에 모든 기능을 영구 폐기할 필요가 있는지는 따로 판단할 수 있습니다.
작게 시험한다는 것은 대충 시험한다는 뜻이 아닙니다
작은 팀이라면 먼저 하나의 과업을 고를 수 있습니다. ‘고객센터를 AI로 바꾸자’보다 ‘담당자가 배송 상태 안내 초안을 만드는 일을 돕자’가 범위와 결과를 확인하기 쉽습니다. 외부 발송과 주문 변경을 제외하면 초안의 품질부터 살펴볼 여지도 생깁니다.
첫 단계에서는 실제 고객에게 아무 영향도 주지 않는 자료로 비교할 수 있습니다. 개인정보를 제거하고 사용 권한을 확인한 과거 자료나 직접 만든 가상 문의를 활용하는 방식입니다. 다만 가상 질문만으로 실제 현장의 성능이 입증되는 것은 아니므로 다음 단계의 한계를 남겨야 합니다.
그다음에는 기존 업무를 유지하면서 AI 결과를 따로 만들어 비교하는 방식을 생각할 수 있습니다. 흔히 그림자 실행이라고 부르는 접근입니다. AI의 답이 고객에게 바로 나가지 않도록 하면서 어떤 유형에서 도움이 되고 어디에서 틀리는지 봅니다.
담당자 일부에게 제한적으로 적용할 때도 예외를 기록하는 편이 좋습니다. AI를 쓰지 않고 직접 답한 문의가 있다면 왜 그랬는지 살펴보는 것입니다. 사용을 강제해 이용률만 높이면 현장에서 피하고 싶은 문제를 감추게 될 수 있습니다.
시험 기간을 무조건 30일로 정할 필요는 없습니다. 문의량과 위험, 업무 주기에 따라 필요한 시간이 다릅니다. 한 달에 한 번만 발생하는 중요한 예외가 있다면 짧은 시험에서는 나타나지 않을 수 있습니다. 달력의 기간보다 어떤 상황을 확인했는지가 중요합니다.
결정은 전면 확대와 폐기 두 가지뿐이 아닙니다. 특정 문의만 유지하거나, 초안 기능만 남기거나, 자동 발송을 끄고 근거 검색에 활용할 수 있습니다. 필요한 경우에는 기존 방식으로 돌아가고 자료 정비부터 다시 시작할 수도 있습니다.
이런 선택은 도입 속도를 무조건 늦추자는 주장이 아닙니다. 실패했을 때의 영향이 작고 결과를 확인하기 쉬운 범위에서 배우자는 제안입니다. 작은 시험의 목적은 홍보할 성공 화면 한 장이 아니라 다음에 무엇을 넓혀도 되는지 근거를 얻는 것입니다.
남은 일은 사라진 일이 아니라 다른 사람에게 옮겨진 일일 수 있습니다
자동화 뒤에 담당자의 화면에서는 일이 줄었는데 다른 팀의 일이 늘어나는 경우를 가정해볼 수 있습니다. AI가 답변을 많이 만들면서 검수팀의 대기열이 길어지거나, 고객의 재문의가 늘어 상담원이 뒷수습을 맡는 상황입니다. 한 단계의 속도를 전체 성과로 읽으면 이 부담이 보이지 않습니다.
고객에게 일이 옮겨갈 수도 있습니다. 대화형 안내는 빨라졌지만 고객이 여러 번 설명해야 하고, 원하는 답을 얻기 위해 표현을 바꿔야 한다면 편의가 누구에게 생겼는지 다시 봐야 합니다. 회사의 처리 건수와 고객의 노력은 별개의 지표입니다.
AI 운영을 위한 새 업무도 생깁니다. 기준 자료를 갱신하고, 잘못된 응답 유형을 분류하고, 권한을 점검하고, 공급업체 변경에 대응해야 할 수 있습니다. 도입 비용을 월 구독료만으로 계산하면 이런 일들이 빠집니다.
그 비용이 생긴다고 도입이 무의미한 것은 아닙니다. 새로 생긴 관리 업무보다 줄어든 부담과 개선된 품질이 더 클 수 있습니다. 중요한 것은 보이지 않던 일을 포함해 비교하는 것입니다. 실제로 하지 않은 측정을 절감률처럼 발표하지 않는 태도도 여기에 들어갑니다.
현장 의견은 그래서 중요합니다. 도구를 만든 팀이 보기에는 간단한 예외가 매일 수십 번 발생하는 일일 수 있습니다. 담당자가 우회 절차를 만들었다면 단순히 변화에 저항한다고 보기 전에 무엇이 불편해서 우회했는지 확인할 필요가 있습니다.
기존 글의 ‘사람을 대체한 도입은 되돌아왔고 돕는 도입은 남았다’는 결론도 이 때문에 덜어냈습니다. 일부 사건만 골라 보아서는 그런 보편적 성공 법칙을 만들 수 없습니다. 같은 보조 도구라도 현장 부담이 커질 수 있고, 제한된 자동 처리가 잘 작동하는 업무도 있을 수 있습니다.
좋은 도입은 실패가 없는 도입이 아니라, 배운 것이 남는 도입입니다
맥도날드의 주문 시험과 코카콜라의 광고를 다시 보면, 한쪽은 특정 시험을 끝냈고 다른 쪽은 논란 속에서도 제작 방식을 이어갔습니다. 이 차이를 지우고 ‘AI를 쓰다 망한 회사들’로 묶으면 이야기는 자극적이지만 실제 결정에는 별 도움이 되지 않습니다.
시험을 끝냈다면 어떤 가정이 맞지 않았고 무엇을 배웠는지 볼 수 있어야 합니다. 계속한다면 어떤 고객 반응과 비용, 성과를 근거로 확대하는지 확인해야 합니다. 중단과 지속 중 어느 쪽도 그 자체로 정답을 보증하지는 않습니다.
가상의 고객문의 업무에서도 마찬가지입니다. AI가 초안을 빠르게 만들었다면 그다음에 확인 시간과 처리 결과를 봅니다. 잘못된 약속이 나왔다면 모델, 원본 규정, 승인 과정 중 어디에서 문제가 생겼는지 나눕니다. 인계가 반복된다면 넘기는 기준뿐 아니라 사람이 이어받을 조건도 살펴야 합니다.
처음의 시연 화면으로 돌아오면 AI는 여전히 멋진 문장을 만들어냅니다. 다만 이제 그 화면 다음을 상상할 수 있습니다. 그 답을 읽는 고객, 내용을 확인하는 직원, 실제 정보를 바꾸는 시스템, 문제가 생겼을 때 중지할 담당자가 있습니다.
AI를 잘 들인다는 것은 그 연결을 없애는 일이 아니라, 어디까지 맡기고 어디서 확인하며 문제가 생겼을 때 누가 이어받는지 분명히 하는 일입니다. 도입 발표보다 덜 화려하지만, 시연이 일상의 업무가 되려면 그 부분이 함께 완성되어야 합니다.
참고 자료와 확인 범위
- CFO Dive / Restaurant Dive — McDonald’s ends automated drive-thru pilot, 2024-06-17. 회사가 직접 보낸 성명을 인용한 보도. 시험 종료, 향후 음성 주문 검토와 성과 지표 미공개를 구분. 바이럴 오류를 확정 중단 원인으로 사용하지 않음.
- McDonald’s — Google Cloud 협력 발표, 2023-12-06. IBM 시험 종료 이전의 매장·클라우드·AI 계획. 사후 갈아타기라는 기존 시간 순서 정정.
- Muse by Clios — 2024 Coca-Cola AI 광고 반응, 2024-11-18. 비판·엇갈린 반응에 관한 보도이며 전체 소비자 설문이나 매출 손실 자료는 아님.
- Coca-Cola — 2025 연말 캠페인 공식 발표, 2025-11-03. AI 영상 재사용으로 철회가 아닌 지속 확인. 회사의 창작 효율 주장 자체를 독립 성과 검증으로 쓰지 않음.
- S&P Global Market Intelligence — VotE AI & Machine Learning 2025 설명, 2025-05-30. 북미·유럽 담당자 1,006명, 운영 전 대부분 과제를 포기한 조직 비중 17%→42%와 조직별 포기 비율 평균 46% 구분. 전 세계·한국의 현재 철수율로 일반화하지 않음.
- NIST — AI RMF Core. MANAGE의 위험 우선순위·비AI 대안·중지 책임·배포 후 모니터링과 복구 항목을 참고. 본문의 고객문의 흐름과 시험 제안은 별도 가상 설계이며 인증 체크리스트가 아님.
2026-09-16 공식 발표·직접 취재 보도·조사 원문을 대조해 보완했습니다. 기존 URL·updated는 유지합니다. 코카콜라를 철회 사례로 묶던 제목, 구글 협업의 선후관계, 시험 중단 비율의 일반화를 교정했습니다. 고객문의·주문·시간·시험 과제 수는 가상 예시이며 실제 기업 실험이 아닙니다. 공개되지 않은 내부 실패 원인은 단정하지 않았습니다. 자료 조사·편집에 AI 보조를 사용했습니다.