rig
무엇인가
Rig는 Rust 애플리케이션 안에서 LLM 호출, 도구 호출, 임베딩, 벡터 검색을 하나의 타입 계약으로 묶는 계층이다. 모델 제공자 SDK를 애플리케이션 코드에 직접 결합하지 않도록, 제공자 중립 추상화와 에이전트 오케스트레이션을 분리해 두는 자리에 놓인다.
어떻게 동작하나
구성은 두 크레이트로 나뉜다. `rig-core`는 제공자 중립 메시지, 완성 모델, 이식 가능한 도구 계약과 컨텍스트 도구 계약, 메모리·벡터 스토어 계약, 내장 제공자 매핑을 담는다. `rig-agent`는 클래식 빌더, 프롬프트·스트리밍 트레이트, 타입 지정 훅, 라이브 도구 레지스트리, 추출, 직렬화 가능한 `AgentRun` 상태 머신을 담고 기본 활성화된다. 루트 `rig` 파사드는 두 크레이트를 기존 경로로 재수출하며 통합별로 feature flag를 하나씩 노출한다. `rig::memory`는 `memory` feature 없이도 `rig-core`의 대화 메모리 트레이트와 인메모리 백엔드를 제공하고, feature를 켜면 `rig-memory`의 히스토리 정형 정책 타입이 같은 모듈에 추가된다.
무엇과 다른가
제공자별 SDK를 각각 의존해 응답 형식과 스트리밍 처리를 따로 작성하는 방식과 달리, 모델 제공자와 벡터 스토어를 각각 하나의 통일 인터페이스 뒤에 둔다. 또 이식 가능한 제공자·백엔드 계약(`rig-core`)과 에이전트 오케스트레이션(`rig-agent`)을 크레이트 경계로 분리해, 오케스트레이션 없이 제공자 추상화만 쓰는 구성도 가능하다.
어떻게 쓰나
의존성에 `rig` 파사드를 추가하고 통합에 해당하는 feature를 켜서 쓴다. 예제 코드는 `#[tokio::main]`을 사용하므로 tokio의 `macros`, `rt-multi-thread` feature가 필요하다. 크레이트별 `examples` 디렉터리에 예제가 있고, 제공자별 통합 테스트는 `tests/providers`에 있으며 cassette 기반으로 기본 오프라인 재생된다. 실제 제공자 API가 필요한 라이브 전용 테스트는 별도로 분리되어 있다.
전제와 한계
WASM은 `wasm32-unknown-unknown` 대상의 이식 가능 코어와 클래식 런타임만 대상이며 WASI는 범위 밖이다. `rig-rmcp`/MCP는 네이티브 전용이다. 프로젝트가 기능을 빠르게 추가하는 단계라 향후 업데이트에 호환성을 깨는 변경이 포함되고, 변경 사항과 마이그레이션 경로는 별도로 표기된다.
관련 논문 2
유사 도구
- langchainLLM 애플리케이션과 에이전트를 조립하는 Python 프레임워크다. 모델·임베딩·벡터 스토어·툴을 표준 인터페이스로 감싸 제공자 교체를 코드 수정 없이 처리한다.
- aichat20개 이상 LLM 제공자를 하나의 인터페이스로 묶어 셸 명령 변환, REPL 대화, RAG, 함수 호출을 한 바이너리에서 처리하는 Rust CLI다.
- langchain4jJVM에서 LLM 애플리케이션을 만드는 Java 라이브러리다. 여러 LLM 제공자와 임베딩 스토어를 단일 API로 묶고 툴 호출·에이전트·RAG를 구현한다.
- haystack검색·라우팅·메모리·생성을 명시적 파이프라인과 에이전트 워크플로로 조립하는 Python LLM 오케스트레이션 프레임워크다.
- langflowLLM·벡터 DB·도구를 노드로 연결해 에이전트 플로우를 시각적으로 만들고, 이를 REST API나 MCP 서버로 배포하는 Python 플랫폼이다.
- llama_index사설 데이터를 수집·구조화해 LLM이 검색·질의할 수 있게 하는 Python 프레임워크다. 코어와 300여 개 통합 패키지를 조합해 RAG·에이전트 앱을 만든다.