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

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. 실패 시 사용자 보고, 자동 복구, 중단의 분기 기준을 정합니다.

바로 적용할 제품 방향

• 먼저 만들 것은 "스킬 플랫폼"보다 로빙의 에이전트 루프 + 도구 프로토콜입니다.
• 즉 모델 출력은 최소한 아래와 비슷한 구조화 액션으로 받는 편이 좋습니다.

{
  "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