AI 산업은 에이전트가 어떻게 행동(behave) 하는지를 테스트하는 데 엄청난 노력을 기울여 왔습니다. 평가(evals), 출력 점수 매기기(output scoring), LLM-as-judge, 런타임 관측성(runtime observability) 등이 그 예입니다. 모두 가치 있는 일입니다. 하지만 거의 모든 사람이 건너뛰는, 더 초기 단계의 더 저렴한 계층이 있으며, 바로 그곳에 가장 비용이 많이 드는 실패들이 숨어 있습니다. 그것은 바로 시스템 자체의 **구조(structure)**입니다.

멀티 에이전트 신뢰성(multi-agent reliability)의 첫 번째 계층으로서 구조적 분석(structural analysis)이 필요한 이유는 다음과 같습니다.

두 가지 서로 다른 질문

행동 테스트(Behavioral testing)는 다음을 답변합니다: "이 실행이 좋은 출력을 생성했는가?"

구조적 분석(Structural analysis)은 다음을 답변합니다: "이 시스템이 제대로 연결(wired)되어 있는가?"

이들은 서로 다른 계층이며, 상반된 특성을 가집니다.

행동 테스트는 더 깊은 계층입니다. 하지만 구조적 분석은 더 저렴하고 더 이른 계층입니다. 그리고 이를 건너뛰는 것이 바로 너무 많은 시스템이 실패하는 이유입니다.

왜 구조적 분석이 우선되어야 하는가

1. 가장 비싼 실패를 잡아낼 수 있는 가장 저렴한 지점입니다.

종료 조건(exit condition)이 없는 피드백 루프(feedback loop). 전체 파이프라인을 중단시키는 단일 장애점(single point of failure). 검증 없이 결정 에이전트(decision agent)로 흘러 들어가는 신뢰할 수 없는 도구(tool)의 출력. 이러한 것들은 운영 환경(production)에서 재앙적이지만, 각 에이전트가 개별적으로는 괜찮기 때문에 에이전트별 행동 테스트로는 완전히 보이지 않습니다. 구조적 분석은 토큰을 단 하나도 사용하기 전, 밀리초(milliseconds) 단위로 이를 찾아냅니다.

2. 에러를 발생시키지 않는 실패를 잡아냅니다.

행동 테스트는 출력이 좋은지 확인합니다. 하지만 멀티 에이전트 시스템에서 가장 큰 피해를 주는 실패는 나쁜 출력을 만드는 것이 아니라, **침묵(silence)**을 만들어냅니다. 종료되지 않고 조용히 토큰을 태워버리는 루프. 추적할 에러 없이 멈춰버리는 의존성(dependency). 하룻밤 사이에 폭등하는 청구서. 이 중 어느 것도 평가(eval)를 통해 확인할 수 있는 행동적 실패가 아닙니다. 이것들은 그래프(graph)의 구조적 속성입니다.

3. 모든 변경 사항에 대해 CI에서 실행됩니다.

구조적 분석 (structural analysis)은 결정론적 (deterministic)이고 즉각적이기 때문에, 행동 테스트 (behavioral testing)가 결코 할 수 없는 방식으로 빌드 파이프라인 (build pipeline)에 통합될 수 있습니다. 행동 테스트는 너무 느리고 불안정 (flaky)하여 PR (Pull Request)을 차단하기에는 부적합합니다. 구조적 분석은 회귀 (regression)가 배포된 후가 아니라, _머지(merge)되기 전_에 이를 잡아냅니다.

대체가 아니라 — 우선순위의 문제

이것은 구조적 분석이 행동 테스트를 대체한다는 주장이 아닙니다. 둘 다 필요합니다. 이것은 _순서_에 관한 주장입니다. 구조적 분석은 모두가 이미 집착하고 있는 비용이 많이 드는 런타임 (runtime) 레이어 앞에 위치해야 하는, 빠르고 비용이 들지 않으며 결정론적인 레이어입니다. 건물을 짓기 전에 설계도 (blueprint)를 먼저 확인하십시오.

그리고 더 깊은 이점이 있습니다. 일단 구조적 지도 (structural map)를 갖게 되면, 행동 테스트가 어디에 집중해야 하는지를 알려줍니다. 그래프 (graph)는 취약한 엣지 (edges)를 보여주므로, 비용이 많이 드는 런타임 테스트가 맹목적으로 퍼징 (fuzzing)하는 대신 실제로 중요한 지점을 겨냥할 수 있게 합니다.

시도해 보세요

swarm-test는 에이전트 토폴로지 (agent topology) (CrewAI, LangGraph, AutoGen 또는 일반적인 에이전트/엣지 기술)를 매핑하고 다음과 같은 구조적 실패를 정적으로 플래그 (flag)합니다: 무한 루프 (no-exit loops), 숨겨진 단일 장애점 (SPOFs), 보호되지 않은 핸드오프 (unguarded handoffs), 인젝션 표면 (injection surfaces), 연쇄 폭발 반경 (cascade blast radius).

pip install swarm-test

LLM 호출이 없습니다. 결정론적입니다. 밀리초 단위로 실행됩니다. CI에서 실행됩니다 (--ci 옵션은 구조적 회귀 발생 시 빌드를 실패 처리합니다). 그리고 무언가를 발견했을 때, 에이전트를 더 추가하라고 말하는 대신 가장 가벼운 해결책 — 설정 변경, 경로 재설정, 인라인 체크 — 을 먼저 제시합니다.

시스템에서 한 번 실행해 보세요. 설정도 비용도 없이 60초면 충분합니다. 최악의 경우, 배선 (wiring)이 깔끔하다는 것을 확인하게 될 뿐입니다. 최선의 경우, 문제가 당신을 찾아내기 전에 조용한 실패 (silent failure)를 발견하게 될 것입니다.

오픈 소스, MIT 라이선스.

에이전트의 행동을 테스트하십시오 — 네, 맞습니다. 하지만 그들이 실행되는 구조를 먼저 테스트하십시오. 그것은 모두가 잊어버리는 레이어이며, 비용이 많이 드는 실패가 숨어 있는 곳입니다.

이 내용이 유용했다면, GitHub에서 스타(star)를 눌러 다른 개발자들이 찾을 수 있도록 도와주세요.