다른 언어English简体中文

AI 에이전트 비교: 우리가 묻는 6가지 질문

AI 에이전트를 어떻게 비교할지는 결국 어떤 질문을 하느냐에 달려 있습니다. 질문이 알아낼 수 있는 내용을 결정하기 때문입니다. 기능 수를 세면 알 수 있는 것은 각 마케팅 부서가 제품 페이지에 무엇을 싣기로 했는지뿐입니다.

• 6가지 질문은 다음과 같습니다. 어디서 실행되는가, 도구는 어떤 방식으로 모델에 전달되는가, 사용자에 대한 메모리는 어디에 저장되는가, 사용자는 무엇을 승인할 수 있는가, 어떤 경로로 접근하며 사용자 없이도 무엇이 실행을 시작할 수 있는가, 누구도 확인하지 못한 것은 무엇인가.
• 이 질문들은 제품을 내부까지 분석한 뒤에 만들었습니다. 미리 가져간 점검표가 아니라, 4개 제품이 실제로 차이를 보인 지점을 짚은 것입니다.
• 어떤 항목에도 가중치를 부여하지 않으며, 종합 수치도 없습니다. 하나로 합치려면 각 항목이 사용자에게 얼마나 중요한지를 대신 결정해야 하기 때문입니다.
• 마지막 질문인 ‘우리가 확인하지 못한 것은 무엇인가’에는 모든 제품에 대해 답을 적었습니다. 그 답변은 짧지 않습니다.

같은 6가지 질문으로 AI 에이전트 비교하기

저희의 비교 내용을 읽는 데 그치지 않고 직접 에이전트를 고르려는 분을 위해 핵심을 정리했습니다. 각 후보에 아래 질문을 순서대로 적용하고, 제품 페이지의 설명 대신 실제로 관찰한 내용을 적으세요.

1. 어디서 실행되는가? 사용자가 볼 수 없는 서버인지, 클라우드에 마련된 사용자 전용 컴퓨터인지, 아니면 메시지와 화면을 볼 수 있는 노트북 내 프로세스인지 확인합니다.
2. 도구는 어떤 방식으로 모델에 전달되는가? 한꺼번에 전달되는지, 묶음 단위로 전달되는지, 별도로 관리되는 허용 목록을 거치는지 확인합니다.
3. 사용자에 대한 메모리는 어디에 저장되는가? 직접 열고 수정할 수 있는 파일인지, 제품을 통해서만 접근할 수 있는 저장소인지 확인합니다.
4. 사용자는 무엇을 승인할 수 있는가? 어떤 작업이 멈춰서 사용자의 응답을 기다리는지, 정확히 무엇을 승인하는지, 에이전트가 알고 있는 정보를 철회할 수 있는지 확인합니다.
5. 어떤 경로로 접근하며, 사용자 없이도 무엇이 실행을 시작할 수 있는가? 사용자가 입력하는 인터페이스와 에이전트를 깨울 수 있는 시간 조건, 수신함, 캘린더를 확인합니다.
6. 알아내지 못한 것은 무엇인가? 확인하지 못한 부분도 답으로 기록합니다. ‘살펴보지 않았다’는 뜻의 빈칸과 ‘아무것도 없다’는 뜻의 빈칸이 똑같이 보여서는 안 됩니다.

예를 들어, 저희가 조사한 Instinct의 메시징 경로에는 정확한 실행 계획에 대한 승인과 임대형 브라우저가 있으며, 메인 에이전트의 호스팅 환경은 확인되지 않았습니다. 9월 복제 실험의 비율만으로는 사용자가 원하는 예약을 완료할 수 있을지 판단할 수 없습니다. 선택하기 전에 원하는 최종 상태, 사용을 허용할 계정, 필요한 가용성 조건, 날짜가 명시된 견적을 적어 두세요. 그런 다음 허용한 범위에서 소규모 시험을 진행하고 결과와 승인 기록을 보관하세요. 이 점검표는 아키텍처에 관한 6가지 질문을 보완하며, 이를 점수로 합산하지는 않습니다.

저희 비교표에서는 같은 6가지 질문을 행으로 사용합니다. 요약하면 다음과 같습니다.

비교표를 가로로 읽으면 하나의 비교 축을 비교할 수 있고, 한 열을 세로로 읽으면 하나의 제품을 살펴볼 수 있습니다. 심층 분석에는 이를 뒷받침하는 관찰 내용과 한계가 담겨 있습니다.

개인용 에이전트의 실행 위치가 나머지를 결정하는 이유

질문은 ‘로컬인가, 클라우드인가’가 아닙니다. 이 4개 제품 중 사용자 컴퓨터에서 모델을 실행하는 제품은 없으므로, 양자택일로 물으면 모두 같아 보이기 때문입니다. 물어야 할 것은 모델과 사용자 데이터 사이에 무엇이 놓여 있는지, 문제가 생겼을 때 사용자 하드웨어가 얼마나 넓게 영향을 받는지입니다.

답은 4가지로 갈립니다. 요청을 전적으로 서버 측에서 구성한다면, 에이전트의 행동을 정하는 지시문은 사용자에게 전달되지 않습니다. 따라서 사용자도, 사용자 컴퓨터의 다른 프로그램도 이를 들여다볼 수 없습니다. 사용자별 Linux VM을 둔다면, 실질적인 의미에서 사용자의 것이라고 할 수 있는 환경에서 요청을 구성합니다. 샌드박스는 로컬 실행을 격리할 수 있지만, 연결된 계정을 통한 행동은 지속적인 영향을 남길 수 있습니다. 네이티브 데스크톱 프로세스는 여기에 더해 부여받은 로컬 권한 범위까지 노출합니다.

마지막 방식은 좀 더 생각해 볼 필요가 있습니다. 노트북에 있는 것은 모델이 아니라 사용자 생활의 상당 부분을 볼 수 있는 프로세스이며, 이 프로세스는 원격 모델의 지시를 따릅니다. 실행 위치는 에이전트가 어디까지 접근할 수 있는지, 악성 지시가 삽입된 웹페이지가 어떤 행동을 유도할 수 있는지, 이후 어떤 증거가 남는지를 결정합니다.

개인용 에이전트의 모델에 도구가 전달되는 방식

개인용 에이전트는 모델과, 그 모델이 수행하도록 허용된 일들의 집합으로 이루어집니다. 이 비교 축에서는 그 집합이 어떻게 모델 앞에 제시되는지, 누가 그것을 선택했는지 묻습니다.

눈여겨볼 차이는 제품이 할 수 있는 일과, 판단하는 순간에 모델에게 할 수 있다고 알려 주는 일 사이에 있습니다. 모든 도구를 한꺼번에 컨텍스트에 넣는 제품도 있습니다. 특정 도구 묶음이 필요해질 때만 해당 묶음의 정의를 불러오는 제품도 있습니다. 권한과 기능을 아예 분리해, 각 기능의 작동 방식에 관한 설명 없이 허용된 항목만 담은 목록을 두는 제품도 있습니다.

이 분리는 사용자에게 특히 중요합니다. ‘이 에이전트가 어디까지 접근하도록 허용되어 있는가’에 짧게 답할 수 있게 해 주기 때문입니다. 도구 정의가 언제 컨텍스트에 들어가는지는 구현자만 신경 쓸 세부 사항이 아닙니다. 전체 목록을 불러오면 에이전트가 한 번도 호출하지 않는 도구까지 컨텍스트를 차지합니다. 그렇다고 이 추가 부담만으로 무료, 정액제, 사용량 기반 요금제에서 소비자가 얼마를 내는지 알 수 있는 것은 아닙니다. 컨텍스트에 있는 모든 것은 악의적인 지시가 악용하려고 시도할 수 있는 대상이기도 하므로, 도구 집합이 작을수록 공격 대상의 범위도 좁아집니다. 여기서 다루는 4개 제품은 이에 대해 서로 다른 4가지 결론에 도달했습니다.

비교표에는 도구 수도 표시하며, 매번 주의사항을 함께 붙입니다. 전체 목록의 도구 수는 제품 어딘가에 존재하는 도구를 센 값입니다. 정작 사용자가 알고 싶은 것은 연결할 의향이 있는 계정만 연결했을 때, 눈앞의 어시스턴트가 몇 개의 도구에 접근할 수 있는가입니다. 이 벤치마크의 어떤 제품도 사용자 계정을 기준으로 한 그 수치를 공개하지 않습니다. 가장 가까운 사례는 Town입니다. 전체 1105개 도구 중 177개가 메인 어시스턴트에 제공되는 것을 확인했지만, 이 역시 사용자 개인의 설정이 아닌 제품에 관한 수치입니다.

사용자에 대한 메모리가 저장되는 곳

이 제품들은 모두 사용자에 관한 정보를 기억합니다. 다만 어떤 형태로 기억하며 누가 들여다볼 수 있는지는 전혀 다릅니다.

이 비교 축은 실용적인 질문 하나로 압축됩니다. 에이전트가 사용자에 대해 잘못 알고 있다면 어떻게 바로잡을 수 있을까요? 이 벤치마크에서 확인한 답은 ‘파일을 열고 해당 줄을 수정한다’부터 ‘제품 인터페이스를 통하거나, 수정하지 못한 채 지낸다’까지 다양합니다. 홈 디렉터리의 Markdown과 조회만 가능한 서버 측 저장소는 같은 기능을 달리 구현한 것에 그치지 않습니다. 자신의 데이터와 맺는 관계 자체가 다릅니다.

여기에 두 번째 질문이 따라옵니다. 다른 정보와 분리해 보관하는 것은 무엇일까요? 입력한 값을 드러내지 않고 양식을 채우도록 설계된 인증 정보 저장소는 일반 메모 파일과는 다른 엔지니어링의 결과물입니다. 둘 다 갖춘 제품이라면 이 문제를 고민한 것입니다.

저희는 각 저장소의 구조를 설명하며, 안에 담긴 내용은 설명하지 않습니다.

AI 에이전트가 행동하기 전에 사용자가 승인할 수 있는 것

대부분의 비교가 건너뛰는 질문이지만, 에이전트에게 카드를 맡기고 자리를 비워도 되는지를 결정하는 질문입니다. 여기에는 2가지 측면이 있습니다. 에이전트가 행동하기 전에 무엇을 멈춰서 물어보는지, 그리고 사용자에 대해 알게 된 정보를 사용자가 철회할 수 있는지입니다.

4개 제품은 첫 번째 측면에 서로 다른 4가지 방식으로 답합니다. Pine은 청구 관련 작업 전에 확인을 요청하며, 확인 절차가 2종류로 나뉩니다. 하나는 별도의 유효기간이 있는 작업 시작 확인이고, 다른 하나는 통화 상대인 회사가 계정 명의자의 확인을 요구할 때 진행하는 본인 확인입니다. Instinct는 선택지가 2개가 아닌 3개인 승인 카드를 보여 줍니다. 승인, 거부, 닫기입니다. 승인은 표시된 정확한 문구에 연결되므로 메시지를 다시 쓰면 새 승인이 필요합니다. Muse는 모든 권한과 승인, 컴퓨터 밖으로 나가는 모든 것을 단일 통제 지점을 거치게 하며, 활동 피드 옆에 승인 탭을 둡니다. Town은 승인을 매번 띄우는 확인창보다 설정의 문제로 다룹니다. 실행 모드, 계정 범위, 도구 목록, 승인 모드가 작업을 시작해도 되는지, 외부의 어떤 곳에든 데이터를 써도 되는지를 결정합니다.

모두에게 맞는 정답은 없습니다. 위험한 단계마다 확인을 요청하는 방식은 직접 지켜보고 싶은 사람에게 맞고, 한 번 설정해 두는 방식은 밤에 반복 작업이 돌아가기를 원하는 사람에게 맞습니다. 어떤 에이전트든 확인해야 할 것은 정확히 무엇을 승인하는가입니다. 전송될 정확한 문구에 연결된 승인과, 그 문구를 만들어 낸 요청에 연결된 승인은 서로 다른 약속입니다.

두 번째 측면은 삭제입니다. Muse의 런타임에는 파일 삭제와 기억 삭제 기능이 노출되어 있지만, 개인 사용자가 접근할 수 있는지는 검증하지 못했습니다. Town의 메모리에는 추가, 수정, 삭제 도구가 있습니다. Instinct는 삭제가 어디까지 적용되는지 문서로 설명합니다. Pine에는 알고 있는 내용을 담은 파일이 없으므로, 사용자가 열어서 지울 대상도 없습니다. 저희 자체 시험도 첫 번째 측면에 같은 원칙을 적용합니다. 사용자 허락 없이 결제, 서명, 최종 제출 단계를 넘어가면 별도 항목에서 무단 행동으로 집계합니다. 자세한 내용은 시험 진행 방식에서 설명합니다.

접근 경로와 사용자 없이 실행을 시작할 수 있는 것

이 비교 축에서 인터페이스 목록은 덜 흥미로운 절반입니다. 웹, 데스크톱, 메시징 앱, 전화, 다른 사람의 에이전트가 호출할 수 있는 API가 여기에 해당합니다.

중요한 절반은 실행을 촉발하는 경로입니다. 여기서 다루는 4개 제품 중 적어도 2개인 Town과 Instinct는 사람이 아무것도 입력하지 않아도 일을 시작할 수 있습니다. 정해진 시각이 되거나, 이메일이 도착하거나, 일정이 다가오거나, 문서가 변경되는 경우입니다. 심층 분석에 이 동작을 기록한 제품은 이 2개이며, Pine과 Muse에 대한 저희 분석으로는 가능한지 아닌지 어느 쪽도 결론 내릴 수 없습니다. 이는 사용자가 잠든 동안에도 에이전트를 유용하게 만드는 기능이자, 사용자가 아닌 사람도 에이전트에 접근할 수 있게 만드는 기능입니다.

수신함이 실행 계기에 포함된 에이전트라면, 사용자의 이메일 주소를 아는 낯선 사람도 누구나 말을 걸 수 있습니다. 따라서 ‘어떤 일이 일어났다’와 ‘그에 따라 행동한다’ 사이에 놓인 검증 절차는 기능 비교만으로는 드러나지 않는 핵심 역할을 합니다. 이 비교 축에 사용자가 입력할 수 있는 곳뿐 아니라 무엇이 실행을 시작할 수 있는지도 기록하는 이유입니다.

우리가 확인하지 못한 것

대부분의 비교는 모르는 부분을 우회해야 할 대상으로 취급합니다. 여기서는 그것을 마지막 비교 축으로 삼고, 모든 제품에 대해 내용을 채웁니다.

이 항목이 있는 이유는 2가지입니다. 분명한 이유는 정직성입니다. 알아낸 것만 보고하는 벤치마크는 신뢰 수준을 가늠할 수 없습니다. 빈칸이 ‘보고할 것이 없다’는 뜻인지 ‘살펴보지 않았다’는 뜻인지 알 수 없기 때문입니다. 덜 분명한 이유는 이 항목들 자체가 정보를 준다는 점입니다. 끈질기게 살펴보는 외부인에게 제품이 얼마나 드러나는지는 그 제품의 실질적인 속성입니다. 확인에 실패한 내용을 담은 4개 열은 어떤 회사가 불투명성을 하나의 기능으로 삼기로 했는지 보여 줍니다.

막연한 언급 대신 구체적으로 적습니다. ‘프롬프트에 관해 아는 것이 별로 없다’가 아니라 몇 번 시도했고 어떤 응답이 돌아왔는지 적습니다. ‘메모리가 불분명하다’가 아니라 구조의 어느 부분이 드러났고 어느 부분은 드러나지 않았는지 적습니다.

개인용 에이전트에 여전히 종합 수치를 매기지 않는 이유

첫 과제 실행 결과가 나왔으며, 순위 대신 구간과 표본 수를 함께 표시합니다. 여전히 종합 점수는 없습니다. 서로 다른 측정값을 하나의 숫자로 바꾸려면 각 항목이 사용자에게 얼마나 중요한지 결정해야 하는데, 저희는 그것을 모르기 때문입니다. 1개 제품의 수치는 공개를 보류했습니다. 전달받은 숫자가 저희가 확인할 수 있는 기록과 맞지 않기 때문입니다.

비교표의 첫 결과 묶음에는 완료율, 95% 구간, 채점한 과제 수를 표시하며, 완료율이 아니라 표본 수 순서로 배치합니다. 기록과 대조해 일치 여부를 확인하지 못한 Town의 수치는 계속 공개를 보류합니다. 이 수치들은 조정된 런타임에서 실시한 시험 측정값이며, 실행 묶음별 근거는 공개되지 않았습니다. 실행 기록은 개별 시도를 기록하고, 시험 방법은 결과를 어떻게 확인하는지 설명합니다. 어떤 측정값도 하나의 제품 점수로 합산하지 않습니다.

다른 비교표인 Assistant Benchmark는 2026년 10월 12일, 139개 어시스턴트 중 32개를 동일한 15개 과제로 시험했으며 실제 사용 후 각각 1점부터 10점까지 점수를 매기고, 시험하지 않은 칸은 비워 두었다고 밝혔습니다. 근거를 공개하는 타당한 방식입니다. 다만 이어서 각 제품을 하나의 종합 수치와 순위로 압축합니다. 앞서 설명한 이유로, 저희 비교표는 그 마지막 단계까지 나아가지 않습니다. 벤치마크 페이지에서는 이를, 동일한 2개 제품의 순서를 반대로 매긴 또 다른 소비자용 비교표와 나란히 살펴봅니다.

이 비교표가 의도적으로 측정하지 않는 3가지

가격은 비교 행에 넣지 않습니다. 가격은 비교 페이지가 따라갈 수 있는 속도보다 빠르게 바뀌며, 오래된 가격도 틀린 정보인 채로 권위 있어 보일 수 있습니다. 현재 가격은 각 제품 페이지에 날짜와 함께 기록합니다.

결과물의 품질도 비교 행에 넣지 않습니다. 에이전트가 이메일을 잘 쓰는지에 대한 판단은 과제마다 달라지며, 점수를 매기다 보면 평가 대상보다 평가자의 성향을 측정하기 쉽습니다. 런타임에 관한 사실은 계정이 있는 사람이라면 누구나 확인할 수 있으므로, 저희는 이를 공개합니다.

저희 자체 제품은 표에 없으며 앞으로도 넣지 않습니다. Zentor는 에이전트 소프트웨어를 개발하므로 이해충돌은 실재합니다. 회의적인 독자에게도 납득시킬 수 있는 유일한 대응은 평가 대상에서 빠지는 것입니다. 이 벤치마크의 운영 주체에서 사이트 운영 자금의 출처를 비롯한 나머지 사항을 설명합니다.

이 표는 런타임 심층 분석만 다룹니다. 별도의 오픈소스 에이전트 비교는 시험 점수를 추가하지 않고, 특정 버전으로 고정한 소스 코드에서 확인한 내용을 기록합니다. Personal Agent Bench 소개에서는 관찰 내용, 외부 보고, 시험 측정값을 어떻게 구분하는지, 어디에서 독립적인 검증이 불가능한지 설명합니다.

별도의 114개 과제 비교에는 Town이 포함되어 있습니다. 이 비교는 오래된 빌드, 필터링, 비공개 대화 기록으로 인해 해석에 한계가 있으며, 본 비교표를 대체하지 않습니다.

자주 묻는 질문

점수를 매기지 않고 어떻게 AI 에이전트를 비교하나요? 모든 제품에 같은 6가지 질문을 던지고 답을 나란히 공개합니다. 비교에 필요한 것은 동일한 질문과 정직한 답변입니다. 맨 아래에 합계가 있을 필요는 없으며, 판단 근거를 가리는 부분이 바로 그 합계입니다.

비교 축의 가중치가 왜 모두 같나요? 단일 점수가 있나요? 가중치는 아예 부여하지 않으며, 단일 점수도 없습니다. 가중치를 매기려면 ‘모델이 서버 측에서 실행된다’는 사실이 ‘메모리가 직접 열 수 있는 파일이다’라는 사실에 비해 얼마나 중요한지 결정해야 합니다. 이는 전적으로 사용자의 상황에 달려 있습니다. 종합 점수를 공개하는 곳은 어디든 그 결정을 명시하지 않은 채 사용자를 대신해 내린 것입니다.

6가지 비교 축은 어디서 나왔나요? 심층 분석에서 나왔습니다. 먼저 4개 제품을 내부까지 분석한 뒤, 실제로 차이가 드러난 부분을 바탕으로 비교 축을 만들었습니다. 일반적인 기능표의 범주 대신 유난히 구체적인 질문들이 된 이유입니다.

이 에이전트들이 실제로 얼마나 잘 수행하는지도 시험하나요? 첫 과제 실행을 마쳤고 완료율을 비교표에 실었습니다. 다만 수치는 시험을 진행한 팀에서 제공했으며, 아직 그 바탕이 되는 실행 묶음까지 거슬러 올라가 대조하지 못했다는 단서가 붙습니다. 이 단서는 각주가 아니라 본문에 표시합니다.

제가 직접 확인할 수 있나요? 직접 확인할 수 있어야 한다는 조건 아래 비교 축을 골랐습니다. 심층 분석의 관찰 내용은 계정으로 확인할 수 있는 동작에 관한 것입니다. 집계된 완료율은 실행 묶음의 공개 기록이 없어 같은 방식으로 독립적으로 검증할 수 없습니다. 관찰하지 못한 부분은 얼버무리지 않고 마지막 행에 적습니다.

확인 가능한 근거로 AI 에이전트 비교하기

방법 자체는 특별하지 않습니다. 모든 제품에 같은 6가지 질문을 던지고, 관찰한 내용을 기록하고, 확인에 실패한 지점을 명확히 밝히며, 결과를 하나의 숫자로 더하지 않습니다.

그렇게 하면 독자가 이의를 제기할 수 있는 페이지가 됩니다. 모든 칸이 관찰 가능한 동작을 가리키므로, 동의하지 않는 독자에게는 구체적으로 반박할 지점이 있습니다. 비교 축의 바탕이 된 4개 심층 분석, 비교표 자체, 또는 기존 에이전트 벤치마크가 무엇을 측정하며 왜 어느 것도 이 질문에 답하지 못하는지 살펴보세요.