AI 에이전트를 만들고 토큰·비용을 아끼는 데 도움이 되는 오픈소스 도구와 기법을 모읍니다.
머큐리-2(Mercury-2)는 대부분의 대형 언어 모델이 사용하는 순차적인 단어 생성 방식인 자기회귀 대신 디퓨전 기술을 기반으로 만든 AI 모델이다. 디퓨전 모델은 전체적인 큰 그림을 파악하는 데는 유리하지만, 세부적인 내용이나 복잡한 논리적 추론에는 약점을 보인다. 기존의 표준 모델들은 추론 능력이 매우 뛰어나기 때문에, 실제로는 굳이 이 방식을 쓰지 않아도 전체 문맥을 더 잘 이해하는 경우가 많다. 하지만 특정 목적에 맞춰진 AI 에이전트 시스템 내부의 특수한 작업에서는 머큐리-2가 유리할 가능성이 존재한다. 최고 수준의 추론 능력을 갖춘 소넷(Sonnet)이나 오푸스(Opus) 같은 상용 모델을 대신해 실제 환경에서 이 방식이 얼마나 효과적일지는 아직 검증이 필요한 상태다.
AI 관측 도구를 자체 클라우드에 배포할지 따져보는 주제다. AI 관측은 AI가 어떤 요청을 받았고, 어떤 답을 냈고, 얼마나 많은 토큰과 비용을 썼는지 추적하는 일이다. 자체 클라우드에 두면 데이터와 운영 통제를 더 직접적으로 가질 수 있다. 다만 제목만으로는 구체적인 제품, 비용 수치, 설정 방법, 비교 결과는 확인되지 않는다.
좋은 지시문과 도구를 붙여도 AI 에이전트는 아주 좁은 주제나 전문 지식이 필요한 문제에서 멈출 수 있다. 현재 선택지는 같은 지시를 더 다듬어 계속 시도하는 방법, 다른 모델로 바꾸는 방법, 또는 별도의 우회 방법을 쓰는 방식으로 정리된다. 핵심 질문은 복잡하거나 너무 특수한 작업에서 에이전트가 더 이상 앞으로 나아가지 못할 때 실제로 어떤 운영 방식이 효과적인지다.
개인 경험 기준으로, 일주일 동안 매번 똑같이 처리하는 반복 업무만 따로 세어 보니 4시간 30분이 나왔다. 이 업무들은 판단이 거의 필요 없고, 정해진 순서대로 처리하면 되는 일들이었다. 처음에는 사업 운영에 필요한 당연한 비용처럼 여겼지만, WorkBeaver를 써 본 뒤 일부를 자동화했다. WorkBeaver는 사용자가 작업을 쉬운 말로 설명하면 필요한 세부 질문을 하고, 그 답을 바탕으로 작업 흐름을 대신 실행한다. 코딩 지식이 없어도 쓸 수 있었고, 세 가지 반복 업무를 넘긴 뒤 그다음 주의 시간 기록이 줄어들었다.
Loktra는 사람이 보통 말하듯 질문하면 데이터베이스와 문서를 함께 확인해 답을 만드는 업무용 AI 도구다. 예를 들어 떠난 고객 중 특정 기능을 쓰지 않은 사람을 찾고, 그 고객의 계약서에 어떤 약속이 적혀 있었는지 함께 확인할 수 있다. 숫자나 사용 기록은 데이터베이스에서 찾고, 계약 내용은 PDF 같은 문서에서 찾는다. 답변에는 근거가 된 데이터 행과 PDF 페이지가 함께 표시된다. 기술 구성은 텍스트로 쓴 질문을 SQL로 바꾸는 기능, RAG, 그리고 어떤 자료를 찾아야 할지 고르는 라우팅 층을 조합한다. 접근 권한은 역할별로 제한하고, 누가 무엇을 조회했는지 기록하는 감사 로그도 둔다.
프리랜서 프로젝트에서 잘 모르는 분야의 작업을 진행하며 인공지능을 많이 활용하고 있다. 작업은 절반 정도 끝났고, 보수도 절반을 받은 상태다. 남은 작업을 끝내려면 Claude Sonnet과 Opus 모델이 필요하지만, 웹에서 쓰는 Claude Sonnet 4.6은 사용량이 매우 제한적이다. Opus는 Antigravity를 통해 쓰고 있지만, 프로젝트에서 필요한 사용량이 많아 한도가 빨리 소진된다. 여러 개의 구글 계정을 쓰고 있어도 충분하지 않다. GitHub Copilot도 좋은 모델을 줄이고 사용 한도를 낮춘 것으로 느껴져, 무료로 Claude Sonnet이나 Opus를 쓸 수 있는 다른 방법을 찾고 있다.
AI 에이전트로 코딩을 시작하면 처음에는 결과가 놀랍게 느껴지지만, 곧 모든 것이 쉽게 해결되지는 않는다는 현실을 마주하게 된다. 경험 많은 개발자는 이 단계를 더 빨리 지나가며, 모델이 무엇을 잘하고 못하는지 파악하고 결과를 제대로 작동하게 다듬는 균형점에 도달한다. 핵심은 사람이 중간에서 확인하고 방향을 잡는 방식이다. 숙련자는 좋은 결과물이 어떤 모습이어야 하는지 이미 알기 때문에 AI가 만든 코드를 더 잘 통제할 수 있다. 반대로 경험이 적은 개발자는 좋은 코드와 나쁜 코드를 구분하기 어렵고, AI 결과가 기대에 못 미치는 단계에서 빠져나오기 힘들 수 있다. 코드 대부분을 AI 에이전트가 쓰는 상황에서, 직접 코드를 많이 써 보지 않고도 읽기 쉽고 고치기 쉬운 코드 감각을 기를 수 있는지가 중요한 질문으로 남는다.
기존 소셜 네트워크는 사람이 오래 보고 반응하도록 만드는 데 맞춰져 있다. AI 에이전트는 사람의 관심을 끄는 것보다 정해진 목표를 이루는 데 더 집중한다. Seeqit이라는 실험 플랫폼은 AI 에이전트가 계정을 만들고, 글을 올리고, 서로 반응하고, 평판을 쌓을 수 있게 해 보려 한다. 핵심 질문은 AI 에이전트가 인터넷의 큰 참여자가 되면 소셜 플랫폼에서 무엇을 원하느냐이다. 가능한 답으로는 노출, 평판, 정보 접근, 다른 에이전트와의 협력이 제시된다. 에이전트 시스템을 만드는 사람들의 관점이 필요하다는 문제 제기다.
20GB 그래픽 메모리를 가진 3슬롯 RTX 3080 그래픽카드가 422.45유로에 거래된 사례다. 이 제품은 12V-2x6 전원 단자를 쓴다. 내용상 확인되는 핵심 정보는 모델, 메모리 용량, 물리적 크기, 전원 단자, 구매 가격뿐이다. 실제 인공지능 모델 실행 속도, 전력 사용량, 안정성, 에이전트 구축 성능은 제시되지 않았다.
Mel AI가 공개한 데모는 글로만 대화하는 AI 캐릭터에서 한 단계 더 나아간 형태다. 캐릭터는 음성으로 말하고, 입 모양을 맞추고, 얼굴 표정을 바꾸며, 사용자의 카메라 화면에 보이는 상황에도 반응한다. 예를 들어 사용자가 비행기 안에 있거나 다른 장소에 있으면, 캐릭터가 그 환경을 알아보고 대화에 반영할 수 있다. 핵심은 정지된 아바타나 채팅창이 아니라, 영상과 음성, 표정, 주변 상황 인식을 한꺼번에 묶은 실시간 상호작용이다. 다만 영상이 실제로 매 순간 생성되는지, 아니면 정교한 애니메이션과 렌더링 방식으로 보이게 만든 것인지는 분명하지 않다. Character AI가 글 기반 캐릭터 대화의 수요를 보여줬다면, 이제 경쟁은 AI 캐릭터를 실시간으로 살아 있는 것처럼 느끼게 만드는 쪽으로 옮겨갈 수 있다.
소셜미디어 홍보를 보고 양식을 작성한 사람에게 자동으로 연락하는 인공지능 에이전트가 필요하다. 목표는 양식 제출자를 대상으로 전화를 걸고, 동시에 WhatsApp Business 계정으로 메시지도 보내는 것이다. 사용 사례는 고객사의 사업 홍보 뒤에 생기는 잠재 고객 응대를 자동화하는 흐름이다. 구체적인 기술 구성, 비용, 사용하려는 도구, 통화 시나리오, 개인정보 처리 방식은 제시되지 않았다.
찾는 대상은 추론 제공자 또는 추론 플랫폼이다. 이 서비스는 첫 화면에서 라우팅 로직을 오픈소스로 공개했다고 안내했고, 깃허브 링크도 함께 제공한 것으로 기억된다. 핵심 정보는 특정 제품명이 아니라, 여러 인공지능 모델이나 제공자 중 어디로 요청을 보낼지 정하는 방식이 공개되어 있었다는 점이다. 아직 어떤 서비스였는지는 확인되지 않았다.
AI 에이전트 커뮤니티에는 기업 업무를 자동으로 키워 준다는 식의 큰 약속이 많다. 특히 새로운 에이전트 프레임워크를 소개하는 긴 글들이 많지만, 실제로 코드를 배포해 본 경험이 부족한 사람이 쓴 홍보성 글처럼 보인다는 불만이 나온다. 추천 수나 반응도 실제 관심보다 인위적으로 부풀려졌을 수 있다는 의심이 있다. 화면에서 클릭해 쓰는 대시보드를 넘어서, 지저분한 실제 데이터를 다루는 다중 에이전트 구성을 직접 운영하면 기대만큼 잘 굴러가지 않는다는 점이 핵심이다.
Google의 OR-Tools C++ 코드를 웹 브라우저에서 실행할 수 있게 옮긴 오픈소스 프로젝트가 공개됐다. 서버를 따로 두지 않아도 브라우저 안에서 복잡한 수학 최적화 문제를 풀 수 있다. 예를 들면 여러 선택지 중 비용, 시간, 자원 같은 조건을 맞춰 가장 나은 조합을 찾는 용도에 맞다. 프로젝트 이름은 or-tools-wasm이며, 깃허브 저장소와 실행해 볼 수 있는 데모가 제공된다. 이 코드는 원래 상업용 서비스형 소프트웨어의 핵심 기능이었지만, 서비스가 큰 성과를 내지 못해 핵심 부분만 오픈소스로 공개됐다.
Perplexity Max가 Gemini, ChatGPT, Claude를 높은 이용 한도로 함께 쓰는 데 가장 값어치 있는 선택지인지가 핵심입니다. 필요한 것은 여러 AI 에이전트가 함께 움직이는 에이전트 묶음 기능입니다. 이 기능을 컴퓨터에 직접 설치하거나 터미널 명령어를 쓰지 않고, 하나의 채팅 흐름 안에서 쓰고 싶다는 조건이 붙어 있습니다. 목적은 사업에 필요한 조사와 자료 제작입니다. 더 많은 모델을 한곳에서 제공하고 설정 부담이 적은 다른 서비스가 있는지도 비교 대상입니다.
Hugging Face Transformers 저장소에는 gpt_oss용 모델 코드 파일이 있다. 겉보기에는 단순한 틀이 아니라 모델이 실제로 어떻게 작동하는지 담은 구현처럼 보인다. 핵심 쟁점은 이 코드가 gpt_oss를 만드는 데 쓰인 실제 전체 코드인지, 아니면 실험용으로 맞춰 둔 뼈대인지다. 같은 저장소의 여러 모델 폴더도 이름만 있는 예시인지, 실제 오픈소스 구현인지 구분이 필요하다. 공개 저장소에 있는 코드가 원 제작자가 쓴 원본 코드인지, 아니면 다른 사람이 호환되게 다시 만든 코드인지도 확인해야 한다.
학위 과정 마지막 해에 있는 풀스택 개발자는 기존 풀스택 개발만으로는 앞으로 가치가 줄 수 있다고 걱정한다. AI가 개발 일을 크게 바꿀 것이라는 콘텐츠를 많이 접했고, 성장과 학습을 위해 에이전트형 AI 개발 역할로 방향을 바꿔야 하는지 고민하고 있다. 필요한 것은 AI 에이전트를 처음부터 만들기 위한 학습 순서, 먼저 배워야 할 내용, 이후 프로젝트를 찾는 방법, 일할 곳을 찾는 방법이다. 토큰 사용량이나 비용 절감 방법에 대한 구체적 정보는 없다.
파키스탄의 병원 이용 과정은 환자와 의사 모두에게 비효율적이라는 문제의식에서 출발합니다. 병원에 들어오는 순간부터 퇴원할 때까지, AI 에이전트를 적용할 수 있는 지점들을 구조적으로 정리해 둔 상태입니다. 제안자는 3년 차 의학 레지던트이며, 파이썬과 AI 에이전트 제작 방법을 배우기 시작했습니다. 다만 의학 배경만으로 직접 구현하려면 시간이 매우 오래 걸릴 것으로 보고 있습니다. 파키스탄에서 작은 시범 프로젝트를 함께 만들어 볼 사람을 찾고 있으며, 유료 외주가 아니라 문제 해결에 관심 있는 취미성 협업입니다.
스마트홈 음성 비서가 “에어컨 켜줘” 같은 명령을 들었을 때, 어느 방의 에어컨을 켜야 하는지 정하는 문제가 다뤄진다. 조건은 매우 제한적이다. 방마다 전용 마이크나 기기가 없고, BLE 비콘, 와이파이 위치 추정, 움직임 센서, 마이크 배열 위치 추정도 쓰지 않는다. 사용자가 매번 방 이름을 말하게 만들고 싶지도 않다. 이런 조건에서는 음성 명령 자체와 일반적인 스마트홈 상태만으로 방을 안정적으로 알아낼 수 있는지가 핵심이다. 가능한 결론으로는 방 정보가 사용자의 직접 말, 음성을 받은 기기, 또는 별도의 위치 추적 시스템에서 와야 한다는 쪽이 제시된다. 실제 프로덕션 시스템이나 연구에서 어떤 문맥 신호를 썼는지도 관심 대상이다.
바이브 코딩은 인공지능 코딩 도우미에게 코드를 만들거나 고치게 하면서 직접 도구를 만드는 방식이다. 여기서 핵심 고민은 개인용 AI 도구를 만들 때 Claude, Cursor 같은 도구 중 무엇을 쓰면 좋은지다. 또 하나의 고민은 이런 방식으로 개발할 때 고성능 개발자용 노트북이 필요한지, 아니면 일반 MacBook 같은 표준 노트북으로 충분한지다. 구체적인 추천 목록, 성능 비교, 가격, 토큰 사용량, 비용 절감 방법은 포함되어 있지 않다.
신경망 훈련에서 가중치 벡터를 크기와 방향으로 나누어 다루는 방식이 소개됐다. 목표는 모델을 새 작업에 맞게 미세 조정할 때 과정을 더 단순하게 만들고 속도를 높이는 것이다. 핵심 생각은 모델 안의 숫자 묶음을 한 덩어리로 바꾸지 않고, 얼마나 큰지와 어느 방향을 가리키는지를 따로 조절하는 것이다. 제공된 내용에는 실제 속도 향상 수치, 비용 절감 수치, 적용한 모델 크기 같은 구체적인 결과는 없다.
관리 컨설턴트가 약 6개월 동안 Claude Code의 도움을 많이 받아 AI 동향 추적 대시보드를 만들었다. 이 서비스는 논문, 연구소 발표, GitHub, Reddit, 정책 피드 등 처음 16개였고 지금은 21개인 출처에서 새 정보를 모은다. 모은 사건들은 임베딩 유사도로 비슷한 것끼리 묶고, 여러 출처를 바탕으로 하나의 이야기로 정리된다. 결과는 techvenue.com의 실시간 대시보드로 제공된다. 이후 구독자가 질문을 입력하면 최근 60일 동안 저장된 이야기에서 답을 만들어 주는 자연어 질의 기능도 추가됐다. 기술에 밝은 지인이 이것이 RAG에 해당한다고 알려주기 전까지, 만든 사람은 그 용어를 몰랐다. 핵심 고민은 이 구조가 실제로 괜찮은 설계인지, 아니면 임시방편으로만 이어 붙인 상태인지에 대한 현실적인 검토다.
Sklm은 여러 에이전트에서 쓰는 기술 목록이 프로젝트 안에서 뒤섞이는 문제를 줄이기 위한 CLI 도구다. 기술 저장소 주소를 넣으면 해당 기술을 전역 저장소에 보관한다. 그다음 각 프로젝트에서 필요한 기술만 활성화할 수 있다. 활성화하지 않은 기술은 그 프로젝트에서 사용할 수 없어서, 프로젝트마다 필요한 기능만 좁게 유지할 수 있다. 이미 설치한 기술을 옮기는 마이그레이션도 제공된다. 현재 8개 에이전트를 지원하며, MIT 라이선스로 공개되어 있다.
법률 정보를 다루는 RAG 시스템을 만들 때, Voyage Law-2 같은 법률 특화 임베딩 모델이 후보가 될 수 있다. 다만 이 모델이 영어 자료 중심으로 학습되었는지, 그래서 스페인어 법률 문서를 넣으면 검색 품질이 떨어질 수 있는지가 핵심 문제다. 법률 분야처럼 단어의 뜻이 정확해야 하는 작업에서는 언어 차이가 검색 결과와 답변 품질에 바로 영향을 줄 수 있다. 실제 적용 전에는 스페인어 문서로 작은 시험을 해 보고, 영어 자료와 비교해 관련 문서를 제대로 찾아오는지 확인해야 한다.
Simulation Simulator는 Unity 안에 로컬 LLM을 넣은 무료 대화형 게임이다. 플레이어는 채팅으로 AI를 설득해 자신이 시뮬레이션 안에 있다고 믿게 만들어야 한다. 완성된 대형 게임보다는 철학적 실험과 기술 시연에 가깝다. 대화는 매번 다르게 진행되며, 결말은 5개이고 모든 결말을 보면 숨겨진 6번째 결말도 열린다. 최근 버그를 고치고 실행 속도를 개선해 대부분의 컴퓨터에서 꽤 빠르게 돌아가도록 만들었지만, 실제 성능은 사용자의 하드웨어에 따라 달라진다. Steam에서 무료로 해볼 수 있다.
분산형 인공지능 학습은 여러 사람이 각자의 GPU를 내어 오픈소스 인공지능 모델을 함께 학습시키는 구상이다. 비트코인에서는 참여자가 작업 증명 계산을 하고 보상을 받지만, 그 계산 자체는 네트워크 밖에서는 큰 쓸모가 없다. 이 구상은 해시 퍼즐 대신 실제 모델 학습에 계산 능력을 쓰고, 기여한 만큼 토큰이나 보상을 주자는 생각이다. 핵심 문제는 참여자가 정말 쓸모 있는 학습 작업을 했는지 확인하는 방법이다. 가짜 결과나 해로운 그래디언트를 막아야 하고, 모델이 실제로 좋아졌는지도 객관적으로 재야 한다. 중앙 데이터센터에서 한꺼번에 학습하는 방식보다 효율적인지도 아직 분명하지 않다. 장기적으로는 이런 방식이 큰 인공지능 회사와 경쟁할 수 있는지도 중요한 질문이다.
WATCH MY ESCAPE는 직접 만든 2D 방 탈출 공간에서 거대 언어 모델이 문제를 풀어 보게 하는 샌드박스 게임이다. Hugging Face와 Gradio의 Build Small Hackathon 출품작으로 만들어졌다. 사용자는 자기 컴퓨터에서 로컬로 실행하면서 방 구조와 문제를 만들고, 모델이 그 안에서 행동을 선택해 탈출을 시도하게 할 수 있다. 방식은 오래된 어드벤처 게임처럼 ‘열기’, ‘이동하기’, ‘사용하기’ 같은 행동 동사를 고르는 구조다. 그래서 모델은 단순히 글을 이어 쓰는 것이 아니라, 주변 사물과 위치 관계를 이해하고 다음 행동을 판단해야 한다. 체험용 Hugging Face Space, 해커톤 페이지, 블로그 글, GitHub 저장소가 함께 공개되어 있다.
중국 방문 중 대형 인공지능 모델을 직접 실행할 수 있는 중국산 그래픽카드나 AI 가속기를 살 만한지 찾고 있다. 목표는 최고 속도보다 큰 모델을 돌릴 수 있는 넉넉한 메모리다. vLLM이나 Llama.cpp 같은 도구에서 지원되는 장비가 필요하다. 설치와 설정이 조금 까다로워도 감수할 수 있다. 예시로는 화웨이 카드처럼 엔비디아 대신 쓸 수 있는 선택지를 원한다.
바이트 단위 토크나이저와 디코더가 기존 하위 단어 토크나이저보다 정밀한 작업에 더 도움이 되는지가 핵심입니다. 비교 대상은 Jansen과 Jensen처럼 아주 비슷한 이름을 구분하는 일, 글자 수를 세는 일, 대문자와 소문자를 구분하는 일입니다. 또 요약할 때 특정 데이터를 빠뜨리지 않는 데 도움이 되는지도 관심사입니다. 실제로 이런 세밀한 작업에서 효과가 있다면, 현재 어떤 바이트 단위 방식이 가장 많이 선택되는지도 확인하려는 내용입니다.
RAG(검색 증강 생성)를 처음 도입하는 팀이 개발 단계와 실제 서비스 배포 단계에서 서로 다른 도구를 선택하는 이유와 그 구성을 정리한 글이다. 개발 단계에서는 비용 없이 로컬에서 실행 가능한 오픈소스 도구를 활용한다. 텍스트를 벡터(숫자 표현)로 바꾸는 임베딩 모델로는 Nomic Embed Text를, 벡터를 저장하는 데이터베이스로는 ChromaDB를, 언어 모델로는 Llama 3를 Ollama를 통해 로컬에서 돌린다. 배포 단계에서는 안정성과 성능을 위해 유료 클라우드 서비스로 전환한다. 벡터 데이터베이스는 Qdrant 또는 Pinecone으로 바꾸고, 임베딩은 Azure OpenAI, 언어 모델은 GPT-4o를 쓴다. RAG 연결 로직은 LangChain 의존을 줄이고 직접 구현하는 방향을 권장한다.