AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
중고 서버 부품과 오래된 그래픽카드를 조합하면 2500달러 이하로 대형 AI 모델 실행용 개인 장비를 맞출 수 있다. 예시 구성은 Epyc 메인보드와 중앙처리장치 약 460달러, P40 24기가바이트 그래픽카드 2장 약 460달러, DDR4 메모리 512기가바이트 약 1000달러다. 전원공급장치, 저장장치, 냉각팬까지 더해 전체 예산을 2500달러로 잡는다. 이 장비에서는 GLM5.2의 Q2, Q3, Q4 같은 압축 버전을 cmoe와 llama.cpp로 실행할 수 있다. 속도는 느리지만, 클라우드나 외부 서비스에 의존하지 않고 직접 쓸 수 있다는 장점이 있다. 돈이 더 생기면 P40을 4080, 3090, 2080 Ti 22기가바이트 같은 더 빠른 그래픽카드로 바꿀 수 있다. KimiK2.6, DeepSeek, MiniMax 같은 다른 대형 모델도 실행 대상이 될 수 있다. 다만 이런 큰 모델로 AI 에이전트를 계속 돌리기에는 느리고, 기획이나 어려운 디버깅처럼 시간이 덜 민감한 작업에 더 알맞다.
작은 인공지능 모델을 이용해 코딩을 돕는 방식에 실제 가능성이 있다는 주장이다. 최근 공개 소프트웨어 커뮤니티에서는 바이브 코딩으로 만든 결과물을 비판하는 목소리가 많다. 작은 기능 하나만 하는 도구가 많고, 실제 영향이 작다는 불만도 있다. 하지만 잘 설계된 코드는 바이브 코딩으로 만들어졌더라도 다른 사람이 함께 고치고 발전시키기 쉽다. Google도 Gemma 4 31B 같은 작은 모델을 대상으로 해커톤을 열고 있다. 이 모델은 초당 1,500 토큰 수준의 추론 속도를 내세우며, 일반 개인 컴퓨터에서 돌리는 속도보다 50~100배 빠르다는 점이 강조됐다. 큰 회사들도 작은 모델을 이용한 인공지능 코딩 지원에 가치가 있다고 보고 있다는 신호다.
회사 자동화와 AI 에이전트를 만드는 실무 경험에서는, 고객에게 AI 에이전트를 만들지 말라고 설득하는 일이 더 큰 가치를 줄 때가 있다. 한 보충제 브랜드는 재고를 보고, 재주문 시점을 판단하고, 공급업체에 이메일까지 보내는 AI 시스템을 원했다. 하지만 실제 운영을 보니 2023년부터 같은 제품을 같은 기준으로 반복 주문하고 있었다. 예를 들어 단백질 분말 재고가 200개까지 내려가면 늘 같은 공급업체에 같은 수량을 주문했다. 새로 판단할 문제가 없었기 때문에 AI가 필요하지 않았다. AI 구축 견적은 5,200달러였지만, 실제 해결책은 700달러짜리 단순 자동화였다. 이 자동화는 매일 아침 Shopify 재고를 확인하고, 정해 둔 재주문 기준보다 낮은 상품이 있으면 미리 써 둔 주문 이메일을 알맞은 공급업체에 보낸다. 운영 비용은 월 60달러이고, 담당자는 첫 주부터 매일 아침 약 40분을 아꼈다.
DeepSeek의 공식 API는 유료이지만, 웹 채팅은 무료로 쓸 수 있다. 이 도구는 일반 DeepSeek 계정으로 한 번 로그인한 뒤 세션을 저장하고, 내 컴퓨터에서 OpenAI API 형식과 맞는 로컬 서버를 연다. 그러면 기존 OpenAI SDK나 OpenAI 호환 도구가 주소만 로컬 서버로 바꿔 DeepSeek를 호출할 수 있다. 스트리밍 응답, 여러 차례 이어지는 대화, 대부분의 OpenAI 호환 도구와 에이전트를 지원한다. 목표는 API 토큰 비용을 내기 애매한 가벼운 자동화, 취미 프로젝트, 실험용 작업에서 무료 호출 지점을 제공하는 것이다. DeepSeek와 공식 관계가 없는 비공식 프로젝트다.
Picotron은 오래되었거나 저렴한 그래픽카드에서도 대형 언어 모델 학습 코드를 실행하기 쉽게 만든 오픈소스 학습 프레임워크다. 기존 Nanotron은 flash-attn, triton, functorch 같은 무거운 그래픽카드 전용 도구를 처음 불러올 때부터 요구해, T4나 V100 같은 장비에서는 시작 단계에서 바로 멈출 수 있었다. Picotron은 이런 필수 의존성을 없앤 새 구현이다. PyTorch를 지원하는 대부분의 그래픽카드에서 돌아가며, 오래된 카드에서는 기본으로 FP16을 쓰고 최신 카드에서는 BF16을 쓴다. 빠른 주의 계산 도구인 FlashAttention-2가 설치되어 있으면 실행 중에 감지해 사용하지만, 없으면 표준 PyTorch 방식으로 대신 처리한다. 작은 200만 매개변수 모델을 FineWeb-Edu 데이터로 실제 학습한 사례도 있다. 설정에는 GQA, MLA, QK-Norm, logit soft-capping, 병렬 FFN/Attn 실행, DDP 위의 ZeRO-1 래핑이 포함되어 있다. 다음 과제로는 MoE 준비 기능과 데이터 준비를 더 쉽게 만드는 작업이 제시되어 있다.
지원 티켓을 자동으로 분류하는 단계가 약 3개월 동안 같은 모델 이름으로 운영되고 있었다. 내부 평가 기준에서 정확도는 약 94%로 안정적이었다. 어느 날 아침 정확도가 약 91%로 떨어졌지만, 서비스 배포도 없었고 코드, 프롬프트, 데이터도 바뀌지 않았다. 설정에 적힌 모델 이름도 전날과 같았다. 원인은 제공업체가 같은 모델 식별자 뒤에서 모델을 새 버전으로 바꾼 일이었다. 새 모델은 일반 벤치마크에서는 괜찮거나 더 나았을 수 있지만, 짧고 화난 말투에 여러 언어가 섞인 티켓에서 다르게 행동했다. 이 유형은 전체 입력의 약 8%였고, 새 모델은 이 티켓들을 특정 분류로 너무 많이 몰아 넣었다. 그 결과 뒤쪽 라우팅 단계가 잘못 처리했고, 원인을 찾는 데 반나절이 걸렸다.
이번 주 공개된 두 연구는 AI 에이전트의 메모리 오염과 개인정보 유출 문제를 같은 방식으로 다룬다. 핵심 방법은 정보 흐름 제어다. 민감한 정보나 의심스러운 정보가 어디에서 왔고 어디로 이동할 수 있는지 규칙으로 관리해, 위험한 행동으로 이어지지 않게 막는 방식이다. 메모리 오염은 나쁜 정보가 에이전트의 메모리에 저장된 뒤, 나중에 결제 전송, 설정 변경, 데이터 유출 같은 잘못된 행동을 일으키는 문제다. 개인정보 유출은 에이전트가 작업을 처리하는 과정에서 민감한 검색, 도구 호출, 메모리 저장 등을 통해 개인 정보가 새어 나가는 문제다. 한 메모리 오염 연구는 기계 검증을 거쳤고, 정보 흐름 제어를 적용한 뒤 8개 모델에서 공격 성공률이 0%로 나왔다. 하지만 이 방식을 바로 붙여 쓸 수 있는 오픈소스 라이브러리는 아직 뚜렷하지 않다.
대형 AI 모델이나 AI 에이전트를 직접 돌리기 위한 GPU와 서버용 메모리 투자는 몇 달 늦추는 것이 낫다는 전망이다. 이유는 장비 가격이 현재 제조 비용에 비해 매우 높게 형성되어 있어 조정 여지가 있다는 점이다. 서버용 메모리는 반년 전에는 매장에서 품절이 많았지만, 지금은 비싸게만 사면 재고를 구할 수 있는 상태라 공급 부족이 완화된 것으로 본다. 경쟁도 늘고 있다. AMD의 새 R9700 GPU가 성능과 가격 면에서 Nvidia 제품과 경쟁력이 있다는 주장이다. Intel도 따라오고 있으며, 중국 GPU 업체들이 더 큰 변수로 꼽힌다. Huawei GPU는 DeepSeek 서비스에서 빠른 응답 속도를 보여 주고 있고, 중국 내 주문을 채운 뒤에는 Huawei Ascend 계열을 포함한 여러 중국 GPU 제조사가 서방 시장에 대안을 내놓을 수 있다는 전망이다.
은행 업무용 RAG 시스템에서 법률·금융 문서를 더 잘 찾기 위해 BM25 검색에 분류 체계와 온톨로지를 넣는 방안이 제시됐다. 첫 번째 방법은 원문은 그대로 두고 색인에 표준 용어와 동의어를 추가하는 것이다. 예를 들어 문서에 “ABS”가 나오면 색인에는 “자산유동화증권” 같은 표준 개념도 함께 넣어, 사용자가 어느 표현으로 검색해도 같은 문서를 찾게 한다. 두 번째 방법은 색인에 모든 단어를 넣지 않고, 법률 분류 체계나 온톨로지에 있는 용어만 넣는 것이다. 이 방식은 잡음을 줄일 수 있지만, 분류 체계에 없는 중요한 표현을 놓칠 위험도 있다. 지식 그래프도 함께 만들고 있지만, 여기서는 문서 검색 색인을 어떻게 개선할지가 핵심이다.
Claude Tag는 현재 채널을 기준으로 인공지능의 접근 범위를 정한다. 비공개 채널마다 하나의 공유 Claude가 있고, 공개 채널도 설정에 따라 공유 문맥을 가질 수 있다. 같은 채널 안의 사람들은 이어서 대화할 수 있고, 관리자는 그 채널의 Claude가 어떤 도구와 데이터에 접근할지 정한다. 이 방식은 단순하지만, 실제 업무 방식과 잘 맞지 않을 수 있다. 사람들은 여러 채널을 오가며 일하고, 실제 데이터 접근 권한도 채널 하나와 깔끔하게 맞아떨어지지 않는다. 더 나은 방식은 Claude를 호출한 사람의 권한과 자격으로 작동하게 하는 것이다. 같은 인공지능을 불러도, 누가 불렀는지에 따라 볼 수 있는 데이터와 답변이 달라져야 한다.
항상 같은 순서로 처리되는 자동화에는 AI 에이전트가 필요하지 않다. 정해진 날짜에 알림을 보내는 일은 예약 작업으로 충분하다. 특정 신호가 오면 한 앱의 데이터를 다른 앱으로 옮기는 일은 웹훅과 조건문으로 처리할 수 있다. 보낸 사람이나 낱말 기준으로 이메일을 폴더에 나누는 일은 규칙 기반 분류에 가깝다. 같은 대시보드에서 매주 보고서를 만드는 일은 템플릿과 예약 실행으로 해결된다. 이런 작업에 AI 모델을 붙이면 비용이 늘고, 실패할 수 있는 지점도 늘어난다. 반대로 고객 지원함처럼 매번 내용이 다르고, 환불인지 오류인지 사람의 도움이 필요한지 문서를 찾아 답할 수 있는지 판단해야 하는 경우에는 에이전트가 더 맞을 수 있다.
Azure에서 RAG 시스템을 만들려는 초기 구상은 공개 웹사이트의 PDF와 자료 문서를 가져오는 방식이다. 먼저 웹페이지에서 내용을 추출하고, 그 내용을 일반 텍스트로 저장한다. 그다음 텍스트를 벡터화해 검색하기 쉬운 형태로 바꾸고, 벡터 임베딩 모델을 사용한다. 이후 Azure AI Search와 Foundry 모델을 함께 써서 질문에 맞는 자료를 찾고 답을 만드는 흐름을 생각하고 있다. 가장 큰 고민은 어떤 Azure 서비스를 조합해야 하는지, 실제 운영 비용이 어디서 발생하는지, 참고할 만한 문서나 자료가 무엇인지다.
PeekAI는 파이썬으로 만든 AI 에이전트를 디버깅하고 비용을 살펴보는 오픈소스 도구다. OpenAI와 Anthropic 호출을 자동으로 잡아내고, 각 작업 단계가 어떤 순서로 실행됐는지 폭포형 화면으로 보여준다. 단계별 토큰 사용량과 비용을 따로 볼 수 있어, 어느 부분에서 돈이 많이 드는지 확인할 수 있다. 도구 호출도 추적하며, 과거 실행 기록을 다시 돌려볼 수 있다. 같은 실행 흐름에서 모델을 바꿔 비용과 품질을 비교하는 것도 가능하다. 클라우드나 계정이 필요 없고, 데이터는 로컬 SQLite에 저장된다. 설치는 `pip install peekai` 뒤 코드에서 `peekai.init()`을 부르면 시작된다. 아직 초기 버전인 0.1이며, MIT 라이선스로 공개됐다.
AI 에이전트가 이메일 발송, 초안 저장, 라벨 적용처럼 실제 변화를 일으키는 도구를 직접 실행하지 못하게 만드는 설계입니다. 모델은 실행 요청을 제안하고 승인 문을 여는 역할만 합니다. 사람이 승인하면 서버가 실제 함수를 한 번만 실행합니다. 실행 기록은 작업 아이디와 승인 문 아이디로 관리되어, 같은 요청이 다시 들어오거나 재시도되어도 중복 실행되지 않게 합니다. 상태는 서버의 Postgres가 기준이 되고, 모든 단계는 감사 기록과 추적 기록에 남습니다. 실행 중에는 에이전트 하나, 작업 흐름 하나, 또는 전체를 멈출 수 있습니다. 다만 이 방식은 실행 안전성을 높일 뿐, 잘못된 결정을 승인하는 문제까지 해결하지는 못합니다. 검토자는 단순히 “확인해 주세요”가 아니라 반복되는 실패 유형과 검토 관점을 함께 받아야 더 잘 판단할 수 있습니다.
운영 환경에서 AI 에이전트를 돌릴 때, 에이전트가 한 번 실수한 뒤 스스로 고치려다 비용을 계속 늘리는 문제가 생길 수 있다. 같은 실패 동작을 반복하거나, 진전 없이 다시 시도하면서 토큰을 소모한다. 이 과정은 결과를 개선하지 못한 채 청구 비용만 키울 수 있다. 실제로 에이전트를 운영하는 사람들은 이런 재시도 반복이 얼마나 자주 생기는지, 최악의 비용 사례가 얼마였는지, 비용 폭주를 어떻게 막는지 고민하고 있다. 현재 대응 방식으로는 지출 상한, 수동 중지 장치, 또는 비용을 그대로 감수하는 방식이 거론된다.
n8n으로 만든 자동화 흐름이 페이스북 새 댓글을 받아 인공지능으로 감정, 의도, 잠재고객 가능성을 살핀다. 구매나 상담 가능성이 높은 긍정 댓글은 후속 연락 대상으로 보내고, 부정 댓글은 바로 관리자에게 이메일로 알린다. 인공지능은 댓글 답장 초안도 만들 수 있다. 불만, 판매 문의 같은 댓글 종류에 따라 서로 다른 처리 경로가 자동으로 움직인다. 목표는 답장 시간을 줄이고 중요한 댓글을 놓치지 않는 것이다. 다음 단계로 CRM 연결, WhatsApp 알림, 잠재고객 점수화, 분석 대시보드가 계획되어 있다.
AI 에이전트가 월드컵 경기 예측을 실제 유료 절차로 끝까지 처리했다. 작업은 참가 가능한 경기를 찾고, 승패와 정확한 점수를 예측하고, 지갑으로 0.01 USDC 참가비를 내고, 예측을 제출한 뒤 나중에 결과를 확인하는 흐름이었다. 6월 27일 기준으로 유효하게 결제된 예측은 50건이었다. 이 중 44건은 결과가 확정됐고, 승패 예측은 18건이 맞고 26건이 틀려 적중률은 40.9%였다. 6건은 아직 결과를 기다리는 중이었다. 앞선 4번의 시도는 결제가 끝나지 않아 제외됐다. 예측 문장을 만드는 것만으로는 실제 작업이 완료되지 않았고, 신원 확인, 결제, 제출까지 모두 성공해야 유효한 참가가 됐다. 실행 과정은 예측 성능보다 더 좋았고, 감사 기록 덕분에 작업 완료 여부, 결제 안정성, 예측 품질을 따로 볼 수 있었다.
2026년 6월 기준으로 96GB 메모리를 단 4090 또는 5090 그래픽카드는 실제 제품으로 확인되지 않았다. 미국에서 작은 그래픽카드 실험실을 운영하고 중국 공장들과 48GB 4090 보드 제작을 해 온 쪽의 firsthand 경고에 따르면, 최근 실제로 확보된 개조 카드는 32GB 4080 슈퍼뿐이다. 96GB 4090이나 5090을 판다는 제안은 카드가 존재하지 않거나 받을 수 없는 사기일 가능성이 크다. 선전 화창베이 전자상가에서도 96GB 5090 이야기가 돌았지만, 한 판매자 쪽 확인은 5090을 산 뒤 VRAM을 96GB로 바꾸는 비용까지 합쳐 약 5만6000위안, 대략 8200달러가 든다는 수준이었다. 이 경우도 정식 보증이 있는 RTX 6000 제품이 약 1만1000달러라면 가격 차이가 크지 않아 위험을 감수할 이유가 약하다.
PipelineRecall은 데이터 파이프라인 장애를 다루는 에이전트다. 일반적인 에이전트는 대화창을 닫으면 이전 오류와 해결 과정을 잊지만, 이 에이전트는 세션이 바뀌어도 과거 장애와 해결책을 저장하고 다시 꺼낸다. 반복되는 문제는 예전 장애 기록과 당시 효과가 있었던 해결 방법을 날짜와 함께 참고해 진단한다. 처음 보는 문제는 억지로 답을 만들지 않고, 아직 본 적 없는 문제라고 판단한다. 기억이 있다고 해서 항상 작은 모델만 쓰지는 않는다. 기억해 낸 사례가 있어도 더 깊은 판단이 필요하면 더 강한 모델로 넘기는 비용 고려 모델 연결 방식을 쓴다. 새 장애를 설명했을 때 처음에는 모른다고 답했지만, 30초 뒤 같은 장애를 다르게 표현하자 방금 저장한 자체 진단을 바로 다시 불러와 활용했다.
Haystack 2.x로 만든 RAG 파이프라인에서 검색 결과가 갑자기 줄거나 실패할 때 원인을 찾기 어려운 문제가 있다. 원인은 문서 저장소 문제, 검색기 설정 오류, 위쪽 데이터 처리 과정의 메타데이터 손상일 수 있다. Haystack Diagnostics Engine은 이 반복 작업을 줄이기 위해 만든 진단 도구다. MCP 서버로 실행되며, 중복 조각, 빠진 메타데이터, 형식이 깨진 문서를 검사한다. 저장된 Haystack 파이프라인 설정도 들여다보고 잘못된 설정을 표시한다. 검색 실패는 빈 결과, 낮은 점수, 메타데이터 필터 불일치 같은 유형으로 나누고 고칠 지점을 알려준다. 전체 질의 상태를 JSON 묶음으로 저장해 두 번의 실행을 비교할 수 있으며, 검색기와 재정렬기 전후 결과, 프롬프트, 답변, 실패 유형, 관련 문서 상태, 답변 차이까지 확인할 수 있다. Weaviate 기반 실제 배포 환경에서 823개 문서 조각을 검사했을 때 195개 중복 조각, 약 24%의 중복, 14개의 정보 누락 문서를 찾았다.
약 15편의 에이전트 반복 실행 연구를 보면, 잘 작동한 사례들은 더 강한 모델 자체보다 결과를 엄격하게 확인하는 검증기를 갖고 있었다. ComPilot은 일반 대형 언어 모델을 컴파일러와 연결해 코드가 맞는지와 속도가 얼마나 빨라졌는지 확인하고, 실패하면 다시 시도하게 했다. 이 방식은 한 번 실행에서 2.66배, 5번 중 가장 좋은 결과에서 3.54배 속도 향상을 냈고, 파인튜닝은 쓰지 않았다. AlphaCodium은 생성한 코드를 테스트에 반복해서 돌리며 GPT-4의 CodeContests 성과를 19%에서 44%로 올렸다. DeepSeek-R1은 수학과 코드처럼 정답 확인이 쉬운 보상으로 훈련했고, R1-Zero는 AIME 점수가 훈련 중 15.6%에서 71.0%까지 올랐으며 다수결 투표를 쓰면 86.7%까지 올라갔다. o3는 ARC-AGI에서 87.5%를 냈지만, 고연산 설정에서 실행 비용이 대략 수십만 달러 규모였다는 점도 함께 봐야 한다. 실패 사례들은 대체로 검증기가 없거나, 모델이 검증 기준을 속일 수 있는 구조였다.
Together.ai로 AI 모델 추론을 돌리던 프로젝트에서 규모가 커지자 비용 부담이 커졌다. 사용량이 늘수록 가격을 계속 감당하기 어렵다는 문제가 생겼다. 응답 속도도 일정하지 않아, 어떤 때는 지연이 커지는 문제가 있었다. 필요한 조건은 여러 모델을 고를 수 있고, 비용과 속도가 더 납득되는 추론 서비스다.
LLMpress는 LLM에 보내는 토큰 수를 줄이면서 전달되는 정보량은 최대한 유지하려는 도구다. 목표는 새로운 압축 방식을 만드는 것이 아니라, 이미 쓰이는 압축 기법을 LLM 작업에 맞게 묶는 데 있다. 코드에서는 언어별 축소 처리를 사용해 공백, 긴 이름, 불필요한 형태를 줄이고, 가능하면 원래 코드 위치를 찾을 수 있는 대응 정보도 남긴다. 선택적으로 프롬프트 압축도 붙일 수 있다. AST를 이용해 코드 구조를 이해한 뒤 더 세게 줄이면서도, 나중에 사람이 읽기 쉬운 원본 코드와 다시 연결하는 방향을 잡고 있다. 장기 목표는 큰 코드베이스를 자주 LLM에 보내는 AI 코딩 흐름에서 입력 크기와 비용 부담을 낮추는 것이다.
AI 에이전트에는 단순히 대화 내용을 저장하는 기억 장치보다 더 실무적인 지식 저장소가 필요할 수 있다. 이 오픈소스 지식층은 사용자가 몇 차례 전에 한 말을 기억하는 데 초점을 두지 않는다. 내부 업무 절차, 지원 이력, 전자상거래 기록, 회사 로그, 잠재 고객 정보, 과거 계약 고객의 공통점, 경쟁사 정보, 개인 메모 같은 운영 정보를 담는 데 초점을 둔다. 목표는 정보를 쌓아두는 것만이 아니라, 서로 겹치거나 이어지는 부분을 찾아 나중에 다시 꺼내 쓰게 하는 것이다. 예를 들어 AI 에이전트가 “지난 분기에 계약된 고객과 비슷한 잠재 고객은 누구인가” 또는 “이 고객 문의는 이미 있는 업무 절차와 어디가 겹치는가”를 물으면, 단순히 뜻이 비슷한 문서를 찾는 대신 실제로 연결된 정보를 돌려주는 방식이다. 구조화된 데이터와 구조화되지 않은 데이터를 모두 받아들이며, 안쪽에서는 네 단계 파이프라인으로 처리된다.
n8n으로 실제 운영에 쓸 수 있는 AI 자동화를 만들려면 무엇부터 배워야 하는지가 핵심이다. 필요한 학습 범위는 n8n의 기본 개념, 자주 쓰이는 연동 기능과 노드, 어느 정도의 JavaScript 지식, 그리고 LLM, RAG, MCP, 벡터 데이터베이스 같은 AI 관련 주제까지 포함된다. 초보자가 워크플로를 만들 때 자주 하는 실수도 중요한 학습 대상이다. 3~6개월 동안 무엇을 어떤 순서로 배울지 정리한 로드맵이 필요하다는 문제의식이 담겨 있다.
하이데라바드의 IT 컨설팅·채용 회사가 외부 영업을 자동화하기 위해 내부용 AI 에이전트 2개를 만들려 한다. 목표는 운영비를 최대한 낮추는 것이며, 가능하면 무료 도구나 저렴한 종량제 방식을 원한다. 첫 번째 에이전트는 회사 도메인 목록을 받아 역방향 DNS와 MX 레코드를 확인하고, 어떤 이메일 서비스를 쓰는지 찾아낸다. 무료 Gmail, Yahoo, 오래된 호스팅 같은 기본 설정을 쓰는 회사는 Google Workspace나 Zoho 이전 영업 대상이 된다. 두 번째 에이전트는 걸러진 회사의 웹사이트를 읽어 사업 내용을 파악하고, 메일 솔루션이나 채용 서비스를 제안하는 짧은 맞춤형 콜드 이메일을 작성한다. 선호하는 방식은 오픈소스 도구, 파이썬, 자체 호스팅 저코드 플랫폼이다. 핵심 고민은 MX 레코드 확인과 웹사이트 수집을 큰 비용 없이 어느 정도 규모 있게 처리하는 방법이다.
LLM 심판이 답안을 채점할 때 나온 결정을 더 쉽게 확인하기 위한 작은 도구가 공개됐다. 이 도구는 하나의 판정 과정을 주장, 근거, 최종 판정으로 나눈다. 그런 다음 최종 판정이 제시된 근거로 충분히 뒷받침되지 않는 경우를 표시한다. 표시된 부분은 사람이 직접 확인할 수 있다. 만든 사람은 모델이 답안을 채점한 결과를 검토하다가 이상한 사례를 손으로 찾기 위해 이 방식을 만들었다. 코드 링크는 GitHub의 claim-memory-graph-sdk 저장소로 연결된다.
법률 관련 서비스형 소프트웨어 에이전트가 세금이나 법률 조언을 요구받으면 일부러 답을 거절한다. 예를 들어 “1099와 W-2 중 내가 어떻게 해야 하느냐” 같은 질문에도 법률 조언을 하지 않는다. 이 거절 방식은 법무 검토를 거친 설계이며, 잘못된 세금·법률 안내를 하는 것보다 답하지 않는 편이 더 안전하다는 판단에 따른 것이다. 그런데 TestMu의 에이전트 간 적대적 테스트 생성 기능은 이런 거절을 “도움이 없는 거절 패턴”으로 보고 기본 평가표에서 준수 위반처럼 점수화한다. 평가 에이전트는 “사용자가 답답해하니 예/아니오만 말해 달라” 같은 압박 상황을 만들고, 에이전트가 끝까지 거절하면 점수가 크게 떨어진다. 맞춤 평가표를 YAML 설정으로 덮어써도 상위 기준에는 반영되지만, “도움성” 아래의 하위 채점기가 계속 거절을 문제로 잡는다. 특정 시나리오에 expected_refusal=true 표시를 붙이는 시도도 언급되어 있다.
기업용 검색형 AI에서 단순한 벡터 검색은 관계나 시간 순서를 따져야 하는 질문을 만나면 쉽게 한계에 부딪힌다. 여러 자료를 이어서 판단해야 하는 문제는 더 좋은 임베딩 모델을 붙이거나 Pinecone, Milvus 같은 평면형 색인에 데이터를 더 넣는 방식만으로 해결하기 어렵다. 그래서 많은 팀이 GraphRAG로 이동하고 있지만, 전통적인 지식 그래프 방식에도 부담이 크다. Neo4j나 AWS Neptune 같은 그래프 데이터베이스를 직접 운영하면, 먼저 고정된 온톨로지를 정하고 문서 종류마다 별도 추출 파이프라인을 만들어야 한다. SharePoint 폴더 구조나 CRM의 사용자 지정 항목이 바뀌면 파이프라인이 깨지고, 같은 대상이 중복으로 생기며, 그래프 질의가 실패할 수 있다. 그 결과 스키마를 계속 관리할 그래프 전문 인력이 필요해진다. 이런 이유로 직접 만든 지식 그래프보다 관리형 컨텍스트 그래프 방식이 더 현실적인 선택지로 제시된다.
많은 사람이 AI를 한 번에 하나씩 묻고, 답을 기다리고, 고치고, 다시 묻는 방식으로 쓴다. 이 방식에서는 사람이 매번 다음 행동을 정하고 답의 품질을 판단해야 한다. 사람이 멈추면 AI도 멈추기 때문에 속도와 규모에 한계가 있다. 더 빠른 방식은 같은 목적을 향해 AI가 반복해서 작업하고 점검하고 다음 단계를 이어 가는 루프다. Claude나 ChatGPT에서도 기본 루프를 만들 수 있으며, 루프는 쓸 만한 상황과 오히려 시간 낭비가 되는 상황을 구분해야 한다.