AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
LLM 환각 중 가장 잡기 어려운 경우는 답이 자연스럽고 자신 있어 보이지만 실제로는 틀린 경우다. 모델이 망설이거나 불확실해 보이는지를 보는 방식은 이런 경우에 약하다. 약 124개 프롬프트를 살펴본 결과, 확신에 찬 지어내기와 참인 답변은 평균적인 내부 반응만 보면 통계적으로 거의 구분되지 않았다. 모델이 거짓말할 때 항상 같은 ‘방향’으로 움직이는 신호는 보이지 않았다. 차이는 크기와 분산에 있었다. 지어낸 답변에서는 모델 내부 흐름이 더 크게, 더 넓게 흔들렸다. 표현 변화 채널에서 지어내기와 참인 답변의 분산 비율은 약 7배였고, 효과 크기는 Cohen's d 약 0.58, p값은 약 0.005였다. 지어내는 정도가 강할수록 흔들림도 커지는 용량-반응 관계가 보여, 단순한 잡음이 아니라 지어내기의 성질일 가능성이 커졌다. 실무적으로는 특정 ‘거짓 방향’을 찾기보다 불안정성을 보고, 답변 전체 구간에 걸쳐 신호를 모으며, 탐지 결과를 차단 장치 하나로만 쓰지 말고 수정이나 재검증 같은 개입과 연결해야 한다.
AIGX는 AI 코딩 에이전트가 코드베이스의 규칙을 더 쉽게 찾도록 돕는 공개 형식이다. 프로젝트 안에 `.aigx/` 폴더를 두고, 제품 설명, 설계 규칙, 엔지니어링 규칙, 파일별 주의사항을 따로 저장한다. 핵심은 `files.aigx`라는 파일별 색인이다. 에이전트가 특정 파일을 고칠 때 그 파일에서 지켜야 할 규칙, 금지된 가져오기, 자주 생기는 실수를 한 번에 찾게 한다. 소스 코드 안에 설명을 끼워 넣지 않기 때문에 기존 코드가 더러워지지 않는다. `npm create aigx`로 시작할 수 있고, Cursor, Claude Code, GitHub Copilot, Windsurf, Aider, `AGENTS.md` 같은 여러 도구에 연결할 수 있다. 검증 도구는 Node, Python, Rust용으로 제공되며, `aigx lint`로 규칙 파일이 깨졌는지 확인하고 `aigx resolve <path>`로 특정 파일에 적용되는 규칙을 볼 수 있다. 자체 벤치마크에서는 Claude Haiku 4.5와 Sonnet 4.6에서 AIGX가 평균 점수, 첫 시도 통과율, 숨은 테스트 통과율에서 모두 가장 높았지만, 상위 형식들의 차이는 통계적으로 크지 않다고 밝힌다.
Decispher는 팀 안에 흩어진 코드 관련 결정, 작업 규칙, 제한 사항을 한곳에 모아 사람과 AI 에이전트가 함께 쓰게 하는 도구다. AI 에이전트가 코드베이스의 배경을 모르면 그럴듯하지만 틀린 코드를 만들 수 있고, 이미 팀이 해결한 문제를 다시 찾느라 토큰을 낭비할 수 있다. Decispher는 Slack, GitHub, Jira에서 오간 대화에서 중요한 결정을 잡아내고, 문서를 손으로 쓰지 않아도 필요할 때 다시 꺼내준다. AI 에이전트는 매번 전체 코드베이스를 많이 넣는 대신, 지금 필요한 결정만 가져와 쓸 수 있다. 자체 테스트에서는 토큰 사용량이 약 65% 줄었다. Branch Story 기능은 브랜치별로 왜 그런 선택을 했는지 남겨, 다음 작업자나 다음 AI 에이전트가 맥락 없이 다시 시작하지 않게 돕는다. 출시 초기 혜택으로 무료 크레딧 50개와 남은 100석이 제시됐다.
하나의 대형 임베딩 컬렉션에 두 가지 성격이 다른 작업이 함께 몰린다는 문제를 다룬다. 첫 번째는 온라인 검색(retrieval)으로, 사용자가 결과를 기다리고 있어 응답 속도(레이턴시)가 중요하다. p95나 p99 같은 응답 지연 지표가 느려지면 서비스가 고장 난 것처럼 느껴지므로, 이 작업에는 전용 컴퓨팅 자원을 따로 두는 게 합리적이다. 반면 두 번째 작업은 학습 전 하드 네거티브(모델이 헷갈려하는 오답 예시) 채굴, 대형 임베딩 컬렉션 중복 제거, 클러스터나 데이터 드리프트 점검, 오프라인 평가 실행, 데이터셋 탐색처럼 몇 시간 집중하고 몇 주는 손대지 않는 배치성 작업이다. 이 두 번째 유형은 응답 속도가 50ms든 아니든 신경 쓰지 않고, 대신 작업이 끝나기만 하면 되고 비용이 예측 가능해야 하며 운영 중인 온라인 검색을 방해하지 않아야 한다. 글쓴이는 온라인 서빙용으로 컴퓨팅 자원을 상시 대기시켜 두는 방식이 분석·배치성 벡터 검색에도 똑같이 적용되는 게 맞는지 의문을 제기하며, 두 작업을 같은 방식으로 다루는 관행이 실제로는 서로 다른 요구사항을 흐리고 있다고 지적한다.
AI 서비스는 실제 운영 비용보다 낮은 가격으로 팔리는 경우가 많다. 큰 AI 모델을 만들고 돌리는 데는 막대한 돈이 들지만, 사용자가 내는 요금이 그 비용을 모두 덮지 못한다는 주장이다. 지금은 벤처 투자자가 그 차액을 감당하며, 낮은 가격으로 많은 사용자를 모은 뒤 나중에 지배적인 기업이 되어 이익을 내기를 기대한다. Anthropic 같은 AI 회사가 상장하면 손실 부담은 주주에게 옮겨갈 수 있다. 연금, 퇴직연금, 401(k) 같은 돈이 지수 펀드에 들어가면, 사용자가 직접 고르지 않아도 큰 상장사의 주식을 자동으로 보유할 수 있다. 그래서 AI를 쓰지 않는 사람도 자신의 노후 자금이 보유한 주식을 통해 다른 사람의 싼 토큰 사용을 간접적으로 떠받칠 수 있다. 다만 AI 운영 비용이 더 빨리 내려가면 이 보조금은 줄 수 있고, 새로 상장한 회사가 곧바로 큰 지수에 들어가는 것도 아니다.
AI 에이전트와 검색 증강 생성 시스템은 데모에서는 잘 작동해 보일 수 있다. 하지만 데모가 답변 능력을 보여준다고 해서 실제 업무 데이터에 연결해도 안전하다는 뜻은 아니다. 고객 관리 시스템, 내부 문서, 실제 작업을 실행하는 시스템에 붙이면 가장 큰 위험은 권한 관리에서 나온다. 시스템 프롬프트에 “사용자 본인 데이터만 보여줘”라고 적는 것은 접근 통제가 아니다. 이런 지시는 쉽게 우회될 수 있으므로, 사용자의 신원 확인, 정책, 원본 시스템의 접근 권한 규칙 같은 확정적인 층에서 모델에 데이터가 가기 전에 막아야 한다. 모델은 어떤 시스템에도 항상 열려 있는 권한을 가져서는 안 된다. 또 기존의 높은 권한 토큰이나 서비스 계정을 편의상 재사용하면, 에이전트가 그 계정이 닿을 수 있는 모든 곳에 실제 권한을 갖게 된다. 에이전트에는 별도 신원, 좁게 제한한 권한, 도구별 허용 목록이 필요하다.
멀티 에이전트 Claude Code 작업에서는 여러 에이전트가 오래 실행되거나 같은 자료를 반복해서 읽을 때 토큰 사용량과 비용이 쉽게 늘어난다. 긴 시간 살아 있는 에이전트는 캐시를 써도 추가 비용이 붙을 수 있으므로, 이른바 캐시 세금을 이해하고 줄이는 설계가 필요하다. 하위 에이전트에게 모든 문맥을 다시 읽게 하기보다, 필요한 정보만 정확히 넘기면 중복 읽기를 줄일 수 있다. 중요한 작업 배분은 약한 모델의 판단에만 맡기지 말고, GitHub 라벨이나 이슈처럼 바깥에 있는 명확한 구조를 기준으로 처리하는 편이 안정적이다. 핵심은 비용, 문맥 관리, 작업 배분을 처음부터 분리해 설계해 멀티 에이전트 흐름의 낭비와 오류를 줄이는 것이다.
StarWAM은 비디오 생성 기반 WAM을 더 쉽게 바꿔 끼우며 실험하도록 만든 초기 단계의 오픈소스 코드베이스다. 목표는 복잡한 월드 모델 구성요소를 하나씩 교체할 수 있게 만들어, 여러 구조를 같은 틀 안에서 비교하는 것이다. 현재 Motus와 FastWAM 같은 MoT 방식 구조, DreamZero 같은 공유 DiT 구조, StarVLA WM4A와 Mimic Video에서 아이디어를 얻은 특징 조건부 구조를 지원한다. 모델의 바탕이 되는 백본으로는 Wan2.2 5B와 Cosmos Predict2를 다룰 수 있다. 로봇 작업 평가에 쓰이는 LIBERO 벤치마크도 지원한다. 다만 비디오 생성 모델은 구조가 복잡하고 백본마다 모듈 설계가 달라서, 아직 완전히 깔끔한 조립식 구조는 아니다. 계산 자원과 시간이 부족해 대규모 학습이나 하이퍼파라미터 튜닝도 충분히 진행되지 않았다.
의료 문헌 1만 편 단위로 RAG(검색 후 생성) 시스템을 구축해 운영한 경험담이다. Graphiti(지식 그래프 도구)와 UMLS(의료 용어 표준 데이터베이스)를 결합하는 방식도 시도했지만, 실제 서비스에는 단순한 방식의 RAG를 사용했다. 몇 달간 고객에게 서비스를 제공한 결과, 고객은 이 도구가 ChatGPT보다 못하다고 평가했다. 이유는 두 가지였다. 첫째, 응답 속도가 느려 답변 생성에 2~3분이 걸렸다. 둘째, 결과물이 ChatGPT보다 특별히 의학적으로 더 정확하거나 뛰어나다는 느낌을 주지 못했다. 이 경험을 바탕으로 공개된 데이터에 대해 RAG 기술이 이미 그 데이터를 학습한 최신 LLM을 정말 이길 수 있는지에 대한 근본적인 질문을 던지고 있다.
OpenCode용 플러그인이 주 모델과 코딩용 저가 모델의 역할을 나눠 토큰 사용을 줄인다. 주 모델은 생각, 계획, 검토를 맡고, 실제 코드 작성 작업은 더 싼 코드 모델에 넘긴다. 코드 모델이 작업을 끝내면 결과가 다시 주 모델로 돌아가고, 주 모델이 내용을 검토한다. 작고 단순한 수정은 그대로 주 모델이 직접 처리할 수 있어, 모든 일을 무조건 넘기지는 않는다. 사용 예시는 GLM5.2를 생각용 모델로 쓰고, 무료 DeepSeek V4 Flash를 코딩용 모델로 쓰는 방식이다. 설치는 `opencode plugin opencode-plugin-code-model@latest`로 하고, OpenCode 안에서 `/code_model` 또는 `/cm` 명령으로 코딩에 쓸 모델을 고른다. OpenCode 소스 코드를 직접 바꾸지 않아도 되는 플러그인 방식이다.
disp8ch는 채팅, 시각적 업무 흐름, 에이전트 팀, 보드, 디자인 자료, 문서, 메모리를 한 작업공간에서 함께 다루는 자체 호스팅 도구다. MIT 라이선스로 공개되어 있고, 유료 단계나 잠긴 기능 없이 모두 무료로 쓸 수 있다. 모델 설정을 바꿀 수 있어 로컬 OpenAI 호환 서버, Ollama, LM Studio, llama.cpp, vLLM, SGLang 또는 온라인 제공업체를 연결할 수 있다. 채팅 요청을 실행 기록이 남는 시각적 업무 흐름으로 바꾸고, 실제 변경이 생기는 작업에는 명시적 승인을 두는 구조를 지향한다. 에이전트는 백그라운드에서 일할 수 있고, 각 에이전트에는 역할, 기술, 확장 기능, MCP 서버를 범위별로 붙일 수 있다. 문서, 노트북, 메모리, 보드, 에이전트 역할이 같은 로컬 상태를 공유한다. 소스, 설치 방법, 테스트는 GitHub 저장소에 공개되어 있다.
Claude를 앱에 넣어 쓰려면 개인 채팅용 Claude Pro와 개발용 Claude API를 구분해야 한다. Claude Pro는 사람이 웹이나 앱에서 대화하는 구독 상품이고, Claude API는 서비스나 제품 안에서 Claude를 호출할 때 쓰는 개발자용 접속 방식이다. 처음 시작할 때는 API 접근 권한을 만들고, API 키를 안전하게 보관하며, 작은 테스트부터 진행하는 흐름이 필요하다. 비용 관리는 핵심이다. 호출량과 토큰 사용량을 확인하고, 예상 밖의 과금이 생기지 않도록 사용 한도와 점검 절차를 두는 것이 좋다. 보안에서는 API 키를 코드에 직접 넣거나 공개 저장소에 올리지 말고, 서버 쪽 환경 변수처럼 외부에 드러나지 않는 곳에 저장해야 한다.
20년 경력의 제품 디자이너가 나중에 볼 자료를 저장하는 앱 Kepp을 혼자 만들었다. 기존 앱들은 기능이 너무 많거나, 정리 방식이 딱딱하거나, 저장한 것을 다시 찾기 어려워 신뢰하기 힘들었다. 목표는 폴더나 관리 규칙 없이 빠르게 저장하고 바로 찾는 단순한 앱이었다. 개발자는 아니었지만 프론트엔드, 백엔드, 인프라, 앱스토어와 플레이스토어 등록, 분석, 법무 문서, 개인정보 설정, 결제, 랜딩 페이지까지 직접 처리했다. 전체 제작의 약 3분의 2에 Claude와 Codex를 사용했다. 혼자 만들 때 토큰 예산을 다루는 능력이 실제로 중요하다는 점도 확인했다.
Azure Storage 계정을 여러 프로젝트에서 관리하다 보면, 어떤 문서 안에 특정 문구가 있는지 알아도 그 문구가 어느 파일(blob)에 있는지 찾을 방법이 마땅치 않은 문제가 있다. Azure Storage Explorer나 포털의 검색 기능은 파일 이름만(그것도 대부분 앞부분 일치로) 찾아준다. Azure AI Search는 강력하지만 진입 비용이 높아서(Basic 요금제 월 약 75달러, Standard 요금제 월 약 250달러, 검색 서비스 1개 기준) 사이드 프로젝트나 소규모 배포, 내부 도구에는 부담스럽다. 이 문제를 해결하기 위해 BlobLens라는 도구가 만들어졌다. docker compose up 명령 한 번으로 Azure Blob Storage 전용의 가볍고 셀프 호스팅 가능한 전문 검색 엔진을 띄울 수 있다. 구성은 FastAPI 백엔드와 내장 검색 UI, 오타를 허용하며 즉시 검색되는 Meilisearch 검색 엔진, 백그라운드 인덱싱 워커로 이루어져 있다. Azure Storage 계정의 연결 문자열만 입력하면 PDF, DOCX, TXT, 마크다운, 소스 코드 등 25가지 이상의 텍스트 기반 파일 형식의 내용을 검색할 수 있고, 파일 이름·내용·컨테이너·파일 형식·메타데이터로도 검색과 필터링이 가능하다. 검색 결과는 약 10밀리초 만에 반환되며, 60분간 유효한 임시 다운로드 링크(SAS 링크)도 함께 생성해준다.
사내 LLM 앱에서 안전장치를 붙이는 일이 기능 개발보다 더 큰 부담이 되고 있다. 사례는 고객 문의 기록과 자주 묻는 질문을 바탕으로 답변 초안을 쓰는 지원 봇, 그리고 데이터 창고를 API로 조회하고 계약서·정책 문서 질의응답을 하는 내부 도우미다. 안전 규칙을 강하게 잡으면 정상적인 업무 요청까지 거절해 직원들이 일을 못 한다고 느낀다. 반대로 규칙을 느슨하게 하면 보안팀은 내부 정보 유출을 걱정하고, 법무팀은 고객에게 이상한 답변이 나갈 위험을 걱정한다. 지금까지 시도한 방법은 안전과 말투에 대한 프롬프트 지시, 역할별 허용 도구와 표 제한, 명백한 문제를 걸러내는 정규식 필터, 더 엄격한 검토와 거절 기준이다. 실제로는 지원 봇이 일반적인 환불·해지 문의까지 거절하고, 분석 도우미는 너무 많은 데이터 열이 막혀 문맥을 잃으며, 추가 검사가 지연 시간을 늘려 사람들이 기존 방식으로 돌아가고 있다.
AI 에이전트를 만들 때 기본 반복 구조는 보통 짧고 단순해서 문제의 핵심이 아닌 경우가 많다. 실제로는 에이전트가 외부 세상과 만나는 도구 계층에서 오류가 먼저 생긴다. 도구 설명이 한 줄뿐이면 모델은 어떤 입력을 넣어야 하는지, 예외 상황은 무엇인지, 결과가 어떤 형태로 돌아오는지 알기 어렵다. Anthropic의 도구 사용 안내도 도구 성능에서 자세한 설명이 매우 중요하며, 도구마다 여러 문장으로 설명하라고 권한다. 비슷한 도구가 너무 많이 나뉘어 있어도 문제가 된다. 같은 대상을 만들기, 고치기, 지우기로 따로 나누면 모델은 매번 어떤 도구를 골라야 할지 헷갈릴 수 있다. 관련 기능을 더 적은 수의 잘 이름 붙인 도구로 묶고, 명확한 작업 매개변수를 주면 잘못된 도구 선택을 줄일 수 있다. 도구 결과가 큰 원본 덩어리로 돌아오면 토큰을 많이 쓰고, 모델이 필요한 정보만 골라 쓰기 어려워진다.
COMPASS Skills는 AI 코딩 에이전트가 긴 작업을 더 잘 이어가도록 돕는 네 가지 로컬 스킬 묶음이다. 핵심 기능은 모호한 작업을 먼저 확인하기, 저장소 안에 작업 진행 상황을 남기기, 새 대화로 넘길 요약 프롬프트 만들기, 사용자의 협업 선호를 로컬 프로필로 관리하기다. 작업 기록은 보통 프로젝트 안의 `.agent-workbench/task-forest/`에 저장되고, 사용자 프로필은 `.compass-skills/user-profiles/v1`에 저장된다. Claude Code와 Codex에서 쓸 수 있고, `npx skills add dongshuyan/compass-skills --skill '*' -a codex -a claude-code` 같은 명령으로 설치할 수 있다. 모든 실행 데이터는 로컬에 두는 방식을 내세우며, 브라우저 쿠키나 토큰, 개인 키 같은 민감한 정보는 읽거나 저장하지 않는다고 밝힌다. 다만 사용자 프로필은 암호화되지 않은 일반 텍스트라서 비밀번호, 토큰, 인증 코드, 민감한 개인정보를 넣으면 안 된다. 공개 설치 경로는 `skills@1.5.11`로 목록 조회, Claude Code 설치, handoff 스모크 테스트까지 검증되었다.
Ollama로 돌리는 오픈소스 모델을 써서 검색 증강 생성(RAG) 앱을 만든 상태다. 언어 모델은 granite-8b, 임베딩 모델은 BGE-M3, 벡터 데이터베이스는 qdrant를 사용했다. 모든 구성 요소와 qdrant 저장 데이터는 개인 컴퓨터 안에 있다. 실제 배포를 하려면 어떤 기술 조합이 적절한지, 다른 사람이 서비스를 쓸 때 내 컴퓨터의 모델이 어떻게 응답을 내보내는지, 모델을 Hugging Face 같은 곳에 올려 별도 엔드포인트를 만들어야 하는지 혼란이 있다. 특히 다른 사용자의 요청 때문에 개인 GPU가 과하게 쓰이는 상황을 피하고 싶어 한다.
RAG 시스템은 답변이 보기 좋고 문서 내용을 조금 담고 있으며 큰 거짓말이 없다고 해서 제대로 작동한다고 볼 수 없다. 실제 사용자는 예상 밖의 방식으로 질문하기 때문에, 단순히 답변이 맞아 보이는지 확인하는 방식은 쉽게 무너진다. 실패 지점은 여러 곳에 있다. 필요한 문서 조각을 아예 못 찾을 수도 있고, 찾았더라도 잡음이 많은 다른 조각에 묻혀 모델이 엉뚱한 부분을 사용할 수도 있다. 검색은 제대로 됐지만 모델이 원문에 없는 의미를 조금 덧붙일 수도 있다. 답은 맞아도 사용자가 정말 묻고 싶은 것을 놓치면 쓸모가 떨어진다. 오래된 문서, 중복 문서, 서로 조금씩 다른 내부 문서처럼 지식 저장소 자체가 지저분하면, 모델이 자료에 근거해 답해도 결과가 나쁠 수 있다.
ScholarLoop는 여러 AI 에이전트가 논문 조사, 아이디어 제안, 실험, 결과 반성, 글 작성과 검토를 차례로 수행하는 오픈소스 연구 자동화 도구다. 핵심은 큰 실험을 바로 돌리지 않고, 여러 아이디어를 먼저 싼 방식으로 빠르게 거른 뒤 살아남은 아이디어만 더 비싼 검증 단계로 올리는 구조다. 예산 한도, 반복 횟수, 성과가 더 이상 좋아지지 않는 상태를 기준으로 스스로 멈출 수 있다. 각 에이전트의 예측과 판단은 실제 측정값과 비교되어 다음 라운드에서 더 믿을 에이전트를 고르는 데 쓰인다. 실험 점수는 고정된 기준으로 재고, 모델이 점수를 속이거나 결과 숫자를 꾸며내지 못하게 코드 차원의 제한을 둔다. 현재 예시는 숫자 분류와 당뇨 회귀 실험을 포함하며, 실제 Claude Opus 4.8 실행에서 기준 성능을 조금 넘긴 결과와 약 0.45달러, 0.77달러 수준의 실행 비용을 공개했다. 전체 루프는 테스트 108개가 있고, 빠른 데모는 API 키나 GPU 없이 정해진 가짜 LLM으로 실행할 수 있다.
사내 업무 자료를 바탕으로 AI 도우미를 만들 때, AI가 만든 요약을 지식 저장소에 계속 저장할지 아니면 질문이 들어올 때마다 새로 요약할지가 핵심 설계 문제가 된다. 미리 요약해서 저장하면 사용자가 질문할 때 읽어야 할 내용이 줄어 응답 비용이 낮아지고 속도도 빨라질 수 있다. 하지만 요약이 틀렸거나 시간이 지나 낡으면, 그 내용이 사실처럼 저장되어 계속 믿어질 위험이 있다. 원문과의 연결이 약해지면 잘못된 정보가 쌓이고, 나중에 어디서 나온 말인지 확인하기도 어렵다. 반대로 원본 자료를 그대로 저장하고 질문할 때마다 AI가 그때그때 요약하게 하면 답변이 원문에 더 잘 근거하고, 출처를 붙이기 쉬우며, 요약은 답변 후 버릴 수 있다. 다만 이 방식은 매 질문마다 AI가 자료를 다시 읽어야 해서 지연 시간과 비용이 늘어난다. 메모리처럼 오래 남는 정보에는 AI가 쓴 요약을 사실로 저장하지 않고, 답변을 만들 때만 출처와 함께 요약하는 쪽으로 기울고 있다.
Aegis는 거대 언어 모델로 실제 서비스를 만들 때 입력과 출력을 중간에서 검사하는 자체 운영형 오픈소스 프록시다. 기존 OpenAI-style 클라이언트에서 BASE_URL만 Aegis 주소로 바꾸면 붙일 수 있게 설계됐다. 입력 단계에서는 모델에 보내기 전에 10단계 검사 흐름을 돌린다. 글자 모양을 표준 ASCII로 맞추고, 보이지 않는 문자를 지우며, 프롬프트나 검색으로 가져온 문맥 안에 PEM 키, API 토큰, Log4Shell 같은 공격 문자열이 있는지 찾는다. GCG와 AutoDAN처럼 모델을 속이기 위해 붙이는 적대적 꼬리 문구도 겨냥한다. 출력 단계에서는 답변을 사용자에게 먼저 보낸 뒤 비동기로 분석해, 사용자가 기다리는 시간을 늘리지 않으면서 환각이나 큰 방향 이탈을 살피는 구조다. 라이선스는 AGPLv3다.
rule-agent는 규칙 엔진의 ‘마지막 단계’를 더 쉽게 만들려는 작은 실험입니다. 핵심 방향은 규칙을 복잡한 설정이나 코드보다 사람이 쓰는 언어에 더 가깝게 다루게 하는 것입니다. 공개된 내용은 짧아서 구체적인 구현 방식, 성능 수치, 지원 모델, 비용 절감 효과, 저장소 주소는 확인되지 않습니다.
완성에 가깝다고 생각한 AI 에이전트를 Badgr Agent Readiness Test로 점검했더니 100점 만점에 68점이 나왔다. 이 테스트는 30개 항목으로 에이전트의 출시 준비 상태를 확인한다. 점검 항목에는 프롬프트 주입, 개인정보 유출, 위험한 답변, 이상한 도구 동작, 지나치게 확신하는 답변이 포함된다. 68점은 완전히 실패한 수준은 아니지만, 실제 사용자에게 바로 공개하기에는 부족한 결과로 받아들여졌다. 핵심 질문은 AI 에이전트를 배포하기 전에 어떤 방식으로 안전성과 신뢰성을 시험해야 하느냐다.
Architect는 생성된 코드보다 소프트웨어 설계를 기준점으로 삼으려는 오픈소스 작업물이다. 높은 수준의 DSL로 도메인 객체, 서비스와 의존 관계, 응용프로그램 인터페이스, 이벤트 처리, 배포와 인프라, 버전과 이전 작업을 적는다. 이 내용을 파싱해 서로 연결된 모델로 만들고, 그 모델을 바탕으로 코드, 테스트, Docker 파일, Docker Compose 설정, 배포용 문서 등을 만들 수 있게 하려는 구조다. 현재 파서와 모델 해석기는 구현되어 있다. 다음 단계는 생성 계층과 프로젝트 잠금 파일이며, 이 파일은 프로젝트 구조, 의존성 버전, 인프라 버전, 생성된 결과물, 작업 의존 관계인 DAG를 기록한다. 목표는 LLM이 소스 파일을 직접 고치는 대신 작업과 계획을 다루는 AI 중심 개발 흐름이다. 로컬에서 Qwen Coder를 실험 중이며, 매번 LLM에게 전체 생성을 맡기지 않고 코드베이스 지식을 유지해 코드 생성을 더 예측 가능하게 만들려 한다. 벡터 데이터베이스와 임베딩은 비슷한 코드를 찾아 재사용과 리팩터링에 쓰는 방향으로 제안되어 있다.
코딩 에이전트가 실패하는 이유가 항상 모델의 성능 부족은 아닐 수 있다. 사람이 개발할 때는 회의 내용, 메신저 기록, 제품 감각, 팀의 일하는 방식을 바탕으로 빈칸을 채운다. 코딩 에이전트는 이런 배경을 거의 모른다. 작업 지시가 흐릿해도 멈추지 않고 추측해서 코드를 만들며, 결과가 그럴듯해 보일 때가 많다. 그래서 필요한 능력은 단순한 프롬프트 작성이 아니라 더 좋은 작업 단위를 만드는 일일 수 있다. 좋은 작업 단위에는 해결할 문제, 바꾸면 안 되는 것, 손댈 파일이나 영역의 범위, 중요한 예외 상황, 완료 기준, 코드를 고치기 전에 에이전트가 물어봐야 할 질문이 들어가야 한다.
AI Hacker Newsletter 39호는 Hacker News에서 나온 AI 관련 링크와 토론을 모은 주간 목록이다. 이번 목록에는 Claude Code가 요청에 숨은 표시를 남긴다는 이야기, 더 좋은 모델이 더 나쁜 도구 경험으로 이어질 수 있다는 주장, 코딩을 배우는 일이 여전히 가치 있다는 글이 포함됐다. 로컬 AI를 실행할 권리를 지켜야 한다는 주제도 들어 있다. 마크 저커버그가 AI 에이전트 개발 속도가 예상보다 느리다고 말했다는 링크도 포함됐다. 전체 뉴스레터에는 이런 링크가 30개 넘게 담겨 있다.
Tenstorrent는 인공지능 연산에서 NVIDIA 중심 구조를 줄일 수 있는 공개형 대안으로 제시된다. 핵심 주장은 한 회사의 하드웨어와 소프트웨어 생태계에 너무 의존하면 선택지가 줄고 비용 압박도 커질 수 있다는 점이다. 다만 제공된 내용에는 실제 성능 수치, 가격 비교, 인공지능 에이전트 구축 방법, 토큰 절감 방법은 포함되어 있지 않다.
QA 테스트 업무에 쓰기 위한 사내 인공지능 챗봇을 만들려는 수요가 있습니다. 목표는 15기가바이트가 넘는 회사 문서에서 필요한 답을 빠르게 찾는 것입니다. 대상 문서는 릴리스 노트, 기능 설명서, 이슈 기록, 테스트 케이스입니다. 요구 조건은 보안이 지켜지는 내부용 챗봇이며, 가능하면 로컬 또는 오프라인 환경에서 돌아가는 방식입니다. 핵심 고민은 코딩을 거의 모르는 사람도 현실적으로 만들 수 있는지, 어떤 순서로 진행해야 하는지, AnythingLLM과 Ollama 조합이나 로컬 LangChain 같은 도구 중 무엇이 맞는지입니다.
자동차 판매 사진으로 폭스바겐 골프 세대처럼 아주 비슷한 차종을 구분하는 작은 실험에서 모델별 차이가 크게 났다. 학습 데이터 175장과 시험 데이터 132장을 쓰고, 이미 학습된 이미지 인코더를 그대로 둔 뒤 임베딩을 만들고 가중 k-NN으로 분류했다. SigLIP2 SO400M은 약 92% 정확도를 보였고, CLIP ViT-L은 약 59%, DINOv2 Giant는 약 41%에 그쳤다. 임베딩을 L2 정규화했기 때문에 코사인 거리와 유클리드 거리는 같은 순위를 냈고, 거리 계산 방식만 바꿔도 DINOv2 결과는 달라지지 않았다. SigLIP은 이미지와 텍스트를 맞춰 배우는 대조 학습 방식이라 비슷한 이미지를 찾는 용도에 잘 맞을 수 있다. DINOv2는 자기지도 학습 모델이라 그대로 k-NN에 쓰기보다 별도 분류기를 붙여 학습해야 더 잘 맞을 가능성이 있다.