2026년 2월 17일 오늘의 AI 뉴스

요즘 키워드는 딱 두 개야. 더 깊게 생각하는 모델(Deep Think류)과, 에이전트가 실전에서 쓸 수 있는 평가/툴체인(환경 + 커스텀 커널)로 빠르게 수렴 중.

Gemini 3 Deep Think 업그레이드: “추론 모드”를 연구/엔지니어링 쪽으로 밀어 넣기

구글이 Gemini 3 Deep Think를 “특화된 추론 모드”로 포지셔닝하면서 큰 업그레이드를 공개했어. 문장 자체는 담백한데, 뉘앙스는 꽤 공격적이야. 이제 모델 경쟁이 “모델 크기”보다 “어떤 사고방식(추론 프로파일)을 언제 켜고, 어디에 적용해서 성과를 내는지”로 넘어갔다는 신호처럼 보이거든.

개발자 입장에서 제일 중요한 포인트는 이거야.

“추론 모드”가 그냥 버튼이 아니라 제품/워크플로에 녹아 들어가는 순간, 사용자는 모델을 선택하지 않고 상태를 전환하게 된다.
그러면 인프라/비용 모델도 바뀐다. 평상시엔 빠른 모드로 땡기고, 정말 어려운 구간에서만 Deep Think를 켠다. 즉, 서비스 설계가 자연스럽게 동적 라우팅(workload routing)으로 간다.
연구/엔지니어링을 언급했다는 건, “정답이 있는 문제”와 “검증 가능한 결과물”에서 성과를 보여주겠다는 말이기도 해. 이런 영역은 결국 평가/검증 파이프라인이 붙어야 하고, 붙는 순간 운영 역량(데이터/테스트/관측)이 승부를 가른다.

개인적으로는 ‘Deep Think’ 같은 이름이 유치하다고 생각하면서도(솔직히 그래), 이건 마케팅보다도 제품 구조 변화에 가깝다고 봐. 이제 프롬프트 잘 쓰는 사람보다, 일을 잘 쪼개서 “빠른 모드로 될 것/안 될 것”을 판별하고, 안 되는 것만 깊게 태우는 사람이 이긴다.

Hugging Face: Codex/Claude로 “커스텀 CUDA 커널”을 만들고, 에이전트 스킬로 굳히기

허깅페이스 블로그에선 Codex와 Claude 같은 코드 생성 모델을 이용해 커스텀 CUDA 커널을 만들고, 그 과정을 “누구나 재현 가능한 형태”로 가져가려는 흐름을 다뤘어. 그냥 “AI가 코드 짜줌” 수준을 넘어서서, 이제는 성능 병목을 직접 찍어 누르는 영역(커널/런타임 최적화)에까지 에이전트가 침투하는 느낌이야.

여기서 재밌는 건 ‘커널 생성’ 자체보다 파이프라인이야.

커널은 틀리면 조용히 느려지는 게 아니라, 크게 깨지거나(정확도), 드라이버/환경에서 폭발한다.
그래서 결국 필요한 건 생성 + 테스트 + 벤치마크 + 롤백까지 포함된 “도구 연결”인데, 이걸 에이전트 스킬로 묶으면 사람 손을 크게 줄일 수 있다.
즉, AI 코딩의 다음 단계는 IDE 안에서 자동완성이 아니라, CI/CD로 성능 개선을 반복하는 자동화가 된다.

물론 위험도 있다. “빠르게 만들어서 빨리 태운다”는 사이클이 커널 수준으로 내려가면, 실수의 비용도 커져. 그래서 난 오히려 이 흐름이 ‘모델이 똑똑해졌다’보다, ‘검증과 자동화가 이제 기본값이 됐다’로 읽혀.

Hugging Face: OpenEnv 실전편 — 툴 쓰는 에이전트를 어떻게 “현실적인 환경”에서 평가할까

에이전트가 툴을 쓴다고 할 때, 진짜 문제는 기능 데모가 아니라 “반복 가능한 평가”야. OpenEnv 관련 글은 이런 부분을 정면으로 건드려.

정리하면, 에이전트를 평가하려면 최소한 아래가 필요해.

환경이 deterministically 재현돼야 한다(같은 입력이면 비슷한 결과가 나와야 함)
성공/실패 판정이 자동화돼야 한다(사람이 매번 채점하면 그건 연구고, 제품은 못 됨)
툴 호출 로그/중간 상태가 남아야 한다(왜 실패했는지 알아야 개선이 가능)

이건 그냥 “벤치마크 만들자”가 아니고, 제품 팀이 바로 쓰는 품질 체계(quality system) 얘기야. 에이전트가 일을 망치면, 사용자 입장에선 ‘오류 메시지’가 아니라 ‘시간을 날린 경험’으로 남거든.

그리고 나는 여기서 한 가지 결론을 또 봐.

에이전트 경쟁은 모델 파라미터가 아니라, 환경 설계 + 평가 설계 + 운영 설계(관측/리트라이/권한/세이프가드)가 된다.

arXiv: VeRA — “정적 벤치마크”를 끝내고, 검증 가능한 문제 생성기로 바꾸기

VeRA(Verified Reasoning Data Augmentation)는 벤치마크의 근본적인 약점을 찌르는 아이디어야. 지금까지 많은 평가는 ‘문제를 고정해 놓고’ 모델을 계속 갈아 넣는 방식이었지. 그러다 보면 당연히 오염(contamination)과 암기(memorization) 문제가 커져. 모델이 똑똑해진 건지, 문제를 외운 건지 구분이 흐려진다.

VeRA는 접근이 다르다.

문제를 “실행 가능한 명세”로 바꾼다.
템플릿 + 파라미터 생성기 + 결정적 검증기(정답 계산기)를 둔다.
그러면 같은 씨드(seed)에서 무한히 많은 검증된 변형 문제를 뽑을 수 있다.

이게 실무에 주는 메시지는 명확해.

모델 평가를 ‘데이터셋’이 아니라 ‘테스트 프레임워크’로 보자.
정답이 계산 가능한 영역에선, 사람 라벨링을 줄이고 “검증기”로 품질을 올릴 수 있다.

개인적으로 VeRA의 매력은, 이게 단순히 연구자의 장난이 아니라는 점이야. 제품에서도 동일하게 쓰이거든. 예를 들면 규칙 기반 계산(세금/정산/스케줄링/권한) 같은 건, 템플릿+검증기로 “신선한 테스트”를 계속 만들어낼 수 있어. 모델이 바뀌어도, 평가가 썩지 않는다.

arXiv: LLM 환각의 기하학적 분류 — 탐지 가능한 것과, 원리적으로 어려운 것

“환각(hallucination)”이라는 단어가 너무 만능이라서 문제였는데, 이 논문은 그걸 세 타입으로 나눠서 보자고 해.

문맥을 제대로 안 읽는 불충실(provided context에 engagement 실패)
아예 다른 의미 영역의 내용을 만들어내는 날조/꾸며냄(topical drift)
개념 프레임은 맞는데 사실이 틀리는 사실 오류

흥미로운 관찰은 이거야.

벤치마크에서 생성된 환각을 탐지하면 도메인 안에서는 점수가 잘 나오는데, 도메인이 바뀌면 급격히 무너질 수 있다.
반대로 사람이 만든 “진짜 날조”는 도메인이 달라도 잘 잡히는 방향(direction)이 존재할 수 있다.
그리고 타입 중 “사실 오류”는 임베딩만으로는 거의 구분이 안 될 수 있다(텍스트 분포만으로는 진실값을 모른다).

실무적으로는 꽤 잔인한 결론이야. “환각 탐지 모델 하나 붙이면 끝” 같은 꿈을 접게 만든다.

문맥 불충실/날조는 로그 + 임베딩/분류로 어느 정도 잡을 수 있다.
하지만 사실 오류는 결국 **외부 검증(검색, DB, 규칙, 출처 강제)**가 필요하다.

즉, 안전한 제품은 ‘더 똑똑한 모델’보다 검증 가능한 파이프라인을 가진 제품이 된다.

예상되는 미래 (Expected Future)

이번 흐름을 한 문장으로 줄이면 이거야.

추론은 “기능”이 아니라 “상태(state)”가 되고, 에이전트는 “데모”가 아니라 “운영 시스템”이 된다.

그래서 앞으로 중요한 건 모델 이름이 아니라, 아래 같은 설계 능력이라고 봐.

언제 깊게 생각하게 할지(Deep Think 같은 모드를 조건부로 태우는 라우팅)
에이전트가 쓰는 툴과 환경을 어떻게 표준화할지(OpenEnv 류의 재현 가능한 환경)
평가를 데이터셋이 아니라 생성/검증기로 만들지(VeRA 같은 검증 기반 평가)
환각을 “탐지”로 끝내지 않고 “검증”으로 닫을지(출처 강제, 외부 사실 확인)