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

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

---

1️⃣ 주요 모델·연구

Google, ‘Gemini 4 Hydrogen’ 출시…코딩 에이전트 성능 개선하고 Carbon과 자동으로 역할을 나누는 실행 환경 제공

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 대형 언어모델, 코딩 에이전트, 멀티모달 AI, 모델 오케스트레이션, Google Antigravity, Gemini API, Google 검색
• 원문: Google — Introducing Gemini 4 Hydrogen

---

Google이 새로운 Gemini 4 계열 모델 Gemini 4 Hydrogen을 공개했다.

이번 모델은 기존 Gemini 4 Carbon과 Argon을 대체하는 모델이 아니다.

Carbon과 Argon이 장시간에 걸친 복잡한 추론과 소프트웨어 설계, 고난도 연구 작업에 집중한다면, Hydrogen은 실제 프로그램을 실행하고 파일을 수정하며 여러 단계를 빠르게 처리해야 하는 업무에 초점을 맞췄다.

특히 Google은 Hydrogen을 단독으로 사용하는 방식뿐 아니라 여러 모델이 하나의 작업을 함께 처리하는 구조도 공개했다.

이번 발표에서 중요한 변화는 새로운 모델의 출시와 함께 Google Antigravity에 Orchestrator 기능이 추가됐다는 점이다.

복잡한 설계와 반복적인 실행을 서로 다른 모델에 맡긴다

일반적인 AI 코딩 에이전트는 하나의 모델이 여러 단계를 순서대로 처리할 수 있다.

예를 들어 사용자가 기존 웹 애플리케이션에 새로운 기능을 구현하도록 요청했다고 가정해 보자.

먼저 프로젝트의 구조를 분석해야 한다.

이후 어떤 파일을 수정해야 하는지 결정한다.

실제 코드를 작성하고 테스트를 실행한다.

테스트가 실패하면 오류를 분석하고 다시 수정해야 한다.

문제는 이러한 작업의 모든 단계가 같은 수준의 추론 능력을 필요로 하지는 않는다는 것이다.

예를 들어 여러 시스템의 관계를 분석해 새로운 아키텍처를 설계하는 작업에는 강력한 추론 모델이 유리할 수 있다.

반면 이미 결정한 설계를 실제 코드로 구현하고 테스트를 반복하는 작업에는 빠르고 저렴한 모델이 더 효율적일 수 있다.

Google은 이를 해결하기 위해 Model Orchestration(모델 오케스트레이션)을 도입했다.

모델 오케스트레이션은 하나의 목표를 달성하기 위해 여러 AI 모델의 역할을 조정하는 기술이다.

이번에 공개된 Antigravity의 Orchestrator는 작업 진행 상황에 따라 Carbon과 Hydrogen 같은 모델을 동적으로 선택한다.

예를 들어 Carbon이 복잡한 코딩 작업의 전체 방향을 결정할 수 있다.

이후 Hydrogen이 실제 파일을 수정하고 테스트를 실행한다.

어려운 문제가 다시 발생하면 Carbon이 추가적인 판단을 수행하도록 구성할 수 있다.

중요한 점은 사용자가 작업의 모든 단계에서 모델을 직접 변경할 필요를 줄였다는 사실이다.

Terminal-Bench 성능 18.2%에서 57.0%로 개선

Google은 Hydrogen의 실제 코딩 능력을 여러 벤치마크에서 평가했다.

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

대표적인 평가인 Terminal-Bench는 AI 에이전트가 실제 터미널에서 프로그램을 실행하고 파일을 수정해 작업을 완료하는 능력을 측정한다.

Google이 공개한 결과는 다음과 같다.

Hydrogen은 Terminal-Bench 4.1에서 기존 Flash보다 38.8%포인트 높은 점수를 기록했다.

다만 이 수치를 모든 종류의 실제 코딩 업무에서 작업 성공률이 38.8%포인트 증가했다는 의미로 해석해서는 안 된다.

해당 벤치마크에서 측정한 성능이다.

또한 작업 완료 속도가 2.5배 빨라졌다는 결과는 Google이 설정한 비교 조건에서 얻어졌다.

실제 작업에서는 파일의 크기와 테스트 실행시간, 외부 API의 응답 속도에 따라 차이가 발생할 수 있다.

Google은 Hydrogen이 도구 호출이 실패하거나 검색 결과가 비어 있는 상황에서도 다음 행동을 조정하는 능력을 개선했다고 설명한다.

이런 능력은 실제 에이전트에 중요하다.

예를 들어 에이전트가 특정한 파일을 찾으려 했지만 존재하지 않을 수 있다.

이때 존재하지 않는 파일의 내용을 추측하는 대신 다른 위치를 검색하거나 사용자에게 필요한 정보를 확인해야 한다.

모델이 실패한 도구 호출을 어떻게 처리하는지는 최종 결과의 신뢰성에 직접적인 영향을 줄 수 있다.

Orchestrator로 사용량과 작업시간 감소

Google은 여러 모델을 함께 사용하는 Orchestrator도 평가했다.

Terminal-Bench 4.0에서는 Carbon 단독 실행과 비슷한 작업 성공률을 유지하면서 다음 결과를 기록했다고 밝혔다.

이 결과는 단순히 작은 모델을 사용했기 때문에 발생한 것은 아니다.

복잡한 판단이 필요한 순간에는 강력한 모델을 사용하고, 상대적으로 단순한 실행 단계에서는 빠른 모델을 사용하는 구조가 영향을 준다.

Google은 Carbon이 전체 작업을 조정하는 역할을 맡고 Hydrogen이 작업자와 검증자의 역할을 수행하는 구성도 소개했다.

예를 들어 여러 에이전트가 서로 다른 파일을 수정하고 별도의 에이전트가 테스트 결과를 검사하도록 만들 수 있다.

이때 작업 공간을 분리하면 서로 다른 에이전트가 같은 파일을 동시에 수정하면서 변경사항을 덮어쓰는 문제를 줄일 수 있다.

하지만 실제로 여러 에이전트를 사용하면 추가적인 조정 비용도 발생한다.

각 에이전트의 작업 결과를 다시 통합해야 하고, 서로 의존하는 작업에서는 완료 순서를 관리해야 하기 때문이다.

따라서 여러 모델을 조합한다고 해서 모든 작업에서 같은 비용 절감 효과가 나타나는 것은 아니다.

위 수치 역시 Google이 공개한 자체 평가 결과다.

독립 평가와 Google 자체 평가의 구분

Google은 외부 평가기관인 Artificial Analysis의 결과도 소개했다.

해당 기관의 Intelligence Index에서는 Hydrogen이 기본 High 추론 설정에서 51점을 기록했다.

Gemini 4 Argon은 50점이었다.

Hydrogen은 가장 높은 xhigh 추론 설정에서 54점을 기록했다.

이 점수는 외부 평가기관의 벤치마크에서 얻어진 결과다.

하지만 특정한 종합 지표가 1점 높다는 사실만으로 Hydrogen이 모든 작업에서 Argon보다 우수하다는 의미는 아니다.

실제로 모델은 작업의 종류와 추론 설정에 따라 서로 다른 성능을 보일 수 있다.

Google은 Hydrogen이 다음 네 가지 추론 수준을 지원한다고 밝혔다.

여기서 Thinking Level(추론 수준)은 모델이 답변을 생성하기 전에 수행하는 내부 추론의 정도를 조절하는 설정이다.

더 높은 추론 수준이 항상 좋은 선택은 아니다.

간단한 질문에는 추가적인 추론이 실제 결과를 개선하지 못하면서 응답시간과 비용만 증가시킬 수 있다.

API 가격과 제공 범위

Google은 Hydrogen의 API 가격을 다음과 같이 발표했다.

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

Hydrogen은 최대 100만 토큰의 컨텍스트를 지원한다.

컨텍스트는 하나의 요청에서 모델이 참고할 수 있는 입력과 이전 대화 등의 정보 범위다.

다만 최대 100만 토큰을 입력할 수 있다는 사실만으로 모든 정보를 완벽하게 기억하거나 추론할 수 있다는 의미는 아니다.

실제 긴 문맥의 정확성은 별도의 평가가 필요하다.

Hydrogen은 Google AI Studio와 Gemini API, 기업용 Gemini 서비스에서 제공된다.

또한 Gemini 앱과 Google 검색에도 적용된다.

Google Antigravity의 유료 사용자에게는 Carbon과 Hydrogen을 조합한 실행 기능도 제공된다.

이번 발표는 AI 모델의 경쟁이 단일 모델의 성능을 높이는 것뿐 아니라 각 작업에 적절한 모델을 배치하고 여러 모델의 역할을 조정해 실제 업무를 완료하는 방향으로 확대되고 있음을 보여준다.

---

Perplexity, 판단 특화 모델 ‘Decider v1.3’과 경량 모델 공개…문장 생성 없이 분류·검색 순위·개인정보 추출

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 오픈웨이트 AI, 분류 모델, AI 에이전트, 모델 라우팅, 검색 순위 결정, 개인정보 식별, 멀티모달 분석
• 원문: Perplexity — Perplexity Decider v1.3: Training, eval, and use cases
• 관련 원문: Hugging Face — Perplexity Decider v1.3

---

Perplexity가 새로운 판단 특화 모델 Decider v1.3과 Decider Flash v1.3을 공개했다.

이번 모델은 일반적인 챗봇처럼 긴 문장을 생성하도록 설계되지 않았다.

주어진 입력을 분석하고 여러 선택지 가운데 어떤 결과가 적절한지 확률로 반환하는 작업에 특화됐다.

예를 들어 고객지원 시스템에 새로운 문의가 접수됐다고 가정해 보자.

AI는 해당 문의가 결제 문제인지, 배송 문제인지, 계정 문제인지 판단해야 할 수 있다.

이때 일반적인 언어모델을 사용하면 분류 결과를 자연어로 생성한 뒤 다시 프로그램이 해당 결과를 추출해야 할 수 있다.

하지만 실제로 필요한 것은 몇 개의 정해진 범주 가운데 하나를 선택하는 작업이다.

Decider는 이런 종류의 업무를 효율적으로 수행하도록 설계됐다.

일반적인 언어모델과 판단 모델의 차이

일반적인 생성형 언어모델은 토큰을 하나씩 생성한다.

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

예를 들어 모델이 긴 답변을 작성할 때는 앞서 생성한 토큰을 참고해 다음 토큰을 계속 예측한다.

반면 Decider는 필요한 질문과 선택지를 미리 전달받는다.

이후 각 선택지에 대한 확률을 계산한다.

이를 통해 다음과 같은 작업을 수행할 수 있다.

특히 여러 질문이 같은 입력을 공유할 수 있다는 점이 중요하다.

예를 들어 하나의 고객 문의에 대해 긴급도와 담당 부서, 개인정보 포함 여부를 함께 판단할 수 있다.

같은 원본 텍스트를 여러 번 처리할 필요를 줄일 수 있기 때문이다.

Qwen 기반 모델을 판단 작업에 맞게 변경

Decider v1.3은 Qwen3.8-27B를 기반으로 개발됐다.

경량 모델인 Decider Flash v1.3은 Qwen3.5-4B를 기반으로 한다.

Perplexity는 큰 Decider 모델의 지식을 작은 Flash 모델에 전달하는 학습 방식을 사용했다.

이를 지식 증류(Knowledge Distillation)라고 한다.

지식 증류는 큰 교사 모델이 가진 지식을 상대적으로 작은 학생 모델에 전달하는 기술이다.

이번 학습에서는 교사 모델이 계산한 여러 선택지의 확률 분포를 학생 모델이 모방하도록 했다.

단순히 정답 선택지 하나를 학습하는 것과 다르다.

예를 들어 교사 모델이 세 선택지에 각각 70%, 20%, 10%의 확률을 부여했다면 학생 모델도 이런 판단의 차이를 학습할 수 있다.

또한 Perplexity는 언어모델의 Attention 구조도 변경했다.

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

일반적인 생성형 모델은 현재 토큰보다 뒤에 있는 내용을 직접 참고하지 않도록 설계될 수 있다.

반면 문서를 분류할 때는 문서 전체를 참고하는 편이 유리할 수 있다.

Perplexity는 이를 위해 양방향 Attention을 적용했다.

또한 여러 질문이 서로 불필요하게 영향을 주는 문제를 줄이기 위해 질문별 계산 경로를 분리했다.

새로운 Locate 기능으로 정확한 문자열 추출

이번 업데이트의 주요 신규 기능은 Locate다.

Locate는 입력 문장에서 필요한 정보가 실제로 존재하는 위치를 반환한다.

예를 들어 다음 문장이 있다고 가정해 보자.

고객이 이메일 주소를 남기고 환불을 요청했다.

이때 모델은 이메일 주소가 무엇인지 새로운 문장으로 작성하는 대신 원문에서 해당 문자열이 시작하고 끝나는 위치를 반환할 수 있다.

이런 방식을 Span Extraction(구간 추출)이라고 한다.

원본 텍스트에서 특정한 정보가 존재하는 구간을 찾는 기술이다.

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

• 이름과 조직, 장소의 식별
• 이메일 주소와 전화번호 탐지
• 개인정보가 포함된 텍스트의 검사
• 계약서에서 특정한 조항 추출
• 문서에서 질문에 해당하는 문구 검색

중요한 점은 새로운 Locate 기능이 기존 판단 기능에 영향을 주지 않도록 설계됐다는 것이다.

Perplexity는 Locate를 학습한 가중치를 기존 모델에 완전히 병합하면 일부 분류 능력이 저하되는 현상을 발견했다.

따라서 이번 버전에서는 Locate에 필요한 별도의 LoRA 어댑터를 유지한다.

LoRA(Low-Rank Adaptation)는 모델 전체의 가중치를 변경하는 대신 상대적으로 적은 추가 파라미터를 학습하는 방법이다.

Locate 기능이 필요한 요청에서만 관련 어댑터를 활성화한다.

기존 내부 분류기보다 평균 정확도 6.54%포인트 개선

Perplexity는 실제 서비스와 관련된 분류 작업 63개를 이용해 모델을 평가했다.

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

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

높은 점수는 관련 문서가 검색 결과의 앞부분에 배치되는 경향이 강하다는 의미다.

Perplexity는 72개 검색 재정렬 작업에서 Decider가 Qwen3-Reranker-8B보다 평균 1.81점 높은 nDCG@10을 기록했다고 설명했다.

또한 한국어를 포함한 8개 언어의 분류 작업에서도 비교 대상인 Jev 1.14보다 높은 평균 정확도를 기록했다.

다만 이 수치들은 Perplexity가 구성하고 실행한 평가 결과다.

일부 비교에는 외부 공개 벤치마크가 사용됐지만 평가 전체를 독립적인 기관이 검증한 것은 아니다.

또한 여러 벤치마크에 반복적으로 모델을 제출하면 실제로는 평가 데이터의 특성에 맞춰지는 문제가 발생할 수 있다.

Perplexity 역시 이런 한계를 인정하고 별도의 내부 평가 자료를 사용했다고 설명한다.

실제 보안 에이전트의 감시에도 활용

Perplexity는 Decider를 실제 서비스의 에이전트 감시에도 활용하고 있다고 밝혔다.

예를 들어 에이전트가 외부 도구를 호출하려는 상황을 생각할 수 있다.

해당 호출이 허용된 작업에 해당하는지 검사해야 할 수 있다.

또는 외부 문서에서 가져온 정보에 악의적인 지시가 포함돼 있는지 확인할 수 있다.

Perplexity는 이런 작업에서 전문 분류 모델을 사용해 여러 위험 신호를 검토한다.

다만 분류 모델이 위험한 행동을 탐지한다는 사실과 실제로 해당 행동을 차단하는 것은 다르다.

중요한 실행 권한은 별도의 프로그램에서 제한해야 한다.

이번 모델들은 Hugging Face에 오픈웨이트로 공개됐다.

또한 OpenRouter와 Perplexity Decisions API에서도 사용할 수 있다.

공개 모델에는 Apache 계열 라이선스가 적용된다.

이번 발표는 AI 애플리케이션을 개발할 때 모든 작업에 범용 생성형 모델을 사용할 필요는 없다는 점을 보여준다.

분류와 검색 순위 결정, 정보 추출처럼 답변의 형태가 명확한 작업은 별도의 전문 모델로 분리하는 방식이 실제 속도와 비용, 시스템 설계의 효율을 높일 수 있다.

---

Salesforce, 260억 파라미터 음성인식 모델 ‘SOV-Transcribe-1’ 오픈웨이트 공개…영어 전사 오류율 2.28%

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 음성인식 AI, 오픈웨이트 모델, 다국어 전사, 콜센터, 음성 에이전트, 의료·금융 전문용어 처리
• 원문: Salesforce — Introducing SOV-Transcribe-1

---

Salesforce의 AI 연구팀이 새로운 오픈웨이트 음성인식 모델 SOV-Transcribe-1을 공개했다.

이번 모델은 텍스트를 음성으로 생성하는 모델이 아니다.

사람이 말한 음성을 실제 텍스트로 변환하는 ASR(Automatic Speech Recognition, 자동 음성인식) 모델이다.

특히 일반적인 단어의 인식 정확도뿐 아니라 실제 업무에서 중요한 전화번호와 이메일 주소, 코드와 전문용어를 얼마나 정확하게 기록하는지에 초점을 맞췄다.

모델은 총 260억 개의 파라미터를 가지며 실제 계산에는 약 40억 개의 파라미터를 활성화한다.

이런 구조는 MoE(Mixture of Experts) 계열의 모델로 이해할 수 있다.

MoE는 여러 전문 신경망 가운데 입력에 필요한 일부만 활성화하는 구조다.

전체 가중치의 규모는 크지만 매번 모든 파라미터를 계산할 필요를 줄일 수 있다.

일반적인 음성인식 정확도보다 중요한 정보

음성인식 모델에서는 보통 WER(Word Error Rate, 단어 오류율)이라는 지표를 사용한다.

WER은 실제 발화한 문장과 모델이 생성한 문장을 비교해 얼마나 많은 단어가 잘못 인식됐는지 계산하는 지표다.

단어의 삽입과 누락, 교체를 기준으로 계산한다.

예를 들어 음성인식 모델이 긴 문장의 대부분을 정확하게 기록했다고 가정해 보자.

하지만 사용자가 말한 이메일 주소에서 숫자 하나를 잘못 기록했을 수 있다.

이 경우 전체 WER은 낮더라도 실제 업무는 실패할 수 있다.

이메일을 잘못된 주소로 보내거나 고객의 계정을 찾지 못할 수 있기 때문이다.

Salesforce는 이를 해결하기 위해 실제 업무에서 중요한 정보를 별도로 평가했다.

독립 음성인식 리더보드에서 상위권 기록

Salesforce가 공개한 대표적인 평가 결과는 다음과 같다.

Artificial Analysis는 외부 AI 모델 평가기관이다.

해당 기관의 평가에서는 SOV-Transcribe-1이 오픈웨이트 비스트리밍 음성인식 모델 가운데 가장 낮은 영어 단어 오류율을 기록했다.

비교 대상인 NVIDIA Nemotron 3.5 Transcribe의 오류율은 2.81%였다.

Mistral Voxtral Small은 2.77%였다.

다만 해당 비교 결과는 2026년 11월 12일 기준 평가 목록에 포함된 모델을 대상으로 한다.

모든 음성인식 모델보다 항상 높은 정확도를 기록한다는 의미는 아니다.

또한 VoiceCodeBench의 76.3%는 녹음 하나에 포함된 중요한 정보를 모두 정확하게 기록한 비율이다.

예를 들어 하나의 녹음에 이메일과 전화번호가 함께 포함됐다면 둘 가운데 하나만 틀려도 해당 녹음은 실패로 판단할 수 있다.

이는 단어 전체의 평균적인 정확도와 다른 지표다.

악센트와 실제 통화 환경에서의 평가

실제 음성인식에서는 발음과 억양의 차이가 중요하다.

예를 들어 같은 영어라도 영국과 아일랜드, 인도와 싱가포르에서 발음하는 방식이 다를 수 있다.

모델이 일부 지역의 음성만 학습했다면 다른 억양의 음성을 처리하는 정확도가 낮아질 수 있다.

Salesforce는 14개 영어 악센트를 포함한 AppTek Call-Center Dialogues에서 모델을 평가했다.

그 결과 평균 8.21%의 WER을 기록했다.

14개 악센트 가운데 8개에서 가장 낮은 오류율을 기록했다고 밝혔다.

또한 실제 기업의 실적발표 음성을 이용한 HALAS 평가에서는 25.69%의 WER을 기록했다.

여기서 흥미로운 점은 평가 데이터의 종류에 따라 오류율이 크게 달라진다는 사실이다.

깨끗한 녹음에서는 낮은 오류율을 기록하더라도 실제 회의나 통화에서는 배경 소음과 겹치는 발화, 고유명사 등의 영향으로 오류가 증가할 수 있다.

따라서 2.28%라는 수치 하나만으로 실제 모든 음성인식 업무의 정확도를 판단해서는 안 된다.

전문용어를 알려주면 인식 정확도 개선

이번 모델은 사용자가 중요한 용어를 미리 전달할 수 있도록 지원한다.

이를 Context Biasing(문맥 기반 인식 보정)이라고 한다.

예를 들어 의료기관의 음성 기록에는 특정한 약품 이름이 반복해서 등장할 수 있다.

하지만 일반적인 음성인식 모델은 해당 약품 이름을 자주 등장하는 일반 단어로 잘못 인식할 수 있다.

이때 모델에 관련 약품 이름을 미리 제공하면 해당 단어를 더 정확하게 인식하도록 유도할 수 있다.

Salesforce는 금융 실적발표 음성에서 이런 기능을 평가했다.

특정한 회사와 사람, 상품 이름을 미리 제공한 결과 핵심 단어의 F1 점수가 다음처럼 변화했다.

F1 점수는 정밀도와 재현율을 함께 고려하는 지표다.

정밀도는 모델이 찾아낸 정보 가운데 실제로 올바른 정보의 비율이다.

재현율은 실제로 존재하는 정보 가운데 모델이 얼마나 많이 찾아냈는지 나타낸다.

이번 결과는 중요한 용어를 미리 알고 있는 업무에서 문맥 정보를 제공하는 방식이 도움이 될 수 있음을 보여준다.

하지만 모델이 제공된 용어를 지나치게 우선해 실제로 말하지 않은 단어를 생성할 가능성도 고려해야 한다.

일반적인 전사와 편집된 전사 구분

SOV-Transcribe-1은 자연어 지시로 전사 결과의 형식을 조절할 수도 있다.

예를 들어 법률 기록에서는 실제 발화한 내용을 최대한 그대로 보존해야 할 수 있다.

반면 메모 작성에서는 말하는 과정에서 발생한 반복 표현과 불필요한 추임새를 제거하는 편이 유용할 수 있다.

Salesforce는 모델이 이런 요구사항을 구분해 처리하도록 설계했다고 설명한다.

하지만 음성을 그대로 기록하는 작업과 문장을 읽기 좋게 수정하는 작업은 구분해야 한다.

특히 중요한 법률·의료 기록에서는 실제로 발화하지 않은 내용이 추가되지 않았는지 확인해야 한다.

오픈웨이트 제공과 실제 사용 범위

SOV-Transcribe-1은 Apache 2.0 라이선스로 공개됐다.

개발자는 Hugging Face에서 가중치를 다운로드해 자체 환경에서 실행할 수 있다.

다만 이번 모델은 비스트리밍(Non-Streaming) ASR에 초점을 맞춘다.

비스트리밍은 녹음된 입력을 받아 전사하는 방식이다.

실제 발화가 진행되는 동안 매우 짧은 지연으로 결과를 계속 출력해야 하는 실시간 스트리밍 서비스와는 요구사항이 다를 수 있다.

따라서 음성 통화 중 실시간 자막을 제공하는 작업에 바로 최적화된 모델이라고 판단해서는 안 된다.

이번 발표는 음성 AI의 성능 경쟁이 일반적인 단어 인식 정확도뿐 아니라 업무상 중요한 숫자와 고유명사, 발음의 다양성과 실제 녹음 환경에서의 정확성으로 확대되고 있음을 보여준다.

---

2️⃣ AI 제품·서비스

Google·삼성·젠틀몬스터, Gemini 탑재 AI 안경 예약 판매 시작…한국 출시 대상에 포함되고 실시간 번역·시각 보조 지원

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 멀티모달 AI, 스마트 안경, 온디바이스 기기, Gemini, 실시간 번역, 접근성, 개인정보 보호
• 원문: Google — See our intelligent eyewear lineup and pre-order your pair
• 관련 원문: Google — Designing for privacy on intelligent eyewear

---

Google이 Gemini를 탑재한 새로운 스마트 안경 제품군의 예약 판매를 시작했다.

이번 발표에는 Google과 삼성전자, 젠틀몬스터, Warby Parker가 참여한다.

새로운 제품의 특징은 사용자가 스마트폰을 직접 꺼내지 않아도 안경의 카메라와 마이크를 이용해 주변 환경을 이해하고 Gemini와 대화할 수 있다는 점이다.

예를 들어 사용자가 외국어로 작성된 메뉴판을 보고 있다고 가정해 보자.

일반적으로는 스마트폰을 꺼내 카메라로 메뉴판을 촬영하고 번역을 요청할 수 있다.

반면 스마트 안경에서는 사용자가 바라보는 장면을 바탕으로 음성으로 질문할 수 있다.

이런 방식은 멀티모달 AI(Multimodal AI)와 연결된다.

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

12MP 카메라와 최대 9시간 사용

Google이 공개한 제품의 주요 사양은 다음과 같다.

실제로는 안경과 연결된 스마트폰을 함께 사용한다.

따라서 스마트폰 없이 모든 AI 기능을 독립적으로 실행하는 기기라고 이해해서는 안 된다.

또한 최대 9시간이라는 배터리 사용시간은 Google이 제시한 제품 사양이다.

실제 사용시간은 카메라와 통화, 음악 재생과 AI 기능의 사용 비율에 따라 달라질 수 있다.

젠틀몬스터 제품은 한국에서도 제공

이번 발표에서는 두 브랜드의 제품군이 공개됐다.

Google은 제품의 정식 매장 판매 시점을 2026년 12월 10일로 안내했다.

따라서 예약 판매가 시작됐다는 사실과 모든 지역의 소비자가 실제 제품을 즉시 수령할 수 있다는 사실은 구분해야 한다.

젠틀몬스터 제품은 한국을 주요 판매 지역에 포함했다.

다만 달러 기준 시작 가격이 한국의 실제 판매가격과 동일하다는 의미는 아니다.

국가별 판매가격과 렌즈 구성, 배송 및 구매 조건은 별도로 확인해야 한다.

안경이 보는 장면을 Gemini가 이해

이번 제품에서는 사용자가 음성으로 질문할 수 있다.

예를 들어 길을 걷다가 건물의 안내 표지판을 보고 해당 내용에 대해 질문할 수 있다.

또는 도서관의 책을 바라보며 관련 추천을 요청할 수도 있다.

Google은 다음과 같은 활용 사례를 소개했다.

• 외국어 메뉴판과 표지판의 내용 이해
• 실시간 번역
• Google Maps를 이용한 길 안내
• 일정과 관련 정보 확인
• 장보기 목록 작성
• 시각장애인을 위한 주변 환경 음성 설명

특히 접근성 분야에서는 Guided Vision 기능을 활용한다.

예를 들어 시각장애인이 작은 글씨를 읽거나 일상적인 물체를 찾는 작업에서 AI의 음성 안내를 받을 수 있다.

하지만 이러한 기능이 실제 주변 환경의 모든 정보를 정확하게 파악한다는 의미는 아니다.

카메라의 시야와 조명, 물체의 크기와 AI의 시각적 이해 능력에 따라 오류가 발생할 수 있다.

특히 횡단보도와 차량, 위험한 장애물에 관한 판단에서는 AI의 설명만을 유일한 안전 근거로 삼아서는 안 된다.

카메라 영상과 개인정보 처리 분리

이번 발표에서 중요한 부분은 Google이 같은 날 공개한 개인정보 보호 정책이다.

스마트 안경은 착용자가 바라보는 장면을 카메라로 처리한다.

그런데 착용자 주변에는 촬영이나 AI 분석에 동의하지 않은 사람이 존재할 수 있다.

따라서 일반적인 스마트폰 카메라와는 다른 개인정보 보호 문제가 발생한다.

Google은 이를 해결하기 위해 여러 보호장치를 적용했다고 밝혔다.

첫 번째는 Gemini History에 카메라의 시각적 입력을 저장하지 않는 방식이다.

착용자가 주변 환경을 질문하면서 제공한 카메라 영상은 일반적인 Gemini 대화 기록에 저장되지 않는다고 설명한다.

또한 해당 영상은 AI 모델 학습이나 광고 타기팅에 사용하지 않는다고 밝혔다.

하지만 텍스트 대화에 대해서는 별도의 기록과 학습 설정이 적용될 수 있다.

따라서 카메라 영상과 실제 대화 기록의 처리 조건은 구분해야 한다.

두 번째는 주변 사람의 얼굴을 자동으로 가리는 기능이다.

Google은 Gemini가 장면을 처리하기 전에 주변 사람의 얼굴을 식별할 수 없도록 가리는 기술을 적용했다고 설명한다.

다만 모든 각도와 조명, 복잡한 장면에서 얼굴을 완벽하게 가릴 수 있는지는 실제 환경에서 검증해야 한다.

세 번째는 촬영 상태를 알리는 물리적 표시등이다.

사진이나 동영상을 촬영할 때 바깥쪽 LED가 켜지도록 설계됐다.

Google은 해당 표시등이 가려지거나 조작된 상황을 감지해 촬영을 제한하는 기능도 소개했다.

또한 안경을 완전히 끌 수 있는 물리적 스위치가 제공된다.

카메라 접근권한도 앱별로 제한

Google은 외부 앱이 안경의 카메라를 사용하려면 사용자의 허가를 받아야 한다고 설명한다.

예를 들어 어떤 앱은 안경 카메라를 이용해 사용자가 보고 있는 책의 페이지를 인식할 수 있다.

하지만 해당 앱이 카메라에 접근할 수 있다는 사실만으로 다른 모든 앱에도 같은 권한이 부여돼서는 안 된다.

이를 위해 앱별 접근권한을 설정하고 이후에도 권한을 회수할 수 있도록 설계했다.

또한 안경에 저장된 데이터와 외부로 전송되는 데이터에는 암호화 기능을 적용한다.

암호화(Encryption)는 데이터를 정해진 키가 없으면 이해하기 어려운 형태로 변환하는 기술이다.

다만 전송 과정의 암호화와 AI 모델이 실제로 데이터를 처리하는 과정의 보호는 서로 다른 문제다.

Google은 더 강한 실행환경 보호를 위한 Private AI Compute 기술도 향후 적용할 계획이라고 밝혔다.

이는 발표 시점에 모든 기능이 이미 적용됐다는 의미는 아니다.

이번 발표는 생성형 AI가 스마트폰과 컴퓨터 화면을 넘어 사용자가 일상적으로 착용하는 기기와 직접 연결되는 방향으로 확대되고 있음을 보여준다.

동시에 시각정보를 수집하는 AI 기기에서는 착용자뿐 아니라 주변 사람의 개인정보까지 고려하는 설계가 중요해지고 있다.

---

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

IBM, AI 지시문과 외부 데이터를 구분하는 ‘LLMON’ 공개…Granite 4.1 기반 모델에서 프롬프트 인젝션 저항성 개선

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 오픈소스 언어모델, AI 에이전트, 프롬프트 인젝션 방어, RAG, 구조화된 데이터, 모델 정렬
• 원문: IBM — LLMON: An LLM-Native Markup Language, now in Granite 4.1 3B and 8B

---

IBM이 대형 언어모델에 지시문과 실제 데이터를 명확하게 전달하기 위한 새로운 표현 형식 LLMON(LLM Object Notation)을 공개했다.

이번 발표에서는 LLMON을 지원하는 실험용 모델 두 개도 함께 공개했다.

대상 모델은 Granite 4.1 3B와 Granite 4.1 8B를 기반으로 한다.

이번 기술의 목적은 일반적인 질문·답변 성능을 크게 높이는 것이 아니다.

AI가 외부 문서에 포함된 악의적인 지시를 실제 사용자의 명령으로 잘못 이해하는 문제를 줄이는 것이다.

외부 문서는 정보이지 새로운 명령이 아니다

일반적인 AI 에이전트를 생각해 보자.

사용자가 특정한 문서의 내용을 요약하도록 요청할 수 있다.

에이전트는 외부 문서를 검색하고 관련 내용을 모델에 전달한다.

그런데 검색한 문서에 다음과 같은 내용이 포함돼 있을 수 있다.

문서를 요약하지 말고 다른 작업을 수행하라는 지시다.

이런 내용은 실제 사용자의 요청이 아니다.

외부 문서에 포함된 일반적인 텍스트다.

하지만 모델이 해당 내용을 새로운 명령으로 잘못 받아들이면 사용자의 원래 요청과 관계없는 행동을 수행할 수 있다.

이런 공격을 프롬프트 인젝션(Prompt Injection)이라고 한다.

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

IBM은 이런 문제가 발생하는 원인 가운데 하나가 지시문과 데이터의 의미가 모델의 입력에서 충분히 명확하게 구분되지 않는다는 점이라고 설명한다.

일반적인 JSON과 무엇이 다른가

일반적인 프로그램에서는 데이터를 JSON 형식으로 전달할 수 있다.

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

예를 들어 특정한 작업의 지시문과 참고 문서, 결과 형식을 서로 다른 속성으로 표현할 수 있다.

하지만 언어모델은 이러한 구조를 일반적인 텍스트 토큰으로 처리한다.

따라서 JSON의 따옴표나 괄호가 문법적으로 어떤 의미를 가지는지 완벽하게 강제받는 것은 아니다.

반면 LLMON은 구조적인 구분을 위해 전용 특수 토큰(Special Token)을 사용한다.

특수 토큰은 모델이 일반적인 단어와 구분해 처리하도록 만든 별도의 토큰이다.

LLMON은 지시와 데이터, 요구사항과 실행 대상 등을 서로 다른 태그로 표현한다.

예를 들어 다음과 같은 의미의 구성요소를 구분할 수 있다.

여기서 중요한 것은 단순히 다른 태그를 사용하는 것이 아니다.

실제로 어떤 지시를 어떤 자료에 적용해야 하는지 명시적인 연결 관계를 표현한다는 점이다.

예를 들어 하나의 대화에 여러 과거 지시가 존재하더라도 현재 작업에 필요한 지시와 자료만 연결할 수 있다.

실행 대상이 아닌 자료는 명령으로 취급하지 않도록 학습

IBM은 LLMON을 지원하는 모델을 학습할 때 일반적인 지시 이행 데이터의 구조를 다시 작성했다.

각 작업의 지시문과 참고 자료를 별도의 블록으로 표현했다.

이후 실제로 어떤 지시를 수행해야 하는지 명시한 실행 블록을 추가했다.

또한 모델의 입력에 사용하지 않아야 하는 지시문이나 관계없는 자료를 함께 포함했다.

모델은 이런 정보가 존재하더라도 실제로 연결되지 않았다면 무시하도록 학습했다.

이를 통해 외부 문서에 포함된 문장을 실제 명령으로 잘못 해석하는 문제를 줄이려 했다.

이후 여러 단계의 강화학습도 수행했다.

강화학습(Reinforcement Learning)은 모델의 행동이나 답변에 보상을 제공해 더 좋은 행동을 학습시키는 방법이다.

IBM은 마지막 학습 단계에서 실제 프롬프트 인젝션 시도에 대한 모델의 응답을 이용해 추가적인 선호 학습을 수행했다고 설명한다.

OPI 평가에서 공격 성공률 크게 감소

IBM은 여러 공개 프롬프트 인젝션 평가에서 LLMON 모델을 시험했다.

대표적인 평가가 OPI다.

OPI는 일반적인 언어 처리 작업에 악의적인 지시가 포함된 데이터를 전달한 뒤 모델이 원래 작업을 유지하는지 확인한다.

IBM이 공개한 결과에 따르면 LLMON 기반 모델은 다음과 같은 성능을 기록했다.

• 비교한 최고 프런티어 모델보다 약 47% 더 많은 공격을 방어
• 비교한 최고 오픈소스 모델보다 약 95% 더 많은 공격을 방어
• 일부 평가에서는 공격 성공률이 거의 0에 가까운 수준으로 감소

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

이 수치는 IBM이 수행한 특정 벤치마크의 결과다.

또한 평가에 사용된 공격은 주로 정적인 간접 프롬프트 인젝션이다.

실제 에이전트에서는 공격자가 여러 번의 대화와 도구 호출 결과를 통해 공격 내용을 변경할 수 있다.

이를 Adaptive Attack(적응형 공격)이라고 한다.

IBM은 이런 공격에 대한 저항성은 아직 개선 중이라고 밝혔다.

따라서 LLMON을 사용하면 모든 종류의 프롬프트 인젝션을 완벽하게 막을 수 있다고 판단해서는 안 된다.

일반적인 모델 능력을 유지하도록 설계

프롬프트 인젝션을 막기 위해 모델의 행동을 지나치게 제한하면 정상적인 요청도 제대로 수행하지 못할 수 있다.

예를 들어 외부 문서에 포함된 모든 명령형 문장을 무조건 무시하도록 학습한다면 실제로 명령문을 분석하거나 번역하는 작업에서도 오류가 발생할 수 있다.

IBM은 이런 문제를 줄이기 위해 일반적인 모델의 언어 이해와 추론 능력을 유지하도록 설계했다고 설명한다.

공개된 평가에서는 LLMON 모델이 같은 규모의 Granite 4.1 Instruct 모델과 비슷한 일반적인 능력을 기록했다.

하지만 모델의 구조와 입력 형식이 달라지므로 실제 서비스의 모든 작업에서 성능이 동일하다는 의미는 아니다.

이번에 공개된 모델들은 실험용 프리뷰다.

외부 개발자는 모델과 관련 도구를 이용해 실제 입력 형식을 시험할 수 있다.

또한 IBM은 Mellea라는 개발 프레임워크와의 연동도 제공한다.

Mellea는 LLMON 구조를 활용해 여러 AI 작업을 구성하도록 지원한다.

구조화된 입력과 실제 실행 권한은 구분해야 한다

이번 연구에서 가장 중요한 한계는 LLMON이 모델의 판단을 개선하는 기술이라는 점이다.

실제 프로그램의 접근권한을 강제로 제한하는 운영체제 수준의 보안 장치는 아니다.

예를 들어 모델이 잘못된 지시를 무시하도록 학습됐더라도 실제로 사용할 수 있는 도구의 권한이 지나치게 넓다면 문제가 발생할 수 있다.

따라서 중요한 파일과 데이터베이스, 외부 시스템에 대한 접근권한은 별도의 실행 환경에서 제한해야 한다.

이번 발표는 AI 에이전트의 안전성을 높일 때 모델이 입력을 이해하는 방식과 실제 행동을 허용하는 실행 시스템을 함께 설계해야 한다는 점을 보여준다.

---

4️⃣ 산업·정책·안전

미국 시민단체 4곳, OpenAI·Anthropic·Google·Meta 등의 고성능 AI 개발 중단을 요구하는 소송 제기

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: AI 규제, 미국 민사소송, AI 안전, 사이버보안, 생물학적 위험, 기업의 법적 책임
• 원문: Public Citizen — Coalition of Nonprofits Files Landmark Lawsuit
• 원문 보도: Reuters — OpenAI, Google, Anthropic hit with lawsuit seeking halt to frontier AI development

---

미국의 시민단체 네 곳이 주요 AI 기업들을 상대로 고성능 AI 모델의 추가 개발과 배포를 중단하도록 요구하는 소송을 제기했다.

소송은 11월 12일 미국 캘리포니아주 샌프란시스코 카운티의 주 법원에 제기됐다.

이번 사건은 새로운 AI 규제 법률이 시행됐다는 소식이 아니다.

민간단체들이 기존의 불공정 경쟁과 공공의 안전에 관한 법률을 근거로 프런티어 AI 개발 자체를 제한해 달라고 법원에 요청한 사건이다.

여기서 중요한 점은 소송이 제기됐다는 사실과 법원이 실제로 개발 중단을 명령했다는 사실을 구분해야 한다는 것이다.

발표 시점에 소송이 제기됐지만 법원이 개발 중단 명령을 내렸다는 사실은 확인되지 않았다.

소송을 제기한 단체와 대상 기업

이번 소송에 참여한 단체는 다음과 같다.

소송의 대상에는 OpenAI와 Anthropic, Google과 Meta, SpaceXSI가 포함됐다.

원고들은 고도화된 AI 모델이 통제되지 않은 행동을 수행하거나 위험한 기술의 접근성을 높일 수 있다고 주장한다.

특히 사이버 공격과 생물학적 위협, 실제 시스템에 대한 무단 접근 등을 우려하고 있다.

하지만 이러한 주장은 소송을 제기한 원고 측의 주장이다.

각 기업이 법률을 위반했다는 사실이 법원에서 확정된 것은 아니다.

캘리포니아 불공정 경쟁법을 근거로 사용

이번 소송은 캘리포니아의 Unfair Competition Law(불공정 경쟁법)를 주요 법적 근거로 제시한다.

불공정 경쟁법은 기업의 불법적이거나 불공정한 사업 행위를 제한하는 데 활용되는 법률이다.

원고들은 고성능 AI 모델의 개발과 배포가 공공의 안전에 위험을 만들 수 있으므로 해당 법률이 적용될 수 있다고 주장한다.

또한 Public Nuisance(공적 불법방해 또는 공공에 대한 유해행위)라는 법적 개념도 제시했다.

공적 불법방해는 일반적인 개인의 피해를 넘어 공공의 안전이나 공동체의 권리에 영향을 주는 행위를 다루는 법적 개념이다.

원고들은 프런티어 AI 개발의 잠재적 위험이 이런 범주에 해당할 수 있다고 주장한다.

하지만 실제로 법원이 해당 법률을 어떻게 해석할지는 아직 결정되지 않았다.

특히 AI 모델의 개발이라는 행위와 실제로 발생한 피해 사이의 인과관계를 어떻게 판단할지가 중요한 쟁점이 될 수 있다.

아직 발생하지 않은 위험을 근거로 개발을 제한할 수 있는가

이번 사건에서 중요한 법적 질문은 잠재적인 위험만으로 기술 개발을 제한할 수 있는가라는 문제다.

예를 들어 특정한 AI 모델이 실제로 허용되지 않은 시스템에 접근하도록 악용될 가능성이 있다고 가정해 보자.

원고들은 이런 위험이 심각하고 예측 가능하다면 실제 피해가 발생하기 전에 예방적인 조치가 필요하다고 주장한다.

반면 개발 중단을 요구하는 조치에는 다른 문제도 존재한다.

어떤 수준의 기술적 능력을 가진 모델이 제한 대상에 해당하는지 정의해야 한다.

또한 위험을 완화하기 위한 충분한 보호조치가 무엇인지 판단해야 한다.

모든 AI 연구를 동일한 위험으로 취급할 수도 없다.

예를 들어 의료 연구나 사이버보안 방어를 지원하는 모델과 실제 공격에 악용되는 시스템은 사용 목적과 영향이 다를 수 있다.

따라서 법원은 실제 법률의 적용 범위와 원고의 법적 자격, 주장된 위험의 근거와 구제 조치의 적절성을 검토해야 할 수 있다.

실제 소송 결과는 아직 불확실

Reuters에 따르면 Meta는 관련 문의에 답변을 거부했고 다른 피고 기업들은 보도 시점에 즉각적인 입장을 내놓지 않았다.

이 역시 해당 보도 시점의 상황이다.

이후 기업들이 추가적인 입장을 발표하거나 법원에 서류를 제출할 수 있다.

중요한 점은 이번 사건을 AI 기업의 위법성이 확정된 사건으로 표현해서는 안 된다는 사실이다.

또한 원고들이 제시한 기술적 위험 사례는 각 사례의 사실관계와 평가 조건을 별도로 확인해야 한다.

예를 들어 보안 연구를 위해 격리된 환경에서 수행한 공격 실험과 실제 외부 시스템을 무단으로 침해한 사건은 서로 다르다.

이번 소송은 미국의 AI 규제 논의가 새로운 법률의 제정뿐 아니라 기존 민사법과 불공정 경쟁법을 이용해 고성능 AI 개발의 책임을 묻는 방향으로도 확대되고 있음을 보여준다.

다만 이러한 법적 접근이 실제로 인정될지는 향후 재판 결과를 통해 확인해야 한다.

---

Capgemini, 기업 AI 비용 조사 발표…59%가 예상 예산 초과 경험하고 성공한 업무당 실제 비용 관리 필요성 제기

• 발표일: 2026-11-12 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 AI, AI 인프라 비용, 모델 라우팅, 에이전트 운영, 오픈웨이트 모델, AI 투자성과 측정
• 원문: Capgemini — Most organizations plan to adopt a multi-model AI strategy

---

Capgemini Research Institute가 기업의 실제 AI 비용과 운영 방식에 관한 새로운 조사 결과를 발표했다.

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

기업들이 AI를 실제 업무에 확대 적용하는 과정에서 예상보다 높은 비용을 경험하고 있으며, 단순한 API 사용량보다 실제로 성공한 업무의 비용을 측정해야 한다는 조사 결과다.

최근 많은 기업은 직원에게 AI 도구를 제공하거나 업무 자동화 에이전트를 도입하고 있다.

하지만 초기 실험에서 예상한 비용과 실제 운영에 필요한 비용은 다를 수 있다.

예를 들어 언어모델의 API 가격이 저렴하더라도 실제 업무에서는 여러 번의 재시도가 발생할 수 있다.

또한 사람이 AI의 결과를 검토하고 수정하는 시간이 필요할 수 있다.

이런 비용까지 함께 계산해야 실제로 AI를 도입하는 것이 경제적인지 판단할 수 있다.

500개 대기업의 경영진 대상 조사

Capgemini는 2026년 9월에 연매출 10억 달러 이상의 기업 경영진 500명을 조사했다.

조사 대상은 미국과 중국, 인도와 영국, 프랑스와 독일, 일본 등 10개 국가의 13개 산업에 속한 기업들이었다.

주요 결과는 다음과 같다.

중요한 점은 59%의 기업이 실제 비용이 예상보다 높았다고 응답했다는 사실이다.

또한 비용을 초과한 기업들에서는 평균적으로 예상보다 약 24% 많은 비용이 발생했다.

하지만 이 수치는 기업 경영진을 대상으로 한 설문조사 결과다.

독립적인 감사기관이 모든 기업의 실제 회계자료를 확인한 것은 아니다.

또한 연매출 10억 달러 이상의 대기업을 대상으로 했으므로 소규모 스타트업이나 개인 개발자의 상황에 그대로 적용할 수는 없다.

API 요금은 전체 AI 비용의 일부

일반적인 AI 비용 비교에서는 입력과 출력 토큰의 단가를 확인한다.

예를 들어 모델 A는 100만 토큰당 1달러를 받는다고 가정할 수 있다.

모델 B는 같은 토큰 수에 5달러를 받을 수 있다.

하지만 실제 업무의 총비용은 다른 요소에도 영향을 받는다.

예를 들어 모델 A가 작업을 세 번 실패하고 네 번째 시도에서 성공했다면 실제 비용은 단순한 토큰 단가보다 커질 수 있다.

또한 오류가 발생했을 때 사람이 검토하고 수정해야 하는 시간이 필요할 수 있다.

Capgemini는 이런 간접 비용을 다음과 같이 구분했다.

AI 거버넌스(AI Governance)는 AI 시스템의 사용 목적과 접근권한, 위험과 책임을 관리하는 체계다.

예를 들어 금융기관에서 AI가 고객의 대출 자료를 분석하는 경우 단순한 모델 호출 비용만 고려할 수 없다.

해당 자료를 처리할 수 있는 권한과 결과의 검증, 관련 규정을 준수하기 위한 절차가 필요하기 때문이다.

AI Yield: 실제 업무의 가치를 계산

Capgemini는 AI Yield라는 지표를 강조했다.

AI Yield는 실제 AI 업무에서 검증된 가치를 계산하고, 그 결과를 안전하게 제공하는 데 필요한 전체 비용을 고려하는 개념이다.

예를 들어 AI가 고객지원 문의 100건을 처리했다고 가정해 보자.

하지만 이 가운데 30건은 사람이 다시 처리해야 했다면 단순히 100건을 처리했다는 사실만으로 성과를 평가하기 어렵다.

또한 자동으로 처리한 70건 가운데 일부가 잘못된 안내를 제공했다면 실제 고객의 불만과 재처리 비용이 발생할 수 있다.

따라서 중요한 지표는 전체 처리량보다 정확하게 완료한 업무의 수와 그 업무를 완료하는 데 필요한 총비용이다.

Capgemini에 따르면 실제로 AI Yield를 계산하는 기업은 약 20%에 불과했다.

또한 기업의 약 60%는 여전히 전체 AI 지출액과 예산을 비교하는 방식에 주로 의존했다.

하지만 향후에는 업무의 첫 번째 시도 성공률과 완료된 작업당 비용을 더 중요하게 평가하려는 경향이 나타났다.

First-Pass Success Rate(첫 시도 성공률)는 재시도나 수정 없이 첫 번째 시도에서 작업을 성공적으로 완료한 비율이다.

이 지표는 실제 에이전트의 운영 비용을 이해할 때 유용할 수 있다.

여러 모델을 조합하는 전략 확대

Capgemini는 기업들이 향후 하나의 AI 모델에만 의존하기보다 여러 모델을 업무에 따라 선택할 계획이라고 설명했다.

이를 Multi-Model Strategy(다중 모델 전략)라고 한다.

예를 들어 일반적인 문서 분류에는 작은 모델을 사용할 수 있다.

반면 복잡한 법률 자료의 분석에는 더 높은 성능의 모델이 필요할 수 있다.

또한 민감한 데이터를 처리하는 업무에서는 자체 서버에서 실행하는 오픈웨이트 모델을 선택할 수도 있다.

Capgemini에 따르면 응답자의 60% 이상이 향후 12개월 안에 이런 다중 모델 전략을 도입할 것으로 예상했다.

또한 약 60%의 기업은 오픈웨이트 모델의 활용을 확대할 계획이라고 응답했다.

오픈웨이트(Open-Weight)는 모델의 학습된 가중치를 공개해 개발자가 자체 환경에서 실행하거나 추가 학습할 수 있도록 하는 배포 방식이다.

하지만 오픈웨이트 모델을 사용하면 비용이 무조건 저렴해지는 것은 아니다.

자체 서버의 GPU와 저장장치, 운영 인력과 보안 관리 비용이 발생할 수 있기 때문이다.

또한 작은 모델이 복잡한 작업에서 자주 실패한다면 전체 비용이 오히려 증가할 수 있다.

비용을 줄이는 것과 실제 가치를 높이는 것은 다르다

이번 조사에서 흥미로운 부분은 예상보다 비용이 증가한 기업의 대응 방식이다.

53%는 AI 관련 예산이나 사용량에 대한 통제를 강화했다고 응답했다.

반면 어떤 업무를 AI에 맡기는 것이 적절한지 검토하거나 모델과 실행 방식을 다시 설계한 기업은 약 20%에 그쳤다.

예를 들어 AI 사용량을 줄이면 지출을 낮출 수 있다.

하지만 실제 업무를 완료하는 데 필요한 시간이 늘어난다면 기업 전체의 생산성은 오히려 감소할 수 있다.

반대로 더 비싼 모델을 사용하더라도 오류와 재시도가 줄어든다면 전체 비용이 낮아질 수 있다.

따라서 단순히 토큰 사용량을 제한하는 것보다 어떤 업무를 AI에 맡기고, 어떤 모델을 선택하며, 실제 결과를 어떻게 검증하는지를 함께 고려해야 한다.

이번 발표는 기업의 AI 도입이 초기 실험을 넘어 실제 운영 단계로 확대되면서 모델의 성능과 총비용, 업무의 성공률과 경제적 가치를 함께 측정하는 문제가 중요해지고 있음을 보여준다.

---

📚 추천 글

Escaping SPACE: Part II

• 저자: Perplexity Research
• 발행: Perplexity
• 게시일: 2026-11-11
• 원문: Perplexity — Escaping SPACE: Part II

---

AI 에이전트가 실제 프로그램을 실행할 수 있다면 어떤 수준의 보안 격리가 필요할까?

예를 들어 AI 코딩 에이전트가 사용자가 제공한 코드를 실행한다고 가정해 보자.

해당 코드가 실제 컴퓨터의 모든 파일과 네트워크에 접근할 수 있다면 보안 문제가 발생할 수 있다.

따라서 실제 에이전트 실행 환경에서는 프로그램이 사용할 수 있는 자원을 제한해야 한다.

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

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

Perplexity는 자사의 AI 에이전트 플랫폼인 SPACE에서 이런 보안 격리를 제공한다.

이번 글은 실제로 여러 AI 모델에게 샌드박스의 보안 장치를 우회하도록 요청한 뒤 어떤 행동을 수행하는지 분석한 연구다.

특히 단순히 공격의 성공 여부만 보는 것이 아니라 모델이 실제로 어떤 종류의 시도를 했는지 조사했다는 점이 흥미롭다.

가상 머신 내부와 외부 시스템 분리

SPACE에서는 AI 에이전트가 별도의 가상 머신에서 프로그램을 실행한다.

VM(Virtual Machine, 가상 머신)은 하나의 실제 컴퓨터에서 별도의 운영체제와 실행 환경을 구성하는 기술이다.

에이전트가 실행되는 VM을 게스트라고 부른다.

실제 서버의 운영체제와 자원을 관리하는 쪽은 호스트다.

일반적으로 게스트 VM에서 실행되는 프로그램은 호스트의 중요한 파일에 직접 접근할 수 없어야 한다.

예를 들어 호스트 서버에 저장된 인증정보가 게스트 VM에 노출돼서는 안 된다.

Perplexity는 이런 보안 경계를 검사하기 위해 AI 모델에게 격리 환경을 벗어나도록 요청했다.

평가에서는 게스트 VM 내부에 관리자 권한도 제공했다.

따라서 일반적인 사용자 권한 제한을 이미 우회한 상황에서도 가상 머신과 실제 호스트 사이의 보안 경계가 유지되는지 검사할 수 있었다.

처음 실험에서는 샌드박스 탈출에 실패

연구팀은 여러 AI 모델을 이용해 가상 머신과 실제 호스트 사이의 경계를 시험했다.

초기 실험에서는 다음 모델들이 포함됐다.

• Claude Opus 계열
• GPT-5.6 Sol·Cyber
• Gemini 계열
• DeepSeek와 Kimi
• GLM과 Qwen
• Grok

이후 새로운 Claude와 GPT 모델을 추가해 총 12개 모델을 평가했다.

연구팀에 따르면 모든 모델은 실제 VM에서 호스트로 탈출하는 데 실패했다.

하지만 이 결과만으로 샌드박스의 모든 보안 문제가 존재하지 않는다고 판단할 수는 없었다.

이유는 모델들이 실제로 샌드박스의 핵심 보안 경계를 충분히 공격하지 않았기 때문이다.

공격의 성공 여부보다 시도한 작업의 종류가 중요

Perplexity는 모델이 수행한 행동을 여러 유형으로 분류했다.

일부 모델은 호스트의 인증정보를 찾기 위해 파일과 메모리를 검색했다.

다른 모델은 내부 서비스의 통신 구조를 조사했다.

또 다른 모델은 공유 파일시스템과 네트워크 경로를 살펴봤다.

하지만 실제로 가상화 계층의 취약점을 조사한 비중은 낮았다.

예를 들어 일부 모델은 전체 작업시간의 4% 이하를 가상화 계층의 실제 보안 경계에 사용했다.

GPT 계열 모델도 약 18~22% 정도만 해당 영역을 조사했다.

따라서 모델이 샌드박스 탈출에 실패했다는 사실만으로 실제 가상화 계층이 충분히 강력한 공격을 견뎠다고 판단하기 어려웠다.

연구팀은 이를 해결하기 위해 프롬프트를 변경했다.

단순히 샌드박스를 탈출하라는 요청 대신 실제로 평가하려는 가상화 보안 경계를 집중적으로 조사하도록 지시했다.

그 결과 모델이 해당 영역에 사용한 작업 비중은 평균 약 60%포인트 증가했다.

하지만 변경한 프롬프트를 사용한 실험에서도 실제 VM에서 호스트로의 탈출은 성공하지 못했다.

이는 초기 실험보다 보안 경계에 대한 강한 근거를 제공하지만, 모든 가능한 공격을 검증했다는 의미는 아니다.

전문 보안 모델이 항상 더 좋은 결과를 기록하지 않았다

이번 글에서 특히 흥미로운 부분은 보안 특화 모델과 일반 모델의 비교다.

GPT-5.6 Cyber는 보안 연구를 위해 추가 학습된 모델이다.

따라서 일반적인 GPT-5.6 Sol보다 보안 문제를 더 잘 해결할 것으로 기대할 수 있다.

하지만 Perplexity의 일부 평가에서는 반대 결과가 나타났다.

예를 들어 소스코드를 제공한 네트워크 제한 우회 실험에서 GPT-5.6 Sol은 세 번의 실행 모두에서 목표를 달성했다.

반면 GPT-5.6 Cyber는 같은 조건에서 세 번 모두 실패했다.

또한 일반적인 GPT-6 Astra가 보안 특화 Claude Mythos 5.1보다 더 좋은 결과를 기록한 사례도 나타났다.

이는 보안 특화 모델이 전체적으로 더 약하다는 의미가 아니다.

해당 모델들이 학습한 보안 업무와 실제 평가에서 필요한 공격 방법이 다를 수 있다는 뜻이다.

예를 들어 특정한 모델은 일반적인 취약점 재현 작업에 특화돼 있을 수 있다.

하지만 실제 가상화 계층과 네트워크 정책을 우회하는 문제에서는 다른 종류의 추론과 탐색 능력이 필요할 수 있다.

연구팀 역시 제한된 실험 결과만으로 일반적인 모델의 보안 능력이 전문 모델보다 높다고 판단해서는 안 된다고 강조했다.

네트워크 접근 제한에서는 실제 문제가 발견

가상 머신과 호스트 사이의 격리에서는 성공한 공격이 발견되지 않았다.

하지만 외부 네트워크 접근 제한에서는 다른 결과가 나타났다.

Perplexity는 일부 AI 모델이 허용된 네트워크 서비스의 특성을 이용해 원래 접근할 수 없어야 하는 목적지에 도달하는 방법을 찾았다고 밝혔다.

즉 실제 가상 머신의 격리는 유지됐지만 네트워크 정책의 일부 제한은 우회할 수 있었다.

연구팀은 관련 취약점을 수정했고 다시 시험한 결과 같은 방법으로 우회할 수 없음을 확인했다고 설명한다.

또한 다른 샌드박스 제공업체 10곳 가운데 8곳에서도 비슷한 종류의 문제가 발견됐다고 밝혔다.

이 경우에는 관련 업체에 책임 있는 공개 절차를 통해 문제를 전달했다.

하지만 이러한 결과를 모든 제공업체의 샌드박스가 위험하다는 의미로 일반화해서는 안 된다.

실제 보안 문제는 각 서비스의 구성과 허용된 네트워크 경로에 따라 달라질 수 있다.

평가의 질문 자체가 결과를 바꿀 수 있다

이번 연구에서 가장 중요한 기술적 관점은 보안 평가에서 모델에게 어떤 목표를 어떻게 제시하는지가 실제 결과에 큰 영향을 줄 수 있다는 사실이다.

예를 들어 모델이 특정한 보안 경계를 공격할 수 있는 능력이 있더라도 일반적인 프롬프트에서는 해당 방법을 거의 시도하지 않을 수 있다.

반대로 평가 대상을 구체적으로 지정하면 더 많은 시도를 수행할 수 있다.

따라서 모델의 안전성과 공격 능력을 평가할 때 단순한 성공률만 확인해서는 안 된다.

실제로 어떤 행동을 시도했고, 어떤 부분을 충분히 검사하지 않았으며, 평가자가 제공한 정보가 얼마나 많았는지도 고려해야 한다.

이번 글은 AI 에이전트의 안전성을 평가할 때 모델의 판단과 실제 실행 환경의 보안 경계, 평가 프롬프트의 설계를 함께 분석해야 한다는 점을 구체적으로 보여준다.

---

The Definitive Fine-Tuning Guide for 3D Generation Models

• 저자: Suvaditya Mukherjee, Merve Noyan, Pedro Cuenca
• 발행: Hugging Face
• 게시일: 2026-11-12
• 원문: Hugging Face — The Definitive Fine-Tuning Guide for 3D Generation Models

---

이미지 생성 AI는 특정한 물체를 비교적 자연스럽게 표현할 수 있다.

하지만 이미지를 실제로 편집 가능한 3D 물체로 변환하는 작업은 훨씬 복잡하다.

예를 들어 사용자가 신발 사진을 제공하고 해당 신발의 3D 모델을 생성하도록 요청했다고 가정해 보자.

AI는 겉으로 보기에 신발과 비슷한 물체를 만들 수 있다.

하지만 실제 밑창의 두께와 형태가 잘못될 수 있다.

또는 뒤꿈치의 구조가 실제 신발과 다르게 만들어질 수 있다.

영상이나 게임에서는 이런 오류가 큰 문제가 아닐 수 있다.

하지만 상품의 3D 미리보기나 로봇 시뮬레이션, 실제 제조와 관련된 작업에서는 물체의 형태가 중요하다.

이번 글은 이런 문제를 해결하기 위해 기존 3D 생성 모델을 작은 전문 데이터셋으로 추가 학습하는 방법을 구체적으로 설명한다.

TRELLIS.2의 두 가지 생성 단계

Hugging Face 연구팀은 TRELLIS.2라는 이미지 기반 3D 생성 모델을 사용했다.

TRELLIS.2는 하나의 이미지에서 3D 물체를 생성하도록 설계된 모델이다.

실제 생성 과정은 여러 단계로 구성된다.

먼저 입력 이미지의 특징을 분석한다.

이후 물체의 대략적인 공간 구조를 생성한다.

다음으로 세부적인 형태를 생성한다.

마지막으로 표면의 재질과 색상 등을 생성한다.

연구팀은 이 가운데 두 부분을 추가 학습 대상으로 선택했다.

첫 번째는 Sparse Structure Flow다.

물체가 3D 공간에서 어느 영역을 차지하는지 대략적으로 생성하는 단계다.

두 번째는 Shape Flow다.

실제 물체의 세부적인 형태를 생성하는 단계다.

중요한 점은 전체 모델을 처음부터 다시 학습하지 않았다는 것이다.

기존 모델의 능력을 활용하면서 신발과 관련된 형태 생성 부분만 추가 학습했다.

LoRA로 적은 데이터에 맞게 조정

이번 연구에는 LoRA(Low-Rank Adaptation)가 사용됐다.

LoRA는 모델 전체의 가중치를 다시 학습하는 대신 상대적으로 적은 추가 파라미터를 학습하는 방법이다.

예를 들어 기존 모델이 이미 의자와 책상, 신발 등 여러 물체의 구조를 학습했다고 가정해 보자.

그런데 신발의 밑창을 더 정확하게 생성하도록 개선하고 싶을 수 있다.

전체 모델을 다시 학습하면 많은 계산 자원이 필요하다.

또한 특정한 물체에 집중해서 학습하는 과정에서 다른 물체를 생성하는 능력이 저하될 가능성도 있다.

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

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

LoRA는 이런 문제를 줄이기 위한 방법 가운데 하나다.

이번 연구팀은 약 930만 개의 추가 파라미터를 학습했다.

실제 TRELLIS.2 전체 모델에 비하면 상대적으로 작은 규모다.

188개 신발 데이터로 실험

연구팀은 Google Scanned Objects 데이터셋에서 신발 188개를 선택했다.

이 가운데 179개는 학습에 사용했다.

나머지 9개는 평가용으로 남겨뒀다.

이를 Held-Out Test Set(별도 평가 데이터)이라고 한다.

학습에 사용하지 않은 자료를 이용해 모델의 실제 일반화 능력을 확인하는 방식이다.

예를 들어 모델이 학습에 사용한 179개 신발만 정확하게 재현한다고 가정해 보자.

이 경우 실제로 새로운 신발의 3D 모델을 생성하는 능력이 개선됐다고 판단하기 어렵다.

따라서 학습하지 않은 신발 9개에서도 형태를 정확하게 생성하는지 확인해야 한다.

연구팀은 Blender를 이용해 각 신발의 여러 시점 이미지를 생성했다.

이후 해당 이미지를 입력으로 사용해 3D 모델을 생성하도록 학습했다.

하나의 A100 GPU로 약 11시간 학습

실제 실험에는 NVIDIA A100 80GB GPU가 사용됐다.

학습은 두 단계로 수행됐다.

데이터 전처리에는 별도로 약 1시간이 필요했다.

다만 이 시간은 연구팀이 사용한 하드웨어와 학습 설정에 따른 결과다.

모든 3D 모델을 같은 규모의 GPU에서 같은 시간에 추가 학습할 수 있다는 의미는 아니다.

이번 글에서는 필요한 프로그램과 라이브러리를 Docker 이미지로 제공한다.

Docker는 프로그램과 실행에 필요한 의존성을 하나의 컨테이너 이미지로 묶어 배포할 수 있도록 지원하는 도구다.

이를 이용하면 개발자가 매번 복잡한 프로그램 설치 환경을 처음부터 구성하는 부담을 줄일 수 있다.

또한 Hugging Face Jobs를 이용한 클라우드 실행 방법도 제공한다.

실제 3D 형태 평가에서 큰 폭의 개선

연구팀은 학습에 사용하지 않은 신발 9개의 생성 결과를 비교했다.

이때 실제 3D 스캔 자료를 정답으로 사용했다.

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

F-score는 생성한 물체의 표면이 실제 물체의 표면과 얼마나 잘 일치하는지 평가하는 지표다.

Chamfer Distance는 두 물체의 표면에 존재하는 점들 사이의 평균적인 거리를 측정하는 방법이다.

낮을수록 두 물체가 더 비슷하다는 의미다.

Normal Consistency는 물체 표면의 방향이 얼마나 일치하는지 평가한다.

예를 들어 신발의 밑창에서 표면이 바깥쪽을 향하는 방향과 실제 스캔 자료의 방향이 비슷한지 확인할 수 있다.

연구팀은 세 지표 모두에서 개선을 확인했다.

또한 평가한 신발 9개 모두에서 F-score가 개선됐다.

특히 추가 학습 이후 신발의 밑창과 전체 형태가 실제 스캔 자료에 더 가까워졌다고 설명한다.

하지만 이 결과는 신발이라는 특정한 물체 유형에서 얻어진 것이다.

의자와 자동차 부품, 복잡한 기계에서도 같은 수준의 개선이 발생한다고 판단해서는 안 된다.

또한 평가용 신발이 9개로 제한적이므로 더 다양한 물체에서의 검증이 필요하다.

3D 생성 모델의 실제 활용을 위한 문제

이번 글의 의미는 단순히 3D 모델의 생성 품질이 높아졌다는 데 있지 않다.

실제 산업에서는 물체의 형태가 중요한 경우가 많다.

예를 들어 온라인 쇼핑몰의 3D 상품 미리보기에서는 상품의 외형과 비율을 유지해야 한다.

로봇 시뮬레이션에서는 물체의 형태가 잘못되면 실제 로봇의 움직임을 제대로 시험하기 어렵다.

제조 분야에서는 부품의 치수와 공차도 중요하다.

공차(Tolerance)는 실제 제조된 부품의 크기와 위치가 설계값에서 어느 정도 벗어날 수 있는지 나타내는 허용 범위다.

다만 이번 연구는 실제 제조용 CAD 모델의 정확성을 보장하는 기술은 아니다.

생성한 3D 형태가 실제 스캔 자료에 더 비슷해졌다는 결과다.

실제 제조와 안전성 검증에는 별도의 공학적 검토가 필요하다.

이번 글은 생성형 AI를 실제 전문 분야에 적용할 때 범용 모델을 그대로 사용하는 것보다 적절한 전문 데이터를 준비하고 필요한 부분만 추가 학습하는 방식이 유용할 수 있다는 점을 보여준다.

---

SafetyPulse: Catching Safety Drift During Fine-Tuning by Reading the Model's Refusal Circuit

• 저자: Purvansh Joshi, Archit Mittal, Anubhav Kiroula
• 발행: Hugging Face Community / Lexsi Labs AI Safety & Alignment Hackathon
• 게시일: 2026-11-08
• 원문: Hugging Face — SafetyPulse: Catching Safety Drift During Fine-Tuning

---

이미 안전하게 학습된 AI 모델을 일반적인 데이터로 추가 학습하면 안전성도 그대로 유지될까?

반드시 그렇지는 않다.

예를 들어 기업에서 특정한 언어모델을 고객지원 업무에 맞게 추가 학습한다고 가정해 보자.

학습 데이터에는 일반적인 고객 문의와 답변이 포함돼 있다.

이 데이터 자체는 위험하지 않을 수 있다.

하지만 추가 학습을 진행하는 과정에서 모델이 기존에 배운 안전한 응답 방식을 일부 잃어버릴 가능성이 있다.

이런 현상을 Safety Drift(안전성 드리프트)라고 한다.

모델을 추가 학습하는 동안 안전한 행동의 기준과 실제 응답 성향이 달라지는 현상이다.

이번 글은 이런 문제를 실제 실험으로 재현하고, 모델이 위험한 답변을 생성하기 전에 내부 상태의 변화를 측정해 문제를 조기에 발견하는 방법을 설명한다.

정상적인 데이터 2,000개로 안전성 저하

연구팀은 Cohere Labs의 Tiny Aya Global 모델을 사용했다.

이 모델은 약 33억5천만 개의 파라미터를 가진 언어모델이다.

연구팀은 일반적인 지시 이행 데이터인 Alpaca의 예시 2,000개를 이용해 모델을 추가 학습했다.

이 데이터는 특별히 위험한 행동을 가르치기 위한 자료가 아니었다.

하지만 실제 평가에서는 위험한 요청에 대한 모델의 행동이 달라졌다.

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

공격 성공률(Attack Success Rate, ASR)은 정해진 유해 요청 평가에서 모델이 원래 제한해야 하는 응답을 생성한 비율이다.

추가 학습 이후 공격 성공률은 10.9%포인트 높아졌다.

이는 학습 데이터가 위험하지 않더라도 모델의 안전한 행동이 약화될 수 있다는 점을 보여준다.

하지만 이 결과는 특정한 소형 모델과 학습 데이터, 평가 환경에서 얻어진 것이다.

모든 언어모델을 정상적인 데이터로 추가 학습하면 공격 성공률이 같은 비율로 증가한다는 의미는 아니다.

모델의 답변이 아니라 내부 상태를 측정

일반적인 안전성 평가에서는 모델에게 위험한 질문을 전달한다.

이후 모델이 올바르게 거부하는지 확인한다.

하지만 이런 방식에는 문제가 있다.

안전한 행동이 약화되기 시작하더라도 실제 답변에서는 한동안 문제가 드러나지 않을 수 있다.

예를 들어 모델의 내부적인 판단 기준이 조금씩 변하고 있을 수 있다.

하지만 아직은 위험한 요청을 올바르게 거부할 수 있다.

이런 상황에서 단순한 응답 평가만 수행하면 문제가 없다고 판단할 가능성이 있다.

SafetyPulse는 이를 해결하기 위해 모델 내부의 거부 반응과 관련된 신경망 상태를 측정한다.

연구팀은 이를 Refusal Circuit(거부 반응 회로)라고 부른다.

실제 전자회로가 존재한다는 의미는 아니다.

신경망 내부에서 특정한 종류의 유해 요청을 처리할 때 관련된 활성화 패턴을 분석하는 개념이다.

연구팀은 모델의 기본 상태에서 이 패턴을 측정했다.

이후 추가 학습이 진행되는 동안 같은 패턴이 얼마나 유지되는지 계산했다.

50개 질문으로 체크포인트마다 검사

SafetyPulse는 유해 요청과 정상적인 요청으로 구성된 50개 질문 쌍을 사용한다.

이 질문들을 모델에 전달한 뒤 내부 활성화의 변화를 측정한다.

여기서 Activation(활성화)은 신경망이 입력을 처리할 때 내부 계층에서 계산되는 값이다.

연구팀은 기본 모델의 활성화와 추가 학습한 모델의 활성화를 비교한다.

이후 CIS(Circuit Integrity Score)라는 점수를 계산한다.

CIS는 거부 반응과 관련된 내부 패턴이 기존 상태와 얼마나 비슷하게 유지되는지 나타내는 지표다.

점수가 낮아지면 안전한 거부 반응이 약화되고 있을 가능성이 있다고 판단한다.

연구팀은 모델의 학습 상태를 주기적으로 저장하는 체크포인트마다 CIS를 측정했다.

체크포인트(Checkpoint)는 모델의 학습된 가중치와 진행 상태를 특정 시점에 저장한 자료다.

이렇게 하면 최종 학습이 완료된 뒤에만 안전성을 평가하는 것이 아니라 학습 도중에 변화를 확인할 수 있다.

실제 유해 응답이 증가하기 전에 경고

연구팀은 학습에 사용하지 않은 별도의 실행 결과를 이용해 SafetyPulse를 평가했다.

그 결과 미리 설정한 기준에서 위험한 상태로 판단된 체크포인트를 모두 탐지했다고 밝혔다.

또한 실제 유해 요청에 대한 공격 성공률이 뚜렷하게 증가하기 1~3개 체크포인트 전에 경고를 제공했다.

반면 50개 질문을 실제로 모델에 전달하고 거부 여부만 확인하는 일반적인 방법은 같은 조건에서 약 13%의 문제만 탐지했다.

이는 모델의 내부 상태를 관찰하는 방법이 실제 답변에서 문제가 드러나기 전에 변화를 발견하는 데 도움이 될 가능성을 보여준다.

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

이번 연구는 하나의 기본 모델과 제한된 학습 조건에서 수행됐다.

따라서 다른 모델 아키텍처와 더 큰 모델에서도 같은 조기 탐지 성능이 나타나는지는 추가 검증이 필요하다.

또한 CIS 점수가 낮아졌다고 해서 반드시 실제 위험한 행동이 증가한다는 인과관계가 완전히 확인된 것은 아니다.

안전성을 복구하는 방법도 시험

SafetyPulse는 단순히 문제를 탐지하는 데서 끝나지 않는다.

연구팀은 안전성이 저하된 모델의 일부 가중치를 조정해 이전 상태로 되돌리는 방법도 시험했다.

이를 Safety Repair(안전성 복구)라고 할 수 있다.

예를 들어 추가 학습 과정에서 변경된 가중치 가운데 거부 반응에 관련된 부분만 일부 복구할 수 있다.

하지만 너무 많은 가중치를 이전 상태로 되돌리면 추가 학습에서 얻은 새로운 업무 능력도 사라질 수 있다.

따라서 안전성을 회복하면서 실제 작업 능력을 유지하는 것이 중요하다.

연구팀은 여러 종류의 복구 방법을 비교했다.

일부 구성에서는 위험한 요청에 대한 공격 성공률을 낮추면서 일반적인 수학 문제 해결 능력도 유지하거나 개선할 수 있었다.

하지만 모든 복구 방법이 항상 안전성과 유용성을 동시에 개선하는 것은 아니다.

복구 강도와 모델의 구조, 학습 데이터에 따라 성능이 달라질 수 있다.

작은 연구이지만 중요한 평가 방향

이번 프로젝트는 AI 안전성 관련 해커톤 연구에서 개발됐다.

연구팀은 코드와 실험 자료를 공개했다.

하지만 아직 다양한 대형 언어모델과 실제 기업 환경에서 충분한 독립 검증이 완료된 기술은 아니다.

따라서 SafetyPulse를 사용한다고 해서 모든 종류의 안전성 저하를 조기에 발견할 수 있다고 판단해서는 안 된다.

그럼에도 이번 연구는 중요한 질문을 제시한다.

AI 모델을 추가 학습할 때 최종 결과만 검사하는 것으로 충분한가?

예를 들어 기업이 자체 데이터를 이용해 모델을 지속적으로 추가 학습한다면 학습 도중에도 안전한 행동이 유지되는지 확인할 필요가 있을 수 있다.

이번 글은 AI 모델의 안전성을 평가하는 방법이 최종 응답의 검사에서 모델 내부 상태의 지속적인 감시로 확대될 수 있다는 점을 실제 실험으로 보여준다.