초기 코딩 에이전트는 놀라운 가능성을 보여주었습니다. 에이전트에게 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 result반면 REPL은 도구에 더 많은 역량을 요구합니다. 지속적인 프로세스 관리, 세션 유지, 반복적인 입력 처리, 그리고 중단과 복구까지 필요합니다. 대부분의 에이전트에 내장된 Bash 도구에는 이러한 기능이 갖춰져 있지 않습니다. 최근 주요 제품 중에서는 Codex 정도만 이 기능을 어느 정도 지원합니다. 그러나 도구가 지원한다는 것은 REPL을 활용할 수 있는 필요조건일 뿐, 모델이 실제로 어떻게 사용할지는 결정하지 않습니다. 두 환경에서 동일한 코드를 실행할 수 있다 하더라도, 모델은 각 환경에 맞춰 다른 방식으로 코드를 작성할 수 있습니다.
환경마다 모델이 코드를 작성하는 방식이 다른 이유
이론적으로는 모델의 프로그래밍 능력이 두 환경에서 동일해야 합니다. 하지만 실제로는 일관된 행동 차이가 관찰되었습니다.
- REPL에서는 모델이 코드를 조금씩 나누어 입력하는 경향을 보입니다.
- heredoc에서는 완결된 프로그램을 한 번에 통째로 생성할 가능성이 더 높습니다.
사람을 위한 소프트웨어가 사용자 경험(UX)을 고려해야 하듯, 에이전트를 위한 소프트웨어에도 이와 유사한 원칙이 적용됩니다. 이를 '모델 경험 엔지니어링(Model Experience Engineering, MX)'이라 부르겠습니다. 인터페이스는 모델이 학습 과정에서 형성한 행동 패턴과 조화롭게 작동해야 합니다.
REPL과 heredoc의 차이는 학습 데이터 분포의 차이를 그대로 반영합니다.
REPL 예제는 주로 튜토리얼, 디버깅 세션, 질의응답에서 비롯됩니다. 전형적인 패턴은 탐색적입니다.
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the text반면 heredoc 코드 블록은 스크립트나 소스 파일에 더 가깝습니다. 시작과 끝이 명확하게 구분되어 있어, 모델이 하나로 이어지는 워크플로를 작성하도록 자연스럽게 유도합니다.
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 양쪽에서 네 가지 실제 브라우저 작업을 수행했고, 반복 실행한 결과를 모아 비교했습니다.
테스트한 작업은 다음과 같습니다.
- X(트위터) 트렌드 게시물 분석 (전형적인 소셜 미디어 스크래핑 작업): 지난 7일간 OpenAI가 올린 원본 게시물을 수집하고, 고정 게시물·리포스트·답글을 제외한 뒤 조회수 기준 상위 5개를 선정해 참여율과 전체 평균을 계산할 것
- OpenAI 채용 지원: 샌프란시스코 소재 클라우드 인프라 직무 공고를 정확히 찾아 이력서를 업로드하고, 지원서를 작성한 다음 최종 제출 직전에 중단할 것
- Redfin 대출 계산: 오스틴의 매물을 주택 유형과 가격으로 필터링하고 정렬한 뒤 첫 번째 결과를 열고, 계약금을 20%로 변경하여 갱신된 예상 월 납입금을 확인할 것
- Expedia 항공권 검색: JFK에서 MIA까지 편도 직항편을 찾아 지정된 항공사 중 가장 저렴한 옵션을 선택하고, 탑승객 정보를 입력한 후 결제 직전에 중단할 것
이 작업들은 단순히 페이지를 열고 텍스트를 읽는 수준을 넘어섰습니다. 구조화된 데이터 추출, 조건부 필터링, 페이지 간 이동, 파일 업로드, 양식 작성, 페이지 상태 변경, 계산까지 포함하며, 브라우저 에이전트가 수행하는 일반적인 작업 대부분을 포괄했습니다.
두 방식 모두 대부분의 작업을 완료했습니다. heredoc의 성공률은 77.5%, REPL은 75.0%로, 신뢰도 차이는 크지 않았습니다.
더 큰 차이는 효율성에서 나타났습니다.
- 평균 완료 시간 감소폭 35.0%.
- 중앙값 완료 시간 감소폭 30.7%.
- 도구 호출 횟수 감소폭 35.5%.
- 토큰 소비량 감소폭 29.8%.
- 평균 비용 감소폭 21.6%.
REPL은 런타임 상태를 재사용할 수 있음에도 불구하고, 그 이점이 상호작용 횟수를 줄여주지는 못했습니다. 실제로 heredoc을 사용한 에이전트가 도구 호출을 더 적게 기록했습니다.
이 결과는 앞서 관찰한 내용과 일치합니다. REPL 환경에서는 에이전트가 작은 코드 조각을 실행하고 결과를 살펴본 뒤 다음 행동을 결정하는 패턴이 자주 나타났습니다. 원래 하나의 프로그램으로 처리할 수 있었던 반복문, 필터, 판단 로직이 여러 차례의 모델-도구 간 왕복으로 분산된 것입니다.
두 환경은 표현력 면에서 비슷합니다. 효율성의 차이는 주로 상호작용 패턴이 에이전트의 행동을 어떻게 이끌어내는지에서 비롯됩니다. 적어도 이 네 가지 브라우저 에이전트 작업에서는, heredoc이 모델이 완결된 프로그램을 작성하고 반복문·필터링·판단을 코드 안에 포함하도록 유도함으로써, 단계별 판단 과정에서 발생하는 왕복 부담을 피하게 하는 데 더 일관되게 효과적이었습니다.
같은 패턴이 더 큰 규모에서도 유지되는지 확인하기 위해, Odysseys 데이터셋에서 ego-browser를 유사한 REPL 기반 브라우저 자동화 제품과 비교했습니다. 위의 통제된 실험과 달리, 이번 비교는 동일한 모델이 두 인터페이스를 사용한 것이 아니라 완전히 다른 두 제품을 비교한 것입니다. 따라서 전체적인 효율성 비교로는 의미가 있지만, 그 차이를 heredoc과 REPL의 차이만으로 설명할 수는 없습니다.
그렇다고 heredoc이 절대적 우위를 점한다는 뜻은 아닙니다
저희는 heredoc이 REPL보다 본질적으로 우월하다고 생각하지 않습니다.
이 결론은 2026년 현재의 모델 능력, 학습 데이터 분포, 그리고 에이전트 도구의 설계 방식에 기반한 것입니다.
현재의 에이전트들은 대체로 코드 블록을 한 번에 완결된 형태로 생성하는 데 더 강점을 보입니다. 셸 도구 역시 명령을 제출하고, 종료를 기다렸다가, 결과를 반환받는 단순한 생명주기를 중심으로 설계되어 있습니다. 이러한 조건에서는 heredoc이 상호작용 횟수를 줄이고 제어 흐름을 로컬에서 실행되는 코드로 이관하는 데 더 수월합니다.
하지만 이런 조건은 언제든지 바뀔 수 있습니다.
앞으로 등장할 에이전트 도구는 안정적인 지속 세션, 구조화된 출력, 견고한 상태 복구 기능을 제공할지도 모릅니다. 그렇게 되면 에이전트가 REPL 프롬프트나 프로세스 상태, 끊긴 세션을 직접 관리해야 할 필요가 사라질 수도 있습니다. 목적에 맞게 학습이 이루어지면, 모델이 불필요한 단계별 상호작용에 빠지지 않고 REPL 안에서도 처음부터 완결된 프로그램을 제출하도록 유도할 수 있을 것입니다.
그런 변화가 일어난다면, REPL은 모델 호출을 늘리지 않으면서도 상태 재사용과 즉각적인 피드백이라는 장점을 그대로 유지할 수 있습니다. 초기화 비용이 크거나, 상태를 오래 유지해야 하거나, 진정한 탐색적 워크플로가 필요한 경우에는 오히려 REPL이 더 나은 선택이 될 수도 있습니다.
그래서 제목에 2026이라는 연도를 명시했습니다. 저희는 영구적인 법칙을 발견했다고 주장하는 것이 아닙니다. 이는 현재 사용 가능한 모델 및 에이전트 도구를 바탕으로 한, 특정 시점의 엔지니어링 판단입니다.