4.4.3. "모른다면 모른다고 답하라"는 지시문의 구체적 변형과 아키텍처적 효과

4.4.3. “모른다면 모른다고 답하라“는 지시문의 구체적 변형과 아키텍처적 효과

모든 활성화된 상용 LLM(거대 언어 모델)은 학습 데이터셋에 내재된 인터넷의 방대한 패턴을 바탕으로, 멈추지 않고 다음 토큰을 끊임없이 예측하여 내뱉는 거대한 확률적 앵무새(Stochastic Parrot)이자 멈출 줄 모르는 텍스트 생성기계다. 이들은 태생적으로 **‘침묵’**을 모른다.

프롬프트로 엄격하게 주어진 컨텍스트(Context) 내에 정답이 전혀 없더라도, 모델은 자신의 파라미터 뇌피셜 내부에 파편적으로 저장된 선행 지식(Prior Knowledge)을 무단으로 동원하거나, 심지어 특정 토큰들을 기괴하게 조합하여 완전히 새로운 가짜 사실을 그럴듯하게 지어내서라도 기어코 빈칸을 채우고 답을 완수하려는 가장 강력하고 치명적인 본능(즉, 할루시네이션, Hallucination)을 뼛속 깊이 가지고 있다.

결정론적이고 냉혹한 오라클(Oracle) 파이프라인 방어막을 설계하는 백엔드 소프트웨어 엔지니어에게, 모델이 환각으로 지어낸 가짜 합격 판정(False Positive) 데이터는 아예 틀려먹은 오답(True Negative)보다 구조적으로 백배 천배는 더 치명적이고 데이터베이스를 오염시키는 맹독이다.
이를 시스템적으로 제어하기 위한 프롬프트 엔지니어링의 가장 오래되고 유명한 관용구가 바로 *“모른다면 제발 모른다고 답하라(If you don’t know the answer, just say you don’t know)”*이다. 하지만 0.1%의 오차도 허용하지 않는 현대의 MLOps 결정론적 시스템에서는, 이 순진하고 단순한 자연어 문구조차 고도화된 프로그래밍 인터페이스 규격으로 잔인하게 변형되고 강제되어야만 한다.

1. 순수한 자연어 지시문의 모호성과 런타임 실패

단순히 시스템 프롬프트 첫 줄에 *“제공된 정보가 없으면 모른다고 하세요”*라고 젠틀하게 적어둔 파이프라인은, 실제 QA 프로덕션 테스트 환경에서 절반 이상의 확률로 무참하게 실패한다. LLM은 이 정중한 지시를 받아들일 때조차 끝까지 ’친절한 인간의 대화 방식’을 모방하여 사족을 붙이려 하기 때문이다.

  • [런타임 파싱 실패 사례 1 (사족의 발생)]: “주어진 문서에는 해당 고객의 환불 정보가 직접적으로 명시되어 있지 않아 제가 정확히 알 수는 없습니다만, 앞선 전체적인 맥락으로 보아 아마도 환불이…”
  • [런타임 파싱 실패 사례 2 (포맷 파괴)]: “알 수 없음.” 혹은 “I don’t know.” (파이썬 Pydantic 파서가 컴파일 수준에서 기대하는 엄격한 ENUM 값이나 Boolean 포맷이 절대 아님)

이러한 인간적인 모호성과 수다스러움은, 텍스트를 기계적으로 잘라먹는 자동화 파이프라인의 JSON 파싱(Parsing) 에러를 즉각 일으키거나, 테스트 러너(Test Runner) 코드가 정규표현식(Regex)으로 실패 사유를 깔끔하게 분류하여 로깅하는 것을 아예 불가능하게 만든다.

2. 상태 코드(Status Code) 및 예외 상수(Exception Constant)로의 치환

결정론적 오라클을 구축하기 위해서는 “나는 모른다“는 인간의 유약한 감정 상태를, HTTP 상태 코드(404 Not Found)나 프로그래밍 언어의 런타임 예외 함수 반환값(Return Value Exception)과 같은 가장 건조하고 물리적인 프로그래밍 스펙으로 강제 치환해 버려야 한다.

  • [배타적 단일 탈출구(Exclusive Exit Rule) 프롬프트 설계]: 
    주어진 데이터를 냉철하게 평가하여, 반드시 아래의 두 가지 상태 중 '단 하나'만 반환하라.
규칙 1: 정보가 명확히 존재하고 평가 기준을 통과하면 "PASS" 텍스트만 리턴.
규칙 2: 주어진 컨텍스트 내에서 평가를 내릴 수 있는 근거 토큰을 100% 확신할 수 없다면, 너의 내부 사전 지식을 꺼내어 임의로 유추하거나 타협하지 마라. 즉시 모든 생성 엔진 스위치를 중단하고, 정확히 `[ERROR: UNKNOWN_CONTEXT_EXCEPTION]` 이라는 상수 문자열 텍스트만 출력하고 세션을 종료하라. 사족이나 다른 어떤 문자도 1바이트라도 붙여서는 안 된다.


이 기법은 언어 모델 내부의 로짓(Logit) 확률 스케일 스페이스에 보이지 않는 강력한 '지리적 경계(Boundary)'를 강제로 생성한다. 모델이 디코딩 과정에서 정답 확률(Confidence Score)을 확신하지 못하는 위험한 중간 지대(Twilight Zone)에 스스로 도달했을 때, 애매하고 비굴한 단어를 수다스럽게 이어 붙이는 본능을 억제하고, 사전에 안전하게 하드코딩된 `[ERROR: UNKNOWN_CONTEXT_EXCEPTION]`이라는 단일하고 거대한 탈출 경로(Escape Route)로 모든 확률 에너지를 쏟아붓고 자폭하도록 기계적으로 유도하는 것이다.

## 3.  제3의 상태(Unknown)가 시스템에 부여하는 강력한 오라클 안전망


CI/CD 테스트 스위트(Test Suite) 파이프라인 관점에서 볼 때, 오직 '성공(Pass)'과 '실패(Fail)' 두 가지만 잔인하게 존재하는 이진(Binary) 오라클은 매우 위험하고 부서지기 쉽다.
모델이 컨텍스트가 턱없이 부족하여 논리적으로 판단할 수 없는 억울한 상황을, 파서가 억지로 그냥 '실패(False)' 통계로 욱여넣어 버리면, 남은 테스트 결과 전체의 지표 신뢰도(Confidence)가 논리적으로 송두리째 무너진다.

시스템 프롬프트 설계에 명시적으로 주입된 **제3의 상태(Unknown, 모름)**는 현대 소프트웨어 엔지니어링의 `Null`, `None`, 혹은 러스트(Rust) 언어의 `Option::None` / `Result::Err` 값 전파 처리와 완전히 동일한 위대한 아키텍처 역할을 수행한다.
이는 모델이 스스로 섣부른 평가를 보류(Suspend)하고, 복잡한 비즈니스 판단의 책임을 상위 미들웨어 레이어(혹은 인간 디버거 모니터 요원)에게 안전하게 위임(Delegate)하여 책임을 떠넘기는 가장 견고하고 안전한 방파제다. "모른다면 제발 모른다고 답하라"는 소박한 자연어 철학은 이처럼 C++이나 Java 수준의 최고로 엄격한 상태 코드 기반의 **예외 처리(Exception Handling) 스키마**로 완벽하게 번역될 때, 비로소 엔터프라이즈 환경에서 진정한 폭발적인 위력을 발휘한다.