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

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

---

1️⃣ 주요 모델·연구

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

2️⃣ AI 제품·서비스

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

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

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

4️⃣ 산업·정책·안전

Cisco Talos, 탈취한 개인정보를 AI로 분석해 피해자의 경제적 가치를 평가하는 악성코드 ‘VOLTA’ 공개

• 발표일: 2026-10-31 — 정확한 게시 시각 미확인
• 적용 범위: AI 사이버보안, 정보탈취 악성코드, LLM 악용, 개인정보 보호, 계정 보안, 위협 인텔리전스
• 원문: Cisco Talos — Appraisal by AI: Model-driven victim prioritization in the VOLTA infostealer
• 관련 원문: WIRED — Spooky New Infostealer Malware Uses AI to 'Autodox' Victims

---

Cisco의 사이버보안 연구조직 Talos가 생성형 AI를 이용해 탈취한 개인정보를 분석하고 공격 대상의 경제적 가치를 평가하는 새로운 악성코드 VOLTA-AUTODOXER를 공개했다.

이번 연구는 AI가 악성코드를 직접 작성하거나 새로운 취약점을 찾아낸 사례와는 다르다.

이미 탈취한 방대한 개인정보를 언어모델에 전달해 어떤 피해자가 가장 가치 있는 공격 대상인지 자동으로 판단하도록 만든 악성코드라는 점이 특징이다.

기존의 정보탈취 악성코드는 사용자의 비밀번호와 인증정보, 브라우저 쿠키 등을 수집해 공격자에게 전달하는 역할을 주로 수행했다.

하지만 공격자는 이렇게 수집한 정보가 실제로 얼마나 가치 있는지 별도로 분석해야 했다.

예를 들어 피해자의 컴퓨터에서 수십 개의 온라인 계정과 결제정보, 여러 서비스의 로그인 세션이 발견됐다고 가정해 보자.

공격자는 어떤 계정이 실제로 사용 가능한지, 어떤 정보가 경제적 가치가 높은지, 서로 다른 정보가 동일한 사람을 가리키는지 조사해야 한다.

VOLTA는 이 분석 과정에 LLM(Large Language Model, 대형 언어모델)을 도입했다.

LLM은 대규모 텍스트 데이터를 학습해 문장을 이해하고 생성하거나 여러 정보 사이의 관계를 추론하는 AI 모델이다.

이번 사례에서는 언어모델의 일반적인 분석 능력이 사이버범죄의 정보 정리와 공격 대상 선별에 사용될 수 있다는 사실이 확인됐다.

악성코드는 어떤 정보를 수집하는가

Talos에 따르면 VOLTA는 Windows에서 실행되는 정보탈취 악성코드다.

Infostealer(정보탈취 악성코드)는 감염된 컴퓨터에서 인증정보와 개인정보 등을 수집하는 프로그램을 의미한다.

VOLTA의 수집 대상은 일반적인 브라우저 비밀번호보다 훨씬 넓다.

대표적인 수집 대상은 다음과 같다.

여기서 OAuth 토큰은 사용자의 비밀번호를 매번 입력하지 않고도 서비스가 정해진 권한으로 접근할 수 있도록 사용하는 인증정보다.

예를 들어 어떤 애플리케이션이 사용자의 Google 계정과 연결돼 있다면 OAuth를 통해 허용된 범위의 데이터에 접근할 수 있다.

문제는 이런 토큰이 탈취됐을 때 발생한다.

공격자가 유효한 인증정보를 확보하면 사용자의 비밀번호를 직접 알지 못하더라도 일부 서비스에 접근할 가능성이 있다.

또한 Session Token(세션 토큰)은 사용자가 로그인한 상태를 유지하기 위한 정보다.

이 토큰이 탈취되면 상황에 따라 추가적인 비밀번호 입력 없이 기존 세션이 악용될 수 있다.

따라서 단순히 비밀번호를 변경하는 것만으로 모든 인증정보가 무효화된다고 가정해서는 안 된다.

서로 다른 개인정보를 연결해 실제 인물을 분석

VOLTA의 특징은 정보를 수집한 뒤 한 번 더 분석하는 단계에 있다.

Talos는 악성코드가 수집한 정보를 바탕으로 피해자의 신원과 자산, 보안 상태를 나타내는 구조화된 자료를 생성한다고 설명했다.

예를 들어 컴퓨터에서 발견한 계정 이름과 이메일 주소, 직장 관련 정보가 서로 연결될 수 있다.

또한 온라인 구매 기록을 통해 특정 주소가 실제 거주지인지 추정할 수 있다.

Talos는 악성코드가 탈취한 인증 세션을 이용해 일부 이메일과 주문 기록을 추가로 조사하도록 설계돼 있다는 사실도 확인했다.

이 과정에서 사용되는 정보에는 구매 영수증과 배송 주소, 서비스 이용 기록 등이 포함될 수 있다.

개별 정보만 보면 크게 중요하지 않아 보일 수도 있다.

하지만 서로 다른 자료를 결합하면 개인의 실제 생활에 관한 상당히 자세한 정보를 추정할 수 있다.

예를 들어 사용자의 직장과 거주 지역, 자주 이용하는 서비스, 경제적 활동과 보안 습관을 함께 파악할 수 있다.

이처럼 여러 정보를 결합해 특정한 사람에 관한 상세한 자료를 만드는 작업을 Profiling(프로파일링)이라고 한다.

VOLTA는 이 과정에서 언어모델의 정보 연결 및 요약 능력을 사용한다.

AI는 탈취한 정보의 경제적 가치를 평가

VOLTA는 수집한 자료를 구조화된 형태로 만든 뒤 외부 AI 서비스에 전달하도록 설계됐다.

이때 OpenRouter라는 모델 API 중개 서비스를 사용한다.

OpenRouter는 여러 AI 모델을 하나의 API 인터페이스를 통해 호출할 수 있도록 제공하는 서비스다.

API는 프로그램이 다른 프로그램이나 서비스의 기능을 호출하기 위한 인터페이스를 의미한다.

악성코드는 언어모델에게 피해자의 자료를 분석하도록 지시한다.

Talos에 따르면 요청 내용에는 두 가지 주요 평가가 포함된다.

첫 번째는 피해자가 보유한 자산의 경제적 가치다.

두 번째는 피해자의 보안 수준이다.

예를 들어 모델은 수집된 계정과 자산 관련 정보를 분석하고, 공격자가 경제적으로 활용하기 쉬운 정보를 구분하도록 지시받는다.

또한 피해자가 비밀번호를 안전하게 관리하는지, 계정 보안 상태가 어떤지 등을 평가하도록 구성돼 있다.

이렇게 생성된 결과는 단순한 정보 목록이 아니라 공격 대상에 관한 분석 보고서에 가깝다.

Talos는 이러한 방식에서 LLM이 공격자의 정보 분석가 역할을 수행한다고 설명했다.

중요한 것은 이번 악성코드가 LLM에 새로운 계정을 직접 찾아내도록 요청하는 것이 아니라는 사실이다.

이미 수집된 정보를 분석하고 우선순위를 정하는 작업에 AI를 사용하는 구조다.

하나의 AI 모델이 거부하면 다른 모델을 시도하도록 설계

VOLTA에는 여러 모델을 선택하는 기능도 포함돼 있다.

Talos가 확인한 설정에서는 다음과 같은 모델이 지정돼 있었다.

여기서 Fallback(대체 경로)은 처음 선택한 시스템이 실패했을 때 다른 시스템을 사용하는 방법이다.

Talos는 악성코드가 모델의 응답에서 요청 거부와 관련된 표현을 확인하도록 설계돼 있다는 사실을 발견했다.

예를 들어 모델이 해당 분석을 수행할 수 없다고 응답하면 다른 모델을 호출하도록 구성돼 있다.

이런 구조는 악성코드 제작자가 AI 모델의 안전장치 때문에 요청이 거부될 가능성을 예상하고 있었음을 시사한다.

그러나 중요한 제한이 있다.

악성코드에 세 가지 모델이 설정돼 있다는 사실만으로 해당 모델들이 실제로 악성 요청을 수행했다는 의미는 아니다.

또한 실제 실행에서 어떤 모델이 요청을 거부했는지, 어느 모델이 최종 분석 결과를 제공했는지에 관한 완전한 운영 기록이 공개된 것도 아니다.

따라서 이번 사례를 특정 모델 제공업체가 악성 요청을 허용했다고 단정하는 근거로 사용할 수는 없다.

이번 연구에서 확인된 사실은 악성코드가 여러 모델을 순차적으로 호출하도록 설계돼 있었다는 점이다.

자체 서버 없이 외부 서비스를 활용하는 구조

Talos는 VOLTA가 공격자 소유의 별도 서버에만 의존하는 구조가 아니라는 점도 지적했다.

악성코드는 이미 존재하는 여러 외부 서비스를 이용하도록 설계됐다.

AI 분석에는 상용 모델 API가 사용된다.

수집한 자료의 전달에도 일반적인 온라인 서비스가 활용될 수 있다.

이런 구조는 보안 담당자가 악성 트래픽을 식별하는 과정을 복잡하게 만들 수 있다.

예를 들어 기업 내부에서 널리 사용하는 정상적인 서비스로 네트워크 요청이 발생했다고 해도 그 요청의 목적이 항상 정상적인 것은 아니다.

정상적인 프로그램이 해당 서비스에 접근하는 경우와 악성코드가 같은 서비스를 이용하는 경우를 구분해야 하기 때문이다.

또한 VOLTA는 실행 이후 자신의 주요 실행 파일을 삭제하도록 설계돼 있다.

이런 행동은 감염된 컴퓨터에서 악성코드의 흔적을 조사하는 작업을 어렵게 만들 수 있다.

하지만 악성코드가 자신을 삭제한다고 해서 모든 기록이 사라지는 것은 아니다.

시스템 로그와 네트워크 기록, 일부 임시 파일이 남아 있을 수 있다.

실제 피해 규모는 아직 확인되지 않았다

이번 연구의 결과를 해석할 때는 확인된 사실과 아직 확인되지 않은 부분을 구분해야 한다.

Talos는 실제 악성코드 샘플을 분석했다.

공개된 샘플의 최초 관찰 시점은 2026년 10월 11일 12:46 UTC다.

그러나 이번 보고서에서는 해당 악성코드를 이용한 대규모 공격 캠페인이나 실제 피해자 수를 확정하지 않았다.

또한 공격자가 AI를 이용한 분석 결과를 실제로 어떤 공격에 활용했는지도 확인되지 않았다.

Talos는 악성코드에 여러 설정값을 넣어 배포할 수 있는 구조가 존재한다는 점에서 상업적으로 판매하는 악성코드일 가능성을 제기했다.

하지만 실제 판매 구조와 구매자 수가 확인된 것은 아니다.

따라서 이번 사건을 이미 수많은 피해자가 발생한 새로운 AI 범죄 캠페인으로 설명하는 것은 정확하지 않다.

현재 확인된 것은 AI 기반 피해자 분석 기능을 포함한 실제 악성코드가 존재한다는 사실이다.

개인정보 보호와 계정 보안에 미치는 영향

이번 사례는 기존의 정보탈취 악성코드에 AI가 추가됐을 때 무엇이 달라질 수 있는지 보여준다.

기존에는 공격자가 많은 정보를 수집하더라도 어떤 자료가 가치 있는지 분석하는 데 사람이 필요했다.

하지만 언어모델이 이 작업을 일부 수행하면 공격자는 수집한 정보에서 필요한 내용을 더 빠르게 찾을 수 있다.

특히 개인이 여러 서비스에서 사용하는 계정과 인증정보가 연결되면 하나의 기기 침해가 다른 서비스의 피해로 확대될 가능성이 있다.

따라서 실제 기기가 감염됐다고 의심되는 상황에서는 비밀번호 변경뿐 아니라 유효한 로그인 세션과 인증 토큰을 함께 점검할 필요가 있다.

또한 민감한 인증정보를 일반적인 텍스트 파일이나 안전하지 않은 위치에 보관하지 않는 것이 중요하다.

기업에서는 비정상적인 인증정보 접근과 여러 서비스에 대한 짧은 시간의 대량 조회를 감시하는 방법도 고려할 수 있다.

하지만 이런 조치가 VOLTA를 포함한 모든 악성코드를 완벽하게 차단한다는 의미는 아니다.

이번 연구는 생성형 AI의 악용이 악성코드를 직접 작성하거나 취약점을 발견하는 단계뿐 아니라 탈취한 정보를 분석하고 공격자의 판단을 보조하는 단계로 확대될 수 있음을 보여준다.

AI가 범죄의 모든 과정을 자동화하지 않더라도 특정 단계에 필요한 사람의 분석 작업을 줄이는 것만으로 공격의 규모와 효율에 영향을 줄 가능성이 있다는 점에서 주목할 만한 사례다.

---

📚 추천 글

How do we get to plug-and-play robots?

• 저자: Luca Cilio
• 발행: ProjectSim / Hugging Face Community
• 게시일: 2026-10-30
• 원문: ProjectSim — How do we get to plug-and-play robots?

---

AI 모델이 아무리 발전해도 로봇을 새로운 환경에 설치하는 작업은 여전히 어렵다.

예를 들어 공장이나 가정에 새로운 로봇을 배치한다고 가정해 보자.

로봇은 물체를 집고 이동시키는 능력을 이미 학습했을 수 있다.

하지만 실제 현장에서는 물체의 크기와 배치, 조명과 바닥의 마찰력, 작업 공간의 구조가 학습 환경과 다를 수 있다.

따라서 기존에 학습한 모델을 그대로 사용하는 것만으로는 원하는 작업을 안정적으로 완료하기 어렵다.

이 글은 여러 최신 로봇 연구를 비교하면서 로봇의 기본 모델이 발전하더라도 실제 배포에 필요한 작업이 왜 쉽게 사라지지 않는지 설명한다.

특히 새로운 로봇 모델의 성능을 소개하는 데서 끝나지 않고 실제로 발생하는 실패와 이를 해결하려는 연구 방향을 함께 분석한다는 점이 흥미롭다.

로봇의 행동 정책과 실제 작업 완료는 다르다

로봇 AI에서는 Policy(정책)라는 개념을 사용한다.

정책은 로봇이 현재 관찰한 환경을 바탕으로 다음에 어떤 행동을 수행할지 결정하는 모델이다.

예를 들어 카메라에 물체가 보이면 해당 물체를 집기 위한 로봇 팔의 움직임을 생성할 수 있다.

하지만 물체를 집는 행동이 성공했다고 해서 사용자의 전체 요청이 완료된 것은 아니다.

예를 들어 사용자가 캔을 전자레인지 안에 넣으라고 요청했다고 가정해 보자.

로봇은 캔을 정상적으로 집을 수 있다.

그러나 캔을 위에서 잡은 상태에서는 로봇의 손과 캔이 전자레인지 입구를 통과하기 어려울 수 있다.

반면 캔을 옆에서 잡으면 넣을 수 있을지도 모른다.

이 경우 집기 자체는 성공했지만 다음 단계의 작업을 고려하지 않은 행동 선택 때문에 전체 작업이 실패한 것이다.

저자는 이런 문제를 설명하기 위해 BATON 연구를 소개한다.

BATON은 로봇이 여러 행동을 수행할 때 다음 단계의 제약을 현재 행동의 선택에 반영하도록 하는 접근이다.

예를 들어 어떤 방식으로 물체를 잡을지 결정할 때 이후 물체를 어디에 놓아야 하는지도 고려한다.

이런 연구는 로봇의 개별적인 동작 능력보다 여러 동작을 연결해 하나의 목표를 완료하는 능력이 중요하다는 점을 보여준다.

AI가 작업 성공 여부를 잘못 판단할 수도 있다

로봇은 특정한 행동을 수행한 뒤 실제로 성공했는지 확인해야 한다.

예를 들어 오렌지를 흰색 그릇에 넣으라는 요청을 수행했다고 가정해 보자.

로봇의 제어 모델은 오렌지를 집고 이동시키는 행동을 실행한다.

이후 별도의 시각 모델이 오렌지가 그릇 안에 들어갔는지 확인할 수 있다.

이를 Outcome Verification(결과 검증)이라고 한다.

하지만 결과 검증을 담당하는 AI 역시 오류를 만들 수 있다.

저자가 소개한 VoLo 연구에서는 시각 모델이 오렌지가 그릇 안에 있다고 판단했지만, 실제 시뮬레이션 화면에서는 오렌지가 여전히 테이블 위에 있었다.

즉 로봇이 실제로 수행한 행동과 이를 평가한 AI의 판단이 서로 달랐다.

VoLo는 시각·언어 기반 계획 및 검증 모델을 기존 로봇 정책과 결합한 시스템이다.

연구팀의 실제 하드웨어 평가에서 완전한 시스템은 42번의 시도 가운데 18번 성공했다.

반면 기본 정책만 사용한 경우에는 42번 가운데 6번 성공했다.

계획과 검증 기능을 추가해 성공 횟수가 크게 증가했다는 의미다.

하지만 동시에 전체 시도의 절반 이상에서는 여전히 작업을 완료하지 못했다.

이는 로봇 시스템에서 결과를 검사하는 기능이 존재한다는 사실과 결과를 정확하게 검사할 수 있다는 사실이 다르다는 점을 보여준다.

새로운 환경에서도 기존 지식을 사용할 수 있을까?

저자는 최근 로봇 연구에서 가장 중요한 변화 가운데 하나로 일반화(Generalization)를 설명한다.

일반화는 모델이 학습 과정에서 직접 경험하지 않은 새로운 상황에서도 유용한 행동을 수행하는 능력이다.

예를 들어 로봇이 특정한 집에서 수건을 접는 방법을 학습했다고 가정해 보자.

실제 제품으로 사용하려면 다른 집에서도 비슷한 작업을 수행할 수 있어야 한다.

집마다 수건의 크기와 재질, 작업대의 높이와 주변 물체의 위치가 다를 수 있기 때문이다.

저자는 Figure의 Helix 2.5 평가를 소개한다.

해당 연구에서는 정리와 수건 접기, 침대 정리라는 세 가지 작업을 학습했다.

이후 학습 중 사용하지 않은 30개 가정의 새로운 환경에서 모델을 시험했다.

Figure가 공개한 결과에 따르면 사전학습에 더 폭넓은 데이터를 사용했을 때 전체 작업 성공률이 9%에서 56%로 증가했다.

다만 이는 Figure가 공개한 자체 평가 결과다.

모든 가정용 로봇에서 같은 수준의 성공률을 보장한다는 의미는 아니다.

또한 새로운 환경에서 작업을 수행할 수 있다는 사실과 어떤 작업이든 사전 준비 없이 수행할 수 있다는 사실은 다르다.

몇 초의 시연만으로 새로운 작업을 배울 수 있다

저자는 Generalist의 GEN-1.5 연구도 소개한다.

이 연구에서는 로봇에게 새로운 작업을 알려주기 위해 짧은 시연을 제공한다.

예를 들어 사람이 물체를 집고 이동시키는 모습을 기록할 수 있다.

로봇은 해당 시연을 참고해 비슷한 작업을 수행하도록 설계됐다.

이런 방식은 Physical Prompting(물리적 시연을 이용한 작업 지시)과 연결된다.

일반적인 언어모델에서 프롬프트가 텍스트 지시라면 로봇에서는 행동 기록 자체가 작업 지시로 활용될 수 있는 것이다.

Generalist가 공개한 평가에서는 3~12초 길이의 시연 하나를 제공했을 때 열 가지 짧은 작업에서 평균 59%의 성공률을 기록했다.

작업당 약 5분의 데이터를 추가하고 열 단계의 미세조정을 수행한 경우 성공률은 83%로 높아졌다.

미세조정(Fine-Tuning)은 이미 학습된 모델을 특정 작업에 맞게 추가 학습하는 과정이다.

다만 두 조건에서는 시연 데이터의 양뿐 아니라 추가 학습 여부도 달라졌다.

따라서 성공률 차이를 단순히 시연 시간이 길어졌기 때문이라고 설명해서는 안 된다.

시뮬레이션이 실제 로봇 개발을 대체할 수 있을까?

로봇을 실제 환경에서 반복해서 학습시키려면 상당한 비용이 발생한다.

로봇이 실패할 때마다 물체를 다시 배치해야 할 수 있다.

또한 실제 장비가 손상되거나 사람에게 위험한 상황이 발생하지 않도록 관리해야 한다.

이를 줄이기 위해 Simulation(시뮬레이션)이 사용된다.

시뮬레이션은 컴퓨터 안에서 로봇과 물체의 움직임, 충돌과 마찰력 등을 계산하는 방법이다.

여러 가상환경을 동시에 실행하면 실제 로봇 한 대에서 수행하기 어려운 규모의 실험을 진행할 수 있다.

저자는 NVIDIA GR00T N1 연구에서 11시간 동안 78만 개의 시뮬레이션 궤적을 생성한 사례를 소개한다.

Trajectory(궤적)는 로봇이 시간에 따라 어떤 상태를 관찰하고 어떤 행동을 수행했는지 기록한 연속 데이터다.

이렇게 생성한 데이터는 로봇의 학습에 활용할 수 있다.

하지만 시뮬레이션에는 중요한 한계가 있다.

예를 들어 실제 물체의 마찰력이 잘못 설정됐다면 가상환경에서는 성공한 행동이 현실에서는 실패할 수 있다.

로봇의 모터가 명령에 반응하는 속도도 실제와 다를 수 있다.

이를 Sim-to-Real Gap(시뮬레이션과 현실 사이의 차이)이라고 한다.

저자는 SIMPLER 연구의 사례를 소개한다.

실제 로봇에서는 정상적으로 성공한 물체 잡기 행동이 시뮬레이션에서는 실패했다.

하지만 로봇 제어기의 반응을 실제 시스템에 더 가깝게 보정하자 시뮬레이션에서도 같은 행동이 성공했다.

이는 시뮬레이션의 결과가 실제 로봇의 능력뿐 아니라 시뮬레이터 자체의 정확성에 영향을 받는다는 점을 보여준다.

플러그 앤 플레이 로봇의 실제 조건

이번 글의 핵심적인 관점은 범용 로봇 모델이 더 많은 능력을 학습하는 것만으로는 충분하지 않다는 것이다.

새로운 환경에서 어떤 부분이 기존 환경과 다른지 확인해야 한다.

로봇이 실패했을 때 원인을 분석해야 한다.

새로운 행동 방법을 시험하고 실제로 개선됐는지 검증해야 한다.

저자는 앞으로 AI 에이전트가 이런 작업의 일부를 자동화할 수 있다고 전망한다.

예를 들어 로봇이 물체를 잡는 데 실패하면 에이전트가 실행 기록을 조사하고 다른 집기 방법을 제안할 수 있다.

이후 시뮬레이션에서 해당 방법을 시험하고 실제 로봇에 적용하는 방식이다.

하지만 이러한 과정이 모든 실제 로봇에서 자동화됐다는 의미는 아니다.

현재는 서로 다른 연구 프로젝트에서 일부 기능을 검증하는 단계에 가깝다.

이번 글은 로봇 AI의 발전을 이해할 때 단순히 모델이 어떤 동작을 생성할 수 있는가보다 새로운 환경에 배포하고 실패를 복구하기까지 필요한 작업이 얼마나 줄어드는가에 주목해야 한다는 관점을 제공한다.

---

Introducing AnySpeechRecognizer and AnyDecisionModel: Open Models for Speech and Decisions on Apple Platforms

• 저자: Mattt
• 발행: Hugging Face Community / 독립 오픈소스 개발
• 게시일: 2026-10-29
• 원문: Hugging Face — Introducing AnySpeechRecognizer and AnyDecisionModel

---

AI 기능을 애플리케이션에 추가할 때 반드시 대형 언어모델을 사용해야 할까?

이 글은 그런 접근이 항상 효율적인 것은 아니라는 점을 실제 오픈소스 구현을 통해 설명한다.

저자는 Apple 플랫폼에서 AI 모델을 실행하기 위한 두 가지 새로운 Swift 라이브러리를 공개했다.

첫 번째는 AnySpeechRecognizer다.

음성을 텍스트로 변환하는 기능을 제공한다.

두 번째는 AnyDecisionModel이다.

입력된 정보에 대해 참·거짓이나 여러 선택지 가운데 하나를 판단하는 기능을 제공한다.

이번 글에서 흥미로운 부분은 일반적인 언어 생성 작업과 음성 인식, 구조화된 판단을 서로 다른 종류의 모델로 분리한다는 점이다.

예를 들어 고객지원 서비스를 개발한다고 가정해 보자.

사용자의 통화를 녹음해 텍스트로 변환해야 한다.

이후 해당 문의가 결제 문제인지 기술지원 문제인지 분류해야 한다.

이 두 작업을 하나의 거대한 언어모델에 모두 맡길 수도 있다.

하지만 음성 인식 전문 모델과 분류 전문 모델을 사용하는 편이 특정 환경에서는 더 빠르고 저렴할 수 있다.

기존 Apple Speech API를 유지하면서 모델 교체

AnySpeechRecognizer는 Apple의 Speech 프레임워크와 비슷한 인터페이스를 제공한다.

Apple은 macOS와 iOS에서 음성 인식 기능을 사용할 수 있는 API를 제공한다.

하지만 기본적으로 Apple이 제공하는 음성 인식 엔진에 의존한다.

AnySpeechRecognizer는 기존 인터페이스를 유지하면서 다른 공개 모델을 사용할 수 있도록 설계됐다.

지원 모델에는 NVIDIA의 Parakeet과 Alibaba의 Qwen3-ASR이 포함된다.

예를 들어 Parakeet v3는 25개 유럽 언어를 인식할 수 있다.

반면 Qwen3-ASR은 한국어와 일본어, 중국어를 포함한 30개 언어와 22개 중국어 방언을 지원한다.

따라서 어떤 언어를 처리해야 하는지에 따라 적절한 모델을 선택할 수 있다.

중요한 점은 모델을 교체해도 애플리케이션의 전체 음성 처리 코드를 다시 작성할 필요를 줄였다는 사실이다.

모델별 차이를 공통 인터페이스로 감싸는 방식이다.

이를 Adapter(어댑터) 또는 추상화 계층이라고 설명할 수 있다.

서로 다른 시스템의 인터페이스를 하나의 공통 구조로 연결하는 소프트웨어 구성요소다.

Core ML을 이용한 로컬 실행

이번 라이브러리는 Apple의 Core ML을 지원한다.

Core ML은 Apple 기기에서 머신러닝 모델을 실행하기 위한 프레임워크다.

저자는 여러 공개 음성 모델을 Core ML 형식으로 변환하고 Hugging Face에 공개했다.

이렇게 하면 적절한 Apple Silicon 기기에서 외부 클라우드 API를 호출하지 않고 음성 인식을 수행할 수 있다.

로컬 실행에는 몇 가지 장점이 있다.

예를 들어 회의 녹음 파일을 외부 서비스에 전송하지 않고 분석할 수 있다.

또한 외부 API의 토큰 사용량에 따른 비용을 줄일 수 있다.

하지만 로컬 모델이 반드시 클라우드 모델보다 빠르거나 정확하다는 의미는 아니다.

실제 성능은 하드웨어와 모델의 크기, 입력 데이터의 특성에 따라 달라진다.

화자 분리 기능도 추가

AnySpeechRecognizer에는 Speaker Diarization(화자 분리) 기능도 포함됐다.

화자 분리는 녹음에서 누가 언제 말했는지 구분하는 기술이다.

예를 들어 세 명이 참여한 회의를 분석할 때 각 발언을 화자 A, B, C에게 연결할 수 있다.

이 기능에는 NVIDIA의 Streaming Sortformer 모델이 사용된다.

최대 네 명의 화자를 구분하도록 구성됐다.

여러 사람이 동시에 말하는 상황도 처리하도록 설계됐다.

하지만 화자가 겹치는 상황에서는 정확도가 떨어질 수 있다.

또한 화자 분리는 반드시 사람의 실제 이름을 알아내는 기능이 아니다.

서로 다른 목소리를 구분하고 각 발언을 연결하는 작업이다.

실제 이름과 연결하려면 추가 정보가 필요할 수 있다.

실제 음성 인식 성능 측정

저자는 M4 Max Mac Studio에서 여러 모델의 음성 인식 성능을 측정했다.

평가에는 LibriSpeech 데이터셋이 사용됐다.

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

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

저자가 측정한 조건에서는 일부 Parakeet 모델이 Apple의 기본 음성 인식 엔진보다 낮은 오류율을 기록했다.

하지만 이 결과는 특정 하드웨어와 영어 음성 데이터에서 측정됐다.

한국어와 실제 회의 녹음에서도 같은 정확도가 나타난다는 의미는 아니다.

또한 실제 회의 환경을 포함한 AMI 데이터셋에서는 시험한 모든 엔진의 WER가 23%를 초과했다.

이는 깨끗한 녹음에서 높은 정확도를 기록한 모델도 실제 회의처럼 여러 사람이 겹쳐 말하는 환경에서는 성능이 크게 떨어질 수 있다는 사실을 보여준다.

저자는 발표 시점에 관련 모델을 macOS 27에서만 직접 시험했다고 밝혔다.

따라서 iPhone에서도 동일한 성능과 기능이 검증됐다고 판단해서는 안 된다.

답변을 생성하지 않고 확률을 직접 계산

두 번째 라이브러리인 AnyDecisionModel은 더 흥미로운 접근을 사용한다.

일반적인 언어모델을 이용해 문의를 분류한다고 가정해 보자.

모델에게 다음과 같은 질문을 할 수 있다.

이 문의는 결제 문제인가, 기술지원 문제인가, 영업 문의인가?

일반적인 LLM은 다음과 같은 텍스트를 생성할 수 있다.

결제 문제입니다.

그런데 실제 프로그램에서는 이런 문장을 다시 분석해야 한다.

예를 들어 문자열을 읽어 해당 값이 결제와 기술지원, 영업 가운데 무엇에 해당하는지 판단해야 한다.

또한 모델이 예상하지 못한 표현을 생성하면 오류가 발생할 수 있다.

AnyDecisionModel은 이런 문제를 줄이기 위해 모델이 각 선택지에 부여한 확률을 직접 읽는 방식을 사용한다.

예를 들어 세 가지 선택지에 대한 확률을 계산할 수 있다.

이후 가장 높은 확률을 가진 선택지를 반환한다.

이런 방식은 긴 문장을 생성할 필요가 없는 분류 작업에서 유용할 수 있다.

하나의 순전파로 여러 판단 수행

AnyDecisionModel은 여러 질문을 묶어 처리하는 기능도 제공한다.

예를 들어 하나의 고객 문의에 대해 다음 세 가지를 판단한다고 가정해 보자.

• 긴급한 문의인가?
• 어느 부서가 담당해야 하는가?
• 고객의 불만 수준은 어느 정도인가?

일반적인 LLM에서는 세 가지 질문에 각각 답하도록 요청하거나 하나의 JSON 문서를 생성할 수 있다.

반면 AnyDecisionModel은 모델의 내부 계산 결과에서 각 선택지의 확률을 추출한다.

일부 모델에서는 여러 판단을 하나의 Forward Pass(순전파)로 처리할 수 있다.

순전파는 입력을 모델에 전달한 뒤 신경망의 여러 계층을 계산해 결과를 얻는 과정이다.

이렇게 하면 여러 번의 텍스트 생성 작업을 줄일 수 있다.

저자는 Cloudflare의 Clef 모델처럼 별도의 판단용 출력 계층을 가진 모델도 지원한다고 설명한다.

확률이 높다고 반드시 정답인 것은 아니다

이번 글에서 중요한 부분은 모델이 반환한 확률을 그대로 신뢰해서는 안 된다는 설명이다.

예를 들어 모델이 특정한 선택지의 확률을 95%라고 반환할 수 있다.

하지만 실제로 해당 선택지가 95%의 경우에 정답이라는 의미는 아닐 수 있다.

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

모델이 반환한 확률과 실제 정답이 발생하는 비율이 얼마나 일치하는지에 관한 문제다.

저자는 온도 조정과 편향 보정 기능을 제공한다.

또한 선택지의 순서를 변경해 여러 번 평가하는 방식도 소개한다.

언어모델은 같은 선택지라도 목록에서 어떤 순서로 제시되는지에 따라 다른 확률을 반환할 수 있기 때문이다.

하지만 이런 보정 방법도 실제 데이터에서 검증해야 한다.

이번 글은 AI 애플리케이션의 모든 기능을 하나의 생성형 언어모델에 맡기는 것보다 음성 인식과 분류, 텍스트 생성의 특성에 맞는 모델과 실행 방법을 선택하는 방식이 효율적일 수 있음을 보여준다.

---

Announcing Project ProtoStar: Making Publicly Funded Science AI-Ready

• 저자: Avijit Ghosh, Sayeed Choudhury, Greg Tananbaum, Emma Scharfmann, Georgia Channing, Eunice Mercado-Lara, Irene Solaiman
• 발행: Hugging Face / Carnegie Mellon University / ORCA 등 공동 프로젝트
• 게시일: 2026-10-29
• 원문: Hugging Face — Announcing Project ProtoStar: Making Publicly Funded Science AI-Ready

---

과학 연구 결과가 인터넷에 공개돼 있다면 AI가 해당 자료를 자유롭게 분석하고 새로운 연구에 활용할 수 있을까?

이 글은 반드시 그렇지는 않다는 문제에서 출발한다.

연구기관과 대학은 수많은 데이터셋과 논문, 모델과 소프트웨어를 공개한다.

하지만 실제 자료는 서로 다른 저장소와 형식에 분산돼 있는 경우가 많다.

예를 들어 특정 대학에서 기후 연구 데이터를 공개했다고 가정해 보자.

해당 데이터가 인터넷에 공개돼 있어도 파일의 구조를 설명하는 문서가 부족하다면 다른 연구자가 사용하기 어려울 수 있다.

데이터의 단위가 섭씨인지 화씨인지 명확하지 않을 수 있다.

어떤 지역에서 어떤 방법으로 수집했는지 알기 어려울 수도 있다.

또한 다른 연구기관의 데이터와 결합하려면 날짜와 위치, 측정 기준을 다시 맞춰야 할 수 있다.

Project ProtoStar는 이런 문제를 해결하기 위해 시작된 공동 프로젝트다.

이번 글은 공개 연구자료를 AI가 실제로 활용할 수 있는 형태로 만드는 데 필요한 기술과 정책, 연구 협력 구조를 설명한다.

공개된 데이터와 실제 사용 가능한 데이터는 다르다

일반적으로 연구 데이터를 공개한다고 하면 파일을 인터넷에 업로드하는 작업을 생각하기 쉽다.

하지만 실제로 재사용 가능한 데이터를 만들려면 더 많은 정보가 필요하다.

예를 들어 연구자가 특정 실험 결과를 CSV 파일로 공개했다고 가정해 보자.

CSV는 행과 열로 구성된 데이터를 쉼표 등으로 구분해 저장하는 파일 형식이다.

파일이 공개돼 있다는 사실만으로 다음 정보를 모두 알 수 있는 것은 아니다.

데이터가 어떤 실험에서 생성됐는지 확인해야 한다.

각 열이 어떤 의미를 가지는지 알아야 한다.

누락된 값이 어떤 이유로 발생했는지도 이해해야 한다.

또한 데이터의 사용과 재배포가 허용되는지 확인해야 한다.

이런 정보를 Metadata(메타데이터)라고 한다.

메타데이터는 데이터 자체에 관한 설명 정보다.

또한 데이터가 어디에서 시작됐고 어떤 과정을 거쳐 현재 형태로 만들어졌는지 추적하는 Provenance(데이터 출처와 생성 이력)도 중요하다.

예를 들어 여러 실험 결과를 합쳐 만든 데이터셋이라면 원본 데이터가 무엇인지 확인할 수 있어야 한다.

AI가 여러 연구자료를 자동으로 검색하고 결합하려면 이런 정보가 특히 중요하다.

대학과 연구기관, 오픈소스 플랫폼의 공동 프로젝트

ProtoStar에는 여러 대학과 연구기관이 참여한다.

초기 협력기관에는 Carnegie Mellon University와 Purdue University, Georgia Institute of Technology, Arizona State University와 George Washington University가 포함된다.

또한 Astera Institute와 Hugging Face, Open Research Community Accelerator(ORCA) 등이 참여한다.

Hugging Face는 모델과 데이터셋을 공개하고 공유하는 인프라를 제공한다.

대학과 연구기관은 실제 과학 연구자료를 공개하고 재사용할 수 있는 형태로 정리하는 역할을 수행한다.

프로젝트는 이러한 자료를 AI-Ready(인공지능이 활용하기 좋은 상태)로 만들려 한다.

여기서 AI-Ready는 단순히 AI 모델이 파일을 다운로드할 수 있다는 의미가 아니다.

데이터의 구조와 사용 조건, 설명 정보와 출처가 충분히 정리돼 있어 실제 분석과 학습에 활용하기 쉬운 상태를 뜻한다.

과학 데이터 공개가 빠르게 증가

Hugging Face는 현재 공개 과학 데이터의 규모도 설명했다.

회사에 따르면 유전체와 단백질, 화학과 기후, 지구 관측과 천문학 등 주요 과학 분야에서 1만7천 개 이상의 공개 데이터셋이 제공되고 있다.

의학과 수학 분야까지 포함하면 약 2만9천 개에 가까운 데이터셋이 존재한다.

또한 2026년 첫 9개월 동안 Hugging Face에 새롭게 공개된 과학 데이터셋은 2025년 같은 기간보다 세 배 이상 증가했다.

이 수치는 Hugging Face 플랫폼에서 관찰한 결과다.

모든 공개 과학 데이터 저장소의 증가율이 동일하다는 의미는 아니다.

또한 공개 데이터셋의 수가 증가했다는 사실과 실제 데이터의 품질이 높아졌다는 사실은 서로 다르다.

프로젝트는 이런 차이를 줄이기 위해 데이터의 구조와 문서화 수준을 개선하려 한다.

문서화가 데이터 활용에 미치는 영향

이번 글에서는 데이터셋의 문서화가 실제 이용과 얼마나 관련되는지도 설명한다.

Hugging Face가 소개한 연구에 따르면 플랫폼의 데이터셋 다운로드 가운데 약 90%가 문서화가 충분한 데이터셋에서 발생했다.

이 결과는 설명 문서가 충분한 데이터셋이 더 많이 사용되는 경향과 일치한다.

하지만 문서가 잘 작성됐다는 사실 때문에 다운로드 수가 증가했다고 인과관계를 단정할 수는 없다.

원래 인기가 높은 데이터셋이 더 많은 문서와 예제를 제공할 가능성도 있기 때문이다.

그럼에도 데이터셋을 공개할 때 실제 사용 방법과 구조를 설명하는 작업이 중요하다는 점은 분명하다.

특히 AI가 데이터셋을 자동으로 검색하고 선택하는 상황에서는 데이터의 이름과 설명이 모델의 판단에도 영향을 줄 수 있다.

첫 번째 도전 과제는 도시 기후 예측

ProtoStar는 공개 데이터가 실제 연구에 얼마나 유용한지 확인하기 위해 여러 공개 도전 과제를 진행할 계획이다.

첫 번째는 Climate Risk Intelligence다.

Carnegie Mellon University가 주관한다.

참가자는 미국의 210개 도시에 관한 과거 기후 데이터를 이용한다.

학습에 사용할 데이터는 2018년까지의 기록이다.

이후 2019년부터 2026년까지 실제로 관측된 기후 조건을 예측하도록 한다.

예측 대상은 다음 네 가지다.

Cooling Degree Days(냉방도일)는 외부 기온이 특정 기준보다 얼마나 높은지 누적해 냉방에 필요한 에너지 수요를 추정하는 데 사용하는 지표다.

예를 들어 어떤 도시의 여름철 기온이 지속적으로 높다면 냉방 수요도 증가할 가능성이 있다.

연구팀은 참가자의 예측을 실제 기후 관측 기록과 비교한다.

또한 단순한 과거 평균과 선형 추세 같은 기본적인 통계 모델과도 비교한다.

이렇게 하면 복잡한 AI 모델이 단순한 통계 방법보다 실제로 더 정확한지 평가할 수 있다.

AI가 언제나 단순한 통계보다 우수한 것은 아니다

이번 도전 과제에서 중요한 부분은 Baseline(기준 모델)의 존재다.

기준 모델은 새로운 방법의 성능을 평가하기 위해 비교하는 단순하거나 기존에 널리 사용되는 방법이다.

예를 들어 특정 도시의 내년 평균 기온을 예측한다고 가정해 보자.

매우 복잡한 AI 모델을 사용할 수도 있다.

하지만 지난 10년의 평균 기온을 이용해 예측하는 간단한 방법도 존재한다.

새로운 AI 모델의 예측 성능이 단순한 평균보다 낮다면 복잡한 모델을 사용하는 이점이 크지 않을 수 있다.

ProtoStar는 이런 비교를 공개적으로 수행하려 한다.

참가자는 예측 결과뿐 아니라 해당 분석에서 얻은 내용을 바탕으로 도시의 기후 적응 정책 아이디어도 제안한다.

예를 들어 폭염에 대응하기 위한 도시 설계와 냉방 에너지 관리, 강수량 변화에 대응하는 기반시설 계획 등을 생각할 수 있다.

하지만 기후 예측의 정확도와 정책 아이디어의 유용성은 별도로 평가한다.

수치 예측이 정확하다고 해서 제안한 정책이 실제로 효과적이라는 의미는 아니기 때문이다.

아직 연구 결과가 나온 것은 아니다

이번 발표에서는 ProtoStar의 첫 번째 도전 과제를 2026년 11월 2일부터 13일까지 진행한다고 밝혔다.

따라서 10월 29일 발표 시점에는 실제 참가자의 모델 성능 결과가 나오지 않았다.

또한 2026년 전체 기후 관측값이 확정된 뒤 최종 결과를 공개할 예정이다.

현재 공개된 것은 연구에 사용할 데이터와 평가 방법, 참여 절차다.

이번 글은 AI 과학 연구의 발전을 이해할 때 새로운 모델의 성능뿐 아니라 다른 연구자가 데이터를 실제로 재사용하고 검증할 수 있는 환경을 만드는 일이 중요하다는 관점을 제공한다.

특히 공개 연구자료를 AI가 활용할 수 있도록 만들기 위해 필요한 데이터 구조와 문서화, 출처 관리와 평가 체계를 설명한다는 점에서 읽어볼 가치가 있다.

---

Build a Validated Kubernetes Runtime for NVIDIA Dynamo

• 저자: Stefan Schimanski, Jamie Li, Yuan Chen
• 발행: NVIDIA Technical Blog
• 게시일: 2026-10-30
• 원문: NVIDIA — Build a Validated Kubernetes Runtime for NVIDIA Dynamo

---

기업에서 대형 언어모델을 Kubernetes에 배포하려면 어떤 구성이 필요할까?

일반적인 웹 애플리케이션에서는 컨테이너 이미지를 만들고 Kubernetes에 배포하는 과정으로 서비스를 시작할 수 있다.

하지만 대규모 AI 모델의 추론 시스템에서는 추가적인 문제가 발생한다.

GPU가 올바르게 인식돼야 한다.

모델의 가중치가 여러 GPU에 적절하게 배치돼야 한다.

서로 다른 서버가 중간 계산 결과를 교환해야 할 수도 있다.

또한 많은 사용자의 요청을 처리하면서 GPU 메모리와 계산 자원을 효율적으로 사용해야 한다.

이 글은 NVIDIA의 분산 추론 프레임워크 Dynamo를 Kubernetes에서 운영할 때 필요한 인프라를 어떻게 구성하고 검증하는지 설명한다.

특히 실제로 모델을 실행하는 프로그램과 그 아래에서 GPU와 네트워크, 스케줄러를 관리하는 인프라를 분리해 설명한다는 점이 유용하다.

모델을 배포했다고 실제 서비스가 준비된 것은 아니다

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

Kubernetes에서는 여러 컨테이너를 Pod(파드)라는 단위로 관리한다.

일반적인 웹 서비스에서는 요청이 들어오면 사용 가능한 서버의 Pod로 전달할 수 있다.

하지만 AI 모델에서는 요청의 특성이 더 복잡하다.

예를 들어 하나의 요청에는 수십 페이지의 문서가 포함될 수 있다.

다른 요청은 짧은 문장 하나만 포함할 수 있다.

또한 일부 사용자는 매우 긴 답변을 생성하도록 요청할 수 있다.

이런 작업에서는 GPU마다 필요한 메모리와 계산량이 달라진다.

따라서 단순히 요청 수를 균등하게 나누는 방식만으로 최적의 추론 성능을 얻기는 어려울 수 있다.

NVIDIA Dynamo는 이런 요청을 여러 GPU와 서버에서 효율적으로 처리하도록 설계된 프레임워크다.

AI Cluster Runtime: 실행 환경을 검증 가능한 구성으로 관리

이번 글의 핵심 기술은 AICR(NVIDIA AI Cluster Runtime)이다.

AICR은 Dynamo를 실행하는 데 필요한 여러 Kubernetes 구성요소를 하나의 검증된 설정으로 관리하도록 돕는다.

예를 들어 AI 모델의 실제 추론 프로그램은 vLLM이나 SGLang을 사용할 수 있다.

하지만 추론 프로그램이 GPU를 제대로 사용하려면 적절한 드라이버가 설치돼 있어야 한다.

GPU를 어떤 Pod에 할당할지도 결정해야 한다.

서로 연결된 여러 GPU가 필요한 작업에서는 관련 자원을 함께 배치해야 할 수 있다.

AICR은 이런 구성요소를 Recipe(레시피)라는 형태로 정의한다.

여기서 레시피는 필요한 소프트웨어와 버전, 설정값과 검증 조건을 정리한 실행 구성이다.

예를 들어 다음과 같은 기술이 포함된다.

이렇게 하면 각 팀이 필요한 GPU 드라이버와 스케줄러, 모니터링 시스템을 독립적으로 조합하는 부담을 줄일 수 있다.

또한 특정한 소프트웨어 버전의 조합이 정상적으로 작동하는지 검증할 수 있다.

KV Cache가 라우팅의 중요한 기준

언어모델의 실제 실행에서는 KV Cache(Key-Value Cache)라는 기술이 사용된다.

KV Cache는 모델이 이전 입력을 처리하면서 계산한 Attention 관련 정보를 저장해 다시 사용할 수 있도록 하는 메모리 구조다.

예를 들어 사용자가 AI 코딩 에이전트에게 처음에 프로젝트 전체의 설명을 제공했다고 가정해 보자.

이후 에이전트는 파일을 수정하고 테스트를 실행하면서 여러 번 모델을 호출한다.

이 과정에서 프로젝트 설명과 시스템 지침은 반복해서 사용될 수 있다.

매번 같은 입력 전체를 다시 계산하면 비용과 시간이 증가할 수 있다.

KV Cache를 활용하면 일부 계산 결과를 재사용할 수 있다.

문제는 여러 GPU 서버에서 모델을 실행할 때 발생한다.

어떤 서버에는 특정한 대화의 KV Cache가 존재한다.

다른 서버에는 해당 캐시가 없을 수 있다.

이때 새로운 요청을 캐시가 없는 서버에 전달하면 이전 입력을 다시 처리해야 할 수 있다.

따라서 단순히 가장 한가한 GPU에 요청을 보내는 것이 최선은 아닐 수 있다.

Dynamo는 이런 문제를 해결하기 위해 KV Cache의 상태를 고려한 라우팅을 사용한다.

라우팅은 요청을 어떤 서버나 프로그램에 전달할지 결정하는 과정이다.

예를 들어 특정 대화의 캐시를 이미 보유한 GPU에 후속 요청을 전달하면 입력을 다시 처리하는 비용을 줄일 수 있다.

라우팅 방식 두 가지 비교

NVIDIA는 Dynamo에서 두 가지 라우팅 방식을 설명한다.

첫 번째는 Dynamo Frontend Router다.

Dynamo의 자체 라우터가 요청을 받은 뒤 적절한 GPU 작업자를 선택한다.

이 방식에서는 Dynamo가 캐시 상태와 서버의 부하를 함께 고려한다.

두 번째는 Gateway API와 EPP(Endpoint Picker Plugin)를 사용하는 방식이다.

Gateway API는 Kubernetes에서 외부 요청을 서비스에 전달하는 경로를 관리하기 위한 규격이다.

EPP는 여러 서버 가운데 실제 요청을 처리할 엔드포인트를 선택하는 구성요소다.

두 방식의 차이는 다음과 같다.

두 방식 모두 KV Cache 정보를 활용할 수 있다.

다만 Gateway API 방식에서는 실제 HTTP 요청을 전달하는 구성요소와 서버를 선택하는 구성요소가 분리된다.

이는 여러 모델과 서비스를 중앙의 네트워크 정책으로 관리하려는 기업에 유용할 수 있다.

반면 하나의 모델만 실행하는 단순한 서비스에서는 추가 구성요소가 오히려 복잡성을 높일 수 있다.

실제 캐시 상태와 예측된 캐시 상태의 차이

이번 글에서 흥미로운 부분은 캐시의 상태를 추정하는 방식에 관한 설명이다.

예를 들어 라우터는 특정한 요청을 GPU A에 전달했으므로 해당 GPU에 관련 KV Cache가 존재한다고 추정할 수 있다.

하지만 실제 GPU 메모리에는 제한이 있다.

메모리가 부족하면 기존 캐시가 제거될 수 있다.

이를 Cache Eviction(캐시 제거)이라고 한다.

라우터가 캐시 제거 사실을 모른다면 실제로는 캐시가 없는 서버에 요청을 전달할 수 있다.

Dynamo는 이런 문제를 줄이기 위해 GPU 작업자가 실제 캐시 상태의 변화를 이벤트로 전달하도록 설계됐다.

이를 KV Cache Event Plane(캐시 상태 이벤트 전달 계층)이라고 할 수 있다.

현재 구성에서는 실제 요청을 전달하는 경로와 캐시 상태를 전달하는 경로를 분리한다.

Dynamo 1.4.2에서는 요청 전달에 TCP를 사용하고, 캐시 이벤트 전달에는 ZMQ를 사용한다.

이렇게 하면 실제 요청의 경로와 GPU 메모리의 상태 정보를 별도로 관리할 수 있다.

모델의 입력과 출력 생성도 분리 가능

Dynamo는 Disaggregated Serving(분리형 추론)도 지원한다.

언어모델의 추론은 크게 두 단계로 구성된다.

첫 번째는 Prefill(입력 처리)이다.

모델이 사용자의 질문과 문서 전체를 읽고 중간 계산을 수행한다.

두 번째는 Decode(출력 생성)다.

모델이 다음 토큰을 하나씩 생성하면서 답변을 작성한다.

두 단계는 GPU의 계산과 메모리를 사용하는 방식이 다르다.

예를 들어 긴 문서를 분석하는 요청에서는 Prefill의 계산량이 많아질 수 있다.

반면 짧은 입력에 긴 답변을 생성하는 요청에서는 Decode의 비중이 높을 수 있다.

따라서 두 단계를 서로 다른 GPU 서버에 배치하면 작업의 특성에 맞춰 자원을 조정할 수 있다.

하지만 중간 계산 결과를 다른 서버로 전달하는 통신 비용이 발생한다.

따라서 모든 모델과 요청에서 분리형 추론이 더 효율적이라고 볼 수는 없다.

실제 배포에서는 버전 호환성도 중요

NVIDIA는 AICR의 레시피가 특정한 Kubernetes와 GPU, 소프트웨어 버전을 기준으로 검증된다고 설명한다.

예를 들어 GPU 드라이버와 스케줄러, Dynamo Operator의 버전이 서로 호환돼야 한다.

하나의 구성요소를 임의로 변경하면 이전에 검증된 설정이 더 이상 유효하지 않을 수 있다.

따라서 AICR은 실제 클러스터의 상태를 확인하고, 적절한 레시피를 생성한 뒤, 구성요소를 배포하고 검증하는 흐름을 제공한다.

이는 일반적인 Infrastructure as Code(코드로 관리하는 인프라) 원칙과 연결된다.

서버와 네트워크, 실행 환경의 구성을 문서화된 설정으로 관리해 재현성과 변경 이력을 확보하는 접근이다.

다만 AICR이 모든 Kubernetes 환경에서 자동으로 최적의 성능을 제공한다는 의미는 아니다.

하드웨어의 종류와 실제 작업 부하, 사용 중인 네트워크에 따라 추가적인 조정이 필요할 수 있다.

이번 글은 대규모 AI 서비스의 성능이 언어모델 자체의 추론 속도뿐 아니라 GPU 서버의 배치와 캐시 재사용, 네트워크 라우팅과 운영 환경의 안정성에 영향을 받는다는 사실을 이해하기 좋은 기술 자료다.

---

Building a Haunted House with NVIDIA Nemotron Open Models

• 저자: Rick Grandy, Maryam Motamedi
• 발행: NVIDIA / Hugging Face
• 게시일: 2026-10-30
• 원문: NVIDIA — Building a Haunted House with NVIDIA Nemotron Open Models

---

실시간으로 사람의 말을 듣고, 대답하고, 표정을 움직이는 AI 캐릭터를 만들려면 어떤 기술이 필요할까?

이번 글은 NVIDIA의 개발자가 실제 할로윈 행사에 사용할 목적으로 제작한 MonsterHouse라는 인터랙티브 AI 시스템을 소개한다.

MonsterHouse는 사람의 음성에 반응하는 집 모양의 캐릭터다.

집의 차고 문에는 움직이는 입이 표현돼 있다.

방문객이 말을 걸면 음성을 인식하고, 상황에 맞는 답변을 생성한 뒤, 실제 소리와 얼굴 애니메이션으로 표현한다.

이 사례가 흥미로운 이유는 하나의 거대한 AI 모델에 모든 작업을 맡기지 않았다는 점이다.

음성 인식과 대화 생성, 음성 합성과 얼굴 애니메이션, 카메라 영상 분석을 서로 다른 전문 모델에 맡기고 하나의 실시간 시스템으로 연결했다.

다섯 종류의 AI 구성요소

MonsterHouse는 다음 기술을 사용한다.

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

TTS(Text-to-Speech)는 텍스트를 실제 소리로 변환하는 기술이다.

VLM(Vision-Language Model)은 이미지와 텍스트를 함께 이해하는 AI 모델이다.

이런 전문 모델들을 연결하면 한 모델이 모든 입력과 출력을 직접 처리하지 않아도 복잡한 상호작용을 구현할 수 있다.

캐릭터의 성격은 별도로 학습

MonsterHouse의 캐릭터는 오래된 해적선의 나무로 만들어진 집이라는 설정을 가지고 있다.

처음에는 방문객에게 불친절하게 반응한다.

하지만 방문객이 정중하게 부탁하거나 감사 인사를 하면 조금씩 친절해진다.

이런 성격은 단순한 시스템 프롬프트만으로 완전히 구현하기 어려울 수 있다.

예를 들어 모델에게 불친절하게 행동하라고 지시하면 모든 대화에서 지나치게 적대적으로 응답할 수 있다.

반대로 정중하게 응답하도록 만들면 캐릭터의 설정이 사라질 수 있다.

개발자는 이를 해결하기 위해 5,000개 이상의 다중 턴 대화 예시를 준비했다.

다중 턴 대화는 여러 번의 질문과 답변이 이어지는 상호작용이다.

이후 해당 데이터로 LoRA(Low-Rank Adaptation)를 학습했다.

LoRA는 대형 모델의 모든 가중치를 변경하는 대신 상대적으로 적은 추가 파라미터를 학습하는 기술이다.

이를 통해 기존 언어모델의 일반적인 능력을 유지하면서 특정 캐릭터의 말투와 행동을 조정할 수 있다.

개발자는 실제로 열 개 이상의 모델을 시험한 뒤 Nemotron 3.5 Bolt E4B를 선택했다고 밝혔다.

선택 기준에는 답변의 품질뿐 아니라 실행 속도와 메모리 사용량도 포함됐다.

실시간 대화에서는 응답 지연이 중요

일반적인 채팅 애플리케이션에서는 답변이 몇 초 늦게 나타나더라도 사용자가 기다릴 수 있다.

하지만 실제 사람과 대화하는 음성 캐릭터에서는 지연시간이 길어지면 어색한 상황이 발생한다.

예를 들어 방문객이 인사를 했는데 집이 10초 뒤에 대답한다면 자연스러운 대화가 어려울 수 있다.

개발자는 이를 해결하기 위해 여러 방법을 사용했다.

먼저 자주 사용하는 인사말과 대사를 미리 저장했다.

또한 일부 문장에 대해서는 생성된 음성을 파일로 저장해 다시 사용했다.

이런 방식을 Caching(캐싱)이라고 한다.

반복해서 사용할 데이터를 미리 저장해 계산을 줄이는 기술이다.

실제 측정 결과는 다음과 같다.

미리 저장한 음성을 사용한 경우 응답이 더 빨랐다.

하지만 모든 상황에서 미리 저장한 대사를 사용할 수는 없다.

방문객이 예상하지 못한 질문을 하면 새로운 문장을 생성해야 한다.

따라서 MonsterHouse는 정해진 상황에서는 캐시를 활용하고 새로운 상황에서는 AI 모델을 실행하는 하이브리드 구조를 사용했다.

음성 생성과 얼굴 애니메이션 분리

MonsterHouse는 음성에 맞춰 차고 문에 표현된 입을 움직인다.

이 작업에는 Audio2Face-3D가 사용된다.

Audio2Face는 음성의 특징을 분석해 캐릭터의 얼굴 움직임을 생성하는 기술이다.

하지만 이번 캐릭터의 목소리는 일반적인 사람의 목소리보다 훨씬 낮고 특수한 효과가 포함돼 있다.

이런 음성을 그대로 얼굴 애니메이션 모델에 전달하면 움직임의 정확도가 떨어질 수 있다.

개발자는 이를 해결하기 위해 두 종류의 음성 경로를 사용했다.

하나는 얼굴 애니메이션을 생성하기 위한 깨끗한 원본 음성이다.

다른 하나는 실제 방문객에게 들려줄 효과음이 포함된 음성이다.

또한 얼굴 애니메이션과 실제 소리가 어긋나지 않도록 약 100ms의 보정 지연을 적용했다.

이런 방식은 실시간 멀티모달 시스템에서 중요한 문제를 보여준다.

단순히 각각의 모델이 좋은 결과를 생성하는 것만으로는 충분하지 않다.

서로 다른 모델이 생성한 결과를 시간적으로 정확하게 맞추는 작업도 필요하다.

GPU도 역할에 따라 분리

개발자는 하나의 워크스테이션에서 MonsterHouse를 실행했다.

다만 모든 작업을 하나의 GPU에 맡기지는 않았다.

언어모델과 음성 처리 작업에는 NVIDIA RTX PRO 6000 Blackwell Max-Q를 사용했다.

Unreal Engine과 얼굴 애니메이션에는 NVIDIA RTX PRO 4000 Blackwell을 사용했다.

GPU를 분리한 이유는 메모리 용량뿐 아니라 계산 자원의 경쟁을 줄이기 위해서다.

예를 들어 언어모델이 새로운 답변을 생성하는 동안 GPU의 계산 자원을 많이 사용하면 그래픽 렌더링의 프레임 속도가 떨어질 수 있다.

실시간 애니메이션에서는 일정한 프레임 속도를 유지하는 것이 중요하다.

따라서 두 작업을 서로 다른 GPU에 배치해 영향을 줄이려 했다.

이런 설계는 게임과 로봇, 실시간 음성 에이전트에서도 참고할 수 있다.

아직 실제 할로윈 운영은 완전히 검증되지 않았다

개발자는 카메라 영상 분석에 관한 기능도 시험했다.

Nemotron 3 Nano Omni는 방문객의 복장을 분석해 캐릭터의 대화에 필요한 시각적 맥락을 제공한다.

YOLO와 ByteTrack은 방문객의 수와 이동을 추적한다.

하지만 공개된 영상 분석 사례 가운데 일부는 실제 방문객이 아니라 합성된 시험 영상을 사용한 결과다.

또한 개발자는 실제 야간 환경에서 여러 방문객과 상호작용하는 과정을 아직 충분히 검증하지 않았다고 밝혔다.

따라서 이번 글을 완성된 상용 제품의 성능 평가로 이해해서는 안 된다.

실제 운영을 위한 개발 과정과 초기 시험 결과에 가깝다.

그럼에도 이번 사례는 여러 작은 전문 AI 모델을 연결해 하나의 실시간 서비스를 구현할 때 발생하는 문제를 구체적으로 보여준다.

특히 대화의 자연스러움과 캐싱, 음성·영상 동기화, GPU 자원 분리, 실제 운영 환경에서의 검증이 얼마나 중요한지 이해하기 좋은 자료다.