AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Awesome Agent Evals는 AI 에이전트를 만들고 평가할 때 참고할 자료를 모은 공개 저장소다. 논문, 블로그, 강연, 강의, 도구, 벤치마크를 포함하며, 단순 링크 모음이 아니라 각 자료가 무엇이고 왜 필요한지 짧게 설명한다. 현재 443개가 넘는 선별 링크와 146개의 깊이 있는 읽기 노트가 들어 있다. 자료 선정에는 1만 1,600개 논문 인용 관계 조사, 실무자 자료 탐색, 47개 강연과 팟캐스트 정리, 분야별 빈틈 점검이 쓰였다. 먼저 읽을 자료로는 AI 에이전트 평가 방법, LLM-as-judge, 오류 분석, 비용을 중요한 평가 기준으로 보는 논문, 벤치마크의 한계, 독립 평가의 신뢰 조건 등이 제시된다. 함께 제공되는 플레이북은 평가 기준 만들기, 결과 분석, 실행 과정 평가, 실제 상태 변화 확인, CI에서 평가를 막는 방법 같은 실무 예시를 다룬다.
개인 경험 기준으로, Odin 게임 개발용 개인 지식 베이스가 MiniMax-M3와 Kilo Code를 중심으로 만들어졌다. 핵심 구성은 오래 반복 실행해도 같은 결과를 내도록 설계한 파이썬 스크레이퍼, 공식 문서와 커뮤니티 자료를 모은 지식 베이스, 그리고 필요한 파일만 골라 읽는 하위 에이전트다. 스크레이퍼는 Skool 멤버십 자료, odin-lang.org 공식 문서, awesome-odin, Zylinski 자료를 모으고, 수집한 내용은 로컬 디스크에 남긴다. 하위 에이전트는 먼저 INDEX.md를 읽은 뒤 관련 지식 베이스 파일 2~3개만 고르고, 답변할 때 정확한 파일 경로와 줄 번호를 인용하도록 되어 있다. .kilo/skills에는 지식 베이스 검색, 코드 형식 정리, 스크레이퍼 실행, 패턴 찾기, 일일 계획, Pyright 검사 같은 6개 작업 도구가 들어 있다. 공식 문서 11쪽은 출처를 남기고 보관되며, 계획 문서는 정해진 양식으로 관리되고 직접 고치지 않는 방식이다.
AI 에이전트에 실제 업무를 맡기기 전에는 먼저 사람이 그 업무를 수동으로 충분히 이해해야 한다는 기준이 제시된다. 핵심 원칙은 수동 절차가 왜 잘 작동하는지 정확히 설명할 수 없다면 아직 자동화할 때가 아니라는 것이다. 업무를 배우는 단계와 에이전트에게 맡겨도 되는 단계를 나누는 선이 중요하다. 일상 업무에서 에이전트나 자동화를 쓰는 사람들은 어떤 업무를 넘겨도 되는지, 어떤 업무는 사람이 더 오래 직접 처리해야 하는지 판단하는 기준이 필요하다.
Reqable MCP Server는 AI 도구가 Reqable의 API 테스트 기능을 직접 사용할 수 있게 해 주는 명령줄 도구다. Dart로 만들어졌고, AI 도구와는 MCP 방식으로 연결되며 stdio로 데이터를 주고받는다. 기본 실행에는 Dart SDK 3.0 이상이 필요하고, `dart pub get`으로 의존성을 설치한 뒤 `dart run bin/main.dart`로 실행한다. Reqable의 API 주소를 직접 지정하려면 호스트와 포트를 넘길 수 있으며, 기본 호스트는 127.0.0.1이고 포트는 로컬 Reqable 설정의 프록시 포트를 우선 사용하거나 9000을 쓴다. 제공 도구는 100개가 넘으며, HTTP 테스트, 웹소켓 테스트, 환경 관리, 컬렉션 관리, 실시간 캡처, SSL 프록시, 중단점, 요청 재작성, 네트워크 속도 제한, 접근 제어 등을 다룬다. 실시간으로 잡은 요청을 cURL 명령으로 만들거나 새 API 탭으로 옮기고, 컬렉션에 추가하는 작업도 AI가 할 수 있다.
RAG 시스템은 그럴듯하게 답하지만, 실제로는 가져온 자료가 답을 뒷받침하지 못하는 문제가 자주 생긴다. 운영 중인 서비스에서는 보통 정답 데이터가 없고, GPT-4 같은 비싼 평가 모델을 매번 쓰기도 부담스럽다. cgs-rag는 이런 답변이 주어진 문맥에 제대로 근거했는지 점검하는 Python 도구다. 정답 데이터나 고급 평가 모델 없이 CPU에서 1초 안팎으로 처리하는 것을 목표로 한다. 판단에는 token-confidence, NLI entailment, cosine attribution을 섞어 하나의 위험 점수를 만든다. 모르는 것을 모른다고 답하는 경우와 근거 없이 자신 있게 지어내는 경우도 구분한다. 긴 문장으로 자연스럽게 답했지만 근거에서 벗어난 경우를 잡는 데 더 잘 맞고, 짧은 단답형 답변에는 덜 강하다. 분야마다 작은 라벨 샘플로 조정이 필요하며, pip install cgs-rag로 설치하거나 참고 앱에서 시험해볼 수 있다.
Skills Hub는 Claude Code, Codex, Cursor, Copilot, OpenClaw 같은 AI 코딩 에이전트에서 쓸 수 있는 기술 묶음 67개를 모아 둔 공개 저장소다. 각 기술 묶음은 특정 작업에 맞춘 지시문, 작업 절차, 도구 연결 방법을 담고 있다. 사용자는 저장소를 내려받은 뒤 Claude Code의 `.claude/skills/`, Codex의 `$CODEX_HOME/skills/`, Cursor의 `.cursor/skills/` 같은 정해진 폴더에 복사해 쓸 수 있다. 기술 묶음은 보안, 개발, 생산성, 테스트, 글쓰기, 중국어 콘텐츠 작업, Supabase, 데브옵스, 웹사이트 생성 같은 범주로 나뉜다. 예시로 AI 에이전트 설계 패턴, API 명세 작성, 코드 정리, 단위 테스트 생성, 전자메일 작성, 긴 문서 요약, 보안 점검 관련 기술 묶음이 포함되어 있다. MCP 서버를 찾는 사람을 위해 별도 MCP Registry도 연결해 둔다. 저장소는 MIT 라이선스이며, GitHub 기준 별 27개, 포크 1개, 공개 릴리스는 아직 없다.
AI 에이전트 작업 흐름에서는 토큰 사용량이 빠르게 늘어날 수 있다. 특히 도구 호출, 재시도, 계획 단계, 긴 문맥 창이 비용을 키우는 주요 후보로 제시된다. 실제 운영 환경에서 AI 에이전트를 돌릴 때 어떤 부분이 토큰을 가장 많이 쓰는지가 핵심 질문이다. 이는 에이전트 비용을 줄이려면 먼저 사용량이 커지는 지점을 찾아야 한다는 문제의식과 맞닿아 있다.
AI 메모리 시스템은 질문에 대한 최종 답변만 평가하면 실제로 필요한 정보를 잘 찾아왔는지 알기 어렵다. PrecisionMemBench는 답변을 생성한 뒤 평가자가 채점하는 방식 대신, 미리 정해 둔 믿음 식별자와 실제로 찾아온 항목이 얼마나 겹치는지로 정밀도와 재현율을 계산한다. 그래서 평가자 프롬프트, 의미가 같은지 판단하는 규칙, 업체가 자기 방식에 맞게 조정할 수 있는 별도 채점층을 빼는 것이 핵심이다. 이 벤치마크는 89개 사례로 구성되어 있고 오픈소스로 공개됐다. 업체가 직접 점수를 제출하는 방식이 아니라, 평가 도구가 각 업체의 래퍼를 실행해 결과를 공개하는 구조다. 공개된 표에서는 tenure가 43개 활성 테스트를 모두 통과했고 평균 정밀도와 평균 재현율이 모두 1.00이었다. 다른 시스템들은 재현율이 높아도 정밀도가 낮은 경우가 많았고, 검색 속도와 데이터 넣는 시간도 큰 차이를 보였다.
Haystack은 실제 서비스에 넣을 수 있는 AI 에이전트와 RAG 앱을 만들기 위한 오픈소스 프레임워크다. 검색, 추론, 메모리, 도구 사용 같은 단계를 조립해 하나의 AI 작업 흐름으로 만들 수 있다. OpenAI, Anthropic, Mistral, Hugging Face, Weaviate, Pinecone, Elasticsearch 같은 여러 도구와 연결할 수 있어 한 회사 기술에만 묶이지 않는 구성을 목표로 한다. 같은 조립식 구성요소로 시제품을 만들고, 테스트하고, 운영 환경에 배포하는 흐름을 지원한다. 파이프라인은 저장과 재사용이 가능하고, 클라우드에 덜 묶인 구조와 Kubernetes 배포, 로그, 모니터링 안내를 내세운다. 활용 분야는 RAG, AI 에이전트, 이미지·음성까지 다루는 멀티모달 AI, 대화형 AI, 콘텐츠 생성이다.
약 26권의 밀도 높은 기술 서적을 대상으로 로컬 검색 증강 생성 평가가 진행됐다. 책에는 공식, 표, 정확한 숫자와 매개변수가 많아서 숫자 하나를 잘못 옮기는 것도 큰 실패로 본다. 환경은 Strix Halo와 128GB 메모리이며, Ollama로 모두 오프라인에서 돌렸다. 평가는 두 단계로 나뉜다. 검색 단계는 Recall@8이 100%, MRR이 약 0.98로 거의 해결된 상태다. 문제는 답변을 평가하는 LLM 심판 단계다. 답변 생성 모델은 qwen3.5:122b이고, 심판 모델은 자기 편향을 줄이려고 다른 계열인 llama3.3:70b-q8을 썼다. 4권, 약 80개 질문 기준 평균은 정답성 약 91%, 관련성 약 89%, 충실도 약 60%, 환각률 약 10%였다. 정답성이 91%인데 충실도가 60%라는 결과는 잘 맞지 않아서, 답변이 근거 없는 세부 내용을 덧붙였거나 심판 모델이 답변을 작은 주장들로 나눈 뒤 너무 엄격하게 평가했을 가능성이 있다. 아직 사람 손으로 만든 정답 라벨과 비교해 심판 모델 자체를 검증하지 않았고, Cohen's kappa 같은 방법으로 실제 검증을 해 본 사람이 있는지, 추론형 심판 모델이나 Llama 4가 더 나은지 궁금해하는 상황이다.
하나의 고정된 메모리 모델을 한 번 학습해 두고, 여러 LLM과 함께 쓰려는 실험이다. 조건은 메모리 모델과 선택한 LLM이 같은 숨은 상태 의미 체계를 써야 한다는 점이다. 다른 작은 모델이 두 모델 사이의 숨은 상태를 번역하는 역할을 맡는다. 이 번역 모델은 수십 메가바이트 정도의 작은 크기를 목표로 하며, 이미 저장소에서 내려받아 쓸 수 있는 형태도 상정한다. 아이디어의 출발점은 Titans 메모리 논문과, 작은 모델로 숨은 상태를 번역하려는 RescursiveMAS 쪽 작업이다. 목표는 벡터 데이터베이스, MCP 도구, 복잡한 프롬프트에 기대지 않고 LLM에 더 나은 메모리를 붙이는 것이다. 현재 결과에 오류가 있는지 확인하기 위해 저장소를 공개하고, 직접 깨뜨려 보거나 반례를 찾아 달라고 요청하고 있다.
인공지능 에이전트는 잘 짜인 시연에서는 좋아 보이지만, 실제 업무에 넣으면 쉽게 무너질 수 있다는 문제의식이 담겨 있다. 흔한 예제는 문서 요약이나 표 질의응답처럼 단순해서, 복잡한 회사 업무에 어떻게 연결할지 판단하기 어렵다. 대상 업무는 영업 운영 흐름이다. 고객관리시스템, 여러 내부 도구, 사람이 직접 넘겨주는 단계가 섞여 있고, 절차도 제대로 문서화되어 있지 않다. 이런 환경에서 에이전트가 일부 업무라도 맡을 수 있다면 매력적이지만, 아직은 큰 기업의 실험 수준을 벗어나기 어렵다는 의심이 있다. 실제 운영 환경에 배포된 사례, 사용한 도구나 플랫폼, 맡긴 업무, 실패하거나 기대에 못 미친 지점 같은 구체적인 경험이 필요하다.
맥에서 파일을 모아 두고 그 내용에 대해 대화하듯 질문하는 로컬 문서 관리 앱을 테스트했다. 같은 30개 문서 묶음과 같은 20개 질문을 여러 작은 모델에 넣어, 이미 아는 정답과 비교했다. Apple Intelligence 모델은 의료와 법률 문장을 제한하는 경우가 있어, MLX에서 돌아가는 다른 모델들이 실제 문서 질문에 얼마나 답할 수 있는지 비교했다. Qwen3 4B가 정답률 83.3%로 가장 높았고, 응답 시작 전 지연은 5.3초, 처음 불러오는 시간은 6.3초, 크기는 2.3GB였다. Llama 3.2 3B는 정답률 72.2%, 크기 1.8GB로 더 작고 빨랐으며, Phi-3.5 mini는 66.7%였다. Qwen3 8B는 더 큰 4.6GB 모델인데도 정답률이 72.2%에 그쳐 Qwen3 4B보다 낮았고, 처음 불러오는 시간도 19.5초로 길었다. Apple FM은 정답률 66.7%, 지연 2.8초, 처음 불러오는 시간 5.5초였다. 다음 비교는 더 큰 법률·의료 문서 묶음과 Qwen3.5 계열 모델로 넓어질 예정이다.
REAP는 코딩 에이전트를 평가하는 벤치마크를 실제 서비스 사용 과정에서 자동으로 모으는 방법으로 제시된다. 핵심은 사람이 일부러 시험 문제를 만드는 대신, 실제 업무 중에 코딩 에이전트가 마주친 상호작용을 평가 자료로 바꾸는 데 있다. 공개된 정보만으로는 성능 수치, 비용 절감 폭, 적용 절차, 사용 가능한 코드 공개 여부는 확인되지 않는다.
소규모 미디어 회사가 문서, 조사 자료, 과거 이메일 같은 내부 지식을 한곳에 모아 직원들이 쉽게 묻고 찾을 수 있는 ‘중앙 두뇌’를 만들려는 상황이다. 목표는 과거 작업에서 나온 주제, 아이디어, 조사 결과를 다시 찾아 새 기획에 활용하는 것이다. 이 시스템은 Claude 같은 인공지능 도구와 연결되어, 직원이 특정 주제를 다룰 때 예전 자료와 발견점을 함께 보여줄 수 있어야 한다. 새 작업물이 Google Drive나 로컬 드라이브에 추가되면 자동으로 이 지식 저장소에도 들어가고 검색 가능해야 한다. 필요한 수준은 개인용 노트 도구보다 더 튼튼하지만, 비용이 낮고 배포와 유지보수가 쉬운 방식이다. Claude가 제안한 기본안은 AWS Bedrock의 관리형 RAG 서비스처럼 자료 수집, 검색, 인공지능 연결을 대신 처리해 주는 방식이다.
프롬프트 캐싱은 같은 앞부분을 다시 보낼 때 비용을 줄여 주는 방식이다. 하지만 주요 대형 언어 모델 제공사들은 이 기능을 가격표, 문서, API 안내에 흩어 놓아 실제 서비스 비용에 미치는 영향을 쉽게 알기 어렵다. 거의 같은 내용의 프롬프트라도 순서가 다르면 실행 비용이 크게 달라질 수 있다. 사용자 질문, 변수, 시간 정보, 요청마다 바뀌는 메타데이터를 앞에 두면 캐시가 기대하는 고정 접두부가 깨질 수 있다. 실무 규칙은 반복되는 내용을 먼저 두는 것이다. 시스템 지시문, 고정 규칙, 예시, 스키마, 출력 형식 요구사항을 앞에 놓고, 사용자 입력과 요청마다 달라지는 데이터는 뒤쪽에 두는 편이 비용 절감에 유리하다. 대규모로 LLM을 쓰는 제품에서는 이런 작은 프롬프트 구조 차이가 토큰 비용과 투자 대비 효과를 크게 바꿀 수 있다.
고정된 테스트 데이터로만 인공지능 응답을 평가하면 실제 서비스에서 생기는 품질 문제를 놓칠 수 있다. 코드 변경 때마다 미리 준비한 입력 데이터로 응답을 채점하고, 기준점보다 낮으면 배포를 막는 방식은 여러 품질 저하를 미리 잡는 데 도움이 됐다. 하지만 실제 사용자 요청의 말투와 내용이 시간이 지나며 바뀌자, 테스트 데이터에 없던 유형에서 응답 품질이 몇 주 동안 조용히 나빠졌다. 자동 테스트는 계속 통과했기 때문에 문제가 늦게 드러났다. 그래서 실제 운영 트래픽에서 나온 응답을 일부 또는 전부 뽑아 직접 채점하는 온라인 평가가 필요해졌다. 고민은 모든 요청을 채점할지 일부만 샘플링할지, 어느 정도 사용량부터 비용이 부담되는지, 품질 하락 알림을 어떻게 잡음 없이 받을지다.
모바일 앱에서 Qwen 3 4B 같은 작은 언어 모델을 직접 실행하려고 하면 응답 속도가 큰 문제가 될 수 있다. Qwen 1.5B와 Phi-4 mini는 결과 품질이 좋지 않았고, 응답이 같은 말을 반복하는 문제가 있었다. Qwen 3 4B에서는 추론 과정을 건너뛰기 위해 빈 think 태그를 강제로 넣고, 약 1만 8천 토큰짜리 프롬프트 캐시를 사용했다. 전체 프롬프트는 2만 토큰보다 작지만, 캐시가 큰 이유는 모델에 많은 조건과 설정값을 전달하기 위해서다. 이런 선택은 기기 안에서 더 빠르게 돌리기 위한 것이지만, 아직 응답 하나를 만드는 데 2~3분이 걸린다. 목표는 사용자가 입력한 뒤 1분 안에 답을 받는 것이다.
미국 연방대법원의 출생시민권 판결문인 Trump v. Barbara는 194쪽짜리 긴 문서다. 다수의견, Jackson의 보충의견, Kavanaugh의 일부 동의·일부 반대 의견, 그리고 세 개의 반대의견이 함께 들어 있다. 같은 “관할권에 속한다”라는 표현도 어느 의견 안에서 읽느냐에 따라 뜻이 달라진다. 그래서 단순히 비슷한 문장을 찾아 붙이는 방식으로는 내용을 섞어 잘못 답하기 쉽다. PageIndex는 이 문서를 벡터 없는 방식과 트리 기반 구조로 다뤘고, 서로 다른 의견과 문서 구역을 구분해 찾아가는 점이 강점으로 드러났다. 예를 들어 Kavanaugh의 근거와 다수의견의 근거를 비교할 때, 비슷한 표현을 한데 섞지 않고 알맞은 의견과 구역으로 이동했다. 답변마다 특정 쪽과 문서 블록을 가리켜서, 실제 PDF를 열어 확인할 수 있었다.
여러 번의 대화를 기억해야 하는 에이전트 메모리 실험에서, 단순히 모든 내용을 벡터 인덱스에 넣는 방식이 뚜렷한 우위를 보이지 않았다. 실험은 LoCoMo라는 실제 다회차 대화 자료로 진행됐고, 약 5,900개의 대화 차례와 답할 수 있는 질문 1,531개가 쓰였다. 비교 대상은 최근 대화만 보는 방식, BM25, 두 가지 임베더, 그리고 BM25와 각 임베더를 RRF로 섞은 방식이었다. 최근 대화만 보는 방식은 점수가 약 0.024로 매우 낮았고, 10개 대화 모두에서 졌다. 필요한 정보가 오래된 대화에 있는 경우가 많아서, 마지막 몇 개 대화만 남기는 방식은 다회차 메모리에 약했다. 강한 임베더를 쓴 단일 벡터 인덱스도 BM25와 비슷한 수준이었다. mxbai-embed-large는 0.526, BM25는 0.552였고, 통계적으로 뚜렷한 차이라고 보기 어려웠다. 핵심 결과는 값싸고 직접 운영하기 쉬운 BM25와 임베더를 함께 쓰는 하이브리드 방식이 더 나은 선택일 수 있다는 점이다.
인공지능 에이전트가 오래 보관하는 메모리에 잘못 만든 사실이 들어가면, 그 정보가 나중에 다시 꺼내지고 몇 주 동안 반복될 수 있다. 모델이 스스로 높은 확신 점수를 붙여도 안전하지 않다. 확신이 높아도 원문에 없는 내용을 사실처럼 만들 수 있기 때문이다. 해결 방식은 어떤 주장도 확신 점수만으로 durable memory에 넣지 않는 것이다. 먼저 그 주장이 근거로 든 문장이 실제 원문 안에 있는지 source-grounding check를 한다. 문장 부호나 형식이 조금 달라도 찾을 수 있도록 문자열 비교와 토큰 겹침 확인을 함께 쓴다. 근거가 원문에서 확인되지 않으면 그 주장은 자동 저장하지 않고 사람이 볼 수 있는 후보 신호로만 남긴다. 예측, 약속, 거래 위험처럼 영향이 큰 주장은 원문 근거가 있어도 별도 확인이나 사람 검토가 필요하다. 다만 원문에 같은 문장이 있다는 것은 인용이 존재한다는 뜻일 뿐, 그 해석이나 추론까지 맞다는 뜻은 아니다.
OKF는 Open Knowledge Format의 줄임말로, 구글 클라우드가 2026년 6월 12일 공개한 AI 에이전트용 공개 형식이다. 핵심은 코드베이스나 시스템 설명을 매번 AI 에이전트에게 다시 입력하지 않고, 프로젝트 안에 `.okf/` 폴더를 두어 지식 파일을 쌓는 것이다. 각 파일은 마크다운으로 쓰고 YAML frontmatter를 붙이며, 필수 항목은 `type` 하나뿐이다. 별도 SDK, 스키마 등록소, 특정 회사 도구에 묶이는 벤더 종속 없이 파일만 있으면 된다. CLAUDE.md나 AGENTS.md처럼 한 장짜리 안내문을 두는 방식과 달리, OKF는 관련 개념끼리 마크다운 링크로 연결되는 지식 그래프에 가깝다. 이 파일들은 코드와 함께 깃에서 버전 관리할 수 있고, Claude Code, Cursor, Codex 같은 여러 에이전트가 함께 읽는 것을 목표로 한다. RAG와의 차이도 중요하다. OKF는 사람이 정리한 프로젝트 지식을 오래 유지하는 데 맞고, RAG는 많은 문서에서 필요한 내용을 찾아오는 문제에 더 맞는다는 관점이다.
LongMemEval은 AI 메모리 시스템을 평가하는 데 쓰이지만, 이제 신뢰하기 어렵다는 비판을 받고 있다. 이 벤치마크는 2024년 말에 나왔고, 주로 채팅 기록을 읽고 질문에 답하는 능력만 본다. 실제 메모리 시스템은 오래된 정보 저장, 필요한 정보 찾기, 잘못된 기억 피하기 등 더 넓은 일을 해야 하므로 평가 범위가 좁다. 최근 상위 점수는 90~95%에 몰려 있어 제품이나 모델의 차이를 잘 가르지 못한다. 더 큰 문제는 평가 방식이 충분히 공개되지 않은 높은 점수가 관심을 더 많이 받는다는 점이다. 예를 들어 실행 방법을 자세히 밝힌 81.5% 점수보다, 방법 설명이 부족한 95% 최고 성능 주장이 더 큰 관심을 받을 수 있다. 그래서 신뢰할 수 있는 기관이 숨겨진 시험 세트와 정해진 모델 목록으로 운영하는 새 메모리 벤치마크가 필요하다는 주장이 나온다.
결정적 인공지능은 같은 질문을 넣으면 같은 답이 나와야 한다는 요구를 뜻한다. 답이 달라진다면 단순한 무작위성이 아니라, 설정 변경이나 입력 차이처럼 설명할 수 있는 이유가 있어야 한다. 하지만 온도를 0으로 낮춰도 같은 프롬프트에서 다른 답이 나오는 경우가 있다. 그래서 지금 실제로 쓸 수 있는 방법이 무엇인지, 같은 입력에 같은 출력을 얼마나 안정적으로 보장하는지, 운영 환경에서도 쓰이는지 아니면 평가와 연구용에 가까운지가 핵심 쟁점이다.
RAG는 AI가 기억만으로 답하지 않고, 먼저 관련 문서를 찾아 그 내용을 바탕으로 답하게 만드는 방식이다. LLM은 학습할 때 본 정보만 알고 있어서, 회사 문서나 최신 정보처럼 학습 밖의 질문을 받으면 확신 있게 틀린 답을 만들 수 있다. 이를 환각이라고 한다. RAG는 문서를 작은 조각으로 나누고, 각 조각을 embeddings라는 숫자 표현으로 바꾼 뒤, vector database에 저장한다. 질문이 들어오면 semantic search가 단어가 똑같은지만 보지 않고 의미가 가까운 문서 조각을 찾는다. 찾은 문서 조각은 LLM에 컨텍스트로 함께 전달되고, LLM은 그 자료를 근거로 답을 만든다. 핵심은 질문과 문서가 vector space 안에서 의미상 가까운 위치를 찾도록 만드는 것이다.
운영 중인 AI 에이전트나 여러 단계로 이어지는 LLM 워크플로에서는 비용과 실패 원인을 빠르게 파악하기 어려운 경우가 있다. 예를 들어 어느 워크플로 비용이 갑자기 3배로 늘었는지, 그중 어떤 단계가 비용 급증을 만들었는지 바로 알기 어렵다. 특정 고객이나 특정 워크플로가 비정상적으로 많은 재시도를 만들고 있는지도 중요한 확인 지점이다. 예산을 쓰면서도 실제로는 진행을 만들지 못한 워크플로를 찾아내는 일도 필요하다. 실패가 실제 고객 결과에 영향을 줬는지까지 연결해서 보는 것도 핵심이다. AI 워크플로가 복잡해질수록 기존 로그, 대시보드, 관측 도구만으로는 이런 질문에 충분히 빠르게 답하지 못할 수 있다.
회사 업무에 쓰이는 AI 에이전트가 이메일을 보내거나, 파일을 지우거나, 코드 저장소를 바꾸거나, 운영 중인 시스템을 건드릴 수 있으면 큰 위험이 생긴다. 데모에서는 중요한 순간마다 에이전트가 사람에게 허락을 구할 것이라고 가정하기 쉽다. 하지만 실제 회사 환경에서는 프롬프트만 보안 경계로 삼는 방식이 CISO 검토를 통과하기 어렵다. 실수로 중요한 작업을 망치거나, 민감한 정보가 새거나, 도구가 잘못 쓰일 수 있기 때문이다. OpenClaw와 Hermes 같은 에이전트 도구가 회사 안에서 실제 일을 처리하기 시작하면 이 문제가 더 커진다. 더 나은 프롬프트보다, 매 단계마다 에이전트가 어떤 권한을 가질지 정하는 런타임이나 제어 평면이 필요하다는 접근이 제시된다. Tandem 데모에서는 에이전트가 이메일 초안을 만들지만, 보내기 직전에 런타임이 멈추고 사람의 승인을 기다린 뒤, 감사 기록을 남기고 작업을 이어간다.
AI 에이전트를 프로덕션 데이터베이스인 Postgres에 연결하려면 여러 위험을 먼저 풀어야 한다. 공식 데이터베이스 MCP나 직접 연결을 주면 에이전트가 운영 환경에서 SQL을 마음대로 실행할 수 있어, 잘못된 명령 하나로 데이터를 지우거나 고객 정보를 노출할 수 있다. 프롬프트 인젝션이 섞이면 에이전트가 의도하지 않은 위험한 요청을 따를 수도 있다. 모든 조회마다 안전한 도구나 전용 화면을 직접 만들면 통제는 가능하지만, 작업량이 크고 데이터 구조가 바뀔 때마다 다시 고쳐야 한다. 읽기 전용 복제 데이터베이스는 조회 위험을 줄이지만, 실제로 필요한 쓰기 작업에는 도움이 되지 않는다. 핵심 쟁점은 파괴적인 SQL 차단, 개인정보 숨김, 안전한 쓰기 처리, 에이전트 작업 기록 남기기다.
오픈 모델이 닫힌 상용 모델보다 약 4개월 뒤처졌다는 말에 의문을 제기하는 경험이다. 코딩 작업에서 오픈 모델을 써 보면, 상용 모델에서는 거의 겪지 않는 이상한 문제가 생긴다는 내용이다. 예시로 GLM5.2에 Gemma용 Unsloth Studio를 Docker Compose로 구성하라고 시켰지만, 계속 생각을 길게 이어가고 같은 내용을 반복했다. 추론 강도를 높게 둔 상태였고, 결국 작업을 끝내지 못해 중단했다. Cursor에서는 비슷한 요청을 하면 뒤에서 브라우저까지 활용해 필요한 정보를 찾고 계속 진행하지만, Zoo Code에서는 그렇게 되지 않았다는 비교도 있다. 오픈 모델과 상용 모델을 자주 비교하는지, 그리고 Zoo Code, Opencode, Cline 같은 에이전트 실행 도구를 무엇으로 쓰는지도 묻고 있다.
GitHub·GitLab·Codeberg에 공개된 순수 파이썬 프로젝트가 역전파(backpropagation)나 그래디언트, 가중치 전달 없이 오직 로컬 규칙만으로 학습하는 새로운 AI 학습 방식을 시연한다. 모든 학습이 하나의 그래프 위에서 이루어지며, 거의 모든 하드웨어에서 돌아갈 만큼 가볍다. 대표 시연으로는 카드 셔플 순서를 맞히는 문제가 있는데, 기존 LLM이 잘 풀지 못하는 52장 전체 카드 셔플 문제를 처음부터 2초 이내로 학습해서 풀어낸다. 짧은 예시로만 학습했음에도 긴 순서 전체를 정확히 맞힌다. 또한 나쁜 데이터로 먼저 잘못 학습시켜도, 그 위에 제대로 된 데이터로 다시 학습시키면 기존에 배운 내용을 잃지 않으면서 올바르게 이해하도록 회복시킬 수 있다. 이 프로젝트에는 작은 데모 세 가지가 포함되어 있는데, 첫 번째는 문자나 단어 더미를 세는 방식으로 숫자 개념을 익힌 뒤, 덧셈을 한 번도 직접 배운 적 없이도 두 수를 더할 수 있게 된다.