우리는 100만 건 이상의 적대적 이벤트로 LLM 런타임을 스트레스 테스트했습니다. 고장 나지 않았습니다.

대부분의 “LLM 프레임워크”는 데모에서는 실패하지 않습니다.

그들은 프로덕션 환경에서 재시도, 부분 실패, 경쟁 상태, 쓰레기 출력 등으로 인해 실패합니다.

그래서 우리는 해피 패스(happy paths) 벤치마킹을 중단했습니다.

대신 카오스 스위트(chaos suite)를 만들었습니다.

우리가 테스트한 것

프롬프트가 아닙니다. 정확도도 아닙니다.

우리는 실패 모드를 테스트했습니다:

• 중복 실행 공격

• 재시도 폭풍 (450k 재시도)

• 중간 단계 충돌

• 순서가 뒤바뀐 이벤트 전달

• 손상된 페이로드

• 도구 실패 연쇄

• 타임아웃 드리프트 (66% 타임아웃 비율)

• 재진입 + 동시 변이

• LLM 출력 노이즈 / 주입

그리고 마지막으로:

«전체 시스템 카오스 모드 (위의 모든 것을 결합)»

결과

13 / 13 테스트 통과

0 잘못된 상태

0 이중 실행

0 정의되지 않은 전환

이 결과를 잘 생각해보세요.

불편한 진실

오늘날 대부분의 LLM 시스템은 암묵적으로 다음을 가정합니다:

next_state = f(LLM_output)

그것이 바로 상황이 잘못되는 지점입니다.

우리는 다른 접근 방식을 취했습니다:

next_state = δ(current_state, event)

여기서:

• 전환은 미리 정의되어 있습니다

• LLM 출력은 제어 흐름이 아닌 데이터일 뿐입니다

• 모든 단계는 검증 및 정규화됩니다

이것이 우리에게 주는 것

• 재시도 시 멱등성: 450,000회 재시도 → 0 위반

• 중복 안전성: 0 이중 실행

• 충돌 복구: 0 깨진 재개

• LLM 격리: 모델 노이즈에 영향을 받는 전환 0건

• 손상 처리: 50,000 / 50,000 정규화

• 순서가 뒤바뀐 이벤트 안전성: 0 잘못된 이벤트 수락

• 카오스 모드: 50,000회 실행 → 0 잘못된 최종 상태

처리량 (네, 빠르기도 합니다)

• 최대 190k ops/sec (순수 실행 안전성)

• LLM 노이즈 하에서 ~148k ops/sec

• 전체 카오스 모드에서 ~4k ops/sec

이것이 실제로 의미하는 것