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

> Clean Markdown view of GeekNews topic #27263. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27263](https://news.hada.io/topic?id=27263)
- GeekNews Markdown: [https://news.hada.io/topic/27263.md](https://news.hada.io/topic/27263.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-07T06:33:06+09:00
- Updated: 2026-03-07T06:33:06+09:00
- Original source: [jido.run](https://jido.run/blog/jido-2-0-is-here)
- Points: 7
- Comments: 1

## Summary

**Jido 2.0**은 Elixir의 **BEAM 런타임**을 기반으로 한 순수 함수형 에이전트 프레임워크로, 상태와 행동을 데이터로 정의하고 부작용을 **명령형 지시(directive)** 로 분리해 테스트와 디버깅을 단순화합니다. `jido_action`, `jido_signal` 모듈을 통해 표준화된 액션·시그널 시스템을 제공하며, 상위 계층의 **Jido AI**는 ReAct, Chain-of-Thought 등 여섯 가지 추론 전략과 ReqLLM 기반 LLM 통합을 지원합니다. 최근에는 Ash Framework와의 통합으로 AI 호출 가능한 CRUD 도구화를 실현하며, BEAM 생태계 전반으로 확장되고 있습니다.

## Topic Body

- **순수 함수형 에이전트 아키텍처**로, 상태와 행동을 데이터로 정의하고 부작용을 **명령형 지시(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 등 주요 라이브러리의 기여로 강화  
  
### 시작하기  
- Hex 패키지로 설치 가능  
  ```elixir  
  {:jido, "~> 2.0"},  
  {:jido_ai, "~> 2.0"}  
  ```  
- 문서: [hexdocs.pm/jido](https://hexdocs.pm/jido)  
- 생태계: [jido.run/ecosystem](https://jido.run/ecosystem)  
- GitHub: [github.com/agentjido](https://github.com/agentjido)

## Comments



### Comment 52543

- Author: neo
- Created: 2026-03-07T06:33:06+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47263036) 
- 아직 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](https://github.com/openai/symphony)와 비슷한 건지 궁금함  
  나는 AI보다는 Elixir 쪽을 더 자주 따라가는데, 이런 **오케스트레이션 워크로드**에 Elixir와 BEAM이 쓰이는 걸 보니 신선함  
  - OpenAI가 Elixir를 활용하는 걸 보니 반가움. Symphony는 Jido가 할 수 있는 일들을 직접 구현한 사례임  

- 사이트가 트래픽 폭주로 접속이 어려움. 그래서 [archive.org 백업 링크](https://web.archive.org/web/20260305161030/https://jido.run/)를 공유함  
  - 이건 앞으로 2주간 내 **개인적 수치**로 남을 듯함… 좋은 문제이긴 하지만, 정말 준비가 부족했음  
  - 관련된 문제인지는 모르겠지만, 페이지가 처음엔 잘 열리다가 몇 초 후 404로 리프레시됨. 결국 읽는 걸 포기했음  

- 공유 고마움! 꼭 확인해볼 예정임  
  나는 최근 LLM으로 **A2A 패키지**를 만들었는데, GenServer와 비슷한 추상화임  
  이미 다른 A2A 구현이 있었지만, 내 패키지는 의미 체계가 달라서 그대로 공개했음  
  관심 있는 사람은 [여기에서 확인 가능](https://github.com/actioncard/a2a-elixir)  
  - 멋짐! 바로 **스타** 눌렀음  

- 몇 달째 이 프로젝트를 지켜보고 있는데, Elixir/BEAM은 에이전트 실행에 **완벽한 플랫폼**임  
  BEAM은 정말 가볍고 효율적이라, 이론적으로 한 서버에서 수천 개의 에이전트를 돌릴 수도 있음  
  앞으로 이걸 이해한 사람들이 어떤 걸 만들지 기대됨  
  - Jido의 코어는 **Raspberry Pi**에서도 실행 가능함  
    심지어 BEAM을 베어메탈(임베디드) 환경에 배포해 그 안에서 에이전트를 돌리려는 시도도 있었음  
    미래가 정말 흥미로워질 것 같음  

- ‘observer’에서 에이전트들이 활성화된 상태의 **프로세스 트리** 스크린샷을 보면 좋겠음  
  참고로 observer는 BEAM VM 내부의 Erlang 프로세스를 시각화해주는 도구임  
  예시 스크린샷은 [Fly.io 문서](https://fly.io/docs/elixir/advanced-guides/connect-observer-to-your-app/)에서 볼 수 있음  
  - 곧 `jido_studio`라는 **대시보드**를 공개할 예정임. 프로세스 구조를 시각화해줌  
    티저 스크린샷은 [여기](https://x.com/mikehostetler/status/2025970863237972319)에서 볼 수 있음  
    AgentRuntime으로 감싼 에이전트는 일반적으로 하나의 GenServer 프로세스로 동작하지만, 더 큰 토폴로지가 필요할 때는 예외도 있음  

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

- 보안은 어떻게 보장하는지 궁금함. 컨테이너 격리가 없다면 **프로덕션 시크릿 유출**을 막기 어려움  
  - Signals와 Plugins을 사용하면 에이전트 간 데이터를 **암호화**할 수 있음  
    실제로 그렇게 구현한 Jido 사례도 봤음  
    다만 이건 사용 사례에 따라 다르고, 보안은 단순히 “컨테이너 안의 에이전트” 문제보다 훨씬 넓은 주제임  
    Jido의 목적은 보안을 직접 해결하는 게 아니라, **사용자가 필요한 방식으로 해결할 수 있는 도구를 제공**하는 것임
