3.7.1 과적합(Overfitting) 유발: 테스트 데이터가 프롬프트에 유출(Leakage)되는 경우

결정론적 정답지(Deterministic Ground Truth)를 구축하고 자율 테스트 파이프라인을 돌리는 조직에서 흔하게 발생하는 치명적인 안티 패턴(Anti-Pattern)은 바로 ‘데이터 유출(Data Leakage)에 의한 과적합(Overfitting)’ 현상이다.

전통적인 머신러닝의 학습(Training) 과정에서 모델이 평가용 데이터(Test Set)를 미리 보게 되면 성능이 부풀려지는 것과 마찬가지로, AI 엔지니어링에서는 개발자가 프롬프트(Prompt)를 깎는 과정에서 오라클(Oracle)이 검증해야 할 정답지의 특이점들을 프롬프트에 무의식적으로 하드코딩(Hard-coding)하는 우를 범하게 된다.

1. 프롬프트 과적합의 발생 기전

개발자는 오라클이 실패(Fail) 알럿을 띄울 때마다, LLM이 정답을 맞히도록 시스템 프롬프트를 수정한다. 이 과정이 통제 없이 반복되면 프롬프트는 기형적으로 변질된다.

• 발생 시나리오: 특정 고객의 배송 지연 클레임을 분류하는 테스트 케이스 “송장 번호 123-456이 아직 안 왔어요“에 대해 LLM이 ’단순 문의’로 오분류를 냈다. 정답지는 ’배송 불만’이다.
• 안티 패턴 프롬프트: 개발자는 프롬프트에 "만약 사용자가 '송장 번호 123-456'을 언급하면 무조건 '배송 불만'으로 분류해라"라는 규칙을 욱여넣는다.
• 결과: 오라클은 테스트 스위트에서 녹색불(Pass)을 띄우지만, 이 시스템은 해당 송장 번호 이외의 다른 배송 클레임을 전혀 처리하지 못하는 과적합 상태에 돌입하게 된다.

이러한 현상은 사실상 오라클의 정답지(Ground Truth)가 프롬프트의 컨텍스트(Context)로 유출된 것이며, 이는 “AI가 추론을 잘하는가“를 평가하는 테스트가 아니라 “AI가 개발자가 주입한 If-Else 문을 잘 암기했는가“를 확인하는 무의미한 절차로 전락한다.

2. 블라인드 테스트 셋(Blind Test Set)의 분리

이러한 유출을 소프트웨어 공학적으로 원천 차단하기 위해, 오라클의 골든 데이터셋(Golden Dataset)은 반드시 두 가지 이상의 논리적/물리적 계층으로 분리되어야 한다.

1. 개발용 정답지 (Dev-set / Prompting-set): 개발자가 프롬프트 엔지니어링이나 RAG 문서 튜닝을 할 때 성능을 참고하고 최적화하기 위해 공개된 데이터셋이다. 이 데이터셋에서 100%의 통과율을 보여도 시스템의 최종 신뢰성은 보장되지 않는다.
2. 보류된 결함 검증용 정답지 (Hold-out Test-set / Blind-set): CI/CD 파이프라인의 핵심 관문에서만 비밀스럽게(Hidden) 동작하는 데이터셋이다. 개발자는 이 데이터의 입력과 출력(Ground Truth)을 직접 열람할 수 없으며, 오직 오라클 파이프라인만이 난독화된 상태로 이 데이터를 돌려 **전체적인 통과율(Pass Rate)과 메트릭스(Metrics)**만을 개발자에게 반환한다.

3. 선언적 체계 강제에 의한 방어

프롬프트가 정답 데이터를 흡수해 버리는 유출 현상을 억제하기 위해서는, 예제 중심의 퓨샷 러닝(Few-Shot Learning) 시 특정 도메인의 식별자(ID, 고유명사) 대신 추상화된 변수를 사용하도록 규칙을 강제해야 한다.

• 프롬프트에 예제를 줄 때 “Alice의 계좌”, “상품 번호 A-123“과 같이 실제 정답지에 있을 법한 구체적인 명사를 투입하면 모델의 편향성이 급증한다.
• 대신, [USER_ID_A], [PRODUCT_REF]와 같은 익명화/추상화 기법을 사용하여, 모델이 ’단어의 형태’를 암기하는 것이 아니라 ‘비즈니스 로직의 구조(Structure)’ 자체에 집중하여 학습(In-context Learning)하도록 유도해야 한다.

기억해야 할 절대적인 명제는, “프롬프트가 테스트 데이터를 대변해서는 안 된다“는 것이다. 결정론적 오라클은 AI 시스템이 **‘학습된 규칙’**에 따라 응답하는지, 아니면 ‘암기된 정답’ 앵무새처럼 내뱉는지를 잔인하게 구별해내는 최후의 방어선이어야 한다.