AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
벡터 검색 기반 RAG(검색 증강 생성)와 지식 그래프는 경쟁 관계가 아니라 서로 다른 문제를 해결한다. 벡터 검색은 '비슷한 문장'을 찾아주지만, 지식 그래프는 '서로 연결된 정보'를 찾아준다. 예를 들어 사모펀드에서 '물류 소프트웨어 분야를 잘 아는 사람이 누구인가'라고 물으면, 일반 RAG는 '물류 소프트웨어'라는 단어가 들어간 문서들(통화 녹취록, 투자 제안서, CRM 메모 등)을 유사도 순으로 찾아줄 뿐이다. 그런데 실제 답은 한 문서에 있지 않고 여러 시스템에 흩어져 있다. 2021년 통화 메모에 창업자 이름이 나오고, CRM 기록이 그 창업자를 특정 회사와 연결하고, 이메일에 파트너가 컨퍼런스에서 그 창업자를 만났다는 내용이 있고, 딜 메모에는 예전에 비슷한 건을 검토했다가 넘겼다는 기록이 있는 식이다. 이 네 문서는 서로 다른 시스템에 있어서, 일반 RAG는 이런 연결 고리를 따라갈 수 없다. 마이크로소프트의 GraphRAG 논문도 이런 한계를 지적했다.
큰 기술 문서에서는 OCR이나 PDF 분석기가 글, 표, 배치, 일부 이미지를 꽤 잘 뽑아도 답을 찾기 어려운 경우가 많습니다. 중요한 근거가 여러 청크로 나뉘거나, 잡음이 섞이거나, 표와 그림 안에 숨어 있으면 검색기가 필요한 부분을 제대로 가져오지 못합니다. 해결 방향은 더 좋은 문서 추출 도구만 기다리지 않고, 문서에서 만든 질문-답변 쌍을 중간 데이터로 다루는 것입니다. 흐름은 PDF나 문서를 OCR 또는 PDF 분석기로 읽고, 마크다운이나 배치 JSON으로 바꾼 뒤, 청크로 나누고 정리한 다음, 질문-답변 쌍이나 VQA 쌍을 만들고, 걸러내고 평가해서 RAG나 학습 데이터에 쓰는 방식입니다. 질문-답변 쌍은 최종 답변이 아니라 검색 품질을 높이는 구조화된 데이터가 됩니다. 지저분한 청크는 더 깨끗한 지식 조각으로 바꿀 수 있고, 긴 문서는 근거가 붙은 여러 질문-답변 쌍으로 나눌 수 있으며, multi-hop 질문-답변 쌍은 단순 검색이 놓치는 관계를 드러낼 수 있습니다.
한 AI 에이전트 워크플로는 약 85%의 확률로 성공하지만, 실패할 때마다 원인이 새롭게 달라진다. 실패 원인으로는 잘못된 도구 선택, 반복 루프, 잊힌 문맥, 시간 초과 등이 있다. 원인을 찾는 데 매번 1~2시간이 걸린다. 현재는 프롬프트, 도구 사용 기록 등을 포함한 로그를 모아 프런티어 LLM에 넣고 문제를 찾아주기를 기대하는 방식으로 해결하고 있다. 더 안정적으로 원인을 찾거나, 이런 문제를 더 잘 다루는 플랫폼이 필요한 상황이다.
힌디어 음성봇을 만들 때 가장 큰 문제는 사용자가 말한 뒤 첫 답변이 나오기까지의 시간이 길다는 점이다. 현재 구성은 LiveKit, 전화 연결 계층, GPT-4.1 mini를 함께 쓰는 방식이다. LiveKit 추론을 쓸 때 LLM의 TTFT는 평균 1,700밀리초였고, OpenRouter로 바꾼 뒤에는 가장 빠른 제공자를 고르는 설정을 써도 약 1,000밀리초까지밖에 줄지 않았다. 목표는 TTFT를 400~600밀리초로 낮추는 것이다. 위치가 인도라서 Bedrock이나 GCP의 ap-south 서버처럼 가까운 지역의 직접 서버를 쓰면 더 빨라질 수 있다는 조언이 있었다. 다만 OpenRouter가 뭄바이 지역을 표시하더라도 실제로는 Cloudflare를 거쳐 유럽이나 미국으로 보내는 것일 수 있다는 의심이 있다. 음성 합성 쪽에서는 Sarvam TTS의 TTFB가 약 300밀리초이며, Cartesia로 바꾸면 더 줄어들지 고민하는 상황이다.
Pocketagent는 Discord, Telegram, Slack 대화를 코딩 에이전트 조작 창처럼 쓰게 해준다. 에이전트는 사용자의 컴퓨터에서 돌아가며, 밖에서 접속할 수 있는 공개 아이피를 열 필요가 없다. 하나의 서버 안에서 여러 채널을 만들고, 채널마다 Claude Code, Codex, 또는 tmux로 실행되는 다른 터미널 도구를 연결할 수 있다. 각 채널은 다른 모델, 시스템 프롬프트, 저장소를 따로 가질 수 있다. 사용량 제한에 걸리면 메시지를 실패 처리하지 않고 순서대로 대기시킨 뒤, 제한이 풀리면 다시 실행한다. 에이전트는 대화 중에 반복 알림이나 한 번짜리 알림을 직접 만들고, 보고, 취소할 수 있다. 선택 기능으로 채널 기록을 일정에 따라 지워 오래된 문맥이 매번 답변에 끌려오지 않게 할 수 있다. 재시작 후에도 --resume으로 이전 대화를 이어가며, 단일 자체 호스팅 Python 프로세스로 실행되고 텔레메트리를 보내지 않는다.
Mark Zuckerberg는 Meta 내부 회의에서 지난 4개월 동안 AI 에이전트 개발이 기대만큼 빨라지지 않았다고 말했다. 회사는 기술 환경 변화에 더 빨리 적응해야 한다는 압박 때문에 인력 감축을 했지만, 그 과정이 깔끔하지 않았다고 인정했다. AI 중심으로 조직을 다시 짠 효과도 아직 뚜렷하게 나오지 않았다. 다만 Zuckerberg는 앞으로 3~6개월 안에 AI 투자에서 개선이 보이기 시작할 것이라고 봤다. 함께 나온 반응들은 AI 에이전트가 단순히 코딩 능력이나 도구 연결만으로 빨리 완성되지 않는다는 점을 짚는다. 큰 규모로 실제 업무에 넣으려면 인프라, 문맥 관리, 업무 범위 설정에서 혼란이 생기고, 이것이 개발 속도를 늦출 수 있다.
로컬 에이전트는 일반 웹페이지를 넘어서 CVE 의존성 그래프나 SEC 8-K 공시처럼 구조가 복잡한 자료를 다룰 때 쉽게 멈출 수 있다. Finnhub, PubMed, VirusTotal을 각각 따로 붙이면 속도 제한, 망가진 SDK, 서로 다른 응답 형식 때문에 관리가 어려워진다. AnySearch로 질의를 보내면 여러 전문 자료원을 한 번에 조회하고, 에이전트가 바로 쓰기 쉬운 JSON이나 Markdown 형태로 결과를 돌려준다. CVE-2024-3094를 물었을 때 CVSS 벡터, 영향을 받는 버전, 패치 일정, 기업 노출 신호가 한 번에 나왔다. 자료가 비어 있는 항목은 꾸며내지 않고 알 수 없음으로 남겨 환각을 줄였다.
실무 AI 에이전트는 계획 세우기, 도구 사용, 메모리, 권한만으로 충분하지 않다. 실패했을 때 단순히 도구 호출이 안 됐다거나 다시 시도하자는 수준에 머물면 같은 실수를 반복할 수 있다. 필요한 것은 어떤 가정이 틀렸는지, 어느 도구 호출이나 결과가 잘못된 상태를 만들었는지, 지금 남아 있는 상태가 무엇인지 파악하는 일이다. 또한 다시 시도해도 안전한지, 롤백이나 보상 처리가 필요한지, 다음 단계에 사람의 검토가 필요한지도 판단해야 한다. 관찰은 무슨 일이 일어났는지를 보는 일이고, 진단은 왜 이런 상태가 되었으며 다음에 무엇을 해도 안전한지를 정하는 일이다. 이런 실패 처리 능력은 에이전트가 그럴듯하게 말하는 능력보다 실무 신뢰에 더 직접적인 영향을 준다.
DeepSeek v4 Pro가 최근 며칠 사이 다르게 반응한다는 이야기가 나왔지만, 실제 변경인지 느낌의 착각인지는 밖에서 확인하기 어렵다. 호스팅 모델은 제공사가 내부 가중치를 조정해도 버전 번호나 변경 내역을 공개하지 않을 수 있다. 그러면 같은 프롬프트와 같은 평가를 돌려도, 지난주에 검증한 모델과 오늘 쓰는 모델이 같은지 확신하기 어렵다. 문제가 생겼을 때 원인이 내 코드 오류인지, 모델 자체의 회귀인지 분리하기 힘들다. 고정된 프롬프트 묶음을 정기적으로 다시 돌리면 행동 변화는 늦게라도 잡아낼 수 있다. 다만 그런 방식도 이미 바뀐 뒤에야 알 수 있고, 정확히 어떤 버전이었는지 증거를 남겨주지는 못한다.
건설 문서용 로컬 시각 RAG는 단순한 PDF 질의응답보다 훨씬 까다롭다. 첫 시험 대상은 828쪽, 약 1GB짜리 PDF이며 계약 문구, 시방서, 일정표, 복잡한 표, 건설 도면이 섞여 있다. 일부 페이지는 36×48인치 정도의 큰 도면 형식이고, 도식 주변의 글자, 설명선, 상세 번호, 공종별 도면처럼 위치와 배치가 중요한 정보가 많다. 목표는 표 구조를 유지하고, 계약 문구를 뽑아내고, 도면의 맥락을 기본 수준에서 이해하며, 자연어 질문에 근거 페이지를 붙여 답하는 시스템이다. 속도보다 정확도가 더 중요하다. 필요한 것은 전체 구조, 자료 처리 흐름, 계속 관리되는 도구 선택, 그리고 ChatGPT, Codex, Claude로 직접 만들 부분과 기존 도구를 써야 할 부분을 나누는 판단이다.
AI 기능을 넣은 작은 서비스와 에이전트 개발에서 비용과 중단 문제가 함께 드러나고 있다. 새로 공개된 MIT 라이선스 AI 관문 도구는 하나의 OpenAI 호환 주소를 통해 237개 LLM 제공업체로 요청을 보낼 수 있게 한다. 이 중 90개 이상은 무료 구간이 있고, 11개는 결제카드 없이 계속 무료로 쓸 수 있다고 주장한다. 운영자는 중복 계산을 뺀 기준으로 한 달 약 16억 개의 무료 토큰을 모을 수 있으며, Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI 같은 13개 이상 코딩 도구를 한 번에 연결할 수 있다고 설명한다. 핵심 기능은 한 제공업체가 속도 제한이나 서버 오류를 내면 다음 모델로 자동 전환하는 구조다. 관련 도구들도 같은 문제를 겨냥한다. Sanskrit-Mesh는 에이전트가 반복해서 보내는 시스템 프롬프트, 메모리, 상태값, 도구 호출 포장 정보를 압축해 구조화된 요청에서 55~77% 절감을 내세운다. 다른 프록시와 MCP 기반 도구들은 실제 청구 토큰 기준으로 약 72~87% 입력 토큰 감소, 코드 그래프 방식에서는 특정 벤치마크에서 약 80% 감소를 주장한다.
LangChain으로 에이전트를 만들 때 API 호출을 자꾸 잘못 지어내는 문제가 생겼고, 원인은 모델 자체보다 문서 구조에 있었다는 실무 경험이다. 마크다운, Confluence, OpenAPI 명세 같은 문서는 사람이 눌러가며 읽기 좋게 만들어졌지만, LLM이 혼자 필요한 정보를 찾아 쓰기에는 불편할 수 있다. 문서를 잘게 나누는 방식과 화면 이동 구조가 검색을 방해하면, 에이전트가 엉뚱한 정보를 가져오거나 없는 API 사용법을 만들어낼 수 있다. 해결 아이디어는 기존 문서를 에이전트가 먹기 쉬운 형태로 바꾸는 변환 계층이다. 예를 들면 의미별 문서 계층, 도구 호출 설명서, 검색에 맞춘 임베딩을 만들어 에이전트가 필요한 정보를 더 정확히 찾게 하는 방식이다. 이 문제는 LlamaIndex 같은 에이전트·검색 프레임워크 팀이나 플랫폼 팀에 의미 있는 좁은 시장일 수 있지만, 이미 프레임워크 내부에서 해결 중일 가능성도 남아 있다.
MIRAGE는 0단계부터 40단계까지 이어지는 웹 보안 실습 코스이며, 모든 단계가 브라우저 안에서 실행된다. 별도 접속 도구, 가상머신, 보안 전용 운영체제를 준비하지 않아도 된다. 실습 범위는 정보 수집, 화면에서만 믿고 처리하는 위험한 설계, 잘못된 접근 제어, IDOR, BOLA, Firebase나 Supabase 같은 서비스의 RLS 설정 실수까지 포함한다. 로그인, JWT, 토큰 악용, SQLi·NoSQLi·SSTI·명령 주입 같은 여러 주입 공격, XSS, SSRF, 안전하지 않은 역직렬화, GraphQL 문제도 다룬다. 마지막 부분은 AI와 대규모 언어 모델 공격으로 이어지며, 프롬프트 인젝션, 저장된 악성 지시, 마크다운 이미지로 정보가 빠져나가는 출력 처리 문제, 도구 권한이 너무 넓은 AI 에이전트의 혼동된 대리자 문제, 벡터 저장소의 BOLA를 포함한다. 내용은 2025~2026년에 실제로 나온 CVE와 사고 사례에 맞춰 구성되며, EchoLeak와 비슷한 간접 주입 공격도 포함된다.
Agentlas라는 코딩 에이전트 도구를 만든 개발자가 토큰 소비를 줄이기 위한 새 방식을 시도했다. 원래 이 도구는 사람이 직접 승인하는 절차를 중심에 두고, 사이트맵과 메모리 정리에 의존하는 구조였다. 이후 여러 에이전트를 동시에 굴리는 스웜 기능을 추가했더니 토큰 소비가 크게 늘어나는 문제가 나타났다. 원인은 두 가지다. 첫째, 스웜은 매번 독립된 새 세션으로 시작하기 때문에 코드베이스를 처음부터 다시 탐색해야 한다. 둘째, 스웜을 쓰지 않아도 새 세션에서 코드를 수정하려면 코드 탐색에 많은 시간이 든다. 코드베이스가 커질수록 그렙(grep)으로 검색하고, 추측하고, 에러를 열어보는 과정에서 문맥(컨텍스트)이 소진되는 문제와, 메모리 기록만 참고하고 실제 코드를 읽지 않아 놓치는 문제가 함께 커진다. 개발자는 이 두 병목의 공통 원인을 '저장 공간이 아니라 주의(attention) 비용'이라고 정의했다. 해결 아이디어는, UI 페이지마다 태그를 붙여 지도처럼 구조화했던 사이트맵 작업에서 착안해, 코드에도 같은 방식의 '코드맵'을 만들어 에이전트가 전체를 훑지 않고 필요한 부분만 바로 찾아가게 하는 것이다.
로컬 대규모 언어 모델은 노트북, 워크스테이션, 사무실 서버, 회사 내부망에서 직접 실행하는 인공지능 모델이다. 개발 업무에서는 코드 확인, 질문, 수정 제안, 패치, 테스트를 빠르게 반복할 수 있어 클라우드 모델을 부를 때 생기는 대기 시간, 호출 제한, 민감한 데이터 전송 부담을 줄인다. 여러 사례는 로컬 모델을 거창한 연구 장비가 아니라 업무 도구의 한 종류로 다루면 된다는 쪽에 가깝다. 내부 문서 검색, 초안 작성, 요약, 표준 업무 절차 정리, 고객 지원 답변 초안, 반복 문의 처리 같은 일은 로컬 모델과 잘 맞는다. 회사 내부망에 두면 고객 이메일, 계약서, 로그, 오류 기록, 소스 코드가 외부 챗봇으로 나가지 않는다. 다만 모든 클라우드 모델을 대체하는 방식은 아니며, 높은 추론 품질이 필요한 복잡한 판단이나 최신 지식이 중요한 작업은 여전히 외부 모델이 더 나을 수 있다.
Patch라는 작은 AI 에이전트는 팀의 Slack 알림, 업무 넘김 누락, 담당자 혼란을 줄이기 위해 만들어졌다. 처음 역할은 매일 회의 내용을 요약하고, 멈춘 일을 맡은 사람에게 확인을 요청하고, 결정 내용을 계속 기록하는 정도였다. 이 에이전트는 프로젝트 보드, 팀 채팅, 공유 문서를 함께 보면서 움직였다. 업무 카드가 막힘 상태로 바뀌거나, PR이 열리거나, 장애 대응 채널이 생기는 같은 신호를 보고 정해진 규칙을 실행했다. 매일 아침 9시 5분에는 배포된 일, 검토 중인 일, 막힌 일, 누가 무엇을 언급했는지를 묶어 팀에 알렸다. 어떤 일이 진행 중 상태로 3일 동안 새 소식 없이 남아 있으면, 아직 진행 중인지와 막힌 이유, 누가 풀 수 있는지를 짧게 물었다. 큰 판단 능력보다 같은 일을 빠뜨리지 않는 꾸준함이 팀의 업무 흐름을 사실상 이끄는 힘이 됐다.
LLM은 프롬프트와 도구 정의를 입력으로 받고, 일반 문장이나 도구 호출을 출력한다. 도구 정의는 파일 읽기, 파일 쓰기, 명령 실행처럼 LLM이 사용할 수 있는 기능을 미리 알려주는 목록이다. 각 도구 호출에는 파일 이름 같은 인수가 붙을 수 있다. 에이전트 하네스는 LLM을 한 번 부른 뒤 응답을 확인하고, 응답이 도구 호출이면 실제로 그 도구를 실행한 결과를 다시 LLM에 넣는다. 응답이 일반 문장이면 반복을 끝낸다. 이 단순한 반복 구조가 Claude Code, opencode, Codex 같은 코딩 에이전트의 핵심 뼈대다. 실제 제품은 더 복잡하지만, 기본 원리는 LLM 호출, 도구 실행, 결과 되먹임, 종료 판단의 반복이다.
소규모 SaaS 운영 환경에서 소셜미디어 AI 에이전트가 사람 승인 없이 정해진 시간에 실제 계정으로 첫 실행을 했다. 목표는 마지막 게시 시간을 확인해 중복 게시를 막고, 지식 베이스에서 주제를 골라 대상 독자와 글의 방향을 정한 뒤, 문구와 이미지를 만들어 Facebook과 Instagram에 올리는 것이었다. 댓글을 읽고 답장하며, 게시물 분석 수치를 가져오고, 했던 일을 메모리에 저장해 같은 내용을 반복하지 않게 하는 흐름도 포함됐다. 첫 실행에서는 이메일 목록이 낡아가는 초기 신호라는 주제를 적절한 독자에게 맞춰 골랐다. Instagram 게시가 처음에는 실패했지만 다시 시도해 게시에 성공했다. 블로그 연결은 404 오류로 실패해 건너뛰고 지식 베이스를 대신 사용했다. 두 플랫폼의 분석 단계는 Graph API 지표 오류로 실패했지만, 에이전트는 중단하지 않고 문제를 보고서에 기록한 뒤 계속 진행했다. 보고서 이메일 발송 부분에도 SMTP 설정 누락이 있었다.
뉴욕에서 열린 Vercel Ship 26은 AI 에이전트를 실제 업무에 쓰려면 모델 성능만으로는 부족하다는 점을 보여준다. AI 인프라는 단순한 챗봇을 돕는 단계에서, 스스로 일을 처리하는 에이전트를 받치는 방향으로 옮겨가고 있다. 그래서 에이전트가 코드를 실행하고, 제한된 환경 안에서 움직이고, 지금 무엇을 하는지 사용자에게 보여주고, 중요한 행동 전에는 사람의 확인을 받는 구조가 필요하다. 행사에는 창업자, 개발자, 투자자, 제품팀이 모였고 Anthropic, Slack, Notion, Stripe, Supabase 같은 회사가 세션에 참여했다. 핵심 관심사는 샌드박스 실행, 통제된 환경, 실시간 가시성, 사람의 감독처럼 에이전트를 안전하고 믿을 수 있게 만드는 기반이었다.
Khazad는 대형 언어 모델을 부르는 요청을 HTTPX 단계에서 가로채어, 비슷한 요청이면 이전 답변을 다시 쓰는 오픈소스 도구다. RAG 작업 흐름이나 AI 에이전트가 같은 질문을 반복하거나 비슷한 방향으로 탐색할 때, 요청이 외부 모델 서비스로 나가기 전에 의미 기반 캐시를 먼저 확인한다. 저장소로는 Redis 8 Vector 데이터베이스를 사용한다. 맞는 답이 있으면 거의 바로 응답을 돌려주므로 대기 시간과 추론 비용을 줄일 수 있다. OpenAI 기본 클라이언트, 직접 만든 래퍼, 가벼운 라이브러리처럼 내부에서 HTTPX를 쓰는 방식이면 특정 프레임워크에 묶이지 않고 쓸 수 있다. 서버 전송 이벤트와 토큰 스트리밍도 지원하며, 별도 프록시 서버를 운영할 필요가 없다는 점을 내세운다.
RAG 파이프라인은 깨끗하게 정리된 테스트 문서에서는 잘 작동해도 실제 문서에 붙이면 답이 조금씩 틀려질 수 있다. 겉으로는 모델이 문제처럼 보이지만, 실제 원인은 모델 출력이 아니라 앞단의 문서 처리와 검색 구조에 있을 수 있다. 첫 번째 위험 지점은 문서 수집과 쪼개기다. 문서 형식이 제각각이고, 문단이나 의미가 끊긴 채 조각이 나뉘고, 수집할 때 메타데이터를 거의 남기지 않으면 검색 결과가 엉뚱해진다. 이 경우 먼저 의심할 곳은 임베딩 모델이 아니라 문서가 어떻게 들어오고 잘렸는지다. 두 번째 위험 지점은 검색과 벡터 저장소다. 임베딩 모델 선택, 유사도 검색 조정, 메타데이터 필터링이 맞아야 필요한 정보가 모델까지 도착한다. 문서 조각에 출처나 최신성 같은 메타데이터가 없으면, 나중에 검색 결과를 출처나 시점으로 걸러낼 방법이 없다.
여러 클라우드 GPU 업체를 한곳에서 비교하는 웹사이트가 준비되고 있다. 대상 업체는 Vast.ai, RunPod, Lambda Labs 같은 서비스다. 목표는 GPU를 빌려 쓰는 사람이 여러 사이트를 따로 열지 않고 가격과 성능을 기준으로 필요한 장비를 찾게 하는 것이다. 현재 뒷단은 업체별 가격 수집, GPU 사양 동기화, Supabase 저장, 순위 점수 계산, API를 통한 화면용 데이터 제공까지 갖춘 상태다. 아직 앞단 화면은 뒷단과 연결되지 않았다. 비교 기준으로 시간당 가격 외에 VRAM, TFLOPS, 신뢰도, 시작 시간, 지역, 재고 여부 같은 항목이 거론된다. 추가로 어떤 업체를 넣어야 하는지, GPU를 자주 빌리는 사람들이 실제로 먼저 보는 조건이 무엇인지가 핵심 질문이다.
자체 문서를 바탕으로 질문에 답하는 RAG 시스템에서, 답은 자신 있게 보였지만 내용은 자주 틀렸다. 처음에는 모델이 내용을 지어낸다고 보고 프롬프트를 고치고, 온도를 낮추고, 다른 모델도 시험했다. 하지만 이런 조정은 임시 처방에 가깝거나 결과를 크게 바꾸지 못했다. 나쁜 답이 나온 순간의 추적 기록을 살펴보자, 모델에 들어간 문맥 자체가 부정확하거나 쓸모없는 경우가 많았다. 모델은 잘못 들어온 자료를 바탕으로 비교적 그럴듯하게 답하고 있었고, 핵심 문제는 회수 단계에 있었다. 문제를 회수와 생성으로 나누어 따로 점수화하자, 어디에 시간을 써야 하는지 훨씬 분명해졌다.
MiniMax M2.7_Q3_XL 모델을 집 안 서버에서 6개의 P40 그래픽카드로 실행한 실험이다. 장비는 Asus X99-E-WS 메인보드, Xeon E5-2680 v4 2.40GHz CPU, 128GB DDR4 메모리, SSD, P40 6개로 구성됐다. P40 6개를 합쳐 총 144GB 비디오 메모리를 썼고, 메인보드는 여러 그래픽카드를 쓰기 위해 BIOS를 수정했다. 32,768 토큰 문맥에서는 기본 설정에서 입력 처리와 답변 생성이 비교적 빠르게 나왔지만, 65,536 토큰과 126,720 토큰으로 문맥을 늘리면 속도가 크게 떨어졌다. Q8 KV 설정은 같은 긴 문맥에서 F16 KV보다 답변 생성이 더 느렸고, 126,720 토큰에서는 약 12.8% 느린 결과가 나왔다. 배치 크기를 2048에서 1024로 줄이고 작은 배치를 512에서 256으로 줄인 설정은 32,768 토큰에서 입력 처리 속도를 높이는 데 도움이 됐다.
맥에서 바로 실행하는 로컬 AI 앱을 모은 디렉터리가 공개됐다. 약 2,300개의 로컬 AI 앱을 살펴보고 분야별로 쓸 만한 앱을 고르는 것이 목표다. 기존에는 Ollama, llama.cpp, vllm 같은 도구로 로컬 모델을 직접 실행할 수 있었지만, 가끔 쓰는 사람에게는 실행 명령과 설정을 기억하는 일이 부담이 됐다. 코딩처럼 생산성이 중요한 작업은 여전히 Codex와 Claude 같은 클라우드 AI를 쓰는 편이 낫다는 판단도 담겨 있다. 대신 짧고 분명한 목적을 가진 앱이 로컬 모델, 작업 흐름, 화면 구성을 한데 묶으면 더 많은 일상 작업을 로컬 AI로 처리할 수 있다. Apple M5와 더 작아진 로컬 모델 덕분에 이런 앱 방식이 더 현실적인 선택지가 될 수 있다는 관점이다.
Gemma 4용 WebGPU 커널이 초당 255개 토큰 처리 속도에 도달했다는 사례가 나왔다. 밀집 모델에서 초당 100개가 넘는 토큰 속도가 나오면, 모든 작업을 Claude나 Codex 같은 유료 모델에 맡기지 않아도 된다. 가벼운 분석, 초안 작성, 반복 작업은 로컬 사설 모델이 맡고, 더 어려운 판단이 필요한 작업에만 프런티어 모델을 쓰는 방식이 가능해진다. 핵심은 빠른 로컬 모델이 개인정보를 밖으로 보내지 않으면서도 토큰 사용량과 API 비용을 줄이는 보조 작업자가 될 수 있다는 점이다.
Agent Behavior Lab은 도구를 쓰는 LLM 에이전트의 행동을 같은 조건에서 반복 시험하는 MIT 라이선스 오픈소스 도구다. 프롬프트, 도구, 역할, 이전 대화 같은 요소 중 하나만 바꾸고 나머지는 그대로 둔 뒤 여러 번 실행해 실제 차이를 본다. 결과는 안전 문제와 행동 실패율, 요소별 열지도, 효과 크기와 신뢰 구간 같은 지표로 묶어 보여준다. 판정 방식은 고정 규칙으로 만들 수도 있고 다른 언어 모델에게 맡길 수도 있다. OpenAI 호환 엔드포인트를 지원해 여러 모델이나 제공자를 바꿔가며 시험할 수 있다. React 19, Vite, TanStack Query, Express, Prisma, PostgreSQL, Docker Compose로 구성됐고, 예제 데이터가 있어 바로 대시보드를 채울 수 있다. 관련 논의에서는 새 모델이 정말 나은지, 에이전트를 감싸는 실행 도구가 결과를 바꾸는지, 겉으로 보이는 토큰 수 뒤에 하위 에이전트가 숨겨 쓴 토큰이 있는지 확인해야 한다는 문제가 함께 드러났다. 한 사례에서는 표면상 5만6000 토큰으로 보인 실험 뒤에 하위 에이전트가 20만5800 토큰을 더 쓴 것으로 나타나, 비용 비교가 쉽게 왜곡될 수 있음을 보여준다.
Qwable-v1은 Claude Fable-5의 코딩 에이전트 행동을 Qwen3.6-35B-A3B 모델에 옮겨 만든 공개 가중치 모델이다. Claude Fable-5는 2026년 6월 9일부터 6월 12일까지 약 4일 동안 공개됐다가 미국 수출 통제 지침 때문에 전 세계에서 중단된 Anthropic의 미리보기 모델이었다. 공개 당시 Fable-5는 SWE-bench Pro에서 80.3%를 기록했고, 출력 토큰 100만 개당 50달러로 매우 비싼 모델이었다. Qwable-v1은 공개된 Fable-5 실행 기록 중 사고 과정이 남아 있던 4,659개의 코딩 에이전트 기록을 학습해 만들었다. 학습은 단일 H200 그래픽 처리 장치에서 약 14시간 걸렸다. 이 모델은 에이전트용 지시문을 받으면 Claude식 도구 호출 형식에 맞춘 XML을 내보내며, str_replace_editor 같은 실제 Claude 도구 이름도 사용할 수 있다. 모델, GGUF 파일, 지도 미세조정 데이터셋은 Hugging Face에 공개됐고, 라이선스는 상위 자료를 따라 AGPL-3.0이다.
부동산 중개사는 웹사이트나 매물 포털에서 새 문의가 들어왔을 때 몇 분만 늦어도 고객을 다른 업체에 빼앗길 수 있다. 이 봇은 새 문의가 들어오면 바로 감지하고, 스팸이나 중복 제출을 먼저 걸러낸다. 그다음 문의 내용에 맞춘 답장을 보내고, 여러 번 메시지를 주고받지 않아도 중개사의 일정에 통화 예약을 넣는다. 밤이나 주말에도 같은 방식으로 즉시 응답한다. 구성은 Python, Claude, Google Sheets, SendGrid, Calendly를 연결한 방식이다. 특히 중복 답장 방지, 콜드 스타트 지연 방지, GDPR에 맞는 데이터 처리처럼 실제 운영에서 문제가 되는 부분을 다듬는 데 시간이 많이 들었다. 현재는 작은 규모나 중간 규모의 부동산 중개업체 1~2곳에 한두 달 무료로 적용해 보고 실제 피드백을 받으려는 단계다.
vLLM의 최근 주요 업데이트 뒤에 메모리 부족 문제가 줄어든 것으로 보인다. 이전에는 메모리를 미리 많이 잡아두는 방식과 설정 문제 때문에 긴 입력을 처리할 때 오류가 났다. 이 문제가 줄어들면서 RTX 5090에서 qwen27b를 돌릴 때 컨텍스트 창을 120k에서 240k까지 늘릴 수 있었다는 실제 사용 사례가 나왔다. 긴 문서를 읽거나 여러 단계로 일하는 AI 에이전트에는 더 큰 컨텍스트 창이 곧 더 많은 정보를 한 번에 다룰 수 있다는 뜻이다. 공개 소프트웨어는 꾸준히 업데이트하면 성능과 사용성이 좋아질 수 있으며, 이를 만드는 개발자와 유지보수자에게도 지원과 존중이 필요하다.