AI가 명령어 하나를 실행하려고 허락을 구합니다. 이번에는 사람이 그 창을 읽기 전에, 모델이 먼저 요청을 살펴봅니다. 지금 맡긴 일에 필요한 행동인지, 그대로 진행해도 안전한지 판단한 뒤 확신이 서지 않을 때 사람에게 넘깁니다. GitHub가 10월 26일 정식 출시한 Copilot의 Assisted permissions입니다. GitHub 발표
승인 창이 줄면 하던 일을 덜 끊어도 됩니다. 다만 창이 뜨지 않은 이유가 ‘처음부터 허용한 행동’인지, ‘모델이 방금 허용한 행동’인지는 달라집니다. 사용자가 보지 못한 사이에 어떤 판단이 있었는지가 궁금해지는 변화입니다.
이번 12호에서는 승인과 권한을 다루는 두 가지 설계, 새 Terra 모델, Cloudflare의 장애 보고서, AI 방문 통계와 로봇 모델의 공개 소식을 살폈습니다. 조사 범위는 10월 23~28일, 마감은 28일 오전 10시 45분 KST입니다. 아래 소식은 03 · 공식 확인으로, 공식 발표와 문서를 대조했으며 성능이나 제품 동작을 직접 재현하지는 않았습니다. 마지막 ‘L-Proof의 해석’은 이를 바탕으로 한 별도의 판단입니다.
GitHub — 매번 묻는 대신, 물어볼 일을 고른다
Assisted permissions는 Copilot CLI, Copilot 앱, VS Code에서 사용할 수 있습니다. 명령 실행, 파일 경로 접근, URL 접근 등의 승인 요청을 모델이 검토하고, 안전하다고 판단한 요청은 자동으로 진행합니다. 기업 관리자는 모든 행동을 허용하는 모드는 막으면서 이 기능만 남기거나, 이 기능도 별도로 끌 수 있습니다. 출시 안내
설정에서 눈여겨볼 부분은 ask입니다. CLI에서는 기업 정책이 ‘물어보라’고 지정한 명령·파일·URL 요청도 검토 대상에 해당하면 모델의 승인으로 통과할 수 있습니다. 반면 금지 규칙은 계속 적용됩니다. ‘승인 절차를 거친다’와 ‘반드시 사람에게 묻는다’가 같은 뜻은 아닌 셈입니다.
무인 실행에서는 사람의 승인이 필요한 요청을 거부하고 그 이유를 Copilot에 돌려줍니다. 모델이 다른 방법을 시도할 수는 있지만, 사람이 없다는 이유로 승인을 생략하는 방식은 아닙니다. 검토 모델도 대화에 쓰는 모델과 다를 수 있고, 상황에 따라 같은 모델을 쓰기도 합니다. GitHub는 이 판단이 틀릴 수 있으며 샌드박스나 접근 제한을 대신하지 않는다고 명시합니다. 작동 방식과 예외
Vercel — 승인할 때 계획과 권한을 함께 보여준다
배포가 고장 났을 때는 원인을 알아야 어떤 변경을 허용할지도 정할 수 있습니다. Vercel이 10월 23일 공개한 설계 설명에서는 에이전트가 먼저 읽기 권한으로 조사하고, 변경이 필요하면 작업 계획과 추가 권한을 함께 제안합니다. 새 기능의 출시 공지보다는 운영 중인 승인 구조를 풀어쓴 자료입니다.
예를 들어 최근 배포와 로그를 읽는 조사 뒤에, 마지막 정상 빌드를 재배포하는 계획을 따로 승인받습니다. API는 요청에 사용된 토큰의 권한을 확인하고, 실행을 관리하는 소프트웨어는 승인된 계획이 여전히 활성 상태인지 확인합니다. 중단한 계획은 토큰의 유효기간이 남아 있어도 그 실행 검사에서 막힙니다.
다만 계획에 ‘배포 X를 다시 배포한다’고 적었다고 토큰까지 배포 X 하나로 제한되는 것은 아닙니다. 배포 쓰기 권한은 그 작업보다 넓을 수 있습니다. 화면에 표시한 계획과 실제 자격증명이 허용하는 범위를 구분해 설명한 점이 이 글의 읽을 거리입니다. Vercel의 권한 설계
OpenAI — 화면을 보고 일하는 모델의 가격이 내려갔다
GPT-6.1 Terra는 10월 26일부터 ChatGPT Work와 Codex에 배포되기 시작했고, API에서는 gpt-6.1-terra로 제공됩니다. 일반 Chat 화면의 모델로 소개된 것은 아닙니다. Work·Codex 이용 가능 여부에는 요금제와 지역, 워크스페이스 설정이 적용됩니다. 공식 릴리스 노트
OpenAI가 앞세운 용도는 화면을 읽고 앱을 조작하는 일입니다. 회사가 공개한 Agents’ Last Exam 평가에서 Terra는 중간 추론 설정 기준으로 이전 GPT-5.6 Terra보다 15%포인트 높은 점수를 약 3분의 1 비용으로 냈습니다. 문서 작성뿐 아니라 도면을 읽어 3D 모델로 옮기는 작업도 포함된 평가입니다. 모든 사무 작업에서 같은 절감률이 나온다는 뜻은 아닙니다. 모델 발표와 평가
표준 API 가격은 100만 토큰당 입력 1달러, 캐시된 입력 0.05달러, 출력 5달러입니다. 캐시 쓰기는 별도 요금이고, 입력이 27만 2천 토큰을 넘는 요청에는 전체 요청의 입력·캐시 요금 2배, 출력 요금 1.5배가 적용됩니다. 긴 화면 작업 이력을 계속 붙인다면 기본 단가만으로 비용을 계산하기 어렵습니다. 모델 사양·가격
같은 화면 작업을 더 낮은 비용으로 반복할 수 있다는 점은 반갑습니다. 실제로 비교해볼 때는 클릭 한 번의 가격보다, 잘못 누른 뒤 되돌아오는 과정까지 포함해 한 작업이 얼마에 끝나는지 보고 싶습니다.
Cloudflare — 성공 응답 뒤에 다른 고객의 데이터가 있었다
Cloudflare는 10월 26일 Workers AI의 GLM-5.3에서 발생했던 고객 간 데이터 노출을 공개했습니다. 사고가 발생한 기간은 8월 27일~9월 9일이며, 9월 9일 수정 후 서비스를 복구했습니다. 이번 주 새로 발생한 장애가 아니라, 원인과 대응을 뒤늦게 공개한 보고서입니다.
회사에 따르면 영향을 받은 응답은 155건이고 모두 입력이 681,280토큰을 넘었습니다. 모델이 받도록 설정한 문맥 길이는 약 105만 토큰이었지만, 입력을 처리하는 GPU의 KV 캐시 공간은 그보다 작았습니다. 여기에 추론 엔진 SGLang의 오류 처리가 겹쳤습니다. 수용할 수 없는 요청이 정상적으로 중단되지 않으면서, 이전 요청의 데이터가 남은 캐시를 읽어 답을 생성했습니다.
출시 전 시험에서는 성공 상태 코드와 오류 없는 스트리밍 응답이 나왔습니다. 응답이 끝까지 돌아온다는 사실만으로 입력이 올바르게 처리됐다고 볼 수 없었던 사례입니다. Cloudflare는 다른 Workers AI 모델은 영향을 받지 않았으며 의도적인 악용의 증거를 찾지 못했다고 밝혔습니다. 이 범위는 회사의 조사 결과입니다. 사고 보고서
Anthropic — 취약점 하나를 찾는 데서 끝나지 않았다
Anthropic은 10월 27일 내부 연구 모델로 찾아낸 다섯 가지 공격 경로를 공개했습니다. Chrome과 Safari, Android, Windows, Linux를 대상으로 한 사례입니다. 일반 사용자가 지금 고를 수 있는 Claude 모델의 성능 발표가 아니라, 아직 출시하지 않은 모델을 이용한 연구 결과입니다.
Chrome 사례에서는 초기 지시 뒤 여러 취약점을 연결해 브라우저의 격리 경계 밖에서 코드를 실행하는 과정까지 만들었다고 설명합니다. 취약한 코드 조각을 지적하는 것과, 여러 약점을 이어 실제 영향으로 입증하는 것 사이의 간격을 보여줍니다. 여기서 소개한 것은 공개된 연구 결과이며 공격 과정을 재현한 것은 아닙니다.
연구진은 검사 에이전트를 많이 돌리는 것뿐 아니라, 각 검사 방식이 기존 결과에 없던 취약점을 얼마나 더 찾았는지도 측정했습니다. 확인된 결과는 공통 검증·위험 평가 과정을 거쳤습니다. 찾은 개수만 비교하는 방식보다, 검사 방식이 서로 놓친 부분을 보완하는지 살핀 대목이 눈에 남습니다. Anthropic 연구 보고서
Vercel — AI가 다녀간 페이지를 따로 본다
사이트 방문 통계에서 AI 봇의 요청을 확인하는 기능이 Vercel Observability에 추가됐습니다. 10월 27일 발표된 AI Traffic 화면에서는 확인된 AI 봇별 요청 수, 크롤러가 많이 찾은 페이지, 사용자의 요청을 받아 AI 어시스턴트가 가져간 페이지를 나눠 볼 수 있습니다. Markdown 요청과 오류가 난 경로도 표시합니다. CLI로 조회하려면 Observability Plus가 필요합니다. 발표 · 지표 설명
예를 들어 제품 설명 페이지는 잘 읽히는데 가격 페이지에서 오류가 난다면, AI를 통해 제품을 알아보는 과정이 어디서 끊기는지 살펴볼 단서가 됩니다. 단순히 봇 방문이 늘었다는 숫자보다 손볼 곳을 찾기 좋습니다.
다만 페이지를 가져갔다는 기록만으로 그 내용이 최종 답변에 인용됐는지, 제품 추천이나 구매로 이어졌는지는 알 수 없습니다. AI에게 잘 보이는 사이트를 만들고 싶더라도, 먼저 확인할 수 있는 것은 ‘무엇을 읽으러 왔고 어디서 실패했는가’입니다.
Google — 로봇의 다음 행동을 고르는 모델이 공개 프리뷰로
Google은 10월 27일 Gemini Robotics ER 2를 Google Cloud의 Gemini 플랫폼에서 공개 프리뷰로 제공한다고 발표했습니다. 모델 자체는 앞서 소개됐고, 이번 변화는 기업이 Cloud 환경에서 접근할 수 있는 범위가 넓어진 것입니다. Google Cloud 발표
ER 2는 영상을 보고 작업의 진행 상태를 해석하고, 여러 단계의 행동을 계획합니다. 실제 이동이나 조작은 개발자가 연결한 로봇 API와 행동 모델 등을 통해 수행합니다. ‘컵을 집어라’는 요청을 이해하는 일과 모터를 제어하는 일을 구분해 생각하면 역할이 조금 선명해집니다.
공식 문서에는 계기판 읽기, 영상에서 특정 순간 찾기, 작업 성공 여부 판별, 여러 로봇의 작업 조율이 나옵니다. 프리뷰 모델은 gemini-robotics-er-2-preview이며 현재 엔드포인트는 global만 지원합니다. 어떤 로봇에나 곧바로 연결해 안전하게 작동한다는 보장은 별개입니다. 장치별 도구 연결과 물리 환경에서의 검증은 여전히 필요합니다. 모델 개요와 이용 조건
GitHub — 자동화에 개인 계정 대신 조직의 신원을 준다
10월 27일 공개 프리뷰에 들어간 Copilot의 서버 간 인증도 짧게 짚겠습니다. Copilot SDK로 만든 서비스가 로그인한 개인의 자격증명 없이, 조직에 설치한 GitHub App의 단기 토큰으로 요청할 수 있게 됐습니다. 사용량과 비용은 조직에 귀속되고 조직의 모델 정책·예산이 적용됩니다. 관리자는 앱을 정지하거나 제거해 접근을 끊을 수 있습니다. GitHub 발표
개인이 자리를 비워도 돌아가는 서비스를 만들 때 살펴볼 변화입니다. 다만 설치 토큰은 한 시간 뒤 만료되므로 갱신이 필요합니다. GitHub Actions 안에서는 별도 앱을 만드는 대신 내장 GITHUB_TOKEN을 쓰는 경로가 문서에 구분돼 있습니다. 인증 주체를 바꾸는 기능이지, 에이전트가 수행할 모든 작업을 승인해주는 기능은 아닙니다. 인증·갱신 문서
L-Proof의 해석
승인 창이 줄면, 무엇을 놓쳤는지 더 알아야 한다
승인을 반복하다 보면 중요한 요청도 익숙한 창 하나로 보이기 쉽습니다. 그 부담을 줄이려는 Copilot의 시도에는 이유가 있습니다. L-Proof가 궁금한 것은 자동 승인 비율보다, 잘못 통과시킨 일을 나중에 얼마나 구체적으로 설명할 수 있는가입니다.
가령 에이전트가 로그를 읽어도 된다는 요청을 외부 서비스에 로그를 보내도 된다는 뜻으로 넓게 받아들였다고 해봅시다. 이때 실행 모델과 승인 모델이 같은 해석을 공유했다면, 검토를 한 번 더 거쳤다는 사실만으로 오해가 풀리지는 않습니다. 두 모델이 서로 다른 이름을 갖는지보다, 승인 판단에 어떤 요청과 어떤 전송 대상이 제시됐는지가 중요해집니다.
Vercel의 설명에서는 사람이 읽는 계획과 토큰이 허용하는 범위 사이에도 간격이 남습니다. L-Proof는 이 간격을 숨기지 않는 제품이 더 유용하다고 봅니다. 사용자는 계획에 적힌 행동만 허용했다고 생각하는데, 시스템은 더 넓은 종류의 행동을 허용할 수 있기 때문입니다.
그렇다고 모든 클릭을 다시 사람에게 돌리면 같은 피로로 돌아갑니다. 자동으로 통과한 작업 일부를 되짚어보면서, 원래 부탁과 실제 행동이 어긋난 사례를 찾는 쪽이 다음 검토 기준을 고치는 데 도움이 될 수 있습니다. 이를 하려면 ‘승인됨’이라는 표시 외에 판단에 사용한 범위와 실제 실행 결과가 남아야 합니다.
완료 표시에 질문을 하나 더 붙인다면
Cloudflare의 사례는 승인 기능의 실패와는 다른 문제입니다. 허용 범위 안에서 요청했더라도, 실행 인프라가 다른 고객의 데이터를 섞어 내보낼 수 있었습니다. 모델에게 더 신중하게 판단하라고 시켜서 해결할 종류의 문제가 아니었습니다.
그런데 두 이야기를 읽고 나면 완료 기록을 보는 습관은 조금 달라질 수 있습니다. ‘허용된 작업인가’에 이어 ‘정확히 어떤 입력과 대상에 대해 끝났는가’를 묻게 됩니다. 성공 상태 코드가 돌아왔고 답변도 자연스럽다는 이유만으로 이 두 번째 질문이 해결되지는 않습니다.
L-Proof는 자동 승인이 늘어나는 만큼 검토 기록이 길어져야 한다고 생각하지 않습니다. 기록이 많아도 중요한 차이를 찾기 어렵다면 다시 읽지 않게 될 겁니다. 대신 문제가 생겼을 때, 사용자의 요청이 넓게 해석된 것인지, 허용된 작업이 잘못 실행된 것인지 구분할 수 있기를 바랍니다.
다음에는 승인 창을 얼마나 줄였는지와 함께, 잘못 통과한 일을 어떻게 발견하고 고쳤는지도 보고 싶습니다.