Google이 2026년 9월 9일 공개한 개발자 기술글은 AI 코딩 에이전트의 관찰 가능한 실행 과정을 평가하는 방법을 설명합니다. 도구 호출과 파일 수정 같은 행동을 살펴보면 최종 점수만으로 드러나지 않는 실패 원인을 좁히는 데 도움이 된다는 내용입니다.
원문 게시일: 2026년 9월 9일 · 확인일: 2026년 9월 14일. 새 모델 출시 공지가 아니라 평가 방법을 다룬 기술 가이드입니다. 아래 발표 요약 이후의 임베디드 개발 적용 사례는 이 글에서 제안하는 해석이며, Google의 제품 기능이나 자체 벤치마크 결과를 뜻하지 않습니다.
1. Google 기술글의 핵심 내용
원문은 행동 평가를 종합 과제 평가와 함께 사용할 것을 제안합니다. 전체 작업의 성공 여부에 더해 중간 도구 호출과 파일 변경을 확인하고, 최근에 발생한 실패 유형 하나부터 평가를 구성하는 방식입니다. 복잡한 작업에는 특정 도구 순서를 고정하기보다 여러 타당한 해결 경로를 허용하며, 모델의 비결정성을 고려해 반복 실행의 통과율 추이를 살펴보라고 설명합니다. Google Developers Blog 원문
2. Firmware 작업에 적용해 볼 평가 항목
임베디드 저장소에서는 빌드에 성공해도 보드 설정을 잘못 선택하거나 다른 장치의 핀 정의를 수정할 수 있습니다. 다음 표는 이런 실수를 재현하는 작은 평가 과제를 만들 때 사용할 수 있는 자체 제안입니다.
| 과제 | 기록할 증거 | 확인할 결과 |
|---|---|---|
| 특정 보드의 UART 핀 변경 | 선택한 보드 정의, 변경 파일, 빌드 대상 | 요청한 보드만 바뀌었는지 |
| 센서 JSON 파서 오류 수정 | 재현 입력, 수정 diff, 검증 결과 | 원래 실패 입력과 정상 입력이 모두 처리되는지 |
| 빌드 옵션 추가 | 설정 변경, 검증 명령의 종료 상태와 출력 | 사용한 옵션이 실제 빌드 시스템에서 유효한지 |
| 의존 라이브러리 교체 | 버전 근거, 잠금 파일 변화, 호환성 검사 | 설명한 버전과 실제 저장소 상태가 일치하는지 |
핵심은 “테스트 명령을 호출했다”에서 검사를 끝내지 않는 것입니다. 명령이 잘못된 디렉터리에서 실행됐거나 대상 테스트를 한 건도 수집하지 못했다면 수정이 검증됐다는 근거가 부족합니다. 종료 코드·실행 대상·수집 건수와 함께 결과를 확인하도록 평가 기준을 구체화할 수 있습니다.
3. Evidence는 실행 기록에서 수집하기
평가 데이터에는 과제 입력, 시작 커밋, 환경 설정, 실행 명령, 도구의 실제 반환값, 최종 diff를 연결해 두는 방식이 유용합니다. 최종 답변의 “테스트 통과” 문장을 평가하려면 그 주장과 일치하는 실행 결과가 있는지도 확인할 수 있습니다.
이 과정에서 필요한 것은 외부에서 관찰 가능한 작업 기록입니다. 모델의 비공개 내부 사고를 수집할 필요는 없습니다. 환경변수 전체나 인증 헤더를 로그에 남기는 대신, 허용한 필드만 기록하고 토큰·고객 데이터는 가리는 구성을 권합니다. 가상 장비 ID와 로컬 파일로 시작하면 실제 장비를 반복 변경하지 않고도 평가 규칙을 점검할 수 있습니다.
다만 기록이 존재한다는 사실과 기록이 충분하다는 판단은 다릅니다. 보드 설정 파일을 읽었다는 로그가 있어도 변경한 핀이 올바른지는 핀맵과 빌드 대상의 관계를 확인해야 합니다. 행동 증거를 최종 변경 결과와 연결해야 평가를 형식적으로 통과하는 현상을 줄일 수 있습니다.
4. Repeat 실행으로 변경 전후 비교하기
프롬프트나 도구 정의를 바꿨다면 동일한 과제 묶음과 시작 커밋으로 변경 전후를 비교하는 실험을 설계할 수 있습니다. 예를 들어 10개 과제를 각각 5회 수행한다면 총 50회라는 분모를 함께 기록하고, 성공 횟수 외에 실패 종류와 실행 비용도 모읍니다. 이는 설명을 위한 실험 설계 예시이며 실제 측정 수치가 아닙니다.
통과율이 조금 변했을 때 곧바로 모델 성능 차이로 결론 내리기보다 네트워크 오류, 환경 차이, 타임아웃, 평가 기준 변경을 먼저 분리하는 편이 좋습니다. 평균만 보면 특정 보드 과제의 반복 실패가 가려질 수 있으므로 과제 종류별 결과도 함께 확인하십시오. 드물지만 영향이 큰 잘못된 파일 변경은 별도 항목으로 추적할 수 있습니다.
5. Adoption 전에 정할 범위
처음부터 모든 작업에 세밀한 행동 규칙을 붙이기보다는 팀에서 반복되는 오류 하나를 선택해 재현 입력과 확인 가능한 결과를 정의하는 방법을 제안합니다. 파서 수정이라면 기존 오류 입력을 처리하는지와 정상 입력을 망가뜨리지 않는지부터 시작할 수 있습니다.
파일을 읽는 순서나 검색 명령의 철자까지 정답으로 고정하면 같은 문제를 올바르게 해결하는 다른 경로가 불리해질 수 있습니다. 반대로 결과만 지나치게 느슨하게 검사하면 검증을 생략한 작업이 통과할 수 있습니다. 업무에서 반드시 지켜야 하는 조건과 자유롭게 선택해도 되는 작업 순서를 구분해 평가 기준을 조정하십시오.
이 글에서는 Google의 예제 SDK를 설치하거나 에이전트 평가를 실제 실행하지 않았습니다. 도구별 지원 API와 실행 환경은 적용 시점에 별도로 확인해야 합니다. 팀의 빌드·테스트 과정에서 이미 얻을 수 있는 증거부터 연결하면, 에이전트가 완료했다고 보고한 작업을 사람이 검토할 때도 근거를 찾기 쉬워집니다.