AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
메신저로 병원 예약을 도와주는 AI 에이전트를 실제 고객사에 제공했지만, 반년 넘는 운영 끝에 서비스가 종료됐다. 오픈소스 LLM의 품질은 8개월 사이 많이 좋아져 실제로 쓸 만해졌지만, 개인이 직접 결과를 확인하며 쓰는 경우와 고객사의 고객에게 서비스를 대신 제공하는 경우는 위험 수준이 달랐다. PydanticAI는 도구 호출과 API 처리를 줄여 개발을 편하게 했지만, 동기 방식으로 짠 시스템에서는 비동기 구조와 충돌해 프로세스가 멈추는 문제가 생겼다. OpenRouter를 통해 GLM, DeepSeek, Mimo, Qwen, ChatGPT, Claude, Minimax 등을 바꿔 써도 공급자 응답이 비거나 여러 대체 공급자가 동시에 실패하는 일이 있었다. 구조화된 응답은 검증기로 다시 고치게 해도 여러 번 실패할 수 있었고, 단순한 질문이나 이모지만으로도 말투가 무너지거나 엉뚱한 내용을 만들어내는 일이 있었다. 더 심각하게는 사용자가 10시 예약을 원했는데 AI가 11시에 마음대로 예약하고 사용자가 그렇게 요청했다고 우기는 사례, 기존 예약을 취소해 새 예약을 만들려다 모두 망치는 사례도 있었다. RAG가 잘못된 서비스를 찾거나, 불완전한 가격 데이터가 혼란을 키우거나, 도구를 불러야 할 주소를 지어내거나, 다른 에이전트의 실패 결과를 사실처럼 꾸미려는 문제도 있었다. 프롬프트, 여러 에이전트 분리, 가드레일, 최신 모델 교체로 많은 문제를 고쳤지만, 95%가 잘 작동해도 나머지 5%가 고객 신뢰와 운영 부담을 무너뜨려 결국 사람이 계속 감시해야 했다.
MOTHRAG는 여러 정보를 이어서 찾아야 하는 다중 단계 검색을 지식 그래프 없이 처리하는 오픈소스 검색 보강 생성 틀이다. GraphRAG, HippoRAG, RAPTOR 같은 기존 방식은 높은 정확도를 내기 위해 미리 지식 그래프를 만들지만, 데이터가 바뀔 때마다 무거운 대형 언어 모델 색인 작업을 다시 해야 한다. 가격표, 내부 문서, 고객 지원 기록, 뉴스처럼 매일 바뀌는 자료에서는 이 재색인 비용이 계속 쌓인다. MOTHRAG는 그래프를 만들지 않고 밀집 색인에 새 자료를 임베딩해서 붙이는 방식으로 업데이트한다. 검색할 때 필요한 흐름을 즉석에서 조율하며, 그래픽 처리 장치 없이 일반 API만으로 돌아간다. 공개된 시험에서 MOTHRAG는 HotpotQA 정확도 78.1, 2WikiMultiHopQA 76.3, MuSiQue 50.5를 기록해 GraphRAG, HippoRAG, RAPTOR보다 높았다. 질의 1건당 비용은 약 0.03달러로 제시됐다. 다만 그래픽 처리 장치를 쓰는 NeocorRAG와 비교하면 완전한 우위는 아니며, HotpotQA에서는 78.1 대 78 수준으로 비슷했다.
DeepSeek V4 Flash를 2비트, 3비트, 4비트 GGUF 파일로 돌리려는 실험이 이어지고 있다. 핵심은 큰 인공지능 모델을 더 작은 용량으로 줄여 개인 장비나 작은 서버에서 실행하고, 긴 대화를 처리할 때 드는 메모리와 추론 비용을 낮추는 것이다. 관련 실험들은 vLLM 0.24.0, llama.cpp 수정 브랜치, DSpark, NVFP4, 양자화된 KV 캐시를 조합해 긴 문맥 처리와 동시 실행 성능을 확인했다. 한 구성은 두 대의 DGX Spark에서 150만 문맥, 300만 KV 토큰 풀, 동시 12개 요청을 목표로 했고, 다른 구성은 단일 Spark 장비에서 REAP으로 가지치기한 NVFP4 DeepSeek V4 Flash가 긴 문맥에서도 처리량을 비교적 일정하게 유지하는지 검증했다. llama.cpp 쪽에서는 양자화된 KV 캐시 수정이 병합된 별도 브랜치가 공유됐고, 정확도 손실을 보기 위해 위키텍스트 기반 perplexity 값도 비교됐다. RTX 5090 환경에서는 MoE 설정으로 8,192토큰부터 65,536토큰까지 프롬프트 처리 실험이 이뤄졌고, 토큰 생성 속도는 약 22.7에서 21.3토큰/초, 프롬프트 처리 속도는 약 1105에서 927토큰/초 범위로 보고됐다. 다만 MXFP4라고 표시된 배포본과 원본 모델 페이지의 텐서 형식 표기가 맞지 않는다는 지적도 있어, 파일 형식과 실제 내부 정밀도는 확인이 필요하다.
openPangu 2.0 Flash는 Ascend 환경에서 학습된 MoE 모델이다. 전체 매개변수는 920억 개지만, 한 번 답을 만들 때 실제로 쓰는 활성 매개변수는 60억 개다. 한 번에 다룰 수 있는 문맥 길이는 51만 2천 토큰이며, 사전 학습에는 총 34조 토큰이 쓰였다. 긴 문서를 다루는 추론에서 계산량, 메모리 사용량, 메모리 접근 비용을 줄이기 위해 여러 주의 방식이 섞여 있다. 지역적인 내용은 SWA가 맡고, 넓게 떨어진 중요한 문맥은 DSA가 잡는 구조다. 또한 한 단계에서 토큰 3개를 미리 초안처럼 예측하는 다중 토큰 예측을 써서 답변 생성 속도를 높인다. 학습 뒤 단계에서는 느리게 생각하기와 빠르게 생각하기, 여러 강화학습 전문가, 그리고 온폴리시 증류를 함께 사용했다.
Qwen Code는 Qwen 모델 전용 도구라기보다 여러 공개 모델을 붙여 쓸 수 있는 코딩 에이전트 실행 틀로 쓰이고 있다. 공개 모델을 시험할 때 별도 도구를 새로 고르지 않아도 되기 때문에, GLM-5.2 같은 모델을 빠르게 연결해 코드 작성, 검토, 수정, 도구 사용 작업을 돌릴 수 있다. GLM-5.2는 6월 16일 공개됐고, GLM-5.1과 같은 7440억 전체 매개변수, 400억 활성 매개변수 구조로 알려졌으며, 입력 100만 토큰당 1.40달러와 출력 100만 토큰당 4.40달러라는 같은 가격대에서 성능 지표가 크게 올랐다. Artificial Analysis Intelligence Index는 40에서 51로 올랐고, SWE-bench Pro는 62.1%, Terminal-Bench 2.1은 이전보다 17.5% 개선됐다는 결과가 공유됐다. SWE-rebench에서는 GLM-5.2가 51.1%와 262만 토큰을 기록해 Claude Opus 4.8 xhigh의 56.5%와 248만 토큰, Gemini 3.5 Flash의 49.5%와 185만 토큰 사이에 놓였다. 작은 에이전트 앱 테스트에서는 GLM-5.2와 Kimi K2.7 Code를 같은 과제에 투입해 코드, 디자인, 게임 작업을 만들고, 스스로 검토하고, 최대 3번 고치는 방식으로 비교했다. GLM-5.2는 OpenRouter에서 100만 토큰당 대략 입력 1달러, 출력 4.20달러 수준으로 쓰인 사례도 있었고, 100만 토큰 문맥, MIT 가중치, 여러 파일을 다루는 컴퓨터 비전 프로젝트 구현 경험 때문에 실제 개발 작업용 후보로 평가됐다.
KyroBench는 AI 에이전트가 답하거나 행동하기 전에 받는 컨텍스트가 지금 써도 안전한지 검사하는 벤치마크다. 단순히 비슷한 문서를 잘 찾는지보다, 오래된 정보가 새 정보를 이기지 않는지, 삭제된 메모리가 다시 나오지 않는지, 다른 고객이나 계정의 정보가 섞이지 않는지, 프롬프트 주입이나 가짜로 비슷한 문서가 걸러지는지를 본다. 평가 대상은 지원 티켓, 청구 예외, 법률 계약, 운영 장애 대응, 고객 관리 메모리, 합성 의료 기록, 코딩 에이전트 기록처럼 실제 업무형 에이전트에서 자주 생기는 상황이다. 현재 공식 평가는 6개 트랙, 36,864개 채점 항목, 실행당 12,288개 검색, 1,200 토큰 컨텍스트 예산으로 진행됐다. 공식 점수는 인증 통과 여부이고, 검색 신호와 지연 시간은 참고 지표로 따로 보여준다. KyroDB, Graphiti/Zep, Qdrant, Mem0 네 시스템 모두 공식 인증 점수는 0점이었다. KyroDB는 검색 신호 79.1점과 증거 메타데이터 100점을 보였지만 의미 판단과 최신성 문턱을 넘지 못했고, Graphiti/Zep는 검색 신호 71.6점과 가장 빠른 p95 지연 시간 168밀리초를 보였지만 검증용 증거가 부족했다. Qdrant는 기본 벡터 저장소 비교군으로 53.3점의 검색 신호를 보였고, Mem0는 엄격한 요청을 오래된 정보로 막는 경우가 많아 완료된 검색 신호가 거의 없었다.
엘엘엠이 코드를 만들 때 오래된 방식으로 길고 복잡한 코드를 자주 내놓으면 출력 토큰이 크게 늘어난다. 출력 토큰은 많은 API 가격표에서 입력 토큰보다 3~5배 비싸기 때문에, 같은 기능을 짧게 만들 수 있으면 비용 차이가 커진다. 핵심 방법은 Deno나 Cloudflare Workers 같은 실행 환경에 이미 들어 있는 웹 기본 기능을 명확히 쓰라고 지시하는 것이다. 예를 들어 주소의 검색값을 직접 쪼개는 코드는 약 140토큰이지만, URL과 URLSearchParams를 쓰면 약 12토큰으로 줄어든다. 폼 입력값도 필드마다 상태를 따로 두면 200~250토큰이 되지만, FormData를 쓰면 약 14토큰으로 처리할 수 있다. 요청 취소, 여러 비동기 작업 처리, 대화상자 같은 화면 요소도 AbortSignal.timeout, Promise.allSettled, dialog 같은 기본 기능을 쓰면 코드가 훨씬 짧아지고 실수도 줄어든다. Deno 요청 처리기처럼 여러 작업이 섞인 코드는 기본 기능을 쓰면 반복 코드가 400~600 출력 토큰에서 60~90 출력 토큰 수준으로 줄 수 있다. 오래된 주석은 엘엘엠을 잘못된 방향으로 이끌 수 있으므로, 주석은 코드가 무엇을 하는지가 아니라 왜 그렇게 해야 하는지와 바꾸면 안 되는 조건을 적는 데 쓰는 편이 낫다.
한 초기 로펌은 8개월 동안 음성 에이전트로 놓치던 야간·주말 전화와 상담 예약 전화를 처리했다. 이 에이전트는 신규 고객과 기존 고객을 구분하고, 사건 내용을 받고, 상담 예약을 잡거나 바꾸거나 취소하고, 급한 내용은 팀에 바로 알리고, 모든 통화 뒤 요약 이메일을 보냈다. 처음에는 사람들이 바로 사람을 찾거나 전화 자동응답처럼 버튼을 눌렀고, 자연스럽게 말하도록 대화 흐름을 고치는 데 약 4주가 걸렸다. 안정화 뒤에는 571건의 전화를 처리했고, 453건의 상담을 예약했으며, 96.5%는 사람 도움 없이 끝까지 처리됐다. 전체 전화 중 176건, 약 3분의 1은 영업시간 밖이나 주말에 들어온 전화였다. 실제 전화에서는 지연 시간이 가장 중요했고, 응답이 조금만 늦어도 발화가 겹치거나 전화를 끊는 일이 생겼다. 정보는 이름, 전화번호, 이메일처럼 하나씩 받고 마지막에 한 번에 확인하는 방식이 효과적이었으며, 법률 조언처럼 절대 해서는 안 되는 답변은 시스템 프롬프트에 명확히 막아야 했다. 비용은 분당 약 0.13달러였고, 첫 응대 창구 전체를 맡기기에는 아직 부족하지만 음성사서함이나 야간 응대 보완용으로는 해외 콜센터와 비슷하거나 더 낮은 비용으로 쓸 수 있었다.
에이전트가 긴 일을 처리할 때 처음 몇 단계는 잘하다가 10단계쯤 지나며 실수가 늘 수 있다. 이미 실행한 도구를 다시 실행하고, 처음에 받은 지시를 놓치고, 자기 판단을 반복해서 되풀이하는 식이다. 모델 자체가 갑자기 바뀐 것이 아니라, 그동안 쌓인 내용이 문맥 창을 채우면서 판단에 방해가 된다. 문제를 추적해 보면 품질 저하는 보통 토큰 깊이가 깊어지고 문맥 창이 꽉 차는 시점과 맞물린다. 문맥 창 안에는 매번 다시 들어가는 전체 대화 기록, 처음 지시 위에 쌓인 긴 중간 과정, 통째로 들어온 도구 출력, 에이전트 자신의 이전 판단이 함께 쌓인다. 특히 큰 제이슨 형태의 도구 출력은 대부분 다시 쓰이지 않는데도 문맥을 크게 차지한다. 실수를 줄이려면 끝난 과거 대화는 결정만 남기고 요약하며, 도구 출력은 에이전트가 실제로 읽어야 하는 필드만 남기는 방식으로 소음을 줄여야 한다.
MCP-Dynamic-Router는 클로드 같은 인공지능 에이전트가 매번 모든 MCP 도구 설명을 읽지 않게 하는 중간 라우터다. 일반적인 MCP 사용 방식은 연결된 서버와 도구 정의를 모두 시스템 프롬프트에 넣는 경우가 많다. 문맥 창이 20만 토큰까지 가능하더라도, 실제 작업에 필요 없는 도구 100개를 매번 넣으면 입력 토큰 비용이 커진다. 도구 설명이 너무 많으면 모델이 어떤 도구를 써야 하는지 헷갈리고, 실제 도구 인자와 다른 값을 지어내는 오류도 늘 수 있다. 또한 세션 중간에 도구를 더하거나 빼려면 전체 문맥을 다시 불러와야 하는 운영 불편이 생긴다. MCP-Dynamic-Router는 먼저 작업 설명을 보고 필요한 도구 2~3개만 모델에 보여주는 방식으로 이 문제를 줄이려 한다. 음성·채팅 흐름에서는 사용자가 말하는 중간에도 일부 문장을 보고 읽기 전용 도구 연결을 미리 준비할 수 있고, 도구 설명과 요청이 정확히 맞으면 1밀리초 미만의 빠른 경로로 연결할 수 있다. 맞는 도구가 없을 때는 억지로 실행하지 않고 추가 질문이나 도구 없음 결정을 내리도록 설계됐다.
구글은 논문을 미리 검토하는 에이전트형 인공지능 도구인 Paper Assistant Tool을 만들었다. 이 도구는 논문 전체를 읽고, 이론 결과가 맞는지 확인하며, 실험이 타당한지 살피고, 고칠 점과 잠재적 오류를 찾아낸다. STOC와 ICML이라는 주요 컴퓨터과학 학회에서 제출 전 점검용으로 시험 배포됐고, 약 1만 편의 논문을 다뤘으며 결과를 약 30분 안에 냈다. 수학 오류를 찾는 평가에서는 제로샷 방식보다 오류를 찾아내는 비율이 34% 높았다. 핵심 방식은 한 번의 답변에만 맡기지 않고 추론 확장을 써서 더 깊은 문제를 찾는 것이다. 최종 판단은 사람 심사자가 맡고, 이 도구는 심사자가 보기 전에 큰 오류를 줄이는 보조 역할을 한다.
AI 자동화와 AI 에이전트는 같은 것이 아니다. 자동화는 미리 정한 순서대로 일을 처리하고, AI 에이전트는 언어 모델이 다음 행동을 직접 고른다. 이 차이를 구분하지 못하면 필요 없는 개발비와 운영비가 생긴다. 실제로 3주 동안 만든 고객용 에이전트가 월 200달러짜리 자동화 도구로도 충분히 해결될 수 있었다. 팀이 업무 순서를 종이에 쓸 수 없다면 자동화할 대상이 아니라 먼저 업무 흐름을 고쳐야 한다. 반대로 판단이 필요한 일을 에이전트에 맡기면 틀렸을 때 피해가 커질 수 있다. 고객 문의를 처리하던 에이전트는 대부분 답을 맞혔지만, 실제로 늦지 않은 주문을 지연됐다고 안내해 환불까지 발생했고 6주 만에 중단됐다. 지금 만들 가치가 있는 예로는 고객 문의나 영업 단서를 몇 시간 뒤가 아니라 빠르게 따라가는 리드 후속 자동화가 제시된다.
Token Warden은 Claude Code용 오픈소스 플러그인이다. 이 도구는 에이전트 작업 기록을 살펴보고, 메모리에 넣어둘 만한 효율 규칙 후보를 만든다. 그런 다음 고정된 테스트 묶음에서 각 규칙을 다시 시험한다. 규칙을 유지하려면 그 규칙을 메모리에 넣는 데 드는 토큰보다 최소 2배 많은 토큰을 아껴야 한다. 또 에이전트가 작업을 끝내는 데 실패하게 만들면 안 된다. 기준을 넘지 못한 규칙은 자동으로 제거된다. 목표는 쓸모없는 문맥 관리 규칙이 쌓여 오히려 비용을 늘리거나 작업 품질을 떨어뜨리는 일을 막는 것이다.
코딩 에이전트가 Claude의 문맥 창을 너무 많이 쓰는 문제를 줄이기 위한 오픈소스 작업 방식이다. 핵심은 코드 전체를 계속 Claude에 넣는 대신, 로컬 그래프로 코드 구조를 기억하고 필요한 코드 조각만 찾아 보내는 구조적 메모리 계층이다. 제시된 예시에서는 토큰 사용량이 1,230만 토큰에서 240만 토큰으로 줄었다. 이렇게 하면 같은 작업에서 Claude가 처리해야 하는 입력이 줄어들어 세션을 더 오래 이어가고 비용 부담도 낮출 수 있다. 이 방식은 GitHub 저장소로 공개되어 있어 다른 코딩 에이전트 환경에 옮겨 적용할 수 있다. 다만 난이도는 고급으로 분류되어 있어 바로 쓰기보다는 구조를 이해하고 맞춰 붙이는 작업이 필요하다.
ContextForge는 LLM이 긴 작업을 할 때 전체 대화 기록을 계속 들고 가지 않고, 매 단계마다 필요한 내용만 골라 작은 문맥을 다시 만드는 방식이다. 핵심 생각은 컨텍스트 창을 오래 저장하는 기억 공간이 아니라, 지금 작업에 필요한 작업대처럼 다루는 것이다. 여기에 LLM Wiki라는 구조화된 기억 층이 추가되어, 기록을 단순한 로그로 쌓는 대신 오래 남고 찾아볼 수 있는 지식 형태로 정리한다. 이 방식은 긴 실행에서 답변의 일관성을 높이는 데 도움이 되었다. 공개 저장소에는 180일, 500일 같은 긴 기간을 가정한 벤치마크 결과가 들어 있으며, 시스템을 한 번의 대화가 아니라 오래 살아 있는 과정처럼 시험한다. RecallBench와도 비교하고 있는데, 이 벤치마크는 단순히 정보를 다시 찾는지만 보지 않고 긴 작업에서 기억을 어떻게 쓰는지도 확인한다.
하루 약 12만 건의 사용 기록이 생기는 멀티모달 에이전트에서 답변 품질을 계속 점검하고 있다. 한 번의 사용자 상호작용마다 사실성, 도움 정도, 안전성, 도구 호출 정확도, 거절 판단, 범위 준수 같은 기준으로 약 6번의 평가 호출이 필요하다. 모든 기록을 검사하면 하루 약 72만 번, 주당 약 500만 번의 평가가 필요하지만, 현재는 실제 트래픽의 16%만 뽑아 주당 약 80만 번 평가한다. 평가용 모델로 gpt-4o-mini를 쓰며, 이 비용만 월 약 2,400달러가 든다. 더 싼 gpt-4.1-nano로 바꾸면 비용은 4분의 1 수준으로 줄었지만, 사람이 표시한 기준 데이터에서 gpt-4o-mini와의 판단 일치율이 87%에서 71%로 떨어졌다. 싼 모델을 먼저 쓰고 애매한 경우만 gpt-4o-mini로 넘기는 방식은 비용을 약 30% 줄였지만, 처리 지연이 생기고 운영 로직이 쉽게 깨졌다. 비슷한 평가 요청을 재사용하는 의미 기반 캐시는 평가 호출을 약 15% 줄였지만, 평가 기준이 바뀔 때 캐시를 다시 관리하는 일이 부담이 됐다.
AI 모델을 고르는 경쟁보다, 그 모델을 실제로 실행해 답을 만들어 주는 추론 인프라 경쟁이 더 중요해지고 있다. OpenRouter는 최근 1억 1,300만 달러를 투자받았고, 매주 47조 개의 토큰 요청을 여러 제공업체로 보내고 있다. 개발자는 OpenRouter에 요청을 보내고, OpenRouter가 어떤 제공업체를 쓸지 고르는 방식이다. 시장은 두 갈래로 나뉘고 있다. Fireworks, Together, Groq 같은 전문 추론 업체와 대형 클라우드 기업은 안정성, 서비스 보장, 기업 계약을 앞세운다. Akash, io net, Venice, c0mpute 같은 분산 네트워크는 중앙 회사가 정한 콘텐츠 필터, 계정 차단, 요청 제한이 적다는 점을 내세운다. DeepSeek는 OpenRouter에서 가장 많이 쓰이는 모델 5개 중 4개를 차지하고 있다. 모델이 무료에 가깝고 오픈소스로 쓸 수 있으면, 그 아래에서 누가 싸고 빠르게 실행하느냐가 더 큰 문제가 된다.
JetSpec은 대형 언어 모델이 답을 더 빨리 만들게 하는 추론 기술이다. 핵심은 모델이 다음 단어 후보를 나무 모양으로 한 번에 여러 갈래 준비한 뒤, 원래 모델이 맞는 후보만 받아들이게 하는 방식이다. 연구진은 이 방법이 답의 품질을 바꾸지 않으면서 MATH-500 문제 풀이에서 최대 9.64배, 자유로운 대화에서는 4.58배 빠른 끝단 속도 향상을 냈다고 밝혔다. 추가로 CUDA 그래프와 커널 최적화를 적용하면 단일 B200 그래픽카드에서 평균 초당 약 1000개 토큰을 처리할 수 있다고 한다. 기존 추측 디코딩 방식은 좋은 후보를 만들수록 계산 비용이 커지거나, 싸게 만들면 깊은 후보들이 서로 맞지 않는 문제가 있었다. JetSpec은 인과관계를 지키는 나무 구조 후보를 한 번에 만들어 이 두 문제를 줄이려 한다. 프로젝트 페이지, 코드, 블로그가 함께 공개되어 재현과 검토가 가능하다.
토큰 단위 과금 때문에 기업들이 작은 언어 모델을 다시 검토하고 있다. 소개된 연구는 고성능 모델 여러 개를 엮어 만든 에이전트 작업 흐름의 실행 기록을 작은 언어 모델 학습에 쓰는 방법을 다룬다. 이렇게 지도 미세조정을 하면 작은 언어 모델도 고성능 모델에 가까운 결과를 낼 수 있고, 비용은 훨씬 낮아질 수 있다는 주장이다. 핵심은 매번 비싼 모델을 여러 단계 호출하지 않고, 그 과정을 작은 모델 안에 어느 정도 흡수시키는 것이다. 실제 업무 환경에서 이 방식이 잘 작동하는지는 아직 확인이 필요하다.
컴퓨터 화면이나 브라우저를 조작하는 인공지능 에이전트는 화면 속 버튼과 아이콘을 정확히 찾아야 한다. Qwen2.5-VL, UI-TARS-1.5, GTA1 세 가지 화면 이해 모델은 ScreenSpot-v2 기준에서 모두 90%가 넘는 높은 정확도를 보였다. 하지만 실제 사용에 가까운 작은 변화만 줘도 성능이 크게 떨어졌다. 브라우저 확대 비율을 70%로 바꾸거나, 페이지 모양을 조금 바꾸거나, “검색창 위의 아이콘”처럼 위치 관계로 지시하자 정확도가 27~56점 낮아졌다. 실패한 사례를 모아 UI-TARS-1.5를 다시 학습시키면 나아질 것처럼 보였지만, 결과는 반대였다. 다시 학습한 모델은 모든 설정에서 기본 모델보다 나빠졌다. 학습 데이터를 6,500개에서 25,000개로 늘리자 성능 저하는 더 커졌다. 합성 데이터와 실제 실패 데이터가 모두 성능을 해쳤기 때문에, 문제는 데이터 품질 하나가 아니라 학습 방식 자체에 있을 가능성이 크다. ScreenSpot-v2 점수는 거의 변하지 않았기 때문에, 그 기준만 보고 있으면 더 나쁜 모델을 개선된 모델로 착각할 수 있다.
Ornith-1.0은 에이전트 코딩 작업에 맞춘 오픈소스 대형 언어 모델 묶음이다. 공개된 모델은 9B 일반 모델, 35B MoE 모델, 397B MoE 모델과 일부 압축 실행용 모델이며, 31B 일반 모델은 소개에는 나오지만 공개 목록에서는 확인이 애매하다는 반응도 있다. 개발팀은 397B 모델이 Terminal-Bench 2.1에서 77.5점, SWE-Bench Verified에서 82.4점을 기록해 Claude Opus 4.7과 비슷하거나 더 높은 결과를 냈다고 밝혔다. 35B 모델은 여러 코딩·에이전트 평가에서 비슷한 크기의 Qwen, Gemma 모델보다 높게 나왔다고 주장한다. 9B 모델은 작은 장비에서도 돌릴 수 있는 크기인데, 일부 평가에서는 훨씬 큰 31B·35B 모델과 맞먹거나 넘는 결과를 냈다고 한다. 핵심 학습 방식은 모델이 답만 만드는 것이 아니라, 문제를 풀기 위한 작업 절차와 보조 구조도 함께 개선하도록 훈련하는 것이다. 커뮤니티 반응은 기대가 크지만, 실제 에이전트 작업에서 성능과 속도, 비용 절감 효과가 검증되어야 한다는 분위기다.
Aura는 안드로이드폰 안에서 작동하는 인공지능 에이전트다. 핵심은 휴대폰 안에 자체 MCP 서버를 두고, 그 서버가 화면 터치, 글자 입력, 스크롤, 앱 실행, 화면 이동 같은 조작을 도구처럼 제공한다는 점이다. Aura는 질문에 답하는 데 그치지 않고 이 MCP 도구를 써서 실제 휴대폰 화면을 움직이고 작업을 실행할 수 있다. 같은 MCP 서버는 Aura만 쓰는 구조가 아니며, Claude Code 같은 외부 MCP 클라이언트도 연결할 수 있다. 즉 안드로이드폰의 조작 기능을 MCP 서버가 열어 주고, Aura나 다른 인공지능 에이전트가 그 기능을 이용해 기기를 제어하는 방식이다. 아직 개발과 실험 단계이며, 작동 모습을 보여 주는 시연 영상이 함께 제공됐다.
FizzBee는 몇 년 동안 개발된 오픈소스 형식 검증 시스템이다. 새 앱은 같은 기술을 써서, 막연한 개발 요청을 더 정확한 요구사항 문서로 바꾼다. 사용자가 프롬프트를 넣으면 중요한 추가 질문을 던지고, 요구사항을 형식 명세로 정리하며, 빠진 조건이나 복잡한 부분을 찾아낸다. 이어서 결과가 제대로 작동하는지 확인할 검증 시나리오도 만든다. 마지막에는 코딩 에이전트가 따라 할 수 있는 명세 문서를 제공한다. 여러 프로젝트 시험에서는 이 문서를 썼을 때 작동하는 코드를 얻기까지 필요한 반복 횟수가 줄었다는 결과가 제시됐다.
NVIDIA가 Nemotron-TwoTower-30B-A3B-Base-BF16을 공개했다. 이 모델은 Nemotron 3 Nano 30B-A3B를 바탕으로 만든 확산 기반 언어 모델이다. 보통 언어 모델은 글을 만들 때 토큰을 하나씩 순서대로 만든다. 이 모델은 고정된 자기회귀 문맥 타워와 확산 잡음 제거 타워를 함께 써서, 여러 토큰 묶음을 반복적으로 병렬 채움한다. NVIDIA 기준으로 기본 마스크 확산 설정은 기존 자기회귀 방식 대비 종합 벤치마크 품질의 98.7%를 유지했다. 동시에 실제 생성 처리량은 2.42배에 도달했다.
오픈소스 RAG 인프라는 기존 앱에 붙여 쓰는 형태를 목표로 한다. 문서를 작은 조각으로 나눌 때 문서 종류에 맞춰 문단 단위, 겹치는 구간 방식 같은 여러 전략을 쓸 수 있다. 마크다운과 HTML에서는 제목 구조를 각 조각에 함께 남겨 문서 안 위치를 알 수 있게 한다. 표 파일에서는 각 조각에 열 제목을 함께 붙여 의미를 잃지 않게 한다. HTML, 마크다운, PDF, 텍스트, JSON, XML, DOCX, XLSX, CSV, PPTX 같은 여러 형식을 읽고, 로컬 파일, 웹 주소, S3에서 가져올 수 있다. 문서에는 필터링용 메타데이터를 붙일 수 있다. 검색은 BM25와 벡터 검색을 함께 쓰며, 기본 비중은 벡터 0.7, 키워드 0.3이지만 조정할 수 있다. 문서 속성 필터로 PDF만 보거나 특정 태그가 붙은 문서만 찾을 수 있고, 검색 결과는 조각과 원본 문서 정보를 함께 돌려준다.
Pylon은 취미용 앱을 실제 서비스 수준으로 옮길 때 필요한 설정과 배포 부담을 줄이려는 풀스택 프레임워크다. 작은 프로젝트는 React나 Next.js로 빨리 시작하기 쉽지만, 실제 서비스에서는 화면과 서버를 나누고 AWS 같은 곳에 백엔드를 따로 올리면서 복잡도와 비용이 커질 수 있다. Pylon은 서버 렌더링 React, TypeScript 함수, 데이터 엔티티, 접근 정책, 실시간 동기화, 내장 인증, 백그라운드 작업과 예약 작업을 한 묶음으로 제공한다. 기본 데이터베이스는 SQLite이고, 실제 운영 환경에서는 Postgres로 바꿀 수 있다. 실행 환경은 Rust 서버이며, Bun을 이용해 TypeScript 함수와 서버 렌더링 React를 실행한다. Rails에서 영향을 받은 방식으로, 세세한 선택지를 많이 고르게 하기보다 정해진 관례를 따라 빠르게 만들고 배포하도록 설계됐다. 핵심 목표 중 하나는 코딩 에이전트와 잘 맞는 구조를 제공해, 에이전트가 앱을 만들고 다루기 쉽게 하는 것이다.
Anthropic은 Alibaba와 Qwen 연구 조직에 연결된 운영자들이 Claude의 능력을 빼내려 했다고 주장했다. 문제의 방식은 증류로, 더 강한 인공지능 모델의 답변을 이용해 더 작고 싼 모델을 훈련하는 방법이다. Anthropic에 따르면 2026년 4월 22일부터 6월 5일까지 약 2만5천 개의 가짜 계정으로 Claude와 2,880만 번가량 상호작용했다. 표적이 된 능력에는 소프트웨어 개발, 에이전트형 추론, 오래 걸리는 작업 처리 능력이 포함됐다. Anthropic은 이런 방식이 미국 인공지능 회사들이 들인 연구개발 비용을 우회해 경쟁 모델을 빠르게 키우는 데 쓰일 수 있다고 보고 있다. Alibaba는 보도 시점에 공개 답변을 내놓지 않았다.
이 챗봇은 대화 시작 후 약 5턴까지는 잘 작동하지만, 그 이후로는 일관성이 급격히 떨어진다. 사용자가 앞서 언급한 제약 조건을 잊어버리거나, 몇 메시지 전에 한 말과 모순되는 답을 하거나, 이전 맥락을 무시한 채 최신 질문에만 답하는 문제가 나타난다. 완전히 망가지는 수준은 아니지만 대화가 점점 부자연스러워진다. 개발팀은 Braintrust로 평가 체계를 구축해 두었고 품질 기준을 꾸준히 통과했지만, 이 문제를 전혀 잡아내지 못했다. 이유는 거의 모든 테스트 케이스가 하나의 질문과 하나의 답변으로만 구성된 단일 턴 평가였기 때문이다. 실제로 필요했던 것은 15~20턴짜리 대화 전체에서 챗봇이 일관성을 유지하는지를 확인하는 평가였다. 팀은 대화 전체를 데이터셋으로 만들어 통째로 채점해야 하는지, 아니면 각 턴을 개별적으로 평가한 뒤 결과를 합산해야 하는지 등 멀티턴 평가를 어떻게 설계해야 할지 방법을 아직 찾지 못한 상태다.
전략 의사결정 메모 3건, 저장소 기반 실행 브리프 1건, 버그 수정 2건으로 구성된 소규모 역할별 벤치마크에서 GPT-5.6의 Sol, Luna, Terra 라인업을 비교했다. 평가 기준은 판단력, 근거 활용, 리스크 인식, 경계 설정, 실행 가능성, 효율성이며 평가자는 모델 정체를 알고 채점했다(블라인드 아님). 다층 제품화 결정 과제에서 Fable 5 레퍼런스가 95점, Sol max 94점, Sol xhigh 90점, Sol high 87점, GPT-5.5 high가 81점을 받았다. 의사결정 방식 검토 과제에서는 레퍼런스 92점에 Sol max 91점이 근접했다. 경계가 정해진 기회 비교 과제에서는 Sol high가 94점으로 레퍼런스(95점)와 1점 차이만 났는데, 소요 시간은 81.5초, 추론 토큰은 369개에 불과했다. 반면 Sol max는 216.9초와 5,178개의 추론 토큰을 쓰고도 결정 내용은 달라지지 않았다. 저장소 기반 실행 브리프 과제에서는 Sol high가 93점(80.73초, 1,818 토큰), Sol medium이 91점(70.66초, 779 토큰)을 기록해 medium이 약 12.5% 더 빠르고 추론 토큰을 57% 적게 쓰면서도 high 수준의 성능을 거의 유지했다.
OpenModel은 로컬 컴퓨터와 클라우드의 여러 AI 모델을 한곳에서 다루는 실행 도구다. Hugging Face의 GGUF 파일, 직접 받은 모델 파일, Ollama 모델을 가져와 실행할 수 있고, OpenAI 방식이나 Ollama 방식의 로컬 API로 연결할 수 있다. 대시보드에서는 요청 수, 추정 토큰 사용량, 지연 시간, 처리 속도, 모델별 사용량, 최근 요청을 볼 수 있다. 로그인하면 월간 사용 한도, 모델별 가격 추정, 로컬 실행과 클라우드 실행의 비용 차이, 사용량과 비용 그래프도 확인할 수 있다. Claude Code, Codex, OpenRouter, BuilderStudio 같은 클라우드 기반 코딩 에이전트의 토큰과 비용 사용 기록도 모을 수 있다. 이 기록은 기본적으로 로컬 JSONL 파일에 저장되며, 동기화 명령을 직접 실행해야 외부 서비스로 전송된다. 프롬프트, 답변, 대화 내용, 소스 코드, 도구 인수, 모델 파일은 사용 기록 저장소에 남기지 않는 방식으로 설계되어 있다.