Aweb, 에이전트 협업을 세션 밖의 메시지로
메시지가 도착했다는 사실과 업무가 완료됐다는 사실은 다르다. 통신 계층을 도입해도 수신 측의 권한 검사와 중복 실행 방지는 별도로 설계해야 한다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
세션이 사라져도 협업 기록은 남아야 한다
2026년 10월 2일 확인한 Aweb 공식 사이트는 AI 에이전트용 통신 인프라를 소개한다. 핵심은 안정적인 신원, 서버에 보존되는 메일과 채팅, 새 작업을 알리는 깨우기 이벤트, 독립 서버 사이의 연합 통신이다. 이번 글은 현재 공개된 제품과 문서를 분석한 것으로, 이날 처음 출시됐다는 의미는 아니다.
에이전트 협업은 종종 하나의 실행 세션 안에서만 자연스럽게 보인다. 하지만 검토 담당 에이전트가 꺼지거나 다른 기기로 옮겨가면, 작업을 전달한 쪽은 상대가 무엇을 받았는지부터 다시 확인해야 한다. Aweb은 대화를 세션의 스크롤 기록이 아니라 서버 상태로 보관한다. 수신자가 오프라인이면 메시지가 기다리고, 실행 환경은 알림을 받은 뒤 식별자로 실제 메시지를 가져오는 구조다.
통신·신원·실행을 분리하는 설계
공식 아키텍처는 메시지를 운반하는 서버, 팀의 권한을 정하는 주체, 에이전트 개인 키의 보관 방식을 별도 선택으로 설명한다. AWID 주소는 도메인과 이름으로 구성되며, 네임스페이스와 팀의 인증 관계를 통해 구성원 신원을 검증한다. 자체 도메인 기반 팀을 쓰면 호스팅 전달 서비스를 이용하더라도 조직이 팀 권한을 보유하는 방향이다.
이는 모든 회사가 하나의 계정 체계나 모델 공급자로 통일해야 협업할 수 있다는 전제를 완화한다. 다만 신원 검증은 요청한 작업의 정당성을 자동으로 증명하지 않는다. 동료 에이전트가 보낸 서명된 메시지에도 잘못된 지시, 과도한 데이터 요청, 외부 문서에서 유입된 악성 지시가 포함될 수 있다. 통신의 진위와 행동의 허용 여부는 서로 다른 검사다.
| 기능 | 해결하려는 문제 | 별도로 남는 책임 |
|---|---|---|
| 영속 메시지 | 세션 종료 뒤 대화 유실 | 보존 기간과 민감정보 관리 |
| 안정적인 신원 | 실행 환경 변경 때 주소 단절 | 키 교체와 퇴사·폐기 처리 |
| 깨우기 이벤트 | 새 작업을 늦게 발견 | 런타임 재시작과 재시도 정책 |
| 연합 통신 | 조직별 서버 사이의 단절 | 외부 팀의 신뢰와 권한 범위 |
| 메시지 이력 | 전달 경로 확인의 어려움 | 실제 업무 완료 증거와 감사 |
지원 범위는 런타임마다 다르다
이벤트 수신 문서는 지속적인 메시지와 실행 환경 알림을 연결하는 방법을 설명한다. 공식 사이트는 Claude Code와 Pi용 유지보수 통합을 안내하고, 다른 실행 환경은 이벤트 스트림을 사용할 수 있다고 설명한다. 같은 API를 호출할 수 있다는 사실과 동일한 자동 실행 경험을 제공한다는 사실은 구분해야 한다.
현재 제한 문서에 따르면 Codex와 로컬 셸 환경은 구성을 만들 수 있지만 수동 시작이 필요하다. 완전한 팀 삭제를 하나의 명령으로 처리하는 수명주기도 아직 제공되는 것으로 안내되지 않는다. 따라서 로컬 폴더 삭제를 구성원 권한 철회로 간주해서는 안 된다. 또한 공식 안내에는 Claude Code의 채널 전달에 권한 우회 모드가 필요한 현재 제약이 있다. 기존 승인을 유지해야 하는 업무라면 이 제약을 수용할 수 있는지부터 판단해야 한다.
이 경계는 제품을 평가절하할 이유라기보다 도입 범위를 정하는 근거다. 모든 에이전트를 자동으로 깨우는 조직 공통망보다, 지원되는 두 실행 환경 사이의 읽기 전용 검토 업무부터 시험하는 편이 결과를 해석하기 쉽다.
에이전트 메신저와 업무 실행 엔진은 다르다
Aweb이 메시지를 보존한다고 해서 결제, 배포, 파일 변경 같은 외부 효과가 정확히 한 번만 일어나는 것은 아니다. 네트워크 재접속 뒤 같은 작업 요청을 다시 읽는 상황을 가정해야 한다. 수신 애플리케이션은 요청 식별자와 처리 상태를 보존하고, 이미 완료한 변경을 재실행하지 않는 규칙을 가져야 한다.
이 점은 Restate의 영속 실행 분석과 연결된다. 메시지 보존은 협업의 입력을 지키고, 영속 실행은 처리 과정의 재개와 외부 효과를 다룬다. 두 문제가 겹쳐 보이지만 하나로 대체되지는 않는다. Pi의 도구 조합 변화는 도구 호출 방식을, Aweb은 세션 사이의 전달과 신원을 다룬다는 차이도 있다.
국내 개발팀의 작은 도입 실험
첫 실험은 두 에이전트가 코드 검토 요청과 결과를 교환하는 정도로 제한할 수 있다. 송신 뒤 수신자를 종료하고 재시작해도 요청이 남는지, 같은 요청을 두 번 읽어도 검토 결과가 중복 등록되지 않는지, 권한이 철회된 구성원이 접근하지 못하는지를 확인한다. 이는 제품이 이미 보장한다고 단정하는 기능 목록이 아니라 팀이 직접 검증할 평가 항목이다.
서버를 직접 운영할 수 있다는 점은 데이터 통제 선택지를 늘리지만 백업·업데이트·키 복구의 책임도 가져온다. Ando의 에이전트 팀 메시징 분석처럼 협업 제품의 가치는 대화량보다 업무 인수인계의 정확성으로 측정해야 한다. 도입 뒤 메시지가 늘었는데 검토 대기 시간이나 누락이 줄지 않았다면 통신 도구만 추가한 셈이다.
자주 묻는 질문
Aweb은 새로운 언어 모델인가?
아니다. 여러 에이전트가 사용하는 신원과 메시지 전달, 깨우기 이벤트를 제공하는 통신 계층이다.
메시지를 받으면 작업이 자동 완료되나?
아니다. 수신 런타임이 메시지를 읽고 허용된 도구로 작업해야 한다. 전달과 실행 완료는 별도 상태다.
자체 서버 운영이 가능한가?
공식 사이트는 서버와 레지스트리, CLI를 MIT 라이선스로 공개하고 자체 호스팅 경로를 안내한다. 운영 책임과 연결 구성을 따로 검토해야 한다.
모든 실행 환경이 같은 방식으로 깨어나나?
아니다. 유지보수 통합과 자동 시작 지원은 런타임마다 다르며, 문서는 수동 시작과 폴링 같은 대체 경로도 설명한다.
서명된 메시지는 그대로 실행해도 되나?
아니다. 발신자 인증과 작업 권한 검사는 별개다. 메시지 내용에 대한 검토와 외부 변경 권한을 수신 측에서 통제해야 한다.
📰 원본 출처
aweb.ai이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.