ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

docs: add robeing agent loop and model selection research

Browse Source
This commit is contained in:
Claude-51124 2026-03-12 14:22:01 +09:00
parent 53148ab25a
commit 37bea009c9
6 changed files with 634 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
journey/README.md
View File

@ -42,6 +42,7 @@
### 에이전트 구조 / Gateway 정리
- OpenClaw 기반 로빙 개선 아이디어 – `ideas/260309_openclaw_기반_로빙_개선_아이디어.md`
- 로빙 에이전트 루프와 스킬 훅 구조 아이디어 – `ideas/260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md`
### Intent 리뷰 / 의도 학습
@ -58,6 +59,11 @@
- Memory · Classification 하이브리드 분류 연구 – `research/memory/classification/README.md`
- E2E Intent 개선 실험 보고서 – `rb8001/experiment_results/e2e_final_experiment_report.md`
### 에이전트 루프 / 오케스트레이션
- 로빙 에이전트 루프·스킬 훅·LLM 실행 구조 리서치 – `research/orchestration_tools/260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md`
- 로빙 LLM API·Agent API·모델 선정·비용 비교 리서치 – `research/orchestration_tools/260312_로빙_LLM_API_Agent_API_모델선정_비용비교_리서치.md`
### HITL / 리뷰 큐
- Human-in-the-Loop Intent Learning 아키텍처 – `../300_architecture/390_human_in_the_loop_intent_learning.md`

105
journey/ideas/260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md Normal file
View File

@ -0,0 +1,105 @@
tags: [robeing, agent-loop, skills, hooks, orchestration]
# 로빙 에이전트 루프와 스킬 훅 구조 아이디어
## 배경
- 로빙이 단순 질의응답기가 아니라 실행 가능한 존재형 에이전트라면, 단발 응답보다 `예측-행동-평가-반성` 루프가 먼저 정의되어야 합니다.
- 현재 `skill-*` 서비스들은 독립 실행 단위로 존재하지만, 로빙 본체가 어떤 지점에서 어떤 스킬을 어떻게 개입시키는지는 더 명확히 정리할 필요가 있습니다.
- 이번 아이디어는 "로빙 본체는 오케스트레이터, 스킬은 훅을 가진 실행 단위"라는 구조를 제안합니다.
## 핵심 아이디어
### 1. 로빙 본체는 큰 루프를 가진다
- 로빙 본체는 사용자 목표를 받아 다음 순서로 움직입니다.
1. 목표 해석
2. 다음 행동 결정
3. 스킬 또는 내부 기능 실행
4. 결과 관찰
5. 성공/실패 판단
6. 기억·로그·정책 갱신
- 즉, 로빙은 스킬을 직접 대체하지 않고 스킬들을 조율하는 존재입니다.
### 2. 스킬은 훅을 통해 루프에 개입한다
- `스킬별로 훅을 가져간다`는 뜻은 각 스킬이 자기 책임 범위 안에서 개입 가능한 지점을 가진다는 뜻입니다.
- 예시 훅:
- `before_plan`: 입력 보강, 권한 확인, 선행조건 점검
- `before_run`: 실행 인자 정규화, 컨테이너/세션 준비
- `on_success`: 결과 후처리, 포맷 변환, 다음 스킬로 전달
- `on_error`: 복구 시도, 재시도 정책 제안, 실패 원인 구조화
- `on_close`: 로그 저장, 기억 반영, 사용자 보고용 요약 생성
- 이렇게 하면 로빙 본체는 공통 루프를 유지하고, 스킬은 자기 도메인 로직만 책임질 수 있습니다.
### 3. 스킬 호출은 API 호출만을 뜻하지 않는다
- 어떤 스킬은 내부 API를 호출할 수 있고,
- 어떤 스킬은 이미 떠 있는 컨테이너에 `exec`로 들어가 실행 파일을 직접 돌릴 수 있고,
- 어떤 스킬은 다른 스킬의 결과를 받아 후속 처리만 할 수도 있습니다.
- 중요한 것은 호출 방식 자체보다 `입력·출력·권한·실패·완료 기준`이 계약으로 고정되는 것입니다.
### 4. 로빙은 API 소비자일 수도 있고 CLI 운영자일 수도 있다
- 안정적인 기능은 API 소비자처럼 동작할 수 있습니다.
- 운영, 복구, 디버깅이 필요한 경로에서는 CLI 운영자처럼 동작할 수 있습니다.
- 따라서 로빙의 미래 구조는 "모든 걸 docker exec로 처리"가 아니라,
- 기본은 API
- 예외적으로 운영 제어가 필요한 구간만 CLI
의 하이브리드가 더 현실적입니다.
## 예시 시나리오
### 뉴스 수집 후 슬랙 전송
1. 사용자가 "AI 뉴스를 보여줘"라고 요청합니다.
2. 로빙이 `news` 스킬을 선택합니다.
3. `news.before_run`이 키워드 정규화와 컨테이너 준비를 수행합니다.
4. `news` 실행 결과가 나오면 `news.on_success`가 중복 제거와 표준 출력 포맷 변환을 수행합니다.
5. 사용자가 "슬랙으로 보내"라고 하거나 작업 목표에 포함돼 있으면 `slack` 스킬이 후속 실행됩니다.
6. `slack.on_close`가 전송 결과와 메시지 ID를 기록합니다.
### 실패 시
1. `news` 실행 중 에러가 발생합니다.
2. `news.on_error`가 에러 타입을 분류하고 재시도 가능 여부를 로빙 본체에 전달합니다.
3. 로빙은 재시도, 코드 수정, 사용자 보고 중 하나를 결정합니다.
4. 실패 은닉 없이 원인과 중단 지점을 남깁니다.
## 이 구조가 로빙 철학과 맞는 이유
- 존재형 에이전트는 단순 실행기가 아니라 판단과 책임의 연속성을 가져야 합니다.
- 스킬 훅 구조는 "무엇을 왜 했는지"를 설명 가능하게 만들고, 실패를 숨기지 않으며, 기억과 반성을 루프에 자연스럽게 연결합니다.
- 이는 공통 SSOT의 `Truth First`, `Trust by Design`, `실패 가시성`, `원인 직접 수정`과도 일치합니다.
## 아직 아이디어 단계인 이유
- 훅 이름과 호출 순서가 아직 고정되지 않았습니다.
- `skill-*` 서비스별 계약 문서가 아직 표준화되지 않았습니다.
- 로빙 본체의 성공 기준, 중단 기준, 최대 재시도 규칙이 제품 수준으로 명시되지 않았습니다.
## 다음 단계
1. `news`, `slack`, `email` 스킬 중 하나를 골라 샘플 훅 계약 문서를 작성합니다.
2. 로빙 본체 루프의 최소 상태 머신을 문서로 먼저 고정합니다.
3. 실패 시 `사용자 보고`, `자동 복구`, `중단`의 분기 기준을 정합니다.
## 바로 적용할 제품 방향
- 먼저 만들 것은 "스킬 플랫폼"보다 `로빙의 에이전트 루프 + 도구 프로토콜`입니다.
- 즉 모델 출력은 최소한 아래와 비슷한 구조화 액션으로 받는 편이 좋습니다.
```json
{
"action": "run_shell",
"args": {
"command": "docker exec news-app python crawl.py --keyword AI"
},
"done": false
}
```
- 로빙은 이 구조를 받아 실행하고, stdout/stderr를 다시 다음 판단 입력으로 넘깁니다.
- 스킬 훅은 이 루프 위에서 `입력 보정`, `실패 분류`, `후처리`, `종료 정리`를 맡습니다.
- 따라서 현재 아이디어의 우선순위는 `스킬을 많이 만드는 것`보다 `루프와 프로토콜을 먼저 고정하는 것`입니다.
- 그리고 이 루프 안에는 최소한 아래 다섯 요소가 들어가야 합니다.
- 명령 실행기
- 결과 수집기
- 오류 판단 루프
- 재시도 규칙
- 위험 명령 차단 규칙
## 관련 문서
- `../research/orchestration_tools/260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md`
- `../research/orchestration_tools/260312_로빙_LLM_API_Agent_API_모델선정_비용비교_리서치.md`
- `../../book/100_philosophy/130_존재형_에이전트란_무엇인가.md`
- `../../book/200_core_design/240_스킬시스템_함수형_자동화와_컨텍스트.md`

2
journey/research/README.md
View File

@ -61,6 +61,8 @@
### [오케스트레이션·에이전트 플랫폼(Orchestration Tools)](./orchestration_tools/README.md)
- LangGraph vs n8n 비교
- OpenClaw 아키텍처 및 로빙 적용 리서치
- 로빙 에이전트 루프/스킬 훅/LLM 실행 구조 리서치
- 로빙 LLM API/Agent API/모델 선정/비용 비교 리서치
- [자기개선 루프 구현을 위한 DB/서비스 리서치 (260303)](./260303_자기개선루프_DB_서비스_구현_리서치.md)
## 로빙을 위한 체크리스트

286
journey/research/orchestration_tools/260312_로빙_LLM_API_Agent_API_모델선정_비용비교_리서치.md Normal file
View File

@ -0,0 +1,286 @@
---
tags:
- Robeing
- LLM
- AgentAPI
- Gemini
- OpenAI
- CostComparison
date: 2026-03-12
modification_date: 2026-03-12
---
# 로빙 LLM API, Agent API, 모델 선정, 비용 비교 리서치
## 1. 목적
이 문서는 로빙의 에이전트 루프를 어떤 모델과 어떤 실행 계층 위에 둘지 판단하기 위한 비교 메모입니다.
정리 대상은 아래 네 가지입니다.
1. LLM API와 Agent API의 차이
2. 로빙이 지금 실제로 쓰는 모델 상태
3. Gemini/OpenAI 계열을 로빙에 붙일 때의 판단 기준
4. 비용 비교 문서를 어디까지 SSOT로 둘지
## 1-1. 2026-03-12 공식 문서 재확인 범위
이 문서는 2026-03-12에 아래 공식 문서를 다시 확인해 보강했습니다.
- Anthropic Skills API 문서
- OpenAI Pricing, Responses API, Tools, Codex 모델 문서
- Google Gemini 모델/가격 문서
- Gemini CLI 문서
따라서 아래 내용 중 가격·모델 라인업은 2026-03-12 시점의 확인값이며, 이후 변경 가능성이 큽니다.
## 2. 현재 로빙의 확인된 상태
### 2.1 rb8001
- [rb8001/README.md](../../../rb8001/README.md) 기준:
- 기본 LLM 모델은 `Gemini 2.5 Flash-Lite`
- 보조 모델로 `Claude 3 Haiku`, `GPT-3.5 Turbo`가 문서에 남아 있음
- `DEFAULT_LLM_MODEL` 환경변수 기반으로 모델을 관리함
### 2.2 skill_news
- [skill_news/README.md](../../../skill_news/README.md) 기준:
- `GEMINI_MODEL=gemini-2.5-flash-lite`
- 모델명 SSOT는 `.env` 단일 항목
- 코드 기본값 폴백 없이 누락 시 fail-fast
### 2.3 현재 상태 해석
- 로빙은 이미 "모델을 갈아 끼울 수 있는 구조"를 부분적으로 갖고 있습니다.
- 하지만 모델 선택 기준, 비용 기준, 작업별 라우팅 기준은 제품 SSOT로 아직 고정되지 않았습니다.
## 3. LLM API와 Agent API의 차이
### 3.1 LLM API
- 모델에게 입력을 보내고 텍스트 또는 구조화 응답을 받는 계층입니다.
- 로빙이 직접 구현해야 하는 것:
- 프롬프트 조립
- 구조화 응답 파싱
- 툴 실행
- 재시도/중단/완료 판단
- 권한 및 로그 관리
- 셸/명령 실행기
- stdout/stderr/종료 코드 수집기
### 3.2 Agent API 또는 CLI 에이전트 런타임
- 모델 호출 위에 도구 실행, 파일 접근, 셸 실행, 승인 흐름까지 감싼 상위 런타임입니다.
- 장점:
- 빠르게 프로토타입 가능
- 도구 호출 및 구조화 출력이 이미 정리된 경우가 많음
- 단점:
- 로빙 고유 철학과 운영 규칙을 그대로 녹이기 어렵다
- 플랫폼 정책에 종속될 수 있다
- 비용은 토큰 외의 실행 오버헤드까지 고려해야 한다
### 3.3 스킬은 CLI 전용이 아니다
- 이것이 이번 재정리의 가장 중요한 수정점입니다.
- Anthropic 공식 문서는 Agent Skills를 API에서 사용하는 방법을 명시하고 있습니다.
- 문서상 Skills는 Messages API에서 `container.skills`와 code execution을 통해 사용됩니다.
- 즉 스킬은 "특정 CLI 전용 기능"이 아니라, API와 에이전트 런타임 모두에서 붙일 수 있는 실행 지식 단위로 보는 편이 맞습니다.
### 3.4 로빙 관점의 판단
- 로빙은 `존재형 에이전트 + 스킬 서비스 생태계`를 지향하므로,
- 핵심 판단 루프는 자체 런타임이 갖고, LLM API는 그 안의 추론 부품으로 두는 쪽이 더 일관적입니다.
- Agent API/CLI 런타임은 참고 구현 또는 벤치마크 대상으로 보는 것이 안전합니다.
- Google 공식 문서도 Gemini CLI를 "터미널에서 Gemini에 접근하는 오픈소스 AI agent"이자 ReAct 루프 기반 도구라고 설명합니다.
## 3-1. 실행 방식 선택: API 소비자 vs CLI 운영자
### 3-1.1 API 방식
- 내부 서비스가 잘 설계된 API를 제공하면, 로빙은 단순히 HTTP 호출만으로 기능을 소비할 수 있습니다.
- 이 구조는 가장 안전하고 단순합니다.
### 3-1.2 CLI 방식
- 로빙이 `docker exec`, `docker compose up`, 로컬 스크립트 실행을 직접 제어하는 구조입니다.
- 이 구조는 더 강한 운영자 역할을 가능하게 하지만, 권한/위험 제어가 반드시 필요합니다.
### 3-1.3 추천
- 안정적 기능은 API 경로로 남기고,
- 복구, 디버깅, 기동 제어가 필요한 경로만 CLI 권한을 주는 방식이 가장 현실적입니다.
## 4. LangGraph, PydanticAI, 자체 루프와 이 문서의 관계
- 이 문서는 "무슨 모델을 쓸까"에 대한 문서이지, "어떤 오케스트레이터가 절대 정답인가"를 확정하는 문서는 아닙니다.
- 특히 [260311_naverworks_briefing_insight_preamble_leak_fix_plan.md](../../plans/260311_naverworks_briefing_insight_preamble_leak_fix_plan.md) 에는 이미 특정 이슈를 `LangGraph를 버리거나 Pydantic AI를 새로 도입해서 닫지 않는다`는 판단이 남아 있습니다.
- 따라서 모델 선택 리서치는 프레임워크 교체 결론과 분리해야 합니다.
## 5. 모델 선택 기준
로빙 관점에서는 모델을 "더 똑똑한가" 하나로 고르기보다 아래 기준으로 봐야 합니다.
### 5.1 추론 품질
- 에러 로그를 보고 다음 액션을 좁힐 수 있는가
- 구조화 출력 형식을 잘 지키는가
- 과한 서론 없이 계약된 형식으로 답할 수 있는가
### 5.2 비용 효율
- 뉴스 요약, 라우팅, 간단 분류처럼 반복 호출이 많은 작업을 감당할 수 있는가
- 고난도 판단과 저난도 분류를 같은 모델로 처리해야 하는가
### 5.3 컨텍스트와 멀티모달
- 긴 문서, 다수 스킬 계약, 히스토리, 로그를 한 번에 넣어야 하는가
- 이미지/오디오/문서 해석이 핵심인가
### 5.4 운영 안정성
- 모델명과 환경변수를 단일 SSOT로 관리하기 쉬운가
- 폴백 없이 fail-fast 구조를 유지할 수 있는가
- 할당량, 쿼터, 응답 형식 변동에 대한 대응이 쉬운가
## 6. 공식 문서로 다시 본 현재 판단
### 6.1 OpenAI
- OpenAI 공식 가격 문서 기준 2026-03-12:
- `GPT-5.4`: 입력 `$2.50`, 출력 `$15.00` / 1M tokens
- `GPT-5 mini`: 입력 `$0.25`, 출력 `$2.00` / 1M tokens
- Responses API 문서는 built-in tools와 function calling을 지원하는 상위 인터페이스로 설명합니다.
- OpenAI 가격 문서에는 모델 가격과 built-in tools 가격이 분리돼 있으며, 별도의 "Responses API 호출 수수료" 항목은 찾지 못했습니다.
- 따라서 현재 해석은 `Responses API 자체에 별도 호출료가 붙는다기보다, 모델 토큰 비용 + 사용한 built-in tools 비용` 구조로 보는 것이 타당합니다.
- Built-in tools 예시로 Hosted Shell / Code Interpreter 컨테이너 비용도 별도 표기돼 있습니다.
### 6.2 Codex
- OpenAI Codex 모델 문서상 `gpt-5.2`는 "coding and agentic tasks"용 일반 목적 모델이었고 `GPT-5.4`에 의해 대체됐다고 적혀 있습니다.
- 이 문맥상 Codex는 독립된 "별종 모델 체계"라기보다, 코딩/에이전트 런타임과 모델 계열이 결합된 제품군으로 이해하는 편이 덜 헷갈립니다.
- 즉 "GPT-5.4 모델"과 "Codex 런타임"을 분리해서 보는 것이 현재 문서 해석에 더 가깝습니다.
### 6.3 Google Gemini
- Gemini 2.5 Flash-Lite 공식 모델 문서는 이 모델을 "most cost-efficient multimodal model"이며 "high-frequency, lightweight tasks", "high-volume classification", "simple data extraction", "extremely low-latency applications"에 적합하다고 설명합니다.
- 따라서 현재 사용 중인 `gemini-2.5-flash-lite`를 로빙의 핵심 자가수정 루프에 단독 메인 엔진으로 두는 것은 보수적으로 다시 봐야 합니다.
- Gemini 가격 문서 기준 2026-03-12:
- `Gemini 2.5 Flash-Lite`: 입력 `$0.10`, 출력 `$0.40`
- `Gemini 3.1 Flash-Lite Preview`: 입력 `$0.25`, 출력 `$1.50`
- `Gemini 3 Flash Preview`: 입력 `$0.50`, 출력 `$3.00`
- 모두 1M tokens 기준
- Gemini 3.1 Flash-Lite Preview는 공식 문서에서 "high-volume agentic tasks" 최적화로 설명됩니다.
- Gemini 3 Flash Preview는 공식 문서에서 "our most intelligent model built for speed"로 설명됩니다.
## 7. 현재 문서 기준 비교 판단
### 6.1 Gemini 계열
- 강점:
- 로빙 현재 구조와 가장 가깝게 이미 사용 중
- `rb8001`, `skill_news`에 이미 설정 경로가 정리돼 있음
- 긴 컨텍스트와 요약/분류 계열 작업에 친화적인 흔적이 문서에 많음
- 약점:
- 가격/모델 라인업 변화가 빨라 문서가 금방 낡음
- Flash Lite 계열은 복잡한 자가수정 루프에선 한계가 있을 수 있음
### 6.2 OpenAI 계열
- 강점:
- 구조화 출력, 툴 호출, 코딩 중심 작업에서 비교 대상으로 의미가 큼
- CLI/에이전트 런타임 사례와 연결해 보기 쉬움
- 약점:
- 현재 로빙 운영 경로의 1차 기본값은 아님
- 비용과 모델 교체 주기가 빠르므로 운영 SSOT로 바로 고정하기엔 변동성이 큼
### 6.3 Anthropic 계열
- 강점:
- 코딩/도구 사용 관점 비교군으로 자주 언급됨
- 구조화된 에이전트 UX 참고 대상으로 가치가 있음
- Skills를 API에서 다루는 공식 패턴이 문서화돼 있어 설계 참고 가치가 큼
- 약점:
- 현재 로빙 핵심 서비스의 기본 모델로 연결돼 있지는 않음
## 8. 현재 추천 구성
### 8.1 지금 당장 가장 현실적인 구성
- 로빙 메인 루프:
- `Gemini 2.5 Flash` 또는 `Gemini 3 Flash Preview` 검토
- 고비용 고난도 복구:
- `GPT-5.4`
- 초경량 반복 작업:
- `Gemini 2.5 Flash-Lite`
### 8.2 보수적 추천
- 비용과 안정성을 같이 보면,
- `2.5 Flash-Lite`는 뉴스 요약, 단순 분류, 가벼운 추출용 보조 모델로 두고
- 메인 에이전트 루프는 그보다 한 단계 위 모델로 올리는 편이 자연스럽습니다.
### 8.3 왜 CLI 에이전트를 백엔드로 바로 삼지 않나
- Gemini CLI는 공식적으로도 ReAct 루프 기반 오픈소스 AI agent입니다.
- 하지만 로빙이 필요한 것은 `종료 기준`, `재시도 규칙`, `위험 명령 차단`, `기억/성장`, `스킬 서비스 생태계`까지 묶인 자체 루프입니다.
- 그래서 CLI 에이전트는 참고 구현체로 보고, 로빙 본체는 별도로 가져가는 편이 맞습니다.
### 8.4 왜 일반 LLM API만으로도 충분한가
- 일반 LLM API만 써도 로빙이 직접 아래를 구현하면 충분히 에이전트가 됩니다.
- 명령 실행기
- 결과 수집기
- 오류 판단 루프
- 재시도 정책
- 위험 명령 차단
- 즉 부족한 것은 모델보다 런타임일 가능성이 큽니다.
## 9. 비용 비교를 문서화할 때의 원칙
### 7.1 가격은 공통 SSOT로 고정하지 않는다
- 가격은 매우 자주 바뀝니다.
- 따라서 이 문서는 "최신 가격표"를 영구 SSOT로 삼지 않습니다.
- 최신 가격은 실제 모델 선정 시점에 공식 문서로 재검증해야 합니다.
### 7.2 문서에는 무엇을 남길까
- 남길 것:
- 어떤 작업군에 어떤 모델이 적합했는지
- 왜 그 모델을 골랐는지
- 호출량과 실패 패턴
- 비용이 문제였는지 여부
- 고정하지 않을 것:
- 장기 SSOT처럼 박아두는 숫자 가격표
- 검증 없는 외부 블로그 기반 최신 가격 단정
### 7.3 가격 문서의 적절한 형태
- `리서치`: 특정 시점의 비교와 판단 근거
- `플랜`: 왜 특정 모델로 전환할지
- `워크로그`: 실제 적용 후 비용/품질 결과
## 10. 구스카운실 계열 흔적과의 연결
- 공통 추출 문서인 [project-essence-extracts.md](/home/admin/0_VALUE/02_Governance/project-essence-extracts.md) 에 따르면 `TheGooseCouncil`은 `접속 기반 에이전트`, `룰베이스 최소화`, `저니 안/밖 분리`를 핵심으로 가집니다.
- 이 관점은 로빙의 모델 선택에도 그대로 적용됩니다.
- 모델 선택은 철학 문서가 아니라 실행 저니 문서에 남겨야 하고
- 한 번의 비교 결과를 영구 진리처럼 고정하면 안 되며
- 고정 규칙보다 반복 검증된 운영 판단이 축적돼야 합니다.
## 11. 로빙에 대한 현재 추천 문서화 방향
### 9.1 지금 유지할 문서
- 구조 아이디어: [260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md](../../ideas/260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md)
- 구조 리서치: [260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md](./260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md)
- 모델/비용 리서치: 이 문서
### 9.2 다음에 추가할 문서
1. `모델 선택 계획`
- 예: `Gemini Flash Lite 유지 vs 상위 모델 전환`
2. `샘플 워크로그`
- 동일 작업을 두 모델로 실행했을 때 품질, 실패율, 토큰 비용 비교
3. `스킬별 모델 라우팅 계획`
- 뉴스 요약, 의도 분류, 자가수정, 슬랙 포맷팅에 서로 다른 모델을 쓸지 결정
## 12. 결론
현재 로빙 기준으로는 `자체 런타임 + LLM API` 구조가 중심이며, Agent API는 참고 대상입니다.
모델 선택 문서는 구조 문서와 분리해 `실행 저니 리서치`로 남기는 것이 맞고, 가격 숫자는 영구 SSOT가 아니라 시점성 있는 비교 근거로만 다루는 편이 공통 원칙과도 맞습니다.
한 줄 권고로 줄이면 아래와 같습니다.
- 먼저 `로빙의 에이전트 루프와 도구 프로토콜`을 만든다.
- 스킬은 그 위에 얹는 실행 지식으로 본다.
- `gemini-2.5-flash-lite` 단독 메인 루프보다는 상위 모델 + 경량 모델 보조 구성이 더 현실적이다.
## 관련 문서
- [로빙 에이전트 루프와 스킬 훅 구조 아이디어](../../ideas/260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md)
- [로빙 에이전트 루프, 스킬 훅, LLM 실행 구조 리서치](./260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md)
- [NAVER WORKS 브리핑 인사이트 서두 누출 수정 계획](../../plans/260311_naverworks_briefing_insight_preamble_leak_fix_plan.md)
- [rb8001 README](../../../rb8001/README.md)
- [skill_news README](../../../skill_news/README.md)
- [프로젝트 Essence Extracts](/home/admin/0_VALUE/02_Governance/project-essence-extracts.md)
## 외부 참고
- [Anthropic: Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide)
- [OpenAI Pricing](https://openai.com/api/pricing/)
- [OpenAI Responses Overview](https://developers.openai.com/api/reference/responses/overview)
- [OpenAI Tools Guide](https://developers.openai.com/api/docs/guides/tools)
- [OpenAI Codex Models](https://developers.openai.com/codex/models)
- [Google Gemini 2.5 Flash-Lite Model Guide](https://ai.google.dev/gemini-api/docs/models/gemini-2.5-flash-lite)
- [Google Gemini Developer API Pricing](https://ai.google.dev/gemini-api/docs/pricing)
- [Google Gemini CLI](https://developers.google.com/gemini-code-assist/docs/gemini-cli)

233
journey/research/orchestration_tools/260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md Normal file
View File

@ -0,0 +1,233 @@
---
tags:
- Robeing
- AgentLoop
- SkillHooks
- LLM
- Orchestration
date: 2026-03-12
modification_date: 2026-03-12
---
# 로빙 에이전트 루프, 스킬 훅, LLM 실행 구조 리서치
## 1. 목적
이 문서는 다음 질문에 답하기 위한 리서치입니다.
1. 로빙은 LLM API를 쓸 때 어떤 부분을 직접 구현해야 하는가
2. 스킬은 단순 프롬프트 저장과 무엇이 다른가
3. `스킬별 훅` 구조는 어떤 의미를 가지는가
4. LangGraph, PydanticAI, 자체 루프 중 어떤 접근이 로빙에 더 맞는가
## 2. 핵심 판단
- LLM API는 기본적으로 `판단기`이고, 실행기와 상태 관리는 로빙 런타임이 책임져야 합니다.
- 스킬은 단순한 프롬프트 템플릿보다 넓은 개념이며, 최소한 `실행 절차`, `입출력 계약`, `권한`, `실패 기준`, `완료 기준`을 포함해야 합니다.
- `스킬별 훅`은 로빙 본체의 공통 루프를 유지하면서도 스킬별 복구·검증·후처리를 분리하는 방식으로 유효합니다.
- 로빙에는 완전 하드코딩 플로우보다 `제한된 자율 루프 + 명시적 종료 조건 + 스킬 계약`의 하이브리드 구조가 더 적합합니다.
- 스킬은 CLI 전용 기능으로 보기보다, API와 에이전트 런타임 양쪽에서 붙일 수 있는 실행 지식 단위로 해석하는 편이 공식 문서 흐름과도 맞습니다.
## 3. LLM API와 에이전트 런타임의 차이
### 3.1 LLM API
- 텍스트 또는 구조화 입력을 받고 다음 행동을 제안하는 추론기입니다.
- 자체적으로 로컬 셸, Docker, 파일시스템을 직접 만지지 않습니다.
- 따라서 "에러를 보고 라이브러리를 설치하자"라는 판단은 할 수 있어도, 실제 설치 실행은 별도 런타임이 필요합니다.
### 3.2 에이전트 런타임
- LLM의 응답을 받아 툴 실행으로 연결하는 래퍼입니다.
- 보통 다음 책임을 집니다.
- 프롬프트 조립
- 스킬/도구 목록 주입
- 구조화 응답 파싱
- 셸/API/파일 실행
- 결과 관찰 및 다음 루프 전달
- 권한/승인/로그/재시도 통제
### 3.3 로빙 관점
- 로빙은 특정 벤더의 "에이전트 API"를 반드시 써야만 하는 것이 아니라,
- 자체 런타임 위에 LLM API를 두고 같은 구조를 구현할 수 있습니다.
- 이 해석이 로빙의 독립성, 지속성, 서비스 분리 철학과 더 잘 맞습니다.
### 3.4 CLI 에이전트는 참고 구현체다
- Gemini CLI 공식 문서는 Gemini CLI를 ReAct 루프 기반의 오픈소스 AI agent로 설명합니다.
- 이런 CLI 에이전트는 좋은 참고 구현체이지만, 로빙의 종료 규칙, 위험 제어, 기억/성장, 스킬 서비스 연결을 그대로 대신해주지는 않습니다.
- 따라서 로빙은 CLI를 백엔드로 삼기보다, 자체 루프 설계의 참고 대상으로 삼는 편이 맞습니다.
## 4. 스킬과 프롬프트 DB의 차이
| 구분 | 프롬프트 DB | 스킬 |
|---|---|---|
| 본질 | 재사용 가능한 문장 | 실행 가능한 작업 단위 |
| 내용 | 지시 문구 | 지시 + 절차 + 권한 + 실패/완료 조건 |
| 실행 주체 | 사용자 또는 상위 로직이 직접 선택 | 로빙 런타임이 문맥에 따라 선택 가능 |
| 결과 | 다음 텍스트 생성 | 실행 결과, 로그, 후속 액션 유발 |
정리하면, 스킬은 "무슨 말을 모델에게 넣을까"보다 "이 작업을 안전하게 끝내려면 어떤 계약이 필요한가"에 가깝습니다.
## 5. 스킬별 훅의 의미
### 5.1 정의
`스킬별 훅`은 스킬이 단순 실행 함수가 아니라, 로빙 본체 루프의 특정 단계에서 개입할 수 있는 포인트를 가진다는 뜻입니다.
### 5.2 필요한 이유
- 스킬마다 선행조건이 다릅니다.
- 스킬마다 실패 패턴과 복구 방식이 다릅니다.
- 스킬마다 성공 후 필요한 후처리가 다릅니다.
- 이 차이를 본체에 하드코딩하면 로빙이 빠르게 비대해집니다.
### 5.3 예시 훅
- `before_plan`: 스킬 선택 전 참고 정보 제공
- `before_run`: 실행 전 입력 검증, 세션/컨테이너 준비
- `after_run`: 원시 결과를 표준 결과로 변환
- `on_error`: 재시도 가능 여부, 복구 액션, 사용자 노출 문구 제안
- `on_close`: 로그, 기억, 메트릭, 후속 스킬 연결
## 6. 로빙의 최소 실행 구조
### 6.1 권장 루프
1. 목표 해석
2. 다음 액션 선택
3. 스킬 또는 내부 기능 실행
4. 결과 관찰
5. 완료 여부 판단
6. 실패 시 복구 또는 사용자 보고
7. 기억/로그/정책 갱신 후 종료
### 6.2 중요한 점
- 종료 조건은 LLM의 감에만 맡기면 안 됩니다.
- 최소한 아래는 런타임이 강제해야 합니다.
- 최대 반복 횟수
- 허용 툴 목록
- 완료 신호 형식
- 치명 실패 기준
- 사용자 승인 필요 작업
### 6.3 일반 LLM API를 쓸 때 로빙이 직접 가져야 하는 것
- 일반 LLM API는 셸을 대신 열어주지 않습니다.
- 따라서 로빙이 실제로 실행 가능한 에이전트가 되려면 최소한 아래 계층을 직접 가져야 합니다.
- 명령 실행기
- 실행 결과 수집기
- 오류 판단 루프
- 재시도 규칙
- 위험 명령 차단 규칙
- 여기서 "셸을 연다"는 말은 GUI 터미널 창을 띄운다는 뜻이 아니라, `subprocess` 같은 방식으로 명령을 실행할 수 있는 실행기를 둔다는 뜻에 가깝습니다.
### 6.4 실행기와 판단기의 역할 분리
- LLM은 `무엇을 할지`를 판단합니다.
- 로빙 런타임은 `실제로 실행하고 결과를 회수`합니다.
- 예시 흐름:
1. 사용자 요청 수신
2. LLM이 다음 액션을 구조화 응답으로 반환
3. 로빙이 `subprocess` 또는 HTTP 호출로 실행
4. stdout, stderr, 종료 코드를 수집
5. 결과를 다시 다음 판단 입력으로 전달
## 6-1. API 방식과 CLI 실행 방식의 경계
### 6-1.1 API 방식
- 컨테이너 또는 서비스가 안정적인 HTTP API를 제공하면 가장 단순한 선택입니다.
- 장점:
- 구조가 단순함
- 권한 통제가 쉬움
- 디버깅과 계약 관리가 쉬움
- 이 방식의 로빙은 "서비스 소비자"에 가깝습니다.
### 6-1.2 CLI 실행 방식
- 로빙이 `docker exec`, `docker compose up`, 내부 스크립트 실행 등을 직접 제어하는 방식입니다.
- 장점:
- 컨테이너 기동/복구 가능
- 내부 로그와 오류를 더 깊게 다룰 수 있음
- API로 노출되지 않은 내부 도구를 직접 쓸 수 있음
- 이 방식의 로빙은 "운영자"에 가깝습니다.
### 6-1.3 무엇이 더 맞는가
- 둘 중 하나만 정답은 아닙니다.
- 안정적 기능은 API로 두고,
- 운영/복구/디버깅이 필요한 경로만 CLI 실행 권한을 주는 하이브리드가 가장 현실적입니다.
## 7. LangGraph, PydanticAI, 자체 루프 비교
## 7.1 LangGraph
- 장점:
- 상태 관리와 재개가 강함
- 분기, 체크포인트, 장기 실행에 유리
- 단점:
- 초기 설계가 무거워질 수 있음
- 모든 복구 흐름을 그래프에 담으려 하면 과설계 위험이 있음
## 7.2 PydanticAI
- 장점:
- 구조화 출력과 툴 인터페이스 설계가 단순함
- Python 중심 구현에 빠름
- 단점:
- 장기 상태 관리와 복잡한 운영 재개는 별도 설계가 필요함
## 7.3 자체 루프
- 장점:
- 로빙 철학과 서비스 구조에 정확히 맞출 수 있음
- `rb8001 + skill-* + gateway` 구조와 직접 연결하기 좋음
- 단점:
- 가드레일, 상태, 재시도, 로깅을 직접 구현해야 함
## 7.4 현재 로빙에 대한 판단
- 지금 단계의 로빙에는 `자체 최소 루프 + 구조화 응답 + 스킬 계약`이 우선입니다.
- 이후 장기 실행, 승인 대기, 중단/재개 요구가 커지면 LangGraph류를 부분 도입하는 것이 합리적입니다.
- PydanticAI는 프로토타입이나 구조화 툴 호출 계층에서 참고 가치가 있습니다.
## 8. 뉴스 스킬 사례에 대한 해석
사용자 요청이 "AI 뉴스를 보여줘"일 때 가능한 구조는 아래와 같습니다.
1. 로빙이 목표를 해석합니다.
2. `news` 스킬 계약을 읽고 실행 방법을 선택합니다.
3. 내부 API 호출 또는 컨테이너 내부 실행 중 하나를 사용합니다.
4. 결과를 표준 구조로 변환합니다.
5. 필요하면 `slack` 스킬로 전달합니다.
6. 성공/실패를 검증하고 종료합니다.
여기서 중요한 점은 "반드시 API 호출이어야 한다" 또는 "반드시 셸 실행이어야 한다"가 아니라, 어떤 방식이든 계약과 검증이 먼저라는 것입니다.
### 8.1 뉴스 스킬에 그대로 적용하면
- 단순 뉴스 검색은 API 방식이 더 적합할 수 있습니다.
- 반대로 아래 상황이면 CLI 실행 방식이 필요해집니다.
- 컨테이너가 꺼져 있으면 직접 띄워야 함
- 내부 스크립트를 직접 돌려야 함
- 상세 stderr와 trace를 읽어야 함
- 내부 테스트나 수정 후 재실행이 필요함
## 8-1. 추가 보정: 스킬과 런타임의 경계
- 스킬은 로빙의 본체가 아닙니다.
- 스킬은 로빙이 읽고 사용할 수 있는 작업 지식, 절차, 리소스 묶음입니다.
- 실제 `실행`, `관찰`, `종료`, `재시도`, `위험 작업 차단`은 로빙 루프가 책임져야 합니다.
- 이 경계를 흐리면 "스킬을 붙이면 자동으로 에이전트가 완성된다"는 착시가 생깁니다.
## 9. 로빙 철학과의 정합성
- 존재형 에이전트는 기억과 판단의 연속성이 있어야 합니다.
- 따라서 스킬 체계도 일회성 자동화보다 `설명 가능한 선택`, `실패 가시성`, `반성 가능한 로그`를 지원해야 합니다.
- 이는 `Value First`, `Truth First`, `Trust by Design`, `실패 가시성 원칙`과 일치합니다.
## 10. 남은 과제
1. 스킬 계약 문서 최소 스키마 정의
2. 로빙 본체 완료 기준 명세
3. 실패 분류 체계와 재시도 한계 정의
4. 사용자 승인 필요 액션 목록화
5. `news`, `slack`, `email` 중 1개를 샘플 구현으로 검증
## 11. 결론
로빙은 "LLM이 모든 것을 알아서 하는 시스템"이 아니라, LLM 판단을 실행 가능한 구조로 묶는 런타임이어야 합니다.
스킬은 프롬프트 모음이 아니라 계약 있는 실행 단위여야 하며, 스킬별 훅은 이 실행 단위를 로빙의 자기개선 루프에 안전하게 연결하는 방식으로 이해하는 것이 적절합니다.
## 관련 문서
- [로빙 에이전트 루프와 스킬 훅 구조 아이디어](../../ideas/260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md)
- [로빙 LLM API·Agent API·모델 선정·비용 비교 리서치](./260312_로빙_LLM_API_Agent_API_모델선정_비용비교_리서치.md)
- [NAVER WORKS 브리핑 인사이트 서두 누출 수정 계획](../../plans/260311_naverworks_briefing_insight_preamble_leak_fix_plan.md)
## 외부 참고
- [Anthropic: Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide)
- [Google Gemini CLI](https://developers.google.com/gemini-code-assist/docs/gemini-cli)
- [OpenAI Responses Overview](https://developers.openai.com/api/reference/responses/overview)

2
journey/research/orchestration_tools/README.md
View File

@ -5,3 +5,5 @@
- [LangGraph vs n8n 비교](250925_langgraph_vs_n8n_comparison.md) — LLM 에이전트·워크플로우 오케스트레이션 도구 비교
- [OpenClaw 로빙 적용 리서치](260205_openclaw_로빙_적용_리서치.md) — OpenClaw 아키텍처 분석 및 로빙 적용 아이디어 (로컬 클론: `ivada/openclaw`)
- [OpenClaw 공식 문서 요약](260205_openclaw_official_docs_summary.md) — docs.openclaw.ai 요약 및 로빙 적용 우선순위
- [로빙 에이전트 루프·스킬 훅·LLM 실행 구조 리서치](260312_로빙_에이전트루프_스킬훅_LLM실행구조_리서치.md) — LLM API, 에이전트 런타임, 스킬 계약, 훅 구조를 로빙 기준으로 정리
- [로빙 LLM API·Agent API·모델 선정·비용 비교 리서치](260312_로빙_LLM_API_Agent_API_모델선정_비용비교_리서치.md) — Gemini/OpenAI 계열 비교, 비용 문서화 원칙, 로빙 기준 모델 선택 방향 정리