AI 데일리 브리핑 — 2026-11-11

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

---

1️⃣ 주요 모델·연구

Google, ‘Gemini 4 Carbon’ 일반 제공 시작…복잡한 코딩·다중 에이전트 작업 강화하고 Antigravity에 /swarm 추가

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: 프런티어 AI 모델, 코딩 에이전트, 멀티모달 AI, 장기 작업 자동화, 사이버보안, 과학 연구
• 원문: Google — Gemini 4 Carbon is now available

Google이 프런티어 모델 Gemini 4 Carbon의 일반 제공을 시작했다.

이번 발표는 Gemini 4 Carbon이라는 모델을 처음 공개한 소식은 아니다. 앞서 제한된 환경에서 제공했던 모델을 일반 유료 API와 기업용 서비스, 일부 소비자 제품으로 확대했다는 점이 핵심이다.

Google은 Carbon을 복잡한 연구와 코딩, 장시간 이어지는 에이전트 작업에 적합한 모델로 소개했다.

특히 여러 AI 에이전트가 협력하면서 파일을 수정하고 결과를 검증하는 작업을 지원하기 위해 Google Antigravity의 /swarm 기능을 프리뷰로 공개했다.

단순히 더 강력한 언어모델을 제공하는 것뿐 아니라, 하나의 복잡한 목표를 여러 에이전트가 나누어 수행하는 실행 환경까지 함께 확대하는 방향이다.

여러 에이전트가 하나의 프로젝트를 나누어 처리

일반적인 AI 코딩 에이전트는 사용자의 요청을 받은 뒤 파일을 읽고 수정하거나 테스트를 실행한다.

하지만 복잡한 프로젝트에서는 한 에이전트가 모든 작업을 순차적으로 처리하는 방식이 비효율적일 수 있다.

예를 들어 기존 웹 애플리케이션의 프런트엔드와 백엔드를 함께 변경한다고 가정해 보자.

한쪽에서는 데이터베이스의 구조를 수정해야 할 수 있다.

다른 쪽에서는 새로운 API를 구현해야 한다.

동시에 프런트엔드의 컴포넌트를 수정하고 전체 테스트도 수행해야 한다.

/swarm은 이런 작업을 여러 에이전트에게 분배하도록 설계됐다.

다중 에이전트 시스템(Multi-Agent System)은 여러 AI 에이전트가 하나의 목표를 달성하기 위해 역할을 나누거나 정보를 교환하는 구조다.

Google은 Carbon을 복잡한 설계와 전체 작업의 조정, 결과 감사에 배치하고 상대적으로 작은 모델을 다른 작업에 사용할 수 있다고 설명한다.

또한 각 에이전트에게 격리된 작업 공간을 제공할 수 있다.

이는 여러 에이전트가 같은 파일을 동시에 수정하면서 서로의 작업을 덮어쓰는 문제를 줄이기 위한 것이다.

여기서 검증 에이전트(Verifier Agent)는 다른 에이전트가 수행한 작업이 올바른지 검사하는 역할을 맡을 수 있다.

예를 들어 새로운 기능을 구현한 에이전트와 별도로 테스트를 실행하거나 보안 문제를 찾는 에이전트를 배치할 수 있다.

다만 여러 에이전트를 사용한다고 해서 모든 작업이 자동으로 빨라지는 것은 아니다.

서로 다른 작업 사이에 의존관계가 존재한다면 일부 에이전트는 다른 작업의 완료를 기다려야 한다.

또한 작업을 분배하고 결과를 통합하는 데 추가적인 토큰과 계산 자원이 필요할 수 있다.

실제 코딩 에이전트 평가에서 성능 개선

Google은 Gemini 4 Carbon을 여러 외부 벤치마크에서 평가했다고 밝혔다.

벤치마크(Benchmark)는 동일한 조건에서 여러 모델이나 시스템의 성능을 비교하기 위해 사용하는 평가 과제다.

대표적인 평가에는 다음이 포함된다.

Google은 Carbon이 CursorBench 4.0과 WANDR, AutomationBench에서 가장 높은 순위를 기록했다고 설명했다.

또한 비교 대상인 차상위 외부 모델보다 성공한 작업당 비용이 두 배 이상 낮았다고 밝혔다.

여기서 중요한 지표는 단순한 토큰당 가격이 아니라 작업당 비용(Cost per Task)이다.

예를 들어 어떤 모델의 API 가격이 저렴하더라도 복잡한 작업에서 반복적으로 실패한다면 재시도 비용이 발생할 수 있다.

반면 상대적으로 비싼 모델이 한 번에 작업을 완료한다면 실제 총비용이 더 낮을 수도 있다.

다만 모델별 점수는 벤치마크 운영 환경과 추론 설정, 에이전트 실행 도구의 영향을 받는다.

Google이 여러 외부 평가의 결과를 인용했다고 해서 실제 모든 개발 프로젝트에서 Carbon이 가장 높은 성능을 제공한다는 의미는 아니다.

Google도 일반적인 코딩 업무에서는 Gemini 4 Argon이 더 적합할 수 있다고 설명한다.

문서와 도면을 분석하는 멀티모달 능력

Carbon은 이미지와 표, 도면과 문서를 함께 분석하는 작업도 강화했다.

멀티모달 AI(Multimodal AI)는 텍스트와 이미지 등 서로 다른 형태의 정보를 함께 처리하는 기술이다.

예를 들어 건축 도면과 관련 설명 문서를 제공한 뒤 특정한 설계 조건을 검사하도록 요청할 수 있다.

또는 금융 보고서의 표와 그래프를 함께 분석하고 새로운 스프레드시트를 작성하도록 할 수 있다.

Google은 Artificial Analysis와 함께 개발한 Multimodal Knowledge Agent(MKA) 벤치마크에서도 Carbon을 평가했다.

이 평가에서 Carbon은 품질 기준 2위를 기록했다.

또한 최고 점수를 기록한 모델보다 평균 작업 비용이 6분의 1 이하였다고 밝혔다.

다만 이는 특정한 평가에서 얻어진 결과다.

모든 종류의 문서 분석에서 같은 비용 차이가 나타나는 것은 아니다.

특히 긴 문서에서 중요한 수치를 추출하는 작업은 실제 결과물에 오류가 없는지 별도로 검증해야 한다.

사이버보안 능력과 안전장치 강화

Carbon은 소프트웨어 취약점을 발견하고 분석하는 능력도 강화했다.

예를 들어 보안 담당자는 특정한 코드에서 취약점이 발생하는 원인을 조사할 수 있다.

이후 실제 문제가 발생하는 조건을 확인하고 수정 코드를 작성할 수 있다.

Google은 내부 프로젝트인 Project Fortify에서 Carbon을 평가했다.

공개된 결과는 다음과 같다.

재현율(Recall)은 실제로 존재하는 문제 가운데 시스템이 얼마나 많은 문제를 발견했는지 나타낸다.

정밀도(Precision)는 시스템이 문제라고 판단한 결과 가운데 실제로 문제가 있는 결과의 비율이다.

이 수치는 Google이 정한 내부 평가 조건에서 측정한 결과다.

모든 소프트웨어의 취약점을 100% 발견하거나 모든 사이버 공격의 99%를 차단한다는 의미는 아니다.

Google은 별도의 Gray Swan 평가에서 공격 성공률이 이전 Argon의 9.86%에서 Carbon의 2.17%로 감소했다고 설명했다.

이 결과 역시 특정한 공격 방법과 평가 환경에서 얻어진 수치다.

모델의 사이버보안 능력이 강해지는 만큼 실제 사용자의 권한과 목적을 확인하는 접근 제한도 중요해지고 있다.

일반 API와 유료 제품으로 제공 확대

이번 발표에 따라 Carbon은 Google AI Studio의 유료 Gemini API와 기업용 Gemini 서비스에서 사용할 수 있게 됐다.

Google이 공개한 초기 API 가격은 다음과 같다.

토큰(Token)은 언어모델이 텍스트를 처리하는 기본 단위다.

위 가격은 Google이 제시한 초기 가격이다.

향후 가격이 변경될 수 있으므로 실제 서비스를 운영할 때는 호출 시점의 요금표를 확인해야 한다.

Google AI Ultra 구독자에게는 Antigravity와 Gemini 앱, Google 검색의 AI Mode 등에서도 단계적으로 제공된다.

하지만 모든 사용자가 같은 시점에 모든 기능을 이용할 수 있는 것은 아니다.

특히 /swarm은 프리뷰 기능이므로 정식 제공 API와 구분해야 한다.

이번 발표는 프런티어 모델의 경쟁이 단순한 질문·답변 성능에서 복잡한 업무를 여러 에이전트가 수행하고, 실제 결과물을 검증하며, 성공한 작업당 비용을 줄이는 방향으로 확대되고 있음을 보여준다.

---

Google DeepMind, ‘Gemini Robotics 2.5’ 공개…200개 로봇 작업 평가하고 Mercedes-Benz 생산라인에서 96% 성공률 기록

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: 로봇 AI, VLA, 멀티모달 AI, 휴머노이드 로봇, 산업 자동화, 물리적 AI 안전
• 원문: Google DeepMind — Gemini Robotics 2.5 accelerates real-world general dexterity

Google DeepMind가 새로운 로봇 행동 모델 Gemini Robotics 2.5를 공개했다.

이번 모델은 실제 로봇이 카메라로 주변 환경을 관찰하고, 자연어 지시를 이해한 뒤, 물체를 조작하는 행동을 생성하도록 설계됐다.

특히 일상적인 물체를 집는 작업뿐 아니라 부드럽게 변형되는 물체를 다루거나 여러 단계의 동작을 연결하는 능력이 강화됐다.

Google은 이번 모델을 200개 이상의 실제 로봇 작업에서 평가했으며, 일부 산업용 휴머노이드 로봇 실험에도 적용했다고 밝혔다.

VLA는 언어모델과 무엇이 다른가

일반적인 언어모델은 텍스트를 입력받아 새로운 텍스트를 생성한다.

반면 로봇은 실제 공간에서 움직여야 한다.

예를 들어 사용자가 로봇에게 컵을 집어 선반에 놓으라고 지시했다고 가정해 보자.

로봇은 컵의 위치를 파악해야 한다.

컵을 집기 위해 손을 어느 방향으로 움직일지도 결정해야 한다.

또한 컵을 집은 뒤 주변 물체와 충돌하지 않으면서 선반까지 이동해야 한다.

이런 작업에는 실제 물체의 위치와 로봇 관절의 상태를 함께 고려해야 한다.

VLA(Vision-Language-Action)는 시각정보와 자연어 지시를 바탕으로 실제 로봇의 행동을 생성하는 모델 구조다.

Gemini Robotics 2.5는 이런 VLA 모델이다.

Google은 별도의 Gemini Robotics ER을 이용해 상위 수준의 작업 계획을 수행할 수도 있다고 설명한다.

예를 들어 ER 모델은 어떤 물체를 어떤 순서로 옮겨야 하는지 결정할 수 있다.

이후 Robotics 2.5가 실제 로봇 팔과 손의 움직임을 생성한다.

이처럼 목표를 계획하는 시스템과 실제 움직임을 수행하는 시스템을 분리하는 방식을 계층적 제어(Hierarchical Control)라고 한다.

200개 작업에서 정밀도와 작업 범위 개선

Google은 Gemini Robotics 2.5를 200개 종류의 작업에서 평가했다.

대표적인 작업은 다음과 같다.

여기서 중요한 부분은 부드럽게 변형되는 물체(Deformable Object)를 다루는 능력이다.

예를 들어 금속 블록은 로봇이 집어도 전체 형태가 크게 변하지 않을 수 있다.

반면 천이나 리본은 집는 위치와 힘에 따라 형태가 계속 변한다.

따라서 로봇이 현재 카메라에서 관찰한 모습만으로 정확한 다음 행동을 결정하기 어려울 수 있다.

Google은 기존 Gemini Robotics 2와 비교해 작업의 종류에 따라 성공률이 상대적으로 30~100% 개선됐다고 밝혔다.

또한 일부 평가에서는 작업 완료시간이 20~30% 감소했다.

대표적인 작업의 성공률 변화는 다음과 같다.

하지만 이 수치들은 Google이 정한 실험 조건에서 얻어진 결과다.

예를 들어 페이스트리 포장에서 100%를 기록했다고 해서 모든 종류의 음식과 집게, 배치 조건에서 반드시 성공한다는 의미는 아니다.

또한 작업마다 실제 평가 횟수와 조건이 다를 수 있으므로 전체 로봇의 일반적인 성공률로 해석해서는 안 된다.

Mercedes-Benz 실제 생산라인에서 로봇 적용

이번 발표에서 가장 주목할 만한 사례는 Apptronik의 Apollo 2 휴머노이드 로봇이다.

Google은 Apptronik과 협력해 Mercedes-Benz의 실제 자동차 생산라인에서 부품을 집고 분류하는 작업을 시험했다.

로봇은 자동차 부품이 담긴 상자에서 필요한 금속 부품을 집는다.

이후 지정된 순서에 따라 다른 용기에 배치한다.

이 작업을 Picking and Packing(집기와 포장·배치)이라고 한다.

로봇은 단순히 같은 동작을 반복하는 것이 아니라 부품의 위치가 조금 달라져도 해당 상황에 맞춰 움직임을 조정해야 한다.

Google은 해당 파일럿 실험에서 96%의 작업 성공률을 기록했다고 밝혔다.

이 결과는 실제 생산환경에서 수행한 개념검증이라는 점에서 의미가 있다.

하지만 아직 모든 Mercedes-Benz 생산라인에 로봇이 대규모로 배치됐다는 의미는 아니다.

또한 96%라는 수치는 해당 파일럿 작업에서 측정된 성공률이다.

다른 종류의 부품과 생산시설에서도 같은 수준의 안정성을 제공한다는 보장은 없다.

실제 상용화에서는 작업 속도와 장비 유지보수, 안전성과 전체 운영 비용도 함께 검토해야 한다.

로봇의 안전성과 프롬프트 공격 문제

로봇 AI에는 일반적인 챗봇과 다른 위험이 존재한다.

예를 들어 텍스트 생성 모델이 잘못된 문장을 작성하면 사용자가 해당 문장을 수정할 수 있다.

반면 실제 로봇이 잘못된 방향으로 움직이면 주변 물체와 충돌하거나 사람에게 위험한 상황을 만들 수 있다.

따라서 로봇의 행동에는 실제 물리적 제약이 필요하다.

Google은 Robotics 2.5에서 주변 사람과 장애물을 고려한 안전한 행동 선택 능력도 개선했다고 설명한다.

또한 ASIMOV-Jailbreak라는 새로운 평가를 소개했다.

이 평가는 로봇 AI가 악의적인 지시나 유도에 얼마나 잘 대응하는지 시험하기 위한 것이다.

Jailbreak(안전장치 우회 공격)는 AI가 원래 따르도록 설계된 안전 규칙을 무시하게 만들려는 공격을 의미한다.

예를 들어 사용자가 로봇에게 안전하지 않은 행동을 지시하는 상황을 시험할 수 있다.

하지만 모델의 안전성 평가 점수가 높다는 사실만으로 실제 로봇의 모든 충돌과 오작동을 예방할 수 있는 것은 아니다.

실제 로봇에서는 별도의 센서와 긴급 정지 장치, 하드웨어 수준의 제어 제한이 필요하다.

현재는 로봇 개발 협력사에 제공

Gemini Robotics 2.5는 발표 시점에 Google의 로봇 개발 협력사를 대상으로 제공이 확대되고 있다.

일반 개발자가 해당 모델의 가중치를 다운로드하거나 모든 로봇에서 바로 실행할 수 있다는 발표는 아니다.

또한 실제로 모델을 사용하는 로봇에는 적절한 카메라와 제어 장치, 실제 동작을 수행할 하드웨어가 필요하다.

이번 연구는 로봇 AI의 발전이 정해진 환경에서 하나의 동작을 반복하는 수준에서 벗어나, 복잡한 물체를 조작하고 새로운 상황에 대응하는 범용적인 행동 능력으로 확대되고 있음을 보여준다.

동시에 실제 산업현장에 적용하려면 모델의 성능뿐 아니라 장비의 신뢰성과 안전성, 운영 비용을 함께 검증해야 한다는 점도 중요하다.

---

Google DeepMind, ‘AlphaProof Code’로 Signal 암호화 코드의 핵심 보안 속성 형식 검증…Lean 증명 코드 600만 줄 이상 생성

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: AI 수학 연구, 소프트웨어 보안, 암호화 프로토콜, 자동 정리 증명, 형식 검증, AI 코딩 에이전트
• 원문: Google DeepMind — Introducing AlphaProof Code: a breakthrough in verifying complex software at depth

Google DeepMind가 AI 에이전트를 이용해 실제 소프트웨어의 보안 속성을 수학적으로 검증하는 새로운 시스템 AlphaProof Code를 공개했다.

이번 연구에서는 Signal 암호화 프로토콜의 핵심 구현 코드가 정해진 보안 속성을 만족하는지 검증했다.

Signal 프로토콜은 Signal 메신저를 포함한 여러 서비스에서 비공개 메시지를 보호하는 데 사용하는 암호화 기술이다.

이번 발표에서 중요한 부분은 프로토콜의 이론적인 설계가 아니라 실제 기기에서 실행되는 코드의 일부까지 검증했다는 점이다.

다만 이번 연구가 Signal 애플리케이션 전체에 보안 문제가 존재하지 않는다는 사실을 증명한 것은 아니다.

검증 대상은 연구팀이 정의한 핵심 암호화 코드와 특정한 보안 속성이다.

일반적인 테스트와 형식 검증의 차이

소프트웨어 개발에서는 일반적으로 테스트를 이용해 오류를 확인한다.

예를 들어 암호화 프로그램에 특정한 메시지를 전달하고 예상한 암호문이 생성되는지 검사할 수 있다.

하지만 입력 가능한 메시지와 시스템의 상태는 매우 다양하다.

모든 가능한 상황을 실제로 실행해 보는 것은 어렵다.

반면 형식 검증(Formal Verification)은 프로그램이 특정한 수학적 조건을 만족하는지 논리적으로 증명하는 방법이다.

예를 들어 암호화 프로토콜에서는 공격자가 일부 정보를 얻더라도 이전에 주고받은 메시지의 내용을 알아내기 어려워야 한다.

또한 특정한 장치가 일시적으로 침해된 뒤 정상적인 상태로 복구됐을 때 이후의 메시지가 다시 보호되는 성질도 중요하다.

이런 보안 속성을 수학적 명제로 표현한 뒤 실제 프로그램이 해당 조건을 만족하는지 검증할 수 있다.

문제는 실제 소프트웨어의 코드가 매우 복잡하다는 점이다.

수학적 명세와 실제 프로그램을 연결하려면 상당한 시간과 전문적인 검토가 필요하다.

AlphaProof Code는 이런 작업의 일부를 AI 에이전트에게 맡긴다.

사람이 검증 목표를 정하고 AI가 증명을 생성

AlphaProof Code는 여러 언어모델을 결합한 에이전트 시스템이다.

연구팀은 먼저 사람이 보안 요구사항을 정의하도록 했다.

이후 AI를 이용해 해당 요구사항을 수학적 명세로 변환했다.

명세(Specification)는 프로그램이 만족해야 하는 조건을 정확하게 표현한 문서다.

예를 들어 어떤 상황에서 메시지의 내용이 외부에 노출되지 않아야 하는지 정의할 수 있다.

Google은 인간 전문가가 이런 명세를 모두 검토했다고 설명한다.

이후 Gemini 4 Carbon 기반의 에이전트들이 실제 증명을 작성했다.

증명에는 Lean이 사용됐다.

Lean은 수학적 명제와 증명 과정을 컴퓨터가 엄밀하게 검사할 수 있도록 하는 언어이자 도구다.

Google에 따르면 에이전트들은 600만 줄 이상의 Lean 코드를 생성했다.

또한 증명 과정에서 추가적인 인간 검토가 필요한 부분을 자동으로 찾아냈다.

Google은 전체 코드 가운데 약 1%를 사람이 추가로 검토하도록 제안했다고 설명했다.

하지만 이 수치는 인간의 판단이 전체 과정에서 1%만 필요했다는 의미가 아니다.

실제로 중요한 보안 명세를 정의하고 검토하는 단계에는 인간 전문가가 참여했다.

실제 실행 코드까지 검증

일반적인 암호화 프로토콜 검증에서는 이론적인 알고리즘이 안전한지 확인할 수 있다.

하지만 실제 프로그램에서는 구현 과정에서 오류가 발생할 수 있다.

예를 들어 수학적으로 안전한 암호화 방식이라도 프로그램의 메모리 처리나 상태 관리에 문제가 존재할 수 있다.

따라서 이론적인 설계가 안전하다는 사실만으로 실제 실행 코드가 안전하다고 판단할 수는 없다.

AlphaProof Code는 실제로 컴파일된 핵심 코드가 정해진 보안 명세를 만족하는지 검사했다.

컴파일(Compilation)은 사람이 작성한 소스코드를 컴퓨터가 실행할 수 있는 형태로 변환하는 과정이다.

Google은 이를 통해 실제 기기에서 실행되는 코드와 보안 명세 사이의 관계를 검증했다고 밝혔다.

연구팀에 따르면 전체 검증에는 약 4주가 필요했다.

기존에는 비슷한 규모의 작업에 전문가들이 수년 동안 참여해야 할 수 있었다고 설명한다.

다만 이 비교는 연구의 규모와 구현 조건에 따라 달라질 수 있다.

AI를 사용한 모든 형식 검증 작업이 같은 비율로 빨라진다는 의미는 아니다.

이미 수정된 실제 버그 두 개를 다시 삽입해 검사

Google은 AlphaProof Code가 올바른 코드만 통과시키는지 확인하기 위해 별도의 실험도 진행했다.

연구팀은 과거에 발견돼 이미 수정된 실제 버그 두 개를 격리된 코드에 다시 삽입했다.

이후 AlphaProof Code를 이용해 해당 구현이 보안 조건을 만족하는지 평가했다.

그 결과 두 사례 모두에서 문제가 존재한다는 사실을 기계적으로 검증할 수 있는 증명을 생성했다.

이는 시스템이 단순히 모든 구현을 안전하다고 판단하는 것이 아니라 잘못된 구현도 구분할 수 있다는 근거다.

하지만 두 가지 버그를 발견했다는 사실만으로 모든 종류의 보안 취약점을 탐지할 수 있다고 판단해서는 안 된다.

또한 어떤 보안 속성을 명세에 포함했는지도 중요하다.

명세에 없는 위험은 증명의 대상에서 제외될 수 있기 때문이다.

형식 증명이 완전한 안전을 의미하지는 않는다

이번 연구를 이해할 때 중요한 부분은 증명의 정확성과 명세의 완전성은 서로 다른 문제라는 점이다.

예를 들어 프로그램이 특정한 보안 조건을 만족한다는 사실을 수학적으로 증명할 수 있다.

하지만 사용자가 실제로 요구한 보안 조건 가운데 일부가 명세에 빠져 있다면 해당 문제는 검증되지 않을 수 있다.

또한 외부 라이브러리나 운영체제, 하드웨어의 동작이 올바르다는 가정이 필요할 수 있다.

따라서 형식 검증이 완료됐다는 사실만으로 소프트웨어 전체에 취약점이 존재하지 않는다고 단정해서는 안 된다.

Signal의 최고기술책임자도 이번 연구가 실제 암호화 구현에 대한 검증 범위를 크게 넓혔다는 점에 의미를 두었다.

이번 발표는 AI가 단순히 새로운 코드를 생성하는 역할에서 벗어나 기존 소프트웨어가 중요한 안전 조건을 실제로 만족하는지 수학적으로 검증하는 역할까지 확대되고 있음을 보여준다.

특히 금융과 의료, 통신처럼 작은 소프트웨어 오류가 큰 피해로 이어질 수 있는 분야에서 주목할 만한 연구다.

---

2️⃣ AI 제품·서비스

OpenAI, ‘Businesses in ChatGPT’ 베타 출시…기업이 직접 정보를 등록하고 고객과 대화하는 비즈니스 에이전트 제공

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: ChatGPT, 기업 프로필, 전자상거래, AI 에이전트, 상품 검색, 광고, 고객지원, 개인정보 보호
• 원문: OpenAI — Introducing Businesses in ChatGPT

OpenAI가 기업이 ChatGPT에서 자사의 정보를 관리하고 고객과 연결될 수 있도록 하는 Businesses in ChatGPT를 베타로 공개했다.

이번 업데이트는 일반적인 ChatGPT 답변 기능의 작은 변경이 아니다.

기업이 ChatGPT 안에서 공식 프로필을 인증하고 상품정보를 제공하며, 별도의 AI 에이전트로 고객과 대화할 수 있는 구조를 도입했다는 점이 핵심이다.

기존에는 사용자가 ChatGPT에서 특정한 기업이나 상품을 검색할 때 웹에 공개된 정보가 활용될 수 있었다.

하지만 웹에 존재하는 정보가 항상 최신 상태인 것은 아니다.

예를 들어 상품의 가격과 재고가 변경됐더라도 검색 결과에 오래된 정보가 남아 있을 수 있다.

또한 기업의 공식 정보와 제3자가 작성한 정보가 혼재할 수 있다.

OpenAI는 이런 문제를 줄이기 위해 기업이 직접 정보를 등록하고 관리하도록 지원한다.

Business Hub에서 공식 기업정보 관리

이번 기능의 중심에는 Business Hub가 있다.

기업은 자신이 실제로 운영하는 조직임을 인증한 뒤 ChatGPT에서 제공되는 기업정보를 관리할 수 있다.

대표적인 기능은 다음과 같다.

Product Feed(상품 피드)는 상품의 이름과 가격, 재고 상태 등의 정보를 일정한 형식으로 제공하는 데이터다.

예를 들어 온라인 쇼핑몰은 여러 상품의 최신 가격과 재고를 제공할 수 있다.

사용자는 ChatGPT에서 상품을 비교할 때 이런 정보를 참고할 수 있다.

OpenAI는 Shopify 판매자가 Business Hub나 Shopify 관리 화면에서 상점 정보를 연결할 수 있도록 지원한다.

다만 기업이 상품정보를 등록했다고 해서 ChatGPT의 모든 답변에 해당 기업의 상품이 반드시 나타나는 것은 아니다.

또한 등록한 정보가 모든 종류의 질문에서 항상 정확하게 활용된다는 보장도 없다.

기업은 집계된 이용 통계를 확인

Business Hub는 ChatGPT 안에서 기업이 얼마나 언급되는지 확인할 수 있는 기능도 제공한다.

예를 들어 특정한 기업의 이름이 모델의 답변에 등장한 횟수를 확인할 수 있다.

또한 사용자가 해당 기업의 웹사이트를 클릭한 횟수도 집계할 수 있다.

기업의 웹사이트가 인용된 대화에서 어떤 주제가 자주 등장하는지도 분석할 수 있다.

하지만 이번 기능이 사용자의 실제 대화 내용을 기업에 그대로 제공하는 것은 아니다.

OpenAI는 개인의 ChatGPT 대화나 Business Agent 대화를 해당 기업에 공유하지 않는다고 밝혔다.

제공하는 통계는 여러 대화와 상호작용을 집계한 결과다.

또한 충분한 수의 상호작용이 존재하는 경우에만 관련 통계를 제공하도록 제한한다.

이런 방식은 기업이 사용자들의 관심사를 이해하도록 지원하면서도 개별 대화의 개인정보가 노출되는 문제를 줄이기 위한 것이다.

다만 실제 집계 기준과 개인정보 처리 조건은 관련 정책을 통해 확인해야 한다.

Business Agent는 일반 ChatGPT 답변과 분리

이번 발표의 중요한 기능은 Business Agent다.

기업은 자사의 상품과 서비스를 설명하는 AI 에이전트를 만들 수 있다.

예를 들어 사용자가 ChatGPT에서 여러 상품을 비교한다고 가정해 보자.

사용자는 특정한 기업의 프로필을 선택할 수 있다.

해당 기업에 Business Agent가 존재한다면 별도의 대화를 시작해 상품에 관해 질문할 수 있다.

이 에이전트는 기업이 제공한 정보를 바탕으로 상품의 특징과 서비스 내용을 설명하도록 구성된다.

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

Business Agent는 ChatGPT의 독립적인 답변과 구분되는 기업 전용 대화 서비스다.

OpenAI는 Business Agent의 대화를 별도로 표시한다고 설명했다.

또한 기업은 자신의 Business Agent를 광고의 연결 대상으로 사용할 수 있다.

이 경우 광고와 후원된 배치는 명확하게 표시되며 ChatGPT의 일반 답변과 구분된다.

따라서 기업이 운영하는 에이전트가 제공한 설명과 일반적인 AI의 독립적인 비교 결과를 같은 것으로 이해해서는 안 된다.

제공 범위는 기업 인증과 Business Agent가 다르다

이번 발표에서는 두 기능의 이용 범위를 구분해야 한다.

Business Hub의 기업 인증은 ChatGPT가 제공되는 지역의 자격을 갖춘 기업을 대상으로 한다.

반면 Business Agent의 초기 제공 대상은 미국의 일부 전자상거래 및 온라인 서비스 기업이다.

따라서 한국 기업이 Business Hub에서 기업정보를 인증할 수 있다는 사실만으로 Business Agent도 즉시 개설할 수 있다고 판단해서는 안 된다.

OpenAI는 향후 더 많은 국가와 기업 유형으로 제공 범위를 확대할 계획이라고 밝혔다.

이번 발표는 생성형 AI가 단순한 정보 검색 도구에서 벗어나 기업과 소비자가 직접 연결되는 새로운 온라인 서비스 공간으로 확대되고 있음을 보여준다.

동시에 기업이 제공하는 정보와 광고, 독립적인 검색 결과를 명확하게 구분하는 일이 중요해지고 있다.

---

Google Cloud, 의료 전용 ‘Gemini for Healthcare’ 프리뷰 출시…진료기록·보험·청구 데이터를 연결해 행정 업무 수행

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: 의료 AI, 기업용 AI 에이전트, 전자의무기록, 의료보험, 청구 업무, 의료 데이터 거버넌스
• 원문: Google Cloud — Google Cloud Launches Gemini for Healthcare

Google Cloud가 의료기관과 보험기관을 위한 AI 에이전트 솔루션 Gemini for Healthcare를 프리뷰로 공개했다.

이번 기능은 새로운 의료 진단 모델 하나를 제공하는 방식이 아니다.

병원과 보험기관에 분산된 여러 데이터 시스템을 연결해 복잡한 행정·운영 업무를 처리하도록 설계된 전문 AI 에이전트다.

병원에서 하나의 업무를 처리하려면 여러 프로그램을 사용해야 하는 경우가 많다.

예를 들어 환자의 진료기록을 확인해야 할 수 있다.

이후 보험 적용 조건과 관련된 자료를 검토해야 한다.

또한 비용 청구에 필요한 문서를 작성해야 할 수도 있다.

이런 정보가 서로 다른 시스템에 저장돼 있다면 담당자가 여러 프로그램을 오가며 자료를 확인해야 한다.

Google은 이런 반복적인 업무를 AI 에이전트가 지원하도록 만들었다.

의료 분야의 전문적인 데이터 연결

Gemini for Healthcare는 기존 Gemini 에이전트를 기반으로 개발됐다.

여기에 의료 분야의 전문 기능과 데이터 연결을 추가했다.

주요 데이터 출처는 다음과 같다.

EHR(Electronic Health Record)은 환자의 진료기록을 전자적으로 관리하는 시스템이다.

여기에는 진단과 처방, 검사 결과와 과거 진료 내역 등이 포함될 수 있다.

CMS(Centers for Medicare & Medicaid Services)는 미국의 주요 공공의료보험 프로그램을 관리하는 기관이다.

Gemini for Healthcare는 이런 자료를 연결해 필요한 정보를 분석하도록 설계됐다.

예를 들어 특정한 치료에 보험 적용이 가능한지 검토하려면 환자의 실제 진료기록과 보험사의 지급 기준을 함께 확인해야 할 수 있다.

AI 에이전트는 필요한 자료를 찾아 검토할 수 있다.

하지만 실제 보험 적용 여부는 관련 규정과 계약, 환자의 구체적인 상황에 따라 결정된다.

따라서 AI가 생성한 설명을 공식적인 보험 승인 결정과 동일하게 취급해서는 안 된다.

정보를 요약하는 것에서 실제 업무 단계로 확대

일반적인 RAG 기반 AI 시스템은 외부 문서를 검색한 뒤 답변을 생성한다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 자료에서 관련 정보를 가져와 언어모델의 입력에 추가하는 기술이다.

예를 들어 사용자가 환자의 기존 진료기록을 요약하도록 요청할 수 있다.

하지만 Gemini for Healthcare는 단순한 요약을 넘어 여러 단계의 업무를 수행하도록 설계됐다.

예를 들어 관련 기록을 확인한 뒤 보험 심사에 필요한 자료를 정리하는 작업을 생각할 수 있다.

또한 서로 다른 시스템에 저장된 정보를 결합해 필요한 다음 단계를 제안할 수 있다.

Google은 이를 위해 외부 데이터 연결과 전문적인 Agent Skill을 제공한다.

Agent Skill(에이전트 스킬)은 특정 업무를 수행하는 데 필요한 지침과 도구 사용 방법을 묶은 기능이다.

다만 모든 의료기관에서 동일한 종류의 업무를 즉시 자동화할 수 있다는 의미는 아니다.

실제 데이터의 구조와 연결 가능한 시스템, 관련 규정에 따라 지원 범위가 달라질 수 있다.

의료 데이터의 접근권한과 인간 검토

의료 데이터는 매우 민감한 개인정보를 포함한다.

예를 들어 환자의 진단과 처방, 검사 결과가 포함될 수 있다.

따라서 의료기관의 모든 직원이 모든 환자의 정보를 자유롭게 조회해서는 안 된다.

Google은 Gemini for Healthcare가 정해진 접근권한과 업무 규칙 안에서 실행되도록 설계했다고 밝혔다.

또한 중요한 업무에는 적절한 인간 감독이 포함된다고 설명한다.

이를 Human-in-the-Loop(인간 검토가 포함된 실행 구조)이라고 한다.

예를 들어 AI가 보험 심사에 필요한 자료를 준비할 수 있다.

하지만 실제로 승인이나 거부와 같이 환자에게 영향을 주는 결정은 적절한 담당자가 검토하도록 구성할 수 있다.

이번 발표는 AI가 의료진을 대신해 진단과 치료를 자율적으로 결정하도록 허용했다는 의미가 아니다.

초기 협력기관과 제공 상태

Google은 다음 의료기관과 보험 관련 조직을 초기 고객 또는 협력기관으로 소개했다.

• Blue Cross Blue Shield of Massachusetts
• Hartford HealthCare
• HCA Healthcare
• Highmark Health
• Northwell Health
• Optum
• Stanford School of Medicine

또한 American Society of Clinical Oncology(ASCO) 등과 협력하고 있다고 밝혔다.

다만 이들 기관이 모두 동일한 기능을 실제 운영환경 전체에 배포했다는 의미는 아니다.

기관별 도입 단계와 사용 범위는 다를 수 있다.

Gemini for Healthcare는 발표 시점에 프리뷰 단계다.

또한 Google은 의료진이 행정 업무에 상당한 시간을 사용한다는 기존 조사 결과를 소개했지만, 새로운 서비스 자체가 실제로 업무시간을 몇 퍼센트 줄였는지에 관한 독립적인 운영 수치는 제시하지 않았다.

이번 발표는 의료 AI의 활용이 단순한 진단 보조와 문서 요약에서 벗어나 여러 의료정보 시스템을 연결해 실제 행정 업무를 처리하는 에이전트로 확대되고 있음을 보여준다.

다만 의료 분야에서는 효율성뿐 아니라 개인정보 보호와 실제 업무의 정확성, 중요한 결정에 대한 인간의 통제가 함께 검증돼야 한다.

---

Adobe MAX 2026, Photoshop·Premiere·Firefly의 생성형 AI 작업 환경 확대…다중 모델 활용과 편집 가능한 결과물에 집중

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 이미지·영상 AI, Photoshop, Premiere, Illustrator, Adobe Firefly, AI 에이전트, MCP, 창작 도구
• 원문: Adobe — Explore new ways to create across Creative Cloud and Adobe Firefly

Adobe가 Adobe MAX 2026에서 Creative Cloud와 Firefly의 AI 기능을 대규모로 확대했다.

이번 발표의 핵심은 단순히 이미지와 영상을 더 많이 생성할 수 있게 됐다는 사실이 아니다.

AI가 생성한 결과물을 기존 전문 편집 도구에서 계속 수정할 수 있도록 하고, 여러 생성형 AI 모델을 하나의 실제 제작 과정에 연결하는 방향으로 기능을 확장했다는 점이다.

일반적인 이미지 생성 AI에서는 사용자가 프롬프트를 입력하면 새로운 이미지가 생성된다.

하지만 실제 디자인 작업에서는 생성한 이미지의 일부만 수정해야 하는 경우가 많다.

예를 들어 광고 이미지의 조명을 바꾸고 싶을 수 있다.

또는 배경은 유지하면서 상품의 위치만 변경하고 싶을 수도 있다.

이런 상황에서 전체 이미지를 매번 새로 생성하면 원래 유지하고 싶었던 부분까지 달라질 수 있다.

Adobe는 이런 문제를 줄이기 위해 기존의 편집 도구와 AI를 더 깊게 연결했다.

Photoshop: AI로 생성한 결과를 세밀하게 수정

이번 업데이트에서 Photoshop에는 Relight와 Generative Restyle 같은 기능이 추가됐다.

Relight는 이미지 안에 새로운 광원을 추가하거나 기존 조명의 느낌을 변경하는 기능이다.

사용자는 조명의 위치와 색상, 밝기를 조절할 수 있다.

예를 들어 인물 사진의 얼굴이 너무 어둡다면 조명의 방향을 변경하도록 요청할 수 있다.

중요한 점은 결과를 실제 편집 가능한 형태로 제공한다는 것이다.

Adobe는 이를 비파괴 편집(Non-Destructive Editing)이라고 설명한다.

비파괴 편집은 원본 이미지를 직접 훼손하지 않고 별도의 조정값이나 레이어를 이용해 수정하는 방법이다.

Generative Restyle은 사용자의 자연어 설명을 바탕으로 이미지의 스타일을 변경한다.

하지만 이후 스타일의 강도를 조절하기 위해 전체 프롬프트를 다시 작성할 필요를 줄였다.

생성한 결과를 레이어로 변환하고 슬라이더를 이용해 효과의 강도를 조절할 수 있다.

또한 Photoshop 베타에는 새로운 카메라 시점과 이미지 구성을 탐색하는 기능도 추가됐다.

하지만 2D 이미지에서 다른 시점을 생성하는 과정에서는 원래 사진에 존재하지 않던 부분을 AI가 추정해야 할 수 있다.

따라서 생성된 결과가 실제 물체의 정확한 구조를 보존한다는 보장은 없다.

Premiere: 영상 타임라인에서 생성형 AI 사용

Adobe는 Premiere에 생성형 미디어 도구를 직접 통합했다.

대표적인 기능은 다음과 같다.

타임라인(Timeline)은 영상과 소리를 시간 순서대로 배치해 편집하는 작업 영역이다.

기존에는 AI로 생성한 영상을 다운로드한 뒤 다시 편집 프로그램에 가져와야 할 수 있었다.

반면 이번 기능에서는 Premiere의 타임라인 안에서 필요한 영상을 생성하고 수정할 수 있다.

또한 Adobe Firefly뿐 아니라 Google과 Kling, Runway, Luma 등의 모델을 선택할 수 있다.

이렇게 하면 하나의 영상 제작 과정에서 서로 다른 생성형 모델을 사용할 수 있다.

다만 모델마다 입력 형식과 가격, 사용 조건이 다를 수 있다.

또한 여러 모델을 연결했다고 해서 실제 결과물의 품질이 항상 개선되는 것은 아니다.

Generative Remove: 영상에서 물체 제거

이번 발표의 중요한 기능 가운데 하나는 Generative Remove다.

이 기능은 Premiere에서 베타로 제공된다.

예를 들어 촬영한 영상에 원하지 않는 마이크나 로고, 배경의 물체가 등장할 수 있다.

사용자는 제거할 물체를 선택하고 해당 영역을 추적할 수 있다.

이후 생성형 AI가 해당 물체가 없어진 공간을 채우도록 만든다.

이 과정에는 Inpainting(인페인팅)과 비슷한 기술이 사용된다.

인페인팅은 이미지나 영상에서 지정한 영역을 주변의 정보와 조화롭게 다시 생성하는 기술이다.

하지만 실제 영상에서는 카메라가 움직이고 조명도 변할 수 있다.

따라서 하나의 프레임에서 자연스럽게 보이는 결과가 전체 영상에서도 일관되게 유지된다는 보장은 없다.

특히 움직이는 물체와 복잡한 배경에서는 프레임 사이의 연결을 확인해야 한다.

Firefly Design·Graph·Builder의 역할 분리

Adobe는 Firefly의 기능도 여러 방향으로 확대했다.

Firefly Design은 여러 종류의 디자인 자료를 하나의 작업 공간에서 관리하도록 지원한다.

Firefly Graph는 여러 모델과 도구를 연결해 반복 가능한 제작 과정을 만드는 기능이다.

예를 들어 하나의 상품 사진을 이용해 여러 크기의 광고 이미지를 만들 수 있다.

이후 각각의 이미지에 정해진 브랜드 스타일을 적용하도록 구성할 수 있다.

이런 작업을 매번 수동으로 반복하는 대신 하나의 작업 흐름으로 저장하고 재사용할 수 있다.

이를 Workflow(워크플로)라고 한다.

Firefly Builder는 자연어 설명으로 실제 작동하는 웹사이트나 앱의 시제품을 만드는 기능이다.

하지만 발표 시점에는 비공개 베타이므로 모든 사용자가 즉시 사용할 수 있는 기능이 아니다.

Adobe Creative Agent와 MCP 통합

Adobe는 AI Assistant의 베타 제공 범위도 확대했다.

Premiere와 Illustrator, InDesign, After Effects와 Frame.io 등에서 자연어를 이용해 여러 단계의 작업을 수행하도록 지원할 계획이다.

또한 MCP(Model Context Protocol)를 이용해 외부 AI 에이전트가 Adobe 도구를 호출하는 통합 기능도 소개했다.

MCP는 AI 에이전트가 외부 프로그램과 데이터를 호출하도록 하는 통신 규격이다.

예를 들어 사용자가 자신의 AI 에이전트에게 광고 이미지의 로고를 변경하도록 요청할 수 있다.

에이전트는 Photoshop을 호출해 실제 이미지 파일을 수정할 수 있다.

중요한 점은 결과물이 Adobe의 기존 편집 가능한 파일 형태로 유지되도록 설계했다는 것이다.

하지만 Creative Cloud의 MCP 통합은 2027년 초 제공 예정이다.

11월 10일 발표 시점에 모든 Creative Cloud 사용자가 외부 에이전트 연결을 즉시 사용할 수 있다는 의미는 아니다.

이번 발표는 생성형 AI가 창작자의 작업을 모두 대신하는 방식에서 벗어나 기존 전문 도구 안에서 결과를 생성하고, 사람이 세밀하게 수정하며, 반복적인 작업을 에이전트에 맡기는 방식으로 발전하고 있음을 보여준다.

---

Meta, Facebook의 ‘Your Algorithm’ 추천 시스템 기술 공개…사용자가 관심사를 직접 수정하고 피드·릴스에 반영

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: Facebook, 추천 알고리즘, 대형 언어모델, 개인화, 피드·릴스, 사용자 제어
• 원문: Meta Engineering — Your Algorithm: Giving People More Ways to Personalize Facebook Recommendations

Meta가 Facebook의 개인화 추천 기능인 Your Algorithm의 실제 기술 구조를 공개했다.

이번 발표는 추천 시스템이라는 기술이 새롭게 등장했다는 의미가 아니다.

사용자가 자연어로 관심사를 직접 수정하면 AI가 해당 내용을 해석하고 피드와 릴스의 추천 결과에 반영하는 과정을 구체적으로 설명했다는 점이 중요하다.

기존의 소셜미디어 추천 시스템은 사용자의 행동을 관찰해 관심사를 추정하는 경우가 많았다.

예를 들어 사용자가 클라이밍 영상을 자주 시청하면 클라이밍 관련 콘텐츠를 더 많이 추천할 수 있다.

하지만 사용자가 특정한 영상을 클릭했다는 사실만으로 해당 주제에 장기적인 관심이 있다고 판단하기는 어렵다.

또한 사용자는 어떤 콘텐츠가 왜 추천되는지 이해하기 어려울 수 있다.

Meta는 이런 문제를 줄이기 위해 사용자가 자신의 관심사를 직접 수정할 수 있는 기능을 제공한다.

관심 있음과 관심 없음 목록

Your Algorithm에는 크게 세 가지 정보가 표시된다.

첫 번째는 Lately Summary다.

최근 사용자의 활동을 바탕으로 관심사를 한 문장으로 요약한다.

두 번째는 Interested In이다.

사용자가 관심 있는 주제를 관리하는 목록이다.

세 번째는 Not Interested In이다.

사용자가 추천받고 싶지 않은 주제를 관리하는 목록이다.

예를 들어 사용자가 클라이밍과 요리에 관심이 있다면 관련 주제를 추가할 수 있다.

반대로 특정한 콘텐츠를 보고 싶지 않다면 관심 없음 목록에 추가할 수 있다.

Meta는 이 정보를 Facebook의 피드와 릴스에 공통으로 적용하도록 설계했다.

중요한 점은 단순한 키워드 일치만 사용하는 것이 아니라는 사실이다.

LLM(Large Language Model, 대형 언어모델)이 사용자가 입력한 자연어의 의미를 분석하고 추천 시스템이 사용할 수 있는 형태로 변환한다.

관심사를 추가하면 추천 후보부터 변경

일반적인 추천 시스템에는 여러 단계가 존재한다.

먼저 사용자에게 보여줄 만한 콘텐츠 후보를 수집한다.

이후 각 후보의 관련성을 평가하고 최종 표시 순서를 결정한다.

이런 과정을 Ranking Pipeline(순위 결정 파이프라인)이라고 한다.

예를 들어 사용자가 이전에 캠핑 콘텐츠를 거의 보지 않았다고 가정해 보자.

갑자기 캠핑에 관심이 생겼더라도 기존 추천 시스템에는 관련 후보가 충분하지 않을 수 있다.

Meta는 사용자가 관심사를 추가하면 해당 주제와 관련된 콘텐츠를 별도로 검색하도록 구성했다.

이 과정에서는 검색과 주제의 유사성, 콘텐츠 사이의 연결 관계 등을 활용한다.

이후 관련 후보가 최종 추천 단계까지 전달될 수 있도록 한다.

하지만 관심사를 추가했다고 해서 피드 전체가 해당 콘텐츠로 채워지는 것은 아니다.

Meta는 같은 관심사에 관한 추천이 지나치게 많이 등장하지 않도록 제한을 적용한다.

또한 새로운 관심사에는 일시적으로 높은 가중치를 부여한 뒤 실제 사용자의 반응에 따라 조정하도록 설계했다.

관심 없는 콘텐츠는 여러 단계에서 제거

사용자가 특정한 주제를 관심 없음 목록에 추가하면 다른 처리가 필요하다.

단순히 해당 단어가 포함된 콘텐츠만 제거하면 충분하지 않을 수 있다.

예를 들어 사용자가 특정한 스포츠에 관한 콘텐츠를 원하지 않는다고 가정해 보자.

실제 콘텐츠에는 스포츠의 이름이 직접 등장하지 않을 수도 있다.

하지만 이미지와 영상의 내용은 해당 스포츠와 관련돼 있을 수 있다.

Meta는 이를 해결하기 위해 임베딩(Embedding)을 사용한다.

임베딩은 문장이나 이미지 등의 의미를 여러 숫자로 표현하는 기술이다.

의미가 비슷한 콘텐츠를 찾는 데 사용할 수 있다.

또한 추천 후보의 최종 목록을 작은 전문 언어모델이 다시 검사한다.

이렇게 하면 초기 추천 단계에서 놓친 관련 콘텐츠를 추가로 제거할 수 있다.

하지만 의미 기반 분류가 완벽한 것은 아니다.

예를 들어 풍자나 비유처럼 문맥에 따라 의미가 달라지는 콘텐츠에서는 판단 오류가 발생할 수 있다.

따라서 관심 없음 목록에 추가한 모든 콘텐츠가 반드시 100% 제거된다는 의미는 아니다.

이미 스마트폰에 저장된 추천 목록도 갱신

이번 글에서 흥미로운 부분은 캐시(Cache)에 대한 처리다.

캐시는 이전에 계산한 결과를 저장해 다시 사용하는 기술이다.

Facebook 앱은 사용자가 다음에 볼 콘텐츠 일부를 미리 받아둘 수 있다.

이렇게 하면 사용자가 스크롤할 때 새로운 콘텐츠가 빠르게 나타날 수 있다.

하지만 사용자가 관심사를 변경한 뒤에도 이미 저장된 추천 목록이 남아 있을 수 있다.

이 경우 추천 시스템에서 새 설정을 적용했더라도 사용자는 이전 추천 결과를 계속 볼 수 있다.

Meta는 이를 해결하기 위해 새로운 관심사를 추가하면 관련 콘텐츠를 추가로 가져오는 요청을 수행하도록 했다.

반대로 관심 없음 목록에 주제를 추가하면 스마트폰에 저장된 후보 가운데 관련 콘텐츠도 제거하도록 구성했다.

이를 Cache Invalidation(캐시 무효화)이라고 한다.

이번 발표는 추천 시스템이 사용자의 행동을 조용히 관찰하는 방식에서 벗어나 사용자가 원하는 콘텐츠를 직접 설명하고 추천 결과를 조정할 수 있도록 만드는 방향으로 발전하고 있음을 보여준다.

다만 실제로 추천의 다양성과 사용자 만족도가 얼마나 개선됐는지는 별도의 평가가 필요하다.

---

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

NVIDIA, AI 에이전트 보안용 ‘OpenShell’을 CNCF에 기증…Kubernetes 관리·추론 복원 도구도 오픈소스로 확대

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: AI 에이전트 보안, Kubernetes, NVIDIA GPU, 오픈소스, 클라우드 인프라, AI 추론, 장애 복구
• 원문: NVIDIA — NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure

NVIDIA가 KubeCon에서 AI 에이전트와 대규모 AI 인프라를 위한 여러 오픈소스 프로젝트의 제공 범위를 확대했다.

이번 발표에서 중요한 변화는 세 가지다.

첫 번째는 AI 에이전트의 실행 행동을 통제하는 OpenShell을 CNCF에 기증한다는 것이다.

두 번째는 GPU 인프라에서 Kubernetes를 운영하기 위한 NVIDIA Kubernetes Engine과 NVIDIA Kubernetes Recipes의 공개 프리뷰다.

세 번째는 AI 추론 서버를 빠르게 복원하기 위한 NVIDIA Snapshot의 공개다.

이와 함께 NVIDIA는 이미 공개된 Google의 Agent Substrate와 연동하는 작업도 발표했다.

다만 Agent Substrate 자체가 이번에 처음 공개됐다는 의미는 아니다.

새로운 내용은 NVIDIA의 보안·추론·스케줄링 기술과 연동을 확대한다는 점이다.

OpenShell: AI 에이전트의 실제 실행 권한 관리

AI 에이전트는 일반적인 챗봇보다 많은 행동을 수행할 수 있다.

예를 들어 파일을 읽고 수정할 수 있다.

외부 API를 호출하거나 터미널에서 명령을 실행할 수도 있다.

문제는 모델이 어떤 행동을 수행해야 하는지 잘못 판단할 가능성이 있다는 점이다.

예를 들어 사용자가 특정한 프로젝트의 코드를 분석하도록 요청했다고 가정해 보자.

에이전트가 관련 파일을 읽는 것은 정상적인 행동이다.

하지만 해당 프로젝트와 관계없는 시스템 파일이나 인증정보까지 읽으려 한다면 문제가 발생할 수 있다.

OpenShell은 이런 행동을 실제 실행 단계에서 제한하도록 설계됐다.

Runtime Policy(실행 시점 정책)는 프로그램이 실제 행동을 수행하려 할 때 해당 행동이 허용되는지 검사하는 규칙이다.

예를 들어 특정한 디렉터리만 읽도록 허용할 수 있다.

외부 네트워크에 접근할 수 있는 주소도 제한할 수 있다.

또한 사용 가능한 인증정보와 도구 호출 범위를 관리할 수 있다.

중요한 점은 에이전트에게 안전하게 행동하라고 설명하는 것과 실제 실행 환경에서 권한을 제한하는 것은 다르다는 사실이다.

언어모델이 잘못된 행동을 제안하더라도 실제 실행 프로그램이 해당 행동을 차단할 수 있어야 한다.

OpenShell은 이런 통제 기능을 제공한다.

CNCF Sandbox로 개발 거버넌스 확대

NVIDIA는 OpenShell을 CNCF(Cloud Native Computing Foundation)에 기증한다고 밝혔다.

CNCF는 Kubernetes를 포함한 여러 클라우드 네이티브 기술의 오픈소스 개발을 지원하는 재단이다.

OpenShell은 CNCF Sandbox 프로젝트로 관리된다.

이는 특정 기업이 독점적으로 개발 방향을 결정하는 구조에서 벗어나 여러 조직이 개발과 검토에 참여할 수 있도록 하는 변화다.

하지만 CNCF Sandbox에 포함됐다는 사실만으로 모든 기업용 환경에서 해당 기술의 보안성이 완벽하게 검증됐다는 의미는 아니다.

Sandbox는 프로젝트가 커뮤니티 중심으로 발전하는 초기 단계에 해당한다.

NVIDIA는 OpenShell이 다른 컴퓨팅 인프라와 모델 제공업체, 인증정보 저장소와 모니터링 시스템을 연결할 수 있도록 설계됐다고 설명한다.

따라서 특정한 모델 하나에만 의존하지 않고 여러 에이전트 실행 환경에 같은 종류의 보안 정책을 적용할 가능성이 있다.

NVIDIA Kubernetes Engine과 Recipes

이번에 새롭게 공개 프리뷰로 제공되는 기술에는 다음이 포함된다.

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

대규모 AI 서비스에서는 여러 GPU 서버에 모델을 배포해야 할 수 있다.

또한 서버의 상태를 확인하고 장애가 발생했을 때 새로운 실행 환경을 준비해야 한다.

NVIDIA Kubernetes Engine은 이런 클러스터의 생성과 관리 과정을 지원한다.

NVIDIA Kubernetes Recipes는 필요한 소프트웨어 버전과 실행 설정을 함께 관리하도록 돕는다.

예를 들어 GPU 드라이버와 Kubernetes 구성요소의 버전이 서로 호환돼야 할 수 있다.

검증된 실행 구성을 제공하면 개별 조직이 이런 조합을 처음부터 시험하는 부담을 줄일 수 있다.

하지만 제공된 레시피를 사용한다고 해서 모든 하드웨어와 실제 작업에서 최적의 성능이 보장되는 것은 아니다.

실제 운영환경에서는 네트워크와 저장장치, 모델의 종류에 따라 추가적인 조정이 필요할 수 있다.

NVIDIA Snapshot: 모델을 다시 읽는 시간 감소

대형 언어모델을 서비스에 배포할 때는 모델의 가중치를 GPU 메모리에 불러와야 한다.

가중치(Weights)는 AI 모델이 학습한 파라미터를 저장한 숫자 데이터다.

대형 모델에서는 가중치의 크기가 상당할 수 있다.

따라서 새로운 추론 서버를 시작할 때 모델을 읽는 과정만으로도 수분이 필요할 수 있다.

또한 실제 요청을 받기 전에 초기 계산을 수행하는 Warmup(예열) 과정이 필요할 수 있다.

NVIDIA Snapshot은 이런 준비가 완료된 실행 환경의 상태를 저장하고 나중에 복원하도록 설계됐다.

예를 들어 이전에 실행했던 모델의 준비된 상태를 저장할 수 있다.

새로운 추론 서버가 필요할 때 해당 상태를 복원하면 모델을 처음부터 다시 읽는 부담을 줄일 수 있다.

이런 방식은 실제 트래픽이 급격하게 증가하는 상황에서 유용할 수 있다.

실제 협력기업의 복원 시간 비교

NVIDIA는 협력기업인 Crusoe와 Saturn Cloud의 자체 평가 결과를 공개했다.

Crusoe는 NVIDIA HGX B300 시스템에서 GLM-5.3 모델을 사용했다.

Saturn Cloud는 vLLM 기반 추론 환경의 시작 시간을 측정했다.

vLLM은 대형 언어모델의 추론을 효율적으로 실행하기 위한 오픈소스 도구다.

이런 결과는 AI 모델의 시작과 복구에 필요한 시간을 크게 줄일 가능성을 보여준다.

하지만 이는 각 기업이 정한 특정한 환경에서 측정한 결과다.

모든 모델에서 시작 시간이 31초 이하로 감소한다는 의미는 아니다.

또한 스냅샷을 생성하고 저장하는 데 필요한 추가적인 자원과 비용도 고려해야 한다.

이번 발표는 AI 에이전트와 추론 서비스를 대규모로 운영할 때 모델의 계산 성능뿐 아니라 실행 권한과 클러스터 관리, 장애 복구와 준비시간이 중요한 기술적 과제가 되고 있음을 보여준다.

---

Meta, GPU 프로그래밍용 오픈소스 ‘TLX’ 공개…Triton의 개발 편의성과 GPU 하드웨어 제어를 결합

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: GPU 컴파일러, 오픈소스, Triton, CUDA, AI 모델 학습, 추천 시스템, LLM 인프라, 하드웨어 최적화
• 원문: Meta Engineering — How We Built TLX: A Hardware-Native GPU Compiler for Production ML at Scale

Meta가 GPU 프로그램을 효율적으로 작성하기 위한 오픈소스 기술 TLX(Triton Low-Level Extensions)를 공개했다.

이번 발표는 새로운 AI 모델의 출시가 아니다.

AI 모델을 실행할 때 사용하는 GPU 프로그램을 더 효율적으로 작성하고, 실제 하드웨어의 고급 기능을 활용하기 위한 컴파일러 확장 기술이다.

최근 대형 AI 모델은 GPU에서 많은 계산을 수행한다.

하지만 GPU의 이론적인 계산 성능이 높다고 해서 실제 프로그램이 모든 성능을 활용할 수 있는 것은 아니다.

예를 들어 AI 모델이 행렬을 계산할 때 GPU가 데이터를 기다리는 시간이 발생할 수 있다.

또한 여러 작은 계산을 따로 실행하면 중간 결과를 메모리에 저장하고 다시 읽는 과정에서 비용이 발생할 수 있다.

TLX는 이런 문제를 줄이기 위해 설계됐다.

Triton과 CUDA의 장단점

AI 모델의 GPU 프로그램을 작성할 때는 여러 기술을 사용할 수 있다.

대표적인 것이 CUDA와 Triton이다.

CUDA는 NVIDIA GPU에서 병렬 프로그램을 작성하기 위한 플랫폼이다.

개발자는 GPU의 실제 하드웨어 동작을 세밀하게 제어할 수 있다.

하지만 복잡한 최적화를 수행하려면 GPU 내부 구조에 관한 높은 수준의 지식이 필요할 수 있다.

반면 Triton은 상대적으로 간결한 Python 기반 문법으로 GPU 계산을 작성하도록 지원한다.

예를 들어 행렬 곱셈이나 Attention 계산을 비교적 짧은 코드로 구현할 수 있다.

하지만 GPU의 새로운 하드웨어 기능을 세밀하게 제어하려면 추가적인 저수준 기능이 필요할 수 있다.

Meta는 이런 두 방식 사이의 간극을 줄이기 위해 TLX를 개발했다.

Triton의 개발 편의성을 유지하면서 실제 GPU의 실행 순서와 메모리 이동을 더 명확하게 제어하도록 만든 것이다.

Warp Group 단위로 역할 분리

GPU는 많은 계산을 병렬로 수행한다.

이때 여러 스레드를 묶어 실행하는 단위를 Warp(워프)라고 한다.

스레드는 프로그램의 작은 실행 단위다.

최신 GPU에서는 여러 워프를 하나의 그룹으로 묶어 계산과 데이터 이동을 조정할 수 있다.

TLX는 이런 Warp Group에 명확한 역할을 부여하도록 지원한다.

예를 들어 다음과 같이 구성할 수 있다.

기존의 단순한 실행 방식에서는 데이터를 읽은 뒤 계산하고 결과를 저장하는 과정이 순서대로 진행될 수 있다.

반면 TLX에서는 데이터 이동과 계산을 일부 겹쳐 실행할 수 있다.

이를 Pipelining(파이프라이닝)이라고 한다.

여러 처리 단계를 서로 겹쳐 실행해 전체 처리시간을 줄이는 방법이다.

예를 들어 첫 번째 데이터의 행렬 계산을 수행하는 동안 두 번째 데이터를 미리 읽을 수 있다.

이렇게 하면 GPU가 데이터 이동을 기다리는 시간을 줄일 가능성이 있다.

데이터 이동과 계산의 동기화

TLX는 Warp Group 사이의 작업 순서를 관리하기 위해 하드웨어 수준의 동기화 기능을 제공한다.

예를 들어 데이터를 이동하는 그룹이 아직 필요한 데이터를 모두 준비하지 않았다고 가정해 보자.

이 상황에서 계산 그룹이 먼저 실행되면 잘못된 결과가 발생할 수 있다.

따라서 특정한 데이터 이동이 끝났다는 사실을 다른 그룹에 알려야 한다.

TLX는 이런 작업에 Barrier(배리어)라는 동기화 기능을 사용한다.

배리어는 필요한 조건이 충족될 때까지 일부 작업을 기다리도록 하는 장치다.

또한 TLX는 GPU의 메모리 구조와 비동기 텐서 계산 기능을 직접 활용할 수 있도록 지원한다.

Tensor(텐서)는 여러 차원의 숫자 데이터를 표현하는 자료구조다.

AI 모델에서는 행렬과 텐서에 관한 계산이 매우 많이 사용된다.

이런 계산을 효율적으로 처리하면 실제 모델의 학습과 추론 성능에도 영향을 줄 수 있다.

Meta의 실제 광고·추천 시스템에서 사용

Meta는 TLX를 단순한 실험용 기술로 공개한 것이 아니다.

이미 몇 달 동안 실제 머신러닝 인프라에서 사용해 왔다고 설명한다.

대표적인 적용 분야는 세 가지다.

첫 번째는 광고 생성·추천 모델인 GEM의 학습이다.

두 번째는 일반적인 추천 시스템의 추론이다.

세 번째는 대규모 언어모델의 사전학습이다.

Meta는 일부 Attention 관련 커널에서 TLX를 이용해 최대 두 배의 순전파 속도 개선을 기록했다고 밝혔다.

순전파(Forward Pass)는 입력 데이터를 모델에 전달해 실제 출력과 중간 계산을 수행하는 과정이다.

하지만 특정 커널의 순전파 속도가 두 배 빨라졌다는 사실이 전체 AI 모델의 학습시간이 절반으로 줄어든다는 의미는 아니다.

실제 학습에는 다른 계산과 데이터 이동, GPU 사이의 통신도 포함된다.

Meta는 추천 시스템의 특정 계산에서도 중복된 데이터 복사를 제거하는 방식을 적용했다.

예를 들어 하나의 사용자를 여러 광고 후보와 비교할 때 같은 사용자 정보를 반복해서 복사할 수 있다.

TLX를 이용하면 이런 중복 데이터를 별도로 생성하지 않고 실제 계산 안에서 처리하도록 구성할 수 있다.

Meta는 특정한 최적화 커널에서 최대 네 배의 속도 향상을 측정했다고 밝혔다.

다만 이 결과 역시 특정한 하드웨어와 계산 구조에서 얻어진 자체 평가다.

AI를 이용한 GPU 최적화도 추진

Meta는 TLX를 실제로 사용하는 과정에서 ACE(Agent for Compute Efficiency)라는 AI 기반 최적화 시스템도 개발했다고 설명했다.

ACE는 GPU 프로그램의 실행 기록을 분석하고 성능 개선 가능성을 찾도록 지원한다.

예를 들어 특정한 계산에서 메모리 접근이 병목인지 확인할 수 있다.

이후 데이터 이동과 계산의 순서를 변경하는 방법을 제안할 수 있다.

하지만 AI가 제안한 최적화가 항상 정확하거나 더 빠른 결과를 제공하는 것은 아니다.

실제 프로그램을 다시 실행해 계산 결과의 정확성과 성능을 검증해야 한다.

이번 발표는 AI 개발의 성능 경쟁이 모델의 아키텍처뿐 아니라 GPU 하드웨어를 실제로 얼마나 효율적으로 활용할 수 있는지에 영향을 받는다는 점을 보여준다.

특히 대규모 모델을 운영하는 기업에서는 GPU 프로그램을 직접 최적화하는 능력이 실제 비용 절감으로 연결될 수 있다.

---

4️⃣ 산업·정책·안전

EU 집행위원회, 선거 관련 DSA 지침 개정안 의견수렴 시작…AI 딥페이크 표시와 추천 알고리즘 검증 강화 제안

• 발표일: 2026-11-10 — 정확한 게시 시각 미확인
• 적용 범위: EU 디지털서비스법, 선거 정보, 생성형 AI, 딥페이크, 소셜미디어 추천 시스템, 플랫폼 책임, 표현의 자유
• 원문: European Commission — Targeted consultation on the draft revised election guidelines under the Digital Services Act

유럽연합 집행위원회가 디지털서비스법(DSA)에 따른 선거 관련 지침 개정안의 의견수렴을 시작했다.

이번 발표는 새로운 법률이 즉시 시행됐다는 의미가 아니다.

기존의 대형 온라인 플랫폼에 관한 선거 위험관리 지침을 생성형 AI와 최신 정보조작 기술에 맞춰 개정하기 위한 초안을 공개한 것이다.

EU는 2024년 4월에 선거와 관련된 첫 번째 지침을 채택했다.

하지만 이후 생성형 AI가 발전하면서 실제 인물의 음성과 영상을 조작하는 기술도 정교해졌다.

또한 소셜미디어의 추천 알고리즘을 악용해 특정한 정보를 빠르게 확산시키는 문제도 중요한 과제로 등장했다.

EU 집행위원회는 이런 변화에 대응하기 위해 기존 지침의 내용을 수정하려 한다.

적용 대상은 모든 웹사이트가 아니다

이번 지침의 주요 대상은 VLOP와 VLOSE다.

VLOP(Very Large Online Platform)는 EU의 디지털서비스법에서 지정하는 초대형 온라인 플랫폼이다.

VLOSE(Very Large Online Search Engine)는 같은 법에서 지정하는 초대형 온라인 검색엔진이다.

대표적으로 대규모 소셜미디어와 검색서비스가 해당 범주에 포함될 수 있다.

이런 서비스는 많은 사용자에게 정보를 제공하므로 추천 알고리즘과 콘텐츠 노출 방식이 선거 환경에도 영향을 줄 가능성이 있다.

따라서 EU는 대형 플랫폼이 실제로 어떤 위험을 만들 수 있는지 평가하고 완화하도록 요구하고 있다.

이번 개정안도 이런 기존 체계를 기반으로 작성됐다.

AI로 생성한 딥페이크의 표시 강화

첫 번째 주요 제안은 AI로 생성한 딥페이크 콘텐츠에 관한 표시다.

Deepfake(딥페이크)는 AI 등을 이용해 실제 인물의 얼굴과 음성, 행동을 조작하거나 합성한 콘텐츠를 의미한다.

예를 들어 실제 정치인이 하지 않은 발언을 한 것처럼 보이는 영상을 만들 수 있다.

이런 콘텐츠가 실제 영상으로 오인되면 유권자의 판단에 영향을 줄 가능성이 있다.

EU 집행위원회는 딥페이크를 명확하게 표시하고, 다른 사람이 해당 콘텐츠를 공유하더라도 표시가 유지되도록 하는 방안을 제안했다.

또한 불법적인 후보자 딥페이크는 신속하게 제거할 수 있도록 하는 내용도 포함됐다.

다만 여기에는 중요한 구분이 필요하다.

모든 AI 생성 콘텐츠를 무조건 삭제하도록 요구하는 것은 아니다.

풍자나 합법적인 정치적 표현, 일반적인 영상 편집까지 동일하게 불법 콘텐츠로 취급해서는 안 된다.

EU 집행위원회는 지침이 표현의 자유와 정보의 자유를 존중해야 한다고 설명한다.

추천 알고리즘의 조작 가능성 검사

두 번째 주요 제안은 소셜미디어의 추천 시스템(Recommender System)에 관한 내용이다.

추천 시스템은 사용자가 어떤 게시물과 영상을 볼지 선택하고 표시 순서를 결정하는 기술이다.

예를 들어 사용자가 특정한 정치 관련 콘텐츠를 자주 시청하면 비슷한 콘텐츠가 더 많이 추천될 수 있다.

문제는 이런 시스템을 조직적으로 악용할 가능성이다.

예를 들어 여러 가짜 계정이 같은 콘텐츠에 반복적으로 반응하도록 만들 수 있다.

이런 행동을 통해 실제 사용자에게 해당 콘텐츠가 인기 있는 것처럼 보이게 만들 수 있다.

EU 집행위원회는 대형 플랫폼이 이런 조작을 선거 전에 적극적으로 검사하도록 제안했다.

구체적으로는 다음과 같은 내용이 포함됐다.

여기서 중요한 점은 추천 알고리즘의 변경 이력을 보관하도록 하는 제안이다.

예를 들어 선거를 앞두고 추천 시스템의 특정한 기준이 변경됐다고 가정해 보자.

해당 변경이 실제 콘텐츠의 노출에 어떤 영향을 주었는지 사후에 검토할 수 있어야 한다는 취지다.

이런 방식은 플랫폼의 추천 시스템이 선거 기간에 어떻게 작동했는지 더 투명하게 평가하기 위한 것이다.

외국의 조직적 정보조작 대응

세 번째 주요 제안은 FIMI(Foreign Information Manipulation and Interference)에 관한 내용이다.

FIMI는 외국에서 수행하는 정보조작과 간섭 활동을 의미한다.

예를 들어 여러 가짜 계정을 이용해 특정한 정치적 메시지를 조직적으로 확산시키는 행동이 포함될 수 있다.

EU 집행위원회는 플랫폼이 이런 행동을 조기에 발견하고 관련 네트워크를 분석하도록 제안했다.

또한 실제 선거 후보자를 사칭하는 계정이나 불법적인 위협과 괴롭힘에 대응하는 절차도 강화하려 한다.

이를 위해 후보자들이 플랫폼에 문제를 신고할 수 있는 별도의 연락 경로를 제공하는 방안도 포함됐다.

다만 특정한 정치적 관점이나 주장이라는 이유만으로 합법적인 콘텐츠를 삭제하도록 요구하는 것은 아니다.

집행위원회는 지침이 특정한 정치적 입장을 차별하지 않아야 한다고 강조했다.

현재는 의견수렴 단계

이번 개정안의 의견수렴 기간은 다음과 같다.

따라서 11월 10일부터 모든 플랫폼에 새로운 딥페이크 표시와 보고 의무가 즉시 적용됐다고 설명하는 것은 정확하지 않다.

실제 지침이 확정되기 전에는 이해관계자의 의견과 법률적 검토가 필요하다.

또한 지침 자체와 DSA에 따른 법적 의무를 구분해야 한다.

이번 발표는 AI 안전과 규제 논의가 개별 모델의 유해한 답변을 차단하는 문제에서 벗어나 AI로 생성한 정보가 실제 사회와 선거 과정에 어떤 영향을 줄 수 있는지 관리하는 방향으로 확대되고 있음을 보여준다.

---

📚 추천 글

Work at the Frontier: AI’s effect on freelance work

• 저자: OpenAI 경제연구팀·Upwork 공동 연구진
• 발행: OpenAI
• 게시일: 2026-11-10
• 원문: OpenAI — Work at the Frontier: AI’s effect on freelance work

AI가 발전하면 실제로 어떤 종류의 일자리가 줄어들고 어떤 새로운 일이 생겨날까?

이 질문은 단순한 기술 성능 평가만으로 답하기 어렵다.

예를 들어 AI가 문서를 작성할 수 있다고 해서 모든 문서 작성 업무가 즉시 사라지는 것은 아니다.

어떤 사람은 AI를 이용해 기존에 외주로 맡기던 문서를 직접 작성할 수 있다.

반면 다른 기업은 AI를 활용해 더 복잡한 문서나 콘텐츠를 제작하도록 새로운 전문가를 고용할 수도 있다.

따라서 실제 변화를 이해하려면 AI의 기술적 능력과 기업이 어떤 일을 외부 전문가에게 맡기고 있는지를 함께 조사해야 한다.

OpenAI는 이런 문제를 연구하기 위해 프리랜서 업무 플랫폼인 Upwork와 공동 연구를 진행했다.

이번 글은 ChatGPT의 실제 사용 유형과 Upwork에 등록된 업무 의뢰의 변화를 비교한다.

특히 단순히 AI가 일자리를 대체할 것이라고 전망하는 대신 어떤 종류의 업무 수요가 감소하거나 증가하고, 하나의 프로젝트에 필요한 능력이 어떻게 달라졌는지 실제 데이터를 이용해 분석했다는 점에서 읽어볼 가치가 있다.

ChatGPT에서 자주 수행하는 업무와 외주 업무 비교

연구팀은 ChatGPT에서 사용자가 어떤 종류의 작업을 수행하는지 분류했다.

또한 Upwork에 등록된 프리랜서 업무 의뢰를 같은 분류 체계로 정리했다.

예를 들어 사용자는 ChatGPT에서 문서 작성과 번역, 코드 작성 등의 작업을 직접 수행할 수 있다.

반면 Upwork에서는 전문적인 영상 제작이나 애니메이션, 복잡한 소프트웨어 개발 등의 업무를 의뢰할 수 있다.

연구팀은 이런 두 종류의 활동을 비교했다.

여기서 중요한 점은 ChatGPT를 자주 사용하는 업무와 프리랜서에게 많이 맡기는 업무가 반드시 같지 않다는 사실이다.

예를 들어 ChatGPT에서는 글쓰기 관련 활동의 비중이 상대적으로 높았다.

반면 Upwork에서는 영상과 애니메이션 관련 의뢰의 비중이 더 높았다.

이런 차이는 사람들이 실제로 AI를 사용하는 방식과 외부 전문가에게 업무를 맡기는 방식이 서로 다르다는 점을 보여준다.

63개 업무 가운데 43개에서 반대 방향의 변화

연구팀은 63개 업무 범주를 비교했다.

그 결과 43개 범주에서는 ChatGPT에서 상대적으로 많이 수행되는 활동일수록 Upwork의 의뢰 비중이 감소하는 경향이 나타났다.

예를 들어 기존에 외부 전문가에게 맡기던 일부 문서 작성이나 단순 콘텐츠 제작 업무를 사용자가 AI로 직접 처리할 가능성이 있다.

하지만 이 결과를 해석할 때는 중요한 제한이 있다.

상관관계(Correlation)는 두 현상이 함께 변화하는 관계를 의미한다.

반면 인과관계(Causation)는 하나의 현상이 실제로 다른 현상을 발생시켰다는 관계다.

이번 연구는 ChatGPT 사용과 Upwork 업무 의뢰의 변화를 비교했다.

따라서 특정한 범주의 외주 의뢰가 감소했다는 사실만으로 ChatGPT가 해당 감소를 직접 발생시켰다고 단정할 수는 없다.

실제 외주 수요는 경기와 기업의 예산, 새로운 소프트웨어의 등장과 노동시장 상황 등 여러 요인의 영향을 받는다.

또한 나머지 20개 범주에서는 반대 방향의 변화가 관찰됐다.

따라서 이번 연구가 모든 프리랜서 업무가 AI 때문에 줄어든다는 결과를 제시한 것은 아니다.

AI 관련 프로젝트는 여러 능력을 결합하는 방향으로 변화

이번 연구에서 가장 흥미로운 부분은 새로운 업무 의뢰의 구조가 복잡해지고 있다는 점이다.

예를 들어 과거에는 영상 편집과 모션그래픽 제작을 별도의 업무로 의뢰할 수 있었다.

하지만 AI 관련 프로젝트에서는 생성형 AI로 영상을 만들고, 실제 편집을 수행한 뒤, 모션그래픽을 추가하는 작업을 하나의 프로젝트로 묶는 경우가 나타났다.

즉 AI를 사용할 줄 아는 능력이 기존 전문 기술과 결합되고 있는 것이다.

연구팀은 이런 변화를 측정하기 위해 AI 관련 업무 의뢰에 포함된 작업 종류의 다양성을 분석했다.

2023년 초부터 2025년 말까지 AI 관련 업무의 작업 구성이 약 45% 다양해졌다고 밝혔다.

이를 같은 빈도로 등장하는 작업 수로 환산하면 다음과 같다.

이 수치는 실제 업무 종류가 정확히 14.6개에서 21.2개로 증가했다는 의미가 아니다.

여러 작업의 출현 비율을 고려해 다양성을 계산한 통계적 지표다.

즉 특정한 몇 가지 업무에 집중돼 있던 AI 관련 의뢰가 더 다양한 작업으로 확대됐다는 의미다.

AI 관련 프로젝트는 예산과 작업량이 더 많았다

연구팀은 AI 관련 프로젝트와 일반적인 프로젝트의 예산도 비교했다.

그 결과 AI 관련 프로젝트에서는 고정금액 계약의 예산이 상대적으로 높았고, 필요한 작업시간도 더 많았다.

반면 시간당 제시된 단가는 비슷한 수준이었다.

이 결과는 흥미로운 해석을 가능하게 한다.

예를 들어 AI 관련 프로젝트의 예산이 크다고 해서 AI 전문가의 시간당 임금이 반드시 높다는 의미는 아니다.

하나의 프로젝트가 더 많은 작업을 포함하기 때문에 전체 예산이 높아졌을 가능성이 있다.

연구팀도 이런 차이를 중요한 설명으로 제시했다.

따라서 AI 관련 의뢰의 예산이 높다는 사실을 근거로 모든 AI 프리랜서의 임금이 크게 증가했다고 판단해서는 안 된다.

실제 노동시장의 변화는 한 방향이 아니다

이번 연구는 AI가 업무를 변화시키는 방식이 단순하지 않다는 점을 보여준다.

일부 작업은 사용자가 AI를 이용해 직접 수행할 수 있게 됐다.

이 경우 기존 외주 의뢰의 수요가 감소할 가능성이 있다.

반면 새로운 AI 도구를 이용해 이전보다 복잡한 결과물을 만들려는 수요도 발생한다.

이 경우 여러 기술을 함께 사용할 수 있는 전문가에 대한 의뢰가 증가할 수 있다.

또한 AI를 도입하려는 기업은 기존 시스템과 AI를 연결하는 개발자나 자동화 전문가를 필요로 할 수 있다.

다만 이번 연구는 주로 Upwork에 등록된 업무 의뢰와 ChatGPT 사용을 비교했다.

따라서 전체 노동시장의 고용 변화나 개인의 실제 소득을 직접 측정한 결과는 아니다.

Upwork에 등록되지 않은 기업 내부 업무와 장기 고용계약은 충분히 반영되지 않을 수 있다.

이번 글은 AI가 노동시장에 미치는 영향을 이해할 때 어떤 직업이 사라질 것인가라는 질문만큼 실제로 어떤 작업이 새롭게 결합되고 있는가를 조사해야 한다는 관점을 제공한다.

특히 개발과 디자인, 콘텐츠 제작처럼 여러 전문 능력을 결합하는 업무의 변화를 이해하는 데 참고할 만한 자료다.

---

Agents aren’t humans (but they kinda are)

• 저자: Bryan Becker
• 발행: Cloudflare
• 게시일: 2026-11-05
• 원문: Cloudflare — Agents aren’t humans (but they kinda are)

AI 에이전트가 사용자를 대신해 웹사이트에서 상품을 구매하거나 서비스를 신청하는 시대에는 어떤 문제가 발생할까?

일반적인 웹사이트는 실제 사람이 브라우저를 조작한다는 가정을 바탕으로 설계된 경우가 많다.

예를 들어 사용자가 로그인하면 웹사이트는 해당 계정과 브라우저의 관계를 확인할 수 있다.

또한 결제가 발생하면 브라우저의 IP 주소와 기기 정보, 이전 결제 기록 등을 이용해 이상한 거래인지 검사할 수 있다.

하지만 AI 에이전트가 사용자를 대신해 웹사이트에 접근하면 상황이 달라진다.

웹사이트가 실제로 관찰하는 것은 사용자의 컴퓨터가 아니라 에이전트가 실행되는 클라우드 서버일 수 있기 때문이다.

Cloudflare의 이번 글은 이런 문제를 해결하기 위한 새로운 기술과 정책적 과제를 설명한다.

특히 AI 에이전트를 단순히 사람과 구분하면 된다는 접근에서 벗어나 실제로 누구를 대신해 어떤 권한으로 행동하는지 확인해야 한다는 관점을 제시한다.

하나의 AI 에이전트가 여러 사용자를 대신할 수 있다

일반적인 웹서비스에서는 하나의 브라우저와 사용자의 계정 사이에 일정한 관계가 존재할 수 있다.

예를 들어 사용자가 자신의 컴퓨터에서 쇼핑몰에 로그인한다고 가정해 보자.

쇼핑몰은 해당 계정과 기기, 접속 위치를 참고해 사용자를 확인할 수 있다.

하지만 클라우드 기반 AI 에이전트는 여러 사용자의 요청을 같은 인프라에서 실행할 수 있다.

예를 들어 사용자 A와 B가 같은 에이전트 서비스를 이용해 서로 다른 쇼핑몰에서 상품을 구매하도록 요청할 수 있다.

이 경우 쇼핑몰에서는 두 요청이 같은 종류의 자동화 인프라에서 발생한 것처럼 보일 수 있다.

반대로 동일한 사용자가 여러 에이전트 서비스를 통해 웹사이트에 접근할 수도 있다.

따라서 단순한 IP 주소나 브라우저 정보만으로 실제 사용자를 식별하기 어려워질 수 있다.

이를 Intermediary(중개자) 문제라고 설명할 수 있다.

에이전트가 사용자와 웹사이트 사이에서 중개자 역할을 수행한다는 의미다.

기존의 CAPTCHA가 충분하지 않은 이유

일반적인 웹사이트에서는 자동화된 프로그램을 구분하기 위해 CAPTCHA를 사용할 수 있다.

CAPTCHA는 사람이 수행하기 쉬운 작업을 제시해 실제 사용자와 자동화 프로그램을 구분하려는 기술이다.

예를 들어 여러 이미지 가운데 신호등이 포함된 이미지를 선택하도록 요청할 수 있다.

하지만 AI 에이전트는 처음부터 사람을 대신해 자동으로 작업하도록 설계됐다.

따라서 에이전트가 사람인지 아닌지 확인하는 질문 자체가 충분하지 않을 수 있다.

실제로 중요한 것은 다음과 같다.

이 에이전트가 실제 사용자의 허가를 받았는가?

사용자는 어떤 행동을 허용했는가?

웹사이트가 해당 행동을 허용할 수 있는가?

예를 들어 사용자가 자신의 항공권을 예약하도록 에이전트에 요청했다고 가정해 보자.

에이전트가 항공권을 검색하는 행동은 허용될 수 있다.

하지만 사용자의 승인 없이 실제 결제까지 수행할 권한이 있는지는 별도의 문제다.

따라서 에이전트가 자동화 프로그램이라는 사실을 확인하는 것보다 행동 권한의 범위를 검증하는 기술이 중요하다.

실제 구매와 결제 분쟁의 문제

이번 글에서 특히 흥미로운 사례는 Friendly Fraud(친숙한 거래를 이용한 부정 청구 분쟁)다.

예를 들어 사용자가 실제로 에이전트에게 상품을 구매하도록 지시했다고 가정해 보자.

에이전트는 정상적으로 상품을 구매했다.

하지만 이후 사용자가 해당 결제가 승인되지 않은 거래라고 주장할 수 있다.

일반적인 쇼핑몰에서는 과거 결제에 사용한 기기와 IP 주소 등을 참고할 수 있다.

그런데 에이전트가 구매를 수행했다면 실제 요청은 에이전트의 서버에서 발생할 수 있다.

따라서 사용자의 과거 거래와 같은 기기에서 발생했다는 근거가 사라질 수 있다.

웹사이트 입장에서는 사용자가 실제로 해당 거래를 승인했는지 확인하기 어려워진다.

또한 에이전트가 사용자의 요청을 잘못 이해해 다른 상품을 구매하는 상황도 발생할 수 있다.

예를 들어 날짜를 잘못 선택하거나 같은 상품을 두 번 구매할 수 있다.

이 경우 누가 책임을 져야 하는지도 복잡한 문제가 된다.

실제 사용자가 잘못 지시했을 수도 있다.

에이전트가 잘못 판단했을 수도 있다.

또는 웹사이트가 사용자의 요청을 처리하는 과정에서 오류를 만들었을 수도 있다.

신원과 평판, 책임을 함께 관리

Cloudflare는 AI 에이전트가 실제 웹에서 안정적으로 작동하려면 세 가지 요소가 필요하다고 설명한다.

Identity(신원)는 실제 요청을 수행하는 주체와 그 주체가 대신하는 사용자를 확인하는 문제다.

Reputation(평판)은 과거의 정상적인 활동과 문제 발생 기록 등을 바탕으로 신뢰 수준을 평가하는 문제다.

Accountability(책임성)는 실제 행동과 그 결과에 대한 책임을 추적할 수 있는 상태를 의미한다.

Cloudflare는 이를 위해 여러 인터넷 표준을 함께 활용하는 방향을 제안한다.

예를 들어 OAuth를 이용해 계정 접근권한을 전달할 수 있다.

OAuth는 사용자의 비밀번호를 매번 전달하지 않고 정해진 범위의 접근권한을 다른 프로그램에 부여하는 기술이다.

또한 실제 에이전트 서비스를 인증하기 위한 별도의 프로토콜도 필요할 수 있다.

하지만 하나의 기술만으로 모든 문제를 해결하기는 어렵다.

예를 들어 OAuth로 계정의 접근권한을 확인할 수 있더라도 실제 사용자가 특정한 결제를 승인했다는 사실까지 자동으로 증명할 수 있는 것은 아니다.

웹사이트도 AI 에이전트에 대한 정책을 표현해야 한다

이번 글에서는 웹사이트가 AI 에이전트에게 어떤 행동을 허용할지 표현하는 문제도 중요하게 다룬다.

일반적인 웹사이트는 검색엔진의 크롤러에 관한 정보를 robots.txt로 제공할 수 있다.

하지만 robots.txt는 AI 에이전트가 상품을 구매하거나 계정을 수정하는 행동까지 충분히 표현하도록 설계된 규격은 아니다.

예를 들어 어떤 웹사이트는 AI 에이전트의 상품 검색을 허용할 수 있다.

반면 실제 결제에는 사용자의 추가 승인을 요구할 수 있다.

또한 일부 민감한 페이지에는 AI 에이전트의 접근 자체를 제한할 수 있다.

이런 규칙을 프로그램이 이해할 수 있는 형태로 제공한다면 에이전트도 웹사이트의 정책을 더 쉽게 따를 수 있다.

Cloudflare는 관련 표준을 논의하기 위해 Trusted Agent Delegation(TAD) 협력체도 발표했다.

다만 이번 글에서 설명하는 표준의 상당 부분은 아직 개발과 논의 단계에 있다.

모든 웹사이트와 AI 에이전트가 사용할 수 있는 완성된 단일 표준이 이미 존재한다는 의미는 아니다.

이번 글은 AI 에이전트가 실제 인터넷의 주요 사용자가 될수록 모델의 추론 능력뿐 아니라 신원 확인과 사용자 권한, 웹사이트의 접근 정책과 실제 거래 책임이 중요한 기술적 문제가 된다는 점을 설명한다.

특히 웹서비스와 인증·결제 시스템을 개발하는 사람에게 새로운 관점을 제공하는 자료다.

---

Introducing the Multimodal Knowledge Agent benchmark

• 저자: Rohan Doshi, Ben Caine
• 발행: Google DeepMind / Artificial Analysis
• 게시일: 2026-11-10
• 원문: Google — Introducing the Multimodal Knowledge Agent benchmark

AI 에이전트가 실제 업무를 얼마나 잘 수행하는지 평가하려면 어떤 기준이 필요할까?

기존의 언어모델 벤치마크에서는 수학 문제나 코딩 문제, 일반적인 지식 질문을 제시하는 경우가 많다.

하지만 실제 회사의 업무는 단순한 텍스트 문제와 다르다.

예를 들어 건축 설계자는 도면을 확인해야 한다.

재무 담당자는 스프레드시트의 숫자와 수식을 분석해야 한다.

연구자는 여러 그래프와 실험 이미지를 함께 검토해야 할 수 있다.

또한 실제 결과물로 보고서나 프레젠테이션을 만들어야 하는 경우도 있다.

이번 글은 이런 작업을 평가하기 위해 Google과 Artificial Analysis가 공동 개발한 Multimodal Knowledge Agent(MKA) 벤치마크를 설명한다.

특히 단순한 답변의 정확도뿐 아니라 여러 파일을 읽고 실제로 완성된 업무 결과물을 만들어내는 능력을 평가한다는 점이 특징이다.

실제 전문가가 수시간 동안 수행하는 작업으로 구성

MKA에는 200개의 평가 작업이 포함됐다.

이 작업들은 10개 산업 분야와 83개 직업에서 실제로 수행하는 업무를 바탕으로 구성됐다.

대표적인 분야는 다음과 같다.

Google에 따르면 각 작업은 해당 분야의 숙련된 전문가가 수행할 때 약 3~8시간이 필요한 수준으로 구성됐다.

또한 하나의 작업에는 여러 종류의 입력 파일이 포함될 수 있다.

예를 들어 PDF 문서와 표, 이미지와 도면을 함께 제공할 수 있다.

에이전트는 필요한 자료를 확인한 뒤 실제 결과물을 만들어야 한다.

이런 방식은 단순한 지식 질문보다 실제 업무와 비슷한 조건을 제공한다.

하지만 전문가에게 필요한 시간과 AI가 수행하는 시간은 같은 조건에서 직접 비교한 결과가 아니므로, AI가 실제 업무를 몇 배 빠르게 만든다고 판단해서는 안 된다.

정확성과 시각적 품질을 함께 평가

MKA의 각 작업에는 전문가가 작성한 평가 기준이 존재한다.

하나의 작업에는 평균적으로 약 70개의 예·아니요 평가 항목이 포함된다.

예를 들어 보고서에 필요한 숫자가 올바르게 포함됐는지 확인할 수 있다.

또한 중요한 그래프가 누락되지 않았는지 검사할 수 있다.

스프레드시트에서는 실제 수식이 올바른지 확인할 수 있다.

평가 점수는 크게 두 영역으로 구성된다.

여기서 중요한 점은 텍스트의 내용이 정확하더라도 실제 결과물이 사용할 수 있는 상태인지 별도로 확인한다는 사실이다.

예를 들어 프레젠테이션의 내용이 모두 맞더라도 글자가 슬라이드 밖으로 벗어나면 실제 업무에 사용하기 어렵다.

또한 스프레드시트가 올바른 숫자를 표시하더라도 수식이 잘못 작성돼 있다면 데이터를 수정할 때 오류가 발생할 수 있다.

따라서 MKA는 최종 답변뿐 아니라 실제 파일을 열고 검사하는 방식을 사용한다.

모든 모델에 같은 에이전트 실행 환경 제공

언어모델을 실제 업무에 적용할 때는 모델 자체의 성능뿐 아니라 주변의 실행 환경도 중요하다.

예를 들어 어떤 모델은 외부 프로그램을 자유롭게 실행할 수 있다.

다른 모델은 파일을 읽는 기능만 제공할 수도 있다.

이런 환경에서 모델을 비교하면 실제 성능 차이가 모델의 능력 때문인지 실행 도구의 차이 때문인지 판단하기 어려울 수 있다.

MKA는 이런 문제를 줄이기 위해 Stirrup이라는 공통 에이전트 하네스를 사용한다.

Harness(하네스)는 AI 모델이 파일과 도구, 프로그램 실행 환경을 사용할 수 있도록 연결하는 소프트웨어 계층이다.

MKA에서는 모든 모델에 같은 도구와 샌드박스, 실행 횟수 제한을 제공한다.

Sandbox(샌드박스)는 프로그램이 사용할 수 있는 시스템 자원과 접근권한을 제한한 실행 환경이다.

이렇게 하면 모델마다 서로 다른 실행 환경을 사용하는 데서 발생하는 차이를 줄일 수 있다.

하지만 공통 하네스를 사용한다고 해서 모든 모델에 완전히 동일한 최적의 환경이 제공된다는 의미는 아니다.

어떤 모델은 특정한 실행 방식에서 더 높은 성능을 제공할 수 있기 때문이다.

따라서 MKA의 결과를 해석할 때는 해당 하네스에서 측정한 성능이라는 점을 고려해야 한다.

AI 평가 모델과 실제 전문가의 판단 비교

200개 작업의 결과를 모두 사람이 직접 평가하려면 상당한 시간이 필요하다.

Google과 Artificial Analysis는 이를 해결하기 위해 별도의 AI 평가 에이전트를 사용했다.

이 에이전트는 실제 파일을 열고 보고서와 프레젠테이션을 렌더링한다.

또한 스프레드시트의 수식을 확인한다.

이후 전문가가 작성한 평가 기준에 따라 결과를 채점한다.

이런 방식을 LLM-as-a-Judge(언어모델을 이용한 평가)라고 한다.

다른 언어모델을 이용해 AI의 결과를 평가하는 방법이다.

Google은 평가 편향을 줄이기 위해 Google이 아닌 회사의 모델을 자동 평가에 사용했다고 밝혔다.

또한 실제 전문가가 같은 결과를 평가하도록 해 자동 평가와 비교했다.

그 결과 전문가의 판단과 자동 평가의 일치율은 96%였다.

하지만 96%라는 수치가 나머지 모든 평가에서도 같은 수준의 정확도를 보장한다는 의미는 아니다.

또한 어떤 조건에서 평가가 일치하지 않았는지도 실제 모델의 순위에 영향을 줄 수 있다.

따라서 자동 평가의 결과는 유용한 비교 자료이지만 완전한 정답으로 간주해서는 안 된다.

비공개 평가와 공개 평가의 역할

이번 벤치마크에서는 전체 200개 평가 작업을 비공개로 유지한다.

이유는 평가 데이터가 모델 학습에 유입되는 문제를 줄이기 위해서다.

이를 Benchmark Contamination(벤치마크 오염)이라고 한다.

예를 들어 실제 시험 문제가 학습 데이터에 포함됐다면 모델이 해당 문제의 답변을 기억하고 있을 가능성이 있다.

이 경우 높은 점수를 기록하더라도 처음 보는 문제를 해결하는 능력을 정확하게 측정하기 어렵다.

Google과 Artificial Analysis는 이런 문제를 줄이기 위해 전체 평가 자료를 비공개로 관리한다.

반면 외부 연구자가 실제 평가의 구조를 이해할 수 있도록 10개 작업은 공개했다.

이렇게 하면 평가의 공정성을 유지하면서도 외부 연구자가 문제 형식과 평가 기준을 확인할 수 있다.

모델마다 작업 수행 방식에도 큰 차이

이번 글에서는 모델의 최종 점수뿐 아니라 작업을 완료하기 위해 얼마나 많은 단계가 필요한지도 분석했다.

Google에 따르면 같은 종류의 평가에서 모델마다 평균 30~130회의 실행 단계를 사용했다.

이는 실제 업무 에이전트의 성능을 이해할 때 중요한 차이다.

예를 들어 두 모델이 같은 보고서를 성공적으로 생성했다고 가정해 보자.

한 모델은 30번의 도구 호출과 분석으로 작업을 완료할 수 있다.

다른 모델은 100번 이상의 단계가 필요할 수도 있다.

이 경우 최종 결과의 품질이 같더라도 시간과 비용은 상당히 다를 수 있다.

Google은 Gemini 4 Carbon이 품질 기준 2위를 기록하면서도 최고 점수 모델보다 평균 작업 비용이 여섯 배 이상 낮았다고 밝혔다.

하지만 이 수치는 해당 벤치마크에서 측정된 결과다.

모든 실제 업무에서 같은 비용 차이가 발생한다는 의미는 아니다.

이번 글은 AI 에이전트의 실제 능력을 평가할 때 모델이 정답을 얼마나 잘 설명하는가뿐 아니라 복잡한 파일을 이해하고, 실제로 사용할 수 있는 결과물을 생성하며, 그 작업을 얼마의 비용으로 완료하는가를 함께 고려해야 한다는 점을 보여준다.

특히 AI를 실제 업무에 도입하려는 조직과 개발자에게 벤치마크 점수를 해석하는 새로운 관점을 제공한다.