엔터프라이즈 자동화를 위한 터미널 에이전트의 충분성 연구

기존의 복잡한 GUI 기반 에이전트나 도구 증강 에이전트보다 터미널과 파일 시스템만 사용하는 단순한 코딩 에이전트가 실제 기업 업무 자동화에 더 효율적임을 입증했다. 이를 통해 에이전트 설계의 복잡성을 낮추면서도 비용은 획기적으로 줄이고 성공률은 높일 수 있는 새로운 실무적 방향성을 제시한다.

기존 에이전트 연구는 사람이 웹사이트를 이용하듯 화면을 보고 클릭하는 GUI 방식이나, 미리 정의된 도구 목록(MCP)을 사용하는 방식에 집중해왔다. 하지만 GUI는 구조가 조금만 바뀌어도 에이전트가 길을 잃기 쉽고, 도구 목록은 복잡한 기업용 시스템의 모든 기능을 담아내기에 표현력이 부족하다는 한계가 있다.

이 논문은 LLM이 직접 코드를 작성해 시스템 API와 통신하는 '터미널 에이전트'가 가장 강력한 해결책이라고 본다. 이는 숙련된 개발자가 복잡한 웹 메뉴를 일일이 클릭하는 대신 터미널에서 curl 명령어로 서버와 직접 통신하며 작업을 완수하는 것과 같은 원리이다. LLM은 텍스트 기반의 API 응답을 훨씬 더 정확하게 이해하며, 실패하더라도 코드를 수정해 다시 시도하는 REPL 루프를 통해 문제를 해결한다.

결과적으로 불필요한 시각적 정보나 추상화 계층을 제거함으로써 에이전트는 더 적은 토큰으로 더 정확하게 작업할 수 있게 된다. 특히 파일 시스템을 메모리처럼 활용해 과거의 성공 경험을 저장하고 재사용하는 방식은 에이전트가 작업을 거듭할수록 더 효율적으로 진화하게 만든다.

실험을 위해 GUI 기반 웹 에이전트, MCP 기반 도구 증강 에이전트, 그리고 터미널 기반 코딩 에이전트인 StarShell을 동일한 LLM 백본에서 비교 분석했다. StarShell은 Bash 명령어 실행 권한과 파일 시스템 접근 권한만 부여받으며, 모든 작업은 직접적인 API 호출을 통해 수행된다.

에이전트는 [작업 설명 수신 → 계획 수립 → 명령어 실행 → 결과 관찰 → 반복]의 REPL 루프를 수행한다. 특히 쉘 이스케이프 오류를 방지하기 위해 복잡한 JSON 페이로드를 임시 파일에 작성한 후 @file 인자를 사용해 전송하는 전략을 사용한다. 성공률(SR)은 [성공한 작업 수 / 전체 작업 수]로 계산되어 에이전트의 완수 능력을 측정하며, 추론 비용은 [사용된 토큰 수 * 가격]으로 합산되어 경제성을 평가한다.

지속성 있는 메모리 구현을 위해 'Skills' 디렉토리를 도입했다. 에이전트가 특정 작업을 성공하면 그 절차와 비직관적인 API 필드 매핑 정보를 마크다운 파일로 기록한다. 이후 새로운 작업이 주어지면 grep 등을 통해 관련 스킬을 검색하고, 이를 바탕으로 탐색 과정을 생략한 채 즉시 실행 계획을 수립한다.

터미널 에이전트는 12개 플랫폼-모델 조합 중 7개에서 가장 높은 성공률을 기록했다. 특히 ServiceNow 환경에서 Gemini 3.1 Pro 기반 터미널 에이전트는 78.5%의 성공률을 달성하며 다른 패러다임을 압도했다. 비용 측면에서는 웹 에이전트 대비 5~9배 저렴한 것으로 나타났는데, 이는 대규모 접근성 트리나 스크린샷 처리 없이 텍스트 기반 API 응답만 처리하기 때문이다.

'Skills' 메커니즘을 적용했을 때 ServiceNow 환경에서 작업당 평균 비용이 $0.78에서$0.44로 약 43.7% 감소하는 성과를 보였다. 이는 에이전트가 과거에 발견한 API 엔드포인트나 필드 정보를 재활용함으로써 불필요한 탐색 호출을 획기적으로 줄였음을 의미한다.

문서 활용 실험에서는 ERPNext와 같이 작업 중심(Task-oriented)으로 구성된 문서는 에이전트의 성공률을 높였으나, ServiceNow와 같이 웹 UI 참조 중심(Reference-oriented)인 문서는 오히려 에이전트가 불필요한 정보를 읽게 만들어 비용만 높이고 성능을 저해하는 결과를 낳았다.

StarShell 아키텍처는 최소한의 추상화를 통해 LLM의 일반적인 코딩 능력을 엔터프라이즈 API 조작으로 전이시킨다. 기존의 MCP 방식이 정적인 도구 정의에 갇혀 API의 전체 기능을 활용하지 못하는 것과 달리, 터미널 에이전트는 런타임에 API 응답을 분석하여 동적으로 쿼리 파라미터를 구성하고 복잡한 데이터 변환을 수행할 수 있다.

연구진은 에이전트가 생성하는 'Skills'가 단순한 코드 조각이 아니라, UI 레이블과 API 필드 간의 비직관적인 매핑 정보나 쉘 쿼팅 이슈와 같은 인프라 수준의 교훈을 포함하고 있음을 확인했다. 예를 들어 ERPNext에서 so_required=1이 'Sales Order 없이 송장 생성 허용'이라는 반직관적인 의미를 가진다는 사실을 에이전트가 스스로 발견하고 기록하여 이후 작업의 오류를 방지한다.

또한 단일 에이전트와 플래너-실행자(Planner-Executor) 다중 에이전트 구조를 비교한 결과, 모델의 능력이 높을수록 단일 에이전트가 더 효율적이며 다중 에이전트 구조는 주로 모델의 추론 한계를 보완하는 역할을 수행한다는 기술적 통찰을 제시했다.

웹 브라우저 세션 쿠키가 필수적인 기능(예: ServiceNow의 사용자 가장 기능)이나 API로 노출되지 않는 복잡한 UI 전용 작업(예: 드래그 앤 드롭 워크플로우 에디터)은 수행할 수 없다. 또한 차트나 시각적 대시보드에서 정보를 추출해야 하는 시각적 이해가 필요한 작업에서도 한계가 명확하다.