AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
이 공개 프로젝트는 여러 언어가 LLM에서 얼마나 많은 토큰을 쓰는지 비교하는 주제를 다룹니다. 같은 뜻의 내용이라도 언어에 따라 토큰 수가 달라질 수 있고, 토큰이 많아지면 사용 비용과 처리 시간이 늘어날 수 있습니다. 핵심 관심사는 언어별 비용 차이가 얼마나 나는지, 그리고 더 공정한 토큰 비용 기준을 어떻게 볼 수 있는지입니다. AI 에이전트를 여러 언어로 운영할 때 입력과 출력이 길어지는 언어가 실제 비용을 더 많이 만들 수 있다는 점을 확인하는 데 연결됩니다.
drun은 초기 버전이 오픈소스로 공개된 MCP입니다. 이 도구는 컴퓨터의 일부 환경을 따로 떼어 AI 에이전트가 쓰는 임시 실행 환경으로 만들어 줍니다. 에이전트는 Git처럼 여러 작업 방향을 나눠 시험하고, 실패한 방향은 버릴 수 있습니다. 이 과정에서 실제 컴퓨터의 파일이나 상태를 망가뜨리지 않는 것이 핵심입니다. drun은 접속 가능한 네트워크 주소, 실행 금지 명령어, 접근 가능한 파일 시스템 경로, 메모리와 실행 시간 같은 자원 한도를 규칙으로 제한합니다. 에이전트에게 컴퓨터를 직접 마음대로 고치게 하는 대신, 넘을 수 없는 경계를 미리 정해 더 안전하게 작업하게 합니다. 프로젝트는 버그 제보와 기여를 받으며 커뮤니티 기반으로 품질과 기능을 키우려 합니다.
self-learning-skills는 AI 코딩 에이전트가 어렵게 알아낸 작업 방법을 다음 세션에서도 다시 쓰게 만드는 오픈소스 도구다. Claude Code, Cursor, Codex처럼 AGENTS.md나 규칙 파일을 읽는 도구와 함께 쓸 수 있다. 핵심은 배포 명령, 운영 데이터베이스 접속 방법, 실제 서비스 확인 절차처럼 여러 번 시도 끝에 찾은 방법을 자동으로 기록하는 것이다. Claude Code에서는 새 SKILL.md 파일로, Cursor에서는 learned 폴더의 규칙 파일로, Codex·Zed·Aider 같은 도구에서는 AGENTS.md나 프로젝트 메모리로 남긴다. 설치는 npx skills add kulaxyz/self-learning-skills 명령으로 할 수 있고, 전역 설치나 특정 에이전트 설치도 지원한다. 여러 단계로 반복될 작업은 새 기술이나 규칙으로 저장하고, 한 줄짜리 사실은 가벼운 메모리로 남기며, 다시 쓸 가능성이 낮은 일회성 내용은 건너뛴다. 비밀번호, 토큰, 연결 문자열, API 키 같은 비밀값은 저장하지 않고, 어디에서 찾아야 하는지만 남기도록 설계되어 있다.
2026년 7월 기준으로 쓸 만한 로컬 시각-언어 모델(VLM)을 고르기 위한 토론이다. 대상은 오픈 가중치 모델로 제한된다. 단순히 모델 이름만 고르는 방식이 아니라, 어떤 하드웨어에서 돌렸는지, 어떤 추론 엔진을 썼는지, 어떤 용도로 얼마나 자주 썼는지까지 함께 비교하자는 취지다. 시각-언어 모델(VLM)은 벤치마크를 믿기 어렵고, 도구가 아직 성숙하지 않았으며, 같은 입력에서도 결과가 달라질 수 있어서 평가가 까다롭다는 전제가 깔려 있다. 그래서 개인용인지 업무용인지, 어떤 도구와 프롬프트를 썼는지도 자세히 공유해야 의미 있는 비교가 된다.
AI 에이전트를 쓰다 보면 단순히 내용을 잊어버리는 것보다 더 심각한 문제가 있다. 한 달 전에 시도했다가 버린 방법을 에이전트가 다시 확신에 차서 제안하거나, 2주 전에 이미 교체된 결정을 여전히 유효한 것처럼 취급하며 계획을 세우는 경우다. 문제가 겉으로 드러나지 않고 조용히 시간만 낭비하게 만든다. 흔한 메모리 기능은 '잊어버림'은 고쳐주지만, '과거에 대해 확신에 차서 틀리는' 문제는 고치지 못한다. 이는 정보를 다시 찾아오는 문제가 아니라, 그 정보의 현재 상태(유효한지, 폐기됐는지, 검증 안 됐는지)를 판단하는 문제이기 때문이다. 이를 해결하기 위해 3개월에 걸쳐 NodeDex라는 도구를 만들었다. 에이전트와의 대화에서 백그라운드 파이프라인이 자동으로 프로젝트의 추론 과정을 그래프 형태로 구축해주기 때문에, 에이전트가 따로 저장을 기억할 필요가 없다. 핵심 설계는 두 가지다. 첫째, 시도했다가 포기한 방법들을 목록으로 명시적으로 관리하고, 에이전트가 새로운 제안을 하기 전에 반드시 이 목록을 먼저 확인하도록 학습시킨다. 둘째, 각 결정에는 그 이유와 함께 고려됐던 대안들도 함께 기록한다. 이 프로젝트는 오픈소스로 공개됐다.
Aletheia는 정답을 바로 확인하기 어려운 질문을 조사하기 위한 오픈소스 에이전트 루프다. 일반적인 에이전트 루프는 코드가 실행되는지, 테스트가 통과하는지처럼 결과를 확인할 수 있을 때 잘 작동한다. Aletheia는 공급사의 성장 주장, 회사의 재무 상태, 과학 뉴스가 실제 연구 내용과 맞는지처럼 증거가 불완전하고 서로 충돌할 수 있는 문제를 다룬다. 작동 흐름은 ‘믿는 것 정리 → 행동 → 관찰 → 판단 갱신’이다. 가능한 답을 명시해 두고, 그 판단을 실제로 바꿀 수 있는 검색을 우선 선택하며, 반대 증거가 나오면 확신을 낮춘다. 첫 적용 사례는 회사와 공급사 실사용 조사 도구이며, 근거, 반대 신호, 확신 수준, 아직 모르는 점을 함께 보여준다. 증거가 부족하면 억지로 결론을 내리지 않고 멈출 수도 있다. 현재 Claude Code와 OpenAI Codex에서 실행된다.
AI 에이전트가 작업할 때 문맥 창(대화 기록을 담아두는 공간)이 점점 차오르는 문제를 다루는 두 가지 방식이 있다. 하나는 '반응형'으로, 문맥이 꽉 찰 때까지 기다렸다가 한꺼번에 압축하는 방식이다. 다른 하나는 '능동형'으로, 매 턴마다 무엇을 문맥에 추가할지 까다롭게 골라서 애초에 불필요한 정보가 쌓이지 않게 하는 방식이다. 대부분의 코딩 에이전트는 반응형을 쓰지만, 개발자는 몇 달에 걸쳐 능동형 방식을 만들었다. 핵심 원칙은 3번째 턴에서 에이전트가 내린 결정이, 이미 끝난 15번째 턴의 도구 실행 결과보다 훨씬 더 중요한 정보라는 것이다. 이를 똑같이 취급하면 '문맥 오염(context rot)', 즉 중요하지 않은 정보가 쌓여 성능이 떨어지는 문제가 생긴다. PRAANA라는 시스템의 컴파일러는 작업 메모리를 활성(active), 소프트(soft), 하드(hard) 세 단계로 나눈다. 각 문맥 조각에 정보 밀도 점수를 매기고, BM25(키워드 기반 검색 알고리즘)와 의미 기반 유사도(Transformers.js를 이용해 자체 프로세스 내에서 실행)를 함께 써서 어떤 정보를 다시 활성 문맥으로 불러올지 결정한다. 개발 과정에서 실수도 있었다. 초반에 급하게 만든 해시 기반 임베더(텍스트를 숫자로 변환하는 도구)를 임시로 썼는데, 이게 조용히 검색 순위를 망치고 있었다. 관련 없는 항목이 관련 있는 항목보다 위로 올라오는 등 순서가 뒤죽박죽이었다. 문제는 오류 메시지 하나 없이 그럴듯해 보였다는 점이라, 문제를 알아채는 데만 3주가 걸렸다. 결국 Transformers.js 기반 임베더로 교체해 해결했다.
정적 HTML로 만든 RAG 실전 안내서가 수집, 청킹, 임베딩, 벡터 데이터베이스, 검색, 보강, 생성, 에이전트, 평가까지 전체 흐름을 한 번에 이어서 보여준다. Python과 LangChain 중심 자료가 많은 상황에서 .NET과 Azure 환경을 쓰는 사람도 이해하기 쉽게 구성됐다. 각 단계마다 Pinecone이나 OpenAI 같은 흔한 기본 선택지만이 아니라 무료 또는 오픈소스 대안도 함께 제시한다. Microsoft AI-103 자격증 공부 과정에서 만든 학습 자료이며, 시각적이고 구조화된 방식으로 RAG 구성요소의 연결 관계를 파악하는 데 초점을 둔다. 특히 Python이 익숙하지 않은 사람이 RAG 기반 에이전트 구성을 처음 정리할 때 도움이 될 수 있다.
Bratan은 RAG 시스템을 더 잘 만들기 위한 오픈소스 실험 프레임워크다. 구조는 세 역할로 나뉜다. 한 역할은 검색과 답변 흐름의 약점을 찾아내고, 다른 역할은 그 문제를 고치며, 마지막 역할은 결과가 실제로 나아졌는지 점수를 매긴다. 이 과정은 한 번에 끝나지 않고, 함께 바뀌는 시험 문제 묶음을 놓고 반복된다. 목표는 고정된 시험에서만 좋은 점수를 받는 시스템이 아니라, 여러 약점에 버티는 검색 기반 답변 시스템을 만드는 것이다. 다만 토큰 절감이나 추론 비용 감소에 대한 구체적인 수치나 검증 결과는 제시되지 않았다.
plan.md 파일에 평소 업무와 비슷한 과제 5개를 적어 두고, 여러 AI 모델에 같은 일을 시켜 비교한다. 비교 대상에는 Claude Sonnet 5 같은 새 모델과 기존에 쓰던 모델이 포함될 수 있다. 결과만 보는 것이 아니라, 일을 끝내는 데 걸린 시간과 비용도 함께 기록한다. 작업이 끝난 뒤에는 외부 테스트 검증으로 결과가 제대로 맞는지 확인한다. 이 방식은 매일 쓰는 실제 업무 기준으로 성능, 속도, 비용을 함께 판단하려는 중급 수준의 벤치마크 흐름이다.
Claude Code의 실험적 팀 모드를 켜면 여러 에이전트가 함께 일하는 방식으로 작업을 나눌 수 있다. 이 방식은 조사와 코드 검토처럼 보조 성격이 강한 일은 Sonnet 5에 맡기고, 핵심 개발처럼 더 중요한 일은 더 비싼 Fable 같은 모델에 남겨 두는 전략이다. 목표는 품질을 유지하면서 비싼 모델 사용을 줄여 비용과 토큰을 아끼는 것이다. 다루는 영역은 품질 관리, 토큰 절약, 문맥과 메모리 관리, 디버깅, 여러 에이전트 작업 흐름이다. 난이도는 중급으로 잡혀 있고, 워크플로 가치는 75점, 최신성은 70점, 신뢰도는 0.80으로 평가되어 있다.
코딩 기본기를 배우기 위한 자체 호스팅 교육 앱 ‘Learn Code’를 여러 AI 모델로 나눠 만들었다. Sonnet은 교육 과정 조사, Opus는 수업과 퀴즈 작성, Fable은 코드 작성, Claude Design은 화면 설계, GPT 5.5는 코드 검토에 쓰였다. 앱은 오픈소스로 공개되었고, Docker로 실행할 수 있게 구성되었다. 기능은 기술별 학습 경로, 연습 문제, 선택적인 로컬 AI 코드 검토를 포함한다. 핵심 문제는 AI로 코드를 만들더라도 사용자가 코드 실수와 동작 원리를 스스로 이해하지 못하면 독립적으로 개발하기 어렵다는 점이었다.
Slop-Cops는 레딧 게시물 안에서 바로 실행되는 작은 웹 게임이다. 사용자가 프로젝트 아이디어나 웹주소를 넣으면, 5개의 AI 캐릭터가 그 아이디어가 타당한지와 얼마나 대충 만든 결과물처럼 보이는지를 놓고 토론한다. 캐릭터는 문법 검사관, 버그를 의심하는 사냥꾼, 복고풍 관리자, 신입, 비관적인 선임 엔지니어로 나뉜다. 기술적으로는 레딧의 Devvit 위에서 만들었고, 화면은 React가 iframe 안에서 보여준다. 이 화면은 Devvit의 Hono 서버와 통신하며, 진행 상태는 Redis에 저장된다. AI 캐릭터의 말과 판단은 Gemini 3.1 Flash Lite가 맡는다. 시험판은 r/slopcops에서 바로 해볼 수 있다.
Claude Code가 전체 작업을 지휘하고, 로컬 대규모 언어 모델이 코드 작성 일부를 맡도록 구성하는 고급 작업 방식이다. 예시는 llama-server 같은 로컬 실행 모델을 하위 에이전트로 연결해 코드 생성을 넘기는 흐름이다. 목표는 Claude Code가 모든 코드를 직접 만들 때 쓰는 토큰을 줄이고, 외부 모델이 제대로 호출되는지 확인하는 것이다. 이 방식은 하위 에이전트가 실제로 쓰이는지 살피고, Claude Code와 하위 에이전트 사이의 대화 문제가 생기면 적극적으로 디버깅하는 과정을 포함한다. 성공한 설정은 나중에 다시 쓰기 위해 문서로 남긴다. 다루는 주제는 품질 관리, 토큰 절약, 문맥과 메모리, 디버깅, MCP, 하위 에이전트, 여러 에이전트 협업이다.
부동산 회사의 홍보 담당자들은 Nextdoor에서 동네 글을 올리거나 잠재 고객에게 개인 메시지를 보낸 뒤, 그 화면을 캡처해 활동 증거로 제출했다. 예전에는 대표가 이메일을 하나씩 열고 스크린샷을 확인한 다음, 지급 대상인지 판단하고 금액까지 직접 계산해야 했다. n8n 워크플로가 이 과정을 대부분 자동으로 처리하도록 구성됐다. 제출자가 실제 활동 중인 직원 목록에 있는지 이름과 이메일을 확인하고, 스크린샷은 Supabase Storage에 저장한다. AI 비전 모델은 각 스크린샷이 동네 게시글인지 개인 메시지 대화인지 분류한다. 게시글은 회사 교육 문서의 인정 기준으로 평가하고, 개인 메시지는 승인된 메시지 양식과 비교한다. 인정되는 제출물은 지급액을 계산하고, 잠재 고객의 답장이 보이면 유망 고객으로 표시해 리더십 팀에 바로 이메일을 보낸다. 핵심 위험은 같은 스크린샷을 다시 제출해 중복 지급을 받을 수 있는 허점이었다.
Claude를 이용한 소프트웨어 개발을 설계, 구현, 테스트, 검토 단계로 나누는 방식이다. 큰 방향을 잡거나 검토할 때는 더 강한 Claude 모델을 쓰고, 실제 코드를 만드는 단계에는 더 작은 모델을 써 비용을 줄이는 구성이 핵심이다. 하위 에이전트를 함께 쓰면 설계, 디버깅, 품질 확인 같은 일을 역할별로 나눠 처리할 수 있다. 코딩 경험이 적은 사람도 기업 업무 시스템 같은 앱을 처음부터 만들 때 과정을 작게 쪼개 따라갈 수 있게 한다. 수동 테스트와 AI 테스트를 함께 넣고, GitHub로 변경 내용을 관리하며, 마지막에는 보안 검토까지 거친다. 난이도는 중급 수준이고, 평가 점수는 80점, 신선도는 70점으로 제시되어 있다.
ClaudeCode에게 오픈소스 프로젝트 유지보수를 맡기되, 마음대로 움직이지 못하게 MAINTAINER.md라는 운영 헌장으로 통제하는 방식이다. 이 헌장은 인공지능 에이전트가 무엇을 할 수 있는지, 어떤 순서로 기획·구현·검토·반영해야 하는지, 반드시 통과해야 하는 확인 절차가 무엇인지 정한다. 정책 변경은 사람이 승인해야 하고, 자기 작업을 스스로 승인할 수 없으며, 비밀번호나 배포 권한처럼 민감한 일은 사람이 계속 맡는다. 코드에서 문서, 에이전트용 작업 지침, 설명 자료를 자동으로 만들어 최신 상태로 유지하는 ‘살아 있는 코드’ 방식도 함께 쓴다. 목표는 에이전트가 오래된 문서를 읽고 잘못 판단하는 일을 줄이고, 매번 긴 설명을 다시 넣지 않아도 되게 해 문맥 관리와 토큰 절약에 도움을 주는 것이다. 난이도는 고급에 가깝고, 품질 관리·디버깅·출시·하위 에이전트 운영까지 포함한 실험적 작업흐름이다.
앤스로픽 Claude에 있는 '에이전트 스킬(Agent Skills)' 기능을 Claude가 아닌 다른 LLM 기반 에이전트에서도 사용할 수 있도록 옮기는 방법을 소개한다. 에이전트 스킬은 특정 작업을 처리할 때 필요한 절차나 도구 사용법을 미리 정의해 두고, 에이전트가 상황에 맞게 불러와 쓰는 방식이다. 이 방식을 Claude 전용 포맷에 묶어두지 않고 다른 모델을 쓰는 에이전트에서도 그대로 동작하도록 변환하는 접근을 다룬다.
LiteLLM은 깃허브에 있는 모델 가격 지도를 불러와 모델별 비용과 문맥 길이를 계산할 수 있다. 하지만 이 파일은 커뮤니티가 고치기 때문에 새 모델 가격이 늦게 들어가거나, 빠진 채 남거나, 잘못된 숫자가 한동안 유지될 수 있다. 비용을 더 정확히 보려면 모델별로 설정을 덮어쓰거나, `LITELLM_MODEL_COST_MAP_URL` 환경 변수로 직접 관리하는 가격 지도 주소를 넣을 수 있다. 예시로 든 `cloudprice.net` 가격 지도는 같은 형식을 쓰며, 각 제공사에서 가격을 가져와 매일 새로 고친다. 이 지도에는 채팅과 임베딩뿐 아니라 이미지, 오디오, 비디오, 재정렬, OCR 가격도 들어 있다. LiteLLM 기본 지도에는 없는 약 340개 모델 가격도 포함되어 있으며, OpenRouter의 Z.AI GLM-5.2, DeepSeek V4, Vercel 쪽 새 모델 같은 최근 모델이 주로 해당된다. 무료로 쓸 수 있고 별도 키는 필요 없지만, 과도한 사용을 막기 위한 제한이 있다. 추가 제안은 게이트웨이 화면에서 기본 가격 지도와 예비 가격 지도를 여러 개 등록하고, 한쪽에 없는 모델은 다른 쪽에서 찾게 하자는 것이다.
대부분의 에이전트 프레임워크는 매 턴마다 이전 대화 전체(또는 그 일부)를 다시 문맥창에 넣는 방식인 트랜스크립트 재생을 기본으로 쓴다. 짧은 작업에는 문제없지만 긴 작업에서는 무너지며, 문맥창을 키운다고 해결되지 않는다. Chroma의 context-rot 보고서는 GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등 18개 모델을 평가한 결과, 토큰 한도에 도달하기 훨씬 전부터 정확도가 떨어지는 것을 발견했다 — 단순 검색/복제 과제에서도 30~50%까지 떨어졌다. 또한 위치도 중요해서 문맥의 시작과 끝 부분은 잘 유지되지만 중간 부분의 정보는 손실되기 쉽다. 최근 논문 "AI Agents Need Memory Control Over More Context"(arXiv 2601.11653)는 계속 커지는 트랜스크립트 대신, 에이전트가 매 턴 확정하는 bounded state(제한된 내부 상태)를 유지할 것을 제안한다. 이 논문은 어떤 자료를 불러오는 것과 그것을 영구 메모리에 기록하는 것을 명확히 구분한다. IT 운영, 보안, 헬스케어 워크플로우에서 트랜스크립트 재생이나 검색 방식보다 드리프트와 환각이 낮다고 주장하지만, 확정적인 수치는 제시하지 않는다.
Claude Code를 매일 쓰는 환경에서, 쉬운 작업까지 비싼 Claude Sonnet에 보내지 않도록 작은 오픈소스 뼈대가 만들어졌다. 구성은 bash와 파이썬 표준 라이브러리만 쓰며, 별도 프레임워크나 pip 설치가 필요 없다. 핵심은 로컬 Ollama 기반 작업 라우터가 작업 난도를 0부터 10까지 매기고, 0~5점은 Gemini Flash, Groq, Cerebras 같은 무료 구간으로 보내는 방식이다. 6~7점은 Groq llama-3.3-70b 같은 중간급 모델로 보내고, 8~10점만 Claude Sonnet/Opus로 보내는 구조다. 모든 판단은 JSONL 기록으로 남아, 어떤 작업이 어느 등급 모델로 갔는지 실제 비율을 확인할 수 있다. 공개된 개인 기록에서는 98번의 판단 중 95번이 Claude의 최상위 등급을 쓰지 않았지만, 설정이 강하게 조정되어 있고 표본이 작아 그대로 비용 절감률을 보장하지는 않는다. 세션 유지와 비밀 스캔 관문도 포함되어, 여러 작업 흐름을 이어가고 민감한 정보가 밖으로 나가는 위험을 줄이는 데 도움을 준다. 다만 작업 점수를 매기는 규칙은 다른 환경에서도 잘 맞을지 아직 불확실하다.
로컬 Qwen 3.6 27B와 Qwopus는 Claude Opus나 Codex처럼 긴 개발 작업을 혼자 오래 맡기기에는 아직 불안정하다. 작은 소프트웨어 회사 환경에서는 고객 데이터가 들어간 진단 자료와 텔레메트리 분석처럼 클라우드에 올리기 어려운 작업에서 큰 가치가 있었다. 1만2000달러짜리 RTX 6000 Pro 96GB 그래픽카드는 몇 달 만에 비용을 회수했는데, 한 고객이 12개월 넘게 실제 사용량보다 4~5배 적게 라이선스를 보고한 사실을 로컬 모델 분석으로 찾았기 때문이다. 하지만 같은 모델은 큰 코드 작업이나 긴 에이전트 작업에서 반복 출력에 빠지거나, 파일 이름과 도구 호출을 지어내거나, 잘못된 해석을 할 수 있었다. 3090 그래픽카드에서는 모델을 줄여서 돌려야 했고, 문맥 길이와 양자화 설정 때문에 품질과 안정성이 더 흔들렸다. RTX 6000 Pro에서는 llama.cpp로 Qwen 3.6 27B를 긴 문맥과 높은 품질 설정으로 돌렸고, MTP를 켜면 초당 67토큰 수준에서 130~200토큰까지 빨라졌다. 운영 관점에서는 로컬 인공지능도 단순한 절약 도구가 아니라 사용자 권한, 사용량 측정, 할당량, 모델 라우팅, 전력 비용, 가동 시간을 관리해야 하는 내부 서비스가 된다. 실전 조언은 로컬 모델을 고객 지원, 범위가 좁은 유지보수, 코드베이스 읽기, 테스트처럼 잘 제한된 작업에 쓰고, 장시간 무감독 코딩에는 맡기지 말라는 것이다.
프롬프트는 코드처럼 자주 바뀌지만, 많은 팀은 함수에는 테스트를 두면서 프롬프트에는 테스트를 거의 두지 않는다. 시스템 프롬프트를 조금 고친 뒤 몇 개 결과만 눈으로 확인하고 배포하면, 나중에 챗봇이 며칠 동안 사실이 아닌 내용을 자신 있게 만들어냈다는 문제가 발견될 수 있다. faithgate는 이런 문제를 막기 위해 만든 프롬프트용 pytest에 가깝다. 질문, 참고 문맥, 기대 답변으로 된 사례 묶음을 저장해 두고, 특정 프롬프트와 모델 버전이 답을 얼마나 근거 있게 내는지 점수화한다. 그런 다음 기준 결과와 사례별로 비교해 나빠진 부분이 있으면 실패 상태로 끝나며, CI에 연결하면 나쁜 프롬프트 변경이 제품에 들어가기 전에 PR 단계에서 막힌다. 통과 조건은 일부러 엄격하다. 맞는 사례가 0개이거나, 점수가 매겨지지 않았거나, 모든 점수가 오류로 끝나면 통과하지 못한다. 실행 기록에는 판정 모델, RAGAS 버전, 테스트 묶음 해시가 남고, 기준 결과와 새 결과의 판정 모델이 달라지면 같은 비교로 보지 않고 별도 오류 코드로 끝난다. 답변 보류는 0점으로 뭉개지지 않고 보류 상태로 따로 저장된다. 기본 판정 모델은 Claude이고, 점수 계산에는 RAGAS가 쓰인다.
ContextJet-ai의 공개 깃허브 저장소 `awesome-llm-observability`는 LLM 관찰과 평가에 쓰는 도구 48개를 정리한다. 범위에는 실행 추적, 평가, 프롬프트 관리, 게이트웨이, OpenTelemetry 연결, 안전장치 도구가 포함된다. 각 도구에는 현재 깃허브 별 수와 라이선스 정보가 붙어 있다. 주요 플랫폼은 직접 설치 가능 여부, 라이선스, 추적 지원, 평가 지원, OpenTelemetry 지원 여부를 비교표로 볼 수 있다. 에이전트 작업에 바로 쓸 수 있는 예시도 포함되어 있으며, 추적 붙이기, 평가 추가하기, 실행 기록으로 문제 찾기, 개인정보를 보호하는 추적 같은 작업을 다룬다. 최소 기능의 OpenTelemetry GenAI 추적 예제도 함께 제공된다.
crawlberg는 Rust로 만든 웹 수집·추출 도구다. 웹사이트 주소를 넣으면 robots 규칙과 사이트맵을 확인하고, 자바스크립트로 뒤늦게 그려지는 페이지는 헤드리스 Chrome으로 읽는다. 결과물은 원본 HTML이 아니라 정리된 Markdown과 링크, 메타데이터, JSON-LD, Open Graph 같은 구조화된 정보다. 그래서 RAG 시스템에 넣기 전에 문서를 잘게 나누기 쉬운 텍스트를 얻을 수 있다. BM25 필터링으로 전체 사이트를 무작정 긁지 않고, 원하는 검색어와 관련 있는 쪽으로 수집 범위를 좁힐 수 있다. SSRF 방어가 기본으로 켜져 있어 사용자가 넣은 주소를 크롤링할 때 내부망이나 민감한 서버 주소 접근을 막는다. 로컬에서 실행되고 MIT 라이선스라 특정 회사 서비스에 묶이지 않는다.
Zero는 모델을 쉽게 바꿔 쓸 수 있는 오픈소스 코딩 에이전트다. OpenAI, Anthropic, Gemini, DeepSeek, Qwen, Groq 같은 25개 이상 제공업체와 연결되고, Ollama나 LM Studio를 통해 로컬 모델도 쓸 수 있다. 한 세션 안에서 `/model` 명령으로 모델을 바꿔도 이전 대화와 작업 흐름의 컨텍스트가 유지된다. 단순한 파일 읽기, 요약, 기본 코드 틀 만들기, 반복 작업은 싸고 빠른 모델에 맡긴다. 깊은 판단이 필요한 단계에서만 프런티어 모델로 올리고, 민감한 코드나 데이터가 들어간 일은 로컬 모델로 처리한다. 이렇게 하면 모든 토큰을 비싼 모델에 쓰지 않고, 실제로 높은 추론 능력이 필요한 일부 단계에만 비싼 비용을 낸다. 세션은 디스크 파일로 저장되어 다시 열거나 갈라서 쓸 수 있고, 단일 Go 실행 파일로 동작하며, 원격 측정이 없고, 자동화에 붙이기 쉬운 헤드리스 모드도 있다.
Laguna M.1은 poolside가 공개한 2250억 개 규모의 Mixture-of-Experts 모델이다. 한 번에 전체 모델을 다 쓰지 않고 토큰마다 약 230억 개의 활성 파라미터만 사용하도록 설계되어, 큰 모델의 능력을 유지하면서 실행 부담을 줄이는 방향이다. 목표 사용처는 에이전트 코딩과 오래 이어지는 작업이다. 구조는 70개 층으로 되어 있고, 앞의 3개 층은 일반 밀집 구조, 나머지 67개 층은 256개 전문가 중 일부를 고르는 전문가 라우팅 구조를 쓴다. 모든 층에서 전체 문맥을 보는 어텐션 구조를 사용하며, 도구 호출 사이에 추론 과정을 끼워 넣는 기능도 지원한다. SWE-bench Verified, SWE-bench Multilingual, SWE-Bench Pro, Terminal-Bench 2.0 같은 에이전트 코딩 평가에서 최신 오픈 가중치 모델과 상용 최상위 모델에 견줄 만한 성능을 낸다고 제시됐다. Apache 2.0 라이선스로 공개되어 상업용과 비상업용 모두에서 사용과 수정이 가능하다. 학습은 사전학습, 후속학습, 강화학습 단계를 거쳤다.
병원 환자 기록이 대부분 종이 파일로 남아 있다. 목표는 의사나 병원 직원이 환자의 과거 병력 요약, 당뇨 진단 여부, 이전 복용 약 같은 질문을 할 수 있는 RAG 기반 비서를 만드는 것이다. 가장 큰 문제는 이미 정리된 디지털 문서가 아니라 여러 해치의 종이 기록에서 시작한다는 점이다. 먼저 스캔, OCR, 데이터 정리와 구조화 단계를 제안한 뒤 RAG 시스템을 만드는 방식이 맞는지 검토가 필요하다. 병원 기록과 의료 인공지능에서 어떤 구조가 현실적인지, 큰 어려움과 피해야 할 실수, 작은 팀이 감당할 수 있는 규모인지가 핵심 질문이다.
해커톤 팀이 인터넷 서버 대신 노트북 두 대에서만 돌아가는 RAG 앱을 만들려 한다. 한 대는 i7 13세대 프로세서와 메모리 32GB가 있지만 그래픽카드는 없다. 다른 한 대는 i5 12세대 프로세서와 메모리 16GB, 엔비디아 그래픽카드 4GB가 있다. 목표는 RAG 방식으로 자료를 찾아 답하는 앱을 만들고, 속도를 잘 내면서 그럴듯하지만 틀린 답을 줄이는 것이다. 그래서 이 환경에서 어떤 오픈소스 LLM을 쓰는 것이 좋은지 판단하려는 상황이다.
긴 문맥을 쓰는 인공지능 모델은 이전 단어들의 계산 결과를 KV cache에 저장해 다음 단어를 더 빨리 만듭니다. 이 실험에서는 KV cache quantization 품질을 재는 흔한 방식에 문제가 있다고 봅니다. 많은 perplexity 검사는 캐시를 끈 상태에서 한 번만 계산하기 때문에, 압축된 캐시를 실제로 읽지 않습니다. 그래서 전체 정밀도, 4비트, 2비트 설정이 모두 3.6416이라는 같은 perplexity 값을 냈고, 값 캐시 압축 오류를 잡아내지 못했습니다. 이를 고치기 위해 먼저 문맥을 채운 뒤 단어를 하나씩 생성하면서 압축된 캐시를 실제로 읽는 방식으로 다시 측정했습니다. 새 방법은 값 벡터를 Hadamard matrix로 돌린 뒤 2비트 uniform quantization을 적용합니다. 키는 KIVI int4 방식을 그대로 두고 값만 바꿨습니다. 수정된 측정에서는 2비트 값 캐시가 KIVI 4비트와 소수 셋째 자리까지 비슷한 품질을 보였고, 메모리는 약 20% 덜 썼으며, fp16보다 약 4배 적게 썼습니다. 결과는 Llama 2 7B와 TinyLlama에서 확인됐고, 다른 기계에서도 재현됐습니다.