AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
로컬 컴퓨터에서 코딩을 도와주는 인공지능을 쓰려는 시도에서 Qwen 3.6 27B UD_4가 기대만큼 작동하지 않았다. 장비는 RTX 5090이었고, 131K 문맥을 열어 두었으며, KV 양자화는 쓰지 않았고, 모델은 Unsloth로 양자화된 상태였다. 작업 도구로는 VS Code 안에서 쓰는 Cline을 골랐다. Claude Code와 비슷하게 코딩 작업을 맡길 수 있을 것으로 봤기 때문이다. Fable로 기본적인 Python 앱을 만들기 위한 아주 자세한 실행 계획을 만들고, 초급 개발자도 따라갈 수 있을 만큼 단계별로 정리한 뒤 저장소에 넣었다. 하지만 Qwen은 코드에 많은 실수를 넣었고, 터미널 명령도 기본 문법이 틀린 형태로 만들었다. 자세한 계획을 거의 순서대로 따라가면 되는 상황에서도 제대로 진행하지 못했다. 최고급 Claude 모델 수준을 기대한 것은 아니었지만, 기본적인 도구 연결과 터미널 실행 안에서도 쓸 만하게 작동하지 않았다.
RAG 시스템의 답이 틀리는 문제는 답을 쓰는 모델보다 필요한 정보를 찾는 과정에서 생기는 경우가 많다. 모델은 보통 스스로 없는 말을 만드는 것이 아니라, 전달받은 자료를 바탕으로 답한다. 그래서 잘못된 자료나 부족한 자료가 들어가면 답도 틀어진다. 개선 효과가 컸던 방법은 문서를 무조건 같은 길이로 자르지 않고 문서의 구조에 맞게 나누는 것, 벡터 검색 뒤에 결과 순서를 다시 매기는 것, 실제 사람들이 물어본 질문으로 테스트 세트를 만드는 것이다. 모델을 바꾸는 것보다 필요한 정보를 더 잘 찾도록 고치는 일이 더 큰 차이를 만들 수 있다. 추론 모델도 잘못된 정보를 고쳐 주지는 못하며, 오히려 틀린 바탕 위에서 더 그럴듯한 답을 만들 수 있다. GraphRAG는 여러 문서가 서로 얽힌 복잡한 질문에는 쓸모가 있지만, 단순한 문서 질문은 문서 나누기와 검색 품질을 먼저 고치는 편이 낫다.
llama.cpp의 새 변경은 ARM CPU에서 NVFP4 형식 모델을 더 빠르게 계산하게 만든다. 핵심은 UE4M3 값을 매번 복잡하게 풀어 계산하지 않고, 미리 준비된 표인 조회표로 빠르게 바꾸는 방식이다. 이 방식은 이미 x86 쪽에 들어간 최적화를 ARM 구현에도 맞춘 것이다. Qwen3.5 4B NVFP4 모델을 CPU 4개 스레드로 시험했을 때, 같은 512 토큰 입력 처리 속도가 초당 1.89 토큰에서 초당 9.97 토큰으로 올랐다. 이는 약 5.3배 빠른 결과다. 기존 공용 조회표를 재사용하므로 ARM과 x86 구현 방식도 더 비슷해진다.
gemini-search-mcp는 Google AI Mode의 Gemini를 이용해 웹 검색을 해 주는 무료 MCP 서버다. API 키 없이 쓸 수 있고, 사용량 제한이 없다고 소개되어 있다. AI 에이전트에 붙이면 에이전트가 웹에서 정보를 찾는 도구로 쓸 수 있다. 별도 검색 API 비용이나 키 관리가 필요 없다는 점이 핵심이다.
AgentTransfer는 AI 에이전트끼리, 또는 AI 에이전트와 사람 사이에 큰 파일을 보내기 위한 오픈소스 도구다. 각 에이전트는 가입하면 이메일 주소, 폴더, 받은편지함을 받고, 최대 5GB 파일을 짧은 시간만 열리는 다운로드 링크로 보낼 수 있다. 처음에는 400MB 저장공간을 쓰고, 소유자가 이메일로 확인하면 20GB 저장공간과 영구 폴더를 쓸 수 있다. 파일은 대화창에 붙여 넣는 대신 따로 전송되며, 해시로 파일이 바뀌지 않았는지 확인하고, 보낸 기록은 서명된 영수증처럼 남는다. MCP 서버가 들어 있어 Codex, Cursor 같은 에이전트 환경에 붙일 수 있고, 하나의 Go 실행 파일로 직접 서버를 띄우거나 자체 호스팅할 수 있다. 아직 초기 단계이며, 저장 파일 암호화, 바이러스 검사, 일부 메일 보안 확인, 이어받기 업로드 같은 기능은 없다고 밝힌다.
OneDev 16의 커뮤니티 에디션에는 자율적으로 일하는 AI 사용자가 들어갔습니다. OneDev는 직접 운영할 수 있는 올인원 깃 서비스이며, 이 AI 사용자는 이슈를 맡아 요구사항을 읽고 따로 관리되는 작업 공간을 만든 뒤 코드를 수정할 수 있습니다. 수정한 코드는 풀 리퀘스트로 올라가며, 이후 같은 AI 사용자가 리뷰 의견에 답하고, 실패한 CI/CD 빌드를 고치고, 병합 충돌을 해결하고, 준비될 때까지 풀 리퀘스트를 갱신할 수 있습니다. AI 사용자는 코드 리뷰에도 참여해 변경 내용을 살피고, 줄 단위 의견을 남기고, 승인하거나 수정 요청을 할 수 있습니다. 필요한 리뷰와 CI/CD 확인을 통과한 뒤에는 설정에 따라 병합까지 맡길 수 있습니다. 핵심은 AI 작업을 따로 흩어진 대화방에서 처리하지 않고, 요구사항은 이슈에 두고, 실행은 격리된 작업 공간에서 하며, 변경 검증은 기존 개발 절차 안에서 남기는 방식입니다. 규칙을 설정하면 특정 이슈를 AI 사용자에게 자동 배정하거나, 풀 리퀘스트 설정과 브랜치 보호 규칙으로 AI 리뷰를 요구할 수 있습니다.
같은 벡터 인덱스를 써도 질문을 어떻게 만들었는지에 따라 한 화면에서는 정확히 답하고 다른 화면에서는 없는 내용을 지어낼 수 있다. 안정적인 RAG 흐름은 먼저 이전 대화와 현재 질문을 합쳐, 따로 읽어도 뜻이 분명한 하나의 질문으로 바꾸는 데서 시작한다. 어려운 질문에는 3~5개의 질문 변형이나 HyDE를 만들어 각각 검색한 뒤 결과를 합치되, 비용이 늘어나므로 모든 요청에 쓰지 않는 편이 낫다. 검색은 의미가 비슷한 문서를 찾는 방식과 BM25를 함께 쓰고, 각각 50~150개 정도를 넓게 가져온다. BM25는 사람 이름, 제품명, 식별번호처럼 글자가 정확히 맞아야 하는 정보를 잘 잡는다. 그다음 여러 검색 결과를 순위 기준으로 합치고, cross-encoder rerank로 후보를 5~20개까지 줄인다. 최종 답변에는 보통 20개 안팎의 자료만 넣고, 점수가 낮은 자료는 버린다. 답변은 제공된 자료 안에서만 만들고, 근거가 없으면 모른다고 답하게 해야 한다. 수집 단계에서는 조각마다 짧은 설명을 붙여 함께 색인하고, 예상 질문이나 비슷한 표현을 추가하며, 의미 단위로 문서를 나누고 metadata를 붙이면 검색 품질의 한계를 더 높일 수 있다.
대부분의 RAG 시스템은 필요한 지식을 찾아 답변에 사용한 뒤 그 지식을 남기지 않는다. 이 방식은 보통 단순하고 안전하다. 하지만 오래 작동하는 에이전트나 도구라면, 반복해서 중요한 지식 일부를 영구 메모리로 저장하는 편이 나을 수 있다. 모든 정보를 저장하면 혼란이 커지므로, 시스템이 “이 정보는 계속 기억할 가치가 있다”고 판단하는 기준이 필요하다. 핵심 쟁점은 영구 메모리가 실제로 도움을 주는지, 아니면 오래된 지식과 잘못된 가정을 쌓아 더 큰 문제를 만드는지다.
tftf는 크기가 너무 커서 컴퓨터 메모리나 그래픽카드 메모리에 한 번에 올리기 어려운 AI 모델을 다루기 위한 오픈소스 도구다. 모델 전체를 한꺼번에 불러오지 않고, 텐서라는 작은 단위별로 작업한다. 그래서 LoRA 병합이나 모델 형식 변환처럼 큰 파일을 손봐야 하는 작업을 더 적은 메모리로 처리할 수 있다. 주된 대상은 큰 모델을 미세조정하는 사람들이다. 다만 개발 방식이 실험적이라고 밝혀져 있어, 중요한 작업에 바로 쓰기 전에는 결과 확인이 필요하다.
커뮤니케이션과 영업 훈련용 인공지능 연습처럼 평가 방법이 뚜렷한 경우에는 고정 작업흐름 방식이 잘 맞을 수 있다. 전체 과정을 작은 단계로 나누면 각 단계가 무엇을 해야 하는지 분명해진다. 그래서 실행 비용이 낮아지고, 속도가 빨라지며, 결과를 통제하기도 쉬워진다. 반대로 오케스트레이터 방식은 더 유연하고 가능성이 커 보이지만, 모든 문제에 처음부터 쓰기에는 과할 수 있다. 실제 선택지는 처음부터 오케스트레이터를 쓰고 제한을 거는 방식과, 고정 작업흐름으로 시작한 뒤 복잡하고 예측하기 어려운 부분에만 오케스트레이션을 더하는 방식으로 나뉜다. 비개발자도 사업 대화용 인공지능 에이전트를 조립할 수 있게 하려는 셀프호스팅 도구 Assemblix가 함께 제시됐다.
open-connector는 AI 에이전트가 Gmail, Slack, Notion 같은 SaaS 서비스에 접근할 때 필요한 로그인 인증(OAuth) 과정을 대신 처리해주는 오픈소스 프로젝트다. 1000개가 넘는 SaaS 제공업체와의 연동을 지원하며, 개발자는 SDK, CLI, MCP(에이전트가 외부 도구를 쓰게 해주는 표준 방식), HTTP, OpenAPI 등 원하는 방식으로 이 게이트웨이를 붙일 수 있다. 즉 에이전트를 만들 때마다 각 서비스별로 인증 로직을 따로 짤 필요 없이, 이 게이트웨이 하나로 여러 서비스 접근 권한을 관리할 수 있게 해준다.
한 개발자가 완전히 로컬에서 동작하는 스마트홈 AI 비서를 만들고 있다. Qwen 4B 모델(GGUF 양자화 버전)을 사용하고, Outlines로 구조화된 JSON을 생성하며, FastAPI·MQTT·PostgreSQL로 시스템을 구성했다. 현재 구조는 사용자 문장을 먼저 파이썬으로 분리한 뒤, 의도 분류기가 동작(Action)·설정 저장(Preference)·상태 확인(Status)·장면(Scene)·삭제(Delete) 중 하나로 분류하고, 그에 맞는 파서가 JSON을 만들어 MQTT나 데이터베이스로 보낸다. "거실 불 켜줘"처럼 단순한 한 가지 명령은 잘 처리된다. 문제는 "R&D룸 불 켜고 내가 들어오면 자동으로 켜지게 저장해줘. 소프트웨어룸 조명 3개도 켜줘"처럼 한 문장에 여러 의도(즉시 실행 + 자동화 규칙 저장 등)가 섞일 때다. 현재 분류기는 문장 하나당 의도 하나만 가정하기 때문에, 명령이 복잡해질수록 4B 크기의 로컬 모델이 속성을 서로 뒤섞거나 전혀 다른 파서로 잘못 보낸다. 이를 해결하기 위해 분류기 대신 문장을 여러 개의 개별 작업(tasks) 목록으로 쪼개주는 작은 "플래너" 모델 도입을 검토하고 있다.
기존 RAG(검색 증강 생성) 방식은 문서를 벡터로 바꿔 저장하고 가장 비슷한 벡터를 찾는 임베딩 기반 검색을 쓴다. 문제는 벡터로 압축하는 과정에서 문맥 정보가 많이 손실되어, 실제로는 관련 있는 근거를 놓치는 경우가 많다는 점이다. 이를 보완하려고 청크 크기 조정, 키워드+의미 검색 결합, 재정렬 모델, 메타데이터 필터, 질의 재작성 등 여러 땜질식 기법이 쌓이는데, 그래도 벡터 검색은 실제로 내용을 '읽는' 것과는 다르다. Attemory라는 새 검색 엔진은 문서를 벡터로 압축하지 않고, 원문 전체를 재사용 가능한 KV(키-값) 상태로 색인해 둔다. 검색할 때는 로컬에서 돌아가는 Qwen3.5 기반 검색 모델이 색인된 메모리와 질의를 함께 '주의(attention)' 메커니즘으로 살펴본 뒤, 메모리 ID·발췌문·파일과 줄 번호 같은 압축된 근거를 돌려준다. 즉 압축된 벡터끼리 유사도를 비교하는 게 아니라, 모델이 실제로 저장된 내용을 훑어보고 근거를 짚어내는 방식이다. 개발자는 장기 기억, 문서, 코드베이스 검색 벤치마크에서 이 방식이 최고 수준(SOTA) 성능을 냈다고 밝혔다.
러시아 스베르방크가 GigaChat3.5-432B-A28B라는 새로운 대형언어모델을 공개했다. 전체 파라미터는 4320억 개이지만, 실제로 답변 생성 시 활성화되는 파라미터는 280억 개뿐인 '전문가 혼합(MoE)' 구조를 사용한다. 사전학습만 마친 베이스 버전도 함께 공개됐다. 특히 공개와 동시에 GGUF라는 경량화 포맷 버전도 나왔는데, 이는 llama.cpp라는 프로그램으로 개인 컴퓨터에서 모델을 돌릴 수 있게 해주는 형식이다. 다만 이 GGUF 지원은 아직 llama.cpp 정식 버전(master 브랜치)에는 병합되지 않았고, 별도의 코드 수정 요청(PR)을 빌드해야 사용할 수 있다.
지식 그래프는 검색 증강 생성(RAG)에서 서로 다른 표현으로 된 정보를 연결해 주는 방법으로 기대를 받는다. 예를 들어 한 규칙은 절도를 금지하고, 다른 규칙은 꼭 필요한 상황의 음식 절도는 허용한다고 할 수 있다. 단어가 다르면 어휘 검색은 두 규칙을 함께 찾기 어렵다. 의미 검색도 관련성을 어느 정도 찾을 수 있지만, 필요한 문서 조각이 상위 K 범위 밖으로 밀리면 답에 쓰이지 못한다. 지식 그래프는 이런 관계를 더 잘 연결할 것처럼 보이지만, 실제로는 다른 RAG 방식보다 뚜렷하게 낫지 않은 경우가 있다. 가능한 원인은 인덱싱 단계에서 LLM이 복잡한 관계를 충분히 뽑아내지 못하거나, 임베딩 모델이 저장할 때와 질문할 때의 표현 차이를 제대로 잇지 못하는 데 있다.
약 1만 7천 개의 지원 티켓 조각을 독일어, 영어, 프랑스어, 이탈리아어 등 여러 언어로 넣은 RAG 실험에서, 기본 밀집 검색만으로도 결과가 매우 좋았다. 50개 질문마다 상위 10개 결과를 뽑아 평가했다. F2LLM-0.6B-Preview를 쓴 기본 방식의 nDCG@10은 0.8421이었다. 여기에 세 가지 점수형 재정렬 모델을 붙였더니 cross-encoder/mmarco-mMiniLMv2-L12-H384-v1은 0.8292, BAAI/bge-reranker-v2-m3는 0.8360, Qwen/Qwen3-Reranker-0.6B는 0.8427을 기록했다. 관련도가 2 이상인 결과를 기준으로 한 MRR은 기본 방식 0.980에서 재정렬 후 0.937~0.957로 내려갔다. 중요한 문서가 이미 거의 항상 1위에 있었기 때문에, 재정렬이 일부 질문에서는 오히려 좋은 문서를 아래로 밀었다. 대안으로 다른 재정렬 모델을 쓰거나, 점수형 방식 대신 쌍비교 방식이 나을 수 있는지가 남은 질문이다.
현재 구성은 Open WebUI에서 Jina의 작은 임베딩 모델과 Jina 재정렬 모델을 모두 Q8 형식으로 돌리는 방식이다. 앞으로는 큰 언어 모델을 직접 돌리지 않고 DeepSeek API를 쓰려는 계획이다. 이렇게 하면 기기 자원을 아껴 더 큰 임베딩 모델이나 재정렬 모델에 쓸 수 있다. 핵심 고민은 0.6B급 작은 모델을 계속 쓸지, 4B급 더 큰 양자화 모델로 바꿀지다. 쓰임새가 글쓰기와 수학이라서, 단순히 빠르고 가벼운 것보다 정확도가 중요하다.
유럽연합 집행위원회가 Frontier AI Grand Challenge의 우승자로 EUROPA 컨소시엄을 선택했다. EUROPA는 이탈리아 기업 Domyn이 이끄는 유럽 컨소시엄이다. 목표는 유럽연합의 24개 공식 언어를 모두 다루는 오픈소스 인공지능 모델을 만드는 것이다. 이 모델은 4,000억 개가 넘는 매개변수를 갖는 대형 모델로 제안됐다. 유럽연합은 자체 인프라에서 고급 인공지능을 개발할 힘을 키우기 위해 이 프로젝트를 선택했다. 완성된 모델은 공개적으로 사용할 수 있게 만들 계획이며, 기업, 연구자, 공공기관이 유럽의 다양한 언어 환경에서 더 쉽게 고급 인공지능을 활용하도록 돕는 것이 목적이다.
AI 에이전트의 토큰 비용은 단순히 더 싼 모델로 바꾸는 것만으로 크게 줄지 않을 수 있다. 여러 실제 사례에서 더 큰 절감은 에이전트가 컨텍스트에 넣을 수 있는 정보량을 제한할 때 나왔다. 예측하기 어려운 큰 터미널 명령 출력은 토큰을 빠르게 늘릴 수 있어서, Codex 사례에서는 AGENTS.md에 출력 제한 규칙을 넣는 것만으로 토큰 사용량을 거의 절반으로 줄였다. 도구 정의도 큰 비용을 만든다. 한 팀은 MCP 도구 정의 508개를 매번 보내면서 실행 1회당 약 377달러를 썼지만, 모든 도구 설명을 처음부터 보내지 않는 방식으로 약 29달러까지 낮췄다. 또 다른 측정에서는 사용자가 첫 질문을 하기 전부터 약 6만7000 토큰이 이미 쓰였다. 모델을 상황에 맞게 고르는 일도 도움이 되지만, 큰 폭의 비용 절감은 보통 도구 출력, 도구 목록, 초반 컨텍스트를 작게 유지하는 데서 나온다.
llama.cpp의 HIP 빌드에 -ffast-math를 켜는 변경이 제안됐습니다. gfx1151 계열 AMD 그래픽칩인 RDNA3.5/Strix Halo, 40개 연산 유닛 환경에서 최신 기본 코드와 비교했습니다. 큰 모델인 Qwen3.5-27B Q4_K_M은 프롬프트 길이에 따라 초당 처리 토큰이 약 4.0%에서 7.0% 늘었습니다. 작은 모델인 Qwen3-0.6B BF16은 짧은 프롬프트에서 약 3%대 개선이 있었고, 32,768 토큰처럼 긴 프롬프트에서는 0.6%로 차이가 작았습니다. FA=0에서는 두 빌드의 결과가 거의 같았습니다. 즉 이 변화는 특정 AMD GPU와 FA=1 경로에서 프롬프트를 읽어들이는 속도를 조금 높이는 성격입니다.
코딩 에이전트로 코드를 만들던 중 토큰 한계에 걸리면 작업이 갑자기 멈춘다. 소프트웨어 만들기는 한 번에 끝나는 일이 아니라 여러 번 고치고 다듬는 과정이다. 특히 대규모 언어 모델이 필요한 문맥을 충분히 이해하지 못하면 더 많은 설명과 반복 수정이 필요하다. 현재 방식에서는 창의적으로 만들던 흐름 중에도 사용량과 비용을 계속 신경 써야 한다. 더 싼 램과 GPU를 써서 개인 컴퓨터에서 코딩 에이전트를 경제적으로 돌릴 방법이 필요하다는 문제의식이다.
Athena는 인터넷 서버에 말을 보내지 않고 개인 컴퓨터 안에서만 작동하는 음성 대화형 AI 비서다. 말소리를 알아듣는 Whisper-small.en, 답변을 만드는 Qwen3.5-397B, 감정이 섞인 목소리로 말하는 Orpheus 3B, 소리를 다루는 SNAC를 함께 쓴다. 실행 중에는 파이썬 없이 C++로 네 개의 작업 흐름이 돌아가며, 설치 때 한 번 쓰는 선택용 변환 스크립트만 파이썬이다. 웃음, 한숨, 놀라는 소리 같은 감정 표현을 낼 수 있고, 사용자의 목소리 감정도 기본적으로 읽어 반응한다. 대화가 끝난 뒤에도 장기 메모리와 성격을 유지하며, 긴 대화의 흐름도 이어 간다. 사용자가 말하는 도중에 끼어들면 대답을 멈추고, 이미 말한 내용은 대화 문맥에 남긴다. 클라우드, 텔레메트리, API 키 없이 소비자용 GPU와 시스템 메모리로 돌아가는 구성을 목표로 한다.
LangChain 문서를 바탕으로 전통적인 RAG 앱을 만들었지만, 자료를 나누고 넣는 과정에서 문제가 생겼다. 청킹이 잘 되지 않았고, 겹치는 구간을 손으로 조정해 벡터 데이터베이스에 넣는 데 약 49분이 걸렸다. 앱은 완성됐지만, 검색 단계에서 관련성이 낮은 답을 가져왔다. 원인은 자료 수집과 저장 과정의 실수로 보인다. GraphDB와 GraphRAG를 알게 된 뒤, 언제 GraphRAG를 써야 하고 언제 쓰지 말아야 하는지, 장단점이 무엇인지가 핵심 고민이다. 대화할 때마다 그래프가 계속 만들어진다면 비용이 커질 수 있다는 우려도 있다.
Excalibur는 제품 개발자가 코드 변경을 AI에 맡기고, 계획부터 테스트와 검토까지 한 흐름으로 관리하도록 만든 오픈소스 도구다. Core 버전은 Apache-2.0 라이선스로 공개되어 있으며, npm으로 설치해 자기 코드 저장소에서 실행하는 방식이다. 작업을 시작하기 전에 범위, 근거, 위험을 따져 바로 만들지, 더 확인할지, 만들지 말지를 고르는 탐색 단계가 있다. 사용자는 간단한 질문, 작은 수정안, 별도 가지에서 구현, 완전 자동 실행처럼 자율성 수준을 고를 수 있다. 큰 작업은 여러 AI 에이전트가 나눠 맡을 수 있고, 각 작업은 격리된 가지에서 진행된 뒤 테스트와 검토를 통과해야 합쳐진다. 비용 관점에서는 실행 기록을 되감아 이전 단계에서 다시 시작할 수 있고, 바뀌지 않은 앞부분은 캐시로 재사용해 다시 실행하는 비용을 줄이도록 설계되어 있다. OpenAI 호환 서비스, Anthropic, Ollama 등을 쓸 수 있으며, 어려운 부분에는 강한 모델을 쓰고 가벼운 문장 작업에는 싼 모델을 쓰는 식의 모델 선택을 지원한다. 로컬 대시보드에는 작업 흐름, 비용 정보, 실행 기록이 보이고, 쓰기·명령 실행·푸시는 승인 후에만 진행되며 샌드박스, 비밀값 차단, 로컬 로그도 제공된다.
kv-psi는 리눅스의 PSI를 읽어, 컴퓨터 메모리가 부족해질 때 대형 언어 모델의 KV 캐시를 줄이는 작은 참고 구현이다. KV 캐시는 모델이 앞에서 읽은 문맥을 다시 쓰기 위해 메모리에 남겨 두는 자료라서, 길게 대화하거나 긴 문서를 처리할수록 커진다. 이 도구는 리눅스의 cgroup memory.pressure 또는 /proc/pressure/memory 값을 보고 압박이 커지면 캐시 일부를 잘라낸다. 실행에는 PSI가 켜진 리눅스, 파이썬 3.10 이상, llama.cpp 실행기 빌드 환경, GGUF 모델이 필요하다. 기본 사용법은 시뮬레이터를 돌리고, llama.cpp 실행기를 빌드하고, 필요하면 작은 벤치마크 모델을 내려받는 흐름이다. Jetson 장비에서 1536 토큰을 생성한 최근 결과에서는 고정 방식이 캐시를 줄이지 않아 최종 KV가 1547로 남았고, PSI 방식은 2~4번 캐시를 줄여 최종 KV가 1004 또는 1291까지 낮아졌다. 속도는 실행 순서와 압박 상태에 따라 달라져, PSI 방식이 88.80 또는 96.16 토큰/초, 고정 방식이 94.00 또는 89.76 토큰/초를 보였다. 벤치마크는 이전 실행의 캐시, zram/swap, PSI 평균값이 다음 실행에 영향을 줄 수 있어 두 실행 순서를 모두 시험하도록 되어 있다.
다중 에이전트 LLM 작업에서는 어떤 모델을 고를지보다 토큰과 비용을 어떻게 나눠 쓸지가 중요할 수 있다. 핵심 목표는 비싼 추론 예산을 정말 판단이 필요한 결정에 남겨 두는 것이다. 넓게 자료를 모으거나 형식을 맞추는 기계적인 일은 감당 가능한 가장 저렴한 모델에 맡기고, 여러 작업을 병렬로 처리한 뒤 필요한 결과만 위로 올린다. 최종 판단은 한곳으로 모아 더 강한 모델이나 더 깊은 추론에 집중한다. 같은 내용을 여러 번 요약하거나 여러 번 판단하지 말고, 한 번 요약하고 한 번 판단하는 흐름이 비용을 줄인다. 모든 자료를 처음부터 넣기보다 필요한 만큼만 단계적으로 찾아 넣는 점진적 검색이 더 효율적이다. 애매한 상황에서는 싼 모델이 추측하게 두지 말고, 불확실성을 위로 올려 더 적절한 판단 단계에서 처리한다. 이 방식은 고정된 모델 서열표가 아니라 모델이 바뀌어도 쓸 수 있는 운용 원칙에 가깝다.
Awesome Agentic DevOps는 DevOps, 클라우드, SRE, 플랫폼 엔지니어링에서 쓸 수 있는 AI 에이전트 도구와 MCP 서버를 한곳에 모은 목록이다. Claude Code, Gemini ADK, OpenAI Agents SDK, MCP 같은 환경에서 쓸 수 있는 도구를 비교한다. 단순히 도구 이름만 모은 것이 아니라 실제 운영에 쓸 만한지, 운영 시스템에 접근할 수 있는지, 사람이 승인하는 단계가 있는지, 작업 기록과 근거가 남는지, 성숙도가 어떤지까지 평가한다. AWS, Microsoft Azure, Google Cloud, GitHub, GitLab, Atlassian, Terraform, Pulumi, Grafana, Datadog, PagerDuty, SonarQube, Okta, Snyk, Wiz, Jenkins, Argo CD 같은 주요 도구의 공식 MCP 서버와 에이전트 자료를 사용 사례별로 묶어 제안한다. 안전 수칙도 분명하다. 처음에는 읽기 전용이나 제안 모드로 쓰고, 실제 변경 작업은 사람이 승인하게 하며, 비밀값을 모델 문맥에 넣지 말고, 최소 권한 계정과 사전 실행 점검을 쓰라는 방향이다.
AI 애플리케이션과 AI 에이전트의 보안을 평가하는 틀을 만들 때, 가장 막히는 부분은 공격용 입력을 어떻게 잘 만들지입니다. 많은 보안 시험 방식은 대규모 언어 모델을 써서 일부러 위험하거나 까다로운 입력을 만듭니다. 필요한 것은 품질 좋은 공격 예시를 잘 만드는 폐쇄형 모델과 오픈소스 모델 추천입니다. 다루려는 공격 범위는 유해한 답변 유도, 프롬프트 인젝션, SQL 인젝션, 탈옥, 간접 프롬프트 인젝션, 프롬프트 유출, 도구 오용, 여러 차례 대화로 이어지는 공격, 에이전트 전용 공격입니다. 또 모든 공격을 새로 생성하지 않고 보안 검증에 쓸 수 있는 공개 기준 데이터도 찾고 있습니다. 이상적인 데이터는 미리 정리된 고품질 공격 예시가 들어 있는 ‘골든 데이터셋’입니다. 실제 현장에서 쓰는 모델, 데이터셋, 논문, 깃허브 저장소 추천이 핵심 관심사입니다.
솔라나 토큰을 사고파는 에이전트는 가격과 거래량만 보면 조직적인 사기 토큰을 정상 토큰과 구분하기 어렵다. 이 도구는 MCP 서버와 일반 REST 방식으로 제공되며, 핵심 기능은 토큰 주소를 넣으면 지갑 관계를 살펴 위험을 판정하는 것이다. 상위 보유자들이 같은 자금 출처에서 돈을 받았는지 추적하고, 같은 블록에서 함께 매수한 지갑을 찾아 조직적인 진입 가능성을 본다. 여러 보유자가 같은 블록에서 많은 물량을 팔면 조직적인 이탈로 표시한다. 토큰 만든 사람의 과거 출시 기록도 확인해, 처음 출시인지, 정상인지, 기록이 나쁜지, 반복적으로 사기 토큰을 만든 사람인지 나눈다. 동결 권한이 아직 살아 있는지 같은 허니팟 위험도 함께 확인한다.
cs4ai는 C# 프로젝트에서 AI 에이전트가 단순 글자 검색 대신 코드의 의미를 기준으로 찾고 고치게 해 주는 Roslyn 기반 명령줄 도구다. Claude가 C# 작업을 할 때 함수나 타입을 찾으려고 grep을 쓰면 주석, 문자열, 프로젝트 파일 이름, 비슷한 이름까지 섞여 수십 개 결과를 읽게 되고, 그 과정에서 토큰이 낭비되거나 잘못 고칠 수 있다. cs4ai는 솔루션을 빌드해 세션 토큰을 만들고, 특정 타입 전체를 살펴본 뒤 상태 확인 토큰을 돌려준다. 코드를 고칠 때는 그 토큰을 함께 내야 하며, AI 에이전트가 오래된 이해를 바탕으로 수정하려 하면 현재 소스를 함께 보여 주며 거절한다. 함수 본문 변경, 이름 변경, 빌드와 테스트 확인 같은 작업을 명령으로 처리하며, 이름 변경은 모든 호출 위치까지 의미를 기준으로 바꾼다. 명령의 종료 코드는 명령 자체가 맞았는지만 뜻하고, 빌드와 테스트 결과는 본문에 새 문제인지 기존 문제인지 표시되어 나온다. 수정 내용은 바로 디스크에 쓰이고, 되돌리기는 git이 맡는다.