초기 코딩 에이전트는 놀라운 사실을 보여줬습니다. 에이전트에게 Bash 접근 권한만 주면, 코드 작성과 맥락 수집부터 Git 워크플로 전체 관리까지 거의 모든 걸 할 수 있다는 것입니다.
이 깨달음은 CLI 우선 소프트웨어라는 더 큰 흐름에 힘을 보탰습니다. 명령줄 인터페이스는 복잡한 애플리케이션을 AI 에이전트가 쓸 수 있게 만드는 표준 방식처럼 보이기 시작했고, 익숙한 슬로건 하나가 생겨났습니다:
CLI 하나면 충분하다.
하지만 숨겨진 비용이 있습니다. 에이전트는 종종 사람처럼 터미널을 씁니다. 짧은 명령을 실행하고, 결과를 확인하고, 다음 행동을 정하는 식이죠. 작업이 복잡해질수록 모델과 도구 사이의 왕복이 늘어나고, 그만큼 LLM 호출도, 낭비되는 맥락도, 기다리는 시간도 늘어납니다.
에이전트에게 복잡한 셸 스크립트를 짜라고 시키는 대신, 이미 이해하고 있는 프로그래밍 언어로 작업을 조율하게 하는 편이 낫다고 생각했습니다. 이건 조금 다른 구조로 이어집니다:
CLI는 범용 진입점으로 남겨두되, 실제 소프트웨어와의 상호작용은 코드로 하는 것입니다.
에이전트는 원래라면 여러 라운드의 상호작용으로 흩어져 있었을 동작, 판단, 데이터 처리를 담은 코드 블록을 제출합니다. 그러면 로컬 런타임이 그 워크플로를 실행합니다.
ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and 조율하는.
이 글에서는 다음을 비교합니다: 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 양쪽으로 네 가지 실제 브라우저 작업을 수행했고, 반복 실행 결과를 모아서 비교했습니다.
테스트한 작업은 다음과 같습니다:
- X trending-post analysis (a typical social media scraping workload): 지난 7일간 OpenAI가 올린 원본 게시물을 모으고, 고정 게시물, 리포스트, 답글은 제외한 다음, 조회수 기준 상위 5개를 뽑아 참여율과 전체 평균을 계산해줘.
- OpenAI 채용 지원: 샌프란시스코에 있는 클라우드 인프라 직무 공고를 정확히 찾아서, 이력서를 올리고, 지원서를 작성한 다음, 최종 제출 전에 멈춰줘.
- Redfin 대출 계산: 오스틴의 매물을 주택 유형과 가격으로 필터링하고, 정렬한 뒤 첫 번째 결과를 열어서, 계약금을 20%로 바꾸고, 갱신된 예상 월 납입금을 알려줘.
- Expedia 항공권 검색: JFK에서 MIA까지 편도 직항편을 찾아서, 지정한 항공사 중 가장 싼 옵션을 고르고, 탑승객 정보를 입력한 다음, 결제 전에 멈춰줘.
These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.
두 방식 모두 대부분의 작업을 완료했습니다. 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. 우리는 영구적인 법칙을 발견했다고 주장하는 것이 아닙니다. 이는 현재 사용 가능한 모델 및 에이전트 도구를 기반으로 한 특정 시점의 엔지니어링 판단입니다.