16.7.2 Level 2: 기본 단위 테스트(Unit Testing) 및 규칙 기반 정적 필터링 도입 단계

조직이 Level 1의 주먹구구식 수동 테스트(Manual Testing)에서 유발된 운영 환경의 구문 파싱(Parsing) 에러와 치명적인 데이터 오염 위기를 뼈저리게 겪고 난 후, 부채질하듯 가장 먼저 시스템에 도입하는 방어선이 바로 **Level 2(정적 기반 확립 단계, Static-based Phase)**이다.
이 단계에서 드디어 MLOps 엔지니어링 링 안에 들어온 AI 모델의 응답 텍스트에 대한 1차적인 품질 검증 책임을, 지치고 피곤한 인간 기획자의 ‘눈대중(Eyeballing)’ 검수에서 분리하여 어느 정도 예측 가능한 **‘결정론적인 코드 스크립트(Deterministic Code Script)’**의 영역으로 이양하기 시작한다.

Level 2의 성숙도는 우리가 앞서 설계한 본격적인 하이브리드 오라클 아키텍처(5계층) 파이프라인 중에서도, 하위 3개 계층(정적 프롬프트 매개변수 통제, 강제 구조화 출력 레이어, 그리고 기본적인 언어 규칙 기반 필터링)에 대한 체계적이고 시스템적인 접근이 CI/CD 환경에서 막 싹트는 시기를 의미한다.

1. 프롬프트의 코드화(Codification)와 컴파일 수준의 강제 구조화(Structured Outputs) 제어

Level 2에 도달한 개발팀은, 더 이상 백엔드 소스 코드 프롬프트 끝자락에 구차하게 *“제발 JSON 포맷으로만 깔끔하게 답해줘”*라고 애원하는 낭만적이고 안일한 주술적 텍스트 명령어(Zero-shot Prompting)를 신뢰하여 사용하지 않는다. 백엔드 엔지니어는 언어 모델 API와 통신하는 I/O(Input/Output) 통로와 데이터 스펙 자체를 파이썬의 타입 힌트(Type Hint)와 코드로 완벽하게 규격화해버린다.

• [스키마의 클래스화(Class-based Schema)]:
  Python의 Pydantic 데이터 클래스나 TypeScript 생태계의 Zod와 같은 강력한 스키마 구조화 정의 도구를 사용하여, 목적 함수 모델이 최종적으로 반환해야 할 데이터의 물리적 형태(예: Product(name: str, price: int, category: Enum))를 매우 엄격하고 빈틈없는 강타입(Strong Type) 클래스로 선언한다.
• [API 레벨의 생성 제약(Generation Constraint)]:
  이렇게 파이썬으로 렌더링 된 스키마를 OpenAI의 함수 호출(Function Calling/Tool Use) 페이로드나 JSON Mode 파라미터(response_format)로 API 통신망에 무겁게 주입하여, LLM API의 토큰 확률 엔진이 애초에 이 규격을 단 1바이트라도 벗어나는 텍스트를 디코딩 생성하는 것 자체를 컴파일 레벨에서 차단(Layer 2)시킨다.
• [통제된 파이프라인 예외 처리(Exception Handling)]:
  이러한 철통 방어망에도 불구하고 0.01%의 확률로 파싱 오류(ValidationError)가 런타임에서 발생하더라도, 과거처럼 모델 탓을 하며 프롬프트를 튜닝(Prompt Engineering)하며 시간을 허비하지 않는다. 대신 정석적인 백엔드 try-except 블록을 통하여 즉각적으로 재시도(Retry) 루프를 돌리거나 기본값(Default Fallback)을 반환하는, 시스템 수준에서의 완벽하게 통제된 예외 처리(Exception Handling)가 비로소 가능해진다.

2. 정적 룰셋(Static Ruleset)과 CI 단위 테스트(Unit Testing) 환경의 도래

눈을 부릅뜬 수동적이고 시각적인 웹 콘솔 챗봇 검증 행위 대신, 전통적 소프트웨어 엔지니어링 로직의 가장 위대하고 고전적인 도구인 ‘단위 테스트(Unit Test)’ 환경 스크립트가 AI 파이프라인 브랜치(Branch) PR(Pull Request) 검증 단계에 최초로 결합된다.

• 사내 데이터베이스를 긁어 모아 가장 치명적이었던 에지 케이스(Edge Case)와 네거티브 테스트 시나리오를 포함한 수백 건 규모의 소규모 골든 테스트 데이터셋(Golden Dataset)을 로컬에 구성하고, PyTest 등의 성숙한 테스트 프레임워크 훅(Hook)을 통해 신규 LLM 프롬프트 함수의 응답을 CI 환경에서 매일 밤 기계적으로 자동 평가(Nightly Batch)한다.
• 이때 오라클 평가의 채점 기준은 인간의 뉘앙스나 의미론적인 복잡한 문맥 해석 파악이 아니라, 철저하게 컴파일이 가능한 규칙 기반(Rule-based)의 차가운 정적 분석(Layer 3) 로직을 따른다. 예를 들면 다음과 같은 확고한 단언(Assertion) 스크립트 문들이 불안정한 AI를 감시하는 오라클 재판관의 자리를 대신한다.
• 키워드 적중률 검증: assert "이체 수수료" in llm_response.text (특정 필수 키워드의 기계적 존재 유무 확인)
• 길이 및 페이로드 제한: assert len(llm_response.extracted_items) <= 5 (응답 리스트 배열 길이의 물리적 상한선 제한)
• 금칙어/블랙리스트 차단: assert not contains_banned_profanity(llm_response.text) (Aho-Corasick 정규식 트리를 활용한 철저한 혐오/욕설 금칙어 필터링 방어선 통과 여부)

3. Level 2가 부딪히는 거대한 절벽: ‘형식주의(Formalism)의 함정’

이 Level 2 스텝에 도달한 MLOps 파이프라인 조직은, 과거 주니어 개발자들을 밤새워 괴롭히던 “어처구니없는 JSON 파싱 트레이스백 에러“와 “단순한 UI 글자 수 초과 범람 에러“를 거의 제로(0)에 가깝게 획기적으로 줄이는 데 대성공한다. 이제 백엔드 서버 인스턴스는 더 이상 LLM의 멍청한 구문 오류 때문에 메모리 릭(Memory Leak)으로 다운되지 않으며, 시스템 안정성 지표(SLA)는 단발적으로 큰 폭으로 수직 상승한다.

하지만 축배를 터뜨리기도 전에, Level 2 조직은 곧이어 해결하기 더 까다로운 **‘가짜 양성(False Positive)의 지독한 함정’**에 치명적으로 빠지게 된다.
오라클이 요구한 Pydantic 스키마의 껍데기 포맷팅 검사를 완벽하게 통과했고, 등록된 비속어나 블랙리스트 키워드는 단 하나도 없어서 PyTest 로그는 모두 초록불(Green)을 띄웠지만, 정작 사용자가 질문한 본질적인 비즈니스 로직 내용 자체가 완전히 반대로 틀렸거나, 질문의 의도(Intent)와 완전히 다른 산으로 가버린 끔찍한 자연어 서술형 환각(Descriptive Hallucination)은 이러한 1차원적인 코드 레벨의 문자열 필터링 뜰채 망을 비웃기라도 하듯 너무나 유유히 통과해 라이브 앱으로 배포(Production)되어 버리는 것이다.

이처럼 *“문법의 형식(Form)은 기계처럼 완벽하지만, 속에 담긴 데이터 통찰력은 새빨간 거짓말”*을 뻔뻔하게 하는 소시오패스 같은 모델을 통제하고 제압하기 위해, 조직은 텍스트의 얄팍한 껍데기 형태(Form)의 정규식 검증을 완전히 뛰어넘어, 문맥과 팩트의 깊은 진실인 의미(Semantics)의 검증을 다룰 수 있는 **차세대 지능형 오라클(LLM 판사, LLM-as-a-Judge)**의 도입, 즉 MLOps 성숙도 Level 3(동적 의미 검증)와 Level 4(메타 오라클 진화) 프로세스로의 아키텍처적 도약을 필연적으로 강제 받게 되는 분수령에 서게 된다.