AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Addy Osmani의 agent-skills 저장소가 5만 9천 개의 별을 받으며 관심을 모았다. 핵심은 AI 코딩 에이전트가 매번 좋은 개발 방법을 새로 판단하게 두지 않고, 반복해서 쓸 수 있는 스킬과 슬래시 명령어로 작업 흐름을 정리하는 것이다. 기본 흐름은 먼저 명세를 쓰고, 작은 작업으로 계획을 나누고, 한 조각씩 만들고, 테스트로 확인하고, 코드 상태를 검토한 뒤 배포하는 순서다. 각 명령은 상황에 맞는 스킬을 자동으로 켠다. 예를 들어 응용 프로그램 연결 방식을 설계하면 API와 인터페이스 설계 스킬이 켜지고, 화면을 만들면 프론트엔드 화면 설계 스킬이 켜진다. 특히 /build-auto 모드는 계획을 만든 뒤 한 번 승인을 받으면 자동으로 진행하되, 작업마다 따로 커밋하고 실패하면 멈춘다. 설치는 마켓플레이스에서 addyosmani/agent-skills를 추가하는 방식으로 제시되어 있다. 남은 실무 질문은 Claude Code 같은 도구에 자체 스킬을 붙일 때 기존 스킬과 충돌 없이 함께 작동할 수 있느냐다.
RepoWise는 코드 저장소를 더 잘 이해하도록 돕는 오픈소스 MCP 도구다. 문제의 출발점은 코딩 에이전트가 이미 읽은 파일을 몇 분 뒤 다시 여는 식으로 시간을 낭비한다는 점이다. 큰 저장소에서는 코드 파일 몇 개만 읽어서는 충분하지 않다. 어떤 사람이 특정 영역을 자주 고치는지, 어떤 파일들이 함께 바뀌는지, 몇 달 동안 불안정했던 부분이 어디인지, 이상해 보이는 설계 결정에 어떤 이유가 있었는지 같은 배경 정보가 중요하다. RepoWise는 이런 정보를 git 기록에서 찾아 MCP 도구로 노출하려고 한다. 코드 안에서는 잘 보이지 않는 파일 간 관계도 커밋 기록에서는 반복해서 드러날 수 있다. 아직 어떤 정보가 실제로 유용하고 어떤 정보가 단순히 보기만 흥미로운지 가려내는 단계이며, Claude Code나 Cursor 같은 코딩 에이전트가 저장소에 대해 미리 알면 좋은 사례를 찾고 있다.
AI 평가에서 모델이 채점한 답변을 더 쉽게 확인하기 위한 터미널 도구가 공개됐다. 이 도구는 채점 실행 결과를 주장, 근거, 판정으로 나누어 보여준다. 판정이 근거와 잘 맞지 않을 수 있는 부분도 표시한다. 사람이 직접 다시 봐야 할 이상한 사례를 찾는 데 도움이 됐다. 결과를 훑어볼 수 있는 작은 터미널 화면도 함께 제공된다. 관련 코드는 GitHub의 claim-memory-graph-sdk 저장소에 있다.
구매자가 바로 내려받아 쓸 수 있는 AI 에이전트를 파는 작은 장터 아이디어다. 고객은 에이전트를 외부 서비스에 맡기지 않고 자기 회사의 서버나 클라우드에서 직접 실행할 수 있다. 기존 업무 도구와는 응용 프로그램 인터페이스로 연결하는 방식이다. 핵심 질문은 내려받아 직접 운영하는 방식이 일반 구독형 서비스보다 신뢰를 얻을 수 있는지, 구매를 막는 요인이 무엇인지, 어떤 종류의 에이전트에 먼저 돈을 낼지, 설치형 결제와 구독형 결제 중 무엇이 맞는지다. 또 이 방식이 기업의 AI 도입을 막는 개인정보 보호와 규정 준수 걱정을 줄일 수 있는지도 쟁점이다.
코딩 작업에서는 하나의 AI 모델만 고르는 방식보다 작업에 따라 여러 모델을 나눠 쓰는 방식이 실용적일 수 있다. Codex는 어떤 코딩 작업에 더 잘 맞고, Claude는 다른 작업에 강점이 있으며, Gemini도 프로젝트에 따라 쓸모가 있다. 문제는 모델 성능 비교보다 구독, API 키, 결제, 초기 설정을 각각 관리해야 한다는 점이다. GPT Proto는 여러 제공업체를 따로 설정하지 않고도 여러 모델을 한곳에서 시험해 보는 용도로 쓰이고 있다. 공식 앱을 계속 쓰더라도, 코딩 흐름 안에서 모델을 비교할 때 한곳에서 다루는 방식이 부담을 줄일 수 있다.
한 firsthand 사례에서 Ragie 도메인에서 온 이메일이 피싱처럼 보였고, 서비스 종료를 암시하는 듯했다. 공개된 내용만으로는 Ragie가 실제로 종료되는지 확인되지 않았다. 당장 필요한 것은 직접 만들고 운영하지 않아도 되는 대체 RAG 서비스다. 내부 팀 규모가 작아 자체 구축은 현실적인 선택지가 아닌 상황이다.
Strix Halo 128GB 공유 메모리 환경에서 120B급 대형 모델 3개와 더 작은 Qwen 35B 모델을 비교했다. 비교 대상은 GPT-OSS 120B, Qwen 3.5 계열, Nemotron Super 120B, Qwen 35B였다. 핵심 기준은 답을 생성하는 속도보다, 긴 기존 코드와 요청 내용을 모델이 처음 읽고 처리하는 속도였다. 코드 변경이나 버그 수정에서는 전체 시간의 대부분이 프롬프트 처리에 쓰이고, 실제 답변 생성은 작은 비중만 차지하기 때문이다. Nemotron Super 120B는 약 10만 토큰 수준의 긴 문맥에서도 체감 품질과 속도가 좋았고, 이를 확인하려고 llama-bench로 비교했다. 기준 속도는 프롬프트 처리 100 TPS였고, 이보다 낮아지면 실사용이 어렵다고 보고 측정을 멈췄다. 문맥 한도도 차이가 있었다. GPT-OSS는 약 12만 8천 토큰, Qwen 3.5/6은 약 25만 6천 토큰, Nemotron은 최대 40만 토큰 문맥까지 다룰 수 있었다.
Google Antigravity에서 Sonnet으로 작업 계획을 만든 뒤 Gemini로 바꿔 실제 변경을 실행하는 방식은 대체로 잘 작동했다. 하지만 Gemini로 전환한 뒤에도 Sonnet 사용량이 계속 줄어드는 것처럼 보이는 문제가 있었다. 실시간 사용량 표시가 더 자세해지면서 이런 차감 흐름을 확인하기 쉬워졌다. 일반적인 설명으로는 하위 에이전트가 따로 돌고 있거나 여러 세션이 열려 있을 수 있다는 가능성이 제시됐지만, 이 사례에서는 IDE 안에서 스킬만 사용했고 하위 에이전트는 쓰지 않았다. 표준 작업 흐름으로 작업을 시작하고 구현 계획을 만든 뒤 모델을 바꿨는데도, Sonnet 사용량이 계속 차감되는 것처럼 보여 사용량 계산 방식이 불명확해졌다.
Tricentis는 Agentic Quality Engineering Platform과 AI Workspace에 새 기능을 추가했다. 핵심은 단순히 AI가 테스트 케이스를 만들어 주는 수준을 넘는 것이다. 여러 AI 에이전트가 테스트 작성, 실행, 성능 테스트, 품질 분석을 나누어 맡고 서로 이어서 처리하는 방식이다. 실제 운영 환경에서 이런 에이전트 기반 테스트 도구가 유지보수 부담을 줄였는지, 어디에서 도움이 되고 어디에서 잡음을 늘렸는지가 중요한 질문으로 떠올랐다. AI가 테스트를 처음 만들어 내는 일은 비교적 쉽지만, 6개월 뒤에도 그 테스트가 계속 쓸모 있게 유지되도록 관리하는 것이 더 어렵다는 경험이 함께 제기됐다.
AI 에이전트가 어떤 도구를 쓰고 있는지, 지금 어떤 단계에 있는지 실시간으로 보여주는 시각화 도구에 대한 수요가 있다. 예전에는 Agent Flow라는 프로젝트가 도구 사용 상태를 글 흐름이나 간단한 화면 요소로 보여줬다. 비슷하지만 더 잘 관리되고 있는 프로젝트가 있는지가 핵심 관심사다. 더 발전된 형태로는 로컬 모델 내부의 어텐션 헤드 같은 작동 흐름까지 실시간으로 보여줄 수도 있지만, 일반 사용자가 쓰는 앱에는 과한 기능일 수 있다.
24시간 돌아가는 개인용 AI 에이전트가 로컬 거대 언어 모델과 클라우드 모델을 함께 쓰며 매일 작업 내용을 마크다운 기록으로 남긴다. 처음 아이디어는 각 프로젝트에 색상 같은 고유 식별값을 주고, 하루 작업을 섞인 색처럼 표현한 뒤 어떤 프로젝트들이 들어 있었는지 다시 읽어내는 방식이었다. 하지만 색상은 숫자 3개만 담기 때문에 약 50개 프로젝트의 참여 여부와 비율을 되돌려 알기에는 정보량이 너무 적다. 대신 요리사가 낯선 음식에서 재료와 비율을 맞히고 모르는 재료까지 알아차리는 방식에 가까운 구조를 썼다. 이 방식은 초차원 컴퓨팅과 벡터 기호 구조라는 오래된 수학 아이디어를 바탕으로 한다. 각 프로젝트 이름은 항상 같은 4,096차원 ±1 벡터를 만들고, 서로 무작위로 만든 큰 벡터들은 거의 겹치지 않는다. 그래서 하루 작업을 프로젝트별 가중합으로 섞어도, 나중에 내적 계산으로 어떤 프로젝트가 얼마나 들어 있었는지 다시 분해할 수 있다. 일반적인 임베딩 검색이 비슷한 글을 찾는 데 강하다면, 이 메모리 층은 하루 기록 안에 섞인 모든 프로젝트 흔적을 구조적으로 되짚는 데 초점을 둔다.
CPU만 쓰는 C99 기반 언어 모델 실행 엔진에서 DeepSeek-V2-Lite-Chat Q4_K_S 모델을 돌렸을 때 속도가 크게 느렸다. 같은 i5-11300H 노트북, 같은 4개 스레드 조건에서 직접 만든 엔진은 초당 1.90토큰을 처리했고, llama.cpp는 초당 13.79토큰을 처리했다. 차이는 약 7.3배였다. 원인은 계산 능력보다 메모리에서 읽어야 하는 데이터 양에 가까웠다. 직접 만든 엔진은 압축된 Q4K 가중치를 실행 전에 F32로 풀어 1개 값마다 4바이트를 읽게 만들었고, MoE 전문가 가중치도 호출 때마다 풀어 썼다. llama.cpp는 Q4K 데이터를 그대로 읽어 1개 값당 약 0.5바이트만 쓰고, Q8로 압축한 활성값과 한 번에 곱셈 계산을 했다. 그래서 같은 메모리 대역폭에서도 읽는 데이터가 훨씬 적어 속도가 크게 빨랐다. AVX2, AVX512F, VNNI 같은 SIMD 방식을 바꿔도 2% 안팎밖에 차이가 나지 않았는데, 병목이 산술 계산이 아니라 메모리 읽기였기 때문이다.
실제 업무 흐름을 자동화하기 위한 AI 에이전트가 개발 중이다. 이 에이전트는 사람이 자연어로 적은 일을 이해하고, 여러 단계로 나누어 계획한 뒤, 여러 도구를 써서 실행하는 것을 목표로 한다. API와 외부 서비스에 연결하고, 웹에서 자료를 조사하며, 보고서와 요약을 만들 수 있다. 반복되는 사무 업무를 줄이는 데도 초점을 둔다. 현재 개선하려는 부분은 장기 메모리, 더 나은 계획과 추론, 환각 감소, 실행 속도 향상, 중요한 작업에서 사람의 승인 절차를 넣는 것이다. 실제 운영 환경에서 어떤 에이전트와 프레임워크가 쓰이는지, 안정적인 에이전트를 만들 때 가장 큰 어려움이 무엇인지가 핵심 질문이다.
개인 개발 환경에서 만든 음성 대화 챗봇이 거의 실시간에 가까운 응답까지 개선됐다. 사용자가 말하면 Whisper-small이 음성을 글로 바꾸고, Qwen3.5-397B가 답을 만들며, Orpheus가 다시 음성으로 읽어준다. 대화 중간에 사용자가 끼어들어도 직전에 말한 내용을 잃지 않도록 문맥을 유지한다. 모든 처리는 외부 서버가 아니라 로컬 컴퓨터에서 돌아간다. 24GB 그래픽카드에서 VRAM 사용량은 최대 21.3GB 정도로 유지되어, 실행에 필요한 여유가 조금 남는다. Qwen 모델의 일부 MoE 전문가는 시스템 메모리 약 150GB를 차지한다. KV 캐시는 bf16으로 쓰고 있으며, 문맥 길이는 131,072 토큰이라 몇 시간 분량의 대화를 담을 수 있다. 코드는 곧 GitHub에 공개될 예정이다.
Gemma 4 계열 모델을 오래된 Nvidia GTX-1070 그래픽카드 3장으로 돌려 본 실제 추론 속도 비교다. 컴퓨터 환경은 Kubuntu 26.04, AMD Ryzen 5 3600 6코어 CPU, 메모리 48GiB, 그래픽카드별 VRAM 8GiB씩 총 24GiB다. 세 그래픽카드의 전력 제한은 각각 120W, 121W, 122W로 낮췄고, 추론 속도는 약 5% 줄었지만 전원 공급 장치 부담은 낮아졌다. llama.cpp의 Vulkan 빌드와 GGUF 모델 파일을 사용했다. 31B 양자화 모델은 17.52GiB로 벤치마크에 3분 35초가 걸렸고, 생성 속도는 초당 7.12토큰이었다. 12B Q8 모델은 12.69GiB로 1분 59초가 걸렸고 초당 13.47토큰이었다. 26B.A4B Q4 모델은 15.83GiB로 1분 45초, 초당 41.28토큰이었고, 26B.A4B QAT 모델은 13.26GiB로 1분 30초, 초당 53.08토큰으로 가장 빠른 생성 속도를 냈다. 세 그래픽카드는 서로 다른 PCIe 속도에 꽂혀 있으며, 그중 하나는 1x 확장기에 연결되어 있다.
코딩 에이전트를 매달 수백 달러 쓰지 않고도 실무에 쓸 수 있는지 확인하려는 비교 테스트다. 목표는 ChatGPT Plus를 이미 쓰는 상황에서, Claude Code 안에서 OpenRouter의 더 저렴한 API 모델을 쓰면 비슷한 가치를 얻을 수 있는지 보는 것이다. 테스트 대상은 실제 업무용 WordPress 플러그인이다. 이 플러그인은 PHP, WordPress 관리자 화면, WP-CLI 명령, 데이터베이스 테이블, 기존 구조, Git 작업 흐름을 포함한다. 비교 대상에는 Claude Sonnet, GPT-5.3 Codex, Kimi K2.5, Qwen3 Coder Next, DeepSeek V4 Pro, MiniMax M3, Xiaomi Mimo 2.5 Pro, NVIDIA Nemotron 모델, OpenRouter 무료 모델이 들어간다. 측정 항목은 작업 하나를 끝내는 비용, 걸린 시간, 기존 프로젝트 구조를 얼마나 잘 지키는지, 요구사항을 얼마나 잘 따르는지, 사람이 얼마나 많이 확인하고 허락해야 하는지다. 일반 지식이나 LeetCode식 코딩 문제 점수는 측정하지 않는다.
코딩 에이전트(코드를 대신 작성해주는 AI 도구)를 매일 쓰면서도 엔터를 치고 코드가 나오기까지 내부에서 무슨 일이 일어나는지 모른다는 점을 답답하게 여긴 개발자가, 그 원리를 이해하기 위해 'Orin'이라는 코딩 에이전트를 직접 만들었다. 코드 대부분은 AI가 작성했지만, 스펙 작성 → 이슈 등록 → 구현 → PR 리뷰라는 정식 소프트웨어 개발 절차(SDLC)를 그대로 따랐고, 모든 diff를 무비판적으로 수락하는 방식(바이브 코딩)은 지양했다고 밝힌다. 완전히 새로운 아이디어는 아니며, pi.dev·nanocoder·opencode 같은 기존 오픈소스 코딩 에이전트의 코드를 직접 읽고 참고했고, Cline과 Kilo Code도 훑어보며 패턴을 파악했다.
코딩 에이전트 두 개를 함께 쓰는 작업 조율 도구에서, 한 에이전트는 계획을 내고 구현하며 다른 에이전트는 검토한다. 실험 중인 기능은 합의 감사다. 두 에이전트가 위험한 계획에 너무 쉽게 동의하면, 검토 에이전트가 한 번 더 돌아가며 아직 따져보지 않은 가정을 공격한다. 문제는 어떤 계획을 추가 검토할 만큼 위험하다고 볼지 정하는 일이다. 첫 방식은 각 결정문을 작은 규칙 목록과 키워드로 맞춰 보는 방식이다. 규칙에는 명시적 허락 없이 공개·푸시·병합·배포하지 않기, 결과가 사라지지 않게 보존하기, 멱등성을 깨지 않기, 진실의 원천에서 벗어나지 않기 같은 항목이 있다. 이 방식은 싸고 예측 가능하지만, 실제 실행에서는 빠뜨림과 헛걸림이 모두 생겼다. 실제 위험 결정이 규칙과 같은 단어를 쓰지 않으면 빠지고, 반대로 merge_intervals 같은 일반 코드 작업은 'merge'라는 말 때문에 위험 신호처럼 잡힐 수 있다.
AI 모델이 스스로 더 똑똑해지는 단계까지는 아직 아니지만, AI가 시스템을 고치는 흐름은 이미 현실적으로 가능하다. 핵심은 AI가 만들고, 살피고, 평가하고, 다음 변경을 제안하고, 다시 반복하게 하되 사람이 제품의 방향을 계속 정하는 것이다. 코드가 망가지지 않게 하려면 자동 테스트와 회귀 방지 체계가 꼭 필요하다. 혼자 AI와 일하더라도 설계, 검토, 구현, 확인, 통합, 피드백 수집을 반복하는 작업 방식이 안정적이다. 즉흥적으로 운영 중인 제품을 바로 고치는 방식은 큰 조직에서도 혼란을 부르기 쉬워 피한다. 코드를 Linear 같은 프로젝트 관리 도구와 지식 저장소에 연결하면 AI가 해야 할 일을 더 좁고 분명하게 잡을 수 있다. 제품이 처음 정한 요구사항대로 움직이는지 살피는 모니터링과 피드백 흐름도 필요하다. 장기 메모리 저장소와 텔레메트리는 다음 개선 결정을 내리는 바탕이 된다.
Ascend GX10 또는 DGX Spark 4대를 묶은 장비에서 GLM5.2를 돌리면, 128k 문맥 기준으로 입력 처리 속도는 초당 400~500 토큰, 답변 생성 속도는 초당 약 15 토큰 정도라는 테스트 사례가 있다. 아주 빠른 수준은 아니지만, 양자화를 쓰면 개인이나 소규모 팀이 감당할 만한 속도로 볼 수 있다. 핵심 고민은 앞으로 더 좋은 오픈소스 모델이 나오면, 클라우드 비용을 계속 내기보다 미리 로컬 하드웨어를 갖춰 두는 편이 나은지다. 전력 사용량은 약 1000와트까지 예상되지만, 비용보다 직접 운영 가능성과 준비 상태를 더 중요하게 보는 관점이다.
RX 7900 XTX 그래픽카드로 Qwen3.6 27B 모델을 로컬에서 돌린 실제 테스트에서 기대보다 낮은 속도가 나왔다. Ubuntu 24.04.4, 리눅스 커널 6.8, llama.cpp, ROCm 7.2.4, AMD 드라이버 6.16.13, Vulkan 환경이 쓰였다. 원시 성능 측정에서는 ROCm이 프롬프트 처리 초당 235.73 토큰, 생성 초당 31.14 토큰을 냈고, Vulkan은 프롬프트 처리 초당 634.80 토큰으로 더 빨랐지만 생성은 초당 13.32 토큰으로 더 느렸다. 실제 API 테스트에서는 32,201개 프롬프트 토큰과 128개 생성 토큰을 넣었을 때 일반 27B 모델이 프롬프트 처리 초당 평균 238.42 토큰, 생성 초당 평균 26.84 토큰, 전체 평균 139.8초를 기록했다. MTP n=3 설정은 프롬프트 처리 초당 평균 226.09 토큰, 생성 초당 평균 17.14 토큰, 전체 평균 149.9초로 더 느렸고, 초안 수락률은 78.76%였다. vLLM도 같은 하드웨어에서는 실용적인 해법이 되지 못했다. 설정에는 65,565 컨텍스트 크기, 그래픽카드 레이어 99개, 플래시 어텐션, 연속 배치 처리, MTP 초안 추론이 포함됐다.
Claude를 몇 달 동안 코딩, 디버깅, 개념 설명, 알고리즘과 수학 문제 풀이에 써 왔지만 무료 사용 한도에 막힌 상황이다. 유료 구독은 지금 감당하기 어렵기 때문에, 비슷하게 쓸 수 있는 무료 인공지능 도구가 필요하다. 필요한 용도는 C, C++, 파이썬, 자바, MATLAB 코드 작성과 디버깅이다. 자료구조, 알고리즘, 네트워크, 운영체제, 전자공학, 임베디드 시스템 개념을 이해하는 데도 도움을 원한다. 수학에서는 이산수학, 미적분, 선형대수 개념을 단계별로 설명하고, 답만 내는 것이 아니라 왜 풀이가 맞는지도 알려주는 방식이 중요하다. 긴 대화를 이어 가며 추가 질문을 많이 하기 때문에 추론 능력, 정확도, 긴 대화 처리도 중요한 조건이다.
mlx-optiq는 MLX에서 쓰는 대형 언어 모델을 더 작게 줄이면서도 정확도 손실을 줄이는 양자화 도구다. 보통은 모든 층을 똑같이 4비트로 줄이지만, mlx-optiq는 층마다 얼마나 민감한지 재고 중요한 층에는 8비트를 더 배정한다. 덜 민감한 층은 4비트로 유지해 전체 평균 크기는 비슷하게 맞춘다. 이렇게 만든 모델은 기본 `mlx_lm.load(...)`로 바로 불러올 수 있어 별도 실행 환경이 필요 없다. 같은 저장 크기에서 균일한 4비트 모델보다 정확도를 더 잘 지키며, 특히 작은 모델에서 차이가 크다. Google의 QAT 미적용 Gemma-4 가중치에서는 손실이 거의 없었고, QAT와 함께 써도 같은 비트 조건에서 성능이 더 나왔다. 예시로 E2B는 54.2점으로 균일 4비트의 52.1점보다 높았고 GSM8K는 58.6%였다. E4B는 65.8점으로 균일 4비트의 64.6점보다 높았고 GSM8K는 80.0%였다.
새 인공지능 모델이 너무 자주 나오면서, 여러 경량화 버전의 품질을 차분히 비교하기가 어려워졌다. 예전에는 다양한 양자화 모델을 비교한 벤치마크가 많이 나왔지만, 지금은 새 모델이 빠르게 쏟아져 따라가기 힘들다. 그래도 실제 사용자는 특정 모델의 q3 버전이 다른 모델의 q6 버전보다 나은지처럼, 직접 돌릴 수 있는 수준의 비교가 필요하다. 문제는 기존 벤치마크가 넓고 무거워서 수백만 개의 토큰을 만들 수 있고, 집에서 초당 10~20개 토큰 정도로 3000억 개 이상 매개변수의 모델을 돌리는 환경에서는 현실적이지 않다. 더 작은 벤치마크가 필요하며, 특히 q6에서는 통과하지만 q5에서는 실패할 수 있는 문제처럼 품질 차이를 잘 드러내는 과제만 골라 쓰는 방식이 제안된다. 이상적으로는 q5가 q8 품질의 약 몇 퍼센트인지처럼, 낮은 비용으로 대략적인 품질 비율을 자동으로 알려주는 방법이 필요하다.
Sentinel은 AI 에이전트가 실제로 도구를 실행하기 전에 허용된 행동인지 확인하는 오픈소스 SDK다. 문제가 생긴 뒤에 보고하는 방식이 아니라, 도구 실행 직전에 정해 둔 규칙으로 막을 수 있다. 규칙은 역할 범위, 실행 의도, 반드시 차단해야 하는 조건을 기준으로 둘 수 있다. 감시 과정에 별도 모델 호출이 들어가지 않기 때문에 결과가 더 예측 가능하고 토큰 비용도 추가되지 않는다. Claude Code용 연결 기능이 이미 제공되며, 설치는 npm 패키지로 할 수 있다. 개발자는 어떤 검사 지점을 더 열어두면 좋을지 피드백을 받고 있다.
gpt-4.1-mini를 gpt-4o-mini 대신 바로 바꿔 써도 되는지 76개 검사로 비교했다. 코드 생성은 10개 검사 모두 통과해, 코드 작업만 맡기는 경우에는 교체 위험이 낮아 보였다. 반대로 추론 과정 검사 10개 중 3개에서 중요한 퇴행이 나왔고, 인공지능 평가 작업 18개 중 3개에서도 중요한 문제가 나왔다. 일반 검사 18개 중 3개, 비위 맞추기 검사 10개 중 1개, 제이슨 스키마 검사 10개 중 2개는 추가 확인이 필요한 수준이었다. llama3.1:8b에서 llama3.2:3b로 낮춘 로컬 모델 비교도 함께 했고, 일반 검사에서 중요한 퇴행 1개가 잡혔다. 검사 도구는 다른 인공지능에게 채점을 맡기지 않고 정해진 기준으로 반복 실행되도록 만들어, 같은 조건에서 다시 확인할 수 있게 했다.
로컬 인공지능을 처음 시작하는 사람을 위한 2026년형 입문 가이드가 공개됐다. 로컬 인공지능은 온라인 인공지능 서비스에 매번 요청을 보내는 대신, 자기 컴퓨터나 개인 장비에서 인공지능 모델을 직접 돌리는 방식이다. 관심이 커지면서 같은 질문이 반복되어, 초보자가 기본 개념과 시작 방법을 한곳에서 볼 수 있게 정리한 자료다.
Harbor 0.5.0은 로컬 컴퓨터에서 쓰는 AI 실행 도구들을 한 번에 내려받고, 설정하고, 서로 연결해 실행할 수 있게 한다. 예를 들어 `harbor up webui llamacpp`, `harbor up opencode mlx`, `harbor up hermes omlx` 같은 명령으로 Open WebUI, OpenCode, Hermes를 MLX, OMLX, Docker Model Runner 같은 실행 환경과 붙일 수 있다. 수동 설정을 줄이는 것이 핵심 변화다. 명령줄 도구도 코딩 에이전트와 함께 쓰기 좋게 바뀌었고, Harbor가 제공하는 기본 스킬을 명령줄에서 바로 확인할 수 있다. OpenCode 같은 서비스에는 이 스킬이 미리 들어 있어, 자연어로 Harbor 실행과 설정을 요청할 수 있다. 새 `harbor pull` 명령은 모델 이름이나 출처에 따라 내려받는 경로를 자동으로 나눈다. 일반 Hugging Face 저장소와 llama.cpp용 양자화 모델은 `huggingface-cli`로, 단순 모델 이름은 Ollama로 보낸다.
neuron-db는 1홉, 2홉, 3홉 질의에서 모두 100% 정확도를 냈다는 자체 벤치마크 결과가 제시됐다. 홉은 답을 찾기 위해 여러 단계로 이어진 정보를 따라가는 깊이를 뜻한다. 어떤 홉 깊이든, 메모리 크기가 커지든 LLM 호출은 항상 2번으로 유지됐다고 한다. 마크다운 전체 덤프 방식과 비교하면 정확도는 같거나 더 높고, 토큰 비용은 약 60분의 1 수준이라고 주장한다. 반대로 6만 7천 토큰짜리 마크다운 덤프를 한꺼번에 모델에 넣는 방식은 규모가 커질수록 모델이 추론을 헷갈려 정확도가 83%까지 떨어졌다고 한다.
클라우드 GPU를 정기적으로 빌려 쓰는 사람들이 실제로 한 달에 얼마를 쓰는지가 핵심이다. 비교하려는 내용은 어떤 작업을 돌리는지, 얼마나 자주 GPU를 켜는지, 월 비용이 어느 정도인지다. 사용 방식이 사람마다 크게 달라 보여서, 일반적인 지출 범위를 알고 싶다는 문제의식이 담겨 있다. 구체적인 비용 수치나 절감 방법은 제시되지 않았다.