AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
AkbasCore는 Transformer 언어 모델이 답을 만드는 inference 단계에서 내부 상태에 아주 작은 방향성 압력을 넣는 C++ runtime 도구다. 모델을 다시 학습하지 않고, 모델 가중치를 바꾸지 않으며, 입력 prompt도 바꾸지 않는 방식이다. 기본 설정에서는 각 층에 들어가는 압력 크기가 bfloat16 정밀도 한계인 약 0.0078 이하로 유지되도록 설계됐다. 공개된 설명에 따르면 일반적인 cosine similarity 측정으로는 변화가 0처럼 보이지만, 출력 품질에는 구조적으로 측정 가능한 차이가 나타난다. 현재 상태는 2026년 6월 기준 pre-print이며, peer review는 아직 거치지 않았다. 작성자는 관련 테스트 76개가 Reddit에 공개 기록으로 남아 있다고 밝힌다.
git2llm은 GitHub 저장소의 커밋, 풀 리퀘스트, 이슈를 가져와 거대 언어 모델 학습에 쓸 수 있는 데이터로 정리하는 명령줄 도구이자 파이썬 라이브러리다. 개인이나 팀의 코드 변경 기록은 코드를 어떻게 쓰고 고치는지 보여주지만, 그대로 쓰기에는 품질이 낮다. 병합 커밋, 봇이 만든 변경 기록, 임시 작업, 의미 없는 커밋 메시지, 자동 생성 파일, 여러 브랜치에 반복된 비슷한 코드가 섞여 있기 때문이다. git2llm은 4단계 정리 과정을 거쳐 병합 커밋과 봇 소음을 빼고, 임시·초안·자동 생성 내용을 걸러내며, 거의 같은 변경도 중복으로 찾아 제거한다. 중복 제거에는 MinHash LSH라는 비슷한 내용을 찾는 방식이 쓰인다. 결과물은 Alpaca 또는 ShareGPT 형식으로 나오며, Unsloth, LLaMA-Factory 같은 지도 미세조정 흐름에 바로 넣을 수 있다. 자체 저장소에서는 원본 커밋의 78%가 제거될 정도로 학습에 부적합한 내용이 많았다.
Moltis Gateway MCP는 개인용 AI 에이전트 서버입니다. 하나의 서버에서 여러 인공지능 모델 제공업체를 쓰고, 음성, 메모리, Telegram, WhatsApp, Discord, Teams 같은 채팅 채널과 연결할 수 있게 합니다. 핵심 의미는 에이전트가 여러 서비스와 대화하도록 만드는 연결 관문을 한곳에 모으는 것입니다.
vault-engine은 민감한 문장을 클라우드 AI에 붙여넣기 전에 사람 이름, 회사명, 장소, 이메일 같은 식별 정보를 다른 표시로 바꾸는 파이썬 도구다. 감지는 기본적으로 내 컴퓨터에서 도는 로컬 대형 언어 모델과 정규식으로 처리되며, 바뀐 글만 ChatGPT, Claude, Gemini 같은 클라우드 모델에 보낼 수 있다. 클라우드 모델의 답변에 남아 있는 토큰은 나중에 내 컴퓨터에 저장된 역매핑 파일로 원래 이름과 정보로 되돌릴 수 있다. 영어와 중국어 예시를 강조하며, 중국어 이름과 조직명에도 강하다고 내세운다. 작은 합성 평가에서는 15개 문서의 77개 식별 정보를 대상으로 vault-engine이 전체 100%를 잡았고, Microsoft Presidio는 전체 61%, 정규식만 쓴 방식은 13%였다고 제시한다. 다만 이 평가는 작은 테스트용 자료라 법적으로 완전한 익명화나 개인정보 보호 보장을 뜻하지 않는다. 기본 설치는 pip로 가능하고, Ollama와 qwen3.6:27b 같은 로컬 모델을 붙여 쓸 수 있으며, 모델 없이도 이메일, 전화번호, 신분증, 카드, URL 같은 일정한 형식의 정보는 처리할 수 있다. 문맥을 어느 정도 유지하는 balanced, 더 강하게 숨기는 max, 덜 가리는 light 정책이 있으며, 역매핑 파일은 절대 클라우드나 저장소에 올리면 안 된다고 경고한다.
실제 서비스에 LLM을 넣으면 비밀 정보가 프롬프트, 문맥, 학습 데이터에서 새어 나갈 수 있다. 프롬프트 인젝션이나 탈옥으로 모델의 지시 체계를 우회하려는 공격도 생긴다. 도구나 플러그인을 붙인 에이전트는 단순한 질문 답변을 넘어 실제 시스템을 조작할 수 있으므로, 잘못 설계하면 피해 범위가 커진다. RAG에 외부 문서를 넣을 때는 그 문서 안에 숨은 악성 지시가 섞일 수 있다. 긴 대화에서는 에이전트가 민감한 문맥을 너무 많이 쌓아 둘 수 있고, 시간이 지나며 모델 행동이 바뀌어도 응답 속도나 서비스 가동률 같은 지표만 보면 문제를 놓칠 수 있다. LLM 앱에서는 믿을 수 없는 입력과 내부 로직의 경계가 쉽게 흐려진다. 그래서 모델에 들어가기 전의 모든 입력을 의심하고, 출처를 표시하며, 모델과 에이전트가 볼 수 있는 정보와 할 수 있는 행동을 제한해야 한다.
AI 에이전트를 실제 서비스처럼 만들 때 어려운 부분은 모델 성능만이 아니다. 더 큰 문제는 메모리, 작업 조율, 안정성, 관찰 가능성, 상태 관리, 도구 연결, 재시도, 권한, 버전 관리, 배포, 디버깅 같은 운영 기반에 있다. 새 모델과 성능 순위는 자주 나오지만, 에이전트가 실제 일을 끝까지 처리하게 만들려면 그 주변 시스템이 필요하다. 핵심 질문은 에이전트 시스템의 다음 발전이 더 똑똑한 모델에서 나올지, 아니면 모델을 안전하고 반복 가능하게 움직이게 하는 인프라에서 나올지다.
AI 에이전트가 파일, 셸, 브라우저, 외부 서비스, 이메일, 회사 시스템에 접근하면 배포 전 점검이 더 중요해진다. FCM Trust는 에이전트 프로젝트를 로컬에서 검사해 보안, 개인정보, 권한, 신뢰성 문제를 찾는 도구다. 현재 자격 증명 노출, 위험한 셸 동작, 지나치게 넓은 파일 접근, 외부 연결, 안전하지 않은 도구 권한, 입력과 프롬프트 처리 위험, 민감한 데이터 저장, 사용자 동의 장치 누락을 확인한다. 검사는 사용자의 컴퓨터에서 실행되며, 프로젝트를 외부로 업로드하지 않고 코드를 자동으로 바꾸지도 않는다. 에이전트 개발에서는 일반 소프트웨어 보안 점검표만으로는 부족할 수 있어, 수동 코드 검토, 샌드박스, 권한 명세서, 정적 분석 도구, 컨테이너 격리, 에이전트 전용 보안 테스트 같은 방법을 함께 논의할 필요가 있다.
소규모 사업 업무에 AI 에이전트를 붙일 때 큰 위험은 에이전트가 갑자기 엉뚱한 행동을 하는 것만이 아니다. 그런 실패는 눈에 잘 띄어서 비교적 빨리 잡힐 수 있다. 더 조용한 위험은 사람이 승인하는 단계가 시간이 지나며 형식만 남는 것이다. 실제 업무 자동화는 보통 낮은 위험의 되돌릴 수 있는 일은 자동 처리, 중요한 일은 사람 확인, 절대 맡기면 안 되는 일은 금지로 나뉜다. 이 중 사람 확인 단계가 가장 많은 가치를 만든다. AI 에이전트가 느리고 반복적인 준비 작업을 끝내고, 사람은 최종 결정을 맡기 때문이다. 하지만 확인 목록이 쌓이고 에이전트가 대체로 맞게 처리하면, 사람은 내용을 꼼꼼히 읽지 않고 빠르게 승인하기 시작한다. 시스템에는 계속 ‘사람이 승인함’으로 기록되지만, 실제로는 더 이상 제대로 검토하지 않는 상태가 될 수 있다.
개인 프로젝트나 프리랜서 프로젝트에서 매번 사람이 모델을 고르는 대신, 요청 내용에 맞춰 자동으로 적절한 대형 언어 모델을 고르는 방법이 필요하다. 목표는 작업이 어려운지, 비용과 품질의 균형이 어떤지, 응답 속도가 얼마나 중요한지, 입력할 수 있는 문맥 길이가 충분한지, 특정 제공사가 잠시 안 될 때 다른 제공사로 넘길 수 있는지를 기준으로 요청을 나누는 것이다. 가벼운 분류기나 의미 기반 라우팅도 검토 대상이다. 모델을 직접 파인튜닝하는 방식은 원하지 않으며, 이미 있는 오픈소스 프레임워크가 충분히 성숙했다면 그것을 쓰고 싶다는 요구다. 제공된 내용 안에는 특정 도구 이름이나 실제 사용 결과는 없다.
상태 없는 대형 언어 모델 챗봇은 별도의 외부 메모리 시스템 없이 대화 내용을 현재 입력 안에서만 처리한다. 긴 대화 초반에 중요한 사실을 넣고, 그 뒤로 관련 없는 메시지를 수백 차례 이어간 다음, 나중에 그 사실을 제대로 기억하는지 확인하는 평가 방식이 제안됐다. 핵심 측정 대상은 대화가 길어질수록 기억 정확도가 어떻게 떨어지는지다. 더 탄탄한 평가를 위해 긴 문맥 기억 한계를 재는 방식이 타당한지, 이미 쓰이는 더 나은 벤치마크나 방법이 있는지, 어떤 지표를 써야 설득력이 커지는지가 검토 대상이다.
Dario의 오픈소스 인공지능 모델 비판에 대한 반박이다. 핵심은 모델 내부를 볼 수 없다는 주장이 오픈 가중치 모델에는 맞지 않는다는 점이다. Claude 같은 닫힌 모델의 가중치는 볼 수 없지만, GLM 5.2 같은 모델은 가중치를 공개해 확인하고 직접 쓸 수 있다. Nemotron3 Ultra처럼 데이터, 훈련 스크립트, 모델까지 더 넓게 공개한 사례도 있다. 오픈 모델은 여러 사람이 고쳐 쓰며 성능을 개선하는 흐름도 실제로 이어지고 있고, 다양한 파인튜닝이 그 예로 제시된다. 또한 반드시 클라우드에서 돌려야 한다는 주장도 반박된다. 작은 MoE 모델이나 Qwen 27B 같은 고밀도 모델은 직접 운영할 수 있어, 상황에 따라 외부 서비스 비용을 줄이는 선택지가 될 수 있다.
AI 에이전트를 만들고, 여러 작업을 조율하고, 필요한 데이터를 붙여 답하게 하는 구조를 백엔드에 둘 수 있다. 이 방식에서는 프런트엔드가 사용자의 요청을 백엔드로 보내고, 백엔드가 준비된 에이전트로 답을 만든 뒤 결과를 돌려준다. 다른 기능이 필요할 때도 프런트엔드가 필요한 정보만 보내면 백엔드의 다른 에이전트가 일을 처리한다. 반대로 GitHub Copilot이나 Claude Code 같은 개발 도구는 많은 처리를 사용자의 컴퓨터나 작업 화면 쪽에서 한다. 코드와 개발 도구가 이미 그곳에 있기 때문에, 에이전트가 읽고 실행해야 할 자료와 도구도 그쪽에 가까이 있다. 핵심 고민은 에이전트 조율과 실행 틀을 백엔드에 둘지, 프런트엔드에 둘지, 또 백엔드 중심 구조에서 MCP를 어떻게 붙일지다.
코딩 에이전트를 일상 개발에 쓸 때, 작은 작업은 바로 구현하게 두는 편이 빠를 수 있다. 예를 들어 작은 버그 수정, 테스트 추가, 한 파일 안의 정리, 간단한 설명 요청은 계획 모드가 오히려 절차처럼 느껴질 수 있다. 반대로 큰 변경에서는 먼저 접근 방식을 설명하게 하는 것이 유용할 수 있다. 여러 파일을 고치는 리팩터링, 마이그레이션, 의존성 업그레이드, 인증이나 권한 변경, 운영 환경에 영향을 줄 수 있는 동작, 낯선 오래된 코드 수정처럼 요구사항을 잘못 이해하면 되돌릴 일이 커지는 작업이 여기에 해당한다. 이런 경우 코딩 에이전트가 먼저 코드를 살펴보고, 실행 계획을 제안하고, 승인 뒤에 파일을 바꾸게 하면 잘못된 작업을 줄일 가능성이 있다. 실제 사용 방식은 바로 구현하게 할지, 먼저 계획을 검토할지, 크거나 위험한 작업에만 계획 모드를 쓸지, 속도 때문에 피할지로 나뉜다.
AI 코딩 에이전트는 실수를 한 뒤 새 지시문을 추가해도, 나중에 비슷한 실수를 다시 할 수 있다. 문제가 되는 이유는 규칙이 실제 행동을 막는 장치가 아니라 문맥 안의 느슨한 기억으로만 남기 때문이다. 더 실용적인 방법은 실패한 행동을 기록하고, 그 행동을 실행 전 확인 규칙으로 바꾸는 것이다. 다음 도구 호출이 실행되기 전에 그 모양을 검사하고, 위험한 패턴과 맞으면 근거를 요구하거나 사람의 승인을 받게 해야 한다. 예를 들어 로그인하지 않은 사용자가 보호된 대시보드 주소에 들어가면 404 오류가 아니라 로그인 화면으로 보내져야 한다. 이 경우 “인증이 중요하다고 기억하라”가 아니라, 세션 없이 보호된 경로를 요청하고 로그인 이동과 되돌아갈 주소 보존을 확인하는 테스트가 필요하다. ThumbGate는 이런 피드백을 다음 셸 명령, 파일 수정, 브라우저 동작, 배포, API 호출 전에 확인 가능한 작은 관문으로 바꾸는 방식이다.
캐릭터형 AI 에이전트를 만들 때 가장 어려운 부분은 모델 선택이 아니라, 평범한 도우미 말투로 돌아가지 않게 하는 일이다. 모델은 “따뜻하지만 짧게 말하라” 같은 부드러운 지시보다 원래 갖고 있는 기본 말투를 더 강하게 따른다. 성격을 형용사로 설명하는 것보다, 반드시 지켜야 하는 장치를 넣는 편이 더 잘 작동한다. 가장 강한 말투 조절 방법은 엄격한 답변 길이 제한이다. 답변이 길어지면 기본 도우미 말투가 다시 섞이고, 짧게 제한하면 캐릭터성이 더 잘 남는다. 특별한 모드는 시스템 프롬프트의 일부가 아니라 핵심 지시가 되어야 한다. 도구를 꼭 써야 하는 상황에서는 “써도 된다”가 아니라 tool_choice를 필수로 설정해야 한다.
Obsidian 같은 노트 저장소를 Claude 같은 AI에 통째로 연결하면 오래된 메모 안의 민감한 정보까지 AI가 읽을 수 있다. 예전에 임시로 적어 둔 API 키, 데이터베이스 연결 문자열, 고객 계정 정보, 비밀번호가 모두 AI의 문맥에 들어갈 수 있다. 더 큰 위험은 AI가 스스로 나쁜 행동을 하는 것이 아니라 간접 프롬프트 주입이다. 예전에 저장한 웹페이지 안에 보이지 않는 지시문이 숨어 있으면, AI가 그 내용을 읽고 따르면서 민감한 정보를 답변에 드러낼 수 있다. Unit 42는 2026년 3월 실제 운영 시스템에서 이런 사례를 문서화했고, OpenClaw 사건에서는 주요 에이전트 장터의 12%가 같은 방식으로 침해됐다고 제시된다. 노트 저장소를 연결하기 전에는 sk_, aws_, ghp_, Bearer, password: 같은 문자열을 검색하고, 쓰기 권한 대신 읽기 전용 접근만 주고, 직접 작성하지 않은 웹 클립에 숨은 내용이 없는지 확인해야 한다.
텍스트를 만들어 주는 인공지능 API 중에서 계속 무료로 쓸 수 있는 곳만 모은 목록이 공개됐다. 기준은 신용카드가 필요 없고, 무료 사용량이 한 번만 주어지는 크레딧이 아니라 자동으로 다시 채워지는 방식이어야 한다는 것이다. 여러 LLM 제공업체를 직접 확인한 결과 37곳만 이 조건을 통과했다. 각 제공업체는 실제로 모델 엔드포인트가 작동하는지도 테스트됐다. 한 곳이라도 영구 무료 모델을 제공하면 목록에 남고, 무료 사용량이 더 이상 다시 채워지지 않으면 제외된다. 목록은 텍스트 출력 모델에 집중하며, 코딩에 쓰기 좋은 상위 10개 표도 포함한다. 깃허브 저장소에는 무료 사용량, 별점, 기본 주소가 정리되어 있어 코딩, 채팅, 간단한 에이전트 실험에 비용 없이 활용할 수 있다.
에이전트가 스스로 답할지 멈출지 정할 때 모델의 확신도를 기준으로 삼는 방식은 작은 모델과 중간급 모델에서 거의 믿기 어렵다. 무작위 숫자로 만든 여러 단계의 정수 계산 문제를 풀게 하고, 각 답과 0~100점 확신도를 함께 내게 한 뒤, 확신도가 실제 정답 여부를 얼마나 잘 맞히는지 비교했다. 점수는 0.5면 동전 던지기와 비슷해 아무 정보가 없고, 1.0이면 맞는 답과 틀린 답을 완벽히 가른다는 뜻이다. qwen2.5:7b는 0.50으로 거의 아무 구분을 못 했고, qwen3-coder:30b도 0.54로 크게 다르지 않았다. 두 모델은 틀린 답에도 매우 높은 확신도를 붙이는 경향이 강했고, 실제 정확도보다 확신도가 각각 0.72, 0.84만큼 높았다. 반면 glm-5.2는 0.73, Claude Sonnet 4.6은 0.90으로 확신도가 정답 여부를 더 잘 가렸다. Claude Sonnet 4.6은 확신도와 실제 정확도의 차이도 0.02로 작아, 스스로 멈출지 판단하는 기준으로 훨씬 안정적이었다.
부동산 중개인은 매주 많은 매수자와 이야기하면서 작은 조건을 놓치기 쉽다. 어떤 사람은 남향 집만 원하고, 다른 사람은 새 학기 전에 이사해야 하며, 또 다른 사람은 일주일 뒤 예산을 바꿀 수 있다. 이런 세부 정보가 고객 관리 도구에 항상 들어가지는 않는다. Bluedot은 회의에 별도 봇을 넣지 않고 녹음한 뒤, 대화록, 요약, 해야 할 일, 검색 가능한 회의 기록을 자동으로 만든다. Claude 연동을 쓰면 흩어진 상담 메모리를 AI 에이전트가 참고할 수 있는 기억층으로 바꿀 수 있다.
제안된 방식은 RAG를 한 번 검색해서 답하는 도구가 아니라, 답을 계속 점검하고 좁혀 가는 반복 구조로 다룹니다. 핵심은 답변을 만든 뒤 평가하고, 그 결과를 다시 답변 개선에 쓰는 닫힌 반복 구조입니다. 평가는 새로운 아이디어가 아니지만, 이 접근은 그 평가 과정을 싸고 빠르게 돌려 에이전트가 더 나은 답을 만들도록 돕는 데 초점을 둡니다. 질문은 단순한 기억 검색보다 답변을 통제하고 개선하는 실행 틀이 더 중요해진 것이 아니냐는 쪽에 가깝습니다. 관련 코드는 GitHub 저장소 wiggins-j/aiar에 공개되어 직접 시험해 볼 수 있습니다.
DeepSpec은 추측 디코딩에 쓰는 초안 모델을 훈련하고 평가하기 위한 전체 코드 모음이다. 추측 디코딩은 큰 모델이 답을 만들 때 작은 모델이 먼저 다음 내용을 빠르게 제안하게 해서 생성 속도를 높이는 방식이다. 이 모음에는 데이터 준비 도구, 초안 모델 구현, 훈련 코드, 평가 스크립트가 들어 있다. 공개된 체크포인트는 논문 표 1의 결과에 사용된 모델들이다. 각 체크포인트는 해당 목표 모델이 비사고 모드에서 만든 open-perfectblend 데이터로 훈련되었고, 저장소의 설정 파일에서 나온 훈련 결과물이다. 대상 모델은 Qwen3 4B, 8B, 14B와 Gemma 4 12B 계열이며, 알고리즘은 Eagle3, DFlash, DSpark가 포함된다. 결과를 논문이나 새 비교에 인용하려면 이 저장소의 훈련 설정과 맞춰야 하며, 그렇지 않으면 비교가 의미 없을 수 있다.
고객을 상대하는 인사 지원 업무가 헬프데스크 플랫폼에서 운영되고 있다. 이미 지식베이스와 연결된 챗봇이 있어 일부 문의는 사람이 보기 전에 처리된다. 하지만 여전히 많은 티켓이 상담원에게 넘어가고 있어, 단순히 답변을 안내하는 수준을 넘어 실제 해결까지 자동화할 수 있는 범위를 고민하고 있다. 핵심 질문은 자동 해결을 어디서부터 시작할지, 어떤 업무는 자동화해도 안전하고 어떤 업무는 사람이 맡아야 하는지, 실제로 시도할 때 무엇을 과소평가하기 쉬운지이다.
제안된 도구는 운영 중인 AI 에이전트의 추적 기록을 살펴보고, 실패 원인을 자동으로 찾아주는 디버거다. 느렸는지, 비용이 많이 들었는지 같은 결과만 보여주는 대신, 잘못된 검색, 틀린 도구 호출, 목표에서 벗어난 에이전트 흐름처럼 실제 원인을 특정 단계와 함께 보여주는 것이 목표다. 대상은 RAG 파이프라인, 도구를 쓰는 에이전트, 멀티 에이전트 시스템을 운영하는 팀이다. Langfuse나 Langwatch 같은 기존 관찰 도구는 추적 기록과 대시보드를 제공하지만, 문제의 원인을 찾으려면 사람이 로그를 직접 뒤져야 하는 경우가 많다. 이 도구의 핵심 가치는 조용히 숨어 있는 이상 징후를 찾아내고, 어떤 단계에서 문제가 시작됐는지 증거와 함께 알려주는 데 있다. 실제 수요를 확인하기 위해 에이전트 실패 원인 파악이 자주 겪는 문제인지, 별도 도구가 필요한지, 기존 관찰 도구에 들어가면 충분한지, 가장 귀찮았던 수동 디버깅 사례가 무엇인지 묻고 있다.
DFlash 지원이 llama.cpp에 합쳐졌다. llama.cpp는 큰 인공지능 모델을 개인 컴퓨터나 서버에서 직접 실행할 때 쓰는 오픈소스 도구다. 이 변화는 로컬 모델 실행 성능이나 효율을 높이는 기능이 llama.cpp 본류에 들어왔다는 뜻이다. 공개된 내용만으로는 속도 향상 폭, 비용 절감 수치, 지원 하드웨어, 설정 방법은 확인되지 않는다.
ChatGPT, Claude, Hermes 같은 여러 AI 도구를 함께 쓰면 각 도구가 다른 도구에서 이미 알게 된 내용을 공유하지 못한다. 그래서 같은 프로젝트 설명, 목표, 파일 구조, 결정 사항을 매번 다시 넣어야 한다. 현실적인 임시 방법은 프로젝트별 마크다운 파일 묶음을 만들고, 대화를 시작할 때 그 파일 경로를 알려 주어 기본 정보를 다시 불러오게 하는 것이다. 일부 에이전트형 메모리 도구도 시도됐지만 결과가 일정하지 않았다. 선택지는 크게 네 가지다. 하나의 마스터 문맥 파일을 모든 도구에 붙여넣기, 각 도구의 자체 메모리에 맡기기, 별도 에이전트형 메모리 계층을 쓰기, 또는 매번 다시 설명하는 비용을 감수하기다.
MDFlux는 PDF, 워드, 파워포인트, 엑셀, 전자책, 웹 문서, 이미지, 오디오 같은 파일을 AI가 읽기 쉬운 마크다운으로 바꾸는 윈도우용 데스크톱 앱이다. 스캔된 PDF나 이미지 문서도 OCR로 글자를 찾아내며, 폴더 전체를 한 번에 처리할 수 있다. 변환은 첫 설정 뒤에는 컴퓨터 안에서 실행되므로 문서를 클라우드에 올리지 않아도 된다. 문서를 이미지 그대로 비전 모델에 보내는 방식보다 토큰을 약 2~6배 적게 쓴다고 제시한다. 예시로 스캔 PDF는 비전 모델 방식이 10,731토큰을 썼지만, MDFlux가 OCR로 마크다운을 만들면 1,893토큰으로 처리됐다고 비교한다. 핵심 변환 엔진은 마이크로소프트의 MarkItDown을 쓰고, MDFlux는 여기에 스캔 문서 인식, 데스크톱 화면, 일괄 처리, 진행 상황 표시, 취소, 미리보기, 진단 기능을 더한다. 현재는 윈도우 10/11용이며, 첫 실행 때 로컬 파이썬 환경을 만들기 위해 인터넷이 한 번 필요하다. 앞으로 MCP 서버, 명령줄 도구, 맥용 앱, 코드 서명, 더 많은 OCR 언어 지원을 계획하고 있다.
Humanized-RAG는 지식창고에서 필요한 내용을 더 적은 검색으로 찾기 위한 실험적 RAG 방식이다. 핵심 아이디어는 문서 조각을 숫자 표현으로 바꾼 임베딩을 다시 묶어서, 더 압축된 “벡터의 벡터” 형태로 다루는 것이다. 이렇게 하면 벡터 데이터베이스가 모든 작은 조각을 처음부터 훑기보다, 큰 주제에서 작은 주제로 내려가며 찾을 수 있다. 구조는 목차, 주제, 하위 주제, 마지막 세부 내용으로 이어지는 계층형 나무에 가깝다. 이 나무는 임베딩을 비슷한 것끼리 묶는 클러스터링으로 만들며, 테스트에는 HDBSCAN이 쓰였다. 목표는 잘 알려진 RAG 방식들과 비교할 수 있을 만큼 효율적인 검색 엔진을 만드는 것이다. GitHub 저장소 HRAG가 공개되어 있고, 아이디어와 테스트 결과를 정리한 논문 초안도 개선과 출판 도움을 기다리고 있다.
로컬에서 직접 돌릴 수 있는 대형 언어 모델을 고를 때, 폐쇄형 모델과 오픈 가중치 모델을 한눈에 비교하기가 어렵다. 기존 벤치마크는 흩어져 있고, 실제로 로컬 실행에 좋은 모델과 API로만 쓰기 좋은 모델을 구분해 주지 못하는 경우가 많다. GLM-5.2급 모델을 돌릴 만큼 VRAM을 준비하더라도, 더 큰 모델이 항상 더 나은 선택인지는 불확실하다. 특히 70B에서 350B 사이 모델은 크기와 실행 복잡도는 크게 늘지만, 체감 품질 향상이 그만큼 크지 않을 수 있다. Qwen3.6 27B처럼 크기에 비해 인상적인 오픈 모델이 더 있는지도 중요한 비교 지점이다. 핵심 고민은 로컬 실행 비용, 장비 부담, 품질 향상 사이에서 어떤 모델이 실제로 쓸 만한가이다.
1000억~2500억 개 규모의 대형 AI 모델을 아주 낮은 정밀도인 Q1이나 Q2로 줄여서 쓰는 방식에 대한 질문이다. 예시로 DeepSeek-V4-Flash, Qwen3-235B-A22B, MiniMax-M2.X, GLM-4.5-Air, Mistral 계열, Llama 계열 같은 대형 모델들이 언급된다. 일부 사용자는 장비 메모리가 부족해 Q4를 돌리기 어려울 때 Q3까지 낮춰 쓰고 있으며, MiniMax-M2 같은 모델도 Q4가 빠듯해 Q3로 쓰는 사례가 있다고 한다. 작은 모델이나 중간 크기 모델은 Q1·Q2로 낮추면 품질이 크게 떨어질 것 같지만, 큰 모델은 원래 규모가 커서 낮은 정밀도에서도 쓸 만할 수 있다는 가정이 깔려 있다. 핵심 질문은 Q1·Q2로 줄인 대형 모델이 에이전트 코딩, 글쓰기, 일반 대화에 실제로 충분한지다. 특히 반복, 같은 말 되풀이, 작업이 빙빙 도는 문제 같은 품질 저하가 있는지 사용자 경험을 묻고 있다.
Qwen 3의 4B 이하 작은 모델을 컴퓨터의 CPU만으로 실행하는 간단한 추론 엔진이다. 파이썬 라이브러리를 이어 붙이지 않고 순수 C로 처음부터 작성됐으며, 기본 C 라이브러리와 수학 라이브러리, cJSON 정도만 필요하다. 병렬 실행을 원하면 OpenMP를 함께 쓸 수 있다. 허깅페이스의 safetensors 파일을 바로 읽고, 실행 중에 4비트 양자화를 적용해 모델을 더 작고 가볍게 다룬다. KV 캐싱도 들어 있어 대화가 이어질 때 앞의 계산 일부를 다시 하지 않도록 돕는다. 내장 채팅 화면이 있지만 속도는 매우 느리다. 실사용 성능보다 대형 언어 모델이 내부에서 어떻게 움직이는지 배우기 쉬운 코드와 설명에 초점이 있다.