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

← 전체 목차 · 이전: LLM 애플리케이션에 왜 "출력 길이 예산"이 반드시 필요한가 · 다음: 같은 모델인데 대화는 멀쩡하고 Agent만 환각을 일으키는 이유는 무엇인가

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

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

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

#분업 원칙

데이터 도구 — 조회, 계산

모델 — 이해, 조직, 설명

#1. 필드 분해

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

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

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

#2. 도구 계산

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

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

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

#3. 답변 인용

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

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

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

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

#3층 아키텍처

#도구가 정확해도 최종 출력은 틀릴 수 있다: 환각은 조회 단계뿐 아니라 가공 단계에서도 생긴다

"공식 도구와 진짜 데이터 소스에 붙였으니 허위 정보는 없다"는 답은 절반만 맞다. 도구 진실 ≠ 출력 진실이다.

세 플랫폼 인터페이스가 반환한 원본 데이터  →  전부 정확  ✓
                ↓
Agent의 집계 / 비율 계산 / 결론 서술  →  모델이 자체 연산에서 오류  ✗
                ↓
                존재하지 않는 항목을 스스로 새로 만들어 추가  ✗
                ↓
        원본 데이터는 옳은데 최종 리포트는 통째로 틀림

이 실패는 취득권(도구가 쥔다)과 서술권(모델이 쥔다)의 경계가 이미 무너진 뒤에 일어난다는 점에서 앞서 다룬 "숫자를 지어낸다"와 뿌리는 같지만 발생 위치가 다르다 — 조회가 아니라 조회 이후의 가공이다. 인터페이스가 200을 반환하고 형식이 멀쩡해도, 총계가 틀리거나 비율이 뒤바뀌거나 순환불액이 주문액으로 둔갑하는 식의 오류에는 에러 로그가 남지 않는다. 발표 자리에서 사람이 숫자를 대조해야만 드러난다.

대응은 세 가지를 더 얹는 것이다.

1. 업무 분급: 재무 통계·재고 집계 같은 고위험 수치류는 모델의 자체 연산 권한을 원천 차단하고 계산을 도구 쪽으로 강제 이관한다. 정보 정리·문안 요약 같은 저위험 콘텐츠류만 모델의 자유 서술을 허용한다.
2. 자동 교차 검증 후 덮어쓰기: 핵심 수치마다 근거 계산식과 원본 데이터를 자동 추출해 전용 계산 도구로 재검증하고, 편차가 나오면 경보로 그치지 않고 도구 결과로 그대로 덮어써 수정한다. 사람이 개입해야 닫히는 루프는 프로덕션에서 작동하지 않는다.
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 반영(프로덕션 투입 후) — 이 세 구간을 합쳐야 "구현 가능"이며, 어느 하나가 빠지면 개념적 답변이다. 이 구간을 능동적으로 보충할 수 있으면 "어떻게 하는지 안다"에서 "해봤다"로 올라간다.
10. "진짜 도구에 붙였다"는 취득권의 답이지 서술권의 답이 아니다 — 취득 단계의 환각(사실을 몰라서 지어냄)과 가공 단계의 환각(사실을 알고도 집계·서술에서 틀림)은 서로 다른 고장이며, 전자를 막는 조치(공식 API 연결)는 후자에 아무 효과가 없다. 도구가 정확하다는 사실이 출력이 정확하다는 증거가 되지 못하는 이유가 여기 있다.
11. 가공 단계 환각은 무증상이라 더 위험하다 — 인터페이스는 200을 반환하고 형식은 멀쩡한데 숫자만 틀리므로 에러율·성공률 같은 시스템 지표에 전혀 잡히지 않는다. 사람이 숫자를 대조해야만 드러나며, 그래서 자동 교차 검증이 "있으면 좋은 것"이 아니라 "이 실패 유형을 잡는 유일한 수단"이다.

#엔지니어링 실전 Tips

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