AI Overviews는 모든 빌더에게 리스크(Liability)에 대한 교훈을 준다

Google의 AI Overviews(AI 개요) 문제에서 얻을 수 있는 불편한 교훈은 단순히 AI가 틀릴 수 있다는 점이 아닙니다. 빌더들은 이미 그 사실을 알고 있습니다. 진짜 교훈은 제품이 답변을 요약하고, 순위를 매기며, 자체적인 목소리로 답변을 제시하는 순간, 사용자들과 법원이 그 답변을 귀하의 것으로 간주할 수 있다는 점입니다.

이는 검색을 훨씬 넘어선 문제입니다. 만약 귀하가 법률 접수, 고객 지원, 의료 분류(Medical Triage), 내부 분석, 교회 운영, 교육 또는 개발자 워크플로우를 위한 AI 어시스턴트(AI Assistant)를 구축하고 있다면, 귀하는 단순히 모델의 출력값(Model Output)을 보여주는 것이 아닙니다. 귀하는 결정 표면(Decision Surface)을 출시하고 있는 것입니다. 제품이 권위 있게 보이는 순간, 모델이 잘못된 점들을 자신 있게 연결할 때를 대비한 증거, 검토 경로(Review Paths), 그리고 복구 방법이 제품에 갖춰져 있어야 합니다.

이번 주 보고된 독일 지역 법원의 판결에 따르면, Google의 AI Overviews가 허위 주장을 생성했을 때 이를 Google 자체의 진술로 취급할 수 있다고 밝혔습니다. 사실관계는 구체적이며, 항소나 다른 관할권에 따라 이 상황은 변할 수 있습니다. 하지만 제품 측면에서의 교훈은 이미 명확합니다. 출처 표기(Attribution Links)가 AI 답변을 자동으로 안전하게 만들어주지는 않습니다.

이것이 Google 검색보다 더 큰 문제인 이유

AI Overviews가 세계에서 가장 많이 사용되는 정보 제품 중 하나 위에 자리 잡고 있기 때문에 Google이 눈에 보이는 사례일 뿐입니다. 하지만 동일한 패턴은 매일 더 작은 제품들에서도 나타납니다:

고객 지원 봇(Support Bot)이 환불 정책을 요약하다가 예외 사항을 지어냄.
내부 데이터 에이전트(Internal Data Agent)가 잘못된 필터를 사용하여 매출 질문에 답변함.
건강 어시스턴트(Health Assistant)가 출처 자료를 혼합하여 임상적인 것처럼 들리는 조언을 제공함.
코딩 에이전트(Coding Agent)가 보안 문제를 설명하면서 실제로 검사하지 않은 파일을 인용함.

각 사례에서 위험한 부분은 단순히 환각(Hallucination)만이 아닙니다. 바로 제시 방식(Presentation)입니다. 세련된 UI(User Interface) 내에서 생성된 문단은 검색 결과 목록, 로그 또는 원본 문서보다 더 최종적인 것처럼 느껴집니다. 이것이 바로 빌더들이 인용(Citations)을 장식용 각주로 취급하는 것을 멈추고, 제품의 안전 시스템(Safety System)의 일부로 취급하기 시작해야 하는 이유입니다.

사용자가 실제로 필요로 하는 것

사용자들은 모든 답변 아래에 법적 고지 사항(Legal Disclaimer)이 스테이플러로 찍혀 있는 것을 원하지 않습니다. 그들에게 필요한 것은 피해가 발생하기 전에 불확실성(Uncertainty)을 가시화하는 인터페이스입니다.

AI 검색 및 지식 제품의 경우, 이는 단순히 관련 링크의 더미를 보여주는 것이 아니라 답변에 사용된 정확한 소스 구절(Source Passages)을 보여주는 것을 의미합니다. 만약 답변이 특정 개인, 기업 또는 조직이 해로운 행동을 했다고 말한다면, 제품은 일반적인 요약보다 더 강력한 증거를 요구해야 합니다. 만약 시스템이 직접적인 근거를 찾을 수 없다면, 이를 명확하게 밝혀야 합니다.

내부용 AI 도구의 경우, 모든 중요한 답변은 추적 기록(Trace)을 포함해야 함을 의미합니다: 어떤 문서, 데이터베이스 테이블, 프롬프트(Prompt), 도구(Tool), 그리고 타임스탬프(Timestamp)가 해당 답변을 생성했는지에 대한 기록입니다. 이 추적 기록은 무언가 고장 나기 전까지는 아무도 열어보지 않는 벤더 대시보드(Vendor Dashboard)에 묻혀 있는 것이 아니라, 사람이 검토할 수 있는 형태로 읽을 수 있어야 합니다.

실무 빌더를 위한 체크리스트

AI를 실제 워크플로우(Workflow)에 배포하고 있다면, 다음과 같은 안전장치부터 시작할 것을 권장합니다:

검색(Retrieval)과 생성(Generation)을 분리하십시오. 모델이 답변을 작성하기 전에 시스템이 무엇을 검색했는지 로그(Log)를 남기십시오. 증거가 나쁘다면 답변도 나쁠 것입니다.
민감한 주장(Sensitive Claims)에 대해서는 요약하기 전에 인용하십시오. 비난, 건강, 금융, 법률, 안전, 채용 또는 목회적 돌봄(Pastoral Care) 맥락의 경우, 생성된 결론을 제시하기 전에 직접적인 근거를 보여주십시오.
모델의 느낌(Model Vibes)이 아닌 증거 유형에 따라 신뢰도를 추가하십시오. 직접적인 정책 문구는 포럼 게시물보다 강력합니다. 검증된 데이터베이스 행(Row)은 캐시된 요약보다 강력합니다.
사용자에게 수정 경로를 제공하십시오. 사람들이 잘못된 답변을 보고하고, 소스 문제를 첨부하며, 고객 지원 이메일을 찾아 헤매지 않고도 검토를 요청할 수 있도록 하십시오.
감사 추적(Audit Trail)을 유지하십시오. 고위험 워크플로우의 경우 모델 버전, 프롬프트 버전, 검색 결과, 도구 호출(Tool Calls), 그리고 렌더링된 답변을 저장하십시오.
유용한 거절(Refusal)을 설계하십시오. 좋은 AI 제품은 언제 답변해야 하는지, 언제 더 많은 맥락을 요청해야 하는지, 그리고 언제 사용자를 사람이나 1차 출처(Primary Source)로 안내해야 하는지를 알아야 합니다.

많은 AI 제품의 약점

너무 많은 AI 기능들이 데모(Demo)처럼 만들어집니다. 프롬프트(Prompt), 응답(Response), 멋진 애니메이션을 넣고 바로 출시(Ship)해 버리는 식입니다. 장난감으로서는 괜찮을지 모릅니다. 하지만 사람들이 의사결정을 내리기 위해 사용하는 제품으로서는 충분하지 않습니다.

힘든 작업은 단순히 모델을 더 똑똑하게 만드는 것만이 아닙니다. 어떤 답변에 마찰(Friction, 사용자에게 확인을 요구하는 과정)을 가해야 하는지 결정하는 것입니다. 항상 자신감 있게 들리는 제품은 결국 대중 앞에서 자신 있게 틀린 답을 내놓게 될 것입니다. 더 나은 제품은 여전히 빠를 수 있지만, 속도보다 증거(Proof)가 더 중요한 시점이 언제인지를 알고 있습니다.

기회

이것은 AI 검색이나 AI 어시스턴트(AI Assistants)를 피해야 할 이유가 아닙니다. 오히려 그것들을 진지한 소프트웨어(Serious Software)처럼 구축해야 할 이유입니다.

승자는 가장 화려한 답변 상자를 가진 팀이 아닐 것입니다. 그들은 "여기 답변이 있습니다, 여기 증거가 있습니다, 우리가 불확실한 부분은 여기이며, 이를 검증하는 방법은 다음과 같습니다"라고 말할 수 있는 팀이 될 것입니다. 그런 종류의 제품은 신뢰를 얻는 데는 시간이 걸리지만, 실제 사용자, 실제 실수, 그리고 실제 책임(Accountability)과 마주했을 때 살아남을 수 있습니다.

AI는 새로움(Novelty)의 단계에서 인프라(Infrastructure)의 단계로 이동하고 있습니다. 인프라에는 로그(Logs)가 필요합니다. 검토(Review)가 필요합니다. 데모의 광채가 사라졌을 때 작동하는 지루한 제어 장치(Controls)가 필요합니다. Google의 AI Overviews 논란은 빌더들이 첫 번째 고통스러운 사고가 발생한 후가 아니라, 그전에 이러한 제어 장치들을 추가해야 한다는 점을 상기시켜 줍니다.

참고 문헌

원문 게시처: https://blog.jenuel.dev/blog/ai-overviews-liability-lesson-for-builders