AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
오픈 가중치 AI 모델은 Hugging Face 같은 중앙 저장소에 많이 모여 있어, 접근 제한이나 삭제가 생기면 개인 개발자와 작은 팀이 영향을 받을 수 있다. 그래서 모델 파일을 토렌트, 아이피에프에스, ModelScope, ModelRegistry 같은 다른 경로에도 나눠 보관하자는 의견이 나온다. 핵심은 모델 파일을 여러 사람이 가진 상태로 두고, 파일이 바뀌지 않았는지 확인할 체크섬과 믿을 수 있는 출처 표시를 함께 갖추는 것이다. 일부는 추론에 바로 쓰는 작은 형식만 모으지 말고, 나중에 다시 변환하거나 연구에 쓸 수 있는 더 원본에 가까운 형식도 저장해야 한다고 본다. 다른 쪽에서는 큰 모델을 개인 장비에서 돌리기 어렵고, 앞으로는 하나의 거대한 모델보다 여러 작은 전문 모델을 조합하는 방식이 더 현실적이라고 본다. 하드웨어 가격, 메모리와 그래픽카드 공급, 지역별 다운로드 제한도 개인이 로컬 AI를 쓰는 비용에 직접 영향을 준다는 점이 함께 언급된다.
검색 증강 생성 챗봇이 지식 베이스에 있는 답을 찾지 못해 “모르겠다”고 답할 수 있다. 실제 답은 처음부터 색인된 `sla-policy.md` 문서에 있었고, “우선순위 1 사고는 1시간 응답, 4시간 해결 SLA를 가진다”는 내용이었다. 문제는 사용자가 “SLA”, “P1”처럼 줄임말로 물었지만, 문서에는 이를 풀어 쓴 표현이 들어 있었다는 점이다. 임베더가 줄임말을 자동으로 넓혀 해석하지 못해, 질문과 정답 문서 조각의 코사인 유사도가 0.41에 그쳤다. 그 결과 정답 조각은 47위로 밀렸고, 상위 5개만 모델에 넘기는 설정에서는 아예 문맥에 들어가지 못했다. 모델이 고장 난 것이 아니라, 답을 만들 재료를 받지 못한 상태였다. 재발을 줄이려면 실제 사용자가 쓰는 줄임말, 코드명, 약어가 들어간 질문 12~15개로 recall@5 평가를 만들고, 임베더를 바꿀 때마다 지속적 통합에서 실패를 잡아내야 한다.
감정을 잘 이해하는 AI 동반자를 만들 때 단순히 “따뜻하게 공감하라”는 지시문 하나만 쓰면 얕은 위로처럼 들리기 쉽다. 이 구현은 Nonviolent Communication이라는 대화 원칙을 여러 단계의 LLM 처리 흐름으로 나누어 더 나은 답변을 만들려는 시도다. 구조는 에이전트가 아니라 워크플로다. 실행 순서는 코드에 고정되어 있으며, 모델이 다음 단계를 스스로 정하지 않는다. 흐름은 라우터, 분석기들, 작성기, 검증기 순서로 이어진다. 라우터만 입력 메시지를 읽고 어느 흐름으로 보낼지 판단하는 LLM 호출이며, 외부 상태를 바꾸는 도구 호출은 없다. Anthropic의 구분에 따르면 에이전트는 모델이 다음 행동과 실행 흐름을 직접 이끄는 방식이고, 이 사례는 미리 정한 경로에 LLM 호출을 배치한 방식이다.
일반적인 인공지능 도구는 첨부파일을 받으면 무엇이 중요한지 잘 모르기 때문에 표면적인 내용만 뽑아내기 쉽다. 사용자가 찾을 내용을 자세히 지시하지 않으면 결과가 너무 넓고 평범해질 수 있다. 이 방식은 사용자가 과거에 저장한 내용, 서로 연결한 이유, 작업 흐름을 바탕으로 인지 지도를 만든다. 첨부파일이 올라오면 에이전트가 그 인지 맥락을 참고해 사용자에게 실제로 필요한 내용을 고른다. 사용자가 별도 지시를 내리면 그 지시가 인지 맥락보다 우선한다. 추출이 끝난 뒤에는 인지 맥락을 다시 사용해 새로 뽑은 내용을 기존 자료와 연결한다.
GPT-5.6은 출시 초기 2주 동안 미국 정부가 승인한 회사에만 먼저 제공된 것으로 제시된다. 이 때문에 OpenAI나 Anthropic 같은 외부 회사의 최신 모델에만 기대면 제품 출시 일정과 기능 계획이 흔들릴 수 있다는 우려가 나온다. 정부나 공급사가 접근 대상을 제한하면, AI 에이전트 제품은 새 기능을 내지 못하거나 경쟁 제품보다 늦어질 수 있다. 그래서 각 회사가 자체 모델이나 오픈소스 모델을 함께 준비해야 한다는 결론으로 이어진다. 자체 모델 운영 비용은 빠르게 낮아지고 있으며, GPU 가격 하락과 Cerebras, Fireworks, Groq, SambaNova 같은 업체의 가격 경쟁이 이유로 제시된다. Qwen, Llama, Mistral, DeepSeek 같은 오픈소스 모델은 많은 작업에서 GPT-4에 가까운 품질에 접근하고 있다고 평가된다.
octomind는 터미널에서 실행하는 오픈소스 에이전트 명령줄 도구다. 긴 에이전트 작업이 오래 이어질수록 느려지고, 판단이 흐려지고, 비용이 커지는 문제를 줄이는 데 초점을 둔다. 여러 MCP 서버를 연결해도 모든 도구를 처음부터 계속 문맥에 넣지 않고, 필요한 기능이 생길 때만 관련 도구를 불러온다. 한동안 쓰지 않는 도구는 LRU 방식으로 내보내서, 모델이 매번 봐야 하는 도구 목록을 작게 유지한다. 긴 대화 내용을 계속 덧붙이는 대신 중요한 구조만 남기며 문맥 압축을 해, 모델이 더 짧고 최신 상태의 정보로 작업하게 한다. 실행마다 비용 상한을 정할 수 있고, 그 한도에 닿으면 작업을 실제로 중단한다. 그래서 재시도 루프가 조용히 예산을 계속 쓰는 일을 막을 수 있다. 역할별로 다른 모델을 고르는 기능, 코드로 쓰는 안전 규칙, MCP 지원도 포함된다.
RAG, 메모리, 에이전트, 그래프, 개체 추출, 청킹, 재순위화, 임베딩 같은 아이디어는 바로 만들기 전에 먼저 평가 방법을 정해야 한다. AI에게 대충 시켜서 코드를 만들고, 그래픽처리장치를 빌리고, 여러 실험 폴더를 만들다 보면 며칠 뒤에도 아이디어 자체가 맞는지 알기 어렵다. 실패 원인은 아이디어가 나쁜 것일 수도 있고, 구현이 틀린 것일 수도 있고, 테스트 방법이 잘못된 것일 수도 있다. 그래서 검색 단계는 Precision@k, Recall@k, MRR, nDCG, Context Entity Recall 같은 기준으로 보고, 답변 생성 단계는 Faithfulness, Hallucination Rate, Groundedness, Answer Relevancy 같은 기준으로 봐야 한다. 전체 시스템은 인용 정확도, 하위 질문 처리 범위, 복합 질문 정확도 같은 기준으로 점검할 수 있다. 운영 관점에서는 지연 시간, 처리량, TPS, 질문당 비용을 함께 봐야 한다. NQ, TriviaQA, SQuAD, PopQA, HotpotQA, 2WikiMultiHopQA, MuSiQue, Bamboogle, CRAG 같은 공개 데이터셋을 써서 비교 실험을 할 수 있다.
Qwen3-VL-2B는 인텔 i3, 메모리 8GB, 윈도우 11, 내장 그래픽만 있는 낮은 성능의 노트북에서도 이미지에서 필요한 값을 뽑아 JSON으로 정리하는 작업을 꽤 안정적으로 처리했다. 같은 조건의 개인 테스트에서는 Qwen3-VL-2B Q4_K_M GGUF가 Qwen3-VL-4B와 Qwen3.5 2B보다 이 특정 작업에서 더 나은 결과를 냈다. 다른 모델들은 결과 품질이 실사용 기준에 못 미쳤다. 다만 이 평가는 정식 실험이 아니라 제한된 기기 3대에서 해 본 개인 테스트다. Qwen3-VL-2B는 주요 공개 성능표인 Artificial Analysis나 Open LLM Leaderboard에는 빠져 있고, 4B 버전만 올라와 있다. 저사양 노트북, 휴대폰, Raspberry Pi 같은 작은 기기에서 JSON 추출을 제대로 할 수 있는 대안 모델이 있는지도 아직 뚜렷하지 않다.
같은 400개 출력물을 사람 검토자 3명과 LLM 심판이 함께 평가했을 때, 사람끼리는 약 89% 일치했지만 LLM과 사람의 일치는 약 71%에 그쳤다. LLM은 실제로는 괜찮은 경계선 사례를 나쁘다고 너무 자주 표시했고, 사람이 잡아낸 미묘한 문제 일부는 놓쳤다. 평가 전에 이유를 먼저 쓰게 하는 방식은 일치율을 약 76%로 올렸다. 경계선 사례를 몇 개 예시로 넣는 방식은 약 78%까지 올렸다. LLM 심판 3개를 돌려 다수결로 정하는 앙상블 방식은 약 82%까지 개선됐다. 사람이 붙인 라벨로 더 작은 분류 모델을 파인튜닝하면 약 85%까지 갔지만, 계속 관리해야 하는 부담이 생겼다. 사람끼리도 89%가 한계라면, 앙상블의 82%와 사람 기준의 89% 사이 7%포인트 차이를 비용을 들여 더 줄일 가치가 있는지가 핵심 문제다.
LangGraph로 만든 AI 에이전트에 약 7개의 도구가 붙어 있고, 배포 전 자동검사인 CI에 종합 평가가 필수 통과 단계로 들어갔다. 그 결과 가장 느린 쪽 기준인 p99 빌드 시간이 6분에서 24분으로 늘었다. 지연의 주된 원인은 평가용 판정 모델 호출이다. 약 200개 상황을 두 번씩 돌리면서 판정 호출이 크게 쌓인다. 개발자들은 이 긴 검사를 피하려고 변경 사항을 한꺼번에 모아 올리기 시작했고, 빠르게 자주 배포하는 CD 흐름이 사실상 깨졌다. 병렬 처리로 판정 호출을 동시에 돌리면 5배 빨라졌지만, 호출 제한 오류인 429 위험이 생겼다. 바뀌지 않은 상황을 다시 평가하지 않는 의미 기반 캐시는 약 60%가 재사용됐지만, 언제 캐시를 버려야 하는지 관리가 어려웠다. 현재 후보는 풀 리퀘스트에서는 가벼운 평가만 하고 밤에 무거운 평가를 돌리기, 배포 뒤 비동기 평가와 카나리아 롤백을 붙이기지만, 행동을 실행하는 에이전트가 잠깐이라도 고장 난 상태로 나갈 수 있다는 걱정이 남아 있다.
Clark Air는 Sana 1.6B라는 텍스트-이미지 모델의 핵심 부분을 크게 압축한 버전이다. 원래 FP16 기준 모델 크기는 3.21GB인데, 압축된 파일은 374MB로 약 8.6배 작다. 압축은 가중치를 ternary 방식으로 줄이고, 그룹별 보정값을 붙이는 방식이다. 전체 매개변수의 약 5%인 조건 처리와 투영 계층은 더 높은 정밀도로 남겨 품질 손실을 줄였다. 측정 기준으로는 가중치 하나당 약 1.85비트를 쓴다. 압축을 풀어 호환성을 맞춘 버전도 있으며, diffusers에서 바로 바꿔 넣어 쓸 수 있다. 기본 모델은 512픽셀 이미지를 만드는 Sana 1.6B이고, 라이선스는 Apache-2.0이다.
기능 개발을 처음 아이디어부터 배포 직전까지 여러 단계로 나누어 자동화하는 고급 작업 흐름이다. 아이디어 정리, 화면 초안, 약점 점검, 상세 명세 작성, 작업 쪼개기, 병렬 구현, 까다로운 검토, 구조 개선, 종단 간 테스트, 문서 갱신까지 이어진다. 핵심은 메인 세션이 전체 흐름을 지휘하고, 하위 에이전트들이 각자 맡은 일을 따로 처리하는 방식이다. 각 구현 작업은 분리된 작업 공간에서 진행되어 서로의 코드 변경이 섞이는 위험을 줄인다. 여러 모델과 에이전트를 역할별로 나누어 쓰며, 일부 단계에서는 일부러 반대 입장에서 문제를 찾는 검토를 넣어 품질을 높인다. 이 방식은 문맥을 한 대화에 모두 몰아넣지 않고 단계별로 관리하려는 목적도 있다.
OpenClaw는 왓츠앱, 텔레그램, 이메일에서 들어오는 메시지를 로컬 Gateway 데몬이 받아 인공지능 핵심 기능으로 보내는 구조다. 기억 내용은 SOUL.md / MEMORY.md 같은 일반 파일로 저장되어 직접 열어 보고 검색할 수 있다. 기능 확장은 ClawHub에서 가져오는 여러 SKILL.md로 한다. 시작 명령인 openclaw onboard를 쓰면 한 번에 실행할 수 있다. 장점은 판단 과정과 기억이 내 컴퓨터의 파일로 남아 확인하기 쉽다는 점이다. 문제는 SKILL.md가 사실상 남이 만든 코드와 지시문인데, 에이전트가 이를 믿을 만한 지시로 받아들인다는 점이다. 2026년 2월에는 ClawHavoc이라는 공격으로 ClawHub에 악성 기술 파일 약 1,184개가 올라갔고, 이 안에는 데이터 빼내기, macOS 정보 탈취, 원격 접속용 뒷문 같은 기능이 숨어 있었다. 또 약 31,000개의 에이전트 기술을 조사한 결과 약 26%에서 하나 이상의 취약점이 발견됐고, 조작된 이메일 하나로 설정 파일과 API 키, 게이트웨이 토큰이 새어 나갈 수 있다는 간접 프롬프트 주입 사례도 제시됐다.
Claude로 게임 개발을 할 때 작업 배경을 여러 번 다시 설명해야 하면 반복 작업이 느려지고 결과 품질도 흔들릴 수 있다. 이 워크플로는 오픈소스로 공개된 스킬 묶음과 에이전트 설정을 사용해, 사용자가 말한 개발 내용과 감지된 게임 엔진이나 작업 종류에 맞는 지식과 문맥을 자동으로 불러온다. Claude Code, Cursor, Kiro 같은 도구에서 쓸 수 있는 방식이다. 목표는 긴 개발 세션에서도 Claude가 필요한 배경을 더 잘 유지하게 만들어, 같은 설명을 반복하는 시간을 줄이고 결과의 일관성을 높이는 것이다. 특히 게임 개발에 필요한 품질 관리, 문맥과 메모리, 스킬, 하위 에이전트, 다중 에이전트 구성을 함께 다룬다.
30년 넘게 앱·웹·기업용 시스템을 만든 개발자가 시스템 프로그래밍 전문 지식이 많지 않은 상태에서 Claude Code로 SQLite 3.54.0을 C에서 Zig로 단계적으로 옮기고 있다. 한 번에 전체를 다시 쓰게 한 것이 아니라, 이미 옮긴 Zig 코드와 아직 남은 C 코드를 같은 실행 파일 안에서 함께 돌리며 하나씩 바꾸는 방식이다. 이 방식 덕분에 데이터베이스는 매일 작동하는 상태를 유지했고, SQLite 자체 테스트 묶음으로 매 단계 검증했다. 지금까지 활성 C 번역 단위 102개 중 90개가 Zig로 바뀌었다. 약 28만 7천 줄의 기존 C 코드에서 약 16만 9천 줄의 Zig 코드가 만들어졌다. 실제 API 사용량은 입력, 캐시, 출력을 합쳐 약 9억 1,900만 토큰이며, 최근 한 세션만 약 7억 8,000만 토큰을 썼다. 전체 작업 시간은 약 25~32시간이었다.
Buildable은 Claude Code, Codex, Cursor, 명령줄 작업에서 쓸 수 있는 오픈소스 플러그인과 스킬 저장소다. 목표는 로컬 코딩 에이전트가 고객관리 도구, 작업 관리 도구, 모바일 습관 추적기 같은 앱을 더 빨리 시작하게 돕는 것이다. 핵심 방식은 에이전트가 빈 화면에서 모든 것을 새로 판단하지 않도록 앱 유형, 앱 명세, 재사용 가능한 작은 구성요소, 사용자 경험 지침, 로컬 우선 기준, 실행 가능한 시작 템플릿, 검토 항목을 미리 제공하는 것이다. 현재 61개 앱 유형, 빌드 검증을 거친 15개 시작 템플릿, 예정된 16개 템플릿 묶음, 웹과 Expo 모바일 작업 흐름을 지원한다. 별도 호스팅 백엔드를 전제로 하지 않고, 사용자의 저장소와 파일 안에서 작업하는 로컬 우선 방식을 기본으로 한다. TOON 전달 파일을 써서 에이전트가 전체 저장소를 다 읽지 않아도 필요한 내용을 작게 받아볼 수 있게 한다. 검토 항목에는 구조, 로컬 우선 원칙 이탈, 접근성, 반응형 화면, 상태 처리 범위, 디자인 토큰 사용이 포함된다.
memlawb는 AI 에이전트가 여러 작업 세션을 지나도 기억을 유지하게 해 주는 오픈소스 메모리 도구다. 기억 내용은 사용자의 컴퓨터에서 먼저 종단 간 암호화되고, 서버에는 읽을 수 없는 암호문만 저장된다. 서버 운영자는 기억 내용, 암호, 암호를 푸는 열쇠를 볼 수 없다. 직접 운영할 수 있으며, 파일 시스템이나 S3 계열 저장소를 붙일 수 있다. MCP를 지원하는 에이전트는 설정 한 블록을 추가해 기억 저장, 불러오기, 검색, 목록 보기, 삭제 기능을 쓸 수 있다. 델타 동기화로 바뀐 항목만 올리며, 업로드 전에 비밀번호나 인증키처럼 보이는 민감한 값이 있는지도 사용자의 컴퓨터에서 먼저 검사한다. 현재 베타 상태이고, 서버·클라이언트 암호화·명령줄 도구·MCP 서버·비밀값 검사·사용량 제한이 구현되어 있으며 50개 테스트가 있다. 무료 베타 서버는 memory.gitlawb.com에서 제공되지만, 암호를 잃어버리면 운영자도 데이터를 복구할 수 없다.
NagaTranslate는 인도 나갈랜드의 언어인 나가미즈, 아오, 세마를 번역하고 음성으로 다루기 위한 서비스다. 이 언어들은 오래동안 말로 주로 쓰였고, 표준화된 번역 데이터가 적어서 일반적인 번역 모델을 만들기 어렵다. 현재 글 번역은 상용 LLM API에 잘 다듬은 지시문과 예시 몇 개를 넣어 처리한다. 처음에는 NLLB 모델을 직접 조정해 썼지만, 일상 대화의 자연스러움과 문맥 이해를 높이기 위해 상용 API 방식으로 바꿨다. 장기 목표는 가벼운 Llama나 Gemma 같은 오픈 가중치 모델을 직접 운영해 API 비용 없이 독립적으로 돌아가는 구조를 만드는 것이다. 하지만 GPU 운영 비용과 작은 모델의 번역 품질이 큰 장애물이다. 음성 합성은 직접 모은 나가미즈 음성 데이터로 조정한 VITS를 쓰고, 음성 인식은 직접 모은 녹음으로 조정한 Whisper를 쓴다. 두 음성 기능은 Hugging Face Spaces ZeroGPU에 올려 보안 API 뒤에서 실행하며, 안드로이드용 Flutter 앱도 비공개 테스트 중이다.
OpenAI와 Anthropic 같은 독립 AI 회사가 장기적으로 불리할 수 있다는 주장이 나온다. 이유는 Google, Microsoft, Apple처럼 이미 많은 사람이 쓰는 제품과 기기를 가진 회사들이 AI를 별도 상품이 아니라 기본 기능처럼 넣을 수 있기 때문이다. Dropbox가 초기에 인기를 얻었지만 Google Drive와 Microsoft OneDrive 같은 큰 생태계 안의 서비스에 밀린 것과 비슷하다는 비교다. 반론도 크다. AI는 파일 저장처럼 단순한 상품이 아니며, 좋은 모델과 개발자용 도구, 안정적인 API는 여전히 돈을 낼 만한 가치가 있다는 시각이다. 특히 기업과 정부처럼 업무에 AI를 깊게 넣는 고객은 무료 챗봇보다 성능, 신뢰성, 보안, 도구 연결을 더 본다. 한 실무 사례에서는 AI 사용 비용이 월 20달러에서 200달러, 400달러를 거쳐 1만 달러까지 늘었고, Anthropic, OpenAI, Gemini, Kimi, Minimax, Deepseek 등 여러 모델을 용도별로 시험한다고 했다. 다만 싼 모델이 항상 싸게 끝나는 것은 아니며, 같은 결과를 내기 위해 더 많은 토큰을 쓰면 실제 비용이 커질 수 있다는 점이 핵심이다.
KoboldCpp 1.116 계열은 개인 컴퓨터에서 AI 모델을 돌리는 사람에게 유용한 업데이트다. 내장된 llama.cpp 웹 화면이 MCP 서버를 지원해, 로컬 모델을 외부 도구와 연결하는 에이전트 실험이 쉬워졌다. 도구 호출 응답을 먼저 llama.cpp의 Jinja 방식으로 해석하도록 바뀌어, 새 도구 호출 모델을 처음 설정할 때 맞물릴 가능성이 커졌다. Qwen과 Gemma 보조 MTP의 속도 문제가 고쳐져, 초안 모델을 함께 쓰는 빠른 생성 방식이 더 쓸 만해졌다. Hugging Face xet 다운로드 속도 저하와 일부 SSL 다운로드 문제도 고쳤고, 스트리밍을 끈 상태에서 추론 내용이 보이지 않던 문제도 수정됐다. 이미지 생성 쪽에서는 Krea 2 Turbo, Ideogram 4, Boogu Edit 지원이 추가됐고, 이미지 생성 프롬프트 길이 제한은 3000자로 늘었다.
55개 거대언어모델이 같은 질문에 답하고, 서로의 답을 익명으로 채점했다. 자기 자신을 채점하는 경우는 뺐고, 한 모델만 심판으로 세우지 않는 방식이었다. 전체 자료는 286번의 평가, 직접 만든 질문 198개, 유효 채점 2만2254건, 11개 개발사 계열의 모델 55개로 구성됐다. 코드, 데이터셋, 프롬프트는 모두 MIT 라이선스로 공개됐다. 충분한 자료가 있는 8개 모델 계열 모두에서 같은 계열 모델을 다르게 평가하는 편향이 통계적으로 확인됐다. Qwen 심판 모델은 다른 Qwen 모델에 약 0.91점을 더 주었고, xAI는 0.75점, Anthropic은 0.62점, MiniMax는 0.31점, OpenAI는 0.23점을 더 주었다. 반대로 Google은 같은 계열을 0.59점 낮게, Meta는 0.68점 낮게, Mistral은 1.02점 낮게 평가했다. 특히 코드 문제에서 심판 모델들의 의견 차이가 가장 컸고, 9개 분야별 묶음에서는 서로 다른 6개 모델이 1위를 차지해 하나의 ‘최고 모델’만 고르는 방식이 부족하다는 점도 드러났다.
고장 난 n8n 자동화 흐름을 밤사이 점검하고, 사람이 보기 전에 수정안을 준비하는 에이전트 구조다. n8n의 오류 처리 흐름이 실패한 실행 내용을 에이전트로 보내면, 에이전트가 원인을 찾고 자동화 흐름 파일 안에서 고칠 수 있는 문제인지 사람이 처리해야 하는 문제인지 나눈다. 인증 문제처럼 계정 권한이나 로그인과 관련된 문제는 항상 사람이 처리하도록 남긴다. 수정안을 만든 모델은 자기 작업을 직접 승인하지 않는다. 예를 들어 Claude가 수정안을 만들면 OpenAI 모델이 별도로 검토한다. 두 모델은 만든 회사와 학습 방식이 달라 같은 실수를 반복할 가능성을 줄이려는 설계다. 검토 모델에는 쓰기 권한이 없어서, 검토가 틀리더라도 실제 자동화 흐름을 바꿀 수 없다. 실제 쓰기 전에는 모델이 아니라 일반 코드가 변경 차이를 확인하고, 진단된 부분 밖을 건드리는 수정은 거부한다.
개인 실험에서 로컬 대형언어모델이 개미 시뮬레이션의 여왕개미 역할을 맡아 일개미에게 명령했다. 목표는 여왕개미를 포함해 일개미 100마리 규모의 군체를 만드는 것이었다. 일개미는 먹이를 찾고 가져올 수 있으며, 먹이는 시간이 지나면 줄고 알을 낳는 데도 쓰인다. 먹이 10점으로 알 2개를 만들 수 있고, 한 번 0까지 고갈된 먹이원은 다시 채워지지 않는다. 기본 프롬프트만 줬을 때는 테스트한 모델들이 충분한 먹이가 있어 바로 목표를 끝낼 수 있는 상황에서도 군체를 굶겨 죽였다. “일개미를 더 만들어야 하며 먹이만 계속 찾으면 안 된다”는 힌트를 주자, 모델들은 살아 있는 일개미가 먹을 몫까지 써서 너무 빠르게 번식했고 결국 굶어 죽었다. 목표 달성에 필요한 계산과 현재 상태를 함께 보라는 힌트를 주자, 모델들은 승리할 수 있었다. 하지만 이 방식은 답에 가까운 길을 너무 직접적으로 알려주는 느낌이 있어 실험자가 만족하지 않았다.
실제 서비스에서 AI 에이전트를 돌릴 때 비용이 꾸준히 늘어나는 것보다 더 큰 문제는 실패한 행동을 계속 다시 시도하는 경우다. 에이전트가 매번 계획을 조금씩 바꾸며 같은 막힌 지점을 반복하면, 정해 둔 예산이 빠르게 사라질 수 있다. 전체 지출 한도는 손실을 멈추게 할 수 있지만, 어떤 분기나 도구 호출이 돈을 가장 많이 썼는지는 알려주지 않는다. 운영 단계에서는 호출별 비용과 도구별 비용을 따로 기록해야 원인을 찾기 쉽다. 중단 기준도 단순한 총액 한도만으로는 부족하며, 더 이상 진전이 없을 때 멈추는 규칙까지 함께 고민해야 한다.
Claude Code를 쓰면 작업 기록이 컴퓨터의 `~/.claude/projects/` 아래에 `.jsonl` 파일로 저장된다. 이 기록에는 여러 차례 이어진 코딩 대화, 코드 수정 과정, 도구 호출, 추론 흔적이 들어 있다. `claude_converter`는 이 파일을 로컬 모델 학습에 쓰기 쉬운 대화 형식으로 바꿔 준다. 변환된 결과는 `TRL`, `Axolotl`, `LLaMA-Factory` 같은 학습 도구에서 쓸 수 있는 형식과 맞는다. 학습 전에 불필요한 블록을 지우는 `clean_messages()` 도우미도 있다. `inspect_session()` 기능은 토큰 수와 내용 블록 구성을 보여 줘서, 어떤 데이터를 학습에 넣는지 미리 확인하게 해 준다. 별도 의존성 없이 작동한다.
AI는 코드를 더 빨리, 더 싸게 만들 수 있게 했다. 하지만 실제 개발에서 중요한 일은 코드 작성 전후로 옮겨 갔다. 무엇을 정확히 요청할지 정하고, 충분한 컨텍스트를 주고, 틀린 가정을 잡아내야 한다. 예상 밖 상황인 엣지 케이스도 확인해야 한다. 무엇을 실제로 배포할지 결정하고, 겉으로는 작동하지만 시스템에 맞지 않는 코드를 정리하는 일도 필요하다. 그래서 개발 업무는 사라진 것이 아니라, 직접 코드를 치는 일에서 방향을 잡고 검토하고 기존 코드베이스에 맞게 합치는 일로 바뀌었다. AI가 만든 코드는 완성품이라기보다 매우 빠른 초안에 가깝다. 프로토타입에는 괜찮을 수 있지만, 실제 코드베이스에서는 변경이 시스템에 잘 맞는지 확인하는 일이 여전히 비용이 큰 부분이다.
전문 분야에 강한 AI 에이전트를 만들 때 어떤 투자가 가장 효과적인지 묻는 문제입니다. 핵심 선택지는 더 나은 프롬프트와 문맥 설계, 검색 증강 생성으로 넣는 분야별 자료, 장기 메모리, 미세조정, 합성 데이터 생성과 계속 학습, 도구 연결과 실행 구조입니다. 예시로 금융 분석가나 법률 조사원처럼 특정 분야에서 깊이 있는 답을 해야 하는 에이전트를 만들려면 어디에 먼저 힘을 써야 하는지가 쟁점입니다. 실제 운영 환경에서 에이전트를 만들어 본 사람들의 경험을 통해, 전문성은 모델 하나만 바꾸는 문제가 아니라 자료, 기억, 도구, 학습 방식, 실행 흐름을 어떻게 조합하느냐의 문제로 볼 수 있습니다.
새 AI 에이전트 프로젝트가 개발자 기여자를 찾고 있다. 이 프로젝트에는 새 하네스가 있으며, 현재 결과가 매우 좋다고 소개됐다. 핵심 성과로 에이전트 설계가 꾸준히 95~99%의 캐시 적중률을 낸다는 점이 제시됐다. 캐시 적중률이 높으면 같은 계산이나 응답을 다시 쓰는 비율이 높아져, AI 호출 횟수와 토큰 사용량을 줄일 가능성이 있다. 프로젝트의 기능 범위가 매우 크다는 주장도 함께 나왔지만, 구체적인 코드, 벤치마크, 비용 절감 수치는 제시되지 않았다.
메모리 오염은 AI 에이전트의 기억 저장소에 거짓 정보를 넣어 두고, 나중에 그 거짓 기억이 답변이나 행동을 바꾸게 만드는 공격이다. MINJA와 Agent Security Bench 같은 연구에서는 일반적인 메모리 기반 에이전트가 이런 공격에 70~95% 성공률로 뚫린다고 보고했다. 이번 테스트는 메모리 단계에서 같은 공격을 다시 만들고, 에이전트가 실제로 꺼내 쓸 기억 기준으로 결과를 쟀다. 비교 대상은 중요도와 최신순으로 기억을 고르는 단순 저장소와, 기억이 오래 남고 신뢰받으려면 결과로 검증되거나 서로 독립적인 근거가 2개 이상 있어야 하는 검증 문턱 저장소였다. 공격 목표는 거짓 기억을 오래 남기는 것과 이미 있는 참된 사실을 거짓으로 덮어쓰는 것이었다. 각 조건마다 150번씩 시험한 결과, 단순 저장소는 두 목표 모두 100% 오염됐다. 검증 문턱은 출처가 하나뿐인 거짓 기억을 0%로 막았다. 다만 시빌 공격처럼 독립적인 것처럼 보이는 근거를 2개 이상 꾸며내면 다시 100% 뚫렸고, “항상 이렇게 하라” 같은 절차 기억 형태의 거짓 지시는 오래 남도록 설계된 기억이라 문턱을 우회했다.
Gemma-4-12B-it에서 안전 제한을 강하게 제거하면 추론 능력이 크게 떨어질 수 있다. gemma-4-it-12B-uncensored-opus4.7-cot는 이 손실을 줄이기 위해 QLoRA로 다시 학습된 12B 모델이다. 학습에는 Claude Opus 4.7이 만든 STEM 분야의 Chain-of-thought 추론 흔적이 쓰였다. 결과 표에서는 원래 Gemma-4-12B-it가 MMLU 0.777, GSM8K 0.949였고, 제한 제거 직후 모델은 MMLU 0.635, GSM8K 0.496까지 내려갔다. 다시 학습한 모델은 MMLU 0.739, GSM8K 0.920까지 회복했다. 낮을수록 좋은 Word Perplexity는 원래 모델 895, 제한 제거 직후 2360, 다시 학습한 모델 580으로 나왔다. WikiText-2 bits/byte도 원래 모델 1.834, 제한 제거 직후 2.095, 다시 학습한 모델 1.717이었다. 모델 파일은 Hugging Face에서 Safetensors와 GGUF 형식으로 제공된다.