tags: [robeing, skills, skill-docs, context-injection, orchestration, ideas]

# 스킬 계약 문서 기반 컨텍스트 오케스트레이션 아이디어

상위 원칙:
- [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
- [0_VALUE Agents Guide](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/agents-rules.md)
- [AI 에이전트 시대의 CLI·스킬·인터페이스 진화](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/ai-agent-cli-skill-interface-evolution.md)
- [스킬 계약 및 실행 원칙](../../book/300_architecture/316_skill-contract-and-execution-principles.md)

## 문제 인식

- 현재 로빙은 `rb8001`이 각 `skill-*` 서비스 API를 직접 알고 호출하는 비중이 큽니다.
- 이 구조에서는 스킬 선택 기준, 입력 제약, 권한, 실패 기준, 완료 기준이 코드와 프롬프트 주변에 흩어지기 쉽습니다.
- 그 결과 `rb8001`이 오케스트레이터라기보다 스킬별 호출 세부사항까지 떠안는 본체가 되기 쉽습니다.
- 스킬이 늘어나거나 계약이 바뀔수록 본체 프롬프트와 분기 로직을 직접 수정해야 하는 압력이 커집니다.

## 아이디어

- 로빙은 먼저 사용자 요청을 구조화해서 "무슨 종류의 일인지", "어떤 스킬 후보가 필요한지"를 더 명확히 해석하는 방향으로 갈 수 있습니다.
- 이때 의도분석 결과는 자유서술보다 typed contract에 가까운 형태로 다뤄져, 후속 스킬 선택의 입력이 되는 구조를 기대합니다.
- 각 스킬마다 `SKILL.md`를 두고, 입력/출력/권한/실행/실패/검증 계약을 그 문서에 고정합니다.
- 로빙은 스킬을 실행하기 전에 해당 문서 전체를 장문으로 주입하는 대신, 의도분석 결과에 따라 현재 요청과 관련된 후보 스킬의 핵심 계약만 추려 컨텍스트로 사용할 수 있습니다.
- 이렇게 되면 `rb8001`의 중심 책임은 "직접 API 세부 호출을 기억하는 본체"가 아니라 "어떤 스킬을 언제 어떤 계약으로 연결할지 판단하는 오케스트레이션 브레인"으로 이동합니다.
- 스킬 구현은 계속 각 `skill-*` 서비스에 두고, 본체는 계약 해석, 스킬 선택, 실행 결과 관찰, 다음 행동 결정을 담당합니다.

## 기대하는 사용 흐름

- 사용자가 요청하면 로빙은 먼저 이것이 메일, 일정, 리서치, 전송, 게시 같은 어떤 작업 성격인지 구조화해 해석하는 쪽으로 갈 수 있습니다.
- 그 다음 로빙은 전체 스킬 문서를 다 들고 있는 대신, 지금 요청과 관련된 몇 개 스킬만 후보로 좁히고 그 스킬들의 계약만 읽는 구조를 기대합니다.
- 이후 로빙은 그 계약을 바탕으로 어떤 스킬을 먼저 쓰고, 어떤 결과를 다음 스킬에 넘길지 판단하는 브레인 역할을 맡게 됩니다.
- 예를 들어 "오늘 일정 확인하고 슬랙에도 공유해줘" 같은 요청에서는 일정 확인과 메시지 전송이 각각 다른 스킬 계약으로 해석되고, 로빙은 두 스킬을 연결하는 조율자 역할을 하게 됩니다.

## 이 아이디어가 상상하는 최소 해석 단위

- 의도분석은 적어도 아래 정도를 구조화해 돌려주는 방향을 상상합니다.
- `task_type`: 메일, 일정, 리서치, 전송, 게시 같은 작업 성격
- `goal`: 사용자가 실제로 원하는 최종 결과
- `required_capabilities`: 필요한 능력이나 작업 조각
- `candidate_skills`: 호출 후보가 되는 스킬 목록
- `needs_human_confirmation`: 승인이나 확인이 필요한지 여부
- 중요한 점은 이 필드명이 최종안이라는 뜻이 아니라, 자유서술 대신 "후속 스킬 선택에 바로 쓰일 수 있는 구조"가 필요하다는 것입니다.

## 후보 스킬 축소에 대해 기대하는 기준

- 모든 스킬을 항상 컨텍스트에 넣는 대신, 현재 요청과 직접 관련된 스킬만 후보로 올리는 방향을 기대합니다.
- 후보 축소는 적어도 `작업 성격`, `필수 능력`, `권한 필요 여부`, `금지 조건` 정도를 기준으로 판단하는 그림을 상상합니다.
- 예를 들어 단순 일정 조회 요청이면 `calendar`가 올라가고, 메일 발송이나 퍼블리시는 후보에서 빠지는 쪽이 더 자연스럽습니다.
- 이렇게 해야 본체가 스킬 전체 카탈로그를 매번 장문으로 들고 있지 않아도 되고, 컨텍스트 오염도 줄일 수 있습니다.

## 기대 효과

- 의도분석과 스킬 실행 사이에 계약 기반 경계가 생겨, 본체가 모든 스킬 세부 호출을 직접 외우지 않아도 되는 방향을 기대할 수 있습니다.
- 스킬 추가나 변경 시 본체 하드코딩보다 스킬 계약 문서와 로더를 먼저 갱신하는 구조로 전환할 수 있습니다.
- `rb8001`과 `skill-*`의 책임 경계가 더 선명해집니다.
- 스킬 호출 방식이 HTTP API이든 제한적 CLI이든 상관없이 같은 계약 해석 구조로 묶을 수 있습니다.
- 실패 기준과 검증 기준을 문서와 런타임에서 같은 언어로 다루기 쉬워집니다.

## 참고 해석

- 이 방향은 `reference` 계층의 `openclaw`에서 보이는 "본체는 오케스트레이션, 도구는 계약 있는 실행 단위"라는 패턴을 참고한 것입니다.
- 다만 `reference/openclaw`의 코드나 문서를 로빙 운영 기준으로 직접 가져오는 것이 아니라, 로빙 문서에 다시 고정한 뒤 검증 가능한 구조로 바꿔야 합니다.
- 따라서 이 아이디어의 핵심은 OpenClaw 이식이 아니라, 스킬 계약 문서와 컨텍스트 로더를 로빙 기준으로 재해석하는 것입니다.

## 검증이 필요한 이유

- 실제로 어떤 스킬부터 `SKILL.md`를 만들지, 그리고 어떤 필드를 공통 표준으로 강제할지는 아직 확정되지 않았습니다.
- 의도분석을 어떤 typed contract 수준으로 다루는 것이 가장 적절한지도 아직 열려 있습니다.
- 문서 기반 컨텍스트 로딩이 본체 프롬프트 복잡도와 실행 품질을 실제로 얼마나 낮추는지 확인이 필요합니다.
- 현재 `rb8001` 코드 경계에서 직접 API 호출 로직과 오케스트레이션 로직을 어디까지 분리할 수 있는지도 조사해야 합니다.
- 스킬 문서와 실제 API/CLI 동작이 어긋나면 SSOT가 아니라 문서 부채가 될 수 있으므로, 검증 루프 설계가 먼저 필요합니다.

## 이 문서를 닫기 위해 바로 넘길 질문

- 현재 `rb8001` 의도분석 출력에서 typed contract로 끌어올릴 최소 필드는 무엇인가
- 현재 스킬 목록 중 `SKILL.md` 1차 대상은 무엇이며, 공통 계약과 개별 계약은 어디서 갈리는가
- 후보 스킬 축소에 필요한 최소 기준은 무엇이며, 지금 코드와 문서에서 어디까지 이미 존재하는가

## 이 문서에서 아직 확정하지 않는 것

- 의도분석 typed contract의 최종 필드와 표현 방식
- 스킬별 `SKILL.md` 템플릿의 최종 필드
- 어떤 스킬을 1차 문서화 대상으로 삼을지에 대한 우선순위
- `rb8001` 내부 로더 구조와 프롬프트 조립 방식의 구체 구현
- API 우선 호출과 제한적 CLI 호출의 최종 경계

## 다음 문서

- [스킬 계약 문서 기반 컨텍스트 오케스트레이션 리서치](../research/260314_스킬_계약_문서_기반_컨텍스트_오케스트레이션_리서치.md)
- `plans`: 어떤 스킬부터 어떤 순서로 `SKILL.md`를 만들고, 본체 로더를 어디까지 바꿀지 고정합니다.

## 관련 문서

- [OpenClaw 기반 로빙 개선 아이디어](./260309_openclaw_기반_로빙_개선_아이디어.md)
- [로빙 에이전트 루프와 스킬 훅 구조 아이디어](./260312_로빙_에이전트루프와_스킬훅_구조_아이디어.md)
- [스킬 계약 및 실행 원칙](../../book/300_architecture/316_skill-contract-and-execution-principles.md)
