AI 데일리 브리핑 — 2026-10-04
Soshy·
기준 시점: 2026-10-04 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-03 06:00 ~ 2026-10-04 06:00 KST
추천 글 범위: 2026-09-27 06:00 ~ 2026-10-04 06:00 KST
1️⃣ 주요 모델·연구
Aleph Alpha, 독일어·영어 특화 오픈웨이트 모델 ‘Kolibri’ 공개…78B MoE에 최대 100만 토큰 컨텍스트
- 발표일: 2026-10-03 — 정확한 게시 시각 미확인
- 적용 범위: 오픈웨이트 LLM, 독일어·영어 AI, 온프레미스 배포, 장문 처리, 에이전트·도구 사용, 공공·규제 산업
- 원문: Aleph Alpha — Kolibri Has Landed: A Sovereign Open-Weight Model
독일 AI 기업 Aleph Alpha가 새로운 영어·독일어 언어모델 Kolibri를 공개하고 전체 모델 가중치를 Hugging Face에서 Apache 2.0 라이선스로 배포했다. 기업이나 정부기관이 외부 API에 데이터를 보내지 않고 자체 인프라에서 모델을 운영할 수 있도록 하는 이른바 sovereign AI(주권형 AI) 를 핵심 목표로 둔 모델이다.
Kolibri는 MoE(Mixture of Experts, 여러 전문 신경망 가운데 입력에 필요한 일부만 활성화하는 구조) 모델이다. 전체 파라미터는 781억 개지만 토큰 하나를 처리할 때 실제로 활성화되는 파라미터는 약 34억6천만 개다. 전체 모델의 지식을 메모리에 유지하면서도 매 토큰마다 모든 파라미터를 계산하지 않아 추론 비용을 줄이는 구조다.
다만 “활성 파라미터가 3B 수준”이라는 표현을 작은 모델처럼 해석해서는 안 된다. 전체 78B 가중치는 여전히 메모리에 올라가 있어야 한다. Aleph Alpha가 제시한 FP8 기준 모델 메모리 요구량은 약 78GB이며, 최소 구성도 2×A100 80GB 또는 1×H200·B200·B300 수준이다. 즉 계산량은 상대적으로 작지만 개인용 GPU에서 가볍게 돌리는 모델은 아니다.
컨텍스트 길이는 최대 1,048,576토큰, 약 100만 토큰까지 지원한다. 다만 실제 장문 학습 단계에서는 최대 262,144토큰까지 학습했고 Aleph Alpha 역시 효율적인 운영을 위해 256K 이하를 권장한다. 100만 토큰은 별도 설정으로 활성화할 수 있는 확장 범위에 가깝다.
모델 학습도 상당히 구체적으로 공개됐다. 먼저 16K 시퀀스에서 20조 토큰을 사전학습하고, 64K 컨텍스트에서 3.44조 토큰의 mid-training을 수행한 뒤, 256K 장문 적응 단계에서 약 2,000억 토큰을 추가 학습했다. 전체 학습에는 NVIDIA B200 GPU 768개가 사용됐다.
사전학습 데이터에서 독일어 비중은 21.3%, 약 4.3조 토큰이다. 일반적인 글로벌 LLM이 압도적으로 많은 영어 데이터에 독일어 자료를 추가하는 방식과 달리, Aleph Alpha는 처음부터 독일어를 주요 언어로 놓고 자체 데이터 파이프라인과 영어·독일어용 tokenizer를 구축했다.
독일어 데이터 수집 과정도 흥미롭다. 일반적인 영어 중심 웹 데이터 필터를 독일어에 그대로 사용하면 긴 합성어와 행정 문체 때문에 정상적인 독일어 문서가 품질이 낮은 자료로 오인돼 삭제되는 문제가 있었다. 이를 독일어 특성에 맞게 다시 조정해 Common Crawl에서 약 1.3조 개의 고유 독일어 토큰을 확보했다고 설명한다.
Post-training에서는 먼저 SFT(Supervised Fine-Tuning, 정답 예시를 이용해 모델 행동을 조정하는 지도 미세조정) 를 수행하고, 이후 코드·수학·도구 사용·에이전트 작업 등 120만 개가 넘는 작업 환경을 이용해 대규모 강화학습을 진행했다. 사용자는 none, low, medium, high 네 단계로 reasoning effort를 조절할 수 있으며 tool calling도 기본 지원한다.
모델 구조는 50개 층 전체가 MoE로 구성돼 있고 384개의 expert 가운데 토큰당 6개가 활성화된다. 장문 처리 비용을 줄이기 위해 50개 층 가운데 40개는 주변 512토큰만 보는 sliding-window attention을 사용하고, 다섯 층마다 한 번씩 전체 컨텍스트를 보는 full attention을 배치했다.
Aleph Alpha가 공개한 자체 평가에서는 AIME 2026 영어 96.0%, 독일어 90.0%, GPQA Diamond 영어 84.3%, 독일어 81.3%를 기록했다. 에이전트 평가에서는 τ³-bench Banking 38.1%, BFCL v4 61.4% 등을 보고했다. 일부 평가에서 비슷한 활성 파라미터 규모의 Qwen·Nemotron·Mistral 모델보다 높은 결과를 냈지만, 모든 수치는 Aleph Alpha가 자체 harness로 실행한 결과이므로 독립적인 제3자 평가와 동일하게 받아들여서는 안 된다. 실제로 일부 일반 지식·장문 평가에서는 비교 모델이 더 높은 점수를 기록한다.
Kolibri에서 모델 성능만큼 눈에 띄는 부분은 가중치를 완전히 내려받아 자체 환경에서 운영할 수 있다는 점이다. 최근 고성능 모델 경쟁이 미국과 중국의 대형 연구소에 집중되는 가운데, Aleph Alpha는 공공기관·금융·제조처럼 데이터 통제와 규제 준수가 중요한 유럽 시장을 대상으로 독일어 특화 모델과 자체 배포 가능성을 함께 제공하는 전략을 택했다.
2️⃣ AI 제품·서비스
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 개발 도구·에이전트
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
4️⃣ 산업·정책·안전
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
📚 추천 글
Solving Open Research Problems Together
- 저자·발행: Meta AI Research
- 게시일: 2026-10-02
- 원문: Meta AI Research — Solving Open Research Problems Together
AI가 이미 답이 존재하는 수학 문제를 잘 푸는 것과 아직 아무도 답을 모르는 실제 연구 문제를 푸는 것은 무엇이 다른지 구체적인 사례로 보여주는 글이다.
Meta는 여러 분야의 수학자에게 Muse Spark 1.1과 1.2를 제공해 실제 미해결 연구 문제를 함께 탐구하게 했다. 별도의 복잡한 연구 에이전트 시스템이나 특수 도구를 만든 것이 아니라 연구자들이 일반 meta.ai 채팅 환경에서 Thinking Mode를 사용했다는 점도 흥미롭다.
최종적으로 여섯 편의 논문이 작성됐고, Meta에 따르면 그 가운데 다섯 편은 이전까지 열려 있던 연구 질문에 답한다. 다만 AI가 독립적으로 문제를 골라 논문을 자동 생성한 것은 아니다. 분야 전문가가 문제를 선정하고 연구 방향을 제시했으며, 별도의 두 번째 수학자 그룹이 결과를 다시 검토했다. 각 논문에서는 사람이 주로 작성한 부분과 AI가 주로 초안을 만든 부분도 구분해 표시했다.
사례 가운데 하나는 “모든 semiabelian finite group은 monomial인가” 라는 2024년의 군론 추측을 반박하는 작업이다. Muse Spark가 수학 소프트웨어 GAP에서 실행할 탐색 프로그램을 만들었고, 이 프로그램이 원소 384개를 가진 반례를 찾아냈다. 이후 인간 수학자들이 결과를 검증하고 완전한 논증으로 정리했다.
다른 연구에서는 수십 년 전부터 예상돼 온 p-adic string theory와 number theory 사이의 관계를 확장하는 작업에 AI가 참여했다. 이 경우 Muse Spark는 후보 증명을 제안하는 것뿐 아니라 논문의 핵심 기술 섹션 세 부분의 초안까지 작성했고, 연구자들이 이를 검토·수정했다.
Meta가 함께 강조하는 점도 중요하다. 일부 문제는 연구가 진행되는 동안 다른 팀이 독립적으로 해결책을 발표했고, 같은 결론에 서로 다른 방법으로 도달한 경우도 있었다. 따라서 “AI가 최초로 미해결 문제를 해결했다”는 단순한 서사보다 실제 연구에서는 선행 연구 확인, 독립 검증, 우선권과 기여도 기록이 함께 필요하다.
최근 AI 수학 성과는 올림피아드 점수나 정답률 중심으로 소개되는 경우가 많았는데, 이 글은 연구 문제에서는 정답지가 없고 어떤 접근이 의미 있는지조차 처음부터 알 수 없다는 차이를 잘 보여준다. 앞으로 과학 연구에서 AI의 역할을 이해할 때 모델의 추론 성능만큼 연구자가 문제를 선택하고 AI 결과를 검증하는 구조가 중요하다는 점을 볼 수 있는 자료다.
Prompt caching benchmark: high cache reuse doesn’t always mean lower cost
- 저자: Nancy Chauhan
- 발행: Arize AI
- 게시일: 2026-10-02
- 원문: Arize AI — Prompt caching benchmark: high cache reuse doesn’t always mean lower cost
장시간 대화를 수행하는 AI 에이전트에서 prompt caching(이전에 처리했던 프롬프트 토큰의 계산 결과를 재사용하는 기능) 이 실제 비용과 속도에 얼마나 영향을 주는지를 네 모델로 직접 비교한 실험이다.
에이전트는 매 요청마다 시스템 지침, 도구 설명, 이전 대화 내용을 반복해서 모델에 전달한다. 대화가 길어질수록 이 입력은 커지기 때문에 이미 계산한 앞부분을 다시 처리하지 않고 캐시에서 읽을 수 있다면 비용과 지연시간을 크게 줄일 수 있다.
Arize는 쇼핑 에이전트를 만들고 5~20턴으로 구성된 20개의 대화를 준비했다. 각 대화를 모델마다 다섯 번 실행해 모델별 100개의 trace를 수집했다. 작업과 상품 데이터, 평가 기준은 동일하게 유지하고 DeepSeek V4 Pro 0813, GLM 5.3 Prime, GPT-6.1 Sol, Claude Opus 5.5를 비교했다.
전체 prompt token 가운데 캐시에서 읽힌 비율은 DeepSeek가 93.6%, Claude가 89.8%, GLM이 84.3%, GPT가 77.7%였다. 그러나 캐시 사용률 순서와 실제 비용 순서는 일치하지 않았다.
100회 실행의 Phoenix 추정 비용은 DeepSeek가 1.17달러, GPT가 2.74달러, GLM이 4.49달러, Claude가 14.63달러였다. Claude는 입력의 거의 90%를 캐시에서 읽었지만 출력 토큰 비용이 전체 비용의 상당 부분을 차지하면서 가장 비쌌다.
반대로 GPT는 GLM보다 캐시 비율이 낮았지만 총비용은 더 낮았다. 실험 전체에서 GPT가 생성한 출력은 약 15만7천 토큰이었던 반면 GLM은 약 72만5천 토큰을 만들었다. 캐시 적중률 하나만 보고 모델 비용을 비교하면 잘못된 결론에 도달할 수 있다는 것이다.
대화 길이에 따른 차이도 상당했다. GPT의 캐시 비율은 5턴 대화에서는 34.2%였지만 20턴에서는 87.0%까지 올라갔다. DeepSeek는 5턴부터 이미 85.7%였고 20턴에서 95.6%에 도달했다. 따라서 짧은 질의가 대부분인 서비스와 오랫동안 상태를 유지하는 에이전트는 같은 모델에서도 비용 특성이 달라질 수 있다.
실험에는 중요한 제한도 있다. DeepSeek와 GLM은 OpenRouter를 통해 실행했고 GPT와 Claude는 각각 OpenAI와 Anthropic을 직접 사용했다. 즉 모델뿐 아니라 provider path도 함께 달라졌기 때문에 결과를 순수한 모델별 캐싱 성능 비교라고 볼 수 없다. 또한 비용은 실제 청구서를 대조한 값이 아니라 Phoenix가 각 업체 가격표와 token 사용량을 이용해 계산한 추정치다.
최근 모델 비교에서는 100만 토큰당 가격만 나열하는 경우가 많지만, 실제 에이전트에서는 대화 길이, 출력량, 캐시 동작과 provider 구현까지 합쳐져 하나의 작업 비용이 결정된다는 점을 실제 trace 데이터로 보여주는 글이다.
Teaching a frozen LLM to see
- 저자: Arnab Maiti
- 발행: Giga
- 게시일: 2026-09-28
- 원문: Giga — Teaching a frozen LLM to see
이미 운영 중인 텍스트 LLM의 성능을 건드리지 않으면서 이미지를 이해하는 능력만 새로 추가할 수 있는가라는 문제를 실제 고객지원 모델을 이용해 다룬 기술 글이다.
Giga가 사용하던 모델은 이미 문체와 tool calling, 고객지원 정책에 맞춰 별도의 DPO 학습까지 끝난 GLM-5.2 기반 모델이었다. 일반적인 멀티모달 파인튜닝처럼 LLM 전체를 다시 학습하면 기존 텍스트 작업의 성능이 바뀔 위험이 있었다. 실제 서비스 트래픽의 약 95%가 이미지가 없는 대화였기 때문에 이 회귀 위험을 피하는 것이 중요했다.
연구팀은 그래서 LLM과 vision encoder를 모두 완전히 동결했다. 대신 이미지 특징을 LLM이 이해할 수 있는 벡터로 바꾸는 4,950만 파라미터짜리 작은 projector와 이미지의 시작·끝을 나타내는 두 개의 embedding만 학습했다. 학습 전후 LLM의 기존 가중치는 byte 단위로 동일하게 유지된다.
구조적으로는 vision encoder가 이미지를 여러 patch로 나누고 특징 벡터를 만든 뒤 projector가 이를 LLM의 6,144차원 hidden representation으로 변환한다. LLM 입장에서는 일반적인 텍스트 embedding 사이에 이미지에서 변환된 벡터가 삽입되는 셈이다. 모델 자체는 바뀌지 않고 모델에게 보여주는 입력 표현만 학습된다.
학습 데이터 설계가 특히 흥미롭다. 같은 이미지에 “무엇이 보이는가?”, “양이 있는가?”, “몇 마리인가?”처럼 서로 다른 질문을 붙였고, 실제로 존재하지 않는 물체를 묻는 negative example도 대량으로 포함했다. 이미지가 들어오면 무조건 설명부터 하는 모델이 되는 것을 막기 위해 open-ended caption 데이터는 전체의 14%로 제한했다.
고객지원 대화 데이터에서는 더 독특한 방법을 사용했다. 이미지 내용을 먼저 텍스트 설명으로 바꾼 뒤 기존 동결 LLM이 그 텍스트를 보고 생성한 답변을 학습 목표로 사용했다. projector가 이미지를 통해 기존 텍스트 설명과 비슷한 정보를 전달하도록 만드는 일종의 self-distillation이다. 덕분에 이미지 기능을 추가하면서도 기존 모델의 말투와 도구 사용 습관을 유지할 수 있었다.
전체 학습 데이터는 약 16만7천 개였고, 8개의 NVIDIA B200에서 한 epoch를 학습하는 데 약 31.9시간이 걸렸다. held-out loss는 0.502에서 0.2245로 낮아졌다.
실제 서비스에 가까운 자체 평가에서 한 개의 인증 코드가 포함된 screenshot을 정확히 읽는 비율은 98~100%였으며, 시작점으로 사용한 범용 projector는 86~88%, 비교한 프런티어 API 모델은 71~80%였다. 코드가 없는 screenshot에서 존재하지 않는 코드를 만들어내는 비율도 Giga 모델은 0.8%였다고 보고했다.
이 숫자는 Giga가 자체 서비스 업무에 맞춰 만든 평가 결과이므로 일반적인 이미지 이해 성능을 뜻하지는 않는다. 오히려 글에서 더 유용한 부분은 범용 멀티모달 성능보다 실제 서비스에서 필요한 시각 행동을 명확히 정의하고 그 행동에 맞는 데이터를 설계했다는 과정이다.
멀티모달 모델을 처음부터 거대하게 다시 학습하지 않고도 이미 검증된 텍스트 모델 주변에 작은 학습 가능한 계층을 붙여 새로운 modality를 추가할 수 있다는 것을 매우 구체적인 학습 과정과 실패 방지 전략으로 보여준다.
Jev made us take another look at tool search
- 저자: Vikram Sivashankar
- 발행: Conversion
- 게시일: 2026-09-28
- 원문: Conversion — Jev made us take another look at tool search
AI 에이전트가 사용할 수 있는 도구가 100개를 넘어가면 모든 tool schema를 프롬프트에 넣어주는 방식이 왜 비효율적인지 실제 제품 데이터를 통해 비교한 글이다.
Conversion의 에이전트에는 당시 114개의 도구가 있었다. Airtable integration 하나만 추가해도 records, comments, files, schema 등을 다루기 위한 여러 도구가 생겼고 새로운 기능이 추가될 때마다 catalog가 계속 커졌다.
문제는 한 사용자 요청에서 실제 필요한 도구가 몇 개뿐이라는 것이다. 114개 도구의 설명을 전부 모델에게 전달하면 context window를 불필요하게 사용하고 입력 비용도 늘어난다. 반대로 단순 keyword search로 몇 개만 골라주면 이름이 직접적으로 일치하지 않는 필수 도구를 놓칠 수 있다.
연구팀은 이를 해결하기 위해 Jev라는 decision model을 tool search 앞단에 배치했다. Decision model은 긴 자유형 답변을 만드는 대신 미리 정의된 선택지에 대한 확률을 반환하는 모델이다. Jev는 사용자 요청과 각 도구 설명을 보고 실제로 필요한 도구를 최대 다섯 개까지 선택했다.
개발 과정에서 100개의 요청으로 설정을 조정한 뒤 조건을 고정하고, 완전히 새로운 요청 100개로 평가했다. 이 가운데 85개는 현재 도구로 수행 가능한 작업이었고 15개는 지원하지 않는 요청이었다. 거의 절반은 여러 종류의 도구가 필요한 multi-step 작업이었다.
모든 방법에서 정상적인 결과가 나온 공통 95개 작업을 비교했을 때 Jev는 84개에서 필요한 모든 기능을 찾아냈고 precision은 80.3% 였다. OpenAI의 native tool search는 77개·64.4%, Anthropic BM25는 79개·15.3%, 로컬 BM25는 55개·21.5%, 단순 lexical search는 42개·16.4%였다.
특히 여러 단계가 필요한 47개 요청에서는 Jev가 43개에서 모든 필요한 기능을 찾았다. 다만 완벽하지는 않았다. 실제 작업에 앞서 schema를 먼저 읽어야 하는 것처럼 숨겨진 prerequisite를 놓치는 경우가 있었고, 지원하지 않는 작업에서도 비슷한 읽기 전용 도구를 잘못 선택하기도 했다.
컨텍스트 절감 폭은 상당했다. 전체 tool definition은 평균 153.32kB였지만 Jev가 선택한 도구는 요청당 평균 2.68kB였다. 모델이 처음부터 읽어야 할 도구 설명을 약 98% 줄인 셈이다.
Jev 검색 100회의 추정 비용은 약 0.16달러였다. 연구팀이 30턴 대화에서 여섯 번 새로운 도구를 검색하는 상황을 모델링했을 때 Claude Opus 5의 tool-input 및 search 비용은 약 0.74달러에서 0.20달러로 73% 감소했다. 캐시가 매번 재생성되는 조건에서는 절감 폭이 약 50%로 줄어들었다.
에이전트의 tool 수가 늘어나는 문제를 단순히 더 큰 context window로 해결하기보다 “현재 작업에 필요한 도구가 무엇인가”라는 판단 자체를 별도의 작은 모델에게 맡기는 구조를 실제 벤치마크로 검증했다는 점이 흥미롭다.
최근 에이전트 시스템이 하나의 거대한 LLM 호출에서 벗어나 검색, 분류, 안전 판단, 도구 선택처럼 작은 의사결정을 전용 모델로 분리하는 방향으로 발전하고 있는데, 그 설계가 비용과 컨텍스트 사용량에 어떤 영향을 주는지 이해하기 좋은 사례다.