AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Ollama와 Qwen2.5를 쓰는 RAG 구성이 위험 등록부 SQL 데이터베이스에서 위험, 사고, 완화책 같은 정보를 찾아 답하도록 만들어지고 있다. 문제는 데이터베이스가 매우 비어 있어 빈 테이블과 빈 열이 많고, 결과에 쓸 만한 문맥이 부족하다는 점이다. 그래서 에이전트가 빈값이나 의미 없는 결과를 받아 답변 품질이 낮아지고 있다. 이를 보완하려고 모든 테이블을 행 단위로 나누고 임베딩해서 의미 기반 검색을 붙였지만, 아직 하이브리드 검색이나 RRF 같은 고급 검색 방식은 넣지 않았다. 핵심 목표는 빠진 값과 null 값을 무시하고, 실제 정보가 있는 데이터만 잘 찾아 데이터베이스와 더 효율적으로 대화하게 만드는 것이다.
Ollama에서 Qwen2.5 모델을 써서 RAG 흐름을 만들고 있다. 목표는 모델이 위험 등록부 SQL 데이터베이스를 읽고, 위험, 사고, 완화책 같은 내용을 단순하거나 복잡한 SQL 질의로 찾아 답하는 것이다. 문제는 데이터베이스가 매우 비어 있다는 점이다. 여러 테이블이 비어 있고, 일부 열도 빈값이 많아서 검색 결과에 문맥이 거의 없다. 이 때문에 에이전트가 결과를 받아도 제대로 된 배경 정보를 얻지 못해 답변이 부실해진다. 행 단위로 모든 테이블을 잘라 임베딩하고 의미 검색도 붙였지만, 아직 하이브리드 검색이나 RRF 같은 고급 검색 방식은 쓰지 않았다. 원하는 방향은 비어 있거나 null인 값을 무시하면서 데이터베이스와 더 효율적으로 상호작용하는 것이다.
스마트폰에서도 완전히 로컬로 실행할 수 있는 작은 AI 모델 2개를 관리하는 인터페이스가 공개됐다. 40억 개 규모 모델은 성능이 꽤 안정적이지만, 고급 스마트폰이 필요하다. 17억 개 규모 모델은 추론 기능을 켜면 아직 안정적으로 유지되지 않는다. 개선 방법은 약 13만 개의 예시로 깊게 미세 조정을 하는 것이다. 핵심 어려움은 학습 수치 자체보다 예시의 품질과 다양성을 확보하는 데 있다. 더 큰 320억 개 규모 모델을 교사처럼 써서 작은 모델에 지식을 옮기는 증류 방식도 쓰고 있다. 데이터셋이 약 10일 뒤 준비되면 17억 개 규모 모델도 더 나아질 것으로 기대된다.
Conduit은 여러 MCP 서버를 한곳에서 관리하는 로컬 게이트웨이다. Claude, Cursor, VS Code, Codex 같은 여러 인공지능 클라이언트가 같은 설정을 함께 쓸 수 있어, 도구 연결을 클라이언트마다 반복해서 맞출 필요가 줄어든다. 핵심 기능은 필요한 도구를 처음부터 모두 보여주지 않고, 에이전트가 필요할 때 찾아 쓰게 하는 지연 발견 방식이다. 이 방식은 많은 도구 목록을 3개의 메타 도구로 줄여 에이전트에 전달되는 정보량을 크게 낮춘다. 소개 내용 기준으로 토큰 사용을 약 90% 줄일 수 있다고 한다. API 키 같은 비밀 정보는 클라우드가 아니라 운영체제 키체인에 저장된다.
Baidu가 Unlimited-OCR이라는 오픈소스 문서 읽기 모델을 공개했다. 목표는 긴 PDF나 여러 장의 문서를 페이지마다 잘라 처리하지 않고, 한 번에 읽고 텍스트로 바꾸는 것이다. 핵심은 AI가 원본 문서 이미지는 계속 참고하면서도, 자신이 이미 만들어낸 긴 텍스트는 작은 범위만 기억하게 만드는 방식이다. 이렇게 하면 긴 문서를 읽을 때 KV 캐시가 계속 커져 VRAM을 가득 채우는 문제를 줄일 수 있다. 저장 공간을 덜 쓰면 같은 장비에서 더 큰 모델을 돌리거나, 긴 문서 처리를 더 안정적으로 할 가능성이 생긴다. 현재 공개 자료는 주로 OCR과 문서 파싱에 초점이 있고, 긴 문서의 분석이나 요약 전체를 해결한다고 보기는 어렵다. GitHub 저장소에는 Hugging Face 방식 실행, SGLang 서버 실행, PDF를 이미지로 바꿔 처리하는 예시, 일괄 처리용 infer.py가 포함되어 있다. 테스트 환경은 엔비디아 GPU와 쿠다 기반 파이썬 환경으로 제시되어 있다.
FlowScript는 에이전트용 작업 지침을 마크다운으로 쓰되, 실행 순서는 별도 실행 장치가 강제하도록 만든 작은 시제품이다. 마크다운 기반 기술 묶음은 사람이 읽고 고치기 쉽지만, 모델이 단계를 건너뛰거나 보조 스크립트를 잘못된 순서로 실행하거나 필요한 결과물이 생기기 전에 요약해 버릴 수 있다. 기존 작업 흐름 엔진은 실행 통제를 해 주지만, 작성 방식이 마크다운 기술 묶음에서 멀어지는 문제가 있다. FlowScript는 기존 SKILL.md를 유지하면서 FLOWSCRIPT.md 파일을 추가하고, 그 안의 flow 블록을 실행 장치가 읽도록 한다. 실행 장치는 선언된 흐름을 불러와 확인하고, 언어 모델, 검증기, 파이썬 스크립트 단계를 정해진 순서대로 실행한다. 또한 허용된 분기만 타게 하고, 결과물을 대화 기록에만 숨겨 두지 않고 저장하며, skill_agent_context.json을 남겨 나중에 다시 실행하거나 점검할 수 있게 한다. 지원하지 않는 종료 지점이나 대체 경로를 만나면 로그와 중간 결과물을 남기고 멈춘다.
mcp-audit는 MCP 서버를 샌드박스 안에서 실행해, 실행 중 어떤 파일을 열고 어디로 인터넷 연결을 보내는지 기록한다. 공식 MCP 등록소는 서버를 누가 올렸는지는 확인하지만, 실행했을 때 실제로 무엇을 하는지는 확인하지 않는다. 기존의 정적 분석은 코드와 설명을 훑는 방식이라, 나중에 버전이 바뀌어 다른 행동을 하거나 목적과 맞지 않는 곳에 접속하는 문제를 놓칠 수 있다. 이 도구는 Docker 안의 버릴 수 있는 리눅스 환경에서 서버를 실행하고, strace로 파일 접근과 네트워크 연결을 잡아낸다. 가짜 비밀값인 카나리도 넣어 두어, 서버가 그 값을 읽거나 밖으로 보내려는지 확인한다. 70개 MCP 서버를 살펴본 결과, 시작 단계에서는 67개가 민감한 파일을 읽거나 예상 밖의 인터넷 연결을 하지 않았다. 3개 서버는 시작할 때 외부 HTTPS 연결을 만들었지만, 각각 거래소 연동, GitHub 가져오기, 클라우드·콘텐츠 전송망 접속처럼 기능과 맞는 연결이었고 민감한 파일이나 카나리를 건드리지 않았다. bullmq-mcp는 시작할 때 /etc/passwd를 읽었지만, 표준 glibc 사용자 조회 과정으로 확인됐고 내용이 밖으로 전송되지는 않았다. 이번 점검은 서버가 켜져 대기하는 상태만 본 것이며, 실제 도구 호출 중 생기는 행동은 아직 살피지 않았다.
RAG 시스템으로 연차보고서, 뉴스, 과학 논문 같은 비정형 데이터를 다루려면 문서를 단순히 작은 글 조각으로 나누는 방식만으로는 부족할 수 있다. 특히 과학 논문에는 그림, 도표, 본문, 숫자가 함께 들어 있어 정보의 위치와 관계를 함께 보존해야 한다. 목표는 문서 안의 세부 내용을 최대한 빠뜨리지 않고 뽑아내는 것이다. 예를 들어 도표의 의미를 물었을 때, 시스템은 도표 자체와 주변 설명을 함께 이해해 믿을 만한 답을 해야 한다. 핵심 고민은 이런 복합 문서를 조각내기 단계에서 어떻게 처리하는 것이 좋은지다.
같은 작업 흐름을 LangGraph, CrewAI, Google의 A2A 방식으로 각각 만들어 비교했다. 작업 흐름은 정보를 찾고, 요약하고, 알림을 보내는 순서였다. LangGraph는 상태 관리와 재시도 처리에서 가장 세밀한 제어가 가능했지만, 처음 쓰는 팀원이 배우기에는 가장 어려웠다. CrewAI는 작동하는 시제품을 가장 빨리 만들 수 있었지만, 정해진 틀에서 벗어난 흐름이 필요해지면 다루기 불편했다. A2A를 직접 쓰는 방식은 처음 만들 때 일이 가장 많았지만, 문제가 생겼을 때 실제로 어떤 정보가 오갔는지 가장 분명하게 볼 수 있었다. 여러 AI 에이전트가 일을 넘겨줄 때는 에러가 크게 터지기보다, 한쪽이 다른 쪽의 의도를 제대로 받지 못한 채 조용히 잘못되는 경우가 중요했다. 세 방식 모두 에이전트 사이를 하나로 이어 보는 관측성은 자동으로 해결하지 못했다. 각 도구는 내부 기록은 남기지만, 사용자의 요청부터 각 에이전트의 처리, 최종 답변까지 이어지는 하나의 추적 화면은 제공하지 못했다.
AI 에이전트가 실패하는 이유 중 상당수는 모델이 잘못 추론해서가 아니라, 정보가 불완전한 상태에서 그냥 실행해버리기 때문이라는 주장이다. 이를 해결하기 위해 새로운 모델이나 프레임워크가 아니라 가벼운 실행 패턴을 제안한다. 핵심은 네 단계다: 상태(데이터)와 실행 로직을 분리하고, 빠진 정보는 AI가 임의로 추측하지 않고 명시적으로 'Unknown(모름)'으로 표시하며, Unknown이 하나라도 남아있으면 실행을 막고, 마지막 상태 자체가 실행 기록(감사 로그)이 되게 한다. 이렇게 하면 AI의 역할이 '빈틈을 추론해서 채우기'에서 '이미 확인된 정보를 매칭하기'로 바뀐다. 모르는 것이 있으면 AI가 아니라 사용자가 직접 채워 넣는다. 별도 인프라나 새 언어 없이 단순한 JSON 구조만으로 구현 가능하며, 예시로 로그인 오류 수정 작업을 JSON 형태(수정 범위 확인 여부, 테스트 기준 존재 여부, UI 변경 금지 등 사용자 제약)로 표현해 보여준다.
AI 에이전트가 Terraform, kubectl 같은 클라우드 인프라 명령을 직접 실행할 수 있으면, 실행 전에 그 작업이 얼마를 쓰게 할지 모르는 빈틈이 생긴다. Claude Pro/Max 같은 유료 요금제를 쓰더라도, 에이전트가 새 서버나 서비스 비용이 예산을 넘는지 스스로 판단하는 것은 별개의 문제다. 이를 막기 위한 MCP 도구는 에이전트가 행동하기 전에 예상 비용, 예산, 사용자가 정한 정책을 확인한다. 결과는 바로 실행 허용, 사람에게 확인 요청, 실행 차단 중 하나로 나온다. 이 도구는 인프라를 직접 바꾸지 않고, 수정안을 풀 리퀘스트로 제안하는 방식도 둔다. 무료로 시작할 수 있고 소스가 공개되어 있으며, 실제 인프라 접근 권한을 가진 에이전트의 비용 통제 방식이 아직 부족하다는 문제의식이 핵심이다.
2019년형 게이밍 노트북에서 Qwen3.6 35B-A3B 모델이 초당 약 28개 토큰 속도로 실행됐다. 장비는 i7-9750H, GTX 1660 Ti 6GB 그래픽카드, 32GB 메모리 구성이다. 이 모델은 전체 크기는 350억 파라미터지만, 토큰 하나를 처리할 때는 약 30억 파라미터만 실제로 쓰는 MoE 구조라 계산 부담이 훨씬 작다. `--n-cpu-moe 36` 설정으로 어텐션과 공유 텐서는 그래픽카드에 두고, 전문가 텐서는 시스템 메모리로 빼서 작은 그래픽카드에서도 돌아가게 했다. Turboquant 포크의 `turbo4`와 `turbo3` KV cache 양자화가 핵심 역할을 했다. 128K 컨텍스트에서는 KV cache가 메모리를 크게 차지하는데, 이 방식이 기본 `q8_0`보다 더 작게 만들어 6GB 그래픽카드에 맞췄다. 로컬의 `localhost:8080`에서 OpenAI 호환 엔드포인트로 열어 opencode에 연결했기 때문에 클라우드 API 비용 없이 쓸 수 있다. Turboquant 포크는 빠르게 바뀌므로 특정 커밋 `4595fff`에 고정하는 것이 권장된다.
Prometheus는 개인 컴퓨터에서 먼저 작동하는 개인용 AI 비서다. 작은 로컬 모델이 전체 대화를 맡아 여러 하위 에이전트에게 일을 나눈다. 브라우저와 셸, 인터넷 작업, 이메일과 달력, 일정 잡기, 프로젝트 추적을 각각 맡는 에이전트가 있고, 큰 결정을 여러 모델이 함께 검토하는 구조도 있다. 값싸고 빠른 일은 로컬 모델이 처리하고, 더 어려운 일에는 클라우드 모델을 불러와 한 대화 안에서 이어서 처리한다. 실제 Chrome을 Playwright/CDP로 조작해 기존 로그인 상태와 쿠키를 그대로 쓰고, xdotool로 데스크톱도 제어한다. 이메일 읽기와 보내기, CalDAV 달력 관리, 자기 소스 코드 수정과 재시작, Telegram·WhatsApp·Slack·웹 대시보드 실행, Whisper와 Kokoro TTS를 이용한 음성 모드도 포함된다. 다만 사용자 권한 그대로 실행되고 샌드박스가 없어, 잘못된 모델 출력이나 웹페이지의 프롬프트 인젝션 때문에 실제 파일과 계정에 문제가 생길 수 있다.
AI 에이전트를 단순한 백엔드 스크립트처럼 배포하면 규모가 커질수록 관리가 어려워진다. LangGraph, CrewAI, 파이썬으로 동작을 만들고 Docker에 담아 클라우드에 올리는 방식은 에이전트가 5~10개를 넘으면 복잡해진다. 여러 에이전트가 상태를 가진 채 높은 권한으로 따로 움직이는데, 비밀키 관리, 되돌리기, 평가를 표준 방식으로 처리하기 어렵다. 규정 준수, 개인정보 가리기, 배포 절차를 LangChain 같은 특정 도구 안에 넣으면 나중에 바꾸기 힘든 빚이 된다. 핵심 에이전트 동작과 인프라 관리는 분리해야 한다. 일부 플랫폼은 단순 실행 도구가 아니라 독립적인 컨트롤 플레인처럼 에이전트 운영을 관리하려 한다.
AI 에이전트의 성패는 첫 질문을 처리하기 전부터 정해지는 경우가 많다. 실제 서비스에서는 모델이 얼마나 똑똑한지보다, 회사의 실제 업무 상황과 데이터에 얼마나 정확하게 닿아 있는지가 더 중요하다. 안정적인 API 연결, 실시간 데이터베이스 접근, 정확한 상태 관리, 실패했을 때의 대체 처리, 실제 업무 흐름에 대한 이해가 필요하다. 최신 추론 모델을 써도 데이터 접근이 약하거나 도구가 자주 깨지면 비용만 커지고 사용자는 답답함을 느낀다. 모델을 더 바꾸는 일보다 도구 호출, 데이터 파이프라인, 평가 체계를 튼튼하게 만드는 일이 실제 에이전트 구축의 핵심이 될 수 있다.
직접 테스트한 경험에 따르면 OmniDimension은 AI 전화 통화에서 100개 이상의 언어를 지원하고, 대화 지연이 낮으며, 코드 없이 설정할 수 있다. 목소리는 꽤 자연스럽게 들리고 응답도 빠르다. 핵심 궁금증은 이런 통화 품질이 음성 인식, 대규모 언어 모델, 음성 합성을 단순히 이어 붙인 결과인지, 아니면 뒤에서 더 많은 최적화가 필요한지다. 비슷한 서비스를 만들려면 어떤 기술 구성이 필요한지, 낮은 지연을 어떻게 유지하는지, 가장 큰 개발 난관이 무엇인지가 쟁점이다. 또 혼자서 최소 기능 제품을 만들 수 있는지, 아니면 전담 개발팀이 필요한 수준인지도 중요한 질문이다.
한 개발자가 한 달에 걸쳐 아이디어부터 완성된 틱톡 영상까지 사람 손을 거의 안 대고 만드는 시스템을 구축했다. n8n(재퍼로도 가능)으로 전체 흐름을 연결했다. 첫 단계는 수집: 트위터, 레딧, 해커뉴스, AI 블로그 등 약 12개 소스의 RSS 피드를 몇 시간마다 스크레이핑해 마크다운으로 S3에 저장하며, 하루가 끝나면 약 100개의 원본 소재가 쌓인다. 두 번째는 선별: 하루에 한 번 프롬프트가 그날 쌓인 소재를 읽고 화제성(파급력, 실용성, 화제성, 놀라움 요소)을 기준으로 상위 3~5개를 골라 같은 사건을 다루는 중복을 제거하고 구조화된 JSON으로 출력한다. 이 과정에서 배운 점은 소스 URL을 그대로 정확히 복사하도록 강제해야 한다는 것이다. 안 그러면 링크가 깨진다. 세 번째는 대본과 후킹 문구 작성: 각 소재를 한 번에 하나씩 순차적으로 처리하며, 각각에 대해 훅 문구 5개를 만들고 그중 최고 2개를 남긴 뒤 약 55초 분량의 talking-head(인물 정면 발화) 대본 2개를 작성한다.
MCPRelay는 내 컴퓨터에서 직접 실행하는 무료 오픈소스 도구다. MCP 클라이언트에 연결하면 일반 ChatGPT가 단순히 복사해서 붙여 넣을 명령을 알려주는 수준을 넘어, 사용자의 컴퓨터를 조작하는 화면처럼 쓰일 수 있다. 만든 이유는 Codex 사용량 제한에 자주 걸렸고, ChatGPT 웹이나 모바일 앱에서도 자기 컴퓨터를 다룰 수 있게 하고 싶었기 때문이다. 방식은 MCPRelay를 로컬에서 실행한 뒤 MCP 클라이언트에 노출하는 구조다. 아직 거칠고 위험을 감수해야 하는 실험적 방식에 가깝지만, 로컬 MCP 구성을 직접 만들어 쓰려는 사람에게는 참고할 만한 예시다.
Atelier는 거대언어모델을 쓸 때 드는 토큰과 비용을 줄이기 위해 만든 도구다. 핵심은 한 번의 호출이나 특정 명령 출력만 보는 것이 아니라, 실제 작업이 끝날 때까지 전체 비용이 얼마나 줄었는지 재는 데 있다. 일부 코드 색인 도구는 토큰을 많이 아낀다고 하지만, 정답에 도달하려면 여러 번 다시 호출해야 할 수 있다. 공개 시험에서는 필요한 정보를 놓치지 않고 찾는 능력이 기본 검색 도구인 grep과 크게 다르지 않을 수 있다. 또 어떤 도구는 명령 출력 같은 좁은 상황에서 70~80% 절감을 보여주지만, 그것만으로 전체 작업 비용이 줄었다고 보기는 어렵다. Atelier는 자체 시험으로 절감이 어디서 생기는지, 품질과 정확한 결과가 유지되는지, 어떤 대가가 있는지 확인하려 한다. 무료로 시험해볼 수 있는 깃허브 프로젝트로 공개되어 있다.
Laurel.dev는 AI 에이전트가 웹을 검색할 때 쓰는 오픈소스 도구다. 기존 AI 검색 서비스들은 보통 검색 1,000건당 5~25달러를 받는다고 비교한다. 이 도구는 자체 AI 제품에 쓰기 위해 만들었고, 웹 검색 10만 건 이상을 3달러 미만으로 처리할 수 있었다고 한다. 검색 결과 품질은 Exa, Tavily 같은 서비스와 비슷하다고 주장한다. 몇 달 동안 내부에서만 쓰다가 무료로 공개했으며, 크레딧 제한이나 건당 과금 없이 쓸 수 있다고 안내한다.
AI 에이전트 협업은 하나의 인공지능에 모든 일을 맡기는 방식이 아니라, 역할이 다른 여러 AI 에이전트가 함께 큰 업무를 처리하는 방식이다. 하나의 모델은 이메일 작성이나 보고서 요약 같은 단발성 작업은 잘할 수 있지만, 실제 회사 업무는 티켓 처리, 승인, 감시, 장애 대응, 구매, 예측, 잦은 인수인계처럼 여러 단계로 이어진다. AI 에이전트는 목표와 문맥을 받고, 필요한 단계를 계획하고, API나 데이터베이스, 브라우저, 코드 실행 같은 도구를 쓰며, 결과를 확인한 뒤 계획을 고칠 수 있는 시스템이다. 다중 에이전트 협업에서는 조율 담당, 조사 담당, 실행 담당, 검토 담당처럼 역할을 나눈 에이전트들이 서로 정보를 주고받아 더 큰 문제를 푼다. 핵심은 복잡하고 계속 바뀌는 환경에서 한 에이전트가 혼자 처리하기 어려운 일을 더 안정적으로 나누어 처리하는 데 있다.
OpenAI가 데스크톱 ChatGPT 앱 구조를 바꿨다. 기존에 쓰던 데스크톱 앱은 'ChatGPT Classic'으로 이름만 바뀐 것으로, 새 모델이 아니다. 새 데스크톱 앱은 그냥 'ChatGPT'라는 이름으로 나오며, 기존의 Chat·ChatGPT Work·Codex 세 가지를 하나로 합쳤다. Classic 앱도 계속 쓸 수 있고 모델 업데이트와 보안 패치는 이어지지만, 새로 나오는 에이전트 기능 일부는 새 앱에서만 쓸 수 있다. 새 구조는 역할이 나뉜다. Chat은 일반 대화·검색·질의응답, Work는 오래 걸리는 업무용 에이전트 작업(문서·리서치·앱·파일 처리), Codex는 저장소·파일·터미널·Git을 다루는 소프트웨어 개발용이다. ChatGPT Work는 GPT-5.6으로 구동되고, Codex도 GPT-5.6 기반으로 업그레이드된다. Work 기능은 Pro·Enterprise·Edu 사용자의 웹/모바일에 먼저 열리고, 이후 며칠 내 Plus·Business로 확대된다. 새 데스크톱 앱 자체는 무료 사용자를 포함해 맥·윈도우 전체에 Chat·Work·Codex 세 기능이 모두 열리지만, 요금제에 따라 세부 기능과 사용량 제한이 다르다. GPT-5.6은 단일 모델이 아니라 Sol·Terra 등 여러 모델로 이뤄진 패밀리다.
LiteLLM을 회사 전체에서 쓰려는 계획이 보안 검토에 걸려 있습니다. 보안팀의 핵심 걱정은 LiteLLM이 여러 인공지능 제공사의 비밀키를 한곳에 들고 있고, 모든 프롬프트 데이터가 지나가는 길목에 놓인다는 점입니다. 의료, 금융, 정부처럼 규제가 강한 환경에서는 이런 구조가 공격자에게 매력적인 목표가 될 수 있습니다. 또 현재 감사 로그가 내부 준수 기준에 맞는 위치나 방식이 아니라는 문제도 있습니다. 실제 도입에는 자체 서버 운영, 맞춤형 감사 로그, LiteLLM 위에 별도 감싸는 계층을 두는 방식이 필요할 수 있습니다. 핵심 판단은 설정을 더 엄격히 하면 되는 문제인지, 아니면 규제 환경에는 도구 자체가 맞지 않는지입니다.
SAAG는 실제 업무에서 AI를 어디에 써야 할지 고르는 간단한 기준이다. 순서는 단순화, 자동화, 에이전트화, 보호다. 먼저 일을 더 단순하게 만들고, 정해진 규칙으로 처리할 수 있으면 일반 자동화로 해결한다. AI 에이전트는 정말 필요하다고 판단되는 부분에만 붙인다. 문제가 생기면 피해를 만들 수 있는 일에는 보호 장치를 둔다. 고객과 함께한 해커톤에서 이 방식이 실제 과제 선정에 쓰였다. 핵심은 “AI 우선” 구호보다, 실제로 만들고 운영할 수 있는 범위로 일을 좁히는 것이다.
@vmcreate/ai-watcher는 개발 중인 폴더를 지켜보다가 파일이 저장되면 바뀐 코드만 AI 모델에 보내는 npm 패키지다. AI는 그 변경분을 보고 바로 코드 검토, 개선 제안, 버그 의심 지점을 알려줄 수 있다. 전체 파일이나 프로젝트를 보내지 않고 실제로 달라진 부분만 보내므로 컨텍스트 토큰 사용을 줄이는 구조다. 사용자는 자신의 API 키와 프롬프트를 넣어 어떤 방식으로 검토할지 설정할 수 있다. 목적은 정식 코드 검토를 기다리기 전에 코딩하는 중간중간 빠른 피드백을 받는 것이다.
OmniOKF는 복잡한 PDF, Word, Excel, PowerPoint, HTML, Markdown 문서를 AI 에이전트가 읽기 쉬운 작은 Markdown 파일 묶음으로 바꾸는 명령줄 도구다. 큰 문서를 그대로 문맥 창에 넣으면 느리고 비용이 많이 들기 때문에, 문서를 제목 단위로 나눈 뒤 Gemini Flash로 다시 정리해 약 200~500토큰짜리 작은 개념 파일로 만든다. 이렇게 하면 에이전트가 질문에 필요한 부분만 불러올 수 있어, 쿼리마다 쓰는 토큰 비용을 75~95%까지 줄일 수 있다는 주장이다. 일반적인 문서 쪼개기는 관련 내용의 흐름을 끊기 쉬운데, OmniOKF는 생성된 파일들 사이에 관련 주제 링크를 자동으로 만든다. Microsoft의 markitdown을 내부에서 사용해 여러 파일 형식을 메모리 안에서 읽으며, Pandoc 같은 무거운 변환 도구나 별도 그래프 데이터베이스 없이 작동하는 것을 목표로 한다. Mermaid 시각화도 만들어 문서 사이의 연결 구조를 볼 수 있게 한다.
LLMSim은 실제 대규모 언어 모델을 부르지 않고도 AI 에이전트, AI 비서, 질의응답 패널, 고객지원 채팅 같은 서비스의 부하 테스트를 해볼 수 있게 해주는 도구다. 실제 모델 호출 대신 가짜 응답을 보내므로 테스트 중 발생하는 추론 비용을 줄이는 데 초점이 있다. OpenAI Completions, OpenResponses, Anthropic 호환 API 형태를 지원해 기존 대규모 언어 모델 클라이언트를 크게 바꾸지 않고 연결할 수 있다. 응답 스트리밍, 지연 시간, 첫 토큰까지 걸리는 시간, 컨텍스트 창 제한, 초당 요청 수 제한 같은 실제 API의 동작 특성을 흉내 내려 한다. Rust 라이브러리로도 쓸 수 있고, 하나의 실행 파일 서버로도 띄울 수 있다. 서버 실행 예시는 `cargo install llmsim --features tui`로 설치한 뒤 `llmsim serve` 명령으로 포트와 응답 토큰 수 등을 지정하고, 클라이언트가 `http://localhost:8080/openai/v1`로 보내는 방식이다.
개발자가 Claude, Cursor, Codex, Antigravity 등 여러 AI 도구를 오가며 작업하다가 겪은 불편에서 시작된 프로젝트다. 사용량 한도에 걸리거나 비용을 아끼려고 도구를 바꿀 때마다, 그리고 각 도구가 잘하는 일이 달라 이것저것 써야 할 때마다 이전 대화에서 쌓인 맥락(정보와 결정 내용)을 새 도구에 다시 넣어줘야 했다. 마크다운 파일을 복사해서 옮기거나, 이미 설명했던 결정을 처음부터 다시 설명하거나, 한 번 학습시킨 내용을 토큰을 써가며 또 학습시키는 일이 반복됐다. 이런 문제를 해결하려고 만든 것이 'Memlin'으로, 특정 도구에 종속되지 않고 여러 에이전트가 공통으로 쓸 수 있는 메모리 저장소를 목표로 한다. 되돌리기(revertable)와 버전 관리, 충돌 감지(collision-aware) 기능을 갖췄다. 아직 완성 단계는 아니지만 이미 매주 상당한 시간과 수백 달러의 비용을 절약해주고 있다고 한다.
RAG 개발에서는 하나의 큰 프롬프트에 검색과 답변을 모두 맡기기보다 역할을 나누는 편이 좋다. 먼저 사용자의 질문을 검색에 맞게 다시 쓰고, 사람 이름, 제품명, 날짜, 약어, 오류 코드 같은 단서를 넓힌 뒤 자료를 찾는다. 그다음 답변 단계에서는 찾은 자료 안에서만 말하게 하고, 각 문장에 어떤 문서와 구역이 근거인지 붙인다. 중요한 답변은 최종 답변 전에 주장, 근거 문서, 확신 정도, 서로 맞지 않는 내용이 있는지를 표로 정리하게 하면 환각을 줄일 수 있다. 자료가 부족할 때는 억지로 답하지 말고, 충분한 근거, 일부 근거, 충돌하는 근거, 관련 근거 없음처럼 상태를 나눠 말하게 해야 한다. 여러 번 검색이 필요한 경우에는 의도 분류, 개요 문서 검색, 필요한 대상 추출, 세부 문서 검색, 답변처럼 단계를 제한하고 어느 단계에서 실패했는지 남기는 것이 좋다. 말투 지시는 유연하게 두되, 근거 규칙은 단단하게 둬야 한다. 숫자, 정책, 가격, 권한, 버전, 지역, 요금제처럼 빠지기 쉬운 정보는 자료에 없으면 없다고 말하게 해야 한다.
peek-cli는 코딩 에이전트가 사용자가 지금 열어 둔 브라우저 화면을 확인할 수 있게 해 주는 도구다. 프런트엔드 개발에서는 화면을 보지 못한 채 코드를 고치는 일이 큰 약점이 될 수 있는데, 이 도구는 그 문제를 줄이는 데 초점을 둔다. 에이전트가 할 수 있는 일은 스크린샷을 찍는 것으로 제한된다. 그래서 브라우저를 직접 조작하거나 민감한 동작을 실행하는 방식보다 위험을 낮추는 구성을 내세운다. 실제 화면을 보며 디자인을 반복 수정할 수 있어, 불필요한 설명과 시행착오를 줄이는 데 도움이 될 수 있다. 비용과 효율이 좋다는 주장도 있지만, 구체적인 수치나 비교 자료는 제시되지 않았다.