멀티 에이전트 시스템을 개선하는 가장 큰 방법은 에이전트의 중요도를 낮추는 것

이런 아키텍처 관련 글이야말로 내가 더 보고 싶었던 것임. 에이전트를 시스템 그 자체가 아니라 대체 가능한 작업자로 보는 관점은 정말 정확함. 나도 문서 처리 파이프라인을 만들면서 똑같은 벽에 부딪혔거든. 에이전트들이 엣지 케이스에서 자꾸 제멋대로 행동하더라고. 이걸 해결한 건 규칙으로 표현 가능한 모든 결정을 뽑아내서 에이전트가 읽을 수는 있지만 수정은 절대 못 하는 정책 계층에 박아 넣은 거였음. 에이전트는 권한을 가진 주체가 아니라 제안 엔진이 된 거지.

'완료'에 대한 부분도 정말 공감됨. 내 현재 설정에는 무엇이든 변경되어야 할 실제 상태를 다시 읽어오는 검증 단계가 있음. 모델이 파일이 존재하지도 않는데 생성했다고 자신 있게 주장한 적이 한두 번이 아님. 환각이라기보다는 의도와 실제 결과 사이의 괴리였지. 이제 시스템은 모델의 주장을 사실이 아니라 검증해야 할 가설로 취급함.

내가 아직 고민 중인 건 에이전트가 언제 에스컬레이션을 요청하게 할지, 아니면 시스템이 언제 강제로 에스컬레이션을 시킬지임. 어떤 작업은 모델이 상황을 더 악화시키는 6가지 우회책을 시도하게 두는 것보다, 그냥 빠르게 실패하고 사람에게 알림을 보내는 게 나음.

맞음. 나도 이 부분을 계속 다듬고 있는 중임.

에스컬레이션이 에이전트가 '나 막혔어'라고 판단하는 것에만 의존해서는 안 된다고 생각함. 실패하고 있는 모델은 자기가 실패하고 있다는 사실조차 인식하지 못할 가능성이 높으니까.

그래서 나는 다음과 같은 시스템 수준의 에스컬레이션 트리거를 고려하고 있음:

• 재시도 예산 소진
• 동일한 유형의 실패 반복
• N번 시도 후 측정 가능한 상태 진전 없음
• 권한/책임 경계 도달
• 결정론적으로 해결할 수 없는 상충하는 증거 발생
• 재시도 예상 비용이 에스컬레이션 가치를 초과함
• 결과적 모호성이 남아있음

에이전트가 더 일찍 에스컬레이션을 요청할 수는 있지만, 주변 시스템도 강제로 에스컬레이션을 시킬 수 있어야 함.

내가 점점 선호하는 패턴은 이거임:
에이전트가 복구 제안 → 시스템이 복구가 허용된 재시도/권한 범위 내에 있는지 확인 → 맞으면 재시도 → 아니면 즉시 실패 처리 후 에스컬레이션

이렇게 하면 '끈기 있게 하라'는 명령이 조용히 '뭔가 망가뜨릴 때까지 계속 즉흥적으로 행동하라'로 변질되지 않음.

그리고 모델의 '완료'는 검증해야 할 가설이지 사실이 아니라는 네 말에 전적으로 동의함. 그 구분 하나가 장기적인 자율성을 생각하는 방식을 완전히 바꿔놨음.

나도 그런 접근 방식으로 전환 중임. 아주 좋은 게, 엄격한 계약과 게이트를 두는 것과 함께 실행 시간/토큰/모델 같은 추가 데이터를 채워 넣을 수 있다는 점임. 만약 보내는 에이전트가 스크립트를 사용해 계약을 생성하면, 자기가 아는 것에만 집중하고 스크립트는 추가 세부 정보를 수집할 수 있음. 받는 에이전트도 스크립트를 통해 데이터를 받아 자기 업무에 관련된 것만 처리하게 할 수 있고. 덕분에 모델 A/B 테스트를 하거나 또 다른 에이전트를 사용해 결과를 평가하는 것도 훨씬 쉬워짐.

대체 가능한 작업자 방식의 함정은 재시도임. 대체 작업자가 '이미 시도했던 것'을 집어 들고는, 이전 작업자가 보고하기 전에 죽어버린 비멱등성 작업(전송, 결제, 삭제 등)을 다시 실행해 버리는 거지. 작업 계약에 멱등성 키를 넣고, 작업자가 아니라 도구 계층에서 그걸 강제하고 권한을 확인하게 한 다음, 재시도 가능하다고 표시하기 전에 외부 상태를 다시 읽어오게 해야 함.

맞음. 이건 매우 중요한 실패 모드임.

대체 작업자는 이전 작업자가 '시도했던' 것에 대한 텍스트 요약뿐만 아니라, 작업 계약과 검증된 작업 이력을 상속받아야 한다고 생각함.

비멱등성 작업의 경우 작업자 아래에 다음과 같은 보호 장치를 두고 싶음:

작업 수준의 멱등성 키

• 도구 계층의 강제성
• 내구성 있는 작업 저널
• 재시도 전 외부 상태 재확인