가벼운 터미널 조합을 찾아서 — Kaku·Kero·Terax·Zellij, 그래도 못 피한 부하

밤 8시 48분, 한 참가자가 아직 나오지 않은 도구의 이름을 궁금해하며 화두를 던졌다.

"Oh My Terminal 나오나요 OmT"

곧이어 다른 참가자가 자신이 직접 테스트해본 결과를 순위로 정리해 내놓았다. 하네스(에이전트 실행 환경)를 감싸는 터미널 프런트엔드 가운데 herdr(접속이 끊겨도 AI 세션을 이어주는 터미널 도구) 기준으로 가장 가벼운 조합은 Kaku, Kero, Terax, Zellij 순이라는 것이었다.

"제가 테스트햇는데 Herdr 가장 가벼운 조합은 1. Kaku 2. Kero 3. Terax 4. Zellij"

이 순위가 나오자 화제는 곧바로 근본적인 질문으로 옮아갔다. 어떤 터미널을 쓰든 결국 메모리와 CPU 부하는 피할 수 없다는 체념 섞인 반응이었다. 밤 9시 4분, 한 참가자는 이 부하 문제 때문에 만들어진 터미널조차 결국 같은 부하에 걸리더라는 지적을 남겼고, 3분 뒤 다른 참가자는 그 이유를 하란 걸 하면 만들기가 귀찮기 때문이라는 짧은 한마디로 정리했다.

"그놈의 메모리랑 cpu부하는 어떤 터미널을 써도 오는군요.. 보통 이 문제 때문에 만들어진 터미널도 결국 부하가 걸리네요 ㅠ"

"하란걸 하면 만들기 개귀찮기 때문입니다.."

가벼운 조합을 찾는 질문에서 시작된 이 대화는 결국 개별 도구의 우열보다 구조적인 한계를 짚는 쪽으로 흘렀다. Kaku·Kero·Terax·Zellij라는 구체적인 순위가 한 차례 제시됐지만, 그 순위 자체보다 더 크게 남은 결론은 어떤 조합을 고르든 부하는 정도의 차이일 뿐 완전히 사라지지 않는다는 인식이었다.

이 대화가 짧게 스쳐 지나간 화제처럼 보여도, 그 안에는 나름의 실측 데이터가 들어 있다는 점이 눈에 띈다. 한 참가자가 직접 여러 조합을 돌려보고 순위를 매겼다는 것 자체가, 이 커뮤니티에서는 도구 추천이 막연한 인상이 아니라 실사용 비교를 거쳐 나온다는 걸 보여준다. 동시에 그 순위표조차 부하 자체를 없애주지는 못했다는 사실은, 가벼운 조합을 찾는 시도와 부하 문제의 근본 해결이 서로 다른 층위의 과제라는 걸 드러낸다.

터미널 경량화를 둘러싼 이 짧은 대화는, 이 커뮤니티가 에이전트 성능 못지않게 그걸 감싸는 실행 환경의 자원 소모에도 예민하다는 걸 보여준다. 하루 종일 에이전트를 여러 개 띄워놓고 작업하는 방식이 일상화된 만큼, 터미널 하나가 잡아먹는 CPU·메모리도 무시할 수 없는 변수가 된 셈이다. 새 터미널이 나올 때마다 부하 문제를 해결하겠다는 기대가 따라붙지만, 정작 써본 사람들의 결론은 완전한 해결책보다는 '덜 무거운 쪽'을 고르는 타협에 가까웠다.