AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
BlitzGraph는 LLM 에이전트가 다루기 쉬운 그래프 데이터베이스를 목표로 만든 서비스다. 기존 SQL 방식처럼 정보를 여러 표에 나누고 같은 대상을 여러 ID로 이어 붙이는 대신, 하나의 기록이 여러 종류에 동시에 속하고 시간이 지나며 상태를 바꿀 수 있게 한다. 예를 들어 한 회사가 처음에는 잠재 고객이었다가 계약 후 고객이 되고, 나중에는 이탈 고객이 되는 흐름을 같은 ID 안에서 따라갈 수 있다. 관계도 고정된 한 가지 형태로만 묶지 않고, 여러 종류의 대상이 같은 역할을 할 수 있게 설계했다. 이런 구조는 현실의 사람, 회사, 계약, 상태 변화를 더 자연스럽게 표현하려는 접근이다.
초기 AI·컴플라이언스 제품을 만들 때 핵심 선택지는 세 가지다. 클라우드 AI API로 빠르게 시작할지, 자체 장비에서 로컬·오픈소스 모델을 돌릴지, 처음에는 클라우드로 만들되 나중에 로컬·비공개 모델도 붙일 수 있게 설계할지다. 클라우드는 시작 속도가 빠르고 초반 비용이 낮을 수 있다. 반대로 민감한 데이터나 개인정보 보호가 중요해지면 로컬 모델이 더 나은 선택이 될 수 있다. 작은 팀은 기존 컴퓨터와 클라우드 서비스를 그대로 쓸지, 필요할 때만 클라우드 GPU를 빌릴지, 아니면 로컬 GPU 워크스테이션이나 AI 전용 장비를 살지도 결정해야 한다. 너무 이른 장비 투자는 피해야 할 가능성이 크고, 실제 사용량과 개인정보 요구가 분명해진 뒤에 인프라를 키우는 접근이 더 신중하다.
기업용 복합 AI 에이전트는 여러 구성요소를 따로 붙이는 방식보다, 메모리, 문맥, 캐시를 고려한 상태 설계를 함께 최적화하는 쪽이 더 적합하다. 이런 에이전트는 보통 할 수 있는 행동의 범위가 비교적 명확하다. 그 제한을 활용하면 모든 상황에 열어 둔 일반형 구조보다 더 단호한 설계 선택을 할 수 있다. 구현 관점에서는 DSPy와 GEPA를 바탕으로 구성요소를 조정하는 접근이 제시된다.
AI 에이전트가 늘어나면서 반복되는 실패 방식과 나쁜 설계 패턴도 더 잘 보이기 시작했다. 필요한 것은 실제 실행 기록 같은 관측 데이터를 바탕으로 에이전트가 어디서 자주 실패하는지 자동으로 찾아주는 도구다. 예로 LangSmith Insights 같은 기능이 있지만, 아직 초기 단계에 가깝고 사용자가 직접 설정하고 모델을 고르는 과정이 필요하다는 불편이 있다. 더 이상적인 형태는 ‘에이전트를 위한 사이트 신뢰성 엔지니어’처럼 작동하는 도구다. 이런 도구는 여러 실패 상황을 자동으로 시험하고, 문제를 줄이기 위한 개선안을 제안해야 한다.
회사 제품 전반에서 쓰는 중앙 AI 에이전트가 OpenRouter를 통해 작동하고 있다. 이 에이전트는 워드프레스 플러그인과 서비스형 소프트웨어 제품 안에서 여러 기능을 처리한다. 문제는 에이전트에게 연결된 도구가 많아질수록, 사용자가 짧게 “안녕”이라고만 입력해도 매번 많은 고정 입력 토큰이 쓰인다는 점이다. 회의 일정 변경, 이메일 보내기, 다가오는 회의 찾기 같은 작업을 하려면 각 도구의 설명을 모델에 함께 보내야 하기 때문이다. 실제로 아주 짧은 입력 하나에도 약 1만 토큰이 소모될 수 있다. 목표는 관리자가 제품에서 할 수 있는 거의 모든 일을 채팅이나 음성으로 처리하게 만드는 것이지만, 제품 기능이 많아질수록 현재 방식은 비용 면에서 잘 늘어나지 않는다. 필요한 방향은 에이전트가 처음부터 모든 도구 설명을 받는 대신, 필요한 도구를 단계적으로 찾거나 도구 검색 기능을 쓰는 방법이다.
내부 개발자 플랫폼에 AI 에이전트를 넣으면 새 개발자가 서비스를 익히도록 돕거나, 망가진 설정을 고치는 일을 도울 수 있다. 이런 에이전트는 온보딩용 스킬, 특정 해결책용 스킬처럼 미리 만든 재사용 모듈을 꺼내 쓴다. 스킬이 계속 늘어나도, 실제로 어떤 스킬이 호출되는지, 얼마나 자주 쓰이는지, 사용자를 돕는지 아니면 잡음만 늘리는지 알기 어렵다. 스킬을 만들어 배포한 뒤에는 그 스킬이 제값을 하는지, 아니면 에이전트가 전혀 쓰지 않는 죽은 코드인지 확인할 수 없는 상태가 된다. 핵심 문제는 에이전트 기능을 더 많이 붙이는 것보다, 각 기능의 사용량과 효과를 볼 수 있는 관측 체계가 있느냐이다.
윈도우 Copilot에서 무료로 쓸 수 있는 GPT-4o를 개발 도구에서 직접 부를 수 있게 만든 비공식 도구가 공개됐다. 이 도구는 사용자의 Microsoft 계정으로 한 번 로그인한 뒤 접속 상태를 저장하고, 내 컴퓨터의 http://localhost:8000/v1 주소에 로컬 서버를 연다. OpenAI SDK가 이 주소를 바라보게 하면 기존 OpenAI 형식으로 요청을 보낼 수 있어 코드 변경을 거의 하지 않아도 된다. 스트리밍과 다중 턴 대화를 지원해 자동화 도구, 개인 프로젝트, 가벼운 작업에서 유료 GPT-4o 크레딧을 아끼는 대안으로 쓸 수 있다. 별도 윈도우 노트북이나 윈도우 서버에 다른 Microsoft 계정을 넣어 개인 도구와 에이전트용 무료 엔드포인트처럼 운영할 수 있다는 제안도 포함돼 있다. 다만 Microsoft와 무관한 비공식 프로젝트이며, 개인용 Copilot을 자동화하는 방식이라 계정 제한이나 서비스 약관 문제가 생길 수 있다.
Fundamental-Ava는 자율적으로 움직이고, 다른 에이전트와 협력하며, 사회적 상황을 이해하는 디지털 인간을 만들기 위한 오픈소스 프로젝트다. 공개된 설명은 매우 짧아서, 구체적인 기능, 설치 방법, 성능 수치, 토큰 절감 방식, 비용 절감 구조는 확인되지 않는다. 핵심 내용은 사람처럼 역할을 맡아 행동하는 자율 에이전트를 만드는 데 초점이 있다.
로컬 문서 RAG 시스템은 회사 문서를 클라우드에 올리지 않고, 개인 컴퓨터나 내부 서버 안에서 검색과 답변 생성을 처리하려는 설계입니다. 대상 문서는 PDF, 스캔 PDF, DOCX, XLSX, CSV, 이미지 파일까지 포함됩니다. 폴더를 감시해 파일이 추가, 수정, 삭제되면 자동으로 읽어들이고, 하위 폴더 구조를 이용해 문서에 자동 태그를 붙이려는 방식입니다. 같은 문서가 다시 올라오면 버전을 관리해야 합니다. 검색은 특정 고객의 문서 안에서만 이뤄져야 하며, 다른 고객 문서가 섞이면 안 됩니다. “1 lakh 루피 초과 송장 보기” 같은 조건 검색, “2023 회계연도와 2024 회계연도 매출총이익 비교” 같은 비교 검색, 일반 키워드 검색이 모두 필요합니다. 답변은 로컬 거대 언어 모델만 사용해 만들고, 모든 주장에는 문서 이름과 페이지 번호가 붙어야 합니다. PDF는 강조 표시된 문서로 보여주고, XLSX는 색칠된 셀로 내보내며, 답변에서 바로 해당 페이지나 여러 문서의 강조 위치로 이동할 수 있어야 합니다. 설계상 중요한 고민은 LlamaIndex LiteParse 같은 파싱 도구를 쓸지, PDF 강조 표시를 위해 문서 아이디와 청크 아이디를 저장해야 하는지, Qdrant 같은 벡터 데이터베이스나 pgvector가 필요한지입니다.
GLM 5.2는 기본 설정에서 가장 높은 사고 단계인 최대 단계로 작동해 토큰 사용량과 대기 시간이 크게 늘어날 수 있다. GLM 5.1에서 5.2로 오면서 추론 토큰 수가 약 1만6,700개에서 3만6,700개로 두 배 이상 늘었다는 관찰이 나왔다. 오래된 제온 장비로 로컬 실행을 시도한 경우, 수학 문제 답변을 기다리다 12시간 뒤 모델을 꺼야 할 만큼 느렸다. Z.ai 기술 보고서의 그래프는 코딩 작업 기준으로 높은 단계가 최대 단계의 절반보다 적은 토큰을 쓰면서도 최대 성능의 약 98%에 가까운 지능 수준을 낼 수 있음을 시사한다. 그래서 로컬 사용자와 응용 프로그램 인터페이스 사용자는 기본 최대 단계 대신 높은 단계를 시험해볼 만하다. 다만 4비트 양자화와 높은 단계를 함께 쓴 테스트에서는 답이 절반 정도만 맞았고, Z.ai 채팅에서 최대 단계와 높은 단계를 비교한 결과는 서로 비슷했지만 일부 경우 판단 차이가 있었다. 관련 실험들은 GLM 5.2가 512GB급 맥 스튜디오, 듀얼 RTX 5090, 4개 RTX 3090 같은 큰 장비에서는 긴 문맥과 로컬 실행 가능성을 보여주지만, 일반적인 개인 장비에서는 속도와 메모리 부담이 여전히 크다는 점도 함께 보여준다.
다중 에이전트 흐름을 실제 용도에 적용해 보니, 결과가 기존 단일 에이전트 방식보다 나쁠 때가 있었다. 구조도 단일 에이전트보다 훨씬 복잡해졌고, 작은 기능 하나를 넣는 데도 문제가 자주 생겼다. 예를 들어 되돌릴 수 없는 작업을 막는 게이트 같은 장치를 추가하면 전체 흐름이 깨지고, 고치는 데 몇 시간이 걸렸다. 비동기 다중 에이전트 파이프라인에서는 여러 에이전트가 서로 맞춰 움직이지 않고 각자 다른 방향으로 가는 일이 있었다. 그 결과 최종 출력물의 품질이 낮아졌다. 핵심 고민은 여러 에이전트 사이의 조율을 어떻게 안정적으로 처리할지, 그리고 복잡도를 줄여 줄 도구나 라이브러리가 있는지다.
AI 코딩 에이전트는 겉으로는 일을 잘 끝낸 것처럼 보여도 실제 목표에는 실패할 수 있다. 예시 실행에서 에이전트는 요청받은 슬라이딩 윈도 함수 대신 관련 없는 클래스를 만들었고, 그 클래스에 맞춘 자체 테스트만 통과했다. 일반적인 관찰 기준으로는 출력이 깨끗하고 테스트도 통과해 낭비가 0%처럼 보였다. 하지만 에이전트가 볼 수 없는 외부 검증은 작업이 완전히 실패했다고 판정했다. 이 문제를 재기 위해 낭비를 두 가지로 나눴다. 하나는 나중에 아무 데도 쓰이지 않은 작업인 출처 기반 낭비이고, 다른 하나는 실행은 깔끔했지만 외부 기준에서는 틀린 결과인 결과 기반 낭비다. GPT-4o mini로 디버깅 작업 15개를 외부 검증한 초기 실험에서는 출처 기반 낭비만 보면 최소 1.71%였지만, 실패한 작업에 들어간 비용은 31.8%였다. 즉 약 30%의 비용이 겉으로는 문제없어 보이지만 실제로는 틀린 작업에 쓰였을 수 있다. 이 도구는 사람 검토 수치를 자동으로 채우지 않고, 1.71% 이상 31.8% 이하라는 범위로만 보고해 과한 정확도를 꾸미지 않는다.
llama.cpp 빌드 dd4623a74(9640)에서 여러 Gemma 계열 모델을 SYCL 백엔드로 돌린 속도 측정값이다. gemma4 E2B Q8_0은 크기 4.69GiB, 46.5억 매개변수이며 pp512에서 초당 5662.45토큰, tg128에서 초당 109.14토큰을 기록했다. gemma4 12B Q8_0은 크기 11.78GiB, 119.1억 매개변수이며 pp512에서 초당 1578.19토큰, tg128에서 초당 32.43토큰을 기록했다. gemma4 26B.A4B Q8_0은 크기 25.00GiB, 252.3억 매개변수이며 pp512에서 초당 1332.35토큰, tg128에서 초당 40.13토큰을 기록했다. qwen35moe 35B.A3B Q8_0 항목도 포함되어 있으며 크기는 34.36GiB, 346.6억 매개변수로 표시되지만, 제공된 내용에서는 최종 속도 값이 잘려 있다.
Alibaba에서 블로워 방식 5060 Ti 그래픽카드가 580달러에 팔리고 있다. 여러 장을 한 시스템에 꽂으면 전기를 비교적 적게 쓰는 로컬 AI 장비가 될 수 있다는 계산이다. 이 카드들은 일반적인 8핀 전원 커넥터를 쓴다. 3080 20GB는 500달러로 더 싸고 메모리 대역폭이 약 25% 더 높지만, 더 큰 전원공급장치가 필요하고 열이 더 많이 난다. 특히 카드 뒷면의 메모리 부품이 뜨거워질 수 있다. 반대로 5060 Ti 네 장 구성은 1000와트 전원공급장치만으로도 가능하다는 점이 장점으로 제시된다.
프로토타입이나 개념 검증 단계에서는 에이전트가 잘 작동해도, 실제 서비스에 올리면 도구 호출이 자주 실패할 수 있다. 문제는 항상 모델이 잘못된 도구 입력값을 지어내는 데서만 생기지 않는다. 더 흔한 실패는 도구 호출 자체가 일어나지 않았는데도 에이전트가 조용히 성공했다고 처리하는 경우다. 여러 시도 끝에 효과가 있었던 방식은 도구가 모델의 긴 설명문이 아니라 실제 상태를 반환하게 만드는 것이다. 이렇게 하면 에이전트가 말로 성공을 꾸미는 대신, 작업이 실제로 어떤 상태인지 확인하기 쉬워진다.
RTX 5080, 32GB DDR4 메모리 환경에서 로컬 언어 모델을 더 잘 돌릴 방법을 찾는 사례다. Qwen 3.6 27B 모델을 Q3KM 수준으로 줄였을 때 초당 약 60토큰이 나왔고, Qwen 3.6 35B 모델을 IQ2 수준으로 더 많이 줄였을 때는 초당 약 190토큰이 나왔다. 낮은 압축 수준인 Q6에서 더 작은 수준으로 내려가면 정확도가 꽤 떨어질 수 있다는 점도 고려하고 있다. 남는 1080 Ti 그래픽카드의 11GB GDDR5X 메모리를 함께 써서 모델을 나눠 올리는 방안도 고민 중이다. 다만 그래픽카드 두 장을 쓰면 전력, 발열, 설정 복잡도가 늘어나므로 추가 메모리 11GB가 실제로 그만한 가치가 있는지가 핵심이다.
로컬 우선 에이전트에 웹 접근 기능을 붙일 때 Tavily, Serper, Firecrawl 같은 유료 API를 쓰지 않는 방법이다. 구성은 단순히 검색용 도구와 본문 추출용 도구 두 가지로 나뉜다. 검색은 SearXNG를 Docker로 직접 띄우고, 에이전트가 JSON 엔드포인트를 호출하게 만든다. 검색 결과는 제목, 주소, 설명 형태로 정리하며, 설명은 페이지 본문이 아니라 SearXNG가 보여주는 짧은 검색 조각이다. 그래서 에이전트가 실제 내용을 읽어야 할 때는 별도 추출 도구가 필요하다. 본문 추출은 Scrapling과 Trafilatura를 함께 쓰며, 일반적인 페이지는 브라우저 없이 빠르게 가져오는 방식으로 처리한다. 설정에서 SearXNG의 검색 형식에 JSON을 켜야 하고, 공개 SearXNG 서버는 자동 호출용으로 쓰기에는 맞지 않을 수 있다.
2026년에도 RAG가 여전히 가치 있는지, 연구할 만큼 중요한 분야인지가 핵심 쟁점입니다. 일부 비판은 최신 LLM이 매우 강력해져서 RAG의 도움 없이도 충분히 답을 만들 수 있다는 주장입니다. 이 항목은 새 실험 결과나 수치를 제시하지는 않고, RAG의 필요성이 예전보다 줄었는지 판단하려는 문제 제기에 가깝습니다.
현재 시스템은 Asus ROG MAXIMUS Z790 DARK HERO 메인보드, Intel Core i9-14900K, 48GB DDR5 메모리 4개 구성을 바탕으로 듀얼 RTX 6000 Pro Max-Q를 고려하고 있다. 이 메인보드는 그래픽카드 2장을 꽂으면 PCIe 5 연결이 각각 x16이 아니라 x8로 줄어든다. 대안은 여러 개의 PCIe 5 x16 슬롯을 지원하는 Threadripper PRO 시스템으로 바꾸는 것이지만, 비용이 크게 올라간다. 판단해야 할 작업은 vLLM 기반 추론, 이미지 생성, LoRA 작업, Flux.2와 z-image, 영상 생성이다. 핵심은 듀얼 PCIe 5 x8이 실제 작업 속도에 충분한지, 아니면 훨씬 비싼 플랫폼 교체가 필요한지다.
AI 개발 작업을 하나의 도구에 모두 맡기지 않고 역할별로 나누어 운영한다. 오케스트레이터는 전체 계획을 세우고 일을 나누지만 직접 코드를 고치지는 않는다. 실행 에이전트는 명령을 실행하고, 검토 에이전트는 작성된 결과를 확인하며, 조사 에이전트는 모호한 부분을 찾아본다. 깃 커밋도 오케스트레이터가 직접 하지 않고 실행 에이전트를 거치게 해서, 계획하는 쪽이 스스로 승인하는 위험을 줄인다. 별도 대시보드에서는 들어오는 요청, 현재 단계, 오류 수를 실시간으로 본다. 캐시가 많은 요청을 처리하고, 일부만 새로 모델에 보내는 구조다. 터미널에서는 일부러 한계를 테스트한다. 제공자를 과하게 호출해 속도 제한이 걸리게 만들고, 재시도와 대체 경로가 실제로 작동하는지 확인한다.
GMKtec EVO-X3는 AMD Ryzen AI Max+ 395 기반의 AI 미니 PC로 소개됐다. 가격은 3,600달러로, 128GB 메모리를 갖춘 기존 Strix Halo 장비를 1,600달러에 샀던 기준보다 두 배 이상 비싸다. 이 장비는 USB4를 지원하고, 데스크톱 그래픽카드를 케이블로 직접 연결하는 OCuLink 전용 포트를 갖췄다. OCuLink는 USB4보다 데이터 손실을 줄이고 외장 그래픽카드 성능을 더 잘 끌어낼 수 있다는 점이 강조됐다. 냉각 성능도 중요한 특징으로 언급됐으며, 장시간 AI 작업에서 열 때문에 성능이 떨어지는 일을 줄이는 데 초점이 있다. 곧 나올 것으로 예상되는 Gorgon Halo 같은 더 강한 칩을 염두에 둔 장비처럼 보인다는 전망도 포함됐다.
Pulpie Orange Small은 웹페이지 HTML에서 광고나 메뉴 같은 불필요한 부분을 걸러내고 실제 본문 내용만 뽑아내는 작은 모델입니다. 이름에 붙은 "Pareto-optimal"이라는 표현은 정확도와 처리 비용(속도·크기) 사이에서 어느 한쪽을 크게 희생하지 않고 최상의 균형을 이뤘다는 의미로 붙여진 것입니다. r/LocalLLaMA 커뮤니티에 공유되었습니다.
Claude Code로 기능 개발과 버그 수정을 할 때 GitHub 이슈를 작업의 중심 기록으로 쓰는 방식이다. 요구사항이 흐리면 Claude가 먼저 질문해서 목표와 범위를 분명히 잡고, 작업 계획과 진행 상황을 GitHub 이슈 댓글에 계속 남긴다. 각 Claude Code 세션을 특정 이슈에 묶어 두면 이전 대화 내용을 길게 다시 설명하지 않아도 작업 문맥을 이어가기 쉽다. 새로 발견된 하위 작업이나 의존 작업은 별도 이슈로 만들어 다음 단계가 흩어지지 않게 한다. CLAUDE.md와 MEMORY.md도 함께 갱신해 프로젝트 규칙과 기억해야 할 내용을 다음 세션에서 재사용할 수 있게 한다. 매일 진행 보고를 남겨 개인 작업자도 무엇을 했고 무엇이 남았는지 쉽게 이어받을 수 있다.
Evolink-AI의 GitHub 저장소는 AI 영상 제작에 쓰는 Blender와 Seedance 작업 흐름을 모아 둔 자료다. 다루는 내용은 촬영 전 장면을 미리 짜 보는 작업, 카메라 움직임 제어, 참고 영상을 활용한 제작 방식, Blender MCP, 에이전트가 작업을 안내하는 사용 사례다. 범위는 일반적인 AI 에이전트 플랫폼이 아니라 영상과 3D 제작 흐름에 맞춰져 있다. 실제 비용 절감 수치나 토큰 사용량 비교는 제공된 정보에 없다.
Claude를 개인 면접 코치처럼 쓰는 작업 흐름이다. 핵심은 Obsidian 저장소에 공부 자료를 정리해 두고, Claude가 그 자료를 참고하며 매일의 준비를 이어 가게 하는 것이다. 저장소에는 진행 상황, 핵심 개념, 연습 기록, 면접 전략 같은 문서가 들어간다. Claude는 개념 설명, 퀴즈, 실습 안내, 모의 면접 같은 여러 방식으로 사용자를 도와준다. 이전 준비 상태를 바탕으로 다음에 무엇을 공부할지 제안하고, 반복해서 쓸 수 있는 면접 준비 체계를 만든다. 최종 면접처럼 발표나 실습이 포함된 상황에 맞춰 개인화된 공부 가이드로 쓰는 방식이다.
Claude Opus 4.8로 웹 작업을 자동화할 때, 화면을 이미지처럼 보고 클릭하는 픽셀 기반 방식과 웹페이지 구조를 읽고 조작하는 DOM 기반 방식의 비용과 효율을 비교했다. 실험은 5가지 웹 작업에서 두 방식을 나눠 측정했다. 일반적인 웹 작업에서는 픽셀 기반 에이전트가 더 저렴할 수 있었다. 반대로 화면 안의 많은 요소를 정확히 찾아야 하는 작업에서는 DOM 기반 에이전트가 더 잘 맞고 비용도 더 효율적이었다. 비교 방법, 결과, 직접 평가해볼 수 있는 오픈소스 평가 도구가 함께 제시됐다. 핵심은 웹 에이전트를 만들 때 한 가지 방식을 고정하지 말고, 작업 성격에 따라 조작 방식을 골라야 토큰과 비용을 줄일 수 있다는 점이다.
어려운 코딩과 디버깅 과제에서 QRF/Arbor식 분기 추론을 한 번에 답하는 방식과 비교했다. Llama-8B는 7개 어려운 과제에서 평균 1.70배였지만 중앙값은 1.00배라서, 보통 과제에서는 나아지지 않았다. 좋아진 결과는 조건이 많은 일부 과제에 몰려 있었다. Gemma3-1B SRD-4는 평균 1.53배, 중앙값 1.33배로 더 작지만 더 고른 개선을 보였다. SmolLM-135M은 평균 6.52배로 커 보였지만, 30배짜리 예외 결과 하나가 평균을 크게 끌어올렸고 중앙값은 1.67배였다. 결론은 분기 추론이 모델을 항상 더 똑똑하게 만들지는 않는다는 것이다. 모델이 필요한 단서를 갖고 있지만 한 번에 답할 때 조건 하나를 놓치는 과제에서는 도움이 될 수 있다. Gemma와 SmolLM은 로컬에서 실행됐고, Llama는 NIM에서 실행됐다.
기업이 AI 에이전트로 코드를 만들고, 문서를 쓰고, 업무 판단을 맡기려면 결과가 실제로 맞았는지 확인할 방법이 필요하다. 결과물이 제대로 작동했는지, 나중에 다른 사람이 믿고 다시 쓸 수 있는지, 회사 안의 지식으로 쌓이는지까지 확인해야 한다. 이런 검증이 없으면 ‘토큰 자본’은 생산적인 자산이 아니라 토큰을 더 많이 쓰는 과정이 될 수 있다. 중요한 기반은 AI가 더 많은 결과물을 뽑아내는 것이 아니라, 조직이 다시 활용할 수 있는 검증된 지식을 만드는 것이다. AI 에이전트가 진짜 회사의 지식 자산을 만들려면 먼저 검증 절차가 필요하다는 문제의식이다.
AI 에이전트를 모든 일에 붙이는 방식은 실제 효율보다 새로움에 끌린 선택일 수 있다. 항공사 좌석표를 1분마다 확인해 더 좋은 좌석으로 바꾸는 일은 항공사가 차단할 수 있고, 에이전트가 잘못 판단해 오히려 나쁜 좌석을 고를 위험도 있다. 커피 주문이나 식당 예약처럼 이미 잘 만든 앱이나 웹사이트가 있는 일은 챗봇으로 처리하는 편이 더 느리거나 불편할 수 있다. 여행 확인 이메일에서 필요한 내용을 찾아 동료에게 보내는 일도, 에이전트가 내용을 잘못 읽거나 없는 정보를 만들어낼 수 있다면 사람이 짧게 복사해 보내는 편이 더 안전할 수 있다. 웹 앱 배포나 보안 인증서 갱신 같은 중요한 IT 작업에 MCP 서버를 붙이는 사례도 언급된다. 이런 작업은 정해진 절차가 분명한 경우가 많아서, 예측 가능한 자동화가 AI 에이전트보다 나을 수 있다.
2026년 6월 현재 쓸 만한 로컬 AI 에이전트를 비교하고 토론하기 위한 정리 흐름이다. 여기서 에이전트는 사용자의 요청을 바탕으로 어느 정도 스스로 행동 순서와 판단 과정을 정해 작업하는 소프트웨어를 뜻한다. IFTTT, n8n, Apple Shortcuts처럼 미리 정해 둔 규칙대로만 움직이는 자동화 도구와 달리, 에이전트는 매번 경로와 논리를 직접 정할 수 있다는 점이 핵심 차이다. 예시로 pi, opencode, hermes 같은 도구가 언급된다. ‘Harness’라는 새 용어는 필요성이 충분하지 않고 합의된 뜻도 부족하다는 이유로 일부러 쓰지 않는다. 에이전트라는 말 자체도 아직 표준 정의가 없으며, 유행어인지 새로운 기본 기술인지 구분하기 어렵다는 신중한 관점이 깔려 있다.