2026년 10월 26일 AI 트렌드: Qwen Code 권한 규칙, Vercel Eve 승인 통제와 반복 평가

2026년 10월 26일 오전 9시(한국 시간)까지 확인한 AI 트렌드의 핵심은 에이전트가 무엇을 할 수 있는지 정하고, 승인 답변을 누구에게서 받았는지 확인하며, 같은 업무를 여러 번 시험하는 운영 방식입니다. Qwen Code는 사전공개판에 세션 권한 규칙을 추가했습니다. Vercel의 오픈소스 에이전트 프레임워크 Eve는 부모 에이전트의 메시지가 사람의 승인을 대신하지 못하도록 고쳤고, 반복 평가 기능을 보강했습니다. 세 변화는 모두 모델 성능 발표가 아니라 실제 업무에 에이전트를 연결할 때 필요한 통제 기능입니다.

조사 기준은 10월 25일 18시부터 26일 09시까지, 시간대는 Asia/Seoul입니다. 이 구간에 공식 발표가 충분하지 않아 10월 24일 21시까지 넓혔습니다. 첫 번째 소식은 기본 구간, 나머지 둘은 확장 구간에 들어갑니다. 세 항목 중 둘은 같은 제품인 Eve의 연속 패치입니다. 개별 기능과 릴리스 시각이 달라 나누어 설명하지만, 이를 세 회사의 독립 발표처럼 세지 않겠습니다. 전날 글에서 다룬 Qwen Code v0.26.1 안정판의 세션 복구 기능은 반복하지 않고, 이후 나온 사전공개판의 새 권한 변경만 봅니다.

한눈에 보는 오늘의 AI 업데이트

위 시각은 각 공식 GitHub 릴리스 화면의 UTC 표시를 한국 시간으로 바꾼 값입니다. 릴리스에 포함된 개별 코드 변경의 작성 시각, 모든 사용자의 설치·적용 시각과는 다릅니다. 저는 이런 날일수록 ‘새 AI 모델이 없으니 오래된 발표를 오늘 출시로 다시 소개하자’는 식의 편집을 피하는 편이 낫다고 봅니다. 오늘 확인한 것은 작은 버전 변경이지만, 회사의 자동화 운영에는 꽤 직접적인 질문을 던집니다.

1. Qwen Code: 세션 권한 규칙을 사전공개판에 추가

QwenLM은 Qwen Code 사전공개 릴리스에 관리형 작업의 세션 권한 규칙과 자동 승인을 추가했다고 적었습니다. 같은 릴리스에는 프로젝트 환경변수로 인한 서빙 토큰 결정 경로를 강화한 수정, 실험적인 공통 에이전트 루프, CLI 취소·재시도 동작 개선도 포함됩니다. 다만 제목에 nightly가 붙고 GitHub가 Pre-release로 표시하는 버전입니다. 사전공개판의 기능을 모든 이용자에게 적용된 안정판 기능이라고 읽으면 안 됩니다.

무엇이 바뀌었나

릴리스 노트가 확인해 주는 범위는 ‘세션 단위의 권한 규칙과 자동 승인 기능이 추가됐다’는 사실입니다. 어떤 기본 규칙이 모든 환경에서 켜지는지, 승인 가능한 작업의 정확한 목록이 무엇인지는 이 짧은 노트만으로 단정하기 어렵습니다. 운영 환경에 적용하려면 해당 버전의 설정 문서와 실제 실행 화면을 확인해야 합니다. 특히 자동 승인은 모든 요청을 무조건 허용한다는 뜻으로 해석해서는 안 됩니다.

어제 소개한 v0.26.1 안정판은 작업이 끊겼을 때 세션과 기록을 이어 다루는 데 초점이 있었습니다. 오늘 사전공개판의 초점은 작업이 진행되는 동안 무엇을 허용할지입니다. 복구와 권한은 둘 다 긴 에이전트 작업에 필요하지만 서로 다른 문제입니다. 복구가 잘 돼도 잘못된 파일을 읽거나 외부로 보내는 권한까지 넓으면 안전한 운영이라고 말할 수 없습니다.

왜 중요한가: ‘매번 묻기’와 ‘전부 허용’ 사이의 설계

업무 자동화에서 사람 승인은 시간이 듭니다. 폴더 목록 조회나 임시 파일 생성처럼 반복되는 저위험 단계마다 멈추면 에이전트의 장점이 사라집니다. 반대로 외부 발송, 고객 데이터 수정, 결제·정산 처리까지 같은 규칙으로 자동 승인하면 작업 속도는 빨라져도 되돌릴 수 없는 실수의 비용이 커집니다. 윤자동의 실무 해석은 권한을 작업 유형별로 나누고, 자동 승인 범위를 읽기 전용 조회와 제한된 임시 작업에서 시작하는 것입니다.

예를 들어 고객 문의를 분류하는 에이전트라면 메일 제목과 본문 조회, 내부 초안 생성, 분류 제안까지는 정해진 범위에서 진행할 수 있습니다. 답장 발송, 다른 고객의 자료 열람, 청구 정보 수정은 다른 승인 규칙이 필요합니다. 구현할 때는 ‘누가 실행했는가’뿐 아니라 무슨 권한으로, 어떤 자료에, 어느 시각에 접근했는가가 남아야 합니다. 이것은 Qwen Code가 그 모든 감사를 자동으로 제공한다는 뜻이 아닙니다. 오늘 릴리스를 계기로 기업이 별도로 정해야 할 운영 기준입니다.

적용 전에 확인할 점

첫째, 사전공개판입니다. 개발용 격리 환경에서 동일한 작업을 반복해 본 뒤 안정판 반영 여부를 확인하세요. 둘째, ‘자동 승인’이라는 문구만 보고 사용 범위를 추정하지 마세요. 셋째, 권한 규칙이 프로젝트 설정이나 환경변수와 충돌할 때 어느 규칙이 이기는지 시험해야 합니다. 넷째, 승인 기록이 남더라도 그것이 실제 파일·네트워크 접근을 막는 기술적 통제인지 구분해야 합니다. 정책 화면과 실행 격리는 서로 다른 층위입니다.

저는 도입 시험에서 먼저 세 가지 행동을 시켜 봅니다. 허용한 폴더의 파일 읽기, 허용하지 않은 위치의 파일 읽기, 외부 전송 시도입니다. 결과는 ‘성공 또는 실패’만 적지 않고 실제 접근 차단, 승인 요청, 로그 기록을 각각 봅니다. 같은 명령이라도 현재 폴더나 실행 주체가 바뀌면 결과가 달라질 수 있기 때문입니다. 이 검증이 끝나기 전에는 밤새 실행되는 작업에 넓은 자동 승인 권한을 주지 않는 편이 좋습니다.

2. Vercel Eve 0.83.2: 하위 에이전트의 승인은 사람의 답으로만 처리

Vercel의 Eve 0.83.2 릴리스는 부모 에이전트가 하위 에이전트에게 보낸 메시지가, 하위 에이전트가 기다리던 도구 승인이나 세션 제한 질문의 답으로 처리되던 동작을 고쳤다고 설명합니다. 릴리스 노트는 이전에 부모가 보낸 approve나 continue 같은 후속 메시지가 사람의 답처럼 요청을 처리할 수 있었다고 적습니다. 수정 뒤에는 사람의 구조화된 답변만 승인 요청을 처리하고, 부모의 메시지는 일반 메시지로 전달됩니다. 세션 제한 질문도 사람의 답을 기다립니다.

기능 변경보다 승인 경계가 핵심

에이전트가 다른 에이전트를 호출하는 구조에서는 대화가 여러 층으로 나뉩니다. 사용자, 상위 에이전트, 하위 에이전트가 같은 작업을 논의해도 승인 권한까지 같은 것은 아닙니다. 하위 에이전트가 외부 API 호출이나 파일 쓰기 전에 사람의 확인을 기다리는 중이라면 상위 에이전트의 문자 메시지가 그 확인을 대체해서는 안 됩니다. Eve의 이번 수정은 이런 경계를 프로그램 동작으로 분리한 사례입니다.

Eve가 발표한 것은 특정 프레임워크에서 발견하고 수정한 동작입니다. 모든 에이전트 제품에 같은 결함이 있다는 뜻도, 수정 하나로 모든 승인 문제가 사라졌다는 뜻도 아닙니다. 기업이 가져갈 교훈은 ‘승인 버튼이 있다’는 설명보다 승인 응답의 발신자와 형식이 검증되는지를 시험해야 한다는 점입니다. 작업 요청 문장에 ‘승인합니다’가 들어 있다고 해서 인증된 승인 기록과 같게 취급하면 안 됩니다.

기업 업무에 적용하면

고객 상담 에이전트가 하위 에이전트에게 견적 초안을 만들라고 맡기는 상황을 가정해 보겠습니다. 초안 작성은 허용하지만 최종 견적서 송부는 담당자의 확인을 거쳐야 합니다. 이때 상위 에이전트가 ‘계속 진행해’라고 말했더라도 그것은 작업 지시일 뿐, 담당자가 수신자·금액·첨부를 본 뒤 누른 승인과 다릅니다. 시스템은 둘을 구분해야 하고, 로그에서도 ‘에이전트 내부 메시지’와 ‘사람 승인 이벤트’가 다른 종류로 남아야 합니다.

실무 시험은 일부러 애매한 문장을 만들어 보는 방식이 좋습니다. 하위 에이전트가 승인을 기다리게 한 뒤, 상위 에이전트에서 ‘좋아’, ‘계속’, ‘승인’ 같은 메시지를 보내세요. 아무 것도 실행되지 않아야 합니다. 이어 담당자가 지정된 승인 화면에서 확인했을 때만 다음 단계가 진행되는지 확인합니다. 세션이 오래돼 만료되거나 질문이 여러 개 동시에 뜬 경우에도 각각의 대상과 답이 정확히 연결되는지 봐야 합니다.

같은 릴리스의 다른 운영 수정

0.83.2에는 연결 도구 호출이 답 없이 계속 걸려 있지 않도록 5분 뒤 오류로 종료하는 수정, 로그인 제공자가 오류를 돌려보냈을 때 성공처럼 안내하지 않는 수정, 평가 기록에서 에이전트 도구 입력을 보존하는 수정도 실렸습니다. 이 내용은 Vercel의 릴리스 노트가 설명한 동작입니다. 특정 회사의 시스템에서 같은 시간 제한이나 오류 처리가 필요하다는 결론은 별도의 업무 요구 분석을 거쳐야 합니다.

저는 이 부분을 ‘멈출 수 있는 자동화’의 관점에서 읽습니다. 도구가 무응답일 때 무한 대기하지 않는지, 실패 메시지가 성공처럼 보이지 않는지, 나중에 왜 그 판단을 했는지 입력이 남는지 확인해야 합니다. 장시간 업무에서는 성공 경로를 한 번 보여 주는 데모보다, 실패했을 때 다음 사람이 어디서 이어받을 수 있는지가 운영 품질을 가릅니다.

3. Vercel Eve 0.83.1: 같은 평가를 여러 번 실행하고 시도별로 기록

같은 날 앞서 공개된 Eve 0.83.1 릴리스는 eve eval --repeat <n>과 설정의 repeat 옵션을 소개합니다. 하나의 평가를 여러 차례 실행하고 각 시도를 별도 결과로 기록하는 기능입니다. 릴리스 노트에 따르면 시도마다 번호가 붙고, 결과 파일과 외부 관찰 도구의 행이 분리되며, 콘솔에는 3/5 passed처럼 통과 횟수가 표시됩니다. 고객 환경에서 통과율이 실제로 얼마나 좋아진다는 주장은 아닙니다.

왜 한 번 성공으로는 부족한가

AI 에이전트의 출력은 모델 선택, 이전 맥락, 도구 응답, 외부 서비스 상태에 따라 달라질 수 있습니다. 같은 요청을 한 번 실행해 원하는 답이 나왔어도 다음 실행에서 누락되거나 다른 도구를 호출할 수 있습니다. 업무 자동화가 매일 반복된다면 성공 사례 한 건보다 반복했을 때 실패가 어디서 생기는지가 중요합니다. Eve의 새 기능은 그 반복 관찰을 평가 절차 안에 넣기 쉽게 합니다.

예를 들어 회의록에서 후속 조치를 뽑는 에이전트를 시험한다고 해 보겠습니다. 평가 질문을 ‘담당자와 마감일이 있는 항목만 추출하고, 없는 값은 만들지 않는다’로 정합니다. 동일한 자료를 다섯 번 처리해 네 번 맞고 한 번 임의 날짜를 만들었다면, 사용자에게 보여 줄 데모는 성공했어도 운영 배포 기준으로는 다시 봐야 합니다. 이 예의 횟수와 결과는 설명을 위한 가상 사례입니다. Eve가 해당 업무에서 그런 수치를 기록했다는 뜻이 아닙니다.

반복 평가를 실무에 붙이는 방법

첫 단계는 정답을 좁게 정의하는 것입니다. ‘좋은 요약’처럼 사람마다 판단이 다른 기준만 두지 말고, 고객명 누출 여부, 금액 일치, 승인 전 발송 금지, 출처 링크 존재처럼 확인 가능한 조건을 섞습니다. 두 번째는 같은 입력으로 반복할 뿐 아니라 유사하지만 다른 입력도 준비하는 것입니다. 길이가 긴 문서, 빈 첨부, 권한 없는 링크, 모호한 날짜처럼 실제 실패가 일어나는 자료가 필요합니다.

세 번째는 시도별 결과를 남기는 것입니다. 다섯 번 중 네 번 통과했다는 숫자만 보면 어떤 실패가 있었는지 놓칠 수 있습니다. 실패한 입력, 모델과 도구 버전, 응답, 중단 지점을 함께 보관해야 수정 후 재현할 수 있습니다. 네 번째는 비용을 재는 것입니다. 반복 횟수를 늘리면 호출 비용과 시간이 늘어납니다. 위험이 큰 발송·수정 업무에는 더 깊은 검증을, 단순 분류 업무에는 작은 표본을 적용하는 식으로 균형을 맞출 수 있습니다.

평가가 안전을 자동 보장하지는 않는다

3/5 passed는 평가 세트에서 세 번 통과했다는 표시입니다. 현실의 모든 상황에서 60%만큼 안전하다는 통계도, 새 요청에 대한 성공 확률을 보증하는 값도 아닙니다. 테스트 자료가 쉬우면 반복 실행해도 위험을 놓칩니다. 반대로 외부 서비스가 일시적으로 실패해 통과율이 낮아질 수도 있습니다. 평가 숫자는 결과를 살펴볼 출발점으로 쓰고, 실패 유형과 업무 영향까지 확인해야 합니다.

Eve 0.83.1은 평가 시각을 기록하고 로컬 평가 서버 상태를 유지하는 기능도 설명합니다. 기업 입장에서는 모델 응답만 비교하기보다 요청이 전송되고 수락된 시각, 이벤트가 도착한 시각을 구분해 병목을 찾는 데 참고할 수 있습니다. 다만 이 데이터가 곧바로 최종 사용자 체감 속도 전체를 뜻하는 것은 아닙니다. 화면 표시, 검색, 저장, 사람 승인 대기처럼 회사의 실제 경로를 별도로 측정해야 합니다.

세 업데이트를 하나의 업무 흐름에 놓으면

오늘의 세 항목을 기술 목록으로만 보면 작아 보일 수 있습니다. 실제 업무 흐름에 겹쳐 놓으면 역할이 분명합니다. 먼저 Qwen Code의 권한 규칙처럼 에이전트가 읽고 쓸 수 있는 범위를 정합니다. 다음으로 Eve의 승인 경계처럼 사람이 결정해야 하는 단계는 사람의 답으로만 넘어갑니다. 마지막으로 Eve의 반복 평가처럼 같은 업무를 여러 번 돌려 예외를 찾습니다. 각 제품의 구현은 다르지만, 운영 질문은 한 줄로 모입니다. ‘에이전트가 잘했는가’ 전에 ‘어디까지 할 수 있었고, 누가 다음 단계에 동의했으며, 다시 해도 같은 기준을 지켰는가’입니다.

이 순서는 모델이나 서비스를 바꾸어도 쓸 수 있습니다. 회사가 도입하는 도구가 오늘 소개한 세 제품이 아니어도 권한 범위, 승인 주체, 반복 검증을 따로 문서화할 수 있습니다. 저는 고객 자료를 다루는 자동화를 설계할 때 먼저 외부 발송을 빼고 읽기와 초안만 시험합니다. 그다음 승인 기록이 실제 실행과 연결되는지 확인합니다. 마지막으로 실패 사례를 포함한 여러 입력으로 반복 실행합니다. 멋진 한 번의 성공 화면보다 이 절차가 운영 판단에 더 많은 정보를 줍니다.

기업 AI 도입 실행 체크리스트

1. 업무 한 가지를 고릅니다. 파일 요약, 문의 분류, 초안 작성처럼 결과를 사람이 확인할 수 있는 일부터 시작합니다. ‘모든 사무 업무 자동화’처럼 범위를 넓게 잡으면 권한과 평가 기준을 정하기 어렵습니다.
2. 자료 범위를 적습니다. 에이전트가 읽을 폴더와 계정, 접근하면 안 되는 고객·인사·계약 자료를 구분합니다. 읽기와 쓰기 권한도 별도로 적습니다.
3. 자동 승인 목록을 작게 만듭니다. 조회와 임시 초안처럼 되돌리기 쉬운 동작부터 허용합니다. 고객 송부, 공개 게시, 금전 변경, 삭제는 별도 확인 대상으로 둡니다.
4. 승인 주체를 기술적으로 검증합니다. 메시지에 ‘승인’이라는 단어가 있다는 이유로 통과시키지 않습니다. 인증된 담당자의 승인 이벤트와 해당 내용·대상·시각을 연결합니다.
5. 하위 에이전트 경로를 시험합니다. 상위 에이전트의 ‘계속해’가 사람의 승인으로 해석되지 않는지 일부러 확인합니다. 여러 승인 요청이 동시에 있을 때도 대상을 뒤섞지 않아야 합니다.
6. 반복 평가 세트를 만듭니다. 정상 사례뿐 아니라 자료 없음, 권한 거부, 모호한 날짜, 중복 요청, 외부 서비스 지연을 포함합니다. 통과 횟수와 실패 이유를 함께 저장합니다.
7. 사전공개판을 별도로 표시합니다. 오늘 Qwen Code 항목은 nightly, Eve 항목은 공개 릴리스입니다. 회사의 설치 버전과 릴리스 노트가 같은지 확인한 뒤 적용합니다.
8. 실패 뒤의 업무 인계를 설계합니다. 무응답 도구, 세션 만료, 잘못된 승인 연결이 생겼을 때 누가 멈추고 복구할지 정합니다. 기록이 없으면 반복 실행 중 같은 실수를 찾기 어렵습니다.

자주 묻는 질문

오늘 새 AI 모델이 출시됐나요?

이번 조사에서 공식 발표 시각과 원문을 함께 확인한, 기본 구간 또는 확장 36시간 구간의 주요 신규 모델 발표는 채택하지 않았습니다. 오늘 글은 에이전트 운영 도구의 새 변경 세 가지를 다룹니다. 모델 발표가 없었다고 모든 회사의 출시가 없었다는 뜻은 아닙니다.

Qwen Code의 자동 승인을 곧바로 회사 전체에 켜도 되나요?

이번 항목은 GitHub에서 사전공개판으로 표시됩니다. 실제 설정 범위와 차단 동작을 격리된 시험 환경에서 확인하고, 안정판 제공 여부를 다시 살펴야 합니다. 자동 승인의 적절한 범위는 업무 위험과 접근 자료에 따라 다릅니다.

Eve 0.83.2를 쓰면 사람 승인을 더는 설계하지 않아도 되나요?

아닙니다. 이번 수정은 부모 에이전트의 메시지가 하위 에이전트의 승인 질문을 대신 처리하던 특정 동작을 고칩니다. 어떤 업무에서 사람이 승인해야 하는지, 승인 화면에 무엇을 보여 줄지, 누가 승인할 수 있는지는 회사가 정해야 합니다.

반복 평가에서 다섯 번 모두 통과하면 운영 배포해도 안전한가요?

다섯 번 통과는 그 입력과 평가 기준에서의 결과입니다. 실제 업무에서 만나는 다른 자료, 권한 오류, 서비스 장애까지 검증했다는 뜻은 아닙니다. 실패할 때의 중단·복구 절차와 사람이 확인해야 할 단계를 함께 시험하세요.

세 소식이 모두 10월 26일에 나온 건가요?

아닙니다. Qwen Code 사전공개판은 한국 시간 26일 오전, Eve 두 버전은 25일 새벽에 공개됐습니다. Eve 항목은 발표가 부족해 넓힌 36시간 범위의 자료입니다. 릴리스의 게시 시각과 개별 기능의 개발·최초 제공 시각을 혼동하지 않았습니다.

공식 출처

• QwenLM, Qwen Code v0.26.1-nightly.20261025.8e28d5380c: https://github.com/QwenLM/qwen-code/releases/tag/v0.26.1-nightly.20261025.8e28d5380c
• Vercel, Eve 0.83.2: https://github.com/vercel/eve/releases/tag/eve%400.83.2
• Vercel, Eve 0.83.1: https://github.com/vercel/eve/releases/tag/eve%400.83.1

조사 기준: 2026년 10월 26일 09:00, Asia/Seoul. 기능과 수정 내용은 각 프로젝트의 공식 릴리스 노트에 적힌 주장입니다. 기업 업무 예시와 도입 순서는 윤자동의 실무 해석입니다.