AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
녹음된 회의를 글로 바꾸고, 각 문장에 말한 사람과 시간을 붙이려면 음성 인식만으로는 부족하다. Whisper, Parakeet, Voxtral 같은 공개 음성 인식 도구는 주로 ‘무슨 말을 했는지’를 만들지만, ‘누가 말했는지’까지 자동으로 잘 나누지는 않는다. 공개 도구 중에서는 WhisperX가 한 번에 쓸 수 있는 대표적인 조합이다. WhisperX는 faster-whisper로 말을 글로 바꾸고 대략적인 시간을 붙인 뒤, wav2vec2 forced alignment로 단어별 시간을 더 정확히 맞추고, pyannote로 말한 사람의 구간을 나눈 다음, 두 시간표를 겹쳐 단어마다 화자를 붙인다. 실제 회의 음성에서는 정확도가 크게 떨어질 수 있다. Whisper large-v3는 깨끗한 LibriSpeech 음성에서는 단어 오류율이 약 2%지만, 실제 회의에 가까운 AMI meeting audio에서는 약 16%로 나빠진다. 조용한 구간에서 Whisper가 없는 말을 만들어내는 문제도 있어, VAD로 말이 있는 구간만 골라내고 condition_on_prev_text=False 설정을 쓰는 방식이 도움이 된다. 여러 사람이 동시에 말하거나 멀리서 녹음된 소리가 섞이면 화자 분리 오류가 가장 크게 늘어난다.
민감한 문서를 쓰는 RAG 시스템은 평가 단계에서도 내부 데이터가 외부로 나갈 수 있다. 인터넷 연결을 끊고 평가 도구를 실행하면, 어떤 부분이 외부 모델을 부르는지 바로 확인할 수 있다. 연결 오류가 나는 평가 항목은 보통 호스팅된 채점 모델에 질문, 검색된 문서 조각, 생성된 답변을 보내고 있다는 뜻이다. 원격 임베딩 API를 쓰면 색인 단계에서 문서가 밖으로 나간다는 점은 비교적 잘 알려져 있다. 하지만 검색 결과가 맞는지, 답변이 문서에 충실한지 평가하는 단계에서도 채점 모델이 질문과 문서 조각과 답변을 함께 봐야 하므로 더 민감한 정보가 외부로 전달될 수 있다. 공개 문서 챗봇이면 큰 문제가 아닐 수 있지만, 계약서, 환자 기록, 내부 소스 코드, 고객 문의 같은 자료라면 외부 채점 모델에 맡기기 어렵다. 제안된 방식은 평가 코드를 직접 읽고, 포크하고, 내부망에서 실행할 수 있는 Apache-2.0 오픈소스 형태로 쓰는 것이다.
기관의 계약서, 규정, 기술 문서에는 조항, 정의, 참조 관계가 많지만 컴퓨터가 바로 믿고 쓰기에는 형태가 제각각이다. LLM은 이런 문서에서 사람, 조직, 규칙, 관계 같은 정보를 뽑아내는 일은 꽤 잘하지만, 그 결과를 곧바로 믿을 수 있는 지식 그래프로 만드는 것은 별개의 문제다. 같은 문서를 다시 읽히거나 모델, 프롬프트, 주변 문맥이 바뀌면 결과가 달라질 수 있다. 처음 정한 온톨로지도 새 문서 유형, 전문가 검토, 다른 팀의 요구 때문에 계속 바뀐다. 그래서 추출 결과는 저장 전에 스키마 검증, 중복 확인, 충돌 확인, 값의 상식적 범위 확인을 거쳐야 한다. 모든 정보에는 원본 문서, 사용한 모델 버전, 추출 시점, 자동 검증 여부, 사람 검토 여부 같은 출처 추적 정보가 붙어야 한다. 신뢰도가 높은 결과는 바로 저장하고, 애매하거나 충돌이 있는 결과는 사람 검토 대기열로 보내는 방식이 필요하다. 프롬프트, 모델, 스키마가 바뀔 때마다 확인할 수 있는 평가 데이터셋도 있어야 품질 하락을 빨리 잡을 수 있다.
인공지능 에이전트의 메모리는 보통 필요한 정보를 얼마나 잘 찾아오느냐에 초점이 맞춰진다. 하지만 그 전에 같은 사람이 여러 방식으로 접속할 때 한 사람으로 묶는 문제가 먼저 해결돼야 한다. 같은 사용자가 익명 브라우저 아이디, 로그인한 아이디, 서버 내부 아이디로 각각 나타나면 메모리 시스템은 이들을 서로 다른 사람으로 볼 수 있다. 그러면 한 세션에서 저장된 문맥이 다음 세션이나 다른 기기에서 이어지지 않는다. 실제 구현에서는 로그인 사용자 아이디를 기준으로 할지, 특정 값을 해시할지, 아니면 앱 쪽에서 이 문제를 처리하게 할지 결정해야 한다.
오프라인 사내 환경에서 n8n으로 회사 내부 문서 질의응답 흐름을 만들고 있다. 문서는 Qdrant에 임베딩으로 저장되고, 임베딩 생성에는 qwen3 임베딩 모델이 쓰인다. 모델 실행은 Ollama로 처리한다. 사용자의 질문에 답하는 단계에는 AI 에이전트 노드가 있고, 대화 모델은 Qwen3-Coder 30B를 사용한다. Qdrant 검색기 출력에는 관련 자료가 들어 있지만, 에이전트가 그 내용을 제대로 묶어 정확한 답으로 만들지 못한다. 일부 답변에는 환각도 나타난다. 더 큰 대화 모델은 하드웨어 제약 때문에 쓰기 어렵기 때문에, 현재 흐름 안에서 정확도를 높일 방법이 필요하다.
몇 달 동안 단일 파일 three.js 게임을 한 번의 지시로 만들게 하는 실험이 이어졌다. 마인크래프트 복제처럼 학습 자료에 많이 있고, 눈으로 결과를 확인하기 쉬운 과제가 주로 쓰였다. 목적은 모델 품질 비교가 아니라, 싸게 반복할 수 있는 과제로 실행 틀, 시스템 프롬프트, 도구 호출 방식을 조정하는 것이었다. 이번에는 난도를 올려 Claude Code의 Opus 4.8과 로컬 Qwen3.6 27B 에이전트가 순수 C와 표준 라이브러리만으로 작은 레이 트레이싱 1인칭 슈팅 데모를 만들게 했다. 두 에이전트 모두 처음에는 한 번에 완성하기 어려워했다. 이후 컴파일된 프로그램에 헤드리스 모드를 넣고, 에이전트가 키보드와 마우스 입력을 넣은 뒤 원하는 프레임에서 스크린샷을 찍을 수 있게 하라는 요구를 추가하자 결과가 크게 좋아졌다.
LLM 심판이 어떤 답변을 통과시켜도, 사람이 같은 답변을 보고 안전하지 않다고 판단하는 경우가 있다. 문제는 LLM 심판이 정해진 채점 기준을 완전히 틀리게 읽는 것이 아니라, 그 기준이 사람이 아는 미묘한 위험을 담지 못한다는 데 있다. 예를 들어 작은 정책 위반, 규칙상 맞지만 실제 고객을 불쾌하게 만들 수 있는 말투, 답은 맞지만 상황에 맞지 않는 응답이 빠질 수 있다. 모든 평가에 사람을 붙이면 비용과 시간이 너무 커지기 때문에, LLM 심판을 쓰는 목적 자체가 약해진다. 핵심 과제는 안전성 판단에서 LLM 심판과 사람의 판단이 갈릴 때 그 차이를 어떻게 줄이느냐이다.
LatentGate는 이미지, 긴 글, 대화 기록, 검색용 문서를 먼저 개인 컴퓨터에서 줄인 뒤, 핵심 내용만 외부 AI 모델로 보내는 파이썬 도구다. 로컬 처리는 Ollama로 실행하며, OpenAI, Anthropic, Google, Groq 같은 여러 외부 AI 서비스와 연결할 수 있다. 목표는 외부 AI에 보내는 토큰 수를 크게 줄여 비용을 낮추는 것이다. 예시 기준으로 이미지를 바로 외부 AI에 보내면 약 1,200 토큰이 들지만, LatentGate를 거치면 약 200 토큰만 보낸다고 제시한다. 긴 글은 약 800 토큰에서 120 토큰, 10턴 대화는 약 2,500 토큰에서 350 토큰, 문서 3개 기반 질문은 약 3,000 토큰에서 450 토큰으로 줄어든다는 벤치마크가 있다. 1만 번의 이미지 질문을 gpt-4o-mini로 처리할 때 입력 토큰은 1,200만 개에서 200만 개로 줄고, 비용은 1.80달러에서 0.30달러로 낮아진다고 제시한다. Claude Desktop, Cursor, Cline, Continue, Zed 같은 도구에서는 MCP 서버로 붙여 이미지, 긴 프롬프트, 큰 대화 기록, 문서 질문을 자동으로 압축하게 할 수 있다. 반복 이미지 캐시, 모델 미리 올리기, 병렬 처리, 영상에서 장면이 바뀔 때만 호출하는 방식도 포함되어 있다.
GLM-5.2의 공개 벤치마크 수치는 여러 평가에서 GPT-5.5와 비슷한 구간에 있고, Opus 4.8에도 크게 뒤처지지 않는 것으로 보인다. 6개월 전만 해도 중국계 모델이 이 정도로 상위권 모델과 겹치는 결과를 내는 일은 드물었다. 다만 에이전트형 코딩 작업에서는 점수만큼 중요한 토큰 비용 차이가 아직 크다. GLM-5.2 Max는 비슷한 점수를 내기 위해 Opus 4.7 Max보다 거의 두 배에 가까운 토큰을 쓰는 것으로 제시됐다. Opus 4.8 High는 같은 점수 대비 토큰을 더 적게 쓰는 쪽에서 훨씬 앞서 있다. 실제 사용에서는 API 비용을 줄이기 위해 일부 작업을 중국계 모델로 옮길 수 있지만, 조건이 많이 붙은 어려운 추론 작업은 여전히 Claude 쪽이 더 안정적이다. GLM-5.2도 큰 작업에서는 더 느리고 토큰을 더 많이 쓰는 경향이 있어 완전한 대체재라기보다 작업을 나눠 맡기는 선택지에 가깝다.
목표는 PPTX와 PDF로 된 프로젝트 자료에서 업무, 주요 일정, 위험, 이슈, 담당자, 상태, 날짜를 구조화된 데이터로 뽑아내는 것이다. 가장 어려운 부분은 간트 차트다. 문서마다 시간 표시 방식이 달라서 월, 분기, 연도, 주 시작일, 회계 기간이 섞일 수 있고, 막대 모양, 마일스톤 아이콘, 범례, 배치도 제각각이다. 어떤 자료는 PPTX 안의 실제 도형으로 되어 있고, 어떤 자료는 이미지나 납작한 PDF처럼 편집할 수 없는 형태다. 안정적인 추출을 위해서는 거대언어모델과 시각언어모델의 판단, 정해진 규칙 기반 추출, 문자인식, 파일 파싱, 좌표/도형 기반 날짜 매핑을 함께 써야 할 가능성이 크다. 핵심 과제는 특정 양식에 맞춘 하드코딩 없이 다양한 간트 시각 자료에서 업무 시작일, 종료일, 마일스톤 날짜를 믿을 만하게 찾아내는 것이다.
그래프 기반 검색 파이프라인에서 큰 문제는 검색기나 대규모 언어 모델이 아니라 관계의 뜻을 잘못 이어 붙이는 데서 생길 수 있다. 예를 들어 “사람이 팀을 관리한다”와 “팀이 도구를 쓴다”라는 두 관계는 각각 맞아도, 이를 합쳐 “그 사람이 그 도구를 쓴다”라고 결론 내리면 틀릴 수 있다. 팀이 쓰는 도구를 관리자가 직접 쓴다고 볼 수는 없기 때문이다. 쿼리 엔진은 문법이 맞는지만 확인하므로 이런 의미 오류를 잡기 어렵다. 스키마 검증은 자료형 불일치는 잡았지만, 사람이 팀의 속성을 물려받아도 되는지는 확인하지 못했다. 쿼리 로그는 어떤 검색이 실행됐는지만 보여줬고, 왜 답이 틀렸는지는 알려주지 못했다. 대규모 언어 모델에게 스스로 답을 검토하게 해도, 잘못된 검색 문맥이 그 결론을 뒷받침하고 있어서 오히려 틀린 답을 자신 있게 확인했다.
소비자용 인공지능이 단순한 도구를 넘어서려면 대화가 매번 끊기는 느낌을 줄여야 한다. 지금의 많은 인공지능 제품은 질문을 넣고 답을 받은 뒤 끝나는 방식이라, 일 처리에는 좋지만 정서적으로 계속 쓰고 싶은 이유는 약하다. 더 강한 제품은 사용자를 기억하고, 사용자가 어떻게 생각하는지 이해하고, 시간이 지날수록 더 잘 맞춰 주는 쪽에 가깝다. 이런 제품은 일반적인 조수보다 ‘대화하고 싶은 상대’에 가까워야 한다. 자주 쓰이고 오래 남으려면 휴대전화 안에 있어야 할 가능성이 크다. 브라우저 탭이나 데스크톱 도구는 이런 개인적이고 반복적인 사용에는 거리감이 있다.
Anthropic 같은 인공지능 회사들이 “AI 안전”을 이유로 모델 접근을 제한하지만, 실제로는 돈과 통제권을 지키는 일에 가깝다는 비판이다. 이 관점은 대형 인공지능 서비스가 오픈소스 기술, 공개 연구, 인터넷의 사람 지식 위에 세워졌다고 본다. 그런데 회사가 충분한 힘을 얻은 뒤에는 누가 제대로 접근할 수 있는지, 누가 개발하거나 연구할 수 있는지, 누가 일반 소비자용 기능에만 묶이는지, 누가 비용 때문에 밀려나는지를 회사가 정한다고 지적한다. 안전 자체는 필요하지만, 모든 제한을 안전이라는 말로 설명하면 이용자와 개발자가 실제 선택권을 잃을 수 있다는 문제 제기다. 결국 공공 지식에서 나온 도구가 비싼 폐쇄형 상품으로 바뀌고, 가드레일이 붙은 형태로 다시 팔린다는 불만이다.
RAG 데모는 좋아 보였지만 실제 사용자가 쓰기 시작하자 답변 정확도가 크게 떨어졌다. 단순한 벡터 검색만으로는 부족했다. 뜻이 비슷해 보이는 문서 조각이 실제로는 틀린 정보를 담는 경우가 많았기 때문이다. BM25와 밀집 검색을 함께 쓰는 하이브리드 검색에 재순위화 단계를 더하자, 모델을 바꾸는 것보다 더 큰 개선이 있었다. 문서를 어떻게 나누는지도 모델 선택보다 더 큰 영향을 줬다. 일정한 길이로 자르면 표와 코드가 깨졌고, 문서 구조를 고려해 나누자 많은 문제가 줄었다. 평가 기준이 없으면 개선 여부를 알 수 없어서, 정답 예시 묶음을 만들고 변경할 때마다 검색 정확도를 재었다. 좋아 보이던 개선 중 절반은 실제로는 성능을 떨어뜨렸고, 대부분의 개선은 프롬프트 손질이 아니라 검색 설계에서 나왔다.
Astraea.cpp와 Python용 Astraea는 뉴질랜드 임대차 법을 묻는 세입자용 질의응답 도구다. 구조는 법령을 먼저 찾는 RAG 방식이다. 주거임대차법, 건강한 주거 기준, 임대차 재판소 결정문, 공식 Tenancy Services 안내를 각각 색인한다. 검색도 법령, 공식 안내, 판례를 따로 나누어 처리한다. 중요한 법 조항은 정해진 규칙으로 바로 연결하고, 그 규칙이 작동하지 않을 때도 법령 검색의 확신이 높으면 벡터 검색 결과를 보조 단서로 쓴다. 답변 생성은 로컬 대형 언어 모델이 맡고, 인용 출처를 붙인다. 시스템은 모델이 실제로 본 문맥과 디버그 출력도 보여준다. 별도로 검증된 실제 임대차 질의응답 300개가 있지만, 이 답변들은 실용 조언은 좋더라도 법 조항이나 재판소 인용이 항상 들어 있지는 않아 최종 법률 정답이 아니라 최소한의 실용 조언 기준으로 쓰려 한다.
로컬 모델은 1년 전만 해도 개인정보 보호용 채팅, 간단한 대화, 작은 문서 검색 작업 정도에 쓰이는 장난감에 가까웠다. 지금은 Gemma, Qwen, GLM, Kimi 같은 모델이 코딩, 개인 문서 처리, 내 컴퓨터 안에서 돌아가는 작업 흐름, 일부 유료 API 호출 대체에 쓰이고 있다. 다만 큰 코드 저장소를 오래 붙잡고 계획을 세우고, 넓은 문맥을 이해하고, 스스로 실수를 고치는 일에서는 아직 최고 수준의 비공개 모델을 완전히 대체하지 못한다. 최근의 변화는 기본 모델 품질 향상, 양자화 개선, llama.cpp와 Ollama 같은 실행 도구 발전, 더 큰 비디오 메모리 보급 같은 여러 요인이 함께 만든 결과로 보인다.
기본적인 사이드 프로젝트를 Cursor와 Claude에 거의 맡겨 진행하면 처음에는 작업 속도가 매우 빨라 보일 수 있다. 초기 설정은 한 시간 안에 끝날 만큼 쉬워진다. 하지만 프로젝트가 조금만 복잡해지면 긴 컨텍스트를 계속 읽고, 프롬프트를 고치고, 인공지능이 같은 실수를 반복하지 않게 확인하는 시간이 늘어난다. 문법 오류를 직접 고치는 일은 줄어도, 대신 인공지능을 계속 돌보고 지시를 다시 쓰는 일이 생긴다. 핵심 로직까지 모두 맡기기보다, 반복적인 기본 코드는 인공지능에 맡기고 중요한 부분은 직접 작성하는 방식이 더 생산적일 수 있다.
AI 에이전트가 널리 쓰이지 못하는 이유로 신뢰성, 비용, 신뢰, 사용하기 쉬운 화면, 뚜렷한 성공 사례 부족이 함께 거론된다. 여러 의견은 특히 신뢰성을 가장 큰 문제로 본다. 회사들이 AI 에이전트로 바꾸려는 일 중 상당수는 사실 단순 자동화에 가깝고, 이런 일에는 예측 가능한 일반 스크립트가 더 싸고 안정적일 수 있다. AI 에이전트는 필요한 정보가 빠졌을 때 스스로 빈칸을 채우다가 환각을 만들 수 있고, 이 때문에 실제 도입 시험에서 컴플라이언스 테스트를 통과하지 못할 수 있다. 개선 방향으로는 막연한 지시 대신 분명한 지시를 주고, 과거 요청, 성공한 응답, 결과 같은 문맥을 함께 넣으며, 매개변수 기반 제한으로 답변 범위를 좁히는 방식이 제시됐다. 또 다른 장벽은 지식 격차다. 좋은 에이전트를 만드는 법을 아는 사람도 적고, 어떤 업무에 에이전트가 필요한지 아는 사람도 아직 많지 않다.
Claude로 AI 에이전트를 만들 때, 많은 정보를 한 번에 넣을 수 있어도 긴 대화에서는 중요한 흐름을 놓칠 수 있다. 토큰 한도와 메모리는 같은 문제가 아니다. 큰 문맥 창은 한 번의 프롬프트에 더 많은 정보를 넣게 해주지만, 오래 보관할 내용, 줄여서 저장할 내용, 잊어도 되는 내용, 다음 사용 때 다시 써야 할 사용자 선호나 결정까지 자동으로 정리해주지는 않는다. 실무 경험상 메모리 문제의 핵심은 단순히 더 긴 입력 공간이 아니라, 필요한 정보를 찾아오는 방식과 저장 구조에 가깝다. 긴 프롬프트는 나쁜 메모리 설계를 가릴 수 있고, 모델이 더 똑똑해 보이게 만들 수 있지만 실제로 오래 기억하는 능력을 보장하지 않는다. 중요한 과제는 어떤 정보를 프롬프트 밖에 따로 보관할지 정하는 것이다.
음성 에이전트는 말소리를 글로 바꾸고, 인공지능이 답을 만들고, 다시 음성으로 읽어 주는 흐름으로 작동한다. 이 흐름은 음성 인식, 언어 모델, 음성 합성, 말 끊김 판단, 전화 연결 같은 여러 부품이 함께 움직여야 해서 배우기 어렵다. 공개 학습 경로는 기초 개념부터 시작해 LiveKit Agents나 Pipecat 같은 도구로 간단한 예제를 만들고, 각 부품을 바꿔 보며 역할을 익히도록 구성되어 있다. 그다음 실제 전화번호를 SIP로 연결하는 단계와, 서비스로 내보내기 전에 평가와 안전 점검을 하는 단계로 이어진다. 자료는 190개가 넘고, 난이도별로 분류되어 있으며, 상업 자료는 따로 표시되어 있다. 마지막에는 5주짜리 학습 계획도 포함되어 있다. 운영 단계에서는 미국 FCC와 유럽연합 인공지능법 같은 규칙도 고려해야 한다.
상거래를 처리하는 AI 에이전트는 단순히 거대 언어 모델이나 도구 연결만으로는 부족할 수 있다. 상품, 서비스, 할인, 제휴 조건을 에이전트가 바로 확인할 수 있는 발견 API가 별도 계층으로 필요하다. 이 계층은 어떤 제안이 실제로 있는지, 어떤 판매자가 지원하는지, 적용 지역과 분야가 무엇인지, 수수료나 결제 조건이 어떻게 되는지 알려줘야 한다. 또 사용자가 어떤 정보를 봐야 하는지, 클릭과 구매 전환을 어떻게 추적하는지, 실제 과금이 어떤 방식으로 이뤄지는지도 다뤄야 한다. 이런 구조가 없으면 개발자는 판매자마다 따로 연결하거나, 일반 제휴 링크를 붙이거나, 작업 흐름마다 추적 시스템을 새로 만들어야 한다. 제품 추천은 소프트웨어, 업무 도구, 지역 서비스, 금융 상품, 여행, 교육, 온라인 쇼핑을 다루는 에이전트에서 기본 기능이 될 가능성이 있다.
수천 개의 PDF에서 제품 번호와 가격을 꺼내 관계형 테이블에 넣어야 하는 상황이다. 파일마다 형식이 달라서 어떤 PDF는 깔끔한 표가 있고, 어떤 PDF는 문단 안에 가격이 흩어져 있다. 배송비나 다른 조건처럼 최종 가격에 영향을 주는 정보도 함께 처리해야 한다. 더 어려운 점은 이런 조건이 모든 제품에 적용되지 않고 일부 제품에만 적용될 수 있다는 것이다. 선택지는 Amazon Bedrock Data Automation 같은 관리형 서비스와, 대형 언어 모델에 PDF를 넣고 구조화된 결과와 신뢰도를 받는 방식이다. 관리형 서비스는 운영에는 편할 수 있지만, 수천 개 문서를 처리하면 비용 부담이 커질 수 있다. 실제 운영에서 어떤 방식이 버텼는지, 정확도가 어느 정도였는지, 비용을 어떻게 통제했는지가 핵심 문제다.
AI 에이전트가 상품을 추천하고 사용자가 구매하는 흐름은 겉보기보다 복잡하다. 사용자는 구매 전에 여러 질문을 할 수 있고, 에이전트는 여러 상품을 비교한 뒤 추천할 수 있다. 추천은 도구 호출 뒤에 나올 수도 있고, 사용자는 나중에 클릭하거나 다른 기기와 다른 방문에서 구매할 수도 있다. 그래서 실제 구매에 누가 얼마나 영향을 줬는지 판단하기 어렵다. 어떤 상품이 추천됐는지, 추천이 광고성인지 자연스러운 답변인지, 충분한 표시가 있었는지, 어느 판매자가 비용을 내야 하는지도 따져야 한다. 낮은 품질의 방문이나 부정행위도 걸러야 한다. 이런 신뢰 장치가 없으면 판매자는 AI 에이전트를 통한 거래를 믿고 돈을 내기 어렵다. 기존 제휴 링크를 그대로 쓰기보다, 에이전트 거래에 맞는 새 기반 시스템이 필요하다는 주장이다.
인공지능 에이전트는 같은 일을 시켜도 한 번은 잘 작동하고 다음번에는 다른 행동을 할 수 있다. 예를 들어 다른 도구를 호출하거나, 다른 입력값을 넘기거나, 엉뚱한 분기로 빠지거나, 반복에 갇히거나, 상태 관리 문제를 일으킬 수 있다. 실행 추적 로그가 남아 있어도 어디서 행동이 달라졌는지 사람이 직접 비교해야 해서 시간이 많이 든다. 이를 줄이기 위한 도구 아이디어는 재실행 결과를 기준 실행과 비교해 처음으로 흐름이 달라진 지점을 바로 보여주는 것이다. 현재 대안으로는 LangSmith, Langfuse, 평가, 맞춤 로그, 수동 추적 비교 같은 방식이 거론된다.
검색 광고는 사용자가 검색어를 입력하고, 결과 화면에 광고가 나오고, 광고들이 노출 위치를 두고 경쟁하는 구조에 맞춰져 있다. 클릭률과 구매 같은 전환 효과도 비교적 뚜렷하게 추적된다. AI 에이전트에서는 이 구조가 잘 맞지 않을 수 있다. 사용자의 의도는 대화, 검색창, 작업 요청, 도구 호출, 추천 흐름 속에 흩어져 나타날 수 있다. 사업 성과도 눈에 띄는 광고 자리 하나가 아니라 추천, 비교표, 도구 결과, 작업 안에 숨어 있는 할인처럼 나타날 수 있다. 그래서 단순한 순위 경쟁만으로는 부족하고, 정보 공개, 인용 메타데이터, 추적, 정산, 판매자 보고 같은 기반 기능이 함께 필요하다. AI 기반 사업 발견은 검색 광고나 내부 챗봇에 머물지 않고, 검색 의도, 지능형 비서 추천, 제휴 마케팅, 판매자 보고가 섞인 새 형태가 될 수 있다.
제품 기획 업무에서 14개 자료를 한 전략 문서로 합치는 실제 Q3 브리프가 Minimax M3에 입력됐다. 자료는 PDF, 실적 발표 녹취록, 애널리스트 노트 2개였고, 전체 분량은 약 34만 토큰이었다. 목표는 여러 자료를 종합하면서 어떤 주장에 어떤 출처가 붙는지 계속 보존하는 것이었다. 출처 표시는 긴 입력 전체에서 비교적 잘 유지됐다. 예를 들어 한 주장이 Gartner 노트에서 왔는지, 경쟁사 실적 발표에서 왔는지 다시 묻지 않아도 구분할 수 있었다. 문제는 약 20만 토큰을 넘긴 뒤부터 종합 내용이 지나치게 확신 있게 바뀐 점이었다. 그 아래에서는 단서와 예외가 유지됐지만, 그 위에서는 서로 충돌하는 내용을 충돌로 표시하기보다 억지로 맞춰 해석하는 경향이 생겼다. Minimax M3가 내세운 BrowseComp 83.5 점수와 ICLR 재현 작업 사례는 장문 종합 업무와는 다른 종류의 성능이라, 실제 긴 문서 작업에서도 같은 안정성이 나오는지는 별도로 확인해야 한다.
ROS-1 Lite는 GPT를 이용해 AI 답변의 결론 구조를 평가하는 초기 공개 도구다. 핵심 생각은 단순하다. 많은 답변은 맞다, 틀리다로만 나뉘지 않는다. 어떤 답변은 충분한 근거로 결론을 냈고, 어떤 답변은 아직 모르는 점을 남겨야 하며, 어떤 답변은 여러 가능성을 함께 유지해야 한다. ROS-1 Lite는 답변을 RESOLVED, OPEN, SUPERPOSED, COLLAPSED 같은 상태로 나눈다. 또 근거가 너무 부족한지, 반대로 근거보다 과하게 복잡한 설명을 붙였는지, 새 용어가 실제 판단 기준에 묶여 있는지도 본다. 이 도구는 정답을 보장하거나 전문가 판단을 대신하지 않는다. 대신 어떤 근거가 결론을 받치고 있는지, 무엇이 빠졌는지, 답변이 너무 빨리 닫혔는지를 드러내는 데 초점을 둔다.
patchright-cli는 AI 에이전트가 명령줄에서 실제 Google Chrome을 열고 조작하게 해 주는 작은 공개 도구다. 보통 쓰는 Playwright나 CDP 방식은 일부 웹사이트에서 자동화 도구로 감지되어 막힐 수 있다. 이 도구는 Patchright를 안쪽에서 사용해 그런 차단을 줄이려는 목적이다. 기본 사용 흐름은 `open`, `snapshot`, `click`, `close`처럼 단순한 명령으로 되어 있다. playwright-cli와 patchright-cli가 서로 바꿔 쓸 수 있게 맞춰져 있어서, 에이전트가 어떤 도구를 써야 하는지 따로 판단하지 않아도 된다. 화면이 실제로 열리는 Google Chrome을 쓰기 때문에 여러 웹사이트 접근에서 일반 브라우저 자동화 도구보다 잘 작동할 수 있지만, 완벽한 해결책은 아니다. 탭을 계속 열어 두면 자원을 많이 쓰기 때문에, 에이전트가 무거운 탭을 닫도록 하는 간단한 힌트도 함께 들어 있다.
Claude Desktop의 코드 모드는 코드 결과를 보기 좋게 보여주고, MCP를 통한 브라우저 조작과 화면 확인 작업에도 쓸 수 있다. 필요한 방향은 이 편한 작업 화면은 그대로 두고, 답변을 만드는 인공지능 모델은 내 컴퓨터나 내부 서버의 로컬 API로 바꾸는 것이다. 확인하려는 핵심은 Claude Desktop 어디에서 로컬 언어 모델 API 주소를 지정할 수 있는지다. Ollama, llama.cpp, vLLM 같은 로컬 모델 실행 도구의 설치 방법은 이미 알고 있다는 전제다.
H64LM은 PyTorch로 직접 만든 2억 4900만 파라미터 규모의 혼합 전문가 모델입니다. 목적은 강한 성능의 모델을 내놓는 것이 아니라, 최신 대형언어모델이 어떻게 돌아가는지 구조를 직접 구현하며 확인하는 것입니다. 고수준 학습 도구에 기대지 않고 주의집중, 혼합 전문가 라우팅, 정규화, 학습 반복 과정을 직접 만들었습니다. 구조에는 묶음 질의 주의집중, 8개 전문가 중 2개만 골라 쓰는 희소 혼합 전문가 방식, 세 가지 보조 라우팅 손실, SwiGLU, RoPE, RMSNorm, 슬라이딩 윈도우 주의집중이 들어갑니다. 학습 쪽에는 혼합 정밀도 학습, 그래디언트 누적, 직접 만든 학습 루프, 체크포인트 저장과 이어서 학습하기가 포함됩니다. 공개된 체크포인트는 WikiText-103 일부로 전체 학습 흐름이 작동하는지 확인한 수준이며, 10번째 학습 반복 이후에는 과적합이 뚜렷하고 가장 좋은 검증 퍼플렉시티는 약 40.5입니다. 현재 한 번에 1개 샘플만 생성할 수 있고, 진짜 분산 학습은 없으며 DataParallel로 대체되는 한계가 있습니다.