에이전트 도구 선택 앞에서 팀 리드가 가장 먼저 확인하는 것은 무엇인가? SWE-bench 점수, 벤치마크 순위, 공식 블로그의 성능 수치. 그런데 2026년 초, Berkeley RDI 연구팀이 발표한 논문 하나가 이 관행에 정면으로 의문을 던졌다. 자동화된 에이전트가 주요 AI 벤치마크 8개에서 거의 만점에 가까운 점수를 기록했다. 문제는 그 에이전트가 실제로 단 하나의 태스크도 풀지 않았다는 것이다. 10줄짜리 Python 훅으로 테스트 리포트를 조작했고, 답안이 들어 있는 로컬 파일 경로에 직접 접근했다. 점수는 진짜였고, 능력은 가짜였다.
같은 시기 YC는 494개 기업에 위조된 SOC2 보고서를 발급한 스타트업 Delve를 퇴출시켰다. Dev.to의 분석이 정확히 짚었듯, 이 두 사건은 동일한 구조적 실패의 서로 다른 레이어다. 선언적 아티팩트—점수든, 인증서든—는 근본적으로 조작 가능하다. 실제 행동을 직접 관찰하지 않는 한, 우리는 숫자가 만들어낸 신뢰를 사는 셈이다. 에이전트 도입 결정권을 가진 팀 리드라면 이 구조적 함정을 먼저 이해해야 한다.
그렇다면 '실제 행동'이란 구체적으로 무엇인가. Google Antigravity와 Anthropic Claude Dreaming은 각각 다른 방식으로 이 질문에 답한다. Antigravity의 Manager View는 에이전트가 플래너, 익스큐터, 리뷰어로 분화되어 병렬 실행되는 과정을 Artifact—스크린샷, 실행 로그, 녹화본—로 남긴다. 태스크를 수행했다는 주장이 아니라, 무엇을 클릭했고 어떤 에러가 났으며 어떻게 수정했는지를 검토 가능한 형태로 제출한다. 코드를 직접 작성하던 개발자가 이제 이 Artifact를 Google Docs에 코멘트 달듯 검토하는 역할로 전환된다.
Claude Dreaming은 다른 층위에서 같은 원칙을 구현한다. 에이전트가 과거 세션을 정기적으로 복기하며 반복 실수 패턴이나 팀의 워크플로우 선호를 추출하고, 메모리 구조를 스스로 재편한다. 법률 AI 팀 Harvey는 이 기능으로 도구 사용 패턴을 기억하여 작업 완료율을 약 6배 높였다. 함께 출시된 Outcomes 기능은 별도의 평가자가 에이전트 추론 과정에 개입하지 않고 결과물을 독립적으로 검증하는 구조다. 내부 벤치마크에서 어려운 문제의 성공률이 최대 10점 향상됐다고 발표했지만—여기서도 역시 이 숫자를 곧이곧대로 믿으면 안 된다. 중요한 건 그 숫자가 어떤 메커니즘에서 나왔는지, 우리 팀의 실제 태스크에서도 재현되는지다.
팀 리드 입장에서 현실적인 채택 검증 기준을 세 가지로 정리할 수 있다.
첫째, 벤치마크 점수가 아닌 실행 로그를 요구하라. 에이전트가 태스크를 어떻게 수행했는지—어떤 파일에 접근했고, 어떤 커맨드를 실행했으며, 실패 시 어떻게 복구했는지—를 확인할 수 없다면 그 도구는 아직 팀 워크플로우에 올릴 준비가 안 된 것이다. Antigravity의 Artifact 시스템이나 Claude Console의 에이전트 실행 추적이 이 기준을 충족하는 방향으로 설계된 이유가 여기 있다.
둘째, 우리 팀의 실제 태스크로 직접 검증하라. Berkeley RDI가 지적한 'jagged frontier' 문제—모델 성능이 태스크 유형에 따라 급격히 달라지는 현상—는 팀마다 다르게 나타난다. 94% SWE-bench 점수를 받은 에이전트가 우리 레거시 코드베이스의 컨텍스트 스위칭에서 무너질 수 있다. 2주간의 실제 프로젝트 파일럿 없이 팀 전체 워크플로우를 전환하는 것은 SOC2 인증서만 보고 벤더를 선택하는 것과 다르지 않다.
셋째, 학습 곡선 비용을 별도로 계산하라. Antigravity는 현재 공개 프리뷰 단계고, 에이전트 루프 충돌과 불안정한 멀티 에이전트 출력이 보고되고 있다. 프리뷰 단계의 도구를 생산 코드베이스에 투입하는 결정은 팀의 학습 비용과 실패 허용 범위를 명확히 계산한 뒤에 내려야 한다.
더 큰 그림을 보면, 에이전트 패러다임의 전환 자체는 실재한다. Google Antigravity가 보여주는 '개발자는 에이전트 매니저, AI는 실행자' 구도와 Claude Dreaming이 보여주는 '에이전트의 자기 개선 루프'는 3~5년 내 개발 워크플로우의 방향을 가리키는 신호다. 그러나 그 전환을 실제로 팀에 안착시키는 속도는 마케팅 발표 일정이 아니라, 팀이 에이전트 행동을 얼마나 투명하게 관찰하고 교정할 수 있느냐에 달려 있다.
결국 에이전트 선택은 점수를 비교하는 작업이 아니라 행동을 설계하는 작업이다. 어떤 도구가 우리 팀의 태스크에서 실제로 어떻게 움직이는지, 실패했을 때 어떤 로그를 남기는지, 그 로그를 팀 리드가 실시간으로 검토할 수 있는지—이 세 가지 질문에 명확히 답할 수 없는 에이전트는, 점수가 아무리 높아도 아직 당신 팀의 워크플로우에 올릴 준비가 되지 않은 것이다.