7.7.2. 2단계: 키워드 포함 여부 및 금칙어 검사를 통한 필수 조건 검증

1단계의 기초적인 마크다운 포맷팅 구문(Syntax) 생존 테스트를 무사히 통과한 언어 모델의 텍스트 데이터는, 이제 2단계 1차선 필터인 **‘어휘적(Lexical) 결정론 판별기’**로 강제 진입한다.
이 단계의 아키텍처 핵심 목적은 텐서 연산을 동원하여 문맥을 이해하는 비용 낭비 없이, 모델의 응답 텍스트 내에 비즈니스 로직상 무조건 존재해야만 하는 **‘필수 키워드(Must-Have)’**가 누락되었거나, 반대로 절대로 기업 파이프라인 외부에 발화되어서는 안 되는 치명적인 **‘금칙어(Blocklist)’**가 단 한 토큰이라도 포함되었는지를 기계적으로 차갑게 스캐닝(Scanning)하여 걸러내는 것이다.

이 과정 역시 GPU의 복잡한 부동소수점 임베딩 유사도 연산을 전혀 거치지 않고, 컴퓨터 공학에서 가장 저렴하고 빠른 ’단순 문자열 매칭(String Matching)’이라는 초고속 O(N) 컴퓨팅 연산만으로 CPU 단에서 구현된다. 따라서 3단계에 위치한 값비싼 통계적 LLM 판사(LLM-as-a-Judge) 모듈이 처리해야 할 트래픽 토큰 낭비와 연산 지연(Latency)을 사전에 차단하는 훌륭하고 거대한 두 번째 백엔드 방파제 역할을 충실히 수행한다.

1. 정답 앵커(Answer Anchor) 검증 체계의 절대성

특정한 금융 도메인 질의응답(QA)이나 핵심 정보 추출(Information Extraction) MLOps 생태계에서는, 생성된 응답 텍스트 전체의 길이가 얼마나 길고 문체의 수사여구가 얼마나 유려하게 사람 같은지 따위보다, 무조건 문장 내에 등장해야만 하는 **핵심 고유 명사나 절대적인 수치 데이터 포인트(Answer Anchor)**의 물리적 존재 여부가 비즈니스적으로 수천 배 더 중요하다.

예를 들어, *“당사 엔터프라이즈 B2B 클라우드의 프리티어 기본 스토리지 제공 용량은 얼마인가?”*라는 사용자 질문에 대응하는 생성 타겟 모델의 응답에는 AI가 어떤 친절하고 장황한 수사여구를 문장 앞뒤로 갖다 붙이든 간에, 메모리 어딘가에 15GB 혹은 15 Gigabytes라는 명확한 상수 앵커 키워드가 반드시 1회 이상 포함되어야만 참(True)으로 인정받을 수 있다.

하이브리드 오라클(Hybrid Oracle) 평가 엔진은 사내 정답 데이터베이스(Ground Truth DB) 마스터 테이블에 매핑된 이 앵커 문자열 목록을, 타겟 모델이 생성한 역직렬화 텍스트에 대해 부분 문자열 검색(Substring Search)이나 정규표현식(Regex)으로 밀리초 단위로 빠르게 스캔한다.
만약 해당 앵커 텍스트가 단 한 번도 검출되지 않는다면, 그 텍스트 응답이 아무리 완벽하고 유창한 문법과 설득력 있는 문장을 지녔다 하더라도 사내 정책을 거짓으로 왜곡한 치명적인 환각(Critical Hallucination)이거나, 질문 의도를 완전히 무시한 도메인 이탈(Off-topic) 반항일 확률이 100%다. 이 결함 케이스는 3단계 LLM 판사의 귀중한 연산 추론력을 낭비할 가치조차 없으므로, 오라클 엔진은 해당 ト랜잭션을 즉각 ‘신뢰성 파괴(Fail)’ 상태로 판정하고 폐기(Reject) 처리해 버린다.

2. 기업 방화벽 계층: 금칙어(Blocklist) 및 PII 토큰 원천 차단

핵심 앵커 검사가 비즈니스 ’포함의 의무 지표’를 다진다면, 금칙어 검사 모듈은 **‘노출에 대한 철저한 금지선’**을 강제하는 기업의 마지막 소프트웨어 생명 방화벽(Application Firewall)이다. 엔터프라이즈 환경에 배포되어 대고객 서비스를 수행하는 AI 모델은 트랜잭션 도중 특정 경쟁사 제품 브랜드에 대한 찬양, 혐오 발언(Hate Speech), 비속어, 또는 백엔드 시스템 콘솔의 날것을 그대로 유저 브라우저에 노출해 버리는 특정 에러 토큰(예: undefined, null, Error 500 내부 에러, 백엔드 DB 구조 리버싱을 암시하는 UNION SELECT)들을 내뱉는 것을 철저하고 폭력적으로 통제받아야 한다.

가장 중요하게는 글로벌 컴플라이언스(GDPR, HIPAA 등)를 위해 주민등록번호, 계좌 비밀번호 등 개인 식별 민감 정보(PII) 패턴을 절대적으로 색인하여 차단해야 한다.
이 결정론적 필터링 계층은 수만 개의 금전적, 윤리적, 보안적 금칙어가 빽빽하게 등록된 사내 데이터 딕셔너리 트리를 메모리에 올리고, 아호-코라식(Aho-Corasick) 알고리즘처럼 수천 개의 복수 블랙리스트 패턴을 단 한 번의 스트리밍 순회(O(N) Time Complexity)로 동시에 찾아내는 고도화된 고성능 텍스트 검색 트리를 통해 작동한다. 단 1바이트의 금칙 문자열 패턴이라도 매치되는 즉시, 해당 타겟 모델의 오염된 응답 스트림은 비즈니스 로직과 보안 헌법을 심각하게 위배한 ’방사능 오염 데이터’로 간주되어, 영구 격리(Quarantine) 처리되고 관제 대시보드 최고 관리자에게 긴급 알람(Alert)을 쏘아 올린다.

3. 렉시컬(Lexical) 문자열 필터링의 본질적 한계와 3단계 LLM 오라클 계승

이처럼 저렴하고 빠른 서버 성능을 자랑하는 파괴적인 2단계 어휘적 룰 매칭(Lexical Rule Matching) 필터링은, 컴퓨터 공학적으로 완벽해 보이지만 안타깝게도 자연어 텍스트가 가진 근본적인 **‘기표(Signifier)와 기의(Signified)의 무한한 파편화 현상’**이라는 거대한 통계적 벽에 부딪힌다.

정산 시스템의 정답 앵커 단어가 비밀번호인데 생성 모델이 자체 추론을 거쳐 문자열 패스워드나 로그인 암호 문자라고 유의어(Synonyms)를 영리하게 내뱉었다면, 멍청한 코드 기반의 렉시컬 매칭 오라클은 이를 억울한 오답(False Negative)으로 무참히 쳐내 버릴 것이다. 반대로 악의적인 어태커(Attacker)가 금칙어인 해킹이라는 단순 단어를 피하기 위해 프롬프트 인젝션을 통해 시스템의 우회적인 관리자 접근 획득 시도라는 유려하고 고도화된 스피어피싱(Spear Phishing) 우회 문장을 구사했다면, 렉시컬 트리의 단순 검사기는 이를 전혀 의심하지 못하고 100% 정상 문장으로 무사통과(False Positive)시키는 보안 참사를 낳는다.

기계적인 하드코딩 문자열 매칭은 결국 인간 언어의 다채로운 행간 맥락(Context)을 이해하지 못한다는 수학적 결함을 영원히 고치지 못한다. 바로 이 지독한 시맨틱(Semantic) 영역에서의 교묘한 모호함을 분별해 내어 처단하기 위해, 앞선 두 번의 잔인한 결정론적 필터(문법 검사, 렉시컬 키워드 검사)를 통과하고 살아남은 ’최정예 1급 문자열 데이터’들만이, 비로소 마침내 진정한 의미론적 사령관이자 막대한 GPU 통계 연산을 소모하는 3단계 **LLM 심판관 전당(Hall of LLM Judges)**으로 최종 이관되어 심판을 받게 되는 것이다.