AI 데일리 브리핑 — 2026-10-29

기준 시점: 2026-10-29 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-28 06:00 ~ 2026-10-29 06:00 KST
추천 글 범위: 2026-10-22 06:00 ~ 2026-10-29 06:00 KST

---

1️⃣ 주요 모델·연구

NVIDIA, 다국어 음성 인식 모델 ‘Nemotron 3.5 Transcribe’ 공개…40개 언어 인식·화자 분리·번역을 하나의 모델로 통합

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: 음성 AI, 다국어 음성 인식, 회의록 자동화, 화자 분리, 음성 번역, 오픈웨이트 모델, 의료 음성 데이터
• 원문: NVIDIA — Nemotron 3.5 Transcribe and Granary v2
• 관련 원문: Hugging Face — Nemotron 3.5 Transcribe 모델

NVIDIA가 음성 인식과 번역, 화자 구분을 하나의 모델에서 수행하는 Nemotron 3.5 Transcribe를 공개했다.

이번 모델은 단순히 음성을 텍스트로 변환하는 기존 ASR 모델의 정확도를 개선한 것보다 적용 범위가 넓다.

ASR(Automatic Speech Recognition)은 사람이 말한 음성을 분석해 문자로 변환하는 기술이다.

일반적인 음성 처리 시스템에서는 음성 인식과 번역, 화자 구분을 서로 다른 모델로 처리하는 경우가 많다.

예를 들어 여러 사람이 참여한 영어 회의를 한국어 회의록으로 정리하려면 음성 인식 모델이 발언 내용을 추출하고, 화자 분리 모델이 누가 말했는지 판단한 뒤, 번역 모델이 다른 언어로 변환하는 방식으로 구성할 수 있다.

하지만 이런 여러 단계의 시스템에서는 앞선 모델의 오류가 다음 단계로 전달될 수 있다.

처음에 사람의 이름을 잘못 인식하면 번역 결과에서도 잘못된 이름이 사용될 수 있다.

화자가 바뀐 시점을 잘못 판단하면 서로 다른 사람의 발언이 하나로 합쳐질 수도 있다.

Nemotron 3.5 Transcribe는 이런 작업을 하나의 모델에서 처리하도록 설계됐다.

30B 전체 파라미터 가운데 약 4B만 활성화

Nemotron 3.5 Transcribe는 약 300억 개의 전체 파라미터를 가진 모델이다.

파라미터는 AI 모델이 학습 과정에서 조정하는 숫자 데이터로, 입력 정보를 처리하고 결과를 생성하는 데 사용된다.

하지만 실제로 토큰 하나를 처리할 때는 약 40억 개의 파라미터만 활성화된다.

이는 MoE(Mixture of Experts) 구조를 사용하기 때문이다.

MoE는 여러 전문 신경망 가운데 현재 입력에 필요한 일부만 선택적으로 실행하는 모델 구조다.

이번 모델은 음성 인코더와 Mamba·Transformer 기반의 MoE 언어모델을 결합했다.

Encoder(인코더)는 음성과 이미지 같은 입력을 모델이 처리하기 좋은 내부 표현으로 변환하는 구성요소다.

Mamba는 이전 입력의 정보를 내부 상태에 요약하면서 순차적으로 처리하는 신경망 구조다.

Transformer는 입력의 서로 다른 부분 사이의 관련성을 계산하는 Attention을 중심으로 설계된 구조다.

이들을 결합해 음성을 이해하는 능력과 언어를 생성하는 능력, 추론 효율 사이의 균형을 맞추려 했다.

다만 실제 계산에 참여하는 파라미터가 40억 개라고 해서 전체 모델의 가중치를 저장하는 데 40억 파라미터만큼의 메모리만 필요하다는 의미는 아니다.

필요에 따라 다른 전문가 네트워크도 사용할 수 있어야 하므로 전체 모델의 가중치를 저장할 공간이 필요하다.

하나의 모델에서 음성 인식·번역·화자 구분

NVIDIA가 발표한 주요 기능은 다음과 같다.

여기서 Speaker Diarization(화자 분리)은 녹음에서 누가 어느 시점에 말했는지 구분하는 기술이다.

예를 들어 세 명이 참여한 회의를 분석한다면 각 발언을 화자 A, B, C의 발언으로 구분할 수 있다.

또한 발언이 서로 겹치는 상황도 처리하도록 설계됐다.

이는 여러 사람이 빠르게 대화하거나 동시에 발언하는 회의에서 중요한 기능이다.

다만 음성 인식을 지원하는 40개 언어 모두에서 번역과 화자 분리 기능까지 동일하게 지원하는 것은 아니다.

언어별 지원 범위는 작업 종류에 따라 다르다.

따라서 특정 언어의 회의록과 번역 시스템을 개발하려면 해당 언어에서 필요한 기능이 실제로 지원되는지 확인해야 한다.

자연어 프롬프트로 음성 인식 결과 조정

이번 모델의 특징 가운데 하나는 음성을 어떤 형식으로 기록할지 자연어로 지시할 수 있다는 점이다.

예를 들어 의료진의 대화를 기록한다고 가정해 보자.

일반적인 음성 인식 모델은 익숙하지 않은 약물 이름이나 의료 용어를 잘못 인식할 수 있다.

Nemotron 3.5 Transcribe에는 가능한 전문 용어를 프롬프트로 제공할 수 있다.

이때 모델은 단순히 제공된 단어를 무조건 출력하는 것이 아니라 실제 음성에서 해당 표현이 사용됐는지 판단하도록 설계됐다.

숫자와 단위의 표기 방식도 지정할 수 있다.

예를 들어 사용자가 말한 금액을 자연스러운 문장으로 기록하거나 통화 기호를 사용하는 형태로 변환하도록 설정할 수 있다.

이는 고객지원 통화나 의료 기록처럼 특정한 표기 형식이 중요한 업무에 유용할 수 있다.

다만 프롬프트에서 특정 용어를 제시했다고 해서 실제로 발언하지 않은 내용을 모델이 추가하지 않는다고 완전히 보장할 수는 없다.

중요한 기록에서는 원본 음성과 결과를 대조해야 한다.

공개 음성 인식 평가에서 높은 정확도

NVIDIA는 여러 음성 인식 벤치마크에서 높은 성능을 기록했다고 밝혔다.

WER(Word Error Rate, 단어 오류율)은 음성 인식 결과에서 잘못 인식하거나 누락하거나 추가한 단어의 비율을 나타내는 지표다.

일반적으로 낮을수록 좋다.

Hugging Face Open ASR 평가에서 영어 인식 결과는 공개 가중치 모델 가운데 가장 높은 수준이었다고 NVIDIA는 설명했다.

Artificial Analysis의 독립 평가에서는 AA-WER 2.8%로 다른 오픈웨이트 모델과 공동 최고 수준을 기록했다.

여기서 중요한 점은 서로 다른 평가기관의 WER 수치를 직접 비교해서는 안 된다는 것이다.

평가에 사용한 녹음과 언어, 계산 방법이 다르기 때문이다.

또한 실제 회의실의 소음과 발음, 녹음 품질에 따라 성능이 달라질 수 있다.

의료 분야 추가 학습으로 오류율 45.8% 감소

NVIDIA는 전문 분야의 음성 인식 정확도를 높이는 방법도 공개했다.

의료 음성 데이터를 이용해 모델을 추가 학습한 결과, 기존 프롬프트 최적화만 사용했을 때 22.44%였던 WER가 12.17%로 감소했다.

상대적으로 45.8% 개선된 결과다.

이 평가는 모델을 조정하는 데 사용하지 않은 2,764개 녹음을 기준으로 진행됐다.

따라서 단순히 학습에 사용한 음성을 다시 인식한 결과보다 의미 있는 검증이다.

하지만 모든 의료 분야와 언어에서 동일한 개선이 나타난다는 의미는 아니다.

특히 특정 약물의 상품명과 검사 이름처럼 드물게 등장하는 용어에서는 여전히 오류가 발생할 수 있다고 연구팀은 밝혔다.

이번 공개에는 모델을 특정한 음성 데이터에 맞게 학습시키는 도구와 예제도 포함됐다.

Granary v2: 46만 시간 이상의 공개 음성 데이터

NVIDIA는 이번 모델과 함께 Granary v2도 공개했다.

Granary v2는 여러 음성 데이터셋을 정리하고 학습용 자료로 변환하는 데이터 처리 프로젝트다.

공개된 데이터 목록에는 48개 언어와 16개 원천 데이터셋의 약 46만3천 시간 분량이 포함된다.

여기에는 음성의 문자 기록뿐 아니라 화자 정보와 표기 방식, 품질에 관한 정보가 포함된다.

예를 들어 같은 발언에 대해 자연스러운 구어체 기록과 숫자·문장부호를 정리한 기록을 별도로 생성할 수 있다.

이렇게 하면 모델이 사용자의 요청에 따라 서로 다른 형식의 기록을 생성하도록 학습할 수 있다.

다만 46만3천 시간은 Granary v2가 공개한 데이터 목록의 규모다.

Nemotron 3.5 Transcribe의 전체 학습 데이터가 정확히 그만큼이었다는 의미는 아니다.

또한 공개된 데이터 목록의 원천 음성을 사용할 때는 개별 데이터셋의 라이선스도 확인해야 한다.

Nemotron 3.5 Transcribe의 모델 가중치는 Hugging Face에서 사용할 수 있으며 vLLM과 SGLang 기반 실행을 지원한다.

다만 현재 모델은 녹음된 음성을 처리하도록 설계됐으며 실시간 스트리밍 음성 인식용 모델은 아니다.

경량 양자화 버전과 일부 로컬 실행 환경은 향후 제공될 예정이다.

이번 발표는 음성 AI가 단순한 받아쓰기에서 벗어나 누가 무엇을 말했고, 어떤 언어로 번역해야 하며, 특정한 전문 용어를 어떻게 표기할지까지 함께 처리하는 시스템으로 발전하고 있음을 보여준다.

---

Rime, 실시간 음성 대화 모델 ‘Prism’ 공개…사용자 말을 들으면서 도구 실행하고 발화 전 텍스트 검증 지원

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: 실시간 음성 AI, 고객지원 에이전트, 음성 합성, 도구 호출, 음성 기반 업무 자동화, AI 안전
• 원문: Rime — Introducing Prism: the first composable speech-to-speech model

음성 AI 기업 Rime이 실시간 음성 대화를 처리하는 새로운 모델 Prism을 공개했다.

이번 모델은 사용자의 음성을 듣고 텍스트와 음성 응답을 생성하면서 외부 도구까지 호출하도록 설계됐다.

특히 음성의 자연스러운 표현을 유지하면서 실제로 말하기 전에 응답 내용을 검토하거나 수정할 수 있도록 만든 구조가 특징이다.

기존 음성 에이전트에서는 일반적으로 두 가지 접근이 사용됐다.

첫 번째는 음성을 텍스트로 변환한 뒤 언어모델이 답변을 생성하고, 다시 음성 합성 모델이 답변을 읽는 방식이다.

이를 Cascade(단계별 연결 구조)라고 한다.

두 번째는 사용자의 음성을 직접 처리해 음성 응답을 생성하는 Speech-to-Speech(음성 대 음성) 방식이다.

두 접근에는 서로 다른 장단점이 있다.

텍스트를 거치면 음성의 일부 정보가 사라진다

단계별 연결 구조에서는 음성 인식 모델이 사용자의 발언을 텍스트로 변환한다.

그런데 텍스트에는 실제 발언의 일부 정보가 포함되지 않는다.

예를 들어 사용자가 같은 문장을 말하더라도 화가 난 목소리인지, 농담하는 상황인지, 당황해서 머뭇거리는지에 따라 의미가 달라질 수 있다.

음성을 텍스트로 변환하는 과정에서 이런 억양과 감정, 주변 소리의 정보가 사라질 수 있다.

반면 음성을 직접 입력받는 모델은 이러한 정보를 함께 처리할 수 있다.

하지만 음성과 텍스트 처리 과정이 완전히 결합돼 있다면 모델이 실제로 어떤 말을 하려는지 사전에 검사하기 어려울 수 있다.

기업용 고객지원에서는 이 문제가 중요하다.

예를 들어 음성 에이전트가 고객에게 환불 가능 여부를 안내하거나 결제에 관한 설명을 제공한다면 특정한 문장을 반드시 말해야 하거나 금지된 표현을 사용하지 않아야 할 수 있다.

Rime은 이 두 문제를 함께 해결하려 했다.

말하기 전에 텍스트를 확인하는 구조

Prism은 사용자의 음성을 직접 처리하면서 응답할 내용을 내부적으로 텍스트 형태로 만든다.

이 텍스트는 실제 음성으로 변환되기 전에 검토할 수 있다.

Rime은 이를 Text Checkpoint(텍스트 검증 지점)라고 설명한다.

예를 들어 금융서비스의 음성 에이전트가 고객에게 특정한 약관을 설명한다고 가정해 보자.

시스템은 모델이 생성한 문장을 검사해 필수 안내 문구가 포함됐는지 확인할 수 있다.

필요하다면 일부 표현을 수정한 뒤 음성으로 출력하도록 만들 수 있다.

이렇게 하면 음성의 자연스러운 대화 능력을 활용하면서도 기업의 업무 규칙을 적용하기 쉬워진다.

또한 Prism은 사용자가 말을 하는 동안 외부 도구를 호출하거나 다음 행동을 준비할 수 있다.

예를 들어 사용자가 식당 주문을 변경하려고 할 때 시스템이 주문정보를 조회하면서 대화를 이어갈 수 있다.

다만 이러한 구조가 모든 업무에서 정확한 도구 호출과 안전한 행동을 보장하는 것은 아니다.

특히 실제 주문과 결제 같은 작업에서는 사용자 확인과 접근권한을 별도로 관리해야 한다.

첫 음성 출력까지 약 0.57초

Rime은 Prism의 응답 속도도 공개했다.

회사 자체 평가에서는 사용자의 발언 이후 첫 번째 음성 응답이 시작되기까지 평균 0.57초가 걸렸다.

이를 Time to First Audio(첫 음성 출력까지 걸리는 시간)라고 한다.

실시간 음성 대화에서는 이 시간이 중요하다.

상대방의 대답이 지나치게 늦어지면 대화가 자연스럽게 이어지기 어렵기 때문이다.

Rime은 또한 Artificial Analysis의 음성 에이전트 평가 환경을 이용해 Prism을 평가했다.

τ-Voice는 고객지원 통화와 도구 호출, 지시 이행 능력을 평가하는 벤치마크다.

Rime이 공개한 평가에서 Prism은 56.6점을 기록했다.

통신서비스 분야에서는 82.5점을 기록했다.

다만 이 점수는 Rime이 Artificial Analysis와 같은 평가 도구를 이용해 직접 실행한 결과다.

Artificial Analysis가 독립적으로 Prism을 시험해 발표한 공식 순위와 동일하게 취급해서는 안 된다.

또한 Rime이 비교 대상으로 사용한 모델의 추론 설정과 대화 조건을 고려해야 한다.

일부 모델은 답변을 시작하기 전에 추가 추론을 수행하도록 설정할 수 있으며, 이는 응답 속도와 정확도에 영향을 줄 수 있다.

실제 주문 확인 비율 개선 사례

Rime은 외식업 음성 주문 시스템을 운영하는 Revmo와 진행한 실험도 공개했다.

연구팀은 약 10시간 분량의 실제 주문 통화 기록을 이용해 Prism을 추가 학습했다.

여기에는 고객의 발언과 도구 실행 기록, 주문 처리 과정이 포함됐다.

Rime에 따르면 추가 학습한 Prism은 주문을 실제로 접수하기 전에 고객에게 확인을 요청하는 비율이 94%였다.

비교 대상인 기존 OpenAI 기반 시스템에서는 해당 비율이 57%였다고 설명했다.

이는 특정한 식당 주문 업무에서 Rime이 수행한 자체 평가 결과다.

다른 서비스와 모든 음성 에이전트에서 같은 개선이 나타난다는 의미는 아니다.

또한 고객에게 확인 질문을 했다는 사실만으로 주문 내용이 모두 정확했다는 뜻도 아니다.

실제 주문의 항목과 수량, 가격을 올바르게 처리했는지는 별도로 검증해야 한다.

기업별 음성 데이터로 모델 조정

Rime은 Prism을 기업별 업무에 맞게 추가 학습시키는 기능도 개발하고 있다.

SFT(Supervised Fine-Tuning, 지도 미세조정)는 올바른 입력과 출력의 예시를 이용해 모델을 추가 학습시키는 방법이다.

RL(Reinforcement Learning, 강화학습)은 모델이 수행한 행동의 결과에 따라 보상을 제공해 더 좋은 행동을 학습시키는 방법이다.

Rime은 두 방식 모두를 위한 API를 구축하고 있다고 밝혔다.

다만 발표 시점에 모든 사용자가 자유롭게 Prism을 추가 학습시키는 셀프서비스 API를 이용할 수 있는 것은 아니다.

현재는 일부 베타 고객과 관련 기능을 개발하고 있으며 Prism 자체는 시험적으로 사용할 수 있도록 제공하고 있다.

이번 발표는 실시간 음성 AI의 발전에서 자연스러운 대화 능력과 기업의 통제 가능성을 함께 확보하는 구조가 중요해지고 있음을 보여준다.

---

Meta, 광고 추천 엔진 ‘Andromeda’의 차세대 아키텍처 공개…GPU 하나에서 초당 10억 건 이상 후보 평가

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: 대규모 추천 시스템, MoE 모델, GPU 인프라, 실시간 광고 검색, 머신러닝 추론 최적화
• 원문: Meta Engineering — Meta Andromeda: Powering the Next Generation of Ads Retrieval Through Model-System Co-Design

Meta가 Facebook과 Instagram의 광고 추천에 사용되는 Andromeda의 차세대 아키텍처와 실제 운영 성능을 공개했다.

이번 발표는 Andromeda를 처음 출시한 소식이 아니다.

Andromeda는 2024년부터 사용된 광고 추천 시스템이다.

10월 28일에 새롭게 공개된 내용은 추천 모델의 구조와 GPU 실행 방식, 네트워크 구성을 함께 변경해 대규모 후보 검색의 처리량을 높인 기술적 개선이다.

Meta의 광고 추천 시스템에서는 수많은 광고 가운데 사용자와 관련성이 높은 후보를 먼저 찾아야 한다.

이후 더 복잡한 모델이 각 후보의 관련성을 자세하게 평가한다.

이를 Retrieval(후보 검색)과 Ranking(순위 평가)으로 구분한다.

검색 단계에서는 매우 많은 광고를 짧은 시간 안에 평가해야 한다.

반면 순위 평가 단계에서는 후보 수가 적기 때문에 상대적으로 복잡한 모델을 사용할 수 있다.

문제는 두 단계 사이에 성능과 정확도의 차이가 존재한다는 것이다.

검색 단계의 모델이 실제로 적절한 광고를 놓치면 이후의 정교한 순위 평가 모델도 해당 광고를 다시 찾아낼 수 없다.

LLM의 MoE 구조를 광고 검색에 적용

Meta는 새로운 Andromeda에 MoE(Mixture of Experts) 구조를 적용했다.

MoE는 여러 전문 신경망 가운데 현재 입력에 필요한 일부만 활성화하는 방식이다.

일반적인 LLM에서는 서로 다른 언어적 특징이나 작업에 따라 전문 네트워크를 선택적으로 사용할 수 있다.

Andromeda에서는 비슷한 개념을 사용자의 관심사와 광고 후보를 평가하는 데 적용했다.

예를 들어 사용자의 관심사는 시간이 지나면서 변할 수 있다.

사용자는 평소에 게임과 개발 도구에 관심이 많더라도 최근에는 여행을 준비하고 있을 수 있다.

Meta는 이런 서로 다른 관심사를 여러 전문적인 사용자 모델로 표현한다.

이후 광고 후보와 현재 상황에 따라 적절한 사용자 모델을 선택해 관련성을 평가한다.

이번 시스템은 세 가지 구성을 결합한다.

먼저 서로 다른 관심사를 표현하는 전문 사용자 모델을 사용한다.

광고 자체의 특징은 현재의 서비스 이용 상황과 결합해 표현한다.

마지막으로 MoE 기반의 Attention 게이트가 어떤 사용자 모델과 광고 후보를 연결할지 결정한다.

Attention(어텐션)은 입력의 여러 부분 사이에서 어떤 정보가 중요한지 계산하는 기술이다.

이 구조는 기존보다 복잡한 관련성 평가를 수행하면서도 필요한 계산량을 줄이려는 접근이다.

모델 계산량을 약 300분의 1로 줄인 구조

Meta는 새로운 MoE 기반 검색 모델이 2024년 Andromeda 검색 모델과 비교해 추론 시점의 부동소수점 연산량을 약 300분의 1 수준으로 줄였다고 밝혔다.

FLOPs(Floating Point Operations)는 부동소수점 계산의 수를 나타낸다.

AI 모델에서는 실제 계산량을 비교하는 지표로 사용한다.

다만 300배 적은 연산이 필요하다는 사실이 실제 전체 서비스가 정확히 300배 빨라졌다는 의미는 아니다.

실제 실행 속도에는 메모리와 네트워크의 데이터 전송, 다른 처리 단계에 필요한 시간도 영향을 주기 때문이다.

Meta는 이 문제를 해결하기 위해 모델의 계산 구조와 시스템 자체를 함께 변경했다.

여러 GPU 커널을 하나로 결합

기존의 GPU 처리 과정에서는 광고의 특징을 가져오고, 모델이 관련성을 계산하고, 결과를 저장하는 작업이 여러 단계로 나뉘어 있었다.

각 단계는 별도의 GPU 커널로 실행될 수 있다.

GPU Kernel(커널)은 GPU에서 특정한 계산을 수행하는 프로그램 단위다.

문제는 여러 단계 사이에서 중간 결과를 GPU 메모리에 반복해서 저장하고 다시 읽는 일이 발생한다는 것이다.

광고 후보가 수십억 건에 달하면 작은 중간 데이터라도 전체 메모리 전송량이 매우 커질 수 있다.

Meta는 이를 해결하기 위해 여러 계산을 하나의 커널로 결합했다.

이를 Kernel Fusion(커널 융합)이라고 한다.

중간 결과를 GPU의 레지스터와 공유 메모리에 유지하면서 다음 계산을 수행해 불필요한 메모리 전송을 줄이는 방식이다.

또한 과거에는 CPU 서버에서 수행했던 광고 후보 필터링과 상위 후보 선택을 GPU 서버로 옮겼다.

이렇게 하면 CPU와 GPU 서버 사이에서 대규모 광고 후보 목록을 주고받을 필요가 줄어든다.

Meta는 이 변경으로 관련 네트워크 트래픽을 약 100분의 1 수준으로 줄였다고 밝혔다.

초당 10억 개 이상의 광고 후보 평가

Meta는 현재 운영 중인 전체 검색 파이프라인이 GPU 서버 하나에서 초당 10억 개 이상의 광고 후보를 처리한다고 설명했다.

이는 기존 2024년 Andromeda 시스템과 비교해 약 100배 높은 처리량이다.

또한 개별 MoE 점수 계산 커널은 NVIDIA GH200에서 초당 100억 건 이상의 후보 평가를 수행했다고 밝혔다.

여기에는 중요한 차이가 있다.

100억 건은 개별 계산 커널의 처리량이고, 10억 건 이상은 전체 검색 파이프라인의 처리량이다.

두 수치를 같은 종류의 성능 지표로 혼동해서는 안 된다.

Meta는 NVIDIA와 협력해 GPU 커널과 데이터 배치 방식도 최적화했다.

특정 연산에서는 처리 속도가 기존보다 2~5배 향상됐으며, 일부 MoE 게이트 계산은 5.3배 빨라졌다고 설명했다.

다만 이러한 결과는 Meta와 NVIDIA의 내부 시스템에서 측정한 수치다.

모든 추천 시스템에서 같은 개선이 발생한다는 의미는 아니다.

광고 전환 성과와 이번 업데이트는 구분

Meta는 Andromeda가 2025년 이후 Facebook 광고 전환 성과를 2.4% 개선했다고 설명했다.

그러나 이 수치를 10월 28일에 공개한 새로운 아키텍처만의 효과로 해석해서는 안 된다.

해당 성과에는 이전부터 적용해 온 Andromeda의 개선사항이 포함될 수 있기 때문이다.

또한 광고 전환 성과는 회사 자체 측정 결과다.

모든 광고주가 동일한 성과 개선을 경험한다는 의미도 아니다.

이번 발표에서 더 중요한 기술적 변화는 추천 모델의 정확도와 실행 인프라를 따로 최적화하는 대신 함께 설계했다는 점이다.

생성형 AI의 발전으로 광고 후보가 계속 증가하는 상황에서 모델의 계산량뿐 아니라 메모리와 네트워크의 데이터 이동까지 함께 고려해야 한다는 사실을 보여준다.

---

2️⃣ AI 제품·서비스

GitHub Universe 2026, Copilot Projects·클라우드 세션·장기 기억 공개…여러 저장소의 작업을 하나의 프로젝트로 관리

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: GitHub Copilot, 코딩 에이전트, 멀티모델 오케스트레이션, 개발 자동화, 컴퓨터 사용, 장기 기억
• 원문: GitHub — GitHub Universe 2026: Evolving every layer of the stack
• 관련 원문: GitHub — Copilot app, Universe releases
• 관련 원문: GitHub — Work from anywhere with a connected Copilot cloud experience
• 관련 원문: GitHub — GitHub intelligence puts your code, context, and history to work

GitHub가 Universe 2026에서 Copilot을 중심으로 한 새로운 개발 환경을 발표했다.

이번 발표의 핵심은 코딩 에이전트가 하나의 파일이나 저장소를 수정하는 데서 벗어나 여러 저장소와 업무 도구를 연결하고 장기간의 프로젝트를 관리하도록 확장됐다는 점이다.

기존의 코딩 에이전트는 특정 저장소에서 작업을 시작하는 경우가 많았다.

예를 들어 사용자가 특정한 버그를 수정하라고 요청하면 에이전트가 관련 파일을 찾고 코드를 수정한 뒤 테스트를 실행한다.

하지만 실제 개발 업무는 하나의 저장소 안에서 끝나지 않을 수 있다.

예를 들어 새로운 결제 기능을 개발하려면 프런트엔드와 백엔드 저장소를 함께 수정해야 할 수 있다.

디자인 파일을 확인하고 요구사항 문서를 작성해야 할 수도 있다.

이후 테스트와 코드 리뷰, 배포 준비까지 여러 작업이 연결된다.

GitHub는 이런 전체 과정을 하나의 작업 공간으로 묶으려 한다.

Copilot Projects: 여러 저장소에 걸친 작업

이번에 공개된 Copilot Projects는 여러 저장소와 관련 문서, 에이전트 실행 결과를 하나의 프로젝트로 관리하는 기능이다.

사용자는 프로젝트에 목표를 설명하고 필요한 저장소와 참고 자료를 연결할 수 있다.

예를 들어 웹 서비스의 관리자 페이지를 새롭게 구성하라는 목표를 전달할 수 있다.

이때 관련 프런트엔드와 백엔드 저장소, 디자인 시안과 회의 기록을 함께 제공할 수 있다.

Copilot은 전체 작업을 여러 에이전트에 분배하고 결과를 하나의 프로젝트에서 관리하도록 설계됐다.

에이전트가 코드 수정을 완료하면 PR을 생성하고 사용자에게 검토를 요청할 수 있다.

PR(Pull Request)은 코드 변경사항을 기존 저장소에 반영하기 전에 검토하고 병합하도록 요청하는 기능이다.

중요한 점은 Copilot Projects가 단순히 여러 대화를 하나의 폴더에 묶는 기능이 아니라는 사실이다.

프로젝트의 목표와 자료, 실제 에이전트 작업을 하나의 실행 단위로 연결한다.

다만 이번 기능은 공개 프리뷰(Public Preview) 단계다.

모든 기능의 안정성과 제공 범위가 정식 버전과 동일하다고 볼 수는 없다.

클라우드 세션을 여러 기기에서 이어서 사용

GitHub는 서로 다른 기기와 프로그램에서 같은 Copilot 작업을 이어서 사용할 수 있는 기능도 정식 제공하기 시작했다.

예를 들어 스마트폰에서 작업을 시작하고 이후 PC의 VS Code에서 같은 세션을 열 수 있다.

또한 GitHub 웹사이트와 Copilot CLI, 데스크톱 앱, Slack과 Microsoft Teams에서도 작업을 이어갈 수 있다.

CLI(Command-Line Interface)는 명령어를 입력해 프로그램을 조작하는 인터페이스다.

Copilot의 클라우드 세션은 GitHub가 관리하는 격리된 실행 환경에서 작동한다.

이를 Cloud Sandbox(클라우드 샌드박스)라고 한다.

샌드박스는 프로그램이 사용할 수 있는 파일과 시스템 자원을 제한하는 실행 환경이다.

에이전트는 사용자의 로컬 컴퓨터와 분리된 환경에서 코드를 수정하고 테스트를 실행할 수 있다.

작업이 중단되면 실행 상태의 스냅샷을 저장한다.

Snapshot(스냅샷)은 특정 시점의 파일과 시스템 상태를 복원할 수 있도록 기록한 자료다.

이후 사용자가 다른 기기에서 작업을 다시 시작하면 이전 상태를 복원할 수 있다.

GitHub는 이번 클라우드 세션에서 기존의 1시간 실행 제한을 제거했다고 밝혔다.

다만 실행 제한이 사라졌다는 사실이 사용량과 비용 제한까지 없어졌다는 의미는 아니다.

실제 계산 자원의 사용량은 요금제와 조직의 정책을 따른다.

클라우드 세션의 새로운 연결 기능은 유료 Copilot 요금제에서 정식 제공된다.

다만 사용자별 적용은 단계적으로 진행된다.

Copilot Memory 정식 제공

이번 발표에는 Copilot Memory의 정식 제공도 포함됐다.

기존의 코딩 에이전트는 새로운 작업을 시작할 때마다 프로젝트의 규칙과 사용자의 선호를 다시 설명해야 하는 경우가 있었다.

예를 들어 개발팀이 PR 설명의 형식을 정해 두었거나 특정 테스트 명령을 사용하도록 규칙을 만들었을 수 있다.

Copilot Memory는 이런 정보를 여러 작업에서 재사용하도록 돕는다.

기억에는 개인적인 선호와 저장소의 개발 규칙 등이 포함될 수 있다.

GitHub는 공개 프리뷰 기간에 메모리를 활용한 CLI 세션을 분석했다.

그 결과 회사 자체 평가에서 93%의 세션에서 개발자 선호를 더 잘 준수했고, 42%에서 작업 효율이 개선됐다고 설명했다.

다만 이는 메모리를 실제로 사용한 일부 세션의 평가 결과다.

모든 Copilot 작업의 생산성이 42% 향상됐다는 의미는 아니다.

또한 개인적인 기억과 저장소 단위 기억의 접근 범위는 서로 다를 수 있다.

실제 기업 환경에서는 어떤 정보를 저장하고 다른 사용자와 공유할지 관리해야 한다.

Dreaming: 과거 작업을 분석해 개발 규칙 개선

GitHub는 Copilot Dreaming도 공개 프리뷰로 제공하기 시작했다.

Dreaming은 과거 에이전트의 작업 기록과 사용자 피드백을 분석해 이후의 작업에 필요한 정보를 정리하는 기능이다.

예를 들어 코드 리뷰에서 반복적으로 발견된 문제가 있다고 가정해 보자.

개발팀은 매번 같은 문제를 지적하는 대신 관련 내용을 코딩 에이전트의 지침에 추가할 수 있다.

Copilot Dreaming은 이런 반복적인 피드백을 분석해 새로운 개발 지침을 제안하도록 설계됐다.

중요한 점은 제안된 변경사항을 무조건 자동으로 적용하는 구조만을 의미하지 않는다는 사실이다.

사용자와 조직은 기억과 지침의 변경을 검토하고 관리할 수 있다.

또한 저장소의 코드를 다른 저장소와 연결해 검색하는 기능도 확대됐다.

에이전트는 현재 로컬에 복제하지 않은 관련 저장소의 코드와 변경 이력을 찾아 작업의 맥락으로 활용할 수 있다.

데스크톱 앱의 컴퓨터 사용

GitHub는 Copilot 데스크톱 앱에서 Computer Use(컴퓨터 사용) 기능도 공개 프리뷰로 제공하기 시작했다.

이 기능을 사용하면 Copilot이 실제 데스크톱 애플리케이션의 화면을 읽고 버튼을 클릭하거나 텍스트를 입력할 수 있다.

예를 들어 코드 저장소와 직접 연결되지 않은 업무 프로그램을 조작할 수 있다.

특정 애플리케이션이 API를 제공하지 않아도 화면을 통해 일부 작업을 수행할 수 있다는 점에서 기존의 도구 호출과 차이가 있다.

현재는 macOS와 Windows에서 공개 프리뷰로 제공된다.

앱을 제어하기 전에 사용자 승인이 필요하며, 조직 관리자는 해당 기능을 비활성화할 수 있다.

따라서 이번 발표가 Copilot이 사용자 승인 없이 모든 데스크톱 프로그램을 자유롭게 조작할 수 있게 됐다는 의미는 아니다.

모델 선택도 자동화

GitHub는 여러 모델을 조합해 코딩 작업을 수행하는 Copilot Fusion도 강조했다.

Fusion은 작업의 종류와 난이도를 분석해 하나 또는 여러 모델을 선택하도록 설계됐다.

예를 들어 간단한 코드 수정과 복잡한 디버깅은 필요한 추론 능력과 계산 비용이 다를 수 있다.

GitHub는 Fusion Max가 Artificial Analysis Coding Agent Index에서 Claude Opus 5.5 Max와 2점 이내의 성능을 기록하면서 작업당 비용은 약 절반, 처리 시간은 약 40% 낮았다고 밝혔다.

다만 이는 GitHub가 공개한 비교 결과이며 실제 모든 코드 저장소에서 동일한 비용과 성능이 나타나는 것은 아니다.

이번 GitHub 발표는 코딩 에이전트의 역할이 코드 생성 도구에서 프로젝트의 계획·실행·검증을 연결하는 개발 업무 플랫폼으로 확대되고 있음을 보여준다.

---

OpenAI·ServiceNow, ChatGPT와 기업 업무 시스템 연결 확대…MCP 플러그인 제공 시작하고 보안·개발 에이전트 통합 예고

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 AI 에이전트, ServiceNow, ChatGPT Work, Codex, 업무 자동화, 사이버보안, MCP
• 원문: OpenAI — OpenAI and ServiceNow expand partnership across enterprise workflows

OpenAI와 ServiceNow가 ChatGPT를 기업의 실제 업무 시스템에 연결하는 협력을 확대한다고 발표했다.

이번 발표에서 실제로 제공되기 시작한 기능은 ServiceNow MCP 플러그인이다.

MCP(Model Context Protocol)는 AI 에이전트가 외부 프로그램과 데이터를 호출할 수 있도록 하는 통신 규격이다.

ServiceNow는 기업이 IT 서비스와 고객지원, 보안 사고, 각종 내부 업무 절차를 관리하는 데 사용하는 플랫폼이다.

예를 들어 기업에서 서버 장애가 발생하면 담당자는 관련 사고 기록을 만들고 원인을 조사한 뒤 해결 과정을 기록할 수 있다.

일반적인 AI 챗봇은 이런 정보를 별도로 제공받지 않으면 현재 사고의 진행 상태를 알기 어렵다.

반면 ServiceNow에 연결된 에이전트는 사용자의 권한에 따라 관련 업무 기록을 조회하고 승인된 작업을 수행하도록 구성할 수 있다.

ServiceNow MCP 플러그인 제공

OpenAI는 이번 발표와 함께 ServiceNow MCP 플러그인을 OpenAI 마켓플레이스에서 제공하기 시작했다고 밝혔다.

이 플러그인은 ChatGPT가 ServiceNow의 업무 정보와 연결되는 경로를 제공한다.

예를 들어 사용자가 특정한 장애의 진행 상태를 확인하거나 관련 변경 기록을 조사하도록 요청할 수 있다.

AI 에이전트는 필요한 정보를 ServiceNow에서 가져와 분석할 수 있다.

하지만 플러그인을 연결했다고 해서 모든 ServiceNow 데이터에 무조건 접근할 수 있는 것은 아니다.

실제로 가능한 작업은 연결된 계정의 권한과 조직의 관리 정책에 따라 달라진다.

또한 중요한 업무 변경을 수행할 때는 별도의 승인 절차가 필요할 수 있다.

기업용 애플리케이션 개발에 Codex 연결

두 회사는 ServiceNow의 AI Workflow Factory에 Codex를 통합할 계획도 발표했다.

Codex는 OpenAI의 코딩 에이전트다.

개발자는 이를 이용해 코드베이스를 분석하고 코드를 수정하거나 테스트를 실행할 수 있다.

ServiceNow의 업무 문맥과 연결되면 기업이 사용하는 내부 데이터와 업무 절차를 참고해 애플리케이션을 개발하는 방식이 가능해질 수 있다.

예를 들어 고객지원 담당자가 새로운 문의 처리 화면을 요청할 수 있다.

개발자는 해당 업무의 요구사항과 기존 ServiceNow 구조를 참고해 기능을 구현하도록 Codex에 작업을 맡길 수 있다.

다만 AI Workflow Factory의 Codex 통합은 2027년 제공 예정이다.

이번 발표일에 모든 고객이 사용할 수 있는 기능은 아니다.

보안 사고 분석과 음성 업무 입력

OpenAI와 ServiceNow는 사이버보안 분야의 공동 솔루션도 개발하고 있다.

계획된 시스템은 OpenAI의 보안 분석 능력과 ServiceNow의 자산·계정·업무 정보를 결합한다.

예를 들어 특정 서버의 취약점이 발견됐을 때 해당 서버가 어떤 서비스를 운영하고 어떤 사용자가 접근하는지 함께 검토할 수 있다.

이런 정보는 취약점의 우선순위를 판단하는 데 중요하다.

같은 종류의 취약점이라도 실제 인터넷에 공개된 서버와 내부 시험 서버에서는 위험 수준이 다를 수 있기 때문이다.

두 회사는 보안 기능의 2027년 1월 조기 접근 제공과 2027년 2분기 정식 제공을 계획하고 있다.

또한 ServiceNow의 Super Intelligence Control Tower에 음성 기반 기능을 추가할 예정이다.

사용자가 음성으로 AI 활용 사례를 설명하면 필요한 평가 항목을 정리하고 누락된 정보를 다시 질문하는 방식이다.

이 기능은 2027년 1분기 제공 예정이다.

따라서 이번 발표에서 기존 MCP 플러그인과 향후 출시할 보안·음성 기능을 구분해야 한다.

실제 제공 기능과 개발 계획

이번 발표의 주요 제공 일정은 다음과 같다.

ServiceNow는 내부 직원들이 ChatGPT Work와 Codex를 사용하도록 확대할 계획도 밝혔다.

OpenAI도 자사 내부 업무에서 ServiceNow의 워크플로를 활용하고 있다고 설명한다.

이번 발표는 기업용 AI의 경쟁이 단순한 질문·답변에서 기존 업무 시스템의 정보와 권한을 활용해 실제 작업을 수행하는 방향으로 확대되고 있음을 보여준다.

---

3️⃣ 개발 도구·에이전트

Microsoft, Copilot의 에이전트 실행 엔진을 Foundry에 공개…Skills·MCP·하위 에이전트를 관리형 환경에서 실행

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: Microsoft Foundry, AI 에이전트, 멀티모델 오케스트레이션, 클라우드 실행 환경, MCP, 장시간 작업 복구
• 원문: Microsoft Foundry — Introducing the Microsoft Copilot harness in Foundry Agent Service
• 관련 원문: Microsoft — Introducing the Microsoft Copilot harness

Microsoft가 자사의 Copilot에서 사용하는 에이전트 실행 기술을 Foundry Agent Service에서 공개 프리뷰로 제공하기 시작했다.

이번에 공개된 기술은 Microsoft Copilot Harness다.

Harness(하네스)는 AI 모델이 실제 업무를 수행하도록 도구와 파일, 실행 환경, 작업 상태를 연결하는 소프트웨어 계층이다.

언어모델이 특정한 문제를 해결할 방법을 알고 있더라도 실제로 작업을 완료하려면 여러 단계가 필요하다.

예를 들어 사용자가 보고서를 작성하라고 요청했다고 가정해 보자.

모델은 관련 정보를 검색해야 한다.

이후 필요한 데이터를 분석하고 문서를 작성한 뒤 파일로 저장해야 할 수 있다.

작업 중 오류가 발생하면 원인을 확인하고 다시 실행해야 한다.

이러한 전체 과정을 모델의 자연어 추론만으로 관리하기는 어렵다.

Harness는 모델이 수행하는 판단과 실제 프로그램의 실행을 연결한다.

개발자가 에이전트 실행 루프를 직접 구현하지 않아도 된다

기존에는 개발자가 에이전트를 만들 때 모델 호출과 도구 실행, 결과 확인을 반복하는 구조를 직접 작성하는 경우가 많았다.

이를 Agent Loop(에이전트 실행 루프)라고 한다.

예를 들어 모델이 파일 검색 도구를 선택하면 프로그램이 해당 도구를 실행한다.

검색 결과를 다시 모델에 전달하면 모델이 다음 행동을 선택한다.

이 과정을 작업이 완료될 때까지 반복한다.

Microsoft Copilot Harness는 이러한 실행 과정을 관리형 서비스로 제공한다.

개발자는 모델과 필요한 도구, 작업 지침을 정의한다.

반면 실제 실행 루프와 샌드박스는 Microsoft Foundry가 관리한다.

이렇게 하면 모든 에이전트 애플리케이션이 실행 환경과 상태 관리를 처음부터 구현할 필요가 줄어든다.

Skills와 MCP를 결합

이번 공개 프리뷰에서는 네 가지 주요 구성이 제공된다.

첫 번째는 Skills다.

Skill은 특정한 업무를 수행하는 데 필요한 지침과 스크립트, 참고 자료를 묶은 구성요소다.

예를 들어 기술 보고서를 작성하는 Skill에는 조사 범위와 출처 검증 방법, 문서 형식을 포함할 수 있다.

두 번째는 연결 도구다.

MCP를 이용해 외부 프로그램과 데이터에 접근할 수 있다.

세 번째는 실행 및 작업 위임이다.

에이전트는 파일과 코드를 처리하고 일부 작업을 하위 에이전트에게 전달할 수 있다.

네 번째는 소스코드로 관리하는 에이전트 정의다.

개발자는 에이전트의 지침과 설정을 애플리케이션 코드와 함께 관리할 수 있다.

이러한 구조에서는 여러 작업에 동일한 Skill을 재사용하거나, 사용하는 모델을 변경하면서 에이전트의 실행 구조를 유지하는 방식이 가능하다.

장시간 실행되는 작업의 장애 복구

Microsoft는 이번 발표와 함께 Hosted Agents의 장시간 작업 복구 기능도 정식 제공한다고 밝혔다.

Hosted Agent는 개발자가 직접 에이전트의 실행 구조를 구현하면서 Microsoft Foundry의 호스팅 환경을 사용하는 방식이다.

장시간 실행되는 에이전트에서는 작업 도중 장애가 발생할 수 있다.

예를 들어 수시간 동안 자료를 조사하는 에이전트가 중간에 실행을 중단할 수 있다.

Foundry는 이런 상황을 감지해 원래 입력으로 작업을 다시 시작하도록 지원한다.

하지만 중요한 제한이 있다.

Foundry가 모든 중간 작업 상태를 자동으로 완벽하게 복원하는 것은 아니다.

개발자는 어떤 작업이 완료됐는지 별도로 저장해야 한다.

예를 들어 보고서 파일을 이미 생성한 상태에서 실행이 중단됐다면 다시 시작한 에이전트가 동일한 파일을 중복 생성하지 않도록 검사해야 한다.

이를 Idempotency(멱등성)라고 한다.

같은 작업이 여러 번 실행되더라도 최종 결과가 한 번 실행했을 때와 같도록 만드는 성질이다.

특히 결제와 이메일 발송, 외부 시스템 수정 같은 작업에서는 중복 실행을 방지하는 설계가 중요하다.

관리형 Harness와 자체 실행 구조의 차이

Microsoft는 개발자가 필요한 제어 수준에 따라 실행 방법을 선택하도록 했다.

예를 들어 간단한 문서 요약 에이전트에는 복잡한 실행 하네스가 필요하지 않을 수 있다.

반면 여러 저장소와 외부 도구를 사용하면서 수시간 동안 작업하는 에이전트에는 관리형 실행 구조가 유용할 수 있다.

하지만 특정한 내부 정책이나 독자적인 실행 알고리즘이 필요하다면 자체 Harness가 더 적합할 수도 있다.

제공 상태와 가격

Microsoft Copilot Harness의 Foundry 통합은 공개 프리뷰다.

기존에 생성한 모든 에이전트가 자동으로 새로운 Harness로 변경되는 것은 아니다.

현재는 새로운 에이전트를 생성할 때 해당 실행 방식을 선택해야 한다.

Microsoft는 2026년 12월 1일부터 Harness 실행 자원에 대한 사용량 기반 요금을 적용할 계획이라고 밝혔다.

그전까지 Harness 실행 자원 자체의 사용료는 면제된다.

다만 모델 추론과 별도 도구 호출, 외부 서비스 이용료는 여전히 발생할 수 있다.

12월 1일 이후 안내된 기본 실행 자원 가격은 vCPU 시간당 0.0994달러, 메모리 GiB 시간당 0.0118달러다.

지역과 계약에 따라 실제 가격은 달라질 수 있다.

이번 발표는 AI 에이전트 개발에서 모델 자체보다 모델이 여러 도구를 사용하고 장애를 복구하며 실제 작업을 완료하도록 만드는 실행 구조가 중요한 소프트웨어 계층으로 발전하고 있음을 보여준다.

---

GitHub Agentic Workflows 1.0 정식 제공…자연어 Markdown으로 작성한 AI 자동화를 GitHub Actions에서 실행

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: GitHub Actions, AI 코딩 에이전트, CI/CD, 오픈소스 자동화, 보안 샌드박스, 모델 라우팅
• 원문: GitHub — GitHub Agentic Workflows generally available

GitHub가 GitHub Agentic Workflows를 정식 제공하기 시작했다.

이 프로젝트는 GitHub Next가 개발한 오픈소스 도구다.

개발자가 자연어로 작성한 업무 절차를 GitHub Actions에서 실행할 수 있는 자동화로 변환한다.

CI/CD(Continuous Integration/Continuous Delivery)는 코드의 변경사항을 자동으로 검사하고 빌드·배포하는 개발 방식이다.

GitHub Actions는 이런 자동화 작업을 실행하는 GitHub의 플랫폼이다.

기존 GitHub Actions에서는 실행할 명령과 조건을 YAML 파일로 정의한다.

예를 들어 새로운 PR이 생성되면 테스트를 실행하거나 특정 브랜치에 코드가 병합되면 배포하도록 만들 수 있다.

하지만 업무가 복잡한 판단을 필요로 하는 경우에는 일반적인 규칙 기반 자동화만으로 해결하기 어렵다.

예를 들어 새로 생성된 이슈의 내용을 읽고 어떤 팀이 담당해야 하는지 분류하는 작업은 단순한 문자열 비교로 해결하기 어려울 수 있다.

GitHub Agentic Workflows는 이런 종류의 판단을 코딩 에이전트에게 맡긴다.

Markdown으로 자동화 정의

개발자는 자연어로 작업 목적과 수행 조건을 작성한다.

예를 들어 매일 새로운 이슈를 확인해 중복된 문제를 찾아내거나, 테스트가 실패한 PR의 원인을 분석하도록 지시할 수 있다.

GitHub Agentic Workflows는 해당 Markdown 파일을 일반적인 GitHub Actions YAML로 컴파일한다.

Compile(컴파일)은 사람이 작성한 표현을 실제 시스템이 실행할 수 있는 형태로 변환하는 과정이다.

중요한 점은 생성한 자동화가 GitHub Actions의 기존 실행 환경과 정책을 재사용한다는 사실이다.

조직이 이미 관리하고 있는 Runner와 접근권한 정책을 함께 사용할 수 있다.

Runner(러너)는 GitHub Actions의 작업을 실제로 실행하는 서버나 프로그램이다.

개발자는 GitHub Copilot을 사용할 수도 있고 자신이 선택한 다른 코딩 에이전트를 연결할 수도 있다.

기본적으로 읽기 전용 권한 제공

이번 정식 버전에서는 보안장치도 강화됐다.

AI 에이전트가 저장소의 내용을 분석하도록 허용하는 것과 실제 코드를 수정하도록 허용하는 것은 서로 다른 문제다.

GitHub Agentic Workflows는 기본적으로 읽기 전용 권한을 사용한다.

에이전트는 제한된 샌드박스에서 실행된다.

또한 Agent Workflow Firewall과 출력 검증 절차를 통해 허용되지 않은 행동을 제한하도록 설계됐다.

예를 들어 에이전트가 외부 문서에 포함된 악의적인 지시를 읽고 저장소의 중요한 파일을 삭제하려 할 수 있다.

이런 상황에서는 모델의 지침만으로 행동을 제한하는 것이 충분하지 않을 수 있다.

따라서 실제 실행 환경의 접근권한과 네트워크 정책을 함께 적용해야 한다.

GitHub는 자동화가 제안한 변경사항을 실제로 반영하기 전에 별도의 위협 탐지 작업도 수행한다고 설명한다.

다만 이러한 안전장치가 모든 악의적인 행동을 완벽하게 차단한다는 의미는 아니다.

실제 시스템에 적용할 때는 조직의 정책과 외부 도구의 접근권한을 검토해야 한다.

정식 버전에서 확장된 기능

이번 정식 제공 버전에는 여러 실행 기능이 추가됐다.

Actions Runner Controller(ARC)와 Docker-in-Docker를 사용하는 자체 러너를 지원한다.

Docker-in-Docker는 컨테이너 내부에서 다른 컨테이너를 실행하는 방식이다.

또한 자동화마다 서로 다른 모델 제공업체를 선택할 수 있다.

Model Routing(모델 라우팅)을 이용해 작업의 종류와 난이도에 따라 적절한 모델을 선택하도록 구성할 수도 있다.

비용 관리 기능도 확대됐다.

개발자는 예상 사용량과 AI 크레딧 비용을 계산하는 기능을 활용할 수 있다.

에이전트 실행 환경에는 Cloud Hypervisor와 NVX 기반 마이크로 가상 머신을 사용하는 격리 기능도 추가됐다.

Micro-VM(마이크로 가상 머신)은 상대적으로 가벼운 가상 머신을 이용해 프로그램의 실행 환경을 격리하는 기술이다.

이런 구조는 여러 저장소를 연결하는 자동화에서 중요한 자료가 의도하지 않은 다른 저장소로 이동하는 위험을 줄이는 데 도움이 될 수 있다.

실제 도입 성과와 한계

GitHub는 Accenture의 내부 개발팀이 Agentic Workflows를 사용한 사례도 소개했다.

해당 팀은 특정한 개발 업무에서 주당 약 29시간을 절약했으며, 팀의 코드 커밋 가운데 91%가 AI로 작성됐다고 설명했다.

하지만 이는 해당 조직이 보고한 개별 사례다.

모든 개발팀에서 같은 생산성 증가가 발생한다는 의미는 아니다.

또한 코드 커밋의 91%를 AI가 작성했다는 사실이 전체 개발 업무의 91%가 자동화됐다는 의미도 아니다.

요구사항 정의와 코드 검토, 실제 배포에 관한 책임은 여전히 개발 조직에 남는다.

GitHub Agentic Workflows는 GitHub Free와 Team, Enterprise에서 정식 제공된다.

다만 기본 실행 엔진으로 Copilot CLI를 사용하려면 Copilot 라이선스가 필요하다.

이번 발표는 AI 코딩 에이전트가 개발자의 개별 요청에 반응하는 도구에서 벗어나 저장소의 이벤트와 일정에 따라 반복적으로 실행되는 개발 자동화 구성요소로 발전하고 있음을 보여준다.

---

4️⃣ 산업·정책·안전

GitHub, AI 애플리케이션의 프롬프트 인젝션·과도한 권한을 PR 단계에서 자동 탐지하는 코드 검사 공개

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: AI 에이전트 보안, 코드 분석, 프롬프트 인젝션, 접근권한, GitHub Advanced Security, CI/CD
• 원문: GitHub — Code scanning for AI applications in public preview

GitHub가 AI 애플리케이션과 에이전트에 특화된 새로운 코드 검사 기능을 공개 프리뷰로 제공하기 시작했다.

기존의 정적 코드 분석 도구는 SQL 인젝션과 메모리 안전성, 잘못된 인증 처리처럼 일반적인 소프트웨어의 보안 문제를 찾는 데 집중하는 경우가 많았다.

하지만 AI 에이전트가 외부 도구와 데이터를 사용하기 시작하면서 새로운 종류의 위험이 발생하고 있다.

이번 GitHub 업데이트는 AI 에이전트의 설계와 데이터 흐름에서 발생하는 보안 문제를 코드 변경 단계에서 찾아내는 기능이다.

프롬프트 인젝션을 코드의 데이터 흐름으로 분석

Prompt Injection(프롬프트 인젝션)은 AI가 읽는 외부 문서나 웹페이지 등에 악의적인 지시를 포함해 원래 사용자의 의도와 다른 행동을 유도하는 공격이다.

예를 들어 고객지원 AI가 웹페이지를 읽는다고 가정해 보자.

공격자는 해당 웹페이지에 고객의 질문과 무관한 지시를 숨길 수 있다.

AI가 그 지시를 정상적인 사용자 명령으로 잘못 받아들이면 중요한 정보를 외부로 전송하거나 허용되지 않은 작업을 수행할 수 있다.

GitHub는 이런 문제를 코드 수준에서 분석하도록 기능을 개발했다.

예를 들어 외부 웹페이지의 내용이 언어모델에 전달되는 경로를 확인할 수 있다.

이후 해당 모델이 파일 수정이나 외부 API 호출 권한을 가지고 있는지 분석한다.

즉 단순히 프롬프트에 위험한 문장이 존재하는지 확인하는 방식과 다르다.

신뢰할 수 없는 데이터가 실제 행동 권한을 가진 모델에 전달되는 구조를 찾아내려는 접근이다.

민감정보 노출과 과도한 권한도 검사

이번 기능은 프롬프트 인젝션 외에도 다른 위험을 검사한다.

첫 번째는 Sensitive Information Disclosure(민감정보 노출)이다.

AI 에이전트가 적절한 접근권한 없이 개인정보나 내부 데이터를 읽거나 외부로 전달할 가능성을 분석한다.

두 번째는 Excessive Agency(과도한 자율성·권한)이다.

에이전트가 자신의 작업에 필요한 범위를 넘어서는 권한을 가진 경우다.

예를 들어 주문 상태를 조회하는 에이전트에게 모든 고객의 정보를 삭제할 수 있는 권한까지 제공할 필요는 없다.

이런 문제는 최소 권한 원칙(Principle of Least Privilege)과 연결된다.

프로그램이나 사용자는 자신이 수행하는 작업에 필요한 최소한의 권한만 가져야 한다는 원칙이다.

AI 에이전트에서는 모델이 예기치 않은 행동을 선택할 가능성까지 고려해야 하므로 접근권한의 범위가 특히 중요하다.

PR에서 자동 검사

새로운 코드 검사 기능은 PR이 생성될 때 실행된다.

기존의 CodeQL 분석과 함께 AI 애플리케이션의 구조를 분석할 수 있다.

위험한 데이터 흐름이 발견되면 PR에 경고를 표시하고 가능한 수정 방향을 제시한다.

이를 통해 취약한 구조가 실제 운영 서비스에 배포되기 전에 문제를 검토하도록 돕는다.

하지만 정적 코드 분석에는 한계가 있다.

실제 실행 시점에 어떤 외부 데이터가 전달되는지 완전히 예측할 수 없기 때문이다.

또한 코드에서 위험한 연결 구조를 발견했다는 사실이 실제 공격이 발생했다는 의미는 아니다.

반대로 경고가 없다고 해서 모든 프롬프트 인젝션 공격에 안전하다는 의미도 아니다.

이번 기능은 GitHub Advanced Security를 사용하는 조직의 공개 프리뷰로 제공된다.

GitHub Enterprise Server에서는 발표 시점에 지원되지 않는다.

기존의 코드 검사와 AI 애플리케이션 검사를 활성화한 저장소에서 사용할 수 있다.

이번 발표는 AI 에이전트 보안이 모델의 답변만 검사하는 단계에서 벗어나 모델과 외부 데이터, 실제 실행 권한이 연결되는 애플리케이션 구조 자체를 검토하는 방향으로 확대되고 있음을 보여준다.

---

GitHub, 기존 패턴에 없는 API 키도 AI로 탐지해 커밋 전 차단…Secret Protection 공개 프리뷰 확대

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: 코드 저장소 보안, API 키 유출 방지, 비밀정보 탐지, GitHub Secret Protection, AI 기반 정적 분석
• 원문: GitHub — Push protection beyond predefined secret patterns

GitHub가 AI를 이용해 API 키와 비밀번호 등의 비밀정보를 탐지하는 기능을 Git Push Protection에 추가했다.

이번 변경의 핵심은 미리 정의된 문자열 패턴에 해당하지 않는 비밀정보도 코드의 문맥을 분석해 탐지하도록 만든 것이다.

일반적인 비밀정보 탐지 도구에서는 정규표현식이나 특정한 문자열 형식을 이용한다.

예를 들어 어떤 API 키가 항상 특정한 접두어로 시작하거나 정해진 길이를 가진다면 그 패턴을 이용해 탐지할 수 있다.

하지만 실제 기업에서 사용하는 모든 비밀정보가 이런 형식을 따르는 것은 아니다.

자체 서비스에서 만든 인증 토큰이나 내부 프로그램의 비밀번호는 특별한 패턴이 없을 수 있다.

이런 값은 일반적인 문자열과 구분하기 어렵다.

GitHub는 이를 해결하기 위해 Microsoft Applied Sciences와 함께 개발한 AI 분류기를 사용한다.

문자열 자체가 아니라 주변 코드까지 분석

새로운 분류기는 특정한 문자열이 어떤 형태를 가지고 있는지만 확인하지 않는다.

해당 값이 코드에서 어떻게 사용되는지도 함께 분석한다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

어떤 파일에 임의의 문자열이 존재한다.

그 문자열이 단순한 테스트 데이터인지, 실제 인증에 사용하는 비밀번호인지는 문자열만으로 판단하기 어렵다.

하지만 코드에서 해당 문자열이 인증 헤더에 전달되거나 외부 API를 호출하는 데 사용된다면 비밀정보일 가능성이 높아질 수 있다.

GitHub는 이런 Context-Aware Detection(문맥을 고려한 탐지)을 사용해 기존 패턴 기반 검사에서 놓치던 비밀정보를 찾으려 한다.

커밋이 저장소에 반영되기 전에 차단

기존의 비밀정보 탐지에서는 이미 저장소에 올라간 코드에서 문제를 발견하는 경우가 있었다.

하지만 API 키가 한 번 공개 저장소에 올라갔다면 이후 파일에서 삭제하더라도 이전 커밋 기록에 남아 있을 수 있다.

따라서 실제 운영 환경에서는 해당 키를 폐기하고 새로 발급해야 하는 상황이 발생할 수 있다.

Push Protection은 이런 문제를 줄이기 위해 코드를 원격 저장소에 반영하는 단계에서 비밀정보를 검사한다.

이번 업데이트에서는 AI가 탐지한 비밀정보도 이 단계에서 차단할 수 있다.

예를 들어 개발자가 인증 토큰이 포함된 코드를 Push하려 하면 GitHub가 해당 변경을 거부한다.

문제가 발견된 파일과 위치도 표시한다.

개발자는 관련 정보를 수정한 뒤 다시 Push해야 한다.

중요한 점은 현재 파일에서 비밀정보를 삭제하는 것만으로 충분하지 않을 수 있다는 사실이다.

동일한 Push에 포함된 이전 커밋에도 비밀정보가 존재한다면 해당 기록도 수정해야 한다.

초기 시험에서 차단한 Push 수 두 배 이상

GitHub에 따르면 이번 AI 분류기를 활성화한 초기 시험에서는 비밀정보가 발견돼 차단된 Push의 수가 기존보다 두 배 이상 증가했다.

또한 사용자들이 보고한 탐지 정확도는 기존 API 제공업체의 전용 패턴 탐지기와 비슷한 수준이었다고 설명했다.

하지만 이는 GitHub의 초기 운영 결과다.

모든 저장소에서 두 배 많은 비밀정보가 발견된다는 의미는 아니다.

또한 탐지량이 증가한 것만으로 실제 보안 사고가 같은 비율로 감소했다고 볼 수는 없다.

AI 기반 탐지에는 잘못된 경고가 포함될 가능성도 있다.

따라서 조직은 중요한 개발 작업이 불필요하게 차단되지 않도록 탐지 결과를 검토할 필요가 있다.

공개 프리뷰의 제공 조건

이번 기능은 공개 프리뷰이며 기본적으로 비활성화돼 있다.

사용하려면 기존의 GitHub Secret Protection 또는 GitHub Advanced Security 환경에서 AI 비밀정보 탐지와 Push Protection을 활성화해야 한다.

이번 기능은 기존의 정규표현식 기반 탐지를 대체하지 않는다.

패턴 기반 탐지와 AI 기반 탐지를 함께 사용하는 구조다.

또한 AI 기반 Push Protection은 사용한 AI 크레딧에 따라 비용이 발생할 수 있다.

반면 이미 Push된 코드에 대한 일부 AI 비밀정보 탐지는 기존 보안 제품에 포함돼 별도의 추가 비용 없이 제공된다.

GitHub는 AI 에이전트가 차단된 변경을 임의로 우회해서는 안 되며, 우회가 필요한 경우에도 적절한 승인을 받아야 한다고 설명했다.

이번 변경은 AI가 새로운 코드를 작성하는 속도가 빨라지는 만큼 코드가 저장소에 반영되기 전에 비밀정보와 위험한 변경을 확인하는 자동화도 강화되고 있음을 보여준다.

---

영국, AI 데이터센터 지원 기준 ‘Data Centre Covenant’ 발표…전력 비용·물 사용·지역사회 기여를 지원 조건으로 연결

• 발표일: 2026-10-28 — 정확한 게시 시각 미확인
• 적용 범위: AI 데이터센터, 국가 AI 인프라, 에너지 정책, 전력망, 환경 기준, 사이버보안, 데이터 주권
• 원문: 영국 정부 — The Data Centre Covenant

영국 정부가 대규모 AI 데이터센터의 개발을 지원하는 새로운 정책 기준인 Data Centre Covenant를 발표했다.

이번 발표는 새로운 AI 모델이나 반도체 기술의 출시가 아니다.

AI 데이터센터의 구축을 국가적으로 지원하는 대신 전력 비용과 환경, 지역사회에 미치는 영향에 대한 책임을 요구하는 정책적 틀을 제시한 것이다.

AI 데이터센터는 많은 GPU와 네트워크 장비, 저장장치와 냉각 설비를 사용한다.

대규모 모델을 학습하거나 많은 사용자의 요청을 처리하려면 상당한 전력이 필요하다.

문제는 새로운 데이터센터가 들어서는 지역에서 전력 공급과 물 사용, 도로와 주거시설 등에 추가적인 부담이 발생할 수 있다는 점이다.

영국 정부는 국가의 AI 역량을 확보하려면 데이터센터가 필요하지만, 그 비용과 영향을 지역사회가 일방적으로 부담해서는 안 된다고 설명했다.

2030년까지 AI 데이터센터 용량 6GW 필요하다고 추정

영국 정부는 국가의 AI 경쟁력과 핵심 공공서비스를 유지하려면 2030년까지 약 6GW의 AI 데이터센터 용량이 필요할 것으로 추정했다.

여기서 GW는 Gigawatt(기가와트)의 약자이며 전력의 규모를 나타내는 단위다.

1GW는 10억 와트에 해당한다.

다만 6GW가 현재 영국에서 이미 운영 중인 AI 데이터센터의 실제 사용량이라는 뜻은 아니다.

2030년까지 확보할 필요가 있다고 정부가 추정한 용량이다.

또한 실제 전력 소비는 데이터센터의 장비 사용률과 전력 효율, 운영 방식에 따라 달라질 수 있다.

영국 정부는 해외의 클라우드와 AI 계산 자원에 지나치게 의존하면 국가적으로 중요한 서비스에서 문제가 발생할 수 있다고 설명했다.

예를 들어 외부 국가의 인프라 장애나 국제적인 공급 제한이 발생하면 의료와 국방, 행정서비스의 AI 사용이 영향을 받을 수 있다.

따라서 일정 수준의 국내 AI 계산 인프라를 확보하려는 것이다.

다섯 가지 정책 기준

Data Centre Covenant는 다섯 가지 주요 기준을 제시한다.

이 기준은 모든 기존 데이터센터에 동일한 새로운 법적 의무가 즉시 적용된다는 의미는 아니다.

정부는 모든 데이터센터가 관련 기준을 충족하도록 권장하고 있다.

다만 추가적인 정부 지원을 받으려는 전략적으로 중요한 데이터센터는 해당 기준을 충족해야 한다는 방향을 제시했다.

전력망 비용을 데이터센터가 부담

첫 번째 기준은 전력 비용에 관한 것이다.

대규모 AI 데이터센터가 새로운 지역에 들어서면 충분한 전력을 공급하기 위해 전력망을 확장해야 할 수 있다.

이때 발생한 비용을 기존 가정과 다른 기업이 과도하게 부담하는 상황을 방지하겠다는 것이다.

영국 정부는 데이터센터가 자신으로 인해 발생하는 전력 시스템의 비용을 공정하게 부담해야 한다고 설명했다.

또한 전력망의 안정성과 유연성을 높이는 데 협력하도록 요구한다.

예를 들어 전력 수요가 높은 시간에 일부 계산 작업의 실행 시점을 조정하면 전력망의 부담을 줄이는 데 도움이 될 수 있다.

다만 모든 AI 작업을 자유롭게 중단하거나 이동할 수 있는 것은 아니다.

실시간 추론 서비스와 긴급한 업무는 지속적인 운영이 필요할 수 있다.

따라서 실제 데이터센터의 전력 사용을 조정하려면 작업의 종류와 서비스 요구사항을 함께 고려해야 한다.

PUE 1.3 이하 목표와 물 사용 공개

환경 기준에서는 PUE(Power Usage Effectiveness)가 중요하다.

PUE는 데이터센터 전체가 소비한 전력을 IT 장비가 사용한 전력으로 나눈 값이다.

예를 들어 서버와 GPU가 100MW를 사용하고 냉각 및 다른 설비가 30MW를 사용한다면 PUE는 1.3이다.

일반적으로 PUE가 1에 가까울수록 IT 장비 외의 부가적인 전력 사용이 적다는 의미다.

영국 정부는 새로운 데이터센터가 PUE 1.3 이하를 목표로 설계돼야 한다고 제시했다.

또한 공공 상수도에 대한 부담을 줄이도록 폐쇄형 냉각 시스템 등의 사용을 권장한다.

발생한 폐열을 주변의 주택과 학교, 병원 등에 활용하는 방법도 제시했다.

전략적 데이터센터에는 연간 에너지와 물 사용량, 배출량과 폐열 재사용 등에 관한 정보 공개도 요구한다.

하지만 PUE가 낮다는 사실만으로 데이터센터의 전체 환경적 영향이 작다고 판단할 수는 없다.

실제 전력 생산 방식과 전체 사용량, 장비 제조와 냉각 시스템의 물 소비 등을 함께 고려해야 하기 때문이다.

지역사회 기여와 고용

영국 정부는 전략적 데이터센터가 Local Benefit Plan(지역사회 기여 계획)을 마련하도록 요구한다.

이 계획은 개발 규모에 맞춰 지역사회에 실질적인 혜택을 제공하기 위한 것이다.

예를 들어 주변 교통과 공원, 교육시설 개선 등에 투자할 수 있다.

또한 데이터센터의 건설 단계뿐 아니라 실제 운영 단계에서도 지속적인 일자리를 제공하도록 권장한다.

반도체와 서버, 전력 설비 등 영국 내 기술 공급망을 강화하는 역할도 기대한다.

이러한 요구사항은 데이터센터를 단순히 전기를 많이 사용하는 건물로 보지 않고 국가의 산업정책과 지역 개발에 연결된 기반시설로 다루려는 접근이다.

기준을 충족하면 정부가 인프라 구축 지원

영국 정부는 전략적으로 중요한 데이터센터가 이러한 기준을 충족하면 전력망 연결과 인허가 절차를 지원할 계획이다.

특히 별도의 장관급 조정 체계를 마련해 중요한 프로젝트의 전력 공급과 개발 문제를 검토한다.

예를 들어 전력망 연결을 기다리는 여러 프로젝트 가운데 국가적으로 중요한 데이터센터에 우선적인 연결 기회를 제공하는 방안을 검토할 수 있다.

또한 특정한 조건에서는 정식 전력망 연결이 준비될 때까지 임시 전력 공급을 허용하는 방안도 마련할 계획이다.

하지만 모든 데이터센터에 이러한 혜택이 자동으로 제공되는 것은 아니다.

전략적 데이터센터의 구체적인 정의와 추가 지원 기준은 향후 공개될 예정이다.

이번 발표는 AI 데이터센터 확대가 단순히 더 많은 GPU를 구매하는 문제가 아니라는 사실을 보여준다.

전력망과 물, 지역사회와 국가 보안까지 함께 고려해야 하는 대규모 사회 기반시설 문제로 발전하고 있다.

---

📚 추천 글

Do LLM Routers Actually Route? Quick answer: Not much!

• 저자: Peter Kruger
• 발행: AutoBench / Hugging Face Community
• 게시일: 2026-10-26
• 원문: Hugging Face — Do LLM Routers Actually Route?

---

AI 모델의 종류가 많아지면서 하나의 애플리케이션에서 여러 모델을 사용하는 방식이 주목받고 있다.

예를 들어 간단한 문서 요약에는 빠르고 저렴한 모델을 사용할 수 있다.

반면 복잡한 코드 수정이나 수학 문제에는 높은 추론 능력을 가진 모델이 필요할 수 있다.

이렇게 작업에 따라 사용할 모델을 자동으로 선택하는 기술을 LLM Router(언어모델 라우터)라고 한다.

이론적으로는 모델 라우터를 이용하면 높은 정확도를 유지하면서 비용을 줄일 수 있다.

하지만 실제로 상용 라우터들이 이런 목표를 달성하고 있을까?

이 글은 7개 라우터 시스템의 17개 설정을 실제 질문과 모델의 비용·품질 데이터로 비교한 연구를 소개한다.

특히 라우터를 사용하지 않고 항상 같은 모델을 호출하는 방식과 직접 비교했다는 점이 흥미롭다.

좋은 라우터의 조건

이상적인 라우터는 모든 요청에 가장 강력한 모델을 사용하는 것이 아니다.

현재 질문을 충분히 잘 해결할 수 있는 모델 가운데 가장 저렴한 모델을 선택해야 한다.

예를 들어 간단한 정보 추출에는 작은 모델을 사용하고, 복잡한 추론에는 큰 모델을 선택할 수 있다.

그러나 어떤 질문이 쉬운지 판단하는 과정 자체가 어렵다.

문장의 길이가 짧다고 해서 반드시 쉬운 질문은 아니다.

반대로 긴 질문이라도 정해진 형식의 정보를 추출하는 작업이라면 작은 모델로도 충분할 수 있다.

AutoBench는 이 문제를 평가하기 위해 252개의 질문과 20개 언어모델을 사용했다.

질문은 10개 분야와 5개 난이도로 구성됐다.

단순한 객관식 문제가 아니라 여러 문장으로 답변해야 하는 개방형 질문이 포함됐다.

연구팀은 각 질문에 대해 20개 모델의 답변과 실제 API 비용을 미리 수집했다.

이후 라우터에게 어떤 모델을 사용할지 선택하도록 했다.

선택된 모델이 얼마나 좋은 답변을 생성하는지와 실제 비용이 얼마인지는 미리 저장한 결과에서 확인했다.

이렇게 하면 라우터가 모델 선택 이후의 답변 생성 과정을 임의로 유리하게 변경하는 일을 줄일 수 있다.

고정된 중간 가격 모델을 이기지 못했다

연구팀이 공개한 결과에서 평가 대상 라우터들은 고정된 중간 가격 모델을 사용하는 전략보다 정확도와 비용을 동시에 개선하지 못했다.

예를 들어 항상 GPT-5.6 Luna를 사용하는 전략은 평가에서 85.3%의 Best Answer Rate를 기록했다.

질문 하나당 평균 비용은 약 0.0043달러였다.

반면 일부 라우터는 비슷한 정확도를 얻기 위해 훨씬 많은 비용을 사용했다.

여기서 Best Answer Rate는 일반적인 정답률과 다르다.

연구팀은 해당 질문에서 가장 좋은 답변을 생성한 모델들과 통계적으로 비슷한 수준의 결과를 선택했는지 평가했다.

따라서 85.3%를 모든 질문 가운데 85.3%가 객관적으로 정확한 정답을 얻었다는 의미로 해석해서는 안 된다.

일부 라우터는 실제로 거의 라우팅하지 않았다

연구팀은 라우터의 선택이 얼마나 다양했는지도 조사했다.

그 결과 17개 설정 가운데 5개 설정에서는 전체 요청의 90% 이상을 하나의 모델에 전달했다.

예를 들어 사용자는 여러 모델을 자동으로 선택하는 기능을 사용한다고 생각할 수 있다.

하지만 실제로는 거의 모든 요청이 같은 모델로 전달되는 구조일 수 있다는 것이다.

이 경우 라우터를 사용하는 이점이 크지 않을 수 있다.

특히 별도의 라우터 사용료나 지연시간이 발생한다면 단일 모델을 직접 호출하는 방식이 더 효율적일 가능성이 있다.

연구팀은 서로 다른 라우터가 같은 질문에 대해 어떤 모델을 선택하는지도 비교했다.

그 결과 서로 다른 제공업체의 라우터들이 동일한 모델을 선택하는 비율은 대부분 낮았다.

이는 질문마다 가장 적절한 모델을 선택하는 기준이 아직 안정적으로 확립되지 않았을 가능성을 보여준다.

다만 서로 다른 선택이 반드시 잘못된 선택이라는 의미는 아니다.

라우터마다 사용할 수 있는 모델과 비용 기준이 다르기 때문이다.

평가 자체의 한계

이번 연구는 특정한 질문 252개와 20개 모델을 기반으로 한다.

또한 라우터에 따라 선택할 수 있는 모델의 종류가 달랐다.

예를 들어 어떤 라우터는 20개 모델 전체를 선택할 수 있지만 다른 라우터는 세 개 모델만 사용할 수 있었다.

따라서 결과를 모든 상용 라우터의 절대적인 성능 순위로 해석해서는 안 된다.

또한 모델 답변의 품질을 판단하는 과정에는 여러 언어모델로 구성한 자동 평가자가 사용됐다.

LLM-as-a-Judge는 다른 언어모델을 이용해 AI의 답변 품질을 평가하는 방식이다.

이런 평가에는 모델 자체의 편향이 포함될 수 있다.

연구팀은 이러한 제한을 인정하면서도 특정 제품의 품질 주장보다 실제 자신의 업무에서 고정된 모델과 라우터의 비용·성능을 함께 비교해야 한다고 강조한다.

이번 글은 여러 AI 모델을 조합하는 시스템을 개발할 때 라우팅 기능이 실제로 의미 있는 선택을 수행하는지 검증해야 한다는 관점을 제공한다.

---

Behind the scenes, two months later: How we ship Google Agent Skills like products

• 저자: Remigiusz Samborski
• 발행: Google Cloud
• 게시일: 2026-10-28
• 원문: Google Cloud — How we ship Google Agent Skills like products

---

AI 에이전트의 행동을 정의하는 지침 파일도 일반적인 소프트웨어처럼 테스트하고 버전을 관리해야 할까?

이 글은 Google이 170개 이상의 Agent Skills를 실제로 관리하면서 만든 품질 검증 체계를 상세하게 설명한다.

Agent Skill(에이전트 스킬)은 AI 에이전트가 특정 작업을 수행할 때 필요한 지침과 스크립트, 참고 자료를 묶은 구성요소다.

예를 들어 데이터베이스를 관리하는 Skill에는 관련 API와 작업 순서, 주의사항이 포함될 수 있다.

일반적으로 이런 지침은 Markdown 파일로 작성된다.

하지만 Google은 Skill을 단순한 문서처럼 관리하면 문제가 발생할 수 있다고 설명한다.

문서에 포함된 표현 하나가 에이전트의 실제 행동을 바꿀 수 있기 때문이다.

예를 들어 지침에서 특정한 명령어의 옵션을 잘못 작성했다면 에이전트가 잘못된 명령을 실행할 수 있다.

또는 모호한 표현 때문에 필요한 단계를 건너뛸 수도 있다.

따라서 Skill의 변경은 실제로 실행되는 프로그램의 동작을 수정하는 것과 비슷한 영향을 줄 수 있다.

여섯 단계의 자동 검사와 사람의 승인

Google은 Skill의 변경사항이 실제 저장소에 반영되기 전에 여러 자동 검사를 수행한다.

검사에는 파일 구조와 Markdown 형식, 버전 정보와 링크의 유효성 등이 포함된다.

또한 Skill이 실제로 필요한 작업을 올바르게 수행하는지 평가한 결과도 제출해야 한다.

이런 평가를 Eval(평가 실행)이라고 한다.

예를 들어 새로운 Skill을 추가한다면 해당 Skill을 사용했을 때와 사용하지 않았을 때의 결과를 비교할 수 있다.

기존 Skill을 수정한다면 이전 버전과 새 버전의 성능을 비교한다.

Google은 모든 Skill 변경에 최신 평가 보고서를 요구한다.

개발자가 평가를 완료한 뒤 코드를 다시 수정했다면 이전 평가 결과를 그대로 사용할 수 없다.

변경된 최신 버전에 대해 다시 평가해야 한다.

이런 구조는 일반적인 소프트웨어의 CI/CD(지속적 통합과 배포)와 비슷하다.

다만 코드 테스트와 달리 AI 에이전트의 행동은 동일한 입력에서도 달라질 수 있으므로 평가 데이터를 충분히 설계해야 한다.

결정적인 작업은 프롬프트가 아니라 코드로 처리

이번 글에서 특히 중요한 원칙은 Deterministic Logic(결정적인 로직)과 모델의 판단을 분리하는 것이다.

예를 들어 배포 명령을 정확한 순서로 실행해야 하는 상황을 생각해 보자.

이 과정을 자연어 지침으로만 작성하면 모델이 명령어를 생략하거나 순서를 바꿀 가능성이 있다.

반면 실제 실행할 명령어를 스크립트로 작성하면 동일한 조건에서 일정한 행동을 보장하기 쉽다.

Google은 이런 경우 명령을 수행하는 스크립트를 별도 파일로 저장하도록 권장한다.

반면 어떤 아키텍처를 선택할지 판단하거나 오류 로그의 원인을 분석하는 작업은 모델의 추론에 맡길 수 있다.

이는 프로그램이 잘하는 작업과 언어모델이 잘하는 작업을 분리하는 설계 원칙이다.

Google은 이런 구분을 검사하는 AI 리뷰 에이전트도 운영한다.

리뷰 에이전트는 Skill의 구조와 지침이 적절한지 검토한다.

하지만 최종 승인은 해당 분야를 이해하는 사람이 수행한다.

필요한 문서만 단계적으로 불러오기

Google은 Skill의 정보를 세 단계로 나눠 관리한다.

첫 번째는 이름과 설명처럼 간단한 메타데이터다.

두 번째는 실제 업무 흐름을 설명하는 핵심 지침이다.

세 번째는 상세한 API 문서와 예제, 참고 자료다.

이를 Progressive Disclosure(정보의 단계적 제공)이라고 한다.

처음부터 모든 참고 문서를 모델에 전달하는 대신 필요한 정보를 단계적으로 제공하는 방식이다.

이렇게 하면 모델이 처리해야 하는 입력 토큰을 줄일 수 있다.

또한 현재 작업과 관련 없는 정보가 모델의 판단을 방해하는 문제를 줄일 수 있다.

Google은 핵심 Skill 문서를 500줄 미만으로 유지하는 내부 규칙도 소개했다.

하지만 중요한 것은 문서 길이 자체보다 에이전트가 실제로 필요한 정보를 찾기 쉬운 구조로 만드는 것이다.

Google은 여러 단계의 참고 문서 링크를 계속 따라가야 하는 구조를 피하도록 권장한다.

실제 평가에서 에이전트가 두 번째 이상의 간접 참조를 충분히 탐색하지 않고 멈추는 문제가 발견됐기 때문이다.

Skill도 버전 관리가 필요

Google은 Skill의 동작에 영향을 주는 변경이 발생하면 반드시 버전을 증가시키도록 한다.

이를 Semantic Versioning(의미적 버전 관리)이라고 한다.

일반적인 소프트웨어에서 사용하는 버전 관리 원칙을 Skill에도 적용한 것이다.

예를 들어 특정 작업의 순서나 도구 사용 방법을 변경했다면 이를 새로운 버전으로 관리한다.

이렇게 하면 문제가 발생했을 때 이전의 정상적인 Skill로 돌아갈 수 있다.

또한 특정 프로젝트가 검증된 Skill 버전을 계속 사용하도록 고정할 수 있다.

이번 글은 AI 에이전트의 지침을 한 번 작성하고 끝나는 프롬프트가 아니라 실제 제품처럼 테스트하고 배포하는 구성요소로 관리해야 한다는 관점을 제공한다.

특히 여러 개발자가 공통 Skill을 작성하고 유지보수하는 조직에 유용한 운영 사례다.

---

How to upgrade embedding models in AlloyDB AI with zero downtime

• 저자: Pushkar Khadilkar, Paul Ramsey
• 발행: Google Cloud
• 게시일: 2026-10-28
• 원문: Google Cloud — How to upgrade embedding models in AlloyDB AI with zero downtime

---

AI 검색 시스템에서 사용하던 임베딩 모델을 더 좋은 모델로 교체하면 어떤 문제가 발생할까?

일반적인 웹 애플리케이션에서는 라이브러리나 API를 새로운 버전으로 교체하는 작업을 생각할 수 있다.

하지만 임베딩 모델은 조금 다르다.

Embedding(임베딩)은 문서나 이미지의 의미를 여러 숫자로 구성된 벡터로 표현하는 기술이다.

예를 들어 상품 리뷰를 임베딩으로 변환하면 의미가 비슷한 리뷰를 검색할 수 있다.

사용자가 제품의 배터리 문제를 검색했을 때 정확히 같은 단어를 사용하지 않은 리뷰도 찾아낼 수 있다.

이를 Semantic Search(의미 기반 검색)라고 한다.

문제는 서로 다른 임베딩 모델이 생성한 벡터를 직접 비교할 수 없다는 점이다.

예를 들어 기존 모델에서 생성한 768차원 벡터와 새로운 모델에서 생성한 3,072차원 벡터는 서로 다른 공간에 존재한다.

차원 수가 같더라도 모델이 다르면 숫자의 의미가 달라질 수 있다.

따라서 기존 문서의 벡터는 그대로 두고 검색어만 새로운 모델로 변환하면 검색 품질이 크게 떨어질 수 있다.

새로운 임베딩으로 전체 데이터 다시 변환

Google은 실제 전자상거래 서비스의 상품 리뷰 테이블을 가정해 이전 과정을 설명한다.

기존에는 text-embedding-005 모델을 사용했다.

새로운 버전에서는 gemini-embedding-001을 사용한다.

기존 모델의 임베딩 차원은 768개다.

새 모델은 3,072개 차원을 사용한다.

따라서 데이터베이스에 새로운 벡터 열을 추가해야 한다.

이후 기존 상품 리뷰의 텍스트를 새로운 모델로 다시 처리한다.

이 과정을 Re-embedding(재임베딩)이라고 한다.

문제는 데이터가 수백만 건이라면 작업에 상당한 시간이 필요할 수 있다는 것이다.

또한 재임베딩이 진행되는 동안에도 사용자의 검색 요청은 계속 처리돼야 한다.

Google은 이를 해결하기 위해 기존 임베딩과 새로운 임베딩을 한동안 함께 유지하는 방식을 소개한다.

운영 중인 데이터베이스를 멈추지 않는 방법

이번 글에서는 Blue-Green Deployment(블루·그린 배포)와 Canary Deployment(카나리 배포) 개념이 사용된다.

블루·그린 배포는 기존 시스템과 새로운 시스템을 나란히 준비한 뒤 사용 경로를 전환하는 방법이다.

카나리 배포는 전체 사용자 가운데 일부에게만 새로운 시스템을 먼저 적용하는 방식이다.

임베딩 모델을 교체할 때도 비슷하게 접근할 수 있다.

먼저 기존 임베딩 열을 유지한다.

새로운 임베딩 열을 추가하고 데이터를 다시 계산한다.

이후 새로운 검색 인덱스를 만든다.

그다음 일부 요청을 새로운 임베딩으로 처리하면서 검색 품질을 확인한다.

마지막으로 전체 요청을 새 모델로 전환한다.

이런 구조에서는 모델을 교체하는 동안 기존 검색 기능을 계속 제공할 수 있다.

새로운 ScaNN 인덱스 생성

벡터 검색에서는 비슷한 문서를 빠르게 찾기 위한 별도의 인덱스를 사용한다.

Vector Index(벡터 인덱스)는 수많은 임베딩 가운데 가까운 벡터를 효율적으로 검색하도록 만든 자료구조다.

Google은 AlloyDB의 ScaNN 인덱스를 사용하는 방법을 설명했다.

ScaNN은 Google이 개발한 벡터 검색 기술이다.

Google이 공개한 자체 시험에서는 10만 개의 3,072차원 벡터를 대상으로 ScaNN 인덱스를 약 50초 만에 생성했다.

비교 대상인 HNSW 인덱스는 약 7~13분이 필요했다.

다만 이는 특정한 데이터 크기와 설정에서 측정한 결과다.

모든 데이터베이스에서 ScaNN이 같은 비율로 빠르다는 의미는 아니다.

Google은 새로운 인덱스를 만드는 동안 기존 데이터베이스의 쓰기 작업이 계속 가능하도록 하는 방법도 소개했다.

새 모델이 더 정확해도 검색 결과는 크게 달라질 수 있다

이번 글에서 흥미로운 부분은 실제 검색 결과의 차이다.

Google의 자체 시험에서 기존 임베딩 모델과 새 모델이 선택한 상위 10개 검색 결과의 겹치는 비율은 31%였다.

즉 새로운 모델을 사용하면 검색 결과의 구성이 상당히 달라질 수 있다는 의미다.

이러한 변화가 반드시 나쁜 것은 아니다.

새로운 모델이 문서의 의미를 더 정확하게 이해했기 때문에 다른 결과를 선택했을 수도 있다.

하지만 검색 결과가 변경되면 실제 사용자 경험에도 영향을 줄 수 있다.

따라서 단순히 새로운 모델이 공개 벤치마크에서 더 높은 점수를 기록했다는 이유만으로 바로 교체해서는 안 된다.

실제 서비스에서 자주 사용하는 검색어와 문서를 이용해 평가해야 한다.

이번 글은 RAG와 의미 기반 검색 시스템에서 모델의 정확도뿐 아니라 모델을 안전하게 교체하고 운영하는 데이터베이스 설계가 중요하다는 점을 보여준다.

특히 이미 운영 중인 AI 검색 서비스를 개선하려는 개발자에게 유용한 기술 자료다.

---

How GKE networking scales to support high densities of concurrent AI agents

• 저자: Srini Jasti, Venkat Krishnan
• 발행: Google Cloud
• 게시일: 2026-10-28
• 원문: Google Cloud — How GKE networking scales to support high densities of concurrent AI agents

---

AI 에이전트를 수천 개 또는 수만 개 동시에 실행하려면 어떤 인프라 문제가 발생할까?

일반적인 웹 서비스에서는 사용자의 요청을 처리하는 서버를 여러 대로 확장할 수 있다.

하지만 AI 에이전트는 일반적인 API 서버와 다른 실행 형태를 가질 수 있다.

예를 들어 코딩 에이전트는 실제 프로그램을 실행해야 한다.

이때 사용자마다 서로 다른 파일과 도구, 임시 실행 환경이 필요할 수 있다.

또한 에이전트가 수행하는 명령이 다른 사용자의 작업에 영향을 주지 않도록 격리해야 한다.

이런 요구사항 때문에 에이전트마다 별도의 Sandbox(샌드박스)를 제공하는 방식이 사용된다.

샌드박스는 프로그램이 접근할 수 있는 파일과 네트워크, 시스템 자원을 제한하는 실행 환경이다.

문제는 샌드박스 수가 매우 많아지면 기존의 컨테이너 관리 방식에서 예상하지 못한 병목이 발생할 수 있다는 점이다.

Google은 이번 글에서 GKE(Google Kubernetes Engine)의 네트워크 구조를 통해 이런 문제를 해결하는 방법을 설명한다.

에이전트마다 별도의 실행 환경

GKE는 Kubernetes 기반의 컨테이너 관리 서비스다.

Kubernetes는 여러 서버에 프로그램을 배포하고 실행 상태를 관리하는 플랫폼이다.

Kubernetes에서는 여러 컨테이너를 하나의 실행 단위로 관리하는 Pod(파드)라는 개념을 사용한다.

예를 들어 코딩 에이전트가 특정한 프로젝트를 분석할 때 별도의 Pod를 생성할 수 있다.

작업이 끝나면 해당 Pod를 삭제한다.

다른 작업이 시작되면 새로운 Pod를 생성한다.

이런 구조는 각 작업을 분리하는 데 유리하다.

하지만 여러 에이전트가 동시에 실행되면 매우 많은 Pod가 빠르게 생성되고 삭제될 수 있다.

Google은 일부 연구기관과 대규모 AI 서비스에서 최대 100만 개의 동시 실행 샌드박스가 필요한 상황을 설명한다.

다만 이는 일부 대규모 시스템이 요구하는 목표 규모다.

모든 GKE 클러스터가 현재 100만 개의 샌드박스를 하나의 클러스터에서 운영하고 있다는 의미는 아니다.

네트워크 권한도 매번 새로 설정해야 한다

Kubernetes에서는 어떤 Pod가 다른 Pod나 외부 네트워크에 접근할 수 있는지 제한할 수 있다.

이를 Network Policy(네트워크 정책)라고 한다.

예를 들어 코딩 에이전트가 공개 패키지 저장소에는 접근할 수 있지만 기업 내부의 민감한 데이터베이스에는 접근하지 못하도록 제한할 수 있다.

이런 정책을 적용하려면 각 Pod의 신원을 구분해야 한다.

Google은 GKE Dataplane V2에서 eBPF 기반 네트워크 정책을 사용한다.

eBPF(Extended Berkeley Packet Filter)는 운영체제 커널 내부에서 네트워크와 시스템 동작을 효율적으로 처리하도록 하는 기술이다.

GKE는 Pod에 부여된 레이블을 이용해 네트워크 신원을 계산할 수 있다.

Label(레이블)은 Kubernetes 자원에 붙이는 키와 값 형태의 설명 정보다.

문제는 AI 에이전트의 Pod마다 고유한 레이블을 부여하는 경우다.

예를 들어 agent-id나 생성 시각을 모든 Pod의 레이블에 포함할 수 있다.

이 경우 Pod가 많아질수록 네트워크 신원도 지나치게 많아진다.

Google은 이런 환경에서 클러스터의 네트워크 신원 수가 65,536개 제한에 가까워질 수 있다고 설명한다.

또한 새로운 신원을 등록하는 과정에서 Pod 생성이 지연될 수 있다.

모든 메타데이터를 네트워크 신원에 사용할 필요는 없다

Google이 제안한 핵심 해결책은 Pod의 고유한 설명 정보와 네트워크 정책에 필요한 정보를 구분하는 것이다.

예를 들어 특정한 Pod의 생성 시각과 작업 ID는 운영 기록을 확인하는 데 필요할 수 있다.

하지만 해당 정보가 반드시 네트워크 접근권한을 결정하는 데 필요한 것은 아니다.

Google은 이런 데이터를 Label 대신 Annotation(어노테이션)에 저장하도록 제안한다.

어노테이션도 Kubernetes 자원에 설명 정보를 저장하는 방법이다.

하지만 일반적인 자원 선택과 네트워크 신원 계산에 사용하는 Label과 역할이 다르다.

네트워크 정책에 필요하지 않은 고유 정보를 Annotation으로 이동하면 Pod마다 새로운 네트워크 신원을 생성해야 하는 상황을 줄일 수 있다.

또한 실제로 필요하지 않은 레이블을 네트워크 신원 계산에서 제외하는 필터도 사용할 수 있다.

이런 방식은 보안 정책을 제거하는 것과 다르다.

접근권한을 결정하는 데 필요한 정보만 유지하면서 불필요한 신원 생성을 줄이는 접근이다.

수만 개 샌드박스에서 발생하는 실제 병목

Google은 일부 고객의 실제 운영 사례도 소개했다.

관련 시스템은 여러 클러스터에 걸쳐 수십만 개의 격리 환경을 관리했으며, 하나의 클러스터에서 3만 개 이상의 샌드박스가 급격하게 생성되는 상황도 처리했다고 설명한다.

하지만 해당 결과는 특정 고객의 인프라와 설정에서 관찰된 사례다.

모든 GKE 환경에서 동일한 규모와 속도를 보장한다는 의미는 아니다.

또한 Pod 생성 속도는 네트워크뿐 아니라 컨테이너 이미지 다운로드와 저장장치, CPU와 메모리에도 영향을 받는다.

따라서 네트워크 신원 문제를 해결해도 다른 병목이 남을 수 있다.

AI 에이전트의 계산 비용과 대기시간

이번 글이 흥미로운 이유는 AI 에이전트의 인프라 비용을 새로운 관점에서 설명하기 때문이다.

예를 들어 모델이 다음 행동을 결정하는 데 1초가 필요하다고 가정해 보자.

그런데 해당 행동을 실행할 샌드박스를 준비하는 데 10초가 걸린다면 전체 작업 시간의 대부분은 모델이 아니라 실행 환경을 준비하는 데 사용된다.

이런 상황에서는 더 빠른 언어모델을 사용하더라도 전체 작업이 크게 빨라지지 않을 수 있다.

따라서 AI 에이전트의 처리량을 높이려면 모델 추론과 실제 프로그램 실행 환경의 시작 시간을 함께 최적화해야 한다.

Google은 이를 위해 샌드박스의 빠른 생성과 상태 복원, 네트워크 권한 관리가 중요하다고 설명한다.

이번 글은 AI 에이전트가 실제 프로그램을 대규모로 실행하는 환경에서 일반적인 컨테이너 관리 기술의 세부적인 네트워크 설계가 전체 시스템의 처리량과 비용에 직접적인 영향을 줄 수 있다는 점을 구체적으로 보여준다.