Jules로 진짜 중요한 걸 측정해봐요
요약
AI 코딩 에이전트가 수동적인 조수에서 주도적인 엔진으로 진화함에 따라, 구글은 '작업'이 아닌 '목표' 지향적인 에이전트를 평가하기 위한 새로운 벤치마크 방법론을 제시했어요. 실제 버그 수정 이력을 활용해 '그라운드 트루스'를 설정하고, 에이전트의 '인사이트 정책'과 '탐색 예산'이 얼마나 중요한지 예비 결과를 통해 보여줍니다.
인사이트
- 주도적인 AI 코딩 에이전트를 평가하려면 기존의 '작업' 기반 벤치마크를 넘어 '목표'와 '인사이트 정책'에 초점을 맞춘 새로운 평가 방법이 필요해요.
- 실제 버그 수정 이력을 '시간적 근접성'과 '의미적 유사성'으로 분석해 클러스터링하면, 에이전트 평가를 위한 고차원적인 '지향적 목표' 즉 '그라운드 트루스'를 효과적으로 구축할 수 있어요.
- 에이전트에게 더 많은 탐색 자원(탐색 예산)을 부여하면, 복잡한 문제에서 놓쳤던 보조 신호를 발견하고 진단 인사이트의 정확도를 크게 향상시킬 수 있어요.
왜 중요한가
AI 코딩 에이전트가 개발자의 지시를 따르는 수준을 넘어 스스로 문제를 예측하고 해결책을 제시하는 '주도적' 역할로 진화하는 것은 소프트웨어 개발 방식에 큰 변화를 가져올 거예요. 이 연구는 이러한 차세대 에이전트의 성능을 객관적으로 평가할 수 있는 핵심적인 방법론을 제공함으로써, AI가 단순한 자동화를 넘어 전략적인 개발 파트너로 성장하는 데 중요한 기반을 마련하고 있습니다.
2026년 6월 22일
AI 코딩 에이전트들이 빠르게 변하고 있어요. 예전에는 개발자가 시킬 때만 작업을 처리하는 수동적인 조수였다면, 이제는 알아서 맥락을 흡수하고, 잠재적인 위험을 찾아내고, 개발자가 묻기도 전에 진단 인사이트를 제공하는 능동적인 엔진으로 진화하고 있는 거죠. 이런 진화의 핵심은 명확하게 정의된 **작업(tasks)**에서 **목표(goals)**로의 전환에 있어요. 목표는 에이전트가 코드베이스를 탐색하고, 관련 있는 것을 발견하고, 더 높은 수준의 목표로 개발자를 안내하는 진단 관찰 결과를 제시해야 하는 거죠.
SWE-Bench 같은 공개 벤치마크는 좁게 정의된 버그 수정 같은 '작업'을 완료하는 에이전트의 능력을 테스트하곤 해요. 하지만 '목표'를 위한 벤치마크는 아직 없어요. 최근 논문인 에이전틱 코딩은 자율성뿐만 아니라 주도성도 필요해요에서, 이 연구팀은 주도적인 에이전트가 '인사이트 정책'을 기준으로 평가되어야 한다고 주장하고 있어요. 이 정책은 무엇이 중요한지, 어떤 증거가 뒷받침하는지, 그리고 개발자를 방해할지 아니면 침묵할지 결정하는 능력을 말하죠.

위 그림은 주도적인 에이전틱 코딩 엔진의 설계를 보여주고 있어요. 컨텍스트가 엔진으로 흘러들어가 개발 상태와 개발자 모델을 유지하고, 인사이트를 방출(알림, 질문, 초안 작성, 침묵)하며, 응답으로부터 학습하는 방식이죠.
실제 버그 수정을 '그라운드 트루스'로 활용하기
Google Labs에서 연속 AI 시스템을 연구해 보니, 주도적인 에이전트의 인사이트 정책을 평가할 수 있는 평가를 구축하려면 '그라운드 트루스(ground truth)'를 설정하는 게 필수적이라는 걸 알아냈어요. 이 '그라운드 트루스'를 구축하는 한 가지 방법은 팀의 실제 버그 수정 이력을 **시간적 근접성(temporal proximity)**과 **의미적 유사성(semantic similarity)**이라는 두 가지 발견적 방법(heuristics)으로 분석하는 거예요.
가설은 간단해요. 엔지니어들이 짧은 시간 안에 여러 관련 버그를 제기하고 해결할 때, 그 버그들은 보통 하나의 근본적인 엔지니어링 노력의 증상이라는 거죠. '샌드박스 타임아웃 오류', '브로커 설정 실패', '네트워크 격리 불안정한 테스트' 같은 버그 덩어리는 모두 '샌드박스 실행 안정성 강화' 와 같은 공통의 목표를 가리키고 있어요. 개별적으로 보면 각 버그는 너무 작업(task)에 국한되어 있어서 목표가 되기 어려워요. 하지만 함께 보면 더 높은 수준의 목표를 드러내 주는 거죠.
예비 평가 세트 구축 및 테스트하기
예비 벤치마크를 구축하고 가설을 테스트하기 위해, Google 내부 코드베이스에서 705개의 버그(1,178개의 CL)를 사용해서 다음과 같은 작업을 했어요.
- 관련된 과거 버그들을 클러스터링해서 개발자들이 실제로 추구했던 더 높은 수준의 '지향적 목표'를 밝혀냈어요.
- 각 클러스터 내의 개별 버그를 '그라운드 트루스' 목표로 설정하고, 코드베이스를 버그 수정 전의 정확한 상태로 되돌려서 에이전트가 사람 엔지니어가 시작했던 지점에서 시작할 수 있게 했어요.
- 에이전트가 최종 인사이트를 생성하기 전에 최대 세 번(이를 '탐색 예산' 또는 N이라고 해요)까지 코드베이스를 조사하도록 허용했어요.
- LLM을 사용해서 에이전트가 예측한 인사이트를 1점(무관함)부터 5점(완벽 일치)까지 '그라운드 트루스' 목표와 비교하여 평가했어요.
- 에이전트의 평균 최고 점수와 얼마나 자주 매우 정확한 일치(Hit@K)를 성공적으로 생성했는지 추적하여 성공 여부를 측정했어요.
예비 결과와 우리가 배운 점
이번 테스트의 예비 결과는 크게 두 가지 이유로 아주 흥미로워요.
핵심 진단 로직이 잘 작동해요: 단 한 번의 탐색 라운드만으로도 에이전트가 매우 관련성 높은 인사이트(5점 만점에 평균 4.5점)를 꾸준히 식별해냈어요. 단순한 엔지니어링 문제에 대한 주요 신호를 성공적으로 포착한 거죠.
탐색 예산이 중요해요: 복잡하고 다각적인 문제는 당연히 더 어렵지만, 에이전트에게 더 많은 조사 자원을 제공하면 그만큼 효과가 좋아요. 탐색 예산을 두 라운드에서 세 라운드로 늘리자, 에이전트의 Hit@5 정확도(상위 5개 추천 항목 내에 올바른 진단 인사이트가 나타나는 비율로 정의해요)가 33%에서 57%로 크게 반등했어요. 이는 추가 탐색이 에이전트가 처음에 놓쳤던 보조 신호를 직접 찾아내는 데 도움이 된다는 걸 증명해요.
다음 단계는 무엇일까요?
이것은 초기 샘플에 대한 예비 결과이며, 이 연구팀은 여러 방면으로 적용 범위를 적극적으로 확장하고 있어요. 우선, 이 방법론을 더 넓은 AI 커뮤니티에 광범위하게 적용할 수 있도록 이 평가를 공개 GitHub 데이터(이슈 및 해결 PR)로 확장하고 있어요. 또한 코드베이스 외에 이슈 트래커, 대화, 설계 문서와 같은 더 풍부한 컨텍스트 스트림을 어떻게 수집할 수 있을지도 탐색하고 있어요.
전체 논문은 여기에서 읽어볼 수 있고요, Google Labs의 코딩 미래에 대한 더 많은 연구에 관심이 있다면 labs.google/code에서 함께 지켜봐 주세요.
다음