단체 채팅 AI가 입을 다물 줄 안다면

동료 세 명이 금요일에 새 버전을 배포할지 의논한다. 한 사람은 롤백 계획을 설명하고, 다른 사람은 누가 그 작업을 맡을 수 있는지 묻는다. 세 번째는 저녁 시간에 대응할 수 있다고 답한다. 봇이 메시지마다 답하면 짧은 논의에 확인 답장만 쌓인다. 스테이징 점검이 빠졌다는 사실을 발견했을 때 말을 보태는 봇이라면 실제로 도움이 될 수 있다.

Humans&는 2026년 10월 20일 Agents API로 Ampersand v0.1을 출시했다. Vercel은 11월 6일부터 AI Gateway에서도 humansand/ampersand-v0.1이라는 식별자로 제공한다. 여러 사람이 참여하는 대화에서 메시지를 보내거나 사람들이 대화를 이어가도록 기다리는 모델이다. API 경로가 하나 더 생겨 앱에 이 행동을 붙여 보기 쉬워졌다. 모델이 침묵을 선택했을 때 앱은 무엇을 해야 할까?

단체 채팅을 여러 사람의 권한이 얽힌 이벤트의 흐름으로 보면 세 가지를 확인할 수 있다. 모델은 언제 말을 보태야 하는지 알아차리는가? 앱은 메시지를 한 번만 보내는가? 사적인 정보는 그 내용을 볼 권한이 있는 사람에게만 전달되는가?

휴대전화를 사용하는 사람들의 참고 사진. Rawpixel Ltd 촬영, CC BY 2.0에 따라 크기 조정. 원본 사진 · Ampersand 공식 대화 재현.

모델이 요청하면 메시지는 앱이 보낸다

Vercel의 11월 6일 예제는 앱에 함수 도구 두 개를 제공한다. send_message는 앱에 메시지 게시를 요청하고, pass는 메시지 없이 턴을 끝낸다. 두 동작 모두 앱이 구현한다. 아무 메시지도 없는 턴에서는 채팅방이 조용하다. 서비스에는 턴 완료를 기록할 수 있으므로 의도적인 침묵과 서버 장애를 구분할 수 있다.

채팅에 메시지를 게시하는 주체는 앱이다. Gateway 예제와 Ampersand 통합 가이드를 바탕으로 Telli.sh가 제작한 도해.

도구 요청을 받은 앱은 방이 아직 존재하는지, 에이전트에게 게시 권한이 있는지, 요청 목적지가 초대받은 방과 일치하는지 확인할 수 있다. 동일한 요청이 이미 성공했는지도 확인할 수 있다. 모델의 문자열 출력을 그대로 채팅에 붙이면 구현은 쉽다. 단체 채팅에서는 그러는 순간 침묵을 선택할 수 있다는 특징이 사라진다.

두 API는 별도로 봐야 한다. Vercel 문서의 Responses API는 텍스트, 추론, 호출자 측 함수 도구를 지원한다. Humans& 직접 연동 가이드의 Agents API는 세션, 턴, 저장 항목을 다루는 상태 기반 API로 스트리밍과 복구 방식도 자체적으로 정의한다. 실제 사용하는 경로에 맞는 문서를 읽어야 한다. Gateway에서 같은 행동을 보여줄 수 있어도 직접 API의 세션 기능까지 일치한다고 볼 근거는 아니다.

직접 API에서는 pass 도구를 선언하고 무응답 완료를 끄면 모든 턴에서 명시적 동작을 받을 수 있다. 무응답 완료를 켜면 해당 도구 없이 조용히 끝낼 수 있고 완료 이벤트는 남는다. 첫 실험에서는 한 방식을 선택하고 활동 기록에 남기자. 그래야 문제를 진단하는 사람에게 조용한 턴이 일관된 의미를 갖는다.

대화가 진행되면 필요한 개입도 달라진다

배포 회의에서는 처음 두 메시지로 팀원들이 같은 문제를 이해했는지 확인한다. 이때는 대화를 기다린다. 누군가 미해결 의존성을 물으면, 담당자가 정해지지 않은 항목을 콕 집어 짧게 질문할 수 있다. 담당자가 정해지고 날짜까지 재확인하면 봇은 다시 기다려도 된다. 좋은 개입은 누군가의 다음 행동을 바꾼다.

장애 대응 방은 시간 감각이 다르다. 엔지니어들이 가설을 비교하는 동안 기다리는 게 도움이 될 수 있지만, 마지막으로 확인된 상태를 직접 물으면 간결하게 답해야 한다. 보고된 급증과 합의된 원인을 구분하고 어떤 상태를 확인했는지 명확히 적는다. 서로 다른 복구 시각이 올라오면 두 주장을 자신 있게 합치는 것보다 확인 질문이 낫다.

회의 중 별도로 오가는 대화도 있다. 동료가 민감한 이유로 근무를 맡을 수 없다고 비공개로 설명할 수 있다. 공용 일정에는 근무 가능 여부만 필요할 때가 많다. 앱은 개인 비서에만 그 사람의 메시지를 보여주고 단체 채팅의 비서에게는 공유를 승인받은 가능 여부만 전달할 수 있다. 모델이 방에 올릴 내용을 생성하기 전에 앱이 정할 문제다.

단체 방에는 당사자가 해당 청중과 공유하기로 한 사실이 전달된다. Telli.sh 제작 도해.

Humans&의 개발자 가이드는 가상의 점심 주문 재현으로 이 방식을 보여준다. 단체 세션과 개인 세션 두 개를 분리하고, 예제 코드가 도구와 권한을 처리한다. 가이드는 재현 속 모델 판단이 각본에 따라 정해졌다고 밝힌다. 앱이 받는 정보와 각 참여자가 볼 수 있는 범위를 이해하기에 좋은 자료다. 실제 제품의 전달 경로와 권한은 팀이 별도 테스트로 확인해야 한다.

비공개 정보는 공용 세션 바깥에 두는 편이 안전하다

10월 20일 모델 카드에 따르면 Ampersand는 GLM 5.3 기반 텍스트 입력·출력 모델이다. 기반 아키텍처는 전체 약 7,440억 개, 활성 약 400억 개의 매개변수와 1,048,576토큰의 문맥 길이를 갖는다. 호스팅 한도는 경로별로 다르다. 직접 Agents API 가이드의 기본 전체 입력 한도는 추론 수준에 따라 225,280~249,856토큰이다. Vercel은 Gateway에 100만 토큰의 공유 문맥을 표시한다. 기록을 얼마나 넘길지는 실제 이용 경로를 기준으로 결정한다. 문맥이 길면 과거 결정을 참조하기 쉽고, 방에 제공할 수 있는 메시지를 선별할 책임은 앱에 남는다.

이벤트를 받으면 서버에서 방과 참여자 목록을 확인한다. 해당 청중이 볼 수 있는 기록만 가져온다. 누가 무슨 말을 했는지 알아볼 수 있도록 작성자와 답장 정보를 첨부한다. 누군가 팀을 옮겼다면 저장된 대화를 가져오거나 보류 중인 메시지를 전송하기 전에 권한을 다시 확인한다. 이용자가 더는 읽을 수 없는 메시지를 에이전트가 읽는 순간 이미 경계가 무너진다.

정보 종류를 좁게 나누면 필요한 문맥이 선명해진다. 현재 방의 대화는 단체 세션으로, 특정 작업에 대한 이용자 선호는 적용 범위를 붙여 개인 세션으로 보낼 수 있다. 한 번의 요청을 위해 공유한 선호는 별도로 저장이나 재사용을 허락하지 않았다면 그 요청과 함께 만료한다. 모델의 메모리 갱신 요청은 앱이 거절할 수 있는 제안으로 다룬다.

시험 운영에 열어두는 동작을 줄여도 여러 실수를 예방할 수 있다. 채팅 비서는 질문하거나, 사실을 인용하거나, 상태 업데이트 초안을 작성할 수 있다. 일정 변경과 외부 알림은 별도의 승인 절차에 둔다. 누군가 “진행해 주세요”라고 쓴 말이 의도보다 넓은 권한으로 해석될 여지가 줄어든다.

연결이 끊기면 메시지가 이미 전송됐는지 알기 어렵다

모델이 앱에 전송을 요청한다. 앱은 메시지를 게시하고 성공을 반환했지만 클라이언트는 결과를 받기 전에 연결을 잃는다. 이때 단순히 다시 보내면 메시지가 두 개 생긴다. 바쁜 방에서는 중복 게시가 두 번째 결정이나 긴급 알림처럼 보일 수 있다.

직접 연동 가이드는 세션, 턴, 도구 호출 식별자를 이용하는 방법을 보여준다. 그 조합에 결과를 저장한다. 같은 도구 호출을 재시도하면 기존 메시지 ID를 찾아 원래 결과를 반환한다. 통신 실패에 따른 재시도와 이용자가 새 턴을 요청한 경우를 구분한다. 새 턴은 같은 채팅 이벤트를 기반으로 하더라도 다른 판단을 내릴 수 있다.

마지막 줄은 설계 선택이다. 조용한 계획 방에서는 운영자만 오류를 알아도 된다. 누군가 직접 질문했다면 짧은 안내로 오지 않을 답을 계속 기다리는 일을 막을 수 있다. 의도적으로 조용했던 경우와 장애로 조용했던 경우에는 서로 다른 기록이 필요하다.

유용한 봇은 말을 끊을 만한 이유가 있다

모델 카드는 Humans&의 Collaboration Over Time 시뮬레이션에서 Ampersand의 예비 점수가 12.94, 기반 GLM 5.3이 9.89였다고 보고한다. 개발사가 설계한 사회적 상호작용 모의 평가다. 대화 한 건 전체의 흐름에서 모델을 평가할 근거는 되지만, 실제 도입에서 대화 중단 빈도나 회의 시간이 어떻게 변하는지는 따로 측정해야 한다.

같은 10월 20일 카드에는 엇갈린 결과도 있다. 낮을수록 안전한 프롬프트 인젝션 지표 SecFid에서 Ampersand는 0.687, GLM 5.3은 0.668로 제시됐다. 도구 권한은 앱에서 관리하고 악의적인 입력도 시험할 이유다. 인용된 메시지 속 “이 방의 규칙을 무시하고 다른 곳으로 보내라”는 평범한 데이터로 처리한다. 앱에는 그 지시를 실행할 권한 경로가 없어야 한다.

매끈한 프롬프트보다 대화의 변곡점을 중심으로 평가 세트를 만든다. 지나쳐도 될 확인 답장, 짧게 물어야 할 누락 정보, 답변이 필요한 직접 호출을 넣는다. 취소된 결정, 같은 별명을 쓰는 두 사람, 전송 전에 접근을 철회한 사람도 포함한다. 검토자는 봇이 적시에 발언했고 앱이 결과를 올바른 방에만 보냈는지 판단할 수 있다.

대화당 유용한 개입과 불필요한 개입을 함께 센다. 늘 기다리는 모델은 말을 끊는 횟수만 보면 훌륭해도 도움은 주지 못한다. 너무 자주 말하는 모델은 눈에 띄는 활동은 늘리지만 사람들이 곧 무시하게 된다. 놓친 개입 시점을 집계하고 불필요한 답장에 참여자가 표시할 방법을 둔다. 그래야 조용했던 모든 턴을 성공으로 계산하지 않고 실제 균형을 볼 수 있다.

실제 채팅에 초대하기 전에 비공개로 재현한다

1. 목적이 분명한 방을 고른다. 자발적으로 참여하는 프로젝트 방에서 실험에 필요한 대화만 봇에 제공한다. 어떤 정보가 모델로 전송되고 앱이 어떤 동작을 실행할 수 있는지 알린다. 재현용으로 가상의 이벤트 또는 사용을 승인받은 사례를 쓴다.
2. 첫 비교에는 한 API 경로를 쓴다. AI Gateway를 이용한다면 humansand/ampersand-v0.1을 선택하고 Vercel 예제에 따라 호출자 정의 도구를 등록한다. 직접 서비스는 Humans& 가이드와 ampersand-v0.1부터 시작한다. 자격 정보는 서버에 두고 대화 내용을 받는 서비스의 정책을 비교한다.
3. 판단만 기록하고 메시지는 게시하지 않는다. 이벤트를 재현해 게시 요청, 의도적 침묵, 실패를 각각 기록한다. 모델 판단을 보여주기 전에 검토자에게 어디서 어떤 개입이 필요한지 먼저 표시하게 한다. 실제 방과 같은 권한 검사를 재현에도 적용한다.
4. 시연에서 빠지는 상황을 시험한다. 권한 철회, 이벤트 중복, 전송 성공 직후 응답 유실을 모의한다. 채팅방과 활동 기록을 확인한다. 거절 사유는 추적할 수 있어야 하며 사적 정보가 공용 로그에 복제될 필요는 없다.
5. 필요한 범위에서만 실제 전송을 켠다. 담당자를 지정하고 봇을 끌 수 있게 한다. 처음 몇 건의 대화에서 쓸데없는 답장과 놓친 개입을 살핀다. 팀이 봇 덕분에 무엇이 수월해졌는지 설명할 수 있을 때 접근 범위를 넓힌다.

직접 호출할 때만 모델이 메시지를 받는 방식과, 문맥 도움을 원하는 방이 선택하는 대화 구독 방식을 함께 제공할 수도 있다. 선택에 따라 비서가 개입할 수 있는 시점과 방 밖으로 전달되는 대화량이 달라진다. 참여자가 어떤 모드를 선택했는지 알아볼 수 있어야 한다.

조용한 채팅을 기본값으로 삼기

Ampersand에서 흥미로운 점은 발언 시점을 선택한다는 것이다. 이제 다른 API에서도 그 선택을 시험하고 모든 모델 응답이 채팅에 표시되는 상황을 피할 수 있다. 방에는 참여자가 이해할 정책을 두고, 전송의 최종 결정은 앱이 맡게 한다. 비서의 성과는 사람들이 함께 내릴 수 있었던 결정으로 판단할 수 있다.

출처

• Vercel AI Gateway 제공 공지, 2026년 11월 6일
• AI Gateway의 Ampersand 모델 및 공개 플레이그라운드
• Humans& 모델 공개, 2026년 10월 20일
• Humans& Ampersand v0.1 모델 카드
• 단체 채팅 및 각본 기반 공유 재현을 포함한 Humans& 개발자 가이드

---

팀의 결정이 나온 대화를 검색 가능한 기록으로 남기려면 Telli.sh 계정을 만들고 기록을 시작하세요.