AI를 쓰는 기업이라면 언젠가 같은 순간을 만납니다. 시스템이 확신에 찬 어조로 답하는데, 그 답이 틀린 순간입니다.
이것은 시스템이 고장 났다는 뜻이 아닙니다. 언어 모델은 확률 위에서 움직이며, 가진 정보가 부족할 때 침묵하는 대신 가장 그럴듯한 문장을 만들 수 있습니다. 진짜 문제는 답이 틀릴 수 있다는 점이 아니라, 틀린 답이 맞는 답과 같은 어조로 온다는 점입니다.
이 글에서는 오답이 왜 생기는지, 어떤 상황에서 실제로 중요한지, 구축 과정에서 통제 장치를 어디에 두어야 하는지를 다룹니다.
🔍 기억해 두세요: AI를 업무에 들이는 일은 오류를 없는 셈 치는 일이 아니라, 오류가 어디에 떨어질지를 미리 정하는 일입니다. 답이 고객에게 갈지, 직원 화면에 뜰지, 승인 칸으로 갈지는 구축 단계에서 결정됩니다.
AI는 왜 틀린 답을 내놓을까
원인이 하나인 경우는 드뭅니다. 구축 현장에서 가장 자주 보이는 네 가지는 다음과 같습니다.
정보가 없거나 오래되었다
모델은 주어진 자료에서 읽습니다. 가격표가 갱신되지 않았거나, 단종된 품목이 아직 카탈로그에 남아 있거나, 규정 변경이 누군가의 머릿속에만 있다면 답은 그 낡은 정보 위에 세워집니다. 여기서 잘못된 쪽은 모델이 아니라 자료입니다.
질문이 모호하다
"이 주문은 어떻게 처리해야 하나요?" 같은 질문은 맥락 없이 오면 여러 개의 맞는 답을 허용합니다. 모델은 그중 하나를 고르고 그 선택을 설명합니다. 사람 동료라면 되물었겠지만, 시스템은 가정 위에서 진행할 수 있습니다.
빈칸 채우기
자료에 답이 없으면 모델은 비슷한 글에서 익힌 형태를 따라 답을 만들 수 있습니다. 이 현상은 흔히 환각이라고 불립니다. 나온 문장은 언어로는 흠이 없고 내용으로는 지어낸 것입니다. 이것이 스스로를 드러내지 않는 오류입니다.
자료는 맞고 맥락이 어긋난다
정보 자체는 맞지만 다른 상황에 속합니다. 특정 고객군에만 적용되는 조건이 시스템에 구분이 없어서 모두에게 안내됩니다. 이런 오류는 하나씩 보면 맞아 보이기 때문에 늦게 발견될 수 있습니다.
모든 오류의 무게가 같지는 않다
모든 오류를 같은 무게로 다루면 구축이 무거워지고, 그 무게는 누구도 감당하기 어렵습니다. 구분은 오류가 무엇에 닿는지를 따릅니다.
- 안에 머무는 오류: 직원이 틀린 답을 보고 고치면 업무는 계속됩니다. 비용이 낮습니다.
- 고객에게 가는 오류: 틀린 정보가 밖으로 나갑니다. 이제 기술 문제가 아니라 신뢰 문제입니다.
- 돈이나 법이 걸린 오류: 가격, 할인, 계약 조건, 개인정보. 이 묶음에서는 답이 곧바로 나가지 않는 편이 안전합니다.
이 구분 없이 세운 시스템은 대개 양 끝 중 하나에 놓입니다. 모든 답이 승인을 기다려 시스템이 느려지거나, 승인 관문을 두지 않아 첫 번째 큰 오류가 고객 앞에서 벌어집니다.
사람 승인은 어디에 두는가
승인은 시스템의 모든 단계가 아니라 오류가 비싸질 수 있는 자리에 둡니다. 실무에서는 세 가지 배치가 쓸모 있을 수 있습니다.
승인 관문
정해 둔 종류의 답은 발송 전에 담당자 화면에 뜹니다. 담당자는 승인하거나 고치거나 반려합니다. 관문은 선택한 흐름에서만 작동하고 나머지는 기다림 없이 진행됩니다.
확신이 없을 때 멈추기
자료에서 대응을 찾지 못한 질문은 답하지 않고 넘기도록 시스템을 설정할 수 있습니다. "담당자에게 전달드리겠습니다"라는 문장이 지어낸 답보다 낫습니다. 이 동작은 구축 단계에서 적어 두는 것이며 저절로 생기지 않습니다.
권한의 경계
시스템이 혼자 할 수 있는 일은 문서로 정해 두어야 합니다. 안내를 하고 접수를 열 수 있지만, 가격을 바꾸거나 반품을 승인할 수는 없습니다. 경계를 적지 않으면 경계는 없는 셈입니다.
답을 자사 자료에 묶기
오답에 맞서는 가장 곧은 길은 모델이 자유로운 지식이 아니라 회사 문서에서 답을 만들게 하는 것입니다. 시스템은 질문을 받아 해당 문서를 찾고 그 문서에 답의 근거를 둡니다.
여기서 두 가지 부수 효과가 따라올 수 있습니다. 첫째, 답 옆에 출처를 붙일 수 있습니다. 어떤 문서에 기댔는지 보이므로 확인이 쉬워집니다. 둘째, 자료가 회사에 남습니다. 데이터가 어디에 있고 어디로 가는지는 별개의 주제이며 데이터는 어디로 가는가 글에서 다뤘습니다.
자료에 묶는 일은 자료 자체를 책임으로 만듭니다. 문서가 낡으면 답도 낡습니다. 그래서 어떤 문서를 최신으로 볼지, 누가 갱신할지를 먼저 정합니다.
틀린 답이 나왔을 때 무엇을 하나
하나씩 고치는 것으로는 부족하고, 같은 오류가 되돌아오지 않도록 원인까지 내려가야 합니다. 순서는 이렇게 잡을 수 있습니다.
- 사례를 기록과 함께 보관합니다. 무엇을 물었고, 어떤 자료에 기댔고, 누가 보았는지.
- 원인을 갈라 봅니다. 낡은 자료인지, 모호한 질문인지, 빈칸을 채운 것인지.
- 자료가 낡았다면 문서를 갱신하고 그 문서의 주인을 정합니다.
- 질문이 모호했다면 시스템이 되묻도록 설정합니다.
- 빈칸이 채워지고 있다면 그 주제를 승인 관문이나 전달 경로로 옮깁니다.
이 흐름이 문서로 없으면 오류는 하나씩만 논의되고 같은 오류가 여러 번 돌아옵니다. 프로젝트가 어디서 막히는지는 자동화 프로젝트가 실패하는 이유 글에서 따로 다뤘습니다.
기록이 왜 중요한가
시스템이 제가 한 말을 기억하지 못하면 오류에서 배울 것도 없습니다. 나중에 돌아봤을 때 기록은 다음 질문에 답할 수 있어야 합니다. 질문이 언제 들어왔는지, 무엇을 답했는지, 어떤 문서에 기댔는지, 승인을 거쳤는지, 누가 승인했는지.
이 기록은 동시에 근거 자료이기도 합니다. 고객이 "그쪽 시스템은 다르게 말했다"라고 할 때 대화는 기억이 아니라 기록 위에서 이루어집니다.
고객에게는 무엇을 말하나
상대가 시스템과 이야기하고 있다는 사실을 아는 것은 신뢰를 해치지 않습니다. 나중에 알게 되는 것이 해칩니다. 분명한 안내 문장과 사람에게 넘어가는 길은 대화 앞머리에 둡니다.
오류가 밖으로 나갔다면 가장 나은 길은 지체 없이 고치고 무엇이 잘못됐는지 담백하게 말하는 것입니다. 고객 쪽 흐름을 어떻게 세우는지는 고객 서비스 자동화 글에 적어 두었습니다.
구축 전에 물어야 할 것들
AI 도입을 논의할 때 다음 질문을 처음에 던지면 이후 논쟁의 상당 부분이 필요 없어질 수 있습니다.
- 시스템은 어떤 자료에서 답을 만들 것인가?
- 그 자료는 누가 갱신하고 얼마나 자주 점검하는가?
- 사람을 거치지 않고 나갈 수 있는 답은 어떤 것인가?
- 시스템은 확신이 없을 때 무엇을 하는가?
- 틀린 답이 발견되면 누구에게 알리는가?
- 대화 기록은 어디에 두고 누가 볼 수 있는가?
답은 기업마다 다릅니다. 업무 절차를 직접 그려 보고 싶다면 교육 시리즈에서 이 주제들을 단계별로 다루고 있습니다.
우리는 이렇게 일합니다
구축에서 먼저 답을 어떤 자료로 만들지를 정합니다. 그다음 어떤 답이 승인을 거칠지, 시스템이 확신이 없을 때 무엇을 할지를 함께 적습니다.
오류 가능성을 없는 셈 치는 구축은 권하지 않습니다. 대신 오류가 어디에 떨어질지 정하고, 기록을 남기고, 바로잡는 경로를 구축 안에 넣습니다.
자주 묻는 질문
AI가 틀리게 답했다는 것을 어떻게 알아차리나요?
읽기만으로 알아차리기는 어렵습니다. 틀린 답도 맞는 답과 같은 문체로 쓰이기 때문입니다. 실무에서는 세 가지가 도움이 됩니다. 답이 기댄 출처를 함께 보여 주기, 민감한 주제에서 사람 승인 두기, 대화 기록을 일정한 간격으로 표본 추출해 읽기입니다. "제가 아는 것과 다릅니다" 같은 고객 반응도 별도 통로로 모아 두는 편이 좋습니다.
모든 답을 사람이 승인해야 하나요?
대개 그럴 필요는 없고, 모든 답을 승인에 걸면 시스템을 쓸 수 없게 만들 수 있습니다. 구분은 답의 종류를 따릅니다. 안내하는 답, 접수를 여는 답, 담당자로 넘기는 답은 대부분의 기업에서 곧바로 나갈 수 있습니다. 가격, 할인, 계약 조건, 반품, 개인정보가 걸린 답은 승인 관문으로 보낼 수 있습니다. 이 목록은 구축 단계에서 적고 시간이 지나며 다시 살핍니다.
시스템이 "모른다"고 말하도록 만들 수 있나요?
학습의 문제라기보다 설정의 문제입니다. 자료에서 대응을 찾지 못하면 답을 만들어 내는 대신 주제를 사람에게 넘기도록 시스템을 세울 수 있습니다. 그 넘김 문구를 어떻게 쓸지, 누구에게 갈지, 고객이 언제까지 회신을 기다리면 되는지도 같은 구축에서 정합니다. 이 동작은 기본값이 아니며 적어 두어야 합니다.
틀린 답으로 생긴 손해는 누가 책임지나요?
책임은 시스템 자체가 아니라 그것을 운영하는 쪽을 향하며, 그래서 구축의 경계를 계약서에 적어 두는 편이 좋습니다. 어떤 답이 사람 승인을 거치는지, 기록을 얼마나 보관하는지, 오류를 발견했을 때 어떻게 알리는지를 미리 정해 두면 논의가 뒤로 밀리지 않습니다. 규제 산업이라면 이 조항은 법률 자문과 함께 작성하는 것이 좋습니다.
자사 문서에 묶인 시스템도 틀린 답을 낼 수 있나요?
네, 다만 오류의 종류가 바뀝니다. 자료에 묶인 시스템에서는 지어낸 답이 드물어지고, 대신 엉뚱한 문서를 고르거나 맞는 문서를 어울리지 않는 맥락으로 옮기는 오류가 앞으로 나옵니다. 이런 오류는 답이 기댄 문서가 옆에 있기 때문에 보기가 더 쉽습니다. 그래서 자료를 최신으로 지키는 일은 구축의 상시 업무가 됩니다.
맺음말
AI가 틀린 답을 내놓는 것은 고장이 아니라 작동 방식의 결과입니다. 그래서 구축의 질문은 "오류가 생길 수 있는가"가 아니라 오류가 어디에 떨어지는가여야 합니다.
답을 회사 자료에 묶고, 위험한 답은 승인 관문으로 보내고, 확신이 없을 때 멈추도록 적어 두고, 대화를 기록에 남기는 것. 이 네 가지가 갖춰지면 오류가 사라지지는 않지만 보이고 고칠 수 있게 됩니다.