🤖 AI

Terminal Agents Suffice for Enterprise Automation

이 논문은 복잡한 에이전트 아키텍처 대신 터미널과 파일시스템만 갖춘 코딩 에이전트가 직접 API 를 호출하여 기업 자동화 작업을 더 효과적으로 수행할 수 있음을 다양한 실증 실험을 통해 입증합니다.

원저자: Patrice Bechard, Orlando Marquez Ayala, Emily Chen, Jordan Skelton, Sagar Davasam, Srinivas Sunkara, Vikas Yadav, Sai Rajeswar

게시일 2026-04-02

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Patrice Bechard, Orlando Marquez Ayala, Emily Chen, Jordan Skelton, Sagar Davasam, Srinivas Sunkara, Vikas Yadav, Sai Rajeswar

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

🍽️ 비유: 레스토랑의 주문 시스템

기업의 업무 시스템 (ServiceNow, GitLab 등) 은 거대한 레스토랑 주방이라고 상상해 보세요. 여기서는 수많은 주문 (업무) 이 들어오고, 주방장 (AI 에이전트) 이 재료를 찾아 요리 (작업) 를 해야 합니다.

논문은 이 주문을 처리하는 세 가지 방식을 비교했습니다.

1. 복잡한 메뉴판 방식 (GUI 에이전트)

상황: 손님이 "스테이크 주세요"라고 하면, 로봇이 실제 주방 문으로 들어가서 벽에 붙은 메뉴판을 보고, 계단을 오르고, 창문을 열고, 주방장에게 손가락으로 가리키며 주문합니다.
문제점: 로봇이 길을 잃거나, 문이 잠겨 있거나, 메뉴판이 바뀌면 주문이 실패합니다. 게다가 이동하는 데 시간과 에너지 (비용) 가 많이 듭니다.
논문 결과: 성공률은 꽤 좋지만, 비용이 너무 비쌉니다. (비행기 표를 끊고 여행하는 것과 같습니다.)

2. 제한된 주문서 방식 (MCP 도구 에이전트)

상황: 로봇에게 미리 작성된 **주문서 (도구 목록)**만 줍니다. "스테이크 주문하기", "샐러드 주문하기" 같은 버튼만 있습니다.
문제점: 손님이 "스테이크에 파슬리 대신 바질을 넣어주세요"라고 하면, 주문서에 '바질' 버튼이 없어서 로봇은 당황합니다. "죄송합니다, 그건 못 해드려요"라고 말하고 끝납니다.
논문 결과: 가장 가성비가 좋지만, 할 수 있는 일이 너무 제한적이라 실패율이 높습니다. (비행기 표는 없는데, 목적지에 갈 수 있는 비행기가 없어서 실패하는 경우.)

3. 직접 전화하는 방식 (터미널 에이전트 - 이 논문의 주인공)

상황: 로봇에게 **주방장에게 직접 전화할 수 있는 전화기 (터미널)**와 **메모장 (파일 시스템)**만 줍니다.
방식: 로봇은 "스테이크 주문합니다. 바질 추가하세요. 그리고 재료가 부족하면 바로 전화하세요"라고 직접 코드로 명령을 내립니다.
장점:
- 유연함: 주문서에 없는 '바질'도 바로 추가할 수 있습니다.
- 빠름: 문으로 뛰어다니지 않고 바로 전화합니다.
- 회복력: 실수가 나면 (예: 전화번호를 잘못 누름), 바로 다시 찾아서 고칩니다.
논문 결과: 성공률은 가장 높거나 비슷하면서, 비용은 가장 저렴했습니다. (택시를 타고 가는 것보다 지하철을 타고 가는 것과 같습니다.)

💡 핵심 발견 3 가지

복잡할수록 나쁘다:
많은 사람들은 "로봇이 더 똑똑해지려면 더 많은 도구와 복잡한 시스템이 필요하다"고 생각합니다. 하지만 이 논문은 **"단순한 전화기 하나면, 잘 훈련된 사람 (AI) 이 복잡한 메뉴판이나 제한된 주문서보다 훨씬 잘한다"**고 증명했습니다.
책 (문서) 이 항상 도움이 되는 건 아니다:
로봇에게 레시피 책 (문서) 을 주면 더 잘할 것 같지만, 책이 너무 두꺼우면 읽는 데만 시간이 걸려서 오히려 주문이 늦어지거나, 책에 적힌 방식이 실제 상황과 달라서 실패하기도 합니다.
- 비유: 요리할 때 매번 두꺼운 요리책을 다 읽으려다 굶어 죽는 상황입니다.
기억력 (스킬) 이 중요:
로봇이 한 번 실수하거나 새로운 방법을 배웠다면, 그걸 메모장에 적어두면 (스킬 축적), 다음에 같은 일을 할 때 훨씬 빠르고 저렴하게 처리할 수 있습니다.
- 비유: "어제 파슬리 넣는 법을 배웠으니, 오늘부터는 바로 그걸 적용하자"라고 메모해두는 것입니다.

🚀 결론: 왜 이것이 중요한가?

이 논문의 결론은 **"기업 자동화를 위해 거창하고 복잡한 시스템을 구축할 필요는 없다"**는 것입니다.

이미 기업 시스템에는 **직접 연결할 수 있는 API(전화선)**가 있습니다. AI 가 이 전화선을 직접 활용하고, 메모장을 잘만 쓴다면, 복잡한 GUI(화면 클릭) 나 제한된 도구 목록을 거치지 않아도 훨씬 더 빠르고, 저렴하고, 똑똑하게 업무를 처리할 수 있습니다.

한 줄 요약:

"복잡한 로봇 팔을 다는 것보다, 똑똑한 사람이 직접 전화기로 주문하는 게 더 빠르고 저렴하다."

이제 기업들은 AI 를 만들 때, 무거운 장비를 쌓아올리는 대신 **단순하고 강력한 연결 (터미널)**에 집중해야 한다는 교훈을 얻게 되었습니다.

논문 요약: 엔터프라이즈 자동화를 위한 터미널 에이전트의 충분성 (Terminal Agents Suffice for Enterprise Automation)

이 논문은 복잡한 에이전트 아키텍처 (GUI 기반 또는 도구 증강형) 가 엔터프라이즈 자동화 작업에 필수적인지, 혹은 단순한 터미널 기반 코딩 에이전트가 더 효율적이고 효과적으로 작동할 수 있는지에 대한 실증적 연구를 수행합니다.

1. 문제 제기 (Problem)

최근 대규모 언어 모델 (LLM) 기반 에이전트가 기업 내 디지털 플랫폼과 상호작용하여 자율적으로 작업을 수행하는 것에 대한 관심이 높아지고 있습니다. 기존 접근 방식은 주로 두 가지 방향으로 진행되었습니다:

GUI 기반 에이전트 (Web Agents): 웹 인터페이스를 통해 DOM 요소나 스크린샷을 분석하여 마우스 클릭, 타이핑 등의 저수준 행동을 수행합니다.
도구 증강형 에이전트 (Tool-augmented Agents): Model Context Protocol (MCP) 과 같은 프레임워크를 통해 사전에 정의된 도구 (API 래퍼) 세트를 호출합니다.

그러나 이러한 복잡한 아키텍처는 높은 비용, 운영 오버헤드, 그리고 인터페이스 변경에 대한 취약성 (GUI) 또는 표현력의 제한 (MCP) 을 초래합니다. 저자들은 **"안정적인 API 가 존재하는 환경에서, 추가적인 추상화 레이어 (GUI 나 MCP) 없이 터미널과 파일시스템만으로도 엔터프라이즈 작업을 해결할 수 있는가?"**라는 가설을 검증하고자 합니다.

2. 방법론 (Methodology)

2.1 StarShell: 터미널 기반 에이전트

저자들은 StarShell이라는 최소한의 터미널 기반 코딩 에이전트를 구현했습니다.

인터페이스: 터미널 (명령어 실행) 과 파일시스템 (아티팩트 저장) 만을 사용합니다.
작동 방식: 사전 정의된 도구를 호출하는 대신, 모델이 직접 플랫폼 API 와 상호작용하기 위해 코드나 스크립트 (예: curl 명령어) 를 작성하고 실행합니다.
지식 확장:
- 문서 접근: 공식 플랫폼 문서를 파일시스템에서 검색하여 API 사용법을 학습합니다.
- 스킬 (Skills) 축적: 이전 작업에서 발견된 해결책, 필드 매핑, 실수 패턴 등을 재사용 가능한 스크립트나 메모로 파일시스템에 저장하여 향후 작업에 활용합니다.

2.2 벤치마크 및 비교 대상

ServiceNow, GitLab, ERPNext 등 3 가지 주요 엔터프라이즈 플랫폼에서 729 개의 실제 업무 태스크로 구성된 통합 벤치마크를 구축했습니다. 세 가지 에이전트 패러다임을 동일한 LLM 백본 (Claude Sonnet/Opus, GPT-5, Gemini) 으로 비교 평가했습니다:

MCP 에이전트: 사전 정의된 도구만 사용.
Web 에이전트: 브라우저 (Playwright) 를 통한 GUI 상호작용.
Terminal 에이전트 (StarShell): 직접적인 API 호출 및 코드 실행.

3. 주요 기여 (Key Contributions)

터미널 에이전트의 우월성 입증: 복잡한 아키텍처 없이도 터미널 기반 에이전트가 GUI 나 MCP 기반 에이전트와 동등하거나 더 높은 성공률을 보이며, 비용은 획기적으로 낮음을 증명했습니다.
통합 벤치마크 구축: 여러 프로덕션급 플랫폼 (ServiceNow, GitLab, ERPNext) 을 아우르는 검증된 평가 환경과 데이터셋을 공개했습니다.
실용적 확장성 연구: 터미널 에이전트에 문서 접근 및 재사용 가능한 '스킬' (Skills) 축적 기능을 추가했을 때의 효과를 분석했습니다.

4. 실험 결과 (Results)

4.1 성능 및 비용 비교 (Table 2)

성공률 (Success Rate): 터미널 에이전트는 Web 에이전트와 동등하거나 더 높은 성공률을 보였습니다 (12 가지 플랫폼-모델 조합 중 7 개에서 최고 또는 동점). 반면, MCP 에이전트는 사용 가능한 도구의 제한으로 인해 성공률이 현저히 낮았습니다 (ServiceNow 에서 11~16% 수준).
비용 (Cost): 터미널 에이전트는 Web 에이전트보다 5 배 이상 저렴했습니다.
- 예: ServiceNow 에서 Claude Opus 4.6 기준, Web 에이전트는 태스크당 $4.21 이 들었으나 터미널 에이전트는$ 1.94 로 약 2 배 이상 저렴했습니다.
- ERPNext 에서는 Web 에이전트가 $6.49, 터미널 에이전트가$ 0.72 로 9 배의 비용 차이가 발생했습니다.

4.2 문서 및 스킬의 영향

문서 접근: 플랫폼에 따라 효과가 달랐습니다. ServiceNow 의 경우 문서가 오히려 비용을 증가시키고 성능을 저하시켰으나 (문서 구조가 API 와 불일치), ERPNext 에서는 도움이 되었습니다. 이는 에이전트가 내재된 지식이나 API 탐색 능력만으로도 대부분의 작업을 수행할 수 있음을 시사합니다.
스킬 (Skills) 축적: 반복 작업을 통해 스킬을 축적한 에이전트는 성공률이 향상되었고 비용이 감소했습니다. 특히 ERPNext 와 같이 덜 알려진 플랫폼에서 효과가 컸으며, 불필요한 API 탐색을 줄여 비용을 16~43% 절감했습니다.

4.3 실패 원인 분석

터미널 에이전트의 실패는 주로 API 호출 오류가 아니라, 브라우저 세션이 필요한 작업 (예: 사용자 위임, UI 기반 워크플로우 편집기 조작) 이나 렌더링된 UI 요소 추출 (차트 값 읽기) 에서 발생했습니다. 이는 터미널 에이전트만으로는 해결할 수 없는 플랫폼의 구조적 한계를 보여줍니다.

5. 의의 및 결론 (Significance & Conclusion)

이 연구는 엔터프라이즈 자동화 분야에서 **"복잡한 에이전트 스택이 반드시 필요한 것은 아니다"**라는 중요한 통찰을 제공합니다.

간단함이 강력함: 강력한 기반 모델 (Foundation Models) 과 직접적인 프로그래밍 인터페이스 (API) 만으로도 복잡한 GUI 나 사전 정의된 도구 레지스트리 없이도 대부분의 기업 작업을 효율적으로 수행할 수 있습니다.
비용 효율성: 터미널 기반 접근법은 UI 렌더링 오버헤드를 제거하여 비용을 대폭 절감하면서도 높은 유연성을 유지합니다.
미래 방향: 완전한 자동화를 위해서는 터미널 에이전트와 브라우저 에이전트의 하이브리드 접근법이 필요할 수 있습니다. 즉, 데이터 조작은 터미널 (API) 로, UI 상호작용이 필수적인 작업은 브라우저로 처리하는 방식으로 각자의 강점을 활용해야 합니다.

결론적으로, 기업들은 새로운 복잡한 에이전트 아키텍처를 구축하기 전에, 플랫폼이 제공하는 안정적인 API 와 강력한 LLM 을 활용한 경량화된 터미널 에이전트 접근법을 먼저 고려해야 합니다.