AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
AI 에이전트의 위험은 권한 없이 큰 사고를 치는 경우만이 아니다. 더 까다로운 문제는 인증도 통과하고, API 키 권한도 있고, 정책 검사도 통과했는데 실제 작업 대상이 틀리는 경우다. 예를 들어 에이전트가 문서 승인 이메일을 보내고 답장을 기다린 뒤, “승인됨”이라는 답장을 보고 데이터베이스 기록을 바꿀 수 있다. 권한 관리에서는 쓰기가 허용되고, 정책에서도 업데이트가 허용된다. 하지만 그 답장이 전달된 이메일 대화에서 온 것이고 실제로는 다른 고객을 가리킨다면, 모든 규칙은 통과했지만 잘못된 고객 기록이 바뀐다. 이 문제를 막기 위해 에이전트가 도구, API, 데이터베이스 작업을 실행하기 전에 권한, 업무 정책, 작업의 출처와 문맥이 맞는지 확인하는 런타임 제어 계층의 초기 시제품이 만들어지고 있다.
WorldBench는 로봇 세계 모델을 평가하기 위한 오픈소스 Python 도구입니다. 로봇이 주변 환경을 얼마나 잘 이해하고 예측하는지 살펴보는 데 쓰입니다. GitHub에 공개되어 있으며, 만든 쪽은 사람들이 직접 시험하고 문제를 찾고 개선 의견을 내주기를 원합니다. 현재 공개된 정보의 핵심은 도구의 존재와 목적, 그리고 외부 테스트 요청입니다.
Modelplane은 여러 곳에 흩어진 그래픽처리장치 묶음을 하나의 AI 추론 운영 환경처럼 다루게 해 주는 오픈소스 제어판이다. 클라우드, 네오클라우드, 회사 내부 서버에 있는 자원을 함께 묶어 모델을 배치하고 요청을 보낼 수 있다. 기존에 많이 쓰는 vLLM, SGLang, TensorRT-LLM 같은 추론 실행 도구 위에서 작동한다. 한 클러스터 안의 실행만 다루는 것이 아니라, 여러 클러스터를 아우르는 운영 층을 맡는다. 주요 기능은 모델을 어디에 둘지 정하기, 요청 라우팅, 자동 확장, 가중치 캐싱 등이다. 자체적으로 추론을 운영하려는 팀에게 필요한 기반 작업을 줄이는 데 초점이 있다.
퍼징은 오랫동안 C와 C++ 같은 언어에서 프로그램이 멈추거나 메모리를 잘못 쓰는 문제를 찾는 방식으로 쓰였다. 파이썬 같은 언어에서는 같은 방식의 효과가 작게 느껴질 수 있다. 최악의 경우에도 프로그램 예외가 나는 정도로 끝나는 일이 많기 때문이다. LLM을 쓰면 단순히 코드의 여러 갈래를 많이 실행해 보는 데서 벗어나, 실제 업무 규칙이 깨지는 지점을 찾아보는 방향으로 테스트할 수 있다. 이미 이런 접근이 가능함을 보여준 프로젝트가 있었고, 실제 성과는 각 용도에 맞는 하네스를 얼마나 잘 만들었는지에 달려 있다. 핵심 질문은 이 방식을 실제 업무 로직에 적용해 본 사례가 있는지다.
AI 에이전트 성능을 점검할 때 프롬프트 하나만 따로 고치는 방식은 한계가 있다. 더 중요한 일은 에이전트가 참고하는 컨텍스트와 전체 실행 틀까지 함께 보고 개선하는 쪽으로 옮겨가고 있다. 즉, 질문 문장을 조금씩 바꾸는 것보다 어떤 정보를 넣을지, 어떤 순서로 처리할지, 실패했을 때 어떻게 다시 시도할지까지 평가해야 한다는 문제의식이다. 실제 현장에서는 이런 전체 구조를 어떻게 시험하고, 어디에서 막히는지가 핵심 질문이다.
부동산 영업 현장에서는 고객 정보가 전화 통화나 집 방문 뒤에 고객 관리 도구로 옮겨지지 않아 빠지는 일이 생긴다. 예를 들어 “남향 뒷마당만 원함”이나 “이 예산을 넘기지 않음” 같은 중요한 조건이 사람의 기억에만 남을 수 있다. 회의 녹음과 대화 기록을 수동 메모 대신 에이전트의 시작점으로 쓰면 이런 빈틈을 줄일 수 있다. Bluedot은 회의에 별도 봇을 들이지 않고 녹음하며, 대화 기록, 요약, 할 일 목록을 만들고 검색도 가능하게 한다. 더 발전된 에이전트는 이 정보를 고객 관리 도구에 자동으로 반영하고, 고객 선호를 다시 알려주며, 다음 만남 전에 필요한 문맥만 꺼내 보여주는 역할을 할 수 있다. 핵심 과제는 단순한 메모 앱을 넘어 실제 업무 도구를 정확히 업데이트하는 방식이다.
AI 에이전트를 더 잘 만들려면 모델 성능, 긴 문맥, 좋은 프롬프트, 더 많은 도구만 볼 일이 아니다. 실제 업무에 쓰기 전에는 에이전트가 건드려도 되는 데이터와 건드리면 안 되는 데이터가 먼저 정해져 있어야 한다. 코드 작성, 고객 데이터 접근, PR 열기, 고객관리시스템 수정, 업무 흐름 실행 같은 행동에는 허용 범위가 필요하다. 비용을 얼마까지 쓸 수 있는지, 어떤 작업은 사람의 승인이 필요한지, 문제가 생기면 어떻게 되돌릴지, 완료됐다는 증거를 무엇으로 볼지도 정해야 한다. 이런 장치가 없으면 에이전트에게 작업 공간을 열어준 뒤 문제가 터진 다음에야 원인을 찾게 된다. 앞으로의 AI 에이전트는 더 똑똑해지는 것뿐 아니라, 행동을 제한하고 확인하고 기록하는 시스템 안에서 움직여야 한다.
목표는 모바일 앱에 Apache 2.0 라이선스의 대규모 언어 모델을 로컬 호스트로 붙이는 것이다. 현재 장비는 24GB 메모리를 가진 새 MacBook Pro Max다. 핵심 고민은 8B 모델을 양자화하면 이 장비에서 실행할 수 있는지다. 다른 선택지는 훨씬 비싼 DGX 같은 전용 인공지능 서버를 사기 위해 돈을 모으는 것이다.
운영 중인 RAG 챗봇에서 같은 질문이 로컬 환경에서는 보통 30초 안에 끝나지만, AWS에 올린 환경에서는 가끔 4~5분까지 느려진다. 이 챗봇은 파이썬 웹 앱, Amazon Bedrock, PostgreSQL 데이터베이스, pgvector를 함께 쓰며, 모두 같은 AWS 지역에 있다. 앱은 컨테이너 형태로 Kubernetes에서 실행되고, 데이터베이스와 벡터 데이터는 같은 PostgreSQL 안에 있지만 서로 다른 저장 구역을 쓴다. 이미 데이터베이스 색인, 벡터 검색용 색인, 연결 재사용, 작업 스레드 재사용, Kubernetes 자동 확장 같은 기본 최적화는 적용되어 있다. 실행 단위마다 메모리는 1GB이고, 3개까지 준비되어 있지만 기록상 실제로는 2개 넘게 쓰인 적이 없다. 문제는 항상 느린 것이 아니라 대부분은 정상 속도이고, 아주 가끔 한 요청만 4~5분 걸린 뒤 다음 요청은 다시 정상으로 돌아간다는 점이다. 확인된 원인은 아직 없다.
3개 지점을 가진 안과가 페이스북 광고로 들어온 잠재 고객을 더 빨리 붙잡기 위해 음성 AI 상담 흐름을 만들었다. 광고 양식이 제출되면 n8n이 동시에 이메일, WhatsApp 메시지, Vapi 음성 전화를 보낸다. 전화를 받지 않으면 음성 에이전트가 근무 시간 안에서 7~8일 동안 다시 시도한다. 에이전트는 병원 가격, 위치, 진료 흐름 같은 기본 질문에 답할 수 있다. 통화 뒤에는 녹취록이 OpenAI로 넘어가고, 예약 의사가 보이면 이메일과 WhatsApp으로 예약 링크가 자동 발송된다. 통화가 연결되지 않으면 후속 연락 대상으로 표시된다. 마지막 예약 확정은 사람이 맡는다. 의료 분야라서 HIPAA를 지키고, 날짜 실수나 불안한 고객 대응처럼 사람이 필요한 부분을 남겨 둔 설계다.
개인용 메모리 에이전트가 맥에서 하루 종일 화면을 보고, 선택하면 마이크와 시스템 소리도 함께 기록한다. 화면의 글자는 OCR로 읽고, 말소리는 글로 바꾼 뒤, 내용을 구조화된 Markdown으로 정리해 Obsidian 저장소에 넣는다. 목적은 사람이 직접 메모하지 않아 사라지는 작은 결정, 작업 흐름, 다음 날이면 잊히는 문맥을 자동으로 붙잡는 것이다. 핵심 상태는 노트 앱이 아니라 SQLite 데이터베이스에 둔다. 사람, 중복 제거, 검색, 비용 추적, 민감한 내용 가리기 같은 실제 기록은 SQLite가 원본이고, Obsidian의 일일 노트와 인물·프로젝트·주제별 위키는 언제든 다시 만들어낼 수 있는 출력물이다. 외부로 데이터가 나가는 구조가 아니라, 사용자가 자기 API key를 넣을 때만 외부 모델을 붙이는 방식이다.
고객사의 이메일 대화, 슬랙 채널, 프로젝트 문서를 함께 살펴 프로젝트의 긴 결정 과정을 추적해야 하는 검색 흐름이 문제로 제시됐다. 일반적인 의미 유사도 검색은 문서를 잘게 나눈 뒤 비슷해 보이는 조각을 찾지만, 이런 방식은 관계가 많은 업무 기록에서 자주 실패한다. 예를 들어 “지난 분기 API 이전 문제의 최종 결론이 무엇이었나?”라는 질문에는 관련 코드 조각만 일부 찾고, 누가 슬랙에서 결정을 내렸는지와 왜 문서가 나중에 바뀌었는지를 놓칠 수 있다. 선택지는 크게 세 가지로 정리된다. 첫째, 평평한 텍스트 조각을 벡터 데이터베이스에 넣고 별도 파이썬 중간 계층으로 메타데이터 필터를 계속 맞추는 방법이다. 이 방법은 시작은 비교적 쉽지만, 메타데이터 동기화가 약하고 다중 단계 관계 질문에서 무너질 수 있다. 둘째, 슬랙 등 여러 비정형 자료 저장소 위에 관리형 문맥 그래프 플랫폼인 60x를 얹어 시험하는 방법이다. 핵심 고민은 문맥 그래프를 직접 만들 만큼 개발 부담을 감수할 가치가 있는지, 아니면 기존 벡터 데이터베이스에 강한 메타데이터 필터를 덧붙이는 편이 나은지다.
검색 증강 생성(RAG)을 쓰는 AI 에이전트가 약한 답을 내놓을 때, 원인은 모델 자체가 아닐 수 있다. 많은 팀은 모델의 환각, 나쁜 프롬프트, 작은 문맥 창, 불명확한 지시를 먼저 의심한다. 하지만 실제 운영 환경에서는 모델이 답을 만들기 전에 이미 잘못된 자료가 들어오는 경우가 많다. 회사들은 문서, 데이터베이스, 정책, 고객 문의, 계약서, 설명서, 내부 시스템에 흩어진 지식을 AI 에이전트가 쓰게 하려고 검색 증강 생성(RAG)을 만든다. 보통 문서를 작은 조각으로 나누고, 글을 임베딩으로 바꾸고, 벡터로 저장한 뒤, 질문과 가까운 조각을 찾아 모델에 넣는다. 단순한 질문에는 이 방식이 잘 맞을 수 있다. 그러나 실제 업무 질문은 더 복잡해서, 검색 단계가 틀리면 모델은 처음부터 잘못된 재료로 답을 만들게 된다.
MIA는 BigQuery 데이터 창고와 미디어 믹스 모델링 플랫폼 위에 만든 마케팅 정보 에이전트다. 다루는 데이터는 채널별 광고비, 모델 결과, 복잡하게 중첩된 플래너 API 응답처럼 정리하기 어려운 형태다. 실제 운영 뒤 얻은 핵심 결론은 신뢰성의 대부분이 거대언어모델이 아니라 정해진 규칙의 코드에서 나온다는 점이다. 거대언어모델은 자연어로 사용자의 의도를 읽고 결과를 말로 풀어주는 역할만 한다. 믿을 수 있게 만드는 부분은 타입이 정해져 있고, 같은 입력에는 같은 결과를 내며, 테스트된 코드로 처리한다. 현실의 지저분한 데이터에서 에이전트는 그럴듯하게 말은 잘하지만, 존재하지 않는 열을 만들거나, 잘못된 연결 키를 추측하거나, 빈 쿼리 결과에서 숫자를 지어낼 수 있다. 이를 줄이기 위해 전체 스키마를 프롬프트에 넣는 대신, 비즈니스 개념을 실제 데이터 필드, 연결 경로, 선택값 사전에 연결하는 문맥 그래프를 둔다. 예를 들어 ‘매출’이나 ‘현재 광고비’ 같은 말은 추측이 아니라 그래프가 정한 실제 필드로 해석된다.
Cortex RAG는 기본적인 벡터 검색만 하는 RAG 도구보다 더 많은 검색 보강 방식을 묶은 오픈소스 도구다. 문서를 작은 조각으로 나눌 때 원래 문서의 배경을 함께 붙이고, 질문을 여러 방식으로 바꿔 더 넓게 찾은 뒤 결과를 합친다. 문서 안의 사람, 회사, 제품 같은 관계도 함께 보고, 대형 언어 모델이 찾은 문서 조각을 평가해 답변에 쓰기 어려운 내용을 걸러낸다. 관련성이 높은 순서로 결과를 다시 정렬하고, 질문이 짧거나 애매할 때는 가상의 답을 만들어 검색 범위를 넓힌다. 같은 질문은 시맨틱 캐시로 빠르게 처리해 반복 검색 시간을 줄인다. 여러 차례 이어지는 대화는 채팅 메모리로 이어갈 수 있다. 클라우드나 API 키 없이 노트북에서 실행되며, 내부 검색, 규정 준수 자동화, 지식 관리 시스템에 맞춰 시험해볼 수 있다.
OpenRouter의 일부 큰 오픈 모델 가격은 실제 서버 비용과 잘 맞지 않아 보인다. GLM-5.2를 예로 들면, 싼 8대 H200 임시 서버를 시간당 12~14달러에 빌리고 FP8 방식으로 돌려도 계산이 빡빡하다. 한 서버 묶음이 초당 출력 토큰 175개를 만든다면, 한 시간에 약 63만 개의 출력 토큰만 만든다. 이 경우 운영비와 이윤을 빼기 전에도 출력 토큰 100만 개당 약 22달러가 든다. 그런데 API 가격이 출력 토큰 100만 개당 약 4달러라면, 실제로는 처리량이 훨씬 높거나, 서버 비용이 훨씬 싸거나, 모델이 더 강하게 최적화 또는 양자화되어야 한다. FP8보다 더 낮은 정밀도로 줄이면 답변 품질이 꽤 떨어질 수 있다는 걱정도 있다. FP8만 써도 품질이 8~10% 낮아질 수 있다는 추정이 나오지만, 이런 품질 저하는 정확히 숫자로 재기 어렵다.
기업용 AI 게이트웨이를 고를 때 가격 체계가 한 가지로 정리되어 있지 않다. 어떤 제품은 좌석당 과금으로 사람 수에 따라 비용을 받는다. 어떤 제품은 사용량 기반 과금으로 실제 이용한 만큼 비용을 매긴다. 또 어떤 제품은 처음에는 싸 보이지만, 실제로 필요한 기능이 별도 비용으로 빠져 있을 수 있다. 핵심은 가격이 싼지 비싼지만 보는 것이 아니라, 필요한 기능까지 포함한 실제 비용을 먼저 확인해야 한다는 점이다.
RAGProbe는 검색형 AI 시스템이 답을 틀리기 쉬운 질문을 자동으로 만들어 시험하는 도구다. 문서를 잘게 나눈 조각들이 의미 공간에서 서로 어떻게 가까운지 살펴보고, 그 구조에서 약한 부분을 찾는다. 특히 여러 조각을 이어야 답할 수 있는 질문, 문서 안에 묻힌 작은 사실, 헷갈리게 만드는 관련 정보, 경계가 애매한 비슷한 내용에서 실패가 나는지 확인한다. 만들어진 질문은 사용 중인 RAG 파이프라인에 HTTP로 보내지고, 답변은 자동으로 채점된다. 결과는 이전 실행과 비교되어 회귀 차이로 정리되며, CI에서 품질이 나빠졌는지 확인할 수 있다. RAGAS, DeepEval, TruLens 같은 평가 도구와 달리 사람이 테스트 질문을 직접 쓰지 않아도 된다는 점을 내세운다.
의료 기록을 대신 작성하는 8개 LLM을 작은 기준 시험으로 비교했다. 시험에는 가상의 의사-환자 대화 300개가 쓰였고, 각 모델은 대화마다 SOAP 노트를 만들었다. 총 2,400개 노트를 평가한 결과, 큰 영향을 줄 수 있는 확인된 환각은 12건이었다. 반면 안전에 중요한 정보가 빠진 경우는 520건이었다. 이 시험에서는 틀린 내용을 지어내는 문제보다, 꼭 들어가야 할 내용을 빼먹는 문제가 훨씬 자주 나타났다. GPT-5.4-mini는 비용과 속도에 비해 결과가 좋았다. Claude Sonnet과 DeepSeek은 문장 품질이 강했지만, DeepSeek은 저렴하고 글은 잘 쓰는 대신 안전 정보 누락이 많았다. Claude Opus는 누락이 가장 적었지만 문장 품질은 낮았고, Kimi는 확인된 환각이 0건이었지만 이 설정에서는 느리고 비쌌다.
중국에서 최소 7개 회사가 H100·H200급으로 비교되는 AI 가속기를 이미 출하하고 있다. 중국 안에서는 이 구도를 ‘3용 4뱀’으로 부르며, ‘용’은 자체 그래픽처리장치와 전체 기술 묶음을 함께 만드는 대형 기술 기업을 뜻한다. Huawei는 지난해 AI 카드 81만2천 장을 출하해 중국 내 자국산 공급의 49%를 차지했고, 자체 고대역폭 메모리와 생산 기반도 갖춘 것으로 소개된다. Ascend 950은 H200급 성능을 목표로 한다고 알려졌다. ‘뱀’은 최근 상장한 전문 칩 회사들을 뜻하며, 그중 여러 곳은 NVIDIA와 AMD의 전직 수석 그래픽처리장치 설계자들이 세운 회사로 소개된다. MetaX는 AMD 출신 그래픽처리장치 리더십이 중국 선전에 다시 모인 사례로 제시되며, 매출이 3년 동안 약 3,800배 늘었다고 한다. Alibaba는 96GB 비디오 메모리 칩 16개를 넣은 서버를 출하하고 있어, 한 대에서 총 1.5TB 비디오 메모리를 제공한다. 이 정도 메모리는 큰 AI 모델을 BF16 형식으로 한 서버 안에 올리는 데 충분한 규모로 설명된다.
Qwen3.6-35B-A3B와 Gemma4-E2B QAT에서 KV 캐시 양자화가 모델 성능에 주는 영향을 비교했다. q8/q8 설정은 두 모델 모두에서 손실이 거의 없어, 캐시를 줄이면서도 품질 저하가 작았다. q4/q4는 Qwen에서는 쓸 수 있는 수준이었지만 Gemma에서는 성능 손상이 매우 컸다. turbo4는 q4_0보다 조금 나을 때도 있고 나쁠 때도 있어 안정적인 우위가 아니었다. turbo3와 turbo2는 캐시를 매우 크게 줄일 수 있지만, 그만큼 품질 손실을 크게 감수해야 했다. K와 V 중 어느 쪽이 더 민감한지는 모델과 설정에 따라 달랐고, 어떤 경우에는 둘의 영향이 비슷했다. 재현용 코드와 확대 가능한 그래프가 함께 공개되어 다른 모델에도 같은 방식의 검사를 적용할 수 있다.
Qdrant와 ChromaDB는 좋은 오픈소스 벡터 데이터베이스로 언급되지만, 기업의 실제 운영 환경에서는 더 까다로운 조건이 필요할 수 있다. 대규모 AI/RAG 애플리케이션에서는 서비스가 계속 살아 있는지, 사용량이 늘어도 버티는지, 보안 기능이 충분한지, 운영을 대신 맡길 수 있는 관리형 서비스인지가 중요하다. 비교 대상에는 Pinecone, Weaviate, Milvus/Zilliz, Azure AI Search, Amazon OpenSearch, Elasticsearch 등이 포함된다. 핵심 질문은 이런 도구들이 Qdrant나 ChromaDB보다 기업 운영에서 왜 더 나은 선택이 될 수 있는지, 실제 사용 경험에서 어떤 차이가 있었는지다.
원본 업무 문서를 그대로 잘라 벡터 데이터베이스에 넣으면 불필요한 PDF와 HTML 흔적, 들쭉날쭉한 서식, 흐트러진 문장 구조까지 함께 들어간다. 이렇게 더러운 데이터로 검색 증강 생성을 만들면 답변이 엉뚱해지기 쉽고, 모델에 넘기는 문맥도 낭비된다. 문서를 자르기 전에 별도 수집 파이프라인을 두고 PDF와 HTML 잡음을 제거하고, 서식을 통일하고, 텍스트 구조를 먼저 정리했다. 그 결과 검색 한 번에 쓰는 토큰 사용량이 약 50% 줄었고, 환각도 크게 줄었다. 핵심은 더 좋은 프롬프트로 문제를 덮기보다, 모델에 들어가기 전 문서 품질을 먼저 높이는 것이다.
Claude, Cursor, GitHub Copilot, Codex, Antigravity 같은 코딩 AI 도구는 처음에는 비슷해 보일 수 있다. 실제 차이는 매일 쓰면서 드러난다. 비교해야 할 기준은 오류 찾기, 코드 저장소 이해, 리팩터링, 에이전트 작업 흐름 처리 능력이다. 한 가지 도구만 계속 쓰는지, 작업 종류에 따라 여러 도구를 바꿔 쓰는지도 중요한 판단 기준이다. 제품 소개나 기능표보다 실제 사용 경험이 더 도움이 되는 상황이다.
RAG는 정해진 순서로 정보를 찾아 답변에 넣는 방식이다. 보통 문서를 숫자 형태로 바꾸고, 비슷한 내용을 검색한 뒤, 찾은 내용을 모델에 넘겨 답하게 한다. 그래서 사실 확인, 빠른 응답, 비용 예측이 중요한 서비스에 잘 맞는다. 단점은 흐름이 고정되어 있다는 점이다. 처음 검색한 내용이 틀리면 모델이 스스로 다른 방법을 찾아 고치기 어렵다. MCP는 모델이 생각하고, 도구를 쓰고, 결과를 보고, 다시 다음 행동을 정하는 반복 구조에 가깝다. 파일, API, 실시간 데이터처럼 바뀌는 외부 도구를 연결하기 좋지만, 응답이 느려지고 계산 비용이 들쭉날쭉해질 수 있다. 단순한 조회와 빠른 답변이 목표라면 RAG가 낫고, 여러 도구를 오가며 계획을 세워야 한다면 MCP 같은 에이전트 구조가 필요하다.
한 지자체 문서 검색 챗봇 프로토타입이 회의록, 예산, 동의안, 보고서 같은 자료를 시민과 지역 정치인이 쉽게 찾고 이해하도록 돕는 것을 목표로 한다. 이 프로젝트는 오픈소스로 공개되어 있고, 데모도 있다. 이미 단순한 질문에서는 동작하지만, 실제 사용자가 예상 밖의 표현을 쓰거나 여러 주제를 한꺼번에 묻거나 문서에 있는 표현과 다른 말로 질문하면 실패하는 일이 생긴다. 문제의 핵심은 사용자가 데모처럼 인공지능이 이해하기 쉬운 방식으로 질문하지 않는다는 점이다. Agentic RAG는 질문을 다시 쓰고, 여러 번 검색하고, 답변 전 여러 단계를 거치는 방식으로 이런 문제를 줄일 수 있을지 검토되고 있다. 다만 단순 RAG보다 만들고 유지하기가 얼마나 어려운지, 복잡한 질문에 실제로 도움이 되는지가 판단 포인트다.
세 가지 오픈 가중치 TTS 모델을 GPU 없이 CPU만으로 비교했다. 테스트 환경은 Intel Xeon 4코어, 메모리 15.6GB였고, 12자부터 1712자까지 여섯 가지 길이의 문장을 넣었다. 각 조건은 예열 뒤 5번씩 시간을 재서 총 150번 실행했고, 모든 음성 결과는 UTMOS로 점수를 매겼다. Inflect-Nano-v1은 RTF 0.1376, MOS 3.48로 가장 빨랐지만 실제로는 기계음 느낌이 있고 말투가 밋밋해 UTMOS 점수가 실제 체감 품질보다 높게 나온 것으로 보인다. Supertonic-3 2단계 설정은 RTF 0.1781, MOS 1.53으로 빠르지만 품질 점수가 낮았다. Supertonic-3 5단계 설정은 RTF 0.3164, MOS 4.37로 속도와 품질의 균형이 더 좋았다. Kokoro-82M은 ONNX에서 RTF 0.5711, MOS 4.44, PyTorch에서 RTF 0.7865, MOS 4.45로 품질은 높지만 더 느렸다. Inflect-Nano-v1은 약 15초 출력 제한이 있어 긴 문장을 조용히 잘라내므로, 긴 글 처리 속도는 실제보다 좋게 보일 수 있다.
AI 코딩 에이전트를 여러 개 동시에 돌리면 토큰 비용보다 사람이 작업 사이를 오가는 시간이 더 큰 부담이 될 수 있다. 한 서비스는 에이전트가 긴 작업을 처리하는 동안 개발자가 광고를 보고 몇 센트를 받게 한다는 방식으로 빈 시간을 수익화하려 한다. 하지만 더 중요한 문제는 그 빈 시간 자체가 아니라, 여러 에이전트가 멈출 때마다 사람이 각 작업의 상태를 다시 떠올려야 한다는 점이다. 네다섯 개의 작업을 번갈아 확인하면, 무엇을 시켰는지, 어디까지 진행됐는지, 다음에 무엇을 지시하려 했는지를 계속 다시 불러와야 한다. 그래서 실제 비용은 모델 품질이나 토큰만이 아니라 문맥 전환에서 생긴다. 에이전트를 많이 병렬로 실행하는 능력보다, 각 에이전트의 진행 상태와 다음 행동을 사람이 쉽게 이어받게 만드는 운영 방식이 더 중요해진다.
녹음 파일을 올리고 잠시 기다려 글자로 바꾸는 일에는 Whisper, faster-whisper, whisper.cpp가 여전히 좋은 기본 선택지다. 특히 음성을 외부 서버로 보내기 싫거나 내부에서 직접 처리해야 할 때 강점이 있다. 하지만 사용자가 말하는 즉시 일부 문장이 나오고, 그 내용을 바탕으로 인공지능 에이전트가 바로 생각하고 답해야 하는 실시간 음성 앱은 요구 조건이 다르다. 이 경우 짧게 끊어 처리할 때 생기는 지연, 말이 끝났는지 판단하는 VAD와 endpointing 조정, 화자 구분 부족, 시간 표시 보정, 여러 언어가 섞인 음성 처리, 규모가 커질 때 GPU 비용, 낮은 p95 지연시간 확보, 직접 운영해야 하는 인프라 부담이 문제가 된다. 그래서 Deepgram, AssemblyAI, Speechmatics, Soniox, Gladia, OpenAI 실시간·음성 변환 기능, Smallest AI Pulse 같은 스트리밍 음성 인식 API가 대안으로 비교되고 있다. 핵심 판단 기준은 지연시간, 동시 사용자 수, 화자 구분, 유지보수 부담, 비용 중 무엇이 제품에 가장 큰 병목이 되는지다.
에이전트가 과거 기록을 다시 찾아 써야 할 때, 벡터 검색은 긴 글이나 문장처럼 말의 뜻이 중요한 자료에는 잘 맞는다. 하지만 “어떤 선택지를 골랐는지”, “어느 계정인지”, “다음에 무엇을 해야 하는지”처럼 표의 행과 열에 담긴 구조화된 기억을 찾을 때는 약할 수 있다. 임베딩은 비슷한 의미를 넓게 묶어 주지만, 정확한 필드와 조건을 맞춰야 하는 구조를 흐리게 만들 수 있다. 대안으로 에이전트의 구조화된 과거 기록을 직접 조회하고, 필요한 필드를 예측한 뒤, 신뢰도 점수를 붙여 낮을 때만 LLM으로 넘기는 방식이 제안됐다. 해당 데이터에서는 적은 양의 자료만으로도 필요한 문맥을 약 65% 맞게 되찾았고, 벡터 검색이 놓친 경우를 일부 보완했다. 다만 언어 의미를 깊게 이해해야 하는 기억 검색에서는 여전히 임베딩이 더 알맞다. 이 방식은 에이전트가 반복해서 수행하는 대량의 구조화 조회에 더 잘 맞는다.