ego lite vs Aside 나에게 맞는 브라우저는 무엇일까?

에이전트가 제어하는 브라우저를 하나 설치해 볼까 하다가 두 개를 같이 보게 됐습니다. ego lite 와 Aside 입니다.

둘 다 macOS 용 Chromium 앱이고, 둘 다 올해 나왔고, 둘 다 Claude Code 나 Codex 가 제어할 수 있습니다. 내세우는 말도 거의 같습니다. 내가 로그인해 둔 사이트에서 에이전트가 대신 일하고, 내 탭은 내 것으로 남는다는 겁니다.

그런데 로그인을 넘기는 방식이 정반대였습니다. ego lite 는 Chrome 쿠키를 통째로 물려주고, Aside 는 비밀번호를 에이전트한테 안 보여 준 채로 페이지에 채워 넣습니다. 같은 편의를 주겠다는 건데 어디까지 믿고 맡기느냐가 다릅니다. 그게 궁금해서 둘을 아홉 가지로 나눠서 봤습니다. 제어 방식, 속도 주장의 근거, 로그인 위임, 격리, 게이트, 프롬프트 인젝션, 설치 경로, 구현을 확인할 수 있는지, 가격입니다.

들여다본 방식도 둘이 달랐습니다. ego lite 는 저장소를 클론해서 읽었고, Aside 는 공식 문서와 벤치마크 저장소를 읽었습니다. 두 회사가 공개한 게 서로 달라서 그렇게 됐습니다.

ego lite 저장소에는 브라우저가 없습니다

ego lite 부터 봤습니다. citrolabs/ego-lite 는 4월에 만들어진 저장소인데 다섯 달 만에 스타가 만 사천 개 넘게 붙었습니다. 클론이 몇 초 만에 끝나서 좀 이상했습니다. Chromium 기반 브라우저라고 소개돼 있었으니까요.

파일 목록을 봤더니 브라우저가 없었습니다.

package/ego-browser/ 아래에 있는 TypeScript 소스는 Chrome DevTools Protocol 로 브라우저를 조작하는 드라이버였고, skills/ego-browser/SKILL.md 는 에이전트한테 그 드라이버를 어떻게 쓰라고 알려 주는 문서였습니다. 브라우저 자체는 cdn.ego.app 에서 받는 DMG 이고 소스는 공개돼 있지 않습니다. GitHub 릴리스에 올라온 파일도 몇백 KB 짜리 zip 하나입니다. 브라우저가 아니라 리모컨인 겁니다. 리모컨만 공개한 게 잘못이라는 얘기는 아닙니다. 다만 오픈소스라는 말을 보고 기대하게 되는 것, 그러니까 이 브라우저가 내 데이터를 어떻게 다루는지 직접 들여다볼 수 있다는 기대는 여기서는 리모컨까지만 해당합니다. 브라우저 안에서 무슨 일이 일어나는지는 여전히 믿고 쓰는 수밖에 없습니다.

README 마지막 줄에는 그게 그대로 적혀 있습니다.

The contents of this repository are released under the MIT License. The ego lite browser is a separate, free download.

그런데 이 문장이 소개 글로 넘어가면서 사라집니다. 찾아보면 "Ego-Lite: The Open-Source Browser That Lets AI Agents Work Alongside You" 같은 제목이 나옵니다. 오픈소스인 건 리모컨이고 브라우저는 아닌데, 한 단어만 건너뛰면 오픈소스 브라우저가 됩니다.

저는 오히려 잘됐다고 생각했습니다. 브라우저는 못 읽어도 리모컨은 다 읽을 수 있으니까요. 이 도구는 제 브라우저에서 에이전트를 돌리고, 제 로그인 상태를 물려주는 게 핵심 기능입니다. 그러면 뭘 넘기게 되는지는 설치해 보고 알 일이 아니라 설치하기 전에 세어 볼 일이라고 생각했습니다.

Aside 는 반대였습니다. 브라우저도 에이전트도 소스가 없고 공개 이슈 트래커도 없습니다. 대신 공식 문서가 페이지 단위로 잘 정리돼 있고, 벤치마크 결과를 태스크별 아티팩트까지 GitHub 에 올려 놨습니다. 그래서 이 글에서 두 도구를 보는 눈이 다릅니다. 한쪽은 구현을 읽었고 한쪽은 정책과 성적을 읽었습니다. 이 차이가 나중에 꽤 많은 걸 정합니다.

둘은 같은 데서 경쟁합니다

처음에는 Aside 가 ChatGPT Atlas 나 Perplexity Comet 처럼 내장 에이전트만 쓰는 제품인 줄 알았습니다. 에이전트가 브라우저 안에 산다고 소개돼 있었고, ego lite README 비교표도 Atlas 와 Comet 을 "외부 에이전트로 제어 불가" 칸에 넣어 놨거든요.

그런데 Aside 문서에 Use the CLI, MCP, and REPL 이라는 페이지가 있었습니다.

{
  "mcpServers": {
    "aside": {
      "command": "aside",
      "args": ["mcp"]
    }
  }
}

aside mcp 로 MCP 서버가 됩니다. Claude Code 든 Codex 든 이 프로토콜로 붙어서 Aside 브라우저를 제어할 수 있습니다. 터미널에서 aside "task description" 으로 세션을 바로 띄울 수도 있고, --session <id> 로 이전 세션을 이어받을 수도 있습니다. aside repl 은 페이지 검사나 스크린샷, 다운로드처럼 매번 같은 결과가 나와야 하는 단계를 직접 밟는 용도입니다.

그러니까 두 도구는 같은 데서 경쟁합니다. 제 Claude Code 가 제어할 브라우저를 고르는 문제입니다. 내장 에이전트까지 따지면 비교할 게 끝이 없는데, 이렇게 좁혀 놓고 나니 무엇을 봐야 할지가 분명해졌습니다.

ego lite 는 자기가 빠른 이유를 이렇게 설명합니다.

Code base, not CLI base, for faster runs with fewer tokens on complex tasks

CLI 기반이 아니라 코드 기반이라서 빠르다는 겁니다. 도구를 하나 부르고 결과를 보고 또 부르는 왕복에 갇히지 않는다는 거고요. 그 왕복의 대표가 MCP 입니다. 그리고 Aside 는 MCP 로 붙습니다. 두 제품이 정확히 이 지점에서 반대편에 서 있습니다.

제어 방식은 heredoc 과 MCP

ego lite 의 SKILL.md 는 이렇게 지시합니다.

Use the Bash tool to run all browser operations via ego-browser nodejs <<'EOF' ... EOF heredoc. Do not write code to a .js file first.

Bash 한 번으로 Node.js 스크립트를 통째로 넘깁니다. 그 스크립트 안에는 openOrReuseTab, snapshotText, click, fillInput 같은 함수가 미리 들어가 있습니다.

ego-browser nodejs <<'EOF'
const task = await useOrCreateTaskSpace('inspect example page')
await openOrReuseTab('https://example.com', { wait: true, timeout: 20 })
cliLog(await snapshotText())
EOF

페이지를 열고, 스냅샷을 찍고, 버튼을 찾고, 클릭하고, 다시 확인하는 걸 MCP 로 하면 도구 호출이 다섯 번입니다. 왕복할 때마다 모델이 끼어들고 컨텍스트가 늘어납니다. 그걸 한 번에 쓰게 만든 겁니다. 모델이 제일 잘하는 게 코드 쓰는 일이니 그걸 시키자는 생각이고, 꽤 그럴싸합니다.

실행은 src/run.ts 에서 합니다. 표준 입력으로 받은 JavaScript 를 헬퍼를 주입한 async 함수 안에서 돌린다고 AGENTS.md 에 적혀 있고, 열어 보면 이렇게 생겼습니다.

const AsyncFunction = Object.getPrototypeOf(async function () {}).constructor;
const fn = new AsyncFunction(...names, `"use strict";\n${code}`);
await fn(...values);

브라우저에 붙는 방식도 흔한 길이 아닙니다. Puppeteer 나 Playwright 는 브라우저를 --remote-debugging-port=9222 로 띄우고 그 포트에 WebSocket 을 붙입니다. ego lite 는 포트를 열지 않습니다.

export function isBrowserRuntime() {
  return Boolean(
    globalThis.ego && typeof globalThis.ego.sendCDPMessage === "function",
  );
}

앱 안에 주입된 ego 객체로 CDP 메시지를 바로 보냅니다. 그래서 디버깅 포트가 필요 없고, 브라우저를 따로 띄울 필요도 없고, 사용자가 지금 쓰고 있는 브라우저에 그대로 붙습니다. README 는 이걸 "kernel-level customization" 이라고 부르는데 커널은 아닙니다. Chromium 을 포크해서 브라우저 프로세스 안에 특권 통로를 하나 심은 겁니다. 커널이라는 말만 빼고 보면 영리한 설계라고 생각합니다. 이슈 트래커에 CDP 포트를 열어 달라는 요청이 몇 건 올라와 있는 걸 보면, 닫아 둔 게 우연이 아니라 일부러 고른 길인 것 같습니다.

Aside 는 이 층에서 특별할 게 없습니다. MCP 서버니까 도구 호출 왕복 구조를 그대로 씁니다. 대신 그 위에 자체 에이전트 루프를 얹었습니다. 과업마다 추론 수준을 고를 수 있고, 제일 높은 단계인 Ultrabrowse 는 긴 작업을 알아서 돕니다. 태스크가 끝나면 Dreaming 이라는 과정으로 배운 걸 로컬 마크다운 파일에 쌓는데, 열어서 고칠 수 있는 평문이라고 문서에 적혀 있습니다. 배운 걸 사람이 열어 보고 고칠 수 있는 평문으로 남긴다는 건 마음에 들었습니다. 에이전트가 뭘 배웠다고 믿고 있는지를 제가 볼 수 있다는 뜻이니까요.

ego lite 에도 비슷한 게 있습니다. README 에는 경험을 쌓는 기능이 "coming soon" 으로 돼 있는데, skills/ego-browser/learnings/ 에 X 와 google 학습 파일이 벌써 들어 있습니다. 도메인 패턴과 도구 시그니처가 있고 X 의 data-testid 선택자가 정리된 노트도 있습니다. 그런데 그 안의 도구 파일은 Playwright 스타일 API 를 쓰고, SKILL.md 는 Playwright 처럼 쓰지 말라고 해 놨습니다. 이 학습 파일들이 실제로 어느 런타임에서 도는지는 소스만 봐서는 잘 모르겠습니다.

제어 방식만 놓고 보면 ego lite 가 낫다고 봤습니다. MCP 는 부르고, 보고, 또 부르는 모양을 벗어날 수가 없는데 heredoc 은 다섯 단계를 한 번에 씁니다. 디버깅 포트를 안 여는 것도 깔끔합니다. 그런데 특권 컨텍스트에서 모델이 쓴 코드를 그대로 실행한다는 게, 빠른 이유이면서 동시에 뒤에 나올 문제들의 출발점이기도 했습니다.

속도 주장을 어떻게 냈나

두 회사 다 자기가 제일 빠르거나 제일 잘한다고 합니다. 그 말을 어떻게 했는지가 꽤 달랐습니다.

ego lite 는 README 에 "up to 2.5× faster" 라고 적고 그래프 이미지 한 장을 붙였습니다. 열어 보니 조건은 gpt-5.5 medium effort, 에이전트는 pi, 과제당 다섯 번 돌린 중앙값이고, 비교 상대는 Vercel 의 agent-browser 하나였습니다.

과제	ego lite	agent-browser
X 게시물 스크래핑 (7일치)	87초 / $0.21	226초 / $0.42
LinkedIn 채용공고 지원서 작성	123초 / $0.45	231초 / $0.64
Redfin 모기지 상환액 추정	60초 / $0.27	86초 / $0.41
Expedia 마이애미 항공권 예약	166초 / $1.10	봇 탐지 차단

걸리는 건 네 번째 줄입니다. agent-browser 는 봇 탐지에 걸려서 과제를 못 끝냈습니다. 비교가 안 되는 칸인데 나머지 셋과 같은 모양으로 들어가 있고, 헤드라인은 "ego-browser finishes faster and costs less on every task" 입니다. 상대가 끝내지 못한 과제까지 every task 에 넣어 세면 무엇을 비교했는지가 흐려집니다.

ego lite 가 그 과제를 통과한 이유가 더 마음에 걸렸습니다. 스냅샷이 좋아서도 아니고 CDP 를 빨리 보내서도 아닙니다. 사용자의 실제 로그인 상태와 실제 브라우저 지문을 그대로 물려받았기 때문입니다. 봇처럼 안 보인 게 아니라 애초에 봇이 아닌 쪽에 앉아 있었던 겁니다. 그러니 이 칸이 재고 있는 건 성능이 아니라 위임입니다. 속도 비교표에 들어가 있는데 다른 걸 재고 있습니다.

과제 목록도 눈에 걸렸습니다. X 스크래핑, LinkedIn 자동 지원, Redfin 조회, Expedia 예약. 넷 다 그 사이트 약관이 자동화를 어떻게 보는지 한 번은 확인해 봐야 하는 일들입니다. 벤치마크로 고른 과제가 그 제품이 어떤 쓰임새를 밀고 있는지를 은근히 보여 주는 것 같습니다. 속도를 재려고 고른 과제가 하필 전부 로그인이 필요하고 봇 탐지가 있는 사이트라는 건, 이 제품이 제일 잘하는 일이 결국 그쪽이라는 뜻으로 읽혔습니다.

Aside 쪽을 보고 나니 이 그래프가 더 얇게 느껴졌습니다. Aside 는 벤치마크 저장소에 수천 개 파일을 올려 놨습니다. 남이 만든 벤치마크 세 개를 돌렸는데, Online-Mind2Web 은 300개 중에 297개를 통과했고, 장기 과업 벤치마크와 BU Bench 도 같이 돌렸습니다.

점수보다 그 옆에 붙은 것들이 더 눈에 들어왔습니다. 모델과 프로바이더, thinking 수준, 동시성, 태스크당 타임아웃, 채점에 쓴 모델까지 설정을 다 적어 놨습니다. 그리고 실패한 태스크를 이름까지 공개했습니다. Online-Mind2Web 에서 못 끝낸 세 개가 표로 나와 있는데, Dillard's 크리스마스 eGift 카드는 사이트가 그 디자인을 더 이상 안 팔아서 불가능으로 분류했고, 중고 Mac Studio 는 재고가 없어서 실패였고, QLED 게이밍 모니터 검색은 이유 없이 "Failed" 라고만 돼 있습니다. 태스크마다 트래젝토리 텍스트와 result.json 과 스크린샷도 들어 있습니다.

이것도 자기 채점이긴 합니다. 채점자가 LLM 이고, 자기 저장소에 자기가 올린 숫자입니다. 라이브 웹사이트를 상대로 돌렸으니 사이트가 바뀌면 결과도 달라진다고 README 에 스스로 적어 놨는데, 그 말대로라면 똑같이 다시 돌려 보기도 어렵습니다.

그래도 둘을 나란히 놓으면 차이가 분명했습니다. 한쪽은 자기가 고른 과제 네 개를 상대 하나와 비교한 그래프 한 장을 냈고, 다른 쪽은 남이 만든 벤치마크 수백 개를 돌려서 실패 목록과 채점 설정과 태스크별 기록을 다 냈습니다. 둘 다 자기 수치라는 건 같은데, 틀린 데를 짚을 수 있는 정도가 다릅니다. 자체 벤치마크 수치를 어떻게 읽어야 하나는 1위와 2위의 0.4%p 를 태스크 개수로 바꿔 봤을 때 한 번 써 봤는데, 그때는 분모가 안 적혀 있다는 게 문제였습니다. 여기서는 한쪽이 분모를 다 적었습니다.

이 항목은 Aside 가 크게 앞선다고 봤습니다. 자기가 못 끝낸 태스크를 이름과 이유까지 내놓는 건 흔한 일이 아닙니다. 반대쪽은 상대가 끝내지 못한 칸을 이긴 걸로 세어 넣었습니다. 점수 자체를 믿을 이유는 둘 다 없는데, 한쪽은 제가 틀렸다고 짚을 수 있게 해 놨고 한쪽은 그럴 틈을 안 줬습니다.

로그인을 어떻게 넘기나

두 제품이 제일 크게 다른 부분이고, 제가 이 글을 쓰게 된 이유입니다.

ego lite 는 물려줍니다. 처음 켤 때 Chrome 데이터를 가져올지 한 번 묻고, 예라고 하면 로그인과 쿠키와 확장과 북마크가 넘어옵니다.

On first launch, ego lite asks one question, whether to migrate your Chrome data. Say yes and your agent inherits your existing logins, cookies, extensions, and bookmarks.

그다음부터 에이전트는 인증된 세션 위에서 일합니다. 모델이 쓴 스크립트가 그 세션에 어디까지 닿느냐가 문제가 됩니다.

Aside 는 채워 넣습니다. 공식 help 문서에 이렇게 적혀 있습니다.

The agent can use the login action, but it does not receive the raw password.

로그인 페이지에 닿으면 Aside 가 대상 URL 과 비밀번호 접근 설정을 확인하고, 허용된 자격증명이면 페이지에 채워 넣습니다. 에이전트는 로그인 동작은 쓸 수 있지만 값은 받지 않습니다. 접근 정책은 Always allow, While unlocked, Never 세 단계이고, 시크릿 세션에서는 에이전트가 비밀번호 관리자를 못 씁니다. 1Password 가 Browserbase 와 같이 내놓은 Secure Agentic Autofill 도 같은 생각이라, 이쪽으로 흐름이 잡혀 가는 것 같습니다.

Aside 문서는 이 방식의 한계도 적어 놨습니다. MFA, 패스키, 캡차, 신원 확인은 사람이 해야 한다고요. 이 설계는 자동화가 중간에 멈추는 걸 받아들인 겁니다. ego lite 는 쿠키를 물려받았으니 그 단계를 아예 안 만납니다. 편한 쪽과 선을 긋는 쪽의 차이가 여기서 그대로 보입니다.

이 항목은 Aside 쪽으로 봤습니다. 그런데 ego lite 가 여기서 밀린 이유가 제어 방식에서 앞선 이유와 같다는 게 묘했습니다. 쿠키를 통째로 받았으니 로그인 화면도 안 만나고 캡차도 안 만나고 봇 탐지도 안 만납니다. 자동화가 안 끊깁니다. 멈추지 않는 자동화를 원하는 사람이라면 판단이 반대로 나올 겁니다. 저는 멈추는 쪽을 고르는데, 그건 제 작업이 남의 계정을 대신 만지는 일이 아니라서 그렇습니다. 멈춰서 물어보는 건 귀찮은 정도로 끝나는데, 쿠키가 통째로 넘어간 상태에서 뭔가 잘못되면 귀찮은 정도로 안 끝납니다. 저한테는 그 차이가 편한 것보다 더 크게 느껴졌습니다.

격리라는 말

ego lite 의 핵심 기능은 Space 입니다.

ego lite gives each agent its own fully isolated Space.

SKILL.md 도 같은 말을 합니다.

A task space is an isolated browsing context that ego-browser provides for AI Agents. Each task space has its own set of tabs but inherits the current user's login state by default.

읽으면 그림이 그려집니다. 에이전트는 자기 방에서 일하고, 그 방에는 내 로그인이 이미 들어와 있고, 내 탭은 안 건드립니다.

그런데 이슈 #319 에 재현 절차가 올라와 있습니다. 서로 다른 Chrome 프로필에 묶인 Space 를 두 개 만들고, 한쪽 Space 에서 Storage.getCookies 를 부르면 다른 프로필의 쿠키가 통째로 돌아온다는 보고입니다. 다른 프로필의 인증 쿠키도 그 안에 섞여 있었다고 합니다. Storage.setCookies 로 쓰면 부른 쪽이 아니라 기본 프로필에 들어간다고도 했습니다.

유지관리자가 이렇게 답했습니다.

A space is not the same as a profile, and spaces do not isolate cookies.

이 한 줄이 README 의 "fully isolated" 와 나란히 놓입니다. 둘 다 이 프로젝트가 쓴 문장입니다. Space 는 탭을 나눠 놓을 뿐이고 자격증명은 나누지 않습니다. 그런데 그 구분이 마케팅 문구에도 없고 SKILL.md 에도 없습니다. 그러면 이 문서만 읽고 일하는 에이전트는 자기가 격리된 방에 있다고 믿게 됩니다.

그 믿음이 실제로 사고를 냈습니다. 이슈 #303 입니다. 에이전트가 자기 Space 에서 일하다가 HTTP 401 이 반복되자 세션 문제라고 판단하고 Network.clearBrowserCookies 와 Network.clearBrowserCache 를 불렀습니다. 자기 Space 안에서만 세션이 초기화될 줄 알았던 겁니다. 사용자가 메인 창으로 돌아가서 인증이 필요한 사이트를 새로고침했더니 로그인이 다 풀려 있었습니다. 보고자는 이렇게 적었습니다.

The key issue is that a routine session-recovery flow inside an isolated Task Space was able to invoke a browser-global destructive operation without warning or confirmation.

401 을 만나서 쿠키를 지우는 건 이상한 행동이 아닙니다. 사람도 그렇게 합니다. 문서가 격리된 컨텍스트라고 했고, 에이전트는 그 안에서 평범한 복구를 했고, 브라우저 전체가 지워졌습니다. 잘못 판단한 건 에이전트가 아니라고 생각합니다. 문서가 말한 것과 구현이 하는 것이 달랐던 거죠. 이 이슈는 아직 열려 있고, #319 쪽에는 다음 버전에서 프로필 단위 Space 를 지원할 계획이라는 답이 달려 있습니다.

Aside 쪽은 공개 이슈 트래커가 없어서 이런 일이 있었는지 알 길이 없습니다. 대신 격리를 무엇으로 정했는지는 문서에 나옵니다. 권한을 세 층으로 나눴습니다. Sandbox 는 명령 실행을 OS 수준에서 격리하는 것이고, File permissions 는 에이전트가 들어갈 수 있는 폴더, Tool permissions 는 도구마다 Allow / Ask / Deny 를 정하는 규칙입니다. Deny 가 우선하고, 설정은 에이전트 단위와 세션 단위로 겹칩니다. 기본 세션 모드는 Guard 인데, 승인된 폴더에서 일하다가 다른 폴더에 들어가려면 물어보는 모드입니다.

Aside 는 격리 단위를 파일시스템과 도구 권한으로 잡았고, ego lite 는 탭으로 잡았습니다. 둘 다 쿠키를 격리 단위로 놓지는 않았습니다. 다만 한쪽은 그걸 격리라고 불렀고, 다른 쪽은 격리라는 말을 다른 데 붙였습니다.

격리라는 말은 듣는 사람마다 떠올리는 게 다른 것 같습니다. 개발자는 프로세스나 컨테이너를 떠올리고, 보안 쪽 사람은 자격증명을 떠올리고, 그냥 쓰는 사람은 서로 안 섞인다는 정도를 떠올립니다. 어떤 격리인지 안 적어 두면 다들 자기한테 제일 듣기 좋은 쪽으로 읽게 됩니다. 에이전트도 마찬가지일 겁니다. 문서에 isolated 라고 적혀 있으면 그 말을 제일 넓은 뜻으로 받아들이고 행동하겠죠.

이 항목도 Aside 쪽으로 봤는데, 이긴 근거가 좀 약합니다. 쿠키를 격리해서가 아니라 자기가 무엇을 격리하는지 문서에 적어 놔서 앞선 겁니다. ego lite 는 "fully isolated" 라고 쓴 곳과 "spaces do not isolate cookies" 라고 인정한 곳이 서로 다른 문서였고, 사용자가 먼저 만나는 건 마케팅 문구 쪽입니다. 아홉 가지 중에 이게 제일 무겁다고 느꼈는데, 격리를 잘하고 못하고보다 격리라는 단어가 무엇을 가리키는지가 안 적혀 있었다는 게 무거웠습니다.

게이트가 있나

ego lite 의 SKILL.md 를 끝까지 읽으면 인상적인 대목이 있습니다. 제어권을 다루는 부분입니다. Space 하나의 제어권은 사람이나 에이전트 중 한쪽만 갖습니다. 사람이 GUI 로 제어권을 가져가면 에이전트의 브라우저 조작은 "user is controlling" 오류로 실패합니다. 그 상황을 이렇게 정해 뒀습니다.

A "user is controlling" error is a hard stop on the whole task — not an obstacle to route around. It means the user has deliberately taken the browser back, often because your current approach is going wrong. Honoring it is the correct outcome here; pushing the goal forward anyway is the failure. The only thing you may do is ask the user and wait.

돌아갈 장애물이 아니고, 밀어붙이는 게 실패이고, 물어보고 기다리는 것만 하라고 적혀 있습니다. takeOverTaskSpace 는 소유권 검사를 안 하니 절대 스스로 부르지 말라는 경고도 있고, 소유권 상태를 셋으로 나눠서 헬퍼마다 사용자 소유 Space 를 어떻게 다루는지 표까지 있습니다.

이렇게까지 정해 둔 문서는 드뭅니다. 사람이 끼어든 순간을 실패가 아니라 정상 종료로 정의했고, 저는 이게 이 프로젝트에서 제일 잘 만든 부분이라고 생각합니다. 물론 여기에도 이슈는 붙어 있습니다. confirm() 대화상자가 예기치 않게 과업 소유권을 넘긴다는 보고가 있고, 페이지 이동이 소유권을 조용히 바꿔 놓고 사용자가 제어권을 가져갔다는 엉뚱한 오류를 낸다는 보고도 있습니다. 규칙을 아무리 잘 써 놔도 상태가 바뀌는 순서가 어긋나면 그 규칙이 엉뚱하게 작동합니다. 그래도 규칙이 먼저 적혀 있으니까 어긋난 걸 이슈로 올릴 수 있는 겁니다. 규칙이 없으면 어긋났다는 것도 모릅니다.

그런데 제어권 말고는 게이트가 없습니다. 결제나 게시나 메시지 전송처럼 되돌리기 어려운 동작 전에 확인하라는 조항이 SKILL.md 에 없습니다.

Aside 는 거기에 게이트를 뒀습니다.

Sensitive actions like payments, posts, and messages always wait for your confirmation.

문서 쪽에도 근거가 있습니다. Tool permissions 의 Ask 규칙이 그 장치이고, 기본 모드가 Guard 라는 것도 적혀 있습니다. 마케팅 문구만 있는 게 아닙니다.

반대로 마케팅 문구에만 있는 것도 있었습니다.

Every credential use is logged, so you know exactly what the agent touched.
Give the agent access only to what each task needs. See what it used, when, and why.

Use Password Manager 문서에는 로그를 어떻게 남기는지가 없습니다. 과업별로 자격증명 범위를 어떻게 자르는지도, 암호화 방식도 그 페이지에 안 나옵니다. changelog 를 처음부터 훑어봐도 감사 로그 이야기는 없습니다. 비밀번호 관리자가 실제로 있고 업데이트된다는 기록은 있습니다. 고정 위치를 잃어버리는 버그를 고쳤다는 항목도 있고, Google 로그인이 너무 자주 풀리던 문제를 고쳤다는 항목도 있습니다. 관리자가 있는 건 맞는데, 쓸 때마다 다 기록된다는 건 제품 페이지 밖에서는 안 보였습니다. 이런 건 문서에 한 줄만 있어도 믿음이 꽤 달라질 것 같은데, 왜 제품 페이지에만 있고 문서에는 없는지 좀 궁금합니다.

게이트 항목은 Aside 쪽입니다. 결제하기 전에 물어보는 게 한쪽엔 있고 한쪽엔 없으니까요. 그래도 ego lite 가 제어권 규칙에 들인 공은 이 판단에 안 잡혀서 좀 아쉽습니다. 사람이 브라우저를 되찾은 순간을 정상 종료로 정의한 문서는 Aside 쪽에서 못 봤습니다. 게이트 개수로는 지는데 게이트를 대하는 생각으로는 이기는, 좀 이상한 항목이었습니다.

양쪽 다 말이 없는 것

ego lite 의 SKILL.md 전체를 inject, untrusted, malicious, credential, secret, password 로 검색해 봤습니다. 걸리는 게 없었습니다. cookie 로도 없고, confirm 으로 걸리는 건 전부 사용자 확인 뒤에 제어권을 돌려받으라는 이야기입니다. AGENTS.md 도 마찬가지였습니다. inject 로 걸리는 줄은 헬퍼를 스코프에 주입한다는 구현 설명뿐이었습니다.

Aside 의 Set agent permissions 문서도 같았습니다. 권한 종류와 기본값과 우선순위는 정리돼 있는데, 프롬프트 인젝션이나 믿을 수 없는 페이지 내용이나 악성 사이트에 대한 말은 없습니다.

이건 ego lite 만의 빈칸이 아니었습니다. 사람과 에이전트 사이의 예절은 둘 다 정해 놨습니다. ego lite 는 소유권 표를 만들었고 Aside 는 Allow, Ask, Deny 를 만들었습니다. 그런데 웹페이지와 에이전트 사이의 경계는 둘 다 비어 있습니다.

에이전트가 페이지를 읽으면 그 페이지 텍스트가 컨텍스트에 들어옵니다. 거기에 지시문이 섞여 있으면 에이전트가 그걸 읽습니다. 브라우저를 쓰는 에이전트라면 늘 안고 가는 위험입니다. 문제는 그 지시문이 어디까지 닿느냐입니다. 에이전트가 읽는 페이지는 제가 고른 게 아닐 때가 많습니다. 검색 결과를 따라가고, 링크를 타고, 광고가 붙은 페이지를 지나갑니다. 그중 어느 페이지에 무슨 글자가 숨어 있는지는 저도 모르고 에이전트도 모릅니다. 그래서 이 경계는 사람과 에이전트 사이의 예절보다 더 먼저 정해야 하는 게 아닐까 싶었습니다.

ego lite 는 그 길이 코드로 보입니다. 이슈 #315 에 줄 번호까지 짚어서 정리돼 있습니다. 모델이 쓴 코드를 호스트 프로세스에서 샌드박스 없이 실행하고, 그 코드에 원본 cdp 와 서버 쪽 fetch 가 같이 주입되고, CDP 메서드는 걸러지지 않고, Node 쪽 HTTP 송신에도 제한이 없다는 내용입니다. http.ts 를 직접 열어 봤습니다.

const response = await nativeFetch(url, {
  ...fetchOptions,
  headers: { "User-Agent": "Mozilla/5.0", ...headers },
  signal: AbortSignal.timeout(timeout * 1000),
});

Node 에서 나가는 요청에 브라우저 User-Agent 를 기본으로 붙여 놨습니다.

이걸 합치면 이렇게 됩니다. 모델이 쓴 스크립트가 특권 컨텍스트에서 실행되고, 그 스크립트는 걸러지지 않는 CDP 로 HttpOnly 쿠키까지 읽을 수 있고, 같은 스크립트에서 바깥으로 HTTP 요청을 마음대로 보낼 수 있습니다. 그리고 그 스크립트를 쓰는 모델은 방금 읽은 웹페이지 텍스트를 머릿속에 들고 있습니다.

보고자는 비공개 취약점 신고 창구가 403 을 돌려줘서 이슈로 올렸다고 했고, 실제 프로필이나 쿠키는 건드리지 않고 가짜 쿠키와 로컬 수집기로만 확인했다고 적었습니다. 유지관리자는 이렇게 답했습니다.

Because ego-browser runs locally on the user's machine, our current view is that if someone is already able to execute ego-browser locally, they can also execute arbitrary local commands with the same local user privileges. For that reason, whether this should be classified as a security vulnerability is debatable from our perspective.

그리고 같은 답의 마지막에 이렇게 덧붙였습니다.

That said, I reviewed your report carefully, and I agree that the behaviors you described do exist. The part we are still debating is the security classification of this issue, not whether the underlying behaviors are real.

지적된 동작이 실제로 있다는 건 인정하고, 그걸 취약점으로 부를지만 아직 논의 중이라는 겁니다. 비공개 신고 창구도 살펴보겠다고 했습니다.

이 답은 공격자를 로컬 사용자로 놓고 있습니다. 로컬에서 명령을 실행할 수 있는 사람이면 어차피 뭐든 할 수 있으니 새로 생긴 권한이 아니라는 거죠. 그 말 자체는 맞습니다. 그런데 이 도구에서 공격자는 로컬 사용자가 아니라 에이전트가 들른 웹페이지라고 생각합니다. 그 페이지는 로컬에서 명령을 실행할 수 없지만, 에이전트의 컨텍스트에 글자를 넣을 수는 있습니다. 그리고 그 에이전트가 특권 컨텍스트에서 코드를 쓰고 실행합니다. 로컬 사용자만 갖고 있던 권한을, 로컬 사용자가 아닌 쪽이 닿을 수 있게 만든 겁니다.

Aside 에서 같은 조합이 되는지는 소스가 없어서 모릅니다. Sandbox 가 명령 실행을 OS 수준에서 격리한다고 문서에 있으니 그 층을 설계에 넣긴 했습니다.

검문소와 통행증 발급처가 같은 곳이면 게이트가 아니라는 이야기를 예전에 한 번 쓴 적이 있는데, 이건 그보다 한 단계 앞의 문제입니다. 게이트가 자기 채점인 게 아니라 게이트가 아예 없습니다.

ego lite 이슈에는 이런 질문도 있었습니다. 어떤 사용자가 X 와 LinkedIn 자동화에 이 도구를 쓰려는데 자기 진짜 계정으로 도는 거라 계정이 제한될까 걱정된다고, 탐지를 피하는 법을 묻는 게 아니라 책임 있게 쓸 수 있는 범위를 알고 싶다고 물었습니다. 답은 아직 하나도 안 달렸습니다.

이 항목은 둘 다 빈칸이라고 봤습니다. 이 글을 쓰면서 제일 오래 붙잡고 있었던 부분입니다. 처음엔 ego lite 만의 빈칸이라고 생각해서 그렇게 썼다가, Aside 권한 문서를 읽고 지웠습니다. 사람이 에이전트에게 무엇을 허용할지는 둘 다 꼼꼼하게 정해 놨는데, 페이지가 에이전트한테 말을 거는 경우는 둘 다 안 다룹니다. ego lite 는 그 길이 코드로 보이고 Aside 는 안 보인다는 차이뿐인데, 안 보인다고 안전하다는 뜻은 아니라고 생각합니다.

설치 경로

ego lite 는 설치까지 에이전트한테 맡기게 해 놨습니다. skills/ego-browser/scripts/install.sh 가 CPU 아키텍처를 보고 DMG 를 받아서, 마운트하고, /Applications 에 넣습니다. 권한이 없으면 sudo 로 넘어갑니다. 그리고 이 줄이 있습니다.

xattr -dr com.apple.quarantine "$staged_app"

Gatekeeper 가 첫 실행을 막지 않게 격리 속성을 뗀다는 주석이 붙어 있습니다. macOS 가 처음 실행하는 앱에 붙이는 표시를 떼어 내는 겁니다. codesign 도 spctl 도 안 부르고, 받은 파일의 해시를 확인하는 단계도 없고, 확인할 해시가 공개돼 있지도 않습니다.

이슈 #292 가 여기를 파고들었습니다. 보고자가 공식 DMG 몇 개에 엄격한 서명 검증을 돌렸더니 다 실패했다고 했습니다. invalid signature (code or signature have been modified) 라는 오류였습니다. 보고자는 악성코드나 데이터 탈취를 주장하는 게 아니라, 다시 해 봐도 똑같이 나오는 배포 무결성 실패와 macOS 첫 실행 보안 장치가 약해지는 걸 보고한다고 말머리에 적었습니다. 유지관리자는 같은 날 재현이 안 된다고 답했고, AI 샌드박스 같은 제한된 환경 말고 정상적인 로컬 macOS 에서 권한을 갖고 돌려 달라고 했습니다. 시스템 접근이 막혀 있으면 서명 검사가 엉뚱하게 실패할 수 있다는 건데, 그 요청 자체는 타당해 보였습니다. 이 이슈도 아직 열려 있습니다.

DMG 주소도 봤습니다. README 와 install.sh 가 가리키는 파일명이 달라서 다른 빌드를 받는 건가 싶었습니다. 두 주소에 HEAD 를 보내 봤습니다.

README:     127175776 bytes, etag 0001807cd3ec99bafc381cfa98bc9abe
install.sh: 127175776 bytes, etag 0001807cd3ec99bafc381cfa98bc9abe

같은 파일이었습니다. CDN 이 파일명은 무시하고 최신 빌드를 돌려주는 것 같습니다. 그래서 오래된 스크립트로 설치해도 최신 빌드를 받습니다. 여기까지는 괜찮습니다.

그런데 파일명이 버전을 가리키지 않는다는 게 마음에 걸렸습니다. 주소만 보고는 어떤 빌드를 받는지 알 수 없고, 받은 파일을 맞춰 볼 해시도 없고, 설치 스크립트는 확인 없이 격리 속성을 벗기고 실행합니다. 이 셋이 같이 있으면 나중에 뭔가 잘못됐을 때 그때 내가 받은 게 뭐였는지 되짚을 방법이 없습니다. 문제가 없을 때는 아무 상관 없는 이야기인데, 문제가 생기고 나서야 필요해지는 정보라서 필요할 때는 이미 늦습니다.

Aside 는 curl -fsSL https://releases.aside.com/install.sh | bash 로 CLI 를 깔고 앱은 따로 받는 구조입니다. 이 스크립트는 제가 안 열어 봤습니다. 파이프로 셸에 바로 넣는 방식이라 그것도 그 나름대로 믿고 맡기는 문제가 있습니다. npm install 하나가 어디까지 닿는지를 keyv 웜을 보면서 세어 본 적이 있는데 결국 같은 종류의 이야기라고 생각합니다. macOS 격리 속성이 실제로 무엇을 막고 있는지는 5900 포트를 세어 보던 날 한 번 들여다봤습니다.

이 항목은 판단을 미뤘습니다. ego lite 쪽만 확인했으니까요. 스크립트에 격리 속성을 떼는 줄이 있는 것도, 서명 이슈가 열려 있는 것도 사실인데, curl | bash 를 스크립트도 안 읽고 실행하는 것보다 나쁘다고 말할 근거가 저한테는 없습니다. 어차피 둘 다 제 손으로 설치할 생각이라 저한테는 별 의미가 없는 항목이기도 합니다.

무엇을 열었고 무엇을 안 열었나

여기까지 오면서 계속 느낀 건, 두 회사가 연 게 서로 반대라는 점이었습니다.

ego lite 는 구현을 열었습니다. 드라이버가 MIT 로 공개돼 있고 이슈가 백 건 넘게 열려 있습니다. 그래서 쿠키가 프로필을 넘는다는 재현 절차도, 에이전트가 사용자 로그인을 날린 사고도, 특권 실행 경로도 다 읽을 수 있었습니다. 대신 성능 주장은 그래프 한 장이 전부입니다.

Aside 는 성적과 정책을 열었습니다. 수백 개 태스크의 기록과 실패 목록과 채점 설정이 다 있고, 권한 모델과 자격증명 처리가 문서에 문장으로 적혀 있습니다. 대신 구현은 볼 수 없고 공개 이슈 트래커도 없어서, 그 정책이 실제로 지켜지는지도, 사고가 난 적이 있는지도 밖에서는 모릅니다.

그래서 이걸 ego lite 가 더 위험하다는 이야기로만 듣고 싶지는 않습니다. ego lite 는 자기가 무엇을 넘기는지 읽을 수 있게 해 놨고, 읽어 보니 넘기는 게 많았습니다. Aside 는 적게 넘긴다고 말하고 그 정책을 문서로 적어 놨는데, 지켜지는지 확인할 창구는 안 줬습니다. 열린 쪽이 결함이 더 많이 보이는 건 열려 있어서이기도 합니다. 저는 둘 중 하나를 고르라면 읽을 수 있는 쪽이 마음이 편합니다. 결함이 보이면 피해 가기라도 할 수 있으니까요. 안 보이는 결함은 피할 방법도 없습니다. 물론 그건 제가 소스를 읽을 시간이 있을 때 이야기고, 그럴 시간이 없는 사람한테는 잘 정리된 문서가 더 믿음직할 수도 있겠습니다.

구현을 확인할 수 있느냐는 항목은 그래서 ego lite 쪽입니다. 이 글에 적은 대부분을 남이 요약한 글이 아니라 소스와 재현 절차로 확인했습니다. Aside 쪽 문장들은 결국 "문서에 그렇게 적혀 있다" 에서 멈춥니다. 앞에서 ego lite 가 밀린 이유들이 전부 이 항목에서 앞섰기 때문에 드러났다는 게 좀 아이러니합니다.

가격도 ego lite 쪽입니다. 무료이고 계정도 필요 없습니다. Aside 는 구독이나 API 키가 필요합니다. 그런데 돈을 안 내는 대신 무엇을 내주는지는 로그인과 격리 이야기에 이미 다 나와 있어서, 이걸로 셈이 끝나지는 않습니다.

설계의 출발점은 분명히 다릅니다. Aside 는 자격증명을 에이전트한테 보여 주지 않는 데서 시작했고, ego lite 는 사용자의 로그인 상태를 그대로 물려주는 데서 시작했습니다. 뒤쪽이 훨씬 편하고, 봇 탐지도 지나가고, 설정할 것도 없고, 무료입니다. 다섯 달 만에 스타가 그렇게 붙은 것도 그래서일 겁니다. 편한 이유와 위험한 이유가 같은 한 가지라는 게 이 도구의 성질인 것 같습니다.

그 밖에 본 것들

주제와는 좀 떨어진 것들인데 같이 봤으니 적어 둡니다. 거의 다 ego lite 쪽입니다. 열려 있는 쪽만 이렇게 볼 수 있다는 게 앞에서 말한 차이입니다.

메모리 이야기가 있었습니다. 병렬로 자동화를 돌리다 보면 RAM 이 수십 GB 까지 올라가서 WindowServer 가 멈추거나 브라우저가 얼어붙는다는 보고입니다. 보고자는 탭마다 수백 MB 를 먹는 Chromium, 쌓여 가는 CDP 이벤트 버퍼와 V8 힙, 그리고 텍스트만 긁어 오면 되는 일에도 렌더링까지 다 하는 탭을 띄우는 구조를 원인으로 꼽았습니다. Space 를 여러 개 동시에 띄울 수 있다는 걸 내세우는 제품이라면 그 값을 여기서 치르는 것 같습니다.

그 보고자는 SKILL.md 패치를 만들어서 자기 fork 브랜치 링크를 붙여 뒀습니다. 왜 PR 이 아니라 fork 링크인지 궁금해서 닫힌 PR 을 훑어봤습니다. 외부에서 온 PR 은 거의 머지되지 않았고, 머지된 몇 개도 CI 셸 인젝션 수정이나 다른 언어 README 추가 같은 것이었습니다. 내부 브랜치 PR 은 대부분 머지됐습니다. 열려 있는 외부 PR 중에는 Linux 포팅 전체 구현도 있었습니다. fork PR 이 404 를 받는다며 협업자 권한을 요청한 이슈도 있었는데, 정작 CONTRIBUTING.md 는 꽤 긴 분량으로 PR 절차를 설명하고 있었습니다. 절차는 길게 써 놨는데 바깥에서 온 PR 이 거의 안 들어가는 걸 보면, 이 저장소가 바깥 기여를 어떻게 생각하는지는 문서보다 머지 기록이 더 정확하게 말해 주는 것 같습니다.

저장소에 성장 장치도 들어 있었습니다. README 에 Trendshift 배지가 있고, star-history 차트를 직접 그려서 올리는 GitHub Actions 워크플로우가 있습니다. main 브랜치 규칙이 봇 커밋을 안 받아서 별도 브랜치로 발행하게 했다는 커밋 메시지도 있었습니다.

작동하지 않는다는 보고도 몇 개 있었습니다. SKILL.md 는 cliLog(help('click')) 로 사용법을 확인하라고 하는데 help() 가 모든 헬퍼에 대해 "Unknown helper" 를 돌려준다는 보고가 있고, 요소 중심이 화면 밖이면 click(selector) 이 조용히 헛클릭한다는 보고, Radix 스타일 팝오버가 안 열린다는 보고, 런타임을 강제로 끄면 모든 Space 조작이 영영 멈춰서 앱을 다시 켜도 안 풀린다는 보고가 있었습니다.

Aside 쪽은 문서로 보이는 한계만 있었습니다. changelog 를 보면 CPU/GPU 사용량이 튀던 걸 고쳤고, 최근 버전에서 프로필 전환 버그를 고쳤습니다. 첫 macOS 릴리스가 2월이고 6월에 공개 출시로 화제가 됐으니 반년 정도 다듬어 온 제품입니다. 그리고 앞에서 말한 대로 MFA, 패스키, 캡차는 사람이 해야 합니다.

저한테 맞는 쪽

아홉 가지를 하나씩 보고 나니 어느 쪽이 몇 개 앞섰는지는 별 의미가 없었습니다. 제어 방식에서 앞선 이유가 로그인에서 밀린 이유였고, 구현을 열어 둔 덕에 격리 문제가 드러났습니다. 항목들이 서로 따로 놀지 않았습니다. 그래서 점수 대신 제 작업으로 나눠 봤습니다.

로그인이 필요 없는 일이면 ego lite 를 쓸 것 같습니다. 공개 페이지 스크래핑, 제가 띄운 개발 서버 QA, 사내 스테이징 훑어보기 같은 일입니다. 이런 일에는 제어 방식과 가격만 걸리고 로그인, 격리, 게이트 이야기는 아예 해당이 안 됩니다. 쿠키를 안 물려주면 이 글에서 센 문제 대부분이 사라지고, 왕복을 접는 구조와 무료라는 것만 남습니다. 저는 이쪽 작업이 더 많아서 ego lite 를 먼저 설치하게 될 것 같습니다.

제 계정으로 돌아야 하는 일이면 Aside 를 쓸 것 같습니다. 로그인, 격리, 게이트가 전부 여기서 정해집니다. 자격증명 처리 방식이 제품 페이지 문구가 아니라 help 문서에 문장으로 있고, 접근 정책 세 단계도 문서에 있고, 민감한 동작 확인이 권한 모델로 받쳐져 있습니다. MCP 서버라서 제 Claude Code 를 그대로 붙일 수 있는 것도 큽니다. 돈을 내야 하는 건 아쉽지만 무료 대신 선을 긋는 걸 사는 거라면 납득이 됩니다. 제일 마음에 걸리는 건 감사 로그입니다. 제품 페이지에는 다 기록된다고 돼 있는데 문서에는 없어서, 실제로 뭘 어디에 남기는지는 물어봐야 알 것 같습니다.

이 두 문장을 합치면 ego lite 의 핵심 기능을 빼고 쓰겠다는 말이 됩니다. 로그인 상태를 물려주는 게 이 도구의 요점인데 그것만 안 쓰겠다는 거니까요. 이상하게 들리긴 하는데 지금은 그렇게 생각합니다. #303 이 열려 있는 동안은 에이전트가 401 하나 만나서 제 로그인을 날릴 수 있고, 그건 에이전트가 이상하게 굴어서가 아니라 문서가 격리라고 한 게 격리가 아니라서 생기는 일입니다.

처음엔 버리는 프로필을 하나 만들어서 우회하면 되지 않을까 생각했는데, 지금은 안 됩니다. #319 가 바로 그 시도를 막습니다. Storage.setCookies 가 목적지를 무시하고 기본 프로필로 들어가니 세션을 옮겨 심을 수가 없습니다. 프로필 단위 Space 를 지원하겠다고 했으니 그때 다시 볼 생각입니다.

설치 스크립트는 어느 쪽이든 안 쓸 것 같습니다. ego lite 의 install.sh 가 하는 일 중에 제가 맡기고 싶은 건 DMG 를 받아서 앱을 옮기는 것 하나뿐입니다. 격리 속성을 떼는 건 제가 직접 판단할 일이지, 스크립트가 sudo 로 넘어가면서 조용히 처리할 일이 아닙니다. 받은 파일에 codesign --verify 를 한 번 돌려서 #292 가 말한 결과가 제 맥에서도 나오는지 보는 게 먼저일 것 같습니다. 유지관리자는 재현이 안 된다고 했으니 어느 쪽이 맞는지는 직접 봐야 알겠습니다. Aside 의 curl | bash 도 스크립트를 먼저 받아서 읽고 돌릴 생각입니다.

"격리" 라고 적힌 문구는 앞으로 한 번 더 물어보게 될 것 같습니다. 무엇과 무엇을 나눠 놓는지가 안 적혀 있으면 탭만 나눠 놓았다는 뜻일 수도 있습니다. ego lite 는 그 구분을 마케팅 문구에 안 넣었고, 유지관리자는 이슈에서 정확하게 답했습니다. 두 문장이 다 같은 프로젝트에서 나왔으니 거짓말을 한 건 아니고, 읽는 사람이 어느 문장을 먼저 만나느냐의 문제였습니다. Qwen 3.8 을 설치하기 전에 알아봤을 때도 비슷했습니다. "싸졌다" 는 말에 뜻이 세 가지 있었고 그중 하나만 저한테 해당했습니다.

제일 오래 들여다본 건 결국 양쪽 문서에 똑같이 비어 있던 부분입니다. 사람이 브라우저를 되찾은 순간을 돌아갈 장애물이 아니라고까지 적어 둔 문서도, 도구 권한을 Allow, Ask, Deny 로 나눠 둔 문서도, 웹페이지가 에이전트한테 말을 거는 순간에 대해서는 아무 말이 없습니다. 앞의 것들은 실제로 부딪혀서 배운 흔적처럼 보이는데, 이건 아직 둘 다 부딪혀 보지 않은 것 같습니다. #315 에서 유지관리자가 인정한 건 그 동작이 있다는 것이었고, 이견을 남긴 건 그걸 취약점으로 부를지였습니다. 그걸 어떻게 부르기로 하느냐에 따라 다음 버전에 게이트가 들어갈지 말지가 정해지지 않을까 싶습니다.

설치하고 나서 볼 것도 적어 뒀습니다. ego lite 는 스냅샷이 iframe 을 실제로 얼마나 버티는지, heredoc 한 번에 몇 단계까지 넣으면 오히려 실패가 늘어나는지, @N ref 가 다시 렌더링될 때 얼마나 자주 엉뚱한 요소를 가리키는지가 궁금합니다. Aside 는 Ask 게이트가 실제로 어디까지 걸리는지, 자격증명을 쓴 기록이 어디에 남는지, MCP 왕복이 제 작업에서 heredoc 보다 얼마나 느린지를 보고 싶습니다. 벤치마크 숫자가 제 작업에서도 나오는지는 그때 재 보면 됩니다. 이런 건 소스를 읽어서는 안 나오고, 반대로 소스를 안 읽고 설치하면 뭘 넘겼는지 모르는 채로 재게 됩니다.