AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
AI 에이전트가 최종 답을 틀리게 내면 평가 실패로 보기 쉽다. 하지만 잘못된 도구를 부르거나, 엉뚱한 저장소를 쓰거나, 관련 없는 파일을 읽거나, 승인 전에 쓰기 작업을 하면 성격이 다르다. 최종 답이 겉으로는 괜찮아 보여도, 이런 행동은 보안 사고에 더 가깝게 다뤄질 수 있다. 도구를 쓰는 대규모 언어 모델 앱을 만들 때 이런 실패를 어디에 기록해야 하는지가 핵심 쟁점이다. 후보는 평가 기록, 앱 사용 기록, 보안 기록, 또는 세 곳 모두다.
700쪽짜리 문서를 한 번에 큰 문맥 창에 넣는 대신, 문서의 각 부분을 따로 처리하는 ‘스킬 전문가’로 나누는 방식이다. 사용자가 PDF를 올리면 문서 구역별로 별도 전문가가 만들어지고, 각 전문가는 자기 문맥과 판단 과정을 가진다. 여러 전문가를 하나의 오케스트레이터 스킬로 묶으면, 질문이 들어왔을 때 알맞은 전문가에게 자동으로 보내진다. 여러 구역을 함께 봐야 하는 질문은 여러 전문가가 답을 만들고, 그 결과를 합쳐 하나의 답으로 정리한다. 이 방식은 MCP 서버로 제공된다. 예시로 회사의 법무, 재무, 인사, 제품 지식을 각각 전문가로 만들고, 하나로 묶어 전사 지식에 질문할 수 있다. 벡터 데이터베이스, 임베딩, 검색 단계 없이 작동한다고 주장한다. 모든 내용을 하나의 문맥 창에 넣는 방식보다 비용이 70~90% 낮다고 주장한다.
Orkaia는 AI 에이전트가 같은 실패 동작을 조금씩 바꿔 다시 실행하며 비용을 쓰는 문제를 줄이기 위한 오픈소스 도구다. 도구 이름과 정리된 입력값을 기준으로 같은 동작인지 식별하므로, 말만 바꾼 재시도도 반복으로 잡아낼 수 있다. 같은 동작이 정해진 횟수만큼 반복되면 전체 지출 한도에 닿기 전에 실행을 끊는다. 각 동작이 쓴 토큰도 따로 기록해, 나중에 어떤 행동이 비용을 만들었는지 바로 볼 수 있다. 로컬에서만 실행되며, 설치는 pip install orkaia로 할 수 있고 가입이나 API 키가 필요 없다. 데이터는 기기 밖으로 나가지 않으며, MIT 라이선스로 공개됐다. 현재 A→B→A→B처럼 두 동작이 번갈아 반복되는 경우를 더 잘 잡는 기능이 다음 과제로 남아 있다.
AI 에이전트가 여러 버전의 같은 자료를 동시에 받으면 답변 품질이 떨어질 수 있다. 예전 문서에는 어떤 기능이나 절차가 유효하다고 쓰여 있고, 새 문서에는 그것이 더 이상 쓰이지 않는다고 적혀 있으면 에이전트가 두 내용을 섞어 이해할 수 있다. 그 결과 이미 폐기된 정보와 최신 정보를 구분하지 못하고 잘못된 답을 만들 수 있다. 에이전트에게는 가능한 한 최신 파일만 넣는 편이 좋다. 변화 과정을 따져야 하는 특별한 일이 아니라면, 오래된 내용이나 폐기된 설명은 문맥에서 빼야 한다. 자료에는 폐기됨 표시를 해두고, 에이전트가 참고하는 입력 묶음에는 포함하지 않는 방식이 혼란을 줄인다.
AI 에이전트를 인기 벤치마크로 평가하려면 토큰 비용이 매우 크게 들 수 있다. terminal-bench나 SWE-bench 같은 벤치마크는 한 번 실행하는 데만 수천 달러가 들 수 있다는 경험담이 나왔다. 결과를 믿으려면 보통 여러 번 돌려 평균을 내야 하므로 총비용은 더 커진다. 특히 Opus 4.6으로 terminal-bench를 실행하면 한 번에 최대 4만 달러까지 들 수 있다는 추정이 제시됐다. 합리적인 결과를 얻기 위해 20만 달러 가까이 쓰지 않아도 되는 더 저렴한 벤치마크가 필요한 상황이다.
Vidilearn은 AI 에이전트와 RAG 시스템에 넣을 자료를 로컬에서 뽑아내는 오픈소스 도구다. 유튜브 자막, 자막 파일, 챕터 정보, 웹 글 본문, 구조화된 메타데이터를 추출할 수 있다. 외부 API 키 없이 로컬 처리 흐름으로 작동하는 점을 내세운다. 자동화 작업에 붙이기 쉽고, AI 시스템과 바로 연결하기 위한 MCP 서버 지원도 포함되어 있다. 성능 예시는 RAG 적중률 94.2%, 정밀도 92.1%, F1 점수 0.931이다. 절대적인 정확도는 Claude가 조금 더 높지만, Vidilearn은 거의 비용 없이 꽤 가까운 결과를 낸다는 주장이다. 기술 구성은 Node.js, Playwright, 로컬 처리 파이프라인이며, 설치는 npm i vidilearn으로 할 수 있다.
개발팀이 만든 시험 문장은 기술자처럼 정확하고 정리된 표현인 경우가 많다. 하지만 실제 사용자는 오타, 속어, 반쪽짜리 문장, 여러 요청이 섞인 문장으로 AI 에이전트에 말을 건다. 이 차이 때문에 개발용 문장에서는 성공률이 약 94%였지만, 실제 사용자 문장에서는 약 71%로 떨어졌다. 격차는 23%포인트다. 내부 직원이 직접 써보는 방식은 도움이 되지만, 직원들도 여전히 엔지니어처럼 말하는 한계가 있다. 사용자 테스트 패널은 표본이 작고 비용이 많이 든다. 작은 모델로 비격식 문장을 합성해 시험 데이터를 만드는 방법은 일부 문제를 잡아내지만, 실제 사람 말투처럼 자연스럽지 않은 느낌이 남는다. 핵심 고민은 실제 사용자 입력 분포를 더 잘 반영하는 평가를 어떻게 만들 것인가다.
browser-search는 AI 에이전트가 웹을 검색하고 실제 페이지를 열어 확인하도록 돕는 오픈소스 도구 묶음이다. 검색은 SearXNG가 맡고, 일반 웹사이트 탐색은 Camofox가 맡으며, 봇 차단이 강한 사이트는 CloakBrowser로 넘어가는 흐름이다. 목표는 에이전트가 먼저 웹에서 근거를 찾고, 그다음 답하게 만들어 없는 내용을 꾸며내는 일을 줄이는 것이다. 모든 구성은 직접 운영하는 방식이라 API 구독료나 사용량 제한 없이 쓸 수 있다고 설명된다. Camofox는 페이지에서 메뉴, 광고, 사이드바를 덜어낸 읽기 쉬운 본문을 뽑아 약 70%의 토큰 절감을 기대할 수 있고, 원본 HTML보다 훨씬 작은 접근성 스냅샷도 제공한다. SearXNG는 빠른 검색 목록을 만들고, Camofox와 CloakBrowser는 필요한 페이지에만 쓰이므로 매번 무거운 브라우저를 돌리는 낭비를 줄이는 구조다. 설치는 SKILL.md만 추가하는 빠른 방식과, SearXNG·Camofox·CloakBrowser를 함께 설치하는 전체 구성으로 나뉜다. 소셜미디어 로그인, 파일 다운로드, 유료 장벽 우회는 다루지 않는다.
SuperESP는 값싼 ESP32 보드에서 인터넷이나 클라우드 없이 실행되는 소형 AI 응용 묶음이다. 이 방식은 큰 서버, 그래픽 처리 장치, 구독형 서비스를 쓰지 않고 기기 안에서 바로 판단을 내리는 것을 목표로 한다. 기반 기술은 Atome LM v2이며, 일반 대화형 챗봇이 아니라 특정 상황을 분류하는 작은 AI 모델들로 구성되어 있다. 공개된 기능은 농업 상태 확인, 음성 명령, 움직임 인식, 손짓 감지, 소리 사건 분류, 기계 이상 감지, 공기 질 분석, 에너지 사용 확인, 사람 있음 추정, 착용 기기 활동 추적, 누수 감지, 예측 정비 등 12가지다. ESP32 운영체제와 범용 설치 도구가 함께 제공되며, GitHub와 Hugging Face에서 확인하고 직접 시험할 수 있다고 소개되어 있다. 각 주장에는 검증용 스크립트가 연결되어 있다고 되어 있다.
짧은 시험에서는 높은 점수를 받는 모델도 몇 시간짜리 에이전트 작업에서는 약해질 수 있다. 처음에 정한 규칙을 40분쯤 지나 잊고, 앞에서 끝낸 일을 나중에 스스로 되돌리는 문제가 생길 수 있다. 이런 문제는 보통 벤치마크 점수만 봐서는 드러나지 않는다. 짧고 따로 떨어진 문제를 잘 푸는 능력과 긴 작업 동안 같은 판단을 유지하는 능력은 다르다. 긴 코드 이전 작업처럼 초반의 작은 실수가 한 시간 뒤 큰 문제로 이어지는 일을 일부러 맡겨 보면, 많은 모델이 중간에 흐름을 놓친다. GLM-5.2는 그런 긴 작업에서 앞선 결정을 덜 흔들고 끝까지 이어 갔다. 다만 어려운 단발성 문제에서는 큰 폐쇄형 모델이 여전히 더 강할 수 있다.
iart-ai의 motion-skills는 AI 코딩 에이전트가 모션 그래픽, 애니메이션, 영상 제작 작업을 더 잘 처리하도록 돕는 오픈소스 기술 묶음이다. 전체는 50개 기술과 14개 설치형 묶음으로 나뉘며, 틱톡·릴스·쇼츠 영상, 문자 대화형 영상, 유튜브 영상, 전자상거래 영상, 광고 영상, 데이터 차트 애니메이션, 설명 영상, 지도 애니메이션, 웹 애니메이션, 3D·WebGL, Manim 수학 애니메이션 등을 다룬다. 각 기술은 에이전트가 특정 작업 방식을 읽고 따라 할 수 있는 폴더 형태이며, 별도 모델 훈련이나 실행용 플러그인이 필요하지 않다. 설치는 필요한 묶음만 골라 하는 방식이고, Claude Code, Cursor, Codex 등 여러 에이전트가 프롬프트와 맞는 기술을 자동으로 찾아 쓸 수 있다고 소개된다. 영상이나 시각 결과물을 만드는 기술에는 결과를 만든 뒤 화면 캡처나 프레임 확인으로 스스로 검토하는 절차와 작은 도구가 포함된다. 웹용 기술은 독립 실행형 HTML을 만들고, 영상용 기술은 Remotion이나 Manim으로 렌더링하는 방식이다. MIT 라이선스로 공개되어 자유롭게 사용할 수 있다.
Pulse는 Claude Code 작업 세션을 계속 저장한 뒤, 에이전트가 그 기록을 읽고 정리하는 도구다. 매일 밤 에이전트가 하루 동안의 원자료를 한 개의 노트로 바꾸며, 무엇을 만들었는지, 어떤 결정을 했는지, 아직 남은 일이 무엇인지 정리한다. 매주 다른 에이전트가 그 노트들을 모아 사용자의 기술과 프로젝트 흐름을 보여주는 프로필로 만든다. 또 다른 에이전트는 한 주의 내용을 바탕으로 LinkedIn과 X에 올릴 글 초안을 만든다. 이 작업은 클라우드 루틴으로 돌아가서, 개인 컴퓨터가 꺼져 있어도 계속 실행된다. 현재는 세션을 저장하는 기능과 매일 노트를 만드는 에이전트가 오픈소스로 공개됐고, 주간 프로필과 게시글 작성 기능은 나중에 공개될 예정이다.
Moonshot이 이번 주 Kimi K2.7 Code를 오픈소스로 공개했다. 성능 수치는 Kimi Code Bench v2 50.9에서 62.0, Program Bench 48.3에서 53.6, MLS Bench Lite 26.7에서 35.1, MCP Mark Verified 72.8에서 81.1로 올랐다. 모델 구조는 같은 1T MoE 계열이며, 한 번에 실제로 쓰는 활성 매개변수는 32B이고, 256k 컨텍스트를 처리한다. 더 중요한 변화는 K2.6보다 추론 토큰 사용량이 30% 줄었다는 점이다. 코딩 에이전트는 문제를 살피고, 코드를 고치고, 테스트하고, 실패하면 다시 시도하는 과정을 반복하기 때문에 추론 토큰이 비용 병목이 되기 쉽다. 최고급 모델인 GPT-5.5나 Opus와의 코딩 성능 격차는 아직 남아 있다. 다만 Moonshot 표 기준 MCP Mark Verified에서는 K2.7이 81.1로 Opus 4.8의 76.4보다 높아, 에이전트형 평가에서는 꽤 경쟁력이 있어 보인다. 앞으로 나올 고속 모드는 같은 모델에서 출력 속도를 약 5~6배 높인다고 하며, 사실이라면 최고 모델을 완전히 대체하기보다 반복 작업의 비용과 시간을 줄이는 용도에 더 맞다.
작은 인공지능 스타트업이 실시간 코딩 에이전트를 만들려면 매우 빠른 추론이 필요하다. 목표 성능은 초당 약 1,000~2,000개 토큰을 꾸준히 처리하는 수준이며, 응답 지연도 낮아야 한다. 이 회사는 학습용 대형 장비보다 실제 서비스에서 빠르게 답을 만들어내는 Cerebras의 ASIC 추론 API 접근을 원했다. 하지만 몇 달째 대기 중이며, OpenAI가 Cerebras 칩을 대규모로 사들이는 계약 때문에 가까운 시기의 추론 용량 대부분이 한 고객에게 먼저 배정됐다고 보고 있다. 그 결과 대형 클라우드 기업이 아닌 팀에게는 API 대기열이 사실상 끝없이 길어진 상태처럼 느껴진다. Cerebras가 상장했지만 바로 쓸 수 있는 계산 자원이 부족해 보인다는 불만도 포함되어 있다.
1년 동안 커진 인공지능 평가 기준이 14개 항목까지 늘어났다. 항목에는 사실 충실성, 관련성, 도움 정도, 말투, 범위, 거절의 정확성, 안전성, 무해성, 완성도, 간결성, 구조, 인용, 도구 호출 정확성, 형식이 포함된다. 이미 사람이 라벨을 붙인 자료로 상관관계 행렬을 돌려 보니, 약 6개 항목은 다른 항목 하나 이상과 0.85를 넘는 높은 상관관계를 보였다. 이는 그 항목들이 독립적인 신호를 거의 더하지 않는다는 뜻이다. 하지만 항목을 지우면 드문 예외 상황을 놓칠 수 있다는 걱정이 있다. 반대로 그대로 두면 평가용 인공지능 판정 비용과 평가 기준을 관리하는 개발 시간이 계속 늘어난다.
Sara AI는 사기꾼과 대화를 이어가며 전화번호, UPI ID, 사기 대본 같은 단서를 모으도록 만든 AI 허니팟이다. 인도 가정주부처럼 힝글리시로 답하며 상대가 대화를 계속하게 만드는 방식이다. 첫 버전은 말투와 역할 유지에는 성공했지만, 대화가 끝나면 모든 내용을 잊었다. 지난주에 나온 UPI ID를 다시 알아보지 못했고, 같은 사기꾼이 전화번호를 바꿔도 연결해서 판단하지 못했다. 그래서 단순한 대화형 API에 설정을 붙인 수준에 가까웠고, 실제 허니팟으로 쓰기에는 부족했다. 더 쓸 만한 구조에는 세션이 끝나도 이어지는 기억, 대화 중 바로 정리되는 정보 추출, 문제가 생겼을 때 어느 단계가 실패했는지 볼 수 있는 처리 흐름이 필요하다. Hindsight는 에이전트 기억을 맡고, CascadeFlow는 여러 요청 단계를 조립하고 추적하는 처리 흐름을 맡는 도구로 제시된다.
개인 실험 단계의 도구가 코드 저장소를 훑어 앱 전체 구조를 눈으로 볼 수 있는 대화형 지도로 바꾼다. 이 지도는 코드가 복잡하게 얽힌 곳이나 쉽게 깨질 수 있는 부분도 표시한다. 목표는 AI가 매번 전체 코드를 다시 읽지 않고 구조 지도를 참고하게 만들어 토큰 사용량과 작업 시간을 줄이는 것이다. 특히 바이브 코딩처럼 AI가 코드를 자주 만들고 고치는 방식에서 AI가 망가뜨리기 쉬운 부분을 미리 찾는 데 도움을 주려 한다. 실제 앱으로 테스트하고 있으며, 완성품이라기보다 거친 초기 실험에 가깝다. 코드 저장소를 보내면 지도를 만들어 보고 피드백을 받겠다는 제안이다.
로컬 Llama 같은 AI 에이전트에 도구 50개를 한꺼번에 넣으면 문맥이 커져 느려지고 판단도 흐려질 수 있다. MCP 생태계는 주로 Python과 TypeScript 실행 환경에 치우쳐 있어서, Go 백엔드가 여러 MCP 서버와 연결하려면 무거운 실행 환경을 붙이거나 하위 프로세스를 띄우는 방식이 필요해지기 쉽다. 이를 줄이기 위해 Go로 만든 가벼운 도구 게이트웨이와 라우팅 엔진이 제시됐다. 이 엔진은 HTTP/SSE로 여러 서버에 연결하고, 검색 색인을 만든 뒤, 사용자의 요청에 맞는 도구 후보를 실시간으로 고른다. 사용자가 “날씨를 알려주고 점심도 예약해줘”처럼 여러 일을 한 문장에 말하면, 정규식과 숫자 확인으로 문장을 나누고 Go의 고루틴으로 동시에 라우팅한다. 음성 입력처럼 같은 요청 조각이 빠르게 반복될 때는 singleflight로 같은 요청을 하나로 묶어, 임베딩 API를 불필요하게 여러 번 때리지 않게 한다. 패키지 사용 방식은 빌더 패턴으로 만들었고, 개발 도구의 자동완성이 설정 과정을 안내하도록 설계됐다.
codelight는 Claude Code 같은 인공지능 코딩 도구의 작업 상태와 토큰 사용량을 따로 보여주는 오픈소스 도구다. 컴퓨터에서 Python 데몬을 실행하면 Claude Code의 사용량, 대기 상태, 작업 중 여부를 읽어 GeekMagic Ultra 작은 화면, Android 위젯, GNOME 패널, VSCode 상태 표시줄로 보낸다. 원격 제어를 켜면 자리에서 떨어져 있어도 Android 앱이나 GNOME 패널에서 권한 요청을 허용하거나 거절할 수 있고, 질문에는 Android, GNOME, VSCode에서 답할 수 있다. 여러 기기에서 동시에 답할 수 있을 때는 먼저 들어온 답이 적용된다. 답할 수 있는 기기가 연결되어 있지 않으면 Claude Code의 기본 확인창으로 바로 넘어가도록 되어 있어 작업이 멈춰 남는 상황을 줄인다. 설치는 화면 펌웨어를 넣고, 컴퓨터에서 `python3 companion/codelight.py --name my-laptop`를 실행한 뒤, 원격 제어가 필요하면 `--secret`과 `--remote-control` 옵션을 붙이는 흐름이다.
ICLR 2026에 ‘재귀적 자기 개선’ 워크숍이 열리며, 이 분야가 박사 연구 주제로 검토되고 있다. 재귀적 자기 개선은 AI가 자신의 실패를 찾고, 행동을 비판하고, 기억·도구·기술을 바꾸며 더 나아지는 방식을 뜻한다. 워크숍은 이 아이디어를 막연한 미래 이야기가 아니라 실제 시스템 설계 문제로 다룬다. 주요 관심사는 언제 무엇을 바꿀지, 보상이나 모방 학습으로 어떻게 개선을 만들지, 웹·업무·로봇·과학 같은 환경에서 어떻게 작동할지다. 안전 문제도 함께 다룬다. 긴 작업에서 성능이 흔들리지 않는지, 새 개선이 기존 능력을 망가뜨리지 않는지, 문제가 생겼을 때 되돌릴 수 있는지가 핵심이다.
로컬에서 대규모 언어 모델을 실행하면 외부 서비스로 데이터를 보내지 않고 쓸 수 있어 속도, 통제력, 규모가 커졌을 때의 비용 면에서 이점이 있을 수 있다. 하지만 로컬 실행이 곧 안전을 뜻하지는 않는다. 데이터는 로그, 플러그인, 모델 다운로드, 잘못 설정된 권한, 프롬프트에 무심코 붙여 넣은 내용 같은 경로로 새어 나갈 수 있다. 안전하게 쓰려면 설치 전부터 무엇을 보호할지 정해야 한다. 고객 개인정보, 내부 전략 문서, 소스 코드, 의료 기록처럼 모델이 다룰 데이터를 구분하고, 유출되면 규제 문제, 경쟁상 손실, 평판 피해 중 무엇이 생길지 따져야 한다. 위험 요인도 악성코드, 호기심 많은 동료, 감염된 의존성, 실수로 인한 공유처럼 구체적으로 생각해야 한다. 기본 원칙은 명시적으로 허용한 것 외에는 어떤 데이터도 기기 밖으로 나가지 않게 하는 것이다.
Gemma 4 12B Q8 모델로 바꾼 뒤 생성 속도가 초당 약 70토큰에서 10토큰으로 크게 떨어졌다. 같은 환경에서 GPT-OSS 20B Q4를 쓸 때보다 작은 모델인데도 훨씬 느려진 것이다. Q8 대신 Q5 모델을 써도 속도 차이는 거의 없었다. 생각 기능을 끄는 설정을 넣었지만 초당 약 2토큰 정도만 빨라졌다. 서버는 llama.cpp의 llama-server로 실행되고, 16개 스레드, 문맥 크기 8192, 그래픽카드 레이어 99개, 배치 크기 4096 설정을 사용한다. 그래픽카드 메모리는 전체 20GB 중 약 10GB만 쓰고 있어, 단순히 메모리가 꽉 차서 느린 상황은 아닌 것으로 보인다.
Claude를 쓸 때 매번 결과만 받는 데서 끝내지 않고, 작업이 끝난 뒤 Claude가 자기 답변과 사용자의 지시문을 함께 점검하게 하는 방식이다. Claude는 더 나은 답을 만들기 위해 무엇을 고쳐야 하는지, 사용자가 다음에 어떤 식으로 요청하면 좋은지, 도움이 되는 표현이나 단어는 무엇인지 정리한다. 그 결과를 다음 세션 시작 때 다시 읽도록 저장해 두면, 이전에 배운 개선점을 잊지 않고 이어갈 수 있다. 목적은 Claude의 출력 품질을 높이고, 사용자의 프롬프트 작성 능력을 키우며, 반복 작업에서 불필요한 설명과 시행착오를 줄이는 것이다. 품질 관리, 토큰 절약, 컨텍스트와 메모리 활용, 스킬 관리에 연결되는 중간 난도 워크플로다.
사내 위키와 검색 증강 생성 기반 답변 시스템을 직접 운영하려는 설계다. 원본 권한 정보와 문서 상태는 PostgreSQL이 기준으로 관리하고, Qdrant는 다시 만들 수 있는 검색용 저장소로 둔다. 문서가 올라오면 Redis 대기열을 거쳐 작은 조각으로 나누고, PostgreSQL에 조각·감사 기록·작업 목록을 저장한 뒤, 별도 작업자가 임베딩을 만들어 Qdrant에 넣는다. Qdrant의 각 문서 조각에는 접근 가능한 조직 단위, 민감도 등급, 문서 상태가 함께 저장된다. 질문이 들어오면 사용자의 조직 접근 범위를 계산해 Qdrant에서 먼저 걸러 찾고, 상위 결과는 다시 PostgreSQL에서 문서 상태·민감도 권한·테넌트를 확인한 뒤 LLM에 넘긴다. 조직 개편이나 권한 회수가 생기면 영향을 받는 문서 조각을 다시 기록해야 하는데, 하위 조직에 문서가 1만 개 이상 있으면 한꺼번에 작업이 몰릴 수 있다는 점이 가장 큰 위험이다.
안드로이드 앱 하나에서 MNN Chat, Google AI Studio, llama.cpp 기반 모델을 함께 쓰려는 실험이다. MNN 모델 지원은 아직 직접 검증되지 않았고, GGUF 모델은 llama.cpp로 실행된다. 삼성 갤럭시 S23 FE에서 Gemma 3 1B는 초당 약 20토큰, 같은 휴대폰에서 TFLite 기반 Gemma 4 e2b는 초당 약 10토큰 속도로 동작했다. 앱은 깃허브에 오픈소스로 공개되어 있다. 검색 기능은 아직 테스트 중이며 공개되지 않았고, 사고 모드, 음성 입력과 출력, 앱 안에서 서버를 여는 기능도 포함된다. 여기에 웹 화면, RAG, OCR을 붙일 수 있는 구조를 목표로 한다. 아직 공개되지 않은 Invent 화면은 세 개의 모델을 이어 붙인다. 첫 모델은 프로젝트 아이디어를 묻고 정리하며, 두 번째 모델은 최신 정보와 의존성, 실현 가능성을 찾고, 첫 모델이 다시 확인한 뒤 세 번째 코딩 모델로 넘기는 방식이다.
RAGless는 자주 묻는 질문을 찾고 답하는 시스템이다. 문서를 넣을 때만 대규모 언어 모델을 쓰고, 실제 질문에 답할 때는 대규모 언어 모델을 쓰지 않는다. PDF, 텍스트, 마크다운 문서를 넣으면 Gemini가 답변과 여러 형태의 질문 문장을 미리 만든다. 각 질문 문장은 임베딩으로 바뀌어 로컬 Qdrant에 저장된다. 사용자가 질문하면 그 질문도 임베딩으로 바뀌고, 저장된 질문들 중 가까운 것을 찾은 뒤 같은 답변에 연결된 점수를 합쳐 가장 알맞은 미리 쓴 답변을 돌려준다. 실행 중에는 새 답변을 생성하지 않기 때문에 실행 시 프롬프트 작업이 필요 없고, 설계상 없는 내용을 지어낼 가능성을 줄인다. 문서 조각 하나를 바로 찾는 방식이 아니라, 같은 답변에 붙은 여러 질문 변형을 함께 평가해서 검색을 더 튼튼하게 만들려는 접근이다. Ollama를 쓰면 완전히 오프라인으로도 동작하며, 설정 파일에서 EMBEDDING_MODEL만 바꾸면 된다.
여러 AI 에이전트가 서로 다른 서비스나 팀에 속해 있을 때, 이메일을 비동기 연락 수단으로 쓸 수 있다. 보통은 공유 메모리나 메시지 큐를 떠올리지만, 두 방식은 에이전트들이 같은 실행 환경에 있거나 같은 기반 시설을 믿는다는 전제가 있다. 서비스 소유자, 배포 환경, 서비스 수준 약속이 다르면 공유 상태를 맞추는 일이 빠르게 복잡해진다. 이메일은 각 대화에 메시지 식별자와 답장 연결 정보가 있어, 어떤 답장이 어떤 요청에 이어지는지 추적하기 쉽다. 보내는 쪽과 받는 쪽이 동시에 켜져 있지 않아도 메시지가 남기 때문에, 서비스 경계를 넘는 오래 가는 비동기 작업에 맞다. 문제가 생겼을 때 이메일 스레드를 보면 대화 흐름을 사람이 읽을 수 있어, 여러 에이전트가 얽힌 작업을 되짚기 쉽다.
작은 언어 모델인 Qwen3.5-4B로 조명, 선풍기, 에어컨, 커튼 같은 사물인터넷 기기를 직접 제어하는 AI 에이전트를 만들고 있다. 큰 모델을 쓰면 더 안정적일 수 있지만, 응답이 느려지는 문제가 있다. 현재 시스템은 여러 도구 호출, 한 번에 여러 행동 처리, 한 문장 안의 여러 의도 처리, 일반 대화, 구조화된 JSON 출력, 실행 전 백엔드 검증을 지원한다. 예를 들어 침실 조명을 켜고 밝기를 70%로 맞추거나, 커튼을 닫고 에어컨을 끄며 내일 날씨까지 알려주는 요청을 처리해야 한다. 문제는 모델이 잘못된 도구를 고르거나, 틀린 매개변수를 만들거나, 존재하지 않는 기기에 명령을 내리거나, 기기 제어와 일반 질문이 섞이면 혼란스러워한다는 점이다. 해결 방향으로 모든 요청을 모든 도구가 열린 큰 언어 모델에 바로 보내는 방식, main LLM 앞에 routing layer를 두는 방식, 시스템을 더 작은 전문 영역으로 나누는 방식이 검토되고 있다.
peerd는 크롬과 파이어폭스 확장 프로그램으로 작동하는 오픈소스 AI 에이전트 실행 도구다. 사용자가 이미 열어 둔 탭과 로그인 상태를 이용해 웹페이지를 읽고, 클릭하고, 작업을 진행할 수 있다. 자바스크립트 노트북, 브라우저 안 리눅스 가상머신, 작은 클라이언트 앱 같은 격리된 실행 공간도 만들 수 있다. 서버를 거치지 않고, 원격 백엔드나 사용 추적 기능도 없으며, 사용자가 직접 고른 모델 제공업체의 API 키를 넣어 쓰는 방식이다. Anthropic, OpenRouter, 로컬 Ollama 같은 모델을 연결할 수 있고, Ollama를 쓰면 키 없이 자기 컴퓨터에서 실행할 수 있어 모델 호출 비용을 피할 수 있다. API 키와 대화 기록은 기기 안의 암호화된 보관함에 저장되며, 키는 선택한 모델 제공업체로만 보내진다. 아직 0.x 단계의 실험적 베타라서 기능과 저장 형식이 바뀔 수 있고, 브라우저를 조작하며 API 키도 보관하므로 조심해서 써야 한다.
문서에서 관련 내용을 찾아 온 뒤 그 문서만 바탕으로 답하게 만든 AI 기능도 위험하게 틀린 답을 낼 수 있다. 문제가 된 경우에는 검색 결과가 완전히 비어 있지는 않았지만, 관련성이 약한 조각들만 돌아왔다. 모델은 그 부족한 문맥 사이를 스스로 메웠고, 맞는 답처럼 자신 있게 보이는 답을 고객에게 내보냈다. 시스템은 멈추거나 오류를 내지 않았고, 겉으로는 정상 작동처럼 보였다. 핵심 실수는 검색을 붙이면 자동으로 근거 있는 답변이 된다고 믿은 점이었다. 검색은 모델에 문맥을 줄 뿐, 모델이 그 문맥 안에서만 말하도록 보장하지 않는다.