AI 데일리 브리핑 — 2026-10-20
Soshy··조회수 —
기준 시점: 2026-10-20 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-19 06:00 ~ 2026-10-20 06:00 KST
추천 글 범위: 2026-10-13 06:00 ~ 2026-10-20 06:00 KST
1️⃣ 주요 모델·연구
Cloudflare, 문서에서 값을 추출하고 계산·예측까지 수행하는 AI 모델 ‘Clairic’ 공개…출력 토큰 생성 없는 단일 연산 구조
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: 구조화된 데이터 추출, 문서 분석, 멀티모달 AI, AI 에이전트, 고객지원 자동화, Cloudflare Workers AI
- 원문: Cloudflare — Introducing Clairic, a new System One class of extraction models
Cloudflare가 비정형 데이터에서 필요한 정보를 추출하고, 숫자를 계산하거나 미래 값을 예측할 수 있는 새로운 AI 모델 Clairic을 공개했다.
이번 모델은 일반적인 대형 언어모델(LLM)과 다른 방식으로 설계됐다.
LLM은 입력을 처리한 뒤 다음 토큰을 하나씩 생성하면서 답변을 완성한다.
여기서 토큰(Token)은 언어모델이 텍스트를 처리하는 기본 단위다.
반면 Clairic은 자연어 답변을 길게 생성하지 않는다. 입력을 한 번 처리한 뒤 미리 정의된 데이터 형식에 맞는 값들을 반환한다.
Cloudflare는 이런 구조를 System One 모델이라고 부른다.
이 명칭은 인간의 사고 과정을 직관적이고 빠른 사고와 느리고 숙고하는 사고로 구분한 개념에서 가져왔다.
다만 모델에 실제로 인간과 같은 두 종류의 사고 체계가 존재한다는 의미는 아니다.
Cloudflare가 사용하는 System One은 출력 토큰을 반복 생성하지 않고 한 번의 계산으로 결과를 반환하는 전문 모델을 가리킨다.
기존 판단 모델에서 데이터 추출 모델로 확장
Cloudflare는 앞서 Clef라는 판단 모델을 공개했다.
Clef는 여러 선택지 가운데 어떤 것이 적절한지 결정하는 작업에 특화돼 있다.
예를 들어 고객 문의를 환불, 배송, 계정 문제로 분류하거나 에이전트가 다음에 사용할 도구를 선택하도록 만들 수 있다.
Clairic은 여기서 한 단계 더 나아간다.
미리 정의된 선택지 가운데 하나를 고르는 대신 입력에 포함된 구체적인 값을 추출하거나 계산한다.
예를 들어 고객이 다음과 같은 문의를 보냈다고 가정해 보자.
고객은 649달러짜리 제품을 구매했고 세금으로 52.10달러를 추가 지불했다. 제품은 9월 28일 배송됐으며, 10월 9일에 화면이 깨지고 모서리가 찌그러졌다는 문의를 작성했다.
일반적인 LLM을 사용한다면 개발자는 모델에게 주문번호와 결제 금액, 배송일, 손상 유형 등을 JSON으로 정리하도록 요청할 수 있다.
모델은 해당 정보를 찾은 뒤 JSON 문자열을 생성한다.
그러나 실제 서비스에서는 출력 형식이 잘못되거나, 존재하지 않는 정보를 모델이 추측해 작성하는 문제가 발생할 수 있다.
Clairic은 이 작업을 다르게 처리한다.
개발자가 원하는 필드와 자료형을 정의하면 모델은 각 필드의 값을 반환한다.
예를 들어 결제 금액은 숫자로, 배송일은 날짜로, 손상 유형은 문자열 목록으로 반환하도록 지정할 수 있다.
앞선 사례에서는 제품 가격과 세금을 더한 701.10달러를 계산하고, 배송일부터 문의 작성일까지 11일이 지났다는 결과도 반환한다.
즉 입력에 직접 적혀 있는 값을 찾아내는 것뿐 아니라 둘 이상의 정보를 이용한 간단한 계산도 수행할 수 있다.
각 결과에 근거 위치와 신뢰도 제공
Clairic의 특징 가운데 하나는 결과가 원문 어디에서 나왔는지 확인할 수 있다는 점이다.
텍스트를 추출한 경우 해당 문자가 입력의 몇 번째 위치에서 시작하고 끝나는지 반환한다.
이를 Character Offset Span(문자 위치 범위)이라고 한다.
예를 들어 모델이 손상 유형으로 cracked screen을 반환했다면 원문에서 해당 표현이 등장한 위치도 함께 제공할 수 있다.
개발자는 이를 이용해 실제 문서에서 추출된 부분을 강조 표시할 수 있다.
또한 모델은 추출 결과에 대한 Confidence Score(신뢰도 점수)를 반환한다.
이 점수는 모델이 해당 결과를 얼마나 확신하는지 나타내는 값이다.
하지만 높은 신뢰도 점수가 실제 정답을 보장하는 것은 아니다.
특정 업무에 사용하려면 별도의 평가 데이터를 통해 신뢰도와 실제 정확도가 얼마나 일치하는지 확인해야 한다.
Clairic은 입력에서 찾을 수 없는 정보를 처리하는 방법도 제공한다.
예를 들어 고객이 배송 추적번호를 언급하지 않았다면 결과를 임의로 생성하는 대신 null을 반환할 수 있다.
동시에 p_null이라는 값을 제공한다.
이는 요청한 정보가 입력에 존재하지 않는다고 판단할 확률을 나타낸다.
모델은 자신이 가장 유력하다고 생각한 값도 별도로 제시할 수 있지만, 최종적으로 정보가 없다고 판단했다면 실제 반환값은 null이 된다.
이런 구조는 단순히 그럴듯한 문자열을 생성하는 방식보다 정보의 존재 여부와 추출 결과를 구분하기 쉽게 만든다.
이미지에서 구조화된 데이터 추출
Clairic은 텍스트뿐 아니라 이미지도 처리할 수 있다.
Cloudflare는 기울어진 영수증 사진에서 주문번호와 구매 시각, 수량, 단가 등의 정보를 추출하는 사례를 공개했다.
일반적인 문서 처리 시스템에서는 OCR(Optical Character Recognition)을 이용해 이미지의 글자를 먼저 텍스트로 변환한 뒤, LLM으로 필요한 값을 다시 추출하기도 한다.
Clairic은 이미지 입력에서 필요한 값을 직접 반환하도록 설계됐다.
다만 이미지에 보이는 모든 정보를 완벽하게 읽는다는 의미는 아니다.
사진의 해상도와 글자의 가독성, 문서 형식에 따라 추출 결과가 달라질 수 있다.
특히 결제나 회계처럼 오류의 비용이 큰 업무에서는 모델의 신뢰도만으로 결과를 확정하지 않고 금액 합계나 주문정보를 별도로 확인하는 과정이 필요하다.
값의 추정과 미래 예측도 지원
Clairic은 입력에 명시적으로 존재하지 않는 숫자를 추정할 수도 있다.
예를 들어 여러 주택의 면적과 건축연도, 침실 수, 거래가격을 입력하면 새로운 주택의 예상 가격을 반환하도록 요청할 수 있다.
이때 모델은 하나의 예상값만 반환하지 않는다.
중앙값과 80% 예측 구간도 제공한다.
예를 들어 예상 가격이 41만8천 달러이고 80% 구간이 37만~47만 달러라면, 모델이 해당 범위에 상당한 확률을 부여하고 있다는 의미다.
다만 80% 예측 구간이 실제로 약 80%의 사례를 포함하는지는 충분한 평가 데이터를 이용해 검증해야 한다.
Cloudflare는 시계열 데이터의 미래 값을 예측하는 Forecasting(예측) 기능도 소개했다.
시계열 데이터는 날짜나 시간 순서에 따라 기록된 숫자들의 집합이다.
예를 들어 일별 매출과 웹사이트 방문자 수, 항공 여행객 수 등이 해당한다.
Cloudflare는 미국 교통안전청(TSA)이 공개한 일별 공항 이용객 수를 이용해 예측 성능을 평가했다.
21일 동안 매일 다음 날의 이용객 수를 예측한 결과, 실제 값과의 평균 오차는 약 3.3%였다.
또한 21일 가운데 17일의 실제 값이 모델이 제시한 80% 예측 구간 안에 포함됐다.
이는 Cloudflare가 수행한 소규모 자체 평가 결과다.
21일간의 특정 시계열에서 얻은 결과이므로 모든 예측 작업에서 같은 정확도를 보장하지는 않는다.
실제로 연구팀은 연휴 기간의 여행객 증가처럼 과거 데이터만으로 설명하기 어려운 사건에서는 예측 오차가 커졌다고 설명했다.
Cloudflare 역시 Clairic이 특정 분야에 맞춰 학습된 전문 시계열 예측 모델을 대체한다고 주장하지 않는다.
전문 모델을 연결하는 에이전트 구조
Cloudflare는 Clairic을 기존 LLM과 경쟁하는 범용 챗봇이 아니라 다른 모델과 함께 사용하는 구성요소로 제시한다.
예를 들어 고객지원 시스템을 다음과 같이 구성할 수 있다.
먼저 Clairic이 고객의 이메일에서 주문번호와 결제 금액, 배송일과 문제 유형을 추출한다.
이후 Clef가 회사의 정책과 추출된 정보를 바탕으로 환불이 가능한지 판단한다.
마지막으로 일반적인 LLM이 고객에게 전달할 답변을 작성한다.
각 모델이 자신에게 적합한 작업을 담당하는 구조다.
Cloudflare가 공개한 자체 시험에서는 이런 다단계 구성을 사용한 고객지원 작업의 처리 시간이 61.7초에서 19.3초로 감소했다.
또한 100만 건 처리 시나리오의 추정 비용은 약 11,740달러에서 6,032달러로 감소했다고 밝혔다.
이는 특정 모델 조합과 작업 흐름을 비교한 자체 측정 결과다.
모든 고객지원 서비스에서 처리 시간이 같은 비율로 감소한다는 의미는 아니다.
Clairic은 현재 Cloudflare Workers AI에서 프리뷰로 제공된다.
모델 ID는 @cf/cloudflare/clairic이다.
Cloudflare는 모델 가중치도 향후 공개할 계획이라고 밝혔지만, 10월 19일 발표 시점에 가중치 공개가 완료된 것은 아니다.
이번 모델은 AI 서비스의 비용을 줄이는 방법이 작은 LLM을 사용하는 것에만 한정되지 않음을 보여준다.
데이터 추출, 판단, 자연어 생성처럼 서로 다른 종류의 작업을 분리하고 각 작업에 맞는 모델을 사용하는 구조가 중요한 대안으로 발전하고 있다.
Meta, 광고를 고유 ID 대신 의미 기반 토큰으로 표현하는 ‘GenRecs Tokenization’ 공개…신규 상품과 광고의 추천 정확도 개선
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: AI 추천 시스템, 대규모 언어모델, 광고 최적화, 멀티모달 임베딩, 상품 검색, 개인화 추천
- 원문: Meta Engineering — GenRecs Tokenization: Transforming Ads Recommendation at Meta with Stable Model Vocabulary
Meta가 Facebook과 Instagram 등의 광고 추천 시스템에서 사용하는 새로운 데이터 표현 기술 GenRecs Tokenization을 공개했다.
이번 발표는 앞서 소개된 Meta의 광고 기반 모델 GEM을 다시 출시한 것이 아니다.
기존 광고 추천 모델이 상품과 광고를 이해하는 방식을 바꾸기 위해 개발한 새로운 토큰화 기술과 그 적용 결과를 설명하는 후속 기술 발표다.
기존 추천 시스템에서는 광고나 상품, 페이지마다 고유한 식별자를 부여하는 경우가 많다.
예를 들어 특정 운동화 광고에 ad_12345라는 ID가 있고, 새로운 운동화 광고에는 ad_98765라는 ID가 있다고 가정해 보자.
두 광고는 거의 같은 상품을 소개할 수도 있다.
하지만 고유 ID만 보면 추천 모델은 두 광고가 비슷하다는 사실을 직접 알기 어렵다.
특히 새로운 광고에는 사용자의 클릭이나 구매 기록이 거의 없을 수 있다.
이런 문제를 Cold Start(콜드 스타트)라고 한다.
새로운 사용자나 상품, 광고에 대한 행동 데이터가 부족해 추천 품질이 낮아지는 현상이다.
고유 ID 대신 의미를 표현하는 토큰 사용
Meta는 이를 해결하기 위해 광고와 상품을 의미 기반 토큰(Semantic Token)으로 변환하는 방법을 개발했다.
의미 기반 토큰은 상품이나 광고의 내용을 압축해 나타내는 기호다.
예를 들어 서로 다른 두 운동화 광고라도 러닝화라는 공통된 특성을 가진다면 일부 토큰을 공유할 수 있다.
추천 모델은 이런 공통 토큰을 통해 두 광고가 관련돼 있다는 사실을 학습할 수 있다.
핵심은 새로운 광고가 등장했을 때도 이미 학습된 비슷한 광고의 정보를 활용할 수 있다는 점이다.
Meta는 광고의 제목과 설명, 이미지뿐 아니라 사용자가 광고와 상호작용한 기록도 활용한다.
먼저 사전학습된 멀티모달 모델이 광고의 텍스트와 이미지를 읽는다.
멀티모달(Multimodal)은 텍스트와 이미지처럼 서로 다른 형태의 데이터를 함께 처리하는 기술을 의미한다.
모델은 광고의 내용을 Embedding(임베딩)으로 변환한다.
임베딩은 데이터의 의미적 특성을 여러 숫자로 표현한 벡터다.
의미가 비슷한 광고는 임베딩 공간에서도 가까운 위치에 표현될 수 있다.
Meta는 여기에 실제 사용자들의 광고 클릭과 구매 등의 행동 정보를 결합한다.
따라서 단순히 이미지가 비슷한 광고뿐 아니라 사용자가 실제로 비슷하게 반응하는 광고 사이의 관계도 표현할 수 있다.
연속된 숫자 벡터를 짧은 토큰 시퀀스로 변환
임베딩은 일반적으로 연속적인 숫자들로 구성된다.
하지만 대형 언어모델은 개별적인 토큰을 처리하는 방식에 익숙하다.
Meta는 이를 연결하기 위해 임베딩을 여러 부분으로 나눈 뒤 각 부분을 미리 정의된 코드 가운데 하나로 변환한다.
이 과정을 Vector Quantization(벡터 양자화)이라고 한다.
벡터 양자화는 연속적인 숫자 공간의 값을 정해진 대표값 가운데 하나로 대응시키는 방법이다.
대표값들의 집합은 Codebook(코드북)이라고 한다.
예를 들어 광고 하나를 표현하는 임베딩을 여러 부분으로 나눈 뒤 각 부분에서 가장 적합한 코드북 항목을 찾을 수 있다.
이렇게 얻은 코드들을 이어 붙이면 하나의 광고를 표현하는 짧은 토큰 시퀀스가 만들어진다.
Meta는 이 과정에서 임베딩을 여러 부분 공간으로 나누는 방법과 단계적으로 오차를 줄이는 방법을 결합했다.
또한 서로 다른 광고나 상품이 공유할 수 있는 안정적인 토큰 체계를 만들려 했다.
이를 통해 광고의 ID가 변경되거나 새로운 캠페인이 만들어져도 기존에 학습한 의미적 관계를 재사용할 수 있다.
토큰 자체의 품질도 평가
이번 연구에서 흥미로운 부분은 최종 광고 성과만 측정하지 않았다는 점이다.
Meta는 토큰화 결과 자체가 좋은지 판단하는 여러 지표를 사용했다.
대표적으로 Cluster Purity(군집 순도)는 같은 토큰을 공유하는 상품들이 실제로 비슷한 범주에 속하는지 평가한다.
Distribution Balance(분포 균형)는 토큰이 일부 코드에만 지나치게 몰리지 않고 적절하게 분산되는지 확인한다.
Codebook Utilization(코드북 활용률)은 준비된 코드 가운데 실제로 사용되는 코드의 비율을 측정한다.
예를 들어 코드북에 1만 개의 코드가 있지만 대부분의 광고가 100개 코드에만 대응된다면 다양한 상품의 특성을 충분히 표현하기 어려울 수 있다.
Meta는 여덟 가지 토큰화 모델을 비교했다.
그 결과 이런 내부 품질 지표가 높은 토큰화 모델일수록 실제 광고 추천 모델의 클릭률 예측 성능도 높은 경향을 보였다고 설명한다.
이는 전체 광고 추천 모델을 처음부터 다시 학습시키지 않고도 토큰화 모델의 품질을 먼저 평가할 수 있는 방법이 있다는 의미다.
다만 토큰 자체의 평가 점수가 높다고 해서 모든 광고 캠페인에서 실제 전환 성과가 자동으로 개선되는 것은 아니다.
최종 성과는 추천 모델과 광고주, 사용자 특성에도 영향을 받는다.
실제 광고 전환 성과 0.35% 개선
Meta는 GenRecs Tokenization을 기존 GEM(Generative Ads Model) 및 Adaptive Ranking Model과 결합해 운영한 결과를 공개했다.
회사 내부 측정에서는 광고 전환 성과가 0.35% 개선됐다.
이 수치는 Meta가 2026년 2월에 수집한 내부 데이터를 기준으로 한다.
따라서 10월 19일에 새롭게 측정된 결과가 아니라, 이번 기술 발표에서 공개된 기존 운영 실험 결과다.
또한 0.35%는 상대적인 전환 성과 개선 수치로 제시됐으며, 전환율이 0.35%포인트 증가했다는 의미로 해석해서는 안 된다.
개별 광고주가 같은 개선 효과를 얻는다는 보장도 없다.
추천 시스템에서는 이런 작은 비율의 변화가 중요할 수 있다.
대규모 서비스에서 광고가 매우 많이 노출되기 때문에 작은 정확도 차이도 전체 시스템의 성과에 영향을 줄 수 있기 때문이다.
Meta는 앞으로 같은 의미 기반 토큰을 광고뿐 아니라 더 다양한 콘텐츠와 추천 시스템에 활용하는 방안도 연구하고 있다.
장기적으로는 텍스트와 이미지, 음성과 영상에 걸쳐 공통된 의미 표현을 만드는 것이 목표다.
이번 발표는 생성형 AI의 기술이 반드시 챗봇이나 콘텐츠 생성에만 적용되는 것은 아니라는 점을 보여준다.
언어모델의 토큰화와 표현 학습 방식을 대규모 추천 시스템에 적용해, 새로운 상품과 광고에서도 기존에 학습한 지식을 활용하는 방향으로 기술이 발전하고 있다.
2️⃣ AI 제품·서비스
World, 금융기관을 위한 ‘World ID for Banking and Finance’ 출시…AI 사칭과 딥페이크에 대응하는 인간 인증 체계 제공
- 발표 시각: 2026-10-20 00:08 KST (2026-10-19 11:08 미국 동부시간)
- 적용 범위: 금융 보안, AI 신원 사칭, 딥페이크 탐지·대응, 디지털 신원 인증, AI 에이전트 권한 위임, 화상회의 보안
- 원문: World Foundation — World Launches World ID for Banking and Finance to Address AI-Driven Impersonation
World Foundation이 금융기관을 위한 새로운 디지털 신원 인증 제품군 World ID for Banking and Finance를 공개했다.
이번 제품군은 AI가 생성한 가짜 신원과 음성, 영상으로 인해 금융기관이 겪을 수 있는 사칭 위험에 대응하는 데 초점을 맞춘다.
최근 생성형 AI는 실제 사람과 비슷한 얼굴이나 음성을 생성할 수 있다.
이를 Deepfake(딥페이크)라고 한다.
딥페이크는 AI를 이용해 실제 인물이 하지 않은 말이나 행동을 한 것처럼 보이게 만드는 기술을 의미한다.
기술 자체는 영상 제작이나 엔터테인먼트에도 사용될 수 있지만, 타인을 사칭하는 금융 사기에 악용될 가능성도 있다.
예를 들어 기업의 재무 담당자가 화상회의에서 경영진처럼 보이는 사람에게 송금 지시를 받았다고 가정해 보자.
얼굴과 목소리가 익숙하더라도 영상이나 음성이 AI로 생성됐을 가능성이 있다.
따라서 단순히 화면에 보이는 얼굴이나 들리는 목소리만으로 상대방의 신원을 확인하기 어려워질 수 있다.
World는 이런 문제를 해결하기 위해 사람의 존재 여부를 확인하는 인증과 AI 에이전트의 권한 위임을 연결하는 방식을 제시했다.
기존 World ID 기술을 금융 업무에 통합
이번 제품군은 세 가지 구성요소를 결합한다.
첫 번째는 World ID 앱이다.
World ID는 사용자가 자신이 실제 사람임을 증명할 수 있도록 설계된 디지털 신원 체계다.
World의 기존 기술에는 홍채 기반 생체정보를 활용하는 본인 확인 방식도 포함돼 있다.
다만 모든 World ID 기능이 매번 홍채를 다시 촬영하거나 생체정보를 직접 전달하는 방식으로 작동하는 것은 아니다.
World는 사용자가 필요한 증명만 제3자 서비스에 제시하는 구조를 강조한다.
두 번째는 World ID for Zoom이다.
화상회의에서 상대방이 실제 사람인지 확인할 수 있도록 돕는 기능이다.
World는 이번 발표와 함께 World ID for Zoom을 정식 제공(GA) 상태로 전환했다고 밝혔다.
세 번째는 World ID for Agents다.
이는 사용자가 AI 에이전트에게 일부 증명 정보를 위임할 수 있도록 하는 기술이다.
예를 들어 사람이 자신의 신원을 확인한 뒤 특정 AI 에이전트가 그 사람의 인증 상태를 제3자 서비스에 증명하도록 할 수 있다.
여기서 중요한 차이는 AI 에이전트 자체가 사람이 된다는 의미가 아니라는 점이다.
AI 에이전트가 확인된 인간 사용자와 연결돼 있음을 증명하는 구조에 가깝다.
AI 에이전트에게 권한을 위임할 때 발생하는 문제
AI 에이전트가 금융 서비스를 대신 이용하는 상황을 생각해 보자.
사용자는 에이전트에게 자신의 계좌 정보를 조회하거나 특정 거래를 준비하도록 요청할 수 있다.
하지만 금융기관은 해당 요청이 실제 고객의 의사에 따라 발생했는지 확인해야 한다.
단순히 요청을 보낸 프로그램이 정상적인 AI 에이전트라는 사실만으로 충분하지 않다.
어떤 사용자가 해당 에이전트를 승인했고, 어떤 범위의 작업을 허용했는지 확인해야 하기 때문이다.
이를 Delegation(권한 위임)이라고 한다.
World ID for Agents는 사용자가 보유한 증명 정보를 에이전트에 위임하고, 에이전트가 이를 외부 플랫폼에 제시하는 방식을 지원한다.
하지만 사용자가 실제 사람이라는 사실과 특정 금융거래가 정당하게 승인됐다는 사실은 별개다.
예를 들어 실제 사람에게 연결된 AI 에이전트라도 잘못된 계좌로 송금하거나 사용자가 허용하지 않은 금액을 거래할 가능성이 있다.
따라서 금융기관이 이를 사용한다면 신원 인증 외에도 거래 금액과 수취인, 권한 범위, 추가 승인 절차를 검증해야 한다.
World의 인증 기술을 도입했다는 사실만으로 모든 사기와 잘못된 거래가 차단되는 것은 아니다.
화상회의 인증과 실제 거래 승인
World ID for Zoom은 화상회의에서 실제 사람의 참여 여부를 확인하도록 설계됐다.
그러나 실제 사람이라는 사실을 확인하는 것만으로 그 사람이 특정 회사의 임직원인지, 해당 거래를 승인할 권한이 있는지까지 모두 보장할 수는 없다.
예를 들어 실제 사람이 회의에 참여했더라도 자신의 신분이나 직책을 거짓으로 설명할 수 있다.
따라서 금융기관에서는 인간 인증과 별개로 기존 고객 신원 확인(KYC)과 내부 결재, 다중 인증 절차가 필요하다.
KYC(Know Your Customer)는 금융기관이 고객의 실제 신원과 거래 목적 등을 확인하는 절차다.
World가 제공하는 인간 인증은 이런 절차의 일부를 보완할 수 있지만 완전히 대체하는 기술로 이해해서는 안 된다.
또한 생체정보 기반 인증을 이용하는 경우에는 개인정보 처리와 정보 보관, 인증의 철회와 계정 복구 절차도 중요한 검토 대상이다.
설계 협력과 실제 도입은 구분
World는 이번 제품군을 공개하면서 여러 설계 협력사를 소개했다.
참여 기관에는 Bain Capital, OpenExchange, Outtake, Pantera Capital, VanEck Funds가 포함됐다.
다만 이러한 협력 관계가 해당 기관의 모든 금융 서비스에 World ID가 실제 배포됐다는 의미는 아니다.
World는 이들 기관과 금융 분야의 인증·보안 활용 사례를 검토하고 있다고 설명한다.
따라서 참여 기관의 이름만으로 실제 운영 규모나 사기 방지 성과를 추정해서는 안 된다.
이번 발표에서 확인할 수 있는 변화는 AI 사칭에 대응하는 보안 기술이 단순히 이미지나 음성의 진위를 판별하는 방식에서 실제 사람과 디지털 서비스, AI 에이전트 사이의 신뢰 관계를 증명하는 방향으로 확대되고 있다는 점이다.
다만 인간 인증과 실제 거래의 안전성은 서로 다른 문제이므로, 고위험 금융 업무에서는 여러 보안 계층을 함께 사용하는 것이 필요하다.
Cloudflare, 기업용 AI 업무 공간 ‘Cloudflare OS’의 외부 서비스 연결 확대…GitHub·Notion·Asana 등 통합
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: 기업용 AI 에이전트, SaaS 연동, 업무 자동화, 데이터 접근권한, AI 보안, 멀티모델 운영
- 원문: Cloudflare — Cloudflare’s AI Workspace Platform Partners with Leading Applications and Deployment Teams
Cloudflare가 기업용 AI 업무 환경인 Cloudflare OS의 외부 애플리케이션 연동 범위와 구축 파트너를 확대한다고 발표했다.
Cloudflare OS 자체는 이번에 처음 공개된 제품이 아니다.
10월 19일의 새로운 변화는 기존 업무 서비스와 연결하는 기능, 그리고 기업의 실제 도입을 지원하는 파트너 생태계가 확대됐다는 점이다.
이번 발표에서 소개된 주요 연동 서비스는 Asana, Box, Canva, ClickHouse, GitHub, Gong, Notion 등이다.
기업이 AI 에이전트를 실제 업무에 활용하려면 이러한 시스템에 접근할 수 있어야 한다.
예를 들어 프로젝트 진행 상황을 요약하려면 Asana의 작업 정보가 필요할 수 있다.
개발 현황을 분석하려면 GitHub의 저장소와 PR, 이슈를 읽어야 한다.
내부 문서를 기반으로 질문에 답하려면 Notion이나 Box의 콘텐츠에 접근해야 할 수 있다.
문제는 이런 정보를 연결하는 과정에서 보안과 접근권한 관리가 복잡해진다는 점이다.
AI 에이전트에게 모든 데이터 접근권한을 부여하면 안 되는 이유
일반적인 업무 자동화에서는 API 키나 서비스 계정을 이용해 외부 서비스에 접근한다.
하지만 여러 서비스를 사용하는 에이전트에게 광범위한 권한을 부여하면 보안 문제가 발생할 수 있다.
예를 들어 프로젝트 문서를 요약하는 에이전트에게 조직 전체의 모든 파일을 삭제할 권한까지 제공할 필요는 없다.
반대로 필요한 문서를 읽을 권한이 부족하면 정상적인 작업을 완료할 수 없다.
이런 문제를 해결하기 위한 기본 원칙이 최소 권한 원칙(Principle of Least Privilege)이다.
프로그램이나 사용자는 자신의 작업에 필요한 최소한의 권한만 가져야 한다는 원칙이다.
Cloudflare OS는 AI가 생성한 도구와 자동화 기능을 기존 업무 시스템에 연결할 때 이 원칙을 적용하도록 설계됐다.
Cloudflare에 따르면 관리자는 새롭게 연결할 서비스와 접근 가능한 데이터의 범위를 설정할 수 있다.
에이전트는 필요한 업무 시스템에 접근하지만, 자신에게 허용되지 않은 자료까지 자동으로 읽을 수 있는 것은 아니다.
이런 구조는 여러 SaaS를 연결하는 AI 에이전트에서 특히 중요하다.
SaaS(Software as a Service)는 프로그램을 사용자가 직접 서버에 설치하지 않고 인터넷을 통해 서비스로 이용하는 방식이다.
기업이 여러 SaaS를 사용한다면 각 서비스의 인증과 접근권한 체계가 서로 다를 수 있다.
따라서 통합 AI 업무 공간은 단순한 API 연결뿐 아니라 각 서비스의 기존 권한을 어떻게 유지할 것인가를 함께 고려해야 한다.
직원 개인의 PC 대신 관리형 환경에서 실행
Cloudflare OS의 또 다른 특징은 AI 에이전트가 직원의 개인 컴퓨터가 아닌 Cloudflare의 인프라에서 실행되도록 설계됐다는 점이다.
개발자가 개인 PC에서 코딩 에이전트를 실행하면 에이전트가 접근할 수 있는 파일과 인증정보를 조직 차원에서 모두 파악하기 어려울 수 있다.
반면 관리형 환경에서는 어떤 도구가 실행됐고 어떤 데이터에 접근했는지 기록하고 통제하기 쉬워진다.
Cloudflare는 이 구조를 통해 보안 담당자가 AI 도구의 사용 상태를 더 명확하게 관리할 수 있다고 설명한다.
다만 중앙에서 실행한다는 이유만으로 모든 보안 문제가 해결되는 것은 아니다.
실제 접근권한을 너무 넓게 설정하거나 외부 자료에 포함된 악의적인 지시를 그대로 실행하면 여전히 문제가 발생할 수 있다.
따라서 실행 환경의 중앙화와 모델의 안전성, 외부 데이터의 신뢰성은 별도로 관리해야 한다.
AI Gateway를 통한 모델 선택과 비용 관리
Cloudflare OS는 AI Gateway를 통해 서로 다른 AI 모델을 활용하도록 설계됐다.
AI Gateway는 애플리케이션과 여러 AI 모델 서비스 사이에서 요청을 전달하고 관리하는 계층이다.
예를 들어 간단한 문서 분류 작업에는 비용이 낮은 모델을 사용하고, 복잡한 코딩이나 추론에는 더 강력한 모델을 사용할 수 있다.
이렇게 하면 모든 요청에 동일한 고성능 모델을 사용하는 것보다 비용을 세밀하게 관리할 수 있다.
또한 모델 호출량과 토큰 사용량 등을 관찰할 수 있다.
특히 여러 직원이 동시에 AI 도구를 이용하는 기업에서는 개별 직원의 작은 사용량이 조직 전체에서는 큰 비용으로 누적될 수 있다.
Cloudflare는 이번 연동 확대가 AI 도구의 활용을 늘리는 동시에 조직이 AI 사용량과 비용, 보안 정책을 관리하는 기반을 제공한다고 설명한다.
기업 구축 파트너도 확대
Cloudflare는 외부 업무 시스템 연동과 함께 구축·운영을 지원하는 파트너를 발표했다.
주요 파트너로는 EPAM, HappyCog, Towards AI가 소개됐다.
이들은 기업이 기존 업무 절차를 AI 에이전트와 연결하고, 실제 운영에 필요한 시스템 구성을 설계하도록 지원할 예정이다.
다만 이번 발표는 모든 연동 서비스가 모든 고객에게 동일한 기능과 권한으로 즉시 제공된다는 의미는 아니다.
실제 연결 가능한 데이터와 실행 기능은 각 애플리케이션의 API와 조직의 설정에 따라 달라질 수 있다.
이번 발표는 기업용 AI 에이전트의 경쟁력이 모델의 추론 성능뿐 아니라 기업이 기존에 사용하던 시스템과 얼마나 쉽게 연결하고, 그 연결을 얼마나 안전하게 관리할 수 있는가에 달려 있음을 보여준다.
Adobe Frame.io, NVIDIA GPU 기반 영상 검색 성능 개선…영상 임베딩 생성 최대 5배 가속
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: 생성형 AI 미디어 도구, 영상 검색, 멀티모달 임베딩, Adobe Frame.io, NVIDIA GPU, 콘텐츠 제작·방송
- 원문: NVIDIA — NVIDIA Advances Agentic Security for Media, From European Public Service Broadcasting to Global Content Production
Adobe가 NVIDIA의 GPU 가속 기술을 활용해 Frame.io의 영상 검색과 미디어 처리 성능을 개선한 결과를 공개했다.
이번 발표는 완전히 새로운 영상 생성 모델의 출시가 아니다.
이미 존재하는 영상 작업 플랫폼에서 AI가 영상 내용을 분석하고 필요한 장면을 찾아내는 과정의 성능을 개선한 기술 발표다.
영화와 방송 제작 환경에서는 매우 많은 영상 자료가 생성된다.
예를 들어 드라마 제작사는 매일 촬영한 영상뿐 아니라 수년 동안 제작한 과거 영상도 보관한다.
특정 인물의 표정이나 특정 장면이 필요할 때 파일 이름만으로 해당 영상을 찾기는 어렵다.
편집자는 실제 영상을 열어 내용을 확인해야 할 수 있다.
이런 문제를 해결하기 위해 사용되는 기술이 Semantic Video Search(의미 기반 영상 검색)다.
사용자가 찾으려는 장면을 자연어로 설명하면 AI가 영상의 내용을 분석해 관련 장면을 찾는 방식이다.
영상 검색을 위한 임베딩 생성
의미 기반 검색에서는 영상의 각 장면을 숫자로 표현하는 과정이 필요하다.
이를 Embedding(임베딩)이라고 한다.
임베딩은 이미지나 문장, 영상의 의미를 여러 숫자로 표현한 벡터다.
예를 들어 두 영상에 비슷한 장면이 나타난다면 해당 장면들의 임베딩도 비슷하게 나타나도록 모델을 학습할 수 있다.
사용자가 특정한 표정이나 행동을 설명하면 검색 시스템은 해당 설명과 의미적으로 가까운 영상 장면을 찾는다.
문제는 대규모 영상 자료에서 임베딩을 생성하는 데 상당한 계산 자원이 필요하다는 점이다.
영상은 수많은 프레임으로 구성되기 때문이다.
Frame(프레임)은 영상의 한 순간을 나타내는 개별 이미지다.
영상이 초당 30프레임이라면 1시간짜리 영상에는 약 10만8천 개의 프레임이 포함된다.
모든 프레임을 AI 모델로 분석하면 처리 비용이 매우 커질 수 있다.
GPU 기반 영상 처리 파이프라인 개선
Adobe는 NVIDIA의 여러 기술을 결합해 이런 과정을 가속했다.
NVDEC는 NVIDIA GPU에서 영상 압축 해제를 가속하는 기술이다.
CUDA는 NVIDIA GPU에서 일반적인 계산을 수행할 수 있도록 하는 플랫폼이다.
TensorRT는 AI 모델의 추론 실행을 최적화하는 도구다.
Adobe는 영상의 압축을 해제하고, 필요한 프레임을 전처리하고, 임베딩을 생성하는 여러 단계를 GPU에서 효율적으로 수행하도록 구성했다.
NVIDIA가 공개한 결과에 따르면 임베딩 생성 속도는 약 5배 향상됐다.
전체 검색 처리량은 최대 4배 증가했고, 검색 처리 지연시간은 최대 5분의 1 수준으로 감소했다.
이 수치들은 Adobe와 NVIDIA가 공개한 기술 평가 결과다.
모든 영상 길이와 해상도, 검색 작업에서 같은 개선 효과가 나타난다는 의미는 아니다.
검색용 저해상도 영상의 크기도 감소
Adobe는 영상 검색에 사용하는 프록시 영상의 크기도 줄였다.
Proxy Video(프록시 영상)는 원본 고화질 영상을 직접 처리하는 대신 빠른 미리보기나 분석을 위해 생성한 상대적으로 가벼운 영상이다.
새로운 방식은 초당 두 개의 프레임을 사용하는 검색용 프록시를 만든다.
NVIDIA에 따르면 이 프록시는 기존 360p 버전보다 약 80% 작다.
검색에 필요한 시각적 정보는 유지하면서 저장 공간과 전송량을 줄이려는 것이다.
이런 최적화는 오래된 방송 자료를 많이 보유한 제작사에서 중요할 수 있다.
발표에서는 독일의 영상 제작사 UFA를 사례로 소개했다.
UFA는 매년 3,500시간이 넘는 영상 콘텐츠를 제작한다.
편집자는 여러 해 전에 촬영한 영상에서 특정 인물의 반응이나 장면을 찾아야 할 수 있다.
의미 기반 영상 검색은 이런 과정에서 파일 이름과 폴더 구조만으로 찾기 어려운 자료를 검색하도록 돕는다.
다만 이번 발표는 특정 작업의 처리 성능을 설명하는 것이며, 모든 UFA 편집 업무의 생산성이 같은 비율로 개선됐다는 뜻은 아니다.
이번 사례는 멀티모달 AI의 실용성이 모델의 시각 이해 능력뿐 아니라 영상을 얼마나 빠르게 처리하고, 어떤 장면을 저장하며, 검색 가능한 임베딩을 얼마나 효율적으로 생성하는가에도 달려 있다는 점을 보여준다.
3️⃣ 개발 도구·에이전트
Meta, 14개 전문 AI 에이전트를 1,300줄의 코드로 연결한 ‘Thin Orchestrator’ 공개…설정 작업을 수일에서 1시간 미만으로 단축
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: AI 에이전트 아키텍처, 멀티에이전트 시스템, 데이터 파이프라인, 개발 자동화, 코드 생성, 업무 검증
- 원문: Meta Engineering — The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do
Meta가 복잡한 내부 개발 업무를 여러 AI 에이전트로 자동화하면서 발견한 문제와 이를 해결한 새로운 시스템 구조를 공개했다.
이번 사례의 핵심은 중앙 AI 에이전트에게 더 많은 정보를 제공하는 대신, 오히려 중앙 에이전트가 해야 할 일을 줄였다는 점이다.
Meta는 새로운 데이터 열을 분석 시스템에 추가하는 작업을 자동화하려 했다.
이 작업은 단순히 데이터베이스 테이블에 열 하나를 추가하는 과정이 아니다.
실제 데이터가 여러 시스템에서 수집되고 처리되는 구조에서는 설정 파일과 코드 생성 규칙, 데이터 처리 파이프라인과 검증 작업이 모두 연결돼 있을 수 있다.
Meta의 사례에서는 하나의 데이터 열을 추가하는 데 세 개의 코드 저장소와 세 종류의 프로그래밍 언어가 관련됐다.
작업에 따라 최대 여섯 단계의 처리 과정이 서로 일치해야 했다.
처음에는 모든 것을 아는 하나의 에이전트를 만들었다
Meta는 초기 시스템에서 하나의 AI 에이전트에게 필요한 지식을 모두 제공했다.
여기에는 여러 저장소의 구조, 데이터 형식, 코드 생성 규칙, 검증 방법과 10개 이상의 데이터 소스에 관한 정보가 포함됐다.
모델에게 충분한 정보를 제공하면 더 정확하게 작업할 수 있을 것이라고 예상한 것이다.
하지만 실제 운영에서는 반대의 문제가 발생했다.
에이전트가 서로 다른 시스템의 규칙을 혼동하기 시작했다.
예를 들어 한 데이터 소스에서 사용하는 필드 이름 규칙을 다른 데이터 소스에 적용하거나, 잘못된 코드 생성 패턴을 사용할 수 있었다.
Meta는 이를 Context Contamination(컨텍스트 오염) 문제로 설명한다.
모델이 너무 많은 정보를 한 번에 참고하면서 현재 작업과 관련 없는 다른 영역의 규칙을 잘못 적용하는 현상이다.
이 문제는 단순히 입력할 수 있는 컨텍스트 길이를 늘린다고 반드시 해결되는 것은 아니다.
많은 정보를 읽을 수 있는 능력과 현재 작업에 적합한 정보를 정확하게 선택하는 능력은 다르기 때문이다.
Meta는 다른 단일 에이전트 접근도 시험했다.
개발자가 작업마다 상세한 프롬프트를 직접 작성한 경우 성공률은 70~80% 수준이었다.
하지만 이런 수동적인 조정을 제거하면 성공률은 10~20%로 떨어졌다.
즉 에이전트가 작업을 수행할 수는 있었지만, 개발자가 매번 세부적인 지시를 제공해야 했다.
자동화하려던 업무가 다시 사람의 프롬프트 작성 능력에 의존하게 된 것이다.
중앙 조정기는 판단하지 않고 경로만 선택
Meta는 이를 해결하기 위해 Thin Orchestrator(얇은 오케스트레이터)라는 구조를 만들었다.
Orchestrator(오케스트레이터)는 여러 작업이나 에이전트의 실행 순서를 관리하는 구성요소다.
기존 접근에서는 오케스트레이터가 전체 업무를 이해하고 어떤 방법으로 해결할지 직접 판단했다.
Thin Orchestrator에서는 중앙 조정기의 역할을 매우 제한한다.
중앙 조정기는 어떤 작업이 필요한지 확인하고, 해당 작업을 담당하는 전문 에이전트에게 전달한다.
실제 기술적인 판단과 코드 수정은 하위 에이전트가 수행한다.
Meta는 약 1,300줄의 코드로 중앙 오케스트레이터를 구현했다.
이 오케스트레이터는 14개의 전문 에이전트와 20개 이상의 업무 흐름을 연결한다.
중앙 조정기는 도메인별 코드를 직접 생성하지 않는다.
오케스트레이터의 핵심 실행 과정은 일곱 단계로 구성됐다.
먼저 현재 작업에 맞는 전문 에이전트의 지침을 확인한다.
그다음 이미 같은 대상이 존재하는지 검사해 중복 생성을 방지한다.
필요한 입력값을 사용자에게 받거나 기존 저장소에서 확인한다.
이후 시스템의 경고 상태나 검토가 필요한 조건을 확인한다.
그다음 실제 작업을 전문 에이전트에게 맡긴다.
작업이 끝나면 결과를 확인하고 오류를 전달한다.
이 가운데 실제 LLM의 추론이 필요한 부분은 전문 에이전트가 업무를 처리하는 단계다.
나머지는 대부분 일반적인 프로그램 코드로 정의된 규칙에 따라 실행된다.
이처럼 실행 경로를 명확한 규칙으로 결정하는 방식을 Deterministic Routing(결정적 라우팅)이라고 한다.
동일한 조건에서는 동일한 경로를 선택하도록 만드는 접근이다.
각 전문 에이전트의 정보는 서로 분리
Meta는 전문 에이전트마다 자신이 담당하는 분야의 정보만 제공한다.
예를 들어 스키마를 관리하는 에이전트는 데이터 형식과 필드 정의를 이해한다.
특정 데이터 소스의 코드를 생성하는 에이전트는 해당 소스에 필요한 규칙만 사용한다.
검증 에이전트는 빌드 시스템과 테스트 방법을 관리한다.
이렇게 하면 한 에이전트가 다른 분야의 규칙을 잘못 적용할 가능성을 줄일 수 있다.
Meta는 25개 이상의 지식 파일을 유지하고 있으며, 필요한 시점에만 해당 내용을 불러온다.
이를 On-Demand Context Loading(필요 시점의 컨텍스트 불러오기)이라고 한다.
예를 들어 데이터베이스 스키마를 검토하는 동안 다른 데이터 소스의 코드 생성 규칙을 모두 컨텍스트에 포함할 필요가 없다.
또한 지식 파일이 수정되면 다음 작업부터 업데이트된 내용을 사용할 수 있다.
중앙 오케스트레이터의 코드를 변경할 필요도 줄어든다.
에이전트를 새로 만드는 대신 업무 흐름을 재사용
이번 구조의 또 다른 특징은 업무 흐름과 전문 에이전트를 분리했다는 점이다.
예를 들어 데이터 열 추가 작업은 스키마 정의, 검증, 데이터 처리 코드 생성, 테스트 순서로 진행할 수 있다.
반면 새로운 이벤트를 등록하는 작업은 다른 순서의 단계가 필요할 수 있다.
파이프라인 마이그레이션에서는 기존 시스템 분석과 계획 수립, 코드 변경과 모니터링이 중요하다.
Meta는 이런 차이를 새로운 AI 에이전트를 계속 추가하는 방식으로 해결하지 않았다.
대신 이미 존재하는 전문 에이전트를 서로 다른 순서로 연결하는 Workflow Template(업무 흐름 템플릿)을 사용했다.
예를 들어 파이프라인 마이그레이션 기능을 추가할 때 새로운 에이전트 코드를 만들지 않고 기존 에이전트들의 실행 순서를 정의했다.
이 방식은 업무의 순서를 일반적인 프로그램이 관리하고, 각 단계의 전문적인 판단은 AI가 담당하도록 만든다.
실제 업무에서 나타난 변화
Meta에 따르면 데이터 열 하나의 설정을 준비하는 작업에는 이전에 사람이 직접 수행할 경우 3~4일이 걸렸다.
초기 설정 기반 자동화 시스템에서는 약 하루가 필요했다.
Thin Orchestrator를 적용한 뒤에는 1시간 미만으로 줄었다.
또한 시스템이 생성한 변경사항 가운데 약 3분의 2는 사람이 큰 수정을 하지 않고도 실제 코드에 반영됐다고 설명한다.
이 수치들은 Meta의 내부 업무 환경에서 관찰된 결과다.
동일한 작업을 무작위로 배정한 독립적인 통제 실험의 결과는 아니므로 모든 개발팀에서 같은 개선이 발생한다고 볼 수는 없다.
특히 Meta는 데이터 파이프라인의 구조와 업무 규칙을 이미 잘 알고 있었기 때문에 전문 에이전트와 검증 절차를 설계할 수 있었다.
규칙이 명확하지 않은 업무에서는 같은 구조를 적용하기 어려울 수도 있다.
이번 발표에서 중요한 부분은 에이전트를 더 똑똑하게 만들기 위해 중앙 에이전트의 능력을 계속 확장할 필요는 없다는 점이다.
오히려 일반 프로그램이 잘할 수 있는 작업 순서와 접근권한 관리, 검증 절차를 코드로 고정하고 LLM의 추론이 정말 필요한 부분에만 전문 에이전트를 배치하는 구조가 더 안정적일 수 있다.
4️⃣ 산업·정책·안전
Meta, 초대형 AI 학습 클러스터 ‘Prometheus’의 실제 아키텍처 공개…수십만 GPU 운영 중, 최종 목표는 약 100만 GPU
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: AI 데이터센터, GPU 클러스터, 대규모 모델 학습, NVIDIA Blackwell, 고속 네트워크, 인프라 안정성
- 원문: Meta Engineering — Inside Prometheus: Meta’s Journey to a Gigawatt-Scale Supercluster
Meta가 미국 오하이오주 뉴올버니에 구축 중인 초대형 AI 학습 클러스터 Prometheus의 실제 하드웨어와 네트워크, 장애 대응 구조를 상세하게 공개했다.
이번 발표는 데이터센터 투자 계획을 처음 발표한 것이 아니다.
이미 가동 중인 클러스터가 어떤 방식으로 구성돼 있고, 실제 대형 모델 학습에서 어느 정도의 안정성과 처리 효율을 확보했는지 설명하는 새로운 기술 자료다.
Meta에 따르면 Prometheus의 첫 번째 구축 단계는 완료됐으며, 이미 Muse Wonder 등 주요 모델의 학습에 사용됐다.
현재 Prometheus는 여러 건물에 분산된 수십만 개의 GPU를 연결해 운영하고 있다.
최종 구축이 완료되면 약 100만 개의 GPU를 하나의 대규모 계산 시스템처럼 사용할 계획이다.
여기서 중요한 것은 100만 GPU가 이미 설치돼 운영 중이라는 의미는 아니라는 사실이다.
현재 규모와 향후 목표를 구분해야 한다.
GPU를 많이 확보하는 것과 효율적으로 학습시키는 것은 다르다
대규모 AI 모델을 학습하려면 여러 GPU가 동시에 계산해야 한다.
예를 들어 하나의 모델을 여러 GPU에 나누어 저장하고, 각 GPU가 담당한 계산을 수행한 뒤 결과를 서로 주고받는다.
이 과정에서 GPU 한 대가 정상적으로 작동하지 않으면 전체 학습 작업이 지연될 수 있다.
특히 수만 개 이상의 GPU를 사용하는 환경에서는 개별 장치가 고장 날 확률이 낮더라도 전체 시스템에서는 장애가 계속 발생할 수 있다.
따라서 대규모 모델 학습에서는 GPU 개수만큼 안정적으로 계산을 이어갈 수 있는 시간이 중요하다.
Meta는 이를 설명하기 위해 Goodput(실제로 유용한 학습 계산이 진행된 비율)이라는 지표를 사용한다.
단순히 GPU가 켜져 있는 시간이나 프로그램이 실행되는 시간이 아니다.
모델의 학습에 실제로 기여하는 작업이 진행된 비율을 의미한다.
Meta에 따르면 Prometheus에서는 사전학습 작업에서 85% 이상의 Goodput을 확보했다.
또한 Muse Wonder의 강화학습 작업에서는 90% 이상을 기록했다.
Pretraining(사전학습)은 모델이 대규모 데이터에서 일반적인 지식과 패턴을 학습하는 단계다.
Reinforcement Learning(강화학습)은 실행 결과에 따른 보상을 이용해 모델의 행동을 개선하는 학습 방식이다.
두 작업은 GPU를 사용하는 방식과 데이터 흐름이 다르기 때문에 실제 운영 성능도 별도로 측정해야 한다.
이번 Goodput 수치는 Meta가 내부 학습 환경에서 측정한 결과다.
다른 기업의 클러스터와 동일한 조건에서 독립적으로 비교한 결과는 아니다.
NVIDIA GB200과 GB300을 함께 사용
Prometheus에는 NVIDIA의 서로 다른 GPU 세대가 사용되고 있다.
첫 번째는 GB200 NVL72다.
NVL72는 72개의 GPU를 고속 연결망으로 묶어 하나의 큰 계산 영역처럼 사용하는 구조다.
Meta는 이를 Catalina라는 플랫폼으로 운영한다.
Catalina는 72개의 Blackwell GPU를 사용하며, 전체 GPU 메모리는 약 13.4TB다.
GPU 하나당 192GB의 HBM3e가 제공된다.
HBM(High Bandwidth Memory)은 여러 메모리 칩을 수직으로 쌓아 높은 데이터 전송 속도를 제공하는 메모리 기술이다.
Catalina의 NVLink 대역폭은 전체 영역 기준 최대 130TB/s다.
NVLink는 여러 NVIDIA GPU가 고속으로 데이터를 교환하도록 돕는 연결 기술이다.
Meta는 초기 GB200 구성을 두 개의 랙에 나누어 설치했다.
각 GPU에 NVIDIA Grace CPU와 두 개의 400Gbps 네트워크 인터페이스를 연결해 외부 통신 용량을 확보했다.
두 번째는 GB300 NVL72 기반의 Clemente다.
이 플랫폼에서는 GPU 하나당 메모리가 288GB로 증가했다.
72개 GPU 전체의 HBM3e 용량은 약 20.7TB다.
또한 전체 72개 GPU를 하나의 랙에 배치할 수 있도록 설계됐다.
Meta는 GB300 기반 시스템이 기존 GB200 NVL72 구성보다 약 5~10% 높은 성능을 제공한다고 설명했다.
다만 이 수치 역시 Meta가 제시한 특정 플랫폼 비교 결과다.
모든 AI 모델의 학습 속도가 같은 비율로 개선된다는 뜻은 아니다.
Meta는 앞으로 NVIDIA의 차세대 Vera Rubin NVL72도 도입할 계획이다.
이는 향후 계획이며, 이번에 공개한 Prometheus의 현재 설치 장비와 구분해야 한다.
건물 사이의 네트워크가 학습 성능을 결정
Prometheus는 여러 건물에 분산돼 있다.
이 때문에 개별 랙 안의 GPU를 연결하는 것뿐 아니라 서로 다른 건물의 GPU가 얼마나 빠르게 데이터를 주고받는가가 중요하다.
Meta는 데이터센터 내부의 GPU 통신을 위해 별도의 백엔드 네트워크를 사용한다.
일반적인 웹 서비스의 네트워크와 달리 대규모 AI 학습에서는 서로 다른 GPU가 계산 결과를 자주 교환해야 하기 때문이다.
Meta는 건물 안의 통신에는 상대적으로 낮은 지연시간과 높은 대역폭을 제공하고, 건물 사이의 통신은 별도의 집계 네트워크에서 처리하도록 설계했다.
건물 사이를 연결하는 기술은 BAG(Backend Aggregation)라고 한다.
BAG는 약 2km에서 100km가 넘는 거리에 걸친 통신을 처리한다.
실제 거리가 멀어지면 빛이 이동하는 시간 자체 때문에 지연이 발생한다.
아무리 빠른 네트워크 장비를 사용해도 물리적인 거리로 인한 지연을 완전히 제거할 수는 없다.
Meta는 이를 고려해 서로 통신이 많은 GPU들을 가능한 한 가까운 위치에 배치하고, 상대적으로 지연에 덜 민감한 데이터를 건물 사이에서 전달하도록 학습 작업을 구성한다.
네트워크 운영에는 Meta의 오픈소스 네트워크 소프트웨어인 FBOSS가 사용된다.
GPU 한 대가 고장 나도 전체 작업이 중단되지 않도록 설계
이번 발표에서 특히 흥미로운 부분은 GPU 장애에 대응하는 방식이다.
NVL72 구조에서는 72개 GPU가 매우 밀접하게 연결돼 있다.
따라서 하나의 GPU에 문제가 발생하면 같은 연결 영역의 다른 GPU에도 영향을 줄 수 있다.
Meta는 학습 작업을 위해 NVL72 영역마다 64개 GPU만 활성 작업에 사용한다.
나머지 8개 GPU는 예비 자원으로 남겨둔다.
GPU 하나가 고장 나면 예비 GPU로 대체하고, 마지막으로 저장한 학습 상태에서 작업을 다시 시작하는 방식이다.
이때 사용되는 학습 상태 저장 기능을 Checkpointing(체크포인트 저장)이라고 한다.
모델의 가중치와 최적화 상태, 학습 진행 위치 등을 저장해 장애 이후 작업을 이어갈 수 있도록 하는 기술이다.
Meta는 랙 전체에 문제가 발생하는 상황에도 대비하기 위해 약 2%의 추가 예비 랙을 확보한다.
예를 들어 32,768개 GPU를 실제 학습에 사용하는 작업을 운영하려면 Meta는 총 523개의 NVL72 랙을 준비한다고 설명한다.
이는 물리적으로 37,656개 GPU에 해당한다.
실제로 학습에 참여하는 GPU보다 약 13% 더 많은 장비가 필요하다는 의미다.
다만 이 가운데 상당 부분은 72개 GPU 중 64개를 사용하고 8개를 예비 자원으로 유지하는 설계에서 발생한다.
추가 자원이 모두 고장에 대비한 별도의 예비 랙인 것은 아니다.
실제 장애 간격도 개선
Meta는 학습 작업의 안정성을 측정하기 위해 MTBI(Mean Time Between Interruptions)를 사용한다.
MTBI는 작업 중단 사이의 평균적인 간격을 나타내는 지표다.
이번 발표에서는 이를 GPU 시간 기준으로 계산했다.
Meta는 초기 학습 작업에서 약 4만7천 GPU 시간의 MTBI를 기록했다.
이후 펌웨어 수정과 장애 대응 체계를 개선하면서 5만4천 GPU 시간 이상으로 높였다고 설명한다.
GPU 시간은 GPU 개수와 실행 시간을 곱한 단위다.
따라서 MTBI가 5만4천 GPU 시간이라는 사실을 전체 클러스터가 5만4천 시간 동안 한 번도 멈추지 않았다는 의미로 이해해서는 안 된다.
수많은 GPU가 동시에 실행되는 상황에서는 누적 GPU 시간이 매우 빠르게 증가할 수 있기 때문이다.
Meta는 이런 대규모 클러스터에서는 개별 장비의 고장을 완전히 없애기보다 고장이 발생하더라도 학습 작업을 빠르게 복구하는 구조가 중요하다고 설명한다.
이번 발표는 프런티어 AI의 성능을 높이는 문제가 단순히 더 좋은 GPU를 구매하는 데서 끝나지 않는다는 점을 보여준다.
수십만 개의 GPU를 연결하는 네트워크와 데이터센터의 물리적 설계, 전력과 냉각, 장애 복구와 학습 작업의 배치 방식이 실제 AI 모델 개발 속도에 큰 영향을 미친다.
영국 과학기술위원회, AI 주권 확보를 위한 정책 권고 공개…해외 모델 의존과 자국 기술 역량 사이의 균형 제안
- 공개일: 2026-10-19 — 정확한 게시 시각 미확인
- 문서 작성일: 2026-07-30
- 적용 범위: 영국 AI 산업정책, 국가 AI 주권, 공공부문 AI 조달, 컴퓨팅 인프라, 데이터 거버넌스, AI 보안
- 원문: 영국 정부 — AI sovereignty: preserving UK agency in an AI-enabled world
영국 정부가 독립 자문기구인 과학기술위원회(Council for Science and Technology, CST)의 AI 주권 관련 정책 권고를 공개했다.
이번 문서는 10월 19일에 처음 작성된 것이 아니다.
실제 서한의 작성일은 2026년 7월 30일이며, 10월 19일에 정부 웹사이트를 통해 공개됐다.
따라서 이번 항목은 새롭게 제정된 정책이나 법률이 아니라 기존에 정부에 전달됐던 정책 권고가 공식적으로 공개된 사례다.
AI 주권을 모든 기술의 자급자족으로 정의하지 않는다
CST는 AI Sovereignty(인공지능 주권)를 국가가 AI 기술을 직접 모두 보유하는 것으로만 정의하지 않았다.
위원회는 국가가 AI 가치사슬의 여러 단계에서 충분한 선택권과 통제력을 확보해 원하는 경제적·사회적 결과를 실현하고, 위기 상황에서도 중요한 기능을 유지할 수 있는 능력으로 설명했다.
여기서 AI Value Chain(AI 가치사슬)은 AI 시스템을 개발하고 운영하는 데 필요한 여러 단계를 의미한다.
여기에는 반도체와 컴퓨팅 인프라, 데이터, 모델 개발, 서비스 운영과 실제 산업 적용 등이 포함된다.
어떤 국가는 자체 AI 모델을 개발할 수 있지만 반도체나 데이터센터를 해외 기업에 의존할 수 있다.
반대로 자체 대형 모델이 부족하더라도 외부 모델을 안전하게 운영하는 인프라와 전문적인 응용 기술에서 강점을 가질 수 있다.
CST는 이런 차이를 고려해 어떤 분야에서 자체 역량이 반드시 필요하고, 어떤 분야에서는 해외 기술을 활용하는 것이 합리적인지 판단해야 한다고 제안했다.
국가 차원의 전략과 조정 체계 필요
위원회는 영국 정부가 AI 주권에 관한 명확한 전략을 마련해야 한다고 권고했다.
여러 부처와 공공기관이 개별적으로 AI 기술을 도입하면 서로 다른 시스템과 계약이 만들어질 수 있다.
이 과정에서 특정 해외 사업자에 대한 의존도가 높아지거나 데이터 접근권한을 일관되게 관리하기 어려워질 수 있다.
따라서 정부가 공공부문 전체의 AI 조달과 운영 원칙을 조정할 필요가 있다는 것이다.
예를 들어 국가적으로 중요한 공공서비스가 특정 클라우드 제공업체에 의존하고 있다면 해당 업체의 서비스가 중단되거나 접근이 제한됐을 때 어떤 대안이 있는지 검토해야 한다.
이런 능력을 Resilience(회복탄력성)라고 한다.
외부 장애나 위기 상황이 발생하더라도 중요한 기능을 유지하거나 빠르게 복구하는 능력을 뜻한다.
위원회는 AI 주권을 단순히 국내 기업을 보호하는 정책이 아니라 국가의 중요한 기능을 안정적으로 운영하기 위한 선택권 확보로 접근한다.
국내 역량이 강한 분야에 집중 투자
CST는 영국이 모든 AI 기술 분야에서 세계 최고 수준을 확보하려 할 필요는 없다고 설명한다.
대신 이미 강점을 가지고 있거나 전략적인 기회가 있는 분야에 집중적으로 투자하는 방향을 제시했다.
여기에는 전문 인력과 연구기관, 데이터 자산과 실제 산업 경험 등이 포함된다.
예를 들어 특정 분야에서 영국이 고품질 데이터와 전문성을 보유하고 있다면 이를 활용한 전문 AI 시스템을 개발할 수 있다.
반면 이미 해외 기업이 높은 성능과 경제성을 확보한 범용 기술에서는 외부 모델을 활용하되 중요한 통제권을 유지하는 방식도 가능하다.
여기서 핵심은 해외 기술을 사용하지 말자는 것이 아니라, 사용하더라도 국가가 중요한 결정을 내릴 수 있는 선택지를 유지해야 한다는 주장이다.
공공 신뢰와 데이터 통제
위원회는 AI 주권이 기술적인 문제만은 아니라고 강조한다.
국민이 AI를 신뢰하고 실제로 활용할 수 있어야 사회적·경제적 효과도 발생하기 때문이다.
특히 공공부문에서 AI를 사용할 때는 데이터의 접근권한과 책임 소재가 중요하다.
예를 들어 공공기관이 민감한 시민 정보를 외부 AI 서비스에 전달한다면 해당 정보가 어디에서 처리되고, 어떤 계약과 법적 체계에 따라 보호되는지 확인해야 한다.
위원회는 이런 문제를 개별 기술 구매의 문제로 취급하지 않고 국가 차원의 데이터·기술 거버넌스로 다룰 필요가 있다고 제안했다.
이번 권고는 영국 정부가 어떤 모델이나 클라우드 사업자를 반드시 사용해야 한다고 확정한 것은 아니다.
또한 새롭게 법적 의무가 시행된 것도 아니다.
실제 정책 변화가 발생하려면 정부의 후속 결정과 예산, 규제 절차 등이 필요하다.
그럼에도 이번 문서는 AI를 둘러싼 국가 간 경쟁에서 중요한 질문이 단순히 누가 가장 강력한 모델을 만드는가가 아니라는 점을 보여준다.
국가가 어떤 기술을 통제해야 하며, 어디까지 해외 기술에 의존할 수 있고, 위기 상황에서 핵심 서비스를 어떻게 유지할 수 있는가가 정책의 중요한 기준으로 등장하고 있다.
유럽방송연맹·NVIDIA, 유럽 공영방송의 AI 주권 표준 확대…자체 클라우드·오픈 모델·보안 기준 결합
- 발표일: 2026-10-19 — 정확한 게시 시각 미확인
- 적용 범위: 유럽 AI 주권, 공영방송, AI 에이전트 보안, 미디어 저작권, 데이터 거버넌스, 오픈웨이트 모델
- 원문: NVIDIA — NVIDIA Advances Agentic Security for Media, From European Public Service Broadcasting to Global Content Production
유럽방송연맹 EBU(European Broadcasting Union)와 NVIDIA가 공영방송사를 위한 AI 주권·보안 프레임워크를 확대한다고 발표했다.
이번 발표는 새로운 AI 규제법의 제정이 아니다.
지난해 EBU와 NVIDIA가 제시했던 미디어 AI 주권 원칙을 실제 배포 가능한 클라우드와 모델, 시스템 통합 구조로 확장하는 계획이다.
EBU는 55개국 이상의 115개가 넘는 공영방송 조직이 참여하는 협력체다.
공영방송에서는 AI 도구를 도입할 때 일반적인 기업과 다른 문제가 발생할 수 있다.
예를 들어 뉴스 제작 과정에서 사용하는 취재 자료에는 공개되지 않은 정보와 취재원의 신원이 포함될 수 있다.
방송 아카이브에는 여러 국가와 언어의 저작권 보호 콘텐츠가 저장돼 있을 수 있다.
또한 특정 국가의 공영방송은 외부 서비스 장애가 발생하더라도 중요한 보도 기능을 유지해야 할 수 있다.
따라서 AI 도구가 편리하다는 이유만으로 모든 자료를 외부 클라우드에 전송하는 방식이 적절하지 않을 수 있다.
모델뿐 아니라 데이터와 인프라까지 통제
이번 프레임워크는 AI 시스템의 여러 구성요소에 대한 통제권을 확보하는 것을 목표로 한다.
첫 번째는 데이터다.
방송사는 취재 자료와 아카이브를 어느 시스템에 저장하고 어떤 모델이 접근할 수 있는지 관리해야 한다.
두 번째는 모델이다.
특정 상용 AI 서비스에만 의존하지 않고 조직의 정책과 언어에 맞춰 모델을 선택하거나 수정할 수 있어야 한다.
세 번째는 실행 인프라다.
중요한 데이터를 처리하는 시스템이 어느 국가의 데이터센터에서 실행되는지 확인할 필요가 있다.
네 번째는 보안과 운영이다.
모델이 어떤 자료를 사용했고 어떤 행동을 수행했는지 기록하고 검증할 수 있어야 한다.
이런 요소들을 결합해 Sovereign AI(주권형 AI) 환경을 구축하려는 것이다.
Microsoft·Nebius와의 협력
이번 확대 계획에는 여러 기술 파트너가 참여한다.
Microsoft는 Microsoft Sovereign Cloud와 Azure Local, Foundry Local을 활용하는 방법을 제시한다.
Azure Local은 기업이나 조직이 자체 시설에서 Azure 관련 기술을 실행하도록 지원하는 제품군이다.
Foundry Local은 일부 AI 모델을 조직의 로컬 환경에서 실행하도록 지원하는 도구다.
이런 방식은 방송사가 민감한 자료를 외부 클라우드로 전달하지 않고 처리하거나 외부 네트워크 연결이 끊겼을 때도 일부 핵심 기능을 유지하는 데 도움이 될 수 있다.
Nebius는 유럽의 컴퓨팅 인프라를 활용해 방송사가 자체 모델을 학습하거나 추가 학습하고 실행하는 환경을 제공하는 역할을 맡는다.
NVIDIA는 오픈 모델인 Nemotron 등을 기반으로 방송사의 전문 업무에 맞는 AI 시스템을 개발하는 방향을 제시했다.
예를 들어 방송사는 자국어 뉴스 아카이브를 이해하거나 내부 편집 정책을 따르는 모델을 별도로 구성할 수 있다.
Qvest 등 시스템 통합 업체는 실제 방송 환경에 기술을 연결하고 운영하는 역할을 지원할 예정이다.
표준 확대와 실제 시스템 배포는 구분
EBU와 NVIDIA는 이번 협력을 통해 어떤 클라우드 환경에서 AI를 실행할지, 데이터를 어떻게 관리하고 모델의 안전성을 어떻게 검증할지에 관한 기준과 참조 아키텍처를 마련할 계획이다.
Reference Architecture(참조 아키텍처)는 특정한 종류의 시스템을 구축할 때 참고할 수 있는 기본 구성과 설계 원칙이다.
하지만 참조 아키텍처가 발표됐다는 사실이 EBU의 모든 회원 방송사에 동일한 AI 시스템이 이미 설치됐다는 의미는 아니다.
또한 이번 프레임워크가 유럽연합의 법적 규제로 즉시 적용되는 것도 아니다.
현재는 관련 기술과 운영 기준을 구체화하고 실제 도입을 지원하는 단계다.
이번 발표는 생성형 AI가 언론과 방송 같은 공공성이 높은 분야에 적용되면서 AI의 성능뿐 아니라 데이터의 소유권, 편집 독립성과 서비스 운영의 통제권이 중요한 요구사항이 되고 있음을 보여준다.
📚 추천 글
Cutting our inference bill by 68% by being obsessive about optimization
- 저자: Ryan Skidmore
- 발행: Cloudflare
- 게시일: 2026-10-19
- 원문: Cloudflare — Cutting our inference bill by 68% by being obsessive about optimization
AI 에이전트의 비용을 줄이기 위해 더 저렴한 모델로 교체하면 충분할까?
이 글은 Cloudflare가 실제 운영 중인 AI 코드 리뷰 시스템의 비용을 약 68% 줄인 과정을 상세하게 설명한다.
특히 단순히 모델 가격이 낮아졌기 때문에 비용이 감소한 것이 아니라 프롬프트 캐싱과 모델 선택, 에이전트 실행 구조를 함께 수정했다는 점에서 읽어볼 가치가 있다.
Cloudflare는 4월에도 자사의 AI 코드 리뷰 시스템을 소개한 바 있다.
당시 코드 리뷰 하나를 수행하는 평균 비용은 약 1.19달러였다.
그런데 시간이 지나면서 비용이 계속 증가했다.
8월 말에는 평균 비용이 약 2.46달러까지 높아졌다.
시스템의 핵심 구조가 크게 달라진 것은 아니었다.
다만 코드 리뷰에 사용하는 모델을 변경하고 더 복잡한 코드 변경사항을 검토하면서 모델 호출량이 늘어났다.
Cloudflare는 이를 해결하기 위해 실제 에이전트의 사용 기록을 분석했다.
코드 리뷰 비용은 어디에서 발생할까?
일반적인 LLM API에서는 모델에 전달하는 입력 토큰과 모델이 생성하는 출력 토큰에 비용이 발생한다.
또한 많은 서비스는 Prompt Caching(프롬프트 캐싱)을 제공한다.
프롬프트 캐싱은 모델이 이전에 처리한 입력의 일부를 재사용해 같은 계산을 반복하지 않도록 하는 기능이다.
예를 들어 AI 코드 리뷰 에이전트가 항상 동일한 코드 리뷰 기준과 도구 목록을 사용한다면 해당 정보는 여러 요청에서 반복된다.
이 부분을 캐시에 저장하면 매번 처음부터 처리하는 비용을 줄일 수 있다.
Cloudflare는 기존 코드 리뷰 시스템의 비용을 분석한 결과 다음과 같은 비중을 확인했다.
| 비용 항목 | 비중 |
|---|---|
| 출력 토큰 | 약 23% |
| 캐시 쓰기 | 약 43% |
| 캐시 읽기 | 약 34% |
흥미롭게도 전체 비용의 상당 부분이 새로운 답변을 생성하는 작업이 아니라 기존 컨텍스트를 반복해서 처리하는 과정에서 발생했다.
코드 품질을 검토하는 에이전트는 리뷰 하나당 평균 16.6회의 LLM 호출을 수행했다.
이 과정에서 약 7만2천 토큰을 캐시에 기록하고, 약 108만 토큰을 캐시에서 다시 읽었다.
모델 호출이 반복될 때마다 이전 대화 기록이 계속 입력에 포함됐기 때문이다.
이는 에이전트 시스템에서 중요한 비용 문제다.
단일 프롬프트가 짧더라도 도구 호출이 반복되고 컨텍스트가 누적되면 하나의 작업에 사용되는 전체 토큰 수가 매우 커질 수 있다.
캐시 적중률이 높아도 비용은 증가할 수 있다
Cloudflare의 코드 리뷰 시스템은 프롬프트 캐싱을 이미 적극적으로 사용하고 있었다.
4월에는 캐시 적중률이 약 85.7%였고, 9월에는 97%까지 높아졌다.
일반적으로 캐시 적중률이 높아지면 비용이 줄어들 것으로 기대할 수 있다.
하지만 같은 기간 리뷰 하나당 처리하는 토큰 수는 약 91만 개에서 299만 개로 증가했다.
캐시를 많이 활용하더라도 전체 처리량이 훨씬 커지면 비용이 증가할 수 있는 것이다.
Cloudflare는 이를 해결하기 위해 캐시 적중률 자체보다 어떤 컨텍스트를 여러 에이전트가 공유할 수 있는가에 집중했다.
코드 리뷰 시스템에서는 하나의 PR을 여러 전문 에이전트가 검토한다.
예를 들어 코드 품질과 성능, 보안을 각각 다른 에이전트가 분석할 수 있다.
이 에이전트들은 대부분 같은 도구 목록과 기본 규칙을 사용한다.
하지만 기존 구조에서는 각 에이전트가 첫 요청을 수행할 때 동일한 내용을 별도로 캐시에 기록하는 경우가 있었다.
Cloudflare는 공통된 프롬프트 부분을 먼저 캐시에 기록하고 다른 에이전트가 이를 재사용하도록 수정했다.
이렇게 하면 여러 에이전트가 동일한 긴 지침을 반복해서 처리하는 비용을 줄일 수 있다.
모델 선택과 추론 강도를 다시 평가
Cloudflare는 캐시 최적화만 수행하지 않았다.
실제 코드 리뷰 결과를 비교하면서 어떤 모델과 추론 설정이 가장 적절한지도 다시 평가했다.
예를 들어 더 높은 추론 강도를 사용하면 비용이 증가할 수 있다.
하지만 실제로 발견하는 중요한 코드 문제의 수가 거의 달라지지 않는다면 추가 비용이 의미 없을 수 있다.
Cloudflare는 일부 모델의 높은 추론 설정이 중간 추론 설정과 비교해 중요한 문제를 더 많이 발견하지 못했다고 설명한다.
따라서 해당 작업에서는 중간 추론 설정으로 변경했다.
또한 10월 초에는 Sonnet 5와 Sonnet 5.5를 비교했다.
두 모델은 같은 토큰 단가를 사용했지만, Sonnet 5.5가 작업을 완료하는 데 필요한 토큰 수가 적었다.
Cloudflare의 자체 비교에서 Sonnet 5.5는 코드 품질 리뷰에서 62%, 성능 리뷰에서 58%, 보안 리뷰에서 47% 낮은 실행 비용을 기록했다.
중요한 문제를 발견하는 능력에도 큰 차이가 나타나지 않아 이후 새로운 모델로 전환했다.
이 결과는 모델의 API 단가만으로 실제 비용을 비교해서는 충분하지 않다는 점을 보여준다.
같은 작업을 완료하는 데 몇 번의 호출과 얼마나 많은 토큰이 필요한가도 함께 고려해야 한다.
전체 비용 68% 절감
Cloudflare는 여러 최적화를 적용한 뒤 코드 리뷰 하나당 평균 비용이 약 2.43달러에서 0.77달러로 줄었다고 밝혔다.
약 68% 감소한 결과다.
중앙값 리뷰 시간도 4분9초에서 1분32초로 감소했다.
Cloudflare는 전체 비용 절감 가운데 약 40%가 코드와 시스템 구조의 개선에서 발생했고, 나머지는 모델 선택과 추론 설정 변경에서 발생했다고 설명한다.
다만 글에서는 이 수치가 모든 변경사항을 독립적으로 통제한 실험에서 얻어진 것은 아니라고 명시한다.
서로 다른 시점의 실제 운영 결과를 비교한 것이므로 작업 유형과 트래픽 구성 등의 영향을 완전히 배제할 수는 없다.
이번 글은 AI 에이전트의 운영 비용을 줄이려면 모델 단가만 보는 것이 아니라 전체 실행 과정에서 입력과 출력, 캐시, 도구 호출에 얼마나 많은 자원이 사용되는지 관찰해야 한다는 점을 보여준다.
특히 여러 전문 에이전트를 사용하는 시스템이나 긴 대화와 반복적인 도구 호출이 많은 업무 자동화 서비스에 적용할 만한 사례다.
Who judges the judge? Three helpful ways to audit your LLM evaluators
- 저자: Héctor González Álvarez
- 발행: Google Cloud
- 게시일: 2026-10-19
- 원문: Google Cloud — Who judges the judge? Three helpful ways to audit your LLM evaluators
AI 에이전트의 답변이 올바른지 평가하기 위해 다른 AI 모델을 사용하는 사례가 늘어나고 있다.
하지만 AI가 다른 AI의 답변을 평가하면 객관적인 결과를 얻을 수 있을까?
이 글은 그런 가정이 항상 성립하지 않는 이유를 설명한다.
AI 에이전트의 답변을 평가하는 데 사용되는 모델을 LLM-as-a-Judge라고 한다.
일반적인 자동화 테스트는 정해진 정답이 있는 작업에서 효과적이다.
예를 들어 계산 결과가 정확한지, JSON 형식이 올바른지, 특정 API가 정상적인 값을 반환하는지는 프로그램 코드로 검사할 수 있다.
반면 고객지원 답변이 친절한지, 긴 보고서가 충분히 명확한지처럼 주관적인 판단이 필요한 작업에서는 단순한 규칙만으로 평가하기 어렵다.
이런 상황에서 다른 언어모델을 이용해 답변의 품질에 점수를 매길 수 있다.
문제는 평가에 사용하는 LLM 역시 여러 편향을 가질 수 있다는 점이다.
긴 답변을 더 좋아하는 편향
첫 번째는 Verbosity Bias(장황함 선호 편향)이다.
모델이 답변의 실제 정확도보다 길이와 설명의 풍부함에 높은 점수를 부여하는 현상이다.
예를 들어 두 답변이 있다고 가정해 보자.
첫 번째 답변은 간결하지만 정확하다.
두 번째 답변은 길고 전문적인 용어를 많이 사용하지만 일부 내용이 틀렸다.
평가 모델이 답변의 길이와 자신감 있는 표현을 품질로 잘못 판단하면 두 번째 답변에 더 높은 점수를 줄 수 있다.
이런 평가를 기준으로 모델을 개선하면 실제 정확도가 높아지는 대신 불필요하게 길고 그럴듯한 답변을 생성하는 방향으로 최적화될 위험이 있다.
두 번째는 Position Bias(위치 편향)이다.
서로 다른 두 답변을 비교할 때 어떤 답변을 먼저 제시했는지에 따라 평가가 달라지는 현상이다.
Google은 관련 연구에서 후보의 제시 순서를 바꾸는 것만으로 평가 결과가 크게 달라진 사례를 소개했다.
따라서 두 모델의 답변을 비교할 때는 A와 B의 위치를 바꿔 다시 평가하는 방법이 유용할 수 있다.
좋은 문장과 올바른 사실을 혼동
세 번째는 Halo Effect(후광 효과)다.
어떤 요소가 좋아 보인다는 이유로 다른 요소도 좋게 평가하는 현상이다.
예를 들어 문장의 문법이 정확하고 형식이 깔끔하다고 해서 내용의 사실관계까지 정확한 것은 아니다.
하지만 평가 모델이 문장의 표현을 긍정적으로 인식하면 실제 정보의 오류를 충분히 확인하지 않을 수 있다.
네 번째는 Agreeableness Bias(동조 편향)다.
평가 모델이 잘못된 답변을 발견하고 낮은 점수를 주는 데 소극적인 현상이다.
평가 데이터의 대부분이 정상적인 답변이라면 이런 문제가 숨겨질 수 있다.
예를 들어 평가 대상 100개 가운데 95개가 올바른 답변이라면 평가 모델이 모든 답변을 통과시켜도 95%의 정확도를 기록할 수 있다.
하지만 실제로는 다섯 개의 잘못된 답변을 하나도 찾아내지 못한 것이다.
따라서 전체 정확도만 보는 것으로는 충분하지 않다.
잘못된 답변을 얼마나 정확하게 찾아내는지도 확인해야 한다.
세 가지 평가 검증 방법
Google은 LLM 평가자의 품질을 확인하기 위해 세 가지 방법을 제안한다.
첫 번째는 Internal Stability(내부 안정성)를 측정하는 것이다.
동일한 답변을 여러 번 평가하도록 하고 점수가 얼마나 일관되게 나오는지 확인한다.
모델이 같은 입력에 대해 5점과 2점, 4점을 번갈아 반환한다면 해당 평가 기준을 신뢰하기 어렵다.
두 번째는 Human Alignment(인간 평가와의 일치도)를 검증하는 것이다.
전문가가 검토한 정답 데이터를 마련하고 AI 평가자가 얼마나 비슷한 판단을 내리는지 비교한다.
이때 단순한 일치율뿐 아니라 우연히 같은 판단을 내렸을 가능성을 보정한 지표를 사용해야 한다.
특히 잘못된 답변을 충분히 포함한 데이터셋으로 검증해야 한다.
세 번째는 Multi-Judge Ensemble(여러 평가 모델의 결합)이다.
하나의 모델이 모든 기준을 평가하는 대신 서로 다른 모델이나 평가자가 개별 항목을 확인하도록 한다.
예를 들어 한 평가자는 사실 정확도를 확인하고, 다른 평가자는 사용자의 요구사항을 충족했는지 검사하며, 또 다른 평가자는 안전성을 검토할 수 있다.
서로 다른 모델의 평가가 크게 달라진다면 해당 결과를 추가 검토 대상으로 분류할 수 있다.
다만 여러 평가 모델이 같은 결과를 내렸다는 이유만으로 그 결과가 반드시 옳은 것은 아니다.
모델들이 비슷한 학습 데이터와 구조를 사용했다면 같은 편향을 공유할 가능성도 있기 때문이다.
이번 글은 AI 에이전트의 평가를 자동화할수록 평가 시스템 자체의 정확도와 일관성을 측정하는 작업이 중요해진다는 점을 보여준다.
특히 실제 서비스에서 AI 답변을 자동으로 점수화하거나 모델을 교체하기 위한 평가 시스템을 설계하는 개발자에게 유용한 자료다.
Developer’s guide to implementing MCP apps in Gemini
- 저자: Dave Wang
- 발행: Google Cloud
- 게시일: 2026-10-19
- 원문: Google Cloud — Developer’s guide to implementing MCP apps in Gemini
AI 챗봇이 외부 서비스를 호출할 수 있게 됐더라도 모든 업무를 채팅으로 처리하는 것이 편리한 것은 아니다.
예를 들어 사용자가 AI에게 대규모 프로젝트의 일정표를 만들어 달라고 요청했다고 가정해 보자.
모델이 일정표를 텍스트로 생성할 수는 있다.
하지만 사용자가 특정 작업의 날짜를 변경하고 싶다면 다시 채팅으로 수정사항을 전달해야 한다.
그다음 결과가 마음에 들지 않으면 또 다른 요청을 보내야 한다.
이런 과정을 반복하면 단순한 UI 조작도 여러 번의 모델 호출을 거쳐야 한다.
Google Cloud는 이를 해결하는 방법으로 MCP Apps를 소개한다.
단순한 도구 호출에서 상호작용 가능한 UI로
MCP(Model Context Protocol)는 AI 에이전트가 외부 프로그램과 데이터를 호출할 수 있도록 하는 통신 규격이다.
일반적인 MCP 도구에서는 모델이 외부 API를 실행하고 결과를 텍스트나 구조화된 데이터로 전달받는다.
예를 들어 데이터베이스를 조회하는 MCP 도구는 검색 결과를 JSON으로 반환할 수 있다.
하지만 사용자가 여러 항목을 비교하고 직접 수정하려면 단순한 JSON 응답보다 화면에서 조작할 수 있는 인터페이스가 편리할 수 있다.
MCP Apps는 이런 요구를 해결하기 위한 MCP 확장 규격이다.
Google이 설명하는 MCP Apps는 SEP-1865를 기반으로 한다.
이 규격은 외부 도구와 함께 사용자가 직접 상호작용할 수 있는 UI를 제공하도록 설계됐다.
예를 들어 AI가 금융 분석 결과를 생성한 뒤 그래프와 입력 필드를 포함한 화면을 보여줄 수 있다.
사용자는 특정 값을 변경하거나 조건을 조정하면서 결과를 즉시 확인할 수 있다.
모든 작은 변경사항을 자연어로 다시 입력할 필요가 없는 것이다.
Gemini Enterprise 안에서 실제 UI 실행
Google은 MCP Apps를 Gemini Enterprise와 연결하는 방법을 소개했다.
외부 MCP 서버는 도구 실행 기능뿐 아니라 UI를 구성하는 HTML도 제공한다.
Gemini Enterprise는 이 UI를 채팅 화면 안에 표시한다.
표시 방식에는 Sandboxed iframe이 사용된다.
iframe은 하나의 웹페이지 안에 다른 웹페이지를 표시하는 HTML 요소다.
Sandboxed iframe은 외부 콘텐츠가 상위 페이지의 기능과 데이터에 임의로 접근하지 못하도록 제한을 적용하는 실행 환경이다.
사용자는 이 UI를 채팅 안에서 확인하거나 전체 화면 또는 별도 패널로 확장할 수 있다.
예를 들어 법률 문서 검토에서는 민감한 정보를 가릴 부분을 시각적으로 선택할 수 있다.
3D 설계 작업에서는 CAD 모델을 회전하거나 특정 부품을 확인할 수 있다.
금융 분석에서는 숫자를 변경하면서 시나리오별 결과를 비교할 수 있다.
이처럼 채팅은 사용자의 의도를 이해하고 작업을 시작하는 역할을 맡고, 반복적인 세부 조작은 일반적인 UI가 담당하도록 구성하는 것이다.
세 계층으로 분리한 시스템 구조
Google이 소개한 아키텍처는 크게 세 부분으로 나뉜다.
첫 번째는 사용자의 브라우저다.
브라우저에는 Gemini 채팅 화면과 MCP App의 UI가 표시된다.
두 번째는 Gemini Enterprise다.
Gemini Enterprise는 모델의 도구 호출과 UI 사이의 메시지 전달, 사용자 인증과 접근권한을 관리한다.
세 번째는 개발자가 운영하는 MCP 서버다.
Google의 예제에서는 MCP 서버를 Cloud Run에 배포한다.
Cloud Run은 애플리케이션을 관리형 서버리스 환경에서 실행하는 Google Cloud 서비스다.
서버리스는 개발자가 개별 서버를 직접 관리하지 않고 필요한 코드를 실행하는 운영 방식이다.
MCP 서버는 실제 업무 데이터를 처리하고 필요한 UI 리소스를 제공한다.
이런 구조에서는 UI와 모델, 실제 업무 시스템의 역할을 분리할 수 있다.
예를 들어 모델은 사용자의 요청을 분석해 필요한 도구를 선택한다.
MCP 서버는 실제 데이터를 조회하거나 변경한다.
사용자는 UI에서 결과를 확인하고 추가적인 조작을 수행한다.
두 단계 인증이 필요한 이유
Google은 이 구조에서 인증을 두 계층으로 나누는 방법을 강조한다.
첫 번째는 Cloud Run IAM이다.
IAM(Identity and Access Management)은 어떤 사용자나 프로그램이 특정 자원에 접근할 수 있는지 관리하는 기능이다.
Cloud Run IAM은 어떤 서비스가 MCP 서버를 호출할 수 있는지 검사한다.
예를 들어 승인되지 않은 외부 프로그램이 MCP 서버에 직접 접근하려 하면 요청을 차단할 수 있다.
하지만 서비스 수준의 인증만으로는 실제 요청을 보낸 개별 사용자의 권한을 확인하기 어렵다.
그래서 두 번째 인증 계층이 필요하다.
이는 OAuth 2.0을 이용한 사용자 인증이다.
OAuth는 사용자의 비밀번호를 외부 서비스에 직접 전달하지 않고 제한된 접근권한을 부여할 수 있도록 하는 인증·인가 체계다.
MCP 서버는 요청에 포함된 사용자 정보를 확인해 실제 사용자가 해당 데이터를 읽거나 수정할 권한이 있는지 검사한다.
이렇게 하면 승인된 Gemini Enterprise를 통해 들어온 요청이라도 모든 사용자가 같은 데이터에 접근하는 문제를 방지할 수 있다.
Google은 이 두 단계의 인증을 독립적으로 적용해야 한다고 설명한다.
AI 챗봇과 일반적인 웹 UI의 결합
이번 글이 특히 흥미로운 이유는 AI가 모든 사용자 인터페이스를 대체해야 한다는 접근과 다르기 때문이다.
사용자가 처음에는 자연어로 목표를 설명하는 것이 편리할 수 있다.
하지만 작업이 진행된 뒤에는 버튼과 표, 그래프를 이용해 직접 수정하는 방식이 더 효율적일 수 있다.
MCP Apps는 두 인터페이스를 하나의 작업 과정에 결합한다.
이렇게 하면 사용자의 의도를 이해하는 데 AI를 사용하면서도 모든 세부 조작을 모델 호출로 처리하는 비용과 지연시간을 줄일 수 있다.
또한 결과를 사용자가 직접 검토하고 승인할 수 있는 화면을 제공하기 때문에 고위험 업무의 통제에도 활용할 수 있다.
이 글은 향후 AI 에이전트의 인터페이스가 단순한 채팅창에서 벗어나 대화와 실제 조작 가능한 UI가 결합된 작업 공간으로 발전할 가능성을 구체적인 아키텍처로 보여준다.
특히 프런트엔드 개발자가 AI 에이전트와 웹 인터페이스를 어떻게 연결할 수 있는지 이해하기 좋은 자료다.
Accelerating Mamba-2 with High-Performance Forward Pass Kernels in NVIDIA CUDA Tile
- 저자·발행: NVIDIA Technical Blog
- 게시일: 2026-10-19
- 원문: NVIDIA — Accelerating Mamba-2 with High-Performance Forward Pass Kernels in NVIDIA CUDA Tile
대형 언어모델의 성능을 높이려면 모델의 구조를 바꾸거나 GPU를 더 많이 확보하는 방법을 생각하기 쉽다.
하지만 같은 모델과 GPU를 사용하더라도 실제 계산을 수행하는 GPU 프로그램을 어떻게 작성하느냐에 따라 처리 속도가 크게 달라질 수 있다.
이 글은 NVIDIA가 Mamba-2 모델의 계산을 최적화한 과정을 설명한다.
특히 일반적인 Python 프로그램보다 GPU의 병렬 처리 구조에 가까운 수준에서 어떤 최적화가 가능한지 살펴볼 수 있다.
Transformer와 Mamba의 차이
최근 언어모델에서 가장 널리 사용되는 구조는 Transformer다.
Transformer의 핵심 구성요소는 Attention(어텐션)이다.
Attention은 입력의 서로 다른 부분 사이의 관련성을 계산하는 방법이다.
예를 들어 모델이 긴 문장을 읽을 때 현재 단어와 관련된 이전 단어들을 참고할 수 있도록 한다.
하지만 입력이 길어질수록 이전 토큰과의 관계를 계산하고 관련 정보를 저장하는 비용이 증가할 수 있다.
이를 해결하기 위한 대안 가운데 하나가 SSM(State Space Model, 상태 공간 모델)이다.
SSM은 이전 입력의 정보를 고정된 크기의 내부 상태에 요약해 저장한다.
새로운 토큰이 들어오면 기존 상태를 갱신하는 방식으로 정보를 처리한다.
이런 구조는 매우 긴 입력을 다룰 때 메모리 사용량을 효율적으로 관리할 수 있다는 장점이 있다.
Mamba-2는 SSM 계열의 모델 구조다.
Mamba-2는 긴 시퀀스를 처리하는 효율을 높이면서도 Transformer처럼 GPU의 병렬 행렬 연산을 활용할 수 있도록 설계됐다.
상태를 갱신하는 계산이 병목이 된다
Mamba-2는 새로운 입력을 받을 때 내부 상태를 갱신한다.
이때 현재 입력과 이전 상태, 학습된 모델 파라미터를 이용해 새로운 상태를 계산한다.
수학적으로는 이전 상태에 일정한 변환을 적용하고 새로운 입력의 영향을 더하는 방식으로 표현할 수 있다.
문제는 실제 GPU에서 이 계산을 효율적으로 수행하는 것이 단순하지 않다는 점이다.
GPU는 수많은 연산을 동시에 실행하도록 설계돼 있다.
하지만 상태 갱신에는 이전 단계의 결과가 필요한 부분이 있다.
이런 의존성이 너무 많으면 GPU가 제공하는 병렬 계산 성능을 충분히 활용하지 못할 수 있다.
NVIDIA는 이를 해결하기 위해 계산을 여러 구간으로 나누는 방식을 사용했다.
이를 Chunking(청크 분할)이라고 한다.
긴 입력을 일정한 크기의 구간으로 나누고, 가능한 연산은 구간 안에서 병렬로 처리하는 접근이다.
이번 구현에서는 계산을 세 개의 GPU 커널로 분리했다.
첫 번째 커널은 상태를 얼마나 유지하거나 감소시킬지 결정하는 누적 계산을 처리한다.
두 번째 커널은 각 구간의 마지막 상태를 계산한다.
세 번째 커널은 각 토큰의 최종 출력값을 계산한다.
이렇게 분리하면 서로 독립적인 계산을 GPU에서 병렬로 실행하기 쉬워진다.
CUDA Tile을 이용한 계산 최적화
NVIDIA는 이번 작업에 CUDA Tile(cuTile)을 사용했다.
CUDA는 NVIDIA GPU에서 범용 계산을 수행하기 위한 플랫폼이다.
CUDA Tile은 여러 숫자로 구성된 데이터 블록을 중심으로 GPU 연산을 작성하도록 돕는 프로그래밍 도구다.
여기서 Tile(타일)은 행렬이나 텐서에서 일정한 크기로 나눈 데이터 블록을 의미한다.
예를 들어 매우 큰 행렬을 한꺼번에 계산하는 대신 작은 타일들로 나누어 처리할 수 있다.
GPU에서는 이런 블록 단위 계산을 잘 설계하면 메모리 접근과 병렬 연산의 효율을 높일 수 있다.
NVIDIA는 cuTile의 ct.mma 연산을 이용해 GPU의 Tensor Core를 활용했다.
Tensor Core(텐서 코어)는 행렬 곱셈처럼 AI 모델에서 자주 사용하는 계산을 빠르게 처리하도록 설계된 GPU의 연산 장치다.
또한 일부 지수함수 계산에서는 일반적인 exp 대신 exp2를 활용했다.
이는 수학적으로 같은 계산을 적절하게 변형하면서 하드웨어에서 더 효율적으로 실행하도록 만드는 최적화 방법이다.
이런 변경은 모델의 학습된 가중치 자체를 바꾸는 것이 아니다.
같은 수학적 연산을 GPU에서 더 효율적인 방식으로 실행하도록 코드를 변경하는 작업이다.
기존 Triton 구현과 성능 비교
NVIDIA는 새로 작성한 cuTile 커널을 기존 Triton 구현과 비교했다.
Triton은 GPU 연산을 상대적으로 높은 수준의 언어로 작성하고 최적화할 수 있도록 하는 도구다.
평가는 NVIDIA B300 GPU 한 대에서 수행됐다.
입력 길이와 내부 상태 크기 등 여러 조건을 변경하면서 Mamba-2의 순전파 계산 시간을 측정했다.
Forward Pass(순전파)는 입력 데이터를 모델에 전달해 내부 계산을 수행하고 출력을 얻는 과정이다.
학습 과정에서는 순전파 이후 손실값을 계산하고, 파라미터를 수정하기 위한 역전파도 수행한다.
NVIDIA가 공개한 결과에서 최적화된 cuTile 커널은 기존 Triton 구현보다 1.14~1.82배 높은 처리 속도를 기록했다.
입력 길이와 내부 상태가 커질수록 개선 효과가 커지는 경향이 나타났다.
다만 이 수치는 Mamba-2 순전파 커널의 실행 시간을 비교한 것이다.
언어모델 전체의 학습 속도가 1.82배 증가했다는 의미는 아니다.
실제 학습 성능은 역전파와 데이터 처리, GPU 사이의 통신과 모델의 다른 계층에도 영향을 받는다.
또한 이번 평가의 하드웨어는 NVIDIA B300이므로 다른 GPU에서 동일한 결과가 나타난다고 볼 수 없다.
NVIDIA는 이번 구현을 TileGym을 통해 사용할 수 있도록 제공했다.
TileGym은 GPU 커널의 구현과 성능을 실험하고 비교하는 데 사용하는 도구다.
이번 글은 AI 모델의 성능이 단순히 파라미터 수와 모델 아키텍처에 의해 결정되지 않는다는 점을 보여준다.
수학적으로 같은 계산이라도 데이터를 어떤 크기로 나누고, GPU 메모리를 어떻게 사용하며, 어떤 연산 장치를 활용하는가에 따라 실제 처리 시간이 달라질 수 있다.
AI 모델을 실행하는 하드웨어와 소프트웨어 최적화가 어떤 문제를 해결하는 분야인지 이해하기 좋은 기술 자료다.