AI 요약에는 증거가 필요합니다: 댓글로부터 근거 기반 보고서를 구축하는 방법

AI 피드백 도구를 사용하면서 제가 계속 마주치는 실수는 요약(summary) 자체를 결과물로 취급하는 것입니다.

모델이 자신감 있게 한 단락을 작성하도록 만드는 것은 더 이상 어려운 일이 아닙니다.

어려운 부분은 모든 유용한 주장이 그것을 생성해낸 무질서한 소스 행(source rows)으로 추적 가능하게 만드는 것입니다.

저는 YouTube 댓글을 기반으로 한 도구를 만들면서 이 문제에 부딪혔습니다. 이 도구를 만들기 전, 크리에이터로서 YouTube 댓글을 수동으로 읽는 데 많은 시간을 보냈고, 그것이 아마도 이 문제에 대해 생각하는 방식에 영향을 주었을 것입니다.

크리에이터, 창업자 또는 마케터는 단순히 "사람들이 영상을 좋아합니다" 또는 "시청자들이 더 많은 튜토리얼을 원합니다"라는 정보만 필요로 하지 않습니다. 그들은 어떤 댓글이 해당 주장을 뒷받침하는지, 그 신호가 단 하나의 목소리 큰 댓글에서 온 것인지 아니면 실제 패턴인지, 그리고 모델이 댓글이 실제로 정당화하지 못하는 깔끔한 이야기를 지어낸 것은 아닌지를 알아야 합니다.

보고서 흐름을 테스트하는 동안, 모델에 대한 질문보다 신뢰에 대한 질문이 더 중요했습니다.

"어떤 모델이 보고서를 가장 잘 쓰는가?"가 아니라,

무질서한 댓글에 대한 AI 보고서를 왜 내가 믿어야 하는가?

이것이 이 포스트에서 다루고자 하는 기술적인 문제입니다.

흔한 실수: 요약을 먼저 하고, 출처는 나중에

가장 단순한 AI 보고서 파이프라인은 다음과 같습니다:

댓글 (comments)
-> 프롬프트 (prompt)
-> 요약 (summary)
...

이는 빠른 읽기에는 유용할 수 있습니다. 목표가 개인적인 메모, 대략적인 요약, 또는 1차 브레인스토밍이라면 느슨한 요약만으로도 충분할 수 있습니다.

하지만 출력물이 행동을 가이드해야 할 때는 문제가 발생합니다.

예를 들어, 세 개의 댓글이 있다고 가정해 봅시다:

c1: "초보자용 버전을 만들어 주실 수 있나요? 중간에 길을 잃었어요."
c2: "심화 부분은 유용했지만, 더 느린 설정 가이드가 필요합니다."
c3: "사용하신 템플릿을 공유해 주세요."

합리적인 요약은 다음과 같이 말할 수 있습니다:

시청자들이 더 초보자 친화적인 설정 자료를 원합니다.

이것은 괜찮습니다.

하지만 이제 생성된 보고서가 다음과 같이 말한다고 가정해 봅시다:

시청자들이 유료 강의와 다운로드 가능한 스타터 키트를 요청하고 있습니다.

그것이 좋은 비즈니스 아이디어일 수도 있고, 아닐 수도 있습니다. 중요한 점은 위의 댓글들이 실제로 그렇게 말하고 있지 않다는 것입니다.

보고서가 연결 고리를 보여주지 않은 채 증거(evidence)에서 해석(interpretation)으로 넘어가 버렸습니다.

일반적인 요약이 유용한 경우

모든 AI 요약에 인용 시스템(citation system)이 필요하다고 생각하지는 않습니다.

일반적인 요약은 다음과 같은 경우에 유용합니다:

독자가 대략적인 방향성만 파악하면 될 때
소스 세트(source set)가 수동으로 검토할 수 있을 만큼 충분히 작을 때
출력물이 고객 대응용이나 비즈니스 의사결정에 사용되지 않을 때
모델이 증거가 아닌 브레인스토밍(brainstorming)을 돕고 있을 때

더 엄격한 요구사항은 요약이 의사결정 접점(decision surface)이 될 때 시작됩니다.

만약 보고서가 답변 아이디어, 콘텐츠 아이디어, 포지셔닝 변경, 리스크 검토 또는 제품 결정을 제안한다면, 사용자는 다음과 같이 물을 수 있어야 합니다:

이 내용의 근거가 되는 댓글들을 보여줘.

시스템이 이에 답할 수 없다면, 해당 보고서가 여전히 유용할 수는 있지만 검토 가능성(inspectable)은 매우 떨어집니다.

더 나은 단위: 증거 기반 주장 (evidence-bound claim)

제가 선호하는 형태는 "요약 우선"이 아닙니다.

그것은 다음과 것에 더 가깝습니다:

소스 행 (source rows)
-> 후보 주장 (candidate claims)
-> 증거 결합 (evidence binding)
...

데이터 수준에서 기본 객체(object)는 단순합니다:

type EvidenceBoundClaim = {
  title: string;
  summary: string;
...

그 작은 필드 하나가 제품의 계약(product contract)을 바꿉니다.

주장은 단순한 텍스트가 아닙니다. 그것은 텍스트와 더불어 사용자가 검토할 수 있는 소스 댓글 목록의 결합입니다.

댓글 보고서에서 동일한 패턴은 다음과 같은 항목에 적용될 수 있습니다:

반복되는 질문
수요 신호 (demand signals)
반대 의견 (objections)
찬사 (praise)
혼란 (confusion)
리스크 신호 (risk signals)
콘텐츠 아이디어
답변 아이디어

보고서는 여전히 일반적인 언어로 작성될 수 있습니다. 다만 댓글로부터 동떨어져 떠다녀서는 안 됩니다.

무질서한 피드백에 더 엄격한 결합이 필요한 이유

YouTube 댓글은 깔끔한 설문 조사 답변이 아닙니다.

댓글에는 농담, 비꼬기, 스팸, 반복되는 질문, 한 단어로 된 반응, 언어 혼용, 답글에 대한 답글, 크리에이터 특유의 맥락, 그리고 스레드 내의 위치 때문에 유용한 댓글 등이 포함되어 있습니다.

이는 여러 가지 실패 모드 (failure modes)를 생성합니다.

하나의 댓글이 패턴이 되는 경우

모델이 하나의 강력한 불만을 발견하면, 마치 청중 전체가 광범위하게 동의하는 것처럼 작성합니다.

증거 결합 (Evidence binding) 자체가 이 문제를 해결하지는 못하지만, 약점을 가시화해 줍니다. 만약 "주요 우려 사항"에 단 하나의 증거 행 (evidence row)만 있다면, 사용자는 20개의 댓글이 뒷받침하는 우려 사항과는 다르게 판단할 수 있습니다.

패턴이 출처를 잃어버리는 경우

모델은 많은 사람이 혼란스러워하고 있다는 점을 정확히 감지하지만, 보고서에는 어떤 댓글이 그러한 인상을 만들었는지 나타나지 않습니다.

이는 보고서를 사용하기 어렵게 만듭니다. 크리에이터는 댓글을 인용하거나, 적절한 스레드에 답변하거나, 혹은 그 혼란이 영상, 제품, 제목, 또는 시청자의 사전 지식에 관한 것인지 결정할 수 없게 됩니다.

다중 소스 보고서의 맥락 혼합

입력에 여러 영상, 재생 목록, 채널 또는 URL 목록이 포함된 경우, 모델은 실수로 소스들을 혼합할 수 있습니다.

이것이 소스 메타데이터 (source metadata)가 중요한 이유입니다. 다음과 같이 압축된 형태면 충분합니다:

type CommentForAnalysis = {
  comment_id: string;
  text: string;
...

이렇게 하면 각 댓글이 자신이 속한 소스 키 (source key)를 지니고 있는 동안, 소스 맥락 (source context)은 한 번만 전송될 수 있습니다.

가드레일 (guardrail)은 간단합니다:

증거 ID (evidence IDs)가 해당 source_key를 뒷받침하지 않는 한, 소스 수준의 차이를 주장하지 마십시오.

이 규칙이 없다면, 인용된 댓글이 실제로 비교를 뒷받침하지 않음에도 불구하고 보고서에 "영상 A가 영상 B보다 가격에 대한 반대가 더 많습니다"라고 적힐 수 있습니다.

내가 더 신뢰하는 파이프라인

이러한 종류의 제품을 위해 내가 원하는 파이프라인은 다음과 같습니다:

공개 댓글 행 (public comment rows)
-> 안정적인 댓글 ID (stable comment IDs)
-> 선택적 소스 맵 (optional source map)
...

내 구현 방식에서 보고서는 나중에 YouTube가 무엇을 반환하느냐에 의존하지 않고, 저장된 댓글 스냅샷 (comment snapshot)으로부터 생성됩니다. 일단 댓글이 저장되면, 분석 단계는 해당 저장된 소스 행들을 대상으로 작동하며, 보고서는 지원이 필요한 주장(claims)에 대해 evidence_comment_ids를 포함하는 결정론적인 semantic_snapshot을 저장합니다.

주장(claim)이 가시적인 증거가 되기 전에, 해당 ID들은 저장된 스냅샷(snapshot)을 대상으로 다시 확인(resolve)됩니다. 만약 ID가 확인되지 않는다면, 독자가 검토할 수 있는 증거 사례 중 하나가 될 수 없습니다.

다중 비디오 입력의 경우, 각 행(row)은 압축된 source_key를 가질 수 있습니다. 분석 프롬프트(analysis prompt)는 증거 ID가 해당 키(key)를 뒷받침하지 않는 한, 모델이 소스 수준의 차이점을 주장하지 않도록 명시적으로 지시합니다.

중요한 제품 결정 사항은 어디까지 엄격하게 제한할 것인가 하는 점입니다.

시스템은 언어, 그룹화(grouping), 해석(interpretation) 측면에서 모델의 도움을 받을 수 있습니다.

하지만 모델이 임의로 만들어낼 수 없는 사항들에 대해서는 엄격해야 합니다:

댓글 ID (comment IDs)
소스 키 (source keys)
정확한 소스 발췌문 (exact source excerpts)
감성 합계 (sentiment totals)
분석된 행 수 (analyzed row counts)
주장에 충분한 근거가 있는지 여부
보고서가 내보내기(export) 또는 공유할 준비가 되었는지 여부

다시 말해, 모델은 이야기를 제안할 수 있습니다.

하지만 시스템은 그 영수증(증거)을 검증해야 합니다.

보고서 완료 판정 전의 검증 (Validation)

피드백 보고서의 경우, 출력이 완료된 것으로 간주하기 전에 다음과 같은 체크 사항들을 거치기를 원합니다:

comments_analyzed > 0
sentiment counts sum to comments_analyzed
every evidence_comment_id resolves against saved source rows
...

이러한 체크 중 일부는 쉽습니다. 일부는 번거롭습니다. 하지만 이 모든 과정은 제품의 '마법 같은 느낌'을 유용한 방식으로 줄여줍니다.

목표는 보고서가 더 자신감 있게 들리도록 만드는 것이 아닙니다.

목표는 근거 없는 자신감이 사용자에게 전달되는 것을 방지하는 것입니다.

증거가 불완전할 때 사용자에게 보여줄 것

이 지점은 백엔드 검증(backend validation)만큼이나 제품 디자인(product design)이 중요한 영역입니다.

만약 증거가 빈약하다면, 사용자에게 보여지는 보고서가 다음과 같이 말하는 것을 원치 않습니다:

신뢰도는 낮지만, 어쨌든 다듬어진 권장 사항을 제공합니다.

이는 사람들이 경고를 무시하도록 가르치는 꼴이 됩니다.

저는 다음 세 가지 결과 중 하나를 선호합니다:

보고서를 '검증 중' 또는 '처리 중' 상태로 유지합니다.
더 작은 규모의 주장(claims)을 담은 보수적인 폴백(fallback) 보고서를 생성합니다.
데이터가 사용 불가능한 경우, 안정적인 소스 또는 계정 차단(blocker)을 표시합니다.

완성된 보고서의 경우, 복사본(copy)은 실제로 무엇이 검증되었는지를 설명해야 합니다:

저장된 댓글 (saved comments)
분석된 샘플 (analyzed sample)
스레드 경계 (thread boundary)
...

이는 지금까지 존재했던 모든 댓글을 완벽하게 커버하겠다고 약속하는 것과는 다릅니다.

삭제됨, 숨겨짐, 비공개, 거부됨, 수정됨, 사용 불가능 또는 API 제한이 걸린 댓글은 여전히 경계 밖에 있을 수 있습니다. 좋은 보고서는 경계가 존재하지 않는 척하는 대신, 데이터의 경계(data boundary)를 설명해야 합니다.

이 접근 방식이 적절하지 않은 경우

증거 기반 보고(Evidence-bound reporting)가 항상 추가적인 구조를 들일 만큼 가치 있는 것은 아닙니다.

다음과 같은 경우에는 더 느슨한 요약(looser summary)을 사용하세요:

출력이 개인적인 읽기 보조 도구로만 사용될 때
소스 세트(source set)가 작을 때
사용자가 어차피 모든 소스 행을 검토할 때
목표가 의사 결정 지원이 아닌 브레인스토밍일 때

다음과 같은 경우에는 증거 기반 보고서를 사용하세요:

출력이 특정 행동을 권장할 때
여러 이해관계자(stakeholders)가 보고서를 읽을 때
보고서가 내보내기, 공유 또는 나중에 사용될 수 있을 때
소스 데이터가 너무 지저분하여 환각된 확신(hallucinated certainty)이 위험할 때
사용자가 시스템이 왜 그런 결론에 도달했는지 감사(audit)해야 할 때

경계는 도구를 정직하게 유지해 줍니다.

제가 이를 적용하는 방법

저는 이를 AudienceCue 샘플 보고서의 공개 YouTube 댓글에 적용하고 있습니다.

핵심적인 제품 아이디어는 다음과 같습니다:

공개 YouTube 링크 붙여넣기
-> 댓글 다운로드
-> 오디언스 보고서 생성
...

이것은 읽기 전용(read-only)입니다. YouTube 댓글에 답글을 달거나, 채널을 관리하거나, 무언가를 삭제하거나, 고정하거나, 크리에이터를 대신하여 조치를 취하지 않습니다.

이러한 읽기 전용 경계는 의도적인 것입니다. 지금은 자동화로 서두르기보다 증거 계층(evidence layer)을 신뢰할 수 있게 만드는 것이 더 중요합니다.

빌더를 위한 체크리스트

지저분한 피드백을 요약하는 AI 도구를 구축하고 있다면, 저는 다음과 같은 질문을 던질 것입니다:

모든 중요한 주장(claim)이 소스 행(source rows)을 참조하고 있습니까?
시스템이 허구로 만들어졌거나 누락된 증거 ID(evidence IDs)를 감지할 수 있습니까?
인용된 예시들이 저장된 소스 스냅샷(source snapshot)과 대조 확인됩니까, 아니면 모델이 의역(paraphrases)한 것입니까?
사용자가 하나의 강한 의견(one loud comment)과 반복되는 패턴(repeated pattern) 사이의 차이를 구분할 수 있습니까?
여러 개의 비디오, 파일 또는 계정이 있을 때 보고서가 소스 문맥(source context)을 보존합니까?
증거 검증 단계(evidence gate)를 통과할 때까지 내보내기(export) 및 공유(share) 작업이 차단됩니까?
증거가 약할 때, 제품이 확신에 찬 문구(confident copy) 뒤로 약점을 숨기는 대신 주장의 강도(claim strength)를 낮춥니까?

마지막 질문이 저에게는 가장 중요합니다.

AI 요약은 인상적으로 만들기 쉽습니다. 하지만 증거에 기반한(evidence-bound) 요약은 더 어렵지만, 신뢰하기는 더 쉽습니다.

다른 분들은 실제 운영 시스템(production systems)에서 이를 어떻게 처리하는지 궁금합니다. AI가 지저분한 사용자 피드백을 요약할 때, 엄격한 인용(strict citations)을 사용하시나요, 근사적 참조(approximate references)를 사용하시나요, 아니면 사람의 검토(human review)를 거치시나요?