요약
크리스 웰런스가 자원을 약 100배 적게 쓴다는 C++ 코딩 하니스 Prospero를 공개했습니다.
w64devkit을 만든 개발자 크리스 웰런스가 자기 블로그에서 Prospero를 소개했습니다. 코딩 하니스(AI 모델이 파일 편집과 명령 실행을 반복하게 하는 프로그램)는 대부분 웹 기술로 만들어져 메모리를 지나치게 쓴다는 불만이 출발점입니다.
왜 중요한가
- 저자는 하니스의 핵심이 curl과
popen()을 이은 정도라서 기가바이트 단위 메모리가 필요 없다고 봅니다. - 로컬 모델을 돌리는 사람에게는 하니스가 메모리를 덜 쓰는 만큼 모델에 쓸 여유가 생깁니다.
- 다만 100배 절감은 저자의 주장이며, 글에 구체적인 측정값은 없습니다.
핵심 내용
- 엔진과 UI가 분리되어, 원격에서 도는 작업은 연결이 끊겨도 계속되고 나중에 다시 붙을 수 있습니다.
- 모든 작업에 제한 시간을 두고, 시간을 넘긴 셸 명령은 백그라운드 작업으로 넘깁니다.
- 서브에이전트, 비전 모델의 데스크톱 제어, Git worktree, MCP를 지원합니다.
- 모델 제공자는 내장되어 있지 않아 llama.cpp나 OpenRouter 같은 API를 직접 연결해야 하고, Claude 구독은 쓸 수 없습니다.
- GitHub의 Community Edition은 무료이고, 원격용 헤드리스 엔진이 포함된 Professional Edition은 소액의 요금을 받습니다.
HN 반응
- GUI 프레임워크 JUCE의 개발자는 마크다운과 긴 스크롤 목록을 C++로 다루기는 무모하다고 했고, 일부 이용자는 네이티브 GUI로 충분하다고 반박했습니다.
- 메모리 절감을 두고는 몇 MB에 왜 신경 쓰느냐는 반문과, 세션 40개면 세션당 300MB도 부담이라는 경험담이 갈렸습니다.
GUI 코딩 에이전트가 나와서 반갑네요. 저는 TUI 에이전트를 늘 쓰고 있는데, 지금은 GUI 에이전트를 직접 만들고 있어요. Claude Code, Codex, opencode 같은 걸 몇 가지 쓰는데 DX/UX가 영 마음에 안 들거든요.
에이전트가 쏟아낸 텍스트 더미에서 한 부분을 클릭해서 관련 텍스트를 검색하거나, 옆에 따로 열어 보고 싶을 때가 많아요. 링크된 파일도 바로 열고 싶고요. 여러 질문에 비동기로 답하고, 다음 날 돌아와서 이어서 답할 수도 있었으면 좋겠어요.
프롬프트 단계에서 원하는 기능도 많아요. 서브에이전트로 오케스트레이션하되 내가 고른 작업만 시키고 싶은데, 체크박스가 없으면 어떻게 고르죠? 아니면 채팅 응답의 한 부분만 서브에이전트에게 맡겨서 (읽기 전용으로) 파고들게 하거나, 작업 목록 중 하나만 코드로 옮기게(쓰기) 하고 싶어요. 이런 자잘한 게 정말 많아요.
코딩 에이전트를 풀타임으로 쓰는 사람으로서, TUI는 저한테 거의 맞지 않아요. 에이전트 주도 개발에서는 텍스트를 쪼개고, 검색하고, 합치는 일이 그 어느 때보다 중요하다고 생각해요. 처음부터 끝까지 전부 텍스트니까요. 저는 제가 만든 GUI 프레임워크로 바로 이걸 만들고 있어요.
혼자가 아니에요. 저도 TUI 쪽 흐름에 반기를 들고 GUI 중심의 하네스 저글러를 직접 만들었거든요( https://github.com/juggler-ai/juggler ). 취향에 맞을지도 모르겠네요. 본인 프로젝트에 너무 매여 있지 않다면 제 프로젝트를 도와주셔도 좋고요 :)
솔직히 저는 TUI에 왜 그렇게들 집착하는지 모르겠어요. ssh로 원격 세션 여러 개를 멀티플렉싱하는 경우를 빼면요. 그래서 저글러는 GUI/웹소켓/Y.js 동기화 등으로 멀티 클라이언트 원격 세션을 전부 처리할 수 있는 구조를 목표로 했어요.
TUI는 윈도 시스템이 없는 최소 사양 VM에서도 돌릴 수 있습니다. 무거운 VM 대신 최소 VM을 쓰면 개발자가 VM을 더 많이 띄울 수 있고요.
에이전트를 VM에서 샌드박싱하지 않으십니까?
안녕하세요, 몇 달 전에 저글러를 써 봤습니다. 한 사람이 만든 제품으로는 기술적으로 인상적이었지만, 쓰기에는 정말 스트레스가 컸습니다. 출력과 활동이 너무 많고, 그것도 여러 겹으로 중첩돼서 나옵니다.
제가 보기에 Claude Code와 Codex가 최근 발전한 부분은 상호작용을 다듬었다는 점입니다. 예를 들어 Codex는 가벼운 "생각" 더미를 쭉 뿌렸다가, 끝나면 그걸 지우고 최종적으로 정리된 답만 보여 줍니다. 어떤 명령을 실행했는지도 자세히 보여 주지 않습니다. 파고들어 볼 수는 있지만 대개 가장 덜 중요한 정보죠. Claude는 다른 세션과 대화할 수 있는 하위/곁가지 세션도 만듭니다. 한 세션이 관련 없는 기존 버그를 발견하면 버그 수정용 인접 세션을 시작하고, 수정이 언제 반영되는지 계속 따라갈 수 있습니다. 조사용 곁가지 세션을 시작하면 새로 알아낸 내용을 다른 세션에 메시지로 보낼 수도 있고요.
저글러가 지금도 예전 같은지는 모르겠지만, 덜 장황하게 만들기를 강력히 권합니다. 저는 그 소음을 도저히 견딜 수 없었습니다.
고마워요, 정말 흥미로운 피드백이네요!
제 고집은 늘 Claude 같은 도구들이 "도구 호출을 여러 번 했음" 같은 불투명한 메시지 속에 숨기는 걸 전부 보고 싶다는 거였어요. 그래서 좋아한다는 분들도 있었지만, 스트레스였다는 얘기는 정말 흥미롭네요. 가서 곰곰이 생각해 볼게요.
몇 주 전에 명령 묶음을 요약 항목 하나로 접을지 토글하는 기능을 추가했어요(저글러 방식의 컬럼 뷰가 여기서 잘 맞는 게, 원하면 그 묶음 안으로 들어가서 도구 호출을 볼 수 있거든요). 저는 세부 내용을 다 보고 싶어서 이 모드를 안 쓰고 있었는데, 말씀을 들으니 그걸 기본값으로 해야 할지, "덜 자세한" 모드를 더 추가해야 할지 고민되네요.
물론 사람마다 일하는 방식은 다릅니다. 제 관점에서는 에이전트가 너무 좋아져서 작업하는 동안 뭘 하고 있는지 들여다볼 이유가 전혀 없습니다.
에이전트가 훨씬 더 자율적으로 일하는 방향으로 가고 있다고 봅니다. 요즘 제 작업 대부분은 원격에서 협력하는 자율 에이전트 팀이 처리합니다. 몇 시간씩 일하다가 주기적으로 사람에게 질문과 진행 상황을 알려 옵니다. 그 작업을 들여다볼 일은 (진단이나 감사 목적 말고는) 거의 없습니다. 적어도 저한테는 에이전트의 출력을 지켜보던 시절이 한참 전에 끝났습니다.
그래도 일부 작업에는 로컬 하네스를 쓰는데, OpenCode의 데스크톱 앱은 마음에 들지 않습니다. 쓸 만한 대안이 있으면 좋겠습니다.
고마워요 줄리안, 방금 확인해 봤는데 정말 멋지고 제 머릿속 기준에 꽤 많이 들어맞아요. 클론해서 파헤쳐 볼게요.
그리고 어디서 들었는지는 기억나지 않지만 JUCE는 전에 들어 본 적이 있어서, 한 번도 써 본 적이 없는데도 바로 알아봤어요. 제가 깃허브에서 너무 많은 시간을 보내나 봐요 :D
이 사람의 GUI는 적어도 일부는 Google의 Antigravity 2( https://antigravity.google/product/antigravity-2 )에서 영감을 받은 것 같네요.
저는 최근에 OpenCode GUI에서 OpenChamber로 갈아탔는데, 백엔드는 여전히 OpenCode를 씁니다. 꽤 훌륭합니다. 에이전트 응답의 일부를 선택해서 댓글을 달 수 있는 기능이 있는데, 그 댓글이 다음 프롬프트와 함께 전송됩니다. 서브에이전트도 훨씬 잘 다룹니다. 계획이 제대로 잡혀 있으면 서브에이전트 떼를 파도처럼 차례로 내보냅니다.
하시는 일은 멋지다고 생각하지만, 30년 경력의 골수 C++ 베테랑으로서(C++ GUI 프레임워크를 직접 만들 정도입니다: https://juce.com ) 말씀드리자면, 제가 코드 에이전트( https://github.com/juggler-ai/juggler )를 만들 때는 에이전트 GUI에 C++을 쓸 생각은 절대 하지 않았을 겁니다!
에이전트 UI는 전부 마크다운, HTML, 거대한 스크롤 목록, 텍스트 흐름, 유니코드 문자 같은 것들인데, C++ 프레임워크는 이런 데 형편없고 HTML/CSS/JS에서는 식은 죽 먹기죠.. 용감하시네요!
정말 흥미롭네요. C/C++로 문자열 관련 코드를 짜는 게 엄청나게 번거롭고 실수하기 쉽다는 건 알아요(보안 면에서도 어렵고요). 그런데 다른 언어의 웹 관련 스택과 라이브러리는 이미 어떤 식으로든 C로 트랜스컴파일되어 실행되고 있거나, LLM/에이전트에게 시키면 비교적 쉽게 이식하고 재사용할 수 있지 않나요?
그렇게 하면 C/C++가 이 분야에 더 강해질 수 있을까요? 다른 곳에서 어떤 걸 가져다 쓰시겠어요?
C++에서 문자열은 별것 아닙니다. 2D 그래픽 그리기도 괜찮고, 많은 라이브러리가 해냅니다. Qt나 JUCE 같은 구식 컴포넌트 프레임워크를 만드는 것도 쉽고요. 저는 AI가 나오기 수십 년 전에 그걸 전부 직접 구현했습니다.
어려운 건 텍스트가 들어간 복잡한 반응형 레이아웃입니다. (거기에 스타일을 입히는 것도요.)
마크다운 텍스트 블록이 들어간 에이전트식 채팅처럼 겉보기엔 사소한 것도, 펼치고 접을 수 있고 부드럽게 스크롤되게 만들려면 미칠 듯이 어렵습니다. 이걸 잘 해내는 프레임워크는 브라우저뿐인데, 브라우저가 쉬워 보이게 하려고 안에 숨겨 둔 끔찍하고 끔찍한 로직의 양은 믿기 어려울 정도입니다.
게다가 많은 에이전트에서는 실제 HTML도 표시하고 싶을 텐데, C++ 라이브러리에 브라우저 엔진을 내장하지 않는 이상 그건 불가능합니다.
통찰력 있는 설명 고맙습니다.
이게 핵심 문제인 것 같네요. 브라우저를 직접 다시 구현하거나(분명 문제가 산더미일 겁니다), 브라우저를 내장하고 어차피 비대해지거나 둘 중 하나군요.
완전한 브라우저나 완전한 HTML 구현은 필요 없습니다. 마크다운을 HTML로 변환한 결과를 표시할 만큼의 HTML 지원이면 충분한데, wxWidgets에는 그 정도 HTML 지원이 내장돼 있습니다. 저는 LLM이 명시적으로 시키지 않았는데 HTML을 생성하는 걸 본 적이 없어서, LLM 텍스트 출력을 렌더링하는 데 완전한 HTML/CSS/JS 지원이 필요하다는 생각이 어디서 나왔는지 모르겠습니다.
저는 제 코딩 에이전트( https://github.com/fluxmoot/fluximp )에 wxWidgets C++ GUI를 썼습니다. C++로 직접 쓴 건 아니고 wxPython을 통해 Python으로요. wxWidgets에는 브라우저 수준의 완전한 HTML/CSS/JS 구현은 없지만, 마크다운을 HTML로 변환해 렌더링하기엔 충분한 HTML 지원이 있어서 문제없이 잘 됩니다. Qt도 마크다운 정도는 문제없을 것 같고요.
이 스레드를 보고 저글러를 살펴봤는데, 몇 시간 뒤인 지금 가지고 놀고 있어요. 정말 멋지네요. 대단한 작업입니다.
고마워요! 많은 분의 취향을 제대로 저격하고 있다니 정말 기쁘네요.
CLI 코딩 에이전트에 대해 사소하게 불평하자면요.
에이전트가 뭔가 작업하는 동안 프롬프트를 입력하고 있는데 갑자기 Y/N 선택지가 있는 질문이 뜨는 일이 많아요. 그러면 제가 단어를 치다가 Y나 N을 입력해서 실수로 "질문에 답해 버리게" 되고, 에이전트가 엉뚱한 방향으로 가거나 멈추는 경우가 많습니다.
Claude Code도 Codex도 이걸 해결하지 못했어요. 막는 방법은 다른 곳에 입력하고 붙여넣는 것뿐인데, 정말 짜증 나요.
추신: 위 문제는 이제 Codex가 다른 에이전트 세션 안에서도 프롬프트/질문을 팝업으로 띄워서 특히 짜증 나요.
그리고 서로 다른 세션의 에이전트 두 개가 대화하게 하고 싶을 때도 좀 어설퍼요. 둘이 제대로 협력하기 전까지 제가 몇 턴 동안 전령 노릇을 해야 하거든요. 어디를 클릭해서 둘 이상의 세션을 연결하고 해제할 수 있으면 좋겠어요.
Próspero는 위 문제들을 해결하나요?
에이전트를 "떼"로 묶어 그룹으로 제어하는 계획은 있나요?
Claude가 내장 도구를 쓰지 못하게 막을 수 있습니다. 질문하는 도구도 포함해서요. 그러면 해결되지 않을까요?
agy에는 팝업 대신 대기 중인 질문을 따로 모아 두는 "질문 대기 중" 패턴이 있는 것 같아요. 저는 별로 안 좋아하지만, 말씀하신 문제를 풀려고 한 것 같네요.
그게 제가 pi 에이전트의 기본형에 직접 만든 확장을 몇 개만 얹어 쓰는 이유 중 하나예요.
질문 팝업이 없어서, LLM이 뭔가 물어보고 싶으면 그냥 물어보고 제 답을 다음 프롬프트로 기다려요.
자원을 적게 쓰면서 터미널에서 작업하는 쪽을 선호하신다면 hax( https://usehax.dev/ )도 고려해 보세요. 완전 정적 링크된 리눅스 바이너리가 2MB 미만이고, 실행 중 RAM 사용량은 몇 MB입니다. 일반적인 클라우드 제공자 외에 로컬 모델에서도 잘 동작하고요(실행 중인 llama-server에서 설정을 자동으로 감지합니다).
이 하네스를 만든 분이라면 그 사실을 밝히셔야 합니다. 자기 홍보에 반대하는 건 아니고, 그냥 좋은 관례라서요.
피드백을 하나 드리자면, Pi 같은 비교적 가벼운 다른 하네스와 어떻게 다른지 짚어 주면 좋을 것 같습니다. 그쪽은 C가 아니니 메모리 사용량이 훨씬 적을 거라고 짐작하지만요. 에이전트 하네스가 워낙 많아서 랜딩 페이지에 비교표가 있으면 좋겠습니다.
참고: 오해하실까 봐 말씀드리면, Hax의 GitHub 계정이 HN 계정과 사실상 같으니 숨기려 했다고 비난하는 건 아닙니다.
네, 제가 hax를 만들었습니다.
pi를 아신다면 GitHub 페이지(와 웹사이트)에 적은 핵심 기능 몇 가지만 봐도 큰 차이가 드러납니다. hax는 크기가 훨씬 작습니다(저는 pi를 "가볍다"고 부르지도 않을 겁니다. 의존성이 많은 무거운 js 런타임이니까요). hax는 터미널 고유의 스크롤백을 보존하고(pi는 alt-screen 전체 화면을 쓰거나, 차등 모드에서는 경우에 따라 화면을 지웁니다), 일반적인 XDG 디렉터리를 쓰며(pi는 ~/.pi를 씁니다), 프로세스 밖에서 확장합니다(pi는 프로세스 안 플러그인을 권합니다).
그 밖에도 표현 방식과 기능에 차이가 있습니다(예를 들어 hax는 백그라운드 bash 실행을 기본으로 지원합니다). 전부 나열하기는 어렵습니다.
감사합니다, 나중에 시간을 내서 써 보겠습니다. 일종의 연속적인 척도이긴 한데, pi가 Opencode나 모든 기능이 들어 있는 "Oh-My-Pi" 같은 하네스와 비교하면 확실히 더 가볍습니다.
그리고 물론 하네스에서 "가볍다"는 해석이 아주 다양합니다(메모리 사용량, 바이너리 크기, 성능, 시스템 프롬프트 등).
저는 Hax가 정말 좋아요. Codex를 한 달 쓰다가 Hax로 갈아탔고, 몇 달째 Hax만 쓰고 있어요.
훨씬 쾌적하고 정말 가벼워요. 컴파일도 순식간이고요. 의존성은 거의 없고, Suckless에서 만들 법한 느낌이에요. 게다가 다른 것들과 달리 OpenBSD에서도 쉽게 돌아가요.
이렇게 미니멀한데도 프롬프트마다 직전 작업에 비용이 얼마나 들었는지 보여 주는 멋진 기능까지 있어요.
여기 올라온 새 코딩 하네스 글을 보고 "Hax보다 나은 게 있을 수 있나?" 하는 마음으로 들어왔는데, 역시 없네요.
Oleksandr, 팬입니다.
가치 제안이 뭔지 모르겠네요. "로컬 모델에서도 잘 동작한다"는 건(다들 그렇잖아요) 어떤 TUI를 돌려도 될 만큼 필요 이상으로 RAM이 많다는 얘기죠. 사람들이 정말 도구를 인체공학이나 기능으로 평가하지 않고 몇 MB 메모리에 연연하나요?
저는 이미 Claude Code가 쓰는 메모리 때문에 한계를 느꼈습니다. 세션당 300MB 정도인데, 세션이 40개면 노트북 메모리를 꽤 많이 차지합니다.
대부분의 세션이 보류 상태였기 때문에 큰 문제는 아니었고, 화면 내용을 잃지 않고 세션을 종료할 방법(herdr에서 화면 덤프를 떴습니다)과 엔터를 누를 때까지 기다렸다가 세션을 재개하는 간단한 래퍼 스크립트를 마련했습니다.
더 가벼운 하네스로 바꿔야 할 필요는 없지만, 메모리 사용량에 무심하지는 않습니다.
요즘 일반적인 코딩 에이전트는 수백 MB의 RAM을 씁니다. 거기에 GUI까지 더하면 GB 단위로 쉽게 넘어갈 수 있고요. 적은 로컬 RAM에 성능 좋은 로컬 모델을 욱여넣으려 할 때는 그 차이가 체감될 수 있습니다.
RAM이 64GB인 머신에서도 덩치 큰 로컬 모델을 다루다 보면 시스템에 메모리 압박이 쉽게 생깁니다. 작은 VPS 서버나 Raspberry Pi 같은 SBC처럼 자원이 제한된 경우도 생각해 보세요.
인체공학과 기능도 여기에 포함됩니다. 요점은 이것들이 적은 자원 사용량과 함께 존재할 수 있다는 것입니다.
터무니없이 보조금을 받는 Claude 구독이 없었다면 써 볼 만한 멋진 하네스가 정말 많았을 텐데요.