제가 정말 만들고 싶은 AI 융합 시스템을 소개합니다.
사용자(고객)가 어떤 문제가 있는지 발견하기 전에, 사용자의 AI 에이전트를 의도적으로 고장 내는 AI 시스템입니다.
단순히 무작위 테스트 케이스를 생성하는 방식으로는 아닙니다.
실제 네트워크 장애, 지연되는 API 응답, 서비스 충돌, 그리고 부분적으로 완료된 트랜잭션을 시뮬레이션함으로써 에이전트를 검증합니다.
그런 다음 Claude Code를 사용하여 실패 지점을 식별하고, 수정 방안을 개발하며, 실제로 작동하는지 증명합니다.
저는 이것을 AI FAILURE TWIN이라고 부르겠습니다.
구성 요소:
Claude Code + Temporal + Toxiproxy + OpenTelemetry + Testcontainers.
다섯 가지 기존 기술로 하나의 강력한 엔지니어링 시스템을 구축했습니다.
아키텍처는 다음과 같습니다.
- TEMPORAL — 에이전트에 내구성 있는 실행력 부여하기 (GIVE YOUR AGENT DURABLE EXECUTION)
AI 에이전트가 고객 주문을 처리하는 상황을 상상해 보세요.
재고를 확인하고, 결제를 요청하며, 데이터베이스를 업데이트하고, 확인 메시지를 보냅니다.
그런 다음 서버가 결제가 성공한 직후에 충돌한다고 가정합니다.
에이전트가 다시 시작하면 어떤 일이 발생할까요?
안전하게 계속 진행될까요?
아니면 고객에게 두 번 청구할까요?
Temporal은 내구성 있는 워크플로우 실행(durable workflow execution), 영속적인 이벤트 기록(persistent event histories), 그리고 설정 가능한 액티비티 재시도(configurable activity retries)를 제공합니다.
Python SDK로 시작하세요:
pip install temporalio
로컬 개발을 위해 Temporal CLI를 설치하고 다음 명령어를 실행합니다:
temporal server start-dev
각 외부 작업은 별도의 Temporal Activity로 구축해야 합니다.
하지만 여기서 중요한 세부 사항이 있습니다:
Temporal은 정확히 한 번만 발생하는 외부 부작용(exactly-once external side effects)을 보장하지 않습니다. 액티비티는 여러 번 실행될 수 있습니다.
따라서 여전히 Idempotency와 신중하게 설계된 재시도 정책이 필요합니다.
- TOXIPROXY — 네트워크를 의도적으로 고장 내기 (DELIBERATELY BREAK THE NETWORK)
여기서 실험이 흥미로워집니다.
Toxiproxy는 Shopify의 오픈 소스 네트워크 장애 시뮬레이션 도구입니다.
테스트 연결에 지연 시간(latency), 연결 재설정(connection resets), 대역폭 제한(bandwidth restrictions), 데이터 손실 등을 주입할 수 있습니다.
만약 사용자의 애플리케이션이 시뮬레이션된 결제 서비스에 호출한다고 가정해 봅시다.
Toxiproxy와 목업(mock) 결제 서버를 시작한 후, 프록시를 구성합니다:
toxiproxy-cli create -l 127.0.0.1:18080 -u 127.0.0.1:8080 payment_mock
테스트 애플리케이션을 포트 18080으로 지정합니다.
이제 2초의 응답 지연 시간(latency)을 주입합니다:
toxiproxy-cli toxic add -t latency -a latency=2000 payment_mock
애플리케이션의 요청 시간 초과(request timeout)를 500밀리초로 설정합니다.
사용자의 결제 목업(payment mock)은 거래를 성공적으로 처리할 수 있지만, 그 응답이 너무 늦게 도착합니다.
애플리케이션은 시간 초과를 감지합니다.
재시도(retries)합니다.
적절한 보호 장치가 없다면, 동일한 논리적 결제가 다시 처리될 수 있습니다.
이것이 일반적인 성공 테스트가 절대 밝혀내지 못하는 종류의 실패입니다.
- OpenTelemetry — 정확히 어디서 실패했는지 파악하기
이제 워크플로우를 OpenTelemetry로 계측(instrument)합니다.
다음 전반에 걸쳐 트레이스(traces)를 캡처합니다:
에이전트 결정 → 결제 활동 → API 요청 → 시간 초과 → 재시도 → 최종 결과.
트레이스 컨텍스트(trace context)를 사용하여 서비스 전반의 작업을 연결합니다.
재시도 횟수, 타이밍, 오류 유형 및 관련 거래 식별자를 기록합니다.
민감한 결제 정보는 원격 측정(telemetry)에서 제외합니다.
한 가지 중요한 구별점:
트레이스는 애플리케이션이 시도한 것을 보여줄 수 있습니다.
실제로 청구가 발생했는지 확인하려면 독립적인 목업 결제 원장(mock payment ledger)을 검사해야 합니다.
그렇지 않으면, 에이전트가 응답하지 않은 요청을 실패한 거래로 오인할 수 있습니다.
- Claude Code — 조사 및 복구
이제 실패한 테스트, 트레이스 데이터, 관련 소스 파일 및 정확한 요구 사항을 Claude Code에 제공합니다:
"결제 응답이 손실되더라도, 하나의 논리적 주문은 절대 하나 이상의 완료된 청구를 생성해서는 안 됩니다."
Claude가 실패를 조사합니다.
가능한 수정 방법은 논리적 주문 ID에서 안정적인 Idempotency Key를 생성하고 재시도 전반에 걸쳐 이를 재사용하는 것입니다.
결제 제공업체 또는 테스트 더블(test double)이 해당 키에 대한 중복 제거(deduplication)를 강제해야 합니다.
Claude는 또한 재시도 제한(retry limits), 시간 초과 처리(timeout handling) 및 복구 동작을 검토할 수 있습니다.
하지만 코딩 에이전트가 자신의 해결책을 통과시키기 위해 인수 테스트(acceptance tests)를 다시 작성하도록 두지 마십시오.
원래의 실패 시나리오를 보호하십시오.
- Testcontainers — 발견을 반복 가능한 테스트로 전환하기
이제 완전한 시나리오를 일회용 테스트 컨테이너(disposable test containers)에서 실행합니다.
Testcontainers는 여러 언어에서 전용 Toxiproxy 모듈을 지원합니다.
사용자의 CI 환경에서는 필요한 서비스를 시작하고, 네트워크 오류를 구성하며, 애플리케이션을 실행하고, 결과를 검사할 수 있습니다.
저는 다음 다섯 가지 시나리오를 테스트해 볼 것입니다:
- 지연된 결제 응답 (A delayed payment response).
- 성공적인 처리 후 연결이 끊어지는 경우 (A dropped connection after successful processing).
- 외부 작업 중 워커가 충돌하는 경우 (A worker crash during an external operation).
- 동일한 이벤트의 중복 전송 (Duplicate delivery of the same event).
- 제어된 목(mock) 서비스로부터 받은 HTTP 429 속도 제한 응답 (An HTTP 429 rate-limit response from a controlled mock service).
서로 다른 실패에는 서로 다른 주입 메커니즘이 필요합니다. Toxiproxy는 네트워크 오류를 처리하고, 목(mock) 서비스는 애플리케이션 수준의 응답을 처리합니다.
모든 테스트는 독립적으로 정의된 비즈니스 불변성(business invariants)을 확인합니다.
예를 들어:
- 하나의 주문 ID → 최대 하나의 완료된 청구만 허용.
- 확인 불가 → 트랜잭션 상태가 검증될 때까지 대기.
- 재시도(Retries) → 정책에 의해 경계 설정됨.
- 실패한 작업 → 복구 가능하거나 명시적으로 에스컬레이션됨.
완벽한 시스템 구조:
AI Agent
↓
Temporal Durable Workflow
↓
Testcontainers Environment
↓
Toxiproxy Fault Injection
↓
OpenTelemetry Evidence
↓
독립적인 실패 감지(Independent Failure Detection)
↓
Claude 코드 근본 원인 분석(Root-Cause Analysis)
↓
제안된 코드 수정(Proposed Code Correction)
↓
동일한 실패 테스트 반복
↓
사람이 검토한 풀 리퀘스트(Human-Reviewed Pull Request)
이제 AI 에이전트를 출시하기 전에 이것을 50가지 실패 시나리오에 대해 실행한다고 상상해 보세요. 다음 항목들을 측정할 수 있습니다:
- 실패 복구율 (Failure recovery rate).
- 중복 작업 건수 (Duplicate-action count).
- 95번째 백분위수 복구 시간 (95th-percentile recovery time).
- 완료된 워크플로우당 비용 (Cost per completed workflow).
- 재시도 증폭(Retry amplification).
- 성공적으로 재현 및 수정된 실패 횟수.
이것들은 발명된 정확도 주장이 아니라 측정 가능한 엔지니어링 결과입니다.
그리고 이 애플리케이션은 결제에만 국한되지 않습니다. 고객 지원 에이전트, CRM 자동화, 재고 시스템, 송장 처리기, AI 연구 파이프라인, 다중 에이전트 워크플로우 등에도 사용할 수 있습니다.
진정으로 흥미로운 부분은 무엇일까요?
AI 에이전트가 완벽한 조건에서 작업을 완료할 수 있는지 묻는 대신, 현실 세계가 예측 불가능해질 때 올바르게 작동하는지 테스트하고 있는 것입니다.
하나의 실패한 테스트는 재현 가능한 엔지니어링 문제가 됩니다.
검증된 수정 사항 하나는 영구적인 회귀 테스트(regression test)가 됩니다.
그리고 모든 새로운 실패 시나리오는 애플리케이션이 취약한 지점에 대한 시스템의 이해를 확장합니다. 테스트 스위트가 모두 통과(green)되었다고 해서 여전히 프로덕션 환경에서의 안전을 보장하는 것은 아닙니다. 그것은 실제로 테스트된 시나리오에 대해서만 신뢰성을 확립할 뿐입니다.
하지만 이것은 자율 시스템(autonomous system)을 배포하기 위한 훨씬 더 강력한 기반이 됩니다.
대부분의 AI 도구는 에이전트(agent)를 더 빠르게 구축하도록 도와줍니다.
저는 오히려 어떤 에이전트를 신뢰할 수 있을 만큼 안전한지 알려주는 시스템을 구축하고 싶습니다.
왜냐하면 에이전트형 AI(agentic AI)의 미래는 단순히 자율 시스템을 더 유능하게 만드는 것에 관한 것이 아니기 때문입니다. 그것은 그들의 실패를 예측 가능하고(predictable), 관찰 가능하며(observable), 복구 가능하도록(recoverable) 만드는 것입니다.