멀티 에이전트 AI의 실패를 예측하려 한 한 달간의 시도. 실패했지만, 그 실패가 내게 가르쳐준 것들

나는 꽤 흥분되는 가설을 하나 가지고 있었습니다. 바로 멀티 에이전트 시스템 (multi-agent system)이 실제로 실패하기 전에, 즉 이를 중단시킬 수 있을 만큼 충분히 이른 시점에 시스템이 궤도를 벗어나고 있다는 것을 감지할 수 있다는 가설입니다. 만약 이것이 사실이라면, 그것은 하나의 제품이 될 것입니다. 만약 사실이 아니라면, 나는 1년이 아니라 한 달 안에 그 사실을 알고 싶었습니다.

그래서 나는 이를 실제 실험으로 진행했습니다. 결과가 단순히 부정적으로 나온 것뿐만 아니라, 완전히 반대로 나온 부분을 포함하여 어떤 일이 일어났는지 공유합니다.

내가 가장 신경 썼던 설정: 나 자신을 속이지 않는 것
이런 아이디어를 "검증"하는 쉬운 방법은 신호 (signal)를 구축하고, 실행한 뒤, 수치가 좋아 보이는 순간 튜닝을 멈추는 것입니다. 그것은 거짓 위에 세워진 무언가를 출시하는 방식이기도 합니다.

따라서 결과에 손을 대기 전에, 나는 모든 것을 사전 등록 (pre-registered)했습니다: 신호, 데이터셋 분할 (dataset split), 성공 기준 (AUC ≥ 0.80), 임계값 (threshold) 설정 방식 등입니다. 나는 파일 수준에서 신호 계산과 라벨 (labels)을 분리했으며, 신호 코드가 라벨을 임포트 (import)하기라도 하면 빌드가 실패하도록 누수 테스트 (leakage test)를 작성했습니다. 그 이후의 모든 변경 사항은 타임스탬프와 "결과를 보기 전에 결정됨" 플래그가 포함된 번호가 매겨진 수정 사항으로 기록되었습니다.

과한 작업처럼 느껴졌습니다. 하지만 과한 것이 아니었습니다. 그것이 내가 다음에 이어질 결과들을 신뢰할 수 있는 유일한 이유입니다.

신호 (The signals)
두 가지 신호가 있으며, 둘 다 실행의 과거 접두사 (past prefix)에서만 계산되었습니다 (절대 미래를 보거나 라벨을 보지 않음):

1. 루프 압력 (Loop Pressure) — 에이전트 간 메시지 그래프 (inter-agent message graph)에서의 구조적 사이클 감지 (structural cycle detection)로, 정보량이 적은 루프가 더 많이 계산되도록 가중치를 부여했습니다. 직관: 실패하는 팀은 종종 제자리를 맴돌기 시작합니다.
2. 정보 이득 감쇠 (Information Gain Decay) — 각 새로운 단계가 새로운 정보를 추가하는 것을 멈추는 속도 (임베딩 참신함 (embedding novelty)을 매끄럽게 처리한 후 그 하향 경사도를 측정). 직관: 정체되기 직전에 새로운 정보가 고갈됩니다.

결과
AUC ≈ 0.46. 사전 등록된 기준치는 0.80이었습니다. 깔끔한 실패였습니다. 프레임워크별로 살펴보면 전반적으로 ~0.5 수준이었으며, 이는 데이터셋 혼합(dataset-mixing)으로 인한 인위적인 결과가 아니었습니다.

"신호 없음, 무작위 성능" 단계에서 멈출 수도 있었습니다. 하지만 그 '이유'가 흥미로운 부분이 되었습니다.

반전: 신호가 길이를 측정하고 있었고, 이를 수정하자 결과가 뒤집혔습니다

제가 사용했던 개별 트레이스 점수(실행 중 최댓값)는 스피어만(Spearman) 상관계수 0.86으로 트레이스 길이와 상관관계가 있었습니다. 즉, 저의 "실패 신호"는 대부분 실행이 얼마나 길었는지를 측정하고 있었던 것입니다. 실행이 길어질수록 → 높은 값에 도달할 기회가 많아지고 → 점수가 높아집니다. 실패한 실행과 성공한 실행 사이의 실제 차이는 유의미하지 않았습니다.

여기서 정직한 조치는 가설이 반증되었다고 결론 내리는 것이 아닙니다. 고장 난 도구로는 아무것도 테스트할 수 없기 때문입니다. 그래서 저는 길이 불변 지표(per-trace mean, 최댓값 대신 개별 트레이스 평균)를 사용하여 사전 등록된 재집계(re-aggregation)를 한 번 수행했습니다. 길이와의 상관관계는 0.86에서 -0.27로 떨어졌습니다. 이제 도구가 깨끗해졌습니다.

깨끗해진 결과는 더 나빴습니다 — AUC 0.42 — 그리고 방향이 뒤집혔습니다. 성공한 실행이 실패한 실행보다 더 많은 정보 이득 감소(information-gain decay)를 보였습니다 (효과는 작지만 유의미했습니다).

그 반전이 제가 배운 가장 유용한 점입니다. "정보의 속도가 느려지는 것"은 실패 신호가 아닙니다. 왜냐하면 그것은 건강한 수렴(convergence) 과정 중에도 발생하기 때문입니다. 작업이 성공적으로 마무리되는 과정 또한 새로운 정보를 생성하는 것을 멈춥니다. 제가 측정하던 수준에서는 "잘 마무리되는 것"과 "루프에 빠지는 것"이 똑같아 보였기 때문에, 저의 신호는 이 둘을 구분할 수 없었습니다.

이것이 의미하는 바와 의미하지 않는 바

이것이 "멀티 에이전트의 실패를 절대 예측할 수 없다"는 뜻은 아닙니다. 제가 사용한 레이블은 인간이 레이블을 붙인 하위 집합과 비교했을 때 약 33%의 불일치를 보이는 LLM 판정 결과였으며, 실행 수준(execution-level)이 아닌 작업 수준(task-level)이었습니다. 루프 압박(Loop Pressure)은 제대로 테스트조차 할 수 없었습니다. 7개의 프레임워크 중 단 하나만이 에이전트 간 엣지(inter-agent edges)를 실제로 기록하고 있었습니다 (이는 멀티 에이전트 툴링의 현 상태에 대한 그 자체로 불편한 발견입니다).

이것이 의미하는 바: 이 데이터에서 깨끗하게 측정된 이 특정 신호는 예측력(predictive power)이 없으며, 약간의 역방향(inverse direction)을 보입니다. 이는 이 접근 방식에 있어 실질적인 부정적 결과이지만, 이 아이디어에 대한 영원한 판결은 아닙니다.

나를 놀라게 한 부분: 본능은 틀리지 않았고, 구현(implementation)이 틀렸습니다.

사후에 문헌을 조사해 보니,

(저는 이 방향으로 좁은 범위의 무언가를 구축하고 있기에 편향되어 있을 수 있습니다. 하지만 저는 주로 제가 실제 문제(real problem)를 쫓고 있는지, 아니면 유령(ghost)을 쫓고 있는지를 알고 싶을 뿐입니다. 전체 실험 과정과 수정 사항 등을 모두 기꺼이 공유하겠습니다.)