모든 자동화된 시스템은 세상의 특정한 형태를 전달받습니다.

그 형태는 기록, 문서, 이벤트, 예외, 그리고 결측치 (missing values)를 통해 표현됩니다. 만약 설계자들이 이러한 형태들—그리고 그것들이 어떻게 잘못된 형태 (malformed)가 될 수 있는지—를 식별하지 못했다면, 기계는 그들의 무지를 물려받아 대규모로 재현하게 됩니다.

문제는 단순히 AI가 실패했는지 여부가 아닙니다.

유용한 질문은 인간이 구축한 시스템이 성공이 무엇을 의미하는지 알고 있었는지, 데이터의 형태를 알고 있었는지, 그리고 자신이 틀렸을 때 이를 어떻게 인식할 수 있는지를 알고 있었는지입니다.

데이터의 형태부터 시작하라

모델을 선택하기 전에, 워크플로 (workflow)를 데이터 변환 (data transformations)의 시퀀스로 그리십시오.

• 각 단계에 무엇이 들어오는가?
• 어떤 형태이며 어떤 소스 (source)로부터 오는가?
• 어떤 값들이 유효하고, 부재하며, 중복되거나, 오래되었거나, 지연되거나, 혹은 모순되는가?
• 각 위반 사항을 어떻게 탐지할 것인가?
• 워크플로는 다음에 무엇을 해야 하는가?

각 데이터 형태에는 그에 상응하는 실패 모델 (failure model)이 필요합니다. 여기서 발생하는 '알 수 없음'은 단순히 기계에게 있어 불확실성이 아니라, 조직 차원에서의 측정 실패입니다.

해결책은 누락된 데이터를 수집하거나, 데이터의 부재를 명시적으로 설계에 반영하는 것입니다. 그렇지 않으면 시스템은 설계자들이 기술하지 않은 세상 속에서 작동하도록 요구받는 셈입니다.

결과물(Deliverable)을 안정화하라

시스템은 계속해서 움직이는 목표를 바탕으로는 안정화될 수 없습니다.

결과물은 프롬프트 (prompt)에 작성된 열망 그 이상이어야 합니다. 이는 관찰 가능한 조건으로 표현되어야 하며, 대표적인 코퍼스 (corpus)에 고정되어야 합니다:

• 수용 가능한 예시들;
• 수용 불가능한 예시들;
• 진정으로 모호한 예시들.

인간 검토자들은 먼저 이러한 구분을 일관되게 적용할 수 있음을 증명해야 합니다. 만약 그들이 성공이 어떤 모습인지에 대해 합의할 수 없다면, 모델은 명세 (specification)를 기준으로 측정되는 것이 아닙니다. 그것은 명세로 위장된 인간의 불일치를 기준으로 측정되고 있는 것입니다.

모델이 곧 시스템은 아니다

그제서야 비로소 워크플로 안에 AI 모델을 배치하는 것이 의미를 갖게 됩니다.

모델은 수많은 변환 과정 중 하나일 뿐입니다:

입력 (Input)
  → 검증 (validation)
  → 검색 (retrieval)
...

각 전이(transition) 단계에서 의미가 소실되거나 오류가 유입될 수 있습니다. 최종 응답의 유창함 때문에 모델이 가장 눈에 띄는 용의자로 지목되곤 하지만, 눈에 잘 띈다는 것이 곧 인과관계를 의미하지는 않습니다.

지능적으로 책임을 할당하려면, 전체 체인(chain)을 관찰하고 정보가 수신되거나 변환되는 모든 경계(boundary)를 테스트해야 합니다.

변이 테스트 (Mutation testing)는 신뢰성 그 자체를 공격한다

전통적인 테스트는 소프트웨어가 작성자가 예상한 조건 하에서 성공하는지를 묻습니다. 변이 테스트 (Mutation testing)는 그 압박의 방향을 뒤집습니다.

이 방식은 조건 반전, 경계 이동, 값 대체, 또는 연산 제거와 같은 작은 결함들을 의도적으로 도입한 뒤, 테스트 스위트 (test suite)가 이를 감지하는지 확인합니다.

• 사멸된 변이 (killed mutant): 최소 하나 이상의 테스트를 실패하게 만든 경우
• 생존한 변이 (surviving mutant): 테스트의 이의 제기 없이 프로그램을 변경한 경우

결과로 도출된 점수는 정확성의 증거가 아닙니다. 이는 생성된 변경 사항에 대해 테스트가 얼마나 민감하게 반응하는지를 측정하는 것입니다.

함께 제공된 구현 예제에서, 집중적인 안전 계약 (safety-contract) 실행 결과는 다음과 같았습니다:

observed mutation sensitivity = 43 generated / 43 killed = 1.0

이 수치가 의미를 갖는 이유는 측정 경계가 명확하기 때문입니다. 즉, 이 실행은 워크플로의 수락 조건 (acceptance predicates)을 포함하는 작은 커널 (kernel)을 점수화합니다. 프롬프트의 구두점이나 CLI 문구가 안전 계약의 일부인 것처럼 가장하지 않습니다.

첫 번째 변이 실행이 중요했던 이유
패키지 전체에 걸쳐 수행된 첫 번째 광범위한 실행에서는 374개의 변이가 생성되었습니다. 그중 185개가 생존했습니다. 많은 변이가 프롬프트 텍스트, 추적 (trace) 문구, 그리고 테스트가 명시적으로 규정하지 않은 게이트웨이 배관 (gateway plumbing) 등을 변경했습니다.

이는 숨겨야 할 부끄러운 결과가 아니었습니다. 오히려 인도물 (deliverable)에 대한 정의가 불안정하다는 것을 드러내 주었습니다. 이후 변이 경계는 안전에 직결된 계약 (safety-critical contract)으로 좁혀졌고, 정확한 수락 경계 (acceptance boundaries)를 중심으로 테스트가 강화되었습니다. 따라서 이 실험은 본 기사의 논지를 재현합니다. 즉, 지표는 인간이 무엇을 측정할 것인지 정의한 후에야 비로소 의미를 갖게 된다는 것입니다.

AI 워크플로우 전반에 걸쳐 동일한 압박을 가하기

변이 원칙 (mutation principle)은 소스 코드에만 국한되어서는 안 됩니다.

예상된 필드를 제거하십시오. 형식을 손상시키십시오. 오래되었거나 모순되는 소스 자료를 제공하십시오. 검색 (retrieval)을 방해하십시오. 지시 사항 (instruction)을 교란하십시오. 유창하지만 부정확한 모델 응답으로 대체하십시오.

모든 경계 지점에서, 주변 시스템이 이러한 교란을 감지하는지, 기권하는지, 폴백 (fallback)하는지, 또는 해당 사례를 인간에게 전달 (route)하는지 확인하십시오.

참조 구현체 (reference implementation)는 이 흐름을 명시적으로 보여줍니다:

shape_failures = shape_agent.inspect(request)
if shape_failures:
    return escalate(shape_failures)
...

실제 구현에는 의도적으로 작게 설계된 네 가지 에이전트가 사용됩니다:

1. shape agent: 잘못된 형식의 입력이나 모델링되지 않은 입력을 거부합니다.
2. evidence agent: 일치하는 코퍼스 (corpus)를 검색하고 모순을 감지합니다.
3. model agent: OpenRouter를 통해 구조화되고 인용된 결정을 제안합니다.
4. critic agent: 인용문, 신뢰도 임계값 (confidence thresholds), 그리고 계산 가능한 정책 오라클 (policy oracle)을 기준으로 결정을 검증합니다.

모델은 유용하지만, 스스로의 성공 기준을 정의하는 것은 결코 허용되지 않습니다.

실행 가능한 실험을 통해 발견한 것

검증된 로컬 검증 결과는 다음과 같습니다:

• 80개의 테스트 통과
• 안전 계약 커널 (safety-contract kernel)에서 43개의 변이 중 43개 모두 제거 (killed)
• 하나의 깨끗한 대조군 (control) 수락
• 주입된 7개의 데이터, 코퍼스 및 모델 결함 모두 감지
• 잘못된 입력이나 모순된 증거로 인해 추론 (inference)이 안전하지 않을 때 모델 호출 0회

Hypothesis는 데이터와 워크플로우 변이 시퀀스를 모두 생성합니다. Mutmut은 안전 계약 소스를 변경합니다. OpenRouter는 엄격한 JSON Schema 응답을 사용하여 선택적인 라이브 모델 경계를 제공합니다.

OpenRouter 호출은 외부 서비스를 사용하며 비용이 발생할 수 있기 때문에 의도적으로 선택 사항(optional)으로 두었습니다. 결정론적 안전 오라클(deterministic safety oracle)은 네트워크 접속, 특정 제공자(provider), 또는 유리한 모델 응답에 의존하지 않습니다.

계산식(computational expression)을 실행하고 그 가정을 검증하십시오

언제 진정으로 AI의 실패라고 할 수 있는가?

이러한 규율이 적용된 후에야 비로소 _AI 실패 (AI failure)_라는 문구가 유용한 의미를 갖게 됩니다.

만약 입력값이 잘 형성되었고, 결과물(deliverable)이 안정적이었으며, 지원 구성 요소들이 올바르게 작동했음에도 불구하고 모델이 알려진 요구사항을 위반했다면, 그때는 모델이 설정된 조건 내에서 실패한 것입니다.

하지만 데이터가 누락되었거나, 대상(target)이 논쟁의 여지가 있거나, 검색(retrieval)이 결함이 있었거나, 혹은 안전 장치(safeguards)가 오류를 인식하지 못했다면, 모델은 단지 이전의 실패가 가시화된 지점에 불과할 수 있습니다. 이를 AI의 실패라고 부르는 것은 시스템을 개선하지 못합니다. 오히려 조직이 학습할 수 있는 피드백 과정을 방해할 뿐입니다.

생성 모델(generative model)은 학습된 유사성(learned resemblance)의 엔진입니다. 모델은 놀라울 정도로 이해하는 것처럼 보이는 동작을 생성할 수 있지만, 유사성이 책임을 질 수는 없습니다. 목표를 선택하고, 허용 가능한 증거를 정의하며, 전이(transitions)를 설계하고, 불확실성이 시스템에 유입될 때 어떤 일이 일어날지를 결정하는 것은 사람입니다.

AI가 실패했다고 선언하기 전에, 시스템이 성공이 무엇을 의미하는지 알고 있었는지, 자신의 세계의 형태를 알고 있었는지, 그리고 자신이 틀렸을 때를 어떻게 인식해야 하는지 알고 있었음을 증명하십시오.

만약 그렇지 않았다면, 실패는 모델이 응답하기 훨씬 전부터 시작된 것입니다.

전체 실험에는 에이전트 위브(agent weave), 속성 기반 테스트(property-based tests), 상태 기반 테스트(stateful tests), 변이 구성(mutation configuration), 결정론적 결함 주입 CLI(deterministic fault-injection CLI), 검증 기록(verification record), 그리고 선택적인 OpenRouter 게이트웨이가 포함됩니다.