코드에 남겨 둔 TODO가 사람에게는 작업 메모일 수 있습니다. 에이전트는 그것을 지금 처리할 일로 받아들이기도 합니다. Google은 11월 6일 공개한 내부 분석에서 이런 우회 작업이 얼마나 자주 일어났고 시간·토큰 사용량과 어떤 관계가 있었는지 보고했습니다. Google 분석
15호는 11월 3~8일 KST에 나온 코딩 에이전트 분석, 보안 모델, 코드 리뷰 도구 변경을 골랐습니다. 자료 확인 마감은 11월 8일 21:18 KST입니다. 아래 소식은 모두 03 · 공식 확인입니다. 발표 주체의 자료로 사실을 확인했으며 제품 성능을 독립적으로 재현한 것은 아닙니다. 끝의 ‘L-Proof의 해석’은 이 사실을 바탕으로 한 별도의 판단입니다.
Google — TODO를 따라 요청 밖의 일을 한 코딩 에이전트
Google은 내부 코딩 에이전트가 파일을 읽은 기록에서 TODO(bug/...)와 FIXME(bug/...) 주석을 추적했습니다. 파일을 읽은 세션의 13%가 이런 버그 참조를 만났습니다. 참조를 마주친 경우의 6%에서 에이전트가 해당 버그를 대상으로 후속 행동을 했고, 그중 83%는 개발자가 요청하지 않은 일이었습니다. 요청 밖의 우회 작업 중 이미 닫힌 버그를 좇은 경우가 41%, 아직 열린 버그를 조사하거나 고치려 한 경우가 57%였습니다. 분석 방법과 결과
Google은 개발자, 작업 유형, 모델 등 여러 조건을 통제한 분석에서 요청 밖의 버그 우회 작업이 발생한 세션에 단계 70%, 토큰 77%, 대기 시간 105% 증가가 함께 나타났다고 보고했습니다. 이는 Google 내부의 특정 주석 형식과 작업 기록에서 얻은 결과입니다. 모든 저장소의 TODO가 같은 비율로 오작동을 일으킨다는 뜻은 아닙니다. 다만 파일의 주석이 에이전트에게는 작업 지시처럼 읽힐 수 있다는 실패 경로는 분명합니다. Google은 버그 이력까지 확인해 정말 낡은 참조만 삭제하도록 하고, 변경은 사람의 리뷰를 받게 했다고 설명합니다. Google 원문
OpenAI — 취약점 조사와 수정 검증을 위한 전용 모델을 추가했다
OpenAI는 11월 5일 API 변경 기록에 gpt-6-cyber를 추가했습니다. 안내된 용도는 취약점 조사, 허가된 시험 환경에서의 재현, 수정 검증입니다. 모델을 쓸 수 있다는 발표를 일반 개발자에게 열린 기능으로 읽어서는 안 됩니다. 조직에 Daybreak Red 접근 권한과 별도의 모델 승인이 모두 필요합니다. 프로젝트 설정에도 해당 권한을 연결해야 합니다. API 변경 기록 · 모델 이용 조건
공개 문서로는 특정 코드베이스에서 실제 취약점을 얼마나 찾거나 잘못 보고하는지 판단할 수 없습니다. 접근 승인과 성능 검증은 별개의 문제입니다. Daybreak 설정 문서
GitHub — Copilot 코드 리뷰의 설정과 결과를 API에서 더 자세히 볼 수 있다
GitHub는 11월 6일 Copilot 코드 리뷰 설정을 REST·GraphQL API에서 관리할 수 있게 했습니다. 기업·조직·저장소 관리자에게 허용되는 설정 범위가 다르며, 저장소에서는 리뷰 강도와 사용자 지시문·MCP 도구 사용 여부를 관리할 수 있습니다. 리뷰 결과에는 Copilot이 작성한 댓글을 식별하는 필드, 사용한 리뷰 강도(메타데이터가 있을 때), 댓글의 출처로 Copilot이 보고한 스킬·MCP 서버·사용자 지시문을 확인하는 정보가 추가됐습니다. GitHub 변경 기록
출처 정보는 검토자가 댓글의 맥락을 되짚는 단서입니다. 그것이 댓글의 정확성이나 모든 도구 호출의 완전한 기록을 보증한다는 발표는 아닙니다. 기업·조직 설정 API에는 GitHub App과 세분화된 개인 액세스 토큰을 쓸 수 없고, 저장소 설정 API는 필요한 관리자 권한을 가진 경우에만 사용할 수 있습니다. 운영 자동화를 만들 때는 이 권한 차이를 먼저 확인해야 합니다. GitHub 변경 기록
L-Proof의 해석
같은 파일도 지시와 자료 사이를 오간다
Google 사례에서 문제의 주석은 코드의 일부였지만, 에이전트가 다음 행동을 정할 때에는 요청처럼 작용했습니다. 낡은 주석을 지우면 이미 닫힌 버그를 좇는 일은 줄일 수 있겠지만, 아직 열린 버그를 따라 요청 범위를 넓히는 문제는 남습니다. 버그가 실제로 존재한다는 사실과 지금 그 버그를 고치도록 위임받았다는 사실은 다릅니다. 예를 들어 로그인 오류를 고치던 에이전트가 같은 파일의 성능 개선 TODO를 발견했다면, 그것을 이번 수정에 끼워 넣기 전에 현재 요청과의 관계를 밝혀야 합니다.
GitHub가 추가한 리뷰 출처와 설정 정보는 댓글의 맥락을 되짚는 데 도움이 됩니다. 그러나 보고된 스킬·MCP·지시문 목록만으로 에이전트가 왜 작업 범위를 넓혔는지, 그 확대를 누가 허용했는지는 알 수 없습니다. Google이 분석한 코딩 에이전트와 GitHub의 코드 리뷰는 서로 다른 제품·단계입니다. 두 발표를 함께 볼 때 드러나는 빈칸은 출처의 존재와 작업 위임, 수정의 검증을 한 가지 기록으로 뭉뚱그릴 수 없다는 점입니다.
L-Proof가 다음에 확인하고 싶은 것은 두 가지입니다. Google의 주석 정리가 요청 밖 작업을 실제로 줄이는지, GitHub의 출처 정보가 리뷰어가 판단을 되짚는 시간을 줄이는지 말입니다. 어느 쪽도 이번 발표만으로 확인된 결과는 아닙니다.