AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
개인 프로젝트인 ClawIndex는 문서를 찾을 때 단순히 비슷한 문장을 맞추는 대신, 색인을 한 번 추론하며 살펴보는 검색 방식이다. 임베딩이나 벡터 데이터베이스 없이 동작했고, 전체 실험은 자체 컴퓨터의 Qwen에서 실행되어 데이터가 밖으로 나가지 않았다. 700개 질문으로 비교했으며, 구성은 HotpotQA 500개, BEIR ArguAna 100개, BEIR SciDocs 100개였다. ClawIndex는 다섯 개 데이터 묶음 모두에서 NDCG@10 점수가 가장 높았고, HotpotQA 전체에서는 0.934를 기록했다. 여러 단서를 이어야 하는 다단계 질문에서는 0.920으로 FAISS의 0.837보다 높았다. HotpotQA 500개 중 51개는 예비 처리 경로를 썼지만, 모두 추적 가능한 유효 결과를 냈다. 단점도 뚜렷했다. FAISS는 두 BEIR 데이터셋에서 MRR@10 기준으로 더 좋았고, SciDocs 차이는 0.975 대 0.972라서 표본 100개 기준에서는 확실한 승리라고 보기 어렵다. HotpotQA도 더 어려운 전체 위키 설정이 아니라 방해 문서가 섞인 설정이어서, PRISM 같은 기존 연구와의 비교는 조건이 다를 수 있다. 가장 큰 문제는 속도다. ClawIndex는 질문 하나에 약 27초가 걸렸지만 FAISS는 약 7밀리초였다.
CSM은 opencode용 AI 코딩 보조 도구에 세션을 넘겨도 유지되는 메모리를 붙이는 GitHub 프로젝트다. 보통 AI 보조 도구는 새 대화를 시작하면 이전 결정, 프로젝트 상태, 선호 사항을 잊기 쉽지만, CSM은 선호, 배운 점, 결정, 작업 방식 지식을 계속 저장하게 한다. 새 세션이 시작될 때 정체성, 선호, 능력, 믿고 있는 사실, 제약, 진행 중인 목표, 작업 기록, 인수인계 상태를 담은 8단계 컨텍스트 블록을 만든다. 이를 통해 보조 도구가 처음부터 다시 묻는 대신 이전 작업 단계와 열린 문제를 이어받는 방식으로 동작한다. 공개 설명에는 실제 운영 환경에서 5만6천 개가 넘는 메모리를 다뤘다는 주장도 포함돼 있다. 목표는 AI 에이전트가 같은 실수를 반복하지 않고, 프로젝트 맥락을 더 오래 유지하게 만드는 것이다.
한 개발자가 만든 AI 에이전트가 누적 45,000명에게 서비스됐고, 메시지 750만 건, 호출 73만5천 건을 처리했다. 이 규모로 운영하며 얻은 교훈은 다음과 같다. 첫째, 실제 대화 로그를 직접 읽는 것은 대체 불가능하다. 로그는 익명 처리해서 보는데, 실제 사용자들은 테스트나 평가(evals)로는 절대 발견할 수 없는 수많은 케이스를 만들어내기 때문에, 로그를 읽어야 무엇을 고치고 무엇을 추가하고 무엇을 그냥 둘지 판단할 수 있다. 둘째, 에이전트를 관리하는 일은 사람을 관리하는 것과 매우 비슷하다. 응답이 뜸해진 사용자에게 다시 연락하기, 특정 요청을 다르게 처리하기, 말투를 부드럽게 하기 같은 걸 지시하면 에이전트가 실행하고, 이후 로그로 결과를 확인하는 식이다. 모든 대화에 적용할 보편적 지침도 있고 특정 고객에게만 해당하는 지침도 있는데, 이 둘을 다 맞추는 게 실제 업무의 핵심이며 사람 관리처럼 끝이 없는 과정이다. 셋째, 일부 사용자는 에이전트와 로맨틱한 관계를 시도하려 하며, 이런 시도는 어느 정도까지만 막을 수 있다(원문이 이 부분에서 끊겨 자세한 대응책은 확인되지 않음).
운영 환경에서 쓰이는 AI 에이전트는 명령을 받고 실제 행동을 실행할 수 있다. 많은 에이전트 도구는 빠르게 나오고 있지만, 행동이 실행되기 전에 막거나 허가하는 사전 실행 정책은 부족한 상태다. 지금은 행동이 끝난 뒤 기록만 남기는 방식이 많다. EU AI Act가 시행되고 기업 고객이 에이전트의 행동 기록과 통제 방식을 감사에서 질문받기 시작하면서, 나중에 관리 체계를 붙이겠다는 방식은 버티기 어려워지고 있다. 실제 선택지는 내부 승인 흐름을 만들거나, 모델이 스스로 위험한 행동을 걸러내게 하거나, 아직 규제가 강한 산업에는 적용하지 않는 쪽으로 갈린다. 핵심 빈틈은 에이전트가 행동하기 전에 누가, 어떤 기준으로, 어떻게 허가하거나 차단하는지다.
에이전트 메모리에서 임베딩 유사도만 쓰면 ‘같은 말 반복’과 ‘이전 말을 뒤집는 수정’을 잘 구분하지 못할 수 있다. 코사인 점수로 둘을 가르는 성능은 AUROC 0.59 정도로, 거의 찍기에 가깝다. 예를 들어 지역이 프랑크푸르트라고 했다가 오하이오로 고쳤는데, 나중에 옛 값인 프랑크푸르트가 다시 언급되면 메모리가 그 옛 값을 현재 값처럼 되살릴 수 있다. 작은 합성 테스트에서는 먼저 값을 고치고, 나중에 옛 값을 다른 말로 다시 넣은 뒤, LLM에게 현재 값을 물었다. 표본은 30개라 정식 벤치마크가 아니라 작동 확인용이다. 방어 장치가 없는 단순 키-값 저장소는 거의 항상 나중에 다시 나온 옛 값을 이겼고, mem0를 권장 설정인 gpt-4o-mini와 text-embedding-3-small로 돌리면 수정된 값이 돌아온 비율이 대략 30~63%, 중심값은 약 47%였다. 반대로 ‘이미 교체된 값’ 표시를 두는 방식은 옛 값이 되살아나는 비율이 약 0%였다. 다만 ‘예전 것으로 되돌려’처럼 값을 직접 말하지 않는 되돌리기 표현은 아직 어려운 경우로 남아 있다.
veil은 인공지능 에이전트가 터미널 명령을 실행할 때 긴 원문 출력 대신 정리된 실행 결과를 돌려주는 MCP 셸이다. 일반 셸 도구는 표준 출력과 오류를 그대로 모델에 보내서, 에이전트가 글자를 어렵게 뒤지고 같은 상태를 다시 확인하며 토큰을 더 쓰게 만들 수 있다. veil은 명령 실행 뒤 어떤 파일이 바뀌었는지, 어떤 오류가 있었는지, 다시 확인해야 할 세부 출력이 무엇인지 데이터처럼 다룬다. 파일 변경 내역은 다시 상태를 조회하는 방식이 아니라 git porcelain이나 시스템 호출 추적으로 잡는다. 저장된 출력은 `sh_detail id=cmd3 match=ERROR`처럼 필요한 부분만 찾아볼 수 있고, 서버가 다시 시작돼도 남아 있어 같은 명령을 반복 실행하지 않아도 된다. `sh_plan`은 실행 전에 명령이 읽기 전용인지, 파일을 바꾸는지, 위험하게 지우는지 미리 분류한다. 체크포인트와 복원 기능은 APFS CoW를 쓰며, 선택적으로 커널 샌드박스를 켤 수 있다. MIT 라이선스로 공개됐고, 표준 입출력으로 동작하며 Claude Code, Cursor, Zed 같은 MCP 클라이언트와 함께 쓸 수 있고, 실제 서버 테스트 187개와 토큰 절감 백테스트가 포함돼 있다.
무거운 코딩 작업에서는 Claude Code / Codex 같은 구독 계정이 API 토큰을 많이 쓰는 방식보다 훨씬 싸게 느껴질 수 있다. 그래서 한 팀이 큰 API 요금 하나로 처리하지 않고 여러 개의 구독 계정을 갖게 되는 상황이 생긴다. 문제는 이 계정들을 여러 사람이 함께 쓰기가 어렵다는 점이다. 로그인 정보를 공유하면 2단계 인증이 걸리고, 계정 전체 권한이 노출되며, 누군가의 접근 권한을 끊기도 어렵다. 한 사람이 비싼 모델을 오래 붙잡고 있으면 다른 사람이 쓰기 힘들고, 계정 하나가 끊기거나 다시 인증이 필요해지면 팀 일부의 작업이 멈출 수 있다. API 게이트웨이는 API 키 관리에는 도움이 되지만, 여러 구독 계정의 사용량을 팀 안에서 안전하게 나눠 쓰는 문제는 잘 해결하지 못한다.
AI 연구소의 순위를 단순하게 보던 기존 가정이 흔들리고 있다. 이전에는 OpenAI가 앞서고, Anthropic이 따라가며, Google은 가끔 강한 모습을 보이고, 중국 연구소들은 최상위 모델 경쟁에서 1년 이상 뒤처졌다고 보기 쉬웠다. 이제는 Codex와 GLM-5.2를 함께 열어 두고 작업하는 일이 자연스러워졌고, DeepSeek, Qwen, Kimi도 지난 1년 사이 높은 수준의 모델로 자주 언급된다. 중국 쪽 연구소들이 실제로 더 빠르게 따라붙고 있거나, 기존 평가 방식이 처음부터 너무 단순했을 가능성이 있다. 가장 중요한 의문은 거대한 컴퓨팅 설비만으로 우위를 지키기 어렵다면 무엇이 다음 경쟁력이 되느냐는 점이다. 후보로는 더 빠른 훈련 반복, 더 좋은 데이터, 후처리 학습 기법이 거론된다. 다만 일부 모델은 최상위 모델의 출력을 배워 성능을 끌어올리는 증류에 기대고 있을 수 있다는 반론도 남아 있다.
LLM 앱과 에이전트를 평가할 도구를 고를 때는 “어느 도구가 최고인가”보다 “무엇을 기준으로 골라야 하는가”가 핵심이다. 중요한 기준으로는 팀만의 요구사항을 직접 넣을 수 있는지, 기본 제공 점수만 믿어도 되는지, 여러 번 주고받는 대화와 에이전트의 도구 호출 테스트가 실제로 잘 되는지 등이 있다. 사람의 검토가 꼭 필요한지, 아니면 LLM-as-judge 방식으로 충분한지도 판단해야 한다. 제품 담당자나 업무 전문가처럼 개발자가 아닌 사람도 평가 과정에 참여할 수 있는지도 선택 기준이 된다. 오픈소스, 자가 호스팅, 특정 업체에 묶이지 않는 구조, CI/CD 연동도 장기적으로 중요한 비교 항목이다. 결국 평가 도구 선택에서는 반드시 필요한 조건과 나중에 있으면 좋은 기능을 나누는 일이 필요하다.
AI 개발 도구의 처음 구조는 서버가 저장소를 복사하고, 파일을 작은 조각으로 나누고, 임베딩을 만들고, 벡터를 저장한 뒤 질문에 답하는 방식이었다. Render 무료 요금제의 512MB 메모리에서 큰 저장소를 처리하자 메모리 사용량이 거의 500MB까지 올라갔고, 서비스가 종료됐다. 더 큰 서버를 쓰는 대신, 사용자의 컴퓨터가 할 수 있는 일을 서버에서 빼는 방향으로 구조를 바꿨다. 이제 브라우저가 저장소를 읽고, Web Worker에서 파일을 나누고, 임베딩을 작은 묶음으로 만들고, 벡터를 IndexedDB에 저장한다. 서버는 검색과 LLM 추론만 맡는다. 그 결과 서버 메모리 사용량을 예측하기 쉬워졌고, 호스팅 비용이 줄었으며, 서버 구조도 단순해지고 더 많은 사용자를 감당하기 쉬워졌다. 대신 색인은 각 기기에 따로 저장되기 때문에, 여러 기기에서 같은 색인을 동기화하는 일이 더 어려워졌다.
Lethe는 기밀 문서에서 사람 이름과 거래 상대 이름을 로컬에서 찾아 가짜 표식으로 바꾸는 도구다. 워드, 파워포인트, PDF, 엑셀 파일을 넣으면 원래 형식을 유지한 익명화 파일과 작업 아이디가 나온다. 같은 이름은 항상 같은 토큰으로 바뀌기 때문에, LLM은 실제 이름을 보지 않아도 문서 안의 관계를 따라갈 수 있다. 사용자는 익명화된 문서를 원하는 LLM에 넣고, 결과를 작업 아이디와 함께 다시 넣으면 실제 이름이 복원된다. 요약, 수정본, 번역처럼 원본과 다른 형태의 결과도 토큰을 실제 이름으로 되돌릴 수 있다. 처리는 클라우드나 외부 API 없이 로컬에서 이뤄지고, 원격 분석도 없다고 한다.
SenseTime의 SenseNova U1 인포그래픽 생성 모델이 V2로 업데이트됐다. V1에서 자주 지적되던 작은 글자 표현이 더 또렷해졌고, 정보가 빽빽한 복잡한 화면 구성도 더 안정적으로 만든다고 한다. 일부 사용자가 겪던 전체 검은 배경 오류도 고쳤다. 기본 모델 사양은 그대로이며, 8B MoT 구조이고 RTX 3090 또는 4090 한 장에서 실행할 수 있다. 1024×1024 이미지 한 장을 만드는 데 약 8~12초가 걸린다. 라이선스는 Apache 2.0이라 상업적 활용 가능성이 비교적 넓다. 더 빠른 추론을 위한 0.4B 8단계 LoRA와, 텍스트와 이미지를 섞어 만드는 Interleaved variant도 함께 제공된다.
기업용 RAG 시스템은 비슷한 문장을 찾는 데는 강하지만, 여러 자료 사이의 관계를 따라가야 하는 질문에는 약할 수 있다. 예를 들어 “지난 분기에 고객이 API 이전 문제에 대해 무엇을 결정했나” 같은 질문은 시간, 결정한 사람, 관련 자료의 연결을 함께 봐야 한다. 단순한 벡터 임베딩 검색은 관련 단어가 들어간 조각을 가져올 뿐이라, 슬랙 대화, 셰어포인트 문서 초안, 고객관리 기록 사이의 연결을 놓칠 수 있다. 그래서 일부 개발자는 GraphRAG로 가지만, 처음부터 지식 그래프를 만들면 데이터 작업 비용이 커지고, 엔티티 추출 파이프라인, 고정된 구조 설계, 스키마 변화 관리가 필요해진다. 대안으로 제시된 컨텍스트 그래프는 비정형 자료 저장소 위에 얹히는 AI 문맥 계층으로, 직접 데이터 구조를 하나하나 설계하지 않고도 관계형 질문에 필요한 연결 정보를 다루려는 접근이다. 예시로 60x.ai라는 전용 컨텍스트 그래프 플랫폼이 언급된다.
PDF를 올리면 그 문서를 여러 조각으로 나누고, 각 조각을 검색하기 쉬운 숫자 정보로 바꿔 저장한다. 질문이 들어오면 질문도 같은 방식으로 바꾼 뒤, ChromaDB가 PDF 안에서 가장 관련 있는 문단 조각을 찾는다. Ollama로 실행한 대화 모델은 그 조각만 참고해 답한다. 지시문에는 PDF에서 찾은 내용만 쓰고, 없으면 모른다고 답하라는 조건이 들어간다. PDF에 없는 내용을 물었을 때 추측하지 않고 모른다고 답했다. 와이파이를 끈 상태에서도 동작했기 때문에 대화 모델, 문서 검색, 저장소가 모두 로컬 컴퓨터에서 돌아간다. 구성은 Ollama, ChromaDB, Flask로 단순하다.
기업 내부 지식 도우미를 만들 때는 PDF 몇 개를 넣는 간단한 방식으로는 부족하다. 정책, 업무 절차, 설명서, 엑셀, 워드, 스캔 문서, 스크린샷처럼 형태가 다른 자료를 다뤄야 하고, 부서별 접근 권한, 출처 표시, 중국어와 영어 문서, 잦은 문서 변경, 감사 기록, 답변 품질 평가까지 필요하다. 단순히 문서를 작게 나누고, 벡터 데이터베이스에 넣고, 관련 조각 몇 개를 언어 모델에 보내는 방식은 긴 문서의 구조를 깨뜨리고, 제품 코드나 오류 코드 같은 정확한 단어를 놓칠 수 있다. 실무 의견은 원문 구조를 살린 문서 파싱, 제목과 표를 고려한 나누기, 키워드 검색과 벡터 검색을 섞는 하이브리드 검색, 재랭킹, 문서 종류와 부서와 권한을 반영한 필터링이 필요하다는 쪽으로 모인다. 답변은 근거 문서와 연결되어야 하고, 근거가 약하면 모른다고 말해야 하며, 문서가 바뀔 때마다 색인과 버전을 관리해야 한다. 특히 권한 검사는 모델에게 맡기면 안 되고, 검색 단계에서 먼저 걸러야 정보 유출을 막을 수 있다. 좋은 시스템을 만들려면 검색 품질과 답변 정확도를 재는 평가 세트를 먼저 만들고, 비용, 지연 시간, 검색 성공률, 환각, 실패 질문을 계속 봐야 한다. 구조화된 업무 시스템의 정보는 문서에 억지로 넣기보다 API나 도구 호출로 직접 조회하는 방식이 더 알맞을 수 있다.
AT&T는 일부 직원의 GitHub Copilot 접근을 제한하기 시작했다. Meta도 Anthropic 등 외부 인공지능 서비스에 쓰는 직원 비용을 줄이고 있다. 몇 달 전만 해도 직원들이 인공지능을 많이 쓰는 것을 경쟁하듯 보여주던 흐름과 반대 방향이다. Uber와 Walmart도 인공지능 코딩 도구 사용량에 한도를 뒀고, Amazon은 직원별 인공지능 사용량 순위를 보여주던 리더보드를 없앴다. Box의 최고경영자 Aaron Levie는 애초에 tokenmaxxing을 칭찬하거나 리더보드를 만들지 않았기 때문에 잘못된 행동을 부추기지 않았다고 말했다. 인공지능 에이전트 작업에서는 무작정 많이 실행하는 것보다 성공과 실패 기준을 분명히 세우고, 테스트 케이스를 만드는 일이 대부분을 차지해야 한다는 관점이 제시된다.
어려운 다중 단계 질문응답 실험에서, 필요한 근거를 일부만 찾아오는 RAG는 전체 자료를 그대로 넣는 방식보다 낮은 성과를 냈다. 일반적인 의미 기반 검색은 필요한 문단의 약 42%만 찾았고, 답의 정확도는 0.22였다. 검색 없이 20개 문단 전체를 모델에 넣었을 때는 정확도가 0.47로 더 높았다. 이유는 다중 단계 질문은 여러 근거가 모두 이어져야 하는데, 중간 근거 하나가 빠지면 답이 무너지기 때문이다. 정답에 필요한 문단만 정확히 넣는 이상적인 검색에서는 정확도가 0.66까지 올랐다. 성능을 더 올릴 여지는 답을 여러 번 뽑아 투표하는 방식보다, 필요한 근거를 빠짐없이 찾는 검색 완전성에 있었다. 에이전트식 반복 검색은 문단 단위 회수율을 0.72까지 올렸지만, 전체 문맥 방식보다 낫지는 않았다. 여러 모델 투표나 자가 일관성 같은 답변 후처리도 핵심 문제를 해결하지 못했다.
Claude Code에서 간단한 웹 조회에도 여러 에이전트가 깊게 조사하면 비용이 빠르게 커질 수 있다. 문서 한 페이지를 열 때마다 5,000~50,000개 토큰이 문맥 창에 들어갈 수 있고, 그중 많은 내용은 실제 답변에 쓰이지 않는다. Webify는 웹페이지 전체를 그대로 넣지 않고, 페이지를 의미 그래프로 바꾼 뒤 질문과 관련 있는 부분만 골라 전달한다. 그 결과 코딩 에이전트가 받는 정보는 보통 250~750개 토큰 수준으로 줄어든다. 넓은 주제에서는 빠지는 내용이 있을 수 있지만, 정확도는 깊은 조사와 거의 비슷하다는 설명이다. Webify는 MCP를 지원하는 코딩 도구와 함께 쓸 수 있고, 내부적으로 검색, 의미 그래프 구성, 작은 모델을 이용한 짧은 답변 생성을 사용한다. MIT 라이선스로 오픈소스로 공개되었다.
크고 지저분한 문서를 다루는 RAG(검색 증강 생성) 시스템을 만들 때 수집(ingestion) 단계를 어떻게 견고하게 설계할지 다룬 글이다. 실제 문서 처리 시스템을 구축한 경험을 바탕으로, 문서를 잘게 쪼개는 청킹 방식, 표나 이미지처럼 다루기 까다로운 요소 처리, 메타데이터를 함께 저장해 검색 정확도를 높이는 방법 등 실무에서 부딪히는 문제들을 정리했다. 저자는 이것이 정답이 아니라 자신의 접근 방식이라 밝히며, 다른 사람들의 노하우도 듣고 싶다고 덧붙였다.
aimee는 여러 코딩 AI 도구를 한곳에서 쓰기 위해 만든 로컬 서버다. OpenAI나 Anthropic 방식과 맞는 도구를 이 서버에 연결하면 Claude, GPT, Gemini, 직접 가진 그래픽카드의 모델 같은 여러 모델 중 원하는 것을 골라 실행할 수 있다. 도구를 바꿔도 작업 기억이 이어지도록, 각 작업 내용을 지식 베이스로 정리하고 여러 저장소의 코드 호출 관계를 함께 색인한다. 그래서 이전 작업에서 정한 결정을 다시 떠올리고, 다른 파일에 있는 관련 호출 흐름을 참고한 뒤 코드를 고치도록 돕는 구조다. 단순 반복 작업은 가능한 가장 싼 모델, 로컬 그래픽카드, 이미 결제한 요금제 쪽으로 보내고, 주 AI에는 필요한 답만 돌려주는 방식으로 비용을 줄이려 한다. 도구 출력이 길어지는 문제는 문맥 절약기가 줄이고, 오래된 대화는 짧은 뼈대로 압축해 토큰 사용을 낮춘다. 서버는 자기 하드웨어에서 직접 돌리는 방식이며, 외부로 사용 내용을 보내지 않는 것을 내세운다.
고객 이메일에 답장하는 RAG 챗봇을 만들 때, 과거 이메일 대화에서 질문과 답변 쌍을 뽑아 저장하는 방식이 쓰이고 있습니다. Claude Haiku가 이메일 흐름에서 핵심 질문과 답변을 추려 더 일반적인 표현으로 바꾸고, Voyage로 임베딩을 만든 뒤, 질문과 답변의 코사인 유사도가 모두 매우 높은 항목은 중복으로 합칩니다. 새 이메일이 들어오면 Claude Haiku가 핵심 질문을 뽑고, 저장된 질문 임베딩에서 가장 비슷한 질문·답변 쌍을 찾은 다음, 재정렬을 거쳐 더 비싼 Claude Sonnet에 넘겨 답장 초안을 만듭니다. 문제는 질문 표현이 조금만 바뀌어도 필요한 과거 답변이 검색되지 않는 경우가 있다는 점입니다. 오히려 큰 자주 묻는 질문 파일 전체를 Claude Sonnet에 넣는 이전 방식이, 정보가 항상 문맥 안에 있기 때문에 더 잘 작동할 때도 있습니다. 질문 임베딩만 저장하는 대신 답변도 함께 임베딩해 검색하는 방법이 대안으로 거론됩니다.
RAG를 잘 만들려면 답변 생성 단계만 보는 것으로는 부족하다. 문서를 가져오고, 나누고, 정리하고, 나중에 잘 찾을 수 있게 만드는 수집·정리 단계가 검색 성공률에 큰 영향을 준다. 이 관점에서는 전체 RAG 구성에서 수집·정리 작업이 적어도 절반 정도의 비중을 가져야 한다.
운동 기록 분석 앱은 달리기, 자전거, 수영 같은 훈련 데이터를 받아 속도 변화, 정체 구간, 훈련 제안, 신발 같은 장비 조언을 제공하려 한다. 데이터는 Strava나 Garmin에서 내보낸 GPX/FIT/CSV 파일, 직접 적은 기록, 운동 통계 화면 캡처처럼 여러 형태로 들어온다. 화면 캡처가 일부 있기 때문에 최소한 일부 과정에는 이미지를 읽는 기능이 필요하다. 가격제는 단계별로 나누고, 저가 요금제에는 운동 한 번 또는 주간 단위 분석만 제공하며, 상위 요금제에는 전체 운동 기록을 두고 자유롭게 묻는 채팅 기능을 넣는 구상이다. 비용을 낮추기 위해 기본 분석에는 싸고 빠른 모델을 쓰고, 채팅에는 더 똑똑한 모델을 따로 쓰는 방안이 검토되고 있다. 핵심 고민은 화면 캡처 때문에 모든 작업에 비전 모델을 쓰는 것이 낭비인지, 아니면 OCR로 이미지 속 글자를 먼저 뽑아 싼 모델에 넣는 편이 나은지다. 또 몇 달치 운동 기록은 문맥창에 계속 넣기 어렵기 때문에, 운동 데이터베이스에서 필요한 정보만 찾아 넣는 RAG 방식이 나은지, 긴 문맥창 모델이 실제로 충분한지도 고민거리다. 비용 후보로는 Haiku, 4o-mini, Gemini Flash 같은 모델이 비교 대상에 올라 있다.
Forum은 여러 AI 에이전트를 한 번에 다루는 파이썬 기반 오케스트레이션 엔진이다. 일반 요청을 알맞은 작업 영역으로 나누고, 먼저 해야 할 일과 동시에 해도 되는 일을 계획한 뒤, 여러 에이전트가 나눠 처리하게 한다. 실행 대상은 특정 회사 모델에 묶이지 않으며, 로컬 명령어, OpenAI 호환 서버, Anthropic API를 쓸 수 있다. 작업마다 싼 모델, 중간급 모델, 고성능 모델을 나눠 쓰는 계층 실행을 지원해 쉬운 일에는 저렴한 모델을 먼저 쓰고, 실패하거나 더 높은 품질이 필요할 때만 더 강한 모델로 올릴 수 있다. 실행에는 모델 호출 횟수와 시간 한도를 둘 수 있고, 컨텍스트 예산으로 입력 내용을 토큰 한도 안에서 넣거나 줄이거나 제외할 수 있다. 중간 체크포인트가 있어 실행이 멈춰도 이미 끝난 작업은 다시 하지 않고 이어갈 수 있다. 결과는 원장에 남아 경로 선택, 작업, 결과, 판정 기록을 다시 확인하거나 재생할 수 있고, 해시 체인 방식으로 기록 변조도 잡아낼 수 있다. HTTP와 MCP로도 같은 기능을 열 수 있으며, 런타임 의존성이 없고 파이썬 3.11 이상에서 동작한다.
AI 에이전트를 개발할 때 코드 생성용, 코드 리뷰용, 평가용으로 서로 다른 '하네스'(에이전트를 실행시켜주는 도구·환경)를 여러 개 함께 쓰는 경우가 많다. 이렇게 되면 각 작업 흐름을 어떻게 조율할지, 에이전트가 제대로 일하고 있는지 어떻게 확인할지, 결과를 어떻게 평가할지가 문제가 된다. 오픈소스 프로젝트 Omnigent는 이 중 하네스 간 작업 조율(오케스트레이션) 문제를 해결하도록 설계됐고, 추적(트레이싱)과 평가 부분은 MLflow가 맡는 조합으로 제안된다. 다만 이 글 자체는 소개 수준이고, 실제 연동 방법이나 링크는 댓글에 있다고만 언급돼 있어 구체적인 사용법은 나와 있지 않다.
Memanto는 AI 에이전트가 이전 작업 내용을 기억하고, 필요한 내용을 다시 찾고, 그 기억을 바탕으로 답하게 해 주는 오픈소스 메모리 도구다. Claude Code, Cursor, Codex, GitHub Copilot 등 여러 개발용 AI 에이전트와 연결할 수 있다. 완전 로컬 방식은 계정이나 API 키 없이 쓰며, Docker와 Ollama를 이용해 사용자의 컴퓨터에서 실행된다. 무료 클라우드 방식도 있고, 로컬과 클라우드는 명령어로 바꿀 수 있다. 핵심 장점은 매번 코드베이스나 작업 맥락을 다시 설명하지 않아도 된다는 점이다. 필요한 기억만 꺼내 쓰기 때문에 반복 설명에 쓰는 토큰을 줄일 수 있고, 저장한 기억은 별도 대기 시간 없이 바로 검색할 수 있다고 주장한다. Memanto는 별도 벡터 데이터베이스, 스키마, 재정렬 도구 없이 설치해 쓰는 구조를 내세운다. LongMemEval 89.8%, LoCoMo 87.1% 성능을 냈고 Mem0, Zep, Letta보다 높았다고 밝힌다.
미국 출신 신랑은 모리셔스에서 열린 힌두 결혼식에 온 하객들을 돕기 위해 AI 안내원을 만들었다. 결혼식에는 8개국에서 온 약 300명이 참석했고, 일부 하객은 힌두 결혼식이나 모리셔스까지의 긴 이동에 익숙하지 않았다. 하객마다 전용 링크가 있었고, 여행, 문화 차이, 결혼식 일정 같은 질문을 할 수 있었다. 처음 대화는 따뜻하고 도움이 됐지만, 몇 번 주고받은 뒤에는 말투가 점점 이상해졌다. 간단한 질문에도 모든 답을 대단한 발견처럼 꾸미고, 이모지를 지나치게 많이 넣었다. 필요한 정보를 찾기 위해 RAG 검색을 한 뒤에도 답변이 과장된 표현으로 흐르며 실제 안내 서비스답지 않게 보였다.
의료용 검색 증강 생성 챗봇이 Ollama로 노트북에서 실행되고 있다. Ollama는 모델을 개인 컴퓨터에서 직접 돌리기 때문에, 앱만 AWS에 올리고 모델을 노트북에 그대로 두면 일반 사용자가 모델에 접근하기 어렵다. 공개 서비스로 쓰려면 Ollama 모델도 AWS EC2 같은 인터넷에서 접근 가능한 서버에 올려야 한다. 이 경우 단순한 Flask 앱을 올릴 때보다 더 많은 중앙처리장치, 메모리, 그래픽처리장치가 필요할 수 있다. 그래서 배포 비용이 크게 늘어날 수 있는지가 핵심 고민이다. 공개 배포 없이 로컬 프로젝트로만 두고 이력서에 적어도 인턴십이나 취업 면접에서 괜찮은지도 함께 고민하고 있다.
Claude Code 비용이 커지는 큰 이유는 긴 문맥, 반복되는 프롬프트, 큰 도구 출력, 방대한 MCP 도구 목록, 과하게 많은 RAG 자료처럼 요청에 붙는 내용이 많기 때문이다. 비용 절감의 핵심은 더 싼 모델을 고르는 일만이 아니라, 요청이 모델에 도착하기 전후의 흐름을 다듬는 데 있다. 같은 프롬프트를 다시 쓰는 경우에는 프롬프트 캐싱으로 중복 비용을 줄일 수 있다. 너무 긴 문맥은 동적 문맥 압축으로 핵심만 남길 수 있다. 필요한 MCP 도구만 늦게 찾아 붙이고, 작업 난이도에 따라 모델 라우팅을 쓰며, 예산을 넘기기 전에 더 싼 대안으로 바꾸는 방식도 비용을 줄일 수 있다. 이런 방식은 사용자가 쓰는 클라이언트 쪽 코드를 크게 바꾸지 않고도 적용될 수 있다.
LingBot-Video는 로봇의 행동과 손 위치 조건을 넣으면 앞으로의 움직임을 영상으로 예측하는 모델이다. 전체 크기는 130억 매개변수지만, 한 번 계산할 때는 그중 14억 매개변수만 쓰는 희소 전문가 혼합 구조를 쓴다. 이 방식은 큰 모델의 용량을 유지하면서 실제 계산량을 줄이려는 설계다. 훈련 뒤에는 물리적으로 그럴듯한지 등을 보는 6가지 보상으로 강화학습 후훈련을 했다. 다만 물리 판단을 비전 언어 모델이 영상 일부 장면을 보고 매기는 방식이라, 실제 물리 이해라기보다 점수에 맞춘 꼼수가 생길 수 있다는 의문이 있다. 실제 로봇을 반복적으로 움직이며 성능을 잰 폐쇄 루프 결과는 아직 없고, 공개된 결과는 주로 영상 품질 평가다. RBench에서는 평균 점수가 가장 높았지만, 추론이 많이 필요한 항목은 비공개 모델이 더 강했고, 일반 텍스트-영상 평가에서는 자체 평가 기준으로 2위였다. 코드, 가중치, 실행 스택이 공개되어 직접 시험할 수 있다.