"팀장님, 그 연구소가 어디입니까?"
12년 차 마케팅 전문가, 박 팀장의 이야기다. 그는 누구보다 꼼꼼하고 트렌드에 민감한 베테랑이다. 그런 그가 최근 팀장 회의에서 얼굴이 새하얗게 질리는 경험을 했다.
사건은 Z세대 소비 트렌드 보고서 작성 중에 일어났다. 시간이 촉박했던 박 팀장은 AI에게 최신 통계와 사례 요약을 맡겼다. 결과물은 완벽해 보였다. 문장은 매끄러웠고, 인용된 통계 수치는 구체적이었다. 의심 없이 회의실에 들어선 박 팀장에게 임원 한 분이 물었다.
"20대 소비 성향이 30% 증가했다는 그 미래소비연구소, 거기가 대체 어디야? 처음 듣는데?"
확인 결과, 그런 연구소는 세상에 존재하지 않았다. AI가 만들어낸 가짜였다. 식은땀을 흘리며 회의실을 나온 박 팀장은 자문했다.
"내가 프롬프트를 너무 짧게 써서 그런 건가? 아니면 AI는 원래 믿을 수 없는 거짓말쟁이인 건가?"
T (번역): 거짓말이 아니라 배치의 오류다
하지만 이것은 AI가 거짓말을 한 것도, 박 팀장이 프롬프트를 못 쓴 것도 아니다. 이 문제의 본질은 도구를 업무의 잘못된 위치에 놓은 배치의 오류다.
박 팀장은 AI를 팩트가 가득 쌓여 있는 창고라고 생각하고 업무의 맨 앞단에 배치했다. 하지만 생성형 AI의 본질은 창고지기가 아니라, 그럴듯한 이야기를 지어내는 작가에 가깝다.
우리는 지금 상상력이 풍부한 작가를 데려다가 가장 엄격해야 할 팩트 검증의 자리에 앉혀둔 셈이다. 작가에게 팩트를 가져오라고 강요하니, 그는 자신의 재능을 발휘해 세상에서 가장 그럴듯한 연구소 이름을 창작해 낸 것이다.
이것은 도구의 잘못이 아니라 상상력이 뛰어난 도구를 검증의 영역에 배치한 설계의 실수다.
사실 이런 일은 더 좋은 프롬프트를 쓴다고 해결될 문제가 아니다. 아무리 정교하게 지시를 내려도 생성형 AI는 본질적으로 다음에 올 가장 확률 높은 단어를 예측하는 구조로 작동한다. 확률로 답하는 기계에게 확신을 요구하는 순간, AI는 사실 여부와 상관없이 가장 그럴듯한 단어를 내놓게 된다. 이것이 우리가 말하는 환각 현상의 실체다.
A (분석): 베테랑의 감각은 왜 전달되지 않았나
그렇다면 왜 경험 많은 박 팀장이 이런 실수를 했을까? 이 사고의 내부를 들여다보면 두 가지 연결 고리가 끊겨 있는 것이 보인다.
첫째, AI에게 잘못된 역할을 기대했다.
박 팀장은 오랜 경험을 통해 데이터 출처를 본능적으로 검증한다. 하지만 이번에는 그 검증 역할까지 AI가 해줄 거라고 기대했다.
요약해 줘라는 지시 뒤에는 당연히 신뢰할 수 있는 출처만 골라서라는 무언의 전제가 깔려 있었다. 마치 베테랑 리서처에게 일을 맡기듯 AI도 알아서 출처를 가려내고 검증까지 해줄 거라는 막연한 믿음이 있었던 것이다.
문제는 생성형 AI는 검증자가 아니라 생성자라는 것이다. 아무리 구체적인 프롬프트를 써도 AI는 이 정보가 사실인가를 판단할 수 없다.
둘째, 확률 기계와 사실 요구의 충돌이다.
AI는 마치 빈칸 채우기 퀴즈를 푸는 사람과 같다. 미래소비연구소는 20대 소비가 ___% 증가했다고 발표했다는 문장을 보면, 가장 그럴듯한 숫자를 집어넣는다. 그 숫자가 진짜 존재하는지는 관심 밖이다.
박 팀장은 100% 확정된 사실이 필요한 업무에 이 확률 기계를 썼다. 확률로 답하는 기계에게 확신을 요구하는 순간, 환각은 불가피해진다.
D (설계): AI를 지도로 쓰고, 검증은 문으로 잠가라
이제 무너진 신뢰를 다시 세울 차례다. 이 문제를 해결하려면 프롬프트를 고치는 것이 아니라 일하는 순서와 구조를 다시 짜는 재설계가 필요하다.
첫 번째 설계: 결과물을 사실이 아닌 키워드로 바라보기
가장 먼저 바꿔야 할 것은 AI의 결과물을 대하는 태도다. AI가 내놓은 OOO 연구소 통계에 따르면...이라는 문장을 팩트로 받아들이면 안 된다. 대신 그 문장 속에 있는 명사들, 즉 연구소 이름이나 트렌드 용어만 골라내야 한다.
쉽게 말해 AI를 정답지라고 생각하지 말고 보물지도라고 생각하는 것이다. 지도는 보물이 어디 있는지 알려줄 뿐, 지도 자체가 보물은 아니다. AI가 알려준 키워드를 들고, 실제 팩트는 구글이나 신뢰할 수 있는 데이터베이스에서 직접 찾아야 한다.
AI의 위상을 정답 생성기에서 검색 키워드 추출기로 낮추는 것, 이것이 신뢰를 지키는 첫 번째 방어선이다.
두 번째 설계: 사후 검증 게이트의 강제 배치
두 번째는 프로세스의 위치 변경이다. 여기서 중요한 판단이 필요하다. 만약 박 팀장이 이미 신뢰할 수 있는 데이터를 가지고 있었다면, 그걸 AI에게 먼저 주고 요약만 시키는 방식을 썼을 것이다. 하지만 이번 케이스는 박 팀장에게 데이터가 없는, 맨땅에 헤딩하는 상황이었다.
이럴 때 선택할 수 있는 유일한 대안은 사후 배치다. AI가 생성한 결과물을 바로 사용하지 않고, 반드시 검증 단계를 거치게 만드는 것이다.
박 팀장은 AI가 준 키워드를 받으면, 반드시 원문 출처를 직접 확인하는 체크리스트를 만들었다. 연구소나 기관이 실제로 존재하는지, 인용된 통계가 그들의 공식 보고서에 정말 있는지, 다른 신뢰할 수 있는 매체도 같은 내용을 보도하고 있는지를 하나씩 검증한다.
이 단계를 건너뛰면 보고서가 팀장 결재로 넘어가지 않도록 프로세스에 박아놓았다.
생성 단계와 검증 단계를 분리하는 것. 그리고 최종 결과물이 나가기 직전에 반드시 이 검증의 문을 통과하게 만드는 것. 이 역방향의 확인 절차가 프로세스에 박혀 있어야만, AI가 아무리 그럴듯한 거짓말을 해도 사고를 막을 수 있다.
진짜 해결책은 프롬프트가 아니라 설계다
박 팀장의 사고는 더 좋은 프롬프트를 쓴다고 해결될 문제가 아니었다. 그것은 검증의 문을 어디에 달 것인가 하는 구조의 문제였다.
우리는 자꾸 프롬프트 한 줄에 목숨을 건다. 어떻게 말하면 AI가 내 의도를 완벽히 알아들을까를 고민한다. 하지만 진짜 전문가는 말재주에 기대지 않는다. 도구를 어디에 두어야 가장 안전하고 효율적인지, 그 판을 짠다.
다음 글에서는 두 번째 페인포인트인 효율의 역전에 대해 이야기하려 한다. AI를 썼는데 왜 수정하느라 야근은 더 늘어나는지 그 고질적인 비효율의 고리를 끊어내는 설계를 보여주겠다.
AI 시대에도 사람의 손길이 필요한 전문 번역을 찾고 계신가요? 29년간의 미국 생활과 기술 분야에 대한 깊은 이해를 바탕으로 한 저의 번역 서비스가 궁금하시다면, 제 크몽 프로필에서 자세한 정보와 포트폴리오를 확인하시거나 브런치 '제안하기'를 통해 직접 문의해 주셔도 좋습니다.