<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>AI_23yellow &amp;gt; 커뮤니티 &amp;gt; AI Agent</title>
<link>https://ai.23yellow.com/ai_agent_01</link>
<language>ko</language>
<description>AI Agent (2026-10-30 15:35:48)</description>

<item>
<title>Ruflo — Claude Code·Codex를 하나의 AI 개발팀으로 운영하는 멀티에이전트 오케스트레이션</title>
<link>https://ai.23yellow.com/ai_agent_01/ruflo-claude-codecodex%EB%A5%BC-%ED%95%98%EB%82%98%EC%9D%98-ai-%EA%B0%9C%EB%B0%9C%ED%8C%80%EC%9C%BC%EB%A1%9C-%EC%9A%B4%EC%98%81%ED%95%98%EB%8A%94/</link>
<description><![CDATA[
MINDUNG의 쇼츠 **「[개발자들의 PICK] 계속 트렌딩에 뜨는 AI 개발팀 오픈소스, 루플로」**에서는 여러 AI 에이전트를 하나의 개발팀처럼 운영하도록 돕는 오픈소스 **Ruflo**를 소개합니다.

## Ruflo는 무엇인가?

Ruflo는 Claude Code나 Codex 같은 AI 코딩 에이전트를 여러 개 연결해 **설계·구현·테스트·검토 역할을 나눠 수행하도록 조율하는 멀티에이전트 오케스트레이션 도구**입니다.

단순히 AI 여러 개를 동시에 실행하는 것이 아니라, 각 에이전트에 역할을 부여하고 전체 작업 흐름을 관리하는 데 초점이 있습니다.

예를 들어 로그인 기능을 개발한다면:

- Agent A → 요구사항과 구조 설계
- Agent B → 실제 코드 구현
- Agent C → 테스트 작성
- Agent D → 결과 검토

처럼 역할을 나눌 수 있습니다.

## 하나의 AI보다 여러 Agent가 유리한 경우

간단한 코드 수정이나 단일 파일 작업은 에이전트 하나로도 충분합니다.

하지만 다음처럼 여러 단계가 필요한 프로젝트에서는 멀티에이전트 구조가 의미가 있습니다.

- 기능 설계
- 프론트엔드·백엔드 구현
- 테스트
- 코드 리뷰
- 보안 점검
- 문서화

각 작업을 분리하면 한 Agent가 지나치게 긴 Context를 들고 모든 일을 처리하는 부담을 줄일 수 있습니다.

## Memory — 이전 작업 경험을 다시 활용

Ruflo의 중요한 특징 중 하나는 **기억을 축적할 수 있다는 점**입니다.

이전에:

- 어떤 오류가 발생했는지
- 어떤 해결 방법이 성공했는지
- 어떤 구조를 사용했는지

같은 정보를 저장해 다음 작업에서 다시 참고하도록 할 수 있습니다.

즉 매번 프로젝트를 처음 보는 Agent처럼 시작하는 것이 아니라, 과거 작업 경험을 다음 실행에 활용하는 구조입니다.

## 전용 Console에서 전체 Agent 상태 확인

여러 Agent를 운영하면 가장 어려운 점은 지금 누가 무엇을 하고 있는지 파악하는 것입니다.

영상에서는 Ruflo Console에서:

- 실행 중인 Agent
- 현재 작업 단계
- 작업 진행 상황
- Token 사용량
- 비용

등을 한눈에 확인할 수 있다고 설명합니다.

멀티에이전트 시스템에서는 모델 성능만큼 **관측 가능성(Observability)** 이 중요하기 때문에 이런 관리 화면은 실무에서 상당히 중요한 요소입니다.

## Agent에게 Console 조작까지 맡길 수 있다

관리 콘솔 자체를 Claude 같은 Agent가 조작하도록 구성할 수도 있습니다.

다만 모든 제어권을 무조건 넘기는 것이 아니라 Agent가 어디까지 조작할 수 있는지 권한 수준을 설정할 수 있습니다.

## Permission과 Human Approval

Ruflo는 중요한 작업에 대해 사람이 직접 승인하도록 구성할 수 있습니다.

예를 들어:

- 파일 대량 삭제
- 배포
- 외부 서비스 변경
- 중요 설정 수정

같은 작업은 Agent가 독단적으로 실행하지 않고 승인 단계에서 멈추도록 설계할 수 있습니다.

필요하면 사용자가 다시 직접 제어권을 가져오는 방식도 가능합니다.

이 구조는:

**Agent Autonomy + Human-in-the-loop**

패턴에 가깝습니다.

## 멀티에이전트의 단점 — Token과 비용

Agent가 많다고 항상 좋은 것은 아닙니다.

여러 Agent가 각각:

- Context를 읽고
- 모델을 호출하고
- 결과를 생성하고

있기 때문에 Token 사용량과 비용도 증가할 수 있습니다.

그래서 작업 복잡도에 따라 적절한 수의 Agent를 사용하는 것이 중요합니다.

작은 작업:

**Single Agent**

복잡한 작업:

**Planner + Coder + Tester + Reviewer**

처럼 구성하는 편이 효율적입니다.

## Claude Code·Codex와 Ruflo의 관계

Claude Code나 Codex가 실제 코드를 읽고 수정하는 **실행 Agent**라면, Ruflo는 여러 Agent를 묶어 역할과 작업 순서를 관리하는 **Orchestration Layer**에 가깝습니다.

구조를 단순화하면:

**사용자 → Ruflo → 여러 Coding Agent → Tools / Files / Git / Tests**

형태로 볼 수 있습니다.

## 어떤 프로젝트에 잘 맞을까?

Ruflo는 특히 다음과 같은 프로젝트에서 활용 가치가 있습니다.

- 프론트엔드와 백엔드를 동시에 개발하는 프로젝트
- 설계·구현·테스트를 반복하는 장기 프로젝트
- 여러 저장소를 함께 다루는 프로젝트
- 코드 리뷰와 품질 검증이 중요한 프로젝트
- 하나의 Agent Context가 너무 커지는 프로젝트

반대로 몇 줄 수정이나 간단한 버그 수정이라면 오히려 구조가 복잡해질 수 있습니다.

## 핵심 정리

Ruflo의 핵심은 'AI를 여러 개 띄우는 것'이 아니라 **여러 AI Agent를 하나의 개발팀처럼 조직하고 운영하는 것**입니다.

즉:

**Role 분담 → Orchestration → Memory → Permission → Monitoring → Human Approval**

까지 하나의 시스템으로 묶는 것이 핵심입니다.

AI 코딩이 단일 Agent 중심에서 실제 소프트웨어 개발팀과 비슷한 **Multi-Agent Engineering Team** 구조로 발전하고 있음을 보여주는 도구라고 볼 수 있습니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-30T15:35:48+09:00</dc:date>
</item>


<item>
<title>Flue — React Hook처럼 만드는 AI Agent Harness Framework</title>
<link>https://ai.23yellow.com/ai_agent_01/flue-react-hook%EC%B2%98%EB%9F%BC-%EB%A7%8C%EB%93%9C%EB%8A%94-ai-agent-harness/</link>
<description><![CDATA[
노마드 코더의 영상 **「미친 프레임워크 등장」**에서는 AI 에이전트를 React의 Hook과 비슷한 방식으로 구성할 수 있는 TypeScript 기반 프레임워크 **Flue**를 소개합니다.

&gt; Flue는 개발 속도가 매우 빠른 프로젝트라 API가 자주 바뀔 수 있습니다. 아래 내용은 영상 공개 시점과 현재 공식 저장소의 구조를 함께 참고해 정리했습니다.

## Flue는 무엇인가?

Flue는 단순한 LLM SDK보다 한 단계 위의 **Agent Harness Framework**를 지향합니다.

즉, 모델 호출 코드만 제공하는 것이 아니라 AI 에이전트가 실제 일을 수행하는 데 필요한:

- Session
- Tool
- Skill
- MCP
- Subagent
- Sandbox
- Persistent State
- Durable Execution
- Observability

같은 실행 환경 전체를 하나의 Framework 안에서 구성합니다.

공식 저장소에서는 Flue를 **'The Agent Harness Framework'**라고 설명합니다.

## React처럼 Hook으로 Agent를 구성한다

Flue의 가장 눈에 띄는 특징은 React처럼 Hook 스타일 API를 사용한다는 점입니다.

현재 공식 구조에서는 Agent 함수 내부에서 다음과 같은 Hook을 선언할 수 있습니다.

- useModel()
- useTool()
- useSkill()
- useSubagent()
- useMcpConnection()
- useSandbox()
- usePersistentState()

즉, Agent의 기능을 거대한 설정 객체 하나에 몰아넣기보다 **필요한 기능을 Hook처럼 조합**합니다.

## Agent는 하나의 함수

현재 Flue에서는 Agent 자체가 하나의 exported function입니다.

그 함수 안에서 모델, Tool, Skill, Sandbox 등을 선언하고 마지막에 Agent의 Instruction을 반환합니다.

개념적으로는:

**Agent = Model + Instructions + Tools + Skills + State + Environment**

라고 볼 수 있습니다.

## Tool 연결

AI가 외부 API를 호출하거나 실제 작업을 수행하려면 Tool이 필요합니다.

Flue는 typed Tool을 Agent에 붙여:

- API 호출
- DB 조회
- 파일 처리
- GitHub 작업
- 내부 서비스 호출

같은 Action을 수행하게 만들 수 있습니다.

## Skill 연결

Skill은 반복적으로 재사용하는 전문 지식이나 Workflow를 패키징하는 방식입니다.

예를 들어:

- 코드 리뷰 Skill
- 보안 점검 Skill
- 고객 문의 처리 Skill
- 문서 작성 Skill

을 따로 만들어 두고 필요할 때 Agent가 사용할 수 있습니다.

공식 구조에서는 SKILL.md 형태의 Skill도 패키징해서 사용할 수 있습니다.

## MCP 연결

Flue는 Model Context Protocol(MCP) 연결도 지원합니다.

즉, 이미 구축된 MCP Server를 연결해:

- GitHub
- 사내 API
- Database
- Browser
- 외부 SaaS

같은 도구를 Agent가 사용할 수 있습니다.

현재 공식 API에서는 useMcpConnection()을 통해 MCP Server를 선언합니다.

## Subagent

하나의 Agent가 모든 작업을 처리하는 대신 전문 역할을 가진 Subagent에게 일을 넘길 수도 있습니다.

예:

**Main Agent**
↓
**Research Subagent**
**Coding Subagent**
**Review Subagent**

처럼 역할을 분리할 수 있습니다.

복잡한 Multi-Agent 시스템을 직접 Routing 코드로 모두 작성하지 않아도 Framework 차원에서 위임 구조를 만들 수 있다는 점이 장점입니다.

## Sandbox

AI Agent가 실제 코드를 실행하거나 파일을 수정하려면 안전한 실행 환경이 필요합니다.

Flue는 Sandbox를 Agent에 붙일 수 있습니다.

공식 저장소 기준으로 Local 환경뿐 아니라 Cloudflare Sandbox 같은 환경과 연결할 수 있고, Sandbox를 선언해야 Shell·Filesystem Tool을 사용할 수 있도록 설계되어 있습니다.

즉, Agent에게 무제한 Shell 권한을 바로 주기보다 **실행 환경 자체를 명시적으로 붙이는 구조**입니다.

## Persistent State와 Memory

장시간 동작하는 Agent는 이전 작업 상태를 기억해야 합니다.

Flue의 usePersistentState() 같은 기능을 사용하면 Agent Instance별 상태를 유지할 수 있습니다.

이를 이용하면:

- 이전 작업 진행 상태
- 사용자 설정
- 마지막 처리 위치
- 누적 데이터

같은 정보를 다음 Turn에서도 이어갈 수 있습니다.

## 조건부 Hook

Flue의 흥미로운 특징 중 하나는 Agent Render마다 Tool이나 Skill을 조건부로 붙일 수 있다는 점입니다.

예를 들어:

**관리자 사용자일 때만 Admin Tool 연결**

**특정 작업일 때만 Sandbox 활성화**

**코딩 작업일 때만 Coding Subagent 연결**

같은 동적 구성이 가능합니다.

React에서 조건과 상태에 따라 UI 구성이 달라지는 것처럼 Agent의 Harness 구성을 상황별로 바꿀 수 있는 개념입니다.

## REST API와 UI 연결

영상에서는 Flue를 이용해 Agent를 단순 CLI 프로그램이 아니라:

- REST API
- WebSocket
- React UI
- 외부 Application

과 연결할 수 있다는 점도 강조합니다.

즉, Agent 코드를 만들고 나면 이를 실제 SaaS나 내부 업무 서비스의 Backend처럼 사용할 수 있습니다.

## DB와 Persistence

공식 Package에는 Postgres Persistence Adapter도 제공됩니다.

따라서 개발 단계에서는 가볍게 시작하고, 운영 단계에서는 PostgreSQL 기반 상태 관리로 확장할 수 있습니다.

## Observability

실제 Agent 운영에서는 어떤 Tool을 호출했고 어디서 실패했는지 추적하는 것이 중요합니다.

Flue는 OpenTelemetry 기반 Observability를 지원하고 Braintrust, Sentry 같은 외부 Monitoring 도구와도 연결할 수 있습니다.

이는 Agent를 단순 Demo가 아니라 실제 Production 시스템으로 운영하기 위한 중요한 기능입니다.

## 어디에 배포할 수 있나

공식 저장소 기준으로 Flue는 다음 환경을 지원합니다.

- Node.js
- Cloudflare Workers
- GitHub Actions
- GitLab CI/CD
- Daytona

즉, 특정 Cloud에 종속된 Agent Runtime이 아니라 배포 환경을 선택할 수 있도록 설계되어 있습니다.

## Flue가 기존 Agent SDK와 다른 점

단순 Agent SDK는 보통:

**Model + Tool Calling**

수준에서 시작합니다.

Flue는 여기에:

**Model + Tool + Skill + MCP + State + Sandbox + Subagent + Durability + Observability**

까지 묶어 하나의 Harness를 구성하려는 접근입니다.

그래서 Claude Code나 Codex 같은 실제 자율형 Agent의 실행 구조를 **Headless하고 Programmable한 Framework**로 만드는 방향에 가깝습니다.

## 주의할 점

Flue는 빠르게 발전 중인 Framework입니다.

실제로 공식 CHANGELOG를 보면 Agent 정의 방식, Workflow API, MCP 연결 방식, Sandbox 구조 등이 큰 폭으로 바뀐 이력이 있습니다.

따라서 Production에 바로 도입할 때는:

- 현재 버전 API 확인
- Migration Guide 확인
- Sandbox 권한 설정
- Tool Allowlist
- MCP 인증
- 실패 복구 정책

을 함께 점검해야 합니다.

## 핵심 정리

Flue의 핵심은 'AI Agent를 코드 몇 줄로 만든다'는 것보다:

&gt; **Agent를 구성하는 Harness 전체를 React Hook처럼 선언적으로 조립한다는 것**

에 있습니다.

정리하면:

**Model**
+ **Instructions**
+ **Tools**
+ **Skills**
+ **MCP**
+ **Subagents**
+ **Sandbox**
+ **State**
+ **Observability**

를 하나의 TypeScript Framework 안에서 구성하는 접근입니다.

Agent를 단순 Chatbot이 아니라 실제 업무를 수행하는 Software Runtime으로 만들고 싶다면 주목할 만한 Framework입니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-26T04:33:15+09:00</dc:date>
</item>


<item>
<title>Aside AI 브라우저 — Task·Skill·Routine으로 로그인된 웹 업무까지 자동화</title>
<link>https://ai.23yellow.com/ai_agent_01/aside-ai-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-taskskillroutine%EC%9C%BC%EB%A1%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8%EB%90%9C-%EC%9B%B9-%EC%97%85%EB%AC%B4%EA%B9%8C%EC%A7%80/</link>
<description><![CDATA[
비노 BeNo의 쇼츠 **「AI 몰라도 자동화는 바로 됩니다 | AI 브라우저 어사이드 기능 3가지」**에서는 AI 브라우저 **Aside**를 이용해 로그인된 웹사이트에서 반복 업무를 자동화하는 방식을 소개합니다.

## Aside는 무엇인가?

Aside는 단순히 웹페이지를 요약하는 AI 브라우저가 아니라, 사용자가 이미 로그인해 둔 웹사이트에서 AI가 직접:

- 페이지 열기
- 버튼 클릭
- 폼 입력
- 파일 처리
- 메시지 작성
- 게시
- 결제 전 단계 작업

같은 실제 브라우저 행동을 수행하는 에이전트형 브라우저입니다.

핵심은 Zapier나 Make처럼 서비스마다 별도 API 연동을 먼저 만들지 않아도, **사람이 브라우저에서 하던 일을 그대로 대신 수행한다는 점**입니다.

## 영상에서 강조하는 기능 3가지

### 1. Tasks

사용자가 자연어로 해야 할 일을 설명하면 Aside가 여러 브라우저 단계를 이어서 실행합니다.

예를 들어:

&gt; 지난달 카드 명세서에서 사용하지 않는 구독을 찾아 해지하고 환불 요청까지 준비해줘

라고 요청하면 관련 사이트를 열고 로그인 상태를 이용해 필요한 페이지를 탐색할 수 있습니다.

공식 문서 기준 Tasks는 브라우징뿐 아니라 검색, 파일 사용, 승인 요청, 허용된 Credential Autofill까지 여러 단계를 이어서 수행할 수 있습니다.

## 2. Skills / Memory

영상에서는 잘 된 작업 방법을 저장해 다음에도 그대로 재사용하는 개념을 소개합니다.

Aside는 사용자가 어떤 사이트에서 어떤 방식으로 업무를 처리하는지 기억해, 매번 처음부터 설명해야 하는 부담을 줄이는 방향으로 설계되어 있습니다.

공식 설명에 따르면 브라우징 이력을 기반으로 작업 Memory를 구성하고, 이 Memory는 로컬 중심으로 관리됩니다.

즉, 단순한 1회성 자동화보다 **반복 업무를 점점 더 잘 처리하는 개인 브라우저 에이전트**를 지향합니다.

## 3. Routines

Routines는 정해진 시간마다 작업을 자동 실행하는 기능입니다.

예:

- 매주 월요일 오전 8시 지난주 지표 요약
- 매일 아침 특정 사이트 확인
- 정기 보고서 준비
- 반복 데이터 수집

처럼 사용자가 매번 실행 버튼을 누르지 않아도 됩니다.

공식 문서에서는 Routine을 크게 두 가지로 구분합니다.

- **Cron Routine** → 일정마다 새로운 Task 실행
- **Heartbeat Routine** → 기존 Chat을 다시 깨워 이어서 작업

무료 요금제에서는 현재 최대 3개의 활성 Routine을 유지할 수 있습니다.

## 로그인과 Credential 처리

AI 브라우저에서 가장 민감한 부분은 Password입니다.

Aside는 저장된 Credential을 AI 모델에게 직접 보여주는 대신, 브라우저 Autofill 방식으로 입력하도록 설계되어 있습니다.

즉:

**AI가 Password 값을 읽음 → 입력**

이 아니라:

**AI가 로그인 필요 판단 → 브라우저가 Credential Autofill**

방식입니다.

## 중요한 작업은 승인 후 실행

공식 설명에 따르면 다음과 같은 민감 작업은 Human Approval을 거치도록 설계되어 있습니다.

- 결제
- 게시
- 메시지 전송
- 중요한 계정 변경

즉, AI가 탐색과 준비는 수행하더라도 최종적으로 되돌리기 어려운 행동은 사용자가 확인하도록 하는 구조입니다.

## ChatGPT·Claude와 연결해서 사용

Aside는 자체 모델만 강제하는 방식이 아니라, 기존 ChatGPT 또는 Claude 구독이나 API Key를 연결해 사용할 수 있습니다.

따라서 사용자는 자신이 선호하는 모델을 브라우저 Agent의 추론 엔진으로 활용할 수 있습니다.

## 일반 자동화 도구와 무엇이 다른가?

### Zapier / Make

- API Integration 중심
- Workflow를 미리 구성
- 서비스마다 Connector가 필요

### Aside

- 브라우저 UI를 직접 사용
- 자연어 Task 중심
- 로그인된 실제 웹사이트에서 실행
- 사람이 하던 브라우저 작업을 그대로 자동화

즉, API가 없는 서비스나 내부 관리자 화면처럼 **브라우저로만 접근 가능한 업무에도 적용할 수 있다는 점**이 차이입니다.

## Playwright 기반 Agent 구조

Aside 공식 기술 블로그에 따르면 내부 Browser Agent는 Playwright 문법을 활용한 JavaScript REPL을 핵심 도구로 사용합니다.

즉, AI가 단순히 화면 좌표를 클릭하는 것보다:

**페이지 상태 파악 → JavaScript/Playwright 코드 작성 → 브라우저 제어**

방식으로 동작합니다.

이는 복잡한 폼, 반복 요소, 동적 페이지를 처리할 때 더 유연한 접근입니다.

## 주의할 점

브라우저 에이전트는 강력한 만큼 위험도 있습니다.

특히:

- 결제
- 계정 삭제
- 게시
- 고객 데이터
- 민감 문서
- 메시지 발송

같은 작업은 결과를 반드시 검토해야 합니다.

또한 웹페이지 안에 숨겨진 Prompt Injection이나 악성 지시가 존재할 수 있으므로, 자동화 범위와 권한을 최소화하는 것이 중요합니다.

## 핵심 정리

Aside의 핵심은 단순한 AI 브라우저가 아니라:

**Task → Memory/Skill → Routine**

으로 이어지는 반복 업무 자동화 구조입니다.

즉:

&gt; 한 번 시켜 보고 → 잘 된 방식을 기억시키고 → 반복 업무는 일정에 따라 자동 실행

하는 형태입니다.

특히 별도 API 연동 없이 **로그인된 실제 웹서비스를 직접 조작하는 Browser Agent**라는 점이 기존 자동화 도구와 가장 큰 차이입니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-25T01:13:23+09:00</dc:date>
</item>


<item>
<title>Karpathy LLM Wiki 패턴 — RAG 다음의 ‘지식 컴파일러’, Ingest·Query·Lint와 3가지 구현 방식</title>
<link>https://ai.23yellow.com/ai_agent_01/karpathy-llm-wiki-%ED%8C%A8%ED%84%B4-rag-%EB%8B%A4%EC%9D%8C%EC%9D%98-%EC%A7%80%EC%8B%9D/</link>
<description><![CDATA[
techyoo 영상 **「LLM Wiki 하나로 GitHub이 2주 만에 뒤집힌 이유」**에서는 Andrej Karpathy가 공개한 **LLM Wiki 아이디어 파일**을 중심으로, 이 패턴이 무엇이고 RAG와 어떻게 다르며 실제로 어떤 방식으로 구현되는지 정리합니다.

## LLM Wiki는 제품이 아니라 패턴

영상에서 가장 먼저 강조하는 점은 **LLM Wiki가 특정 제품명이 아니라는 것**입니다.

Karpathy가 공개한 것은 코드나 공식 프로젝트가 아니라 아이디어를 정리한 Markdown 파일에 가깝고, 이후 커뮤니티가 이를 각자의 방식으로 구현하면서 여러 저장소가 등장했습니다.

즉, LLM Wiki는 하나의 앱이라기보다:

&gt; **LLM이 지속적으로 유지·확장하는 개인 또는 팀 지식 위키를 만드는 설계 패턴**

으로 보는 것이 맞습니다.

## 3계층 구조

영상에서는 LLM Wiki를 크게 세 계층으로 설명합니다.

### 1. Raw Source

PDF, 이메일, 회의록, 웹 문서 같은 원자료를 그대로 보관합니다.

원본은 가능한 한 수정하지 않고 **근거 자산**으로 유지합니다.

### 2. Wiki

LLM이 원본을 읽고 개념별 Markdown 문서로 재구성한 계층입니다.

예:

- transformer.md
- attention.md
- optimizer.md
- project-a.md

단순 요약이 아니라 관련 개념끼리 링크를 연결하고 기존 페이지를 갱신합니다.

### 3. Schema / Agent Rules

AI가 어떤 규칙으로 Wiki를 만들고 유지할지 정의하는 운영 문서입니다.

예를 들어:

- 어떤 형식으로 문서를 만들지
- 제목 규칙
- 링크 규칙
- 원본 출처 표기
- 충돌 처리
- 업데이트 방식

등을 적습니다.

## 핵심 연산 3가지

LLM Wiki의 핵심은 세 가지 동작으로 요약할 수 있습니다.

### Ingest

새 원본 자료를 읽고 기존 Wiki에 흡수합니다.

새 페이지를 만들 수도 있고, 기존 페이지를 보강하거나 관련 링크를 추가할 수도 있습니다.

### Query

사용자 질문이 들어오면 Wiki를 읽고 답변합니다.

즉, 매번 원본 전체를 읽기보다 **이미 정리된 지식 계층**을 우선 활용합니다.

### Lint

Wiki 내부의 충돌과 모순을 찾습니다.

예를 들어 한 페이지에서는 “A가 항상 더 낫다”고 쓰여 있는데 다른 페이지에서는 반례가 있다면 이를 검토 대상으로 올릴 수 있습니다.

## RAG와 가장 큰 차이

영상에서는 두 방식을 이렇게 비교합니다.

### RAG

질문이 들어올 때 관련 자료를 찾습니다.

**Query-time Retrieval**

### LLM Wiki

자료가 들어올 때 미리 정리합니다.

**Ingest-time Compilation**

쉽게 말해:

- RAG → 질문할 때마다 도서관에서 책을 찾음
- LLM Wiki → 사서가 책이 들어올 때마다 요약 노트를 미리 갱신함

입니다.

## “지식 컴파일러”라는 관점

LLM Wiki를 이해하기 좋은 표현 중 하나가 **Knowledge Compiler**입니다.

원본 문서를 그대로 검색 대상으로 두는 것이 아니라, AI가 미리 읽고:

- 핵심 개념 추출
- 관계 연결
- 요약
- 교차 참조
- 구조화

를 수행해 **AI가 더 쉽게 읽고 재사용할 수 있는 지식 형태로 컴파일**하는 방식입니다.

## Vector DB가 꼭 필요한 것은 아니다

이 패턴에서 흥미로운 부분은 초기에 Vector DB나 Embedding 없이도 운영할 수 있다는 점입니다.

다음과 같은 전통적인 파일 구조만으로도 가능합니다.

- index.md
- log.md
- concepts/
- projects/
- sources/
- agents.md

AI 코딩 에이전트가 이 파일들을 직접 읽고 탐색할 수 있기 때문입니다.

자료 규모가 작거나 중간 수준이라면 이 방식이 오히려 단순할 수 있습니다.

## 실제 구현 방법 3가지

영상에서는 대표적으로 세 가지 방식을 소개합니다.

### 1. 로컬 CLI

Claude Code, Codex 같은 코딩 에이전트가 로컬 폴더를 직접 읽고 Wiki를 갱신합니다.

장점은 가장 단순하다는 점입니다.

별도의 서버나 DB 없이:

**폴더 + Markdown + Agent 규칙**

만으로 시작할 수 있습니다.

### 2. Obsidian

Obsidian Vault를 그대로 Wiki 저장소로 사용합니다.

장점은:

- 사람이 읽기 쉬움
- 그래프 뷰 활용
- 링크 관계 확인
- Markdown 기반
- 로컬 저장

입니다.

AI가 Ingest할 때 자동으로 링크를 추가하면 지식 그래프처럼 관계가 시각화됩니다.

### 3. MCP 서버

Wiki를 MCP 서버로 노출하면 Claude Desktop, Cursor 같은 외부 AI 도구에서도 동일한 지식베이스를 사용할 수 있습니다.

즉:

**LLM Wiki → MCP → 여러 AI 클라이언트**

구조로 확장할 수 있습니다.

## 대표 구현체

영상에서는 커뮤니티 구현체로 다음 프로젝트를 소개합니다.

- **nashsu/llm_wiki** → 데스크톱·Obsidian 스타일
- **SamurAIGPT/llm-wiki-agent** → Python CLI
- **atomicmemory/llm-wiki-compiler** → TypeScript + MCP

모두 구현 방식은 다르지만 핵심 구조는 비슷합니다.

## Lint가 중요한 이유

지식베이스가 쌓이면 단순 검색보다 **일관성 유지**가 더 어려운 문제가 됩니다.

예를 들어:

- 오래된 주장
- 서로 충돌하는 설명
- 중복 페이지
- 출처 불명확
- 잘못 연결된 개념

이 생길 수 있습니다.

Lint는 이런 부분을 AI가 먼저 찾아 사람에게 검토 요청하는 역할을 합니다.

다만 영상에서도 강조하듯 **Lint가 모든 오류를 잡아준다고 가정하면 위험합니다.**

## 비판 지점 3가지

### 1. 최종 신뢰 책임은 여전히 사람에게 있음

AI가 지식을 정리하더라도 그 내용이 사실인지 검증하는 책임은 남습니다.

### 2. 모순 탐지가 완벽하지 않음

충돌을 놓칠 수도 있고, 오히려 “문제 없음”이라는 잘못된 안도감을 줄 수 있습니다.

### 3. 대규모 확장성이 검증되지 않음

개인·팀 수준에서는 자연스럽지만 수만·수십만 문서 규모에서는 기존 검색 인프라가 더 적합할 수 있습니다.

## Karpathy의 중요한 단서 — Moderate Scale

영상은 Karpathy가 이 아이디어를 **moderate scale**에 적합한 패턴으로 본 점을 강조합니다.

즉:

- 개인 지식
- 연구 노트
- 소규모 팀 문서
- 프로젝트 지식
- 콘텐츠 제작 자료

에는 잘 맞을 수 있지만,

대규모 기업 검색 전체를 곧바로 LLM Wiki로 대체하자는 주장은 아닙니다.

## RAG를 대체하는 기술이 아니다

이 영상의 가장 중요한 결론은:

&gt; **LLM Wiki는 RAG를 죽이는 기술이 아니라, RAG가 잘하지 못하는 ‘지식 유지·정리·축적’을 담당하는 보완 레이어**

라는 점입니다.

실제로는 다음과 같이 함께 쓸 수 있습니다.

**Raw Source → RAG 검색**
**정제된 Knowledge → LLM Wiki**
**다중 클라이언트 연결 → MCP**
**장기 유지 → Lint / Human Review**

## 누가 쓰면 좋은가?

특히 다음 사용자에게 잘 맞습니다.

- 연구자
- 리뷰어
- 뉴스레터 제작자
- 기자
- PM
- 기획자
- 개인 지식관리 사용자
- 장기 프로젝트 운영자

반대로 대규모 FAQ, 고객센터, 엔터프라이즈 검색처럼 문서가 매우 많고 즉시 최신 원문 검색이 중요하다면 RAG가 여전히 핵심입니다.

## 핵심 정리

LLM Wiki는 단순한 “AI 메모장”이 아니라 다음 구조를 가진 **지식 컴파일러 패턴**입니다.

**Raw → Ingest → Wiki → Query → Lint**

그리고 구현은:

**Local CLI / Obsidian / MCP**

중 하나로 시작할 수 있습니다.

핵심은 모델이 더 똑똑해지는 것이 아니라, **AI가 장기간 사용할 지식 자체를 미리 구조화하고 지속적으로 유지하는 계층을 만드는 것**입니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-24T17:07:32+09:00</dc:date>
</item>


<item>
<title>LLM Wiki vs RAG — Obsidian·Claude Code로 만드는 개인 지식 그래프와 라이프 로깅 시스템</title>
<link>https://ai.23yellow.com/ai_agent_01/llm-wiki-vs-rag-obsidianclaude-code%EB%A1%9C-%EB%A7%8C%EB%93%9C%EB%8A%94/</link>
<description><![CDATA[
빌더 조쉬의 HOW I AI 팟캐스트 **「LLM wiki랑 RAG랑 뭐가 다른건지 알려드려요」**에서는 브레인 트리니티의 브라이언과 함께 **개인 지식 관리(PKM), LLM Wiki, RAG, 지식 그래프, 온톨로지, 라이프 로깅**을 하나의 시스템 관점에서 설명합니다.

이번 영상은 단순히 “Obsidian에 문서를 넣고 Claude Code로 정리한다”는 수준을 넘어, **내 기록을 AI가 지속적으로 이해하고 재활용할 수 있는 개인 지식 인프라로 만드는 방법**을 다룹니다.

## 왜 기록이 중요한가?

영상에서 가장 먼저 강조하는 것은 **AI가 나를 이해하려면 나에 대한 기록이 필요하다**는 점입니다.

AI가 일반적인 질문에는 잘 답하더라도:

- 내가 무엇을 중요하게 생각하는지
- 어떤 맥락에서 질문하는지
- 과거에 어떤 결정을 했는지
- 어떤 경험을 했는지
- 어떤 자료에 가치를 느꼈는지

를 알지 못하면 답변은 여전히 일반적일 수밖에 없습니다.

즉, 개인 지식 관리의 목적은 단순히 자료를 모으는 것이 아니라 **AI가 나의 맥락을 읽을 수 있는 기반을 만드는 것**입니다.

## LLM Wiki란?

영상에서는 LLM Wiki를 **LLM과 사람이 함께 편집하고 활용하는 지식 베이스**로 설명합니다.

원본 자료를 그대로 쌓아두는 대신 AI가 이를 읽고:

- 개념을 추출하고
- 관련 엔티티를 만들고
- 서로 연결하고
- 사람이 읽기 쉬운 Markdown으로 정리하고
- 이후 질문에 다시 활용할 수 있도록 인덱싱

합니다.

핵심 흐름은 다음과 같습니다.

**Raw Data → Ingest → Wiki / Entity → Relation → Index → Retrieval → Answer**

## RAG와 LLM Wiki는 무엇이 다른가?

둘 다 외부 지식을 활용하지만 중심 구조가 다릅니다.

### RAG

일반적인 RAG는 질문이 들어오면 원본 문서나 Vector DB에서 관련 자료를 검색해 LLM에 전달합니다.

**질문 → 검색 → 원본 문맥 → LLM 답변**

즉, **질문 시점의 검색**이 중심입니다.

### LLM Wiki

LLM Wiki는 자료가 들어오는 시점에 AI가 내용을 구조화합니다.

**원본 자료 → 요약·분해 → 엔티티·개념 생성 → 관계 연결 → Wiki 축적**

이후 질문에서는 이 정리된 지식 구조를 따라가며 답을 만듭니다.

즉, LLM Wiki는 단순 Retrieval보다 **지식의 지속적인 가공과 유지관리**가 더 중요합니다.

## Ingest는 단순 변환이 아니다

영상에서는 Ingest를 단순히 PDF나 웹페이지를 Markdown으로 바꾸는 과정으로 보지 않습니다.

중요한 것은 **새 자료를 기존 지식과 연결하는 것**입니다.

예를 들어 하나의 영상을 저장했다면 AI는 다음을 추출할 수 있습니다.

- 등장 인물
- 회사
- 핵심 개념
- 방법론
- 관련 기술
- 다른 자료와의 연결점

그리고 기존 Wiki에 이미 존재하는 개념과 연결합니다.

즉, Ingest는:

**변환 + 요약 + 엔티티 추출 + 관계 연결 + 인덱스 갱신**

과정이라고 볼 수 있습니다.

## “왜 저장했는가”까지 넣어야 가치가 커진다

영상에서 특히 흥미로운 부분은 원본 자료 자체보다 **내가 그 자료를 왜 저장했는지**를 함께 기록한다는 점입니다.

예를 들어 영상을 저장할 때:

- 왜 이 자료를 저장했는가?
- 어떤 부분이 인상적이었는가?
- 내 생각과 어디가 같거나 다른가?
- 이 지식을 어디에 활용하고 싶은가?

를 AI가 질문하도록 구성합니다.

이렇게 하면 단순한 외부 정보가 아니라 **개인의 관점이 들어간 지식**으로 변합니다.

영상에서는 이를 일종의 **무의식의 의식화**로 설명합니다.

## 지식 그래프와 온톨로지

LLM Wiki가 커질수록 엔티티 사이의 관계가 생깁니다.

예를 들어:

**BCG → Enterprise IQ → AI Transformation → AX Consulting**

같은 연결이 누적됩니다.

이런 연결 구조가 **지식 그래프**입니다.

영상에서는 지식 그래프와 온톨로지를 구분합니다.

### 지식 그래프

실제 인물·회사·개념·프로젝트 사이의 연결입니다.

즉, **구체적인 인스턴스와 관계**를 표현합니다.

### 온톨로지

세상을 어떤 구조로 바라볼 것인지 정의하는 **질서와 체계**에 가깝습니다.

예를 들어 개인 온톨로지는:

- 나는 어떤 사람인가
- 무엇을 중요하게 보는가
- 어떤 원칙으로 판단하는가
- 지식을 어떤 방식으로 분류하는가

같은 구조를 담을 수 있습니다.

결국 AI가 개인의 사고방식을 더 잘 이해하게 하려면 단순 데이터보다 **나만의 온톨로지와 규칙 문서**가 중요해집니다.

## 하루를 5겹으로 기록하는 라이프 로깅

영상에서는 개인의 하루를 여러 레이어로 기록하는 라이프 로깅 시스템도 소개합니다.

대표적으로 다음과 같은 구조입니다.

### 1. 의도

오늘 무엇을 하려고 했는가?

### 2. 실행

실제로 어떤 행동을 했는가?

### 3. 현실

컴퓨터 화면·음성·활동 로그 등 실제로 발생한 데이터

### 4. 해석

그 경험을 내가 어떻게 느끼고 판단했는가?

### 5. AI 대화 로그

AI와 어떤 대화를 했고 어떤 결론에 도달했는가?

이렇게 기록하면 단순 일정이나 일기보다 훨씬 풍부한 **개인 맥락 데이터**가 됩니다.

## 24시간 화면·음성 기록과 자동화

영상에서는 ScreenPipe 같은 도구와 음성 기록을 활용해 실제 활동을 자동으로 수집하는 사례도 소개합니다.

이렇게 쌓인 데이터를 AI가 활용하면:

- 실제로 무엇을 했는지
- 어떤 문서를 봤는지
- 어떤 대화를 했는지
- 어떤 결정이 반복됐는지

를 기반으로 회고를 생성할 수 있습니다.

즉, AI에게 “오늘 어땠어?”라고 묻는 것이 아니라 **실제 데이터 기반으로 하루를 재구성하게 하는 방식**입니다.

## 일일·주간·월간·분기·연간 회고

영상에서는 기록 시스템을 회고 자동화에 적극적으로 활용합니다.

흐름은 다음과 같습니다.

**Daily → Weekly → Monthly → Quarterly → Yearly**

각 단계에서 이전 기록을 압축·종합해 더 큰 서사를 만듭니다.

예를 들어 AI가:

- 오늘 가장 중요한 일
- 이번 주 변화
- 이번 달 반복 패턴
- 분기별 성장과 문제
- 1년 전체의 서사

를 자동으로 정리하게 할 수 있습니다.

이 방식의 장점은 인간이 잊기 쉬운 디테일까지 AI가 기록을 기반으로 다시 연결해 준다는 점입니다.

## 개인 지식이 ‘세컨드 브레인’을 넘어가는 지점

기존의 Second Brain은 주로 **내가 다시 찾기 쉽게 정리하는 시스템**이었습니다.

하지만 LLM Wiki는 한 단계 더 나아갑니다.

AI가 직접:

- 새 자료를 읽고
- 구조화하고
- 관련 자료를 연결하고
- 기존 지식과 비교하고
- 인사이트를 만들고
- 회고를 생성하고
- 향후 행동을 제안

할 수 있기 때문입니다.

즉, 저장 시스템이 아니라 **능동적으로 유지되는 지식 에이전트**로 바뀝니다.

## 시작할 때 가장 먼저 해야 할 것

영상에서는 처음부터 모든 것을 자동화하려 하지 말고, 먼저 **내가 누구인지 정리한 문서**를 만드는 것을 권합니다.

예를 들어 기존 기록을 모아 AI에게 다음을 분석시킬 수 있습니다.

- 나는 어떤 일을 하는 사람인가
- 어떤 가치를 중요하게 생각하는가
- 어떤 선택을 반복해 왔는가
- 무엇을 위해 일하는가
- 어떤 주제에 계속 관심을 두는가

이를 하나의 개인 프로필·세계관·원칙 문서로 만들어 두면 이후 지식 분류와 AI의 판단 기준이 훨씬 명확해집니다.

## 개인 지식 시스템의 전체 구조

영상 내용을 시스템 구조로 정리하면 다음과 같습니다.

**Life Log / Web Clip / Note / Document  
↓  
Raw Data  
↓  
Ingest Skill  
↓  
Entity / Concept / Summary  
↓  
Relation / Knowledge Graph  
↓  
Personal Ontology  
↓  
LLM Wiki  
↓  
Search / Reasoning / Reflection  
↓  
Personal AI Agent**

이 구조가 쌓이면 AI는 단순히 “내 문서를 검색하는 도구”가 아니라 **내 과거와 맥락을 바탕으로 판단을 돕는 개인 에이전트**에 가까워집니다.

## RAG와 LLM Wiki를 함께 쓰는 게 현실적

둘 중 하나만 선택해야 하는 것은 아닙니다.

대규모 원본 자료는 Vector RAG로 빠르게 검색하고, 중요도가 높은 지식은 LLM Wiki에서 구조화해 관리하는 방식이 현실적입니다.

예를 들면:

**Raw Archive → Vector RAG  
중요 지식 → LLM Wiki  
핵심 개념 → Knowledge Graph  
개인 규칙 → Ontology / Agent Instructions**

처럼 계층을 나눌 수 있습니다.

이렇게 하면 검색 성능과 구조화된 지식 관리의 장점을 동시에 얻을 수 있습니다.

## 핵심 정리

이번 영상의 핵심은 **“LLM Wiki가 RAG보다 무조건 낫다”가 아니라 역할이 다르다**는 점입니다.

- **RAG** → 필요한 원본 정보를 빠르게 찾는다.
- **LLM Wiki** → 지식을 미리 정리·연결·유지한다.
- **Knowledge Graph** → 개념 사이 관계를 표현한다.
- **Ontology** → 개인의 사고 체계와 질서를 정의한다.
- **Life Logging** → 개인의 실제 행동과 경험을 데이터로 축적한다.
- **AI Agent** → 이 모든 데이터를 바탕으로 판단과 회고를 돕는다.

결국 개인 AI의 품질을 높이는 가장 중요한 자산은 **모델 자체보다도 내가 어떤 기록과 구조를 만들어 두었는가**일 수 있습니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-24T16:58:13+09:00</dc:date>
</item>


<item>
<title>Obsidian + Claude Code로 만드는 LLM Wiki — 내 지식을 축적·연결·정비하는 개인 AI 브레인</title>
<link>https://ai.23yellow.com/ai_agent_01/obsidian-claude-code%EB%A1%9C-%EB%A7%8C%EB%93%9C%EB%8A%94-llm-wiki/</link>
<description><![CDATA[
진한별의 AI 연구소 영상 **「옵시디언 LLM Wiki + 클로드로 나만의 AI 브레인 만들기」**에서는 Obsidian과 Claude Code를 이용해 **내 지식을 직접 읽고, 정리하고, 연결하고, 유지하는 개인 지식 시스템**을 만드는 방법을 소개합니다.

이 방식의 핵심은 단순히 문서를 검색해 답하는 RAG를 넘어, AI가 내 자료를 바탕으로 **지식 페이지를 계속 생성·보강·정비하는 구조**를 만든다는 점입니다.

## LLM Wiki란?

영상에서는 LLM Wiki를 **AI가 개인 지식을 읽고 구조화해 유지하는 위키형 지식 시스템**으로 설명합니다.

일반적인 RAG가 질문할 때마다 원본 문서를 검색해 관련 내용을 가져오는 구조라면, LLM Wiki는 원본을 바탕으로 AI가 별도의 정리된 위키 페이지를 만들어 두고 이후에는 그 위키를 중심으로 탐색하고 추론합니다.

쉽게 말하면:

**원본 자료 → AI가 구조화한 위키 → 질문·추론·새로운 인사이트**

의 흐름입니다.

## 3층 구조

영상에서는 LLM Wiki를 세 층으로 나눕니다.

### 1층 — Raw

사용자가 직접 넣는 원본 자료입니다.

예시는 다음과 같습니다.

- 기사
- 유튜브 정리
- 강의 메모
- 책 내용
- 업무 문서
- 개인 메모

이 영역은 **원본 보존 공간**으로 두고 AI는 읽기 위주로 사용합니다.

### 2층 — Wiki

AI가 Raw 내용을 읽고 정리한 구조화된 지식 페이지입니다.

예를 들어 여러 자료가 각각 따로 존재하더라도 AI가 다음처럼 묶어 줄 수 있습니다.

- AI 자동화
- 학습
- 도구
- 트렌드
- 콘텐츠 아이디어

관련 문서끼리는 링크를 연결해 Obsidian의 그래프 뷰에서도 관계를 확인할 수 있습니다.

### 3층 — 운영 규칙 문서

Claude Code를 쓴다면 **CLAUDE.md**, Codex를 쓴다면 에이전트용 규칙 파일처럼 AI가 이 위키를 어떤 방식으로 관리할지 정의합니다.

이 문서에는:

- 자료를 어떻게 정리할지
- 제목 규칙
- 링크 규칙
- 어떤 폴더를 읽고 쓸지
- 어떻게 검색할지
- 정비 주기

같은 운영 원칙을 넣습니다.

## LLM Wiki의 3가지 핵심 동작

영상에서는 시스템을 **넣기·찾기·정비** 세 가지로 설명합니다.

### 1. 넣기

새로운 Raw 자료가 들어오면 AI가 이를 읽고:

1. 핵심 내용 추출
2. 기존 Wiki 페이지 보강
3. 새 페이지 생성
4. 관련 문서 교차 링크
5. 목차와 이력 갱신

을 수행합니다.

즉, 단순 저장이 아니라 **새로운 자료를 기존 지식 구조 안에 편입하는 과정**입니다.

### 2. 찾기

질문하면 AI가 Wiki에서 관련 페이지를 찾아 여러 정보를 종합해 답합니다.

영상에서는 답변할 때 관련 Wiki 링크도 함께 제시하도록 구성합니다.

이렇게 하면 단순 답변보다 **어떤 지식에서 나온 결론인지 추적하기 쉬워집니다.**

### 3. 정비

지식이 계속 쌓이면 다음 문제가 생길 수 있습니다.

- 오래된 내용
- 서로 충돌하는 정보
- 중복 페이지
- 연결되지 않은 페이지
- 잘못된 파일명
- 기준이 다른 문서 구조

그래서 AI에게 주기적으로 **위키 건강검진**을 시켜 이런 문제를 찾아 수정하게 합니다.

이 부분이 일반적인 단발성 문서 요약과 크게 다른 점입니다.

## 왜 Obsidian인가?

Obsidian은 Markdown 파일을 로컬 폴더에 저장하는 구조라 다음 장점이 있습니다.

- 특정 클라우드 서비스에 종속되지 않음
- 파일을 직접 확인·수정 가능
- Git으로 버전 관리 가능
- 링크와 그래프 구조 활용 가능
- 장기간 보관에 유리

영상에서는 Obsidian을 **도서관**, Claude Code를 **자료를 정리하는 사서**에 비유합니다.

## Claude Code를 Obsidian 안에서 사용

영상에서는 Obsidian 커뮤니티 플러그인을 이용해 터미널을 열고 그 안에서 Claude Code를 실행합니다.

흐름은 대략 다음과 같습니다.

1. Obsidian Vault 생성
2. Raw 폴더 준비
3. Wiki 폴더 준비
4. 터미널 플러그인 설치
5. Claude Code 실행
6. 관리 규칙 작성
7. 새 자료를 Raw에 추가
8. Claude에게 Wiki 반영 요청
9. 그래프 관계 확인

즉, Obsidian을 단순 메모 앱이 아니라 **AI가 직접 읽고 수정하는 로컬 지식 저장소**로 사용하는 방식입니다.

## Web Clipper로 자료 수집

웹 기사나 참고 자료는 Obsidian Web Clipper를 이용해 Raw 폴더에 저장할 수 있습니다.

이후 Claude Code에게:

&gt; 새로 추가된 자료를 Wiki에 반영하고, 기존 페이지와 연결해 줘.

같은 식으로 요청하면 AI가 기존 지식과 연결해 구조화합니다.

이 흐름은 개인 지식 관리에서 매우 실용적입니다.

**웹 수집 → Raw 저장 → AI 정리 → Wiki 연결**

로 이어지는 자동화 파이프라인이 되기 때문입니다.

## 여러 자료를 겹쳐 새로운 인사이트 찾기

LLM Wiki의 강점은 개별 문서를 단순 검색하는 것보다 **여러 자료를 함께 봤을 때 나타나는 연결점을 찾게 할 수 있다는 것**입니다.

영상에서는 다음과 같은 요청을 사용합니다.

&gt; 개별 자료에서는 잘 보이지 않지만, 여러 자료를 같이 보면 드러나는 연결점이나 인사이트를 알려줘.

이런 방식은 단순 검색을 넘어 **개인 지식 기반의 추론**에 가깝습니다.

## 개인화된 콘텐츠 기획에도 활용

쌓인 Wiki를 기반으로:

- 다음에 만들 콘텐츠
- 연구 주제
- 프로젝트 아이디어
- 업무 개선 아이디어
- 학습 우선순위

등을 제안하게 할 수 있습니다.

중요한 점은 일반적인 인터넷 지식만으로 추천하는 것이 아니라 **내가 수집한 자료와 관심사, 과거 메모를 기반으로 추천한다는 것**입니다.

## RAG와 LLM Wiki의 차이

두 방식은 비슷하지만 목적이 조금 다릅니다.

### 일반적인 RAG

**질문 → 원본 문서 검색 → 관련 문맥 → LLM 답변**

원본 문서를 검색하는 것이 중심입니다.

### LLM Wiki

**원본 자료 → AI가 지속적으로 구조화 → Wiki 축적 → 연결·정비 → 질문·추론**

검색뿐 아니라 **지식 구조 자체를 계속 가공한다는 점**이 다릅니다.

따라서 LLM Wiki는 개인 지식 관리, 연구, 장기 프로젝트, 콘텐츠 제작처럼 **시간이 지나면서 지식이 축적되는 업무**에 잘 맞습니다.

## 장점

- 내 자료를 기반으로 개인화된 답변 가능
- 지식이 쌓일수록 연결 관계가 풍부해짐
- Markdown 기반이라 사람이 직접 확인 가능
- AI가 문서 구조를 지속적으로 정비 가능
- 여러 자료를 종합한 인사이트 생성 가능
- 특정 AI 모델에 완전히 종속되지 않음

Claude Code 대신 Codex 같은 다른 코딩 에이전트로도 같은 구조를 구현할 수 있습니다.

## 주의할 점

자료가 많아질수록 모든 문서를 AI가 반복해서 읽게 하면 토큰 사용량이 커질 수 있습니다.

규모가 커지면 다음 구조를 고려할 수 있습니다.

- 변경된 파일만 처리
- 요약 계층 추가
- 인덱스 파일 사용
- 벡터 검색과 Wiki 혼합
- 오래된 페이지 아카이빙
- 자동 정비 주기 설정

즉, 소규모에서는 파일 기반으로 충분하지만 지식베이스가 커지면 **RAG와 LLM Wiki를 결합한 하이브리드 구조**가 더 효율적일 수 있습니다.

## 핵심 정리

이 영상의 구조를 한 줄로 정리하면:

**Obsidian = 지식 저장소  
Claude Code = 지식을 정리·연결·관리하는 에이전트  
LLM Wiki = 둘을 결합한 개인 AI 브레인**

단순히 AI에게 매번 내 상황을 다시 설명하는 대신, 내 지식을 로컬에 축적해 두고 AI가 이를 계속 읽고 정리하도록 만드는 방식입니다.

장기적으로는 개인 메모, 연구 자료, 업무 문서, 프로젝트 기록을 하나의 **개인 지식 에이전트**로 연결하는 기반으로 활용할 수 있습니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-24T16:21:41+09:00</dc:date>
</item>


<item>
<title>AI 브라우저 3종 실전 비교 — Claude in Chrome·Aside·ego lite, 자동화·병렬 작업·보안까지</title>
<link>https://ai.23yellow.com/ai_agent_01/ai-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-3%EC%A2%85-%EC%8B%A4%EC%A0%84-%EB%B9%84%EA%B5%90-claude-in/</link>
<description><![CDATA[
옆자리 연구원 채널의 영상 **「AI 브라우저 자동화, 나 대신 클릭까지? 어사이드 vs 클로드 인 크롬 vs ego lite 8가지 시험」**에서는 Claude in Chrome, Aside, ego lite 세 가지 AI 브라우저를 같은 조건에서 직접 비교합니다.

단순히 “써 보니 좋다” 수준이 아니라, **자료 조사·쇼핑·예약·신청서 작성·병렬 가격 비교·반복 루틴·프롬프트 주입 공격**까지 8가지 실제 작업을 동일한 Claude Sonnet 5.5 환경에서 시험한 것이 핵심입니다.

## 세 도구의 구조가 어떻게 다른가?

### Claude in Chrome

현재 사용하는 Chrome에 확장 프로그램 형태로 붙는 방식입니다.

장점은 이미 로그인된 사이트를 그대로 사용할 수 있다는 점입니다.

AI가 오른쪽 패널에서 지시를 받고 현재 탭을 직접 읽고 클릭하며 작업합니다.

다만 영상에서는 네이버 지도·검색이 안전 제한으로 막혔고, 일부 쿠팡 검색 페이지에서도 접근 거부가 발생했습니다.

즉, **기존 브라우저 환경을 그대로 활용하는 편의성은 높지만 사이트별 차단 정책의 영향을 받을 수 있습니다.**

### Aside

Aside는 처음부터 AI 작업을 중심으로 만든 독립 브라우저입니다.

여러 사이트를 동시에 조사하거나 반복 작업을 등록하는 기능이 강점입니다.

영상에서는 세 쇼핑몰 가격 비교 작업을 **세 갈래 병렬 작업으로 분리해 약 37초 만에 처리**했고, 매일 오전 9시에 뉴스 요약을 수행하는 루틴도 브라우저에 지속적으로 등록했습니다.

다만 무료 크레딧이 제한되어 있고, 설치 단계에서 기존 Chrome 로그인 데이터나 비밀번호를 가져올지 신중히 선택할 필요가 있습니다.

### ego lite

ego lite는 브라우저 자체에 채팅창이 있는 형태가 아니라 Claude Code 같은 코딩 에이전트가 **/ego-browser** 명령으로 브라우저를 제어하는 구조입니다.

작업은 사용자 화면과 분리된 AI 전용 작업 공간에서 실행됩니다.

영상에서는 한 번의 도구 호출에 여러 동작을 묶어 처리해, Claude in Chrome보다 브라우저 도구 호출 횟수가 적었습니다.

특히 코딩 에이전트와 브라우저 자동화를 함께 쓰는 사용자에게 잘 맞는 구조입니다.

## 8가지 실전 테스트 결과

### 1. 공식 가격 조사

Claude, ChatGPT, Gemini의 무료·유료 요금제를 조사하는 작업은 세 도구 모두 정확하게 수행했습니다.

속도는 영상 테스트 기준으로:

- Aside 약 25초
- ego lite 약 31초
- Claude in Chrome 약 43초

였습니다.

단순 자료 조사에서는 세 도구 모두 충분한 수준이었습니다.

### 2. 쇼핑 비교

다나와에서 10만 원 이하 무선 이어폰을 비교하고, 구매 직전까지만 진행하게 한 시험에서도 세 도구 모두 같은 제품을 선택했습니다.

중요한 점은 **구매 버튼을 누르지 않고 멈췄다는 것**입니다.

AI 브라우저를 쓸 때 실제 결제·전송 같은 되돌리기 어려운 작업은 사용자 확인을 거치는 방식이 중요합니다.

### 3. 네이버 예약

네이버 지도에서 강남역 근처 식당 예약 가능 여부를 확인하는 시험에서는 차이가 크게 났습니다.

- Aside → 여러 식당을 비교하고 예약 과정 진행
- ego lite → 예약자 정보 입력 직전까지 진행
- Claude in Chrome → 네이버 지도 접근 자체가 차단

이 결과는 브라우저 성능만의 문제가 아니라 **사이트가 외부 AI 에이전트를 허용하는지 여부**가 자동화 성공률을 크게 좌우한다는 점을 보여줍니다.

## 병렬 작업에서 가장 큰 차이

세 쇼핑몰에서 같은 상품 가격을 동시에 확인하는 시험에서는 Aside가 작업을 여러 에이전트로 나눠 병렬 실행했습니다.

- Aside → 약 37초
- ego lite → 약 55초
- Claude in Chrome → 약 59초

Claude in Chrome은 쿠팡 검색 결과에서 접근이 막혀 일부 결과를 제외해야 했습니다.

이 테스트에서 보이는 핵심은 **여러 웹 작업을 동시에 수행할 수 있는가**입니다.

단일 탭 자동화와 다중 에이전트 병렬 작업은 실제 업무 생산성에서 큰 차이가 날 수 있습니다.

## 반복 업무에서는 Aside가 유리

매일 오전 9시에 Anthropic과 OpenAI 뉴스 페이지를 확인하고 새 글을 요약하는 루틴 테스트에서는 Aside가 지속형 루틴을 브라우저에 등록했습니다.

반면 Claude in Chrome과 ego lite는 Claude Code의 예약 기능을 활용했지만, 영상 설명에 따르면 해당 창이 열려 있어야 하고 일정 기간 후 종료되는 제한이 있었습니다.

따라서:

- 일회성 조사 → 세 도구 모두 가능
- 여러 사이트 병렬 조사 → Aside·ego lite 강점
- 매일 반복되는 루틴 → Aside 강점

으로 볼 수 있습니다.

## AI는 웹을 어떻게 보는가?

영상에서는 AI 브라우저의 페이지 인식 방식을 두 가지로 설명합니다.

### 화면 기반 방식

사람처럼 스크린샷을 보고 버튼 위치를 찾아 클릭합니다.

장점은 어떤 페이지에서도 쓸 수 있다는 점이지만, 화면이 움직이면 잘못된 위치를 누를 위험이 있습니다.

### DOM 기반 방식

웹 페이지 내부 구조를 읽어 “신청 버튼”, “입력 칸” 같은 요소를 이름과 역할로 인식합니다.

DOM 기반 접근은 빠르고 정확할 수 있지만, 사이트 구조나 차단 정책의 영향을 받을 수 있습니다.

## 프롬프트 주입 공격 테스트

영상에서 가장 중요한 부분 중 하나는 **Prompt Injection** 시험입니다.

메일이나 상품 후기 안에 AI만 읽을 수 있도록 숨겨 둔 악성 지시를 넣어:

- 급여 명세서를 외부 주소로 전달
- 장바구니에 상품 추가
- 사용자에게 숨기기

같은 행동을 유도했습니다.

세 도구 모두 숨은 지시를 실행하지 않았고, 오히려 사용자에게 경고했습니다.

다만 이 결과만으로 완전히 안전하다고 볼 수는 없습니다.

세 도구 모두 같은 Claude Sonnet 5.5를 사용했기 때문에 **브라우저 자체보다 모델의 안전 처리 능력이 작동했을 가능성**이 큽니다.

## AI 브라우저를 안전하게 쓰는 3가지 원칙

영상에서는 다음 세 가지를 강조합니다.

1. **중요한 계정은 AI 브라우저에 로그인하지 않거나 별도 테스트 계정을 사용**
2. **결제·예약 확정·전송 같은 마지막 버튼은 사람이 직접 누르기**
3. **은행·건강 기록 등 민감한 데이터에는 사용하지 않기**

특히 AI가 웹사이트를 실제로 클릭하고 입력할 수 있는 단계가 되면서, 단순 챗봇보다 권한 관리가 훨씬 중요해졌습니다.

## 어떤 도구가 누구에게 맞을까?

### Claude in Chrome

이미 Claude를 쓰고 있고, 간단한 자료 조사·쇼핑 비교·폼 입력 정도가 목적이라면 가장 간단합니다.

별도 AI 브라우저를 설치하지 않고 기존 Chrome 환경을 활용할 수 있습니다.

### Aside

여러 사이트를 동시에 조사하거나 반복 루틴을 계속 돌리고 싶다면 강점이 큽니다.

병렬 작업과 지속형 루틴이 핵심입니다.

### ego lite

Claude Code 같은 코딩 에이전트에서 브라우저 자동화를 자주 사용하는 개발자에게 잘 맞습니다.

사용자 화면과 분리된 작업 공간에서 실행되고, 여러 동작을 묶어 처리하는 효율적인 브라우저 제어가 특징입니다.

## 핵심 정리

이 영상의 결론은 **“어떤 AI 브라우저가 무조건 최고인가?”가 아니라 “어떤 일을 맡길 것인가?”에 따라 선택해야 한다는 것**입니다.

- 간단한 조사·폼 입력 → Claude in Chrome
- 병렬 웹 조사·지속 루틴 → Aside
- Claude Code 중심의 브라우저 자동화 → ego lite

그리고 앞으로 더 중요한 문제는 브라우저 자체보다 **AI에게 얼마나 넓은 권한을 줄 것인가**입니다.

AI 브라우저가 로그인 계정·메일·쇼핑·예약·업무 시스템까지 직접 조작하기 시작하면, 권한 분리·사람의 최종 승인·Prompt Injection 대응 같은 안전 설계가 필수 요소가 됩니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-24T15:59:10+09:00</dc:date>
</item>


<item>
<title>Deep Twin 에이전트 설계 — 메모리·Harness·Loop·Graph·LLMOps로 기업 암묵지 자산화하기</title>
<link>https://ai.23yellow.com/ai_agent_01/deep-twin-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%EC%84%A4%EA%B3%84-%EB%A9%94%EB%AA%A8%EB%A6%ACharnessloopgraphllmops%EB%A1%9C-%EA%B8%B0%EC%97%85-%EC%95%94%EB%AC%B5%EC%A7%80/</link>
<description><![CDATA[
양실장의 바이브코딩대학 강의 **「암묵지 자산화를 위한 딥트윈 에이전트의 전체 원리와 설계 프로세스」**에서는 AI 에이전트를 단순히 LLM에 도구 몇 개를 붙인 자동화 수준이 아니라, **기업에서 운영·평가·개선 가능한 자산**으로 만드는 전체 구조를 설명합니다.

핵심은 각각의 기술 용어를 따로 외우는 것이 아니라, **메모리 → Harness → Loop/Graph → LLMOps → Eval → Deep Twin**이 어떻게 하나의 시스템으로 연결되는지를 이해하는 것입니다.

## AI 에이전트는 무엇으로 구성되는가?

강의에서는 에이전트의 기본 입력을 다음 세 가지로 설명합니다.

- 시스템 프롬프트
- 사용자 프롬프트
- 현재 대화 히스토리

여기에 외부 메모리와 도구가 연결되면서 단순한 LLM 응답 시스템이 실제 업무를 수행하는 에이전트로 확장됩니다.

## 에이전트 메모리의 세 가지 유형

강의에서는 메모리를 세 가지 관점으로 나눕니다.

### 1. 절차적 메모리

**어떻게 행동해야 하는가**를 기억하는 구조입니다.

대표적인 예가 Skill입니다. 특정 작업을 언제 사용하고 어떤 순서로 처리해야 하는지가 정의되어 있기 때문에, 에이전트가 반복 가능한 업무 절차를 수행할 수 있습니다.

### 2. 의미론적 메모리

**무엇을 알고 있는가**에 해당합니다.

매뉴얼, 규정, 사용자 정보, 회사 문서 같은 사실성 정보를 벡터 데이터베이스에서 검색해 현재 작업에 주입하는 구조이며, 일반적으로 RAG가 여기에 해당합니다.

### 3. 일화적 메모리

과거 대화나 실제로 있었던 사건을 기억하는 구조입니다.

현재 채팅의 히스토리와는 달리, 이전 세션에서 있었던 대화나 판단 사례 중 현재 작업과 관련 있는 내용을 검색해 다시 활용합니다.

즉, 에이전트 메모리를 정리하면 다음과 같습니다.

- Skill → 절차 기억
- RAG → 사실·지식 기억
- 과거 대화·행동 기록 → 경험 기억

## Harness — 확률적인 LLM을 실제 업무에 쓰게 만드는 구조

LLM은 본질적으로 확률적으로 결과를 생성합니다.

하지만 기업 업무에서는 결과를 단순히 확률에 맡길 수 없습니다.

강의에서는 **Harness**를 LLM이 실제 업무 환경에서 안전하고 통제 가능하게 움직이도록 감싸는 구조로 설명합니다.

Harness에는 다음과 같은 요소가 들어갈 수 있습니다.

- 도구 사용 규칙
- 작업 절차
- 결과 검증
- 반복 실행
- 권한 제한
- 오류 처리
- 상태 관리

모델을 묶어두는 개념이라기보다, **LLM이라는 엔진에 실제 업무를 수행할 팔다리와 통제 장치를 붙이는 구조**에 가깝습니다.

## Loop — 목표를 달성할 때까지 실행하고 검증한다

에이전트가 한 번 작업했다고 해서 업무가 완료된 것은 아닙니다.

예를 들어 사용자가 10개의 항목을 처리해달라고 요청했는데 하나만 처리하고 "완료했습니다"라고 답한다면 자동화라고 보기 어렵습니다.

Loop는 다음과 같은 구조를 만듭니다.

**실행 → 결과 확인 → 목표 충족 여부 판단 → 미완료 시 다시 실행 → 완료**

즉, Loop는 **Goal-driven 구조**입니다.

정기적으로 실행되는 Cron 작업이나 반복적인 검증 프로세스 역시 넓은 의미에서 Loop의 일부로 볼 수 있습니다.

## Graph — 복잡한 업무를 병렬로 분기하고 다시 합친다

모든 업무가 단순한 반복 구조로 해결되는 것은 아닙니다.

기업 업무는 여러 작업이 동시에 진행된 뒤 하나의 결과로 합쳐지는 경우가 많습니다.

예를 들어 일정 관련 이메일을 처리한다고 하면 다음 작업이 병렬로 실행될 수 있습니다.

- 이메일 내용 분석
- 캘린더 조회
- 담당자 정보 조회
- 관련 문서 검색
- 일정 충돌 확인

그리고 각 결과를 다시 모아 최종 답변을 생성합니다.

이처럼 **분기 → 병렬 실행 → 결과 통합** 구조가 필요할 때 Graph 기반 설계가 유용합니다.

## 개인 에이전트와 기업 에이전트의 가장 큰 차이

개인용 에이전트는 결과가 이상하면 사용자가 직접 확인하고 다시 요청할 수 있습니다.

하지만 기업에서 사용하는 에이전트는 그렇지 않습니다.

기업에서는 다음 질문에 답할 수 있어야 합니다.

- 어떤 입력을 받았는가?
- 어떤 메모리를 사용했는가?
- 어떤 도구를 호출했는가?
- 어떤 경로를 거쳐 결과를 만들었는가?
- 왜 이런 판단을 했는가?
- 비용과 응답 시간은 얼마나 들었는가?
- 결과가 기준을 만족했는가?

이런 운영 환경이 없으면 에이전트는 기업 입장에서 **거대한 블랙박스**가 됩니다.

## LLMOps와 Tracing

그래서 필요한 것이 **LLMOps**입니다.

웹 개발에서 오류가 발생하면 stack trace를 따라가며 문제가 발생한 위치를 찾듯이, AI 에이전트 역시 작업 과정을 추적할 수 있어야 합니다.

Tracing을 통해 다음과 같은 내용을 확인할 수 있습니다.

- 어떤 프롬프트가 사용됐는가
- 어떤 도구를 호출했는가
- 어떤 메모리가 주입됐는가
- 어떤 단계에서 오류가 발생했는가
- 토큰이 과도하게 사용됐는가
- 특정 구간에서 지연이 발생했는가
- Loop가 불필요하게 반복됐는가

강의에서는 이런 구조가 있어야 기업이 에이전트를 관리 가능한 자산으로 볼 수 있다고 설명합니다.

## Eval — 결과가 기준을 만족했는지 평가한다

에이전트가 결과를 만들었다고 해서 업무가 끝난 것은 아닙니다.

**Eval(Evaluation)** 은 결과가 사전에 정의한 기준을 만족했는지를 평가하는 과정입니다.

예를 들어 다음과 같은 기준을 둘 수 있습니다.

- 사실 관계가 맞는가?
- 필요한 항목이 모두 포함됐는가?
- 회사 정책을 위반하지 않았는가?
- 지나치게 많은 토큰을 사용하지 않았는가?
- 응답 시간이 허용 범위 안인가?

평가 결과가 기준을 충족하면 실제 운영 환경에 적용하고, 그렇지 않으면 Tracing 결과를 바탕으로 다시 수정합니다.

즉,

**실행 → Tracing → Eval → 개선 → 재배포**

라는 운영 루프가 만들어집니다.

## Hermes와 원격 AI 에이전트

강의에서는 Hermes 같은 원격 에이전트도 전체 구조 안에서 설명합니다.

Telegram이나 Slack 같은 채널은 사용자와 에이전트를 연결하는 **Gateway** 역할을 합니다.

에이전트를 계속 사용하면 다음과 같은 정보가 축적될 수 있습니다.

- 사용자의 반복적인 요청
- 선호하는 방식
- 업무 습관
- 자주 쓰는 절차
- 판단 기준

이 과정에서 일부는 메모리로 저장되고, 반복되는 작업은 새로운 Skill로 정리될 수 있습니다.

## 마지막 단계는 Deep Twin

강의의 핵심은 결국 **기업의 암묵지를 어떻게 AI 자산으로 만들 것인가**입니다.

기업에서 중요한 지식은 매뉴얼이나 규정에만 존재하지 않습니다.

숙련된 사람은 상황에 따라 다음 요소를 함께 고려합니다.

- 과거 경험
- 비슷한 사례
- 상대방의 반응
- 조직의 분위기
- 결과에 대한 피드백
- 상황별 판단 기준

이런 지식은 문서만으로 완전히 설명하기 어렵기 때문에 **암묵지**라고 부릅니다.

Deep Twin은 단순히 "나는 이런 사람이다"라는 프로필을 만드는 것이 아닙니다.

대신 다음 데이터를 지속적으로 축적합니다.

- 실제로 어떤 행동을 했는가
- 무엇을 보고 판단했는가
- 어떤 선택을 했는가
- 결과가 어땠는가
- 그 결과에 어떤 피드백을 남겼는가

이 데이터가 계속 쌓이면 에이전트는 사람의 사고 절차와 판단 기준에 점점 가까워질 수 있습니다.

## 전체 구조 정리

영상의 내용을 하나의 흐름으로 정리하면 다음과 같습니다.

**LLM → Memory → Skill·RAG → Harness → Loop·Graph → Tracing → LLMOps → Eval → Feedback → Deep Twin**

이 구조에서 중요한 점은 AI 에이전트를 단순한 자동화 프로그램이 아니라 **지속적으로 학습·평가·개선되는 업무 시스템**으로 바라보는 것입니다.

특히 기업에서는 사람의 경험과 판단 과정까지 데이터로 축적할 수 있을 때, AI 자동화가 단순한 생산성 도구를 넘어 **조직이 보유할 수 있는 새로운 형태의 지식 자산**이 될 수 있습니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-17T13:31:11+09:00</dc:date>
</item>


<item>
<title>Microsoft Decision-1 공개 — Jev·OpenAI Decisions API보다 빠른 결정 모델</title>
<link>https://ai.23yellow.com/ai_agent_01/microsoft-decision-1-%EA%B3%B5%EA%B0%9C-jevopenai-decisions-api%EB%B3%B4%EB%8B%A4-%EB%B9%A0%EB%A5%B8/</link>
<description><![CDATA[
잔재미코딩(DaveLee) 채널의 **「Jev 벌써 끝? MS Decision-1 미쳤다」** 영상에서는 Microsoft가 공개한 새로운 **결정 모델(Decision Model) `Decision-1`**을 Jev와 OpenAI Decisions API와 비교해 소개합니다.

결정 모델은 긴 문장을 생성하는 일반적인 LLM과 달리, 여러 선택지 가운데 하나를 빠르게 고르는 데 최적화된 모델입니다. AI 에이전트가 다음 행동을 선택하거나 게임·자동화 시스템에서 즉시 판단을 내려야 할 때 특히 유용합니다.

## Microsoft Decision-1은 무엇인가?

영상에 따르면 최근 Jev를 시작으로 Cloudflare Clef, OpenAI Decisions API에 이어 Microsoft도 **Decision-1**을 공개했습니다.

핵심은 복잡한 텍스트 생성보다 **빠른 의사결정 자체에 특화**되어 있다는 점입니다. AI 에이전트가 수많은 도구와 행동 후보 중 다음 액션을 고르는 과정에서 이런 모델을 활용하면 전체 응답 시간을 크게 줄일 수 있습니다.

## OpenAI Decisions API와의 비교

영상에서 소개된 게임 테스트에서는 AI가 우주선을 어떻게 움직일지 반복해서 판단하도록 했습니다.

- **Microsoft Decision-1:** 최종 점수 3,320점
- **OpenAI Decisions API:** 최종 점수 1,300점
- Decision-1의 판단 시간은 약 **0.1초 안팎**
- OpenAI Decisions API는 평균 **0.3초 이상**

또한 36개 벤치마크 비교에서는 다음 수치가 소개됩니다.

- Decision-1 정확도: **83.5%**
- OpenAI Decisions API 정확도: **79.4%**
- Decision-1 속도: 약 **3.5배 빠름**

## GPT-6 Sol보다 35배 빠르다는 의미

Microsoft는 Decision-1이 **GPT-6 Sol보다 35배 빠르다**고 소개했지만, 영상에서는 이 비교를 그대로 받아들이기보다는 모델 목적의 차이를 함께 봐야 한다고 설명합니다.

GPT-6 Sol은 일반적인 텍스트 생성 모델이고 Decision-1은 빠른 선택을 위한 결정 모델이기 때문에, 같은 종류의 모델을 직접 비교한 수치는 아닙니다.

즉 Decision-1의 강점은 범용 언어 생성 능력이 아니라 **빠른 판단과 행동 선택**에 있습니다.

## Jev와의 비교

영상에서 소개된 수치 기준으로는 Jev와 Decision-1의 정확도 차이는 크지 않습니다.

- Decision-1 정확도: **83.5%**
- Jev 정확도: **82.3%**
- 속도는 Decision-1이 약 **2.8배 빠름**

가격 역시 Jev와 동일하게 소개됩니다.

- 입력 100만 토큰: **$0.042**
- 출력: **무료**

Jev와 OpenAI Decisions API를 505개 문제로 비교했던 테스트에서도 정답 수가 각각 385개와 378개로 큰 차이가 없었다고 설명합니다.

## AI 에이전트에서 결정 모델이 중요한 이유

AI 에이전트는 단순히 문장을 생성하는 것보다 반복적으로 **다음 행동을 선택하는 과정**이 더 중요할 수 있습니다.

예를 들어 에이전트가 다음과 같은 결정을 계속 내려야 한다면 범용 LLM을 매번 호출하는 것은 비용과 지연시간 측면에서 비효율적일 수 있습니다.

- 어떤 도구를 호출할지 선택
- 검색 결과 중 어떤 정보를 사용할지 판단
- 여러 작업 중 우선순위 결정
- 게임이나 로봇의 다음 행동 선택
- 자동화 워크플로에서 다음 단계 결정

Decision-1 같은 모델은 이러한 선택 과정만 빠르게 처리하도록 설계되기 때문에 **AI Agent의 판단 엔진**으로 활용될 가능성이 있습니다.

## 결정 모델 경쟁이 본격화되고 있다

Jev 이후 짧은 기간 안에 Cloudflare, OpenAI, Microsoft까지 연이어 결정 모델을 공개하고 있다는 점도 주목할 만합니다.

지금까지 AI 모델 경쟁이 더 큰 컨텍스트와 더 좋은 텍스트 생성 능력에 집중됐다면, 앞으로는 에이전트 환경에서 필요한 **저지연·저비용 의사결정 모델**이 별도의 중요한 영역으로 자리 잡을 가능성이 있습니다.

영상에서는 향후 Decision-1과 OpenAI Decisions API를 직접 사용할 수 있게 되면 Jev와 함께 **한국어 정확도와 실제 응답 속도**까지 비교할 예정이라고 설명합니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-10-13T02:16:11+09:00</dc:date>
</item>


<item>
<title>Meta Muse 공개 — 항상 백그라운드에서 일하는 개인 AI 에이전트</title>
<link>https://ai.23yellow.com/ai_agent_01/meta-muse-%EA%B3%B5%EA%B0%9C-%ED%95%AD%EC%83%81-%EB%B0%B1%EA%B7%B8%EB%9D%BC%EC%9A%B4%EB%93%9C%EC%97%90%EC%84%9C-%EC%9D%BC%ED%95%98%EB%8A%94-%EA%B0%9C%EC%9D%B8/</link>
<description><![CDATA[
Muse 공식 영상 **「Take the full tour of Muse, Meta's personal AI agent」**에서는 사용자를 위해 항상 백그라운드에서 일하는 개인 AI 에이전트 **Muse**의 주요 기능과 화면 구성을 소개합니다.

Muse는 단순한 챗봇이 아니라, 사용자의 관심사와 목표를 기억하고 필요한 작업을 지속적으로 수행하는 **개인형 상시 에이전트**를 지향합니다.

## 메신저처럼 사용하는 Chat 탭

Muse의 기본 화면은 일반적인 AI 채팅창보다 메신저 앱에 가깝게 설계되어 있습니다.

사용자는 Muse와 대화하면서 다음과 같은 일을 맡길 수 있습니다.

- 영화 티켓 구매
- 가족 주말 여행 계획
- 체스 계정 모니터링
- 경기 결과 분석
- 개인 관심사에 대한 조사

영상에서는 Muse가 자체 컴퓨터를 가지고 있으며, 사용자가 직접 보고 있지 않아도 백그라운드에서 계속 작업한다고 설명합니다.

## 지금 무엇을 하고 있는지 확인하는 Status

상시형 에이전트에서는 투명성이 중요합니다.

Muse 화면 상단의 상태 표시를 통해 다음 내용을 확인할 수 있습니다.

- 현재 무엇을 하고 있는지
- 이미 어떤 작업을 했는지
- 다음에 무엇을 할 예정인지
- 어떤 작업에 사용자 승인이 필요한지

권한이 필요한 경우 사용자는 상태 화면이나 채팅에서 직접 승인할 수 있습니다.

## 개인화 Feed

Feed 탭에서는 Muse가 사용자의 관심사에 맞는 콘텐츠를 찾아 제공합니다.

예를 들어 다음과 같이 시간대별로 원하는 정보를 설정할 수 있습니다.

- 아침: 금융 뉴스
- 저녁: 논픽션 도서 추천

중요한 점은 단순히 기존 콘텐츠를 모아 보여주는 것이 아니라, **사용자를 위해 개별적으로 작성된 피드**를 제공한다는 점입니다.

## Ideas — 먼저 제안하는 AI

Ideas 탭에서는 Muse가 기존 대화를 바탕으로 사용자가 요청하지 않은 작업도 먼저 제안합니다.

영상에서 등장하는 예시는 다음과 같습니다.

- 허리 회복 루틴
- 유치원 일정 조정
- 인허가 신청
- 개인 생활 개선 아이디어

즉, Muse는 사용자의 질문을 기다리는 도구가 아니라 **도움이 될 만한 일을 스스로 찾아 제안하는 구조**입니다.

## Goals — 장기 목표를 추적

Muse는 사용자와의 대화를 통해 중요한 목표를 파악하고 Goals 탭에 정리합니다.

목표별로 다음 내용을 확인할 수 있습니다.

- 현재 진행 상태
- Muse가 백그라운드에서 수행한 작업
- 전체 작업 타임라인
- 장기적으로 진행할 프로젝트

이 기능은 단발성 명령 처리보다 **지속적인 목표 관리**에 초점을 맞춥니다.

## Library — AI가 만든 결과물을 한곳에 저장

Muse와 함께 만든 결과물은 Library에서 관리됩니다.

영상에서는 다음 형식이 소개됩니다.

- 일반 문서
- PDF
- Markdown 파일
- 인터랙티브 결과물
- 개인화된 분석 대시보드

예시로 체스 계정 데이터를 분석한 대시보드가 등장합니다.

## Muse가 보여주는 개인 AI 에이전트의 방향

Muse의 구조를 정리하면 다음과 같습니다.

**대화 → 개인화 학습 → 백그라운드 작업 → 선제 제안 → 목표 추적 → 결과물 축적**

기존 AI 챗봇이 사용자의 질문에 답하는 데 집중했다면, Muse는 사용자의 맥락과 목표를 계속 추적하면서 **개인 비서와 프로젝트 관리 도구를 결합한 형태**에 가깝습니다.

특히 최근 등장하는 OpenAI dots와 마찬가지로, Muse 역시 AI가 사용자의 요청을 기다리지 않고 **항상 실행되며 필요한 일을 먼저 찾아 수행하는 상시형 에이전트**라는 점에서 주목할 만합니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-30T15:46:00+09:00</dc:date>
</item>


<item>
<title>OpenAI dots 공개 — 24시간 먼저 움직이는 상시형 AI 에이전트</title>
<link>https://ai.23yellow.com/ai_agent_01/openai-dots-%EA%B3%B5%EA%B0%9C-24%EC%8B%9C%EA%B0%84-%EB%A8%BC%EC%A0%80-%EC%9B%80%EC%A7%81%EC%9D%B4%EB%8A%94-%EC%83%81%EC%8B%9C%ED%98%95/</link>
<description><![CDATA[
OpenAI 공식 영상 **「Introducing dots, always-on agents built to handle everything」**에서는 ChatGPT 안에서 동작하는 새로운 상시형 AI 에이전트 **dots**의 실제 사용 장면을 소개합니다.

dots의 가장 큰 특징은 사용자가 매번 명령을 내리지 않아도, 필요한 일을 계속 진행하고 중요한 순간에 먼저 사용자에게 알려준다는 점입니다.

## dots는 무엇인가?

OpenAI는 dots를 **GPT-6 Astra 기반의 항상 켜져 있는 AI 에이전트**로 소개합니다.

각 dot은 자신만의 클라우드 컴퓨터를 사용하며, 사용자의 피드백을 바탕으로 선호와 업무 방식을 점차 학습합니다.

또한 OpenAI의 플러그인 생태계를 통해 여러 앱과 연결되어 실제 업무를 수행할 수 있습니다.

## 먼저 움직이는 AI

공식 시연에서 dot은 사용자가 요청하기 전에 다음과 같은 일을 진행합니다.

- 웹사이트 리뉴얼 준비
- Teams의 최신 지표를 반영해 이사회 자료 업데이트
- Google Meet 회의 노트에서 앱 마이그레이션 작업 발견
- 변경 사항을 미리 정리
- 결혼식 케이크 업체 취소를 감지하고 대체 업체 탐색
- 가족 일정과 업무 일정 충돌 확인

기존 챗봇이 사용자의 질문에 반응하는 구조였다면, dots는 **상황을 계속 확인하면서 먼저 움직이는 방식**입니다.

## 승인 필요한 순간에는 사용자에게 확인

dots가 모든 일을 독단적으로 처리하는 것은 아닙니다.

공식 영상에서는 중요한 작업에서 사용자 승인을 받는 장면이 반복됩니다.

예를 들어:

- 웹사이트 디자인 변경 후 공개 전 확인
- 앱 마이그레이션 진행 전 검토 요청
- 단계적 배포 준비 후 승인 대기
- 일정 충돌 시 변경 여부 확인

즉, **자동 실행과 사용자 승인 사이의 경계**를 두는 구조입니다.

## 업무와 개인 일정을 함께 관리

dots는 업무 자동화뿐 아니라 개인 비서 역할도 보여줍니다.

공식 영상에서는 다음과 같은 개인 일정 작업도 등장합니다.

- 결혼식 준비
- 케이크 시식 일정 조율
- 자녀 방과 후 수업 예약
- 가족 행사와 회사 일정 충돌 해결

하나의 에이전트가 업무와 개인 생활을 함께 연결하는 형태입니다.

## ChatGPT·Slack·Teams에서 이어지는 작업

OpenAI 설명에 따르면 dot은 ChatGPT뿐 아니라 Slack이나 Teams 등 연결된 환경에서도 계속 접근할 수 있습니다.

사용자는 필요할 때:

- 질문하기
- 아이디어 논의
- 작업 피드백
- 음성 통화

등을 통해 dot과 계속 협업할 수 있습니다.

## 사용할수록 개인화되는 에이전트

OpenAI는 dots가 사용자와 함께 일하면서 다음을 학습한다고 설명합니다.

- 사용자의 선호
- 의사결정 방식
- 작업 스타일
- 좋은 결과의 기준

결국 dots의 목표는 단순히 명령을 수행하는 것이 아니라, **사용자가 직접 했을 법한 방식으로 일을 처리하는 것**입니다.

## 상시형 AI 에이전트의 변화

dots가 보여주는 가장 큰 변화는 AI의 역할이 다음과 같이 바뀐다는 점입니다.

**질문받고 답하는 AI → 목표를 이해하고 계속 일하는 AI**

사용자가 자리를 비우거나 별도 지시를 하지 않아도, AI가 작업을 이어가고 중요한 순간에만 개입을 요청하는 형태입니다.

이런 구조가 확산되면 AI Agent는 단순한 생산성 도구를 넘어 **개인 비서·프로젝트 매니저·업무 수행자**에 가까운 역할로 확장될 가능성이 큽니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-30T15:44:34+09:00</dc:date>
</item>


<item>
<title>노션에 AI 직원을 붙이면 어디까지 할까? — Notion Workers와 AI Agent 자동화</title>
<link>https://ai.23yellow.com/ai_agent_01/%EB%85%B8%EC%85%98%EC%97%90-ai-%EC%A7%81%EC%9B%90%EC%9D%84-%EB%B6%99%EC%9D%B4%EB%A9%B4-%EC%96%B4%EB%94%94%EA%B9%8C%EC%A7%80-%ED%95%A0%EA%B9%8C-notion/</link>
<description><![CDATA[
노마드 코더 Nomad Coders 채널의 **「노션에 AI를 붙여놓으면 어디까지 할까?」** 영상에서는 Notion의 개발자 플랫폼과 AI 기능을 활용해, 단순한 문서 도구를 넘어 **AI 에이전트가 실제 업무를 수행하는 자동화 환경**을 만드는 과정을 소개합니다.

&gt; 이 영상에는 Notion의 유료 광고가 포함되어 있습니다.

## 노션 안에 AI 직원을 만든다

영상의 핵심은 Notion을 단순히 문서와 데이터베이스를 관리하는 공간으로 사용하는 것이 아니라, **AI가 데이터를 읽고 필요한 작업을 실행하는 업무 플랫폼**으로 확장하는 것입니다.

Notion Workers를 이용하면 특정 작업을 수행하는 AI 에이전트를 구성하고, Notion의 데이터와 외부 서비스를 연결해 반복 업무를 자동화하는 구조를 만들 수 있습니다.

## YouTube 데이터를 Notion으로 자동 수집

영상에서는 YouTube 데이터를 Notion으로 가져오는 자동화 예제를 다룹니다.

외부 서비스의 API를 이용해 필요한 데이터를 가져온 뒤 Notion 데이터베이스에 저장하도록 구성하면, 사람이 직접 복사하거나 입력하지 않아도 **외부 데이터 → Notion 데이터베이스** 형태의 자동화 흐름을 만들 수 있습니다.

이런 방식은 YouTube뿐 아니라 뉴스, CRM, 프로젝트 관리 도구, 사내 API 등 다양한 서비스와 연결하는 데 활용할 수 있습니다.

## API 키 설정부터 테스트와 배포까지

외부 서비스를 연결하려면 API 인증과 실행 환경이 필요합니다. 영상에서는 API 키를 설정하고 기능을 테스트한 뒤 실제 사용할 수 있도록 배포하는 과정도 함께 보여줍니다.

AI Agent를 구축할 때 중요한 점은 AI 모델 자체뿐 아니라, **AI가 실제로 사용할 수 있는 도구와 API를 어떻게 연결하느냐**입니다.

## AI 에이전트에게 도구를 만들어주기

AI 에이전트는 대화만 하는 챗봇과 달리 필요한 도구를 호출해 실제 작업을 수행할 수 있습니다.

예를 들어 에이전트에게 다음과 같은 도구를 제공할 수 있습니다.

- 외부 API에서 데이터 조회
- Notion 데이터베이스 읽기 및 저장
- 콘텐츠 정리 및 분류
- 반복 업무 자동화
- 특정 조건에 따른 후속 작업 실행

즉, AI에게 단순히 질문하는 방식에서 벗어나 **업무에 필요한 기능을 도구로 만들어 AI에게 제공하는 구조**가 핵심입니다.

## Notion이 프로그래밍 가능한 업무 플랫폼으로 확장

Notion은 문서 작성과 데이터베이스 관리 중심의 서비스에서 점차 개발자 플랫폼과 AI 기능을 결합한 형태로 확장되고 있습니다.

Notion API와 AI Agent, Workers 같은 기능을 조합하면 데이터가 저장된 공간과 자동화가 실행되는 공간을 하나로 연결할 수 있습니다. 특히 AI Agent 개발 관점에서는 **데이터베이스 + API + 자동화 + AI 도구 호출**을 하나의 워크플로우로 구성할 수 있다는 점이 인상적인 부분입니다.

영상에서는 이러한 구조를 실제 예제를 통해 살펴보며, Notion을 AI 에이전트의 작업 공간으로 활용할 수 있는 가능성을 보여줍니다.]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-22T03:55:22+09:00</dc:date>
</item>


<item>
<title>Codex 2026 기초 가이드 — 플러그인·자동화·목표 설정·앱샷 핵심 기능</title>
<link>https://ai.23yellow.com/ai_agent_01/codex-2026-%EA%B8%B0%EC%B4%88-%EA%B0%80%EC%9D%B4%EB%93%9C-%ED%94%8C%EB%9F%AC%EA%B7%B8%EC%9D%B8%EC%9E%90%EB%8F%99%ED%99%94%EB%AA%A9%ED%91%9C-%EC%84%A4%EC%A0%95%EC%95%B1%EC%83%B7-%ED%95%B5%EC%8B%AC/</link>
<description><![CDATA[
이동훈의 루트AI 채널의 **「Codex 2026 기초 가이드ㅣ핵심 기능 설명, 실습까지 바로 따라하세요」** 영상에서는 OpenAI의 Codex를 처음 사용하는 사람을 대상으로 설치부터 주요 기능과 실제 활용 방법까지 단계별로 소개합니다.

## Codex는 어떤 도구인가?

영상에서는 Codex를 단순히 질문에 답하는 챗봇이 아니라, 사용자의 요청을 바탕으로 **추론하고 계획을 세운 뒤 실제 작업까지 수행하는 AI 에이전트**로 설명합니다.

개발자를 위한 코딩 에이전트에서 출발했지만 데스크톱 앱과 다양한 기능이 추가되면서 코딩뿐 아니라 여러 컴퓨터 작업과 업무 자동화에도 활용할 수 있는 방향으로 확장되고 있다는 점을 소개합니다.

## 설치와 기본 화면

Codex 앱을 설치한 뒤 기본적으로 다음과 같은 요소를 사용할 수 있습니다.

- 프로젝트별 작업 관리
- 자연어로 작업을 지시하는 입력창
- 작업 성격에 따른 모델 선택
- 추론 깊이를 조절하는 Intelligence 설정
- 작업 실행 범위를 결정하는 권한 설정
- 여러 프로젝트의 병렬 작업

단순한 파일 정리나 변환에는 낮은 추론 수준을, 복잡한 개발이나 장시간 작업에는 더 높은 추론 수준을 사용하는 방식도 설명합니다.

## 플러그인으로 외부 서비스 연결

영상에서 중요하게 다루는 기능 중 하나가 **플러그인**입니다.

Codex 자체 기능만 사용하는 것이 아니라 외부 서비스와 연결하여 AI가 실제 업무를 수행할 수 있도록 확장하는 방식입니다. 영상에서는 플러그인을 MCP 서버와 워크플로우 스킬을 결합한 형태로 설명합니다.

실습에서는 Vercel 플러그인을 연결한 뒤 Codex에게 포트폴리오 랜딩 페이지 제작을 요청하고, 만들어진 앱을 실제로 배포하여 URL까지 받는 과정을 보여줍니다.

즉,

**요청 → 코드 생성 → 앱 제작 → 외부 서비스 연결 → 배포**

과정을 하나의 AI 에이전트 워크플로우로 연결할 수 있습니다.

## 자동화 기능

Codex의 자동화 기능을 사용하면 사용자가 매번 직접 작업을 요청하지 않아도 지정한 시간이나 조건에 맞춰 작업을 수행하도록 구성할 수 있습니다.

영상에서는 Google Calendar와 Slack을 연결하여 **매일 오전 9시에 일정을 확인하고 브리핑을 전달하는 자동화**를 예제로 만듭니다.

이처럼 플러그인과 자동화를 조합하면 단순한 코딩 도구를 넘어 반복 업무를 처리하는 개인 업무 에이전트 형태로 활용할 수 있습니다.

## 목표 설정 모드

길고 복잡한 작업을 처리하기 위한 **목표 설정 모드(Goal Mode)**도 소개합니다.

세부 단계를 하나씩 지시하는 대신 최종 목표를 지정하면 Codex가 해당 목표를 달성하기 위해 필요한 작업을 이어서 수행하는 방식입니다.

영상에서는 여행 일정 계획을 목표로 설정하고, 플러그인을 통해 결과를 Notion 페이지로 정리하는 예제를 보여줍니다.

이 기능은 여러 단계가 필요한 조사, 개발, 문서 작성 및 장시간 작업 등에 활용할 수 있습니다.

## 앱샷(App Shot)

영상 후반에는 화면의 정보를 AI에게 빠르게 전달할 수 있는 **앱샷 기능**을 소개합니다.

기존에는 화면을 캡처하고 클립보드에 복사한 뒤 AI 창에 붙여 넣는 과정이 필요했지만, 앱샷을 이용하면 현재 보고 있는 앱이나 화면을 바로 컨텍스트로 전달할 수 있습니다.

이를 통해 화면을 기반으로 한 질문이나 작업 지시를 보다 간단하게 수행할 수 있습니다.

## 영상에서 소개하는 핵심 흐름

이번 영상에서 보여주는 Codex의 방향은 단순한 코드 생성보다 **AI가 실제 도구와 연결되어 작업을 수행하는 에이전트 환경**에 가깝습니다.

특히 다음 기능의 조합이 핵심입니다.

- 프로젝트 기반 작업 관리
- 플러그인을 통한 외부 서비스 연결
- 반복 업무 자동화
- 목표 중심의 장시간 작업
- 현재 화면을 전달하는 앱샷
- 자연어 지시를 실제 실행으로 연결하는 AI 에이전트

Codex를 처음 사용하거나 AI 에이전트를 실제 업무 자동화와 개발에 어떻게 활용할 수 있는지 궁금한 사용자라면 전체적인 기능 흐름을 살펴보기에 좋은 입문 영상입니다.

## 영상 정보

- 채널: 이동훈의 루트AI
- 영상 길이: 11분 22초
- 주요 내용: Codex 설치, 플러그인, 자동화, 목표 설정 모드, 앱샷
- 게시일: 2026년 6월 5일]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-21T14:22:38+09:00</dc:date>
</item>


<item>
<title>OpenClaw 2.0이 AI 에이전트의 판도를 바꿨습니다!</title>
<link>https://ai.23yellow.com/ai_agent_01/openclaw-20%EC%9D%B4-ai-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EC%9D%98-%ED%8C%90%EB%8F%84%EB%A5%BC-%EB%B0%94%EA%BF%A8%EC%8A%B5%EB%8B%88%EB%8B%A4/</link>
<description><![CDATA[
OpenClaw 2.0: AI Agents Just Changed Forever
Discover why OpenClaw 2.0 is the most significant rebuild in the tool's history, featuring shared cloud sessions and persistent memory. Learn how to transform your AI workflow from a simple chatbot into a powerful, multi-user workspace.

00:00 - 00:00 - Intro
01:23 - Easier Setup &amp; Integration
01:47 - The Rebuilt Workspace
02:18 - Multi-User Cloud Sessions
03:53 - Persistent Memory &amp; Dreaming
04:54 - Multi-Device &amp; Mobile Support
05:31 - Automation &amp; AI Swarms
07:00 - Is It Worth The Update?

<br />
OpenClaw 2.0: AI 에이전트의 새로운 시대가 열리다
공유 클라우드 세션과 지속형 ​​메모리(persistent memory) 기능을 갖춘 OpenClaw 2.0이 왜 이 도구 역사상 가장 획기적인 개편인지 확인해 보세요. 단순한 챗봇 수준의 AI 워크플로를 강력한 다중 사용자 협업 공간으로 탈바꿈시키는 방법을 알아보세요.

00:00 - 00:00 - 도입부
01:23 - 간편해진 설정 및 통합
01:47 - 새롭게 개편된 워크스페이스
02:18 - 다중 사용자 클라우드 세션
03:53 - 지속형 메모리 및 '드리밍(Dreaming)' 기능
04:54 - 멀티 디바이스 및 모바일 지원
05:31 - 자동화 및 AI 스웜(Swarm)
07:00 - 업데이트할 가치가 있을까?]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-06T02:33:23+09:00</dc:date>
</item>


<item>
<title>스스로 진화하는 OpenClaw 2.0 출시!! 헤르메스 에이전트랑 비교하면?</title>
<link>https://ai.23yellow.com/ai_agent_01/%EC%8A%A4%EC%8A%A4%EB%A1%9C-%EC%A7%84%ED%99%94%ED%95%98%EB%8A%94-openclaw-20-%EC%B6%9C%EC%8B%9C-%ED%97%A4%EB%A5%B4%EB%A9%94%EC%8A%A4-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EB%9E%91-%EB%B9%84%EA%B5%90%ED%95%98%EB%A9%B4/</link>
<description><![CDATA[
#ai #바이브코딩 #openai #chatgpt #codex #claude #fable #opus #mythos #anthropic #openclaw #hermes 

00:00 훅
01:14 인트로
05:26 버즈
06:22 자동화
08:10 플러그인/스킬
10:57 호스팅어 원클릭 설치
12:48 메모리
14:27 보안
15:40 총평
17:14 개인 비서 사용처]]></description>
<dc:creator>최고관리자</dc:creator>
<dc:date>2026-09-06T02:31:33+09:00</dc:date>
</item>

</channel>
</rss>
