이 소식은 무엇인가요?
배경부터 차근차근 살펴보기
AI 코딩 에이전트의 성능을 평가하는 보통의 방법은 SWE-bench 같은 큰 벤치마크로 최종 결과만 확인하는 것입니다. 코드가 맞으면 성공, 틀리면 실패라는 식인데, 이 방식은 시간이 오래 걸리고 비용이 많이 들 뿐 아니라, 무엇 때문에 실패했는지 원인을 찾기 어렵습니다.
구글 개발자 팀이 제안하는 대안은 '행동 검증(behavioral evaluation)'입니다. 최종 결과 대신 중간 단계의 동작 하나하나를 확인하는 방식인데, 예를 들어 파일이 제대로 생성됐나, 함수 호출이 의도대로 나왔나, 테스트가 실행됐나 하는 식으로 작은 체크를 모아서 검증합니다. 이는 단위 테스트(unit test)를 소프트웨어 개발에서 쓰는 원리와 같습니다.
이렇게 하면 테스트가 빠르고 저렴해지며, 무엇이 잘못됐는지 정확히 알 수 있습니다. 같은 논리로 시스템 프롬프트를 바꾸거나 모델을 업그레이드할 때도, 전체 벤치마크를 다시 돌 필요 없이 작은 단계 검증으로 변경 사항이 정상 작동하는지 빠르게 확인할 수 있어서 실패의 위험을 크게 줄일 수 있다는 주장입니다.
이 접근법의 핵심은 '작은 검증(micro-checks)'과 '큰 벤치마크(macro benchmarks)'를 함께 사용하는 것입니다. 모든 변경마다 거대한 테스트를 돌지 않으면서도, 신뢰성을 유지할 수 있다는 의미입니다.
이는 에이전트를 직접 쓰는 개인 사용자부터 에이전트를 만드는 개발팀까지 도움이 됩니다. 자신이 쓰는 도구를 제대로 검증할 방법을 알 수 있기 때문입니다.
공식 발표에서 확인된 내용
구체적으로 무엇이 달라졌나
- 01
최종 코드 검증 대신 각 단계 동작을 확인하는 '행동 검증(behavioral evaluation)'이 단위 테스트처럼 빠르고 정확합니다.
- 02
파일 수정 여부, 특정 함수 호출 기록, 테스트 실행 여부 같은 중간 결과를 따로따로 확인하면 무엇이 잘못됐는지 곧바로 알 수 있습니다.
- 03
중간 단계 검증을 통해 시스템 프롬프트나 모델 변경 때마다 큰 규모 벤치마크를 다시 돌지 않아도 정상 작동을 빠르게 확인할 수 있습니다.
- 04
작은 체크(micro-checks)와 큰 벤치마크(macro benchmarks)를 함께 사용하면 비용을 절감하면서도 신뢰성을 유지할 수 있습니다.
사용자에게 미치는 영향
누구에게 어떤 의미가 있나
에이전트 도구를 쓰는 연구원·직장인
에이전트가 생성한 코드가 정말 신뢰할 수 있는지, 어디서 잘못됐는지를 판단할 수 있는 체계적 기준을 갖게 됩니다. 도구를 업그레이드했을 때 실제로 개선됐는지 객관적으로 확인할 수 있습니다.
강의에서 학생에게 AI 도구를 쓰게 하는 교수
학생 제출물을 평가할 때 '코드만 맞는가'가 아니라 '생성 과정이 논리적인가'를 확인하는 기준을 세울 수 있습니다. 같은 최종 결과도 과정에 따라 학습도를 다르게 판단할 수 있습니다.
여러 코딩 도구를 비교하는 사용자
Cursor, ChatGPT, Claude 등 여러 도구 중 어느 것이 더 신뢰할 수 있는지 판단할 때, 단순히 '최종 성공 비율'이 아니라 각 도구의 구체적인 강점과 약점을 파악할 수 있습니다.
실제 활용 장면
어디에 어떻게 써볼 수 있나
생성된 함수의 신뢰성 검증하기
에이전트가 만든 함수가 의도대로 작동하는지 확인할 때, 최종 테스트만으로 끝내지 말고 각 단계를 기록하고 검증합니다.
- 예를 들면
- 에이전트에게 '파이썬으로 CSV를 읽어 null값을 처리하는 함수를 만들어'라고 지시한 후, (1) 파일이 코드 디렉토리에 생겼나, (2) pandas 같은 필요한 라이브러리를 import했나, (3) 함수 이름과 매개변수가 요청과 일치하나, (4) null 처리 로직이 명시되어 있나, (5) 테스트 코드가 있나를 각각 확인합니다.
- 확인할 결과
- 네 항목 이상을 확인하면서 진행하면, 어느 단계에서 문제가 생겼는지 명확히 알 수 있고, 같은 도구를 다시 쓸 때 어느 부분을 더 주의할지 알게 됩니다. 단순히 '성공했다/실패했다'를 넘어 도구의 패턴을 이해하게 됩니다.
강의 과제 검증 규칙 세우기
학생이 AI 도구로 제출한 코드를 평가할 때 행동 검증 기준을 적용합니다.
- 예를 들면
- 과제: '주어진 데이터셋에서 이상치를 찾는 파이썬 코드 작성'. 제출물이 들어오면, (1) 필요한 라이브러리(numpy, pandas 등)를 import했나, (2) 데이터 로드 코드가 있나, (3) 이상치 탐지 로직(IQR, Z-score 등)이 명시적으로 구현되어 있나, (4) 결과를 시각화하는 부분이 있나, (5) 주석이나 문서화가 있나를 항목별로 채점합니다.
- 확인할 결과
- 학생의 이해도를 최종 결과만으로 판단하는 것보다 훨씬 정확히 파악할 수 있습니다. 피드백도 '코드가 틀렸다'가 아니라 '이상치 탐지 로직이 너무 단순하다' 또는 '시각화 부분이 없어서 검증하기 어렵다'처럼 구체적으로 줄 수 있습니다.
도구 업데이트 전후 성능 비교하기
에이전트 도구가 업그레이드되거나 자신의 지시 방식을 바꿨을 때, 중간 단계 검증으로 실제 영향을 측정합니다.
- 예를 들면
- Claude, ChatGPT, Gemini 중 어느 도구를 계속 쓸지 선택할 때, 각각에게 같은 코딩 과제 5개를 줍니다. 최종 코드 맞음 비율이 모두 80%로 같아 보이지만, 중간 단계를 보면: 도구A는 함수 정의와 주석이 항상 있음, 도구B는 매번 테스트 코드를 빠뜨림, 도구C는 에러 처리가 부족함. 이렇게 보면 각 도구의 신뢰도가 다릅니다.
- 확인할 결과
- 전체 성공률이 같아도 각 도구의 구체적인 강점과 약점을 파악해서, 작업 유형에 따라 도구를 구분해 씁니다. 예: 데이터 분석은 주석이 잘 나오는 도구, 팀 협업은 테스트 코드를 잘 만드는 도구를 선택할 수 있습니다.
직접 적용해 보기
처음부터 무리하지 말고, 이 순서로 확인하세요
지난 에이전트 사용 기록에서 중간 동작 분석하기
지난주에 코딩 에이전트를 썼던 경우 3~5개를 선택합니다. 최종 결과(코드가 맞았나)가 아니라, 과정에서 어떤 파일이 생겼는지, 어떤 함수 호출이 기록됐는지, 테스트가 실행됐는지를 정리해 봅니다.
확인: 각 사건마다 5~10개 항목(파일 생성, import 여부, 함수 정의, 테스트 코드, 주석, 에러 처리 등)을 체크리스트로 만들 수 있는지 확인하세요. 만들 수 없으면, 자신이 그 도구를 어떤 기준으로 쓰고 있었는지 명확하지 않다는 뜻입니다.
자신의 도구별 검증 기준 설계하기
자신이 주로 쓰는 도구(Cursor, Copilot, Claude 등) 1~2개에 대해 '내가 이 도구의 결과를 받아들일 기준'을 정합니다. 예: 함수는 반드시 있어야 함, 테스트 코드도 있으면 좋음, 주석은 있으면 좋음, 에러 처리는 필수입니다.
확인: 기준을 글로 쓸 수 있는지, 그리고 지난 사용 기록 3개를 새 기준으로 다시 평가해 봤을 때 이전 판단이 달라지는지 확인하세요. 달라지면 기준이 제대로 작동한다는 뜻입니다.
한 번의 에이전트 작업에서 중간 단계 기록하기
앞으로 에이전트를 쓸 때, 최종 코드가 나올 때까지의 모든 단계를 기록합니다. 어떤 지시를 했는지, 어떤 파일이 생겼는지, 어떤 수정과 재요청이 들어갔는지 등을 타임라인처럼 남겨 두세요.
확인: 기록이 5단계 이상인지 확인하세요. 기록이 적으면 너무 간단한 작업이거나, 사용하는 도구의 중간 단계가 보이지 않는 인터페이스라는 뜻입니다.
작은 검증(micro-check) 목록 만들고 테스트하기
기록한 중간 단계들을 보면서, 각 단계마다 '이것이 맞으면 OK'라는 체크리스트를 만듭니다. 예: (1) 파일이 코드 폴더에 생겼나? (2) 함수 이름이 요청과 일치하나? (3) 입력값 검증이 있나? (4) 테스트를 돌렸나?
확인: 체크리스트가 10개 항목 이상인지, 그리고 향후 같은 유형의 작업을 또 받았을 때 이 목록을 그대로 쓸 수 있을지 생각해 보세요. 재사용 가능하면 앞으로의 모든 비슷한 작업에 쓸 수 있습니다.
도구 업데이트나 지시 방식 변경 후 검증하기
에이전트 도구가 업데이트되거나 자신의 지시 방식을 바꿨을 때, 같은 종류의 작업을 다시 해 봅니다. 이번엔 최종 결과만 비교하지 말고, 앞서 만든 중간 단계 체크리스트로 비교합니다.
확인: 이전과 이후의 중간 단계 체크리스트 점수가 몇 점 올라갔는지, 내려갔는지 기록해 두세요. 그러면 도구와 지시 방식의 실제 영향을 객관적으로 알 수 있습니다.
해석할 때 주의할 점
확인된 범위와 아직 모르는 내용을 구분하세요
이 글은 구글 개발자 팀이 제안하는 행동 검증 개념과 그 이점을 설명합니다. 구체적으로 구현된 도구나 오픈소스 라이브러리 이름, 비용 절감 규모, 특정 모델별 성능 수치는 아직 공개되지 않았습니다. 행동 검증의 철학과 실행 원칙만 이 자료에서 확인할 수 있으므로, 자신의 환경과 도구에 맞는 구체적인 검증 방법은 별도 실험과 기록이 필요합니다.
- 이 글은 개념 수준의 설명이므로, 자신이 쓰는 도구(Cursor, Copilot, Claude 등)와 프로그래밍 언어별로 구체적인 검증 항목을 어떻게 정할지는 별도 정보와 실험이 필요합니다.
- 중간 단계 기록과 체크리스트 관리를 수작업으로 하면 시간이 들 수 있으므로, 자신의 도구가 이런 기록을 자동으로 남기는지(예: 호출 로그, 파일 diff, 대화 이력) 먼저 확인하는 것이 좋습니다.
- 팀 환경에서 이 방식을 쓸 때는 '검증 기준'을 팀원 모두가 같은 방식으로 이해하고 적용해야 신뢰할 수 있으므로, 기준을 정하는 데 시간과 논의가 필요할 수 있습니다.
- 비용 절감 규모는 이 글에서 구체적으로 다루지 않으므로, 작은 검증(micro-check)을 많이 할 때 API 호출이나 토큰 사용량이 실제로 줄어드는지 자신의 환경에서 직접 측정해야 합니다.
- 모델별, 언어별 특성에 따라 검증 기준이 달라질 수 있습니다. 예: 파이썬의 type hint 검증과 자바스크립트의 그것은 다를 수 있습니다.
출처와 확인일
원문에서 다시 확인하기
이 글은 Google Developers Blog의 공식 발표를 바탕으로 정리했습니다. 기능 범위와 제공 조건은 바뀔 수 있으므로 실제로 적용하기 전에는 원문을 다시 확인해 주세요.
- 마지막 확인
- 2026-09-09
- 다음 검토
- 2026-10-09