5.7.2 엣지 케이스(Edge Case) 및 코너 케이스(Corner Case) 발굴 전략

AI 모델 테스트용 ’최소 기능 데이터셋(MFD)’을 구성할 때, 평범하고 명확한 문장(Happy Path)들로만 픽스처(Fixture)를 채우는 것은 결정론적 오라클의 방어력을 맹목적으로 과대평가하게 만든다. LLM이 마주하는 실제 프로덕션 환경은 오타, 문맥의 비약, 앞뒤가 맞지 않는 요구사항이 난무하는 혼돈의 장(Field of Chaos)이다.

따라서 오라클이 진짜 유효한 판관(Judge)이 되려면 비즈니스 로직의 경계를 교묘하게 넘나드는 **엣지 케이스(Edge Case)**와 두 가지 이상의 극단적 상황이 겹친 **코너 케이스(Corner Case)**를 체계적으로 발굴하여 골든 샘플에 주입해야 한다.

자연어 처리 기반의 AI 시스템을 위해 엣지 케이스를 발굴하는 전략은 정통 소프트웨어 공학과 유사하면서도 훨씬 더 다차원적이다.

1. 정통적 경계값 분석(Boundary Value Analysis)의 자연어적 해석

숫자로 명확히 떨어지는 도메인(예: 19세 이상 입장)에서는 18, 19, 20이라는 숫자를 테스트하면 되지만, 자연어에서는 이 경계가 ’의미론적(Semantic)’으로 형성된다.

• 시간과 날짜의 모호성 경계:
  비즈니스 정책상 “환불은 구매 후 7일 이내“일 때, 엣지 케이스 입력은 “저번 주 수요일 오전에 샀는데 환불해 줘” 혹은 “산 지 일주일쯤 된 것 같아“와 같이 명확한 Date 값을 주지 않고 모델의 암묵적 계산 능력을 시험하는 문장들이어야 한다.
• 다중 의도(Multi-intent) 충돌 경계:
  “이 제품 너무 좋네요. 근데 환불하고 싶어요.” (감성 분석에서는 ’긍정’으로 읽히지만 실제 비즈니스 의도는 ’불만/환불’인 경우)를 테스트하여, 파서가 텍스트의 감성이 아닌 명확한 인텐트를 분리해내는지 확인한다.

2. 생산망 로그 기반(Production Log Mining)의 코너 케이스 발굴

개발자의 상상력에는 한계가 있으므로, 코너 케이스 발굴의 가장 훌륭한 광산은 실제 유저들이 남긴 운영망의 로그(Logs) 데이터다. 데이터 파이프라인(예: ELK 스택, Datadog)을 구축하여 다음과 같은 쿼리(Query)를 통해 골든 샘플 후보군을 자동으로 필터링해야 한다.

• 재시도(Retry) 폭주 로그: 짧은 시간 안에 동일한 세션에서 모델 응답이 3번 이상 실패하거나 사용자가 질문을 5번 이상 고쳐 쓴 경우, 이는 모델과 오라클이 유저의 의도를 제대로 수용하지 못하는 맹점(Blind Spot)일 확률이 높다.
• 비정상적인 응답 길이: 모델이 평소에는 200자 내외로 답하다가 갑자기 2,000자의 응답을 내놓은 경우의 입력값은, 프롬프트의 길잃음(Lost in the middle)을 유발한 훌륭한 엣지 케이스다.

3. 적대적 변이(Adversarial Mutation) 기법 활용

발명된 엣지 케이스를 더욱 가혹한 코너 케이스로 몰아붙이기 위해, 기존에 확보된 정상 픽스처 데이터에 프로그래밍적인 돌연변이(Mutation)를 가하는 스크립트를 테스트 스위트 레벨에 장착할 수 있다.

1. 언어 혼용(Code-switching): “Can I get a 환불 for this item? Please 빨리요.” (단일 언어 파서의 붕괴 유도)
2. 구두점 무작위 삭제 및 오타 주입: RAG(Retrieval) 성능 및 의도 파악(Intent Classification) 모델이 텍스트의 형태가 아닌 문맥적 의미를 유지하는지 테스트한다.
3. 극단적 컨텍스트 조작: RAG 시스템 테스트 시, 모델에 주입되는 참고 문서(Context) 5개 중 4개를 전혀 관련 없는 ‘고양이 키우는 법’ 문서로 채운 뒤, 모델이 1개의 팩트 문서를 찾아 답을 낼 수 있는지 강제 노이즈 테스트를 수행한다.

오라클의 무결성은 그것이 통과시킨 엣지 케이스의 기괴함에 비례한다. 가장 예의 바른 입력부터 가장 악의적이고 혼란스러운 입력까지, 경계를 집요하게 공격하는 픽스처 데이터세트를 관리하는 것이야말로 진정한 테스트 주도 AI 개발(TDD for AI)의 선결 조건이다.