Your Sub-Agents Are a Distributed System. Treat Them Like One. - Girish Konda, Microsoft

한 줄 핵심

서브 에이전트는 단순한 함수 호출이 아니라 공유 상태와 실패 모드를 가진 분산 시스템으로 다뤄야 하며, 안전한 인계와 명시적 상태를 코드로 강제하지 않으면 그럴듯한 오답과 중복 실행이 쉽게 누적된다.

시간별 요약

1. 0:00
   서브 에이전트는 분산 시스템이다 여러 서브 에이전트가 같은 상태를 공유하며 병렬로 도구를 호출하고 결과를 합치는 구조는 전형적인 분산 시스템이다. 따라서 에이전트 사용에서 마주치는 문제도 새로운 AI 고유의 문제가 아니라, 부분 실패와 공유 상태 오염, 재시도 같은 익숙한 분산 시스템 문제로 봐야 한다.
2. 2:00
   기본 실패 모드: 부분 실패, 무응답, 비잔틴 오류 서브 에이전트는 중간에 실패해도 성공처럼 보이는 텍스트를 반환할 수 있고, 응답이 늦거나 사라져도 원인을 즉시 알 수 없다. 또한 같은 입력에서 그럴듯하지만 서로 다른 결론을 내는 비잔틴형 오류가 생기므로, 결과의 형태만 보고 성공으로 처리하면 안 된다.
3. 7:01
   공유 컨텍스트는 더티 리드를 만든다 한 서브 에이전트의 추정이나 미검증 결론이 다른 서브 에이전트의 사실처럼 재사용되면, 같은 잘못이 여러 번 독립적으로 확인된 것처럼 보인다. 단순히 여러 에이전트가 읽는다고 독립성이 생기는 것이 아니므로, 사실에는 출처와 시점, 검증 상태가 함께 따라가야 한다.
4. 10:00
   안전한 인계 모델: SAFE handoff 서브 에이전트 인계는 source feeds, at most once effects, fanout budgets, explicit outcomes의 네 가지 원칙으로 통제해야 한다. 즉, 사실에는 출처와 최신성이 붙고, 쓰기 작업은 중복 재실행을 막는 식별자와 승인으로 묶이며, 하위 작업 수와 대기 시간은 예산으로 제한되고, 모든 결과는 completed나 failed가 아니라 stale, unknown 같은 명시적 상태로 돌아와야 한다.
5. 20:01
   한계와 실전 적용 이 모델은 사실을 진실로 바꾸지 못하고, 정확히 한 번 실행을 보장하지도 않으며, 부분 작업의 롤백도 자동으로 해결하지 않는다. 다만 실제 프로덕션 시스템을 건드리는 서브 에이전트라면, 각 인계를 네트워크 호출처럼 취급하고 상태를 텍스트가 아니라 코드로 판정하는 것만으로도 실패율과 오판을 크게 줄일 수 있다.

실무 인사이트

• 서브 에이전트의 출력은 자연어 설명이 아니라 상태를 가진 작업 결과로 다뤄야 하며, partial·stale·unknown 같은 실패 상태를 반환하도록 인터페이스를 설계해야 한다.
• 공유 메모리나 컨텍스트에 들어가는 정보는 문장이 아니라 출처·시점·버전이 포함된 기록이어야 하며, 검증되지 않은 추정은 별도 표식으로 분리해야 한다.
• 재시도와 병렬 확장은 기본적으로 중복 실행과 경쟁 상태를 유발하므로, 승인·쓰기·세션 시작에는 예산과 식별자, 거부 신호를 반드시 넣어야 한다.