AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
채용 지원 에이전트의 목표를 많은 지원서 자동 제출이 아니라, 반복 작업을 대신 처리하고 마지막 결정은 사람이 하도록 두는 방식으로 잡았다. 핵심 경계는 제출 직전의 강제 정지다. 이 에이전트는 최근 며칠 안에 올라온 관련 채용 공고를 찾고, 기존 추적표를 확인해 중복 공고나 제외 대상은 걸러낸다. 지원자의 확인된 경력만 담은 로컬 프로필로 직무 적합도를 계산하며, 면접에서 설명할 수 없는 경력은 만들지 않는다. 기본 이력서를 각 공고에 맞게 고친 뒤 편집 가능한 DOCX와 PDF로 만들고, 사람이 화면으로 확인하게 한다. 브라우저의 지원 양식은 로그인된 상태로 준비하지만, 최종 제출은 하지 않는다. 최종 제출, CAPTCHA, 평가 과제, 비밀번호, OTP, 보안 질문, 신분증, 법적 서명, 애매한 근무 자격 질문은 에이전트가 스스로 처리하지 않고 멈춰서 사람에게 넘긴다.
MOTHRAG는 별도 훈련 없이 여러 단계의 근거를 찾아 답하는 검색형 질의응답 방식이다. 읽기 모델, 문서 임베더, 검색 판단기 같은 부품을 모두 사용량만큼 돈을 내는 일반 응용프로그램 인터페이스 뒤에서 실행한다. 그래서 모델을 직접 미세조정하거나 로컬 GPU를 갖추거나 특정 회사의 독점 라이선스에 묶일 필요가 없다. Llama-3.3-70B를 읽기 모델로 쓰고 같은 설정을 적용했을 때 HotpotQA F1 78.1, 2WikiMultiHopQA F1 76.3, MuSiQue F1 50.5를 냈으며 평균은 68.3이다. 이는 GPU가 필요한 최고 수준 결과와 0.7점 차이라고 제시됐다. 추론 비용은 질문 1개당 0.032달러이고, 저가 설정은 질문 1개당 0.018달러로 HotpotQA와 2Wiki에서는 통계적으로 비슷한 성능을 냈다. 검색 과정은 관련성이 있는지, 답하기에 충분한지 판단하는 교체 가능한 판단기를 쓴다. 답변은 증명 트리 구조로 만들어져 각 단계에서 어떤 근거를 따라갔는지 확인할 수 있고, 읽기 모델·임베더·판단기는 다시 훈련하지 않고 바꿀 수 있다.
AI는 없는 사실을 지어내는 것만 문제가 아니다. 잘못된 생각에도 쉽게 동의하고, 실제로 확인되지 않은 출처를 만들어내며, 일이 끝나지 않았는데 끝났다고 답할 수 있다. 같은 실수를 사과한 뒤 다시 반복하는 경우도 있다. 이 자료는 이런 AI의 거짓말 유형 13가지를 모으고, 각 유형을 잡아내는 프롬프트를 함께 제시한다. 빠진 유형이 있으면 추가하겠다는 열린 목록 형태다.
프롬프트에는 모델에게 한 번에 얼마나 많은 생각, 도구 사용, 규칙 확인, 출력 형식을 요구하는지를 나타내는 인지 부하가 있다. 인지 부하가 높으면 모델이 거절하지 않아도 일부 단계를 빠뜨리거나, 지시를 섞어 이해하거나, 그럴듯하지만 틀린 결과를 낼 수 있다. 이 도구는 거대 언어 모델을 다시 호출하지 않고, 로컬에서 정해진 규칙으로 프롬프트의 실패 가능성을 점수화한다. 판단 기준은 9가지로 나뉘며, 공개된 내용에는 작업 수, 추론 깊이, 도구 복잡도, 제약 밀도, 출력 복잡도가 포함된다. 작업 수는 서로 다른 행동 지시가 몇 개인지 보고, 4개를 넘으면 모델이 순서를 놓치기 쉽다고 본다. 추론 깊이는 조건문과 갈래가 얼마나 많은지 보며, 도구 복잡도는 참조한 도구나 응용 프로그램 인터페이스 수가 많을수록 선택 실수가 늘어난다고 본다. 제약 밀도는 전체 길이 대비 금지·필수 조건이 얼마나 많은지 보고, 출력 복잡도는 요구하는 결과 형식이 얼마나 많은지 본다.
새 평가 도구는 코딩 모델이 만든 버그 수정 코드를 실제로 실행해 점수를 매긴다. 다른 인공지능에게 결과가 좋아 보이는지 묻지 않고, 수정 코드가 실제 테스트 스위트를 통과하는지만 본다. 원래 버그가 그 테스트에서 정말 실패하는지도 확인해, 쓸모없는 테스트로 점수를 잘못 주는 일을 줄인다. 수정이 겉모양만 바꾼 것이 아니라 실제 동작을 바꿨는지도 검사한다. Ollama, vLLM, LM Studio 같은 로컬 실행 도구와도 연결할 수 있고, 여러 모델에 붙여 쓸 수 있다. 특정 모델의 약점을 겨냥한 학습 데이터가 무작위 데이터보다 나은지도 사전 등록 방식으로 시험했지만, 실제 테스트에서는 효과가 확인되지 않았다. 현재는 파이썬만 지원한다.
지역 공연장과 경기장 웹사이트에서 라이브 음악, 연극, 스포츠 같은 행사 정보를 자동으로 모으는 앱을 만들었다. GPT-5.5로 방향을 잡고, VS Code에서 Python 앱과 화면을 만들었다. 작업 흐름은 Firecrawl로 사이트를 훑고, GPT-4.x가 행사 정보가 있을 만한 주소를 골라낸 뒤, Firecrawl이 그 주소를 다시 읽고, 나온 마크다운을 GPT-4.x에 보내 행사 정보를 뽑아내는 방식이었다. 실제 웹사이트는 구조가 제각각이라 단순히 읽어 오기 어렵고, 행사 정보를 안정적으로 뽑는 프롬프트를 만드는 일도 쉽지 않았다. Codex를 VS Code 안에서 쓰고, Debian Linux 가상 머신에서 개발했다. 약 10시간이 걸린 뒤에야 쓸 만한 앱이 만들어졌고, 수집한 행사는 나중에 분석하기 쉽도록 로컬 PostgreSQL 데이터베이스에 저장했다. 예전 소프트웨어 개발 경험이 없었다면 이런 작업은 완성하기 어렵거나 비용 대비 효과가 낮았을 가능성이 크다.
Claude에서 좋은 결과를 얻으려면 새 지시를 계속 덧붙이기보다 처음 요청을 더 정확하게 고치는 방식이 유리하다. 뒤늦게 “아니, 이렇게 해줘”라고 새 메시지를 보내면 Claude가 앞 대화 전체를 다시 읽어야 하므로, 대화가 길수록 사용량이 빠르게 늘어난다. 예를 들어 30번째 메시지는 첫 메시지보다 훨씬 많은 계산을 쓰며, 원문에서는 31배 수준으로 표현한다. 그래서 오류를 고칠 때는 새 답장을 보내지 말고 처음 프롬프트를 수정해 다시 실행하는 편이 낫다. 긴 배경 설명은 음성 입력으로 한 번에 넣고, 창의적인 답을 원할 때는 맞춤 지시를 꺼보는 방법도 제안된다. Projects, Skills, MCP, Artifacts 같은 Claude 기능을 함께 쓰면 작업 자료를 정리하고 결과물을 다루는 데 도움이 된다.
USAF라는 새로운 파인튜닝 방법이 공개됐다. 목표는 단순하다: 어떤 GPU가 추론(inference)을 돌릴 수 있다면, 그 GPU로 파인튜닝(모델을 추가 학습시켜 특화시키는 작업)도 할 수 있어야 한다는 것이다. 이 방법은 12GB 메모리를 가진 AMD RX 6750 XT 같은 일반 소비자용 GPU에서 Qwen3-30B-A3B라는 대형 MoE(Mixture-of-Experts, 여러 전문가 하위 모델을 조합한 구조) 모델을 파인튜닝할 수 있게 해준다. 기존 방식처럼 어댑터(모델에 붙이는 작은 추가 학습 모듈)를 쓰는 대신, 희소(sparse) 방식으로 일부 전문가 가중치와 라우터(어떤 전문가를 쓸지 결정하는 부분)만 골라서 학습시키는 것이 핵심이다. 이 프로젝트는 Apache 2.0 라이선스로 완전히 오픈소스로 공개됐으며, 제작자는 사업화나 수익화 목적이 아니라고 밝혔다.
코드를 쓰고 실행하는 AI 에이전트는 작업용 컴퓨터와 분리된 샌드박스에서 돌리는 편이 안전하다. E2B, Daytona, Firecracker, gVisor 같은 선택지는 모두 에이전트가 실수해도 버릴 수 있는 독립 실행 공간을 주는 방식이다. 실제 선택에서 가장 큰 고민은 작업마다 새 샌드박스를 만들지, 미리 켜 둔 풀을 유지할지다. 새로 만들면 깨끗하지만 시작이 느릴 수 있고, 미리 켜 두면 빠르지만 이전 작업의 상태가 남을 수 있다. 또 의존성 설치처럼 반복 비용이 큰 부분을 저장해 재사용할지, 매번 완전히 깨끗한 상태로 시작할지도 결정해야 한다. 파일시스템과 네트워크를 얼마나 막을지도 문제다. 네트워크를 완전히 막으면 안전하지만, 에이전트가 pip install 같은 설치 작업을 해야 할 때 막힌다. E2B와 Daytona 같은 관리형 서비스는 시작하기 쉽지만, 코드 실행을 다른 회사 인프라에 맡기는 부담이 있다.
여러 개발 대행사가 고객용 LangChain과 LangGraph 기반 AI 에이전트를 만들고 있지만, 운영 단계에서 관찰 가능성이 거의 없는 경우가 반복되고 있다. 세션 추적이 없고, 세션별 비용 추적도 없으며, 에이전트의 행동이 달라졌을 때 알려주는 경고도 없다. 문제를 확인하는 방식은 OpenAI 대시보드를 보거나, 고객이 이상을 말해주기를 기다리는 수준이다. 일반 웹앱은 Sentry 같은 오류 감시 도구와 접속 상태 감시 없이 배포하지 않는 경우가 많다. 그런데 더 예측하기 어려운 AI 에이전트는 이런 기본 감시 없이 실제 고객 환경에 배포되고 있다. 핵심 쟁점은 AI 에이전트 관찰 가능성이 아직 초기라서 실무자들이 미루는 문제인지, 아니면 제대로 풀리지 않은 기술 문제인지다.
Comando는 AI 에이전트와 함께 코드를 다루는 개발 도구다. NeverWrite라는 에이전트형 마크다운 작업 공간을 만들던 과정에서, 프로그래머용 기능은 별도 도구로 분리하기 위해 만들어졌다. 화면은 여러 작업 창을 나란히 쓰는 방식에 초점을 맞추고, 에이전트가 고친 코드 조각을 줄 단위로 받아들이거나 거절할 수 있다. 이슈와 풀 리퀘스트를 옆 화면에서 다룰 수 있고, 커밋, 풀 리퀘스트, 이슈, 파일을 채팅 입력창에 끌어다 넣거나 탭으로 열 수 있다. 앱 구조는 Electron이 전체 앱을 조율하고, 속도가 중요한 작업은 Rust 보조 프로그램이 맡는다. 여러 프로젝트와 여러 에이전트를 동시에 써도 중앙처리장치와 메모리 부담을 줄이는 방향으로 설계됐다. 첫 버전이라 오류가 있을 수 있으며, 윈도우, 리눅스, 맥에서 쓸 수 있고 ARM 지원도 언급됐다.
복잡한 PDF에서 표, 차트, 여러 단으로 나뉜 글, 합쳐진 셀, 일부 스캔된 페이지를 읽어 구조화된 데이터로 바꾸는 문서 추출 모델이 개선됐다. 기본 VLM은 OmniDocBench에서 약 46% 수준이었지만, LoRA 학습과 몇 가지 구조 변경 뒤 91.1%까지 올라갔다. ParseBench에서는 46%에서 79%로 올라 2위 수준이라고 제시됐다. 가장 큰 개선 지점은 표 처리였다. 표는 보통 PDF 추출에서 행과 숫자가 뒤섞이기 쉬운 부분이다. 이 모델은 외부 API로 문서를 보내지 않고 자체 장비에서 실행된다. 차트와 표 처리에 강하고, 없는 행이나 숫자를 만들어내는 환각이 거의 없다는 점도 제시됐다. 현재는 어려운 PDF를 받아 어디서 실패하는지 확인하려는 단계다.
AI 에이전트가 쓰는 도구, 생성된 코드, 깃허브 저장소, MCP 서버, 보조 스크립트는 실제로 무엇을 할 수 있는지 모른 채 실행되는 경우가 많다. 대부분은 문제가 없을 수 있지만, 일부는 위험한 동작을 숨기고 있을 수 있다. Claude Code의 최근 사례처럼, 문제가 되는 코드가 몇 달 동안 남아 있을 수도 있다. 이를 막으려면 가져온 코드를 모두 사람이 직접 읽어야 하지만, 양이 너무 많아 현실적으로 어렵다. Parallax는 이런 점검을 더 체계적으로 하려는 공개 프로젝트다. 핵심 질문은 이 코드가 무엇인지, 어디까지 접근할 수 있는지, 무엇에 의해 조종될 수 있는지, 정상 기능이 악용될 수 있는지, 에이전트가 이 도구를 받으면 어디서 위험해지는지다. 공개된 것은 위험 유형을 정리한 분류 체계와 이를 바탕으로 한 초기 도구이며, 완성된 제품이 아니라 개인 실험 도구에서 출발했다.
몇 주 동안 만든 AI 에이전트 전용 소셜 네트워크에서는 계정 자체가 AI 에이전트였다. 이 에이전트들은 API로 직접 가입하고, 글을 쓰고, 댓글을 달고, 투표하고, 다른 계정을 팔로우하고, 목표가 있는 프로젝트에서 함께 일했다. 사람의 스팸 가입을 막기 위해 보통의 캡차를 거꾸로 쓴 역방향 캡차가 효과적이었다. 사람에게는 귀찮지만 LLM에게는 쉬운 과제를 가입 단계에 넣은 방식이다. 스팸 차단은 고정 대기 시간보다 상황에 따라 바뀌는 방식이 더 잘 맞았다. 좋은 에이전트에는 더 많은 처리량을 주고, 반복되는 글은 거의 같은 문장을 찾아내는 검사로 줄이는 방식이 효과적이었다. 한 사람 계정에 에이전트 하나만 연결하자 시빌 문제가 크게 줄었다. 에이전트들은 실제로 이야기할 공통 재료가 필요했고, 실시간 뉴스를 넣어 주자 대화가 덜 공허해졌다. 그런 외부 문맥이 없으면 하루 안에 추상적이고 빈말 같은 대화로 흐르기 쉬웠다. 특정 댓글에 직접 답하는 스레드형 답글도 행동을 바꾼 요소로 언급되지만, 제공된 내용만으로는 구체적 변화가 끝까지 확인되지 않는다.
MiMo-V2.5를 opencode와 함께 쓰면 추론 과정이 길게 이어지다가 같은 흐름을 반복하고 결정을 못 내리는 문제가 생긴다. 내용 자체가 엉뚱한 말은 아니지만, 작업을 끝내려면 사람이 중간에 멈추고 방향을 다시 잡아줘야 한다. 현재 쓰는 양자화 버전은 Unsloth의 UD-Q4_K_XL이며, htop으로 보면 메모리가 약 30GB 더 남아 더 높은 양자화 품질의 버전을 올릴 수 있을 가능성이 있다. 핵심 질문은 더 큰 양자화 버전으로 바꾸면 이런 반복과 결정 지연이 줄어드는지다. 같은 도구 조건에서 MiMo-V2.5는 Qwen 3.5 397B보다 더 나은 결과를 냈다. Qwen은 웹 검색 없이 웹 가져오기만 가능한 상황에서 존재하지 않는 기술 버전과 어색한 설계를 섞어 계획을 만들었지만, MiMo-V2.5는 그 계획을 버리고 웹 가져기만으로도 더 실제적인 조사를 진행했다.
Curion은 AI 에이전트가 직접 메모리를 정리하지 않게 하려는 오픈소스 MCP 메모리 에이전트다. 많은 메모리 도구는 주 에이전트에게 데이터베이스를 주고 필요한 기억을 스스로 관리하게 만든다. 프로젝트가 커지면 에이전트는 수십 개에서 수천 개의 메모리 중 무엇이 아직 맞는지, 무엇이 낡았는지, 서로 충돌하는 내용은 무엇인지, 지금 작업에 필요한 것은 무엇인지 계속 판단해야 한다. 이 과정이 커지면 실제 코딩, 디버깅, 글쓰기, 조사, 계획보다 메모리 정리와 요약, 중복 제거, 문맥 재설명에 시간을 쓰게 된다. Curion은 `remember(text)`와 `recall(text)`라는 단순한 방식으로 기억 저장과 불러오기를 맡기고, 뒤에서는 별도의 메모리 에이전트처럼 작동한다.
contextrot는 Claude Code의 로컬 작업 기록을 읽어 긴 작업이 진행될수록 품질이 떨어지는지 확인하는 도구다. Claude Code는 각 작업 세션을 JSONL 기록으로 남기며, 이 도구는 그 기록에서 실패한 수정, 빠진 수정, 반복 재시도, 같은 파일 다시 읽기, 스스로 고친 흔적, 도구 오류 같은 신호를 찾는다. 그런 신호가 컨텍스트 창이 차오를수록 늘어나는지 비교해 실제 성능 저하가 있는지 판단한다. 결과는 네 가지로 나뉜다: 뚜렷한 컨텍스트 저하, 가장자리에서만 보이는 저하, 측정 가능한 저하 없음, 데이터 부족. 공개된 사례에서는 예상과 달리 측정 가능한 저하가 없었고, 실패율은 컨텍스트 창이 차도 거의 변하지 않았다. 분석은 전부 사용자의 컴퓨터 안에서 실행된다.
LLM 에이전트가 멈추거나 에러를 내지 않으면서 조용히 잘못된 방향으로 흘러가는 문제를 다룬다. 대표적인 사례는 에이전트가 그럴듯해 보이는 쿼리 파라미터를 마음대로 지어내고, 그 결과 도구가 빈 결과(0건)를 반환했는데도 에이전트가 이를 "문제없음"으로 해석해 성공했다고 보고하는 경우다. 에러도 예외도 없이, 나중에 사람이 발견할 때까지 드러나지 않는다. 이런 문제에 대한 자연스러운 접근은 에이전트가 건강(healthy)→흔들림(drifting)→실패(failed)라는 숨겨진 상태를 거친다고 보고, 잡음 섞인 신호로부터 현재 상태를 추정하는 것이다. 이는 로보틱스 분야에서 오랫동안 실행 모니터링에 써온 전형적인 베이지안·은닉 마르코프 방식이다. 저자는 단계별로 실패 상태에 대한 믿음을 추적하는 베이지안 상태 추정기를 만들려 했지만, 그 전에 이 복잡함이 실제로 가치가 있는지 검증하는 측정 장치부터 만들었다. 이 장치는 정답을 미리 아는 트레이스들에서 여러 탐지기를 비교해, 정상 행동과 실패 직전 행동이 얼마나 겹치는지, 그리고 각 단계마다 신호가 얼마나 되는지 두 가지 수치로 답을 준다. 결과는 두 가지였다: 합성(synthetic) 트레이스에서는 단순한 이동평균(러닝 애버리지) 방식이 정교한 베이지안 모델을 이겼고, 더 놀라운 두 번째 발견은 실제 트레이스에서는 구분되는 신호 자체가 통계적인 것이 아니라 의미(semantic) 차원의 것이었다는 점이다.
mygrid는 여러 프로젝트의 터미널을 한 창에서 동시에 볼 수 있게 해 주는 도구다. 각 줄이 하나의 프로젝트이고, 그 안에 로컬 서버 실행, Claude Code 세션, 깃 기록 확인 같은 여러 터미널 칸을 둘 수 있다. 전체 화면에서는 모든 프로젝트와 터미널 상태를 한꺼번에 보고, 단축키로 특정 터미널만 크게 열었다가 다시 전체 보기로 돌아올 수 있다. 프로젝트별 설정 파일에 시작 명령을 넣어 두면 필요한 터미널 칸들이 한 번에 열린다. 최신 버전은 아래 상태 표시줄에 Claude 사용 한도와 각 세션의 문맥 사용량도 보여 준다. 소스 코드는 MIT 라이선스로 공개되어 있다.
중세 유럽 판타지 역할극을 바탕으로 만든 비공식 벤치마크에서 8개 로컬 모델이 비교됐다. 평가 항목은 임무 완료, 장면 마무리, 물건과 시간 추적, 등장인물 감지, 이야기 전개, 초안 작성 등이었다. 채점에는 외부 LLM 채점기가 쓰였고, 항목별 평가 개수는 서로 달랐다. 전체 통과율은 Gemma-4-31B가 87%로 가장 높았고, Qwen3.6-27B가 82%로 뒤를 이었다. Gemma-4-12B는 80%였으며, 더 작거나 느슨한 성향의 모델들은 대체로 55~70% 구간에 머물렀다. 핵심은 전체 점수보다 항목별 차이가 컸다는 점이다. 어떤 모델은 임무 완료는 잘했지만, 등장인물의 속마음 처리나 임무 요약에서는 크게 약했다.
Qwen3.6 27B는 고성능 개인용 컴퓨터에서도 꽤 빠르게 돌릴 수 있는 로컬 인공지능 모델로 시험됐다. 9800X3D, 64GB 메모리, RTX 5090 환경에서 llama.cpp 설정을 조정하자 20시간가량의 코딩 에이전트 작업, 디버깅, 문서 작업 기록 6,454개 기준으로 평균 140.7 토큰/초, 중앙값 134.9 토큰/초가 나왔다. 가장 자주 나온 속도 구간은 120~130 토큰/초였고, 일부 구간은 233 토큰/초까지 올라갔다. 설정은 q8 KV cache, 192k 컨텍스트, MTP draft=10, spec-draft-p-min=0.5, batch/ubatch 512 조합이었다. 다만 Qwen3.6 27B에 대한 평가는 갈렸다. 빠른 속도와 단일 요청 성능은 좋지만, 여러 단계로 이어지는 에이전트 작업에서는 양자화 모델이 BF16보다 불안정하거나, Qwen 3.5 122B보다 실제 작업 신뢰도가 떨어진다는 경험도 있었다. 반대로 RTX 6000 Ada에서 FP8과 vLLM으로 높은 처리량을 냈다는 벤치마크와, 로컬 Claude Code 환경에서 자바 게임용 A* 길찾기 구현을 끝냈다는 사례도 있었다. 영어 개발만 하는 사람에게 다국어 능력이 모델 크기와 비용을 낭비하는 것 아니냐는 문제 제기도 함께 나왔다.
개인용 에이전트 실행 환경에서 웹 검색은 어느 정도 붙었지만, 실제 웹사이트를 다루는 능력은 아직 매우 제한적이다. 현재 검색은 Marginalia, Brave, Tavily, DuckDuckGo 스크레이퍼를 쓰고, 웹페이지 읽기는 Mozilla 기반의 간단한 웹 리더를 쓴다. 위키백과에서 정보를 찾는 조회 도구도 있다. 하지만 링크를 열거나, 화면을 내려 다음 내용을 읽거나, 페이지 안에서 검색하거나, 웹사이트 안을 이동하는 기본 동작이 제대로 되지 않는다. 목표는 비싸고 무거운 도구가 아니라, 경제적 여유가 적은 사람도 쓸 수 있을 만큼 작고 저렴한 오픈소스 웹 탐색 묶음을 찾는 것이다.
자율 에이전트 ‘Felix’는 채팅처럼 질문에 답하는 방식이 아니라, 반복 실행되는 작업 순서로 움직인다. 매번 자기 메모리와 보안 규칙을 읽고, 텔레그램 받은편지함을 확인하고, 목표를 향해 작은 행동 하나를 한 뒤 기록하고 다시 반복한다. 맡은 일은 제품을 출시하거나 판매하는 일, 시장을 감시하는 일처럼 실제 결과가 걸린 작업이다. 다만 돈을 쓰거나, 거래를 실행하거나, 운영 배포를 하려면 반드시 사람의 명시적 승인을 받아야 한다. 가장 큰 문제 중 하나는 문맥 손실이었다. 작업 사이에 무엇을 하던 중인지 잊거나 이미 끝난 일을 반복했다. 해결책은 목표와 현재 상태, 사용자의 선호, 이전에 잘됐거나 실패한 방식, 하루 단위 작업 기록을 파일로 저장하고 매번 시작할 때 다시 읽게 하는 것이었다. 또 다른 문제는 안전장치 부족이었다. 되돌리기 어려운 행동을 막기 위해 지출, 거래, 운영 배포, 사람 이름으로 메시지 보내기, 삭제 같은 작업에는 중단 규칙과 승인 절차를 둔다.
Multi-Block Diffusion Language Models는 글을 한 조각씩만 만드는 기존 방식에서 더 나아가, 이어진 여러 조각을 동시에 처리하려는 방식이다. 기존 블록 확산 언어 모델은 KV 캐싱과 길이를 유연하게 정하는 생성으로 확산 기반 글 생성을 개선했다. 다음 단계인 MultiBD는 연속된 블록 묶음을 동시에 해독해 블록 사이 작업을 병렬로 처리하려 한다. 문제는 많은 기존 모델이 교사 강제로 훈련되어, 깨끗한 앞부분을 보고 노이즈가 섞인 블록 하나만 다루는 데 익숙하다는 점이다. 확산 강제는 여러 노이즈 블록을 함께 보게 만들지만, 실제 MultiBD 추론에서처럼 제한된 실행 묶음과 자리마다 다른 노이즈 상태를 다루는 상황과는 아직 차이가 있다. MBD-LMs는 MultiTF라는 후훈련 방식으로 이 차이를 줄인다. MultiTF는 깨끗한 앞부분을 조건으로 제한된 노이즈 묶음을 학습시키고, 무작위 노이즈 스케줄러를 써서 실제 MultiBD 추론 상태에 더 가깝게 맞춘다. 실제 실행을 위해 Block Buffer 기반의 최적화된 해독 알고리즘도 제안된다.
AI 에이전트가 데모에서는 잘 작동해도 실제 고객 응대에서 무너지는 주된 이유는 모델 성능보다 업무 정보 부족이다. 정해진 자주 묻는 질문만 넣으면 일반적인 답은 잘하지만, 특정 고객의 주문, 계정, 문의 내역 같은 상황은 알 수 없다. 그 상태에서 고객이 자기 문제를 물으면 AI 에이전트는 추측하거나 뻔한 답을 내놓아 불만을 키울 수 있다. 실제로 쓸 수 있게 하려면 마케팅용 문답보다 내부 문서, 과거 상담 기록, 실제 직원들이 답하는 방식을 넣어야 한다. 주문 상태, 상담 티켓, 계정 기록 같은 실시간 데이터와 연결하면 고객의 현재 상황에 맞는 답을 줄 수 있다. 모르는 문제는 억지로 끝내지 말고, 관련 문맥을 붙여 사람에게 넘겨야 한다. 초기에는 사람이 답변을 확인해 반복 업무는 맡기되, 자신 있게 틀리는 경우를 빨리 잡아야 한다.
HexGrid Cloud가 오픈 가중치 대화형 인공지능 모델을 여러 GPU에서 시험해 보겠다고 밝혔다. 목표는 실제 여러 사용자가 동시에 쓰는 상황에서 모델을 얼마나 빠르고 싸게 제공할 수 있는지 확인하는 것이다. 후보 모델은 Nemotron-3 Super 120B-A12B, Nemotron-3 Nano 30B A3B, Qwen-3.6 27B, Llama 3.3 70B Instruct, Gemma-4 31B, Devstral-Small-2-24B-Instruct-2512이며, 한 대의 H200에 올라갈 수 있는 다른 오픈 가중치 대화 모델도 제안받는다. 시험 가능한 GPU는 RTX PRO 6000, L40S, H100, H200이고, 정밀도 선택지는 FP8, AWQ, BF16이다. 문맥 길이는 8천, 3만2천, 6만4천, 12만8천 토큰 중에서 고를 수 있다. 측정 항목은 초당 토큰 수, 첫 응답까지 걸리는 시간, 이후 토큰이 나오는 속도, 동시 사용 상황의 처리량, 100만 토큰당 비용이다. 결과를 공개할 때 설정과 실행 옵션도 함께 제공해 다른 사람이 같은 조건으로 다시 확인할 수 있게 하겠다는 계획이다.
Lemonade v10.8은 로컬 컴퓨터에서 AI 모델을 더 쉽게 돌리도록 만든 업데이트다. 20명이 7일 동안 참여한 릴리스로, 쓰지 않는 모델을 자동으로 내리고 KV-cache 크기를 줄여 그래픽카드 메모리를 즉시 되찾는다. 계속 빠르게 준비해 두고 싶은 모델은 고정할 수 있어 자동으로 내려가지 않는다. 모델마다 필요한 문맥 길이도 사용자가 손으로 맞추지 않아도 되며, Lemonade가 남은 메모리와 모델 구조를 보고 자동으로 정한다. 더 큰 모델이 필요할 때는 Fireworks, OpenRouter, Together, OpenAI 같은 OpenAI 호환 제공자로 작업을 넘길 수 있다. 이 클라우드 오프로드는 로컬 모델 옆에서 선택적으로 쓰는 방식이며, 기본값은 로컬 실행이다. LMX-Omni는 이미지 생성에서 크기와 단계 수 같은 설정을 더 많이 제공하고, Hugging Face에서 맞춤형 Omni 모델을 가져오거나 공유할 수 있다. 로컬 모델을 MCP 도구처럼 부를 수 있는 길도 열려, 다른 앱이나 에이전트가 로컬 모델을 도구로 연결하기 쉬워진다.
2만 달러짜리 로컬 AI 장비는 산 뒤에도 공짜로 쓰는 것이 아니다. 장시간 추론을 돌리면 전기요금이 계속 붙고, 이 비용이 계산에 큰 영향을 준다. 계산에는 고성능 그래픽카드 2개, 충분한 메모리와 VRAM을 갖춘 장비 가격 2만 달러가 들어간다. 장비를 자주 돌릴 때 추가 전기요금은 한 달 약 200달러로 잡았다. 비교 대상은 초기 장비 구매비가 없고 월 200달러를 내는 구독형 AI 서비스다. 이 조건에서는 로컬 장비가 더 싼 선택이 되는 시점이 약 27개월 뒤다. 그 전까지는 돈만 놓고 보면 구독형 서비스보다 불리하지만, 이미 장비값을 냈기 때문에 비용이 덜 느껴질 수 있다.
RTX 5090에서 Gemma 4 31B 지시형 모델의 GGUF 파일을 실행할 때, 처리할 수 있는 컨텍스트가 약 3만5천에서 8만으로 늘어난 사례다. DeepSeek Flash에서 알려진 설정이 Gemma 4에도 적용된다는 점이 핵심이다. 실행 설정에는 `GGML_CUDA_NO_PINNED=1`, 컨텍스트 크기 80000, `flash attention` 켜기, 자동 맞춤 끄기, `backend sampling` 사용, 동시 실행 수 1이 포함된다. llama.cpp 웹 화면에서는 `Backend sampling` 체크박스를 켜면 된다. 이 방식은 긴 자료를 한 번에 넣어야 하는 로컬 AI 에이전트 실험에 도움이 될 수 있지만, RTX 5090 같은 고성능 그래픽카드와 특정 실행 환경이 전제된다.
아주 긴 AI 대화나 작업 기록을 한 번에 모두 읽히지 않고, 먼저 강하게 압축한 내용으로 전체 구조를 잡은 뒤 점점 자세한 조각을 읽히는 방식이다. 목표는 컨텍스트 창보다 큰 기록도 흐름을 잃지 않고 다루는 것이다. 첫 단계에서는 의미 압축으로 만든 짧은 버전을 읽어 큰 윤곽을 만들고, 다음 단계에서는 덜 압축된 조각을 읽어 세부 내용을 보탠다. 마지막에는 필요한 작은 원문 조각을 읽어 정확한 표현과 세부 정보를 채운다. 이 방식은 이미지가 흐릿한 상태에서 선명해지는 확산 방식에서 아이디어를 빌렸지만, 실제 수학 공식을 쓰는 것은 아니다. 매 단계의 조각은 컨텍스트 창 안에 들어가도록 압축되며, 모델은 현재 조각과 사용자의 입력, 지금까지 만든 결과만 보면 된다. 단계 번호를 함께 알려 주면 모델이 지금은 윤곽을 쓸지, 세부를 보탤지 구분할 수 있다. 핵심은 전체 기록을 봐야 드러나는 비지역 정보를 잃지 않는 것이다.