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

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

---

1️⃣ 주요 모델·연구

Google DeepMind, ‘AlphaGenome 2’ 공개…1억 개 이상의 세포 데이터로 유전자 변이가 특정 세포에 미치는 영향 예측

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: 유전체 AI, 단일세포 생물학, 유전자 발현 예측, 질병 연구, 신약개발, 과학 연구 API
• 원문: Google DeepMind — AlphaGenome 2: Deciphering how cells read DNA to better understand disease

---

Google DeepMind가 DNA 서열의 변이가 실제 세포에서 어떤 영향을 일으키는지 예측하는 새로운 모델 AlphaGenome 2를 공개했다.

이번 모델은 기존 AlphaGenome의 후속 버전으로, 유전자 분석의 단위를 넓은 조직 수준에서 개별 세포 유형과 세포의 활성 상태까지 세분화했다.

특히 기존 모델보다 유전자 변이의 영향을 훨씬 정확하게 구분할 수 있으며, 학습에서 직접 보지 못한 새로운 세포 상태에도 별도의 재학습 없이 적용할 수 있도록 설계했다.

같은 DNA를 가지고도 세포마다 다른 기능을 수행하는 이유

사람의 몸을 구성하는 대부분의 세포는 기본적으로 같은 DNA 정보를 가지고 있다.

하지만 심장 근육세포와 면역세포, 신경세포는 서로 다른 기능을 수행한다.

그 이유는 같은 DNA를 가지고 있더라도 어떤 유전자를 활성화하고 어떤 유전자의 활동을 억제하는지가 다르기 때문이다.

이를 유전자 발현(Gene Expression)이라고 한다.

유전자 발현은 DNA에 저장된 유전정보가 실제로 RNA나 단백질을 만드는 과정에 사용되는 정도를 의미한다.

예를 들어 어떤 유전자는 심장 근육세포에서는 활발하게 발현되지만 면역세포에서는 거의 발현되지 않을 수 있다.

따라서 DNA의 특정 위치에 변이가 발생했더라도 모든 세포에서 같은 문제가 발생하는 것은 아니다.

특정한 면역세포에서만 유전자 발현이 크게 달라질 수도 있다.

기존의 유전체 AI는 여러 세포가 혼합된 조직의 평균적인 특성을 예측하는 경우가 많았다.

하지만 조직 전체의 평균을 사용하면 소수의 특정 세포에서 발생하는 중요한 변화를 놓칠 가능성이 있다.

AlphaGenome 2는 이 문제를 해결하려 한다.

100만 염기 DNA와 세포 상태를 함께 입력

기존 AlphaGenome은 약 100만 개의 DNA 염기서열을 입력받아 여러 조직에서 나타나는 분자적 특성을 동시에 예측했다.

AlphaGenome 2는 접근 방법을 변경했다.

DNA 서열과 함께 분석하려는 세포의 유형 또는 상태를 조건으로 입력한다.

이를 조건부 모델(Conditional Model)이라고 한다.

예를 들어 같은 DNA 서열을 분석하더라도 일반적인 면역세포와 감염에 반응해 활성화된 면역세포에서는 서로 다른 결과를 예측할 수 있다.

이 조건은 모델의 마지막 출력 단계에만 반영되는 것이 아니다.

Google은 세포 상태에 관한 정보를 모델의 여러 계산 단계에 전달하도록 아키텍처를 재설계했다고 설명한다.

이를 통해 같은 DNA 구간이 서로 다른 세포에서 어떻게 해석되는지 학습하도록 했다.

또한 다음과 같은 분자적 특성을 예측할 수 있다.

염색질(Chromatin)은 DNA와 단백질이 결합해 형성한 구조다.

염색질의 상태에 따라 특정 유전자가 활성화되기 쉬워질 수도 있고 억제될 수도 있다.

따라서 DNA 서열 자체뿐 아니라 실제 세포에서 DNA가 어떤 상태로 존재하는지도 중요하다.

1억700만 개 이상의 세포 데이터로 학습

Google DeepMind는 인간과 생쥐의 여러 조직에서 수집한 데이터를 이용해 AlphaGenome 2를 학습했다.

공개된 규모는 다음과 같다.

특히 단일세포 데이터를 이용했다는 점이 중요하다.

단일세포 분석(Single-Cell Analysis)은 조직을 구성하는 여러 세포의 특성을 평균 내는 대신 개별 세포의 유전자 활동 등을 분석하는 방법이다.

예를 들어 혈액에는 여러 종류의 면역세포가 존재한다.

조직 전체를 분석하면 각 세포의 차이가 평균에 가려질 수 있다.

반면 단일세포 데이터를 이용하면 어떤 종류의 면역세포에서 특정 유전자가 활성화되는지 구분할 수 있다.

AlphaGenome 2는 이런 데이터를 바탕으로 실제 세포별 차이를 예측하도록 학습됐다.

원인 유전자 변이 발견 비율 16%에서 30%로 개선

Google은 TenK10K라는 단일세포 데이터셋에서 모델의 성능을 평가했다.

이 평가에는 28개 주요 면역세포 유형이 포함됐다.

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

원인 변이 식별 비율이 16%에서 30%로 높아졌다는 것은 해당 평가에서 더 많은 원인 후보를 찾아냈다는 의미다.

또한 특정 변이가 유전자의 활동을 증가시키는지 감소시키는지 구분하는 능력도 개선됐다.

하지만 이 수치는 Google DeepMind가 수행한 특정 평가에서 얻어진 결과다.

모든 유전질환의 원인 변이를 30% 발견한다는 의미가 아니다.

또한 계산으로 예측한 변이가 실제 질병의 원인인지 확인하려면 별도의 실험적 검증이 필요하다.

염증성 장질환의 원인 변이를 세포 수준에서 재현

Google은 실제 질병 관련 연구 결과를 다시 분석하는 사례도 공개했다.

대표적인 대상은 염증성 장질환(IBD)이다.

기존 연구에서는 장의 특정 면역세포에서 ETS2 유전자의 활동이 과도하게 증가하는 현상과 관련된 DNA 변이가 확인된 바 있다.

문제는 해당 변이가 모든 세포에 똑같은 영향을 미치지는 않는다는 점이다.

AlphaGenome 2는 여러 면역세포를 각각 분석했다.

그 결과 해당 변이가 장의 대식세포에서 ETS2 유전자의 활동을 선택적으로 증가시키는 패턴을 예측했다.

대식세포(Macrophage)는 외부 병원체와 손상된 세포 등을 처리하는 면역세포의 한 종류다.

이 사례는 새로운 질병 원인을 처음 발견한 결과가 아니다.

이미 발표된 생물학적 연구 결과를 AI 모델이 얼마나 정확하게 재현할 수 있는지 확인한 사례다.

그럼에도 조직 전체의 평균만으로는 구분하기 어려운 세포별 차이를 예측했다는 점에서 의미가 있다.

새로운 실험 데이터도 재학습 없이 분석

이번 모델의 중요한 기능은 기존 학습 데이터에 포함되지 않은 세포 상태를 처리하는 능력이다.

예를 들어 연구자가 백신 접종 이후 활성화된 T세포의 유전자 활동을 측정했다고 가정해 보자.

T세포(T Cell)는 면역반응에 중요한 역할을 하는 면역세포다.

기존 방식에서는 새로운 세포 상태에 관한 데이터가 충분하지 않으면 모델을 추가 학습해야 할 수 있었다.

AlphaGenome 2는 수십 개 세포에서 수집한 단일세포 RNA 분석 결과를 이용해 새로운 세포 상태를 표현할 수 있다.

이후 해당 상태에서 DNA 변이가 어떤 영향을 미칠지 예측한다.

Google은 COVID-19 mRNA 백신 연구의 단일세포 데이터를 이용해 이런 기능을 시험했다.

그 결과 활성화된 T세포와 일반적인 T세포에서 특정한 유전적 변이가 서로 다르게 작용하는 패턴을 구분했다고 설명했다.

이는 세포의 종류뿐 아니라 실제 생물학적 상태가 유전자 변이의 효과를 바꿀 수 있다는 점을 분석하는 데 활용할 수 있다.

연구용 API 제공, 임상 진단에는 사용 불가

AlphaGenome 2는 발표일부터 AlphaGenome API를 통해 비상업적 연구에 사용할 수 있다.

상업적인 연구를 위한 접근은 비공개 프리뷰 형태로 제공된다.

또한 Google은 관련 도구를 Antigravity와 연결하는 Agent Skill을 향후 공개할 계획이라고 밝혔다.

하지만 AlphaGenome 2는 현재 연구용 모델이다.

의료 진단과 임상적 의사결정에 사용할 수 있도록 검증되거나 승인된 제품이 아니다.

모델이 특정한 유전자 변이가 질병과 관련될 가능성을 예측하더라도 실제 환자에게 해당 질병이 발생한다는 의미는 아니다.

이번 발표는 AI가 유전자 서열을 분석하는 기술에서 한 단계 나아가 같은 DNA가 서로 다른 세포와 생물학적 상태에서 어떻게 작동하는지 예측하는 기술로 발전하고 있음을 보여준다.

---

Google Research, 스마트워치 데이터로 12주 뒤 건강 변화 예측하는 ‘Sensor World Model’ 연구 공개

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: 웨어러블 AI, 시계열 예측, 월드 모델, 생활습관 시뮬레이션, 심혈관·신장·대사 건강 연구
• 원문: Google Research — Using wearables to enable cardiovascular-kidney-metabolic risk profiling for personalized coaching

---

Google Research가 스마트워치에서 수집한 데이터를 이용해 생활습관을 변경했을 때 미래의 건강 지표가 어떻게 달라질지 예측하는 연구를 공개했다.

이번 연구는 새로운 소비자용 건강 앱을 출시한 소식이 아니다.

스마트워치가 기록한 과거 활동을 분석하는 데서 그치지 않고, 앞으로 운동이나 수면 습관을 바꾸면 12주 뒤 어떤 변화가 나타날 수 있는지 계산하는 실험적 AI 프레임워크를 발표한 것이다.

Google은 관련 연구 두 건을 함께 소개했다.

첫 번째는 변경 가능한 생활습관을 바탕으로 계산한 건강 나이와 미래 행동을 시뮬레이션하는 연구다.

두 번째는 웨어러블 정보와 혈액검사 결과를 결합해 심혈관·신장·대사 건강을 분석하는 연구다.

생물학적 나이를 실제로 바꿀 수 있는 생활습관과 연결

일반적인 나이는 출생 이후 얼마나 많은 시간이 지났는지를 나타낸다.

하지만 같은 나이의 사람이라도 실제 건강 상태는 다를 수 있다.

이를 설명하기 위해 생물학적 나이(Biological Age)라는 개념이 사용된다.

생물학적 나이는 생리학적 지표를 이용해 현재 몸의 상태를 나이와 비슷한 단위로 표현하려는 접근이다.

Google은 이번 연구에서 Coachable Health Age(CHA)라는 새로운 지표를 제안했다.

기존의 일부 생물학적 나이 모델은 실제 출생 나이를 얼마나 정확하게 예측하는지 학습한다.

하지만 이런 방식에서는 쉽게 변경할 수 없는 특징까지 학습할 수 있다.

반면 CHA는 실제 생활에서 변경 가능한 행동과 관련된 신호에 초점을 맞춘다.

대표적인 입력은 다음 네 가지다.

일부 평가에서는 최대산소섭취량과 수면 규칙성, 인슐린 저항성 등 추가적인 지표도 사용했다.

Google은 이 정보들을 결합해 생활습관과 생리학적 상태의 차이를 나이 단위로 표현했다.

예를 들어 실제 나이보다 건강 나이가 낮게 계산됐다면 현재의 측정 지표가 상대적으로 양호한 상태라는 의미로 해석할 수 있다.

하지만 이 숫자가 실제로 신체의 모든 기관이 몇 살 더 젊다는 사실을 직접 측정한 것은 아니다.

특정한 통계적 모델과 건강 지표에 기반한 추정값이다.

2만2천748명의 자료로 미래 질병 위험 평가

Google은 여러 집단에서 CHA의 관련성을 검증했다.

미국의 All of Us 연구 프로그램에 참여한 2만2천748명의 데이터를 활용했다.

여기에는 6만8천 인년(Person-Years) 이상의 추적 정보가 포함됐다.

인년(Person-Year)은 한 사람을 1년 동안 관찰한 기간을 하나의 단위로 계산한 것이다.

예를 들어 1,000명을 2년 동안 관찰하면 총 2,000인년에 해당한다.

연구팀은 CHA와 실제 나이의 차이가 향후 고혈압과 심혈관질환, 제2형 당뇨병 발생과 관련이 있는지 조사했다.

그 결과 건강 나이가 실제 나이보다 높은 사람은 이후 관련 질환이 발생할 위험도 높은 경향을 보였다.

또한 나이와 성별, 체질량지수만 사용하는 기존 위험 예측에 CHA를 추가하면 일부 집단에서 예측 성능이 개선됐다.

하지만 이는 관찰 데이터를 이용한 연구다.

CHA가 높다는 사실 자체가 질병을 직접 발생시킨다는 의미는 아니다.

또한 CHA를 낮추면 실제 질병 발생률도 같은 비율로 감소한다는 인과관계가 증명된 것은 아니다.

2주 기록으로 향후 12주를 시뮬레이션

이번 연구의 핵심 기술은 SensorWM(Sensor World Model)이다.

월드 모델(World Model)은 현재 상태와 특정한 행동을 바탕으로 이후 환경이나 시스템의 상태를 예측하는 모델이다.

로봇 분야에서는 특정한 동작을 수행한 뒤 물체가 어떻게 움직일지 예측할 수 있다.

이번 연구에서는 비슷한 개념을 사람의 건강 데이터에 적용했다.

예를 들어 현재 하루 평균 5,000보를 걷는 사람이 있다고 가정해 보자.

이 사람이 하루 7,000보를 걷기 시작하면 앞으로 안정 시 심박수와 수면 등의 지표가 어떻게 변화할지 예측하려는 것이다.

SensorWM은 약 10만 명의 Fitbit 사용자로부터 수집한 228만 인주(Person-Weeks)의 데이터로 사전학습됐다.

인주는 한 사람을 1주일 동안 관찰한 기간을 의미한다.

모델은 과거 2주 동안의 데이터를 입력받는다.

이후 운동과 수면 등 여러 행동 조건에 따라 향후 12주 동안 20개 생리학적 지표가 어떻게 변화할지 예측한다.

연구팀은 사용자별로 125개 생활습관 조합을 시뮬레이션했다.

예를 들어 걸음 수를 늘리는 방법과 수면시간을 늘리는 방법을 비교할 수 있다.

이 과정을 Counterfactual Simulation(반사실적 시뮬레이션)이라고 한다.

실제로 수행하지 않은 행동을 가정해 다른 결과가 나타났을 가능성을 계산하는 방법이다.

하지만 시뮬레이션의 예측과 실제 사람에게 해당 행동을 적용했을 때 나타나는 결과는 다를 수 있다.

과격한 운동 계획보다 실현 가능한 계획 선택

Google은 모델이 예측한 여러 생활습관 가운데 가장 큰 변화가 예상되는 방법만 선택하지 않았다.

실제로 사용자가 해당 계획을 꾸준히 수행할 수 있는지도 고려했다.

예를 들어 운동을 거의 하지 않던 사람에게 갑자기 매일 강도 높은 운동을 수행하도록 권고하는 것은 적절하지 않을 수 있다.

따라서 연구팀은 기존의 생활습관과 변화 가능성, 임상적으로 허용되는 운동 강도 등을 함께 고려했다.

이후 언어모델 기반 코칭 에이전트가 실제 생활에 적용할 수 있는 12주 계획을 작성하도록 했다.

전문가 평가에서 일반적인 코칭보다 높은 선호

연구팀은 생활습관 코치와 의사에게 생성된 계획을 평가하도록 요청했다.

대표적인 결과는 다음과 같다.

생활습관 코치는 SensorWM의 시뮬레이션을 이용한 계획을 일반적인 웨어러블 데이터 기반 계획보다 더 선호했다.

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

전문가가 제안한 계획을 선호했다는 사실과 실제 사용자가 해당 계획을 따랐을 때 건강이 개선됐다는 사실은 다르다.

이번 연구에서는 생성된 계획의 적절성과 생리학적 타당성을 전문가가 평가했다.

모든 계획을 실제 참가자에게 12주 동안 적용한 임상시험의 결과는 아니다.

혈액검사와 결합한 CKM 건강 분석

Google은 별도의 연구에서 웨어러블 자료와 혈액검사 결과를 결합했다.

분석 대상은 CKM(Cardiovascular-Kidney-Metabolic) 건강이다.

CKM은 심혈관과 신장, 대사 건강이 서로 연결돼 있다는 개념이다.

예를 들어 당뇨병과 고혈압은 심혈관과 신장 기능에도 영향을 줄 수 있다.

연구팀은 819명의 WEAR-ME 연구 참가자 데이터를 분석했다.

기존 웨어러블 지표에 다음 정보를 추가했다.

• 콜레스테롤과 HDL의 비율
• 신장 여과 기능을 나타내는 eGFR
• 인슐린 저항성을 나타내는 HOMA-IR

그 결과 사람마다 어떤 기관의 건강 지표가 먼저 변화하는지가 다를 수 있음을 관찰했다.

예를 들어 대사와 심혈관 관련 지표는 함께 나빠지는 경향이 있지만 일부 사람에게서는 신장 관련 변화가 독립적으로 나타날 수 있었다.

이번 프레임워크는 연구 단계의 기술이다.

현재 실제 질병을 진단하거나 개인의 운동 처방을 결정하는 의료기기로 검증된 것은 아니다.

특히 12주 뒤의 건강 상태를 예측한 결과를 실제 의료진의 진단이나 치료계획과 동일하게 취급해서는 안 된다.

이번 연구는 웨어러블 AI가 과거 활동을 기록하는 도구에서 여러 생활습관 선택지의 결과를 비교하고 가능한 변화를 시뮬레이션하는 도구로 발전할 가능성을 보여준다.

---

Tether AI Research, 8억 파라미터 온디바이스 에이전트 ‘BotPsy’ 공개…도구 사용 성능 약 2배 개선

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: 소형 언어모델, 온디바이스 AI, 도구 호출, 개인 비서, 강화학습, 오픈웨이트 모델
• 원문: Hugging Face — BotPsy: On-Device Personal Assistant with a Sub-Billion-Parameter Agentic Language Model

---

Tether AI Research의 QVAC 연구팀이 약 8억 개의 파라미터를 가진 새로운 에이전트 특화 모델 BotPsy를 공개했다.

이번 모델은 Qwen3.5-0.8B를 기반으로 개발됐다.

일반적인 지식 질문에 가장 잘 답하는 모델을 만드는 것보다 작은 기기에서도 외부 도구를 정확하게 호출하고 여러 단계의 업무를 수행하도록 만드는 것에 초점을 맞췄다.

예를 들어 개인 비서가 사용자의 일정이나 파일, 메시지를 관리하려 한다고 가정해 보자.

이런 작업에는 항상 수천억 파라미터 규모의 모델이 필요한 것은 아닐 수 있다.

특정한 도구를 언제 호출해야 하는지, 어떤 값을 전달해야 하는지 정확하게 판단하는 능력이 더 중요할 수 있다.

BotPsy는 이런 가정에 기반한 연구다.

도구 호출과 일반적인 언어 이해는 서로 다른 능력

일반적인 언어모델은 사용자에게 이메일을 보내는 방법을 설명할 수 있다.

하지만 실제 에이전트는 이메일을 보내는 API를 호출해야 한다.

예를 들어 수신자와 제목, 본문을 정확한 형식으로 전달해야 한다.

사용자가 아직 수신자를 지정하지 않았다면 임의의 주소로 보내지 않아야 한다.

또한 해당 작업을 수행할 권한이 있는지 확인해야 한다.

Function Calling(함수 호출)은 AI가 외부 프로그램의 기능을 실행하기 위해 필요한 함수와 입력값을 선택하는 기술이다.

BotPsy는 이런 능력을 중심으로 추가 학습됐다.

네 단계의 학습 방법

연구팀은 네 단계로 모델을 학습시켰다.

첫 번째는 SFT(Supervised Fine-Tuning, 지도 미세조정)다.

실제 도구 호출 예시를 이용해 올바른 함수와 입력값을 선택하도록 학습한다.

두 번째는 MOPD(Multi-Teacher On-Policy Distillation)다.

여러 전문 교사 모델의 지식을 하나의 작은 모델에 전달하는 기술이다.

연구팀은 도구 사용과 일반 추론, 지시 이행에 각각 특화된 세 가지 Qwen3.5-4B 모델을 교사로 사용했다.

학생 모델은 자신의 답변을 생성한다.

이후 적절한 전문 교사의 피드백을 받아 실제 판단을 개선한다.

세 번째와 네 번째는 강화학습이다.

강화학습(Reinforcement Learning)은 모델이 수행한 행동에 보상을 제공해 더 좋은 행동을 선택하도록 학습시키는 방법이다.

여기서는 도구 이름과 입력값, 실제 작업의 성공 여부 등을 평가해 보상을 제공했다.

특히 두 번째 강화학습 단계에서는 일반 지식과 코딩 문제도 함께 사용해 도구 사용에만 지나치게 특화되는 문제를 줄이려 했다.

도구 사용 벤치마크에서 기존 모델 크게 앞서

Tether AI Research가 공개한 주요 평가 결과는 다음과 같다.

BFCL은 AI가 올바른 함수를 선택하고 정확한 입력값을 전달하는 능력을 평가한다.

τ-bench는 고객지원처럼 여러 차례의 대화와 정책 준수가 필요한 업무를 평가한다.

ToolSandbox는 여러 도구를 연결해 실제 작업을 수행하는 능력을 평가한다.

BotPsy는 기본 모델보다 여러 평가에서 약 두 배 높은 점수를 기록했다.

또한 일부 작업에서는 파라미터 수가 2.5배 많은 Qwen3.5-2B보다 높은 점수를 기록했다.

하지만 모든 항목에서 앞선 것은 아니다.

Claw-Eval에서는 더 큰 Qwen 모델이 높은 점수를 기록했다.

또한 이번 비교는 연구팀이 선정한 모델과 실행 설정을 기준으로 수행됐다.

모든 소형 모델보다 BotPsy가 우수하다는 독립적인 검증 결과는 아니다.

가장 어려운 업무에서는 여전히 낮은 성공률

이번 연구에서 중요한 부분은 높은 상대적 개선과 실제 절대적인 성능을 구분할 필요가 있다는 점이다.

예를 들어 BrowseComp-Plus에서는 BotPsy가 4.5점을 기록했다.

이는 비교 대상 가운데 가장 높은 점수였지만 절대적인 수준에서는 매우 낮았다.

BrowseComp-Plus는 복잡한 검색과 여러 단계의 정보 수집이 필요한 업무를 평가한다.

또한 복잡한 정보 검색 작업의 성공률은 단순한 도구 호출보다 크게 낮았다.

따라서 BotPsy가 개인 비서의 모든 업무를 독립적으로 수행할 수 있다고 판단해서는 안 된다.

반면 정해진 도구가 존재하고 입력값이 비교적 명확한 업무에서는 작은 모델도 유용할 수 있다.

안전성 평가에서는 개선됐지만 한계 존재

연구팀은 모델의 안전성도 평가했다.

자동화된 유해 요청 평가에서 위험한 응답을 생성한 비율은 기본 모델의 36%에서 BotPsy의 21%로 감소했다.

또한 프롬프트 인젝션(Prompt Injection) 공격에 대한 위험 응답 비율은 46%에서 31%로 감소했다.

프롬프트 인젝션은 외부 문서나 도구 결과에 포함된 악의적인 지시를 이용해 AI의 원래 행동을 변경하려는 공격이다.

하지만 31%라는 수치는 여전히 상당한 공격 성공 가능성이 남아 있다는 의미다.

따라서 실제로 개인정보에 접근하거나 금전적 행동을 수행하는 에이전트에 모델만 믿고 모든 권한을 제공해서는 안 된다.

중요한 행동에는 별도의 실행 권한 제한과 승인 절차가 필요하다.

오픈웨이트와 실제 배포 조건

연구팀은 BotPsy의 가중치를 공개하고 BF16, Q8, Q4 등의 정밀도를 지원한다고 설명했다.

양자화(Quantization)는 모델의 숫자를 낮은 정밀도로 표현해 메모리 사용량을 줄이는 기술이다.

GGUF 형식도 제공해 llama.cpp 등 로컬 추론 환경에서 사용할 수 있도록 했다.

다만 공개 글에서는 Apache 2.0 라이선스와 함께 연구·교육 목적의 사용 범위를 별도로 언급하고 있다.

따라서 실제 상업용 서비스에 적용하려면 모델 저장소의 최신 라이선스와 이용 조건을 확인해야 한다.

이번 연구는 AI 에이전트의 발전이 항상 더 큰 모델을 요구하지는 않는다는 점을 보여준다.

일반적인 지식 능력은 제한적이더라도 특정한 도구 사용과 업무 절차에 집중적으로 학습한 작은 모델이 실제 제품의 일부 작업에서 충분한 경쟁력을 가질 수 있다.

---

2️⃣ AI 제품·서비스

KT·Microsoft, 통신망 장애를 AI 에이전트가 조기에 발견하는 ‘AIO-Net’ 운영 성과 공개…탐지시간 10분 이상에서 2~3분으로

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 AI 에이전트, 통신망 운영, 장애 탐지, Microsoft Foundry, 운영 자동화, 인프라 안전
• 원문: Microsoft — KT Meisters and Microsoft engineers build AI agents to spot network issues before customers do

---

Microsoft가 KT와 공동 개발한 통신망 장애 분석 시스템 AIO-Net의 실제 운영 성과를 공개했다.

이번 발표는 AIO-Net이 11월 11일 처음 출시됐다는 의미가 아니다.

2026년 8월부터 실제 운영에 사용해 온 시스템의 구조와 장애 탐지시간, 업무 처리 성과를 새롭게 상세 공개한 사례다.

KT는 전국적인 모바일 및 유선 통신망을 운영한다.

이런 통신망에는 라우터와 스위치, 여러 종류의 네트워크 장비가 존재한다.

문제가 발생하면 고객의 인터넷 연결이나 통화 품질에 영향을 줄 수 있다.

따라서 문제가 실제 서비스 장애로 확대되기 전에 원인을 찾아내는 일이 중요하다.

여러 시스템의 경보를 하나의 분석 과정으로 연결

기존 통신망 운영에서는 담당자가 여러 프로그램을 오가며 장애 원인을 조사해야 했다.

예를 들어 특정한 라우터에서 경보가 발생했다고 가정해 보자.

담당자는 장비의 상태를 확인해야 한다.

이후 해당 장비와 연결된 다른 장비에서도 문제가 발생했는지 확인할 수 있다.

또한 최근의 네트워크 트래픽과 과거 장애 기록을 비교해야 할 수 있다.

실제 원인을 찾으려면 여러 자료를 종합해야 한다.

AIO-Net은 이 과정을 여러 AI 에이전트가 지원하도록 설계됐다.

Microsoft Foundry에서 실행되는 여러 대형 언어모델을 이용한다.

Microsoft Foundry는 AI 모델과 에이전트를 개발하고 관리하도록 지원하는 플랫폼이다.

AIO-Net의 에이전트들은 전국의 통신 장비가 생성하는 데이터를 1분마다 분석한다.

이상 징후가 발견되면 관련 기록과 운영 절차를 참고해 원인 후보를 분석한다.

실제 네트워크 전문가의 지식 활용

이번 시스템의 중요한 특징은 KT가 오랜 기간 근무한 네트워크 전문가의 경험을 활용했다는 점이다.

KT는 이들을 Meister(마이스터)라고 부른다.

실제 통신망 운영에서는 매뉴얼에 모든 예외 상황이 기록돼 있지 않을 수 있다.

예를 들어 특정한 장비에서 발생한 경보가 실제로는 다른 장비의 문제에서 비롯됐을 수 있다.

이런 상황에서는 과거에 비슷한 문제를 해결한 전문가의 판단이 중요하다.

KT와 Microsoft는 전문가의 피드백을 시스템에 지속적으로 반영하도록 설계했다.

이를 피드백 루프(Feedback Loop)라고 한다.

AI의 판단 결과를 사람이 검토하고 그 결과를 이후 시스템 개선에 다시 활용하는 구조다.

예를 들어 에이전트가 특정한 장애 원인을 잘못 판단했다면 담당자가 올바른 원인을 기록할 수 있다.

이후 비슷한 경보가 나타났을 때 해당 정보를 활용하도록 시스템을 개선한다.

다만 이런 구조가 모델의 가중치를 모든 피드백에 대해 실시간으로 다시 학습한다는 의미는 아니다.

실제 개선 방식에는 운영 규칙과 데이터, 에이전트 실행 절차의 수정도 포함될 수 있다.

탐지시간과 조사시간 감소

KT가 공개한 주요 운영 결과는 다음과 같다.

이 수치는 KT가 실제 운영을 바탕으로 공개한 자체 결과다.

외부 독립기관이 모든 운영 조건에서 동일한 시간을 측정한 것은 아니다.

또한 장애를 더 빨리 발견했다는 사실과 실제 장애가 완전히 해결됐다는 사실은 다르다.

문제의 종류에 따라 실제 복구에는 추가적인 작업이 필요할 수 있다.

AIO-Net은 장애의 원인을 조사하고 해결 방법을 제안하는 역할을 맡는다.

실제 대응과 조치는 사람이 결정한다.

실제 장비를 제어하는 명령은 실행하지 못하도록 제한

이번 사례에서 특히 중요한 부분은 AI의 실행 권한이다.

일반적인 에이전트에서는 모델이 외부 도구를 호출해 실제 프로그램을 실행할 수 있다.

하지만 통신 장비에 잘못된 명령을 전달하면 오히려 새로운 장애가 발생할 수 있다.

KT는 이를 방지하기 위해 AIO-Net이 사용할 수 있는 명령을 읽기 전용(Read-Only)으로 제한했다.

읽기 전용은 장비의 상태를 조회할 수 있지만 실제 설정을 변경하지는 못한다는 의미다.

또한 사전에 허용한 명령만 실행하도록 구성했다.

이를 허용 목록(Allowlist) 방식이라고 한다.

중요한 점은 이러한 제한을 단순히 AI의 시스템 프롬프트에 작성한 것이 아니라 실제 애플리케이션의 실행 권한으로 강제했다는 사실이다.

예를 들어 모델이 실수로 장비 설정을 변경하려 하더라도 프로그램이 해당 명령을 실행하지 못하도록 차단한다.

실제 네트워크 장애 대응의 최종 결정과 실행은 KT의 운영 담당자가 수행한다.

이번 발표는 AI 에이전트를 중요한 인프라에 도입할 때 모델의 분석 능력과 실제 장비의 제어 권한을 분리하는 설계가 중요하다는 점을 보여준다.

특히 기존 업무 전문가의 지식과 지속적인 피드백을 연결하는 방법까지 포함했다는 점에서 실제 산업 현장의 AI 적용 사례로 참고할 가치가 있다.

---

Google Labs, 실시간 공동 계획 도구 ‘Tabletop’ 공개…자연어로 여행 일정·투표·비용 정산용 인터랙티브 공간 생성

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 AI 제품, 협업 도구, 자연어 기반 앱 생성, 그룹 계획, 실시간 상호작용
• 원문: Google — Try Tabletop: Customizable, collaborative spaces for groups

---

Google Labs가 여러 사람이 하나의 화면에서 공동으로 계획을 세우고 상호작용할 수 있는 새로운 AI 실험 제품 Tabletop을 공개했다.

이번 서비스는 일반적인 챗봇과 조금 다른 접근을 사용한다.

사용자가 자연어로 원하는 작업을 설명하면 AI가 단순한 텍스트 답변 대신 여러 사람이 직접 사용할 수 있는 인터랙티브 작업 공간을 생성하도록 설계됐다.

예를 들어 친구들과 여행을 준비한다고 가정해 보자.

일반적인 AI 챗봇은 여행 일정을 글로 정리할 수 있다.

하지만 실제 여행에서는 여러 사람이 방문하고 싶은 장소에 투표하거나 비용을 나눠 계산해야 할 수 있다.

또한 일정이 변경되면 모든 참가자가 같은 정보를 확인해야 한다.

Tabletop은 이런 종류의 작업을 하나의 공유 공간에서 처리하도록 만든다.

자연어를 실제 상호작용 기능으로 변환

사용자는 Tabletop에 링크와 파일, 아이디어를 추가할 수 있다.

이후 @tabletop에 원하는 작업을 설명하거나 미리 제공된 템플릿을 선택할 수 있다.

Google이 소개한 대표적인 사용 사례는 다음과 같다.

이런 기능은 실제 사용자가 입력하거나 선택할 수 있는 형태로 생성된다.

예를 들어 여행 참가자가 특정한 식당에 투표할 수 있다.

다른 참가자는 공유된 공간에서 그 결과를 확인할 수 있다.

또한 공동 비용을 입력해 누가 얼마를 부담해야 하는지 계산할 수 있다.

이런 접근은 생성형 사용자 인터페이스(Generative UI)와 연결된다.

생성형 UI는 사용자가 요청한 목적에 맞춰 실제 화면과 상호작용 기능을 동적으로 구성하는 방식이다.

여러 사람이 동시에 사용

Tabletop은 생성된 작업 공간을 링크로 공유할 수 있도록 설계됐다.

다른 참가자는 해당 링크를 이용해 같은 공간에 참여할 수 있다.

Google은 Google Docs처럼 여러 사람이 동시에 작업하는 경험을 목표로 한다고 설명했다.

하지만 이번 발표만으로 실제로 생성된 모든 작업 공간이 복잡한 권한 관리와 데이터베이스 기능을 제공한다고 판단해서는 안 된다.

예를 들어 비용 정산 화면을 만들 수 있다는 사실이 실제 결제와 송금까지 자동으로 수행한다는 의미는 아니다.

Tabletop은 현재 Google Labs의 실험 제품이다.

미국의 만 18세 이상 사용자를 대상으로 대기자 명단을 통해 단계적으로 제공된다.

한국에서 일반적으로 즉시 사용할 수 있는 서비스는 아니다.

또한 Google은 이번 발표에서 실제 생성한 기능의 장기적인 정확성과 협업 안정성에 관한 독립적인 평가 수치를 제시하지 않았다.

이번 제품은 생성형 AI가 단순히 내용을 작성하는 기능에서 벗어나 사용자의 목적에 맞는 실제 상호작용 공간을 만들어 여러 사람이 함께 사용하도록 하는 방향을 보여준다.

---

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

Google, ‘Gemini Decision 1’과 Decisions API 출시…문장 생성 없이 최대 1,000개 판단을 한 번의 모델 계산으로 처리

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: AI 에이전트, 모델 라우팅, 함수 선택, 정책 검사, 멀티모달 분류, 개발자 API
• 원문: Google — Gemini Decisions API: Fast, calibrated multimodal decisions

---

Google이 새로운 판단 특화 모델 Gemini Decision 1과 전용 Decisions API를 공개했다.

이번 발표는 일반적인 대화형 언어모델을 하나 더 추가한 것이 아니다.

여러 선택지 가운데 어떤 결과가 적절한지 판단해야 하는 작업을 문장 생성 없이 직접 수행하도록 설계한 모델과 API를 제공한다는 점이 핵심이다.

예를 들어 고객지원 시스템이 있다고 가정해 보자.

사용자가 결제 오류에 관한 문의를 남겼다면 해당 문의를 결제 담당 부서로 전달해야 할 수 있다.

일반적인 언어모델에서는 모델이 자연어 문장으로 답변을 생성한다.

이후 프로그램은 생성된 문장을 다시 읽어 실제 분류 결과를 추출해야 한다.

하지만 실제로 필요한 것은 긴 문장이 아닐 수 있다.

미리 정의된 부서 가운데 어느 부서가 가장 적합한지에 관한 판단만 있으면 충분하다.

Gemini Decision 1은 이런 작업을 효율적으로 처리하도록 설계됐다.

토큰을 하나씩 생성하지 않고 선택지의 확률 계산

일반적인 언어모델은 다음 토큰을 하나씩 생성하는 방식으로 답변을 작성한다.

이를 자기회귀 생성(Autoregressive Generation)이라고 한다.

예를 들어 모델이 100토큰의 답변을 생성하려면 이전에 생성한 토큰을 참고하면서 계산을 반복해야 한다.

반면 Decisions API는 실제 답변 문장을 생성하지 않는다.

입력과 질문, 선택지를 바탕으로 각 선택지의 점수를 직접 계산한다.

이를 순전파(Forward Pass)라고 한다.

순전파는 입력 데이터를 모델에 전달해 실제 출력값을 계산하는 과정이다.

Google은 여러 판단을 하나의 순전파 과정에서 처리하도록 설계했다.

하나의 요청에는 최대 1,000개의 독립적인 질문을 포함할 수 있다.

세 가지 판단 유형

Decisions API는 세 가지 종류의 판단을 지원한다.

choice 유형은 2개에서 255개까지의 선택지를 지원한다.

score 유형은 정해진 순서가 있는 등급을 바탕으로 점수를 계산한다.

예를 들어 고객지원 문의의 긴급도를 0점에서 4점 사이로 평가할 수 있다.

각 판단에는 선택 결과와 관련 확률값이 포함된다.

이런 방식을 Closed-Set Decision(폐쇄형 선택지 판단)이라고 한다.

가능한 답변의 범위를 미리 정의하고 그 안에서 판단하는 방식이다.

텍스트뿐 아니라 이미지와 음성, 영상도 지원

Gemini Decision 1은 멀티모달 입력을 지원한다.

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

지원하는 입력에는 다음이 포함된다.

• 텍스트
• 이미지
• 음성
• 영상
• PDF 문서

최대 입력 길이는 25만6천 토큰이다.

예를 들어 보험회사가 고객의 사고 신고를 분석한다고 가정해 보자.

고객이 설명한 문장과 손상된 자동차의 사진, 관련 PDF 문서를 함께 전달할 수 있다.

모델은 필요한 정보가 포함됐는지, 어떤 종류의 사고인지, 추가적인 검토가 필요한지 등의 질문을 한 번에 평가할 수 있다.

하지만 여러 종류의 데이터를 처리할 수 있다는 사실과 실제 보험사고의 법적·금전적 판단을 정확하게 수행한다는 사실은 다르다.

중요한 결정에는 별도의 검증이 필요하다.

일반적인 언어모델 호출보다 낮은 지연시간

Google이 공개한 대표적인 성능은 다음과 같다.

지연시간(Latency)은 요청을 전달한 뒤 결과를 받기까지 걸리는 시간이다.

Google은 최대 1만6천 토큰의 입력과 1~100개 질문을 포함한 평가에서 모델의 내부 계산시간이 비교적 일정하게 유지됐다고 밝혔다.

또한 같은 평가 묶음에서 Gemini 3.5 Flash-Lite의 일반적인 Interactions API보다 약 다섯 배 저렴했다고 설명했다.

하지만 이 수치는 Google이 수행한 자체 비교다.

모든 입력과 모든 질문에서 같은 지연시간과 비용 차이가 발생하는 것은 아니다.

특히 매우 긴 입력과 복잡한 영상에서는 실제 처리시간이 달라질 수 있다.

확률을 반환한다고 실제 확신이 정확한 것은 아니다

이번 API는 각 판단의 확률과 신뢰도 점수를 제공한다.

하지만 모델이 특정한 선택지에 90%라는 확률을 부여했다고 해서 실제로 같은 조건에서 100번 가운데 90번 정답을 맞힌다는 의미는 아니다.

모델이 계산한 확률과 실제 정답 빈도가 얼마나 일치하는지는 별도의 검증이 필요하다.

이를 Calibration(확률 보정)이라고 한다.

Google은 여러 평가에서 Gemini Decision 1이 낮은 보정 오류를 기록했다고 설명했다.

하지만 이러한 성능은 Google의 자체 평가 결과다.

실제 서비스에서는 도메인별 검증 데이터를 이용해 판단의 정확성과 확률 분포를 확인해야 한다.

예를 들어 결제 사기 탐지처럼 잘못된 판단의 비용이 큰 작업에서는 낮은 확신도의 결과를 사람에게 전달할 수 있다.

또한 정상적인 거래가 잘못 차단되는 비율도 함께 측정해야 한다.

AI 에이전트의 도구 선택에 활용

이번 모델은 일반적인 분류 업무뿐 아니라 AI 에이전트의 내부 판단에도 활용할 수 있다.

예를 들어 에이전트가 여러 도구를 가지고 있다고 가정해 보자.

사용자가 어떤 작업을 요청했을 때 어떤 도구를 호출해야 하는지 결정해야 한다.

이때 대형 언어모델로 긴 추론 문장을 생성하는 대신 작은 판단 모델을 사용해 후보 도구의 적합도를 계산할 수 있다.

이를 Tool Routing(도구 라우팅)이라고 한다.

또한 사용자의 요청이 어떤 모델을 필요로 하는지 판단하는 Model Routing(모델 라우팅)에도 활용할 수 있다.

간단한 작업은 저렴한 모델에 전달하고 복잡한 작업은 더 강력한 모델에 전달하는 방식이다.

다만 모델이 도구를 선택할 수 있다는 사실과 실제 해당 도구를 호출할 권한이 있다는 사실은 다르다.

중요한 실행 권한은 실제 애플리케이션에서 별도로 검사해야 한다.

이번 발표는 AI 애플리케이션의 모든 작업을 긴 자연어 생성으로 해결하기보다 분류와 판단이 필요한 작업에는 전용 모델을 사용하는 방향이 강화되고 있음을 보여준다.

---

Google Cloud, AlloyDB에 ai.classify·ai.extract 추가…PostgreSQL 안에서 텍스트 분류와 JSON 추출 실행

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: PostgreSQL, AlloyDB, 생성형 AI, 데이터베이스, 텍스트 분류, 구조화된 정보 추출, SQL 기반 AI
• 원문: Google Cloud — Introducing new AI functions for AlloyDB: ai.classify and ai.extract

---

Google Cloud가 AlloyDB AI에 두 가지 새로운 SQL 함수인 ai.classify와 ai.extract를 프리뷰로 추가했다.

이번 발표는 새로운 데이터베이스 제품의 출시가 아니다.

기존 PostgreSQL 데이터베이스에 저장된 자연어 데이터를 별도의 애플리케이션 코드 없이 SQL 안에서 직접 분류하거나 구조화된 데이터로 변환할 수 있도록 만든 기능이다.

예를 들어 고객지원 시스템의 데이터베이스에 수백만 건의 문의가 저장돼 있다고 가정해 보자.

일부 문의에는 결제 문제에 관한 내용이 포함돼 있다.

다른 문의에는 배송 지연이나 계정 오류에 관한 설명이 포함돼 있을 수 있다.

일반적인 SQL에서는 특정한 단어가 포함된 행을 검색할 수 있다.

하지만 고객이 같은 문제를 서로 다른 표현으로 설명하면 단순한 문자열 검색만으로는 정확하게 분류하기 어렵다.

이런 상황에서 언어모델을 이용한 분류가 필요할 수 있다.

ai.classify: SQL 안에서 의미 기반 분류

ai.classify는 텍스트를 사용자가 지정한 범주 가운데 하나 이상으로 분류한다.

예를 들어 고객의 상품 후기를 긍정과 중립, 부정으로 구분할 수 있다.

개발자는 범주의 이름과 설명을 지정할 수 있다.

또한 특정한 범주가 어떤 의미인지 예시를 제공할 수 있다.

이를 Few-Shot Prompting(소수 예시 기반 지시)이라고 한다.

몇 개의 입력과 정답 예시를 제공해 모델이 원하는 판단 기준을 이해하도록 돕는 방법이다.

지원하는 주요 기능은 다음과 같다.

예를 들어 하나의 고객 문의가 배송 지연과 환불 요청을 동시에 포함할 수 있다.

이 경우 다중 분류를 사용하면 두 범주를 모두 반환하도록 할 수 있다.

ai.extract: 자유로운 문장을 JSON으로 변환

두 번째 기능인 ai.extract는 자연어 문장에서 필요한 정보를 추출해 JSON으로 반환한다.

JSON(JavaScript Object Notation)은 데이터를 키와 값의 형태로 표현하는 구조화된 형식이다.

예를 들어 고객지원 대화에는 주문번호와 고객 이름, 요청사항 등이 포함될 수 있다.

하지만 실제 문장에서는 정보의 순서가 일정하지 않을 수 있다.

어떤 고객은 주문번호를 먼저 작성할 수 있다.

다른 고객은 문제 상황을 설명한 뒤 마지막에 주문번호를 작성할 수 있다.

ai.extract는 필요한 데이터의 구조를 정의한 뒤 자연어에서 관련 정보를 추출하도록 만든다.

이때 사용하는 것이 JSON Schema(데이터 구조 명세)다.

예를 들어 주문번호는 문자열, 수량은 정수, 요청 유형은 특정한 값 가운데 하나로 정의할 수 있다.

모델은 해당 구조에 맞는 데이터를 생성하도록 설계됐다.

하지만 JSON의 형식이 올바르다는 사실과 실제 추출한 값이 원본 문서의 사실과 정확하게 일치한다는 사실은 다르다.

예를 들어 고객이 주문번호를 잘못 작성했다면 추출 프로그램은 원래 잘못된 번호를 그대로 가져올 수 있다.

또한 입력에 없는 정보를 모델이 추정할 가능성도 고려해야 한다.

따라서 실제 업무에 사용할 때는 데이터 유형과 필수값, 원본과의 일치 여부를 검증해야 한다.

데이터베이스에서 직접 AI를 호출

기존 방식에서는 애플리케이션이 데이터베이스에서 텍스트를 읽어야 했다.

이후 외부 AI API에 해당 텍스트를 전달한다.

모델이 반환한 결과를 프로그램에서 분석한 뒤 다시 데이터베이스에 저장하는 과정을 거칠 수 있다.

이런 구조에는 여러 번의 데이터 이동과 프로그램 코드가 필요하다.

이번 기능에서는 SQL 안에서 직접 AI 함수를 호출할 수 있다.

다만 이것이 언어모델 전체가 PostgreSQL 프로세스 내부에서 실행된다는 의미는 아니다.

실제 분류와 추출에는 연결된 Gemini 모델이 사용된다.

AlloyDB가 모델 호출과 결과 처리를 SQL 함수 형태로 관리하는 것이다.

따라서 민감한 데이터에 사용할 때는 실제 모델 호출의 데이터 처리 경로와 클라우드 보안 설정을 확인해야 한다.

Smart Batching으로 여러 행을 묶어 처리

Google은 여러 데이터 행을 효율적으로 처리하기 위한 Smart Batching 기능도 제공한다.

Batching(배치 처리)은 여러 입력을 하나의 묶음으로 처리하는 방법이다.

예를 들어 고객 문의 1,000건을 각각 별도의 모델 호출로 전달할 수 있다.

하지만 이 방식에서는 요청마다 반복되는 지침과 시스템 설정 때문에 추가 비용이 발생할 수 있다.

반면 여러 문의를 묶어서 처리하면 공통적인 입력을 반복해서 전달하는 부담을 줄일 수 있다.

AlloyDB는 SQL의 WHERE 조건 안에서 AI 함수를 사용할 때 입력을 적절한 작은 묶음으로 전달하도록 설계됐다.

Google은 이를 통해 행 단위 호출보다 지연시간과 토큰 비용을 줄일 수 있다고 설명한다.

하지만 이번 발표에서는 모든 데이터 크기와 쿼리에서 동일하게 적용되는 성능 개선 수치를 제시하지 않았다.

실제 성능은 입력 텍스트의 길이와 선택한 모델, 데이터베이스 쿼리의 구조에 따라 달라질 수 있다.

현재는 PostgreSQL 18 기반 프리뷰

이번 기능은 다음 환경에서 제공된다.

따라서 일반적인 모든 PostgreSQL 서버에서 같은 SQL 함수를 즉시 사용할 수 있다는 의미는 아니다.

또한 프리뷰 단계에서는 실제 기능과 제공 조건이 변경될 수 있다.

이번 발표는 생성형 AI를 이용한 데이터 처리가 애플리케이션의 별도 로직에서 데이터베이스의 기본적인 분석 기능으로 확대되는 방향을 보여준다.

특히 고객지원과 문서 분석처럼 대량의 자연어 데이터를 정해진 업무 구조로 변환해야 하는 시스템에서 활용 가능성이 있다.

---

4️⃣ 산업·정책·안전

NVIDIA, AI 모델·에이전트의 실제 실행 상태를 추적하는 AIBOM 통합 공개…Kubernetes 기반 AI 공급망 관리 강화

• 발표일: 2026-11-11 — 정확한 게시 시각 미확인
• 적용 범위: AI 인프라, Kubernetes, AI 공급망 보안, 모델 추적, 거버넌스, NVIDIA AI Cluster Runtime, 오픈소스
• 원문: NVIDIA — Validating GPU Platforms with Runtime AI Inventory via the NVIDIA DSX AI Factory

---

NVIDIA가 AI 인프라에서 실제 실행 중인 모델과 애플리케이션의 구성을 추적하기 위한 AIBOM(AI Bill of Materials) 기술을 자사의 GPU 클러스터 배포 도구에 통합했다고 발표했다.

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

기업이 AI 서버에 어떤 모델과 추론 엔진, 외부 API가 배포돼 있는지 실제 운영 상태를 기준으로 확인할 수 있도록 만든 인프라 보안 기능이다.

최근 기업에서는 여러 종류의 AI 모델을 동시에 사용할 수 있다.

예를 들어 고객지원 시스템에는 하나의 언어모델이 연결돼 있을 수 있다.

문서 검색 시스템에는 별도의 임베딩 모델이 존재할 수 있다.

또한 일부 에이전트는 외부 AI API를 호출할 수도 있다.

문제는 이런 구성이 시간이 지나면서 변경될 수 있다는 점이다.

처음 배포한 모델의 버전과 실제로 실행 중인 모델의 버전이 달라질 수도 있다.

또한 개발자가 별도로 만든 AI 애플리케이션이 조직의 공식 관리 목록에 등록되지 않을 가능성도 있다.

NVIDIA는 이런 문제를 해결하기 위해 실제 운영 상태를 추적하는 시스템을 통합했다.

SBOM에서 AIBOM으로

소프트웨어 보안에서는 오래전부터 SBOM(Software Bill of Materials)이라는 개념이 사용돼 왔다.

SBOM은 하나의 소프트웨어가 어떤 라이브러리와 구성요소를 사용하는지 정리한 목록이다.

예를 들어 웹 애플리케이션이 특정한 버전의 오픈소스 라이브러리를 사용한다고 가정해 보자.

이후 해당 라이브러리에서 보안 취약점이 발견될 수 있다.

SBOM이 있다면 어떤 애플리케이션이 영향을 받을 수 있는지 비교적 빠르게 확인할 수 있다.

하지만 AI 애플리케이션에는 일반적인 소프트웨어와 다른 구성요소가 존재한다.

예를 들어 같은 추론 엔진을 사용하더라도 서로 다른 AI 모델의 가중치를 불러올 수 있다.

외부 AI API의 모델 이름과 버전도 변경될 수 있다.

또한 RAG 시스템에서는 벡터 데이터베이스나 임베딩 모델이 별도로 사용될 수 있다.

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

AIBOM은 이런 AI 특화 구성요소를 정리한다.

실행 중인 AI 구성요소 추적

NVIDIA는 Google이 개발한 오픈소스 프로젝트 k8s-aibom을 이용했다.

이 프로젝트는 Kubernetes 환경의 AI 작업을 관찰하고 관련 정보를 기록한다.

Kubernetes는 여러 서버에서 애플리케이션을 배포하고 관리하는 플랫폼이다.

k8s-aibom은 실제 Kubernetes의 작업 정의를 분석해 어떤 AI 관련 구성요소가 존재하는지 확인한다.

예를 들어 다음 정보를 기록할 수 있다.

이를 통해 기업은 실제 AI 모델의 구성이 원래 승인한 내용과 같은지 비교할 수 있다.

예를 들어 기존에 승인한 모델의 가중치가 변경됐거나 새로운 외부 API가 추가됐다면 해당 변화를 검토할 수 있다.

다만 이번 시스템이 모든 종류의 AI 애플리케이션을 자동으로 발견하는 것은 아니다.

현재 인식할 수 있는 Kubernetes 작업 유형과 AI 관련 신호가 존재하는 경우에 한해 목록을 생성한다.

배포하려던 구성과 실제 실행 구성을 비교

NVIDIA는 AICR(NVIDIA AI Cluster Runtime)과 k8s-aibom을 결합했다.

AICR은 GPU 클러스터에 필요한 소프트웨어와 설정을 정해진 버전으로 관리하는 도구다.

예를 들어 어떤 모델과 추론 엔진, 드라이버와 Kubernetes 구성요소를 사용할지 배포 명세에 기록할 수 있다.

이런 명세는 처음 배포할 때 유용하다.

하지만 실제 운영 중에는 새로운 버전이 설치되거나 설정이 변경될 수 있다.

따라서 처음 계획한 상태와 현재 실제 상태를 구분해야 한다.

NVIDIA는 이를 다음처럼 나누어 설명한다.

AICR은 어떤 구성을 배포하려 했는지 기록한다.

k8s-aibom은 현재 어떤 AI 작업이 선언되거나 실행되도록 구성돼 있는지 관찰한다.

두 정보를 비교하면 승인되지 않은 변경사항을 발견하는 데 도움이 될 수 있다.

이를 Configuration Drift(구성 드리프트)라고 한다.

처음 승인한 설정과 실제 운영 상태 사이에 차이가 발생하는 현상이다.

AI 구성의 신뢰도를 네 단계로 표현

이번 시스템은 발견한 정보를 모두 같은 수준의 사실로 취급하지 않는다.

대신 정보의 신뢰도를 구분한다.

예를 들어 특정한 모델의 이름이 실행 명령의 입력값에 포함돼 있을 수 있다.

이 경우 해당 모델이 사용되도록 선언됐다는 사실은 확인할 수 있다.

하지만 실제 모델의 가중치가 정확히 해당 버전인지까지 검증됐다고 판단해서는 안 된다.

이를 확인하려면 모델의 서명이나 해시값 등을 이용한 추가 검증이 필요할 수 있다.

해시(Hash)는 입력 데이터에서 일정한 길이의 값을 계산하는 방법이다.

동일한 파일을 다시 검사할 때 내용이 변경됐는지 확인하는 데 사용할 수 있다.

NVIDIA는 이런 신뢰도 구분을 통해 실제 운영 자료의 근거를 추적하도록 지원한다.

실제 실행 성공과 AIBOM 생성은 다르다

이번 글에서 특히 중요한 제한은 AIBOM이 생성됐다고 해서 실제 AI 프로그램이 정상적으로 실행됐다는 의미는 아니라는 사실이다.

예를 들어 Kubernetes에 특정한 모델 서버의 배포 명세를 등록했다고 가정해 보자.

아직 컨테이너 이미지를 다운로드하는 중일 수 있다.

또는 GPU 자원이 부족해 실제 프로그램을 시작하지 못했을 수도 있다.

그런데 k8s-aibom은 배포 명세를 확인해 AIBOM을 생성할 수 있다.

따라서 AIBOM이 존재한다는 사실과 실제 서비스가 정상적으로 실행됐다는 사실은 구분해야 한다.

실제 실행 성공 여부는 별도의 상태 검사와 로그를 통해 확인해야 한다.

실제 운영 오버헤드 평가

NVIDIA는 Google Kubernetes Engine에서 k8s-aibom의 자원 사용량을 측정한 결과도 공개했다.

이 결과는 특정한 시험 환경에서 측정한 수치다.

해당 시험에서는 실제 GPU 작업이 실행되지 않고 대기 중인 상태도 포함됐다.

따라서 모든 대규모 AI 클러스터에서 같은 자원 사용량이 유지된다는 의미는 아니다.

또한 NVIDIA는 AIBOM의 기록 자체에 별도의 암호학적 서명이 기본으로 적용되는 것은 아니라고 설명했다.

서명과 실제 공급망 검증 기능을 연결하는 작업은 추가적인 구성 또는 향후 개발이 필요하다.

관찰 대상과 접근권한 관리

k8s-aibom은 기록을 생성할 Kubernetes 네임스페이스를 선택하도록 지원한다.

Namespace(네임스페이스)는 Kubernetes에서 관련 자원을 논리적으로 구분하는 단위다.

예를 들어 운영 서비스와 개발용 서비스를 별도의 네임스페이스에 배치할 수 있다.

하지만 이번 구현에는 주의할 부분이 있다.

기록 생성 대상을 특정 네임스페이스로 제한하더라도 컨트롤러 자체는 클러스터 전체의 작업 명세를 읽을 수 있다.

따라서 어떤 네임스페이스에서 기록을 생성하는지와 컨트롤러가 실제로 접근 가능한 정보의 범위를 구분해야 한다.

NVIDIA는 기본적으로 외부 데이터 전송 대상과 Kubernetes Secret 접근권한을 설정하지 않는다고 설명했다.

하지만 실제 기업 환경에서는 접근권한과 데이터 보관 정책을 별도로 확인해야 한다.

이번 발표는 AI 인프라의 보안이 기존 소프트웨어의 취약점 관리에서 벗어나 실제로 어떤 모델이 어디에서 실행되고 있으며 어떤 외부 시스템과 연결되는지 추적하는 문제로 확대되고 있음을 보여준다.

---

📚 추천 글

Token Pooling-Aware Training for Multi-Vector Embedding Models

• 저자: Tom Aarsen
• 발행: Hugging Face / Sentence Transformers
• 게시일: 2026-11-11
• 원문: Hugging Face — Token Pooling-Aware Training for Multi-Vector Embedding Models

---

검색 품질을 유지하면서 AI 검색 시스템의 저장공간을 줄일 수 있을까?

이번 글은 여러 벡터를 이용해 문서를 검색하는 모델에서 문서당 저장하는 벡터의 수를 줄이면서 검색 정확도를 최대한 유지하는 방법을 설명한다.

특히 단순히 벡터를 압축하는 알고리즘을 소개하는 데서 끝나지 않고, 압축될 것을 고려해 모델 자체를 학습시키는 방식을 실제 실험으로 검증했다는 점에서 읽어볼 가치가 있다.

임베딩 모델은 무엇인가

임베딩(Embedding)은 문장이나 이미지 등의 의미를 여러 숫자로 표현한 것이다.

예를 들어 사용자가 빨간 행성이라는 표현을 검색했다고 가정해 보자.

관련 문서에는 화성이라는 단어가 포함돼 있을 수 있다.

일반적인 문자열 검색에서는 정확히 같은 단어가 없으면 관련 문서를 찾기 어려울 수 있다.

반면 임베딩 기반 검색은 단어가 달라도 의미적으로 관련된 문서를 찾을 수 있다.

이런 방식은 RAG에서 널리 사용된다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 문서를 검색한 뒤 해당 문서를 언어모델의 입력에 제공하는 기술이다.

검색 품질이 낮으면 언어모델이 아무리 강력하더라도 필요한 정보를 찾지 못할 수 있다.

따라서 검색용 임베딩 모델의 성능도 중요하다.

하나의 문서를 여러 벡터로 표현

일반적인 임베딩 모델은 하나의 문서를 하나의 벡터로 표현할 수 있다.

하지만 Multi-Vector Embedding(다중 벡터 임베딩) 모델은 하나의 문서를 여러 벡터로 표현한다.

예를 들어 문서의 각 토큰마다 별도의 벡터를 만들 수 있다.

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

이 방식의 장점은 문서의 여러 부분을 세밀하게 비교할 수 있다는 것이다.

예를 들어 긴 기술 문서에서 특정한 오류 코드와 관련된 짧은 문장만 검색하려는 상황을 생각할 수 있다.

문서 전체를 하나의 벡터로 압축하면 일부 세부 정보가 사라질 수 있다.

반면 여러 벡터를 사용하면 특정한 토큰과 관련된 정보를 더 정확하게 찾을 가능성이 있다.

하지만 단점도 있다.

문서 하나가 200개의 벡터로 표현된다면 문서 100만 개는 약 2억 개의 벡터를 저장해야 할 수 있다.

이는 검색 인덱스의 저장공간과 계산 비용을 증가시킨다.

비슷한 토큰 벡터를 하나로 합치기

이번 글에서 소개한 방법은 Token Pooling(토큰 풀링)이다.

토큰 풀링은 서로 비슷한 벡터를 묶어 더 적은 수의 벡터로 표현하는 기술이다.

예를 들어 하나의 문서가 200개 벡터로 구성돼 있다고 가정해 보자.

이 가운데 의미적으로 매우 비슷한 벡터들을 묶어 50개로 줄일 수 있다.

이렇게 하면 저장해야 할 벡터의 수가 75% 감소한다.

하지만 문제도 존재한다.

서로 비슷해 보이는 토큰이 실제 검색에서는 중요한 차이를 만들 수 있기 때문이다.

예를 들어 특정한 전문용어와 유사한 일반적인 단어가 하나로 합쳐지면 정확한 문서 검색이 어려워질 수 있다.

따라서 무조건 많은 벡터를 합치는 것보다 어떤 정보를 유지해야 하는지 학습하는 과정이 중요하다.

압축된 벡터로도 올바르게 검색하도록 학습

Tom Aarsen은 이를 해결하기 위해 두 가지 검색 손실을 함께 계산했다.

첫 번째는 원래의 전체 벡터를 사용해 문서를 검색하는 경우다.

두 번째는 일부 벡터를 합쳐 압축한 뒤 검색하는 경우다.

Loss(손실)는 모델이 생성한 결과와 실제 목표 사이의 차이를 수치로 표현한 것이다.

모델은 두 종류의 손실을 동시에 줄이도록 학습한다.

이렇게 하면 원래의 전체 벡터로 검색하는 능력을 유지하면서도 압축 후의 검색 품질을 개선할 수 있다.

이 접근은 Pooling-Aware Training(풀링을 고려한 학습)이라고 할 수 있다.

실험에는 ModernBERT-base 모델이 사용됐다.

연구자는 같은 초기 모델과 같은 학습 데이터를 사용해 두 모델을 비교했다.

첫 번째는 일반적인 검색 손실만 학습한 모델이다.

두 번째는 전체 벡터와 압축된 벡터의 검색 손실을 함께 학습한 모델이다.

학습에는 MS MARCO의 약 12만 개 문서·질문 관련 데이터가 사용됐다.

벡터 수 74.8% 감소하면서 검색 성능 대부분 유지

연구자가 공개한 대표 결과는 다음과 같다.

nDCG@10은 검색 결과의 상위 10개 문서가 실제 관련성에 따라 얼마나 올바르게 정렬됐는지 평가하는 지표다.

점수가 높을수록 관련된 문서가 검색 결과의 앞부분에 더 잘 배치됐다는 의미다.

풀링을 고려해 학습한 모델은 벡터 수를 약 75% 줄이면서도 기존 검색 성능의 약 97.8%를 유지했다.

반면 일반적으로 학습한 모델은 같은 압축 조건에서 94.6%를 유지했다.

또한 압축하지 않은 상태에서도 풀링 고려 학습 모델이 조금 더 높은 점수를 기록했다.

하지만 이 결과는 연구자가 수행한 특정한 모델과 검색 데이터셋에서 얻어졌다.

모든 검색 모델과 실제 업무 문서에서 같은 성능이 나타난다는 의미는 아니다.

실제 검색 시스템에서는 계산 비용도 고려

이번 연구는 벡터 저장공간을 줄이는 것에 초점을 맞췄다.

하지만 실제 검색 시스템의 전체 비용에는 다른 요소도 존재한다.

예를 들어 문서를 처음 임베딩으로 변환하는 시간이 필요하다.

이후 압축할 벡터를 선택해야 한다.

또한 실제 사용자가 검색할 때 여러 문서의 관련성을 계산해야 한다.

연구자는 벡터를 묶는 과정에 Ward Clustering을 사용했다.

Ward Clustering은 서로 비슷한 데이터를 단계적으로 합치는 군집화 방법이다.

이 작업을 GPU에서 수행하도록 최적화한 결과 기존 SciPy 기반 CPU 구현보다 30~150배 빠른 군집화 계산을 관찰했다고 밝혔다.

하지만 이는 군집화 단계의 속도를 비교한 수치다.

전체 검색 서비스의 응답시간이 30~150배 빨라진다는 의미는 아니다.

실제 서비스에서는 검색 인덱스 생성과 메모리, 데이터베이스의 구조도 함께 고려해야 한다.

이번 글은 RAG와 검색 시스템을 개발할 때 더 큰 임베딩 모델을 사용하는 것뿐 아니라 저장해야 하는 데이터의 표현 방식 자체를 개선하는 접근이 중요할 수 있음을 보여준다.

---

MotionGraphicsBench: Evaluating Motion Graphics Generation with Programmatic Verification

• 저자: Jiaju Ma, Ashvini Kumar Jindal, Chuhua Wang, Sumithra Bhakthavatsalam
• 발행: Figma / Stanford University / Hugging Face
• 게시일: 2026-11-10
• 원문: Hugging Face — MotionGraphicsBench: Evaluating Motion Graphics Generation with Programmatic Verification

---

AI에게 실제로 움직이는 그래픽을 만들어 달라고 요청했을 때 어떤 기준으로 결과를 평가해야 할까?

예를 들어 사용자가 가위 그림을 제공하고 가위가 닫혔다가 다시 열리는 애니메이션을 만들어 달라고 요청했다고 가정해 보자.

AI는 JavaScript 코드를 생성할 수 있다.

하지만 코드가 오류 없이 실행된다는 사실만으로 가위가 실제로 올바르게 움직인다는 의미는 아니다.

가위의 날이 이상한 방향으로 회전할 수 있다.

또는 닫히기는 하지만 다시 열리지 않을 수도 있다.

이번 글은 이런 문제를 평가하기 위한 MotionGraphicsBench를 소개한다.

특히 실제 그래픽 애니메이션을 생성한 뒤 컴퓨터가 결과의 움직임을 수치적으로 검사하도록 만든 평가 방식이 흥미롭다.

기존 코딩 벤치마크와 다른 점

일반적인 코딩 벤치마크에서는 프로그램이 예상한 결과를 반환하는지 검사할 수 있다.

예를 들어 숫자를 정렬하는 함수를 작성했다면 출력값이 올바른지 확인할 수 있다.

하지만 애니메이션에서는 결과가 시간에 따라 달라진다.

예를 들어 물체가 왼쪽에서 오른쪽으로 이동해야 한다면 시작 위치와 마지막 위치뿐 아니라 이동하는 과정도 중요하다.

움직임의 속도와 회전 방향, 물체 사이의 상대적인 위치도 고려해야 할 수 있다.

MotionGraphicsBench는 이런 특징을 평가한다.

연구팀은 100개의 애니메이션 작업을 준비했다.

각 작업에는 기존 SVG 그림과 원하는 움직임을 설명하는 자연어 지시가 포함된다.

SVG(Scalable Vector Graphics)는 점과 선, 도형의 좌표로 그래픽을 표현하는 형식이다.

일반적인 비트맵 이미지와 달리 확대해도 선명한 형태를 유지할 수 있다.

AI는 제공된 SVG 요소를 이용해 실제 애니메이션을 생성하는 JavaScript 코드를 작성해야 한다.

32개 모델을 같은 조건에서 평가

연구팀은 12개 제공업체의 32개 AI 모델을 평가했다.

모델마다 여러 종류의 추론 설정을 사용해 총 47개 모델·설정 조합을 비교했다.

전체 생성 시도는 5만1천200회였다.

모든 모델에는 GSAP이라는 애니메이션 라이브러리를 사용하도록 했다.

GSAP은 웹에서 요소의 이동과 회전, 크기와 투명도 변화를 제어하는 데 사용하는 JavaScript 라이브러리다.

이렇게 하면 서로 다른 모델이 같은 실행 환경에서 애니메이션을 생성하도록 비교할 수 있다.

이후 실제 브라우저에서 코드를 실행하고 여러 시점의 SVG 상태를 추출했다.

움직임을 프로그램으로 직접 검사

이번 벤치마크의 중요한 특징은 결과를 다른 AI 모델에게 보여주고 단순히 좋은지 나쁜지 판단하도록 맡기지 않았다는 점이다.

대신 각 작업에 별도의 검증 프로그램을 작성했다.

예를 들어 가위 애니메이션에서는 다음 조건을 검사할 수 있다.

첫 번째는 가위의 두 날이 서로 가까워지는지다.

두 번째는 닫히는 과정에서 두 날의 방향과 겹침이 적절한지다.

세 번째는 다시 원래의 열린 상태로 돌아오는지다.

이 세 조건 가운데 하나라도 만족하지 못하면 해당 작업을 실패로 처리한다.

이런 방식은 Programmatic Verification(프로그램 기반 검증)이라고 한다.

실제 실행 결과를 수치와 규칙으로 검사하는 방법이다.

특히 모델이 애니메이션을 만들었다고 설명하더라도 실제 화면에서 요구사항을 만족하지 못하면 성공으로 인정하지 않는다.

최고 성능 모델도 첫 시도 성공률 67.7%

공개된 대표적인 결과는 다음과 같다.

Pass@1은 한 번의 생성 시도에서 작업을 성공할 비율이다.

가장 높은 점수를 기록한 모델도 첫 번째 시도에서 약 3분의 1의 작업을 실패했다.

또한 47개 평가 설정 가운데 최고 추론 강도를 사용했을 때 첫 시도 성공률이 50%를 넘는 모델은 네 개에 불과했다.

이는 일반적인 코드 작성 능력이 높더라도 실제로 움직이는 그래픽을 생성하는 작업은 별도의 어려움을 가지고 있음을 보여준다.

여러 번 생성하면 성공률이 높아지지만 비용도 증가

연구팀은 같은 작업을 여러 번 독립적으로 생성했을 때의 결과도 평가했다.

이를 Pass@k라고 한다.

최대 k번의 시도 가운데 적어도 한 번 성공한 경우를 측정하는 지표다.

15개 모델을 대상으로 32번의 독립적인 생성을 허용했을 때 평균 성공률은 다음처럼 변했다.

하지만 이 결과를 실제 에이전트가 실패를 확인하면서 32번 수정했다는 의미로 해석해서는 안 된다.

연구에서는 이전 시도의 결과를 다음 생성에 제공하지 않았다.

서로 독립적으로 같은 작업을 반복한 것이다.

따라서 이 수치는 반복 생성으로 성공한 결과를 얻을 가능성을 나타낸다.

실제 애플리케이션에서는 여러 번 생성할수록 모델 호출 비용과 평가 시간이 증가한다.

이번 글은 AI가 만든 코드를 평가할 때 코드가 실행되는가와 실제 사용자가 요구한 움직임을 정확하게 구현했는가는 서로 다른 문제라는 점을 보여준다.

특히 프런트엔드와 애니메이션, 시각적 결과물을 생성하는 AI 에이전트의 평가 방법을 이해하는 데 유용하다.

---

Bring Your Own Expert! Extending MoE Models with New Domain Expertise

• 저자: Fabian Klemm, Lars Reimann, Andreas Rabenstein, Henrik Klagges 외 TNG 연구진
• 발행: TNG Technology Consulting / Hugging Face
• 게시일: 2026-11-10
• 원문: Hugging Face — Bring Your Own Expert! Extending MoE Models with New Domain Expertise

---

기존 언어모델의 일반적인 능력을 유지하면서 특정한 프로그래밍 언어에 대한 능력만 강화할 수 있을까?

예를 들어 기업에서 특정한 오픈웨이트 모델을 사용한다고 가정해 보자.

해당 모델은 일반적인 웹 개발과 문서 작성에 충분한 성능을 제공할 수 있다.

하지만 Rust나 Haskell 같은 특정한 프로그래밍 언어의 코드를 생성하는 능력은 상대적으로 낮을 수 있다.

이 경우 전체 모델을 다시 학습시킬 수 있다.

하지만 새로운 데이터로 추가 학습하는 과정에서 기존의 다른 능력이 저하될 가능성도 있다.

이를 Catastrophic Forgetting(파국적 망각)이라고 한다.

새로운 정보를 학습하는 과정에서 기존에 학습한 능력이 약화되는 현상이다.

이번 글은 이를 해결하기 위해 MoE 모델에 새로운 전문 네트워크를 추가하는 방법을 소개한다.

MoE의 구조를 이용한 전문 지식 추가

MoE(Mixture of Experts)는 여러 전문 신경망 가운데 필요한 일부만 선택적으로 실행하는 모델 구조다.

예를 들어 하나의 모델에 수십 개의 전문가 네트워크가 존재할 수 있다.

하지만 실제로 하나의 토큰을 처리할 때는 그 가운데 일부만 활성화된다.

이때 어떤 전문가를 사용할지 선택하는 구성요소를 Router(라우터)라고 한다.

일반적인 언어모델의 추가 학습에서는 기존 가중치를 수정한다.

반면 이번 연구에서는 기존 전문가의 가중치를 변경하지 않는다.

대신 새로운 전문가를 추가한다.

예를 들어 Rust 코드 생성에 특화된 전문가 하나를 추가할 수 있다.

이후 라우터가 Rust 관련 입력에서 해당 전문가를 선택하도록 학습시킨다.

이런 접근은 기존 능력을 유지하면서 새로운 전문 능력을 추가하려는 구조적 확장이다.

새로운 전문가를 그냥 추가하면 사용되지 않을 수 있다

이번 연구의 중요한 문제는 새로운 전문가의 초기 상태였다.

예를 들어 아무것도 학습하지 않은 새 전문가를 모델에 추가했다고 가정해 보자.

처음에는 기존 전문가보다 결과가 좋지 않을 수 있다.

이 경우 라우터는 새로운 전문가를 거의 선택하지 않을 수 있다.

전문가가 선택되지 않으면 충분한 학습 기회를 얻기 어렵다.

이를 Cold-Start Problem(초기 학습 기회 부족 문제)이라고 할 수 있다.

TNG는 이를 해결하기 위해 기존 전문가 가운데 자주 사용되는 전문가의 가중치를 복사해 새로운 전문가를 초기화했다.

또한 새 전문가에 대응하는 라우터의 가중치도 기존 전문가에서 복사했다.

이후 잠시 라우터를 고정한 상태에서 새로운 전문가를 학습시켰다.

이렇게 하면 새 전문가가 실제로 유용한 기능을 익히기 전에 라우터가 해당 전문가를 사용하지 않도록 결정하는 문제를 줄일 수 있다.

Rust와 Haskell에 특화된 전문가 학습

연구팀은 Qwen3.5-35B-A3B 모델을 기반으로 실험했다.

약 1억2천500만 파라미터의 새로운 전문가를 추가했다.

첫 번째 전문가는 Rust 코드 생성에 특화됐다.

두 번째 전문가는 Haskell 코드 생성에 특화됐다.

학습에는 The Stack 데이터셋의 관련 언어 코드가 사용됐다.

The Stack은 여러 프로그래밍 언어의 공개 소스코드를 포함하는 데이터셋이다.

연구팀은 NVIDIA B200 GPU 8개를 이용해 학습했다.

하나의 언어에 특화된 전문가를 학습하는 데 약 반나절이 필요했다고 설명했다.

하지만 이는 해당 연구팀의 하드웨어와 학습 설정에서 측정한 시간이다.

다른 종류의 모델과 데이터셋에서도 같은 시간이 필요하다는 의미는 아니다.

실제 코드 생성 성능 개선

연구팀이 공개한 대표 결과는 다음과 같다.

Pass@1은 한 번의 코드 생성 시도에서 정해진 평가를 성공할 비율이다.

Rust 전문가를 추가한 경우 성공률은 62%에서 73%로 높아졌다.

Haskell 전문가를 추가한 경우에는 32%에서 51%로 높아졌다.

특히 두 전문가를 각각 독립적으로 학습한 뒤 하나의 모델에 결합해도 상당한 성능 향상이 유지됐다.

이런 방식에서는 여러 전문가를 처음부터 함께 학습할 필요를 줄일 수 있다.

하지만 이번 결과는 특정한 프로그래밍 언어와 평가 데이터에서 얻어졌다.

모든 종류의 전문 지식을 같은 방법으로 추가할 수 있다는 의미는 아니다.

또한 전문가의 수가 계속 증가하면 모델의 전체 저장공간도 증가할 수 있다.

LoRA와 무엇이 다른가

일반적인 모델 추가 학습에는 LoRA(Low-Rank Adaptation)가 자주 사용된다.

LoRA는 기존 가중치에 작은 추가 행렬을 학습하는 방식이다.

전체 모델을 다시 학습하는 것보다 필요한 계산 자원을 줄일 수 있다.

하지만 서로 다른 작업에 맞게 학습한 여러 LoRA를 하나로 합치면 문제가 발생할 수 있다.

예를 들어 Rust용 LoRA와 Haskell용 LoRA를 각각 학습했다고 가정해 보자.

두 LoRA를 단순히 병합하면 서로 다른 업데이트가 충돌할 가능성이 있다.

반면 새로운 MoE 전문가를 추가하는 방법에서는 각 전문 네트워크를 별도로 유지한다.

라우터가 필요에 따라 해당 전문가를 선택하도록 만들 수 있다.

이번 연구에서는 실제로 LoRA를 병합한 경우보다 새로운 전문가를 결합한 방식이 더 좋은 결과를 기록했다.

하지만 새로운 전문가를 추가하는 방법에도 비용이 존재한다.

기존 모델의 구조와 전문가 수를 변경해야 하므로 메모리 사용량과 실제 추론 성능에 영향을 줄 수 있다.

따라서 특정한 작업에만 사용한다면 LoRA가 더 단순하고 경제적인 선택일 수도 있다.

이번 글은 AI 모델의 추가 학습이 기존 가중치를 수정하는 방식뿐 아니라 새로운 능력을 가진 전문 네트워크를 별도로 추가하는 방식으로도 발전하고 있음을 보여준다.

특히 기업이 기존 오픈웨이트 모델에 특정한 업무 지식을 추가하려는 상황에서 참고할 만한 기술 자료다.

---

How lemonflow built real-time agents for EV charging using Gemma and TPUs

• 저자: Dr. Lukas Fieber, Konstantin Huneke
• 발행: lemonflow / Google Cloud
• 게시일: 2026-11-11
• 원문: Google Cloud — How lemonflow built real-time agents for EV charging using Gemma and TPUs

---

AI 음성 에이전트가 실제 고객지원 업무를 수행하려면 무엇이 가장 중요할까?

일반적으로는 모델이 사용자의 질문을 얼마나 정확하게 이해하는지 생각하기 쉽다.

하지만 실제 음성 고객지원에서는 응답시간과 연결 안정성, 외부 장비의 상태를 정확하게 확인하는 능력도 중요하다.

예를 들어 전기자동차 운전자가 충전소에서 충전을 시작하려는데 문제가 발생했다고 가정해 보자.

사용자는 AI에게 충전기가 왜 작동하지 않는지 질문할 수 있다.

AI는 실제 충전기의 상태를 확인해야 한다.

또한 어떤 충전 사업자의 장비인지 파악하고 필요한 절차를 안내해야 한다.

그런데 AI의 응답이 너무 느리면 사용자가 말을 중간에 끊거나 통화를 종료할 수 있다.

이번 글은 유럽의 전기차 충전 지원 기업 lemonflow가 이런 문제를 실제 서비스에서 해결한 과정을 설명한다.

특히 기존의 관리형 모델 API에서 자체 운영하는 Gemma 모델과 TPU 인프라로 이동한 이유, 실제 운영 결과를 자세하게 공개했다는 점에서 읽어볼 가치가 있다.

90개 이상의 언어로 충전 문제 지원

lemonflow는 전기차 충전 과정에서 발생하는 고객지원 문제를 처리하는 AI 에이전트를 개발한다.

지원하는 언어는 90개 이상이다.

회사에 따르면 약 90초마다 한 명의 전기차 운전자가 AI 지원 서비스를 이용한다.

전기차 충전 과정에서는 여러 종류의 문제가 발생할 수 있다.

예를 들어 충전기가 차량을 인식하지 못할 수 있다.

결제 승인이 실패할 수도 있다.

또는 충전이 시작됐지만 실제 전력이 공급되지 않을 수 있다.

문제는 충전 사업자마다 사용하는 시스템과 장비의 통신 방식이 다를 수 있다는 점이다.

따라서 하나의 AI 에이전트가 여러 사업자의 실제 데이터를 조회하려면 관련 시스템을 표준화해 연결해야 한다.

lemonflow는 이런 기능을 자체 플랫폼에서 관리한다.

관리형 API에서는 응답시간이 불안정

회사는 처음에 외부의 관리형 언어모델 API를 사용했다.

하지만 실제 음성 서비스에서 문제가 발생했다.

평소에는 약 1.0~1.2초 수준이었던 응답 지연이 사용량이 많은 시간에는 1.7초 이상으로 증가할 수 있었다.

또한 요청량 제한 때문에 HTTP 429 오류가 발생하기도 했다.

HTTP 429는 클라이언트가 허용된 요청 횟수를 초과했을 때 서버가 반환할 수 있는 응답 코드다.

음성 서비스에서는 이런 지연이 실제 사용자 경험에 영향을 준다.

예를 들어 사용자가 질문한 뒤 1초 이상 아무 응답이 없다면 시스템이 말을 알아듣지 못했다고 생각할 수 있다.

이후 같은 질문을 다시 말하거나 AI의 답변을 중간에 끊을 수 있다.

이를 Barge-in(사용자의 대화 중 끼어들기)이라고 한다.

lemonflow는 내부 시험에서 응답 지연이 약 800ms를 넘으면 이런 문제가 증가할 수 있다고 판단했다.

자체 운영하는 Gemma와 TPU로 전환

lemonflow는 이를 해결하기 위해 Gemma 4 모델을 Google Cloud TPU v6e에서 자체 운영하는 구조로 변경했다.

TPU(Tensor Processing Unit)는 Google이 AI 계산을 위해 개발한 반도체다.

자체 운영한다는 것은 외부 모델 API에 모든 요청을 전달하는 대신 회사가 직접 모델 실행 환경을 관리한다는 의미다.

이를 Self-Hosting(자체 호스팅)이라고 한다.

이렇게 하면 어떤 버전의 모델을 사용하는지와 실제 서버의 자원 배분, 응답 요청의 우선순위를 더 직접적으로 관리할 수 있다.

또한 모델의 실행 설정을 자체적으로 최적화할 수 있다.

lemonflow는 vLLM 기반의 추론 환경을 조정하고 TPU 메모리와 서버 메모리 사이에서 모델의 상태를 관리하는 방식을 적용했다.

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

회사는 실시간 음성 통화를 가장 우선적으로 처리하도록 요청 라우터를 만들었다.

웹 채팅은 그다음으로 처리한다.

반면 즉시 처리할 필요가 없는 테스트와 시뮬레이션은 사용량이 적은 시간에 실행한다.

이렇게 하면 실제 고객의 음성 통화가 내부 실험 때문에 지연되는 문제를 줄일 수 있다.

실제 장비의 제어 규칙과 언어모델 분리

이번 사례에서 중요한 부분은 AI가 모든 장비의 규칙을 자연어로 판단하도록 맡기지 않았다는 사실이다.

예를 들어 충전 사업자마다 실제 장비의 상태를 확인하는 API가 다를 수 있다.

또한 충전을 중단하거나 재시작하는 행동에는 별도의 권한과 조건이 필요할 수 있다.

lemonflow는 이런 업무 규칙을 별도의 프로그램으로 처리한다.

이후 표준화된 정보를 언어모델에 전달한다.

또한 외부 입력에 포함된 악의적인 지시를 차단하기 위한 보호조치도 적용한다.

이를 통해 모델은 사용자의 질문을 이해하고 상황을 설명하는 데 집중할 수 있다.

반면 실제 장비와 관련된 중요한 제어 조건은 기존 프로그램이 관리한다.

이런 구조는 실제 장비를 다루는 AI 에이전트에서 특히 중요하다.

언어모델이 잘못된 명령을 제안하더라도 실제 실행 프로그램이 허용되지 않은 행동을 차단할 수 있어야 하기 때문이다.

운영 결과: 응답 지연 약 350ms

lemonflow가 공개한 자체 운영 결과는 다음과 같다.

P50은 전체 요청 가운데 절반이 해당 시간 이내에 완료됐다는 의미다.

P90은 전체 요청 가운데 90%가 해당 시간 이내에 완료됐다는 의미다.

예를 들어 P90이 600ms라면 90%의 요청이 약 600ms 이내에 처리됐다는 뜻이다.

나머지 10%의 요청은 더 오래 걸릴 수 있다.

따라서 평균 지연시간 하나만 보는 것보다 P50과 P90을 함께 확인하는 편이 실제 사용자 경험을 이해하는 데 도움이 된다.

lemonflow는 기존 관리형 API보다 실제 응답속도가 약 세 배 빨라졌다고 설명했다.

또한 자체 TPU 인프라에서는 모델의 요청량 제한을 직접 관리할 수 있어 관리형 API의 429 오류를 피할 수 있었다고 밝혔다.

하지만 이 수치는 lemonflow가 공개한 자체 운영 결과다.

모든 종류의 AI 에이전트에서 Gemma와 TPU를 사용하면 동일한 성능 개선이 발생한다는 의미는 아니다.

또한 자체 호스팅에서는 실제 GPU·TPU의 사용료와 운영 비용, 장애 대응 비용이 발생한다.

따라서 모델 API 호출료만 비교해서 전체 비용이 반드시 낮아진다고 판단해서는 안 된다.

2~3시간 걸리던 시험이 10분으로

이번 글에서 특히 흥미로운 부분은 실제 모델 운영 방식이 개발 과정에도 영향을 미쳤다는 점이다.

관리형 API에서는 제공업체가 모델의 실행 설정과 서버 상태를 변경할 수 있다.

이런 환경에서는 이전에 성공한 테스트가 나중에 다른 결과를 생성할 수도 있다.

lemonflow는 자체적으로 모델 버전과 실행 환경을 고정했다.

이후 실제 대화를 재현하는 테스트를 반복적으로 수행할 수 있도록 만들었다.

그 결과 프롬프트를 변경하고 테스트하는 주기가 기존 2~3시간에서 약 10분으로 줄었다고 밝혔다.

이는 단순히 모델의 출력 속도가 빨라졌기 때문만은 아니다.

실제 실행 환경을 통제하고 테스트를 자동화하면서 개발 과정의 반복 속도가 개선된 것이다.

이번 글은 실시간 AI 서비스를 실제로 운영할 때 모델의 성능뿐 아니라 응답 지연과 실행 우선순위, 외부 시스템의 권한 관리와 테스트 환경의 재현성이 중요하다는 점을 구체적인 사례로 보여준다.