SpacebarBench가 지속형 협업 작업공간에서 에이전트를 평가했다

SpacebarBench: 공유 화이트보드에서 에이전트 평가

지속되는 작업의 벤치마크

SpacebarBench는 하나의 공유 작업공간에서 14개 요청을 거치며 바뀌는 재무 모델을 에이전트가 얼마나 일관되게 관리하는지 평가한다. 2026년 10월 벤치마크에는 모델 구성 6개가 참여했고, 최종 결과물은 100점 기준으로 감사했다. 실행 시간은 누적 실행 시간이며 점수는 통계적 모델 순위가 아니라 제출된 결과물을 평가한다.

첫 답변 뒤에도 이어지는 작업

가격 페이지 세 개를 열어 나란히 놓고 비교할 수 있게 해 주세요. 계속 열어 두세요. 나중에 다시 필요합니다.

벤치마크는 일부러 평범한 요청에서 시작한다. 고객 지원 소프트웨어를 평가하는 사람은 보통 프로젝트에 필요한 모든 공식, 차트, 위험 메모, 구매 규칙을 처음부터 지정하지 않는다. 먼저 질문하고, 찾은 내용을 살핀 뒤, 작업을 발전시킨다.

평가 대상은 계속 변화하는 프로젝트다. 뒤이은 요청은 이전 결과물을 물려받으므로, 답변이 맞더라도 보존된 작업이 서로 모순되면 충분하지 않다.

벤치마크는 Intercom, Zendesk, Freshdesk 세 고객 지원 플랫폼을 비교해 예산과 추천안을 준비하는 하나의 프로젝트를 따른다. 14개 요청은 같은 작업을 이어서 수정한다.

한눈에 보는 작업 흐름. 각각 새로 시작하는 과제가 아니라 하나의 작업공간에서 연속으로 주어지는 요청이다.

이 단계에서는 최신 메시지에 답하는 것만으로는 부족하다. 에이전트는 적절한 기존 결과물을 찾아 제자리에서 수정하고, 여전히 유효한 가정을 보존하며, 스프레드시트와 대시보드와 메모가 같은 내용을 말하는지 확인해야 한다. 채팅에 올바른 문단을 쓰더라도 오래된 차트는 고쳐지지 않는다. 추천이 잘못된 수식에 기대고 있다면 세련된 메모만으로는 충분하지 않다.

이 연구가 살피려는 변화는 에이전트가 사람에게 결과물을 돌려주는 단계에서, 사람들이 이미 일하는 작업공간에 참여하는 단계로의 이동이다.

Spacebar에서 에이전트는 브라우저 뷰어, 문서, 스프레드시트, 대화형 앱이 있는 지속형 협업 캔버스 안에서 일한다. 이들은 대화 끝에 첨부되는 파일이 아니라 함께 쓰는 작업 객체다. 대화 초기에 연 뷰어를 나중에 다시 열 수 있고, 가정이 바뀌는 동안 스프레드시트를 보드에 둘 수 있다. 앱은 공유 시나리오 선택값을 유지하며, 에이전트가 이를 조작하고 확인할 수 있다.

이 작업흐름의 대화형 애플리케이션은 Mario 앱이다. 에이전트가 동적으로 만들고 Spacebar 자체에서 호스팅하며 Spacebar와 같은 동기화 계층을 사용하는 맞춤형 협업 애플리케이션이다. 벤치마크에서 에이전트는 공급업체 및 시나리오 선택기, 편집 가능한 가정, 비용 차트, 추천 영역을 갖춘 CX Vendor Decision Lab을 만든다. 선택값과 편집 가능한 가정은 공유 앱 상태에 저장되므로, 앱은 채팅 끝에 전달되는 정적 대시보드가 아니라 협업자가 함께 쓰는 도구가 된다.

따라서 성공의 의미도 달라진다. 에이전트가 유용한 결과물을 만들 수 있는지만 묻는 것이 아니다. 지시와 증거와 결정이 바뀌어도 작업을 유용하게 유지할 수 있는지를 묻는다.

이 환경의 중요한 특성은 사람과 에이전트가 같은 지속형 객체에서 일할 수 있다는 점이다. 같은 브라우저 뷰어를 참조하고, 같은 통합 문서를 살피며, 같은 협업 앱을 사용할 수 있다. 팀이 작업을 이용하려면 에이전트 전용 환경에서 복사해 나와야 하는 것은 아니다.

객체를 공유한다고 해서 모든 저수준 상호작용까지 공유하는 것은 아니다. 구현에서 에이전트는 브라우저 제어, 보드 도구, Google Workspace 도우미를 사용할 수 있다. 사람은 화면에 보이는 애플리케이션 인터페이스로 조작한다. 양쪽 모두 공유 작업 결과물을 다루지만, 에이전트가 사람의 모든 마우스 클릭을 그대로 재현해야 하는 것은 아니다. 이 벤치마크는 배포된 에이전트와 도구를 평가하며, 시각 입력만 사용하는 컴퓨터 조작 시스템을 평가하지 않는다.

공유 객체와 서로 다른 상호작용 경로. 이는 작업공간의 상호작용 모델과 파일럿의 범위를 설명하며, 시각 입력만 쓰는 시스템이나 여러 사람이 동시에 참여하는 실험을 뜻하지 않는다.

이 구분은 새로움에 관한 주장을 정확하게 한다. 사람과 에이전트의 협업에는 선행 사례가 있다. 마이크로소프트의 Magentic-UI는 협업형 브라우저 실행을 지원하고, 협업 문서 편집 연구는 여러 사용자가 참여하는 글쓰기 환경에 AI 에이전트를 포함했다. 이 연구는 지속형 뷰어, 네이티브 문서와 스프레드시트, 공유 상태를 가진 대화형 앱, 그리고 여러 결과물에 반영해야 하는 수정을 결합하는 데 초점을 둔다. Magentic-UI, Collaborative Document Editing with Multiple Users and AI Agents.

더 넓은 작업공간은 협업을 지원하지만, 이번 파일럿이 시험한 범위는 더 좁다. 변화하는 세션에서 스크립트로 정해진 사용자 메시지 한 줄기를 전달한다. 사람의 동시 편집, 여러 참여자의 상충하는 지시, 팀과 에이전트의 협업 능력은 측정하지 않는다. 중요한 후속 실험 대상이지, 이번 결과로 입증된 사항은 아니다.

표 1 설명: 환경은 이번 첫 파일럿에서 측정한 범위보다 더 넓은 형태의 협업을 지원한다.

14개 요청으로 이어지는 하나의 프로젝트

고객 지원 플랫폼 평가는 조사, 계산, 발표, 의사결정을 연결하면서 어느 한 단계만으로는 충분하지 않다는 점에서 선택됐다. 사용자는 가상의 2027년 지원 운영을 위해 Intercom, Zendesk, Freshdesk를 비교한다. 상업 정보는 공급업체의 실시간 페이지에서 가져오며, 공개되지 않은 가격은 기억에 의존해 채워 넣지 않고 미확인으로 남겨야 한다.

작업흐름은 1월 정규 상담원 42명, 매달 두 명씩 증가, 경량 사용자 18명, 월간 지원 대화 55,000건, AI가 해결한 결과 6,000건에서 시작한다. 대화량은 처음에 월 3%, AI 해결 건수는 4%씩 증가한다. 예산에는 10% 예비비를 적용한다. 뒤이은 메시지에서 가정과 제약 조건이 바뀐다.

14개 메시지는 다섯 단계로 나뉜다.

• 조사와 모델 작성, 1~4턴: 가격 뷰어를 열어 보존하고 요금제를 해석한 뒤, 예산 통합 문서와 수식 기반 월별 예측을 만든다.
• 새 증거와 가정 수정, 5~8턴: 출처를 추가하고 기존 뷰어를 찾아 이동하며 결제 정보를 조정한다. 재무팀 변경을 반영하고 계절성과 시나리오를 추가한다.
• 발표와 공유 상호작용, 9~11턴: 통합 문서 서식을 다듬고 연결 차트를 추가한다. 의사결정 앱을 게시한 다음 공유 선택값과 상태를 바꾸고 다시 읽어 확인한다.
• 의사결정 전달, 12턴: 통합 문서와 앱에 맞는 CFO 메모를 작성한다.
• 후반 변경, 13~14턴: 유지 지침을 반영하고 최종 구매 규칙을 기존 결과물 전반에 적용한다.

이 과제들은 서로 독립적인 14번의 시도가 아니다. 뒤이은 요청은 이전 작업을 물려받는다. 기존 대시보드를 수정하라는 요청에 새 대시보드를 만들어도 겉보기에는 좋아 보일 수 있지만 지시를 어길 수 있다. 잘못된 뷰어로 이동하면 유용한 맥락이 사라질 수 있다. 뒤늦은 수정이 앞서 올바르게 계산한 내용을 망칠 수도 있다.

그림 2. 지속형 결과물에 요청된 작업. C는 생성 또는 추가, R은 읽기·조작·수정을 뜻한다. 이는 작업흐름 설계이며 모든 실행에서 각 작업이 완료됐다는 주장은 아니다.

최종 구매 지시는 결과물 간 의존성을 분명히 드러낸다. 문서화된 할인이 10% 이상일 때만 연간 결제를 사용하고, 그렇지 않으면 월간 결제를 모델링하며, 공개되지 않은 할인은 추정하지 말아야 한다. 에이전트는 가격 증거를 확인하고 선택된 요율을 바꾸며, 통합 문서가 재계산되도록 하고, 앱을 수정하고, 메모와 대조해야 한다. 필요한 가격이 여전히 미확인이라면 숫자로 순위를 매기는 것이 정당하지 않을 수 있다.

그림 3. 최종 구매 요청은 기존 결과물 곳곳에 필요한 확인 절차를 만든다. 이 순서는 에이전트가 수행해야 할 작업을 나타내며 통합 문서, Mario 앱, 메모가 자동으로 동기화된다는 뜻은 아니다. 공개되지 않은 가격은 0으로 조용히 바꾸지 말고 미확인으로 남겨야 한다.

남겨진 결과물을 점검한다

에이전트의 대화 기록은 에이전트가 무엇을 시도했고 사용자에게 무엇이라고 말했는지를 보여준다. 하지만 실제로 무엇이 존재하는지를 확인하는 증거로는 충분하지 않다.

결과물 우선 감사에서는 제출된 통합 문서와 문서, 보드의 객체 목록, 가능한 경우 앱의 소스 또는 상태, 실행 추적을 살핀다. 스프레드시트에서는 보이는 서식뿐 아니라 수식과 계산 결과도 확인한다. 문서에서는 추천이 근거를 갖췄는지, 읽기 쉬운지 점검한다. 앱에 선택기를 구현하는 것과 선택값을 성공적으로 저장하는 것은 별개의 확인 항목이다. 둘 중 어느 하나만으로 협업자에게 최종 화면이 올바르게 표시된다고 입증되지는 않는다.

기존 평가 기준은 6개 범주에 총 100점을 배분한다.

이 점수는 판단에 기반한 감사 점수이지 성공 확률이 아니다. 84점은 에이전트가 업무 과제의 84%를 성공한다는 뜻이 아니다. 단 한 번의 실행에서 나온 작은 점수 차이를 확립된 능력 격차로 해석해서도 안 된다.

결함과 검증 불가도 구분해야 한다. 렌더링 도구가 실패하면 앱의 외관을 확인하지 못할 수 있지만, 그렇다고 인터페이스가 고장 났다고 입증되는 것은 아니다. 상업 가격을 확인할 수 없다면 합계를 미결 상태로 남기는 것이 올바른 대응일 수 있다. 반대로 데이터 모델에는 미확인으로 저장해 놓고 화면에 0으로 표시하면 독자를 오도할 수 있다.

6개 모델의 결과

Spacebar의 14개 메시지 CX 작업흐름에서 6개 모델 구성이 만든 최종 결과물을 평가했다. 결과는 2026년 10월 7~8일 기록과 고정된 100점 평가 기준을 사용한다. 추론 설정을 명시했으며, 같은 노력 수준 표시가 공급업체 간 동일한 연산 예산을 뜻하지는 않는다.

표 3. 실행 시간은 평가 결과에 기여한 측정 실행 시간의 합이며, 실행 이력 안에서 실패한 작업도 포함한다. 비활성 대기 시간, 프로비저닝, 결과물 내보내기는 제외한다. 점수는 최종 보존 결과물을 평가하며 첫 시도의 신뢰성 순위가 아니다.

그림 4. 점수는 설명적이며 블라인드 처리하지 않은 결과물 검토에서 나왔다. 감사 범주별 점수 범위의 하한을 사용해 명확한 근거가 있는 점수만 부여했다. 총점은 범주 점수의 합이다.

모델별로 관찰된 강점

모든 과제마다 다른 우승자를 정하는 것보다 범주별 점수 구성이 더 유용하다. GPT 6.1 Sol은 조사, CFO 메모, 결과물 간 일관성에서 가장 높은 점수를 받았다. Opus 5.5는 스프레드시트 품질에서 근접한 점수(22/25, Sol은 23/25)를 얻었으며, 결과를 내는 데 걸린 시간은 Sol의 155.0분보다 짧은 39.8분이었다. 이는 감사한 결과물에 대한 관찰이지 통계적으로 확립된 능력 차이는 아니다.

범주별 프로필. 셀은 공개된 범주 점수이며 색상은 각 범주의 만점 대비 점수 비율을 나타낸다.

이는 이 작업흐름에서 배포된 구성을 관찰한 결과이지, 다른 과제에 대한 일반적 추천이 아니다. 예를 들어 앱 점수가 높다고 해서 같은 모델이 재무 통합 문서를 안정적으로 관리한다고 입증되지는 않는다.

모델이 만든 앱

각 모델은 CX Vendor Decision Lab의 자체 버전을 만들었다. 아래 이미지는 목업이나 재현된 인터페이스가 아니라 Spacebar의 실시간 앱 렌더러에서 캡처한 실제 Mario 앱 화면이다.

Spacebar는 렌더러를 에이전트 도구로 제공한다. 이 도구는 공유 상태가 담긴 앱 이미지를 반환하므로, 시각 기능을 갖춘 에이전트가 코드와 상태뿐 아니라 렌더링된 화면도 살필 수 있다. 시각 검사는 게시 성공이나 상태 재확인만으로는 드러나지 않는 레이아웃 및 표현 문제를 찾을 수 있다.

캡처는 2026년 10월 7~8일 결과물 검토 때 보존된 평가자 이미지다. 각 앱의 화면 일부와 상태를 보여주며 모든 영역을 담지는 않는다. 시각적 검사 경로가 있음을 보여주지만, 벤치마크 대상 모델 모두가 이를 성공적으로 사용했다는 뜻은 아니다. 표시된 사업 수치는 아래 결과물 감사 내용에 따라 달라질 수 있다. 이미지를 열면 전체 해상도로 볼 수 있다.

• GPT 6.1 Sol — 앱 감사 14/15. 계획 제어, 미확인 비용 경고, 월별 및 시나리오 차트. 스크린샷 열기 · 2400 × 3000
• Opus 5.5 — 앱 감사 13/15. 공유 가정, 차트, 위험과 추천을 담은 밀도 높은 검토 화면. 스크린샷 열기 · 2880 × 2080
• DeepSeek v4.1 Flash — 앱 감사 13/15. 공급업체 제어, 핵심 지표 카드, 비용 차트를 결합한 간결한 대시보드. 스크린샷 열기 · 2560 × 2160
• GLM 5.3 — 앱 감사 12/15. 큰 공급업체 선택 카드와 공유 의사결정 상태 제어. 스크린샷 열기 · 1520 × 1120
• Grok 4.7 — 앱 감사 11/15. 눈에 띄는 의사결정 제어, 편집 가능한 가정, 비용 카드. 스크린샷 열기 · 1520 × 1120
• Muse Spark 1.3 — 앱 감사 12/15. 구획별 공유 입력값, 핵심 지표 카드, 비교 차트. 스크린샷 열기 · 2200 × 1800

실행 시간과 비용

유용한 결과인지를 평가할 때 결과를 만드는 데 든 시간과 비용도 살펴야 한다. 아래 차트는 각 결과에 기록된 작업흐름 실행 구간을 합산한다. 모델 추론 지연만이 아니라 도구 사용을 포함한 경과 작업 시간이다.

그림 5. 평가한 결과물 집합의 누적 실행 시간. 폐기한 결과물 집합에서 수행한 초기 실험은 제외한다. 실행 시간은 추정치가 아니라 측정값이다.

비용은 위 실행 시간과 같은 실행 이력을 다룬다. 물결표(~)는 사용량 기반 추정치, ≥는 청구 기록이 완전하지 않을 때의 하한이다. ‡ Sol은 기록된 사용량에 공개된 표준 등급 요금을 적용했다. 자세한 내용은 아래 산정 설명을 참조한다. 이 수치는 인프라, 브라우저 서비스, 보조 임베딩을 제외하며 청구서 금액이 아니다. 보고된 추론 사용량은 이중 계산하지 않도록 포함했고, 기록이 있는 경우 프롬프트 캐시 사용량도 반영했다. 청구 기록 누락분을 비용 0으로 간주하지 않는다.

작업별 비용

여기서 작업은 14개 사용자 메시지 중 하나를 뜻하며, 도구 호출이나 성공적으로 완료한 결과물이 아니다. 작업당 평균 비용은 총 생성 비용을 14로 나눈 값이다. 이는 비용을 분산한 작업량 지표이지, 맥락 없이 독립된 과제를 새로 해결하는 가격이 아니다.

기록된 시작 시각을 이용해 요청을 서로 겹치지 않는 6개 작업 그룹으로 나눌 수도 있다. 그룹은 사용자가 에이전트에게 요청한 내용에 따른다. 품질 점수 범주와는 의도적으로 다르다. 조사와 스프레드시트 작성은 동시에 진행될 수 있고, 마지막 수정 한 번이 통합 문서·앱·메모를 모두 바꿀 수 있다. 신뢰성은 전체 실행의 특성이며 별도의 청구 작업 범주가 아니다.

각 작업 그룹 셀은 그룹 전체 비용이지 요청 하나의 비용이 아니다. 그룹의 요청 수로 나누면 요청당 평균이 나오며, 이 평균은 다운로드 가능한 데이터에도 포함된다. ~는 요금표 기반 추정치, ≥는 기록된 하한, ‡는 아래에 설명한 Sol의 공개 요금 계산을 뜻한다. 표시 자릿수 반올림으로 열 합계가 달라질 수 있다.

요청 비용에는 하위 에이전트 작업, 물려받은 대화 맥락, 해당 사용자 요청이 진행되는 동안 비용이 청구된 수정 작업이 포함된다. 따라서 후반 작업은 고립된 마이크로벤치마크가 아니다. DeepSeek 요청 네 개는 기록된 작업 시간 범위 밖에 있다. 그중 하나에는 약 $0.002의 비용 기록이 있어 추측으로 배정하지 않고 별도로 표시했다. 미확인 비용을 0으로 보지 않는다.

GLM의 총액 $10.07은 요청당 $0.72에 해당한다. Opus의 요금표 기반 추정치는 요청당 $1.67이다. DeepSeek은 $0.32, Grok은 $1.19, Muse는 $2.77로 기록된 하한이다. 이는 성공한 작업 하나당 비용이 아니며, 비용 기록이 누락되어 확정적인 비용 효율 순위를 매길 수 없다.

Opus 비용 배분은 공개 총액을 추정할 때 쓴 같은 가정에 따른다. 입력 토큰 100만 개당 $4, 출력 토큰 $20, 캐시 읽기 $0.20, 캐시 쓰기 $5다. 이 가정은 검증된 청구서가 아니다.

‡ Sol의 총 $41.86(요청당 $2.99)은 2026년 10월 8일 확인한 OpenAI의 GPT 6.1 Sol 공개 요금을 525개 요청 중 사용량이 기록된 524개에 적용한 결과다. 표준 등급에서 토큰 100만 개당 일반 입력은 $2, 캐시 읽기는 $0.10, 캐시 쓰기는 $2.50, 출력은 $10이다. 입력 토큰이 272,000개를 넘는 200개 요청에는 요청 전체에 대해 각각 $4, $0.20, $5, $15를 적용했다. 청구 지역 속성이 보존되지 않았으므로 지역 할증이 없는 표준 처리를 가정했다. 사용량 기록이 없는 한 요청은 비용을 0으로 두지 않고 제외했다. 이는 청구서와 대조한 총액이 아니라 공개 요금표를 이용한 계산이다.

캐시 읽기와 추론 토큰

캐싱은 공급업체, 라우팅, 보존된 접두부, 대화 길이와 시점이 함께 작용하는 전체 실행 경로의 특성이다. 캐시 읽기 비율이 높다고 모델 고유 능력이 높은 것은 아니며, 절감된 비용의 비율을 직접 알려주지도 않는다.

기록된 응답의 총 입력 토큰 중 캐시 읽기 토큰의 비율이다. Anthropic의 총 입력에는 새 토큰, 캐시 읽기, 캐시 쓰기를 포함한다. 다른 공급업체는 프롬프트 토큰 합계에 캐시 입력이 이미 포함된다. 분모는 요청 수가 아니라 토큰량이다. 사용량 기록이 없으면 전체 실행의 비율이 달라질 수 있다.

Opus와 Sol은 캐시 읽기가 약 96%, Grok은 약 95%, GLM과 DeepSeek은 약 89%다. Muse는 약 27%다. Opus와 Sol의 작은 차이가 일반적인 캐시 성능 우위를 입증하지는 않는다. Sol의 한 요청에는 사용량 기록도 없다. Sol은 기록된 입력 토큰을 약 1억 2,630만 개 보냈고 Opus는 5,040만 개를 보냈다. 캐시 비율이 비슷해도 맥락의 양이나 비용이 같다는 뜻은 아니다. Muse의 낮은 비율은 구체적인 최적화 가능성이지만 특정 원인을 입증하지는 않는다.

이 수치는 공급업체가 보고한 토큰 카운터이며, 공개된 사고 과정 문장이나 추론 품질 측정치가 아니다. 보고된 추론 토큰은 출력 사용량의 일부이므로 비용 계산에서 다시 더하면 안 된다. 사용량 기록이 없다고 추론 토큰이 0이라는 뜻은 아니다.

† GLM 응답 11개와 DeepSeek 응답 2개에서는 추론 토큰 필드가 같은 응답의 보고된 출력 총계보다 크다. 표에는 원시 합계를 그대로 보존했지만 검증된 총계로 취급하지 않으며, 신뢰할 만한 추론·출력 비율을 계산하는 데 사용하지 않는다. 이 차이는 별도로 조정된 API 요금의 유효성을 훼손하지 않는다. API 요금은 추론 수수료를 다시 더하지 않고 그대로 사용했다.

일관되게 기록된 자료에서 Opus는 추론 토큰 33,499개, Sol은 129,193개를 기록했다. 보고된 추론 토큰이 많다고 추론 능력이 더 좋다는 뜻은 아니다. 모델마다 작업 길이, 토크나이저, 보고 방식, 선택한 노력 수준이 다르다. 실제 작업에서 올바른 결과를 냈는지는 결과물 감사로 판단한다.

결과물에서 드러난 차이

가장 뚜렷한 차이는 입력을 바꾸거나 같은 결정을 여러 결과물에서 대조할 때 나타난다. 통합 문서, 대시보드, 메모를 만드는 것으로는 부족하다. 가정과 계산과 결론이 계속 일치해야 한다.

GPT 6.1 Sol의 최종 통합 문서, 대시보드, 메모는 공급업체·시나리오 조합 9개의 금액이 모두 일치한다. 인원 변경, Copilot 전환, 10% 할인 경계값이 독립 확인을 통과했다. 공유된 Freshdesk / Base / Finance 검토 선택값이 보존됐고 가격이 없는 입력값은 명시적으로 미확인 상태로 남았다. 남은 감점은 실행 신뢰성, 문서 레이아웃, 검증 공백에 관한 것이다.

GLM 5.3에는 중요한 수식 누락이 있다. Zendesk 총액에 AI 사용량 행이 반영되지 않는다. AI 단가를 1달러로 입력하면 해당 행에는 $93,796.23이 표시되지만 연간 총액은 바뀌지 않는다. DeepSeek은 통합 문서에서 시작 인원을 바꾸면 1월 값만 변한다. 앱에서는 같은 입력이 연중 계산에 반영된다. 따라서 기준선이 일치한다고 해서 입력값 변경에도 결과물들이 일관된다는 뜻은 아니다.

Muse Spark에서는 시나리오 이름, 시작 인원 입력값, 11월 배수가 통합 문서 계산에 연결되지 않는다. 두 성장률을 바꾸면 계산은 반응하지만 저장된 시나리오 비교에는 오래된 결과가 남는다. 메모에는 Conservative 시나리오의 Zendesk/Freshdesk 총액으로 약 $172,786/$84,130이 반복된다. 입력값을 다시 계산하면 약 $168,512/$83,555다. 앱은 후자의 금액을 올바르게 계산한다.

Muse의 최종 구매 규칙은 대시보드의 공유 추천에 들어 있지만 통합 문서와 메모에는 없다. 최종 답변은 해당 문서를 수정하지 못했다고 인정한다. 메모의 유지 관련 큰 글자는 첫 두 페이지에 걸쳐 나타난다. 이는 응답을 반환했는지만으로 감점한 것이 아니라 결과물과 소통에서 관찰된 문제다.

Grok의 대시보드는 Zendesk Base 총액을 $179,716.67로 계산한다. 통합 문서의 예측과 메모에는 $269,979.19가 적혀 있다. Vendor Comparison에는 세 번째 값인 $263,118.35가 나온다. 앱은 상담원당 포함 AI 결과 50건에 단가 $1.50을 사용하지만 통합 문서는 10건에 $2.00을 사용한다. 메모는 앱의 가정을 설명하면서 통합 문서의 금액을 인용한다. 그런데도 최종 답변은 결과물들이 일치한다고 주장한다.

이 확인에는 저장하지 않은 통합 문서 사본, 보존된 앱 계산 함수, 공유 상태 재확인을 사용했다. 평가자는 온라인 결과물을 수정하지 않았다. 원본 웹 페이지 본문과 일부 도구 결과 본문이 보존되지 않아 모든 상업적 주장이나 자체 수정 내용을 독립적으로 확인할 수는 없다. 네이티브 Google Sheets 민감도 테스트와 철저한 다중 사용자 앱 테스트도 검증 범위에 들지 않는다.

방법론이나 재현 세부 사항은 engineering@spacebar.ai로 문의할 수 있다.

이번 파일럿이 보여준 것과 다음 단계

이번 파일럿은 에이전트가 지속형 작업공간에서 일할 때 점검할 구체적 항목을 보여준다. 결과물의 동일성, 수식 무결성, 공유 선택값, 출처의 불확실성, 뒤늦은 변경의 전파, 에이전트가 자기 작업을 설명한 내용의 정확성이다. 불완전한 비용 수집과 작업 정산 관찰 등 평가 절차의 약점도 드러난다.

이 결과로 일반적인 모델 순위를 확정할 수는 없다. 제한된 작업흐름, 실시간 웹 출처, 서로 다른 구성, 결과물을 살피면서 발전한 평가 절차에 기반한다. 일부 시각 검사를 할 수 없었다. 답변을 반환했다고 해서 결과물이 정확하거나 완전한 것은 아니었다. 이런 조건도 결과와 함께 제시해야 하며 독자가 순위 제목을 본 뒤 각주에서야 발견하게 해서는 안 된다.

다음 실험에서는 공유 작업공간의 요구를 의도적으로 넓혀야 한다. 특정 결과물에 메모를 붙이고, 의미 있는 축을 따라 스티키노트를 배치하고, 프로젝트가 바뀌어도 관련성을 유지하는 다이어그램을 만드는 공간형 과제가 제안됐다. 이런 과제는 이번 14턴 파일럿의 결과와 별개다. 실제 다중 사용자 실험은 동시 편집, 상충하는 요청, 소유권, 협업자의 작업을 덮어쓰지 않는 복구 문제를 더할 수 있다.

이 환경에서 에이전트는 사람들이 자신이 남긴 상태에서 계속 작업할 수 있을 때 유용하다. 이 벤치마크가 지향하는 기준은 생성에 그치지 않고 협업이 계속되는 동안 정확하고 이해하기 쉬우며 쓸 수 있는 작업이다.

재현성

벤치마크 방법론, 구성, 재현 방법에 관한 자세한 내용은 engineering@spacebar.ai로 문의할 수 있다.