초기 코딩 에이전트는 놀랍도록 강력한 기능을 보여주었습니다. 에이전트에게 Bash에 대한 액세스 권한을 부여하면 코드 작성 및 컨텍스트 수집부터 전체 Git 워크플로 관리에 이르기까지 거의 모든 작업을 수행할 수 있습니다.
이러한 통찰력은 CLI 우선 소프트웨어를 향한 광범위한 움직임을 촉진하는 데 도움이 되었습니다. 명령줄 인터페이스는 AI 에이전트가 복잡한 애플리케이션에 액세스할 수 있도록 하는 표준 방법처럼 보이기 시작했으며 다음과 같은 친숙한 슬로건이 탄생했습니다.
CLI만 있으면 됩니다.
그러나 숨겨진 비용이 있습니다. 에이전트는 사람이 사용하는 것처럼 터미널을 사용하는 경우가 많습니다. 간단한 명령을 실행하고 결과를 확인한 후 다음에 수행할 작업을 결정합니다. 작업이 더욱 복잡해짐에 따라 모델과 도구 사이에 더 많은 왕복 작업이 발생하게 되고, 이는 더 많은 LLM 호출, 더 많은 컨텍스트 낭비, 대기 시간 증가를 의미합니다.
에이전트에게 복잡한 쉘 스크립트를 조합하라고 요청하는 대신, 에이전트가 이미 이해하고 있는 프로그래밍 언어로 작업을 조정하는 것을 선호합니다. 이는 약간 다른 아키텍처로 이어집니다.
CLI를 범용 진입점으로 유지하되 코드를 소프트웨어와 상호 작용하는 실제 방법으로 사용하십시오.
에이전트는 여러 라운드의 상호 작용에 걸쳐 분산되는 작업, 결정 및 데이터 처리가 포함된 코드 블록을 제출합니다. 그러면 로컬 런타임이 워크플로를 실행합니다.
ego-browser는 이 아이디어를 바탕으로 만들어졌습니다. CLI는 프로그래밍 가능한 환경을 시작하고, 브라우저는 작은 기능 세트를 통해 기능을 공개하며, 에이전트는 기존 프로그래밍 기술을 사용하여 해당 기능을 구성하고 그들을 조율하다.
이번 글에서는 비교해보겠습니다. heredoc 및 REPL, CLI를 통해 코드를 실행하는 두 가지 방법을 설명하고 ego-browser의 실험 결과를 공유합니다. heredoc를 사용하여 에이전트는 44% 더 적은 실행 라운드, 35.5% 더 적은 도구 호출, 21.6% 더 낮은 비용으로 동일한 작업을 완료했습니다.
"CLI만 있으면 됩니다." 그렇다면 무엇입니까?
“CLI만 있으면 된다”는 주장은 모델이 해당 CLI를 사용하는 방법을 이미 알고 있다고 가정합니다.
Git, Docker, FFmpeg 등 잘 알려진 도구의 경우 이는 일반적으로 문제가 되지 않습니다. 모델은 학습 중에 수많은 명령, 튜토리얼, 스크립트 및 오류 메시지를 확인했으며 이미 인수와 명령이 어떻게 결합되는지 알고 있습니다.
그러나 에이전트를 위한 새로운 CLI를 구축하면 상황이 달라집니다. 모든 CLI에는 고유한 하위 명령, 인수, 출력 형식 및 오류 의미 체계가 있습니다. 모델에게는 본질적으로 새로운 미니 언어입니다. 완전한 문서화에도 불구하고 모델은 먼저 규칙을 학습한 다음 반복 호출을 통해 명령이 어떻게 서로 맞는지 파악해야 합니다.
대신 JavaScript API 또는 다른 언어의 API와 동일한 기능을 노출하면 모델은 여전히 새로운 도메인 개념을 배워야 하지만 더 이상 제어 흐름, 데이터 구조 또는 구성을 다시 배울 필요가 없습니다. 루프, 조건, 예외 처리 및 데이터 처리는 모두 이미 알고 있는 프로그래밍 언어로 유지됩니다.
간단한 작업을 수행해 보세요. 웹페이지를 열고 주요 제목을 읽어보세요. ego-browser가 기존 명령 스타일 인터페이스를 노출한 경우 에이전트가 이를 완료하려면 여러 단계가 필요할 수 있습니다.
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role heading모든 단계가 끝나면 에이전트는 도구를 기다리고 결과를 읽고 다음에 수행할 작업을 결정합니다.
실제로 사용되는 코드 인터페이스 ego-browser를 사용하면 전체 작업 흐름을 한 번에 표현할 수 있습니다.
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);두 접근 방식 모두 동일한 작업을 수행합니다. 명령 스타일 인터페이스는 프로세스를 모델-도구 상호 작용의 여러 라운드로 나눕니다. 코드 인터페이스를 사용하면 에이전트가 전체 프로세스를 한 번 작성하여 로컬 런타임에 전달할 수 있습니다.
이것이 바로 앞에서 언급한 설계 아이디어입니다. 즉, CLI를 범용 진입점으로 유지하되 코드를 소프트웨어에 대한 실제 인터페이스로 사용하는 것입니다. 이는 호출 및 통합이 쉽다는 CLI의 장점을 유지하는 동시에 모델이 구성 및 오케스트레이션을 위해 이미 보유하고 있는 프로그래밍 기술을 사용할 수 있도록 합니다.
CLI가 코드의 게이트웨이가 되는 경우
CLI가 코드를 승인하면 다음 질문은 에이전트가 해당 코드를 실행 환경에 어떻게 전달해야 하는가입니다.
엄밀히 말하면 heredoc은 쉘 입력 구문이고 REPL은 인터프리터의 실행 모드입니다. 둘은 동일한 추상화 계층에 있지 않습니다. 이 기사에서 실제로 비교하는 것은 ego-browser의 heredoc을 통해 입력된 원샷 코드 실행과 REPL에 구축된 지속적인 대화형 세션입니다. 간결함을 위해 여기에서는 이들을 heredoc 및 REPL이라고 부르겠습니다.
한 가지 방법은 heredoc입니다. ego-browser에서 에이전트는 전체 JavaScript 블록을 한 번에 제출합니다.
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF셸은 코드를 ego-browser에 전달하고, 실행이 끝날 때까지 기다린 뒤 결과를 받아 종료합니다. 에이전트 입장에서는 일반적인 도구 호출처럼 작동합니다.
Submit command → wait for process → receive resultREPL은 다르게 작동합니다. 인터프리터는 활성 상태로 유지되므로 에이전트가 변수와 세션 상태를 유지하면서 반복적으로 코드를 입력할 수 있습니다.
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"표현력 측면에서 이 둘은 본질적으로 동일합니다. REPL은 루프, 조건 및 예외 처리가 포함된 완전한 프로그램을 한 번에 실행할 수 있으며 heredoc은 단 한 줄만 제출할 수 있습니다.
분명한 차이점은 프로세스 수명주기입니다. heredoc을 사용하면 코드 실행이 완료되자마자 프로세스가 종료됩니다. REPL은 인터프리터 프로세스를 활성 상태로 유지하고 추가 입력을 기다립니다. 이는 또한 에이전트 도구에 대한 두 가지 요구 사항이 다르다는 것을 의미합니다. heredoc은 익숙한 요청-응답 모델에서 직접 실행됩니다.
submit the command → wait for the process to exit → get the resultREPL은 지속적인 프로세스, 세션 관리, 지속적인 입력, 중단 및 복구 등 도구에 더 많은 것을 요구합니다. 대부분의 에이전트에 내장된 Bash 도구에는 이러한 기능이 없습니다. 오늘날 주류 제품 중 Codex만이 이를 합리적으로 잘 지원합니다. 그리고 도구 지원은 REPL을 사용하기 위한 필수 조건일 뿐입니다. 모델이 실제로 어떻게 사용할지는 결정하지 않습니다. 두 환경 모두 동일한 코드를 실행할 수 있는 경우에도 모델은 여전히 각각 다르게 코드를 작성할 수 있습니다.
모델이 각 환경에서 코드를 작성하는 방법
이론적으로 모델은 두 환경 모두에서 동일한 프로그래밍 능력을 갖습니다. 실제로 우리는 일관된 행동 차이를 관찰했습니다.
- REPL에서 모델은 코드를 점진적으로 입력하는 경향이 있습니다.
- heredoc에서는 한 번에 완전한 프로그램을 생성할 가능성이 더 높습니다.
인간을 위한 소프트웨어는 인체공학을 고려해야 합니다. 에이전트를 위한 소프트웨어에도 비슷한 원칙이 필요합니다. 모델 경험 엔지니어링. 인터페이스는 훈련 중에 개발된 행동 패턴 모델과 함께 작동해야 합니다.
REPL과 heredoc 사이의 대조는 훈련 데이터의 분포를 반영합니다.
REPL 예제는 일반적으로 튜토리얼, 디버깅 세션 및 질문과 답변 교환에서 나옵니다. 일반적인 패턴은 탐색적입니다.
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textHeredoc 코드 블록은 스크립트나 소스 파일과 더 비슷해 보입니다. 여기에는 명시적인 시작 및 끝 경계가 있어 모델이 지속적인 워크플로를 생성하도록 장려합니다.
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);이는 REPL이 완전한 프로그램을 실행할 수 없다는 의미는 아닙니다. 모델은 한 단계로 동일한 코드 블록을 REPL에 제출할 수 있습니다.
구별은 상황에 따라 다릅니다. REPL은 다음을 권장합니다. 실행하다, 관찰하다, 계속하다 패턴. heredoc은 다음을 권장합니다. 먼저 정리하고 실행한다 패턴.
이러한 경향은 제어 흐름이 어디에 있는지도 결정합니다. REPL에서 모델은 작업을 여러 단계로 나누고 모든 결과 후에 무엇을 할지 결정할 가능성이 높습니다. heredoc에서는 루프, 조건, 필터링 및 데이터 처리를 프로그램에 직접 넣고 로컬 런타임에서 처리하도록 할 가능성이 더 높습니다.
실험이 보여준 것
안정적으로 통합할 수 있는 주류 에이전트 도구 중에서 Codex는 지속적인 REPL에 필요한 실행 기능을 제공했습니다. 그래서 우리는 Codex SDK에 자동화된 벤치마크를 구축했습니다. 동일한 에이전트가 REPL과 heredoc를 통해 4가지 유형의 실제 브라우저 작업을 완료했으며, 비교를 위해 반복 실행을 통해 결과를 집계했습니다.
작업은 다음과 같습니다.
- X 트렌드 포스트 분석: 지난 7일간 OpenAI님의 원본 게시물을 수집하고 고정된 게시물, 재게시물, 답글을 제외하고 조회수 기준 상위 5위 순위를 매기고 참여율과 전체 평균을 계산합니다.
- OpenAI 취업 지원서: 샌프란시스코에서 올바른 클라우드 인프라 위치를 찾고, 이력서를 업로드하고, 지원서를 작성하고, 최종 제출 전에 중지하세요.
- Redfin 모기지 계산: 주택 유형 및 가격별로 오스틴의 부동산을 필터링하고, 정렬 후 첫 번째 결과를 열고, 계약금을 20%로 변경하고, 업데이트된 예상 월별 지불액을 검색합니다.
- Expedia 항공편 검색: JFK에서 MIA까지의 편도 직항 항공편을 찾아 특정 항공사에서 가장 저렴한 옵션을 선택한 다음 승객 정보를 입력하고 결제 전에 중지하세요.
이러한 작업에는 페이지를 열고 텍스트를 읽는 것 이상의 작업이 포함되었습니다. 여기에는 구조화된 추출, 조건부 필터링, 페이지 탐색, 파일 업로드, 양식 완성, 페이지 상태 변경 및 계산이 포함되어 브라우저 에이전트가 수행하는 대부분의 일반적인 작업을 포괄합니다.
두 접근 방식 모두 대부분의 작업을 완료했습니다. Heredoc은 REPL의 75.0%에 비해 77.5%의 성공률을 달성했습니다. 신뢰성의 차이는 미미했습니다.
더 큰 차이점은 효율성이었습니다.
- 평균 완료 시간이 감소했습니다. 35.0%.
- 평균 완료 시간이 단축되었습니다. 30.7%.
- 도구 호출이 감소했습니다. 35.5%.
- 토큰 소비량이 감소했습니다. 29.8%.
- 평균 비용이 감소했습니다. 21.6%.
REPL은 런타임 상태를 재사용할 수 있지만 이러한 이점으로 인해 상호 작용이 줄어들지는 않았습니다. 실제로 heredoc 에이전트는 더 적은 수의 도구 호출을 수행했습니다.
결과는 이전 관찰과 일치했습니다. REPL 내부에서 에이전트는 종종 작은 코드 조각을 실행하고 결과를 조사한 후 다음에 수행할 작업을 결정했습니다. 단일 프로그램 내에서 처리할 수 있었던 루프, 필터 및 결정은 대신 여러 모델-도구 교환에 분산되었습니다.
두 환경은 비슷한 표현력을 제공합니다. 효율성 차이는 주로 상호 작용 패턴이 에이전트 행동을 형성하는 방식에서 비롯됩니다. 적어도 이 네 가지 브라우저-에이전트 작업에 대해 heredoc은 모델이 완전한 프로그램을 구성하고, 루프, 필터링 및 결정을 코드에 푸시하고, 단계별 의사 결정의 추가 왕복을 피하도록 보다 일관되게 권장했습니다.
또한 Odysseys 데이터 세트에서 ego-browser를 유사한 REPL 기반 브라우저 자동화 제품과 비교하여 동일한 패턴이 더 큰 규모로 유지되는지 조사했습니다. 위의 통제된 실험과 달리 이 비교에는 두 개의 인터페이스를 통해 작동하는 동일한 모델이 아닌 두 개의 완전한 제품이 포함되었습니다. 따라서 전반적인 효율성을 비교하는 데 유용하지만 그 차이점을 REPL과 heredoc의 전적으로 관련시킬 수는 없습니다.
이것은 heredoc의 영구적인 승리가 아닙니다.
우리는 heredoc이 본질적으로 REPL보다 우수하다고 생각하지 않습니다.
우리의 결론은 2026년에 존재하는 모델의 기능, 훈련 데이터의 분포, 에이전트 도구의 설계에 따라 달라집니다.
오늘날의 에이전트는 일반적으로 한 번에 전체 코드 블록을 생성하는 데 더 능숙합니다. 쉘 도구는 또한 명령을 제출하고, 명령이 종료될 때까지 기다리고, 결과를 반환하는 간단한 수명 주기를 중심으로 설계되었습니다. 이러한 조건에서 heredoc을 사용하면 상호 작용 라운드를 줄이고 제어 흐름을 로컬에서 실행되는 코드로 쉽게 이동할 수 있습니다.
이러한 조건은 빠르게 바뀔 수 있습니다.
미래의 에이전트 도구는 안정적인 영구 세션, 구조화된 출력 및 강력한 상태 복구를 제공할 수 있습니다. 에이전트는 더 이상 REPL 프롬프트, 프로세스 상태, 중단된 세션 자체를 처리할 필요가 없습니다. 또한 대상 교육을 통해 모델이 불필요한 단계별 상호 작용에 빠지는 대신 REPL 내에서 사전에 완전한 프로그램을 제출하도록 가르칠 수도 있습니다.
그런 일이 발생하면 REPL은 추가 모델 호출 없이도 상태 재사용 및 즉각적인 피드백의 이점을 유지할 수 있습니다. 비용이 많이 드는 초기화, 수명이 긴 상태 또는 진정한 탐색 워크플로가 있는 작업에 더 나은 선택이 될 수도 있습니다.
그렇기 때문에 제목이 명시하고 있습니다. 2026. 우리는 영구적인 법칙을 발견했다고 주장하는 것이 아닙니다. 이는 현재 사용 가능한 모델 및 에이전트 도구를 기반으로 한 특정 시점의 엔지니어링 판단입니다.