에이전트 브라우저 ego와 어사이드, 어디에 뭘 붙일까

저녁 7시 12분, 한 참가자가 "ego라는 에이전트 브라우저가 있네요"라며 새 도구를 꺼냈다. 반응은 1분 만에 붙었다. "ego(lite) 가벼워서 괜춘하더라구요". 이미 써 본 사람이 있었고, 첫 평가는 성능이 아니라 무게였다.

대화는 곧 우열 비교가 아니라 배치 문제로 넘어갔다. 7시 18분에 정리된 한 줄이 그 틀을 잡았다. "코덱스처럼 브라우저 에이전트가 있는 모델은 어사이드와 잘 맞겠지만, 그록이나 딥시크 같은 컴퓨트 유즈가 약하거나 브라우저 에이전트가 없는모델을 사용할때에는 ego가 더 좋을수도있겠네요". 브라우저를 직접 다루는 능력을 이미 가진 쪽에는 어사이드가 얹히고, 그 능력이 약하거나 아예 없는 쪽에는 ego가 그 자리를 메운다는 구분이다. 같은 도구가 누군가에게는 군더더기이고 누군가에게는 없으면 안 되는 부품이 된다는 이야기이기도 하다.

밤 9시 무렵에는 사용 방식에 대한 질문이 붙었다. "근데 어사이드가 사용성은 더 좋은듯한데 … 에고는 cli 형태로 쓰는거죠 ? 브라우져 내에서 세션 만들어서 하는게 아닌거같아서". 곧이어 실사용 후기가 이어졌다. "cli로 연결해서 쓰기엔 에고가 더 낫나봅니다 ㅋㅋ 어사이드는 가끔 코덱스랑 끊기기도해서". 사용성은 한쪽이 앞서는데 연결 안정성은 반대라는 것, 즉 어느 층에서 붙이느냐에 따라 답이 갈린다는 정리였다. 브라우저 안에서 세션을 만드는 방식과 터미널에서 프로세스를 붙이는 방식은 겉으로 보이는 기능이 비슷해도 끊김이 생기는 지점이 다르다.

참가자 4명에 메시지 31개짜리 짧은 대화였지만 짚은 지점은 작지 않다. 에이전트 브라우저는 단독 제품으로 줄 세우기 어려운 범주다. 쓰는 모델이 브라우저 조작 능력을 내장했는지, 실행 환경이 CLI인지 브라우저 안 세션인지에 따라 같은 도구가 중복이 되기도 하고 반드시 있어야 할 보완재가 되기도 한다. 기능표를 나란히 놓고 고르는 방식이 잘 통하지 않는 이유다. 어느 쪽이 더 좋은 브라우저인가라는 질문에는 답이 없고, 내 조합에서 무엇이 비어 있는가라는 질문에만 답이 있다.

실무적으로는 도구를 고르기 전에 자기 스택의 빈칸을 먼저 그리는 편이 낫다. 쓰는 모델이 브라우저를 직접 다루는지, 작업 진입점이 터미널인지 브라우저인지, 세션이 끊겼을 때 복구에 드는 비용이 얼마인지를 적어 두면 선택지는 저절로 줄어든다. 이날 대화가 서른 개 남짓한 메시지 만에 쓸 만한 결론에 닿은 것도, 비교 기준을 성능에서 배치로 바꿨기 때문이다. 기능을 전부 헤아릴 필요 없이 각자 쓰는 모델과 진입점만 밝히면 어느 쪽이 맞는지가 바로 나왔다.