AI 에이전트 (AI agents)는 일반적인 API 호출처럼 실패하는 경우가 드뭅니다. 이들은 토큰을 소모하고, 도구 (tools)를 사용하고, 잘못된 단계를 재시도하며, 실제보다 더 완벽해 보이는 답변을 생성한 뒤, 작업 중간에 실패합니다.

그것이 위험한 부분입니다.

일반적인 테스트는 "모든 것이 정상 작동할 때 이 워크플로우가 통과하는가?"라고 묻습니다. 카오스 테스팅 (Chaos testing)은 더 날카로운 질문을 던집니다: "모델이 혼란에 빠지고, 도구가 느려지며, MCP 서버가 잘못된 형식의 데이터를 반환하고, 그럼에도 사용자가 안전한 결과를 기대할 때는 어떤 일이 발생하는가?"

만약 당신이 에이전트, 도구 호출 (tool calls), RAG, 브라우저 자동화 (browser automation) 또는 다단계 워크플로우 (multi-step workflows)를 사용하여 AI 제품을 구축하고 있다면, 이것은 미래의 문제가 아닙니다. 이것은 훌륭한 데모와 사용자가 신뢰할 수 있는 시스템 사이를 잇는 프로덕션 신뢰성 (production reliability) 작업입니다.

AI 에이전트 카오스 테스팅이 중요한 이유

전통적인 소프트웨어는 명확한 실패 지점 (failure surfaces)을 가집니다. 데이터베이스가 타임아웃(timeout)되거나, API가 500 에러를 반환하거나, 큐 (queue)가 작업을 재시도합니다. 당신은 모킹 (mocks), 통합 테스트 (integration tests), 부하 테스트 (load tests)를 통해 이러한 경로를 테스트할 수 있습니다.

AI 에이전트 워크플로우는 더 복잡한 실패 모드 (failure modes)를 추가합니다:

• 모델이 잘못된 도구를 선택하지만 이를 자신 있게 설명합니다.
• 도구 응답에 무관하거나 적대적인 지침이 포함됩니다.
• 재시도 루프 (retry loop)가 진전 없이 사용자의 예산을 소모합니다.
• 브라우저 에이전트가 페이지 변경으로 인해 잘못된 버튼을 클릭합니다.
• RAG 파이프라인이 오래된 컨텍스트 (stale context)를 검색하고 에이전트가 이에 따라 행동합니다.
• MCP 서버가 계속 진행하기에 충분히 유효해 보이는 불완전한 데이터를 반환합니다.
• 장시간 실행되는 작업이 재시작 후 상태 (state)를 잃어버립니다.
• 폴백 모델 (fallback model)이 출력 형식을 변경합니다.

최근 업계의 신호들도 같은 방향을 가리키고 있습니다. AI 연구소들은 보안 평가 중에 모델이 테스트 가정을 벗어나는 사례를 보고했습니다. 에이전트 리플레이 (agent replay), 코딩 에이전트 사용 추적, MCP 테스팅과 관련된 제품 출시들은 개발자들이 더 이상 "에이전트가 작동할 수 있는가?"만을 묻지 않는다는 것을 보여줍니다. 그들은 "실제 시스템이 오작동할 때 에이전트가 복구될 수 있음을 증명할 수 있는가?"를 묻고 있습니다.

그것이 바로 AI 에이전트 카오스 테스팅이 채워주는 간극입니다.

AI 에이전트 카오스 테스팅 (AI agent chaos testing)은 에이전트 워크플로우 (workflows)에 통제된 실패를 주입한 다음, 시스템이 안전하고 (safe), 경계가 명확하며 (bounded), 복구 가능하고 (recoverable), 감사 가능 (auditable)한 상태를 유지하는지 측정하는 관행입니다.

목표는 에이전트를 완벽하게 만드는 것이 아닙니다. 목표는 실패를 지루하게 만드는 것입니다.

탐색의 간극: 과도한 에이전트 하이프, 부족한 실패 연습

대부분의 AI 에이전트 콘텐츠는 여전히 프레임워크 (frameworks), 프롬프트 (prompts), 모델 비교, 그리고 빠른 데모에 집중하고 있습니다. 이것들은 유용하지만, 빌더들이 출시 후에 직면하게 되는 질문, 즉 "무엇이 가장 먼저 고장 나는가?"라는 질문은 건너뜁니다.

에이전트 테스팅에 대해 상위 순위에 오르는 콘텐츠는 보통 다음 중 하나의 관점을 다룹니다:

• 일반적인 LLM 평가 (LLM evaluation)
• 벤치마크 점수 (benchmark scores)
• 프롬프트 테스팅 (prompt testing)
• RAG 품질 체크 (RAG quality checks)
• 모델 모니터링 (model monitoring)
• 보안 레드팀 활동 (security red teaming)
• 에이전트 프레임워크 튜토리얼 (agent framework tutorials)

누락된 실무 계층은 프로덕션 스타일의 에이전트 워크플로우를 위한 빌더 친화적인 카오스 테스팅 가이드입니다. 개발자들에게는 결함 주입 (fault injection), 재생 (replay), 복구 점수 산정 (recovery scoring), 도구 호출 회귀 테스트 (tool-call regression tests), 그리고 MCP 서버 실패 드릴 (MCP server failure drills)에 대한 예시가 필요합니다.

이 점이 AI 에이전트 카오스 테스팅을 강력한 롱테일 키워드 (long-tail keyword)로 만듭니다. 이는 구체적이고 개발자 중심적이며, AI 에이전트 (AI agents), LLM 평가 (LLM evaluation), 또는 AI 자동화 (AI automation)와 같은 광범위한 용어보다 경쟁이 적습니다.

무엇을 의도적으로 망가뜨려야 하는가?

사용자에게 피해를 주거나, 예산을 낭비하거나, 신뢰를 무너뜨릴 수 있는 워크플로우의 부분부터 시작하십시오.

1. 모델 동작 (Model behavior)

현실적인 모델의 실수를 시뮬레이션하는 실패를 주입하십시오:

• 잘못된 도구 선택 (wrong tool selection)
• 유효하지 않은 JSON (invalid JSON)
• 검증 단계 누락 (skipped verification step)
• 근거가 빈약한 과도하게 자신감 있는 답변 (overconfident answer with weak evidence)
• 승인이 필요한 안전하지 않은 계획 (unsafe plan that should require approval)
• 안전한 경로가 있음에도 거부함 (refusal when a safe path exists)
• 환각된 도구 결과 (hallucinated tool result)

모델이 악의적이도록 강제할 필요는 없습니다. 대부분의 실제 실패는 평범합니다: 모호함, 잘못된 컨텍스트 (context), 오래된 메모리 (stale memory), 누락된 상태 (missing state), 또는 모델이 과도하게 신뢰하는 도구 응답 등입니다.

2. 도구 호출 (Tool calls)

도구는 에이전트의 실패가 실제 행동으로 이어지는 지점입니다.

테스트 케이스에는 다음이 포함되어야 합니다:

• 타임아웃 (timeout)
• 속도 제한 (rate limit)
• 잘못된 형식의 응답 (malformed response)
• 부분적 성공 (partial success)
• 중복 실행 (duplicate execution)
• 권한 거부 (permission denied)
• 빈 결과 (empty result)
• 오래된 결과 (stale result)
• 예기치 않은 스키마 버전 (unexpected schema version)
• 텍스트 필드 내부의 숨겨진 지시문 (hidden instruction inside a text field)

예를 들어, 에이전트가 결제 API를 호출하는 경우, 카오스 테스팅 (Chaos testing)은 타임아웃이 중복 결제를 유발하지 않는지, 재시도 (retry)가 멱등성 (idempotency)을 건너뛰지 않는지, 그리고 혼란스러운 응답이 성공으로 처리되지 않는지를 검증해야 합니다.

3. MCP 서버 (MCP servers)

MCP는 도구 (tools)를 더 쉽게 연결할 수 있게 해주지만, 너무 광범위하게 노출되기도 더 쉽게 만듭니다. MCP에 대한 카오스 테스팅 (Chaos testing)은 다음을 포함해야 합니다:

• 서버 사용 불가 (server unavailable)
• 도구 목록 변경 (tool list changes)
• 도구 설명 변경 (tool description changes)
• 느린 stdio 응답 (slow stdio response)
• 스키마 불일치 (schema mismatch)
• 권한 강등 (permission downgrade)
• 도구 출력 내 프롬프트 인젝션 (prompt-injection) 텍스트
• 예기치 않은 파일 시스템 또는 네트워크 액세스 (unexpected filesystem or network access)

실질적인 MCP 카오스 테스트는 다음과 같이 질문합니다: 만약 이 서버가 실패한다면, 에이전트는 안전하게 중단하는가, 폴백 (fallback)을 선택하는가, 아니면 진행 상황을 허구로 만들어내는가?

4. 검색 및 컨텍스트 (Retrieval and context)

RAG 및 메모리 (memory) 실패는 종종 "좋은 답변"처럼 보입니다. 이 때문에 이를 포착하기가 더 어렵습니다.

다음 항목들로 검색 (retrieval)을 망가뜨려 보세요:

• 오래된 청크 (outdated chunks)
• 상충하는 소스 (conflicting sources)
• 누락된 테넌트 필터 (missing tenant filters)
• 낮은 유사도의 상위 결과 (low-similarity top results)
• 중복 문서 (duplicate documents)
• 오염된 문서 (poisoned documents)
• 매우 긴 컨텍스트 패킷 (very long context packets)
• 인용 메타데이터가 없는 소스 (source without citation metadata)

그 다음, 컨텍스트가 취약할 때 에이전트가 증거를 인용하는지, 명확한 설명을 요구하는지, 아니면 행동을 거부하는지를 점수화하십시오.

5. 워크플로우 상태 (Workflow state)

장시간 실행되는 에이전트에는 내구성이 있는 상태 (durable state)가 필요합니다. 다음 상황에서 어떤 일이 발생하는지 테스트하십시오:

• 작업 중간에 프로세스가 재시작될 때
• 큐 (queue)가 이미 완료된 단계를 재시도할 때
• 승인이 만료될 때
• 실행 중간에 사용자가 목표를 변경할 때
• 이후 단계가 시작된 후 하위 작업 (subtask)이 실패할 때
• 다른 모델로 작업이 재개될 때
• 에이전트가 오래된 메모리 항목을 수신할 때

만약 에이전트가 안전하게 재개할 수 없다면, 그것은 가치 높은 업무를 수행할 준비가 되지 않은 것입니다.

간단한 카오스 테스팅 아키텍처 (A Simple Chaos Testing Architecture)

시작하기 위해 거대한 플랫폼이 필요하지는 않습니다. 작은 팀이라도 다섯 가지 부분으로 구성된 유용한 하네스 (harness)를 구축할 수 있습니다.

1. 시나리오 파일 (Scenario files)

시나리오는 워크플로우 (workflow), 허용된 도구 (tools), 예상되는 증거 (expected evidence), 그리고 주입된 결함 (injected failures)을 기술합니다.

id: invoice_followup_timeout
workflow: invoice_followup_agent
tenant: demo_tenant
...

시나리오를 읽기 쉽게 유지하십시오. 만약 단 한 명의 엔지니어만이 해당 테스트를 이해한다면, 그 테스트는 부패할 것입니다.

2. 결함 주입기 (Fault injector)

결함 주입기 (fault injector)는 에이전트 (agent)와 도구 (tools) 사이에 위치합니다. 이는 도구의 응답을 지연시키거나 (delay), 손상시키거나 (corrupt), 차단하거나 (block), 또는 교체할 (replace) 수 있습니다.

type Fault =
  | { type: "timeout"; afterMs: number }
  | { type: "rate_limit"; retryAfterMs: number }
...

이 패턴은 도구가 REST 엔드포인트 (endpoints), SDK 함수 (functions), MCP 도구 (tools), 큐 (queues), 또는 브라우저 동작 (browser actions)인지 여부와 관계없이 작동합니다.

3. 트레이스 기록기 (Trace recorder)

모든 카오스 실행 (chaos run)은 트레이스 (trace)를 생성해야 합니다:

• 사용자 목표 (user goal)
• 프롬프트 버전 (prompt version)
• 모델 및 설정 (model and settings)
• 검색된 컨텍스트 ID (retrieved context IDs)
• 도구 호출 및 응답 (tool calls and responses)
• 주입된 결함 (injected faults)
• 재시도 (retries)
• 승인 (approvals)
• 최종 답변 (final answer)
• 비용 및 지연 시간 (cost and latency)
• 통과/실패 증거 (pass/fail evidence)

로그 (logs)에만 의존하지 마십시오. 로그는 디버깅 (debugging)을 위한 것입니다. 트레이스 (traces)는 재생 (replay)을 위한 것입니다.

4. 복구 점수 산정기 (Recovery scorer)

카오스 테스트는 단순히 "작업이 완료되었는가?"라고 물어서는 안 됩니다. "시스템이 올바르게 복구되었는가?"라고 물어야 합니다.

다섯 가지 차원에서 복구 (recovery)를 점수화하십시오:

워크플로우 (workflow)가 원래의 작업에는 실패하더라도, 안전하게 실패한다면 카오스 테스트는 통과할 수 있습니다.

5. 회귀 컴파일러 (Regression compiler)

카오스 실행이 실제 버그를 발견하면, 해당 트레이스 (trace)를 결정론적 회귀 테스트 (deterministic regression test)로 전환하십시오.

import { runAgentScenario } from "./harness";

it("does not send follow-up email when invoice lookup times out", async () => {
...

이 지점이 카오스 테스팅 (chaos testing)이 매일매일 유용해지는 단계입니다. 당신은 단순히 무서운 데모를 수집하는 것이 아닙니다. 조용히 다시 나타날 수 없는 실패 사례들의 성장하는 라이브러리를 구축하고 있는 것입니다.

일반적인 AI 워크플로우를 위한 실질적인 카오스 테스트

고객 지원 에이전트 (Customer support agent)

결함 발생 (Break):

• 계정 기록 누락 (missing account record)
• 상충하는 정책 문서 (conflicting policy documents)
• 화난 사용자 메시지 (angry user message)
• 도구(tool)가 다른 고객의 기록을 반환
• 환불 API 타임아웃 (refund API times out)

기대 동작 (Expected behavior):

• 개인 데이터 노출 금지
• 정책 출처 인용
• 환불 전 상담원 검토 요청
• 깔끔한 에스컬레이션(escalation) 노트 생성

데이터 분석 에이전트 (Data analyst agent)

결함 발생 (Break):

• SQL 타임아웃 (SQL timeout)
• 빈 데이터셋 (empty dataset)
• 행 수준 보안 거부 (row-level security denial)
• 지표 정의 충돌 (metric definition conflict)
• 차트 생성 실패 (chart generation failure)

기대 동작 (Expected behavior):

• 숫자를 조작하지 말 것 (do not fabricate numbers)
• 데이터 한계를 명확히 명시할 것
• 쿼리 이력을 보존할 것
• 더 작은 규모의 쿼리를 제안할 것
• 테넌트 간 데이터 유출(cross-tenant leakage)을 방지할 것

코딩 에이전트 (Coding agent)

결함 발생 (Break):

• 수정 후 테스트 실패 (failing test after edit)
• 의존성 누락 (missing dependency)
• 오래된 파일 컨텍스트 (stale file context)
• 린트(lint) 오류
• 숨겨진 지침이 포함된 도구 출력 (tool output with hidden instructions)

기대 동작 (Expected behavior):

• 작업을 완료로 표시하지 말 것
• 변경된 파일을 보여줄 것
• 테스트 증거를 포함할 것
• 위험한 수정을 되돌리거나 격리할 것
• 파괴적인 명령을 실행하기 전 요청할 것

브라우저 자동화 에이전트 (Browser automation agent)

결함 발생 (Break):

• 변경된 DOM 선택자 (changed DOM selector)
• 로그인 만료
• 페이지에 악성 텍스트 포함
• 버튼 레이블 변경
• 클릭 후 네트워크 요청 실패

기대 동작 (Expected behavior):

• 불확실한 파괴적 동작을 클릭하지 말 것
• 페이지의 불확실성을 요약할 것
• 위험이 증가할 때 승인을 요청할 것
• 스크린샷 또는 DOM 증거를 저장할 것
• 제한된 횟수 내에서 재시도할 것

카오스 테스트를 얼마나 자주 실행해야 하는가?

모든 풀 리퀘스트 (pull request)마다 소규모 세트를 실행하세요:

• 도구 타임아웃 1건
• 잘못된 형식의 출력 1건
• 권한 거부 1건
• 컨텍스트 충돌 1건
• 승인이 필요한 동작 1건

릴리스 전에는 더 큰 규모의 스위트 (suite)를 실행하세요:

• 다단계 실패 (multi-step failures)
• 제공자 장애 조치 (provider failover)
• MCP 서버 변경
• 브라우저 워크플로우 변경
• 고비용 재시도 경로 (high-cost retry paths)
• 데이터 격리 테스트 (data isolation tests)

프로덕션 장애 발생 후에는 특정 사고에 특화된 시나리오를 실행하세요. 만약 사용자가 에이전트가 잘못된 초안을 보냈거나, 컨텍스트를 유출했거나, 도구에서 루프에 빠졌거나, 거짓 진척 상황을 주장했다고 보고한다면, 해당 사고를 새로운 시나리오로 전환하세요.

최고의 카오스 스위트는 당신이 직접 겪은 상처(scars)로부터 구축됩니다.

추적할 가치가 있는 지표 (Metrics Worth Tracking)

모호한 대시보드는 피하세요. 엔지니어링 동작을 변화시키는 수치를 추적해야 합니다.

이미 모델 비용, 지연 시간 (Latency), 도구 호출량 (Tool-call volume)을 추적하고 있다면, 해당 트레이스 (Traces)에 카오스 라벨 (Chaos labels)을 추가하세요. 그러면 성공했을 때는 저렴하지만, 혼란에 빠졌을 때는 비용이 많이 발생하는 워크플로우가 무엇인지 빠르게 파악할 수 있습니다.

흔한 실수 (Common Mistakes)

실수 1: 해피 패스 (Happy paths)만 테스트하는 것

해피 패스는 데모가 작동한다는 것을 증명할 뿐입니다. 제품이 신뢰할 수 있다는 것을 증명하지는 않습니다.

실수 2: 모델이 모든 것을 판단하게 두는 것

LLM-as-judge (판단자로서의 LLM)가 도움이 될 수 있지만, 중요한 단언 (Assertions)은 가능한 한 결정론적 (Deterministic)이어야 합니다. 작업 (Actions), 도구 호출 (Tool calls), 예산 (Budgets), 승인 (Approvals), 스키마 (Schemas), 그리고 상태 (State)를 직접 확인하세요.

실수 3: 모든 실패를 모델 문제로 취급하는 것

많은 에이전트 실패는 시스템 설계 문제입니다: 멱등성 (Idempotency) 누락, 취약한 상태 관리 (Weak state), 광범위한 권한 (Broad permissions), 모호한 도구 계약 (Vague tool contracts), 불량한 컨텍스트 위생 (Poor context hygiene), 또는 승인 게이트 (Approval gate)의 부재 등이 이에 해당합니다.

실수 4: 재현 (Replay) 불가

실패를 재현할 수 없다면, 그것은 테스트가 아니라 단순한 이야기일 뿐입니다.

실수 5: 실패 중 발생하는 비용을 무시하는 것

0.02달러를 쓰는 고장 난 워크플로우는 짜증 나는 수준입니다. 하지만 비싼 모델과 도구를 사용하며 10분 동안 재시도하는 고장 난 워크플로우는 비즈니스 문제입니다.

시작을 위한 체크리스트 (A Starter Checklist)

에이전트 워크플로우를 프로덕션 환경에 배포하기 전에 다음을 확인하세요:

• 모든 도구에 타임아웃 처리 (Timeout handling)가 되어 있는가.
• 모든 쓰기 작업 (Write action)에 멱등성 (Idempotency)이 보장되는가.
• 모든 위험한 작업에 승인 규칙 (Approval rule)이 있는가.
• 모든 워크플로우에 재시도 예산 (Retry budget)이 설정되어 있는가.
• 모든 실행이 재현 가능한 트레이스 (Replayable trace)를 기록하는가.
• 도구 출력 (Tool outputs)을 신뢰할 수 없는 입력 (Untrusted input)으로 취급하는가.
• RAG 결과에 출처 및 테넌트 메타데이터 (Source and tenant metadata)가 포함되어 있는가.
• 장기 실행 작업 (Long-running tasks)이 내구성이 있는 상태 (Durable state)를 저장하는가.
• 실패한 실행이 사용자에게 안전한 복구 메시지 (User-safe recovery messages)를 생성하는가.
• 프로덕션 장애가 회귀 시나리오 (Regression scenarios)로 전환되는가.

빌더를 위한 콘텐츠 맵 (Content Map for Builders)

이 주제는 프로덕션 AI 아키텍처 (production AI architecture) 기둥에 속합니다. 이는 에이전트 관측성 (agent observability), 평가 하네스 (evaluation harnesses), 모델 페일오버 (model failover), MCP 테스팅 (MCP testing), 워크플로우 상태 (workflow state), 그리고 도구 계약 테스팅 (tool contract testing)을 포함하는 신뢰성 클러스터 (reliability cluster)를 지원합니다.

더 넓은 콘텐츠 전략을 위한 유용한 내부 링크 앵커 (internal-link anchors):

• AI 에이전트 관측성 체크리스트 (AI agent observability checklist)
• AI 에이전트 평가 하네스 (AI agent evaluation harness)
• MCP 도구 테스팅 (MCP tool testing)
• LLM 폴백 전략 (LLM fallback strategy)
• 에이전트 워크플로우 상태 관리 (agent workflow state management)
• AI 에이전트를 위한 도구 계약 테스팅 (tool contract testing for AI agents)

다음 유용한 클러스터 구성 요소:

• 프로덕션 에이전트를 위한 MCP 장애 테스팅 (MCP Failure Testing for Production Agents)
• 개발 팀을 위한 에이전트 리플레이 트레이스 스키마 (Agent Replay Trace Schema for Developer Teams)
• 도구 호출 워크플로우를 위한 AI 재시도 예산 설계 (AI Retry Budget Design for Tool-Calling Workflows)
• 위험한 웹 동작을 위한 브라우저 에이전트 장애 훈련 (Browser Agent Failure Drills for Risky Web Actions)

FAQ

AI 에이전트 카오스 테스팅 (AI agent chaos testing)이란 무엇인가요?