1. 발단 — AI가 「639건」이라고 썼다. 실제로는 0건이었다 #

이전에 우리의 로컬 LLM이 자동 생성한 모니터링 리포트에 「인증 실패 639건」이라고 쓴 적이 있습니다. 실제로 로그를 확인하니, 그 시간대의 인증 실패는 0건이었습니다. LLM이 그럴듯한 숫자를 그대로 만들어낸 것입니다(이 전말은 「로컬 LLM이 모니터링 리포트의 수치를 조작한 사례와 그 대책」에 적었습니다).

이것은 LLM의 결함이 아니라 성질입니다. LLM은 「문맥적으로 그럴듯한 문장」을 생성하는 데 능하며, 「사실로서 정확한 숫자」를 보장하는 구조는 애초에 가지고 있지 않습니다. 평소에는 올바른 숫자를 쓰기도 하지만, 그것은 「정확성이 보장되어 있는」 것이 아니라 「우연히 맞은」 것뿐입니다.

AI Ops에서 이것은 간과할 수 없습니다. 믿을 수 없는 모니터링 리포트는 없는 것과 같거나, 오히려 위험합니다. 「인증 실패 639건」을 믿고 누군가 대응에 나서면, 존재하지 않는 문제에 시간을 씁니다. 반대로, 진짜 이상이 묻힐지도 모릅니다.

그래서 우리는 「LLM이 쓴 숫자를 그대로 믿지 않는」 구조 ―― 할루시네이션 감사 ―― 를 도입했습니다. 본 기사는 그 구현의 사고방식입니다.

2. 원칙 — 「사실」은 LLM이 만들지 않는다. 로그가 만든다 #

감사의 출발점은 역할의 분리입니다.

모니터링 리포트에 나오는 숫자·건수·IP 주소·시각 같은 「사실」은, LLM의 문장 생성이 아니라, 실제 장비 로그에 대한 결정론적 쿼리에서 취득합니다. LLM의 역할은, 확정된 사실을 사람이 읽기 쉬운 문장으로 정리하는 것으로 한정합니다.

• 사실(숫자·대상·시각) → 로그에 대한 쿼리가 만든다 (ground truth)
• 내러티브(요약·설명·문장) → LLM이 만든다

이 분리만으로도 조작이 끼어들 여지는 크게 줄어듭니다. LLM에게 「로그를 읽고 건수를 세어」라고 부탁하면 세는 오류(=조작)가 일어나지만, 건수를 먼저 집계해 확정값을 넘기고, LLM에게는 「이 숫자를 사용해 상황을 설명해」라고 부탁하면, 숫자는 더 이상 움직이지 않습니다.

3. 그래도 남는 조작을 「감사」로 잡아낸다 #

역할을 분리해도, LLM이 문장을 쓰는 과정에서 넘기지 않은 숫자를 멋대로 보태거나, 대상을 잘못 잡는 일은 있습니다. 그래서 LLM이 생성한 리포트를, 출력 후에 다시 한 번 원본 로그와 대조하는 감사 단계를 둡니다.

대략의 흐름은 이렇습니다.

1. 로그를 집계해 「확정된 사실」을 만든다          <- ground truth
2. LLM에 확정값을 넘겨 리포트 문장을 생성시킨다
3. 생성된 리포트에서 정량적 주장을 추출한다
   (예: 「호스트 A에서 인증 실패가 N건」)
4. 각 주장을, 원본 로그(1의 확정 사실)와 대조한다
5. 뒷받침 없는 주장·모순되는 주장을 검출하면,
   확정값으로 치환 or 리포트를 재생성한다
6. 검출한 불일치는 기록한다(언제·어디서·무엇을 조작했는가)

포인트가 두 가지 있습니다.

대조는 결정론적으로 한다. 대조를 다른 LLM에게 시키지 않습니다. 할루시네이션을, 할루시네이션할 수 있는 것으로 감사해도 의미가 없습니다. 대조는, 원본 로그라는 움직이지 않는 사실에 대한, 기계적인 체크입니다.

「주장」을 검증 단위로 한다. 자유 문장 속에서 나중에 숫자를 줍기보다, LLM의 출력을 처음부터 검증하기 쉬운 구조(「대상·지표·값」의 조합)로 받는 편이, 대조가 견고해집니다. 문장의 형식이 아니라, 주장 하나하나가 ground truth에 뒷받침되는지를 봅니다.

대조 모습의 이미지(값은 설명용):

[AUDIT] report_id=████
  claim: host=A  metric=auth_fail  value=639
  truth: host=A  metric=auth_fail  value=0
  => MISMATCH  (확정값으로 치환 or 재생성)

  claim: host=B  metric=port_scan  value=47
  truth: host=B  metric=port_scan  value=47
  => OK

4. 이것은 「LLM을 똑똑하게 만드는」 이야기가 아니다 #

여기가 설계 사상으로서 중요한 부분입니다. 할루시네이션 감사는, LLM을 더 똑똑하게·더 정확하게 만들려는 접근이 아닙니다. 「LLM은 틀리는 것」이라는 전제를 바꾸지 않은 채, 출력을 구성상(by construction) 신뢰할 수 있는 것으로 만드는 접근입니다.

LLM이 틀린 숫자를 써도, 감사에서 ground truth와 대조되므로, 최종적으로 나오는 리포트의 숫자는 담보됩니다. LLM의 똑똑함에 신뢰를 맡기는 것이 아니라, 검증의 구조에 맡깁니다.

5. 설계상의 트레이드오프(솔직하게) #

만능은 아닙니다.

1. 비용이 증가한다. 집계·생성·감사로 패스가 늘어납니다. 다만 프로덕션 모니터링 리포트에서 「믿을 수 있다는 것」의 가치는, 이 비용에 걸맞다고 판단하고 있습니다.
2. 잡을 수 있는 것은 「사실·정량」의 조작. 「인증 실패 건수」 같은 검증 가능한 주장은 대조할 수 있지만, 「이 경향은 위험해 보인다」 같은 주관적인 내러티브의 타당성까지는 기계 대조하기 어렵습니다. 그렇기에, LLM의 역할을 요약·정형으로 한정하고, 판단은 시키지 않는 설계로 하고 있습니다.
3. ground truth가 올바르다는 전제. 감사는 「원본 로그가 사실」이라는 전제에 섭니다. 로그 수집이나 장비 판정 그 자체의 정확성이 토대가 됩니다(수집·자동 판정의 구조는 별도 기사에서 다룹니다).

6. BASTION의 뿌리와 같은 원칙 #

이 「LLM이 쓴 숫자를 믿지 않는다」는 자세는, BASTION 전체의 설계와 이어져 있습니다.

공격 IP의 최종 판정이나, 방화벽으로의 차단 실행 같은, 시스템을 실제로 움직이는 판단은, LLM이 아니라 실제 장비 로그에 기반한 결정론적 판정으로 하고 있습니다(다층 상관 캠페인 탐지의 구조). LLM이 잘하는 것은 자연어의 요약이나 정형이지, 프로덕션의 의사결정이 아니다 ―― 이 선 긋기는, 「아름다운 설계일수록, 실데이터로 의심한다」에서 적은 검증 규율 그 자체입니다.

할루시네이션 감사는, 그 같은 원칙을 리포트 계층에 적용한 것입니다. LLM도, (침해될 수 있는) Agent도, 우리에게는 「신용하지 않고, 검증하는」 대상입니다.

7. 정리 #

AI에게 맡기는 범위가 넓어질수록, 「AI의 출력을 어떻게 검증할 것인가」가, 제품의 신뢰를 결정합니다.

• 사실(숫자)은 LLM에게 만들게 하지 않고, 로그에서 취한다
• LLM이 쓴 주장은, 출력 후에 ground truth와 대조한다
• 대조는 결정론적으로. 할루시네이션을 할루시네이션으로 감사하지 않는다
• LLM의 역할은 요약·정형으로 한정하고, 판단은 시키지 않는다

LLM이 쓴 숫자를, 곧이곧대로 믿지 않는다. 수수하지만, 프로덕션에서 AI Ops를 안심하고 돌리기 위한 토대입니다.