AI 환각 (Hallucinations)은 처음 보기에 고장 난 것처럼 보이는 경우가 드뭅니다. 그것들은 자신감 있고, 세련되었으며, 바로 출시할 수 있을 것처럼 보입니다.

그것이 위험한 부분입니다.

생성된 보고서가 동의한 적 없는 고객을 인용할 수 있습니다. 고객 지원 답변이 정책을 지어낼 수 있습니다. 데이터 어시스턴트가 잘못된 소스를 사용하여 지표를 설명할 수 있습니다. 누군가 이를 알아차릴 때쯤이면, 문제는 더 이상 "모델이 실수를 했다"가 아닙니다. 그것은 스크린샷, 전달된 이메일, 그리고 누가 이 답변을 승인했느냐고 묻는 고객이 포함된 신뢰 사고 (Trust incident)가 됩니다.

해결책은 모델에게 "정확해져라"라고 말하는 것이 아닙니다. 해결책은 모델 주변에 주장 검증 (Claim verification) 파이프라인을 구축하는 것입니다.

이 가이드는 고객 대면 워크플로우, 내부 코파일럿 (Copilots), 분석 어시스턴트, 연구 도구, 온보딩 봇, 또는 규제 준수가 중요한 제품에 AI를 추가하려는 빌더들을 위한 실질적인 아키텍처를 보여줍니다. 목표는 간단합니다: 모든 중요한 AI 생성 주장은 사용자에게 전달되는 답변이 되기 전에 추적 가능하고, 확인 가능하며, 검토 가능해야 합니다.

왜 지금 주장 검증이 중요한가

최근 AI 뉴스는 동일한 패턴을 계속해서 지적하고 있습니다: 조직들은 에이전트 시스템 (Agentic systems)을 통해 더 빠르게 움직이고 있지만, 신뢰 제어 (Trust controls)는 뒤처지고 있다는 점입니다.

TechCrunch의 보고서는 조직들이 자신들의 AI 도입에 관한 주장이 틀렸거나 오해의 소지가 있다고 말한 후, KPMG가 AI 사용 보고서를 철회한 사례를 설명했습니다. 이번 주 Hacker News의 토론에서도 개발자들이 규제 영역에서 AI 지원 제품을 구축하며 "이것이 작동한다"와 "이것이 신뢰할 수 있을 만큼 충분히 정확하다" 사이의 간극과 씨름하고 있음을 보여주었습니다. 동시에, 에이전트 플랫폼, 워크플로우 자동화 도구, RAG 스택, 그리고 AI 데이터 어시스턴트가 일반적인 빌딩 블록 (Building blocks)이 되고 있습니다.

이것은 새로운 제품 요구 사항을 만들어냅니다: 당신의 앱은 단순히 답변을 생성하는 것에 그쳐서는 안 됩니다. 답변의 어느 부분이 주장인지, 그 주장들이 어디에서 왔는지, 그리고 근거가 약할 때 어떤 일이 일어나야 하는지를 알아야 합니다.

소규모 팀에게는 이것이 무겁게 들릴 수 있습니다. 그럴 필요는 없습니다. 유용한 첫 번째 버전은 몇 개의 데이터베이스 테이블, 소스 확인기 (Source checker), 리스크 점수 (Risk score), 그리고 검토 대기열 (Review queue)만으로도 구성될 수 있습니다.

핵심 아이디어: 주장을 객체(Objects)로 취급하기

대부분의 AI 애플리케이션은 모델의 출력을 하나의 텍스트 덩어리(blob)로 취급합니다.

이는 검증을 어렵게 만듭니다. 어떤 문장이 어떤 소스(source)에 의존하는지, 어떤 주장이 위험한지, 또는 어떤 부분을 차단해야 하는지를 쉽게 파악할 수 없기 때문입니다.

대신, 답변을 주장 객체(claim objects)로 분할하십시오.

주장 객체는 다음과 같은 내용을 담은 구조화된 단위입니다:

• AI가 무엇을 주장했는가
• 주장의 유형은 무엇인가
• 어떤 소스(source)가 이를 뒷받침하는가
• 증거가 얼마나 강력한가
• 사람이 검토해야 하는가
• 사용자에게 보여주기에 안전한가

예시:

{
  "claim_id": "clm_9x2",
  "answer_id": "ans_184",
...

주장이 객체가 되면, 다른 프로덕션 이벤트와 마찬가지로 라우팅(routing)할 수 있습니다.

저위험(Low-risk) 주장은 자동으로 통과될 수 있습니다. 근거가 없는 주장은 제거하거나 다시 작성할 수 있습니다. 고위험(High-risk) 주장은 사람의 검토 대기열(human review queue)로 보낼 수 있습니다. 모든 과정은 나중에 디버깅(debugging)할 수 있도록 로그로 기록될 수 있습니다.

무엇을 주장(claim)으로 간주하는가?

주장이란 중요한 측면에서 틀릴 가능성이 있는 모든 진술을 의미합니다.

모든 문장에 동일한 정밀 조사가 필요한 것은 아닙니다. "여기에 요약이 있습니다"는 보통 위험도가 낮습니다. 하지만 "귀하의 환불이 승인되었습니다"는 그렇지 않습니다.

일반적인 주장 유형은 다음과 같습니다:

주장 유형	예시	일반적인 위험도
계정 사실 (Account fact)	"이 사용자는 12개의 활성 시트(seats)를 보유하고 있습니다."	높음
...

많은 팀이 범하는 실수는 최종 답변만을 검증하는 것입니다. 더 나은 파이프라인은 답변 내부의 주장들을 검증합니다.

주장 검증 파이프라인의 아키텍처 (Architecture)

프로덕션 환경에 적합한 흐름은 7단계로 구성됩니다.

1. 초안 답변 생성 (Generate the draft answer)

첫 번째 모델 호출은 일반적인 초안을 생성합니다. 아직 이를 사용자에게 보여주지 마십시오.

모델에게 근거 없는 구체적인 정보를 피하도록 요청하되, 그 지침에만 유일한 통제 수단으로 의존하지 마십시오. 프롬프트(Prompt)는 도움을 줄 뿐이며, 파이프라인(Pipeline)이 강제합니다.

const draft = await llm.generate({
  system: "제공된 컨텍스트(context)만을 사용하여 답변하세요. 이름, 날짜, 숫자, 정책 또는 인용구를 지어내지 마세요.",
  user: userQuestion,
...

2. 원자적 주장 추출 (Extract atomic claims)

초안을 주장 추출기 (claim extractor)로 보냅니다. 이는 동일한 모델일 수도 있고, 더 저렴한 모델이거나 하이브리드 파서 (hybrid parser)일 수도 있습니다.

추출기는 작고 테스트 가능한 주장 (claims)을 반환해야 합니다. 다섯 가지 사실이 뒤섞인 거대한 주장은 피하세요. “사용자가 3월에 업그레이드했고, 연간 결제를 했으며, 환불 대상입니다”라는 문장은 업그레이드 날짜, 결제 조건, 정책 기간, 자격 요건에 대한 별도의 주장으로 분리해야 합니다.

예시 추출기 프롬프트 (extractor prompt):

답변에서 사실적 주장 (factual claims)을 추출하세요.
JSON으로만 반환하세요.
각 주장은 원자적 (atomic)이고 검증 가능해야 하며, 유형별로 라벨이 지정되어야 합니다.
...

예상 출력:

[
  {
    "text": "The user upgraded in March.",
...

3. 필요한 증거 규칙 부착 (Attach required evidence rules)

모든 주장 유형 (claim type)은 증거 규칙 (evidence rule)에 매핑되어야 합니다.

이 지점에서 많은 시스템이 모호해집니다. “모델이 컨텍스트 (context)에서 확인했다고 말했다”는 식의 답변은 고위험 워크플로 (high-risk workflows)에 충분하지 않습니다.

명시적인 규칙을 사용하세요:

주장 유형 (Claim type)	증거 규칙 (Evidence rule)
계정 사실 (Account fact)	데이터베이스 또는 결제 API와 일치해야 함
...

시작 단계에서는 간단한 규칙 객체 (rules object)만으로도 충분합니다:

const evidenceRules = {
  account_fact: { required: "database", review: "on_mismatch" },
  policy_claim: { required: "approved_document", review: "on_missing" },
...

4. 올바른 소스에 대해 검증 (Verify against the right source)

검증은 제약이 없는 다른 모델이 아니라, 신뢰할 수 있는 원천 (source of truth)을 사용해야 합니다.

예를 들어:

• 고객 상태 (customer status) → 데이터베이스 (database)
• 결제 플랜 (billing plan) → Stripe 또는 내부 결제 테이블 (internal billing table)
• 분석 지표 (analytics metric) → 데이터 웨어하우스 쿼리 (warehouse query)
• 정책 (policy) → 승인된 정책 문서 (approved policy docs)
• 문서 요약 (document summary) → 검색된 소스 구간 (retrieved source spans)
• 코드 설명 (code explanation) → 리포지토리 파일 (repository files)
• 웹 조사 (web research) → 저장된 소스 스냅샷 (saved source snapshot)

검증기 (verifier)는 결정론적 (deterministic)일 수도 있고, 모델 보조 (model-assisted) 방식일 수도 있으며, 두 가지 모두를 사용할 수도 있습니다.

구조화된 데이터 (structured data)의 경우, 결정론적 체크를 사용하세요:

async function verifyAccountClaim(claim, tenantId) {
  const record = await db.subscriptions.findFirst({
    where: { tenantId, userId: claim.subject_user_id }
...

비구조화된 문서 (unstructured documents)의 경우, 소스 구간 매칭 (source-span matching)을 사용하세요:

async function verifySourceClaim(claim, sourceChunks) {
  const result = await llm.generateJson({
    system: "소스 텍스트가 해당 주장을 직접적으로 뒷받침하는지 결정하세요. supported, contradicted, 또는 not_found 중 하나를 반환하세요.",
...

5. 리스크를 점수화하고 경로(route) 결정하기

이제 주장 유형(claim type), 검증 결과(verification result), 신뢰도(confidence), 그리고 사용자 영향도(user impact)를 결합합니다.

간단한 라우팅 매트릭스(routing matrix)가 효과적입니다:

조건	경로 (Route)
검증됨 (Verified) + 낮은 리스크 (low risk)	게시 (Publish)
...	...

예시:

function routeClaim(claim, verification) {
  if (verification.status === "contradicted") return "block";
  if (verification.status === "not_found") return "rewrite";
...

6. 검증된 주장만을 사용하여 답변 재작성하기

뒷받침되지 않는 주장을 단순히 삭제하고 문단이 여전히 말이 통하기를 바라지 마세요. 모델에게 검증된 주장 세트(verified claim set)를 사용하여 재작성하도록 요청하세요.

입력값:

• 원본 답변 (original answer)
• 검증된 주장 (verified claims)
• 차단된 주장 (blocked claims)
• 재작성 정책 (rewrite policy)

프롬프트 (Prompt):

'verified'로 표시된 주장만을 사용하여 답변을 재작성하세요.
유용한 답변을 제공할 수 없는 경우, 무엇이 누락되었는지 말하세요.
내부 검증 라벨(internal verification labels)을 언급하지 마세요.
...

다음과 같은 답변 대신:

귀하의 계정은 3월에 업그레이드되었으며 환불 자격이 있습니다.

다음과 같은 답변을 받을 수 있습니다:

귀하의 계정이 Pro 플랜임을 확인했습니다. 가용한 정책 컨텍스트(policy context) 내에서는 환불 자격 여부를 확인할 수 있는 충분한 검증 정보가 없습니다.

이러다가 답변은 덜 화려할지 모르지만, 더 안전하고 신뢰할 수 있습니다.

7. 증거 영수증(evidence receipt) 저장하기

모든 중요한 답변은 영수증을 남겨야 합니다.

이것이 민감한 원문 프롬프트(raw prompts)를 영원히 저장해야 한다는 의미는 아닙니다. 출력값을 디버깅하고 감사(audit)할 수 있을 만큼 충분한 증거를 저장해야 한다는 의미입니다.

영수증에는 다음 항목이 포함될 수 있습니다:

• 답변 ID (answer ID)
• 주장 ID (claim IDs)
• 프롬프트 버전 해시 (prompt version hash)
• 모델 이름 및 설정 (model name and settings)
• 소스 문서 ID (source document IDs)
• 소스 텍스트 해시 (source text hashes)
• 데이터베이스 레코드 ID (database record IDs)
• 검증 결과 (verification result)
• 검토자 결정 (reviewer decision)
• 최종 답변 해시 (final answer hash)
• 타임스탬프 (timestamps)

예시 스키마 (Example schema):

create table ai_claims (
  id text primary key,
  answer_id text not null,
...

Human review queues: 자동화가 멈춰야 하는 시점

훌륭한 검증 파이프라인(verification pipeline)은 인간을 배제하는 것이 아닙니다. 대신 인간이 가장 중요한 순간에 인간을 활용합니다.

다음과 같은 경우를 위해 리뷰 큐(review queues)를 생성하세요:

• 근거가 없는 고영향 주장 (unsupported high-impact claims)
• 고객/계정 사실 관계가 불일치하는 경우 (mismatched customer/account facts)
• 소스 매칭이 약한 정책 관련 주장 (policy claims with weak source matches)
• 컴플라이언스(compliance) 비중이 높은 설명
• 이메일로 발송되거나, 게시되거나, 외부에 노출될 생성 콘텐츠
• 돈, 접근 권한, 건강, 법적 의무 또는 보안과 관련된 답변

리뷰 UI에는 최종 제안된 답변, 위험한 주장, 뒷받침하는 소스, 충돌 사항, 모델 신뢰도(model confidence), 그리고 승인/재작성/거절(approve/rewrite/reject) 버튼이 표시되어야 합니다. 리뷰어에게 숨겨진 전체 프롬프트 추적(prompt trace)을 읽으라고 요구하지 마세요. 그들에게 필요한 결정 패킷(decision packet)을 제공하십시오.

소규모 구현 계획

만약 당신이 1인 개발자이거나 소규모 팀이라면, 이를 계층별로 구축하십시오.

Version 1: 근거 없는 구체적 정보 차단

단순한 규칙부터 시작하세요: 만약 답변에 이름, 날짜, 숫자, 정책 용어, 가격 또는 고객별 계정 사실이 포함되어 있다면, 반드시 소스 참조(source reference)가 필요합니다.

이것만으로도 많은 당혹스러운 실패 사례를 잡아낼 수 있습니다.

Version 2: 주장 추출 (claim extraction) 추가

주장(claims)을 답변과 별도로 저장하세요. 주장 유형, 위험 수준, 소스 참조 및 검증 상태를 추가합니다.

Version 3: 결정론적 체크 (deterministic checks) 추가

구조화된 제품 데이터의 경우, 모델을 검사기로 사용하는 것을 중단하세요. 데이터베이스, 결제 제공업체, 창고 또는 승인된 설정(config)과 직접 대조하여 검증하세요.

Version 4: 리뷰 큐 추가

고위험 또는 불확실한 주장만 인간에게 전달하도록 라우팅하세요. 사람들이 실제로 사용할 수 있도록 큐의 규모를 작게 유지하십시오.

Version 5: 실패 사례 재현 (replay failures)

잘못된 답변이 통과되었을 때, 해당 사례를 회귀 테스트(regression test)로 저장하세요.

테스트에는 다음 항목이 포함되어야 합니다:

• 원래 사용자 질문
• 검색된 컨텍스트 (retrieved context)
• 모델 초안 (model draft)
• 추출된 주장 (extracted claims)
• 검증 결과
• 기대되는 안전한 답변

이를 통해 사고(incidents)를 평가 커버리지(eval coverage)로 전환할 수 있습니다.

피해야 할 일반적인 실수

실수 1: 두 번째 모델을 유일한 판사(judge)로 사용하는 것

두 번째 모델이 도움을 줄 수는 있지만, 그것이 진실의 근원(source of truth)은 아닙니다. 두 번째 모델 또한 환각 (Hallucinations)을 일으킬 수 있습니다.

모델은 분류(classify), 비교(compare), 설명(explain)하는 데 사용하십시오. 검증(verify)에는 기록 시스템 (systems of record)을 사용하십시오.

실수 2: 주장 (claims)이 아닌 인용 (citations)만 검증하는 것

인용이 존재하더라도 해당 문장을 뒷받침하지 못할 수 있습니다. 인용된 구간 (quoted span)이 실제로 주장을 증명하는지 항상 확인하십시오.

실수 3: 모든 주장을 동일하게 취급하는 것

잘못된 일반적 설명은 짜증을 유발할 뿐입니다. 잘못된 환불, 세금, 액세스 또는 보안 관련 주장은 심각한 문제를 초래할 수 있습니다.

리스크 라우팅 (Risk routing)이 중요합니다.

실수 4: 불확실성을 숨기는 것

주장을 검증할 수 없다면, 이를 명확하게 밝히십시오. 사용자는 자신감 넘치는 추측보다 절제된 답변을 더 신뢰합니다.

실수 5: 너무 많은 민감한 데이터를 저장하는 것

감사 가능성 (Auditability)을 확보한다고 해서 부주의하게 데이터를 보관해야 하는 것은 아닙니다. ID, 해시 (hashes), 비식별화 (redaction) 및 보관 주기 (retention windows)를 사용하십시오.

이것이 AI 스택의 어디에 위치하는가

주장 검증 파이프라인 (claim verification pipeline)은 생성 (generation) 이후와 전달 (delivery) 이전에 위치합니다.

전형적인 흐름은 다음과 같습니다:

1. 사용자가 질문을 합니다.
2. 앱이 컨텍스트 (context)를 검색합니다.
3. 모델이 답변 초안을 작성합니다.
4. 주장 추출기 (Claim extractor)가 사실적 주장 (factual assertions)을 식별합니다.
5. 검증기 (Verifiers)가 각 주장을 확인합니다.
6. 라우터 (Router)가 게시 (publish), 재작성 (rewrite), 차단 (block) 또는 검토 (review)를 결정합니다.
7. 검증된 주장과 함께 답변이 재작성됩니다.
8. 증거 영수증 (Evidence receipt)이 저장됩니다.
9. 실패 사례는 평가 케이스 (eval cases)가 됩니다.

이 방식은 RAG 앱, AI 데이터 분석가, 지원 코파일럿 (support copilots), 코딩 어시스턴트 (coding assistants), 브라우저 에이전트 (browser agents), 문서 워크플로우 (document workflows) 및 내부 운영 도구와 함께 작동합니다.

또한 LLM 게이트웨이 (LLM gateways), RAG 평가 (RAG evaluation), 출력 출처 (output provenance), 승인 게이트 (approval gates) 및 관측성 (observability)과도 잘 결합됩니다. 중요한 점은 주장 검증이 별도의 "품질 프로젝트"가 아니라는 것입니다. 이는 답변 경로 (answer path)의 일부입니다.

최종 체크리스트

영향력이 큰 AI 답변을 사용자에게 보여주기 전에, 다음을 질문하십시오:

• 사실 관계에 기반한 주장 (factual claims)을 추출했는가?
• 중요한 주장들에 필요한 근거 (evidence)가 포함되었는가?
• 구조화된 사실 (structured facts)이 실제 진실의 원천 (source of truth)과 일치하는가?
• 출처 기반의 주장 (source-based claims)에 일치하는 인용구 (quotes) 또는 구절 (spans)이 포함되었는가?
• 위험한 주장 (risky claims)이 검토 (review) 단계로 넘어갔는가?
• 근거 없는 주장 (unsupported claims)이 제거되거나 다시 작성되었는가?
• 근거 영수증 (evidence receipt)을 저장했는가?

만약 그렇지 않다면, 시스템은 여전히 모델의 확신 (model confidence)에 너무 많이 의존하고 있는 것입니다. 유용한 AI 제품의 미래는 단순히 더 나은 프롬프트 (prompts)를 만드는 것에 있지 않습니다. 그것은 프롬프트 주변의 더 나은 검증 (verification)에 있습니다.

FAQ

AI 주장 검증 파이프라인 (AI claim verification pipeline)이란 무엇인가요?

AI 주장 검증 파이프라인은 모델 출력에서 사실 관계에 기반한 주장 (factual claims)을 추출하고, 이를 신뢰할 수 있는 출처와 대조하며, 위험한 주장은 검토 단계로 전달하고, 근거 없는 답변은 다시 작성하며, 감사 (audit) 또는 디버깅 (debugging)을 위해 근거를 저장하는 워크플로우 (workflow)입니다.

주장 검증 (claim verification)이 RAG 평가 (RAG evaluation)와 동일한 것인가요?