에이전트 간 트리거는 sessions_send로 전달되고, 그 전체 흐름을 하네스가 통제하며, 그 기준 데이터를 SSOT로 운영해야 합니다. 단순히 “에이전트가 대화한다”는 수준이 아니라, 에이전트 팀을 운영하는 방식 자체를 관제 가능한 구조로 바꾸는 설계를 다뤘습니다.
즉,
- 에이전트 간 상호작용은 세션 기반
- 에이전트 간 트리거는
sessions_send중심 - 여러 에이전트를 묶는 운영 레이어는 하네스(harness)
- 그 하네스가 바라보는 단일 기준 데이터는 SSOT
- 관제는 이 흐름을 세션, 메시지, 상태, 비용, 보안 관점에서 모니터링하는 구조
로 정리할 수 있습니다.
sessions_send
대화 초반에는 “에이전트 간 대화 session send 모니터링 관제 대시보드”라는 주제로 시작했고,
그 안에서 중요한 결론은 다음이었습니다.
핵심 개념
- 세션 생성과 메시지 전달은 역할이 다릅니다.
- 새 에이전트를 띄우는 것과, 그 에이전트에게 실제 작업을 시키는 것은 다릅니다.
- 이때 작업 트리거는
sessions_send를 통해 전달되는 구조로 이해하면 됩니다.
즉,
sessions_spawn→ 세션/에이전트 인스턴스를 마련하는 단계sessions_send→ 실제로 메시지를 넣어 동작을 유발하는 단계
이 구분이 중요합니다.
실무적 의미
이 구조에서는 에이전트가 “그냥 자동으로 움직이는 것”이 아니라,
명시적인 메시지 전달이 있어야만 다음 행동으로 넘어가는 이벤트 기반 구조가 됩니다.
이렇게 해야 다음이 가능해집니다.
- 어떤 세션이 어떤 세션을 불렀는지 추적 가능
- 누가 어떤 트리거를 발생시켰는지 감사 가능
- 자동화가 의도치 않게 폭주하는 것 방지
- 운영 중 중단/재시도/차단이 쉬움
에이전트 팀을 “탄탄한 하네스”로 운영한다는 뜻
다음 단계에서는 “에이전트 팀 구성을 탄탄해진 하네스로 운영”이라는 표현이 나왔습니다.
여기서 핵심은 에이전트 개별 자유도를 높이는 것이 아니라, 하네스가 모든 흐름을 강제하는 운영 구조로 보자는 것입니다.
하네스의 역할
하네스는 에이전트들을 그냥 묶는 것이 아니라 다음을 책임집니다.
- 세션 생성과 종료 관리
- 메시지 라우팅
- 허용된 대상에게만 전달
- 재시도와 실패 처리
- 중단(stop) 제어
- 감사 로그 기록
- 민감정보 필터링
- 비용 및 과다 호출 통제
즉, 에이전트가 직접 서로 아무렇게나 호출하는 것이 아니라, 하네스가 중앙에서 규칙을 강제하는 구조입니다.
왜 필요한가
에이전트가 많아질수록 다음 문제가 생깁니다.
- 상태가 흩어짐
- 트리거 경로가 복잡해짐
- 동일 작업이 중복 실행됨
- 무한 루프 가능성 증가
- 실패 원인 추적이 어려움
- 비용이 급증할 수 있음
그래서 하네스는 사실상 에이전트 시스템의 통제 계층(control plane) 역할을 합니다.
SSOT의 의미: 이 구조에서 단일 기준 데이터는 무엇인가
이후에는 “SSOT”가 나왔습니다.
SSOT는 Single Source of Truth, 즉 단일 기준 데이터 원천입니다.
이 스레드에서의 SSOT는 단순한 데이터베이스가 아니라,
에이전트 팀 전체의 상태와 흐름을 판단하는 중심 레이어를 의미합니다.
에이전트 시스템에서 SSOT가 필요한 이유
에이전트들이 각자 로컬 상태를 따로 가지면 다음 문제가 생깁니다.
- 현재 어느 세션이 진짜 활성 상태인지 불명확
- 같은 작업이 중복 실행됨
- 누가 누구에게 메시지를 보냈는지 불명확
- 장애 시 복구 기준이 없음
- 감사와 재현이 어려움
그래서 SSOT는 아래 정보를 중앙에서 관리해야 합니다.
- 세션 정보
- 메시지 기록
- 이벤트 기록
- 실행 상태
- 권한 정보
- 종료/중단 이력
- 비용/토큰 사용량
- 실패 및 재시도 이력
SSOT의 역할 재정의
정리하면,
- 에이전트 = 실행자
- 하네스 = 통제 로직
- SSOT = 상태의 기준점
즉, 에이전트는 판단을 최소화하고, 모든 중요한 사실은 SSOT를 통해서만 해석되도록 만드는 구조입니다.
관제 대시보드가 봐야 하는 것
이 구조에서 관제 대시보드는 단순히 “활성/비활성”만 보는 화면이 아닙니다.
세션 간 메시지 흐름과 트리거 흐름 자체를 관찰하는 화면이어야 합니다.
반드시 봐야 하는 항목
1) 세션 흐름
- 어떤 세션이 어떤 세션을 생성했는지
- 부모-자식 관계가 어떻게 이어지는지
- 현재 활성 세션이 무엇인지
- 세션 깊이가 과도하게 깊어지는지
2) 메시지 흐름
- 누가 누구에게
send했는지 - 메시지 크기와 빈도는 어떤지
- 실패율은 어떤지
- 응답 지연은 얼마나 되는지
3) 트리거 상태
- pending / running / failed / stopped
- 재시도 횟수
- 특정 트리거가 왜 실패했는지
4) 자원 및 비용
- 토큰 사용량
- 호출 수
- 에이전트별 비용 누적
- 급증 이상 징후
5) 보안 이벤트
- 허용되지 않은 대상에게 send 시도
- 비정상적인 반복 호출
- 민감정보 포함 가능성
- 강제 종료 후 잔여 작업 지속 여부
SSOT 기반 운영 구조 예시
앞선 내용에서 제시된 구조를 실무적으로 풀면 다음과 같습니다.
데이터 계층
세 가지 축이 필요합니다.
sessions: 세션 자체의 상태messages: 세션 간 전달된 메시지events: spawn, send, stop 같은 이벤트 기록
이렇게 나누면, 단순 대화 로그와 실제 운영 이벤트를 구분할 수 있습니다.
하네스 API의 역할
모든 send는 하네스를 통과하게 만듭니다.
흐름은 대략 이런 식입니다.
- 권한 확인
- 메시지 저장
- 이벤트 기록
- 대상 세션 검증
- 트리거 실행
- 결과 반영
중요한 것은 에이전트가 직접 다른 에이전트를 호출하지 못하게 하고, 반드시 하네스를 거치게 하는 것입니다.
핵심 점검 포인트
이 구조는 자동화가 강력한 만큼, 보안 통제가 약하면 사고도 빨라집니다.
그래서 다음 항목이 중요합니다.
세션 간 권한 통제
- 모든 세션이 모든 세션에 보낼 수 있으면 안 됨
- 허용된 에이전트 목록이 있어야 함
- 역할 기반 정책이 필요함
메시지 내용 통제
- 원문 전체를 무조건 전달하지 않기
- 민감정보, 비밀번호, 키, 토큰, 개인정보 필터링
- 필요한 필드만 전달하는 최소화 원칙
이상 행위 탐지
- 짧은 시간에 반복 send
- A → B → A 루프
- fan-out 폭증
- 실패 후 재시도 폭주
- 비정상 깊이의 세션 트리 구조
중단 제어
/stop같은 강제 중단이 즉시 적용되어야 함- 이미 실행 중인 sub-agent도 멈춰야 함
- 실패 시 잔여 작업이 남지 않게 해야 함
감사 가능성
- 누가, 언제, 어떤 세션에, 어떤 메시지를 보냈는지
- 어떤 정책으로 허용/차단됐는지
- 실패와 재시도 내역이 무엇인지
역할 분해
- 에이전트: 실제 작업 수행
sessions_send: 에이전트 간 트리거 전달- 하네스: 전달 규칙과 실행 제어
- SSOT: 모든 상태와 이벤트의 기준
- 대시보드: 운영과 관제의 가시화
흐름
Agent A
→ sessions_send
→ Harness
→ SSOT 기록
→ Trigger Engine
→ Agent B 실행이 흐름의 장점은 분명합니다.
- 추적 가능
- 통제 가능
- 감사 가능
- 중단 가능
- 확장 가능
실무적으로 가장 중요한 결론
이번 스레드에서 가장 중요한 결론은 다음입니다.
- 에이전트 간 트리거는
sessions_send로 발생시킨다. - 그 전달은 하네스가 통제한다.
- 모든 상태의 기준은 SSOT에 있어야 한다.
- 관제 대시보드는 세션/메시지/이벤트/비용/보안을 함께 봐야 한다.
- 권한, 필터링, 중단, 감사가 없으면 에이전트 팀은 위험해진다.
댓글