아직 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가 할 수 있는 일들을 직접 구현한 사례임
이건 앞으로 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의 목적은 보안을 직접 해결하는 게 아니라, 사용자가 필요한 방식으로 해결할 수 있는 도구를 제공하는 것임
Hacker News 의견들
아직 Jido를 실제로 사용해본 적은 없지만, 한 달에 한 번 정도는 꼭 확인하고 있음
BEAM이 에이전트 프레임워크에 완벽히 어울린다고 생각하지만, 생태계가 아직 제한적이라 깊게 파고들지는 못했음
2.0 버전이 기대됨. 참고로 코드 샘플 중 일부에서 엔티티 이스케이프 문제가 있는 것 같음
글의 초반부터 강조된 “데이터와 순수 함수” 중심 접근이 정말 마음에 듦
BEAM의 실행 모델이 AI에 적합하다는 이야기를 자주 보는데, 실제로는 노드 장애나 롤링 배포 같은 상황에서의 견고성이 종종 간과됨
Elixir가 위치 투명성을 제공한다는 오해도 있는데, 사실 그렇지 않음. 노드가 내려가면 그 안의 프로세스도 함께 종료됨
각 API 호출 단계마다 명확하고 순수한 에이전트 상태를 유지하면 이런 문제를 해결할 수 있음. Mnesia나 Redis에 상태를 저장하고, 다른 노드에서 이어받으면 됨. 결국 체크포인팅이 핵심임
그래서 Jido 코어에는 LLM 지원이 전혀 없음.
40년 넘게 이어진 에이전트 연구가 있는데, LLM이 등장하면서 그걸 다 잊은 듯함. 그래서 나는 그 역사를 다시 공부하며 Jido에 녹이려 했음
물론 LLM을 좋아하지만, 그건 Jido AI 패키지의 역할임
타이밍이 완벽함. 나는 gen server와 Oban을 섞어서 직접 에이전트 프레임워크를 만들었는데, 정말 고통스러운 작업이었음
이 프로젝트는 개발의 고통을 크게 줄여줄 것 같음. 정말 고마움
혹시 이게 OpenAI Symphony와 비슷한 건지 궁금함
나는 AI보다는 Elixir 쪽을 더 자주 따라가는데, 이런 오케스트레이션 워크로드에 Elixir와 BEAM이 쓰이는 걸 보니 신선함
사이트가 트래픽 폭주로 접속이 어려움. 그래서 archive.org 백업 링크를 공유함
공유 고마움! 꼭 확인해볼 예정임
나는 최근 LLM으로 A2A 패키지를 만들었는데, GenServer와 비슷한 추상화임
이미 다른 A2A 구현이 있었지만, 내 패키지는 의미 체계가 달라서 그대로 공개했음
관심 있는 사람은 여기에서 확인 가능
몇 달째 이 프로젝트를 지켜보고 있는데, Elixir/BEAM은 에이전트 실행에 완벽한 플랫폼임
BEAM은 정말 가볍고 효율적이라, 이론적으로 한 서버에서 수천 개의 에이전트를 돌릴 수도 있음
앞으로 이걸 이해한 사람들이 어떤 걸 만들지 기대됨
심지어 BEAM을 베어메탈(임베디드) 환경에 배포해 그 안에서 에이전트를 돌리려는 시도도 있었음
미래가 정말 흥미로워질 것 같음
‘observer’에서 에이전트들이 활성화된 상태의 프로세스 트리 스크린샷을 보면 좋겠음
참고로 observer는 BEAM VM 내부의 Erlang 프로세스를 시각화해주는 도구임
예시 스크린샷은 Fly.io 문서에서 볼 수 있음
jido_studio라는 대시보드를 공개할 예정임. 프로세스 구조를 시각화해줌티저 스크린샷은 여기에서 볼 수 있음
AgentRuntime으로 감싼 에이전트는 일반적으로 하나의 GenServer 프로세스로 동작하지만, 더 큰 토폴로지가 필요할 때는 예외도 있음
완벽한 타이밍임. 나도 직접 Erlang 에이전트 프레임워크를 만들고 있었는데, 이게 훨씬 나음
보안은 어떻게 보장하는지 궁금함. 컨테이너 격리가 없다면 프로덕션 시크릿 유출을 막기 어려움
실제로 그렇게 구현한 Jido 사례도 봤음
다만 이건 사용 사례에 따라 다르고, 보안은 단순히 “컨테이너 안의 에이전트” 문제보다 훨씬 넓은 주제임
Jido의 목적은 보안을 직접 해결하는 게 아니라, 사용자가 필요한 방식으로 해결할 수 있는 도구를 제공하는 것임