18개월간의 구축, 재작성, 그리고 재고민 끝에 Jido 2.0이 출시되었습니다. 현재 Hex에서 이용 가능합니다.

Jido는 2024년에 BotHive라는 이름의 봇 플랫폼으로 시작되었습니다. 그러다 AI 파도가 몰아쳤고 모든 것이 변했습니다. 저는 이미 Elixir를 사용하고 있었고 한 가지 도박을 하기로 했습니다. 바로 BEAM가 에이전트 시스템 (agent systems)을 위한 최고의 런타임 (runtime)이라는 것이었습니다.

TypeScript 에이전트 프레임워크 (agent frameworks)는 장난감처럼 느껴졌습니다. 단일 스레드 이벤트 루프 (Single-threaded event loops)가 Promise와 기도에 의존하며 동시성 에이전트 (concurrent agents)들을 다루려 애쓰는 모습이었죠. Python 에이전트들은 조금 더 나았지만, 시간이 지나면 유지되지 못했습니다. BEAM는 정확히 이런 종류의 작업을 위해 구축되었습니다.

18개월 동안 BEAM 위에서 에이전트들을 다뤄본 결과, 그 도박은 확실히 결실을 보고 있는 것으로 보입니다.

1.0에서 2.0으로

Jido 1.0은 지난 3월에 출시되었지만, 솔직히 과하게 설계 (overengineered)되었습니다. 저는 여전히 OTP를 깊이 있게 배우는 중이었고, 그것이 결과물에 드러났습니다. 실제로는 의미 없는 추상화 (abstractions)들을 추가했습니다. 이로 인해 다른 에이전트 프레임워크들이 기본적으로 쉽게 제공하던 기본적인 작업들을 수행하는 데 너무 많은 마찰이 발생했습니다.

피드백은 명확하고 일관적이었습니다. 사람들은 프레임워크와 싸우는 것이 아니라 에이전트를 구축하고 싶어 했습니다. 저는 그 모든 피드백을 수렴하여 2.0에서 해결했습니다. 더 단순한 API. 더 적은 절차 (Less ceremony). 처음부터 BEAM 우선 (BEAM-first) 방식으로 설계했습니다.

우리가 출시한 내용은 다음과 같습니다:

강력하고 내구성이 뛰어난 에이전트 코어 (agent core)

Jido 2.0의 기반은 순수 함수형 에이전트 아키텍처 (pure functional agent architecture)입니다. 에이전트는 데이터입니다. GenServer 내부에서 실행될 수 있는 상태 (state), 액션 (actions), 그리고 도구 (tools)를 가진 구조체 (struct)입니다. 그게 전부입니다.

모든 것은 단일 함수인 cmd/2를 통해 흐릅니다.

액션이 입력되면, 업데이트된 에이전트와 지시 사항 (directives) 목록이 출력됩니다. 에이전트는 항상 단순한 데이터입니다. 부작용 (Side effects)은 런타임 (runtime)이 실행하는 타입화된 데이터 구조인 지시 사항 (directives)으로 기술됩니다. 이를 통해 에이전트를 더 쉽게 추론하고, 테스트하고, 디버깅할 수 있습니다.

다음은 예시입니다:

defmodule MyAgent do
use Jido.Agent,
name: "my_agent",
...

네트워크, 데이터베이스, 또는 LLM에 접속하지 않고도 에이전트가 내리는 모든 결정을 단위 테스트 (unit test)할 수 있습니다.

Jido의 모든 기능은 이 기본 개념을 중심으로 구축되었습니다.

Jido.AgentServer

어떠한 에이전트든 감독된 (supervised) GenServer로 래핑(wrap)하며, 시그널 라우팅 (signal routing), 지시문 실행 (directive execution), 그리고 부모-자식 에이전트 계층 구조 (parent-child agent hierarchies)를 제공합니다. 이는 이후에 이어지는 모든 것을 위한 에이전트 런타임 (agent runtime)입니다.

전략 (Strategies)은 핵심적인 확장 지점입니다. 전략은 cmd/2가 액션 (actions)을 처리하는 방식을 제어하며, 플러그인 방식으로 교체 가능합니다. Jido 코어에는 두 가지 전략이 포함되어 있습니다: Direct (순차적 실행) 및 FSM (전이 가드 (transition guards)를 가진 상태 머신 (state machines)). 이들은 AI의 개입 없이도 매우 폭넓은 영역을 커버합니다.

이 방식은 Jido AI가 연결되는 방식이기도 합니다. ReAct, Chain-of-Thought 및 기타 추론 전략 (reasoning strategies)은 루프에 LLM 호출을 추가하는 전략 구현체일 뿐입니다. 동일한 cmd/2 계약 (contract), 동일한 지시문 시스템 (directive system), 동일한 에이전트를 사용합니다. AI 레이어는 별개의 세계가 아닌 하나의 확장 기능입니다.

jido_behaviortree가 또 다른 예시입니다. 이는 LLM 없이도 Jido 에이전트에 행동 트리 (behavior tree) 실행을 추가합니다. 동일한 전략 인터페이스를 사용하지만, 실행 모델은 완전히 다릅니다.

2.0 버전에서는 액션 (actions)과 시그널 (signals)을 각각 전용 패키지로 분리했습니다:

jido_action은 범용 액션 계약 (universal action contract)입니다. 에이전트가 가진 모든 기능은 Jido.Action이며, 이는 컴파일 타임 스키마 검증 (compile-time schema validation), 라이프사이클 훅 (lifecycle hooks), 그리고 폭넓은 제공자 호환성을 위한 ReqLLM의 도구 (tool) 형식으로의 자동 변환 기능을 갖춘 구성 가능하고 검증된 명령 (composable, validated command)입니다. 25개 이상의 사전 구축된 도구와 복잡한 다단계 실행을 위한 DAG 기반 워크플로우 플래너 (workflow planner)가 함께 제공됩니다.

jido_signal은 메시징 신경계 (messaging nervous system)입니다. CloudEvents v1.0.2 명세 (spec)를 기반으로 구축되었으며, 표준화된 시그널 엔벨로프 (signal envelopes), 고성능 트라이 기반 라우터 (trie-based router), 발행/구독 (pub/sub) 버스, 그리고 9개의 디스패치 어댑터 (dispatch adapters)를 제공합니다. 표준 기반의 시그널을 사용하므로 무엇과도 통합할 수 있습니다. 커스텀 프로토콜이나 독점적인 형식이 아닙니다.

Jido AI

에이전트 코어 위에는 Jido AI가 자리 잡고 있습니다. 이는 가공되지 않은 LLM 호출을 구조화된 에이전트 지능 (agent intelligence)으로 변환하는 강력한 AI 통합 레이어입니다.

여섯 가지 추론 전략 (reasoning strategies)이 기본적으로 제공됩니다. ReAct는 가장 일반적이며 대부분의 도구 호출 (tool-calling) 사용 사례를 처리합니다. Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM, 그리고 Adaptive는 비용, 깊이, 품질 사이의 서로 다른 트레이드오프 (tradeoffs)가 필요한 상황을 위해 준비되어 있습니다.

defmodule MyApp.SupportAgent do
use Jido.AI.Agent,
name: "support_agent",
...

에이전트는 ReAct 루프를 실행합니다: 질문에 대해 추론하고, 도구를 호출하며, 결과를 LLM에 다시 전달하고, 답변을 얻을 때까지 이 과정을 반복합니다. 도구는 단순한 Jido.Action 모듈이므로, 액션으로 정의할 수 있는 모든 것은 LLM이 호출할 수 있는 도구가 됩니다.

Jido AI는 제가 만든 Elixir LLM 클라이언트인 ReqLLM을 기반으로 구축되었습니다. ReqLLM은 기존에 존재하지 않아 사이드 퀘스트 (side quest)로 직접 만들어야 했던 프로젝트입니다. 스트리밍 우선 (Streaming-first) 방식이며, 665개 이상의 모델을 지원하는 11개의 프로바이더 구현을 갖춘 멀티 프로바이더 (multi-provider) 시스템입니다. 때로는 사이드 퀘스트가 그 자체로 하나의 모험이 되기도 합니다. ReqLLM은 현재 버전 1.6에 도달했으며, 기여자 커뮤니티가 성장하고 있고 여러 기업에서 프로덕션 환경에서 사용 중입니다.

성장하는 생태계

여기서부터 흥미진진해집니다. Jido는 이제 단순한 프레임워크가 아닙니다. 하나의 생태계 (ecosystem)가 되어가고 있습니다.

성장하는 빌더 커뮤니티가 에이전트를 구축하기 위해 BEAM을 사용하고 있습니다. 이 모멘텀 (momentum)은 실재합니다. 사람들은 Jido를 기반으로 코딩 어시스턴트, 워크플로우 오케스트레이터 (workflow orchestrators), 연구 에이전트, 그리고 프로덕션 지원 시스템을 구축하고 있습니다. 또한 브라우저 자동화, 메모리 시스템, 평가 하네스 (evaluation harnesses), MCP 통합 등 AI 스택의 다른 부분을 해결하기 위한 패키지 세트도 등장하고 있습니다. 이 모든 것은 Jido 코어를 중심으로 구축됩니다.

Ash Framework에 대한 퍼스트 클래스 지원

ash_jido가 2.0 버전과 함께 출시되었습니다. 만약 Ash를 기반으로 구축하고 있다면, 이제 에이전트는 퍼스트 클래스 시민 (first-class citizen)입니다. 어떤 Ash 리소스에든 jido DSL 블록을 추가하면, 여러분의 CRUD 액션은 권한 정책 (authorization policies), 데이터 레이어, 그리고 타입 안정성 (type safety)이 보존된 상태로 AI가 호출 가능한 도구가 됩니다. 또한 ash_ai는 LLM 클라이언트로 ReqLLM을 사용하도록 전환하고 있으며, 이는 두 생태계가 수렴하고 있음을 의미합니다.

전체 생태계는 jido.run/ecosystem에서 탐색할 수 있습니다.

감사합니다

이번 출시는 Elixir 커뮤니티 덕분에 가능했습니다. 우리가 기반으로 삼고 있는 Phoenix, LiveView, Ash, Req, Telemetry, NimbleOptions와 같은 생태계는 세계적인 수준입니다. 이 라이브러리들 하나하나가 존재함으로써 Jido를 더 나은 방향으로 만들어 주었습니다.

Jido가 아직 미흡했던 시절에 사용해 보고, 때로는 불편할 수도 있었던 솔직한 피드백을 남겨주신 초기 테스터분들과 기여자분들께 감사의 말씀을 전합니다. 2.0 버전은 그러한 정직함이 만들어낸 직접적인 결과물입니다. 이곳에서 무언가를 만들어 나갈 수 있어 매우 기쁩니다.

개발 시작하기

# mix.exs
def deps do
[
...

• 시작하기 (Getting Started): jido.run/docs/getting-started
• 문서 (Docs): hexdocs.pm/jido
• 생태계 (Ecosystem): jido.run/ecosystem
• GitHub: github.com/agentjido
• Discord: jido.run/discord