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

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

---

1️⃣ 주요 모델·연구

Physical Superintelligence, AI가 18년 된 양자컴퓨팅 수학 난제의 증명을 생성했다고 발표…Lean 형식 검증 통과

• 발표일: 2026-11-06 — 정확한 게시 시각 미확인
• 적용 범위: AI 수학 연구, 양자컴퓨팅, 형식 검증, 자동 정리 증명, AI 연구 에이전트
• 원문: Physical Superintelligence — A proof of the Aaronson-Ambainis conjecture
• 관련 원문: GitHub — 증명 논문과 Lean 4 형식화 코드

AI 연구기업 Physical Superintelligence(PSI)가 2008년 제안된 Aaronson-Ambainis 추측의 증명을 AI 연구 시스템으로 생성했다고 발표했다.

이번 발표는 새로운 언어모델의 출시가 아니다. 기존에 해결되지 않았던 수학 문제에 대해 AI 시스템이 증명을 작성했고, 그 증명을 컴퓨터가 엄밀하게 검사할 수 있는 형태로 변환했다는 연구 결과다.

특히 PSI는 이번 연구에서 비공개 Anthropic 모델을 사용했다고 밝혔다. 모델 자체의 이름과 가중치는 공개하지 않았지만, 생성된 수학 논문과 형식 증명 코드는 외부에서 확인할 수 있도록 제공했다.

다만 이번 결과는 발표기관이 주장하는 수학적 성과이며, 아직 독립적인 학계의 검토가 완료된 것은 아니다.

Aaronson-Ambainis 추측이란 무엇인가

이 문제를 이해하려면 먼저 양자컴퓨터의 계산 방식부터 살펴볼 필요가 있다.

일반적인 컴퓨터는 0과 1로 표현되는 비트를 처리한다.

반면 양자컴퓨터는 중첩(Superposition)과 같은 양자역학적 성질을 이용한다. 중첩은 하나의 양자 상태가 여러 가능한 상태의 조합으로 표현될 수 있다는 개념이다.

양자컴퓨터는 특정한 문제에서 일반적인 컴퓨터보다 훨씬 적은 계산으로 결과를 얻을 수 있다.

대표적인 사례가 쇼어 알고리즘(Shor's Algorithm)이다.

쇼어 알고리즘은 큰 정수를 소인수분해하는 문제에서 알려진 고전적 방법보다 훨씬 효율적인 계산을 수행할 수 있다.

그런데 중요한 의문이 존재한다.

양자컴퓨터의 매우 큰 속도 향상은 특별한 수학적 구조를 가진 문제에서만 발생하는 것일까?

예를 들어 어떤 입력 데이터에 반복적인 패턴이 존재한다면 양자컴퓨터가 그 구조를 활용할 수 있다.

하지만 무작위로 생성된 일반적인 데이터에는 그런 구조가 존재하지 않을 수 있다.

Scott Aaronson과 Andris Ambainis는 2008년 이 문제와 연결되는 수학적 추측을 제안했다.

핵심은 다음과 같다.

복잡한 계산 결과를 표현하는 다항식이 완전히 일정한 값을 가지는 것이 아니라면, 입력 변수 가운데 적어도 하나는 결과에 충분히 큰 영향을 미쳐야 한다는 것이다.

여기서 다항식(Polynomial)은 여러 변수의 거듭제곱과 곱, 합으로 표현되는 수학적 식이다.

예를 들어 두 변수 x와 y가 있을 때 x² + 3xy + 2와 같은 식이 다항식이다.

이번 문제에서는 입력 변수가 0과 1 가운데 하나의 값을 가지며, 다항식의 결과는 0과 1 사이의 값으로 제한된다.

이런 다항식은 양자 알고리즘이 특정한 결과를 출력할 확률을 표현하는 데 활용할 수 있다.

중요한 변수가 존재한다는 사실을 증명

연구팀이 공개한 핵심 결과는 다항식의 Influence(변수의 영향도)에 관한 부등식이다.

영향도는 하나의 입력 비트를 변경했을 때 다항식의 결과가 평균적으로 얼마나 달라지는지 나타내는 값이다.

예를 들어 여러 개의 스위치가 하나의 계기판과 연결돼 있다고 생각할 수 있다.

각 스위치는 켜짐과 꺼짐의 두 상태를 가진다.

이때 특정한 스위치를 변경하면 계기판의 값이 크게 달라질 수 있다.

반대로 다른 스위치는 변경해도 결과에 거의 영향을 주지 않을 수 있다.

Aaronson-Ambainis 추측은 일정한 조건에서 충분히 큰 영향도를 가진 변수가 반드시 존재한다는 주장을 포함한다.

PSI가 제시한 결과는 다음 형태의 하한을 제공한다.

[
\operatorname{Inf}_i(f)
\geq
\frac{8\sqrt{15}}{125\pi^4}
\frac{v^{5/2}}{d^6}
\geq
\left(\frac{v}{d}\right)^7
]

여기서 d는 다항식의 차수, v는 다항식 출력의 분산을 나타낸다.

분산(Variance)은 값들이 평균을 중심으로 얼마나 퍼져 있는지 나타내는 통계적 지표다.

이 결과가 중요한 이유는 영향도의 하한이 입력 변수의 전체 개수와 무관하게 다항식의 차수와 분산으로 표현된다는 점이다.

이런 성질을 이용하면 무작위 입력을 다루는 일부 양자 알고리즘의 계산 능력에 관한 기존 추측을 해결할 수 있다.

다만 이 결과가 양자컴퓨터의 모든 속도 이점을 부정한다는 의미는 아니다.

특정한 구조를 가진 문제에서는 여전히 양자컴퓨터의 큰 속도 향상이 가능할 수 있다.

AI가 논문과 형식 증명을 함께 생성

PSI는 내부적으로 개발한 연구 에이전트 시스템을 이용했다.

이 시스템은 비공개 Anthropic 모델의 여러 인스턴스를 사용하도록 구성됐다.

연구팀에 따르면 시스템은 실행을 시작한 뒤 세 번째 날에 완전한 증명 초안을 생성했다.

이후 연구팀은 관련된 추가 문제를 검토하도록 시스템에 요청했다.

AI는 증명을 두 차례 개선했고 최종 결과도 Lean에서 받아들여졌다.

Lean 4는 수학적 정리를 형식적으로 표현하고 각 증명 단계가 논리 규칙을 따르는지 검사하는 도구다.

일반적인 논문에서는 사람이 수학적 증명을 읽고 타당성을 확인한다.

반면 Lean에서는 수학적 명제와 증명 과정을 컴퓨터가 검사할 수 있는 코드로 작성한다.

이런 방식을 형식 검증(Formal Verification)이라고 한다.

PSI는 공개한 코드에 증명 없이 정리를 참으로 인정하는 임의의 추가 공리나 미완성 증명 표시가 포함돼 있지 않다고 밝혔다.

또한 연구팀은 두 가지 독립적인 Lean 커널 구현으로 증명을 다시 검사했다고 설명했다.

하지만 이는 PSI가 자체적으로 수행한 검증이다.

외부 연구자가 동일한 결과를 독립적으로 재현하고 학술적 검토를 완료했다는 의미는 아니다.

형식 검증에도 남아 있는 중요한 조건

컴퓨터가 증명을 받아들였다는 사실은 강한 검증 근거다.

하지만 한 가지 구분이 필요하다.

Lean은 코드로 표현된 수학적 명제가 주어진 논리 규칙 아래에서 증명됐는지 검사한다.

반면 코드에 작성한 명제가 원래 연구자가 의도한 수학적 문제와 정확하게 동일한지는 별도로 확인해야 한다.

예를 들어 원래 문제의 가정 가운데 하나가 형식화 과정에서 누락됐다면 Lean은 누락된 가정을 스스로 찾아내지 못할 수 있다.

또한 추가적인 가정이 포함됐을 때 그 조건이 원래 추측보다 강하지 않은지 검토해야 한다.

PSI는 이런 문제를 확인할 수 있도록 원래 추측과 Lean 코드 사이의 대응 자료를 공개했다.

연구에는 David Turturean이 중심적으로 참여했다.

그는 AI 연구 시스템을 개발하고 문제를 선정했으며 결과를 검토한 책임자다.

PSI의 자문위원인 Jim Halverson은 증명을 감사했고 Phiala Shanahan은 Lean 형식화에 의견을 제공했다.

Stanford의 관련 연구자들도 증명을 읽고 의견을 전달했다고 PSI는 설명했다.

하지만 발표 시점에 논문의 정식 동료심사(Peer Review)는 완료되지 않았다.

따라서 최종적인 학술적 평가에서는 원래 추측과 형식화의 일치 여부, 증명의 모든 전제가 검토돼야 한다.

이번 발표는 AI가 단순히 기존 수학 지식을 설명하는 수준에서 벗어나 새로운 증명을 제안하고 컴퓨터가 검증할 수 있는 형태로 작성하는 연구 과정에 참여할 수 있음을 보여주는 사례다.

동시에 AI가 생성한 결과의 중요성이 커질수록 독립적인 검증과 공개된 재현 자료도 중요해진다는 점을 보여준다.

---

Nous Research, Qwen을 추가 학습한 오픈웨이트 ‘Arete-27B’ 공개…정치적 주제의 답변 성향 변화 실험

• 발표일: 2026-11-06~07 — 공식 글의 정확한 게시 시각 미확인
• 적용 범위: 오픈웨이트 LLM, 모델 정렬, 지도 미세조정, 학습 데이터 공개, 정치적 편향 평가, AI 거버넌스
• 원문: Nous Research — Introducing Arete-27B
• 관련 원문: Hugging Face — Arete-27B 모델 및 평가 결과

Nous Research가 Alibaba의 Qwen3.8-27B를 추가 학습한 새로운 오픈웨이트 모델 Arete-27B를 공개했다.

이번 발표는 기존 모델보다 더 많은 파라미터를 가진 새로운 아키텍처를 만든 사례가 아니다.

기존 모델의 일반적인 언어 이해와 코딩 능력을 크게 변경하지 않으면서 특정한 정치·사회적 주제에 대한 응답 성향을 바꾸는 실험이다.

Nous Research는 원래 Qwen 모델이 일부 정치적으로 민감한 질문에서 중국 정부의 공식 입장을 따르거나 답변을 회피하는 경향이 있다고 평가했다.

이를 바탕으로 새로운 학습 데이터를 만들고 모델의 응답을 변경했다.

다만 어떤 답변을 편향으로 판단할 것인지에는 연구자가 설정한 가치 기준이 개입된다.

따라서 이번 연구는 중립성을 완전히 확보했다는 증명이라기보다 모델의 행동을 추가 학습으로 얼마나 변경할 수 있는지 보여주는 실험으로 이해하는 것이 적절하다.

270억 파라미터 모델을 추가 학습

Arete-27B는 약 270억 개의 파라미터를 가진 모델이다.

파라미터는 모델이 학습 과정에서 조정하는 숫자 데이터다.

Nous Research는 기존 Qwen 모델의 아키텍처를 변경하지 않았다.

대신 SFT(Supervised Fine-Tuning, 지도 미세조정)를 사용했다.

SFT는 입력과 원하는 답변의 예시를 이용해 모델을 추가 학습하는 방법이다.

예를 들어 특정한 질문에 대해 모델이 어떤 사실을 언급하고 어떤 표현을 사용해야 하는지 예시를 제공할 수 있다.

이번 실험에서는 약 5,280만 토큰을 이용해 추가 학습했다.

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

모델은 총 두 번의 학습 에포크와 1,202단계의 업데이트를 거쳤다.

Epoch(에포크)는 준비된 학습 데이터 전체를 한 번 사용하는 학습 주기를 의미한다.

이번 실험에서는 강화학습이나 별도의 선호 최적화 방식을 사용하지 않았다.

기존 모델의 가중치를 지도 미세조정으로 직접 수정했다.

또한 모델의 이미지 이해를 담당하는 인코더는 변경하지 않았다.

이번 학습 데이터가 텍스트 중심이었기 때문이다.

일곱 가지 가치 영역을 중심으로 평가

연구팀은 모델이 정치·사회적 주제에 어떻게 응답하는지 평가하기 위해 자체 벤치마크를 만들었다.

평가에는 803개의 질문이 포함됐다.

대상은 다음 일곱 가지 영역이다.

연구팀은 각 질문에 대해 확인해야 할 사실을 두 개에서 네 개까지 정의했다.

이후 모델이 해당 사실을 올바르게 언급했는지 평가했다.

동시에 중국 정부의 공식적 서술을 사실과 구분하지 않고 자신의 답변으로 채택했는지도 검사했다.

하지만 이런 분류에는 중요한 제한이 있다.

특정한 정부의 입장을 소개하는 것과 그 입장을 사실로 단정하거나 지지하는 것은 서로 다른 행동이다.

연구팀도 이런 차이를 구분하도록 평가 규칙을 작성했다고 설명한다.

자체 평가에서 응답 성향 큰 폭 변화

Nous Research가 공개한 결과는 다음과 같다.

사실 평가 점수는 2.32점에서 2.98점으로 높아졌다.

또한 연구팀이 정의한 특정한 서술 패턴이 포함된 답변의 비율은 22%에서 0.9%로 감소했다.

그러나 이 수치를 모든 정치적 편향이 0.9%로 감소했다는 의미로 해석해서는 안 된다.

해당 평가는 Nous Research가 직접 만든 질문과 기준에 기반한다.

또한 평가에는 Grok 4.7을 자동 채점기로 사용했다.

LLM-as-a-Judge는 다른 언어모델을 이용해 AI의 답변을 평가하는 방식이다.

이런 방식은 많은 결과를 일관된 형식으로 검사하는 데 유용하다.

하지만 평가 모델 자체의 판단 오류나 정치적 관점도 결과에 영향을 줄 수 있다.

연구팀은 평가 모델이 답변을 작성한 모델의 이름을 보지 못하도록 했으며, 일부 질문은 사람이 직접 검사해 평가 규칙을 수정했다고 설명했다.

그럼에도 전체 결과를 독립적인 외부 기관이 검증한 것은 아니다.

일반적인 코딩 능력은 유지됐을까?

이번 실험의 또 다른 목적은 정치·사회적 응답을 변경하면서 일반적인 능력이 얼마나 유지되는지 확인하는 것이었다.

Hermes Bench에서는 원본 모델의 65.77%와 Arete-27B의 65.60% 사이에 큰 차이가 나타나지 않았다.

Terminal-Bench 2.1에서는 Arete-27B가 약간 더 높은 점수를 기록했다.

그러나 연구팀은 이 작은 차이를 새로운 모델의 실질적인 능력 개선이라고 주장하지 않았다.

모델의 실행 설정과 평가 환경에 따른 변동이 영향을 줬을 수 있기 때문이다.

따라서 현재 확인할 수 있는 것은 연구팀이 수행한 제한된 평가에서 일반적인 작업 능력의 뚜렷한 저하가 발견되지 않았다는 점이다.

이는 모든 업무와 모든 언어에서 성능이 유지됐다는 의미와는 다르다.

모델과 학습 데이터, 평가 데이터 공개

Nous Research는 이번 연구에서 모델 가중치와 학습 데이터, 평가 질문을 공개했다.

Arete-27B 모델에는 Apache 2.0 라이선스가 적용됐다.

외부 연구자는 모델을 다운로드하고 같은 평가를 다시 실행할 수 있다.

또한 서로 다른 정치·사회적 기준을 사용해 결과를 비교할 수도 있다.

이번 실험의 의미는 특정한 가치 기준을 모든 AI 모델에 적용해야 한다는 주장에 있지 않다.

오히려 오픈웨이트 모델의 응답 성향이 비교적 제한된 추가 학습을 통해 상당히 달라질 수 있다는 사실을 보여준다.

이는 모델이 답변을 생성할 때 가진 관점과 정책이 사전학습 데이터뿐 아니라 이후의 학습 과정에도 영향을 받는다는 점을 보여준다.

동시에 모델의 응답을 평가하는 기준이 누구에 의해 정의됐는지, 실제 사실과 가치 판단이 어떻게 구분됐는지 검토해야 한다는 과제도 남긴다.

---

2️⃣ AI 제품·서비스

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

---

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

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

---

4️⃣ 산업·정책·안전

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

---

📚 추천 글

Agent Distraction

• 저자: Sam Saccone, Madhuri Garikapati
• 발행: Google Developers Blog
• 게시일: 2026-11-06
• 원문: Google Developers — Agent Distraction

AI 코딩 에이전트에게 기존 프로젝트의 소스코드를 읽도록 하면 어떤 문제가 발생할까?

일반적으로 개발자는 코드에 포함된 주석을 참고자료로 사용한다.

예를 들어 특정한 기능을 나중에 수정해야 한다는 TODO 주석이 존재할 수 있다.

하지만 실제로 해당 작업이 이미 완료됐거나 더 이상 필요하지 않을 수도 있다.

사람 개발자는 이런 주석을 읽고 현재 작업과 관계없다면 무시할 수 있다.

반면 AI 코딩 에이전트는 주석에 적힌 내용을 새로운 작업 지시로 잘못 이해할 가능성이 있다.

이번 글은 Google 내부 코딩 에이전트의 실제 사용 기록을 분석해 이런 문제가 얼마나 자주 발생하는지 조사했다.

수십만 건 이상의 실제 에이전트 작업 분석

Google은 수천 명의 엔지니어가 사용하는 내부 코딩 에이전트의 실행 기록을 조사했다.

분석 대상에는 91만3천 건 이상의 세션과 수억 개의 에이전트 실행 단계가 포함됐다.

연구팀은 특히 코드에 포함된 TODO(bug/...)와 FIXME(bug/...) 같은 주석에 주목했다.

이런 주석에는 특정한 버그 관리 시스템의 이슈 번호가 포함된다.

예를 들어 어떤 코드에 몇 년 전에 작성한 TODO 주석이 남아 있을 수 있다.

하지만 실제 버그는 이미 수정됐을 수 있다.

Google은 에이전트가 읽은 주석의 이슈 번호를 실제 버그 관리 시스템의 상태와 비교했다.

이를 통해 에이전트가 사용자의 요청과 관계없는 작업을 수행했는지 분석했다.

약 13%의 세션에서 관련 주석 발견

분석 결과는 다음과 같다.

여기서 6%는 관련 주석을 실제로 접한 경우를 기준으로 한 비율이다.

전체 에이전트 세션의 6%에서 반드시 같은 문제가 발생했다는 의미는 아니다.

특히 중요한 부분은 실제로 다른 작업을 수행한 경우 가운데 대부분이 사용자가 요청하지 않은 행동이었다는 사실이다.

예를 들어 사용자가 현재 발생한 오류를 수정하라고 요청했을 수 있다.

그런데 에이전트가 관련 소스코드를 읽다가 이전에 작성된 TODO 주석을 발견한다.

이후 원래 오류를 수정하는 작업과 무관하게 해당 TODO의 버그를 조사하기 시작한다.

이런 현상을 Scope Creep(작업 범위의 불필요한 확대)이라고 한다.

원래 계획하거나 승인받은 범위보다 작업이 확장되는 현상이다.

실제로 완료된 버그를 다시 조사

Google은 불필요한 작업의 유형도 분류했다.

이 가운데 약 41%는 이미 종료된 버그를 다시 조사하는 경우였다.

세부적으로는 이미 수정되거나 검증된 버그가 약 32%, 해결할 필요가 없는 오래된 버그가 약 9%였다.

반면 약 57%에서는 실제로 아직 열려 있는 버그를 조사하면서 작업 범위를 확장했다.

열려 있는 버그라고 해서 현재 사용자의 요청과 관련된 것은 아니다.

예를 들어 사용자가 로그인 오류를 수정하도록 요청했는데 에이전트가 같은 파일에서 발견한 이미지 처리 버그까지 수정하기 시작할 수 있다.

이 경우 수정 자체가 올바르더라도 사용자가 요청하지 않은 코드 변경이 발생한다.

실제 개발에서는 이런 변경이 새로운 오류를 만들 가능성도 있다.

실행 단계와 토큰 사용량 증가

Google은 사용자와 코드베이스의 복잡성, 작업 유형과 모델 수준 등 여러 요인의 영향을 통계적으로 보정했다.

이후 불필요한 TODO 추적이 발생한 세션의 비용을 분석했다.

그 결과 추가 작업이 발생한 세션은 평균적으로 실행 단계가 70% 많았고 토큰 사용량은 77% 증가했다.

대기시간은 105% 증가했다.

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

토큰 사용량이 증가하면 API 사용료도 증가할 수 있다.

또한 에이전트가 더 많은 도구를 호출하고 파일을 검색하면 전체 작업의 완료시간도 늘어날 수 있다.

하지만 이번 결과는 Google 내부의 특정한 코딩 에이전트와 개발 환경에서 측정됐다.

모든 AI 코딩 도구에서 동일한 비용 증가가 발생한다는 의미는 아니다.

더 강력한 모델도 영향을 받았다

Google은 모델의 능력이 높을수록 이런 불필요한 행동을 더 많이 수행하는 경향도 관찰했다고 설명한다.

이는 처음에는 이상하게 느껴질 수 있다.

더 강력한 모델이라면 관련 없는 주석을 더 잘 무시할 것이라고 생각하기 쉽기 때문이다.

하지만 실제로는 모델의 도구 사용 능력이 높아질수록 주석에 포함된 다른 작업까지 적극적으로 조사할 수 있다.

예를 들어 오래된 TODO 주석을 발견한 뒤 해당 이슈를 검색하고 관련 코드를 수정할 수 있다.

이런 행동은 모델이 기술적으로 더 많은 작업을 수행할 수 있다는 사실을 보여준다.

하지만 사용자의 현재 목표를 정확하게 따랐다는 의미는 아니다.

작업을 수행할 수 있는 능력과 실제로 수행해야 하는 작업을 구분하는 능력은 서로 다른 문제다.

Google의 대응: 오래된 주석 자동 정리

Google은 이런 문제를 줄이기 위해 별도의 코드 정리 에이전트를 만들었다.

해당 에이전트는 코드베이스 전체에서 오래된 TODO와 FIXME 주석을 검색한다.

이후 연결된 버그의 현재 상태와 과거 변경 이력을 확인한다.

예를 들어 버그가 종료됐다는 사실만으로 해당 주석을 무조건 삭제하지 않는다.

실제 코드에서 주석이 여전히 필요한 정보를 제공하는지 조사한다.

필요하지 않다고 판단되는 경우에만 삭제를 제안한다.

최종 변경사항은 사람이 검토한다.

Google에 따르면 지난 6개월 동안 이런 방식으로 수천 개의 오래된 주석을 제거했다.

사람이 검토한 변경 제안의 승인율은 95%를 넘었다.

이번 글은 AI 코딩 에이전트의 생산성을 높이기 위해 모델 자체를 개선하는 것뿐 아니라 에이전트가 읽는 코드와 문서의 품질을 관리하는 작업도 중요하다는 점을 보여준다.

특히 실제 개발 현장에서는 오래된 TODO와 이슈 참조를 정리하는 일이 단순한 코드 청소를 넘어 AI 에이전트의 잘못된 행동을 줄이는 효과를 가질 수 있다는 점에서 흥미롭다.

---

Cost per task: Using cheap classifiers to route across Gemini models and thinking levels

• 저자: Sergio Villani
• 발행: Google Developers Blog
• 게시일: 2026-11-03
• 원문: Google Developers — Cost per task: Using cheap classifiers to route across Gemini models and thinking levels

AI 에이전트를 운영할 때 가장 저렴한 모델을 사용하면 전체 비용도 가장 낮아질까?

반드시 그렇지는 않다.

예를 들어 작은 모델을 사용하면 요청 하나의 비용은 낮을 수 있다.

하지만 실제 작업을 실패해 세 번이나 다시 시도해야 한다면 전체 비용은 오히려 증가할 수 있다.

반대로 고성능 모델을 사용하면 작업 성공률이 높을 수 있지만 간단한 질문에도 많은 추론 자원을 사용할 수 있다.

따라서 AI 에이전트의 비용을 평가하려면 단순히 입력 토큰과 출력 토큰의 가격을 비교하는 것보다 하나의 작업을 성공적으로 완료하는 데 실제로 얼마가 필요한지 확인해야 한다.

Google의 이번 글은 이런 문제를 해결하기 위해 저렴한 분류 모델을 활용한 라우팅 방식을 실제로 시험한 결과를 설명한다.

모델 라우팅이란 무엇인가

Model Routing(모델 라우팅)은 입력 작업의 특성에 따라 사용할 AI 모델을 선택하는 방법이다.

예를 들어 사용자가 로그에서 오류 코드를 추출해 달라고 요청했다고 가정해 보자.

이는 비교적 간단한 정보 추출 작업일 수 있다.

반면 복잡한 프로그램의 상태 변화와 오류 원인을 분석하려는 요청은 여러 단계의 추론이 필요할 수 있다.

모든 작업에 가장 강력한 모델을 사용하는 대신 간단한 작업에는 작은 모델을 사용하고 복잡한 작업에만 더 큰 모델을 선택하면 비용을 줄일 가능성이 있다.

하지만 먼저 현재 작업이 얼마나 어려운지 판단해야 한다.

이 판단 자체에도 계산 비용이 발생한다.

Google은 이를 위해 TypeSafe AI의 Jev라는 소형 분류 모델을 사용했다.

Jev는 긴 자연어 답변을 생성하는 대신 특정한 질문에 대한 확률과 선택 결과를 계산하는 모델이다.

예를 들어 입력된 질문이 여러 단계의 논리적 추론을 필요로 하는지 평가할 수 있다.

Google은 이 예제에 관해 TypeSafe와 별도의 파트너십이 없으며, Jev가 유일한 구현 방법도 아니라고 명시했다.

단순한 문자열 규칙은 처음 보는 문제에서 실패

연구팀은 처음에 매우 간단한 라우팅 규칙을 만들었다.

예를 들어 질문이 35단어보다 길면 복잡한 작업이라고 판단할 수 있다.

또는 특정한 수학 용어와 프로그래밍 표현이 포함되면 고성능 모델로 전달하도록 구성할 수 있다.

이런 방법은 구현이 쉽고 별도 AI 호출 비용이 거의 들지 않는다.

하지만 문제가 발생했다.

처음 규칙을 개발하는 데 사용한 16개 질문에서는 93.8%의 정확도를 기록했다.

그런데 처음 보는 34개 질문에 같은 규칙을 적용하자 정확도가 70.6%로 감소했다.

반면 Jev 분류기는 같은 34개 질문에서 모두 연구팀이 설정한 난이도 분류와 일치했다.

전체 50개 질문에서는 96.0%의 분류 일치율을 기록했다.

하지만 34개 질문에서 100%를 기록했다는 사실만으로 실제 모든 코딩 업무의 난이도를 완벽하게 분류할 수 있다는 의미는 아니다.

이번 평가는 50개의 제한된 문제와 연구팀이 직접 설정한 난이도 기준에 기반한다.

출력 토큰 수를 줄여도 추론 비용이 줄지 않을 수 있다

이번 연구에서 가장 중요한 발견 가운데 하나는 출력 토큰 제한과 내부 추론 수준은 다르다는 사실이다.

예를 들어 언어모델에게 최대 300토큰만 출력하도록 설정할 수 있다.

이렇게 하면 답변이 짧아지므로 비용이 줄어들 것이라고 생각하기 쉽다.

하지만 실제 추론 모델은 최종 답변 외에도 내부 계산에 토큰을 사용할 수 있다.

Google은 maxOutputTokens를 300으로 제한한 경우와 4,096으로 설정한 경우를 비교했다.

그 결과 간단한 작업에서 내부 추론 토큰 사용량은 거의 같았다.

오히려 출력 제한이 작을 때 일부 어려운 문제는 답변을 완성하지 못했다.

따라서 토큰 제한을 낮추는 것보다 모델의 추론 강도를 직접 조절하는 방법이 더 적절할 수 있다.

Google은 Gemini 3.8 Flash의 thinkingLevel을 낮추는 방법을 시험했다.

가장 좋은 비교 대상은 라우터가 없는 구성

연구팀은 모델을 여러 개 연결한 뒤 비용이 줄었다고 주장하는 것만으로는 충분하지 않다고 설명한다.

라우터를 사용하지 않는 가장 좋은 구성과 비교해야 한다.

이번 평가에서는 Gemini 3.8 Flash를 낮은 추론 수준으로 실행한 구성이 50개 작업을 모두 성공했다.

따라서 새로운 라우터는 이보다 더 저렴하거나 빨라야 실제 이점이 존재한다.

연구팀은 Jev를 사용해 간단한 요청을 Flash-Lite로 전달하고, 어려운 요청만 Gemini 3.8 Flash의 낮은 추론 설정으로 전달했다.

이 구성도 50개 작업을 모두 성공했다.

또한 해당 평가에서는 단일 Flash 구성보다 비용과 응답시간을 일부 줄일 수 있었다.

하지만 이 결과는 짧고 독립적인 작업을 중심으로 측정됐다.

실제 코딩 에이전트의 긴 작업에서도 같은 개선이 발생한다고 단정할 수는 없다.

모델을 자주 변경하면 캐시 이점이 사라질 수 있다

이번 글에서 흥미로운 부분은 Prompt Caching(프롬프트 캐싱)과 모델 라우팅의 관계다.

프롬프트 캐싱은 반복되는 입력의 처리 결과를 저장해 이후 요청에서 재사용하는 기술이다.

예를 들어 코딩 에이전트는 같은 프로젝트의 구조와 개발 지침을 여러 번 모델에 전달할 수 있다.

이런 입력을 캐싱하면 비용을 줄일 수 있다.

그런데 모델이 요청마다 달라지면 캐시도 모델별로 따로 관리해야 할 수 있다.

따라서 라우팅을 적극적으로 사용하면서 오히려 캐시 효율이 떨어지는 상황이 발생할 수 있다.

Google은 짧고 독립적인 요청에서는 라우팅이 유용할 수 있지만, 많은 문맥을 반복해서 사용하는 작업에서는 하나의 모델을 계속 사용하는 편이 적절할 수 있다고 설명한다.

또한 모델의 재시도와 실패, 도구 호출에 필요한 비용까지 포함해 평가해야 한다.

이번 연구는 AI 모델의 운영비를 계산할 때 토큰당 가격보다 성공한 작업당 총비용을 기준으로 비교해야 한다는 점을 실제 실험으로 보여준다.

다만 각 구성은 대부분 한 번씩 평가됐으므로 결과의 변동성은 추가 검증이 필요하다.

---

Four small models that guess where a backpack is

• 저자: Brian Sheppard
• 발행: Hugging Face Community
• 게시일: 2026-11-07
• 원문: Hugging Face — Four small models that guess where a backpack is

AI를 이용해 사람의 위치나 행동을 추정하려면 반드시 카메라와 거대한 신경망이 필요할까?

이번 글은 매우 작은 머신러닝 모델로 주변 환경을 추정하는 실험을 소개한다.

저자는 오랫동안 자신의 가방에 넣어 다니던 노트북에 여러 센서를 연결했다.

센서에는 GPS와 무선 신호 측정 장치, 빛과 온도 센서, 가속도 센서와 마이크 등이 포함됐다.

이렇게 수집한 정보를 바탕으로 노트북이 지금 책상에 있는지, 이동 중인지, 차량 안에 있는지 등을 추정하는 모델을 만들었다.

이번 연구에서 흥미로운 부분은 모델의 크기가 아니다.

실제로 예측하려는 정보를 직접 측정하는 센서는 입력에서 제외하고, 간접적인 신호만으로 환경을 추정하도록 설계했다는 점이다.

1분마다 478개의 센서 값 수집

저자는 노트북이 관찰한 환경을 1분마다 기록했다.

하나의 기록에는 478개의 숫자 값이 포함됐다.

예를 들어 주변 무선 신호의 강도와 GPS 수신 상태, 움직임과 소리의 주파수 분포 등을 저장했다.

하지만 실제로 어떤 위치에 있는지에 관한 정답 정보는 모델의 입력에서 제외했다.

예를 들어 해가 뜨는 시간을 예측하는 모델이라면 빛의 밝기를 측정하는 센서를 사용하지 않았다.

빛 센서를 그대로 사용하면 모델이 해가 떴는지 판단하는 일이 지나치게 쉬워지기 때문이다.

대신 주변 무선 신호와 소리, GPS 수신 상태 등을 참고하도록 했다.

이런 설계는 Data Leakage(데이터 누출) 문제를 줄이기 위한 것이다.

데이터 누출은 실제 예측 상황에서는 사용할 수 없는 정보가 학습이나 평가에 포함되는 현상이다.

예를 들어 시험 문제의 정답이 입력 데이터에 포함돼 있다면 높은 점수를 기록하더라도 실제 예측 능력을 검증했다고 보기 어렵다.

단순한 로지스틱 회귀 모델 사용

이번 실험에 사용한 모델은 매우 작은 로지스틱 회귀(Logistic Regression) 모델이다.

로지스틱 회귀는 여러 입력값을 이용해 특정한 범주에 속할 확률을 계산하는 통계적 방법이다.

예를 들어 현재 노트북이 이동 중일 가능성을 계산할 수 있다.

저자는 네 가지 모델을 공개했다.

첫 번째는 노트북의 운반 상태를 분류하는 모델이다.

두 번째와 세 번째는 서로 다른 센서 구성을 사용해 일출 시점을 예측하는 모델이다.

네 번째는 폭포 근처를 지나는 상황을 예측하는 모델이다.

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

AUC(Area Under the Curve)는 분류 모델이 양성 사례와 음성 사례를 얼마나 잘 구분하는지 나타내는 지표다.

일반적으로 0.5는 무작위 추측에 가까운 수준이며 1.0은 완벽한 구분에 해당한다.

그러나 AUC가 0.82라는 사실이 실제 확률 예측도 정확하다는 의미는 아니다.

이번 연구에서는 실제 확률값을 얼마나 신뢰할 수 있는지 별도로 평가했다.

정확도 95%의 함정

이번 글에서 중요한 부분은 운반 상태 분류의 정확도다.

언뜻 보면 95%는 매우 높은 점수처럼 보인다.

하지만 실제 데이터에서는 대부분의 시간에 노트북이 책상이나 가방 안에 놓여 있었다.

따라서 가장 흔한 상태만 항상 예측해도 약 93%의 정확도를 얻을 수 있었다.

이를 Majority Baseline(다수 범주 기준 모델)이라고 한다.

가장 자주 등장하는 범주를 무조건 예측하는 단순한 방법이다.

실제 모델의 정확도 95%는 이 기준보다 겨우 2%포인트 높았다.

따라서 전체 정확도만 보면 모델이 실제로 얼마나 유용한지 판단하기 어렵다.

저자는 대신 실제로 가방을 들고 이동하는 상황을 얼마나 정확하게 찾아냈는지 확인했다.

그 결과 운반 상태의 정밀도는 81%, 재현율은 83%였다.

이 수치가 전체 정확도보다 해당 작업에서 더 유용한 평가 기준이다.

무작위 데이터 분할은 실제 성능을 과장할 수 있다

이번 연구에서는 약 36일 동안 수집한 데이터를 사용했다.

일반적인 머신러닝 평가에서는 데이터를 무작위로 학습용과 평가용으로 나눌 수 있다.

하지만 센서 데이터에서는 이 방식에 문제가 발생할 수 있다.

예를 들어 오후 2시의 센서 값과 오후 2시 1분의 센서 값은 매우 비슷할 가능성이 높다.

이 가운데 하나를 학습에 사용하고 다른 하나를 평가에 사용하면 모델이 실제로 새로운 환경을 예측하는 능력보다 높은 점수를 기록할 수 있다.

이를 방지하기 위해 저자는 Leave-One-Day-Out(하루를 제외하고 평가하는 방식)을 사용했다.

예를 들어 첫 번째 날을 평가할 때는 나머지 날짜의 데이터만 학습에 사용한다.

이후 평가할 날짜를 바꾸면서 같은 과정을 반복한다.

이렇게 하면 모델이 같은 날의 매우 비슷한 센서 패턴을 이용해 정답을 맞히는 문제를 줄일 수 있다.

폭포를 감지한 이유가 예상과 달랐다

이번 글에서 가장 흥미로운 발견은 폭포 근처를 지나가는 상황에 관한 모델이었다.

연구자는 처음에 주변의 소리 신호가 폭포의 존재를 알려줄 것이라고 생각했다.

하지만 실제로는 노트북의 마이크가 가방 안에 있어 폭포 소리를 거의 감지하지 못했다.

그런데 모델은 폭포 근처를 지나는 상황을 비교적 잘 구분했다.

연구자가 확인한 이유는 주변의 무선 신호 환경이었다.

폭포 근처의 공원에서는 다른 장소보다 무선 신호가 적었다.

모델은 폭포의 소리가 아니라 공원 주변의 무선 신호 특성을 학습한 것이다.

이는 Spurious Correlation(우연한 상관관계)의 사례로 이해할 수 있다.

모델이 원하는 현상과 실제로 관련된 원인을 학습한 것이 아니라 해당 현상과 우연히 함께 나타나는 다른 특징을 이용할 수 있다는 의미다.

예를 들어 다른 폭포 근처에 무선 신호가 많다면 이번 모델은 제대로 작동하지 않을 수 있다.

따라서 예측 점수가 높다는 사실만으로 모델이 올바른 원인을 학습했다고 판단해서는 안 된다.

개인정보 보호를 데이터 수집 단계에서 설계

이번 프로젝트는 개인정보 보호도 중요한 설계 요소로 다뤘다.

예를 들어 마이크에서 수집한 원본 음성을 그대로 저장하지 않았다.

대신 특정한 주파수 대역의 소리 강도만 기록했다.

카메라의 실제 이미지도 저장하지 않았다.

화면의 색상 분포를 요약한 정보만 사용했다.

Wi-Fi와 Bluetooth 정보도 주변 기기의 식별자를 그대로 저장하지 않고 개수와 신호 통계, 해시값으로 변환했다.

Hash(해시)는 입력 데이터를 일정한 형식의 값으로 변환하는 방법이다.

실제 위치 좌표와 사람의 정보도 공개 모델의 데이터에 포함하지 않았다.

저자는 이런 제한을 데이터 수집 이후에 사람이 기억해서 적용하는 것이 아니라 센서에서 데이터를 받아 저장하기 전에 프로그램으로 적용하도록 설계했다.

이번 글은 AI 연구에서 모델의 크기보다 실험의 질문과 데이터 누출 방지, 올바른 평가 지표와 개인정보 보호 설계가 더 중요할 수 있다는 점을 보여주는 사례다.