AI 데일리 브리핑 — 2026-10-15
Soshy··조회수 —

기준 시점: 2026-10-15 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-14 06:00 ~ 2026-10-15 06:00 KST
추천 글 범위: 2026-10-08 06:00 ~ 2026-10-15 06:00 KST
1️⃣ 주요 모델·연구
Ai2, 전 세계 극한기상 현상을 3km 해상도로 시뮬레이션하는 ‘HiRO-ACEv2’ 공개…기존 고해상도 기후 모델 대비 비용 약 300분의 1
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: AI for Science, 기후 모델링, 극한기상 연구, 태풍·허리케인, 재난 위험 분석, 오픈소스 AI
- 원문: Allen Institute for AI — HiRO-ACEv2: Simulating extreme weather at 3 km resolution for a fraction of the cost
미국의 비영리 AI 연구기관 Allen Institute for AI(Ai2)가 전 세계의 기후와 극한기상 현상을 매우 높은 해상도로 시뮬레이션하는 새로운 모델 HiRO-ACEv2를 공개했다.
이번 연구는 AI를 이용해 내일의 날씨를 예보하는 것보다 더 근본적인 문제를 다룬다.
앞으로 수십 년 동안 발생할 수 있는 수많은 기상 상황을 컴퓨터로 만들어내고, 그 가운데 매우 드물게 발생하는 극단적인 현상을 분석하는 것이다.
예를 들어 특정 지역에 기록적인 폭우가 발생할 가능성을 연구하려면 실제로 발생한 폭우 기록만으로는 충분하지 않을 수 있다.
100년에 한 번 발생할 정도로 드문 사건은 관측 사례 자체가 적기 때문이다.
따라서 기후 연구자들은 대기와 해양의 물리법칙을 이용해 오랜 기간의 가상 기후를 시뮬레이션하고, 실제 관측에서는 충분히 확보하기 어려운 극단적인 상황을 연구한다.
문제는 이런 시뮬레이션에 엄청난 계산 자원이 필요하다는 점이다.
100km에서 3km로, 기후 모델의 해상도를 높이는 방법
전통적인 기후 모델은 지구를 수많은 격자로 나누고 각 위치의 온도, 압력, 바람과 강수량을 계산한다.
격자 하나의 크기가 작아질수록 더 세밀한 현상을 표현할 수 있다.
예를 들어 100km 크기의 격자에서는 넓은 지역의 기압과 바람 변화를 파악할 수 있지만, 좁은 지역에 집중되는 폭우나 산악 지형에서 발생하는 바람을 정확하게 표현하기 어렵다.
반면 3km 크기의 격자를 사용하면 허리케인 내부 구조나 지역적인 폭우처럼 훨씬 작은 규모의 현상을 분석할 수 있다.
그러나 격자 크기를 줄이면 계산해야 하는 공간과 시간이 크게 증가한다.
Ai2는 이 문제를 해결하기 위해 두 모델을 연결했다.
첫 번째는 ACE다.
ACE는 전 세계 기후를 약 100km 해상도로 시뮬레이션하는 AI 모델이다.
두 번째는 HiRO다.
HiRO는 ACE가 생성한 거친 해상도의 기후 데이터를 입력받아 약 3km 해상도의 세밀한 데이터로 변환한다.
이 과정을 Downscaling(다운스케일링)이라고 한다.
Downscaling은 넓은 지역을 거칠게 표현한 기후 정보를 더 작은 지역 단위의 세밀한 정보로 변환하는 기술이다.
이번에 공개된 HiRO-ACEv2의 핵심은 다운스케일링을 담당하는 HiROv2의 개선이다.
기존 HiRO는 주로 강수량을 세밀하게 생성했다.
새로운 HiROv2는 강수량뿐 아니라 바람과 해면기압까지 동시에 생성하도록 확장됐다.
따라서 폭우뿐 아니라 강풍, 저기압과 열대성 폭풍의 구조까지 함께 분석할 수 있게 됐다.
백만 개 중 하나 수준의 극단적인 기상 현상까지 비교
Ai2는 모델의 성능을 확인하기 위해 X-SHiELD라는 고해상도 대기 시뮬레이션 모델을 사용했다.
X-SHiELD는 대기의 물리적 현상을 직접 계산해 폭풍과 작은 규모의 기상 구조를 시뮬레이션하는 시스템이다.
연구팀은 X-SHiELD가 만든 데이터를 낮은 해상도로 변환한 뒤, HiROv2가 이를 얼마나 정확하게 복원하는지 평가했다.
그 결과 HiROv2는 강수량, 바람과 기압의 고해상도 통계적 특성을 잘 재현했다.
특히 데이터 백만 개 가운데 하나 정도로 드물게 나타나는 극단적인 값에서도 기준 시뮬레이션과의 통계적 차이가 약 3% 이내였다고 연구팀은 설명한다.
다만 여기서 중요한 구분이 있다.
3%라는 수치는 실제 관측된 모든 극한기상 현상에 대한 예측 오차가 아니다.
AI 모델이 고해상도 물리 시뮬레이션의 통계적 특성을 얼마나 잘 재현했는지를 나타내는 결과다.
연구팀은 허리케인도 평가했다.
HiRO-ACEv2는 태풍의 눈과 주변 강수대 같은 구조를 생성할 수 있었고, 장기간 시뮬레이션에서 발생한 열대성 폭풍의 전체 에너지 분포도 X-SHiELD와 비슷하게 나타났다.
학습 중 직접 보지 못했던 일부 태풍의 특성도 재현했다.
다만 허리케인의 눈 주변에서 나타나는 바람과 기압 분포는 기준 시뮬레이션보다 다소 비대칭적인 경우가 있었다.
즉 극한기상 현상의 전체적인 분포를 잘 재현하더라도 개별 폭풍의 세부적인 물리 구조까지 완벽하게 재현하는 것은 아니다.
비용은 줄였지만 현재 기후 조건에 제한
Ai2는 HiRO-ACEv2를 이용해 전 세계의 3km 해상도 기후 데이터를 1년 분량으로 생성했다.
연구팀의 자체 계산에 따르면 이 작업에 필요한 비용은 X-SHiELD를 직접 실행하는 경우의 약 300분의 1이었다.
이러한 비용 차이는 매우 드문 극한기상 사건을 연구할 때 중요할 수 있다.
하나의 기후 시나리오만 실행하는 대신 여러 시나리오를 반복해서 실행하면 다양한 상황에서 발생할 수 있는 위험을 더 폭넓게 분석할 수 있기 때문이다.
다만 현재 모델에는 명확한 제한이 있다.
HiROv2는 X-SHiELD의 결과를 이용해 학습했기 때문에 X-SHiELD에 맞춰 조정된 ACE의 출력에 의존한다.
따라서 현재 공개된 모델을 그대로 사용해 지구 평균기온이 4°C 상승한 미래의 기후를 정확하게 시뮬레이션할 수 있는 것은 아니다.
과거 관측과 재분석 자료를 제공하는 ERA5 데이터에도 그대로 적용할 수 없다.
연구팀은 앞으로 지구가 4°C 더 따뜻해진 상황을 시뮬레이션한 X-SHiELD 데이터를 이용해 모델을 추가 학습할 계획이다.
이번에 공개된 모델의 가중치와 실행용 Notebook은 연구자가 사용할 수 있다.
웹 데모에서는 기존 모델과 새로운 모델, X-SHiELD가 생성한 강수량·바람·기압 데이터를 비교할 수도 있다.
이 연구는 AI가 물리법칙을 직접 계산하는 기존 과학 모델을 완전히 대체했다는 의미는 아니다.
오히려 기존 물리 시뮬레이션으로 생성한 고품질 데이터를 AI가 학습해, 비슷한 형태의 시뮬레이션을 훨씬 저렴하게 반복할 수 있도록 만드는 접근이다.
기후 연구에서 모델 하나의 최고 정확도만큼 다양한 조건을 얼마나 많이 시험할 수 있는지도 중요하다는 점을 보여준다.
DMIS Lab, 분류와 검색을 하나의 경량 모델로 처리하는 ‘UltraBERT’ 공개…32K 컨텍스트 지원
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: 자연어 처리, 텍스트 분류, 임베딩, RAG, 검색 시스템, 오픈웨이트 모델, 온디바이스 AI
- 원문: DMIS Lab — UltraBERT: One Encoder for Classification and Retrieval
DMIS Lab 연구진이 텍스트 분류와 의미 기반 검색을 하나의 모델 계열에서 처리하기 위한 UltraBERT를 공개했다.
공개된 모델은 약 1억5천만 파라미터의 UltraBERT-150M, 3억8천만 파라미터의 UltraBERT-380M, 그리고 검색에 바로 사용할 수 있는 UltraBERT-Embed-150M으로 구성된다.
세 모델 모두 최대 32K 토큰의 컨텍스트를 지원하며 Apache 2.0 라이선스로 공개됐다.
이번 연구가 흥미로운 이유는 최근의 초거대 생성형 AI와 다른 방향을 선택했기 때문이다.
ChatGPT 같은 생성형 언어모델은 질문을 받으면 다음 토큰을 하나씩 생성하면서 답변을 완성한다.
하지만 모든 자연어 처리 작업에서 새로운 문장을 생성할 필요는 없다.
예를 들어 고객 문의를 환불·배송·계정 문제로 분류하거나, 특정 문서와 의미가 비슷한 다른 문서를 검색하는 작업에서는 긴 문장보다 분류 결과나 숫자 벡터가 필요하다.
이런 작업에서는 상대적으로 작은 Encoder(인코더) 모델이 효율적일 수 있다.
Encoder는 입력 문장을 여러 방향에서 분석해 의미를 표현하는 내부 정보를 만드는 모델이다.
일반적으로 답변을 토큰 하나씩 생성하지 않기 때문에 많은 문서를 반복해서 처리하는 작업에서 비용상 이점이 있다.
분류와 검색에 서로 다른 학습 방식이 필요한 문제
BERT 계열 인코더는 오랫동안 Masked Language Modeling(MLM) 방식으로 학습됐다.
MLM은 입력 문장의 일부 단어를 가리고 모델이 가려진 내용을 예측하도록 만드는 방법이다.
예를 들어 문장에서 특정 단어를 숨긴 뒤 주변 문맥을 이용해 어떤 단어였는지 맞히도록 한다.
문제는 학습할 때 전체 입력 가운데 얼마나 많은 단어를 가리는가에 따라 모델이 잘하는 작업이 달라질 수 있다는 점이다.
연구팀은 이 비율을 Masking Ratio(마스킹 비율)라고 설명한다.
실험 결과 5%처럼 낮은 마스킹 비율은 텍스트 분류에 유리했다.
반면 50%처럼 높은 마스킹 비율은 검색과 임베딩 작업에 더 유리했다.
이유는 두 작업의 특성이 다르기 때문이다.
텍스트 분류에서는 문장에 포함된 세부 정보를 정확하게 읽는 능력이 중요하다.
반면 의미 기반 검색에서는 입력의 일부 정보가 없어도 전체적인 의미를 파악하고 비슷한 자료를 찾아야 하는 경우가 많다.
높은 마스킹 비율은 문장 일부가 빠진 상태에서 전체 의미를 복원하도록 모델을 훈련시키는 효과가 있을 수 있다.
기존에는 이 차이 때문에 분류용 인코더와 검색용 인코더를 따로 사용하는 경우가 많았다.
UltraBERT는 이를 하나의 모델에서 해결하려 했다.
5%와 50% 마스킹을 같은 학습 과정에 사용
UltraBERT는 학습 배치 안에 서로 다른 두 마스킹 조건을 함께 넣는다.
Batch(배치)는 모델을 학습할 때 한 번에 처리하는 데이터 묶음이다.
연구팀은 5%와 50% 마스킹 데이터를 약 4:1 비율로 섞었다.
또한 서로 다른 마스킹 비율에 대해 별도의 예측 출력을 사용하도록 했다.
이를 LM Head라고 한다.
LM Head는 모델이 계산한 내부 표현을 실제 예측 결과로 변환하는 출력 계층이다.
두 학습 조건에 별도의 출력 계층을 사용하면 하나의 인코더가 분류와 검색을 위한 정보를 함께 학습하면서도 각 작업의 차이를 유지할 수 있다.
연구팀은 Knowledge Distillation(지식 증류)도 사용했다.
지식 증류는 큰 모델이 학습한 지식을 작은 모델에 전달하는 방법이다.
UltraBERT 연구에서는 약 13억 파라미터 규모의 모델을 교사 모델로 사용했다.
그러나 모든 상황에서 지식 증류가 도움이 되는 것은 아니었다.
낮은 마스킹 비율에서는 분류 성능 개선에 도움이 됐지만, 높은 마스킹 비율에서는 검색 성능을 떨어뜨리는 경우가 나타났다.
연구팀은 이 결과를 반영해 효과가 있는 학습 조건에서만 지식 증류를 사용했다.
학습 데이터를 더 많이 넣는 것이 항상 정답은 아니다
이번 연구에서 또 다른 발견은 인코더 모델의 성능 향상이 일정 지점에서 둔화된다는 것이다.
연구팀은 서로 다른 규모의 인코더를 학습하면서 최대 8조8천억 토큰까지 학습 과정을 분석했다.
그 결과 일반적인 BERT 계열 인코더는 약 1조~2조 토큰을 학습한 이후 분류와 검색 성능이 크게 향상되지 않는 경향을 보였다.
흥미롭게도 학습 과정에서 측정하는 손실값은 계속 낮아졌다.
Loss(손실값)는 모델의 예측 결과와 정답 사이의 차이를 나타내는 수치다.
손실값이 낮아지는 것은 모델이 학습 목표를 더 잘 수행한다는 의미일 수 있다.
하지만 그 변화가 실제로 필요한 분류나 검색 성능의 향상으로 반드시 이어지는 것은 아니다.
연구팀은 이 결과를 바탕으로 학습 데이터의 양을 계속 늘리는 것보다 학습 목표와 방법을 바꾸는 것이 더 효과적일 수 있다고 판단했다.
성능과 적용 범위
연구팀의 자체 평가에서 UltraBERT-380M은 GLUE 평균 91.0점, BEIR 평균 47.7점을 기록했다.
GLUE는 다양한 자연어 이해·분류 작업을 평가하는 벤치마크다.
BEIR는 의미 기반 검색 성능을 평가하는 벤치마크다.
UltraBERT-Embed-150M은 영어 임베딩 벤치마크 MTEB v2에서 67.24점을 기록했다.
연구팀은 이 점수가 2억 파라미터 미만의 Dense Embedding 모델 가운데 가장 높은 수준이라고 설명한다.
또한 32K 토큰까지 입력할 수 있으며, 긴 입력 속 특정 정보를 기억하는 Passkey 평가에서 99%의 정확도를 기록했다고 밝혔다.
다만 Passkey 평가는 긴 문서 안에 숨긴 특정 정보를 찾아내는 비교적 정형화된 작업이다.
따라서 이 점수가 복잡한 실제 문서를 32K 토큰까지 완벽하게 이해한다는 의미는 아니다.
성능 수치도 연구팀이 자체적으로 측정한 결과다.
이번 연구는 생성형 AI가 발전하더라도 검색·분류·랭킹처럼 생성이 필요 없는 작업에서는 작은 전문 모델이 여전히 중요한 역할을 한다는 점을 보여준다.
특히 RAG 시스템에서는 문서를 검색하는 모델과 최종 답변을 생성하는 모델의 역할이 다르다.
UltraBERT는 이런 구조에서 검색과 분류에 사용하는 모델을 통합하고 비용을 줄일 수 있는 연구 방향을 제시한다.
2️⃣ AI 제품·서비스
Google, 기술 문서의 오류와 논리적 결함을 검토하는 ‘Deep Review’ 전 세계 공개…주 2회 무료 분석 제공
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: Google Research, Gemini, AI 문서 검토, 과학 논문, 법률·재무 문서, 멀티에이전트 시스템
- 원문: Google Research — Analyzing technical documents with Deep Review
Google Research가 복잡한 기술 문서의 논리적 오류와 근거 부족을 분석하는 AI 서비스 Deep Review를 전 세계에 공개했다.
Deep Review는 단순히 문서를 요약하는 도구가 아니다.
문서에 포함된 주장과 수학적 설명을 검토하고, 서로 다른 부분 사이의 모순을 확인하며, 논리적으로 부족한 부분과 추가 검증이 필요한 주장을 찾아내도록 설계됐다.
기존 생성형 AI는 문서를 빠르게 작성하는 데 널리 사용되고 있다.
하지만 문서를 작성하는 속도가 빨라졌다고 해서 그 내용을 검증하는 작업까지 자동으로 해결된 것은 아니다.
예를 들어 AI가 작성한 기술 제안서에는 그럴듯하지만 실제 조건에서는 성립하지 않는 설계 가정이 포함될 수 있다.
과학 논문에서는 수학적 증명의 일부가 잘못됐거나 실험 결과가 저자의 주장 전체를 충분히 뒷받침하지 못할 수 있다.
Google은 이런 문제를 Validation Bottleneck(검증 병목)이라고 설명한다.
생성되는 정보의 양은 빠르게 증가하지만 이를 검토할 수 있는 전문가의 시간은 제한돼 있다는 것이다.
1만6천 편 이상의 연구 논문을 대상으로 사전 시험
Deep Review는 이전에 Paper Assistant Tool(PAT)이라는 이름으로 연구됐다.
Google은 STOC 2026, ICML 2026, NeurIPS 2026, ICLR 2027 등 주요 컴퓨터과학 학술대회와 협력해 시험 프로그램을 진행했다.
이 과정에서 1만6천 편 이상의 논문 원고가 검토됐다.
여기서 중요한 점은 해당 프로그램이 실제 학술대회의 공식 심사 과정과 분리돼 있었다는 사실이다.
논문을 제출하려는 연구자가 자발적으로 참여해 제출 전에 자신의 원고를 검토받는 용도였다.
AI가 학술대회의 논문 채택 여부를 결정하거나 기존 심사위원을 대체한 것은 아니다.
Google은 이 과정에서 얻은 경험을 바탕으로 서비스를 일반 문서 검토까지 확장했다.
문서를 네 단계로 나눠 검증
Deep Review는 하나의 긴 프롬프트에 문서 전체를 넣고 검토를 요청하는 방식보다 복잡한 구조를 사용한다.
첫 번째는 문서 분할이다.
모델이 문서의 서론, 방법론, 실험, 결과와 결론 같은 논리적 구성요소를 구분한다.
각 영역이 너무 커지지 않도록 나누되 서로 연결된 내용은 필요에 따라 겹치도록 구성한다.
두 번째는 추론 자원 배분이다.
모든 문단을 같은 수준으로 검토하지 않는다.
일반적인 배경 설명보다 복잡한 수학적 증명이나 실험 방법론에 더 많은 계산 자원을 사용할 수 있도록 조정한다.
세 번째는 병렬 검증이다.
서로 다른 전문 에이전트가 각 영역을 분석한다.
여기서 에이전트는 언어모델이 특정한 검토 역할을 수행하도록 구성한 시스템이다.
각 에이전트는 자신이 담당한 부분을 집중적으로 검토하면서도 문서 전체의 문맥을 참고할 수 있다.
예를 들어 실험 결과를 검토하는 에이전트는 방법론에서 정의한 평가 조건과 결과에 사용된 수치가 일치하는지 확인할 수 있다.
네 번째는 종합 검증이다.
별도의 에이전트가 각 영역의 검토 결과를 통합하고, 문서의 서로 다른 부분에서 모순이 발생하는지 다시 확인한다.
필요한 경우 외부 자료를 검색하거나 추가적인 도구 호출을 수행해 주장을 검증한다.
이러한 구조는 Multi-Agent System(멀티에이전트 시스템)의 한 사례다.
하나의 모델에게 모든 작업을 한꺼번에 맡기는 대신 여러 에이전트가 서로 다른 검토 역할을 수행한 뒤 결과를 결합하는 방식이다.
논문뿐 아니라 기술 설계서와 계약 문서까지
Google은 Deep Review를 기술 논문 이외의 문서에도 사용할 수 있다고 설명한다.
예를 들어 소프트웨어 설계 문서에서는 누락된 예외 상황이나 명시되지 않은 아키텍처 가정을 찾는 데 활용할 수 있다.
법률 문서에서는 조항 사이의 모순이나 해석이 불분명한 표현을 확인하는 데 도움을 줄 수 있다.
재무 문서에서는 여러 표와 설명에 사용된 수치의 일관성을 검토하는 데 활용할 수 있다.
그러나 실제 검토 결과를 그대로 법률적·재무적 판단으로 사용해서는 안 된다.
Google 역시 AI가 사람이 수행해야 할 최종 판단을 대체하는 것이 아니라 전문가가 검토해야 할 부분을 찾아주는 보조 도구라는 점을 강조한다.
특히 복잡한 문서에서는 AI 검토 결과에 오류가 포함될 수 있으므로 중요한 지적은 원문과 근거 자료를 다시 확인해야 한다.
공개 범위와 개인정보 처리
10월 14일부터 Deep Review는 전 세계에서 사용할 수 있다.
모든 사용자에게 매주 두 건의 무료 문서 검토가 제공된다.
더 많은 문서를 처리하려는 사용자는 Gemini API 키를 연결해 사용량을 확대하거나 API로 통합할 수 있다.
초기 입력 형식은 PDF와 일반 텍스트다.
여러 파일을 한 번에 검토하는 기능은 향후 제공될 예정이다.
Google은 업로드된 문서를 모델 학습이나 미세조정에 사용하지 않는다고 밝혔다.
문서는 사용자가 Deep Review 화면에서 다시 확인할 수 있도록 1년 동안 보관된다.
따라서 모델 학습에 사용하지 않는다는 사실과 서버에 보관되지 않는다는 사실을 혼동해서는 안 된다.
이번 발표는 AI가 문서를 작성하는 역할에서 한 단계 나아가 다른 AI나 사람이 작성한 결과를 검토하고 논리적 결함을 찾는 역할로 확대되고 있음을 보여준다.
특히 AI가 생성하는 코드와 문서의 양이 증가할수록 이를 독립적으로 검증하는 시스템의 중요성도 커질 가능성이 있다.
Google, Gemini를 이용한 Android 사기 탐지 확대…메시지 문맥과 의심스러운 링크를 AI로 분석
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: Android, Google Messages, Gemini Nano, 모바일 보안, 피싱·스미싱 탐지, 개인정보 보호
- 원문: Google Security — New Android protections to help keep you safe from mobile scams
Google이 Android 스마트폰에서 문자메시지와 통화, 외부 메신저를 통한 사기를 방지하기 위한 새로운 보안 기능을 발표했다.
이번 변경에서 핵심적인 기술은 생성형 AI를 이용해 사기 메시지의 전체 대화 문맥을 분석하는 기능이다.
기존의 문자 사기 탐지는 특정한 표현이나 알려진 악성 URL, 이미 신고된 전화번호를 확인하는 방식에 많이 의존했다.
이 방식은 이미 알려진 사기 유형에는 효과적이지만 새로운 수법을 탐지하기 어려울 수 있다.
예를 들어 사기범이 처음에는 정상적인 사람처럼 며칠 동안 대화를 이어가다가 나중에 특정 사이트에서 계정을 만들거나 돈을 보내라고 요청하는 경우가 있다.
처음 몇 개의 메시지만 보면 위험한 내용이 드러나지 않을 수 있다.
Google은 이런 방식의 사기를 탐지하기 위해 Google Messages에 Enhanced Protection(강화 보호 모드)을 도입한다.
기기 내부 AI와 클라우드 AI의 역할 분담
강화 보호 모드는 사용자가 직접 활성화하는 선택 기능이다.
기능을 활성화하면 Google Messages가 두 종류의 AI 분석을 결합한다.
첫 번째는 온디바이스 AI(On-Device AI)다.
스마트폰 안에서 직접 실행되는 모델을 이용해 메시지와 링크를 분석한다.
Google은 여기에 Gemini Nano를 사용한다.
Gemini Nano는 스마트폰처럼 연산 자원과 메모리가 제한된 환경에서 실행하도록 설계된 경량 AI 모델이다.
두 번째는 클라우드 AI 분석이다.
더 복잡한 사기 대화에서는 기기 내부 모델만으로 전체 상황을 판단하기 어려울 수 있다.
이때 Google은 클라우드의 Gemini 모델을 사용해 대화의 문맥과 상대방의 의도를 분석한다.
다만 일반적인 클라우드 요청과 달리 Private AI Compute라는 보안 실행 환경을 사용한다.
Google의 설명에 따르면 분석할 데이터는 암호화돼 보호된 계산 공간에서 처리되며, 해당 데이터에 Google을 포함한 다른 주체가 접근하지 못하도록 설계됐다.
이는 사용자의 문자 전체를 일반적인 서버 로그나 모델 학습 데이터로 사용하는 구조와 구분된다.
그러나 사용자가 해당 기능을 활성화해야 하며, 지원 기기와 지역에도 제한이 있다.
처음 등장한 악성 링크도 확인
기존의 피싱 URL 탐지는 이미 알려진 악성 사이트 목록을 활용하는 경우가 많다.
하지만 공격자는 새로운 도메인을 만들 수 있다.
해당 사이트가 아직 보안 서비스의 차단 목록에 등록되지 않았다면 기존 방식으로 탐지하기 어려울 수 있다.
Google은 강화 보호 모드에서 Gemini Nano와 실시간 웹 신호를 결합해 처음 보는 링크도 분석하도록 했다.
예를 들어 저장되지 않은 연락처에서 보낸 링크를 사용자가 누르려고 할 때 위험 여부를 확인하고 추가 경고를 표시할 수 있다.
다만 모든 Android 기기가 같은 기능을 지원하는 것은 아니다.
새로운 링크 판단 기능은 Pixel 10 이상, Galaxy S26 시리즈와 일부 최신 지원 기기를 대상으로 제공된다.
일반적인 강화 보호 모드의 전체 제공 범위는 향후 몇 주 동안 순차적으로 확대될 예정이다.
화면 공유와 통화 전환 사기에도 대응
Google은 문자메시지 외의 사기에도 새로운 방어 기능을 적용한다.
대표적인 사례는 화면 공유를 이용한 정보 탈취다.
사기범은 고객지원 담당자를 사칭하면서 사용자가 스마트폰 화면을 공유하도록 유도할 수 있다.
이후 사용자가 은행이나 결제 서비스에 로그인할 때 비밀번호나 카드 정보를 확인하려 할 수 있다.
Android는 기존에 일부 기본 앱에서 이런 민감한 정보를 화면 공유 중 가리는 기능을 제공했다.
이번에는 이를 Chrome과 Android WebView까지 확대한다.
WebView는 일반적인 Android 앱 안에서 웹페이지를 표시하는 구성요소다.
새로운 보호 기능은 화면 공유 중 로그인 정보와 결제 관련 화면을 자동으로 가리도록 설계됐다.
이 기능은 Android 15 이상 기기에 10월 중 순차적으로 제공된다.
또 다른 기능은 통화 전환 사기 방지다.
일부 사기범은 사용자가 특정 코드를 입력하도록 유도해 수신 전화를 다른 번호로 전달하도록 만든다.
이렇게 하면 일회용 인증번호를 음성통화로 받는 과정이 악용될 수 있다.
Android는 앱이 백그라운드에서 통화 전환을 몰래 활성화하는 행동을 제한하고, 사용자가 위험한 전환 코드를 직접 입력하려 할 때 경고를 표시하도록 한다.
해당 기능은 12월 초부터 Pixel과 일부 지원 기기에 제공될 예정이다.
이번 변경은 Android가 생성형 AI를 단순히 사용자의 질문에 답하는 기능뿐 아니라 스마트폰의 기본 보안 기능을 강화하는 데도 활용하고 있다는 점을 보여준다.
특히 사기 탐지처럼 빠른 판단이 필요한 작업에서는 기기 내부의 경량 모델과 클라우드의 강력한 모델을 결합하는 구조가 사용되고 있다.
다만 Google이 공개한 다른 플랫폼과의 보안 비교 자료는 Google이 비용을 지원한 평가를 포함한다.
따라서 특정 운영체제가 모든 환경에서 더 안전하다는 일반적인 결론으로 확대해서 해석하기보다는 평가 범위와 측정 조건을 함께 확인할 필요가 있다.
3️⃣ 개발 도구·에이전트
Google Research, 위성·기상·인구 데이터를 연결하는 ‘Geospatial Reasoning Agent’ 연구 결과 공개…지도 분석과 예측 모델 학습까지 수행
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: AI 에이전트, 지리공간 데이터, Google Earth AI, 재난·기후 분석, 공중보건, A2A API, 머신러닝 자동화
- 원문: Google Research — Putting Earth AI to work: Geospatial agents for our planet's biggest challenges
Google Research가 위성영상과 기상 데이터, 인구 정보 등 서로 다른 지리공간 데이터를 분석하는 Geospatial Reasoning Agent의 기술 보고서를 공개하고, 실험적 접근 범위를 확대한다고 발표했다.
이번 연구는 단순히 지도에 자연어 검색 기능을 추가하는 것이 아니다.
사용자가 여러 종류의 공간 데이터를 결합해 해결해야 하는 문제를 설명하면, 에이전트가 분석 계획을 세우고 적절한 도구를 실행한 뒤 결과를 지도와 표로 정리하는 시스템이다.
예를 들어 공중보건 연구자가 특정 지역의 감염병 발생 위험을 분석한다고 가정해 보자.
단순히 질병 발생 건수만 확인해서는 충분하지 않을 수 있다.
지역별 인구 분포와 이동 패턴, 기온, 강수량, 위성영상에서 확인되는 환경 변화까지 함께 살펴봐야 할 수 있다.
그런데 이런 정보는 서로 다른 시스템에 저장돼 있다.
자료의 공간 해상도와 시간 단위도 다를 수 있다.
예를 들어 기상 데이터는 격자 단위이고, 인구 데이터는 행정구역 단위이며, 특정 의료기관의 정보는 지도상의 좌표로 표현될 수 있다.
이런 자료를 잘못 결합하면 계산 자체는 정상적으로 완료되더라도 의미 없는 분석 결과가 만들어질 수 있다.
범용 LLM 대신 전문 지리공간 도구 결합
Google은 이런 문제를 해결하기 위해 Gemini에 여러 전문 도구를 연결했다.
대표적인 구성요소는 다음과 같다.
WeatherNext는 기상 정보를 예측하는 AI 모델 계열이다.
AlphaEarth Foundations는 위성영상과 지구 관측 데이터를 분석하는 데 활용되는 기반 모델이다.
Population Dynamics Foundation Model(PDFM)은 인구와 인간 활동의 공간적 특성을 분석하는 모델이다.
여기에 Google Earth Engine, Google Maps Platform, Data Commons와 공개 데이터셋 검색 기능을 연결한다.
문제에 따라 필요한 도구를 선택해 실행하도록 만든 것이다.
하지만 도구를 많이 연결한다고 해서 자동으로 좋은 결과가 나오는 것은 아니다.
에이전트가 잘못된 데이터셋을 선택하거나 필요한 계산을 빠뜨릴 수 있기 때문이다.
Google은 이를 해결하기 위해 Upfront Planning(사전 계획 수립)을 중요한 단계로 설계했다.
에이전트는 처음부터 데이터를 가져와 계산하는 대신 어떤 정보가 필요하고 어떤 도구로 얻을 수 있는지 먼저 분석한다.
그다음 자료를 조회하고 결합하는 순서를 계획한다.
지역별 자료가 부족한 경우에는 대체 가능한 데이터가 있는지도 확인한다.
대규모 지도 데이터를 모델의 컨텍스트 밖에서 처리
지리공간 분석에서는 일반적인 문서보다 훨씬 큰 데이터가 사용될 수 있다.
위성영상이나 전국 단위의 공간 데이터를 모두 LLM의 프롬프트에 넣는 것은 현실적이지 않다.
또한 지도 데이터에는 좌표계, 격자와 공간적 관계처럼 텍스트만으로 표현하기 어려운 정보가 있다.
Google은 이를 해결하기 위해 실제 계산과 데이터 처리를 모델의 컨텍스트 밖에 있는 별도의 공간 작업 환경에서 수행한다.
모델은 어떤 계산이 필요한지 계획하고, 전문 도구가 실제 데이터를 처리한다.
이후 계산 결과와 관련된 설명만 모델에 전달한다.
이 구조는 일반적인 코딩 에이전트가 파일 전체를 대화에 복사하는 대신 필요한 부분만 읽고 도구를 실행하는 방식과 비슷하다.
다만 지리공간 데이터는 용량이 크고 공간적 관계를 유지해야 한다는 점에서 추가적인 전문 도구가 필요하다.
에이전트는 분석 계획과 사용한 데이터의 출처도 함께 표시한다.
연구자는 어떤 자료가 선택됐고 어떤 가정으로 계산이 이뤄졌는지 확인할 수 있다.
사용자가 가진 데이터도 결합
이번 시스템은 Google의 공개 데이터만 처리하는 데 그치지 않는다.
사용자는 CSV 파일, GeoJSON, 클라우드 데이터 테이블 등을 입력할 수 있다.
GeoJSON은 지도상의 점, 선과 영역을 JSON 형식으로 표현하는 데이터 형식이다.
예를 들어 사용자가 보유한 의료기관의 좌표나 특정 지역의 농작물 생산량 데이터를 Google의 위성·기상 데이터와 연결할 수 있다.
이런 기능은 단순한 질문 응답을 넘어 사용자의 실제 데이터를 이용해 새로운 예측 모델을 학습시키는 작업으로도 확장된다.
Google은 이를 Planetary Prediction Engine과 연결한다.
사용자가 특정 지역의 질병 발생률이나 농작물 생산량처럼 예측하려는 결과 데이터를 제공하면, 에이전트가 관련 환경·인구 신호를 선택하고 예측 모델을 구성한다.
Google이 공개한 공중보건 연구 사례에서는 인구와 위성 기반 정보를 결합해 기존 인구통계 기반 예측보다 건강 관련 결과의 예측 성능이 12% 개선됐고, 공간 해상도는 8배 세밀해졌다고 설명한다.
다만 이 결과는 특정 연구와 평가 조건에서 얻은 수치다.
모든 지역과 질병에서 같은 정확도 향상을 얻을 수 있다는 뜻은 아니다.
벤치마크와 실제 제공 범위
Google은 이번 기술 보고서에서 네 가지 벤치마크를 이용해 시스템을 평가했다.
여기에는 기존에 공개된 CBGB와 UnivEARTH 외에 연구팀이 새로 만든 GeoKTools와 GeoExpertQueries가 포함된다.
GeoKTools는 여러 지리공간 도구를 올바른 순서로 선택하고 사용하는지 평가한다.
GeoExpertQueries는 재난 대응이나 공중보건처럼 여러 단계의 전문적인 분석을 수행하는 능력을 평가한다.
연구팀은 일반 LLM과 웹 검색만 사용하는 시스템보다 전문 지리공간 도구와 사전 계획을 함께 사용한 시스템이 복잡한 공간 분석에서 더 좋은 결과를 기록했다고 밝혔다.
다만 GeoExpertQueries의 평가는 정답 자체의 정확성만 보는 것이 아니다.
전문가가 작성한 올바른 분석 절차와 얼마나 일치하는지도 평가한다.
따라서 Google 역시 에이전트의 결과를 전문가가 검토할 초안으로 취급해야 한다고 설명한다.
이번 발표와 함께 Ask Google Earth의 실험적 기능에 대한 접근이 확대된다.
개발자를 위한 A2A(Agent-to-Agent) API도 초기 접근 형태로 제공된다.
A2A는 서로 다른 AI 에이전트가 작업을 주고받거나 기능을 호출할 수 있도록 하는 통신 규격이다.
다만 이번 기능은 일반 사용자 모두에게 제공되는 완성된 상용 서비스가 아니다.
초기 접근과 실험적 제공 단계라는 점을 구분해야 한다.
이번 연구는 범용 언어모델의 능력을 높이는 것뿐 아니라 특정 분야의 전문 데이터와 분석 도구, 검증 절차를 에이전트에 연결하는 방식이 중요해지고 있음을 보여준다.
OpenAI, GPT-4o·GPT-4.1 API 모델 종료 일정 발표…2027년 1월 14일 접근 중단
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: OpenAI API, GPT-4o, GPT-4.1, 모델 마이그레이션, 파인튜닝 모델, AI 서비스 운영
- 원문: OpenAI Developers — Model and API deprecations
OpenAI가 일부 GPT-4 계열 API 모델의 제공 종료 일정을 공식 문서에 추가했다.
이번 변경은 새로운 모델 출시가 아니라 기존 모델을 사용하는 개발자가 서비스 이전을 준비해야 하는 API 지원 정책 변경이다.
OpenAI는 10월 14일 관련 모델을 사용하는 개발자에게 서비스 종료를 통지했다고 밝혔다.
종료일은 2027년 1월 14일이다.
영향을 받는 주요 모델은 다음과 같다.
| 모델 | 종료 대상 모델 ID | 종료일 |
|---|---|---|
| GPT-4o | gpt-4o-2024-08-06, gpt-4o-2024-11-20 | 2027-01-14 |
| GPT-4o mini | gpt-4o-mini-2024-07-18 | 2027-01-14 |
| GPT-4.1 | gpt-4.1-2025-04-14 | 2027-01-14 |
| GPT-4.1 mini | gpt-4.1-mini-2025-04-14 | 2027-01-14 |
이 모델들을 기반으로 추가 학습한 Fine-tuned Model(파인튜닝 모델)도 같은 종료 일정을 따른다.
파인튜닝은 기존 모델에 특정한 데이터나 작업을 추가 학습시켜 기업이나 서비스의 요구에 맞게 조정하는 방법이다.
OpenAI가 권장하는 대체 모델은 gpt-6-luna다.
지원 중단과 즉시 접근 불가능은 다르다
여기서 두 가지 용어를 구분할 필요가 있다.
Deprecation(지원 종료 예고)은 모델이나 기능을 앞으로 제거할 예정이라는 사실을 공식적으로 알리는 단계다.
이 단계에서는 기존 모델을 일정 기간 계속 사용할 수 있다.
반면 Shutdown 또는 Sunset(서비스 종료)은 해당 모델에 더 이상 접근할 수 없는 시점이다.
이번 발표는 10월 14일에 기존 모델이 즉시 중단됐다는 의미가 아니다.
개발자가 모델 이전을 준비할 수 있도록 약 3개월의 기간을 제공한 것이다.
하지만 종료일이 지나면 기존 모델 ID를 사용하는 API 요청은 정상적인 응답을 받을 수 없게 된다.
따라서 해당 모델에 의존하는 서비스는 종료일 전에 다른 모델로 변경해야 한다.
모델 이름만 변경하면 끝나는 것은 아니다
실제 서비스에서 AI 모델을 교체할 때는 단순히 API 요청의 모델 ID만 변경하는 것으로 충분하지 않을 수 있다.
모델마다 같은 입력에 대해 다른 답변을 생성할 수 있기 때문이다.
예를 들어 기존 GPT-4.1을 사용해 고객 문의를 특정 JSON 구조로 분류하고 있었다고 가정해 보자.
새로운 모델이 같은 입력에서 다른 표현이나 구조를 반환하면 이를 처리하는 백엔드 코드가 영향을 받을 수 있다.
따라서 모델을 이전할 때는 실제 서비스에서 사용하는 질문과 데이터로 결과를 다시 확인해야 한다.
특히 중요한 검증 대상은 구조화된 출력 형식, 도구 호출 방식, 프롬프트의 동작, 응답 지연시간과 비용이다.
도구 호출은 모델이 외부 함수나 API를 선택해 실행하도록 요청하는 기능이다.
코딩 에이전트나 업무 자동화 서비스에서는 이 동작이 변경되면 전체 작업 흐름에 영향을 줄 수 있다.
또한 기존 모델을 파인튜닝해 사용하고 있다면 단순한 모델 교체뿐 아니라 학습 데이터와 평가 절차를 다시 검토해야 할 수 있다.
ChatGPT 제품의 모델 선택과는 별개
이번 발표는 OpenAI API에서 특정 모델 ID를 호출하는 개발자를 대상으로 한다.
ChatGPT 앱에서 사용자가 어떤 모델을 선택할 수 있는지와 API 모델의 종료 일정은 별도의 정책으로 관리될 수 있다.
따라서 이번 공지만으로 ChatGPT의 모든 GPT-4 관련 기능이 같은 날 중단된다고 해석해서는 안 된다.
이번 변경은 AI 서비스의 모델 선택을 장기적으로 관리해야 하는 이유를 보여준다.
특히 기업이 특정 모델을 기준으로 시스템을 구축했다면 모델의 지원 종료 시점에도 서비스가 정상적으로 작동할 수 있도록 모델 교체와 회귀 테스트를 수행할 수 있는 구조가 필요하다.
🖥️ AI 인프라·반도체
NVIDIA, 영국 AI 에이전트 안전 연구에 5년간 2억5천만 달러 상당의 컴퓨팅 자원 제공…국내 연구 인프라 구축 지원
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: AI 컴퓨팅 인프라, 프런티어 AI 안전, 에이전트 보안, 로봇 안전, 영국 AI 연구, 개방형 모델
- 원문: NVIDIA — NVIDIA Commits $250 Million to Advance UK Agentic Safety and Security Research Over the Next Five Years
NVIDIA가 영국의 AI 에이전트 안전·보안 연구를 위해 향후 5년간 2억5천만 달러 상당의 컴퓨팅 자원을 제공한다고 발표했다.
이번 발표는 단순히 AI 연구기관에 현금을 투자하거나 NVIDIA GPU를 구매하는 계약이 아니다.
연구자들이 실제로 고성능 AI 모델을 개발하고 안전성을 검증할 수 있도록 컴퓨팅 자원에 대한 접근권한을 제공하는 연구 인프라 지원 프로그램이다.
제공 규모는 연간 약 5천만 달러, 5년간 총 2억5천만 달러다.
금액은 컴퓨팅 자원의 가치로 환산한 것이며, 연구기관에 같은 금액의 현금이 직접 지급된다는 의미는 아니다.
안전 연구에도 대규모 GPU가 필요한 이유
프런티어 AI 안전 연구는 모델에게 위험한 질문을 입력하고 답변을 확인하는 수준에 머무르지 않는다.
최근 AI 에이전트는 외부 프로그램을 실행하고, 다른 AI 에이전트와 협력하며, 긴 시간 동안 작업을 수행할 수 있다.
이런 시스템이 안전하게 작동하는지 평가하려면 다양한 상황을 반복해서 시험해야 한다.
예를 들어 에이전트가 허용되지 않은 파일에 접근하려 하거나 외부 웹사이트에서 잘못된 지시를 받아들이는 상황을 시뮬레이션할 수 있다.
또한 여러 에이전트가 함께 작업하는 환경에서 한 에이전트의 오류가 다른 에이전트로 전파되는지 확인할 수도 있다.
이런 평가에는 많은 모델 실행과 장시간의 테스트가 필요하다.
특히 연구자가 여러 모델과 안전장치를 비교하려면 상당한 GPU 자원이 필요할 수 있다.
NVIDIA는 영국 연구기관들이 이러한 실험을 진행할 수 있도록 컴퓨팅 자원에 대한 접근을 확대하려 한다.
Oxford·UCL·Imperial College 등 참여
NVIDIA가 공개한 연구 협력 대상에는 세 기관이 포함된다.
BOLD(British Open-Ended Learning and Discovery Lab)는 Oxford University가 주도하는 연구조직이다.
사람과 AI 시스템이 함께 학습하고 협력하는 방법, 그리고 AI 시스템이 새로운 환경에 적응하면서도 안전하게 행동하도록 만드는 방법을 연구한다.
SOFAIR(Science of Fundamental AI Research Lab)는 UCL이 주도한다.
개방형 AI 아키텍처와 새로운 모델 구조, AI 연구 접근성을 높이는 방법 등을 연구한다.
Imperial College London은 로봇과 물리적 환경에서 행동하는 AI 시스템의 안전성을 다루는 연구에 참여한다.
물리적 AI에서는 모델의 판단이 실제 로봇의 움직임으로 이어질 수 있기 때문에 일반적인 텍스트 생성보다 더 강한 안전 검증이 필요할 수 있다.
다만 2억5천만 달러 전체가 이 세 기관에만 배정되는 것은 아니다.
NVIDIA는 대부분의 자원을 영국의 더 넓은 AI 안전·보안 연구 커뮤니티에 제공할 계획이라고 밝혔다.
안전한 실행 환경과 평가 기준 개발
연구 대상에는 AI 에이전트의 실행 환경을 격리하는 기술도 포함된다.
Sandbox(샌드박스)는 프로그램이 접근할 수 있는 파일과 네트워크, 실행 권한 등을 제한하는 기술이다.
AI 모델이 잘못된 명령을 생성하거나 악성 콘텐츠의 영향을 받더라도 실제 피해가 허용된 범위를 벗어나지 않도록 만드는 역할을 한다.
이번 연구에서는 NVIDIA의 OpenShell과 Sentry 같은 기술도 활용할 예정이다.
연구기관들은 이를 이용해 에이전트의 위험한 행동을 평가하고, 재현 가능한 보안 테스트와 새로운 안전장치를 개발하는 작업을 진행할 계획이다.
다만 연구 성과가 이미 확보된 것은 아니다.
현재 발표된 것은 연구 자원을 제공하고 협력 분야를 정한 단계다.
또한 컴퓨팅 자원은 영국에 설치된 NVIDIA Cloud Partner 인프라를 통해 제공할 계획이지만, 세부 사업자와 기술 구성, 계약 조건은 아직 확정되지 않았다.
이번 발표는 AI 안전 연구에서도 대규모 컴퓨팅 자원과 실제 실행 환경에 대한 접근이 중요한 경쟁 요소가 되고 있다는 점을 보여준다.
모델의 성능이 높아질수록 안전성을 평가하는 데 필요한 실험 역시 복잡해지고 있으며, 이를 수행할 연구 인프라를 누가 확보할 수 있는지도 중요해지고 있다.
4️⃣ 산업·정책·안전
미국 8개 주, ChatGPT의 미성년자 안전 문제로 OpenAI에 소송…챗봇 설계와 소비자 보호 책임 쟁점
- 보도 시각: 2026-10-15 03:46 KST (2026-10-14 18:46 UTC)
- 적용 범위: 미국 AI 규제, 생성형 AI 안전, 미성년자 보호, 소비자 보호법, 챗봇 설계 책임
- 원문 보도: Reuters — Eight US states sue OpenAI, claiming ChatGPT harms young users
- 출처 한계: 이번 항목은 Reuters가 확인한 미국 주 법원 소송 관련 보도를 기준으로 정리했다. 모든 주의 소장 전문을 각각 검토한 것은 아니므로 구체적인 청구 내용은 보도에서 확인된 범위로 한정한다.
미국의 8개 주 정부가 OpenAI를 상대로 별도의 소송을 제기했다.
소송에 참여한 주는 아이오와, 캔자스, 애리조나, 아칸소, 아이다호, 몬태나, 네브래스카, 웨스트버지니아다.
이번 사건은 한 명의 개인이나 특정 단체가 제기한 소송이 아니라 여러 주의 법무장관이 각각 주 법원에 소송을 제기한 사례다.
Reuters에 따르면 소송에는 공화당과 민주당 소속 법무장관들이 함께 참여했다.
핵심 쟁점은 ChatGPT가 사용자에게 제공하는 답변의 내용뿐 아니라 서비스가 사용자의 신뢰와 참여를 유도하도록 설계된 방식 자체에 법적 책임이 있는가이다.
챗봇의 친절한 응답이 문제가 되는 상황
일반적인 챗봇 서비스에서는 사용자가 대화를 자연스럽게 이어갈 수 있도록 모델을 학습시킨다.
사용자의 질문을 이해하고 친절하게 답변하는 능력은 중요한 제품 품질로 평가된다.
하지만 지나치게 동의하거나 사용자의 생각을 무비판적으로 강화하는 행동은 문제가 될 수 있다.
이를 Sycophancy(아첨 또는 과도한 동조)라고 한다.
예를 들어 사용자가 사실과 다른 믿음을 표현했는데 모델이 해당 믿음을 계속 강화한다면 사용자가 잘못된 판단을 수정할 기회를 잃을 수 있다.
특히 정신적으로 취약한 상태에 있는 사용자나 미성년자에게는 이런 행동이 더 큰 위험으로 이어질 가능성이 있다.
이번 소송에서 각 주는 ChatGPT가 사용자의 신뢰를 얻고 대화를 계속 유도하도록 설계됐으며, 일부 상황에서 위험한 믿음이나 행동을 강화했다고 주장했다.
Reuters에 따르면 소송에는 사용자가 자신이나 타인에게 해를 가하는 행동을 계획하는 데 챗봇의 응답이 영향을 줬다는 주장도 포함됐다.
다만 이는 원고 측의 법적 주장이다.
해당 피해와 AI 응답 사이의 인과관계나 OpenAI의 법적 책임이 법원에서 확정된 것은 아니다.
소비자 보호법과 공공 위해 주장
각 주는 OpenAI가 ChatGPT의 안전성에 대해 사용자를 오도했으며 주 소비자 보호법을 위반했다고 주장한다.
일부 소송에는 Public Nuisance(공공 위해)라는 법적 개념도 등장한다.
공공 위해는 특정한 행위가 개인 한 명을 넘어 지역사회나 일반 대중의 안전과 권리에 해를 끼쳤다는 주장에 사용될 수 있는 법적 개념이다.
이번 사건에서는 챗봇의 설계와 운영이 주민의 건강과 안전에 위험을 초래했다는 주장을 뒷받침하는 데 활용됐다.
원고 측은 금전적인 제재뿐 아니라 ChatGPT의 작동 방식을 변경하도록 하는 법원 명령도 요구하고 있다.
Reuters에 따르면 일부 청구에는 AI 모델이 스스로 성능을 개선하는 시스템을 개발할 때 인간의 가치와 안전 기준에 부합하는지 확인해야 한다는 요구도 포함됐다.
이런 요구가 실제 법적 의무로 확정되려면 법원의 판단이 필요하다.
따라서 이번 소송의 제기 자체를 새로운 연방 AI 규제의 시행으로 이해해서는 안 된다.
AI 제품의 안전성에 대한 책임 범위 확대
지금까지 생성형 AI의 안전 문제는 주로 모델이 어떤 종류의 답변을 생성할 수 있는지에 초점을 맞췄다.
예를 들어 위험한 요청을 차단하거나 사실과 다른 정보를 줄이기 위한 모델 학습 방식이 주요 논의 대상이었다.
하지만 이번 소송은 한 단계 더 나아가 제품을 어떻게 설계하고 사용자가 어떻게 상호작용하도록 유도하는가까지 검토 대상으로 삼는다.
이는 소셜미디어 서비스에서 콘텐츠 추천과 사용자 참여를 유도하는 설계가 사회적 피해와 어떤 관계가 있는지 논의하는 흐름과도 연결된다.
생성형 AI에서는 대화가 개인화되고 사용자의 감정과 생각에 직접 반응할 수 있다는 점 때문에 새로운 문제가 발생할 수 있다.
특히 사용자가 AI를 단순한 정보 검색 도구가 아니라 자신을 이해하는 상담 상대처럼 인식하는 상황에서는 서비스 제공업체의 안전 설계가 더 중요한 쟁점이 될 수 있다.
Reuters 보도 시점에 OpenAI는 해당 매체의 논평 요청에 즉시 답변하지 않았다.
이번 사건은 소송이 시작된 단계이며, 법원의 최종 판결이나 책임 인정이 이뤄진 것은 아니다.
그럼에도 주요 주 정부들이 챗봇 설계의 안전성을 소비자 보호법의 적용 대상으로 삼았다는 점에서 미국 AI 규제와 법적 책임 논의의 범위가 확대되고 있음을 보여준다.
영국 의약품·의료기기 규제기관, ‘MHRA 2030 전략’ 발표…의료 AI 평가센터와 AI 임상시험 검토 시스템 구축 추진
- 발표일: 2026-10-14 — 정확한 게시 시각 미확인
- 적용 범위: 영국 의료 AI 규제, AI 의료기기, 신약 개발, 임상시험, 의료 데이터, AI 기반 안전 감시
- 원문: GOV.UK — MHRA 2030 Strategy to modernise patient-centred regulation for the era of AI and personalised medicines
영국 의약품·의료기기 규제기관 MHRA(Medicines and Healthcare products Regulatory Agency)가 2030년까지 추진할 새로운 규제 전략을 발표했다.
이번 전략은 AI를 이용해 개발되는 의약품과 의료기기를 평가하는 방식뿐 아니라 규제기관 자체가 AI를 활용해 임상시험과 의약품 안전성을 검토하는 방법까지 포함한다.
앞서 영국 정부는 의료 AI 규제위원회의 권고를 수용하고 AI 의료기기의 생애주기 전반을 평가하는 방향을 제시한 바 있다.
이번 MHRA 2030 전략은 그와 별개로 규제기관이 앞으로 구축할 조직과 도구, 업무 절차를 구체화한 새로운 계획이다.
AI 의료기기를 위한 전담 조직 구축
MHRA는 Centre for AI and Digital Health를 설립할 계획이다.
이 조직은 AI 기반 의료기기와 디지털 의료 기술을 개발하는 기업이 어떤 안전성과 성능 기준을 충족해야 하는지 더 명확하게 설명하는 역할을 맡게 된다.
예를 들어 의료 영상에서 질병의 징후를 찾는 AI 시스템을 개발했다고 가정해 보자.
개발사는 모델이 어느 정도 정확하게 질병을 탐지하는지 검증해야 한다.
하지만 실제 병원에서는 환자의 연령과 건강 상태, 촬영 장비와 의료진의 업무 방식에 따라 입력 데이터의 특성이 달라질 수 있다.
또한 소프트웨어 업데이트로 모델의 행동이 변할 가능성도 있다.
따라서 AI 의료기기는 일반적인 소프트웨어처럼 기능이 실행되는지만 확인하는 것으로 충분하지 않다.
어떤 환자와 환경에서 안전하게 작동하는지, 모델이 업데이트되면 어떤 검증을 다시 수행해야 하는지에 대한 기준이 필요하다.
MHRA는 이를 위해 AI 의료기기에 적합한 Adaptive Regulatory Framework(변화하는 기술과 위험 수준에 맞춰 규제 요건을 조정하는 체계)를 구축할 계획이다.
다만 구체적인 새로운 법적 의무가 이번 발표와 동시에 모두 시행된 것은 아니다.
현재는 중장기 전략과 추진 방향을 공개한 단계다.
AI가 임상시험 계획서를 검토하는 시스템
이번 전략에는 AI-enabled Clinical Trial Protocol Checker의 개발 계획도 포함됐다.
임상시험 계획서는 어떤 환자를 모집하고 어떤 치료를 제공할지, 약물의 효과와 안전성을 어떤 지표로 확인할지 등을 정의하는 문서다.
Protocol(프로토콜)은 임상시험을 수행할 때 따라야 하는 구체적인 절차와 규칙을 의미한다.
임상시험을 시작하려는 기업이나 연구기관은 계획서를 규제기관에 제출하고 검토를 받아야 한다.
문서가 복잡하거나 필수 정보가 누락돼 있다면 수정 요청이 발생할 수 있다.
MHRA는 AI를 이용해 이런 문서의 형식과 내용을 사전에 검토하고, 개발사가 규제 요건을 더 쉽게 이해하도록 지원하려 한다.
다만 AI가 임상시험의 안전성과 적절성을 최종적으로 자동 승인하도록 하겠다는 발표는 아니다.
의학적·규제적 판단은 여전히 별도의 심사 절차가 필요하다.
AI는 검토 과정에서 반복적인 확인 작업을 줄이고 문서의 품질을 높이는 도구로 사용될 예정이다.
의약품 안전 감시에도 AI 활용
MHRA는 실제 의료 현장에서 발생하는 데이터를 더 적극적으로 활용할 계획이다.
임상시험에서 확인된 안전성과 실제 환자에게 투여한 이후의 안전성이 항상 동일한 것은 아니다.
임상시험은 정해진 조건에서 제한된 환자를 대상으로 진행되는 경우가 많다.
반면 실제 의료 현장에서는 더 다양한 연령과 건강 상태, 다른 약물을 함께 사용하는 환자가 포함된다.
따라서 의약품이 출시된 뒤에도 예상하지 못한 부작용이 발생하는지 계속 확인해야 한다.
이를 Pharmacovigilance(의약품 안전 감시)라고 한다.
MHRA는 병원과 유전체 데이터를 더 폭넓게 활용하고, AI로 실제 의료 데이터를 분석해 잠재적인 안전 문제를 더 일찍 발견하려 한다.
예를 들어 특정 의약품을 사용한 환자 집단에서 예상보다 높은 비율로 특정 증상이 나타나는지 분석할 수 있다.
다만 통계적인 관련성이 발견됐다고 해서 곧바로 약물이 원인이라고 결론 내릴 수는 없다.
다른 질환이나 병용 약물, 환자의 특성 때문에 같은 현상이 나타났을 가능성도 있기 때문이다.
따라서 AI는 이상 신호를 찾는 데 활용될 수 있지만, 실제 의학적 인과관계를 확인하기 위해서는 추가적인 평가가 필요하다.
2027년 AI 의약품 개발 실행계획 발표 예정
MHRA는 2027년에 AI Medicines Development Action Plan을 발표할 계획이다.
이 계획에는 AI를 이용한 의약품 개발과 평가를 규제 체계에 어떻게 반영할지에 관한 구체적인 내용이 포함될 예정이다.
기관 내부의 업무 효율화도 추진한다.
예를 들어 일부 과학적 자문 서비스의 처리 기간을 기존 90일에서 45일로 줄이고, 조건을 충족하는 초기 임상시험의 최초 평가 목표도 14일로 단축하는 계획을 제시했다.
이러한 변화는 AI 기술 도입뿐 아니라 업무 절차와 규제 체계 전체의 개편을 포함한다.
이번 발표는 의료 AI 규제가 단순히 새로운 AI 제품의 출시를 허가하거나 금지하는 방식에서 벗어나고 있다는 점을 보여준다.
규제기관이 AI 의료기기를 평가하는 동시에 자체 심사와 안전 감시 업무에도 AI를 활용하는 방향으로 발전하고 있다.
특히 의료 AI는 사람의 건강과 생명에 직접적인 영향을 줄 수 있으므로, 새로운 기술을 빠르게 도입하는 것과 검증 가능한 안전 기준을 유지하는 것 사이의 균형이 중요하다.
📚 추천 글
Are Harnesses Worth the Cost?
- 저자: Naresh Jain
- 발행: Martin Fowler's Website
- 게시일: 2026-10-13
- 원문: Martin Fowler — Are Harnesses Worth the Cost?
코딩 에이전트에 상세한 지침과 자동화 테스트를 제공하면 언제나 더 좋은 결과를 얻을 수 있을까?
이 글은 그런 가정을 실제 실험으로 검증한다.
저자 Naresh Jain은 같은 백엔드 서비스를 AI 코딩 에이전트가 여러 번 만들도록 하고, 하네스가 있는 환경과 없는 환경의 결과를 비교했다.
여기서 Harness(하네스)는 모델이 작업을 수행하는 과정에 필요한 지침, 도구, 실행 제약과 검증 절차를 결합한 시스템이다.
예를 들어 개발자가 코딩 에이전트에게 API 서버를 만들라고 요청할 때 단순히 요구사항만 전달할 수도 있다.
반대로 API 명세, 예제 데이터, 테스트 환경과 오류를 확인할 수 있는 도구를 함께 제공할 수도 있다.
후자가 하네스를 적극적으로 활용하는 방식이다.
동일한 백엔드 서비스를 10번씩 구현
실험에 사용된 과제는 상품 검색용 BFF(Backend for Frontend)를 만드는 것이었다.
BFF는 프런트엔드의 요구사항에 맞춰 여러 백엔드 서비스를 연결하고 데이터를 가공하는 서버 계층이다.
이번 과제에서는 클라이언트가 호출하는 HTTP API를 만들고, 기존 Order API와 통신하며, 필요한 정보를 Kafka에 발행해야 했다.
Kafka는 여러 서비스 사이에서 이벤트와 데이터를 전달하는 메시징 시스템이다.
단순히 API 응답을 반환하는 것뿐 아니라 입력값 검증, 외부 API 실패 처리, 재시도와 비동기 작업 결과 확인까지 구현해야 했다.
저자는 이러한 요구사항을 바탕으로 178개의 외부 자동화 테스트를 준비했다.
이 테스트는 에이전트가 개발 과정에서 사용하는 테스트와 별도로 관리됐다.
따라서 에이전트가 자신의 구현에 맞춰 테스트를 수정해 통과하는 상황을 방지할 수 있었다.
하네스가 제공되는 환경에서는 OpenAPI와 AsyncAPI 명세, 실행 가능한 예제와 모의 서버를 사용했다.
OpenAPI는 HTTP API의 요청과 응답 구조를 정의하는 표준이고, AsyncAPI는 메시지 기반 시스템의 통신 규칙을 정의하는 표준이다.
에이전트는 이를 이용해 자신의 구현이 실제 요구사항을 충족하는지 중간에 확인할 수 있었다.
큰 모델에서는 하네스가 오히려 비쌌다
첫 번째 평가 대상은 GPT-6 Sol이었다.
결과는 예상과 달랐다.
하네스가 없는 환경에서도 10번의 실행 모두 178개 테스트를 통과했다.
하네스가 있는 환경에서도 똑같이 10번 모두 통과했다.
하지만 비용과 시간에는 큰 차이가 있었다.
하네스가 없는 경우 작업당 평균 비용은 약 0.406달러, 시간은 약 6분51초였다.
하네스를 사용하면 작업당 평균 비용이 약 2.679달러, 시간은 약 19분53초로 증가했다.
입력과 출력에 사용된 토큰도 약 10.5배 많아졌다.
즉 이 과제에서는 큰 모델이 이미 충분한 성능을 가지고 있었기 때문에 하네스가 성공률을 높이지 못했다.
오히려 추가적인 검증과 반복 작업으로 비용만 증가했다.
이 결과는 하네스를 많이 제공할수록 항상 효율적인 것은 아니라는 점을 보여준다.
작은 모델에서는 성공률이 크게 증가
두 번째 평가 대상은 비용 효율성을 우선하는 GPT-6 Luna였다.
이 모델에서는 결과가 크게 달라졌다.
하네스 없이 실행한 경우 10번 중 3번만 모든 테스트를 통과했다.
반면 하네스를 사용한 경우 10번 모두 통과했다.
하네스가 없는 Luna도 대부분의 기능은 올바르게 구현했다.
실패한 경우에도 전체 테스트의 약 94.8%를 통과했으며, 주로 비동기 처리와 API 사이의 연결처럼 세부적인 조건에서 문제가 발생했다.
예를 들어 외부 API가 시간 초과를 반환했을 때 요청을 완전히 실패로 처리하는 대신, 백그라운드에서 작업을 이어가고 사용자가 나중에 결과를 확인할 수 있도록 해야 했다.
이런 예외 상황에서 하네스가 제공한 테스트와 피드백이 도움이 됐다.
하네스를 사용한 Luna의 작업당 평균 비용은 약 0.273달러였다.
하네스가 없는 Luna의 비용인 0.086달러보다 높았지만, 하네스가 없는 Sol의 0.406달러보다는 약 33% 낮았다.
이번 실험에서는 작은 모델에 하네스를 제공하는 방식이 큰 모델을 그대로 사용하는 것보다 저렴하면서도 같은 성공률을 기록했다.
다만 이 결과는 하나의 백엔드 과제를 각 조건에서 10번 실행한 실험이다.
모든 개발 작업에서 작은 모델과 하네스를 사용하면 큰 모델보다 저렴하고 정확하다는 뜻은 아니다.
또한 성공 여부는 준비된 178개 테스트를 모두 통과했는지에 따라 결정했다.
실제 운영에서 발생할 수 있는 모든 종류의 문제까지 검증한 것은 아니다.
하네스의 가치는 모델과 작업에 따라 달라진다
저자는 이번 실험을 통해 하네스의 역할을 두 가지로 구분한다.
첫 번째는 Guides(가이드)다.
모델이 작업을 시작하기 전에 올바른 설계 방향과 요구사항을 이해하도록 돕는다.
두 번째는 Sensors(센서)다.
모델이 작업을 수행한 뒤 실제 결과가 요구사항을 충족하는지 검사한다.
특히 저자는 가이드와 센서가 서로 모순되지 않도록 만드는 것이 중요하다고 설명한다.
예를 들어 API 명세에는 특정 오류에서 503을 반환해야 한다고 정의돼 있는데 테스트에는 500을 기대하도록 작성돼 있다면 에이전트는 잘못된 피드백을 받게 된다.
그래서 이번 실험에서는 테스트가 API 명세와 예제에서 자동으로 생성되도록 구성했다.
이는 AI 코딩 에이전트의 품질을 개선하는 방법이 단순히 프롬프트를 더 자세하게 작성하는 데 그치지 않음을 보여준다.
검증 가능한 요구사항과 독립적인 테스트를 제공하는 것이 특정 모델의 부족한 능력을 보완할 수 있다는 것이다.
동시에 이미 충분한 능력을 가진 모델에서는 같은 구조가 불필요한 비용이 될 수 있다.
이 글은 AI 코딩 도구를 선택하거나 하네스를 설계할 때 모델 가격만 보는 대신 최종적으로 성공한 작업 하나를 얻는 데 드는 전체 비용을 비교해야 한다는 관점을 제공한다.
Optimizing Agent Reliability and Tool Calling Efficiency for Chip Design Using NVIDIA NeMo Gym
- 저자: Joshua Mabry, Chris Wing, Niranjan Sitapure, Kenton DeLathouwer, Ming Ming Zhang
- 발행: NVIDIA Technical Blog
- 게시일: 2026-10-14
- 원문: NVIDIA — Optimizing Agent Reliability and Tool Calling Efficiency for Chip Design Using NVIDIA NeMo Gym
AI 에이전트가 여러 전문 도구를 연결해 복잡한 업무를 수행할 때 모델을 변경하지 않고도 안정성과 효율성을 얼마나 개선할 수 있는지 보여주는 기술 글이다.
NVIDIA와 Siemens는 반도체 설계 작업을 수행하는 AI 에이전트에 NeMo Gym을 적용했다.
NeMo Gym은 AI 에이전트의 실행 환경과 작업, 평가 기준을 정의하고 반복적으로 성능을 측정하기 위한 오픈소스 도구다.
이번 사례에서는 Siemens의 반도체 설계 도구인 Solido Characterization Suite와 AI 에이전트를 연결했다.
반도체 설계에서 가장 중요한 것은 최종 결과의 정확성
반도체를 설계할 때는 개별 논리회로가 어느 정도의 전력을 소비하고 얼마나 빠르게 동작하는지 확인해야 한다.
이를 Standard-Cell Characterization(표준 셀 특성 분석)이라고 한다.
반도체 제조사는 새로운 공정이 도입될 때마다 설계 규칙과 트랜지스터 특성을 정의한 PDK(Process Design Kit)를 제공한다.
설계자는 이 정보를 이용해 다양한 전압과 온도, 제조 조건에서 회로가 어떻게 작동하는지 시뮬레이션한다.
이 조건들을 PVT(Process, Voltage, Temperature)라고 한다.
문제는 확인해야 하는 조합이 매우 많다는 것이다.
예를 들어 이번 평가에 사용된 데이터에는 229개의 표준 셀과 36개의 PVT 조건이 포함됐다.
AI 에이전트는 필요한 도구를 설정하고 시뮬레이션을 실행한 뒤, 각 셀의 동작 정보를 파일로 정리해야 한다.
이때 생성되는 대표적인 결과물이 Liberty 파일(.lib)이다.
Liberty 파일에는 반도체 설계 도구가 사용할 수 있는 회로의 타이밍과 전력 특성이 기록된다.
문제는 에이전트가 실행한 중간 명령들이 모두 성공했다고 해서 최종 Liberty 파일까지 정확하다고 볼 수 없다는 점이다.
예를 들어 일부 셀의 결과가 누락되거나 특정 온도 조건의 계산이 잘못됐을 수 있다.
파일의 형식은 올바르지만 실제 수치가 틀린 경우도 가능하다.
이런 오류는 단순히 프로그램이 정상 종료됐는지만 확인해서는 발견하기 어렵다.
최종 결과물을 기준으로 평가
NVIDIA와 Siemens는 NeMo Gym을 이용해 최종 Liberty 파일의 정확성을 평가하는 검증기(Verifier)를 만들었다.
검증 기준은 크게 다섯 가지였다.
첫 번째는 필요한 셀과 PVT 조건이 모두 포함됐는지 확인하는 Coverage다.
두 번째는 파일 형식이 올바르고 실제 도구에서 사용할 수 있는지 확인하는 Validity다.
세 번째는 기준 결과보다 새로운 오류가 발생하지 않았는지 확인하는 Relative Validation이다.
네 번째는 실제 수치가 허용된 오차 범위 안에 들어오는지 측정하는 Accuracy다.
마지막은 결과를 일부만 복사하거나 기존 값을 재사용하지 않고 정상적인 시뮬레이션 과정을 거쳤는지 확인하는 Integrity다.
이 검증기는 중요한 조건 가운데 하나라도 실패하면 전체 점수를 0으로 처리한다.
이는 에이전트가 일부 작업만 성공한 뒤 전체 작업을 완료한 것처럼 보고하는 문제를 방지하기 위한 설계다.
모델은 그대로 두고 도구 사용 방법 개선
연구팀은 모델 자체를 새로 학습시키지 않았다.
실험에서는 Claude Opus 4.8과 Claude Code를 고정해서 사용했다.
대신 에이전트가 참고하는 지침과 도구 설명을 반복적으로 수정했다.
도구 연결에는 MCP(Model Context Protocol)를 사용했다.
MCP는 AI 에이전트가 외부 프로그램과 데이터를 호출할 수 있도록 하는 표준화된 통신 규격이다.
초기에는 비슷한 역할을 하는 도구가 여러 개 존재해 모델이 잘못된 도구를 선택하거나 불필요한 명령을 반복하는 문제가 발생했다.
연구팀은 각 도구의 역할을 더 명확하게 구분하고 입력값을 JSON Schema로 정의했다.
JSON Schema는 JSON 데이터가 어떤 필드와 자료형을 가져야 하는지 정의하는 규칙이다.
또한 실패한 실행 기록을 분석해 에이전트가 어떤 단계에서 잘못된 판단을 내렸는지 확인했다.
이후 지침과 도구 설명을 수정하고 같은 평가를 다시 실행했다.
연구팀은 약 25번의 실행을 통해 구조를 개선했다.
평가에서는 전체 데이터 가운데 대표적인 셀 두 개와 36개 PVT 조건을 사용했다.
각 실행에는 약 1.5~2시간이 걸렸다.
최종 결과는 다음과 같았다.
| 항목 | 개선 전 | 개선 후 |
|---|---|---|
| 검증 점수 | 약 55% | 약 95% |
| 에이전트 실행 단계 | 155회 | 53회 |
| 출력 토큰 | 약 81,000 | 약 29,000 |
검증 점수는 약 40%포인트 증가했고, 에이전트 실행 단계는 약 66% 감소했다.
출력 토큰도 약 64% 감소했다.
이 수치는 NVIDIA와 Siemens가 특정 반도체 설계 작업에서 수행한 자체 평가 결과다.
모든 에이전트의 성능이 같은 비율로 향상된다는 뜻은 아니다.
또한 사용한 모델의 일반적인 추론 능력이 향상된 것이 아니라 같은 모델이 도구를 더 정확하고 효율적으로 사용하도록 실행 환경을 개선한 결과다.
이번 글에서 중요한 부분은 AI 에이전트의 성공을 개별 도구 호출의 성공 여부로 평가해서는 충분하지 않다는 점이다.
실제 기업 업무에서는 여러 단계가 모두 정상적으로 연결돼 최종 결과물이 사용 가능한 상태로 완성되는지가 중요하다.
특히 AI 에이전트가 생성한 결과가 겉보기에는 그럴듯하지만 실제로는 일부 정보가 빠져 있을 수 있는 전문 업무에서 유용한 접근이다.
Impactful scheduling for GPU clusters
- 저자: Kyle Wiggers / Allen Institute for AI
- 발행: Hugging Face
- 게시일: 2026-10-09
- 원문: Allen Institute for AI — Impactful scheduling for GPU clusters
AI 연구기관이 확보한 GPU를 여러 연구자에게 어떻게 공정하게 나눠줄 수 있을까?
이 글은 이 문제를 단순한 기술적 자원 배분이 아니라 조직의 목표와 연구 우선순위, 사람의 행동이 결합된 문제로 설명한다.
Ai2는 수천 개의 NVIDIA H100, B200, B300 GPU를 운영하고 있다.
클러스터 규모는 약 88개에서 1,024개 GPU까지 다양하며, 약 150명의 연구자가 이를 사용한다.
연구 대상에는 언어모델, 비전모델, 로봇 강화학습과 과학 연구용 AI 에이전트 등이 포함된다.
문제는 필요한 GPU가 항상 충분하지 않다는 점이다.
Ai2에 따르면 특정 시점에 제출된 작업들이 요구하는 GPU의 수는 실제로 사용 가능한 GPU의 약 2~3배다.
따라서 모든 연구 작업을 즉시 실행할 수 없다.
스케줄러는 어떤 작업을 먼저 실행할지 결정해야 한다.
기존 우선순위 시스템이 실패한 이유
처음에 Ai2는 일반적인 우선순위 기반 스케줄러를 사용했다.
연구자는 자신의 작업을 HIGH나 LOW 같은 우선순위로 지정할 수 있었다.
중요한 연구에 높은 우선순위를 제공하고 덜 중요한 작업은 나중에 실행하도록 만드는 방식이다.
하지만 실제 운영에서는 예상하지 못한 문제가 발생했다.
시간이 지나면서 실행 중인 거의 모든 작업이 HIGH 우선순위를 사용하기 시작했다.
모두 높은 우선순위를 선택하면 우선순위 자체가 의미를 잃는다.
또한 일부 연구자는 필요할 때 즉시 GPU를 사용할 수 있도록 아무 계산도 하지 않는 작업을 실행해 GPU를 미리 점유했다.
이를 GPU Squatting(GPU 자원 선점)이라고 한다.
개별 연구자에게는 합리적인 행동일 수 있다.
하지만 전체 조직에서는 실제 연구에 사용할 수 있는 GPU가 줄어드는 결과를 만든다.
이런 상황은 경제학에서 말하는 Tragedy of the Commons(공유지의 비극)와 비슷하다.
여러 사람이 공동으로 사용하는 자원을 각자 자신의 이익을 위해 최대한 확보하려다 전체 효율이 떨어지는 현상이다.
GPU 개수 대신 사용 시간을 예산으로 배분
Ai2는 해결책으로 GPU 자체를 고정적으로 나눠주는 대신 GPU 사용 시간을 예산으로 배분하는 방식을 도입했다.
예를 들어 특정 연구 프로젝트에 전체 GPU 시간의 35%를 할당할 수 있다.
이 프로젝트는 항상 전체 GPU의 35%를 점유하는 것은 아니다.
실제 작업이 없을 때는 다른 연구팀이 자원을 사용할 수 있다.
반대로 해당 프로젝트가 많은 작업을 제출하면 자신에게 배정된 시간 예산을 기준으로 적절한 우선순위를 받을 수 있다.
이 방식에서는 자원을 점유하는 행동에도 비용이 발생한다.
아무 작업도 하지 않는 프로그램을 실행해 GPU를 선점한다면 그 시간은 연구팀의 예산에서 차감된다.
따라서 GPU를 미리 점유하는 행동이 개인에게도 불리해질 수 있다.
Ai2는 이를 위해 Hierarchical Fair-Share Scheduling(계층적 공정 배분 스케줄링)을 사용했다.
조직의 연구 프로그램과 하위 프로젝트에 시간 예산을 배분하고, 실제 사용량에 따라 다음 작업의 우선순위를 조정하는 방식이다.
스케줄러는 기본적으로 최근 7일 동안의 사용량을 확인한다.
배정된 예산에 비해 자원을 덜 사용한 프로젝트는 상대적으로 높은 우선순위를 받는다.
반대로 이미 충분한 시간을 사용한 프로젝트는 다른 팀의 작업을 먼저 실행하도록 조정된다.
오랫동안 실행되는 학습 작업도 관리
AI 모델 학습은 몇 분 만에 완료되는 작업만 있는 것이 아니다.
대규모 모델의 학습은 며칠 또는 몇 주 동안 이어질 수 있다.
따라서 새로운 작업에 GPU를 배정하려고 실행 중인 학습을 즉시 중단하면 그동안의 계산 결과가 낭비될 수 있다.
Ai2는 이를 해결하기 위해 Scheduling Contract(스케줄링 계약)라는 방식을 도입했다.
연구자가 작업을 제출할 때 최소한 얼마 동안 GPU를 사용해야 의미 있는 진행이 가능한지 선언하도록 하는 방식이다.
예를 들어 어떤 학습 작업이 최소 4시간은 실행돼야 중간 결과를 저장할 수 있다면, 그동안은 다른 작업이 GPU를 빼앗지 못하도록 보호할 수 있다.
하지만 최소 실행 시간이 지나면 스케줄러가 필요에 따라 작업을 중단하고 다시 대기열에 넣을 수 있다.
이를 Preemption(선점 또는 실행 중단 후 재배치)이라고 한다.
이 구조에서는 연구자가 학습 상태를 저장하고 나중에 재개할 수 있도록 설계하는 것이 중요해진다.
또한 유지보수가 필요한 서버에서도 실행 중인 작업을 정해진 시점에 종료하고 GPU를 비울 수 있다.
Ai2는 이 방식을 적용한 뒤 사람이 직접 개입해야 하는 장비 수리 작업이 74% 감소했다고 밝혔다.
기존에는 서버를 수리하기 위해 연구자와 작업 종료 시점을 협의해야 하는 경우가 많았다.
새로운 구조에서는 정해진 최소 실행 시간이 끝난 뒤 자동으로 작업을 이동시킬 수 있었기 때문이다.
사용률이 아니라 연구 성과를 고려
Ai2는 GPU 운영 상태를 네 가지 기준으로 구분한다.
Availability(가용성)는 장비가 정상적으로 사용할 수 있는 상태인지 나타낸다.
Occupancy(점유율)는 실제로 GPU가 특정 작업에 할당된 시간의 비율이다.
Impact(영향 또는 가치)는 조직에서 중요하게 평가하는 연구가 자원을 확보하고 있는지 나타낸다.
마지막 Utilization(활용률)은 GPU가 할당된 동안 실제 계산에 얼마나 사용됐는지를 의미한다.
이 구분이 중요한 이유는 GPU 점유율이 높다고 해서 반드시 연구 성과가 높아지는 것은 아니기 때문이다.
GPU를 계속 점유하고 있지만 실제로 의미 있는 계산을 거의 수행하지 않는 작업도 존재할 수 있다.
반대로 매우 중요한 연구가 짧은 시간 동안만 GPU를 사용하더라도 큰 성과를 만들 수 있다.
Ai2는 단순한 GPU 점유율을 최대화하는 것보다 제한된 GPU 자원을 연구기관의 목표에 맞게 배분하는 것이 중요하다고 설명한다.
이번 글은 AI 인프라 운영이 서버와 스케줄러의 기술적 설정만으로 해결되지 않는다는 점을 보여준다.
사용자의 행동과 조직의 의사결정, 자원 배분에 대한 인센티브까지 함께 설계해야 전체 시스템이 효율적으로 운영될 수 있다는 사례다.
OCP Summit 2026: Powering AI with Open Innovations in Scale-Up, Scale-Out, and Scale-Across Networks
- 저자·발행: Meta Network Infrastructure Team / Meta Engineering
- 게시일: 2026-10-12
- 원문: Meta Engineering — OCP Summit 2026: Powering AI with Open Innovations in Scale-Up, Scale-Out, and Scale-Across Networks
대규모 AI 모델의 학습 속도를 높이는 데는 GPU의 연산 성능만큼 GPU 사이의 네트워크 성능도 중요하다.
최근 프런티어 모델은 수천 개 이상의 GPU에 나뉘어 학습된다.
각 GPU는 모델의 일부 계산을 수행하고 다른 GPU와 계산 결과를 주고받는다.
그런데 GPU가 아무리 빠르게 계산하더라도 다른 GPU에서 데이터가 도착하기를 기다리는 시간이 길어지면 전체 학습 속도가 떨어질 수 있다.
이 글은 Meta가 자체 AI 데이터센터에서 이런 문제를 해결하기 위해 개발한 네트워크 기술과 오픈소스 프로젝트를 설명한다.
특히 하나의 서버 안에서 GPU를 연결하는 기술부터 여러 지역의 데이터센터를 하나의 학습 시스템으로 묶는 기술까지 다룬다.
GPU 사이의 거리에 따라 달라지는 네트워크
AI 데이터센터의 네트워크는 크게 세 단계로 구분할 수 있다.
Scale-Up은 같은 서버나 랙 안의 GPU를 매우 빠르게 연결하는 방식이다.
Scale-Out은 여러 서버와 랙을 연결해 더 큰 GPU 클러스터를 만드는 방식이다.
Scale-Across는 서로 다른 건물이나 지역의 데이터센터를 연결하는 방식이다.
각 단계는 해결해야 하는 문제가 다르다.
Scale-Up에서는 매우 짧은 지연시간과 높은 대역폭이 중요하다.
Scale-Out에서는 수많은 GPU가 동시에 데이터를 주고받을 때 네트워크가 혼잡해지지 않도록 관리해야 한다.
Scale-Across에서는 물리적인 거리가 길어지면서 발생하는 지연시간과 장비 장애를 관리해야 한다.
Meta는 이런 환경에서 독점적인 네트워크 기술에만 의존하지 않고 Ethernet 기반의 개방형 구조를 확대하려 한다.
102.4Tbps 스위치와 액체 냉각
이번 글에서 소개하는 하드웨어 가운데 하나는 IcePack이다.
IcePack은 Meta의 새로운 액체 냉각 네트워크 랙이다.
그 안에는 IceCube라는 네트워크 스위치가 설치된다.
IceCube는 초당 102.4Tbps의 데이터를 처리할 수 있도록 설계됐다.
이는 이전 세대 51.2Tbps 스위치의 두 배에 해당하는 대역폭이다.
네트워크 스위치는 여러 컴퓨터와 서버 사이에서 데이터를 전달하는 장비다.
대규모 GPU 클러스터에서는 수많은 장치가 동시에 데이터를 교환하기 때문에 스위치의 처리 능력이 중요하다.
하지만 대역폭을 높이면 장비의 전력 소비와 발열도 문제가 된다.
Meta는 이를 해결하기 위해 스위치 장비에도 액체 냉각을 도입했다.
일반적으로 AI 데이터센터의 액체 냉각은 GPU 서버에 많이 사용되지만, 네트워크 장비도 점점 더 높은 전력을 소비하고 있기 때문이다.
IceCube는 Broadcom과 NVIDIA의 서로 다른 스위치 반도체를 사용하는 구성을 지원한다.
운영체제는 Meta가 공개한 오픈소스 네트워크 운영체제 FBOSS를 사용한다.
이처럼 여러 제조사의 하드웨어를 같은 운영 소프트웨어로 관리하려는 접근은 AI 데이터센터의 장비 선택과 유지보수에 영향을 줄 수 있다.
GPU를 여덟 개의 네트워크 경로로 연결
Meta는 새로운 Flattened Planar Fabric(FPF)도 공개했다.
기존 대규모 네트워크는 여러 단계의 스위치를 거쳐 데이터를 전달하는 계층형 구조를 사용한다.
그러나 데이터가 여러 스위치를 통과할수록 지연시간과 운영 비용이 증가할 수 있다.
FPF는 GPU 하나를 서로 독립적인 여덟 개의 100Gbps 네트워크 경로로 연결하는 방식이다.
이렇게 하면 GPU가 데이터를 여러 경로에 분산해서 전달할 수 있다.
또한 네트워크 경로 하나에 문제가 발생하더라도 다른 경로를 활용할 수 있다.
Meta는 기존의 3단계 Clos 네트워크를 2단계 구조로 단순화해 데이터가 통과해야 하는 스위치 수를 줄였다고 설명한다.
Clos Network(클로스 네트워크)는 여러 단계의 스위치를 이용해 많은 장치를 효율적으로 연결하는 네트워크 구조다.
Meta는 NVIDIA와 협력해 이 구조를 실제 인프라에 적용했으며, 향후 다른 클라우드 사업자도 유사한 방식을 사용할 수 있도록 설계 경험을 공유하고 있다.
여러 지역의 데이터센터를 연결
데이터센터가 커질수록 하나의 건물에 모든 GPU를 설치하는 것이 어려워진다.
전력 공급과 냉각, 물리적인 공간의 제약 때문이다.
Meta는 이를 해결하기 위해 서로 다른 건물과 지역의 데이터센터를 하나의 대규모 AI 학습 시스템으로 연결하고 있다.
여기에는 BAG(Backend Aggregation)라는 네트워크 계층이 사용된다.
BAG는 여러 데이터센터 네트워크를 연결하는 대규모 통신 구조다.
Meta는 일부 지역 사이에서 수십 페타비트 수준의 통신 용량을 제공하도록 설계했다고 설명한다.
Petabit(페타비트)는 1,000조 비트에 해당하는 데이터 단위다.
하지만 거리가 멀어지면 단순히 통신 용량만 늘린다고 문제가 해결되는 것은 아니다.
데이터가 이동하는 시간이 늘어나고, 네트워크 경로마다 지연시간이 달라질 수 있기 때문이다.
대규모 모델 학습에서는 여러 GPU가 서로 계산 결과를 기다리는 경우가 많아 일부 경로의 지연이 전체 작업에 영향을 줄 수 있다.
Meta는 이를 해결하기 위해 실제 케이블 길이를 측정해 네트워크 버퍼를 설정하고, 장애가 발생한 경로의 남은 처리 능력에 맞춰 트래픽을 분산하는 방법을 사용한다.
또한 가능하면 물리적으로 가까운 GPU끼리 더 많은 데이터를 교환하도록 작업 배치와 통신 구조를 최적화한다.
개방형 네트워크 표준과 MetaRoCE
이번 글에서는 MetaRoCE도 소개한다.
RoCE는 RDMA over Converged Ethernet의 약자다.
RDMA는 서버의 CPU를 많이 거치지 않고 다른 서버의 메모리와 직접 데이터를 교환하도록 돕는 기술이다.
AI 모델 학습에서는 GPU 사이에서 많은 데이터를 빠르게 주고받아야 하므로 RDMA가 중요하다.
MetaRoCE는 Meta가 AI 클러스터에 맞춰 개발한 Ethernet 기반 통신 기술이다.
Meta는 이번에 해당 기술의 오픈소스 구현을 공개했다고 밝혔다.
또한 Microsoft, Alibaba와 함께 OSPA(Open Switch Platform Architecture)라는 새로운 개방형 표준화 작업도 추진한다.
OSPA는 네트워크 스위치의 전력 관리, 센서, 펌웨어와 하드웨어 제어를 위한 공통 인터페이스를 정의하려는 프로젝트다.
이를 통해 서로 다른 제조사의 네트워크 장비를 사용하더라도 운영 소프트웨어와 관리 도구를 재사용할 수 있도록 하려는 것이다.
이번 글은 AI 인프라의 확장이 단순히 GPU를 더 많이 구매하는 문제만은 아니라는 점을 보여준다.
수천 개의 GPU가 실제로 하나의 모델을 효율적으로 학습하려면 연산 장치 사이의 통신, 장애 대응, 전력과 냉각, 네트워크 표준화가 함께 발전해야 한다.
특히 서로 다른 제조사와 지역의 인프라를 연결하는 개방형 기술이 AI 데이터센터의 핵심 경쟁 요소로 떠오르고 있다는 점을 이해하기 좋은 자료다.