AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
코딩 에이전트로 버튼이나 화면 요소를 만들 때, 같은 프로젝트인데도 세션마다 색상, 간격, 글자 크기가 조금씩 달라질 수 있다. 예를 들어 첫 세션에서는 파란색을 #3B82F6으로 쓰고, 다음 세션에서는 #2563EB을 쓰고, 또 다른 세션에서는 bg-blue-500 같은 다른 표현을 고를 수 있다. 간격도 1rem, 16px, gap-4처럼 섞이고, 글자 크기도 text-xl, 1.25rem, 20px처럼 흔들릴 수 있다. 원인은 에이전트가 참고할 수 있는 구조화된 색상표나 토큰 표가 없기 때문이다. CLAUDE.md, AGENTS.md, .cursor/rules 같은 규칙 파일에 브랜드 색상을 문장으로 써 두어도, 모델은 실제 코드를 만들 때 어떤 값을 써야 하는지 다시 해석하고 추측해야 한다. 마크다운 표로 색상표를 넣는 방식은 작은 프로젝트나 한 번 쓰는 작업에는 어느 정도 도움이 되지만, 대화가 길어지면 다시 흔들릴 수 있다. tailwind.config.js를 기준 파일로 두고 에이전트에게 읽게 하는 방식은 자연어 규칙보다 더 구조적이라 낫다.
노코드 AI 에이전트 빌더는 작은 회사나 개발팀이 없는 고객에게 빠르게 쓸 수 있는 AI 상담 도구를 만들 때 유용하다. 고객의 웹사이트 내용을 바탕으로 1시간 안에 작동하는 지원 에이전트를 만들 수 있고, 그 시간의 대부분은 도구 설정이 아니라 좋은 시스템 프롬프트를 쓰는 데 쓰인다. 코드를 쓰지 않아도 되기 때문에, 만든 뒤에는 고객이 직접 로그인해서 가격 같은 정보를 고칠 수 있다. 같은 에이전트를 웹사이트, WhatsApp, Slack에 따로 다시 만들지 않고 붙일 수 있는 점도 장점이다. 대부분 무료 요금제가 있어 돈을 내기 전에 실제 업무에 맞는지 시험해 볼 수 있다. 단점은 환각이다. 답변을 학습 데이터 안으로 제한하지 못하는 빌더는 고객이 예상 밖의 질문을 하면 없는 환불 정책이나 없는 기능을 지어낼 수 있다. 또 맞춤 설정이 제한되어 있으며, 예를 들어 잠재고객 정보 입력 양식이 이름, 이메일, 전화번호 정도로만 묶여 있을 수 있다.
Claude Code를 여러 번 나누어 쓰면 이전 대화와 작업 흐름이 흩어져 같은 설명을 다시 해야 하는 일이 생긴다. `obsidian-vault-sync`라는 파이썬 스크립트는 Claude Code가 로컬에 남기는 `.jsonl` 대화 기록을 읽어 Obsidian 보관함 안의 정리된 마크다운 노트로 바꾼다. Claude Code의 내부 메모리 폴더를 Obsidian에 심볼릭 링크로 연결해, 프로젝트별로 Claude가 기억하는 내용을 사람이 직접 보고 고치고 서로 연결할 수 있게 한다. 분류는 외부 인공지능 호출 없이 가중치가 붙은 키워드 매칭으로 처리한다. 저장할 가치가 있는 내용만 거르는 `vault-worthy` 필터도 포함한다. 자동 동기화는 `cron`이나 `launchd`로 예약할 수 있다.
가장 강한 AI 모델도 계속 쓸 수 있는지 알 수 없으면 실제 워크플로에 넣기 어렵다. 프런티어 모델은 성능뿐 아니라 접근 규칙까지 제품의 일부로 봐야 한다. 누가 쓸 수 있는지, 어떤 기능까지 포함되는지, 임시 미리보기인지 오래 유지되는 접근인지, 심사가 필요하면 어떤 절차를 거치는지, 막혔을 때 어떤 대체 모델을 써야 하는지가 명확해야 한다. 제한을 모두 없애자는 뜻은 아니다. 중요한 AI 작업은 미리 계획할 수 있는 접근 규칙이 있어야 안정적으로 운영될 수 있다.
내부에서 약 4개월 동안 쓰던 LLM 도구에 기존 API 보안 체계를 그대로 적용했지만, 레드팀이 30분 안에 프롬프트 인젝션으로 시스템 프롬프트의 동작을 바꿨다. WAF는 요청이 로그인된 사용자의 정상 JSON 요청이고 형식도 맞다고 보고 통과시켰다. 기존 API 보안은 정해진 형식과 규칙에서 벗어난 입력을 막는 데 강하지만, LLM은 자연어 문장을 입력으로 받기 때문에 “이전 지시를 무시하라” 같은 문장도 평범한 사용자 메시지처럼 보일 수 있다. AI 방화벽은 글의 뜻과 의도를 살펴보고, 실행 중간 단계에서도 프롬프트 인젝션을 잡으며, 사용자가 답변을 받기 전에 LLM 출력도 검사할 수 있다는 점이 다르다. RAG에서 가져온 내부 문맥이 답변에 새는 문제도 출력 검사 없이는 놓칠 수 있다.
IDE(코드 편집 환경)에서 AI 사용 토큰이 바닥났을 때, 브라우저에서 무료 AI를 써서 얻은 코드 수정안을 로컬 파일에 자동으로 붙여넣어 주는 파이썬 스크립트다. 터미널에서 실행하며, AI가 제안한 코드 편집 내용을 특정 형식으로 붙여넣으면 스크립트가 알아서 해당 파일을 찾아 수정을 적용한다. AI가 들여쓰기를 살짝 틀리거나 빈 줄을 잘못 넣어도 difflib(파이썬 표준 비교 도구)로 유사도를 계산해 허용 오차 안에서 처리한다. 파일 경로를 AI가 일부 잊어버려도 파일을 추적해 찾아낸다. 실제로 파일에 쓰기 전에 삽입 내용과 유사도 점수를 미리 보여줘서 잘못 적용되는 걸 방지한다. 설정은 patcher.py를 ~/scripts/ 폴더에 저장하고 .bashrc 또는 .zshrc에 함수를 추가하는 것으로 끝난다. 작성자 본인도 완벽하다고 보장하지 않으므로 사용에 주의가 필요하다.
오픈소스로 공개된 AI 에이전트 파이프라인이 이야기 아이디어 하나를 받아 드라마 에피소드 제작 과정을 끝까지 처리한다. 시리즈 설정집을 바탕으로 대본을 쓰고, 인물 관계, 줄거리, 다음 회차로 이어지는 긴장 요소를 추적한다. 각 에피소드는 긴장감, 말투의 일관성, 이야기 연결성 기준으로 점검된다. 장면 이미지는 Gemini, OpenAI, Qwen, Leonardo 중에서 골라 만들 수 있고, ElevenLabs로 내레이션 음성을 만든다. 자막은 자동으로 만들고 영상에 맞춰 붙이며, 내장 음악 목록에서 배경음악을 넣고, Remotion으로 세로형 9:16 영상을 내보낸다. 같은 원본 에피소드를 영어, 튀르키예어, 독일어, 스페인어, 아랍어로 번역하고 음성 더빙도 다시 만들 수 있다. MCP 도구 13개를 지원해 Claude Code나 Cursor에서 자연어로 전체 제작 흐름을 지시할 수 있다. 기술 구성은 Next.js, PostgreSQL, Prisma, Remotion이며, 직접 호스팅하고 API key는 사용자가 넣는 방식이다.
복잡한 일을 한 번에 맡기면 LLM이 중간에 방향을 잃거나 대충 처리할 수 있다. 이 방법은 큰 작업을 사람이 하듯 작은 단계로 나누고, 각 단계마다 전용 지시문인 스킬을 만든 뒤, 처리할 항목 목록에 상태 추적을 붙여 진행한다. LLM은 목록을 보며 어떤 항목이 남았는지 확인하고, 필요한 스킬을 적용해 하나씩 끝낸다. 이렇게 하면 문맥이 흐려지는 문제를 줄이고, 빠뜨린 항목을 다시 확인하기 쉬워진다. 복잡한 분석, 디버깅, 품질 검토처럼 여러 단계를 거치는 작업에서 결과의 일관성과 꼼꼼함을 높이는 데 초점이 있다.
Claude와 긴 대화를 계속 이어가면 작업이 복잡해질수록 집중력이 떨어지고, 앞뒤 맥락이 흐려져 대충 처리하거나 지시를 놓칠 수 있다. 해결책은 큰 프로젝트를 한 대화에서 끝까지 밀어붙이지 않고, 문헌 조사, 개요 작성, 초안 작성, 수정처럼 작은 단계로 나누는 방식이다. 각 단계는 새 채팅에서 시작해 불필요하게 긴 대화 기록을 줄이고, 필요한 내용만 넘긴다. 이전 단계의 핵심 내용은 ‘스킬’에 정리된 인수인계 메모로 전달한다. 이렇게 하면 Claude가 새 문맥에서 더 선명하게 작업하고, 토큰을 덜 쓰면서 품질도 관리할 수 있다. 작업이 끝난 뒤에는 어떤 실수가 있었는지 돌아보고, 그 내용을 Claude의 스킬이나 전역 선호 설정에 반영해 다음 작업 방식을 개선한다.
Claude Code 같은 MCP 에이전트가 실제 업무 앱에서 API 버그를 얼마나 잘 찾고 고치는지 반복해서 시험하는 방법이다. 핵심은 특정 API에 대한 지식을 모아 둔 맞춤형 MCP 서버를 만들고, 이미 만들어진 작은 FastAPI 앱에 흔한 API 버그를 일부러 심어 두는 것이다. 그다음 에이전트에게 이 앱을 맡겨 버그를 찾아내고 고치는 과정을 관찰한다. 결과를 모아 어떤 지식이 부족했는지, 프롬프트가 어디서 헷갈렸는지, MCP 시스템 자체가 어디서 약했는지 확인한다. 이후 API 지식, 에이전트 프롬프트, MCP 구성을 계속 고쳐 가며 테스트 품질을 높인다. 이 방식은 난이도 높은 품질 관리, 디버깅, 문맥 관리, 토큰 절약, 여러 에이전트 운용을 함께 다루는 반복 가능한 오픈소스 실험 틀로 제시된다.
Claude가 대화마다 선호 방식이나 작업 배경을 잊으면 같은 지시를 계속 다시 써야 하고 결과물도 들쭉날쭉해질 수 있다. 해결책은 Claude.ai 또는 Claude 앱의 설정에서 Claude 메모리 기능을 켜고, Claude Code에서는 CLAUDE.md 파일에 프로젝트 규칙과 작업 선호를 적어 두는 방식이다. 이렇게 하면 긴 대화나 여러 작업 세션을 이어 갈 때 Claude가 기본 요구사항을 더 잘 유지할 수 있다. 목적은 반복 프롬프트를 줄이고, 복잡한 작업에서 결과 품질을 더 안정적으로 만드는 것이다. 이 작업 방식은 품질 관리, 토큰 절약, 컨텍스트 유지, CLAUDE.md 활용에 초점이 있으며, 가치 점수는 85/100, 신뢰도는 0.95, 난이도는 중급으로 제시되어 있다.
Claude Code로 복잡한 개발 작업을 할 때 품질이 들쭉날쭉해지고, 이전 맥락을 잃고, 실행 순서가 흐트러지는 문제를 줄이기 위한 고급 작업 방식이다. 핵심은 claude.md에 작업 범위와 규칙을 적은 경계 프로토콜을 두고, 구조화된 XML 프롬프트로 지시를 분명하게 만드는 것이다. Claude는 개발팀처럼 작업을 나눠 수행하고, Codex는 검토하는 관리팀처럼 결과를 점검하는 식으로 역할을 나눈다. 변경 사항은 왜 필요한지 설명하고 방어해야 하며, 단계별 준비와 검토 관문을 거친 뒤 다음 단계로 넘어간다. 메모리 확인을 강제로 넣고, 프로젝트의 지속적인 맥락을 유지해 코드 결과가 더 일관되고 확인 가능해지도록 한다. 주제 분류에는 품질 관리, 토큰 절약, 문맥과 메모리, 디버깅, 배포, CLAUDE.md, 스킬, 하위 에이전트, 다중 에이전트가 포함된다.
DWN.Bridge는 윈도우 데스크톱에서 돌아가는 오픈소스 AI 에이전트 도구다. 목표는 자율적으로 코드를 고치거나, 여러 번 시도하며 작업하거나, 데이터베이스 구조를 분석할 때 생기는 큰 API 비용을 줄이는 것이다. 일반적인 AI 에이전트는 많은 토큰을 쓰기 때문에 짧은 시간에도 비용이 빠르게 커질 수 있다. 이 도구는 별도 API 대신 사용자가 이미 접속한 Gemini Web 세션을 로컬 작업공간과 연결한다. 그래서 도구 호출, 로컬 파일 접근, SQL 질의 같은 에이전트 기능을 API 비용 없이 쓰는 구조를 내세운다. 엑셀 파일 분석 예시에서는 원본 데이터를 클라우드로 보내지 않고, LLM에는 스키마만 보여준 뒤 SQL 논리를 만들게 한다. 민감한 데이터 노출을 줄이면서 토큰 사용도 줄이려는 방식이다.
AgentForge는 콘텐츠 제작 흐름을 여러 AI 에이전트로 나누어 처리하는 오픈소스 도구다. 8개의 전문 에이전트가 각자 맡은 일을 처리하고, 비동기 병렬 실행으로 여러 작업을 동시에 진행할 수 있다. 여러 LLM 제공자를 바꿔 꽂을 수 있어 특정 회사 모델에만 묶이지 않는다. 토큰 추적 기능이 있어 AI 호출에 얼마나 많은 사용량이 들어가는지 확인할 수 있다. 설정은 YAML 파일로 관리해 코드 수정 없이 흐름을 바꾸는 구조를 목표로 한다.
작거나 중간 규모의 검색 증강 생성 시스템에서는 문서가 바뀌면 문서 전체를 다시 색인하는 경우가 많다. 문서 안에서 바뀐 조각만 찾아 다시 처리하는 방식은 만들고 관리하기가 복잡해서, 규모가 크지 않으면 얻는 이익이 크지 않다. 문서 양이 많고 업데이트가 자주 일어나는 큰 시스템에서는 점진적 파이프라인이 더 중요해진다. 이유는 임베딩 비용만이 아니라 최신 상태 유지, 처리 속도, 운영 안정성과도 관련이 있다. 실제 어려움은 임베딩 자체보다 문서 버전 관리, 접근 권한, 삭제 처리, 감사 기록, 최신성 보장 같은 운영 문제에 더 가깝다. AI가 참고하는 지식을 계속 정확하게 맞춰 두는 일은 단순한 검색 기능이 아니라 더 넓은 인프라 문제다.
Flama는 파이썬 함수 몇 개에 장식자를 붙여 AI 에이전트가 쓸 수 있는 MCP 서버를 만들게 해준다. MCP는 AI 앱이 외부 기능과 데이터에 같은 방식으로 연결되도록 돕는 공개 표준이다. 서버는 세 가지를 제공한다. 도구는 AI가 실행할 수 있는 함수이고, 리소스는 AI가 읽을 수 있는 데이터이며, 프롬프트는 다시 쓸 수 있는 지시문 틀이다. Flama에서는 서버를 특정 주소에 등록한 뒤, 더하기 같은 함수는 도구로, 설정 정보는 리소스로, 요약 지시문은 프롬프트로 공개한다. 함수의 입력과 출력 정보는 파이썬 타입 힌트에서 자동으로 만들어져 클라이언트가 어떤 값을 넣고 어떤 결과를 받을지 알 수 있다. 긴 작업은 백그라운드 작업으로 돌릴 수 있고, 추가 확인이 필요하면 사용자 입력을 다시 받을 수 있으며, 결과 옆에 작은 사용자 인터페이스도 붙일 수 있다. 하나의 Flama 앱 안에 여러 MCP 서버를 둘 수 있어 기능을 분야나 버전별로 나눌 수 있다. 요청마다 필요한 정보가 모두 담기는 상태 없는 방식이라 서버를 여러 대로 늘리기 쉽고, 별도 설정 파일이나 코드 생성 없이 시작할 수 있다.
AMD Radeon RX 7900 XTX와 Ubuntu 환경에서 llama.cpp의 Vulkan 빌드로 Qwen3.6-35B-A3B IQ4_XS 모델을 실행하는 설정이다. 목표 문맥 길이는 262k로 매우 길고, 메모리 사용량은 약 22GiB 수준이다. 같은 환경에서 최적화한 ROCm 7.14 구성보다 토큰 생성과 문맥 압축이 약 두 배 빠르며, 메모리 사용량도 더 낮다고 한다. 실행 스크립트는 llama-server 경로, 모델 파일 경로, Vulkan 장치 번호, 서버 주소와 포트, 문맥 크기, 캐시 형식, 캐시 메모리, GPU 레이어 수, 스레드 수, 배치 크기를 환경변수로 바꿀 수 있게 만든다. 기본값은 로컬 접속용 127.0.0.1:8081, 문맥 262144, 캐시 형식 q4_0, 캐시 메모리 16384MB, GPU 레이어 99, 스레드 20, 배치 크기 512다. 실행하려면 Vulkan을 켠 llama.cpp 빌드, 정상 동작하는 Vulkan 드라이버, GGUF 모델 파일이 필요하다.
Qwen 3.5 4B를 Ollama에서 돌려 개인 일정과 프로젝트를 기록하는 로컬 비서로 쓰는 구성이다. 그래픽카드는 8GB VRAM이 있는 RTX 2070 Super이고, 시스템 메모리는 32GB다. 음성 입력에는 Whisper large-v3를 함께 올려 두며, 대화 창은 Telegram을 쓴다. Qwen 3.5 4B는 64k 문맥을 포함해 약 5GB를 쓰고 초당 약 68토큰을 낸다. Whisper가 약 2GB를 더 써서 8GB VRAM이 거의 꽉 차며, 이 때문에 더 큰 모델을 쓰기 어렵다. 핵심 문제는 작은 모델이 기록 작업에서 도구 호출을 빠뜨리거나 망가뜨리고, 저장하지 않았는데 저장했다고 말하며, “그거 완료 처리해”처럼 애매한 지시에서 엉뚱한 항목을 고른다는 점이다. Qwen 9B, 27B, 35B 계열도 시험했지만 8GB VRAM에 맞지 않아 시스템 메모리와 CPU로 밀려 느렸고, 애매한 참조를 더 잘 풀지도 못했다. Ollama 버전을 올리자 도구 호출 신뢰도가 약 55%에서 거의 100%로 좋아지고 가짜 완료 답변도 거의 사라졌으며, Qwen3는 /no_think를 붙이지 않으면 생각 과정에 토큰 예산을 써 버리고 빈 답을 낼 수 있다. 댓글 흐름에서는 작은 모델 자체보다 저장, 확인, 삭제 제한, 작업 공간 제한, 실제 성공·실패 결과 확인 같은 결정적 구조가 더 중요하다는 조언이 많았다.
복잡한 작업을 Claude에게 반복해서 시키면 답이 대충 나오거나 토큰 비용이 커질 수 있다. 이 방법은 먼저 작업 절차를 실행 지침서로 정리해 Claude가 따라야 할 순서를 분명하게 만든다. 그다음 Claude를 이용해 이 절차를 파이썬 스크립트로 바꾼다. 반복 실행은 스크립트가 맡고, Claude는 실행 과정을 살피는 감독자 역할을 한다. 실행 결과는 나중에 다시 찾아 쓸 수 있는 검색 증강 생성 자료로 쌓는다. 핵심은 Claude가 모든 일을 매번 직접 처리하지 않게 하고, 반복되는 부분을 코드와 지식 저장소로 옮겨 비용과 품질 문제를 줄이는 것이다.
Claude를 중심에 두고 개인용 AI 운영체제처럼 쓰는 구성이다. 금융, 법률, 건강 같은 흩어진 개인 데이터를 직접 만든 백엔드와 REST API로 한곳에 연결한다. 핵심은 데이터를 모으는 데서 끝나지 않고, Claude가 어떤 자료를 봤고 어떤 가정을 했으며 어떤 단계를 거쳐 답을 냈는지 확인할 수 있게 만드는 것이다. 이런 감사 추적은 그럴듯하지만 틀린 답을 그대로 믿고 중요한 개인 또는 업무 결정을 내리는 위험을 줄인다. 여러 자료가 섞이면서 AI의 답이 원래 맥락에서 벗어나는 컨텍스트 드리프트 문제도 줄이는 데 초점이 있다. 난도는 높은 편이며, 품질 관리, 토큰 절약, 컨텍스트와 메모리 관리, 디버깅, 다중 에이전트 구성과 관련된다.
Recall은 Claude Code를 쓸 때 매번 프로젝트 상황을 다시 설명하는 일을 줄이기 위한 로컬 메모리 도구다. 작업 내용은 프로젝트 안의 `.recall/history.md`에 쌓이고, 다음 세션에서 바로 이어갈 수 있도록 `.recall/context.md`에 짧은 요약이 만들어진다. 세션이 시작되면 저장된 내용을 이어서 쓸지, 이번 세션도 기록할지 묻는다. 사용자는 `/recall:save` 명령으로 요약을 만들 수 있고, 설정을 켜면 세션이 끝날 때 자동으로 다시 만들 수도 있다. 요약에는 목표, 진행 상황, 다음 단계, 만진 파일, 실행한 명령, 깃 변경 요약 같은 정보가 들어간다. 별도 설치나 API 키가 필요 없고, 외부 모델 호출도 하지 않으며, TF-IDF와 TextRank라는 로컬 요약 방식으로 문장을 고른다. 그래서 메모리를 만들 때 추가 토큰 비용이 들지 않고, 다음 세션에 1천~2천 토큰 정도의 짧은 문맥만 넣어 시작할 수 있다. 보안 쪽에서는 흔한 비밀값을 지우려는 처리, 프로젝트 밖으로 쓰기 방지, 안전한 깃 읽기 설정을 제공하지만, `.recall` 파일을 커밋하기 전에는 직접 확인해야 한다.
직접 만든 약 100개 작업으로 여러 인공지능 모델이 특정 좁은 분야에서 얼마나 잘하는지 비교하려는 상황이다. 로컬 모델은 간단한 파이썬 스크립트로 각 작업을 새 세션에 넣고 결과를 폴더별로 저장하면 비용 부담 없이 테스트할 수 있다. 문제는 OpenAI, Anthropic, Google 같은 비공개 모델이다. API로 넓은 범위의 모델과 설정을 시험하면 비용이 커질 수 있고, 사람이 직접 웹 화면에서 반복 테스트하기에는 시간이 너무 많이 든다. 대안으로 Codex Exec이나 Claude -p처럼 정액 구독에 포함된 도구를 써서 API 비용을 피하는 방법이 검토되고 있다. 다만 이런 방식은 다른 모델의 답변이나 평가 기준이 들어 있는 파일을 읽지 못하게 샌드박스가 필요하다. 또 더 싼 에이전트가 화면을 보고 질문과 답을 웹 화면에 복사해 넣는 방식도 생각해 볼 수 있다.
작은 AI 모델은 여러 조각의 자료를 받아 긴 원인과 결과 흐름을 스스로 찾아내는 일을 잘 못할 수 있다. 이 방식은 자료를 넣을 때 원인과 결과 관계를 먼저 뽑아 방향 그래프로 저장한다. 질문이 들어오면 단순한 문서 조각 대신, 이미 이어진 원인 흐름을 찾아 모델에 넘긴다. 그래서 모델은 처음부터 추론을 만들기보다, 제시된 흐름이 맞는지 확인하고 쉽게 풀어 설명하는 역할을 한다. 54개 질문 실험에서 Claude Haiku로 답을 만들었고, 여러 단계를 거치는 질문은 기존 평면 RAG 방식의 0.41에서 0.74로 올랐다. 근본 원인 질문은 0.37에서 0.59로 올랐고, 단순 사실 찾기는 거의 차이가 없었다. 질문할 때 추가 AI 호출을 쓰지 않고 알고리즘으로만 찾기 때문에 응답 지연도 낮게 유지된다는 점이 핵심이다. /rootcause와 /impact 같은 REST API도 제공된다.
Forsy-AI의 agent-apprenticeship은 AI 에이전트가 실제 작업을 반복하면서 배운 내용을 다시 쓰도록 설계된 오픈소스 생태계다. 핵심은 한 번의 작업 결과를 버리지 않고, 반복되는 업무 흐름과 경험을 다음 작업에 활용하는 것이다. 관련 흐름도 비슷한 방향으로 움직인다. Macro는 이메일, 채팅, 업무, 문서, 고객 관리, 에이전트를 한 화면에 묶고 공유 메모리로 연결하려 한다. Eve와 Zkit은 에이전트를 만들기 위한 틀이나 라이브러리 쪽에 가깝다. 또 다른 실험에서는 Claude가 작업을 조율하고 Codex가 코드를 작성하는 반복 루프가 몇 주 동안 연구개발 업무를 돌렸고, 한 기능은 사람이 코드를 고치지 않은 채 약 1,400줄의 Rust 변경으로 병합됐다. AGENTOWNERS는 AI 에이전트가 어떤 파일을 고칠 수 있고, 어떤 행동은 사람 승인이 필요한지 정하는 규칙을 제안한다.
FaultLine은 이전에 PostgreSQL 기반 데이터베이스 중심으로 작동한다고 소개됐지만, 실제 구현은 그 설명과 달랐다. 개발 과정에서 확인해야 할 신호를 놓쳤고, 문서와 파이프라인도 원래 의도와 맞지 않는 상태였다. 사실 데이터는 PostgreSQL에만 질서 있게 보관되는 것이 아니라, 조용히 벡터 저장소로 들어가 검색에 쓰이고 있었다. PostgreSQL이 일부 뒤에서 받쳐 주고 있더라도, 공개적으로 말한 “데이터베이스 중심” 구조라고 보기는 어렵다. 벡터 저장소는 완전히 없애는 대상이 아니라, 근거와 신뢰도를 제대로 잡지 못할 때 짧게 보관하는 보조 수단으로 남는다는 입장이다.
에이전트의 메모리 관리에서 잊을 정보 고르기, 서로 맞지 않는 사실을 믿을 시점 정하기, 신뢰가 깨진 출처를 빨리 낮추기, 여러 답안 후보 중 몇 개를 비교할지 정하기는 서로 다른 문제가 아니다. 모두 새 정보 하나를 얼마나 빨리 믿을지의 문제다. 너무 빨리 갱신하면 한 번의 나쁜 입력만으로 메모리가 뒤집힌다. 너무 느리게 갱신하면 실제로 상황이 바뀌었을 때 뒤처진다. 어떤 값이 갑자기 달라진 첫 순간에는 단순한 오류인지 진짜 변화의 시작인지 바로 구분할 수 없다. 그래서 한 번의 입력으로 판단하지 말고, 비슷한 변화가 몇 번 이어지는지 확인한 뒤 메모리를 바꾸는 방식이 더 안정적이다. 실제로 16개의 전문가 라벨 데이터 흐름으로 비교했을 때, 오래 이어지는 변화에서는 이런 지속성 기반 감지가 단순한 한 지점 판단보다 항상 이기거나 같았다. 한 서버 설정 오류 사례에서는 같은 재현율에서 단순 규칙이 1181번의 잘못된 경고를 냈지만 지속성 기반 방식은 0번이었다. 다만 짧게 튀는 일시적 이상값만 잡아야 할 때는 단순 규칙이 더 나을 수 있다.
rewardspy는 강화학습 학습 중 보상 점수가 오를 때 실제 성능이 좋아지는지, 아니면 보상 함수의 빈틈을 이용하는지 확인하는 작은 도구다. 기존 보상 함수를 감싸서 쓰며, 학습이 진행되는 동안 보상 해킹의 초기 신호를 계속 살핀다. 확인 항목에는 최근 보상 통계, 보상 변동 폭이 갑자기 줄어드는 현상, 보상 구성 요소가 한쪽으로 치우치는 현상, 답변 길이가 달라지는 흐름, 보상 증가 기울기 변화, GRPO 그룹 붕괴 등이 포함된다. 만든 사람은 GRPO 학습을 실험하다가 보상 점수 상승만으로는 정책이 정말 개선되는지 판단하기 어렵다는 문제를 겪었다. 아직 첫 주요 강화학습 프로젝트에 가까운 초기 라이브러리이며, 기술 조언을 받고 있다.
고객 문의를 약 여섯 가지로 나눠 담당자에게 보내는 AI 에이전트가 있었다. 처음에는 거대 언어 모델(LLM)이 문의 내용을 읽고 분류했지만, 일주일에 한두 번 정도 잘못된 곳으로 보내는 문제가 생겼다. 모델이 확신한 것처럼 보였기 때문에 사람이 바로 알아차리지 못했고, 문의가 엉뚱한 대기열에 오래 남는 일이 있었다. 실제 문의를 살펴보니 대부분은 “환불”, “중단”, “청구서” 같은 뚜렷한 단어 한두 개만 봐도 분류할 수 있었다. 그래서 자주 나오는 쉬운 경우는 간단한 조건문 규칙으로 처리하고, 아무 규칙에도 걸리지 않는 애매한 경우만 LLM에 맡겼다. 그 결과 잘못 보내는 일이 줄었고, 비용도 낮아졌으며, 왜 특정 문의가 그 담당자에게 갔는지도 설명할 수 있게 됐다.
개인용 컴퓨터에서 AI 모델을 돌릴 때는 모델 크기와 양자화 수준에 따라 필요한 메모리가 크게 달라진다. Q4는 대부분의 개인 사용자에게 가장 현실적인 출발점이다. Q8보다 필요한 메모리를 거의 절반으로 줄이면서도, 코딩, 역할극, 구조화된 출력 같은 일반 작업에서는 품질 차이를 알아차리기 어렵다. Q8은 작은 오류가 이어져 큰 문제가 되는 정밀한 데이터 추출처럼 출력의 정확도가 아주 중요한 경우에만 더 적합하다. Q2는 숫자만 보면 메모리를 더 아낄 수 있어 끌리지만, 한 단계 이상 생각해야 하는 작업에서는 답변 품질이 뚜렷하게 떨어진다. 7B 모델을 Q4로 돌리면 약 4GB가 필요해, 8GB 메모리 기기에서 쓰기 좋은 기준점이 된다.
rabbithole은 텍스트를 선택하고 질문하면 답변이 새로운 문서로 가지처럼 뻗어나가는 무한 캔버스 형태의 학습 도구입니다. 하나의 주제를 파고들 때 원문에서 궁금한 부분을 골라 질문하면, 그 답이 별도의 문서로 분리되어 캔버스 위에 트리 구조로 쌓이는 방식입니다. 이 프로젝트는 MCP(모델 컨텍스트 프로토콜) 서버를 함께 제공해서, Claude Code나 Codex 같은 코딩 에이전트뿐 아니라 MCP를 지원하는 어떤 AI 에이전트에서도 이 캔버스 기능을 도구로 불러 쓸 수 있게 만들었습니다.