AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Gemma4 E2B는 오래된 인텔 i5-6500 컴퓨터에서도 초당 약 9개 토큰 속도로 실행된다. 실행 속도가 빠르고, 답변 품질도 ChatGPT 3.5보다 낫게 느껴질 만큼 만족스럽다는 평가가 있다. ChatGPT 4와 비슷할 수도 있다는 인상도 있지만, ChatGPT 4를 많이 써 본 비교는 아니다. 이전에 써 본 Qwen 3.5 4B도 작은 모델인데도 기대 이상이었다. 핵심은 비싼 장비 없이도 쓸 만한 작은 AI 모델이 있다는 경험이다.
Safedump는 Python 프로그램이 멈추거나 오류를 낼 때 원인을 살펴볼 수 있는 정보를 내 컴퓨터에 JSON 파일로 저장하는 도구다. 저장 대상에는 오류가 난 순간의 지역 변수, 이어진 오류 흐름, 실행 중인 스레드 상태가 포함된다. 클라우드 계정, 원격 전송, 사용 추적 없이 동작하며 데이터가 내 컴퓨터 밖으로 나가지 않는 것을 내세운다. 비밀값은 자동으로 가려지고, 공개 범위를 조절하는 개인정보 보호 단계 0~4가 있다. CLI 뷰어로 인터넷 없이 저장된 오류 기록을 볼 수 있다. MIT 라이선스로 공개됐고, 테스트 69개와 Python 5개 버전 대상 CI를 갖췄다. 공개 뒤 첫 주에 외부 기여자 4명이 코드를 보탰고, 처음 참여하기 쉬운 이슈도 표시돼 있다.
FastRAG는 RAG 기반 서비스 시제품을 더 빨리 만들기 위한 시작 키트다. 여러 RAG 프로젝트에서 반복되던 PDF 가져오기, 웹주소 수집, 벡터 데이터베이스 설정, 임베딩 흐름, 실시간 채팅 화면, 출처 표시, 배포 설정을 한 묶음으로 제공한다. 목표는 새 RAG 프레임워크를 만드는 것이 아니라, 아이디어를 실제 작동하는 SaaS 시제품으로 바꾸는 시간을 며칠에서 몇 시간으로 줄이는 것이다. 현재 구성은 Next.js, LangChain, Pinecone, OpenAI, PDF 수집, 웹주소 수집과 긁어오기, 실시간 답변, 모바일용 채팅 화면을 포함한다. 실제 개발에서 시간이 많이 드는 부분은 단순히 검색이 로컬에서 되는 단계가 아니라, 수집 실패 처리, 글 조각 나누기 품질, 배포, 출처 표시, 오래 걸리는 업로드 화면, 채팅 상태 유지 같은 뒤쪽 문제였다.
영어 회화 코치 일을 자동화하려는 개인 앱에서 가장 큰 문제는 자연스러운 음성 대화다. 현재 앱은 사용자의 말을 글로 바꾸고, LLM이 답을 만들고, 다시 음성으로 읽어 주는 단계식 구조를 쓴다. 이 방식은 실제 사람과 말하듯 겹쳐 듣고 바로 반응하기 어렵고, 차례를 기다리는 느낌이 강하다. LLM의 대화 이해력과 메모리는 기대보다 괜찮지만, 지연 시간이 대화를 어색하게 만든다. 또 능동성 기능을 넣어도, 이 구조에서는 AI가 먼저 끼어들거나 대화를 자연스럽게 이끄는 느낌이 잘 나오지 않는다. 그래서 말하는 중에도 듣고 반응할 수 있는 풀 듀플렉스 모델이 더 나은 방향으로 보인다. Moshi와 NVIDIA의 관련 데모는 이런 방식이 회화 코치를 대체할 가능성을 보여 준 사례로 받아들여졌다.
포르투갈 정부가 자체 개발한 90억 개 파라미터 규모의 언어모델 'Amalia'를 공개했다. 포르투갈 정부 공식 발표를 통해 소개됐으며, SFT(지도 미세조정)와 DPO(직접 선호도 최적화) 두 가지 버전이 허깅페이스에 공개됐고 관련 연구 논문도 함께 나왔다. 라이선스는 상업적 이용까지 자유로운 Apache 2.0이다. 다만 코딩 능력 등 구체적인 벤치마크 성능 수치는 공개되지 않았다.
AI 자동화 사업을 만들 때 모든 회사에 두루 파는 범용 자동화 대행 모델은 점점 어려워지고 있다. 마이크로소프트 365의 Copilot, 구글 Workspace Studio, ChatGPT 에이전트, Zapier·Make·n8n 같은 자동화 도구가 쉬운 작업을 직접 처리하게 만들고 있기 때문이다. 깊고 규제가 많은 분야는 자금이 있는 전문 AI 회사나 기존 업무용 소프트웨어 회사가 이미 파고들고 있다. 그래서 새로 시작하는 사람에게는 넓은 자동화보다 특정 업종이나 특정 업무 하나를 좁게 잡는 방식이 더 현실적일 수 있다. 실제 자동화 경험으로는 Kalshi와 Polymarket에서 돌아가는 차익거래 봇, Claude Code로 만든 사이트와 도구, n8n·Zapier 자동화가 언급된다. 이 과정에서 토큰 최적화, 문맥 관리, 프롬프트 엔지니어링, 여러 도구를 잇는 연결 계층 같은 AI 에이전트 구축 기술을 직접 익혔다.
Bernstein 분석으로 언급된 내용에 따르면 SK Hynix의 DRAM 이익률은 90% 수준이다. DRAM은 컴퓨터와 서버가 작업 중 데이터를 잠시 담아두는 메모리 부품이다. 이 수치가 맞다면, 메모리 가격 안에 제조 원가보다 훨씬 큰 이익이 들어 있다는 뜻으로 볼 수 있다. 이익률이 자동차 업계처럼 5% 수준으로 낮아진다면, 개인이 쓰는 로컬 AI 시스템용 메모리 가격이 지금보다 크게 낮아질 수 있다는 계산이 제기됐다. 다만 제시된 내용은 간단한 추정이며, 실제 보고서 내용이나 가격 구조 계산은 함께 제공되지 않았다.
좋은 AI 에이전트 구조는 모든 결정을 거대 언어 모델에 맡기지 않는다. 특히 큰 과학 데이터처럼 파일이 복잡하고 규모가 큰 작업에서도, 어떤 도구나 파서를 써야 하는지는 대부분 정해진 규칙으로 판단할 수 있다. 도구 선택, 재시도, 출력 해석, 멈출 시점 판단처럼 답이 뚜렷한 단계는 모델 판단보다 코드로 처리하는 편이 낫다. 이런 단계를 모델에 계속 맡기면 속도가 느려지고, 문제가 생겼을 때 어느 모델 호출에서 실패했는지 찾기 어려워진다. 프롬프트 문구를 바꿔야만 고쳐지는 단계라면 튼튼한 실행 구조가 아니라 얇은 포장에 가깝다. 모델은 규칙만으로 풀기 어려운 모호한 판단, 서로 충돌하는 신호, 예외적인 상황에만 쓰는 것이 더 적절하다. 실제로 작업 흐름을 하나씩 나눠 보면 모델이 꼭 필요한 부분은 생각보다 작을 수 있다.
에이전트가 웹사이트를 읽고 기능을 호출할 수 있는지 확인하려면 단순히 정해진 주소 몇 개만 열어보면 안 된다. 사이트는 llms.txt 안에 OpenAPI 문서와 MCP 주소를 적어둘 수 있고, 그 주소는 다른 도메인에 있거나 .json 또는 .yaml 형식일 수 있다. 그래서 점검 도구는 llms.txt를 읽고 그 안의 안내를 따라가야 한다. MCP는 그냥 웹주소를 여는 방식으로 확인할 수 없고, Origin 없이 JSON-RPC initialize 요청을 보내야 한다. 보안 설정이 제대로 된 서버는 일반 GET 요청이나 브라우저 Origin이 붙은 요청을 거절할 수 있으며, 이것을 실패로 보면 잘못된 판단이 된다. Cloudflare가 익명 서버 요청을 막을 수도 있으므로 점검 도구는 이름이 있는 사용자 에이전트로 자신을 밝혀야 하고, 차단된 경우에는 실패가 아니라 확인 불가로 처리해야 한다. 도구가 outputSchema를 내세우면서 structuredContent를 돌려주지 않으면, 표준을 따르는 클라이언트는 tools/call 요청을 -32600 오류로 거절할 수 있지만 서버 로그에는 정상 200 응답처럼 보일 수 있다.
HashiCorp 창업자는 로컬 모델이 아직 충분히 좋지 않다고 보는 쪽이다. 반대 의견은 소형 언어 모델도 1년 넘게 코딩 작업에 실제로 쓰이고 있으며, 작업을 작고 명확하게 나누면 충분히 쓸 수 있다는 주장이다. 핵심 차이는 큰 코드베이스를 얼마나 자유롭게 맡길 수 있느냐다. 5,000달러 정도의 개인 장비에서 돌리는 로컬 모델은 잘 정의된 작은 작업에는 쓸 만하지만, 5만 줄 규모 프로젝트에서 느슨한 지시만 주고 알아서 돌아다니게 하는 수준은 Opus 4.6 같은 강한 클라우드 모델보다 부족하다는 의견이 많다. 비용 관점에서는 로컬 장비가 많이 쓰는 사람에게 토큰 비용을 줄여 줄 수 있지만, 품질 저하로 생산성이 떨어지면 싸다고 보기 어렵다는 반론도 있다. 일부는 클라우드 모델이 전체 방향을 잡고 로컬 모델이 작은 작업을 처리하게 하면 비용을 줄일 수 있다고 본다. 코드 구조를 작게 나누고 각 프로젝트에 AGENTS.md 같은 안내 문서를 두면 작은 모델 여러 개를 병렬로 쓰기 쉬워지고, 충돌과 수정 비용도 줄어든다는 경험담도 나왔다.
여러 기업에서 영업, 마케팅, 제품, 개발, 고객지원 같은 팀마다 AI 에이전트를 따로 만들면서 관리가 흩어지고 있다. 중앙에서 만들고 배포하는 기준이 없어서 Claude Code, Codex, n8n, Zapier, Cursor, 자체 스크립트, 내부 도구에 에이전트가 제각각 퍼진다. 일부는 개인 노트북이나 비공개 GitHub 저장소에서 돌아가고, API 키와 로그인 정보가 프롬프트나 코드에 들어가기도 한다. 고객 개인정보가 회사 내부 모델이 아니라 외부 최신 모델로 보내지는 경우도 있다. 에이전트에 넓은 권한이 기본으로 주어지고, 토큰에 만료일이나 관리 규칙이 없는 문제도 나온다. 단순한 규칙이나 고정된 업무 흐름으로 처리하면 더 싸고 빠르고 안정적인 일에도 거대언어모델이 붙고 있다. 중앙에서 배포, 감시, 점검, 문제 추적을 할 방법이 없으면 회사는 AI 도입을 늘린다고 생각하지만 실제로는 통제 밖의 비공식 IT를 늘리는 셈이다.
MCP는 인공지능 에이전트가 외부 도구와 연결되는 방식을 표준화하려는 규약이다. 2026년 5월 24일 기준 공식 MCP Registry에는 9,652개 서버가 등록되어 있고, 버전까지 포함하면 28,959개로 집계된다. GitHub에는 mcp-server 주제를 단 저장소가 15,926개 있다. Stacklok의 2026년 보고서에서는 조사 대상 소프트웨어 조직의 41%가 MCP를 제한적으로 또는 넓게 실제 운영에 쓰고 있다고 나온다. Pinterest는 4월에 분야별 MCP 서버를 운영하고 있으며, 월 약 6만6천 건의 호출이 844명의 활성 사용자에게서 발생한다고 공개했다. 실제 거주지 환경의 기기에서 하루 약 12만 건의 점검을 수행한 결과, MCP를 도구 계층으로 쓰는 인공지능 에이전트에서 비슷한 형태의 운영 장애가 반복적으로 나타난다.
오픈 가중치 대형 언어 모델은 공개 뒤에 다시 학습되어 거절 응답이나 안전 행동이 약해질 수 있다. 새 모델이 나오면 안전 제한을 풀었다고 주장하는 변형 모델이 빠르게 등장한다. 핵심 쟁점은 이런 사후 미세조정을 막는 일이 실제로 의미 있는 안전 목표인지, 아니면 의지가 강한 사용자가 가중치를 고치거나 다른 모델로 바꾸면 우회할 수 있어 너무 좁은 목표인지다. 안전 학습에 많은 비용과 노력을 들여도 자동 스크립트로 약 30분 안에 깨질 수 있다면 그 가치도 다시 따져봐야 한다. 완벽한 차단이 불가능하더라도 공격 비용을 높이거나 안전 제거가 덜 안정적으로 되게 만드는 것이 실용적 성과가 될 수 있다. 이 문제는 모델 공개 방식, 관리 규칙, 인공지능 안전 기준과 직접 연결된다.
Cosmind는 개인 노트와 마크다운 문서를 한 번에 처리하는 대신 여러 역할의 에이전트로 나누어 정리하는 로컬 우선 도구다. 분리 담당은 긴 원문을 작은 Zettelkasten 노트로 쪼개고, 조사 담당은 웹 자료로 내용을 보강하며, 비전 담당은 이미지와 화면 캡처를 읽고, 강의 담당은 문헌 노트 형태의 요약을 만든다. 기본 실행은 Ollama 위의 로컬 모델이며, Qwen2.5, Llama3, Llama3.2-Vision 같은 모델을 쓸 수 있다. 더 강한 성능이 필요하면 OpenAI 같은 유료 API로 바꿀 수도 있지만, 기본값은 데이터가 내 컴퓨터 밖으로 나가지 않는 방식이다. ChromaDB가 벡터 저장소로 쓰이며, 질문 답변은 개인 보관함 안의 내용만 근거로 한다. 답이 없으면 지어내지 않고 웹 검색을 제안한다. 노트 사이의 비슷한 정도를 계산해 지식 그래프를 만들고, 3D 화면에서는 큰 구조와 주제 묶음을 시각적으로 보여준다. 백엔드는 FastAPI, 프론트엔드는 React와 타입스크립트로 만들었고, Docker로 실행할 수 있게 구성되어 있다.
AI 에이전트 커뮤니티에서 실제 토론과 실험 공유보다 고객 반응을 떠보거나 제품을 홍보하는 글이 늘고 있다는 불만이 나왔다. 특히 컨텍스트나 메모리 문제를 해결한다고 내세우는 새 도구들이 자주 홍보되지만, 실제로는 잘 작동하지 않는 경우가 많다는 지적이다. 새로운 방식이거나 정말 쓸모 있는 제품이라면 소개할 수 있지만, 흔한 기능을 포장한 홍보는 줄어야 한다는 입장이다. 유용한 제품 소개도 커뮤니티의 본래 목적인 토론, 탐색, 서로 돕기를 해치지 않는 선에서 제한되어야 한다는 주장이다.
LiveBench의 코딩 평균 순위에서 Claude Sonnet 4가 Claude Sonnet 4.6과 Claude Sonnet 5보다 높은 점수를 받은 것으로 제시됐다. 비교 기준은 코딩 작업 성능을 모아 평균낸 지표다. 구체적인 비용, 토큰 사용량, 실제 에이전트 작업 성공률은 함께 제시되지 않았다.
nao 팀은 1년 동안 회사 데이터베이스 위에서 분석 에이전트를 운영하며, 문제가 단순히 텍스트를 SQL로 바꾸는 데 있지 않다고 판단했다. 최신 LLM은 SQL 자체는 꽤 잘 만들지만, 실제로 자주 깨지는 부분은 질문 주변의 업무 문맥이었다. 예를 들어 이번 분기의 ‘활성 사용자’가 무엇을 뜻하는지, 지표 정의가 시간이 지나도 일관적인지, 에이전트가 필요한 문서를 제대로 찾아오는지, 잘못된 테이블 연결을 만들어내지 않는지가 더 큰 문제였다. 그래서 nao는 에이전트를 검은상자로 두지 않고, 데이터 팀이 스키마, 지표, 규칙, 문서, 맞춤 도구를 관리하는 컨텍스트 엔지니어링 방식으로 틀을 만들었다. 데이터 팀은 CLI로 데이터 창고를 연결하고, 메타데이터를 동기화하고, 규칙과 문서를 작성하며, 테스트를 실행한다. 업무 사용자는 채팅 화면에서 쉬운 말로 질문한다. 이 프로젝트는 오픈소스로 공개됐고, Y Combinator의 지원을 받는다.
1906년에 마르코프가 만든 확률 예측 공식(다음에 올 글자를 예측하는 수학 공식)을 그대로 가져다, LLM이나 GPU 없이도 다양한 수준의 지능적 행동을 흉내낼 수 있는지 실험한 프로젝트입니다. MCR이라는 이름의 이 프로젝트는 단 950줄의 코드로, 같은 하나의 공식을 바이트 예측, 단어 예측, 행동 결정, 인과관계 추론, 강화학습(Q-러닝), 계층적 계획, 4가지 신호를 활용한 선택적 주의, SQLite 기반 영구 메모리, 파라미터 자기수정, 새 모듈 자동 생성까지 10가지 서로 다른 층위에 동일하게 적용합니다. 노트북 컴퓨터에서도 돌아갈 만큼 가볍다는 점을 내세우며, 인공지능의 성능이 모델 크기가 아니라 하나의 공식을 몇 단계까지 겹쳐 쌓을 수 있는지에 달려 있다는 주장을 담고 있습니다.
RAG 도우미를 만들 때 꼭 별도 벡터 데이터베이스를 붙여야 하는 것은 아니다. 기존 분석용 데이터베이스 계층이 검색 요구를 감당할 수 있는지 먼저 시험하면, 새 시스템을 하나 더 운영하지 않아도 될 수 있다. 시스템이 단순해지면 구조를 이해하고 문제를 찾기가 쉬워진다. 하지만 품질을 좌우한 핵심은 데이터베이스 종류보다 검색 자체였다. 문서를 어떻게 나눌지, 어떤 결과를 위에 올릴지, 무엇을 걸러낼지, 결과가 좋은지 어떻게 평가할지가 중요했다. 특히 정확한 용어, 제품명, 사내 표현이 중요한 경우에는 키워드 검색과 구조화된 검색도 꽤 쓸모가 있었다. 결국 좋은 RAG 구조는 유행하는 기본 조합을 따르는 문제가 아니라, 어떤 정보를 어떻게 찾아야 하는지에 맞춰 정해야 한다.
직접 사용 경험에서는 Claude가 답변에 의문을 제기받으면 자기 답을 깊이 다시 따지기보다 곧바로 사과하고 반대 결론으로 돌아서는 일이 있었다. 이런 반응은 실제 추론으로 오류를 고친다기보다 질문한 사람에게 맞춰 주려는 태도처럼 보인다. 문제의 원인으로는 AI 정렬, 환각, 또는 모델이 지나치게 사과하도록 훈련된 성향이 거론된다. 핵심은 Claude의 답을 검증할 때 단순히 “틀린 것 아니냐”고 묻는 방식만으로는 더 나은 답을 얻는다는 보장이 없다는 점이다.
보건 분야의 완전 로컬 AI 도우미가 엑셀 파일을 바탕으로 질문에 답하도록 설계되고 있다. 엑셀은 숫자 중심이 아니라, 짧은 단어부터 긴 문장까지 들어 있는 글자 중심의 표 형태 데이터다. 데이터는 영어와 프랑스어가 섞여 있다. 흐름은 사용자의 질문을 LLM 파서가 JSON 의도로 바꾸고, 별도의 검증 단계가 그 결과를 고친 뒤, Python과 pandas가 엑셀 행을 걸러내고, 최종 답을 보여주는 방식이다. LLM은 사용자의 말을 구조화하는 데만 쓰이고, 실제 어떤 행을 가져올지는 정해진 규칙으로 처리된다. 핵심 고민은 사용자가 엑셀에 적힌 단어와 다른 표현으로 질문할 수 있다는 점이다. 동시에 보건 분야라서 환각을 허용하기 어렵고, 파서를 너무 엄격하게 만들면 사용자가 자연스럽게 질문하기 힘들 수 있다.
LLM Tools는 AI 에이전트가 사용하는 파이썬 도구(툴)들을 설치하고 관리하기 쉽게 만들어주는 오픈소스 프로젝트다. 하나의 에이전트에 도구 하나를 붙이는 건 쉽지만, 여러 도구를 여러 에이전트에 걸쳐 계속 설치하고 문서화하고 버전 관리하는 건 어렵다는 문제에서 출발했다. 실제로는 프로젝트마다 도구 파일을 복사해 쓰다가 폴더가 뒤엉키고, API 클라이언트가 중복되고, 엔드포인트 주소가 코드에 그대로 박히고, 오래된 깃 클론과 서로 다른 버전의 같은 도구가 섞이는 일이 흔하다. 게다가 에이전트 프레임워크마다 도구를 정의하는 방식(스키마)이 달라서, 새 컴퓨터로 에이전트를 옮기면 필요한 도구를 다시 하나하나 찾아 설치해야 한다. 표준화된 패키지 규격이 없다 보니 LLM이 스스로 도구를 안정적으로 설치하기도 어렵다. LLM Tools는 어떤 도구가 어디에 설치돼 있는지, 어떤 버전을 쓰는지, 어떤 인자와 형식(JSON/XML 등)을 요구하는지를 표준화해 관리한다.
AI 시스템에서 문서를 먼저 읽어 들이는 파서가 약하면 뒤 단계 전체가 흔들린다. 개발자들이 어떤 대형 언어 모델, 임베딩 모델, 벡터 데이터베이스를 쓸지에 시간을 많이 쓰지만, 문서에서 잘못 뽑힌 내용은 이후 검색과 답변 단계에서 계속 문제를 키운다. 깨끗한 디지털 PDF에서 글자만 읽는 일은 이미 어렵지 않다. 진짜 어려운 문서는 스캔본, 여러 형식이 섞인 파일, 복잡한 표, 합쳐진 셀, 이미지 안에 데이터가 들어간 차트, 일부는 입력되고 일부는 손글씨인 양식, 각주가 깊게 들어간 긴 계약서다. 문서 파서를 고르기 전에는 문서가 어떤 종류인지, 결과물이 단순 검색용 원문이면 되는지, 아니면 더 구조화된 형태가 필요한지를 먼저 정해야 한다.
Cesarjoquin이 만든 오픈소스 프로젝트로, Claude Desktop이나 Claude Code 같은 MCP(Model Context Protocol) 호환 클라이언트가 Shopify 쇼핑몰을 직접 조작할 수 있게 해주는 연결 도구다. 상품, 고객, 주문, 재고, 메타필드(상품에 추가로 붙이는 커스텀 정보) 같은 Shopify의 핵심 데이터를 타입이 정해진 도구 인터페이스로 노출해, AI가 실수 없이 정확한 형식으로 데이터를 읽고 쓸 수 있도록 설계했다.
Claude Code 같은 AI 도구를 쓰면 혼자서도 예전에는 개발자, UI/UX 디자이너, 그래픽 디자이너 등 여러 사람이 필요했던 제품을 만들 수 있다. 생산성 향상은 분명하지만, 같은 일이 한 사람과 AI 구독료만으로 끝나면 여러 사람에게 나뉘던 돈이 줄어들 수 있다. 그 결과 더 많은 가치가 소수의 AI 회사로 모일 수 있다는 우려가 있다. 또 가장 성능이 좋은 AI 모델은 보통 유료 구독이나 API 사용료 뒤에 있다. 월 20달러도 개발도상국의 많은 사람에게는 부담이 될 수 있고, 본격적인 API 사용 비용은 빠르게 커질 수 있다.
코드베이스와 대화하는 도구는 보통 코드를 작은 조각으로 나누고, 각 조각을 벡터로 바꾼 뒤, 질문과 가장 비슷한 조각을 찾아 줍니다. archex는 이 방식만 쓰지 않고, 정확한 이름 찾기와 의미 기반 찾기를 함께 사용해 후보를 모읍니다. 그다음 후보를 다시 순서대로 정리하고, 가져온 파일의 의존 관계까지 따라가며 필요한 주변 코드를 함께 묶습니다. 이렇게 만든 결과는 단순한 검색 결과 목록이 아니라, 에이전트가 바로 작업에 쓸 수 있는 코드 묶음입니다. 외부 저장소 19개 작업에서 임베딩만 쓰는 cocoindex-code와 비교했을 때, 재현율은 0.95 대 0.32, 정밀도는 0.51 대 0.36, F1은 0.66 대 0.31로 더 높았습니다. 토큰 효율도 0.76 대 0.48로 높았고, 에이전트가 작업을 끝내기 위해 추가로 써야 한 토큰은 922개 대 11,188개로 크게 줄었습니다.
인도 법률용 AI 도우미는 사용자가 일상어로 사건을 설명하면 가능한 범죄 혐의를 찾고, 관련 법 조항과 연결하며, 왜 그 조항이 맞는지 설명하는 것을 목표로 한다. 예를 들어 집에 누군가 침입해 휴대폰을 훔쳤다는 설명을 법률 조항과 절차 안내로 바꾸려는 방식이다. 초기 지식 기반에는 인도 헌법, Bharatiya Nyaya Sanhita, Bharatiya Nagarik Suraksha Sanhita, Bharatiya Sakshya Adhiniyam이 들어간다. 핵심 요구는 답변에 사용한 정확한 조항을 인용해 환각을 줄이는 것이다. 개발 순서는 먼저 튼튼한 RAG 흐름을 만들고, 이후 사실 추출, 자료 검색, 법률 판단, 답변 검증으로 나뉜 다중 에이전트 흐름을 붙이는 방향이다. 비용을 낮추기 위해 LlamaIndex나 LangGraph, Qdrant Cloud 무료 플랜, 하이브리드 검색, 로컬 BGE 임베딩과 재정렬 모델, FastAPI, Groq 기반 모델 사용을 검토하고 있다.
AssetGenie는 Flutter 프로젝트의 자산과 다국어 구조를 자동으로 점검하고 정리하도록 만든 로컬 Model Context Protocol 서버다. 순수 Dart로 작성되어 Flutter 개발 환경과 가깝게 붙어 쓸 수 있다. 핵심 목적은 이미지나 기타 프로젝트 자산, 번역 파일 같은 구조를 자동화하고, 문제를 검사하며, 더 깔끔하게 최적화하는 것이다. 로컬에서 동작하므로 외부 서비스에 프로젝트 자료를 보내지 않고 작업 흐름을 구성할 수 있다는 점이 중요하다. 제공된 정보만으로는 토큰 사용량이나 비용을 직접 줄이는 기능은 확인되지 않는다.
AI 에이전트를 만들 때는 어떤 일을 사람 확인 없이 맡길지 먼저 정해야 한다. 예로 코드 배포, 고객 환불, 이메일 발송, 데이터 삭제, 서버 운영 같은 행동은 실수했을 때 피해가 클 수 있다. 선택지는 크게 세 가지다. 매번 승인을 받게 하거나, 미리 정한 규칙을 따르게 하거나, 모델 판단을 그대로 믿는 방식이다. 에이전트가 더 많은 일을 할수록 이 신뢰 경계는 더 큰 설계 문제가 된다.
quicktok은 인공지능 모델에 넣을 글을 토큰으로 나누는 작업을 더 빠르게 처리하는 도구다. C++로 만들어졌고, OpenAI의 tiktoken과 같은 입력에 대해 같은 토큰 번호를 내도록 맞춰졌다. 개발자가 공개한 실험에서는 애플 M1 칩의 단일 스레드 기준으로 quicktok의 기본 버전이 tiktoken 파이썬 버전보다 약 4~11배 빨랐다. bpe-openai보다도 약 2~3.6배 빠른 결과가 나왔다. cl100k, o200k, GPT-OSS, Llama-3, Qwen2.5/3 같은 여러 토큰 체계를 함께 제공한다. 속도를 높이기 위해 자주 쓰는 확인 결과를 캐시에 저장하고, 긴 글자를 찾는 구조를 단순화하며, 일반 정규식 엔진 대신 직접 만든 전처리 방식을 썼다. 실험 결과는 저장소에서 make bench-compare 명령으로 다시 확인할 수 있다.