AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
Lyze는 검색 증강 생성(RAG) 방식의 도구로, 텍스트만 다루는 일반적인 구성보다 더 넓은 파일 형식을 목표로 한다. PDF, 이미지, 음성 녹음, 영상 파일을 한곳에 넣고 질문하면, 관련 내용을 파일 전체에서 찾아 답을 만든다. 답이 어느 파일에서 나왔는지도 함께 보여준다. Ollama로 완전히 로컬 실행할 수 있어 API 비용이 들지 않고, 개인 파일이 컴퓨터 밖으로 나가지 않는다. 원하면 Gemini 무료 모델, OpenAI, Anthropic 같은 클라우드 모델도 연결할 수 있다. 화면 쪽은 React와 TypeScript, 서버 쪽은 Python과 FastAPI로 만들었다.
구상 중인 서비스는 사람마다 전용 AI 비서를 제공한다. 사용자는 화면의 채팅뿐 아니라 전화로도 이 비서와 대화한다. 업무는 며칠에 걸쳐 이어지고, 웹앱, 이메일, 전화, 회의록, 데이터 같은 여러 도구를 오간다. AI 비서는 사용자를 돕고 제안도 해야 하지만, 어떤 단계에서는 정해진 절차를 반드시 따라야 한다. 스스로 배우고 개선하는 기능 때문에 Agent Hermes가 후보로 떠올랐고, 정해진 업무 흐름을 다루기 위해 LangGraph와 함께 쓸 수 있는지가 핵심 고민이다. 또 이전에 어디까지 진행했는지 기억해야 하므로 상태 관리도 필요하다. 전문 업무 환경에서 Agent Hermes가 믿고 쓸 만한 선택인지가 중요한 판단 포인트다.
26주짜리 무료 오픈소스 에이전트형 AI 로드맵이 공개되어 16만 회 이상 조회됐다. 목표는 영상을 많이 봐도 실제 결과물을 만들지 못하는 엔지니어가 직접 만들면서 배우게 하는 것이다. 로드맵은 9단계, 60개 이상 모듈, 실제 서비스 수준의 마무리 프로젝트 3개로 구성된다. 다루는 내용은 파이썬 기초, 거대 언어 모델의 작동 방식, 프롬프트 작성, RAG, 여러 AI 에이전트를 함께 움직이는 구성, LLMOps 등이다. 2026년 7월 11일 토요일 오후 7시 IST에는 3시간짜리 무료 첫 실습 수업이 열린다. 이 수업에서는 슬라이드 중심 강의가 아니라, 먼저 작동하는 모습을 본 뒤 함께 Claude Code 에이전트를 만든다. 목표 결과물은 저장소의 PR을 스스로 검토하는 에이전트다. 실습에는 Claude를 데이터와 셸에 연결하는 도구 사용, MCP 연동, 계획-실행-비판 반복 구조가 포함된다.
실서비스에서 대규모 언어 모델 기능을 운영할 때, 어떤 결과는 사람이 확인하고 어떤 결과는 바로 처리할지 정해야 한다. 대상은 고객지원 답변, 콘텐츠 검수 판단, 에이전트의 도구 호출, 요청 분류, 업무 우선순위 나누기 같은 작업이다. 판단 기준으로는 신뢰도 기준, 평가 결과, 사람이 일부만 확인하는 점검, 정책 규칙 등이 쓰일 수 있다. 핵심 문제는 사람 검토를 건너뛴 결과만 따로 오류율을 재고 있는지, 아니면 대시보드나 수동 확인으로 대략 관리하는지다. 실제 운영팀들이 감이 아니라 측정 가능한 근거로 자동 통과 기준을 정하고 있는지가 중요하다.
LLM 출력물을 자동으로 점수 매기는 방식은 명확히 좋은 답과 명확히 나쁜 답은 잘 가르는 편이었다. 입력 데이터와 답변을 모아 두고, 또 다른 LLM이 정답성이나 말투를 평가한 뒤 점수를 시간별로 추적하는 구조다. 하지만 약 50개 답변을 사람이 직접 다시 채점해 보니, 애매한 답변에서는 자동 평가와 사람 평가가 약 3분의 1 정도 어긋났다. 겉으로는 맞는 말이지만 질문의 핵심을 놓친 답변이 높은 점수를 받기도 했다. 반대로 충분히 괜찮아 보이는 답변이 말투 문제로 낮은 점수를 받기도 했고, 그 이유가 분명하지 않았다. 더 큰 문제는 평가에 쓰는 모델도 시간이 지나며 바뀔 수 있다는 점이다. 모델이 업데이트되거나 사라지면 평가 기준이 조금씩 달라질 수 있고, 대시보드 점수는 변했는데 실제 제품 품질 변화인지 평가 모델 변화인지 구분하기 어려워진다. 그래서 사람 평가와 주기적으로 맞춰 보는 일, 평가 모델 버전을 고정하는 일이 필요해진다.
독일의 병원, 치과, 의원 같은 의료기관을 대상으로 AI 예약 도우미를 만드는 아이디어다. 주요 기능은 진료 예약 요청 처리, 예약 취소, 알림 발송, 자주 묻는 질문 답변, 초진 문진표 수집, 접수팀으로 메시지 전달 등이다. 핵심 걱정은 독일과 유럽의 개인정보 보호 규정인 GDPR을 지키면서 건강 관련 데이터를 다룰 수 있는지다. 또 의료기관이 실제로 돈을 낼 만큼 수익성 있는 시장인지도 불확실하다. 처음부터 의사나 치과를 고객으로 삼는 것이 좋은지, 아니면 의료 분야는 규제가 강하니 다른 소규모 사업부터 시작하는 것이 나은지가 핵심 판단 지점이다. 가장 단순한 MVP는 예약 변경, 알림, 기본 문의 응답처럼 위험한 의료 판단을 피하고 접수 업무 부담을 줄이는 기능에 가까울 가능성이 크다.
목표 모드는 AI 에이전트에게 일을 하나씩 지시하는 대신, 달성해야 할 결과를 먼저 정해 주는 방식이다. 핵심은 목표, 성공 기준, 제약 조건, 사람에게 넘겨야 하는 조건, 멈출 조건을 함께 적는 것이다. 이렇게 하면 에이전트는 계획하고, 실행하고, 결과를 확인하고, 부족하면 다시 고치는 흐름을 반복한다. 예를 들어 여행 계획에서는 예산 6,000달러, 방문 도시, 숙소 평점, 하루 평균 걷는 양 같은 조건을 정하고, 모든 조건을 만족한 일정이 완성될 때 멈춘다. 소프트웨어 배포 준비에서는 테스트 통과, 문서 갱신, 치명적 버그 없음, 배포 요약 작성 같은 체크를 에이전트가 스스로 확인한다. Claude Code는 `/goal` 명령으로 이 방식을 쓸 수 있고, `.claude/commands/` 폴더에 재사용할 슬래시 명령을 저장할 수도 있다. OpenClaw, Hermes Agent, OpenAI Codex CLI 같은 도구들도 단순한 지시 수행보다 목표 달성과 완료 판단을 중시하는 흐름으로 움직이고 있다. 중요한 변화는 속도보다 신뢰다. 사람이 매 단계 확인하는 대신, 무엇을 성공으로 볼지 더 분명히 정하는 쪽으로 역할이 바뀐다.
현장 경험상 많은 사업용 자동화가 처음에는 작동하지만 실제 운영에서는 자주 멈춘다. 문제는 만든 사람이 업무 전체를 묻지 않고, 자동화가 건드리는 단계와 그 다음에 일어날 일을 확인하지 않은 채 기능부터 만든 데서 시작된다. 빈 값이 들어오거나 API가 사용량을 제한하면 오류 처리가 없어 흐름 전체가 멈추고, 고객은 고치는 방법을 모른다. 깨끗한 시험 데이터에서는 맞아 보였던 규칙도 실제 프로덕션 데이터에서는 틀어질 수 있다. 문서, 주석, README가 없으면 왜 그렇게 만들었는지 알 수 없어 나중에 고치기도 어렵다. 모든 작업을 하나의 거대한 흐름에 몰아넣으면 작은 수정도 전체 구조를 알아야 가능하다. API 키가 설정 화면에 그대로 남아 있는 경우도 있어 보안 위험이 생긴다. 자동화가 살아남으려면 누가 책임지는지, 고장 나면 누가 대응하는지, 만든 사람이 떠난 뒤 어떻게 바꿀지까지 정하는 거버넌스가 필요하다.
목표는 회사 데이터를 이용해 사내 지식 관리 시스템을 만드는 것이다. 기반 기술로는 검색 증강 생성(RAG)과 AI 에이전트를 염두에 두고 있다. 현재는 컴퓨터 비전 분야에서 6년 일한 뒤 생성형 AI 프로젝트를 시작하는 단계다. 첫 단계는 SharePoint에 있는 몇 개 문서로 개념 증명을 만드는 것이다. 저장소와 배포 환경은 처음에는 고성능 컴퓨팅 환경을 쓰고, 나중에는 클라우드로 옮길 계획이다. 핵심 고민은 문서 수집, 저장, 검색, 답변 생성, 배포까지 전체 파이프라인을 어떻게 설계해야 하는지다.
AgentHelm은 프리랜서가 고객용 AI 에이전트를 운영할 때 생기는 문제를 줄이기 위한 가벼운 관리 도구다. 핵심 문제는 에이전트가 밤새 같은 일을 반복하며 고객 예산을 많이 쓰거나, 개발자가 자리를 비운 사이 엉뚱한 방향으로 작업을 진행하는 상황이다. AgentHelm은 텔레그램 원격 제어, 안전 장치, 실행 기록 추적, 체크포인트를 제공한다. LangGraph, CrewAI, DSPy 같은 기존 에이전트 제작 도구 위에서 함께 쓸 수 있다. 무료 요금제도 있다.
RAMen은 Redis처럼 빠르게 임시 데이터를 저장하는 메모리 저장소이지만, AI 앱과 AI 에이전트에 맞춘 기능을 함께 넣은 도구다. 기존 Redis 클라이언트와 Redis 프로토콜을 일부 그대로 쓸 수 있어, 많은 경우 앱의 연결 주소만 바꿔 시험할 수 있다. 핵심 기능은 일반 캐시, 벡터 검색, 의미 기반 캐시, 에이전트 메모리, 내장 MCP 서버다. 의미 기반 캐시는 뜻이 비슷한 질문이 다시 들어오면 AI 모델을 다시 부르지 않고 저장된 답을 돌려줘 비용을 줄이는 데 쓸 수 있다. 이 기능에는 임베딩 제공자가 필요하며, 로컬 Ollama나 OpenAI 임베딩을 붙일 수 있다. Claude 같은 AI 에이전트는 MCP 서버를 통해 RAMen 안의 데이터를 읽고, 쓰고, 검색하고, 기억할 수 있다. 설치는 Go, Docker, 소스 빌드 방식으로 가능하고, 실행하면 기본적으로 데이터 포트 6379와 대시보드 8080을 연다. 다만 아직 클러스터링, 복제, 장애 전환, 강한 내구성은 없어서 큰 운영용 Redis 묶음을 대체하기보다는 한 대 서버에서 쓰는 AI 데이터 계층이나 실험용 캐시에 가깝다.
매달 프로젝트 보고서를 쓸 때마다 회사 배경, 프로젝트 이력, 지난달 이후 바뀐 내용을 다시 설명해야 하는 문제가 생긴다. 새 대화를 시작하면 이전 문맥이 끊겨서 기본 정보부터 다시 맞춰야 한다. 내장 메모리는 중요한 사실을 놓치거나, 몇몇 대화를 바탕으로 역할과 취향을 잘못 추정할 수 있다. 그래서 AI가 알아서 기억하기를 기대하기보다, 클라우드 문서에 있는 프로젝트 기록과 이전 업데이트를 외부 지식 저장소로 연결하는 방식이 쓰인다. 보고서 작성 전에 도우미가 관련 문서와 과거 기록을 먼저 찾아보고 초안을 만든다. 문서가 오래됐거나 정리가 나쁘면 답변도 여전히 지저분해질 수 있고, 최종 검토도 필요하다. 그래도 같은 배경 설명을 매번 반복하지 않아도 되고, AI가 빈칸을 그럴듯한 말로 채우는 위험이 줄어든다.
aimee는 Claude Code, Codex, OpenCode, Gemini CLI, Copilot 같은 AI 코딩 도구 아래에 놓이는 로컬 중간 계층이다. 도구가 OpenAI API나 Anthropic API 방식으로 말할 수 있으면 Claude, GPT, Gemini, Mistral, 로컬 모델 같은 여러 모델로 작업을 보낼 수 있다. 한 도구나 한 회사에 묶이지 않고 제공업체를 바꿀 수 있으며, 기존 메모리와 설정도 다른 도구나 제공업체로 가져갈 수 있게 하는 것이 목표다. 비용 절감 방식은 비싼 기본 에이전트가 모든 원문 문맥을 직접 처리하지 않게 하는 것이다. 더 싸거나 무료인 위임 에이전트가 일부 일을 처리하고, 기본 에이전트는 압축된 결과만 받아 전체 흐름을 관리한다. 안전 기능도 포함된다. 민감한 파일은 모델에 전달되기 전에 막고, 계획 모드에서는 쓰기 작업을 잠그며, 각 세션을 분리해 동시에 여러 작업을 돌려도 서로 덮어쓰지 않게 한다. 또한 4단계 메모리로 중복 정보를 줄이고, 서로 모순되는 내용을 잡고, 오래된 사실은 덜 믿게 만들어 다음 세션이 이전에 배운 내용을 이어받도록 한다.
해커톤에서 특정 업무용 소프트웨어를 조작하는 챗봇 에이전트를 이틀 동안 만들었지만 목표를 이루지 못했다. 목표는 사용자의 요청을 읽고 약 700개의 API 엔드포인트 중 알맞은 것을 골라 작업을 끝내는 것이었다. 도구는 LangGraph를 쓰고, 회사 제약 때문에 Gemini 2.5 Pro 모델을 사용했다. 가장 큰 문제는 REST API 문서가 Swagger에는 있었지만 OpenAPI 3.1 형태로 잘 정리되어 있지 않았고, 사용자의 말뜻을 어떤 API 엔드포인트에 연결해야 하는지 알려주는 예시 목록도 없었다는 점이다. 예를 들어 티켓을 수정한다는 말만으로는 어떤 항목을 바꾸려는지에 따라 다른 API 엔드포인트를 골라야 하는데, 그 구분이 잘 되지 않았다. 모든 문서를 매번 모델에 넣으면 토큰을 많이 써서 비효율적이었다. 많은 요청은 여러 번의 API 호출도 필요했다. 먼저 여러 곳에서 데이터를 가져오고, 분석한 뒤, 필요한 경우 추가 데이터를 더 찾고, 마지막에 수정 요청을 보내야 했다. 사용자 문장에서 검색 조건을 뽑거나 수백 개 API에 맞는 POST/PUT 데이터를 만드는 일도 문서와 예시가 부족하면 매우 어렵다. 결론은 API 색인, 사용자 의도 매칭, 작은 작업별 기술 문서가 거의 필수라는 것이다.
최근 AI 모델 흐름에서는 “가장 똑똑한 모델은 닫힌 API를 돈 내고 쓰고, 싼 모델은 성능을 포기한다”는 기존 생각이 약해지고 있다. 특히 성능은 높고 비용은 낮은 영역에 열린 가중치 모델이 많이 들어오고 있다. DeepSeek, Qwen, GLM, Kimi, MiniMax 같은 모델들이 그 예다. 실제 업무의 대부분은 세상에서 가장 뛰어난 모델이 아니라, 충분히 잘하고 충분히 싼 모델을 필요로 한다. 이런 용도에서는 최고급 닫힌 모델과 강한 열린 모델의 성능 차이보다 비용 차이가 더 커질 수 있다. 닫힌 모델은 직접 운영할 필요가 없고, 안정성이 좋고, 최신 최고 성능을 빨리 쓸 수 있다는 장점이 있다. 하지만 열린 모델은 비싼 API 토큰을 계속 사지 않고도 비용과 운영 방식을 더 직접 통제할 수 있다는 점에서 매력이 커지고 있다.
온라인 사업을 대신 시작하고 운영하는 AI 에이전트 플랫폼에서는 시장 조사, 랜딩 페이지 제작, 제품 설정, 글 작성, 사회관계망 운영까지 자동으로 처리할 수 있다. 사용자는 사업 아이디어만 말하면 에이전트가 대부분의 준비 작업을 맡는 구조다. 하지만 실제로 사업을 합법적으로 세우고, 은행 계좌를 연결하고, 돈을 받는 단계에서는 자동화가 끊긴다. 에이전트는 LLC가 무엇인지 설명하거나 어느 주에서 회사를 세우면 좋은지 안내할 수는 있다. 그러나 정부 사이트에서 절차를 진행하거나, 등록 대리인을 찾거나, EIN 발급 과정을 처리해 주지는 못한다. 이 때문에 사용자는 플랫폼을 떠나 여러 외부 절차를 직접 해결한 뒤 돌아와야 하며, 자율적으로 작동하는 경험이 크게 깨진다.
딥시크(DeepSeek) v4 플래시 모델은 파라미터 수가 2840억 개에 달하는 대형 모델인데도, OpenRouter 같은 API 제공업체에서 매우 저렴한 가격에 서비스되고 있다. 글쓴이는 파라미터 수가 훨씬 적은(약 270억 개, 딥시크의 10분의 1 크기) Qwen 모델보다도 가격이 싸다는 점을 지적하며, 어떻게 이런 가격이 가능한지 의문을 제기한다. 가능한 이유로는 제공업체들이 손해를 보면서 덤핑 판매를 하고 있거나, 딥시크 v4의 아키텍처 자체가 서빙 비용을 극적으로 낮추도록 설계되었을 가능성을 언급한다. 글쓴이는 GPU가 없어 로컬에서는 260억 파라미터급 모델을 초당 한 자릿수 토큰 속도로만 돌려본 경험뿐이라, 실제로 딥시크 v4를 구동해본 사람들의 경험담을 구한다.
Loop Library는 AI 에이전트가 일을 한 번만 시도하고 끝내지 않고, 결과를 확인한 뒤 다음 행동을 정하는 반복 절차 모음이다. 공개 웹사이트에서 여러 절차를 찾아 읽고 프롬프트를 복사할 수 있으며, 별도 설치 없이도 사용할 수 있다. 선택 설치형 스킬을 추가하면 에이전트가 목표에 맞는 절차를 찾고, 기존 절차의 약한 확인 방식이나 멈춤 조건을 점검하고, 사용자의 도구와 기준에 맞게 고쳐 쓸 수 있다. 좋은 반복 절차는 목표, 성공 여부를 확인하는 방법, 배운 내용을 다음 행동에 반영하는 방식, 멈추거나 사람에게 물어볼 시점을 정한다. 예를 들어 웹사이트를 빠르게 만들라는 막연한 지시 대신, 가장 느린 페이지를 찾고 한 가지 개선을 한 뒤 다시 측정하며, 효과가 있을 때만 유지하고 목표를 달성하거나 더 나아지지 않으면 멈추는 식이다. 이 방식은 에이전트가 자신감에 기대어 계속 바꾸는 일을 줄이고, 실제 확인 결과를 기준으로 진행하게 만든다. Codex, Cursor, Claude Code용 설치 명령이 제공되며, 스킬을 설치해도 자동으로 배포, 삭제, 메시지 전송 같은 행동을 시작하지는 않는다. 저장소는 MIT 라이선스이며 GitHub에서 890개 별을 받은 공개 프로젝트다.
Loop Library는 AI 에이전트가 일을 한 번만 처리하고 끝내지 않도록, 반복 가능한 작업 절차를 제공하는 오픈소스 저장소다. 각 루프는 에이전트가 무엇을 해야 하는지, 결과가 좋아졌는지 어떻게 확인할지, 다음에 무엇을 시도할지, 언제 멈추거나 사람에게 확인을 받을지를 정한다. 예를 들어 “웹사이트를 빠르게 만들어라” 같은 넓은 지시 대신, 가장 느린 페이지를 찾고 한 가지 개선을 한 뒤 다시 재고, 효과가 있을 때만 남기고 목표에 도달할 때까지 반복하게 만든다. 이 방식은 운영 오류 수정, 테스트 보강, 제품 검토, 문서 최신화처럼 첫 시도만으로 끝나기 어려운 일에 맞다. Codex, Cursor, Claude Code에 설치할 수 있고, 공개된 루프를 찾거나 기존 루프를 점검하고 고치거나, 자기 도구와 기준에 맞게 바꾸거나, 새 루프를 설계하는 데 쓸 수 있다. 루프를 고르는 것만으로 배포, 삭제, 메시지 발송, 일정 실행 같은 작업이 자동으로 시작되지는 않으며, 그런 행동은 별도 승인과 권한이 필요하다.
100개의 AI 에이전트를 만들고 각자 100달러의 예산을 주는 실험 아이디어다. 각 에이전트는 그 돈으로 토큰이나 도구를 쓰는 결정을 스스로 내린다. 이후 에이전트들이 서로 거래를 제안하고, 상대 제안을 받아들일지 거절할지도 사람 개입 없이 정한다. 핵심은 에이전트들이 제한된 돈 안에서 비용을 어떻게 쓰고, 서로 어떤 교환을 만들며, 그런 실험을 해볼 수 있는 샌드박스나 시험 환경이 이미 있는지 확인하는 것이다.
AI 에이전트가 일을 망치는 이유는 모델이 생각을 못해서가 아니라, 이전 단계의 목표와 조건, 이미 시도한 일을 잊기 때문인 경우가 많다. 단계마다 상태를 오래 보관하지 못하면 같은 정보를 다시 만들고, 같은 실수를 반복하고, 같은 질문을 다시 하게 된다. 그래서 더 좋은 계획 세우기나 도구 사용만으로는 안정적인 에이전트를 만들기 어렵다. 믿을 수 있는 모델, 명확한 작업 규칙과 검토 방식, 오래 유지되는 메모리가 함께 있어야 에이전트가 이전 작업을 이어받아 더 나은 결과를 낼 수 있다. 특히 메모리는 짧은 요약에만 기대는 것이 아니라, 확인 가능한 실제 기록을 읽고 쓰는 방식이어야 한다. 세 요소가 모두 갖춰지면 에이전트는 단순한 자동완성 도구보다 함께 일하는 동료에 가까워진다.
지역 서비스 업체의 웹사이트와 채팅 에이전트는 서로 다른 일을 맡아야 한다. 웹사이트는 방문자가 몇 초 안에 업체를 믿을 수 있게 만드는 곳이다. 면허 번호, 인증, 실제 증거, 사람다운 말투를 보여주고, 전화나 견적 요청 같은 분명한 행동으로 안내해야 한다. 채팅 에이전트는 웹사이트가 처리하기 어려운 대화를 맡는다. 특히 영업시간이 아닐 때 방문자의 질문을 받고, 이름과 전화번호를 남기게 해서 사람이 다시 연락할 수 있게 해야 한다. 중요한 성과는 똑똑해 보이는 대화가 아니라 실제 문의를 확보하는 것이다. 에이전트는 사업자가 웹사이트에서 이미 약속한 내용 안에서만 답해야 하며, 영업시간, 서비스 지역, 제공 서비스처럼 안전하게 말할 수 있는 사실만 다뤄야 한다. 그 밖의 내용은 추측하지 말고 사람에게 넘겨야 한다.
AI 에이전트는 코드를 작성할 수 있지만, 실제 회사 업무는 코드 작성만으로 끝나지 않는다. 중요한 일에는 배경 이해, 담당자 확인, 건드리면 안 되는 부분 판단, 승인 대기, 위험 설명, 팀 간 조율이 포함된다. 지금의 많은 에이전트는 강력하지만 검은 터미널 안의 도구처럼 느껴진다. 명령을 실행하고 파일을 고치지만, 때로는 추측하고, 다시 시도하면 안 되는 일을 반복하기도 한다. 막혔을 때 누구에게 물어야 하는지, 어떤 승인이 필요한지, 다음 단계가 무엇인지 잘 모르는 경우도 있다. 앞으로는 한 개의 거대한 에이전트가 사람을 모두 대체하기보다, 코딩 에이전트, 리뷰 에이전트, 보안 에이전트, 문서 에이전트, 지속적 통합 에이전트처럼 역할이 나뉜 여러 에이전트가 사람과 함께 일하는 방식이 더 현실적이다. 그러려면 에이전트에는 도구뿐 아니라 정체성, 권한, 저장소와 파일의 책임 관계를 이해하는 능력이 필요하다.
긴 인공지능 대화 세션은 문맥이 많이 쌓이면 답변 품질이 흐려질 수 있다. 이 무료 플러그인은 실제 컨텍스트 창이 얼마나 찼는지 백분율로 읽고, 상태 줄에 계기판처럼 보여준다. 사용자는 수치가 높아질 때 /compact로 대화를 압축하거나 /clear로 새로 시작할 시점을 더 쉽게 판단할 수 있다. 만든 쪽은 이 도구가 실행될 때 토큰을 쓰지 않는다고 설명한다. 개인 기준으로는 약 70%쯤 찼을 때 답변이 흐려져 압축을 한다는 경험이 함께 제시됐다.
SIFT는 MIT 라이선스로 공개된 새 GitHub 프로젝트이며, AI 작업공간 안에서 도구 관리에 이미 쓰이고 있다. 핵심 방향은 도구 사용 비용을 예측 가능하고 낮게 만드는 것이다. 현재 예시는 8개 도구를 다룬다. 사용 흐름과 기본 설명 문서는 아직 외부 피드백을 받는 초기 단계다. SIFT가 쓰인 더 큰 AI 작업공간은 나중에 오픈소스와 자가 호스팅 형태로 공개될 예정이다.
Apodex-1.0 Heavy-Duty는 서로 맞지 않는 자료가 섞인 깊은 조사 작업을 처리하기 위해 여러 에이전트를 나누어 쓰는 구조를 제안한다. 일반적인 ReAct 방식은 하나의 에이전트가 생각하고, 행동하고, 결과를 보고, 다시 생각하는 과정을 한 컨텍스트 안에서 반복한다. 이 방식은 단계가 수백 번쯤 쌓이면 한계가 생긴다. 컨텍스트가 복잡해지고, 서로 다른 조사 갈래가 섞이며, 에이전트가 자기 실수를 스스로 되짚는 능력도 약해진다. 같은 에이전트가 자기 답을 검토하면 처음 실수를 만든 약점을 그대로 갖고 있기 때문이다. Apodex 구조는 컨텍스트 길이만 늘리는 대신 AgentOS라는 실행 구조 위에서 최대 150개의 전문 하위 에이전트를 비동기로 움직인다. 중심 조정자가 작업에 맞춰 하위 에이전트를 만들고, 각 하위 에이전트는 따로 분리된 깨끗한 컨텍스트에서 일한다. 제목 기준으로는 별도 검증자도 두어 서로 충돌하는 자료를 더 잘 걸러내려는 방향이다.
복잡한 업무 규칙을 긴 프롬프트에 한꺼번에 넣으면 대형 언어 모델이 지시를 놓치기 쉽다. 규칙이 서로 조건으로 연결되거나, 정해진 순서를 따라야 하거나, 예산 같은 제한을 동시에 맞춰야 할 때 문제가 커진다. 예를 들어 식당 직원 근무표를 짤 때 손님 조건에 따라 요리사를 추가하고, 먼저 책임자를 배정한 뒤 보조 인력을 넣고, 마지막에 비용까지 확인해야 할 수 있다. Nanonets는 이런 규칙을 평평한 문장 묶음으로 넣지 않고, 규칙을 점으로, 규칙 사이의 의존 관계를 선으로 표현하는 컨텍스트 그래프를 만들었다. 이 방식은 전체를 한 번에 맞히려 하기보다 가까운 관계의 제약 조건을 따로 확인한다. Surge AI의 지시 수행 벤치마크에서 45% 점수를 냈고, 공개된 최고 성능보다 높다는 주장이다. 아직 개발 중인 방법이며, 더 개선할 방향에 대한 검토가 필요하다.
자가 운영 개인 비서형 AI 에이전트는 사용자의 자연어 요청을 여러 작은 작업으로 나누고, 필요한 실행기나 에이전트를 골라 연결해야 한다. 요청 하나에 파일, 메일, 데이터베이스, 일정 같은 여러 영역의 행동이 함께 들어갈 수 있어 구조가 복잡해진다. 실행기 후보가 수백 개처럼 많고 매번 달라지면, 요청의 뜻을 구분하고 후보를 줄이고 작업 순서를 엮는 과정이 핵심 문제가 된다. 이 구조에서는 정해진 규칙으로 처리하는 결정론적 방법과 LLM처럼 확률로 판단하는 통계적 방법을 섞어 써야 한다. 모든 것을 결정론적으로 만들면 빠르고 결과도 예측하기 쉽지만, 사용자가 매우 딱딱한 방식으로 말해야 해서 자연어 비서의 장점이 줄어든다. 반대로 LLM에 많이 맡기면 자연스러운 요청을 더 잘 다룰 수 있지만, 판단이 흔들릴 수 있고 속도, 캐시, MTP 같은 최적화가 새 불확실성을 만들 수 있다.
여러 최신 AI 모델을 직접 비교 평가한 경험에서, API로 쓰는 모델과 공개 가중치 모델 모두 답변 방식이 점점 비슷해지는 모습이 보였다. 특히 대화가 여러 번 이어지거나 좁고 전문적인 주제로 들어가면 문장 흐름, 조심스러운 표현, 놓치는 지점이 서로 닮아간다는 관찰이다. 완전히 망가지는 수준은 아니지만, 모델마다 다른 개성과 세밀한 차이가 줄어드는 현상으로 이해할 수 있다. 가능한 원인으로는 여러 모델이 서로 비슷한 합성 데이터의 영향을 받으면서 행동 방식까지 닮아가는 흐름이 제시됐다. 이 현상을 임시로 EchoCreep이라고 부르며, 이를 잡아낼 평가 지표가 있는지, 사람이 직접 고른 데이터로 미세 조정하면 완화되는지, 모델 버전이 바뀔수록 더 심해지는지 확인할 필요가 있다.
AI 에이전트가 단순히 질문에 답하는 수준을 넘어서 이메일을 보내고, 고객 관리 기록을 바꾸고, 환불을 처리하고, 회의를 잡고, 기반 시설 설정까지 수정하면 시험 방식도 달라져야 한다. 답변형 챗봇에서는 틀린 답이나 지어낸 말이 핵심 위험이다. 하지만 행동형 에이전트에서는 잘못된 고객에게 이메일을 보내거나, 엉뚱한 기록을 지우거나, 되돌리기 어려운 조치를 실행하는 것이 더 큰 문제다. 그래서 답변의 품질만 보는 평가는 충분하지 않다. 실제 결과가 생기는 행동을 에이전트가 안전하게 고르는지, 실행 전에 멈춰야 할 상황을 아는지, 실수했을 때 피해를 줄일 장치가 있는지를 따로 검증해야 한다.