---
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)
