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`