AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
작은 챗봇을 만들면서 예상보다 문서 쪼개기 방식이 결과에 큰 영향을 줬다. 좋은 답을 만들려면 대형 언어 모델 자체보다 필요한 정보를 제대로 찾아오는 검색 품질이 더 중요할 때가 많았다. 임베딩은 여러 검색 결과를 직접 비교하고, 그 결과가 답변을 어떻게 바꾸는지 확인한 뒤에야 이해하기 쉬워졌다. 처음에는 프롬프트를 잘 쓰는 일이 가장 어려울 것이라고 생각했지만, 실제 시간은 관련 정보가 왜 검색되지 않는지 찾고 검색 방식을 개선하는 데 더 많이 쓰였다. Python, LangChain, Qdrant로 만든 첫 RAG 챗봇 경험에서는 답변 문장보다 답변에 넣을 자료를 고르는 과정이 핵심 문제였다.
LiquidAI가 LFM2.5 기반의 3억5천만 파라미터 검색 모델 2종을 공개했다. LFM2.5-Embedding-350M은 문서마다 하나의 벡터를 만들어 빠르게 검색하는 모델이며, 11개 언어를 오가는 검색에 맞춰져 있다. 같은 크기의 밀집 임베딩 모델 중 다국어 정확도가 높다고 소개된다. LFM2.5-ColBERT-350M은 문서의 각 토큰마다 벡터를 저장하고, 질문과 문서의 잘 맞는 부분을 비교해 더 정밀하게 찾는 방식이다. 예를 들어 영어 상품 설명을 저장해 두고도 여러 언어의 질문으로 찾아낼 수 있다고 한다. 두 모델 모두 효율적인 LFM2 구조 덕분에 더 작은 모델과 비슷한 추론 속도를 낸다고 설명된다. 기존 검색 증강 생성 파이프라인에 바꿔 끼워 쓸 수 있는 GGUF 형식 모델이 Hugging Face에 공개되어 있다.
tokless는 Antigravity에서 코딩 에이전트의 토큰 사용과 문맥 창 부담을 줄이기 위한 오픈소스 도구 묶음이다. 복잡한 플러그인 설정 없이 한 줄 명령을 실행한 뒤 Antigravity를 선택하면, 통합 개발 환경과 명령줄 환경이 함께 설정된다. 설정 뒤에는 에이전트를 다시 시작하면 된다. 포함되는 도구는 코드 구조를 찾는 CodeGraph, 터미널 출력에서 필요한 부분만 걸러내는 RTK, 작업 실행을 제한된 환경에서 다루는 Context-Mode, 에이전트 답변을 짧게 만드는 Caveman이다. 목표는 비전문가도 코딩 에이전트의 토큰과 문맥 사용량을 줄이는 설정을 쉽게 적용하게 하는 것이다. 호환성 문제가 있으면 GitHub 이슈로 알릴 수 있다.
자체 서버에서 RAG를 운영할 때 Milvus는 성능이 좋은 벡터 데이터베이스지만, 규모가 커지면 운영 구성이 무거워질 수 있다. 실제 운영에서는 Milvus의 분산 구조를 쓰게 되고, 이때 Kubernetes, etcd, MinIO 같은 저장 장치, 메시지 큐까지 함께 준비해야 한다. 인터넷이 막힌 환경, 현장 장비, Kubernetes를 운영하고 싶지 않은 작은 팀에는 이 준비 작업 자체가 큰 장벽이 된다. Actian 쪽 벤치마크에서는 VectorAI DB가 외부 의존 없이 단일 Docker 컨테이너로 실행되고 인터넷도 필요 없다는 점을 차이로 내세운다. 같은 장비에서 100만 개 벡터와 768차원 조건으로 비교했을 때 VectorAI DB는 Milvus보다 처리량이 높았고, 색인 불러오기도 73% 빨랐다고 제시됐다. 다만 정확도에 해당하는 재현율은 Milvus가 0.9983으로, VectorAI DB의 0.9948보다 높았다. 또 비교는 Milvus 분산형이 아니라 독립 실행형 기준으로 진행된 점을 감안해야 한다.
Claude Code 안에서 하나의 답만 받는 대신, 세 개의 에이전트가 서로 다른 역할로 아이디어를 검토하는 방식이다. Visionary는 새 아이디어를 만들고, Destroyer는 그 아이디어의 약한 전제와 허점을 공격하며, Synthesizer는 두 관점을 합쳐 더 버티기 쉬운 대안을 만든다. 이 과정은 여러 단계로 강도를 높이며 반복되고, 나중에는 역할을 바꿔 서로 반대 입장도 맡는다. 각 단계 뒤에는 내부 검증자가 주장, 숨은 가정, 반대 근거, 편향, 놓친 부분을 점검한다. 점수가 10점 만점에 8점보다 낮으면 다시 반복한다. 목표는 하나의 LLM이 흔히 내놓는 평균적인 답을 줄이고, 여러 관점이 부딪히면서 더 색다른 해결책을 찾는 것이다. 예시로 CLI 도구의 바이럴 성장 장치를 찾는 작업에 이 방식을 적용했다.
Docling으로 논문 PDF를 로컬에서 파싱할 때, 25쪽을 넘는 파일에서 전처리 단계가 실패했다. 실패한 쪽은 25~28쪽으로 표시됐고, 오류 이름은 std::bad_alloc이었다. 사용한 노트북은 RTX 4060 8GB, 램 16GB, i5-12450HX 사양이었다. 실행 중 GPU 사용률은 95%, 램 사용률은 80%였고, 남은 램은 약 3GB였다. PDF를 20쪽 단위로 나누어 처리하면 진행은 되지만, PDF 30개를 처리하는 데 약 45분이 걸렸다.
웹 개발 경험이 있는 사람이 빠르게 돈을 벌기 위해 동네 카페용 작은 웹 앱을 만들었다. 대부분의 코드는 직접 쓰지 않고 Claude Code가 만들었으며, 아이디어를 설명하자 약 40분 만에 작동하는 SvelteKit 데모가 나왔다. 데모는 개인 서버에 올렸고, 각 카페마다 하위 도메인을 따로 만들어 카페 이름과 로고가 바로 보이게 했다. 세 곳의 카페를 직접 찾아가 말로만 설명하지 않고 바로 눌러볼 수 있는 데모를 보여줬다. 첫 번째 카페 주인이 5분 안에 구매를 결정했고 가격은 700달러였다. 판매된 앱 자체는 AI 에이전트가 아니라 일반 웹 앱이다. 손님은 테이블의 QR 코드를 찍고, 앱은 테이블 번호를 읽어 휴대폰 주문을 받는다. 주문은 테이블 번호와 메뉴 항목이 함께 직원용 주문 관리 화면에 표시되어, 직원이 주문을 종이에 적으러 올 때까지 기다릴 필요가 줄어든다.
Claude 에이전트를 더 빠르고 적은 토큰으로 원하는 결과에 가깝게 만드는 자체 조정 방식의 작업 흐름이다. 핵심은 작업 세션의 성과를 살펴보고, CLAUDE.md, 스킬, 에이전트 설정을 바꾸는 제안을 자동으로 만드는 것이다. 이 흐름은 언제 자동으로 실행할지, 얼마나 자주 조정할지, 어떤 설정을 저장할지도 다룬다. 메모리 관리도 포함한다. 도움이 된 기억은 더 오래 쓰도록 올리고, 틀렸거나 쓸모없는 기억은 줄이거나 지운다. 목표는 사용자가 매번 직접 설정을 손보지 않아도 Claude 에이전트가 시간이 지날수록 더 효율적으로 일하게 만드는 것이다.
CLAUDE.md 파일을 8개 핵심 구역으로 나누어 Claude에게 프로젝트 정보를 더 분명하게 주는 방식이다. 목표는 Claude가 코드를 만들거나 프로젝트를 도울 때 엉뚱한 구조를 만들지 않게 하는 것이다. 프로젝트의 배경, 원하는 설계 방향, 사용할 도구, 코드 작성 규칙, 제약 조건을 미리 적어 두면 Claude가 매번 같은 기준으로 판단하기 쉬워진다. 그 결과 필요 없는 설명과 수정 요청이 줄어 토큰 낭비를 줄일 수 있다. 이 방식은 코드 품질 관리, 문맥 유지, 디버깅, 배포 준비 같은 작업에 도움이 되는 중급 수준의 워크플로로 소개된다. 항목 자체의 평가값은 워크플로 가치 85/100, 신선도 70/100, 신뢰도 0.90이며 상태는 active로 표시되어 있다.
TinyHarness는 Ollama를 기본으로 쓰는 로컬 우선 AI 코딩 도우미다. 사용자가 따로 선택하지 않으면 코드가 외부 서비스로 나가지 않아, 사내 코드나 개인 프로젝트를 다룰 때 부담을 줄일 수 있다. 긴 작업 중 대화 기록이 너무 커지는 문제를 줄이기 위해 도구 실행 결과를 이어 붙이고, 시스템 프롬프트를 짧게 유지하며, 대화 내용을 단계적으로 압축하는 기능을 제공한다. 이 압축 방식은 100만 토큰 규모의 긴 대화도 6만 4천 토큰 한도의 모델로 줄여 다룰 수 있게 하는 것을 목표로 한다. 0.2.0 버전에는 채팅, 실시간 프로젝트 구조, 파일 트리를 한 화면에서 보는 터미널 화면이 추가됐다. Nix 설정 파일, /image 명령을 통한 이미지 입력, cargo install TinyHarness 설치 방식도 제공된다.
몇 달 동안 Codex와 Claude Code 같은 AI 코딩 에이전트 작업 방식을 계속 다듬은 결과, 복잡한 저장소나 프레임워크보다 단순한 문서 중심 흐름이 더 오래 남았다. 핵심은 AGENTS.md를 기준 문서로 두고, /docs 폴더에 10~30개의 작은 문서로 세부 지식을 나누는 방식이다. 이 문서들은 아키텍처 결정, 좋은 개발 습관, 코딩 규칙, AI가 피해야 할 일, 특정 업무 지식을 담는다. 문서가 너무 커지면 오케스트레이션 파일로 바꾸고 내용을 더 작은 파일들로 쪼갠다. 이렇게 하면 AI가 매번 거대한 지식 묶음을 읽지 않고, 지금 할 일에 필요한 문서만 읽게 된다. 작업 전에는 검증 단계를 먼저 돌려서 에이전트가 일을 시작하기 전에 필요한 점검을 하려는 흐름도 포함되어 있다.
turbopuffer의 월 기본 가격이 64달러에서 16달러로 내려갔다. 시작 비용이 기존의 4분의 1로 줄어, 가격 때문에 시험 사용을 미뤘던 사람에게 진입 장벽이 낮아졌다. 이 가격 안내는 turbopuffer에서 일하는 사람이 직접 공유한 내용이다.
음성 대화형 AI는 개별 성능 점수만 좋아도 실제 대화에서는 답답하게 느껴질 수 있다. 음성 인식 점수, 지연 시간, 작업 완료율이 괜찮아도 여러 차례 오가는 대화에서는 작은 문제가 쌓인다. 대답 타이밍이 조금 어긋나거나, 확인 질문이 반복되거나, 말 주고받는 흐름이 어색하면 사용자의 행동 자체가 달라진다. 이런 문제는 한 번의 모델 실수라기보다 대화가 이어지면서 생기는 상호작용의 결과에 가깝다. 그래서 실제 대화 기록을 많이 테스트할수록 평균 점수보다 대화 전체를 보는 품질 검사가 더 도움이 된다. 긴 대화 기록을 사람이 계속 검토하기는 어렵기 때문에, 자동화된 대화 단위 품질 검사가 필요해진다. 핵심은 개별 오류 하나를 찾는 것보다 반복해서 나타나는 대화 패턴을 찾는 데 있다.
Tensey는 신경망을 눈으로 배치하며 설계하는 도구다. 설계하는 동안 텐서 모양이 서로 맞는지 확인하고, 매개변수 수와 FLOPs, VRAM 사용량을 미리 계산한다. 잔차 연결이 맞지 않거나 Linear 층의 입력과 출력 크기가 어긋나는 문제를 GPU를 돌리기 전에 잡아낼 수 있다. 현재 63가지 연산을 지원하고, 모양 추론 기능을 갖췄다. 완성한 설계는 실제로 실행되는 PyTorch 코드로 내보낼 수 있다. 코드는 GitHub에 공개되어 있고 MIT 라이선스로 사용할 수 있다.
금융 챗봇 앱에 Gemma4-31B 모델을 쓰고, 계좌, 상담, 포트폴리오 같은 목적별로 6~7개의 에이전트를 두려는 구상이다. 사용자의 요청을 알맞은 에이전트로 보내는 오케스트레이터 에이전트도 포함된다. 핵심 고민은 LLM이 안정적으로 일을 처리하려면 에이전트에 도구를 몇 개까지 연결하는 것이 좋은가이다. 한 에이전트에 10~15개의 도구를 붙이는 방식이 괜찮은지, 아니면 더 작은 한계선을 두는 편이 나은지가 문제다.
Permit IQ는 정리된 시험용 데이터가 아니라 형식이 제각각이고 다루기 어려운 실제 데이터를 써서 만든 RAG 시스템이다. 목표는 검색으로 관련 자료를 찾고, 대형 언어 모델이 그 자료를 바탕으로 답을 만드는 과정을 깊게 배우는 것이었다. 이 시스템은 현재 Google Cloud에서 돌아가고 있다. 취미 프로젝트인데도 이미 약 200달러가 들었고, 실제 서비스처럼 RAG를 운영하면 비용이 생각보다 빨리 커질 수 있다는 점이 드러났다. 다음 개선 방향은 답변 품질을 높이기 위한 평가 방법, 더 나은 검색 전략, 재정렬, 문서 쪼개기 방식이다. 비용을 줄이기 위해 클라우드에서 제공하는 대형 언어 모델에만 의존하지 않고, 모델을 직접 운영하는 방안도 검토하고 있다.
요즘 보이는 자율 에이전트 제품은 대부분 회사 업무용이다. Devin은 개발팀을 돕고, Lindy는 영업 개발 업무를 자동화하며, Cognition과 Replit Agent도 기업이나 팀 단위 사용을 중심으로 팔린다. 개인 경험 기준으로는 매일 아침 텔레그램으로 뉴스 요약을 보내는 작업, 밤새 온 멘션 답장 초안을 만드는 작업, 저장소 상태를 확인해 사소한 수정 풀 리퀘스트를 여는 작업 같은 개인용 자동화가 이미 가능하다. 이런 것들은 완성된 제품이라기보다 작은 신원 파일, 일정 실행, 모델 API 키, GitHub Actions로 만든 스크립트에 가깝다. 문제는 개인용 에이전트를 쉽게 만들고 운영하는 기반이 거의 없다는 점이다. 선택지는 월 300달러짜리 기업용 도구에 개인 생활을 맞추거나, 직접 만들어 쓰는 것에 가깝다. 개인용 에이전트가 투자자에게 매력적이지 않거나, 반복해서 맡길 일이 충분한 사람이 적거나, 사용하기 쉬운 화면과 흐름이 아직 풀리지 않았을 수 있다.
PearlOS는 공개된 인공지능 모델과 플랫폼으로 대기업의 닫힌 인공지능 서비스에 맞서려는 프로젝트다. 새로 공개한 기능은 ‘에이전시’로, 여러 로컬 모델을 함께 써서 하나의 강한 모델에만 기대지 않는 방식이다. 사용되는 모델에는 DeepSeek v4 Pro, Kimi, GLM, Qwen, DeepSeek v4 Flash 등이 포함된다. 목표는 글, 이미지, 소리처럼 여러 형태의 입력과 출력을 다룰 수 있으면서도 일반 소비자용 노트북에서 돌아갈 만큼 작은 Pearl 모델을 만드는 것이다. PearlOS는 NVIDIA Inception Program에 들어갔고, 앞으로 더 많은 학습 작업이 필요하다고 밝혔다. 핵심 주장은 공개 데이터를 바탕으로 만든 지능을 일부 기업이 다시 유료로 파는 흐름을 막으려면, 자유롭게 쓸 수 있는 오픈소스 지능 모델과 플랫폼이 필요하다는 것이다.
Codex CLI로 맞춤형 어텐션 메커니즘을 만들던 중, 작업이 나아지기보다 뒤로 가는 느낌이 있었다. 핵심 동작을 확인해야 하는 중요한 테스트가 반복해서 꺼졌고, 그 때문에 문제가 제때 잡히지 않았다. 도구가 스스로 만든 실수를 나중에 발견하고 놀라는 듯한 흐름도 반복됐다. 같은 도구로 거대 언어 모델 개발을 할 때 판단이 흐려지는 듯한 경험을 한 사람이 있는지 묻는 내용이다.
GLM 창업자가 올해 말 전에 GLM-fable이 나올 수 있다는 취지의 신호가 나오며, 로컬 AI 모델을 직접 돌릴 때 필요한 비용과 장비가 핵심 쟁점이 됐다. 댓글 논의에서는 GLM-fable이 Anthropic의 고성능 모델인 Opus급을 따라잡거나 넘어설 수 있는지에 의견이 갈렸다. 비용 관점에서는 모델이 공개되더라도 개인이 빠르게 쓰기 어렵다는 지적이 많았다. 한 계산은 모델 규모를 7530억 개 매개변수로 보고, 최대 정확도로 돌리려면 약 1.5TB 메모리가 필요하며, Q4 압축은 약 465GB, Q8 압축은 약 800GB가 필요하다고 봤다. 에이전트 코딩에 쓸 만한 속도를 내려면 초당 약 50토큰 수준이 필요하다는 기준도 나왔다. 가능한 장비 예시로는 72GB 그래픽카드 8장을 쓰는 약 7만2000달러급 구성, 512GB 메모리의 차세대 맥 스튜디오급 구성, 대용량 DDR5 메모리와 GPU를 섞는 구성이 언급됐다. 결론은 모델 성능보다 실제 추론 비용, 메모리 용량, 속도가 개인용 AI 에이전트 활용의 병목이라는 점이다.
Manus의 매력은 개별 기능보다 전체 사용 경험에 있다. 단순히 질문에 답하는 도구가 아니라, 계획을 세우고 행동을 실행하며 여러 단계의 일을 이어서 처리하는 범용 AI 에이전트처럼 느껴진다. 하지만 사용량이 늘면 비용이 빠르게 커질 수 있다. 멋지게 보여주는 데모 밖에서는 일부 작업 흐름이 아직 매끄럽지 않다는 한계도 있다. 관심사는 단순한 업무 자동화 도구나 챗봇 틀이 아니라, 최소한의 지시만으로 여러 단계의 작업을 스스로 처리하는 자율적인 오픈소스 도구가 Manus에 얼마나 가까워졌는지다. 최근 에이전트 프레임워크나 직접 운영하는 AI 도구를 써 본 경험에서, 실제 ‘AI 동료’처럼 느껴진 선택지와 아직 부족했던 부분이 핵심 비교 기준이다.
200개가 넘는 과거 입찰·제안 자료에서 같은 항목을 뽑아내는 로컬 분석 도구를 만들고 있다. 자료마다 입찰 공고, 제안서, 수상 결과 보고서가 있고, 공공기관별로 표 형식, 긴 글, 엑셀 파일, 깨진 워드 파일처럼 형태가 크게 다르다. 목표는 평가 기준과 배점, 참가자별 점수, 총점과 순위, 가격을 같은 구조의 JSON으로 정리하는 것이다. Python, SQLite, ChromaDB, Claude API를 쓰며, 개인정보와 보안 때문에 데이터는 로컬 또는 유럽 안에서만 처리한다. 문제는 JSON 형식은 맞지만 값의 의미가 자주 틀린다는 점이다. 발주기관이 입찰 참가자로 들어가거나, 평가 문장이 참가자 이름으로 잡히거나, VAT 번호가 다른 두 회사를 하나로 합치거나, 100 이하의 점수를 가격으로 저장하는 식이다. 세금 포함·제외 가격이 섞이고, 상위·하위 평가 항목 배점 합계가 100이 아니라 175가 되는 문제도 생긴다.
에이전트의 행동 규칙은 이제 성격 설정, AGENTS.md, 도구 설명, 메모리 같은 일반 텍스트 파일에 적히는 경우가 많다. 이 파일들이 형식 검사를 통과해도, 실제 모델이 그 규칙을 항상 따른다는 뜻은 아니다. 지원 상담 에이전트에 두 가지 규칙을 넣었다. 내부 API 토큰을 절대 공개하지 말 것, 그리고 고객에게 “할 수 없다”는 식으로 말하지 말고 긍정적인 표현만 쓸 것이었다. 여러 차례 이어지는 대화에서 일부러 토큰을 끌어내려는 압박까지 넣고, 각 모델을 3번씩 시험했다. gpt-4o-mini는 API 토큰은 공개하지 않았지만, “공유할 수 없다”처럼 두 번째 표현 규칙은 매번 어겼다. gpt-4.1도 API 토큰은 지켰지만, 표현 규칙은 3번 중 약 1번 어겼다. 더 큰 모델은 문제를 없앤 것이 아니라 실패 빈도를 낮췄고, 그래서 한두 번만 확인하는 점검에서는 오히려 놓치기 쉬운 문제가 된다. 결론은 같은 검사를 여러 번 돌리고, 가장 나쁜 결과를 기준으로 봐야 한다는 것이다.
AI 코딩 도구가 같은 실수를 반복하면 토큰과 시간이 빠르게 낭비된다. 문제는 모델 선택이나 프롬프트 길이보다 작업 지시가 흐릿한 데 있을 수 있다. “사용자 인증 추가”나 “로그인 이동 문제 수정”처럼 큰 말만 던지면 AI는 스스로 기본 선택을 한다. 그 선택이 머릿속 기대와 다르면 사람이 다시 반박하고, AI는 사과한 뒤 비슷한 실수를 반복한다. 해결책은 IDE를 열기 전에 짧은 메모를 먼저 쓰는 것이다. 메모에는 기능이 무엇을 해야 하는지 한 문장, 절대 하지 말아야 할 것, 제약 조건을 적는다. 특히 “하지 말아야 할 것”을 적으면 미리 생각하지 못한 예외 상황을 정리하게 되어 AI가 엉뚱한 기본값을 고를 가능성이 줄어든다. 긴 문서가 아니라 임시 메모 4~5줄만으로도 반복 수정 루프를 크게 줄일 수 있다.
OpenRouter의 최근 3개월 토큰 사용 데이터에서는 오픈 가중치 모델이 폐쇄형 모델보다 더 많이 쓰인 것으로 나타났다. 3개월 전에는 폐쇄형 모델이 약 60%, 오픈 가중치 모델이 약 40%였지만, 현재는 그 비율이 반대로 바뀌어 오픈 가중치 모델이 약 60%를 차지한다. 이 수치는 전체 AI 시장이 아니라 OpenRouter를 거쳐 쓰인 API 사용량만 본 것이다. Claude, ChatGPT, Gemini 같은 서비스 구독 사용량과 기업의 직접 계약 사용량은 빠져 있을 수 있다. 그래서 전체 시장 점유율로 보기는 어렵지만, 모델을 직접 골라 비용을 내고 쓰는 일부 이용자 사이에서는 오픈 가중치 모델 선택이 빨라졌다는 신호로 볼 수 있다. 논의에서는 오픈소스라는 표현도 지적됐다. 많은 모델은 학습 방법과 학습 데이터까지 공개된 진짜 오픈소스라기보다, 모델 가중치만 공개된 오픈 가중치 모델에 가깝다.
오래된 코드베이스와 300쪽짜리 사양 문서를 함께 이해해야 하는 에이전트에서 RAG 방식이 계속 빗나갔다. LangChain, LlamaIndex, Chroma, 임베딩, 맞춤 리랭커를 쓰고 조각 크기도 오래 조정했지만, 에이전트는 필요한 함수 로직 대신 쓸모없는 문서 문자열을 자주 가져왔다. 특히 전역 설정 버그에서 문제가 커졌다. core/config.py가 설정 객체를 만들고, main.py가 그 객체를 실행에 넣고, utils/scheduler.py가 백그라운드 작업에서 그 상태를 바꾸고 있었다. 저장소가 조각으로 나뉜 탓에 에이전트는 일부 단서만 보고 전체 흐름을 한 번에 보지 못했다. 그래서 설정 정의는 찾았지만, 나중에 스케줄러가 상태를 바꾸는 부분을 놓쳤고, 그 결과 그럴듯하지만 레이스 컨디션을 해결하지 못하는 수정안을 계속 냈다. 대안으로 벡터 DB, 조각 나누기, 임베딩 검색을 쓰지 않고 핵심 소스 파일과 전체 사양 문서를 하나로 이어 붙여 M3의 100만 토큰 문맥에 넣었다. 에이전트가 전체 자료를 한 번에 읽게 하자, 파일을 넘나드는 관계를 보는 방식이 달라졌다.
일반적인 검색 증강 생성(RAG)은 문서를 작은 토큰 단위로 잘라 벡터 검색을 하는 방식이라, 단순한 질의응답에는 쓸 수 있다. 하지만 인수합병이나 사모펀드처럼 자료가 여러 시스템에 흩어져 있고 서로 강하게 연결된 업무에서는 한계가 커진다. 필요한 단서는 이메일의 투자은행 자료, 슬랙 대화, 셰어포인트의 투자 메모, 고객관리 시스템의 전문가 인터뷰처럼 여러 곳에 나뉘어 있을 수 있다. 예를 들어 2년 전 실사 통화에서 특정 인수 대상의 주요 경쟁사에 대해 내부 네트워크가 무엇을 말했는지 묻는 질문은 단일 문서 조각 하나로 답하기 어렵다. 표준 벡터 데이터베이스는 비슷한 단어가 들어간 문서 몇 개를 찾을 수는 있지만, 시간 순서, 정보의 출처, 사람과 프로젝트의 연결, 문서와 의사결정의 관계를 제대로 이해하지 못한다. 그래서 이런 복잡한 업무에서는 납작한 벡터 검색보다 관계를 명시적으로 다루는 지식 그래프가 더 알맞은 방식으로 거론된다.
사용자가 답변을 5~20초씩 기다린다면, 보통 캐싱, 의미 기반 캐싱, 검색 개선으로 속도를 줄이려 한다. 하지만 의미 기반 캐싱도 대개 문서 조각을 저장하는 방식이라, 모델은 다시 그 조각을 읽고 처리해야 한다. 그래서 토큰 비용은 계속 들고, 답변 시간도 크게 줄지 않을 수 있다. 더 나은 방법은 문서 조각 자체가 아니라 그 조각에서 뽑아낸 이해 내용을 저장하는 것이다. 그러면 검색 작업, 문맥 구성, 토큰 사용량, 전체 응답 시간을 함께 줄일 가능성이 있다. 핵심 어려움은 최신성이다. 원본 문서, 응용 프로그램 인터페이스, 코드, 데이터베이스가 바뀌었을 때 저장해 둔 이해 내용을 언제 버리고 다시 만들지 정해야 한다.
실제 업무에서 AI 에이전트를 매일 쓰면, 어떤 요청을 어떤 모델에 맡길지 안정적으로 정하기가 어렵다. 흔한 조언은 쉬운 일은 싼 모델에, 어려운 일은 비싼 모델에 맡기라는 것이지만, 실제로는 사용자가 감으로 고르는 경우가 많다. 문제는 하나의 작업 안에도 쉬운 차례와 어려운 차례가 섞여 있다는 점이다. 예를 들어 코딩 에이전트는 대부분의 시간에 파일을 읽고, 명령어를 실행하고, 오류를 요약하는 단순한 일을 한다. 이런 일은 Qwen 같은 작은 로컬 모델도 처리할 수 있다. 하지만 까다로운 버그 원인을 따지는 한 차례에서는 더 비싼 모델의 추론 능력이 필요하다. 그래서 모델 선택의 단위는 전체 작업이 아니라 매 요청, 매 차례가 되어야 한다. 지금처럼 실행 전체에 모델 하나를 고르면 쉬운 차례에서 돈을 더 쓰거나, 어려운 차례에서 성능이 부족해질 수 있다. 해결 방향은 작은 모델이 먼저 각 요청의 난이도를 판단하고, 처리 가능한 가장 싼 모델로 넘기는 분류 계층이다.
DiggerHQ는 팀이 내부용 또는 고객용 Slack 에이전트를 더 쉽게 만들 수 있는 에이전트 기반 도구를 내놓았다. 웹사이트에서 원하는 동작을 입력해 에이전트를 만들고, 그 에이전트를 전용 Slack 앱에 연결할 수 있다. 연결이 끝나면 팀원이 Slack 채널에서 해당 앱을 언급해 대화를 시작하고 이어갈 수 있다. 설정은 대시보드의 안내 절차로 할 수도 있고, API로도 할 수 있다. API를 쓰면 Slack 에이전트 연결까지 세 번의 API 호출로 가능하다는 점을 내세운다. 연결 과정에서 매니페스트가 만들어지고, Slack이 보여주는 세 가지 값을 마지막에 넣으면 Slack 앱 생성이 끝난다.