AI가 일을 마쳤는데, 다음 지시가 오지 않습니다. Anthropic이 공개한 사내 분석에서 대화형 Claude 세션 시간의 약 80%는 사람의 입력을 기다리는 시간이었습니다. 모델이 느려서 생긴 대기가 아닙니다. Anthropic 연구 보고서
지난 호에서는 밤새 만든 코드 중 무엇을 받아들일지 살폈습니다. 이번에는 그 결과를 읽고 관리하는 데 얼마나 많은 일이 생기는지 들여다봅니다.
10월 13~18일 공개 자료에서 기존 호와 겹치지 않는 변화들을 골랐습니다. 아래 소식은 모두 03 · 공식 확인입니다. 개발사 발표와 문서를 대조했으며, 제품이나 실험을 직접 재현한 것은 아닙니다.
Anthropic — Claude를 관리할 도구를 만드는 직원들
Anthropic은 10월 16일 자사 내부의 고용·AI 사용·업무 변화에 관한 연구를 공개했습니다. 내부 기록과 설문, 직원 17명 인터뷰를 함께 분석했습니다.
비개발 직군에서도 대화형 Claude의 출력을 전부 읽으려면 근무 주간의 절반 이상이 필요하다는 추정이 나왔습니다. 실제로 그만큼 읽었다는 측정은 아닙니다. 출력량을 토큰당 0.75단어로 환산하고 분당 250단어를 읽는다고 가정한 계산입니다. 앞의 80% 역시 대화형 세션의 경과 시간에서 에이전트의 실제 작업 시간을 뺀 값으로, 모든 자율 실행 작업의 유휴율을 뜻하지 않습니다.
직원들은 쏟아지는 결과를 정리할 도구를 만들고 있었습니다. 한 엔지니어는 다른 에이전트들의 요청을 분류할 비서실장 역할의 에이전트를 만들었습니다. 일을 맡긴 뒤 돌아오는 요청을 정리하는 일도 다시 자동화하고 있었습니다. 직원별 대화형 Claude 세션에서 이런 ‘메타워크’가 차지하는 비중은 평균 10%(2025년 가을)에서 22%(2026년 봄)로 늘었다고 합니다. 대화 요약 표본을 자동 분류해 추정한 세션 비중이며, 근무시간의 비중은 아닙니다.
AI를 만드는 회사가 자기 조직을 분석한 사례입니다. 모든 회사의 미래로 옮겨 읽기는 어렵지만, 에이전트를 많이 쓰는 곳에서 어떤 일이 새로 생기는지는 구체적으로 보여줍니다. 연구 내용과 측정 방법
GitHub — 보안 경고를 수정 PR로, 단 검사의 범위는 따로
보안 경고를 받은 뒤 관련 파일을 찾고, 고친 다음 같은 검사를 다시 돌리는 과정까지 Copilot에 맡길 수 있게 됐습니다. GitHub는 10월 15일 agentic autofix를 정식 제공하기 시작했습니다. 에이전트는 CodeQL을 다시 실행해 경고가 해소되는지 확인하고, 수정 이유와 검증 과정을 담은 초안 PR을 엽니다. 기본 브랜치의 경고가 대상이며, 최대 25개를 한 PR에서 함께 다룰 수 있습니다. Agentic autofix 발표
같은 날 정식 제공된 AI Scan은 PHP·Shell/Bash·Terraform 설정 등 CodeQL이 현재 다루지 못하는 언어·프레임워크의 PR 변경을 보완 검사합니다. 결과는 참고 의견으로, code scanning 검사 실패나 ruleset을 통한 병합 차단 조건이 되지 않습니다. 포크에서 온 PR과 Dependabot PR도 검사 대상에서 제외됩니다. “검사가 초록색이었다”는 말만으로 AI가 제기한 보안 우려까지 없었다고 읽을 수는 없습니다. AI Scan 발표
사용 조건
>
- Agentic autofix: Enterprise Cloud의 Code Security 또는 Advanced Security 고객용입니다. 관리자 활성화와 Copilot 결제 수단 설정이 필요하며, Code Security AI Credits와 Actions 사용 시간을 소모합니다. - AI Scan: code scanning과 AI Scan 설정을 켜야 합니다. 공개 저장소에서 사용할 수 있고, 조직의 비공개·내부 저장소에는 위 보안 상품이 필요합니다. Copilot 라이선스 없이도 사용할 수 있지만 Code Security AI Credits는 소모합니다.
Cursor — 에이전트가 만든 화면을 함께 열어본다
Cursor의 Canvas는 채팅 옆에 표·차트·분석을 별도 화면으로 펼쳐놓는 기능입니다. 긴 답변을 읽는 것과 달리 화면의 구성을 바꾸거나, 에이전트에게 수정을 요청하고 나중에 다시 열어볼 수 있습니다. 10월 16일 업데이트로 클라우드 에이전트도 작업 중 Canvas를 만들고 완성된 화면을 팀에 링크로 공유할 수 있게 됐습니다. 변경 기록
공식 문서가 드는 용도는 대시보드, 분석, 감사, 보고서입니다. 공유받은 팀원은 에이전트를 다시 실행하지 않고 같은 표와 차트를 브라우저에서 읽기 전용으로 봅니다. 작성자는 원래 Canvas를 수정한 뒤 Publish로 공유 화면을 갱신할 수 있습니다. 함께 편집하는 문서라기보다, 작성자가 갱신해 전달하는 결과 화면에 가깝습니다.
공유에는 지원되는 유료 플랜과 팀 소속, 데이터 저장을 허용하는 프라이버시 설정이 필요합니다. Legacy Privacy Mode에서는 공유할 수 없고, 팀 관리자도 기능을 끌 수 있습니다. 개인 유료 플랜을 쓰더라도 팀에 속해 있어야 공유할 수 있으므로, 외부 누구에게나 보내는 공개 링크로 생각하면 안 됩니다. Canvas 동작과 공유 조건
별도 업데이트 — 클라우드 실행 환경
같은 날 Environments API 베타도 나왔습니다. 클라우드 에이전트의 실행 환경을 프로그램으로 생성·관리하는 기능입니다. 별도로 클라우드 실행 환경은 최대 300개 저장소를 지원하게 됐습니다. 이 숫자는 API 호출 한도가 아닙니다. 결과물을 팀에 전달하는 Canvas와 실행 환경을 구성하는 API는 용도가 다른 업데이트입니다. 환경 관련 발표
Vercel — 같은 대화인데 캐시를 다시 못 쓰는 이유
에이전트의 대화가 이어지면 앞서 보낸 문맥도 다음 요청에 포함됩니다. 이때 같은 모델을 쓰더라도 요청을 처리하는 제공업체가 바뀌면, 앞선 업체에 남은 프롬프트 캐시를 그대로 이용할 수 없습니다. Vercel의 기존 session affinity는 앞선 요청을 처리한 제공업체를 다음 요청에서도 우선 시도해 캐시 재사용을 돕습니다. Session affinity 문서
10월 17일 추가된 AI Gateway Sessions 화면은 그 과정을 대화 단위로 보여줍니다. Claude Code·Codex·Cursor 등 어떤 앱에서 시작한 세션인지, 모델과 제공업체, 비용, 입력의 캐시 사용 현황을 함께 볼 수 있습니다. 세션을 열면 각 턴의 처리 시간과 제공업체가 바뀐 경로도 나옵니다. 요청 하나의 비용을 확인하는 데서 나아가, 여러 번 오간 대화에서 비용과 캐시 사용이 어떻게 누적됐는지 살펴볼 수 있게 된 것입니다. Sessions 발표
단, 같은 제공업체를 계속 쓴다는 보장은 아닙니다. 장애가 나면 다른 업체를 시도하고, 개발자가 허용하지 않은 업체를 캐시 때문에 새로 선택하지도 않습니다. 모델·제공업체별 캐시가 따로 있다는 점도 그대로입니다. 이번에 새로 나온 것은 이 경로를 들여다보는 화면입니다. 라우팅과 캐시 동작
매번 같은 지시로 시작하는 자동화라면 실행마다 고유한 세션 ID를 보내는 편이 좋습니다. ID 없이 자동 분류할 경우, 같은 시스템 지시·도구·첫 사용자 메시지로 시작하는 별개의 실행이 하나의 세션으로 묶일 수 있기 때문입니다. 단일 턴 세션은 화면의 기본 필터에서 숨겨져 있습니다. 세션 식별 방식 · 화면 필터
OpenAI — 말하는 도중에 고개를 끄덕이는 AI
사용자가 좋은 소식을 말하는 동안 화면 속 캐릭터가 미소 짓고 고개를 끄덕입니다. 답변이 모두 만들어진 뒤 애니메이션을 붙이는 장면이 아닙니다. OpenAI가 문서에서 보여주는 GPT-Live와 Decisions의 연동 예시입니다. 실제 사용자 대상 성능 실험으로 제시된 것은 아닙니다. 공식 예시
10월 15일 GPT-Live에 Decisions 네이티브 연동이 공개됐습니다. 사용자 정의 연동에서는 앱이 Live의 요청을 받아 Decisions에 전달합니다. 이번 네이티브 연동에서는 Live가 직접 호출해 앱을 거치는 왕복을 줄입니다. Live가 앱에서 처리할 요청을 알아차렸을 때 판단을 맡기거나, 사용자와 AI의 발화가 텍스트 조각으로 들어올 때마다 판단을 시작하도록 설정할 수 있습니다. 앞서 다룬 API 공개 베타 이후, 이번에는 음성 대화 안으로 연결점이 들어온 것입니다. 릴리스 노트 · 연동 방식
문서의 다른 예시는 차량 음성 비서입니다. 춥다는 말에는 온도 조절을 선택하고, 길 안내와 식당 검색까지 요청하면 Responses API에 넘길지도 함께 판단합니다. 선택지를 고르는 단계와 실제 장치를 조작하거나 검색하는 단계는 나뉩니다. 앱은 실행 결과를 확인해 대화에 돌려줘야 합니다.
실시간 반응에는 순서 문제도 남습니다. 여러 발화 조각을 묶어 처리할 수 있고, 판단 결과가 발화 순서와 다르게 도착할 수도 있습니다. 문서는 결과의 원본 이벤트 ID를 확인하고 입력·출력 각각에서 최신의 관련 결과를 적용하도록 안내합니다. 캐릭터의 입 움직임은 판단 결과가 아니라 음성에 맞추도록 구분합니다. 무엇을 판단했는지와 그 판단이 어느 순간에 해당하는지를 함께 다뤄야 하는 연동입니다. 이벤트 처리 안내
Vercel Daemons — 요청이 없어도 작업을 가져오는 워커
Vercel이 10월 15일 공개 베타로 내놓은 Daemons는 계속 켜져 작업을 기다리는 프로세스를 앱과 같은 프로젝트에 배포하는 기능입니다. 영상 처리 요청을 큐에 쌓고, 별도 워커가 하나씩 가져가 처리하는 서비스가 있다고 해봅시다. 웹 요청에 응답하는 코드와 달리, 이 워커는 다음 작업을 기다리며 실행을 이어갑니다.
공식 발표는 Celery·BullMQ 같은 큐 소비자, Temporal 워커, 작업을 가져오는 자체 CI 러너를 예로 듭니다. HTTP 서버를 열 필요 없이 컨테이너가 큐나 데이터베이스에서 일을 가져옵니다. 개발자가 지역별 인스턴스 수를 정하면 Vercel이 그 수를 유지하고, 종료되거나 비정상 중단된 인스턴스를 다시 시작합니다. Daemons 발표
베타의 범위는 분명합니다. 프로덕션 배포에서 수동으로 인스턴스 수를 정하며, 프리뷰 배포·자동 확장·영구 저장소는 지원하지 않습니다. 인스턴스가 다시 시작된다고 진행 중이던 작업까지 안전하게 이어지는 것도 아닙니다. 문서는 작업이 중단되거나 반복 실행돼도 문제가 없도록 설계하고, 큐 메시지는 처리가 끝난 뒤 완료 확인을 보내라고 안내합니다. 로컬의 vercel dev도 아직 Daemons를 실행하지 않아 별도 Docker 실행이 필요합니다. 베타 범위와 작업 종료 처리
L-Proof의 해석
먼저 볼 것을 고르면, 뒤로 밀리는 것도 생긴다
L-Proof는 앞으로 에이전트가 만든 작업물의 품질과 함께 사람에게 검토를 요청하는 방식의 품질도 따로 보게 될 것으로 생각합니다. 결과가 많아질수록 무엇부터 읽을지 정하는 단계에서 이미 판단이 시작되기 때문입니다.
분류를 AI에 맡기면 사람이 읽은 요약은 정확하더라도, 중요하지 않다고 분류돼 화면에서 밀려난 변경에 문제가 있을 수 있습니다. 검토 시간이 줄었다는 수치만으로는 그 차이를 알 수 없습니다. 나중에 문제가 된 변경이 처음에는 어느 순서에 놓였는지도 함께 봐야 합니다.
그렇다고 에이전트가 사람을 기다리는 시간을 전부 낭비로 볼 수는 없습니다. 여러 부서가 영향을 받는 변경이라면, 모델이 확신하더라도 사람이 합의할 시간이 필요합니다. L-Proof가 줄이고 싶은 것은 그런 판단의 시간이 아니라, 판단할 대상을 찾느라 쓰는 시간입니다.
통과 표시는 어디까지 책임질 수 있을까
L-Proof는 검토 요청에 ‘먼저 봐야 하는 이유’와 ‘아직 확인하지 못한 범위’를 함께 남겨야 한다고 봅니다. 그래야 사람이 결과뿐 아니라, AI가 정한 검토 순서도 바꿀 수 있습니다.
검토 화면에서도 통과한 검사와 함께, 병합을 막지 않는 경고와 검사하지 않은 범위를 볼 수 있어야 합니다. 그래야 사람이 “통과”를 보고 검토를 끝낼지, 추가 확인을 할지 고를 수 있습니다. 경고를 숨겨 화면을 단순하게 만들면, 그 선택까지 대신 내려버릴 수 있습니다.
사람에게 올리는 알림이 줄어들면 반가울 것입니다. 그다음에는 이렇게 묻게 될 것 같습니다. 정말 확인할 일이 줄었을까요, 아니면 확인해야 할 일이 덜 보이게 됐을까요.