LightRAG를 한 번 써 본 사람이라면 금방 부딪히는 한계가 있습니다. 텍스트 문서는 잘 다루지만, 스캔 PDF나 이미지가 섞인 보고서, 차트와 그래프가 많은 문서는 갑자기 처리 난도가 올라간다는 점입니다. 이 영상은 그 빈칸을 메우는 방법으로 RAG-Anything 를 소개합니다. 핵심은 새로운 RAG를 처음부터 다시 만드는 것이 아니라, LightRAG 위에 멀티모달 문서 처리 레이어를 하나 더 얹는 방식 이라는 데 있습니다. 0:48 1:03 더보기

이 영상의 핵심은 Hermes Agent 자체보다, 그 에이전트를 더 많은 사용자가 편하게 다룰 수 있게 만드는 Hermes for Web 에 있습니다. 발표자는 Hermes Agent를 2주 정도 직접 써 본 뒤, 설치와 사용이 다소 불편한 지점을 웹 UI와 몇 가지 자동화 패키지로 보완했다고 설명합니다. 결과적으로 CLI 중심 에이전트에 온보딩, 예약 작업, 메모리 확인, 모델 선택, Obsidian 연동 을 얹은 관리 화면이 만들어집니다. 0:24 1:11 2:24 더보기

pro-workflow 가 흥미로운 이유는 “좋은 프롬프트 모음”에 머물지 않기 때문입니다. 이 프로젝트는 Claude Code가 사용자의 교정을 세션마다 잊어버리는 문제를, 영속 메모리와 자동 규칙 재주입 으로 풀려는 시도에 가깝습니다. 저장소 README는 이를 self-correcting memory 라고 부르며, 교정이 SQLite 데이터베이스에 누적되고 다음 세션 시작 시 다시 로드된다고 설명합니다. README GitHub API 메타데이터 더보기

RBAC(Role-Based Access Control)는 익숙한 개념이지만, 실제로 설계할 때는 “사용자에게 권한을 어떻게 직접 붙일 것인가”보다 “권한을 어떻게 중간 레이어로 묶어 확장 가능하게 관리할 것인가”가 더 중요합니다. Rohit의 이 Medium 글은 RBAC를 아주 정석적인 형태로 풀어냅니다. 핵심은 user, role, permission을 분리하고, user-role과 role-permission을 조인 테이블로 연결하는 것입니다. 원문 더보기

이 영상의 포인트는 RBAC를 깊게 파는 보안 강의라기보다, 바이브 코딩을 할 때 권한 구조를 어떻게 말해야 결과 품질이 달라지는가 에 있습니다. 발표자는 개발자가 아닌 사람도 이제는 제품을 직접 만드는 시대라 RBAC 같은 단어를 아는 것만으로도 AI에게 훨씬 더 좋은 결과를 끌어낼 수 있다고 말합니다. 특히 프로젝트가 복잡해질수록 촘촘한 권한 설정이 필요해지기 때문에, 역할 기반 권한 모델을 이해하는 것이 기본기가 된다는 설명입니다. 0:00 0:13 0:21 더보기

Agent Reach 는 AI 에이전트가 인터넷을 “볼 수 있게” 만드는 환경 부트스트랩 도구를 표방합니다. 핵심 메시지는 단순합니다. 웹 읽기, YouTube 자막, X 읽기, Reddit 검색, GitHub 탐색, RSS 구독 같은 능력 자체는 각 플랫폼별 도구를 조합하면 구현할 수 있지만, 실제로는 API 비용, 로그인, 쿠키, 프록시, 의존성 설치, 툴 선택 때문에 매번 처음부터 삽질하게 된다는 것입니다. Agent Reach는 이 골치 아픈 선행 작업을 한 번에 정리해, 에이전트가 곧바로 인터넷 채널을 다루게 만드는 것을 목표로 합니다. (출처: GitHub README) 이 프로젝트가 흥미로운 이유는 새로운 프레임워크를 만들겠다고 주장하지 않는다는 점입니다. README는 Agent Reach를 framework가 아니라 scaffolding 이라고 정의합니다. 즉 자체 추상화 계층으로 모든 것을 감싸는 게 아니라, yt-dlp, gh, twitter-cli, rdt-cli, Jina Reader, feedparser, mcporter 같은 기존 상위 도구들을 에이전트가 바로 쓸 수 있도록 설치·선택·연결·진단 레이어를 제공하는 방식입니다. (출처: GitHub README, raw README) 더보기

AI 코딩과 에이전트 이야기는 유행어만 계속 바뀌는 것처럼 보이지만, 실제로는 꽤 분명한 방향으로 진화해 왔습니다. 이 영상은 그 흐름을 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 바이브 코딩 → 하네스 엔지니어링 으로 묶어 설명합니다. 중요한 건 이름이 아니라, 각 단계가 이전 단계의 한계를 해결하려고 등장했다 는 점입니다. 0:01 0:16 더보기