AI 판단 신뢰 구축: 환각 방지와 판단 재구성의 구조

자율 보안 에이전트에 권한을 넓혀줄 수 있는 상한선은 모델의 지능이 아니라 두 가지 능력에 의해 결정됩니다. 잘못된 판단을 내리지 않는 능력, 그리고 오판이 발생했을 때 그 과정을 명확히 되짚는 능력입니다. 이번 편에서는 엘리스가 환각을 프롬프트가 아닌 시스템 구조로 막기 위해 구축한 4개의 방어 계층과 모든 판단을 사후에 재구성하는 계측 구조를 설명합니다.

1. 신뢰가 자율성의 상한을 결정한다

일반적인 챗봇의 환각은 틀린 답변으로 끝나지만 보안 운영에서의 환각은 실제 조치로 이어집니다. 관측되지 않은 공격 시나리오가 보고서에 실리고, 존재하지 않는 호스트가 격리 대상에 오르며, 근거 없는 위협 증가 추세가 경영진에 보고될 수 있습니다. 반대 방향의 부작용도 있습니다. 부정확한 근거를 한 번이라도 확인한 담당자는 이후 모든 자동 보고를 사람 손으로 다시 검증하게 됩니다. 자동화로 확보한 시간이 재검증에 고스란히 소모되는 셈입니다. 이 때문에 엘리스는 자율화의 상한선을 모델의 지능이 아니라 '환각 통제력'이 결정한다고 정의했습니다.

하지만 방어 계층을 갖추더라도 예상과 다른 판단은 언제든 발생할 수 있습니다. 그때 필요한 질문은 세 가지입니다. 무엇을 보았는가, 어떤 도구를 호출했는가, 왜 그 결론에 이르렀는가. 인간에게는 이 질문을 직접 던질 수 있지만, 에이전트에게는 그럴 수 없습니다. 판단 시점의 컨텍스트가 실행 종료와 함께 사라지기 때문입니다.

보안 영역에서는 이 차이가 특히 큽니다. 차단과 격리 같은 조치는 업무에 직접적인 영향을 주고, 감사와 컴플라이언스의 대상이기 때문입니다. "AI가 그렇게 판단했다"는 설명만으로는 감사 요구를 충족할 수 없습니다. 결국 자율성을 넓히려면 두 가지가 함께 갖춰져야 합니다. 오류를 사전에 줄이는 예방과 불가피한 오류를 사후에 재구성하는 추적입니다.

2. 설계 원칙: 프롬프트가 아니라 구조로 막는 접근

환각을 금지한다는 지시만으로는 환각을 막을 수 없습니다. LLM은 확률에 따라 가장 그럴듯한 출력을 생성하므로, 지시 여부와 상관없이 일정 비율로 사실과 다른 내용을 만들어냅니다. 엘리스가 택한 접근은 심층 방어(Defense-in-Depth)입니다. 입력, 생성, 출력, 판단의 네 지점에 각각 독립된 방어 계층을 두고, 한 계층이 놓친 오류를 다음 계층에서 잡아내도록 설계했습니다.

1. 입력 그라운딩 : 환각할 재료를 주지 않습니다.
2. 생성 규칙 : 생성해도 되는 항목과 안 되는 항목을 규칙으로 강제합니다.
3. 기계 검증 : 담당자가 확인하기 전에 기계가 원본 데이터와 대조합니다.
4. 교차 검증 : 중요한 판단은 단일 AI에 의존하지 않습니다.

네 계층은 오류 빈도를 크게 낮추지만 0으로 만들지는 못합니다. 이에 따라 다섯 번째 장치로 관측 계층을 두었습니다. 이는 부가 기능이 아니라 자율 운영을 위한 전제 조건입니다. “4. 추적: 판단 한 건의 전체 여정”부터 그 구조를 설명합니다.

3. 예방: 환각을 막는 4개의 계층

계층 1. 입력: 환각할 재료의 차단

③편에서 설명했듯이, 에이전트에게는 벤더별 원시 로그 대신 정규화·집계된 근거만 전달합니다. 원문 수천 줄을 그대로 넘기면 모델이 빈 부분을 자의적 추정으로 채우려 합니다. 반면 해당 기간 동안 로그 클래스의 소스 IP별 집계표를 전달하면 추정으로 메울 여지가 크게 줄어듭니다.

여기에 자산 컨텍스트를 함께 주입합니다. 대상 서버의 OS, 역할, 노출 포트를 미리 전달해 리눅스 서버에 윈도우 전용 공격 가설을 세우는 유형의 오류를 입력 단계에서 걸러냅니다. 아울러 모든 에이전트의 샘플링 온도(Temperature)를 0으로 고정했습니다. 보안 판단에서는 출력의 다양성보다 일관성이 훨씬 중요하기 때문입니다.
-> 에이전트가 근거를 전달하는 방식 알아보기

사례 1) 컨텍스트 결핍이 만든 환각
도입 초기에 오케스트레이터가 하위 에이전트를 호출하면서 조사 상태 정보의 일부만 전달한 적이 있습니다. 인텔 에이전트는 부족한 맥락을 추정으로 메운 보고서를 생성했습니다. 문장 구성은 매끄러웠지만 내용에 실체적 근거가 없었습니다. 원인은 모델이 아니라 컨텍스트 전달 구조에 있었습니다. 조사 전체 맥락을 온전히 주입하도록 수정하자 같은 모델이 전혀 다른 품질의 보고서를 내놓았습니다. 환각의 상당 부분은 모델 자체의 결함이 아니라 시스템의 정보 결핍에서 발생합니다. 다만 그 원인을 찾아낸 것은 사람의 짐작이 아니었습니다. 4절에서 설명할 트레이스를 열어 어느 단계에서 정보가 누락되었는지 확인한 결과였습니다.

계층 2. 생성: 환각 억제 규칙 다섯 가지

그라운딩을 적용하더라도 생성 단계에서의 명시적 규칙은 반드시 필요합니다. 엘리스는 전체 에이전트의 시스템 프롬프트에 다음 다섯 규칙을 공통 정책으로 강제합니다.

규칙 2번의 효과
다섯 규칙 중 가장 효과가 컸던 항목은 2번입니다. 근거가 없을 때 '해당 없음'으로 답해도 된다고 명시하기 전까지, 에이전트는 어떻게든 보고서를 채우는 방향으로 출력을 생성했습니다. 알지 못한다고 답할 수 있는 경로를 열어주는 것만으로 보고 정확도가 크게 향상되었습니다. 사람 조직과 마찬가지로, AI 에이전트의 정직한 보고 역시 이를 허용하는 설계에서 나옵니다.

계층 3. 출력: 사람 확인 전 기계 대조

생성이 끝난 보고서는 담당자에게 곧바로 전달되지 않습니다. 그 사이에 '그라운딩 검증기'를 두었습니다. 보고서가 인용한 모든 IP, 호스트명, 식별자를 실제 조회 데이터와 기계적으로 1:1 대조합니다. 원본에 존재하지 않는 식별자가 하나라도 발견되면 해당 보고서는 즉시 폐기됩니다.

재작성 요청 대신 폐기를 택한 이유는 분명합니다. 수정을 요구하면 기존 추정 위에 또 다른 추정이 덧붙여지기 때문입니다. 실제로 레드팀 에이전트의 공격 체인 보고서가 이 게이트에서 반려된 사례가 여러 차례 있었습니다. 공격 자체는 성공했지만 보고서의 근거 인용이 부정확했기에 시스템이 보고서 발행을 차단한 것입니다. 보고 건수는 다소 줄어들지만, 남은 보고서의 신뢰도는 확실히 올라갑니다.

같은 지점에 오탐 사전 검증 게이트도 함께 동작합니다. 보고 직전 해당 트래픽이 이미 방화벽에서 차단되었는지를 별도 에이전트가 확인하여, 이미 차단 완료된 공격에 대한 중복 알림을 걸러냅니다. 이 두 게이트를 도입한 뒤 반복적으로 유입되던 오탐성 보고가 눈에 띄게 줄었습니다.

계층 4. 판단: 단일 AI 의존의 배제

고위험 판단, 즉 특정 이벤트가 실제 공격인지, 해당 IP를 차단 대상으로 올릴 것인지에 대한 결정은 마지막 계층을 거칩니다. 서로 다른 관점을 가진 복수의 검증 에이전트가 동일 사안을 독립적으로 심리하며, 여기에 의도적으로 반대 논리를 펴는 악마의 변호인(Devil's Advocate)이 참여합니다.

*악마의 변호인: 의도적으로 반론을 담당하는 역할

• 만장일치인 경우: 검증 완료로 분류하여 다음 대응 단계로 넘깁니다.
• 불일치인 경우: 교착으로 분류하고, 임의로 자동 종결하지 않은 채 사람 검토 대상으로 남겨둡니다.

핵심은 불일치를 실패로 보지 않는다는 점입니다. 검증 에이전트 간 의견이 엇갈렸다는 사실 자체가 바로 사람이 직접 확인해야 할 사건이라는 명확한 신호이기 때문입니다. 처음 관측된 유형의 이벤트는 기본적으로 이 경로를 거치도록 설계했습니다.

4. 추적: 판단 한 건의 전체 여정

엘리스는 오픈소스 LLM 트레이싱 도구인 랭퓨즈(Langfuse)를 온프레미스로 호스팅하여 20여 개 에이전트를 정밀 계측했습니다. 도입 방식은 간단합니다. 각 에이전트 함수 상단에 데코레이터 한 줄을 추가하는 것으로 계측이 시작됩니다.

*랭퓨즈: LLM의 추론 과정과 도구 호출을 기록 및 조회하는 도구

# 데코레이터 한 줄로 에이전트 실행 전체가 트레이스로 기록됨
from langfuse.decorators import observe

@observe()
def run_triage_agent(alert, asset_context):
    evidence = query_siem(alert)           # 도구 호출도 하위 span으로 기록
    verdict  = llm_judge(alert, evidence)  # 프롬프트·응답·토큰 사용량 기록
    return verdict

이렇게 하면 SIEM 알림 유입부터 최종 보고서 생성까지의 전체 여정이 하나의 통합 트레이스로 묶입니다. 트리아지가 무엇을 분류했고, 헌터가 어떤 쿼리로 로그를 받아 가설을 세웠으며, 검증기가 어떤 근거로 통과시켰는지가 타임라인에 남습니다. 예상과 다른 보고서가 나오더라도 해당 트레이스를 열어 어느 단계에서 판단이 어긋났는지 몇 분 안에 파악할 수 있습니다. 앞서 소개한 사례 1에서 컨텍스트 전달 결함을 특정할 수 있었던 것 역시 이 기록 덕분이었습니다. 계측이 없었다면 동일한 문제를 단순 모델 품질 문제로 오진했을 것입니다.

트레이스와 감사 로그의 역할 구분

트레이싱과 별도로 감사 저장소(Audit Store)를 분리해 둡니다. 둘의 역할은 명확히 다릅니다.

사람의 결재가 개입하는 HITL(Human-In-The-Loop) 게이트에서는 '누가 승인했는가'뿐만 아니라 '무엇을 근거로 승인했는가'까지 감사 로그에 결합되어 남습니다. AI가 제안하고 사람이 승인하는 체계는 그 승인 기록을 사후에 완벽히 재구성할 수 있을 때 비로소 신뢰를 얻습니다.

5. 계측의 산출물로서의 지표

이전 아티클에서 언급한 운영 수치인 자율 처리율(약 82%)과 판단 정확도(약 90%)는 별도의 수작업 측정 프로젝트가 아니라, 실시간 계측 데이터에서 자동으로 산출됩니다.
-> 자율 처리율과 판단 정확도 더 알아보기

• 자율 처리율 : 전체 사이클 중 사람 개입 없이 완결된 비율입니다. 트레이스의 종료 상태에서 계산합니다.
• 판단 정확도 : 사람이 사후 검토한 표본에서 에이전트 판정과 사람 판정이 일치한 비율입니다.
• 에이전트 활용도 : 최근 24시간 동안 실제로 호출된 에이전트와 그 빈도입니다. 동작하지 않는 에이전트를 찾아냅니다.
• 토큰·GPU 비용 : 에이전트별 토큰 소모량과 GPU 사용 시간입니다. 판단 한 건당 투입된 연산 비용을 산출합니다.

이 지표들은 대시보드에 상시 투명하게 노출됩니다. 핵심은 이 지표들이 자동화 범위를 어디까지 넓힐지 결정하는 객관적 근거가 된다는 점입니다. 자율 처리율과 정확도가 함께 안정되어 있으면 HITL 승인 게이트를 한 단계 뒤로 물리고, 정확도에 흔들림이 생기면 게이트를 다시 앞으로 당깁니다. “1. 신뢰가 자율성의 상한을 결정한다”에서 언급한 자율성의 상한을 실제로 조절하는 제어기가 바로 이 계측 데이터입니다. 계측이 없다면 조절을 뒷받침할 근거도 확보할 수 없습니다.

사례 2) 계측 사각지대가 만든 유휴 오판
활용도 지표에서 일부 에이전트가 며칠째 유휴 상태로 표시된 적이 있습니다. 정리 대상인지 확인해 보니 해당 에이전트들은 정상 동작 중이었습니다. 오케스트레이터를 거치지 않는 직접 호출 경로가 감사 로그에 기록되지 않았을 뿐이었습니다. 계측 경로를 보완하자 유휴로 보였던 에이전트 대부분이 활성으로 재분류되었습니다. 측정 경로가 빠진 지표는 관리 공백이 아니라 오판을 만들기 때문에 지표를 신뢰하기 전에 지표의 수집 경로를 먼저 검증해야 합니다.

6. 관측의 마지막 단계인 승인 화면

트레이스와 지표가 아무리 정확해도, 담당자가 마주하는 승인 카드가 불투명하면 실효성을 잃게 됩니다. 계층 4에서 교착으로 분류된 고난도 사건 역시 결국 이 화면으로 모입니다. 이에 따라 엘리스는 사람에게 노출되는 화면 인터페이스에도 엄격한 '정직성 원칙'을 강제합니다.

• 실측 수치만 표기: 카드의 건수와 비율은 실제 DB 조회 결과에 기반해야 하며, 추정치는 반드시 '추정'임을 명시합니다.
• 미구현 항목의 명확한 구분: 아직 모의 단계인 조치가 실제 집행처럼 보이지 않게 합니다.
• 구체적 대상 명시: "다수 호스트에서 이상 행위"와 같은 모호한 서술 대신, 대상 호스트명과 정확한 대수를 표기합니다.
• 직관적인 용어 사용: 승인자가 카드를 이해하지 못하면 승인은 형식적 절차로 머무릅니다.

그 결과 승인 카드에는 판단 요약, 구체적 근거 데이터와 함께 전체 트레이스로 연결되는 링크가 나란히 제공됩니다. 근거가 투명할수록 사람의 승인 속도는 빨라집니다. 엘리스가 실전에서 확인한 HITL의 중요한 특성입니다. 사람의 개입 지점을 정밀하게 설계할수록 운영자가 소모하는 시간은 오히려 줄어듭니다.

7. 운영에서 확인한 사항

• 환각 대책의 순서는 데이터, 규칙, 검증, 합의입니다. 많은 팀이 프롬프트부터 시작하지만, 투자 대비 효과는 데이터 계층에서 가장 컸습니다.
• 기본 차단은 비용이 들지만 유효합니다. 검증에서 걸러진 보고서는 살리지 않고 폐기하며, 다음 사이클에서 다시 조사합니다.
• 해당 없음도 유효한 결과입니다. 빈 보고서를 결함으로 취급하지 않을 때 보고의 정확도가 올라갑니다.
• 검증 에이전트 간 불일치는 결함이 아니라 설계된 동작입니다. 교차 검증의 목적은 만장일치가 아니라, 사람이 개입할 지점을 정확히 찾는 것입니다.
• 환각으로 보이는 현상의 상당수는 시스템의 정보 결핍입니다. 계측이 없으면 그 구분을 하지 못하고 모델 탓으로 끝납니다.
• 지표를 믿기 전에 지표의 수집 경로를 먼저 검증해야 합니다. 측정되지 않은 경로는 공백이 아니라 오판으로 나타납니다.

신뢰는 선언이 아니라 재구성 가능성에서 나옵니다. “우리 AI는 믿을 만합니다”라는 설명보다, “어떤 판단이든 그 근거와 과정을 5분 안에 다시 보여드릴 수 있습니다”가 자율 보안 체계의 신뢰 근거입니다.

다음 편에서는 이렇게 확보한 신뢰를 실제 운영 변경으로 옮기는 방법, 즉 AI가 작성한 탐지 규칙을 초안·카나리·승격 파이프라인으로 배포하는 구조를 설명하며 시리즈를 마칠 예정입니다.