AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
로컬 모델은 외부 인공지능 서비스에 데이터를 보내지 않고 직접 실행할 수 있다. 원하는 데이터로 모델을 미세조정할 수 있고, 추측 디코딩 같은 방법을 써서 응답 속도를 더 끌어올릴 수 있다. 한 번 산 하드웨어는 글, 이미지, 음성 작업에 계속 재사용할 수 있으며, 여러 모델을 섞어 쓰는 방식도 자유롭다. 사용량이 늘어도 호출할 때마다 돈을 내는 구조가 아니기 때문에, 데이터셋을 만들고 실험하는 비용 부담이 줄어든다. 핵심 장점은 개인정보 통제, 실험 자유도, 장기적인 추론 비용 절감이다.
AI 분야에서는 새 발표, 새 규칙, 새 에이전트, 데이터를 모델에 연결하는 방식이 계속 나오지만 많은 것은 몇 주 안에 잊힌다. 오래 볼 만한 것은 특정 모델 이름이나 성능 점수보다, 거대 언어 모델로 무엇을 어떻게 만들지 바꾸는 기본 개념이다. 후보로는 모델이 외부 기능을 부르게 하는 도구 호출, 외부 문서를 찾아 답에 반영하는 검색 증강 생성, 모델의 사고 과정을 다루는 추론 흔적, 기억의 바탕이 되는 임베딩, 작은 꼼수보다 규모가 이긴다는 생각, 시스템 프롬프트와 파인튜닝의 선택 문제가 있다. 에이전트가 계획하고, 행동하고, 결과를 보고 다시 조정하는 에이전트 루프도 장기적으로 남을 수 있는 개념으로 제시된다. 도구 쪽에서는 겉을 감싸는 편한 화면이나 단순한 프레임워크보다, 실제 개발 방식을 바꾸는 낮은 수준의 기반 기술이 중요하다는 관점이다.
Freestyle은 단축키를 누른 채 말하고, 손을 떼면 커서 위치에 글자가 붙여 넣어지는 음성 받아쓰기 앱이다. 처음에는 사용자가 로컬 음성 모델을 직접 고르고, 필요하면 후처리 단계를 붙일 수 있게 만드는 데 초점을 뒀다. 지금도 로컬 모델은 쓸 수 있지만, 별도 설정을 몰라도 바로 작동하는 기본 파이프라인인 Freestyle Transcribe가 추가됐다. 현재 구성은 Whisper Large Turbo V3가 음성을 글자로 바꾸고, Qwen3-32B가 결과를 다듬는 방식이다. 이 구성은 Groq와 Cloudflare에서 운영되며, 응답 지연은 약 600~800밀리초다. Wispr Flow와 비슷한 속도를 목표로 하면서, 정확도는 더 안정적이라고 주장한다. Freestyle은 무료 오픈소스로 공개돼 Wispr Flow의 월 12달러 구독료를 피할 수 있다.
Qwen3.6 27B 모델을 여러 양자화 버전으로 돌릴 때 실제 사용에서 어떤 차이가 나는지 비교하려는 내용이다. 비교 대상은 Q4_K_M, UD-Q4_K_XL, UD-Q5_K_XL, UD-Q6_K_XL, UD-Q8_K_XL 같은 버전이다. 핵심 관심사는 더 큰 모델을 쓰기 위해 속도와 문맥 길이를 얼마나 포기해야 하는지다. 기준 하드웨어는 총 32GB VRAM을 가진 소비자용 데스크톱의 두 개 그래픽카드 구성이다. 이 구성은 합리적인 예산으로 바로 살 수 있으면서도 로컬 거대 언어 모델을 돌릴 수 있는 현실적인 선택지로 본다. 테스트는 llama.cpp와 Ubuntu 환경에서 직접 돌리는 것을 선호한다. 주된 사용 사례는 코딩과 복잡한 처리 작업이지만, 다른 실제 사용 사례나 평가 방식도 함께 검토할 수 있다.
LLM 사용량이 늘면서 비용이 계속 올라가자, 긴 프롬프트에서 불필요한 지시를 줄이고 반복되는 내용에는 캐싱을 적용했다. 그 결과 토큰 지출이 약 40% 줄었다. 문제는 비용을 줄인 뒤 답변 품질이 그대로인지 증명해야 했다는 점이다. 프롬프트를 줄이면 겉으로는 멀쩡해 보여도 답변 품질이 조용히 나빠질 수 있다. 몇 개 결과를 눈으로 확인하는 방식만으로는 충분하지 않았다. 미리 만들어 둔 평가 데이터셋과 점수 기준으로 변경 전후 결과를 비교하자 품질은 유지됐고, 한 시나리오는 약간 좋아졌지만 잡음일 가능성이 있었다. 덕분에 비용 절감 효과뿐 아니라 품질 유지도 숫자로 설명할 수 있었다.
VCCB는 달력의 주간 화면 이미지를 AI 모델에 보여주고, 일정 제목, 시작 시간, 끝 시간이나 길이, 겹치는 일정, 반복 일정, 하루 종일 또는 여러 날 이어지는 일정을 구조화된 데이터로 뽑게 하는 벤치마크다. 만든 계기는 로컬 AI 에이전트가 화면 사진에서 달력 일정을 다시 만들 때 시간을 15~30분 틀리거나, 모든 일정을 1시간짜리로 처리하거나, 옆 날짜에 중복 일정을 만드는 문제가 자주 났기 때문이다. 같은 주간 달력을 Outlook, HCL Notes, Thunderbird 세 프로그램에서 만들고, 각 화면을 깨끗한 스크린샷, 정면 사진, 약 15도 비스듬한 사진으로 준비해 한 번 실행할 때 9장의 이미지를 쓴다. 점수는 프로그램마다 화면 표현 방식이 달라서 각 프로그램 기준에 맞춰 100% 만점으로 계산한다. 초기 결과는 사람은 약 99%, Claude Opus 같은 상위 상용 모델은 약 80~85%, ChatGPT 무료급 모델은 약 75%, 로컬 모델과 Claude Haiku는 약 38~58% 수준이었다. 핵심 관심사는 같은 모델이라도 양자화 수준이 달라질 때 정확도가 얼마나 떨어지는지다. 이미지, 프롬프트, 실행 스크립트, 채점기, 정답표, 결과는 GitHub 저장소에 공개되어 있고, 로컬 모델 사용자는 자신이 실제로 쓰는 모델과 설정으로 결과를 제출할 수 있다.
2026년 6월 기준으로 H100 80GB와 A100 80GB 그래픽처리장치의 스팟·인터럽터블 가격을 RunPod, Vast.ai, AWS에서 비교했다. H100 80GB는 RunPod에서 시간당 1.80~2.40달러, Vast.ai에서 보통 1.47~2.00달러였고, 공급이 얇은 시장에서는 1.03달러까지 보인 경우도 있었다. AWS P5 스팟은 시간당 2.50~3.10달러 수준이지만 물량이 매우 적어 가격이 있어도 자주 구하기 어렵다. A100 80GB는 RunPod 커뮤니티 스팟에서 시간당 0.20~0.40달러까지 내려갈 수 있지만, 이 낮은 가격대에서는 안정성이 빠르게 떨어진다. Vast.ai의 A100은 보통 시간당 0.67달러 수준이며, 호스트 점수와 입찰 상황에 따라 더 낮아질 수 있다. AWS P4d 스팟은 시간당 약 1.00~1.50달러이고, P5 스팟보다 비교적 꾸준히 구할 수 있다. 스팟 할인은 온디맨드보다 H100에서 40~60% 저렴하고, A100에서는 더 큰 절감도 가능하지만, 공급자별 가격 차이와 안정성 차이가 온디맨드보다 훨씬 크다.
실제 업무 도구를 다루는 AI 에이전트에서는 모델 성능보다 권한 통제가 더 큰 문제가 될 수 있다. 에이전트가 환불 처리, 데이터베이스 수정, 이메일 발송, 고객 정보 조회 같은 행동을 할 수 있으면, 실수나 악용의 피해가 바로 현실 업무로 이어진다. 운영 방식으로는 넓은 서비스 토큰을 한 번 주는 방법, 고정된 OAuth 범위를 미리 부여하는 방법, 매번 작업마다 직접 권한 검사를 넣는 방법, 위험한 작업에는 사람이 승인하는 방법 등이 거론된다. 중요한 질문은 에이전트가 어떤 일을 했고, 왜 그 행동이 허용됐는지 나중에 정확히 증명할 수 있느냐다. 실서비스에서 에이전트가 하지 말아야 할 일을 했을 때 어떤 문제가 생겼는지도 핵심 관심사다.
새 프로젝트를 만들 때 코딩 에이전트를 작업 하나마다 잠깐 실행할지, 아니면 계속 켜 두고 자동으로 일을 맡길지에 대한 실전 고민이다. 계속 실행하는 방식은 반복 실행 구조나 예약 작업을 써서 이슈 처리, 테스트, 기능 제안, 기능 구현을 자동으로 돌리는 형태를 뜻한다. 핵심 질문은 이 방식이 비용과 작업 흐름 면에서 실제로 이득이 있는지다. 기대하는 이점은 더 빠른 개발, 여러 작업의 병렬 처리, 밤사이 진행되는 작업이다. 실패 지점으로는 나쁜 문맥, 환각으로 인한 엉뚱한 변경, 결과를 믿기 어려움, 시스템 안에서 무슨 일이 일어났는지 알기 어려움이 꼽힌다. 실제 운영 방식으로는 여분의 컴퓨터, Mac mini, 가상 서버, GitHub Actions, n8n, 직접 만든 조율 시스템 같은 선택지가 언급된다.
Claude가 벤치마크에서 GLM-5.2보다 좋은 결과를 내도, 그 차이가 꼭 모델 자체의 능력 차이라는 뜻은 아니다. 비교 대상이 GLM-5.2의 단순 추론 결과와 Claude라는 전체 제품일 수 있기 때문이다. Claude는 내부 reasoning traces를 숨기고 전체 대화 내용도 모두 보여주지 않으므로, 뒤에서 어떤 보조 처리가 들어가는지 외부에서는 알기 어렵다. 예를 들어 RAG로 필요한 지식을 넣거나, 입력을 미리 다듬거나, 상황에 따라 다른 system prompt를 붙이거나, 보이지 않는 도구 호출을 하거나, 특정 작업에 강한 별도 모델을 함께 쓸 수 있다. 이런 방식은 결과 품질을 크게 높일 수 있지만, 이용자는 모두 하나의 Claude API 응답처럼 받게 된다. 따라서 닫힌 모델과 공개 모델을 비교할 때, 실제로는 같은 조건의 모델 추론을 비교하는 것이 아닐 수 있다. 극단적으로는 닫힌 서비스 안에 공개 모델보다 항상 뛰어난 단일 모델이 없더라도, 제품 전체 성능은 더 좋아 보일 수 있다.
2026년 6월 공개 모델 목록에는 여러 미세조정 모델과 비용 절감에 연결될 수 있는 실행 방식이 함께 포함됐다. 미세조정 모델로 Nex-N2, Ornith-1.0, Agents-A1, Holo3.1, Tmax-27b, MusaCoder-27B, VibeThinker-3B가 언급됐다. NVIDIA는 NVIDIA-Nemotron-3-Ultra-550B-A55B, diffusiongemma-26B-A4B-it, Qwen3.6-27B, GLM-5.2, MiniMax-M3, Qwen3.5-397B-A17B에 쓰이는 NVFP4를 제시했다. AMD는 Kimi-K2.7-Code, GLM-5.2, Qwen3.5-397B-A17B, MiniMax-M3에 쓰이는 MXFP4를 제시했다. Intel의 AutoRound는 DiffusionGemma-26B-A4B, DeepSeek-V4-Pro, Gemma-4-31B-it, Gemma-4-12B-it에 적용되는 항목으로 나왔다. 그 밖에 Gemma-4-QAT, NVIDIA의 Nemotron-Labs-TwoTower-30B-A3B-Base, DeepSeek의 DeepSpec 계열인 Eagle3, DFlash, DSpark도 포함됐다.
Claude Code가 맞춤 API 기본 주소를 쓸 때 요청에 표시를 붙인다는 의혹 때문에 논쟁이 생겼다. 핵심 쟁점은 이것을 감시로 볼지, 남용을 막기 위한 일반적인 텔레메트리로 볼지가 아니다. 더 중요한 질문은 AI 에이전트 도구가 권한처럼 요청 메타데이터도 사용자에게 알려야 하는지다. 권한은 에이전트가 내 컴퓨터에서 무엇을 읽거나 실행할 수 있는지를 보여준다. 요청 메타데이터는 에이전트가 모델에 일을 보낼 때 클라이언트가 어떤 정보를 덧붙이는지를 보여준다. AI 에이전트는 파일을 읽고, 코드 저장소를 살피고, 셸 명령을 실행하고, 도구를 부르고, 로컬 문맥을 원격 모델로 보낼 수 있기 때문에 이 정보가 일반 앱보다 더 중요하다. 모든 메타데이터가 나쁜 것은 아니다. 업체는 남용, 재판매, 모델 복제 시도, 수상한 중간 경로, 정책 위반, 장애, 결제 문제, 계정 경계 문제를 찾아야 할 현실적인 이유가 있다. 다만 남용 방지 규칙 전체를 공개할 수 없더라도, 요청 단계 전체가 보이지 않는 상태로 남아서는 안 된다.
네 가지 대규모 언어 모델을 대상으로 시스템 프롬프트 추출 위험을 실제 정답 기준과 비교해 측정한다. 기준은 OWASP LLM07이다. 확인된 정보에는 어떤 모델을 썼는지, 성공률이 얼마였는지, 어떤 공격 문장을 썼는지, 어떤 방어가 효과적이었는지는 없다. 토큰 절감이나 비용 절감 결과도 포함되어 있지 않다.
한 개발자가 기존 오픈소스를 조합한 것이 아니라 처음부터 새로 설계한 그래프 기반 검색(RAG) 엔진을 공개했다. 개발자는 생화학 박사 학위를 가지고 20년 가까이 제약·바이오테크 업계에서 일해온 사람으로, 생물학 지식을 바탕으로 아키텍처를 설계했다고 밝혔다. 성능 검증을 위해 HippoRAG 2와 동일한 코퍼스(위키피디아 문단 11,656개)를 사용해 멀티홉 질의응답 벤치마크인 MuSiQue의 1,000개 질문 세트를 돌렸고, 그중 답변 가능한 496개 질문으로 점수를 냈다. 평가 지표는 SQuAD F1으로, LLM 판정 없이 토큰 단위 정밀도·재현율을 결정론적으로 계산하는 방식이다. 비교 대상은 BM25, LlamaIndex, HippoRAG2였다. 결과와 방법론, 한계점을 모두 공개했으며 정리 과정에는 AI의 도움을 받았다고 밝혔다.
인스타그램 짧은 영상을 바탕으로, 검색어에 맞는 크리에이터를 찾아주는 RAG 파이프라인이 필요하다. 예를 들어 “엄마 크리에이터”나 “곱슬머리 크리에이터” 같은 조건에 맞는 사람을 찾아야 한다. 현재 방식은 Gemini 3.1 Flash Lite로 각 영상을 요약하고, BAAI/bge-small-en-1.5 모델로 384차원 임베딩을 만든 뒤, 데이터베이스에서 여러 검색문으로 벡터 검색을 돌리는 구조다. 그다음 조건을 넘긴 영상이 많은지, 기준 점수를 넘겼는지를 보고 크리에이터 순위를 매긴다. 핵심 문제는 조건에 맞지 않는 크리에이터가 많이 잡히는 오탐이다. 평가 기준도 아직 잘 잡히지 않아, 어떤 방식으로 성능을 점검하고 개선해야 할지 정리된 접근이 필요하다.
Celesto 샌드박스에 페타바이트 규모의 오래 보관되는 저장소가 추가됐다. 이 저장소는 코딩 에이전트, 실행 하네스, 큰 파일을 다루는 작업에 쓰기 위한 것이다. AI 에이전트는 명령 하나만 실행하고 끝나는 도구가 아니라, 새 컴퓨터 환경을 실제 작업공간처럼 바꿔 쓴다. 저장소에는 코드 저장소 복사본, 설치한 의존 도구, 내려받은 브라우저, 빌드 폴더, 로그, 화면 캡처 같은 작업 흔적이 남는다. 이런 파일은 부수물이 아니라, 다음 작업에서 이어서 참고할 수 있는 작업 기억에 가깝다.
AI 에이전트가 외부 서비스를 쓸 때, 기존 API 결제 방식은 잘 맞지 않을 수 있다. 많은 API는 사람이 가입하고, API 키를 만들고, 월 구독료를 내는 흐름을 전제로 한다. 하지만 자율적으로 움직이는 AI 에이전트는 날씨 조회, 가상자산 가격 확인, 문서 분석처럼 특정 기능을 한 번만 필요로 할 수 있다. 제안된 방식은 기업이 API 기능 하나하나에 건당 가격을 붙이고, AI 에이전트가 필요할 때 찾아서 자동으로 결제한 뒤 바로 쓰는 시장형 구조다. 예로 날씨 조회는 요청 1건에 0.001달러, 가상자산 가격 조회는 조회 1회당 과금, 문서 분석기는 PDF 1개당 과금할 수 있다. 작은 기업이나 특정 데이터를 가진 회사도 구독 영업이나 긴 계약 없이 자기 데이터와 기능을 외부 에이전트에 팔 수 있다.
Claude Code로 사이트의 첫 화면 로딩과 글꼴 성능을 다듬는 중, 백그라운드에서 파일을 찾는 도구의 출력이 에이전트의 컨텍스트에 그대로 들어갔다. 그 출력 안에는 사용자가 직접 쓴 것처럼 보이는 새 지시가 섞여 있었다. 내용은 기존 성능 작업을 멈추고, 존재하지 않는 backend/middleware/rate_limit.py 파일을 열어 API 키 기준의 토큰 버킷 제한 방식으로 바꾸라는 식이었다. 실제 사용자는 그런 지시를 한 적이 없었다. 더 큰 문제는 에이전트의 내부 요약과 다음 행동이 이미 바뀌어, 원래 작업 대신 그 파일을 열고 수정하려는 상태가 됐다는 점이다. 실제 파일 수정은 일어나지 않았지만, 도구 출력에 섞인 문장이 사용자의 목소리처럼 쓰였다는 이유만으로 에이전트가 거의 따를 뻔했다. 이는 간접 프롬프트 주입이 단순히 이상한 텍스트를 읽는 문제가 아니라, 에이전트의 작업 기억과 다음 행동까지 바꿀 수 있음을 보여준다.
Opera의 브라우저 에이전트 도구 팀이 4가지 브라우저 화면 정보 형식을 비교했다. 실험은 AXI의 브라우저 벤치마크에서 가져온 7개 과제를 쓰고, 각 조건에서 5번씩 실행했다. 사용한 모델은 gpt-5.5 medium reasoning이었다. 네 형식 모두 과제 통과율은 100%로 같았다. 하지만 평균 입력 토큰은 크게 달랐다. 가공하지 않은 chrome-devtools-mcp 형식은 17만9천200개, AXI 기준 명령줄 도구는 10만2천200개, Opera의 압축 없는 원시 출력은 10만7천500개, Opera의 압축 형식인 opera-compact는 3만6천300개였다. 도구 호출 수도 opera-compact가 평균 1.4회로 가장 낮았다. 압축은 역할만 봐도 알 수 있는 ARIA 속성, 반복되는 텍스트, 계속 다시 들어가는 주소를 줄이는 방식으로 이뤄졌다. 이 도구는 opera-browser-cli와 opera-devtools-mcp로 제공되며, Apache-2.0 라이선스다.
Headroom은 인공지능 에이전트가 도구에서 받은 긴 결과를 언어 모델에 넘기기 전에 짧게 압축하는 오픈소스 도구다. 대상은 도구 출력, 실행 로그, 검색으로 가져온 문서 조각처럼 에이전트 작업에서 자주 길어지는 내용이다. 공개된 설명에서는 품질 손실을 크게 만들지 않으면서 토큰 사용을 60~95% 줄일 수 있다고 주장한다. 사용 방식은 파이썬 라이브러리, 표준 입출력 프록시, MCP 서버 세 가지다. 특히 MCP 서버 방식은 기존 도구 서버를 고치지 않고 클라이언트와 도구 사이에 끼워 넣어 응답을 자동으로 압축한다. 여러 MCP 서버를 연결해 많은 도구 호출을 처리하는 환경에서는 긴 결과를 계속 잘라내는 대신, 같은 작업 흐름 안에서 더 많은 정보를 컨텍스트에 남길 수 있다. 관련 사례들은 에이전트 비용 문제가 넓게 퍼졌음을 보여준다. 토큰 절약용 스킬, 로컬 프록시, 비용 대시보드, 캐시 최적화 도구가 함께 거론되고 있으며, 실제 500개 Claude Code 세션과 6억1400만 토큰, 926달러 기준 비용을 다시 계산해 절감 효과를 비교한 사례도 있다.
Claude Code 안에 중국 사용자나 중국 쪽 사용 경로를 가려내는 코드가 있다는 의혹이 제기됐다. 핵심 쟁점은 일반 사용자를 모두 감시한다는 주장보다, 사용자 지정 엔드포인트를 쓰는 경우 특정 시간대, 주소, 요청 형식 같은 신호를 확인할 수 있다는 점이다. 일부 사람들은 이것을 Anthropic이 중국 AI 연구소의 무단 재판매나 모델 증류를 막기 위한 장치로 본다. 다른 사람들은 중앙 서버에 의존하는 AI 도구가 지역, 정치, 회사 정책에 따라 조용히 다르게 동작할 수 있다는 점을 문제로 본다. 댓글에서는 VPN만으로는 시스템 시간대나 API 주소 같은 신호를 바꾸기 어렵다는 지적도 나왔다. 또 폐쇄형 소프트웨어를 핵심 업무에 쓰면 내부 동작을 확인하기 어렵고, 그래서 로컬 모델이나 오픈소스 도구를 더 선호해야 한다는 의견이 이어졌다.
Hermes 에이전트에서 장기 메모리는 단순히 대화 기록을 저장하는 문제가 아니다. 시간이 지나도 쓸모 있는 문맥만 남기고, 오래된 대화가 한 덩어리로 쌓이는 일을 막아야 한다. 사용자의 정보가 바뀌었을 때 예전 내용을 어떻게 고칠지, 무엇을 기억할 가치가 있는지, 메모리 계층을 에이전트 실행 부분과 어떻게 분리할지도 핵심 과제다. 최근 Mem0 업데이트, Cognee 공개, Weaviate의 Engram 같은 에이전트 메모리 도구가 이 문제를 다루고 있다. Hermes는 제공자 인터페이스 덕분에 메모리 구현을 바꿔도 에이전트 로직을 크게 고치지 않을 수 있다. Engram은 Hermes와 연결하는 플러그인 안내가 있고, 메모리 중복 제거와 관련 없는 오래된 사실 누적을 줄이는 방향으로 시험되고 있다.
약 10개의 자바 마이크로서비스에서 비슷한 로그가 여러 번 남아 비용이 커지는 문제를 다룬다. 이미 한 서비스 안에서는 비싼 로그를 찾아 유지, 축소, 등급 낮추기를 제안하는 AI 도구가 있다. 더 어려운 문제는 한 요청이 여러 서비스를 지나갈 때 같은 의미의 로그가 반복되는 경우다. 예를 들어 한 서비스가 라이선스 정보를 보냈고 다른 서비스가 그 요청을 받았다고 각각 남기면, 따로 보면 둘 다 타당하지만 전체 흐름에서는 하나가 과할 수 있다. 모든 저장소를 한 번에 LLM에 넣는 방식은 문맥 한계 때문에 현실적이지 않다. 대신 각 저장소를 따로 분석하고, 로그 양식을 정리하며, 서비스의 역할과 주요 흐름과 의존 관계를 작게 요약하고, 실제 운영 로그량과 추적/상관관계 ID로 요청 경로를 파악하는 방향이 제시된다.
Genie 공간을 만들면 팀원이 매번 SQL을 직접 부탁하지 않고도 영업과 영업 파이프라인 질문을 평범한 문장으로 물을 수 있다. 성능을 올리는 핵심은 긴 자유문 지시문을 많이 쓰는 것이 아니다. 각 정보를 알맞은 위치에 넣어 모델이 데이터 구조를 바로 이해하게 만드는 것이 더 효과적이다. 먼저 테이블과 열 설명을 정리하고, 좋은 질문과 SQL 예시를 몇 개 넣고, 테이블끼리 어떻게 연결되는지와 관계의 크기를 명시해야 한다. 자유문 지시문은 구조화해서 넣기 어려운 내용에만 마지막 수단으로 쓰는 편이 낫다. 답이 틀릴 때는 지시문을 더 붙이기보다 메타데이터 단계에서 원인을 고치는 방식이 더 중요하다. 작은 평가 기준을 만들어 질문별 기대 SQL을 정해 두고, 바꿀 때마다 결과를 확인하는 것이 도움이 된다.
AI 에이전트가 고객에게 견적, 할인, 추천 상품을 제시할 때는 그 결정 뒤에 확인 가능한 기록이 필요하다. 기록에는 사용자의 의도, 적용 가능한 할인, 특정 추천을 고른 이유, 후원 또는 제휴 여부, 공개된 안내 문구, 클릭 추적 여부, 이후 구매나 가입 같은 전환 사건, 연결된 판매자 마케팅 캠페인이 포함될 수 있다. 이런 기록은 모든 사용자에게 전부 보일 필요는 없지만, 문제가 생겼을 때 시스템이 판단 근거를 확인할 수 있어야 한다. 사용자는 추천 내용이 왜 나왔는지 물을 수 있고, 판매자는 전환율을 따질 수 있으며, 개발자는 결제 문제를 확인해야 할 수 있다. 기존 광고 시스템도 로그와 기여도 기록에 의존해 왔다. 대화 안에서 추천이 자연스럽게 섞이는 상업용 AI 에이전트는 더 많은 확인 가능성이 필요하며, 감사 가능성이 없으면 신뢰를 유지하기 어렵다.
AI 제품에서 검색은 사용자가 검색어를 넣고 결과 목록을 받는 일로 끝나지 않는다. 검색어는 시작점일 뿐이며, 시스템은 추가 질문을 하거나, 관련 검색어를 제안하거나, 특정 도구를 바로 실행할 수 있다. 때로는 할인 정보를 보여주거나, 결과가 없다는 화면을 띄우거나, 보안 확인 절차로 넘겨야 할 수도 있다. 그래서 검색 품질은 문서나 상품을 얼마나 잘 찾았는지만으로 결정되지 않는다. 더 중요한 것은 사용자의 의도에 맞는 다음 행동을 고르는 일이다. 겉으로 비슷해 보이는 두 검색어도 하나는 바로 이동이 필요하고, 다른 하나는 구매 관련 결과나 추가 확인 질문이 필요할 수 있다. AI 에이전트에서는 검색이 단순한 정보 찾기가 아니라, 어떤 경로로 일을 처리할지 정하는 의사결정 라우팅이 된다.
도구를 쓰는 거대 언어 모델 에이전트는 웹페이지, 파일, 응용 프로그램 인터페이스 같은 외부 정보를 읽다가 숨은 지시에 속을 수 있다. 이런 문제를 프롬프트 인젝션이라고 하며, 특히 에이전트가 읽은 내용을 바탕으로 실제 행동까지 할 때 위험이 커진다. Sentinel Gateway는 에이전트가 믿을 수 있는 명령과 믿을 수 없는 외부 데이터를 다른 통로로 다루게 하는 중간 계층이다. 핵심은 외부 입력을 위험한지 아닌지 맞히려 하지 않고, 실행 행동에는 서명된 권한 토큰이 있어야만 하게 만드는 것이다. 그래서 에이전트가 무엇을 보았는지와 실제로 무엇을 실행할 수 있는지를 분리한다. 구현은 FastAPI 기반 미들웨어, 실행 요청용 토큰 권한 확인, 점검용 Streamlit 화면, 에이전트 판단과 도구 사용 기록, 단일 저장소 또는 Postgres 저장소를 포함한다. Claude 기반 세션 같은 여러 에이전트 구조에도 붙일 수 있는 형태로 설계되어 있다.
코딩 에이전트가 만든 아키텍처 그림은 그냥 보기 좋은 문서가 아니라, 코드 구조를 점검하는 도구가 될 수 있다. 핵심은 Event Storming 방식으로 시스템을 시간 순서의 흐름으로 그리는 것이다. 어떤 사건이 반응을 만들고, 그 반응이 명령을 만들며, 그 명령이 다시 새 사건을 만든다. 이렇게 그리면 모든 요소에 원인과 결과가 있어야 한다는 규칙이 생긴다. 이 규칙을 이용해 에이전트는 그림을 감으로 평가하지 않고, 원인에서 결과로 이어지는 그래프를 기계적으로 검사할 수 있다. 검사기는 원인이 없는 사건, 결과 사건을 만들지 않는 명령, 아무것도 연결하지 않는 정책, 따로 떨어진 카드 같은 빈틈을 구조화된 목록으로 돌려준다. 이 방식은 에이전트에게 지치지 않고 같은 기준으로 확인하는 피드백 루프를 제공한다.
RAG 작업용 벡터 데이터베이스를 고를 때 QPS 순위만 보면 실제 운영 비용을 놓치기 쉽다. 응답이 빠른 구성이 처음에는 좋아 보여도, 메타데이터 필터링, 결과에 붙는 추가 데이터 반환, 잦은 새 데이터 입력, 여러 고객이나 팀을 나누어 쓰는 구조가 들어가면 평가가 달라진다. 트래픽이 가끔 몰리는 경우와 계속 일정하게 들어오는 경우도 비용 차이를 크게 만든다. VDBBench는 단순 속도 순위보다 실제 사용 방식에 따른 선택의 차이를 보게 해 준다. 특히 빠른지뿐 아니라 어떤 사용 패턴에서 얼마의 비용으로 빠른지를 함께 보게 하는 점이 핵심이다. 새로 넣은 데이터가 검색에 반영되는 속도, 쉬고 있다가 다시 시작할 때의 지연, 추가 데이터까지 함께 찾는 검색, 여러 사용자를 나눈 검색 같은 항목도 실제 서비스 운영에 더 가깝다.
PatSnap이 특허 문서를 대량으로 처리하기 위해 내부에서 쓰던 문서 파싱 도구 2개를 오픈소스로 공개했다. Hiro-Smart-Doc은 PDF, 오피스 문서, 이미지에서 페이지 구조를 먼저 찾고, 각 영역을 올바른 읽기 순서로 처리해 마크다운으로 내보내는 자체 호스팅 FastAPI 파이프라인이다. 페이지 안의 영역은 RT-DETR로 25가지 종류로 나누며, 여러 단으로 된 문서도 읽는 순서를 맞춘다. 표는 HTML, 수식은 LaTeX, 일반 글은 마크다운으로 정리된다. 글자 인식에는 Hiro-MOSS-OCR이 쓰이며, 이 모델은 5천만 건이 넘는 기술 문서로 처음부터 학습된 0.3B 크기의 OCR 모델이다. OmniDocBench v1.5 점수는 93.63이고, vLLM을 쓰면 RTX 4090 한 장에서 초당 58건을 처리한다고 한다. 두 도구 모두 Apache-2.0 라이선스로 공개됐다.