AI 데일리 브리핑 — 2026-10-21

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

---

1️⃣ 주요 모델·연구

Anthropic, Claude가 설계한 전갈 신경독 결합 단백질 17종 실험 검증…64시간의 AI 연구로 31만 개 이상 후보 탐색

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: AI 신약 연구, 단백질 설계, 자율 과학 에이전트, 생명공학, 실험 자동화, 독성 단백질 연구
• 원문: Anthropic — How Claude designed protein binders against scorpion neurotoxins

Anthropic이 Claude를 이용해 전갈의 신경독에 결합하는 새로운 단백질을 설계하고, 실제 실험에서 일부 후보의 결합 능력을 확인한 연구 결과를 공개했다.

이번 연구에서 가장 중요한 점은 AI가 단순히 기존 논문을 읽고 단백질 구조를 추천한 것이 아니라 연구 문제를 분석하고, 대규모 후보를 생성하고, 실험할 대상을 선정하는 과정에 장시간 참여했다는 사실이다.

연구에는 Claude Science 환경에서 실행한 내부 연구 모델이 사용됐다.

연구팀은 처음에 하나의 주요 요청을 전달했고, 이후 네 차례의 추가 지시를 제공했다. 그 사이 Claude는 약 64시간 동안 대부분의 작업을 자율적으로 수행했다.

Claude가 생성한 단백질 설계 후보는 총 318,484개였다.

이 가운데 Claude가 직접 선택한 180개와 연구팀이 추가한 31개를 합쳐 211개 후보를 실제 실험 대상으로 선정했다.

외부 실험기관 두 곳에서 이 후보들을 검증한 결과, 17개 단백질이 목표로 한 전갈 신경독에 결합하는 것으로 확인됐다.

다만 이 결과를 전갈 독에 대한 새로운 치료제나 해독제가 개발됐다는 의미로 해석해서는 안 된다.

연구팀은 단백질이 독소에 결합한다는 사실을 확인했지만, 독소의 유해한 작용을 실제로 중화하는지는 검증하지 못했다고 명확하게 밝혔다.

전갈 독을 막는 단백질을 설계하는 이유

전갈에 쏘이는 사고는 세계 여러 지역에서 발생한다.

Anthropic은 매년 120만 명 이상이 전갈에 쏘이고, 3,250명 이상이 사망한다는 기존 연구 자료를 소개했다.

특히 의료 접근성이 낮은 지역에서는 효과적인 치료를 신속하게 받기 어려울 수 있다.

전갈 독에는 여러 종류의 신경독성 단백질이 포함돼 있다.

이 가운데 일부는 신경세포의 세포막에 존재하는 나트륨 통로(Sodium Channel)에 결합한다.

나트륨 통로는 신경세포가 전기적 신호를 발생시키고 전달하는 데 필요한 단백질이다.

독소가 이 통로의 정상적인 작동을 방해하면 신경세포가 부적절한 시점에 활성화될 수 있다.

심각한 경우 심혈관계와 호흡기계에 영향을 주는 전신 반응으로 이어질 수 있다.

이런 독소의 작용을 막는 방법 가운데 하나는 독소에 먼저 결합해 다른 단백질과의 상호작용을 방해하는 분자를 만드는 것이다.

이번 연구에서 Claude가 설계한 것은 Minibinder(미니바인더)라는 작은 단백질이다.

미니바인더는 특정한 목표 단백질의 표면을 인식하고 강하게 결합하도록 설계된 단백질이다.

항체처럼 표적에 선택적으로 결합하는 기능을 목표로 하지만 구조와 크기, 제조 방법은 다를 수 있다.

31만 개 이상의 후보 가운데 211개만 실험

단백질 설계에서 어려운 문제는 가능한 후보의 수가 매우 많다는 것이다.

아미노산의 종류와 배열을 조금만 바꿔도 서로 다른 단백질이 만들어질 수 있다.

아미노산(Amino Acid)은 단백질을 구성하는 기본 단위다.

어떤 아미노산이 어떤 순서로 연결되는지에 따라 단백질이 접히는 구조와 다른 분자에 결합하는 능력이 달라진다.

Claude는 연구 과정에서 여러 설계 도구와 분석 절차를 이용해 후보를 생성하고 평가했다.

하지만 컴퓨터에서 좋은 후보로 예측된 단백질이 실제 실험에서도 효과적으로 작동한다는 보장은 없다.

설계된 단백질이 예상과 다른 구조로 접히거나 충분히 안정적이지 않을 수 있기 때문이다.

연구팀은 Claude가 선정한 후보를 외부의 실험기관인 Adaptyv Bio와 Twist Bioscience에 전달했다.

두 기관은 실제 단백질을 제작하고 목표 독소와의 결합 여부를 검사했다.

평가에는 SPR(Surface Plasmon Resonance, 표면 플라스몬 공명) 같은 실험 기술이 사용됐다.

SPR은 두 분자가 결합하거나 분리되는 과정을 측정해 상호작용의 강도를 분석하는 방법이다.

연구팀은 특정한 결합 강도와 재현성 기준을 충족한 후보를 성공적인 바인더로 분류했다.

그 결과 총 17개가 기준을 충족했다.

이들은 서로 다른 네 종류의 신경독을 대상으로 했다.

연구팀이 조사한 모든 독소에 대해 성공적인 바인더가 만들어진 것은 아니며, 하나의 단백질이 여러 독소를 동시에 효과적으로 결합하는 결과도 확보하지 못했다.

결합 강도와 독소 중화 능력은 다르다

연구에서는 일부 후보가 매우 강한 결합 능력을 보였다.

특히 Cn2라는 독소에 결합하는 후보 가운데 일부는 나노몰 수준의 결합 친화도를 기록했다.

결합 친화도는 두 분자가 얼마나 강하게 결합하는지 나타내는 특성이다.

이를 표현하는 지표 가운데 하나가 KD(해리 상수)다.

일반적으로 동일한 조건에서 KD가 작을수록 두 분자가 강하게 결합하는 것으로 해석할 수 있다.

하지만 결합력이 강하다는 사실만으로 독소의 기능을 차단할 수 있다고 판단해서는 안 된다.

예를 들어 바인더가 독소의 특정 표면에 강하게 붙더라도, 독소가 신경세포의 나트륨 통로에 결합하는 부위가 그대로 노출돼 있다면 독성을 막지 못할 수 있다.

실제로 해독제로 사용할 수 있는지 확인하려면 세포 수준에서 독소의 작용이 억제되는지 검사해야 한다.

이후 동물실험 등을 통해 안전성과 효과를 평가하는 추가 연구도 필요하다.

Anthropic은 이번 연구가 그런 단계까지 진행되지 않았음을 명확하게 밝혔다.

따라서 이번 결과는 실험적으로 결합이 확인된 단백질 후보를 발견한 연구이지, 전갈 해독제를 완성한 연구가 아니다.

AI 에이전트가 과학 연구에 참여하는 방식

이번 사례는 AI를 과학 연구에 사용하는 방법이 변화하고 있음을 보여준다.

기존에는 연구자가 문제를 정의하고 AI 모델에 특정한 예측을 요청하는 방식이 중심이었다.

예를 들어 연구자가 단백질 구조를 입력하면 모델이 결합 가능성을 예측하는 방식이다.

반면 이번 연구에서는 Claude가 여러 설계 도구를 사용하고, 대량의 후보를 비교하며, 실험할 후보를 선택하는 일련의 연구 과정에 참여했다.

또한 분석 결과를 정리하고 보고서 초안을 만드는 작업에도 활용됐다.

다만 연구가 완전히 사람의 개입 없이 수행된 것은 아니다.

연구 문제의 선택과 실험 설계, 중간 방향 조정, 실제 실험과 결과 검증에는 사람이 참여했다.

Anthropic은 이번 연구에 사용된 211개 후보의 설계 정보와 실험 데이터도 공개했다.

다른 연구자들이 결과를 재분석하거나 새로운 후보를 개발하는 데 활용할 수 있도록 하기 위한 조치다.

이번 결과는 AI가 과학 연구의 속도를 높일 수 있다는 가능성을 보여주는 동시에, 컴퓨터가 예측한 결과를 실제 생물학적 실험으로 검증하는 과정은 여전히 필수적이라는 점을 분명하게 보여준다.

---

NVIDIA, 실제 수술 영상을 학습한 로봇 시뮬레이터 ‘Cosmos3-H-Dreams’ 공개…수술도구 움직임에 실시간 반응하는 영상 생성

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: 로봇 AI, 멀티모달 생성형 AI, 의료 로봇, 수술 시뮬레이션, 월드 모델, GPU 추론 최적화
• 원문: NVIDIA — Cosmos3-H-Dreams: Bringing Clinical Surgery to Life Through Generative Simulation

NVIDIA가 실제 수술 장면과 수술 로봇의 움직임 데이터를 학습한 새로운 생성형 시뮬레이터 Cosmos3-H-Dreams를 공개했다.

이 시스템은 사용자가 수술 로봇의 도구를 움직이면 그 움직임에 반응하는 새로운 수술 장면을 영상으로 생성한다.

기존의 영상 생성 AI가 주어진 문장이나 이미지로 동영상을 만드는 데 집중했다면, 이번 모델은 도구를 어떻게 조작하는지에 따라 다음 화면이 달라지는 상호작용에 초점을 맞췄다.

NVIDIA는 이런 종류의 모델을 World Foundation Model(월드 기반 모델)이라고 부른다.

월드 모델은 특정 환경에서 어떤 행동을 하면 이후 상태가 어떻게 달라질지 예측하거나 생성하도록 학습된 모델이다.

예를 들어 로봇 팔이 물체를 밀면 물체가 어느 방향으로 움직일지, 집게로 물체를 잡으면 어떻게 반응할지 예측하는 방식이다.

이번에는 이런 접근을 실제 인체 내부의 수술 장면에 적용했다.

기존의 물리 시뮬레이션과 다른 접근

일반적인 로봇 시뮬레이터에서는 물체의 위치와 형태, 질량, 마찰력 등을 정의하고 물리법칙에 따라 상태 변화를 계산한다.

하지만 수술 환경은 매우 복잡하다.

인체 조직은 수술도구의 움직임에 따라 늘어나거나 압축될 수 있다.

도구가 조직을 가리면 화면에서 일부 구조가 보이지 않게 된다.

빛의 반사와 연기, 수술도구의 회전도 영상에 영향을 준다.

이런 변화를 모두 수학적인 물리 모델로 정확하게 구현하기는 어렵다.

Cosmos3-H-Dreams는 다른 방식을 사용한다.

실제 수술 영상과 그 순간의 로봇 제어 데이터를 함께 학습해, 특정 행동 이후 어떤 영상이 나타나는지 생성한다.

기존 모델이 명시적인 물리 계산을 중심으로 동작했다면, 이번 모델은 대량의 영상과 동작 데이터에서 시각적인 변화의 패턴을 학습한 것이다.

NVIDIA는 앞서 탁자 위에서 수행하는 봉합 작업을 시뮬레이션하는 Cosmos-H-Dreams를 공개한 바 있다.

이번 업데이트는 이를 실제 수술 데이터로 확장했다는 점에서 차이가 있다.

담낭절제술과 수술 로봇 데이터 사용

이번 모델의 학습에는 복강경 담낭절제술(Cholecystectomy) 영상이 사용됐다.

담낭절제술은 담낭을 제거하는 수술이다.

연구팀은 CMR Surgical의 Versius 수술 로봇에서 기록한 영상과 로봇 동작 데이터를 활용했다.

시뮬레이터는 두 종류의 수술도구를 중심으로 작동한다.

하나는 조직을 잡고 움직이는 Cadiere Grasper다.

다른 하나는 절개나 조직 분리에 사용되는 Monopolar Hook이다.

모델은 두 도구의 위치와 회전, 집게 상태, 에너지 제어와 조작 버튼 등 총 28개 차원의 제어 정보를 사용한다.

학습 영상의 해상도는 832×480이며, 로봇 동작 데이터는 초당 10회의 간격으로 영상과 정렬됐다.

이렇게 영상과 행동을 같은 시점에 맞추는 과정이 중요하다.

예를 들어 도구가 왼쪽으로 움직였을 때 실제 조직이 어떻게 반응했는지 배우려면 영상과 제어 데이터 사이의 시간 관계가 정확해야 하기 때문이다.

긴 영상에서 발생하는 오류 누적 문제

생성형 영상 시뮬레이션에서는 처음 몇 프레임이 자연스럽더라도 시간이 지나면서 장면이 점차 이상해지는 문제가 발생할 수 있다.

예를 들어 수술도구의 형태가 바뀌거나 조직의 위치가 갑자기 이동할 수 있다.

모델이 이전에 자신이 생성한 영상을 다시 입력으로 사용하면서 작은 오류가 반복해서 누적되기 때문이다.

NVIDIA는 이를 해결하기 위해 먼저 상대적으로 큰 교사 모델(Teacher Model)을 학습시켰다.

교사 모델은 먼저 24개의 미래 프레임을 예측하도록 학습됐다.

이후 예측 범위를 72개 프레임까지 확대했다.

초당 10프레임을 기준으로 각각 2.4초와 7.2초에 해당한다.

그다음 교사 모델의 능력을 더 빠르게 실행할 수 있는 학생 모델(Student Model)에 전달했다.

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

큰 모델이 학습한 행동을 상대적으로 가볍거나 빠른 모델에 전달하는 학습 방식이다.

학생 모델에는 자신이 생성한 이전 영상을 다시 입력으로 사용하면서 학습하는 Self-Forcing 기법도 적용됐다.

실제 실행에서는 이전에 생성한 영상이 계속 다음 영상의 입력으로 사용되므로, 학습 과정에서도 같은 조건을 경험하도록 만든 것이다.

생성 속도와 화질의 절충 관계

NVIDIA는 두 종류의 실행 모델을 공개했다.

하나는 영상 블록을 생성할 때 네 번의 노이즈 제거 단계를 사용하는 모델이다.

다른 하나는 두 번의 단계를 사용하는 모델이다.

이 과정에서 말하는 노이즈 제거는 일반적인 영상의 잡음을 없애는 작업과는 다르다.

확산 기반 생성 모델이 무작위적인 초기 표현에서 점차 원하는 영상에 가까운 결과를 만드는 계산 과정을 의미한다.

단계 수를 줄이면 결과를 더 빠르게 생성할 수 있다.

하지만 영상의 시각적 품질이 떨어질 수 있다.

NVIDIA는 두 단계 모델을 네 단계 모델의 설정만 바꿔 실행한 것이 아니라 별도로 추가 학습한 모델이라고 설명했다.

또한 FlashDreams라는 스트리밍 추론 기술을 결합해 영상 생성을 가속했다.

이 구성은 NVIDIA RTX PRO 6000 GPU 한 대에서 실시간 상호작용이 가능하도록 설계됐다.

다만 모델이 실시간으로 실행된다는 사실과 생성된 장면의 물리적 정확성이 입증됐다는 사실은 다르다.

시각적으로 자연스러운 수술 장면이 실제 안전성을 보장하지는 않는다

이번 연구에서 가장 중요한 제한은 생성된 영상의 시각적 사실성이 실제 생체역학적 정확성을 보장하지 않는다는 점이다.

예를 들어 영상 속 조직이 도구의 움직임에 따라 자연스럽게 늘어나는 것처럼 보이더라도, 실제 인체 조직과 동일한 힘과 변형 관계를 재현한다는 보장은 없다.

또한 수술도구가 조직에 가하는 압력이나 특정 조작이 실제 환자에게 미치는 영향을 검증한 결과도 이번 발표에 포함되지 않았다.

따라서 Cosmos3-H-Dreams를 실제 의료진의 수술 훈련이나 환자 안전 평가에 검증 없이 사용할 수 있는 완성된 의료 시뮬레이터로 보아서는 안 된다.

NVIDIA는 모델의 가중치와 실행 코드, 학습·적응 방법을 공개하고 연구자들이 새로운 로봇과 데이터에 적용할 수 있도록 했다.

이번 발표는 생성형 AI의 역할이 영상 제작에서 더 나아가 로봇이 실제 환경에서 행동하기 전에 여러 상황을 시험하는 상호작용 시뮬레이션으로 확대되고 있음을 보여준다.

---

Ai2, AI 채용·대출 심사의 숨겨진 편향을 측정하는 ‘FairStress’ 공개…동일한 압박에 대한 판단 변화까지 평가

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: AI 공정성, 채용·금융 의사결정, 의료 AI, AI 안전 평가, 오픈소스 벤치마크, 모델 편향 분석
• 원문: Allen Institute for AI — FairStress: A deeper evaluation of fairness in LLM decision-making

미국의 비영리 AI 연구기관 Allen Institute for AI(Ai2)가 언어모델의 의사결정 공정성을 더 세밀하게 평가하는 새로운 벤치마크 FairStress를 공개했다.

기존 AI 공정성 평가에서는 같은 능력을 가진 두 사람의 인구통계학적 특성만 바꿔 모델의 선택이 달라지는지 검사하는 경우가 많았다.

예를 들어 동일한 경력을 가진 지원자의 성별이나 인종 정보를 바꿨을 때 채용 추천 결과가 달라지는지 확인하는 방식이다.

하지만 연구팀은 최종 선택이 같더라도 그 선택을 유지하는 정도에는 차이가 있을 수 있다는 문제에 주목했다.

예를 들어 두 지원자 가운데 A의 경력이 명확하게 더 좋다고 가정해 보자.

모델이 처음에는 두 가지 인구통계학적 조건에서 모두 A를 선택했다면 겉으로는 공정하게 행동한 것처럼 보일 수 있다.

하지만 이후 누군가 B를 선택해야 한다는 압박을 가했을 때, 지원자의 특성에 따라 모델이 올바른 선택을 포기하는 비율이 달라질 수 있다.

FairStress는 바로 이런 차이를 측정한다.

300개 시나리오에서 1,300만 개 이상의 평가 사례 생성

FairStress에는 29개 분야의 300개 의사결정 시나리오가 포함된다.

주요 분야는 채용, 대출, 의료, 교육, 주거와 형사사법이다.

각 시나리오에서는 일반적으로 두 후보 가운데 하나를 선택해야 한다.

어떤 시나리오에서는 객관적인 조건에 따라 한 후보가 명확하게 더 적합하다.

다른 시나리오에서는 두 후보가 각각 다른 장점을 가지고 있어 어느 쪽이 더 좋은지 판단하기 어렵다.

연구팀은 후보의 인구통계학적 특성을 여러 방식으로 표현했다.

특성 정보를 전혀 제공하지 않거나, 이름을 통해 간접적으로 암시하거나, 명시적인 설명을 제공하는 방식이다.

여기에 모델의 선택을 변경하도록 유도하는 Adversarial Prefix(적대적 설득 문구)를 추가했다.

예를 들어 상급자가 특정 후보를 추천했다는 주장이나, 특정 지원자가 역사적으로 불리한 집단에 속한다는 설명을 추가할 수 있다.

연구팀은 이런 문구가 어느 후보를 지지하느냐에 따라 모델의 판단이 어떻게 달라지는지 비교했다.

그 결과 기본 시나리오 300개를 확장해 1,300만 개 이상의 평가 사례를 구성했다.

전체 평가 비용이 매우 높을 수 있다는 점을 고려해 5만 개 사례로 구성된 FairStress-Core도 제공한다.

최초 답변은 같아도 설득에 대한 반응은 달랐다

연구팀은 Olmo, Llama, Qwen, Gemma, Claude와 GPT 계열 모델을 평가했다.

흥미롭게도 인구통계학적 정보가 없는 상태에서는 여러 모델이 비슷한 판단을 내렸다.

한 후보가 명확하게 더 적합한 상황에서는 대체로 해당 후보를 선택했다.

하지만 인구통계학적 정보가 구체적으로 제공되면 결과가 달라졌다.

Ai2는 일부 모델이 상대적으로 불리한 집단을 지지하는 주장에 더 쉽게 영향을 받아, 원래 근거에 부합했던 결정을 포기하는 경향을 발견했다고 설명한다.

이는 연구팀이 Anti-Stereotypical Over-Correction(고정관념을 피하려다 발생하는 과잉 보정)이라고 부르는 현상이다.

모델이 특정 집단에 불리한 판단을 내리지 않으려는 과정에서 객관적인 자격이나 조건의 차이를 충분히 반영하지 못할 수 있다는 뜻이다.

연구팀이 평가한 15개 모델에서는 집단 정체성이 간접적으로 암시됐을 때 올바른 선택을 포기하는 비율의 평균 격차가 6.9%포인트였다.

정체성을 명시적으로 표시한 경우에는 격차가 9.3%포인트였다.

다만 이는 여러 모델과 평가 조건을 종합한 결과다.

모든 모델이 같은 집단을 같은 정도로 선호했다는 뜻은 아니다.

또한 특정 실제 채용 시스템이 이러한 비율로 차별적인 결정을 내린다는 의미도 아니다.

공정성을 하나의 숫자로 정의할 수는 없다

Ai2는 FairStress가 대칭적 공정성(Symmetric Fairness)이라는 특정한 정의를 사용한다고 명시했다.

이 정의에서는 동일한 조건의 사람에게 동일한 기준을 적용하고, 근거에 따라 내린 판단이 인구통계학적 특성과 무관하게 비슷한 수준으로 유지돼야 한다.

하지만 공정성에는 다른 관점도 존재한다.

예를 들어 역사적인 차별과 구조적인 불이익을 고려하는 형평성(Equity) 중심의 접근에서는 동일한 조건을 기계적으로 적용하는 것만으로 충분하지 않을 수 있다.

FairStress는 이런 다양한 공정성 개념을 모두 평가하는 도구가 아니다.

연구팀도 이 한계를 명확하게 설명한다.

따라서 벤치마크 점수가 높다는 이유만으로 어떤 AI 모델이 모든 사회적 상황에서 공정하게 행동한다고 결론 내릴 수는 없다.

이번 연구는 AI의 최초 답변뿐 아니라 압박과 설득, 추가 정보가 주어졌을 때 판단이 얼마나 일관되게 유지되는지를 평가해야 한다는 새로운 관점을 제공한다.

특히 AI를 채용이나 금융 심사처럼 사람의 권리와 기회에 영향을 주는 업무에 활용하려는 조직에는 중요한 평가 문제를 제시한다.

---

2️⃣ AI 제품·서비스

Google Cloud, 공공기관용 ‘Gemini for Government Services’ 프리뷰 공개…법령 검색부터 정보공개 청구·보조금 감사까지 지원

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 AI 에이전트, 공공기관 업무 자동화, 법령 검색, 정보공개 청구, 공공 데이터 보안, Google Cloud
• 원문: Google Cloud — Introducing Gemini for government services

Google Cloud가 정부와 공공기관의 업무에 특화된 AI 에이전트 환경인 Gemini for Government Services를 프리뷰로 공개했다.

이번 발표는 Gemini의 새로운 기반 모델을 출시한 것이 아니다.

기존 Gemini 에이전트에 정부 업무에 필요한 전문 지침과 데이터 연결, 접근권한 관리, 검토 절차를 결합한 산업별 솔루션이다.

일반적인 기업용 AI 에이전트와 공공기관용 에이전트 사이에는 중요한 차이가 있다.

예를 들어 기업의 내부 보고서를 요약하는 AI가 내용을 일부 잘못 해석하면 담당자가 수정할 수 있다.

하지만 공공기관이 시민의 자격 요건이나 법적 의무를 판단하는 과정에서 잘못된 정보를 사용하면 실제 권리와 행정 절차에 영향을 줄 수 있다.

따라서 정부 업무에는 일반적인 정보 검색 능력뿐 아니라 어떤 법령을 적용했는지 설명하고, 담당자가 검토할 수 있는 근거를 남기는 기능이 중요하다.

법령과 업무 지침을 재사용 가능한 Skill로 구성

Google은 정부 업무에 필요한 지식을 Skill이라는 형태로 제공한다.

Skill은 AI 에이전트가 특정 작업을 수행할 때 참고하는 전문 지침과 절차, 관련 정보를 묶은 구성요소다.

예를 들어 보조금 지출을 검토하는 에이전트에는 해당 사업에 적용되는 법령과 감사 기준, 필요한 서류 목록을 제공할 수 있다.

정부 계약을 검토하는 에이전트에는 입찰 규칙과 심사 절차를 제공할 수 있다.

중요한 점은 범용 언어모델이 학습한 일반적인 지식에만 의존하지 않는다는 것이다.

에이전트가 실제 업무를 수행할 때 해당 기관이 따라야 하는 구체적인 규칙을 참고하도록 만드는 것이다.

Google은 법령과 규정에 관한 질문에 답할 때 원문 자료의 페이지와 문단을 함께 제시하는 기능을 소개했다.

이는 담당자가 AI의 설명을 그대로 믿는 대신 실제 규정에 근거해 판단을 검토하도록 돕는다.

기존 정부 시스템의 데이터를 이동하지 않고 연결

공공기관은 여러 종류의 시스템을 사용한다.

예를 들어 인사 정보는 별도의 인사관리 시스템에 있고, 계약 정보는 조달 시스템에 있으며, 민원 자료는 문서관리 시스템에 저장돼 있을 수 있다.

이런 데이터를 모두 하나의 AI 서비스로 복사하는 것은 보안과 규제 측면에서 부담이 될 수 있다.

Google은 Gemini가 각 시스템에 직접 질의하도록 하는 Connector(연결 도구)를 제공한다.

연결 대상에는 Google Workspace와 Microsoft 365, SharePoint, Salesforce, ServiceNow, Oracle 기반 업무 시스템 등이 포함된다.

또한 미국의 Federal Register, eCFR, Regulations.gov 같은 공식 규제 정보에도 연결할 수 있다.

핵심 설계는 원본 데이터를 다른 저장소로 무조건 이전하지 않는다는 것이다.

에이전트는 필요한 시스템에 접근해 관련 정보를 가져오고, 해당 시스템에서 이미 설정된 사용자별 접근권한을 따라야 한다.

하지만 원본 데이터가 이동하지 않는다는 사실만으로 모든 데이터 처리 위험이 사라지는 것은 아니다.

AI 모델이 특정 자료를 읽고 요약한 결과에도 민감정보가 포함될 수 있기 때문이다.

따라서 실제 서비스에서는 모델의 출력과 외부 전송 경로도 함께 관리해야 한다.

정보공개 청구와 문서 비공개 처리

Google이 소개한 대표적인 활용 사례는 FOIA(Freedom of Information Act) 관련 업무다.

FOIA는 미국의 연방 정보공개법이다.

시민이나 언론사가 정부에 특정한 기록의 공개를 요청할 수 있도록 하는 법률이다.

공공기관은 요청받은 자료를 찾아 검토하고, 법에 따라 공개할 수 없는 정보를 적절하게 가려야 할 수 있다.

이를 Redaction(비공개 처리 또는 정보 가림)이라고 한다.

예를 들어 공개 대상 문서에 시민의 개인정보가 포함돼 있다면 해당 부분을 가려야 할 수 있다.

Gemini는 여러 문서 저장소와 이메일 기록에서 관련 자료를 검색하고, 비공개 처리해야 할 가능성이 있는 내용을 식별하도록 설계됐다.

하지만 AI가 자동으로 모든 공개 여부를 최종 결정하는 것은 아니다.

Google은 중요한 단계마다 사람이 검토하고 승인하는 구조를 강조했다.

즉 AI는 검토 대상을 정리하고 후보를 제시하지만, 실제 공개와 비공개 판단은 담당자가 확인하도록 구성한 것이다.

보조금 감사와 입찰 평가

다른 활용 사례는 정부 보조금과 계약 업무다.

예를 들어 특정 보조금 사업에서는 사용할 수 있는 비용의 종류와 지출 증빙 요건이 정해져 있다.

에이전트는 청구서와 영수증, 구매주문서 등을 관련 규정과 비교해 문제가 있는 항목을 표시할 수 있다.

또한 입찰 제안서의 필수 요건이 충족됐는지 확인하고, 평가 기준에 맞는 근거를 정리할 수 있다.

이런 작업에서는 단순히 문서의 내용을 이해하는 것뿐 아니라 서로 다른 문서에 있는 숫자와 조건을 비교하는 능력이 중요하다.

다만 정부 보조금이나 입찰에 관한 실제 법적 판단을 AI가 독자적으로 수행할 수 있다는 의미는 아니다.

Google이 발표한 기능은 담당자의 검토를 지원하는 도구로 이해해야 한다.

공공기관의 보안·운영 정책을 중앙에서 관리

Gemini for Government Services에는 에이전트의 접근권한과 데이터 사용 정책을 중앙에서 관리하는 기능도 포함된다.

Google은 VPC Service Controls, CMEK, Assured Workloads 등을 관련 기술로 제시했다.

VPC Service Controls는 Google Cloud의 서비스와 데이터가 정해진 보안 경계를 벗어나지 않도록 제한하는 기능이다.

CMEK(Customer-Managed Encryption Key)는 고객이 관리하는 암호화 키를 사용하는 방식이다.

Assured Workloads는 특정 규제와 보안 요구사항을 충족하도록 클라우드 환경을 구성하는 기능이다.

이런 기술을 결합해 기관은 어떤 에이전트가 어떤 자료에 접근할 수 있는지 관리할 수 있다.

다만 이번 서비스는 프리뷰 단계다.

일부 기능이 공개됐다고 해서 모든 정부기관에서 즉시 모든 연결 도구와 업무 자동화 기능을 사용할 수 있는 것은 아니다.

Google은 이번 발표에서 일반적인 정부 업무의 처리 시간이 어느 정도 단축되는지에 대한 독립적인 성능 검증 결과를 제시하지 않았다.

이번 발표는 기업용 AI 에이전트가 산업별 전문성을 확보하는 방향으로 발전하고 있음을 보여준다.

특히 공공기관에서는 모델의 답변 품질만큼 법적 근거를 확인할 수 있는가, 기존 접근권한을 유지하는가, 중요한 결정을 사람이 통제할 수 있는가가 중요한 제품 요구사항이 되고 있다.

---

OpenAI, 신약 개발 업무 조정 플랫폼 ‘Orchestra Bio’ 인수…Rosalind의 과학 분석과 연구 프로젝트 관리 연결 추진

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: AI 신약 개발, 과학 연구 에이전트, 바이오의약품 개발, 실험 계획, 임상 연구 프로젝트 관리
• 원문: OpenAI — OpenAI acquires Orchestra Bio

OpenAI가 바이오의약품 개발 업무를 조정하는 플랫폼 기업 Orchestra Bio를 인수했다고 발표했다.

이번 발표는 투자 금액이나 기업가치에 관한 소식보다 OpenAI가 과학 연구용 AI와 실제 의약품 개발 프로젝트를 연결하려 한다는 기술적 방향에 주목할 필요가 있다.

OpenAI는 기존에 Rosalind라는 생명과학 연구용 AI 제품군을 제공하고 있다.

Rosalind에는 생물학과 화학 관련 문제를 분석하는 GPT-Rosalind와 실제 과학 도구 및 데이터를 연결하는 Rosalind Workbench가 포함된다.

Rosalind Workbench는 연구자가 실험 결과를 분석하고 새로운 실험을 계획하도록 지원하는 환경이다.

하지만 신약 개발에서는 과학적인 발견만으로 실제 치료제가 완성되지 않는다.

신약 후보를 발견한 뒤에도 많은 업무가 남는다

일반적으로 새로운 의약품을 개발하려면 여러 단계의 연구와 검증을 거쳐야 한다.

연구자는 먼저 질병과 관련된 생물학적 표적을 찾고, 해당 표적에 작용할 가능성이 있는 물질을 탐색한다.

이후 후보 물질의 효과와 독성, 약물의 체내 작용을 검사해야 한다.

제조 공정과 품질관리 방법을 개발하는 과정도 필요하다.

임상시험에 들어가면 연구기관과 병원, 제조업체, 규제기관 사이의 협력이 중요해진다.

OpenAI는 미국에서 표적 발견부터 의약품 승인까지 평균적으로 10~15년 정도가 걸릴 수 있다고 설명했다.

이처럼 긴 기간에는 과학적 난제뿐 아니라 업무 조정 문제도 영향을 미친다.

예를 들어 임상시험에 사용할 의약품의 제조 과정에서 문제가 발생하면 시험 시작 일정이 변경될 수 있다.

그런데 그 일정 변경은 단순히 제조팀 하나에만 영향을 주지 않는다.

임상시험 기관의 준비 일정과 규제 서류, 계약과 공급 일정까지 함께 달라질 수 있기 때문이다.

Orchestra Bio가 담당하는 역할

Orchestra Bio는 이런 업무를 여러 팀 사이에서 조정하는 플랫폼이다.

연구자와 프로젝트 관리자는 임상시험 준비와 제조, 실험 일정 등의 진행 상태를 확인하고, 일부 모니터링 업무를 AI 에이전트에게 맡길 수 있다.

AI 에이전트는 여러 업무 사이의 의존관계를 분석해 특정 단계에서 발생한 문제가 다른 일정에 어떤 영향을 주는지 찾아낼 수 있다.

예를 들어 제조 일정이 지연되면 관련된 실험과 임상시험 준비 업무를 확인하고 가능한 대응 방안을 비교하도록 만드는 것이다.

여기서 중요한 개념은 Workflow Dependency(업무 의존관계)다.

어떤 업무가 완료돼야 다음 업무를 진행할 수 있는지 나타내는 관계를 의미한다.

일반적인 프로젝트 관리 도구도 이런 의존관계를 관리할 수 있다.

Orchestra는 여기에 AI 에이전트를 결합해 여러 자료를 조사하고 영향을 받는 작업을 파악하는 과정을 자동화하려 한다.

과학적 판단과 업무 실행을 연결

OpenAI는 Rosalind와 Orchestra Bio를 결합해 과학적 발견과 실제 개발 과정 사이의 연결을 강화하겠다고 설명했다.

예를 들어 Rosalind가 특정 실험 데이터를 분석하고 새로운 실험이 필요하다고 제안할 수 있다.

이후 Orchestra의 업무 관리 기능이 해당 실험에 필요한 협력기관과 자원, 기존 일정에 미치는 영향을 정리하는 방식이 가능할 수 있다.

하지만 이번 발표는 이런 통합 기능 전체가 이미 상용 서비스에 배포됐다는 의미는 아니다.

OpenAI는 두 기술과 조직을 결합할 계획을 설명했으며, 구체적인 통합 제품의 제공 일정과 성능 지표를 공개하지 않았다.

또한 AI 에이전트가 임상시험을 독자적으로 승인하거나 의약품의 효과와 안전성을 최종 판단한다는 내용도 아니다.

실제 의약품 개발에는 생물학적 실험과 품질관리, 규제기관의 심사 등이 필요하다.

이번 발표는 AI가 신약 후보를 찾는 역할에서 더 나아가 실험과 제조, 연구 협력과 프로젝트 의사결정까지 포함한 긴 개발 과정의 일부를 지원하려는 방향을 보여준다.

다만 실제 개발 기간이 얼마나 단축될지는 향후 제품 도입과 운영 결과를 통해 검증해야 한다.

---

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

Google·IBM·Red Hat, 분산 LLM 추론 플랫폼 ‘llm-d 1.0’ 공개…에이전트별 캐시 재사용과 GPU·TPU 자원 배분 지원

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: 오픈소스, LLM 추론 인프라, Kubernetes, AI 에이전트, GPU·TPU, KV Cache, 분산 모델 서빙
• 원문: Google Cloud — Announcing llm-d 1.0: Open distributed inference for agents

Google Cloud가 IBM, Red Hat 및 오픈소스 커뮤니티와 함께 개발한 분산 언어모델 추론 플랫폼 llm-d 1.0을 공개했다.

llm-d는 여러 서버에서 실행되는 언어모델을 하나의 서비스처럼 관리하는 소프트웨어다.

이번 1.0 버전은 연구용 기능을 모아둔 초기 프로젝트에서 나아가 실제 운영 환경에 필요한 안정적인 API와 트래픽 관리, 업그레이드 기능을 제공하는 단계로 발전했다는 의미가 있다.

프로젝트에는 25개 이상의 조직에서 500명 이상의 기여자가 참여했다.

llm-d는 현재 CNCF(Cloud Native Computing Foundation)의 Sandbox 프로젝트다.

CNCF는 Kubernetes를 비롯한 클라우드 네이티브 기술의 발전과 표준화를 지원하는 재단이다.

Sandbox는 초기 오픈소스 프로젝트를 지원하는 단계이며, 이 자체가 모든 기능의 성숙도나 안정성을 보증한다는 의미는 아니다.

일반적인 챗봇과 AI 에이전트의 트래픽은 다르다

기존 챗봇에서는 사용자가 질문을 보내고 모델이 답변하는 방식이 일반적이었다.

이런 환경에서는 여러 모델 서버에 요청을 순서대로 분산하는 방식도 사용할 수 있다.

하지만 AI 에이전트는 하나의 작업에서 모델을 여러 번 호출한다.

예를 들어 코딩 에이전트가 저장소를 분석할 때 다음과 같은 과정이 발생할 수 있다.

먼저 사용자의 요청과 기존 프로젝트 정보를 읽는다.

이후 파일을 검색하고 내용을 분석한다.

그다음 수정 코드를 작성하고 테스트를 실행한다.

테스트에서 오류가 발생하면 이전 결과를 참고해 다시 코드를 수정한다.

이 과정에서 모델은 이전 요청과 상당 부분 동일한 컨텍스트를 반복해서 처리할 수 있다.

컨텍스트는 모델이 참고하는 이전 대화와 지침, 도구 실행 기록 등을 의미한다.

문제는 각 모델 호출이 서로 다른 서버로 전달되면 이미 계산한 내용을 다시 처리해야 할 수 있다는 점이다.

KV Cache를 알고 요청을 분배한다

언어모델은 이전 입력을 처리하면서 계산한 일부 정보를 KV Cache(Key-Value Cache)에 저장한다.

KV Cache는 모델이 다음 토큰을 생성할 때 이전 토큰과 관련된 계산을 반복하지 않도록 돕는 저장 구조다.

예를 들어 사용자가 긴 기술 문서를 전달하고 여러 질문을 이어간다면 문서의 앞부분은 여러 요청에서 반복될 수 있다.

동일한 모델 서버가 해당 문서의 KV Cache를 가지고 있다면 일부 계산을 재사용할 수 있다.

하지만 요청이 다른 서버로 전달되면 같은 문서를 처음부터 처리해야 할 수 있다.

llm-d는 이를 해결하기 위해 Cache-Aware Routing(캐시 인식 요청 분배)를 사용한다.

시스템은 어떤 서버에 어떤 컨텍스트의 캐시가 저장돼 있는지 확인한다.

이후 새로운 요청이 들어오면 해당 캐시를 가진 서버를 우선적으로 고려한다.

물론 캐시가 있는 서버에 요청이 너무 많이 몰려 있다면 다른 서버를 선택해야 할 수도 있다.

따라서 llm-d는 캐시의 존재 여부뿐 아니라 서버의 현재 부하와 예상 지연시간도 함께 고려한다.

GPU 메모리에서 CPU 메모리·스토리지로 캐시 이동

KV Cache는 GPU 메모리를 많이 사용할 수 있다.

특히 긴 문서를 읽거나 여러 에이전트가 동시에 실행되면 캐시의 크기가 크게 증가한다.

하지만 GPU 메모리는 가격이 높고 용량에도 제한이 있다.

llm-d는 이런 문제를 해결하기 위해 Tiered KV Cache(계층형 KV 캐시)를 제공한다.

자주 사용하는 캐시는 GPU 메모리에 유지하고, 상대적으로 사용 빈도가 낮은 캐시는 다른 저장 계층으로 이동하는 방식이다.

예를 들어 일부 캐시를 CPU 메모리나 외부 저장소로 옮길 수 있다.

이후 다시 필요한 경우 해당 캐시를 불러와 사용할 수 있다.

이는 웹 서비스에서 자주 사용하는 데이터를 메모리 캐시에 저장하고 덜 사용하는 데이터를 상대적으로 느린 저장소에 보관하는 방식과 비슷하다.

다만 캐시를 저장소에서 다시 가져오는 데도 시간이 필요하다.

따라서 어떤 캐시를 어디에 보관할지 결정하는 정책이 중요하다.

입력 처리와 토큰 생성을 서로 다른 서버에서 실행

llm-d는 Disaggregated Inference(분리형 추론)도 지원한다.

언어모델의 추론은 크게 두 단계로 나뉜다.

첫 번째는 Prefill이다.

사용자가 전달한 입력 전체를 읽고 내부 계산을 수행하는 단계다.

두 번째는 Decode다.

입력을 처리한 뒤 출력 토큰을 하나씩 생성하는 단계다.

Prefill은 많은 행렬 연산이 집중되는 반면 Decode는 이전 계산 결과와 모델 가중치를 반복해서 읽는 과정이 중요하다.

두 작업은 GPU 자원의 사용 특성이 다르다.

따라서 서로 다른 서버에서 실행하면 특정 작업에 적합한 자원을 독립적으로 배치할 수 있다.

llm-d 1.0에는 이 구조의 업그레이드와 실행 상태를 관리하는 DisaggregatedSet도 포함된다.

예를 들어 모델 서버의 일부를 업데이트할 때 전체 서비스를 중단하지 않고 작업을 순차적으로 이동시키도록 설계됐다.

여러 고객과 에이전트 사이의 우선순위 관리

실제 서비스에서는 모든 요청이 같은 수준의 응답 속도를 요구하지 않는다.

사용자가 채팅 화면에서 기다리는 요청은 빠르게 처리해야 할 수 있다.

반면 백그라운드에서 보고서를 작성하는 에이전트는 상대적으로 느리게 처리해도 괜찮을 수 있다.

llm-d는 이런 차이를 반영해 요청의 우선순위와 처리량을 관리한다.

여기에는 QoS(Quality of Service, 서비스 품질) 개념이 사용된다.

서로 다른 작업에 필요한 응답 지연시간과 처리량을 보장하도록 자원을 배분하는 방식이다.

Google은 이번 발표에서 1,000개의 격리된 AI 에이전트가 하나의 llm-d 엔드포인트를 사용하는 시연도 공개했다.

시연에는 vLLM과 SGLang, Google Cloud의 GPU와 TPU가 함께 사용됐다.

다만 시연에서 1,000개 에이전트가 작동했다는 사실이 모든 서비스에서 동일한 처리량이나 응답 속도를 보장한다는 의미는 아니다.

실제 성능은 모델 크기와 입력 길이, 하드웨어 구성, 요청 패턴 등에 따라 달라진다.

이번 발표는 AI 에이전트가 증가하면서 언어모델 추론 인프라의 설계도 달라지고 있다는 점을 보여준다.

단순히 여러 GPU에 모델을 복제하는 방식에서 나아가 에이전트의 실행 상태와 캐시, 요청 우선순위를 함께 관리하는 구조가 중요해지고 있다.

---

Hugging Face·Google, PyTorch에서 TPU를 직접 사용하는 ‘TorchTPU’ 통합 공개…기존 모델 코드를 크게 변경하지 않고 실행

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: PyTorch, Google TPU, Hugging Face Transformers, Diffusers, AI 모델 학습·추론, 오픈소스
• 원문: Hugging Face — Hugging Face ❤️ TorchTPU: TPUs, Natively

Hugging Face와 Google이 TorchTPU를 이용해 PyTorch 기반 모델을 Google TPU에서 직접 실행하는 개발 환경을 공개했다.

이번 변화의 핵심은 새로운 AI 반도체가 출시됐다는 사실이 아니다.

이미 존재하는 TPU를 일반적인 PyTorch 코드에서 더 쉽게 사용할 수 있도록 소프트웨어 계층을 개선했다는 점이다.

AI 모델 개발에는 PyTorch가 널리 사용된다.

하지만 PyTorch 기반 코드를 다른 종류의 AI 가속기에서 실행하려면 해당 하드웨어를 지원하는 소프트웨어가 필요하다.

Google의 TPU(Tensor Processing Unit)는 신경망의 행렬 계산을 빠르게 수행하도록 설계된 AI 가속기다.

Google은 TPU를 Gemini 등의 모델 학습과 추론에 사용하고 있으며, Google Cloud에서도 제공한다.

문제는 TPU의 소프트웨어 생태계가 오랫동안 TensorFlow와 JAX를 중심으로 발전했다는 점이다.

PyTorch 사용자들은 TPU를 사용하기 위해 PyTorch/XLA라는 별도 통합 계층을 활용해야 했다.

기존 PyTorch/XLA의 실행 방식

PyTorch/XLA는 PyTorch의 연산을 TPU에서 실행할 수 있는 형태로 변환하는 기술이다.

하지만 기존 환경에서는 Lazy Execution(지연 실행)이라는 특성이 중요했다.

일반적인 PyTorch에서는 프로그램이 특정 연산을 실행하면 해당 연산이 비교적 즉시 처리되는 방식으로 동작한다.

반면 지연 실행에서는 여러 연산을 모아두었다가 나중에 함께 실행할 수 있다.

이는 하드웨어 최적화에 유리할 수 있지만 개발자에게는 다른 문제를 만든다.

예를 들어 코드를 한 줄씩 확인하면서 오류를 찾을 때 실제 계산이 예상한 시점과 다르게 실행될 수 있다.

또한 입력의 크기나 프로그램 구조가 조금 바뀌면 새로운 계산 그래프를 컴파일해야 할 수 있다.

이런 차이는 기존 GPU용 PyTorch 코드를 TPU로 이전할 때 추가적인 수정과 디버깅 부담을 만들었다.

TorchTPU는 이를 줄이기 위해 TPU를 PyTorch의 일반적인 장치 백엔드로 제공한다.

개발자는 다른 장치를 선택하듯 "tpu"를 지정할 수 있다.

Transformers와 Diffusers의 직접 지원

Hugging Face는 TorchTPU를 Transformers, Diffusers와 연결했다.

Transformers는 다양한 언어모델과 멀티모달 모델을 불러오고 실행하기 위한 라이브러리다.

Diffusers는 이미지와 영상 생성에 사용되는 확산 모델을 실행하기 위한 라이브러리다.

기존에는 TPU 전용 코드와 설정이 필요했던 일부 작업을 일반적인 Hugging Face 모델 실행 방식과 비슷하게 처리할 수 있게 됐다.

또한 TorchTPU는 Eager Execution(즉시 실행)을 지원한다.

이는 개발자가 PyTorch에서 익숙한 실행·디버깅 방식을 유지할 수 있도록 돕는다.

성능이 중요한 작업에서는 torch.compile을 사용할 수 있다.

torch.compile은 PyTorch 프로그램의 연산을 분석하고 최적화된 실행 코드로 변환하는 기능이다.

개발 과정에서는 이해하기 쉬운 실행 방식을 사용하고, 실제 배포에서는 컴파일을 통해 처리 성능을 높이는 구성이 가능하다.

여러 TPU를 사용하는 분산 학습과 Pallas 기반의 전문 연산 커널도 지원한다.

지원 범위와 성능 검증

Hugging Face는 이번 통합을 위해 TPU에서 실행하는 자동화 테스트를 확대했다.

공개된 자료에 따르면 관련 테스트 가운데 약 96.5%가 통과했다.

하지만 이는 테스트가 정의한 범위에서 얻은 결과다.

모든 PyTorch 연산과 모든 모델이 TPU에서 문제없이 실행된다는 의미는 아니다.

일부 기능에는 아직 개선 작업이 필요하다.

Hugging Face는 전문 커널을 사용한 특정 Qwen 모델의 디코딩 작업에서 기존 구현보다 높은 성능을 기록했다고 설명했다.

그러나 이 결과는 특정 모델과 TPU, 배치 크기에서 측정한 수치다.

모든 모델이 같은 비율로 빨라진다는 의미는 아니다.

이번 발표는 AI 개발자가 특정 회사의 GPU나 TPU에 맞춰 프로그램을 크게 변경해야 하는 부담을 줄이려는 움직임과 연결된다.

같은 PyTorch 기반 모델과 개발 도구를 서로 다른 하드웨어에서 실행할 수 있도록 하는 소프트웨어 호환성이 AI 인프라 경쟁의 중요한 요소가 되고 있다.

---

AWS, Trainium용 네이티브 PyTorch 백엔드 ‘TorchNeuron’ 공개 베타 시작…지원 모델 구조 범위 확대

• 공개 베타 시작일: 2026-10-20
• 관련 공식 발표일: 2026-10-19 — 정확한 게시 시각 미확인
• 적용 범위: AWS Trainium, PyTorch, Hugging Face, AI 모델 학습·추론, 분산 학습, 오픈소스
• 원문: PyTorch — Introducing TorchNeuron: Native PyTorch backend for AWS Trainium
• 관련 원문: Hugging Face — TorchNeuron: running HF models on AWS Trainium is easier than ever

AWS가 자체 AI 가속기인 Trainium에서 일반적인 PyTorch 코드를 실행할 수 있도록 지원하는 TorchNeuron의 공개 베타를 10월 20일 시작했다.

이번 공개 베타는 10월 19일에 사전 소개된 기술의 실제 배포 단계다.

Google의 TorchTPU와 마찬가지로 새로운 AI 모델보다는 개발자가 기존 PyTorch 코드를 특정 하드웨어에서 얼마나 쉽게 실행할 수 있는가라는 문제에 초점을 맞췄다.

AWS Trainium은 AI 모델의 학습과 추론에 사용되는 AWS의 자체 AI 가속기다.

Trainium2와 Trainium3 등 여러 세대의 하드웨어가 존재한다.

기존에는 AWS Neuron SDK와 PyTorch/XLA 기반의 실행 방식을 통해 관련 모델을 운영했다.

하지만 이런 접근에는 추가적인 코드와 실행 설정이 필요할 수 있었다.

TorchNeuron은 이 과정을 단순화한다.

PyTorch에서 일반적인 장치처럼 Trainium 사용

TorchNeuron은 PyTorch에 neuron이라는 장치 백엔드를 추가한다.

백엔드는 특정 하드웨어에서 연산을 실행하도록 연결하는 소프트웨어 계층이다.

개발자는 모델의 일부 연산을 다른 장치로 이동하듯 Trainium으로 전달할 수 있다.

또한 두 가지 실행 방식을 지원한다.

첫 번째는 Eager Execution(즉시 실행)이다.

개발 과정에서 코드를 비교적 직관적으로 실행하고 오류를 확인하는 데 유리하다.

두 번째는 torch.compile 기반 실행이다.

실제 모델을 빠르게 실행하기 위해 여러 연산을 분석하고 최적화된 형태로 컴파일하는 방식이다.

이처럼 개발 단계와 운영 단계에서 서로 다른 실행 방식을 선택할 수 있도록 했다.

여러 AI 가속기를 동시에 사용하는 분산 학습도 지원한다.

여기에는 FSDP(Fully Sharded Data Parallel)와 Tensor Parallelism 같은 기술이 포함된다.

FSDP는 모델의 파라미터와 학습 상태를 여러 장치에 나누어 저장하는 방법이다.

Tensor Parallelism은 하나의 모델 계층에서 수행하는 계산을 여러 장치에 분산하는 방식이다.

Hugging Face 모델과 연결

이번 통합은 Hugging Face 생태계에서도 활용할 수 있다.

지원 대상에는 Transformers와 Diffusers, Accelerate, PEFT, TRL 등이 포함된다.

이들은 각각 모델 실행과 이미지 생성, 분산 학습, 효율적인 추가 학습 등을 지원하는 라이브러리다.

Hugging Face의 자체 조사에 따르면 TorchNeuron은 자주 사용되는 텍스트 생성 모델 구조 상위 100개 가운데 89%를 지원했다.

기존 Optimum Neuron 0.4.5의 지원 비율은 46%였다.

다만 이 수치는 Hugging Face가 정의한 모델 구조 호환성 평가 결과다.

지원된 모델의 전체 학습과 추론 기능이 모든 설정에서 동일하게 작동한다는 의미는 아니다.

실제로 공개된 예제에는 일부 제한이 있다.

예를 들어 자동 동적 입력 크기 처리에는 제약이 있으며, 특정한 가중치 비동기 로딩 기능은 비활성화해야 할 수 있다.

따라서 개발자는 자신이 사용하는 모델과 학습 방식에 맞는 호환성을 확인해야 한다.

TorchNeuron은 Apache 2.0 라이선스의 오픈소스 프로젝트로 공개됐다.

이번 발표는 AI 하드웨어 경쟁에서 GPU나 자체 가속기의 연산 성능만큼 PyTorch 같은 기존 개발 생태계와의 호환성이 중요하다는 사실을 보여준다.

개발자가 이미 사용하는 코드와 도구를 유지하면서 다른 하드웨어로 이전할 수 있어야 새로운 AI 가속기의 도입 장벽도 낮아질 수 있다.

---

Google Research, 저전력 AI 반도체용 ‘Coral NPU’ 설계와 컴파일러 1.0 공개…웨어러블·센서에서 AI 직접 실행

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: 온디바이스 AI, 오픈소스 반도체, RISC-V, 저전력 NPU, 웨어러블, 로봇·산업용 센서
• 원문: Google Developers — Unifying Edge AI: How Coral NPU's open standard brings portable intelligence from model to silicon

Google Research가 저전력 기기에서 AI 모델을 실행하기 위한 Coral NPU의 32비트 아키텍처와 Coral Compiler 1.0을 공개했다.

이번 발표는 하나의 새로운 반도체 제품만 소개한 것이 아니다.

AI 반도체의 설계와 모델 컴파일러를 함께 공개해 서로 다른 제조사의 기기에서도 같은 AI 모델을 실행하기 쉽게 만들려는 시도다.

최근 AI 모델은 스마트폰뿐 아니라 웨어러블과 산업용 센서, 로봇 같은 다양한 기기에서 활용되고 있다.

예를 들어 이어폰이 주변 소음을 분석하거나, 스마트워치가 사용자의 활동을 인식하고, 산업용 카메라가 장비의 이상 상태를 감지할 수 있다.

이런 작업을 모두 클라우드로 전달하면 네트워크 지연과 통신 비용이 발생한다.

또한 민감한 데이터를 외부 서버에 전송해야 할 수도 있다.

반면 기기 내부에서 AI를 실행하면 일부 작업을 더 빠르게 처리하고 개인정보의 외부 전송도 줄일 수 있다.

문제는 작은 기기에서 사용할 수 있는 전력과 메모리가 제한돼 있다는 점이다.

여러 제조사의 AI 반도체가 서로 다른 문제

현재 저전력 AI 반도체 시장에는 여러 종류의 칩이 존재한다.

제조사마다 사용하는 명령어와 컴파일러, 실행 라이브러리가 다를 수 있다.

따라서 개발자가 하나의 AI 모델을 만들더라도 특정 반도체에 맞춰 추가적인 변환과 최적화를 수행해야 할 수 있다.

Google은 이를 Fragmentation(생태계 파편화) 문제로 설명한다.

예를 들어 같은 음성 인식 모델을 여러 제조사의 웨어러블에서 실행하려면 각각 다른 도구를 사용해야 할 수 있다.

모델이 지원하지 않는 연산을 사용하면 해당 부분이 CPU에서 실행될 수도 있다.

그러면 AI 전용 가속기를 탑재했더라도 실제 처리 속도가 느려지거나 전력 사용량이 증가할 수 있다.

Google은 이를 해결하기 위해 공개된 하드웨어 설계와 공통 컴파일러를 함께 제공하는 방식을 선택했다.

RISC-V 기반의 32비트 NPU 구조 완성

Coral NPU는 RISC-V라는 개방형 명령어 구조를 기반으로 한다.

RISC-V는 프로세서가 어떤 명령을 이해하고 실행할지 정의하는 공개 명령어 체계다.

Google은 기존에 Coral NPU의 주요 구성요소를 단계적으로 공개해 왔다.

이번에는 네 번째 단계인 Matrix Execution Unit(행렬 실행 장치)을 공개하면서 32비트 아키텍처의 주요 설계를 완성했다.

신경망의 계산에서는 행렬 곱셈이 자주 사용된다.

예를 들어 이미지 인식 모델이나 Transformer 계열 모델은 많은 숫자로 구성된 행렬을 반복해서 계산한다.

일반적인 CPU나 벡터 처리 장치도 이런 연산을 수행할 수 있지만, 전용 행렬 계산 장치를 사용하면 데이터 이동과 반복 계산의 비용을 줄일 수 있다.

Coral NPU의 Matrix Execution Unit은 한 주기에 256개의 곱셈·누산 연산을 처리하는 구조를 사용한다.

곱셈·누산은 숫자를 곱한 뒤 결과를 더하는 연산으로, 신경망의 행렬 계산에 널리 사용된다.

Google은 이 설계를 최대 1TOPS까지 확장할 수 있다고 설명했다.

TOPS는 초당 수행할 수 있는 연산의 수를 나타내는 지표로, 1TOPS는 초당 1조 회 연산을 의미한다.

또한 Google은 평균 추론 전력을 약 10mW 수준으로 낮추는 것을 목표로 제시했다.

다만 1TOPS와 10mW는 해당 아키텍처의 설계 가능 범위와 목표를 설명하는 수치다.

모든 실제 반도체가 같은 조건에서 두 수치를 동시에 달성한다는 의미는 아니다.

Coral Compiler 1.0도 오픈소스로 공개

반도체 구조만 공개해서는 개발자가 쉽게 사용할 수 없다.

AI 모델을 해당 반도체가 이해하는 명령으로 변환하는 도구도 필요하다.

Google은 이를 위해 Coral Compiler 1.0을 공개했다.

이 컴파일러는 IREE와 MLIR을 기반으로 한다.

MLIR은 프로그램의 계산을 여러 단계의 중간 표현으로 변환하고 최적화하는 컴파일러 기술이다.

IREE는 머신러닝 모델을 다양한 하드웨어에서 실행할 수 있도록 컴파일하는 오픈소스 프로젝트다.

Coral Compiler는 JAX와 PyTorch, TensorFlow로 작성한 모델을 Coral NPU에서 실행할 수 있는 형태로 변환하도록 설계됐다.

이 과정에서는 어떤 연산을 CPU에서 처리하고 어떤 연산을 NPU에서 처리할지 결정한다.

또한 여러 연산을 결합하거나 행렬을 작은 블록으로 나눠 제한된 메모리에 맞게 실행하도록 최적화한다.

Google은 전체 32비트 하드웨어 설계의 RTL(Register-Transfer Level)도 GitHub에 공개했다.

RTL은 반도체 내부의 데이터 이동과 논리 연산을 기술하는 설계 표현 방식이다.

외부 반도체 제조사와 연구기관이 이를 검토하거나 수정해 실제 칩을 설계하는 데 활용할 수 있다.

실제 상용 반도체와 개발 보드 확대

Google은 Synaptics와의 협력 결과도 소개했다.

Synaptics의 새로운 Astra SR200 마이크로컨트롤러 제품군은 Coral NPU 기술을 사용한다.

해당 제품군은 최대 400GOPS 수준의 AI 연산 성능을 목표로 한다.

GOPS는 초당 10억 회의 연산을 의미한다.

웨어러블이나 산업용 센서처럼 배터리와 전력 제약이 큰 기기를 주요 적용 대상으로 한다.

개발자가 실제 하드웨어에서 모델을 실행해 볼 수 있는 Coralboard SR도 발표됐다.

이전에 공개된 Coralboard SL은 글로벌 유통 채널을 통해 제공 범위가 확대됐다.

다만 이번 아키텍처 공개와 새로운 반도체 발표가 모든 제품의 대량 공급과 성능 검증이 완료됐다는 의미는 아니다.

제품별 실제 공급 시점과 지원하는 기능, 전력 사용량은 구체적인 하드웨어 사양을 확인해야 한다.

이번 발표는 AI 모델을 실행하는 기술이 거대한 데이터센터뿐 아니라 매우 적은 전력으로 동작하는 일상적인 기기까지 확대되고 있음을 보여준다.

또한 AI 반도체의 경쟁에서 하드웨어의 연산 성능뿐 아니라 개발자가 모델을 쉽게 이전하고 실행할 수 있는 개방형 소프트웨어 환경이 중요한 역할을 한다는 점을 드러낸다.

---

4️⃣ 산업·정책·안전

Microsoft, AI 데이터 주권 통제 기능 확대…외부 암호화 키 관리 정식 제공하고 로컬 Copilot·Foundry 운영 계획 공개

• 발표일: 2026-10-20 — 정확한 게시 시각 미확인
• 적용 범위: 기업용 AI 보안, 클라우드 주권, Microsoft Azure, 로컬 AI, GitHub Copilot, 데이터 암호화, 규제 산업
• 원문: Microsoft — Advancing digital sovereignty with greater control and choice

Microsoft가 정부와 금융, 주요 인프라 기업을 위한 디지털 주권(Digital Sovereignty) 기술을 확대한다고 발표했다.

이번 발표는 새로운 AI 모델을 출시한 것이 아니다.

기업이 AI 모델과 데이터를 어디에서 실행하고, 누가 시스템에 접근하며, 외부 네트워크가 중단돼도 업무를 계속할 수 있는지를 관리하는 기술에 초점을 맞췄다.

디지털 주권은 단순히 데이터를 특정 국가의 데이터센터에 저장하는 것보다 넓은 개념이다.

예를 들어 어떤 기업이 데이터를 국내에 저장하더라도 외부 서비스 제공업체의 직원이 해당 데이터를 관리할 수 있다면 운영 통제권에는 별도의 문제가 남을 수 있다.

또한 데이터가 국내에 저장돼 있더라도 외부 네트워크 연결이 끊기면 중요한 AI 서비스를 실행하지 못할 수 있다.

따라서 데이터의 저장 위치뿐 아니라 접근권한과 암호화 키, 실제 운영 주체와 서비스 지속 가능성을 함께 고려해야 한다는 것이 Microsoft의 설명이다.

고객이 보유한 암호화 키를 외부에서 관리

이번 발표에서 정식 제공으로 전환된 기능 가운데 하나는 Azure Managed HSM의 외부 키 관리다.

HSM(Hardware Security Module)은 암호화 키를 안전하게 보관하고 암호화 관련 연산을 수행하는 전용 보안 장치다.

암호화 키는 보호된 데이터를 복호화할 수 있는 권한과 연결된다.

일반적인 클라우드 서비스에서는 고객이 클라우드 사업자의 암호화 키 관리 기능을 사용한다.

하지만 일부 금융기관이나 정부기관은 중요한 암호화 키를 클라우드 사업자의 인프라 밖에서 직접 관리해야 할 수 있다.

Microsoft는 이번 변경으로 고객이 자신이 소유하거나 신뢰하는 외부 기관이 운영하는 하드웨어에 루트 암호화 키를 보관할 수 있다고 설명했다.

이는 클라우드에서 처리하는 모든 데이터가 자동으로 외부에 노출되지 않는다는 의미와는 다르다.

암호화 키의 위치와 통제권을 고객이 더 명확하게 관리할 수 있다는 의미다.

이번 기능은 GA(General Availability, 정식 제공) 상태다.

유럽 지역의 시스템 접근 기록 강화

Microsoft는 EU와 EFTA 지역의 고객을 위한 운영 접근 통제 기능도 확대하고 있다.

Data Guardian은 특정 생산 시스템에 Microsoft 엔지니어가 원격으로 접근하는 상황에서 유럽 거주 인력의 감독을 추가하는 기능이다.

Production Touch Ledger는 시스템 접근과 수행한 행동에 대해 사후 변경을 탐지할 수 있는 기록을 제공한다.

이를 Tamper-Evident Log(변조 감지 가능 로그)라고 한다.

일반적인 로그와 달리 기록이 나중에 수정되거나 삭제됐는지 확인할 수 있도록 설계된 것이다.

이런 기능은 시스템 장애와 보안 사고가 발생했을 때 누가 어떤 작업을 수행했는지 추적하는 데 유용하다.

다만 이 기능들은 지역과 적용 대상에 제한이 있으며 단계적으로 배포되고 있다.

EU의 모든 Azure 시스템에 동일한 수준으로 즉시 적용됐다고 볼 수는 없다.

AI를 외부 클라우드 연결 없이 실행

Microsoft는 자체 시설에서 클라우드 기능을 운영하는 Azure Local도 확대할 계획이다.

여기서 중요한 개념은 Disconnected Operation(네트워크 분리 환경에서의 운영)이다.

기업이 외부 인터넷이나 클라우드 서비스에 연결하지 않은 상태에서도 중요한 프로그램과 일부 AI 기능을 사용할 수 있도록 하는 것이다.

예를 들어 주요 국가 기반시설을 운영하는 기관은 외부 네트워크가 중단돼도 필수 시스템을 유지해야 할 수 있다.

AI가 이런 시스템에 사용된다면 모델의 추론과 데이터 접근이 내부 환경에서 계속 작동해야 할 수 있다.

Microsoft는 이를 위해 Foundry Local을 활용할 계획이다.

Foundry Local은 모델을 사용자의 로컬 환경에서 실행하도록 지원하는 기술이다.

기존에는 클라우드 API를 호출해야 했던 일부 AI 작업을 고객이 직접 운영하는 인프라에서 처리할 수 있도록 하는 방향이다.

또한 GitHub Enterprise Local을 통해 코드 저장소와 개발 산출물을 내부 환경에서 운영하는 방안도 제시했다.

GitHub Copilot이 로컬에서 실행되는 모델을 활용하도록 구성할 수도 있다.

이런 구조는 민감한 코드와 내부 데이터를 외부 모델 제공업체에 전송하기 어려운 조직에 유용할 수 있다.

하지만 중요한 구분이 있다.

GitHub Enterprise Local과 Foundry Local의 해당 Azure Local 통합 기능은 10월 20일에 모두 정식 제공된 것이 아니다.

Microsoft는 향후 열리는 Microsoft Ignite에서 일부 기능을 GA로 전환할 예정이라고 설명했다.

또한 Azure Local의 DocumentDB와 Blob Storage 관련 기능 일부는 프리뷰 단계다.

따라서 현재 사용할 수 있는 기능과 앞으로 제공될 기능을 구분해야 한다.

데이터 주권과 AI 제품 선택의 관계

이번 발표는 기업이 AI 모델을 선택할 때 고려하는 기준이 달라지고 있다는 점을 보여준다.

일반적인 AI 모델 비교에서는 정확도와 처리 속도, 토큰 비용이 중요한 기준으로 사용된다.

하지만 공공기관이나 규제 산업에서는 추가적인 요구사항이 존재한다.

예를 들어 모델이 어떤 국가에서 실행되는지, 암호화 키를 누가 관리하는지, 외부 서비스 제공업체의 관리자가 어떤 접근권한을 가지는지 확인해야 할 수 있다.

또한 외부 네트워크 장애가 발생해도 서비스를 계속 운영할 수 있어야 할 수 있다.

Microsoft는 이런 요구사항을 충족하도록 공용 클라우드와 고객 운영 환경, 지역별 파트너 서비스를 조합하는 방향을 제시했다.

이번 변화는 AI 모델의 성능 경쟁과 별개로 기업이 AI를 신뢰하고 운영할 수 있도록 만드는 보안·운영 기술의 경쟁도 확대되고 있음을 보여준다.

---

📚 추천 글

ALTK-Evolve: How learned memory tops the τ²-bench leaderboard on customer service tasks without a frontier model

• 저자: Ashwath Vaithinathan Aravindan, Vatche Isahagian, Vinod Muthusamy 외 IBM Research 연구진
• 발행: IBM Research / Hugging Face
• 게시일: 2026-10-20
• 원문: IBM Research — ALTK-Evolve: How learned memory tops the τ²-bench leaderboard

AI 에이전트의 성능을 높이려면 반드시 더 강력한 모델을 사용하거나 모델의 가중치를 추가 학습해야 할까?

IBM Research는 이번 연구에서 다른 방법을 제시한다.

기존 에이전트가 과거 작업에서 무엇을 잘했고 무엇을 실패했는지 분석한 뒤, 그 경험을 다음 작업에서 사용할 수 있는 지침으로 저장하는 것이다.

연구팀은 이를 ALTK-Evolve라고 부른다.

이번 연구가 흥미로운 이유는 최신 프런티어 모델이 아니라 기존의 GPT-4.1을 사용했다는 점이다.

연구팀은 GPT-4.1 기반의 기본 고객지원 에이전트에 과거 실행에서 추출한 지침을 추가하는 것만으로 복잡한 고객지원 평가의 성공률을 높였다.

모델의 파라미터를 추가 학습하거나 사람이 모든 지침을 직접 작성할 필요는 없었다.

고객지원 에이전트의 실제 성공 여부를 어떻게 평가할까?

연구팀은 τ²-bench라는 고객지원 에이전트 벤치마크를 사용했다.

이 벤치마크에는 소매업과 항공사 고객지원 업무가 포함된다.

예를 들어 고객이 주문을 취소하거나 상품을 반품하려고 할 수 있다.

다른 고객은 항공편을 변경하거나 예약 정보를 수정하려 할 수 있다.

에이전트는 고객의 요청을 이해한 뒤 해당 회사의 정책을 확인하고 적절한 도구를 실행해야 한다.

예를 들어 환불을 처리하기 전에 사용자의 신원을 확인해야 할 수 있다.

또한 실제 데이터베이스에 변경사항을 적용하기 전에 고객의 승인을 받아야 할 수 있다.

여기서 중요한 것은 최종 답변의 표현이 자연스러운지보다 실제로 올바른 업무 처리가 완료됐는지다.

τ²-bench는 에이전트가 수행한 도구 실행의 최종 결과를 확인한다.

예를 들어 반품 요청에서 환불 대상과 금액이 올바르게 처리됐는지 검사한다.

이를 Final State Evaluation(최종 상태 평가)이라고 한다.

모델이 환불을 완료했다고 답변했더라도 데이터베이스의 실제 상태가 잘못됐다면 실패로 판단할 수 있다.

성공과 실패 기록에서 행동 규칙 추출

ALTK-Evolve는 에이전트가 이전 작업을 수행하면서 남긴 Trajectory(실행 궤적)를 분석한다.

Trajectory는 하나의 작업을 해결하기 위해 모델이 생성한 답변과 도구 호출, 중간 결과를 순서대로 기록한 자료다.

연구팀은 GPT-4.1을 이용해 이런 실행 기록에서 유용한 행동 규칙을 추출했다.

예를 들어 과거의 성공 사례에서 다음과 같은 규칙을 얻을 수 있다.

고객의 주문을 변경하기 전에 신원을 확인해야 한다.

데이터베이스를 수정하기 전에 변경 내용을 고객에게 정리해 보여주고 명시적인 승인을 받아야 한다.

반품이나 교환을 처리할 때는 환불 금액과 예상 환불 시점을 함께 설명해야 한다.

도구를 호출한 뒤에는 실제 결과를 확인하고 다음 행동을 결정해야 한다.

이러한 규칙은 특정 고객 한 명에 대한 정보가 아니라 다른 고객지원 대화에서도 재사용할 수 있는 일반적인 절차다.

연구팀은 이를 Markdown 형식의 지침으로 정리해 에이전트의 시스템 프롬프트에 추가했다.

System Prompt(시스템 프롬프트)는 모델이 작업을 수행할 때 따라야 하는 기본 지침이다.

이렇게 하면 모델의 가중치를 변경하지 않아도 다음 작업에서 과거의 경험을 활용할 수 있다.

많은 지침이 항상 좋은 것은 아니다

연구팀은 저장할 지침의 수가 성능에 어떤 영향을 주는지도 평가했다.

먼저 아무런 추가 지침을 사용하지 않는 기본 모델을 평가했다.

이후 여러 실행에서 반복해서 유용했던 지침만 남기는 방식을 시험했다.

마지막으로 정리된 지침을 가능한 한 많이 유지하는 방식도 비교했다.

소매업 분야에서는 모든 지침을 유지하는 방식이 가장 높은 성능을 기록했다.

반면 항공사 업무에서는 일부 핵심 지침만 유지하는 방식이 반복 실행의 안정성 측면에서 더 좋았다.

이 차이는 중요한 의미를 가진다.

지침이 많아지면 더 다양한 상황에 대응할 수 있지만, 일부 지침이 서로 충돌하거나 현재 작업과 관련 없는 정보가 모델의 판단에 영향을 줄 수 있기 때문이다.

즉 에이전트의 기억은 무조건 많이 저장하는 것보다 어떤 정보를 유지하고 언제 사용하는지 결정하는 과정이 중요하다.

평균 성공률과 반복 성공률을 구분

이번 연구에서는 두 가지 평가 지표를 사용했다.

첫 번째는 평균 성공률이다.

같은 작업을 여러 번 실행했을 때 평균적으로 얼마나 자주 성공하는지를 측정한다.

두 번째는 Pass^4다.

Pass^4는 같은 작업을 네 번 독립적으로 실행했을 때 네 번 모두 성공한 작업의 비율을 의미한다.

예를 들어 어떤 작업의 평균 성공률이 75%라고 해도 네 번의 실행에서 모두 성공할 가능성은 훨씬 낮을 수 있다.

실제 고객지원에서는 같은 유형의 요청을 어떤 고객에게는 올바르게 처리하고 다른 고객에게는 잘못 처리하는 상황이 문제가 될 수 있다.

따라서 단순한 평균 성공률뿐 아니라 반복해서 실행해도 안정적으로 성공하는가가 중요하다.

IBM이 공개한 소매업 평가 결과는 다음과 같다.

전체 지침을 사용한 경우 평균 성공률은 4.4%포인트, Pass^4는 10%포인트 개선됐다.

항공사 업무에서도 평균 성공률이 개선됐다.

다만 항공사 평가에서는 전체 지침보다 핵심 지침만 사용한 구성이 반복 성공률 측면에서 더 높은 결과를 기록했다.

이 수치는 IBM Research가 수행한 자체 평가 결과다.

소매업의 평가 작업은 40개, 항공사 업무는 20개로 비교적 제한적이었다.

따라서 모든 고객지원 업무에서 같은 수준의 개선이 나타난다는 의미는 아니다.

또한 비교에 사용된 리더보드 순위는 2026년 10월 12일 시점의 기록을 기준으로 한다.

이번 발표 당시의 모든 최신 모델과 직접 비교한 실시간 순위라고 해석해서는 안 된다.

모델을 다시 학습시키지 않고도 개선할 수 있다

이번 연구가 보여주는 가장 중요한 방향은 모델의 가중치와 에이전트가 축적하는 업무 경험을 분리하는 것이다.

전통적인 머신러닝에서는 성능을 개선하기 위해 모델을 다시 학습시키는 경우가 많았다.

하지만 실제 기업 업무에서는 특정한 실수 하나를 수정하기 위해 모델 전체를 다시 학습시키는 것이 비효율적일 수 있다.

예를 들어 환불 절차에서 사용자 승인을 빠뜨리는 문제가 발견됐다면, 해당 오류에서 일반화할 수 있는 지침을 추출해 다음 요청에 활용하도록 만드는 방법이 있다.

이런 접근은 모델이 기본적으로 가진 문제 해결 능력을 유지하면서 업무 절차와 실행 경험을 외부 기억으로 축적하는 방식이다.

다만 저장된 지침이 항상 올바르거나 영구적으로 유효하다는 보장은 없다.

기업의 정책이 변경되면 과거에 유용했던 지침이 잘못된 행동을 유도할 수도 있다.

따라서 실제 운영 환경에서는 지침의 버전 관리와 유효성 검증이 필요하다.

이번 글은 AI 에이전트의 성능을 개선하는 방법이 더 큰 모델이나 추가 학습에만 있는 것이 아니라 과거의 실행 기록을 분석하고 검증된 행동 규칙으로 축적하는 시스템 설계에도 있다는 점을 보여준다.

---

MPS in PyTorch 2.15

• 저자: Irakli Salia, Khushi Agrawal
• 발행: Hugging Face / PyTorch
• 게시일: 2026-10-20
• 원문: Hugging Face — MPS in PyTorch 2.15

Mac에서 AI 모델을 직접 실행할 때 성능이 느리거나 메모리가 부족한 문제를 경험할 수 있다.

그런데 이 문제가 반드시 GPU의 계산 성능이 부족하기 때문에 발생하는 것은 아니다.

같은 하드웨어에서도 AI 모델을 실행하는 소프트웨어의 구현 방식에 따라 처리 속도와 메모리 사용량이 크게 달라질 수 있다.

이 글은 Hugging Face의 PyTorch 개발팀이 Apple Silicon의 GPU 실행 환경을 개선한 과정을 설명한다.

특히 PyTorch 2.15에 반영되는 여러 변경사항을 실제 모델과 성능 수치로 비교한다.

Apple Silicon과 PyTorch의 관계

Apple Silicon은 Apple이 Mac과 일부 다른 기기에 사용하는 프로세서 계열이다.

여기에는 CPU와 GPU가 통합된 형태로 제공된다.

일반적인 NVIDIA GPU에서는 AI 모델을 실행하기 위해 CUDA를 많이 사용한다.

반면 Apple GPU에서는 Metal이라는 그래픽·계산 기술을 사용한다.

PyTorch는 이를 지원하기 위해 MPS(Metal Performance Shaders)라는 실행 백엔드를 제공한다.

백엔드는 프로그램이 작성한 연산을 특정 하드웨어에서 실행하도록 연결하는 소프트웨어 계층이다.

문제는 PyTorch가 지원하는 모든 연산이 Apple GPU에서 최적화된 방식으로 실행되는 것은 아니라는 점이다.

일부 연산은 CPU로 이동하거나, 메모리를 불필요하게 많이 사용하거나, 일반적인 GPU 실행 방식보다 느리게 동작할 수 있다.

Hugging Face 개발팀은 실제 언어모델과 이미지·영상 생성 모델을 반복해서 실행하면서 이런 문제를 분석했다.

같은 MoE 모델의 토큰 생성 속도 5~6.5배 개선

이번 변경 가운데 눈에 띄는 결과는 MoE(Mixture of Experts) 모델의 추론 속도 개선이다.

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

이 구조에서는 어떤 전문가 네트워크를 사용할지 결정하고, 선택된 전문가에게 계산을 분배하는 작업이 필요하다.

이런 과정은 일반적인 Dense 모델보다 복잡할 수 있다.

Hugging Face는 Apple GPU에 맞춘 새로운 행렬 계산과 전문가 선택 연산을 구현했다.

특히 Grouped Matrix Multiplication(그룹화된 행렬 곱셈)을 최적화했다.

Grouped Matrix Multiplication은 서로 다른 크기의 여러 행렬 계산을 묶어 효율적으로 실행하는 기술이다.

기존에는 여러 전문가의 연산을 처리하는 과정에서 불필요한 GPU와 CPU 사이의 동기화가 발생할 수 있었다.

동기화는 서로 다른 계산 장치가 작업의 완료를 기다리거나 실행 순서를 맞추는 과정이다.

이런 대기 시간이 줄어들면 모델이 다음 토큰을 생성하는 속도가 높아질 수 있다.

Hugging Face가 공개한 자체 평가에서 Qwen3.6-35B-A3B 모델은 M3 Ultra 환경에서 다음과 같은 결과를 기록했다.

약 6.5배 개선된 결과다.

다른 MoE 모델인 LFM2.5-8B-A1B도 초당 23.6토큰에서 123.6토큰으로 개선됐다.

다만 이 수치는 특정 모델과 M3 Ultra, torch.compile 설정에서 측정한 결과다.

모든 Mac이나 AI 모델에서 동일한 성능 향상이 나타난다는 의미는 아니다.

FP8 지원으로 메모리 사용량 감소

PyTorch 2.15에는 Apple GPU에서 사용하는 FP8 관련 지원도 확대된다.

FP8은 숫자를 8비트 부동소수점 형식으로 표현하는 방식이다.

AI 모델에서는 일반적으로 BF16이나 FP16 같은 16비트 형식을 사용하기도 한다.

FP8은 이런 형식보다 숫자 하나를 저장하는 데 필요한 공간이 적다.

따라서 같은 크기의 데이터를 저장할 때 필요한 메모리를 줄일 수 있다.

하지만 표현할 수 있는 숫자의 정밀도가 낮아지는 문제가 있다.

따라서 모델이 실제로 필요한 정확도를 유지할 수 있는지 확인해야 한다.

Hugging Face는 이번 변경을 통해 FP8 데이터와 관련 행렬 연산을 Apple GPU에서 더 폭넓게 사용할 수 있도록 했다고 설명한다.

이런 변화는 메모리가 제한된 개인용 컴퓨터에서 상대적으로 큰 모델을 실행할 때 유용할 수 있다.

영상 생성에서 메모리 270GiB에서 8GiB로 감소

이번 글에서 특히 인상적인 부분은 영상 생성 모델의 메모리 사용량 개선이다.

Hugging Face는 Wan2.2 모델의 영상 디코딩 과정을 분석했다.

영상 생성 모델에서는 압축된 내부 표현을 실제 영상 프레임으로 변환하는 과정이 필요하다.

이때 사용되는 구성요소 가운데 하나가 VAE(Variational Autoencoder)다.

VAE는 데이터를 더 작은 내부 표현으로 압축하거나, 압축된 표현을 다시 이미지와 영상으로 복원하는 데 사용되는 모델이다.

기존 구현에서는 특정한 영상 디코딩 작업의 최대 메모리 사용량이 약 270GiB에 달했다.

Hugging Face는 관련 GPU 연산과 메모리 사용 방식을 수정한 뒤 이를 약 8GiB로 줄였다고 밝혔다.

이 수치는 전체 영상 생성 모델이 8GiB 메모리만 사용한다는 뜻이 아니다.

특정 VAE 디코딩 단계의 최대 메모리 사용량을 비교한 결과다.

그럼에도 이런 최적화는 기존에는 메모리 부족으로 실행하기 어려웠던 일부 작업을 가능하게 만들 수 있다.

이미지 편집의 정확도 문제도 수정

성능뿐 아니라 정확성 문제도 다뤘다.

Hugging Face는 Qwen-Image-2.1의 이미지 인코딩 과정에서 Apple GPU가 잘못된 결과를 생성하는 문제를 발견했다.

이 문제는 프로그램이 명확한 오류를 반환하지 않더라도 실제 이미지가 손상될 수 있다는 점에서 중요하다.

이를 Silent Corruption(조용한 데이터 손상)이라고 한다.

프로그램이 정상적으로 실행되는 것처럼 보이지만 결과 데이터가 잘못되는 현상이다.

개발팀은 이미지의 경계 부분을 처리하는 Padding 연산을 수정했다.

Padding(패딩)은 이미지나 행렬의 주변에 추가적인 값을 배치해 계산 조건을 맞추는 방법이다.

수정 이후 이미지 인코딩과 디코딩 결과가 CPU 실행 결과와 더 가깝게 일치하도록 개선됐다.

이번 글은 AI 모델을 실행할 때 단순한 처리 속도뿐 아니라 같은 계산이 하드웨어마다 올바르게 수행되는지 확인하는 과정도 중요하다는 점을 보여준다.

또한 모델 자체를 다시 학습시키지 않더라도 일반적인 소프트웨어 최적화와 GPU 커널 개선만으로 성능이 크게 달라질 수 있다는 사실을 잘 설명한다.

---

AnyLanguageModel 1.0: One Year of Local Models on Apple Platforms

• 저자: Mattt
• 발행: Hugging Face Community
• 게시일: 2026-10-20
• 원문: Hugging Face — AnyLanguageModel 1.0: One Year of Local Models on Apple Platforms

애플리케이션에 AI 기능을 추가할 때 가장 먼저 결정해야 하는 것 가운데 하나는 어떤 모델을 어디에서 실행할 것인가이다.

예를 들어 간단한 텍스트 분류나 개인적인 메모 분석은 사용자의 기기에서 직접 처리할 수 있다.

반면 복잡한 추론이나 대규모 문서 분석에는 외부 클라우드의 강력한 모델이 필요할 수 있다.

문제는 모델을 어디에서 실행하는지에 따라 개발에 사용하는 API와 도구가 달라지는 경우가 많다는 것이다.

이 글은 Apple 플랫폼의 Swift 개발자가 로컬 모델과 클라우드 모델을 하나의 공통된 인터페이스로 사용할 수 있도록 하는 AnyLanguageModel 1.0을 소개한다.

모델을 교체하려면 애플리케이션 코드도 변경해야 할까?

일반적으로 Apple 플랫폼에서 기기 내부 AI 기능을 사용하려면 Foundation Models 프레임워크를 활용할 수 있다.

Framework(프레임워크)는 특정 기능을 개발할 때 필요한 API와 기본 구조를 제공하는 소프트웨어다.

Foundation Models는 Apple의 AI 기능을 앱에서 사용할 수 있도록 하는 개발 환경이다.

하지만 외부 모델 제공업체의 API를 사용하려면 다른 방식으로 코드를 작성해야 할 수 있다.

예를 들어 Apple의 온디바이스 모델을 사용하는 코드와 OpenAI 또는 Anthropic의 클라우드 모델을 호출하는 코드는 서로 다른 인터페이스를 사용할 수 있다.

이렇게 되면 모델을 변경할 때마다 응답 처리와 도구 호출, 구조화된 출력에 관한 코드를 수정해야 할 수 있다.

AnyLanguageModel은 이 문제를 해결하려는 프로젝트다.

핵심 아이디어는 Apple Foundation Models의 인터페이스를 유지하면서 실제 실행 모델을 교체할 수 있도록 만드는 것이다.

개발자는 애플리케이션에서 사용하는 주요 세션 코드를 크게 변경하지 않고 모델 제공업체를 선택할 수 있다.

로컬 모델과 클라우드 모델 지원

AnyLanguageModel 1.0은 여러 모델 실행 환경을 지원한다.

로컬에서는 Apple의 기본 모델과 llama.cpp, MLX, Core ML 기반 모델을 사용할 수 있다.

llama.cpp는 다양한 언어모델을 CPU와 GPU에서 실행할 수 있도록 하는 오픈소스 프로젝트다.

MLX는 Apple Silicon에서 머신러닝 모델을 효율적으로 실행하기 위한 프레임워크다.

Core ML은 Apple 기기에서 머신러닝 모델을 실행하도록 지원하는 기술이다.

클라우드에서는 OpenAI의 API와 Anthropic의 Messages API, Google Gemini API, Hugging Face Inference Providers 등을 사용할 수 있다.

또한 Ollama와 Open Responses, OpenAI 호환 API 엔드포인트도 지원한다.

이렇게 하면 하나의 앱에서 작은 모델은 기기 내부에서 실행하고, 복잡한 작업은 외부 모델에 전달하는 구조를 만들 수 있다.

예를 들어 간단한 문장 분류는 로컬 모델이 처리하고, 긴 보고서의 복잡한 분석은 클라우드 모델에 맡길 수 있다.

다만 로컬 모델과 클라우드 모델이 같은 API를 사용한다고 해서 답변 품질이나 사용 가능한 기능까지 완전히 같아지는 것은 아니다.

실제 모델의 능력은 각각 다를 수 있다.

도구 호출과 구조화된 출력도 공통으로 제공

AnyLanguageModel은 단순한 텍스트 생성뿐 아니라 Tool Calling(도구 호출)도 지원한다.

도구 호출은 언어모델이 외부 함수나 API를 선택해 실행하도록 요청하는 기능이다.

예를 들어 사용자가 일정에 관한 질문을 했을 때 모델이 캘린더 정보를 조회하는 도구를 사용할 수 있다.

또한 Guided Generation(형식 제약이 있는 생성)을 지원한다.

이는 모델이 정해진 데이터 구조에 맞춰 결과를 반환하도록 하는 기술이다.

예를 들어 사용자 프로필을 생성하는 기능에서 이름과 나이, 관심사 등의 필드를 갖춘 데이터 구조를 반환하도록 지정할 수 있다.

프로젝트는 이런 기능을 로컬 모델과 여러 클라우드 제공업체에서 비슷한 방식으로 사용하도록 설계됐다.

1.0 버전에는 이미지 입력을 처리하는 기능도 포함됐다.

따라서 이미지와 텍스트를 함께 이해할 수 있는 모델을 앱에 연결할 수 있다.

하지만 실제 이미지 지원 여부는 선택한 모델의 능력과 실행 환경에 따라 달라진다.

인증정보 처리와 개인정보 보호

로컬 AI의 장점 가운데 하나는 일부 데이터를 외부 서버에 보내지 않고 처리할 수 있다는 점이다.

예를 들어 개인적인 일기나 내부 문서를 기기 안에서 분석하는 작업에는 이런 방식이 유용할 수 있다.

하지만 모든 작업을 로컬에서 실행할 수 있는 것은 아니다.

큰 모델을 실행하기에는 기기의 메모리나 계산 성능이 부족할 수 있기 때문이다.

그래서 실제 앱에서는 클라우드 모델을 함께 사용하는 경우가 생긴다.

AnyLanguageModel은 이런 상황에서 API 키를 관리하는 방법도 개선했다.

개발자는 클라우드 모델의 인증정보를 앱 안에 고정된 문자열로 저장하는 대신, 필요할 때 안전한 서버에서 단기 인증정보를 받아오는 구조를 사용할 수 있다.

이는 중요한 보안 문제와 연결된다.

모바일 앱이나 데스크톱 앱에 비밀 API 키를 직접 포함하면 프로그램을 분석하는 사용자가 해당 키를 추출할 가능성이 있다.

따라서 외부 모델을 사용하는 실제 서비스에서는 인증정보를 보호하는 별도의 서버와 권한 관리 구조가 필요할 수 있다.

Swift용 모델 배포 생태계도 함께 개선

AnyLanguageModel 1.0과 함께 swift-huggingface 1.0과 swift-xet 1.0도 공개됐다.

이들은 Swift 애플리케이션에서 Hugging Face의 모델 파일을 가져오고 관리하는 데 활용된다.

모델을 앱에 연결할 때는 실제 모델의 가중치를 다운로드해야 할 수 있다.

Model Weight(모델 가중치)는 모델이 학습하면서 조정한 숫자 데이터다.

모델의 크기가 커지면 가중치 파일도 수GB에서 수십GB 이상이 될 수 있다.

따라서 파일을 안정적으로 다운로드하고 버전을 관리하는 기능이 중요하다.

이번 1.0 버전은 이런 모델 배포 환경까지 함께 개선했다는 점에서 의미가 있다.

이 글은 생성형 AI를 앱에 통합할 때 특정 모델 하나에 강하게 의존하는 구조보다 모델을 교체할 수 있는 추상화 계층을 만드는 방식이 유용할 수 있다는 관점을 제공한다.

특히 Apple 플랫폼에서 AI 기능을 개발하거나 온디바이스 AI와 클라우드 AI를 함께 사용하는 서비스를 설계하려는 개발자에게 참고할 만한 기술 자료다.