#AI가 데이터를 지어내는 것을 어떻게 막나

← 전체 목차 · 이전: LLM 애플리케이션에 왜 "출력 길이 예산"이 반드시 필요한가 · 다음: 표 QA는 LLM이 읽게 할까, 코드가 계산하게 할까?

데이터층, 계산층, 표현층 세 층으로 쪼개고 여기에 필드 분해 → 도구 계산 → 답변 인용이라는 3단 워크플로를 붙인다. 숫자는 데이터 시스템에서 조회하고, 계산은 코드가 실행하며, 모델은 구조화된 결과를 읽을 수 있는 리포트로 쓰는 일만 담당한다. 데이터가 없으면 결손을 표기하거나 되묻지, 절대 지어내지 않는다.

한 문장 대원칙: 숫자는 데이터 시스템에서 와야지 모델의 머릿속에서 나오면 안 된다.

#표면은 환각을 묻지만 실제로는 사실 사슬을 묻는다

#분업 원칙

데이터 도구 — 조회, 계산

모델 — 이해, 조직, 설명

#1. 필드 분해

사실 숫자 — 반드시 데이터 소스와 집계 기준에 바인딩

폴백 규칙: 데이터가 없으면 결손을 표기하거나 되묻고, 지어내면 안 된다.

경계: 모델은 표현을 담당하지 사실을 발명하지 않는다.

#2. 도구 계산

규칙: 모델이 쿼리 계획을 생성하는 것은 되지만, 결과는 결정론적 도구가 반환해야 한다.

1. 전년 대비
2. 전기 대비
3. 순위
4. 평균값
5. 이상 탐지

중요한 숫자에 대해서는 2차 검증도 해야 한다.

#3. 답변 인용

주보 핵심 수치 85.4%  ──┬─→ 하위 쿼리 결과
                      └─→ 원본 리포트 링크

모든 핵심 수치는 밑바탕 출처로 역추적할 수 있어야 한다.

사용자가 "이 전환율은 어떻게 계산한 건가요?"라고 되물으면, 시스템이 기준과 출처를 제시할 수 있어야지 모델이 다시 설명하게 하면 안 된다.

1. 모든 숫자에 출처가 있다
2. 모든 계산에 기준이 있다
3. 모든 결측에 사유가 있다

#3층 아키텍처

#핵심 통찰

1. "모델이 숫자를 지어낸다"는 모델 문제가 아니라 아키텍처 문제다 — 이 문서에서 가장 중요한 판정의다. 환각을 모델 탓으로 돌리면 해법이 Prompt 조정밖에 안 되지만, "숫자에 사실 사슬이 없다" 탓으로 돌리면 해법이 엔지니어링으로 풀 수 있는 3층 분할이 된다. 답변의 분수령이 바로 이 원인 규명 단계에 있다.
2. Prompt는 표현층의 제약기이지 사실층의 보증기가 아니다 — 이것이 Prompt 엔지니어링의 능력 상한을 제시한다. 모델이 "지어내기를 거부하게" 만들 수는 있어도 모델이 "정답을 알게" 만들 수는 없다. Prompt를 데이터베이스로 여기는 것은 제약기를 데이터 소스로 오용하는 것이다.
3. 모델이 쿼리 계획을 생성하는 것은 되지만 결과를 생성하는 것은 안 된다 — 이 경계가 극히 실용적이다. 모델의 강점은 자연어 의도를 쿼리 의도로 번역하는 것(계획 생성)이고, 약점은 결정론적 연산을 실행하는 것이다. "계획은 모델이, 결과는 도구가"를 고수하기만 하면 환각의 주입 지점이 물리적으로 격리된다.
4. "1200을 어떻게 서술할까"는 모델의 몫이고 "1200이 얼마인가"는 데이터베이스의 몫이다 — 숫자 하나로 직책 경계를 관통해 설명한다. 모든 AI 생성류 시스템에 그대로 옮길 수 있는 기준이다: 서술권은 모델에, 취득권은 데이터에.
5. 기준이 불명확하면 "하나 추측하기"가 아니라 "반드시 되묻기"다 — 대부분의 AI 리포트 사고는 잘못 계산한 것이 아니라 계산 기준이 사람의 생각과 다른 것이다(테스트 계정을 포함하는지, 중복을 제거하는지, 자연주인지 롤링 7일인지). "기준 불명확 → 되묻기"를 하드 규칙으로 만드는 편이 사후에 숫자를 맞춰보는 것보다 싸다.
6. 검증 가능성은 내장할 수 있다: 총계 = 항목의 합, 주기가 완전한가 — 이 두 가지는 비용 0의 자가 점검 불변식이다. 어떤 리포트 시스템이든 이런 항등식을 어서션으로 만들어 "예쁘지만 틀린 주보"가 발송 전에 차단되게 해야 한다.
7. 인용이 있어야 신뢰도가 있다: 숫자는 쿼리나 리포트 링크로 역추적 가능해야 한다 — 인용은 사용자에게 보여주기 위한 것만이 아니라 동시에 시스템 자신을 위한 감사 입구다. 역추적 가능한 숫자는 문제가 생기면 위치를 특정할 수 있고, 역추적 불가능한 숫자는 통째로 다시 만드는 수밖에 없다.
8. 평가에서 숫자 정확률을 텍스트 품질에서 떼어내 단독 집계할 것 — 가장 놓치기 쉬운 항목이다. 총점 하나에 섞으면 유창함이 사실 오류를 덮어버리고, 단독으로 분리해야 "조작률"이 낮출 수 있는 KPI가 된다.
9. 검증 클로즈드 루프 = 회귀셋(프로덕션 투입 전) + Trace 모니터링(프로덕션 운영 중) + Bad Case 반영(프로덕션 투입 후) — 이 세 구간을 합쳐야 "구현 가능"이며, 어느 하나가 빠지면 개념적 답변이다. 이 구간을 능동적으로 보충할 수 있으면 "어떻게 하는지 안다"에서 "해봤다"로 올라간다.

#엔지니어링 실전 Tips

• 지표마다 "기준 카드"를 만들 것: 필드명, 시간 범위 정의, 중복 제거 규칙, 테스트 계정 포함 여부, 계산식. 기준이 없는 지표는 일률적으로 주보에 올리지 않는다.
• 항등식을 사람의 눈이 아니라 어서션으로 만들 것: 총계 = 항목의 합, 주기 완전성, 전기 대비 분모가 0이 아님 — 이런 검사를 계산층에 써넣고 실패하면 발행을 차단할 것.
• 다운그레이드 전략을 미리 설계할 것: 데이터가 결손일 때의 올바른 행위는 "결손 표기 / 되묻기"이지 모델이 그럴듯해 보이는 숫자를 스스로 채우는 것이 아니다. 시스템에는 "이 부분은 데이터가 없음"이라는 합법적 출력 형태가 있어야 한다.
• Structured Outputs + Function Calling은 선택이 아니라 표준 장비다: 이것들이 "모델의 자유 발휘"를 "모델이 구조를 채우기 / 도구를 호출하기"로 수렴시키며, 3층 아키텍처가 API 계층에 적용되는 지점이다.
• 숫자 정확률, 기준 일관성, 조작률 세 지표를 독립적으로 채점할 것: "주보 품질 점수" 하나로 합성하지 말 것. 그러면 문체가 좋을 때 숫자 오류가 점수에 묻혀 올라간다.
• Trace로 숫자를 역추적할 수 있어야 한다: 프로덕션 투입 후 "각 숫자가 어느 쿼리에서 왔는지"를 기록해, 사용자가 기준을 되물으면 그 자리에서 설명할 수 있어야 한다. 이것이 기업 리포트가 사용 가능해지는 문턱이다.
• 답변 순서 제안: 먼저 원인 규명을 교정(환각이 아니라 사실 사슬을 묻는 것) → 3층 아키텍처 → 3단 워크플로 → 평가 지표 → 검증 클로즈드 루프를 능동적으로 보충.