JUCE와 Tracktion 만든 Julian Storer, 6개월간 개발한 오픈소스 GUI 코딩 에이전트 Juggler 공개

Opencode나 Pi 같은 오픈 에이전트 커뮤니티를 보면서 다들 확장성 때문에 좋아하는 건 알겠는데, 나는 터미널에 갇혀 있는 게 너무 싫더라. 컨텍스트의 모든 항목이 각자 커스텀 UI를 가진 플러그인이면 어떨까 싶어서 Juggler를 만들어봄.

JUCE 쓰는 사람으로서 이 프로젝트 보니 반갑다. Valhalla 플러그인도 JUCE 기반이고 Tracktion도 예전에 많이 썼었는데, 지금 Opencode 쓰면서 기능은 충분한데 릴리즈 속도가 너무 빠르고 시스템 프롬프트까지 붕 뜨는 느낌이라 트리형 UX가 반가움.

Kilo code도 한번 봐봐, 거기도 model-independent인데 터미널 기반은 아니야. 트리 구조가 스크롤 채팅보다 나은 건 동의함.

UI 깔끔하고 맥에서 설치도 잘 됐음. 지금은 zed, vscode에 claude, codex, Hermes 조합으로 쓰는데 계속 쓸지는 모르겠지만 UI 자체는 확실히 좋음.

이거 만들 때도 AI 에이전트 도움 받았을 것 같은데, 6개월이나 걸린 이유가 본인만의 확고한 취향 때문인 것 같다. AI로 큰 프로젝트 만들 때 경험이 어땠는지 궁금함.

경력 내내 C++ 백만 줄은 썼을 텐데 이번엔 거의 손으로 안 쓰고 AI한테 맡겼음. 그런데 의외로 재밌었고, 코딩의 즐거움이 과정이 아니라 결과물에 있다는 걸 깨달았음.

Wails 이름 듣고 Ruby on Wails인가 했는데 아니었넼ㅋㅋ 근데 No Electron 강조하는 거 보면 Electron이 곧 JavaScript인 것처럼 취급하는 느낌이라 좀 별로임. Go로 웹 프론트 렌더링하는 게 더 걱정됨.

No Electron은 자바스크립트 자체 문제가 아니라 블로트와 의존성 피하려는 거임. 나는 C++ 리얼타임 배경이라 단일 바이너리가 아닌 제품은 좀 못 받아들이겠음. 나중에 Electron으로 바꿔도 아무도 못 알아챌 거라고 생각함.

나는 정반대로 Zed, Cursor 같은 GUI 에이전트 툴에 질려서 콘솔 TUI 에이전트를 만들었는데 재밌게 봄.

지금 GUI 에이전트 툴 대부분이 얇은 GUI 씌운 터미널 앱일 뿐이라 터미널이랑 다를 게 없어서 가치가 없다고 생각함.

ACP 지원되면 진짜 경쟁력 있을 것 같은데, 지금 쓰는 Pi 플러그인 다시 짜야 하는 게 걸림돌임. UI는 확실히 더 나아질 여지가 있어 보임.

ACP는 이제 신규 에이전트 툴의 최소 요구사항이어야 한다고 봄, 지원되면 내 니치 에이전트도 옮겨볼 생각임.

깃허브 페이지에 스크린샷 좀 추가해줬으면 좋겠음.

헤드리스로 돌릴 때 libwebkitgtk-6.0.so.4 설치 안 해도 되게 할 수 있나 궁금함.

이번 릴리즈랑 상관없지만 2006년에 처음 쓴 DAW가 Tracktion이었고 JUCE 기반 플러그인도 많이 쓰고 있어서 그냥 감사 인사 남김.

독특한 시도라고 생각하고 세션 트리 구조가 특히 장점 있음. 나도 6개월짜리 솔로 프로젝트로 OrcaBot이라는 에이전트 오케스트레이션 툴을 만들고 있는데, 슬랙 같은 대화형 앱과 트리/스레드 구조를 결합하는 방향도 고려해볼 수 있는지 궁금함.

가스타운식 에이전트 스웜 orchestration 쪽이 아니라 나는 한 번에 하나씩 하고 git commit도 직접 하는 핸즈온 코딩 UX를 지향함. 다만 확장 시스템으로 그런 오케스트레이션도 가능하게 만들 수 있으면 도와주고 싶음.