AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
mcpsnoop는 AI 클라이언트와 MCP 서버 사이에 끼워 넣는 투명 프록시 도구입니다. Claude Desktop, Cursor, Claude Code 같은 실제 AI 클라이언트가 서버에 보내는 도구 호출과 서버의 답장을 터미널 화면에 바로 보여줍니다. 공식 MCP Inspector는 별도 클라이언트로 접속하기 때문에 실제 사용 중인 클라이언트와 서버 사이의 대화를 놓칠 수 있지만, mcpsnoop는 실제 통로 안에서 JSON-RPC 요청, 응답, 알림, 서버 오류 출력까지 확인합니다. 일반 서버는 서버 실행 명령 앞에 mcpsnoop --를 붙여 감싸고, 웹 주소로 연결되는 서버는 앞단에서 요청을 받아 원래 서버로 넘기는 방식으로 추적합니다. 캡처한 도구 호출을 새 서버 사본에 다시 실행해 문제를 재현할 수 있고, 처음에 합의된 기능, 긴 JSON 내용, 오래 멈춘 호출, 느린 호출, 실패한 호출을 필터로 좁혀 볼 수 있습니다. 설치는 Go, Homebrew, 미리 빌드된 실행 파일을 지원합니다. mcpsnoop가 감싼 서버 명령을 실제로 실행하므로, 믿을 수 없는 서버는 분리된 환경에서 다뤄야 합니다.
Google Research의 TabFM은 표처럼 행과 열로 정리된 데이터를 다루는 기초 모델이다. 숫자 열과 범주 열이 섞인 데이터에서도 분류와 회귀를 할 수 있다. 별도의 파인튜닝이나 하이퍼파라미터 조정 없이, 예시 데이터를 문맥으로 넣으면 바로 예측한다. 예측은 한 번의 전방 계산으로 끝나기 때문에, 표 데이터용 모델을 따로 훈련하고 실험하는 부담을 줄일 수 있다.
Basemind는 코딩용 인공지능 에이전트가 큰 코드 저장소를 통째로 읽지 않아도 되게 해 주는 로컬 색인 도구다. 저장소를 사용자의 컴퓨터에서 색인하고, MCP로 에이전트에 연결하며, 300개 이상 언어의 코드 구조, 깃 기록과 변경 책임 정보, 90개 이상 문서 형식의 검색형 응답을 제공한다. 질문에 답할 때 전체 파일을 넘기기보다 함수 서명과 줄 번호처럼 필요한 단서만 먼저 돌려주기 때문에 토큰 사용을 줄일 수 있다. 더 자세한 코드가 필요할 때만 특정 함수 본문을 추가로 펼쳐서 가져오는 방식이다. Rust로 만들어졌고 MIT 라이선스로 공개됐으며, MCP 서버, 명령줄 도구, Claude Code 플러그인으로 쓸 수 있다. 한계도 있다. 큰 저장소를 처음 스캔할 때 시간이 걸리고, 파일이 바뀐 뒤 다시 스캔되기 전까지 색인이 실제 코드보다 늦을 수 있다. 비슷한 흐름으로 로컬 대형 언어 모델의 실행 속도와 메모리 사용을 조절하는 도구, 코드 의존 관계를 그래프로 보여주는 MCP 서버, 문서와 소스 파일에서 근거 묶음을 먼저 만드는 검색형 도구들이 함께 나오고 있다.
Claude Code와 비슷한 코딩 에이전트를 오래 쓰면, 답변과 터미널 로그가 대화에 계속 남아 출력 토큰과 사용 한도를 빠르게 소모할 수 있다. justsaydone은 Claude Code의 답변을 최대 95%까지 짧게 만들어 출력 토큰 비용을 줄이는 데 초점을 둔다. 비슷한 흐름의 도구들은 긴 빌드 로그, 설치 로그, 검색 결과처럼 한 번만 확인하면 되는 내용을 계속 대화에 남기지 않도록 줄이거나 나중에 불러오게 만든다. Claude Code Eco는 일반 절약 모드에서 출력 토큰을 31~73% 줄이면서 중요한 지적은 유지했다고 밝히고, 더 강한 모드에서는 최대 75%까지 줄였다고 제시한다. Boost는 로컬 CLI 계층으로 터미널 잡음을 걸러 에이전트의 문맥 창을 덜 차지하게 하려는 접근이다. PxPipe는 긴 입력 문맥을 이미지 입력으로 바꿔 토큰을 줄이는 방식이며, 자체 테스트에서 Fable 5 기준 60~70% 절감을 주장한다. 전체 흐름은 더 똑똑한 모델보다 먼저, 에이전트가 보고 말하는 양을 줄여 비용과 한도 문제를 완화하려는 실용적 시도에 가깝다.
BaryGraph는 지식 그래프에서 두 개념 사이의 관계를 단순한 선으로 두지 않고, 검색 가능한 독립 문서로 다룬다. 이 관계 문서는 BaryEdge라고 부르며, 각 관계마다 자체 임베딩 벡터를 가진다. 여러 BaryEdge를 다시 묶으면 MetaBary라는 세 항목 구조가 만들어지고, 서로 멀리 떨어져 보이는 개념 사이의 숨은 연결을 찾는 데 쓰인다. 기본 벡터 검색은 가까운 점만 찾기 때문에, 표현은 다르지만 같은 현상을 다루는 자료를 놓칠 수 있다는 문제를 겨냥한다. 예시는 궤도 역학의 비행체 이상 현상과 항성 역학의 이상 잔차처럼, 서로 인용하지 않고 임베딩 공간에서도 멀리 있는 개념을 연결하는 경우다. 구현은 MongoDB Community, mongot, nomic-embed-text를 로컬에서 사용하며, 전체 영어 Wiktionary 660만 문서를 대상으로 돌렸다. MCP 서버도 열려 있고, 사전 논문과 벤치마크 CSV가 공개되어 있다.
한 대기업 CIO와 나눈 대화를 정리한 내용이다. 대기업들은 고객 대상 에이전트보다 사내 인력 비용 절감을 위한 내부용 에이전트 구축에 훨씬 집중하고 있지만, 이를 뒷받침할 인프라는 아직 준비되어 있지 않다. 기업들은 '문맥(컨텍스트) 관리'가 필요하다는 것은 감지하고 있으나 이를 정확히 부르는 용어조차 아직 없는 상태다. 실무에서는 에이전트를 여러 개로 흩어진 사내 시스템에 그대로 연결한 뒤, 모델이 시스템 간 비즈니스적 의미를 알아서 추론해주길 기대하는데, 이는 실제 운영 단계에서 금방 무너진다. 핵심 문제 중 하나는 '정적 온톨로지'(고정된 개념 체계)다. 현실 세계는 매일 바뀌지만 온톨로지(사내 데이터·개념의 의미 체계)나 시맨틱 레이어(데이터에 비즈니스 의미를 입히는 계층)는 분기 단위로만 갱신되어, 배포되는 순간 이미 낡은 정보가 되어버린다. 사람으로 구성된 조직조차 몇 년마다 구조가 바뀔 만큼 현실은 계속 변한다는 점이 그 근거로 제시된다.
여러 AI 에이전트를 이어 붙인 작업 흐름에는 조용한 약점이 생기기 쉽다. 각 단계가 자기 결과를 스스로 통과 처리하면, 첫 단계의 조사 오류가 뒤 단계로 그대로 넘어간다. 다음 에이전트는 앞 단계의 완료 표시를 믿고 그 위에 결과를 만들고, 마지막 결과가 틀려도 중간 관문은 모두 성공으로 보일 수 있다. 이런 상태를 자기 인증이라고 부를 수 있고, 로그만 보면 작업 흐름이 정상처럼 보여 더 찾기 어렵다. 점검 방법은 각 단계가 자기 결과를 직접 평가해 다음 단계로 넘기는 지점을 모두 표시하는 것이다. 프롬프트 안에서 결과가 완성됐다고 판단되면 진행하거나, 확신도가 높으면 계속하라는 식의 조건은 위험 신호다. 해결은 더 좋은 문장을 쓰는 수준이 아니라 구조를 바꾸는 일이다. 결과를 만든 에이전트와 그 결과를 판단하는 역할을 분리해야 한다.
AtlasMind는 베타 상태의 오픈소스 VS Code 확장 도구다. VS Code 마켓플레이스와 공개 저장소에서 받을 수 있다. 20개가 넘는 AI 제공업체를 연결할 수 있고, 로컬 모델도 쓸 수 있다. 15개의 전용 에이전트가 있으며, 40개가 넘는 맞춤 기술과 MCP 서버 연결을 지원한다. 개인 정보나 기밀 데이터가 어떤 모델로 보내질지 제한하는 개인정보 대시보드가 있다. 테스트 대시보드에는 에이전트가 자동으로 사용할 수 있는 23개 테스트 절차가 들어 있다. 장기 메모리는 SSOT와 세션별 문맥을 따로 관리하도록 만들어졌다. 아이디어 대시보드는 아직 완성도가 낮아 본격 테스트 대상은 아니다.
중간 규모의 부동산 관리 회사가 네 곳의 건물에서 약 340세대를 관리하고 있다. 최근 놓친 전화가 많아지고 세입자 불만도 늘어서, 프런트 데스크가 받지 못하는 전화를 AI 음성 상담원으로 처리하는 방안을 검토하고 있다. 단순히 영업시간을 묻는 전화는 시연에서 잘 처리되는 것처럼 보인다. 문제는 3주째 처리되지 않은 수리 요청에 화가 난 세입자나, 따로 협상한 조건이 있는 임대 갱신 문의처럼 복잡하고 민감한 전화다. 이런 상황은 정해진 대본으로 해결하기 어렵다. 실제 운영 환경에서 AI 접수원이 무엇을 못 하는지, 특히 실패한 사례와 한계가 더 중요하게 다뤄지고 있다.
에이전트 평가 플랫폼을 고르기 위해 Testmu, Patronus, Confident AI 세 가지 도구를 비교했다. Testmu는 지원하는 플랫폼 범위가 가장 넓지만 기본 비용이 가장 높다. Patronus는 적대적 테스트에 가장 강하지만 다루는 범위가 더 좁다. Confident AI는 실제 운영 중 나온 기록을 계속 평가하는 운영 추적 평가에 강하지만, 여러 번 주고받는 다중 턴 대화 평가는 가장 약하다. 세 도구는 각각 다른 장점이 있고, 한 팀의 사용 사례는 세 장점이 모두 필요한 상황이다. 선택지는 하나를 사서 약점을 감수하거나, 두 개를 사서 빈틈을 메우거나, 직접 만든 맞춤 기능을 얹는 방식으로 나뉜다.
Godcoder는 개인 컴퓨터에서 실행되는 오픈소스 AI 코딩 에이전트다. 사용자는 자신의 LLM 키를 넣어 OpenAI, Anthropic, 또는 OpenAI 호환 모델 제공자를 직접 연결한다. 소스 코드는 중간 서버를 거치지 않고, 모델 요청만 사용자가 고른 제공자로 바로 보내는 구조다. 질문, 계획, 코딩 모드를 나눠 쓸 수 있고, 파일을 바로 고치고, 변경 차이를 확인하고, 이전 상태로 되돌릴 수 있다. 내장 터미널, 파일 탐색기, 세션 기록도 포함된다. 선택 기능인 컨텍스트 엔진을 켜면 큰 코드베이스에서 의미 검색, 구조 검색, 호출 관계 검색, 단어 검색을 함께 써서 필요한 코드 조각을 찾는다. 현재는 미리 만든 설치 파일이 준비 중이며, Rust, Node.js 20 이상, npm을 설치한 뒤 소스에서 빌드해야 한다.
Microsoft Research의 NextLat은 트랜스포머가 다음 단어만 맞히는 방식의 한계를 줄이려는 학습 방법이다. 기존 방식은 바로 다음 토큰을 예측하지만, NextLat은 현재 내부 잠재 상태와 다음 토큰을 바탕으로 다음 잠재 상태도 함께 예측하도록 훈련한다. 이렇게 하면 모델이 앞선 내용을 더 작은 믿음 상태로 압축해 기억하고, 추론과 계획에 쓸 수 있는 내부 표현을 만들도록 유도한다. 단어 하나를 맞히는 것보다 잠재 공간에서 예측하는 일이 더 촘촘한 학습 신호를 줄 수 있어 데이터 효율도 좋아질 수 있다. 또 여러 단계를 미리 내다보는 재귀 방식으로 자가 추측 디코딩을 하면서 추론 속도를 최대 3.3배 높일 수 있다고 한다. 논문, 블로그, 코드 링크가 함께 공개되어 있다.
검색 보강 생성 시스템을 만들기 시작해도 시간이 지나면 단순한 검색 기능이 아니라 여러 실행 결정을 직접 관리하는 구조가 되기 쉽다. 예를 들어 어떤 모델을 쓸지, 어떤 검색 방식을 쓸지, 대화 기억을 어떻게 붙일지, 답을 다시 검증할지, 도구를 어떻게 호출할지, 캐시와 예산을 어떻게 다룰지가 애플리케이션 코드 안에 쌓인다. 이 방식은 기능이 늘수록 고정된 파이프라인이 커지고 바꾸기 어려워진다. 제안된 방향은 애플리케이션이 실행 절차를 직접 정하지 않고, 원하는 목표만 전달하게 하는 것이다. 별도 실행 계층이 모델, 검색, 메모리, 검증 여부, 더 싼 실행 전략을 고르는 식이다. 이는 데이터베이스가 질문을 받으면 내부에서 효율적인 실행 계획을 고르는 방식과 비슷하다. 이 접근은 Python과 Go로 구현되었고, 관련 백서와 코드가 공개되어 있다.
추측 디코딩은 큰 언어 모델이 답을 더 빨리 만들도록 돕는 추론 최적화 방법이다. 작고 빠른 초안 모델이 다음에 올 토큰 여러 개를 먼저 예상한다. 그다음 더 크고 느린 대상 모델이 그 예상이 맞는지 한 번에 확인한다. 이 방식은 한 번에 토큰 하나씩만 만드는 흐름보다 여러 토큰을 함께 처리할 수 있어 응답 속도를 높인다. 목표는 출력 품질을 떨어뜨리지 않으면서 큰 모델의 토큰 생성 시간을 줄이는 것이다. SGLang은 Modal과 Z.ai의 DFlash 추측 디코딩 모델을 써서 언어 모델 추론 서비스의 지연 시간을 최신 수준으로 낮췄다고 밝혔다. Papers with Code에서는 이 방법 설명과 관련 논문, 원래 논문을 인용한 후속 연구를 함께 볼 수 있다.
Strata-K는 인공지능이 영어로 된 정책을 규칙으로 바꾸고, 그 규칙을 컴파일러와 결정론적 엔진으로 검사해 실행하는 논리 언어다. 예를 들어 “두 단계 안의 소유자 중 제재 대상이 있으면 거래를 승인하지 말라”는 정책을 규칙으로 만들게 한 뒤, 선언되지 않은 이름 같은 오류를 안정적인 오류 코드와 위치 정보로 알려준다. 이 오류 정보는 자동 수정 루프가 읽기 쉬운 형태라서, 단순한 실패 로그보다 고치기 쉽다. 규칙 검사를 통과하면 엔진이 같은 입력에 대해 항상 같은 방식으로 실행하고, 어떤 사실이 왜 참인지 전체 근거를 돌려줄 수 있다. 현재 공개된 코드는 Rust로 만든 CPU 기준 구현이며, 계층화된 Datalog, 부정 조건, 집계, 안정 모델, 정확한 확률 질의를 지원한다. 인공지능 모델을 타입 시스템 안의 조건처럼 쓰는 기능은 설계만 되어 있고 아직 구현되지 않았다. 코드는 MIT/Apache 라이선스로 공개되어 있다.
llama.cpp용 실험 기능으로 scatter 샘플러가 추가됐다. 이 기능은 다음에 나올 토큰 후보 중 이미 상위권으로 고른 후보들 안에서만 확률을 조금씩 나눠 갖게 만든다. 목표는 답변이 너무 딱딱하게 굳지 않게 하면서도, 온도를 올릴 때처럼 품질 낮은 하위 후보가 갑자기 섞이는 일을 줄이는 것이다. 빛이 퍼지는 모습에 비유하지만 실제 물리 계산은 아니며, 토큰 순위 주변에서 값이 조금 번지는 가벼운 평균 처리에 가깝다. 예를 들어 1순위 후보의 확률 일부가 2순위, 3순위, 4순위 후보로 옮겨갈 수 있고, 5순위 후보도 가까운 순위와 확률을 주고받는다. 현재 llama.cpp의 기본 샘플러 API와 샘플러 체인 이름 scatter로 구현되어 테스트된 실험 기능이다.
HRM이라는 반복형 구조를 문서 검색 모델에 적용한 실험이다. 목표는 단순히 비슷한 단어가 들어간 문서를 찾는 것이 아니라, 몇 단계의 생각을 거쳐 맞는 문서를 찾아야 하는 BRIGHT 기준에서 성능을 높이는 것이었다. 이 모델은 약 6억 개 매개변수로 작고, RTX 3060 Ti 8GB 한 장에서 학습됐다. BRIGHT 12개 영역의 평균 nDCG@10 점수는 기본 방식 18.1에서, 질문을 다시 쓰는 방식 34.3, 결과를 합친 방식 33.7로 올라갔다. 반복 횟수를 줄이면 pony 영역에서 정확도가 매번 떨어져, 반복해서 내부 상태를 다시 살피는 구조가 추론형 검색에 도움이 된 것으로 보인다. 한계도 뚜렷하다. 바탕 모델은 넓은 지식을 많이 배우도록 학습된 것이 아니라 효율을 위해 적은 텍스트로 학습돼, 지식이 많이 필요한 영역에서는 약했다. 가중치는 Apache-2.0으로 공개됐고, 전체 BRIGHT 평가 도구도 저장소에 들어 있다.
AI API를 내부에서 쓰는 팀은 작은 통제 실패만으로도 큰 비용을 낼 수 있다. 평소 월 AI 비용이 약 1만 달러였는데, 모델을 계속 부르는 잘못된 반복 실행 하나 때문에 하루 비용이 5천 달러를 넘었다. 또 운영용 Gemini 키가 AI 코딩 도구와 명령줄 도구에 쓰였고, 별도 개발용 키나 사용 한도가 없어 제공업체 쪽에서는 정상 사용으로 보였다. 일부 코드는 공식 키 관리 시스템을 거치지 않고 API 키를 직접 사용하고 있었다. 비용이 급증했을 때 돈이 빠져나가는 것은 보였지만, 어느 코드에서 시작됐는지, 누가 책임자인지, 바로 꺼도 안전한지 빠르게 판단하기 어려웠다. 핵심 문제는 비용 자체보다 반복 실행 제한, 키 분리, 사용량 추적, 소유자 확인 같은 기본 운영 장치가 약했다는 점이다.
SwiReasoning은 AI 모델이 답을 낼 때 '겉으로 드러내는 사고 과정(명시적 추론)'과 '내부적으로만 처리하는 사고 과정(잠재적 추론)'을 상황에 맞게 번갈아 쓰도록 만든 기법이다. 이렇게 하면 모델이 문제를 풀 때 필요한 토큰(글자 단위 처리량) 수가 크게 줄어, 답변 속도가 체감상 빨라진다. 한 사용자는 Qwen 3.6 27b 모델에 이 기법을 적용해봤더니 답변이 더 정확해지고 문제 해결 속도도 훨씬 빨라졌다고 보고했다. 초당 생성 토큰 수(t/s) 자체는 약간 느려졌지만, 전체적으로 필요한 토큰이 훨씬 적어서 결과적으로는 더 빠르게 느껴졌다는 것이다. 이 기법은 이미 9개월 전에 나온 것으로, GitHub 저장소(sdc17/SwiReasoning)와 llama.cpp용 구현체도 존재한다. 그럼에도 널리 알려지지 않은 이유가 뭔지 궁금하다는 질문이 커뮤니티에 올라왔다.
총 448GB VRAM을 갖춘 개인용 초대형 컴퓨터에서 MiniMax M3가 실행됐다. 장비는 96GB RTX Pro 6000 Max-Q 2장, 24GB RTX 3090 8장, 32GB RTX 5090 2장, 전원공급장치 3개, 128GB DDR5 메모리, Threadripper 9960x로 구성됐다. 모델은 AWQ-INT4 방식으로 줄여서 vLLM 위에서 돌렸고, PP와 TP 그룹을 함께 써서 여러 그래픽카드에 일을 나눴다. 속도는 한 사람이 단독으로 쓸 때 초당 약 30토큰, 묶음 처리에서는 초당 약 960토큰 수준이었다. 한 명에게는 100만 토큰 문맥까지 줄 수 있지만, 목표는 동시에 4명이 쓰는 방식이다. 긴 문맥을 여러 사용자에게 안정적으로 나누는 위치와 방식은 아직 정해지지 않았다.
tokenscope는 AI 코딩 에이전트가 작업 중에 쓴 토큰이 어디에 많이 들어갔는지 보여주는 오픈소스 도구다. 로컬 컴퓨터에 있는 세션 로그를 읽어, 같은 파일이나 내용이 여러 번 다시 들어간 경우와 너무 큰 도구 실행 결과가 컨텍스트 창을 많이 차지한 경우를 찾아낸다. 각 문제에는 줄일 수 있는 양의 추정치와 고치는 방법이 함께 붙는다. 설치 없이 `npx tokenscope-ai`로 실행할 수 있고, 전역 설치도 가능하다. Claude Code의 `~/.claude/projects/` 로그는 현재 0.1 버전에서 지원하며, 범용 프록시 모드, OpenAI 원시 JSONL 기록, Gemini CLI, aider용 어댑터는 뒤 버전 또는 사양 단계로 잡혀 있다. 결과는 터미널에서 볼 수 있고, 브라우저로 여는 단일 HTML 트리맵 보고서로도 만들 수 있다. 토큰 수는 로컬 토크나이저로 계산한 추정치라 약 5% 안팎의 오차가 있을 수 있으며, 정확한 청구액보다 낭비가 큰 부분을 찾는 데 초점이 있다.
로컬 RAG에서는 답을 만들어내는 디코드 속도보다, 답변 전에 긴 문맥을 먼저 읽는 프리필 속도가 더 큰 병목이 될 수 있다. RAG는 검색해 온 자료를 매번 프롬프트에 수천 토큰씩 붙여 넣기 때문에, 첫 답이 나오기 전 준비 시간이 길어진다. Strix Halo 같은 통합 메모리 기기는 일부 MoE 모델에서 디코드 속도가 초당 25~40토큰으로 괜찮아도, 프리필 속도는 개별 그래픽카드보다 크게 느릴 수 있다. 24GB 개별 그래픽카드는 같은 문맥을 몇 초 안에 처리할 수 있지만, 통합 메모리 환경에서는 첫 토큰이 나오기까지 20~60초를 기다릴 수 있다. 한 번에 많이 돌리는 배치 작업에는 통합 메모리도 충분할 수 있다. 하지만 자주 묻고 고치며 대화형으로 RAG를 쓰려면, 나중에 개별 그래픽카드를 추가할 수 있도록 PCIe 슬롯이 남는 보드를 고르는 편이 현실적이다.
LLM 앱 보안 테스트의 핵심은 서버 보안이나 로그인 문제가 아니라, 사용자가 예상 밖의 말을 하거나 정해진 흐름을 벗어났을 때 모델이 어떻게 반응하는지 확인하는 데 있다. 실무에서는 프롬프트 테스트와 기본 가드레일에 기대는 경우가 많아 보인다. Garak 같은 자동 점검 도구와 OWASP LLM 같은 보안 기준도 거론되지만, 실제 프로젝트에서 얼마나 널리 쓰이는지는 분명하지 않다. 그래서 필요한 비교 지점은 각 팀이 모델 행동을 어떻게 시험하고, 어떤 도구를 쓰며, 예외 상황을 얼마나 체계적으로 다루는지다.
AI 에이전트가 위험한 이유는 모델이 이상한 말을 하는 게 아니라 실제로 위험한 작업을 실행해버리는 데 있다는 문제의식에서 나온 프로젝트다. 이 도구는 앱과 LLM(OpenAI 호환 API 전부) 사이에 프록시로 들어가서, base_url 설정 한 줄만 바꾸면 모든 도구 호출(tool call)이 실행되기 전에 정책 검사를 거치게 만든다. 규칙은 YAML로 작성하며, 예를 들어 rm -rf 같은 삭제 명령을 막거나 배포 작업에는 강제로 dry_run(실제 실행 없이 결과만 미리 보기)을 적용하는 식이다. 호출이 차단되면 왜 막혔는지 모델에게 알려주는데, 그러면 모델은 대부분 오류를 내는 대신 스스로 다른 방법을 다시 생각해낸다. CI에서 자동 평가를 돌려 공격 차단율 40건 중 40.9건(90.9%), 오탐률(정상 요청을 잘못 막는 비율) 20건 중 1건(5.0%)을 기록했다. 놓친 4건은 일부러 테스트에 남겨둔 base64로 인코딩된 비밀정보 유출과 비영어권 언어로 된 프롬프트 인젝션(모델을 속여 의도치 않은 행동을 시키는 공격) 사례다. 코드는 MIT 라이선스로 공개돼 있고 API 키 없이 데모 실행이 가능하다.
Tilelli Lab의 Yaz는 지식을 추가, 수정, 삭제할 수 있다고 소개된 오픈소스 로컬 언어 모델이다. 새 사실을 반영하기 위해 모델을 다시 학습시키지 않고, 간단한 데이터베이스처럼 지식을 바꾸는 방식을 내세운다. 맞춤형 지식 관리나 오래된 정보 수정에 쓰는 것을 목표로 한다. 확신이 없을 때는 지어내기보다 “모른다”고 답하도록 설계됐다고 한다. 컴퓨터의 중앙처리장치에서 로컬로 실행되는 연구용 시제품이며, GitHub 저장소와 소개 페이지가 공개되어 있다. Tilelli Lab의 앞선 공개물로는 5달러짜리 ESP32 칩에서 실행된 Atome LM, 중앙처리장치에서 실행되며 모를 때 모른다고 답하도록 만든 Tilelli LLM이 언급된다.
Qwen3.5-9B 기반 파인튜닝 모델인 Qwythos-9B를 GGUF 포맷(Q4_K_M, Q8_0)으로 변환해 llama.cpp 서버 위에서 lm_eval 도구로 GSM8K, IFEval, HumanEval 벤치마크를 돌리는 과정에서 여러 문제가 발견됐다. 첫째, Qwen3.5 계열 모델은 추론(reasoning) 내용을 응답 본문과 별도 필드로 분리해서 반환하는데, llama-server를 --reasoning-preserve 옵션 없이 실행하면 벤치마크 도구가 빈 응답으로 인식해 점수가 50~80%나 떨어진다. 오류 메시지 없이 그럴듯해 보이는 나쁜 점수만 나오기 때문에 발견하기 어렵다. 둘째, IFEval 벤치마크는 langdetect, immutabledict 같은 숨겨진 의존성 패키지가 필요한데 이게 어디에도 명시돼 있지 않아, 몇 시간 걸리는 실행 도중 ModuleNotFoundError로 중단된다. 셋째, HumanEval의 기본 lm_eval 태스크는 채팅 API가 아니라 local-completions 백엔드를 전제로 만들어져 있어, 채팅 API를 호출한 뒤 생각(thinking) 블록을 제거하고 코드만 추출해 code_eval 지표로 채점하는 커스텀 스코어러를 직접 만들어야 했다. HellaSwag, ARC 같은 로그우도(loglikelihood) 기반 태스크는 세 가지 방법을 다 시도해도 막다른 길이었다.
중견 온라인 쇼핑몰들이 고객 지원 비용을 줄이려고 OpenAI나 Claude를 쇼핑몰 시스템에 붙인 단순 챗봇을 도입하고 있다. 반품 규정처럼 정해진 답을 말하는 일은 잘 처리하지만, 주문 수정, 배송지 변경, 일부 환불처럼 실제 처리가 필요한 요청에서는 문제가 생긴다. 무상태 방식의 대화 설정은 이전 대화 내용을 놓치거나, 응답이 느려지거나, 약속하지 않은 할인 같은 잘못된 답을 내놓을 수 있다. 더 큰 문제는 잘못된 주문 정보나 환불 정보를 백엔드 API로 보내 실제 업무 시스템까지 흔들 수 있다는 점이다. 해결책은 문장을 더 잘 쓰는 프롬프트 조정이 아니라, 고객의 흐름을 정해진 단계로 나누고 각 단계에서 할 수 있는 일을 제한하는 결정적 상태 기계 구조로 바꾸는 것이다. Dialogflow CX나 Vertex AI Agent Builder 같은 기업용 도구는 대화 흐름과 업무 처리를 더 엄격하게 관리하는 방법으로 제시된다.
AI 에이전트가 실제 업무를 처리하려면 돈을 보내고 받는 과정도 자동으로 다뤄야 할 수 있다. 예를 들면 해외 프리랜서에게 비용을 보내거나, 여러 나라의 서비스 구독료를 관리하거나, 원격 팀 급여와 기업 간 정산을 처리하는 일이다. 기존 은행 API는 해외 송금에서 시간이 오래 걸리고, 은행 영업시간의 영향을 받으며, 수수료가 높을 수 있다. 스테이블코인은 달러 같은 법정화폐 가치에 맞춰 움직이도록 설계된 디지털 돈이라, 하루 24시간 빠르게 정산할 수 있다는 장점이 있다. 그래서 앞으로 AI 에이전트를 위한 금융 시스템은 은행 API만 쓰거나 암호화폐 지갑만 쓰기보다, 법정화폐와 스테이블코인 경로를 함께 지원하는 혼합 구조가 더 현실적일 수 있다. 핵심 쟁점은 AI 에이전트가 스스로 거래를 실행할 때 달러를 스테이블코인으로 바꾸는 기능이 기본 기능이 될지 여부다.
자체 호스팅 앱이 OpenAI나 Claude 같은 외부 AI 서비스를 연결하도록 만들면, 개인정보 보호와 외부 의존을 줄이려는 목적과 충돌할 수 있다. 특히 단위 변환, 간단한 입력 정리, 운동 기록 조언처럼 기본 기능으로 만들 수 있는 일을 AI 연결 뒤에 두면 사용자는 불필요한 추론 비용과 외부 전송을 떠안게 된다. 반대로 좋은 로컬 모델을 직접 돌리려면 그래픽카드, 메모리, 전기 사용량이 필요하고, 어려운 작업에서는 클라우드 AI가 여전히 더 강하다는 현실적인 이유도 있다. 작은 로컬 모델은 자동완성, 이름 바꾸기, 단순 코드 수정 같은 반복 작업에는 충분할 수 있지만, 복잡한 여러 파일 작업은 외부 모델에 맡기는 식의 나눠 쓰기가 제안된다. 앱이 외부 AI를 선택 사항으로 두고 Ollama 같은 로컬 실행 도구나 OpenAI 호환 API를 함께 지원하면 자체 호스팅의 장점을 크게 해치지 않는다. 문제가 되는 지점은 AI가 없어도 되는 기능까지 필수 AI 기능으로 만들거나, 더 빠르고 싼 일반 코드로 해결할 일을 AI 호출로 처리하는 설계다.
Anthropic은 Alibaba와 Qwen AI 연구소가 Claude의 능력을 빼내 경쟁 모델을 훈련하려 했다고 주장했다. 의혹의 핵심은 2026년 4월부터 6월까지 거의 2만5천 개의 가짜 계정으로 Claude와 2,880만 번 상호작용했다는 점이다. 이런 방식은 강한 모델의 답변을 대량으로 모아 더 작은 모델이나 경쟁 모델을 학습시키는 증류 공격으로 볼 수 있다. Alibaba는 이 주장에 공개적으로 답하지 않았고, 의혹도 독립적으로 확인되지 않았다.