▲

Jido 2.0 - Elixir 기반 에이전트 프레임워크 공개

 (jido.run)
2P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 순수 함수형 에이전트 아키텍처로, 상태와 행동을 데이터로 정의하고 부작용을 명령형 지시(directive) 로 분리해 테스트와 디버깅을 단순화
  • 간결한 API와 BEAM 중심 설계를 채택하고, jido_action, jido_signal 등 모듈을 분리해 표준화된 액션·시그널 시스템을 제공
  • 상위 계층의 Jido AI는 ReAct, Chain-of-Thought 등 6가지 추론 전략을 지원하며, ReqLLM 기반 LLM 통합으로 11개 제공자와 665개 모델을 활용 가능
  • Jido는 이제 에이전트 생태계 플랫폼으로 확장 중이며, Ash Framework와의 통합(ash_jido)을 통해 AI 호출 가능한 CRUD 도구화를 지원

Jido 2.0 개요

  • Jido 2.0은 18개월간의 개발과 재설계를 거쳐 완성된 Elixir 기반 에이전트 프레임워크
    • 초기에는 2024년 BotHive라는 봇 플랫폼으로 시작했으며, 이후 BEAM 런타임을 에이전트 시스템의 기반으로 채택
    • TypeScript나 Python 기반 프레임워크의 한계를 극복하기 위해 BEAM의 동시성·안정성을 활용

1.0에서 2.0으로의 변화

  • Jido 1.0은 과도한 추상화로 인해 사용성이 떨어졌으나, 2.0에서는 단순화된 API와 BEAM 중심 구조로 개선
    • 사용자 피드백을 반영해 불필요한 복잡성을 제거하고, 기본 기능 수행의 마찰을 최소화
    • “에이전트를 만들고 싶지, 프레임워크와 싸우고 싶지 않다”는 요구를 반영

강력하고 내구성 있는 에이전트 코어

  • Jido 2.0의 핵심은 순수 함수형 에이전트 아키텍처
    • 에이전트는 상태(state), 행동(actions), 도구(tools)를 가진 단순한 구조체로 정의
    • 모든 동작은 cmd/2 함수로 처리되며, 입력된 액션에 따라 갱신된 에이전트와 지시 목록을 반환
    • 부작용은 지시(directive)로 표현되어 런타임이 실행, 테스트와 디버깅이 용이
  • Jido.AgentServer는 에이전트를 감시된 GenServer로 감싸며, 신호 라우팅과 부모-자식 에이전트 계층을 지원
  • 전략(strategy)은 확장 지점으로, Direct(순차 실행) 과 FSM(상태 기계) 두 가지가 기본 제공
    • ReAct, Chain-of-Thought 등 AI 전략도 동일한 인터페이스로 작동

액션과 시그널 모듈 분리

  • jido_action: 모든 에이전트 기능을 정의하는 보편적 액션 계약
    • 컴파일 시 스키마 검증, 생명주기 훅, ReqLLM 도구 포맷 자동 변환 기능 포함
    • 25개 이상의 사전 구축 도구와 DAG 기반 워크플로 플래너 제공
  • jido_signal: CloudEvents v1.0.2 기반의 메시징 시스템
    • 표준화된 시그널 포맷, 트라이 기반 라우터, pub/sub 버스, 9개의 디스패치 어댑터 제공
    • 비표준 프로토콜 없이 다양한 시스템과 통합 가능

Jido AI 통합 계층

  • jido_ai 는 LLM 호출을 구조화된 에이전트 지능으로 변환하는 통합 계층
    • ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM, Adaptive 등 6가지 추론 전략 내장
    • 동일한 cmd/2 계약과 지시 시스템을 유지하며, AI 계층을 별도 세계가 아닌 확장으로 통합
  • ReqLLM 기반으로 동작하며, 11개 제공자와 665개 이상의 모델을 지원
    • 스트리밍 우선 설계, 멀티 제공자 구조, 활발한 커뮤니티 기여

확장되는 생태계

  • Jido는 단순 프레임워크를 넘어 에이전트 생태계로 발전 중
    • 커뮤니티가 BEAM 위에서 코딩 어시스턴트, 워크플로 오케스트레이터, 리서치 에이전트, 운영 지원 시스템 등을 구축
    • 브라우저 자동화, 메모리 시스템, 평가 하니스, MCP 통합 등 다양한 패키지가 등장
  • Ash Framework 통합(ash_jido)
    • Ash 리소스에 jido DSL 블록을 추가하면 CRUD 액션이 AI 호출 가능한 도구로 변환
    • 권한 정책, 데이터 계층, 타입 안전성을 유지
    • ash_ai도 ReqLLM으로 이전 중으로, 두 생태계의 수렴 진행

커뮤니티와 감사

  • Jido 2.0은 Elixir 커뮤니티의 생태계 위에서 구축됨
    • Phoenix, LiveView, Ash, Req, Telemetry, NimbleOptions 등 주요 라이브러리의 기여로 강화

시작하기

▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 아직 Jido를 실제로 사용해본 적은 없지만, 한 달에 한 번 정도는 꼭 확인하고 있음
    BEAM이 에이전트 프레임워크에 완벽히 어울린다고 생각하지만, 생태계가 아직 제한적이라 깊게 파고들지는 못했음
    2.0 버전이 기대됨. 참고로 코드 샘플 중 일부에서 엔티티 이스케이프 문제가 있는 것 같음

    • 고마움! 바로 수정 중임

  • 글의 초반부터 강조된 “데이터와 순수 함수” 중심 접근이 정말 마음에 듦
    BEAM의 실행 모델이 AI에 적합하다는 이야기를 자주 보는데, 실제로는 노드 장애나 롤링 배포 같은 상황에서의 견고성이 종종 간과됨
    Elixir가 위치 투명성을 제공한다는 오해도 있는데, 사실 그렇지 않음. 노드가 내려가면 그 안의 프로세스도 함께 종료됨
    각 API 호출 단계마다 명확하고 순수한 에이전트 상태를 유지하면 이런 문제를 해결할 수 있음. Mnesia나 Redis에 상태를 저장하고, 다른 노드에서 이어받으면 됨. 결국 체크포인팅이 핵심임

    • 내 생각에 Jido의 가장 중요한 원칙은, LLM을 사용하기 전에 LLM 없이도 구조적으로 올바른 에이전트를 만드는 것임
      그래서 Jido 코어에는 LLM 지원이 전혀 없음.
      40년 넘게 이어진 에이전트 연구가 있는데, LLM이 등장하면서 그걸 다 잊은 듯함. 그래서 나는 그 역사를 다시 공부하며 Jido에 녹이려 했음
      물론 LLM을 좋아하지만, 그건 Jido AI 패키지의 역할임

  • 타이밍이 완벽함. 나는 gen server와 Oban을 섞어서 직접 에이전트 프레임워크를 만들었는데, 정말 고통스러운 작업이었음
    이 프로젝트는 개발의 고통을 크게 줄여줄 것 같음. 정말 고마움

    • ❤️

  • 혹시 이게 OpenAI Symphony와 비슷한 건지 궁금함
    나는 AI보다는 Elixir 쪽을 더 자주 따라가는데, 이런 오케스트레이션 워크로드에 Elixir와 BEAM이 쓰이는 걸 보니 신선함

    • OpenAI가 Elixir를 활용하는 걸 보니 반가움. Symphony는 Jido가 할 수 있는 일들을 직접 구현한 사례임

  • 사이트가 트래픽 폭주로 접속이 어려움. 그래서 archive.org 백업 링크를 공유함

    • 이건 앞으로 2주간 내 개인적 수치로 남을 듯함… 좋은 문제이긴 하지만, 정말 준비가 부족했음
    • 관련된 문제인지는 모르겠지만, 페이지가 처음엔 잘 열리다가 몇 초 후 404로 리프레시됨. 결국 읽는 걸 포기했음

  • 공유 고마움! 꼭 확인해볼 예정임
    나는 최근 LLM으로 A2A 패키지를 만들었는데, GenServer와 비슷한 추상화임
    이미 다른 A2A 구현이 있었지만, 내 패키지는 의미 체계가 달라서 그대로 공개했음
    관심 있는 사람은 여기에서 확인 가능

    • 멋짐! 바로 스타 눌렀음

  • 몇 달째 이 프로젝트를 지켜보고 있는데, Elixir/BEAM은 에이전트 실행에 완벽한 플랫폼임
    BEAM은 정말 가볍고 효율적이라, 이론적으로 한 서버에서 수천 개의 에이전트를 돌릴 수도 있음
    앞으로 이걸 이해한 사람들이 어떤 걸 만들지 기대됨

    • Jido의 코어는 Raspberry Pi에서도 실행 가능함
      심지어 BEAM을 베어메탈(임베디드) 환경에 배포해 그 안에서 에이전트를 돌리려는 시도도 있었음
      미래가 정말 흥미로워질 것 같음

  • ‘observer’에서 에이전트들이 활성화된 상태의 프로세스 트리 스크린샷을 보면 좋겠음
    참고로 observer는 BEAM VM 내부의 Erlang 프로세스를 시각화해주는 도구임
    예시 스크린샷은 Fly.io 문서에서 볼 수 있음

    • 곧 jido_studio라는 대시보드를 공개할 예정임. 프로세스 구조를 시각화해줌
      티저 스크린샷은 여기에서 볼 수 있음
      AgentRuntime으로 감싼 에이전트는 일반적으로 하나의 GenServer 프로세스로 동작하지만, 더 큰 토폴로지가 필요할 때는 예외도 있음

  • 완벽한 타이밍임. 나도 직접 Erlang 에이전트 프레임워크를 만들고 있었는데, 이게 훨씬 나음

  • 보안은 어떻게 보장하는지 궁금함. 컨테이너 격리가 없다면 프로덕션 시크릿 유출을 막기 어려움

    • Signals와 Plugins을 사용하면 에이전트 간 데이터를 암호화할 수 있음
      실제로 그렇게 구현한 Jido 사례도 봤음
      다만 이건 사용 사례에 따라 다르고, 보안은 단순히 “컨테이너 안의 에이전트” 문제보다 훨씬 넓은 주제임
      Jido의 목적은 보안을 직접 해결하는 게 아니라, 사용자가 필요한 방식으로 해결할 수 있는 도구를 제공하는 것임
답변달기