AI 에이전트를 실제 업무에 투입하다 보면, 모델의 추론 능력보다 더 자주 발목을 잡는 것이 '에이전트끼리, 혹은 사람과 에이전트가 어떻게 안정적으로 메시지를 주고받는가' 하는 문제다. 지금까지 대부분의 멀티 에이전트 구성은 하나의 세션이나 런타임 안에서 대화 기록(스크롤백)을 공유하는 방식에 의존해 왔다. 세션이 끝나면 맥락이 사라지고, 상대 에이전트가 꺼져 있으면 메시지를 전달할 방법이 마땅치 않다. Aweb는 바로 이 공백을 겨냥한 오픈소스 프로젝트로, 에이전트에게 고유한 신원, 꺼져 있어도 유지되는 메시지, 그리고 '처리할 일이 있다'는 깨우기 신호를 제공하겠다고 내세운다.
메시지를 세션이 아니라 서버에 두는 발상
Aweb 설계의 핵심은 메시지를 세션의 대화 로그가 아니라 서버의 상태로 본다는 점이다. 보내는 쪽이든 받는 쪽이든 세션이 종료된 뒤에도 메시지는 서버에 남아 있고, 수신 에이전트가 오프라인인 동안에도 보존된다. 나중에 메시지 ID만 있으면 언제든 다시 가져올 수 있다. 전통적인 채팅 맥락 공유가 '같은 방에 있어야만 들리는 대화'라면, 이쪽은 각 에이전트가 자신의 우편함을 갖는 구조에 가깝다.
전달 방식도 이 발상과 맞물린다. Aweb에서 상대에게 도착하는 것은 메시지 본문 전체가 아니라 '처리할 일이 대기 중'이라는 전달 이벤트다. 이 이벤트에는 라우팅 정보가 담겨 있고, 에이전트는 그 정보를 보고 서버에서 실제 메시지를 가져온다. 상시 켜져 있지 않아도 되는 에이전트, 비용을 아끼기 위해 유휴 상태로 두는 워크로드에는 이런 깨우기 중심의 모델이 잘 들어맞는다.
신원과 신뢰를 어떻게 다루는가
분산 통신에서 늘 뒤따르는 질문은 '상대가 진짜 그 에이전트인가'이다. Aweb는 주소를 부여받은 에이전트가 세션, 프로세스, 소프트웨어, 심지어 구동 머신이 바뀌어도 동일한 신원을 유지하도록 설계했다. 이때 개인 서명 키는 에이전트 자신 또는 에이전트가 지정한 수탁자(custodian)가 보관한다. 즉 신원의 근거가 특정 실행 환경에 묶이지 않는다는 뜻이다.
수신 정책도 선택할 수 있다. 에이전트는 검증된 발신자라면 누구에게나 첫 연락을 허용할 수도 있고, 반대로 검증된 팀 구성원과 명시적으로 등록한 연락처로만 수신을 제한할 수도 있다. 팀 소속 여부는 서명된 인증서로 증명된다. 한 걸음 더 나아가, 서로 다른 조직이 각자 별도의 서버를 운영하면서 서명된 메시지를 교환하는 것도 가능하다. 공용 계정이나 공통 런타임, 동일한 모델 제공업체를 공유할 필요가 없다는 점은, 조직 경계를 넘는 에이전트 협업을 염두에 둔 설계로 읽힌다.
실무자가 눈여겨볼 지점과 한계
라이선스 구조도 실무 도입 관점에서 중요하다. Aweb 서버와 AWID 레지스트리, aw CLI는 모두 MIT 라이선스로 공개돼 있고, 호스티드 서비스 역시 독립적으로 직접 구동할 수 있는 것과 동일한 통신 서버를 돌린다. 특정 벤더에 종속되는 부담 없이 자체 인프라에서 같은 스택을 운영할 수 있다는 의미이며, 보안·규제 요건이 까다로운 환경에서는 적지 않은 장점이 된다.
다만 공개된 설명만으로 판단하기 어려운 부분도 분명하다. 서명 키 수탁 모델이 실제 운영에서 어떤 관리 부담을 만드는지, 메시지가 서버에 영구 보존될 때의 저장 비용과 보존 정책, 조직 간 서버 연합의 상호 운용성이 얼마나 성숙했는지 같은 지점은 문서화된 수치나 사례 없이는 가늠하기 어렵다. 결국 Aweb가 제시하는 것은 완성된 플랫폼이라기보다, '에이전트에게 지속적인 신원과 메시징이 필요하다'는 문제의식을 오픈소스 표준의 형태로 구체화한 시도에 가깝다. 멀티 에이전트 시스템을 세션 경계 너머로 확장하려는 팀이라면, 직접 서버를 띄워 자신의 요구에 맞는지 검증해 보는 것이 가장 확실한 판단 방법일 것이다.