에이전트에 bash만 주면 어떻게 되는가 — 타입 도구를 더해도 점수는 오르지 않았습니다

1. 핵심 요약

용어를 먼저 정합니다. 타입 도구는 이름·설명·JSON 스키마로 정의된 함수를 모델이 하나씩 호출하는 방식입니다. MCP(Model Context Protocol) 서버가 내보내는 도구가 대표적입니다. 셸 인터페이스는 에이전트에 bash 같은 셸 하나만 주고, 파일 조작·API 호출·데이터 처리를 전부 명령과 스크립트로 하게 하는 방식입니다. 프로그램형 도구 호출은 모델이 타입 도구를 함수처럼 부르는 프로그램을 작성하고, 그 프로그램이 컨테이너 안에서 여러 도구를 연속으로 실행한 뒤 결과만 돌려주는 방식입니다. Anthropic은 코드 실행 컨테이너에서 Python으로, OpenAI는 격리된 JavaScript 런타임에서 같은 이름의 API 기능으로 제공합니다. [5] [8]

이 글의 수치는 논문 표에 인쇄된 값입니다. 백분율 차이(%p)는 두 비율의 차이를 뜻하고, 절감 비율은 이 글이 표의 값으로 나눈 파생값이며 그렇게 표시했습니다. 논문은 Microsoft Copilot Studio 팀의 지원을 받은 Microsoft 소속 연구이고, 논문 서론은 Copilot Studio를 GitHub Copilot CLI·SDK를 쓰는 셸 기반 제품으로 분류합니다. 여기서 하네스는 모델을 반복 호출하며 도구를 연결하는 에이전트 실행 루프를 뜻합니다. 이 이해관계는 10절에 다시 적었습니다.

2. 비교한 다섯 가지 인터페이스

논문은 모델·과제 문장·기본 프롬프트·종료 조건을 고정한 채 도구 인터페이스만 바꿨습니다. Bash+Synthesis 조건과 프로그램형 도구 호출 조건에만 각 인터페이스를 쓰는 방법을 설명하는 안내 문장이 추가됩니다. [1]

세 번째 열은 논문 원문이 아니라, 이 글이 실무에서 비슷한 구성으로 볼 수 있는 예를 붙인 것입니다. 논문은 이 다섯 가지를 두 축으로 설명합니다. 셸은 임의 코드 실행을 허용해 한 단계에 여러 행동을 할 수 있지만 실행과 접근을 통제해야 하고, 승인된 도구 목록은 배포자가 허용한 함수만 노출하지만 하나씩 부를 때 비용이 붙습니다. 프로그램형 도구 호출은 그 사이에 있습니다. 도구 호출은 프로그램으로 연결·반복·병렬화하지만, 실행 환경에서 할 수 있는 작업은 승인된 도구 목록 안으로 제한합니다. [1]

3. 무엇을 어떻게 측정했는가

점수의 뜻이 벤치마크마다 다릅니다. TheAgentCompany의 점수는 난이도를 반영한 체크포인트 달성률이고, APEX-Agents의 점수는 채점 기준을 충족한 비율의 평균이며 LLM 기반 채점기가 매깁니다. 통과율은 과제를 완전히 해낸 비율입니다. 두 벤치마크의 점수를 서로 비교하면 안 되고, 같은 벤치마크 안에서 인터페이스끼리만 비교해야 합니다. [1]

4. 결과 ① 점수·토큰·비용

아래는 논문 표 1의 값입니다. 토큰은 과제당 평균 총 토큰(입력+출력, 캐시 읽기 포함)이고, 비용은 과제당 추정 추론 비용입니다. [1]

Bash+Tool과 Bash+Synthesis 행은 5절에 따로 실었습니다. 점수의 95% 신뢰구간은 논문 표에 있으며 폭은 대체로 ±6%p(TheAgentCompany)와 ±4%p(APEX-Agents)입니다.

세 가지가 읽힙니다.

• 점수 차이는 벤치마크에 따라 크기가 달랐습니다. TheAgentCompany에서 bash 단독은 타입 도구보다 21.8~24.5%p 높았고, 통과율은 두 배 가까이 됐습니다(24.1%→50.6%, 25.3%→47.7%). APEX-Agents에서는 4.8~7.4%p로 차이가 작았습니다. 논문은 유연한 실행이 코딩과 서비스 간 이동에는 크게 도움이 되지만 전문 분야 추론에는 덜 도움이 된다고 해석합니다.
• 토큰은 19~72% 적게 썼습니다. 가장 큰 차이는 TheAgentCompany의 Opus-4.8로 945k에서 264k로 줄었습니다(이 글의 계산으로 72.1% 절감). 가장 작은 차이는 같은 벤치마크의 GPT-5.5로 465k에서 377k입니다(18.9% 절감). APEX-Agents는 두 모델 모두 46% 정도 줄었습니다. 비용도 같은 방향이지만 폭은 더 작습니다(15~69%, 이 글의 파생값).
• 시간은 한 방향이 아닙니다. Opus-4.8은 TheAgentCompany에서 bash가 더 빨랐지만(5.1분→3.0분), GPT-5.5는 타입 도구 단독이 가장 빨랐습니다(1.8분 대 2.6분). 지연이 중요한 곳에서는 토큰과 시간을 따로 봐야 합니다.

논문의 부록은 이 결과를 같은 과제·같은 모델 조건끼리 묶어 다시 계산했습니다. TheAgentCompany에서 bash 단독과 타입 도구 단독의 차이는 348쌍 평균 +24.6%p(95% 신뢰구간 +20.6~+29.0)이고, APEX-Agents에서는 960쌍 평균 +6.2%p(+3.6~+8.7)입니다. 두 구간 모두 0을 포함하지 않습니다. 분야별로 보아도 모든 분야에서 Bash ≥ Bash+Tool ≥ Tool-only 순서가 유지됐고, 격차는 소프트웨어 엔지니어링에서 가장 컸으며 기업 법무에서 가장 작았습니다. [1]

5. 결과 ② 셸에 도구를 더하면

셸이 있는 코딩 에이전트에 MCP 서버를 붙이면, 셸 위에 타입 도구를 더한 구성이 됩니다. 논문의 Bash+Tool이 이 구성입니다. 결과는 같은 과제·같은 모델 조건끼리 묶어 비교한 표에 있습니다. [1]

네 비교 모두 신뢰구간이 0을 포함합니다. 논문 표현을 풀어 쓰면, 측정 결과에서 확인할 수 있는 점수 향상은 없었습니다. 대신 토큰은 대체로 늘었습니다. TheAgentCompany의 Opus-4.8에서 Bash는 264k, Bash+Tool은 569k였습니다. 예외는 같은 벤치마크의 Bash+Synthesis(249k)로, 이것이 논문이 적은 유일한 토큰 감소 사례입니다. [1]

왜 도구를 더해도 나아지지 않았는지에 대한 단서가 셸 사용 통계에 있습니다. 타입 도구가 함께 있으면 에이전트는 셸을 덜 쓰는데, 남은 셸 호출의 실패율은 오히려 높고 실패 직후 같은 명령으로 다시 시도하는 비율은 낮았습니다. TheAgentCompany에서 Bash 단독의 셸 호출 실패율은 7.9%, 실패 후 즉시 재시도율은 76.3%였고, Bash+Tool은 각각 10.8%와 58.7%였습니다. 논문은 이를 "셸 사용을 줄이되 남은 셸 호출의 신뢰성은 개선하지 않는다"고 요약합니다. [1]

에이전트가 스스로 도구를 만들어 쌓는 Bash+Synthesis도 마찬가지였습니다. 만든 도구의 대부분을 실제로 쓰긴 했지만(Opus-4.8 기준 TheAgentCompany 21개 중 19개), 나중 과제에서 다시 쓴 비율은 절반 안팎이었고(21개 중 12개), 합성 도구를 호출한 과제와 그렇지 않은 과제 사이에 점수 차이가 없었습니다. 재사용 도구의 호출 성공률이 새로 쓴 코드보다 높지도 않았습니다. [1]

6. 결과 ③ 프로그램형 도구 호출

프로그램형 도구 호출은 "도구 목록은 유지하되 호출 비용은 줄이자"는 답입니다. Anthropic 문서는 이 방식이 모델을 거치는 왕복을 줄여 지연과 토큰을 낮추고, 데이터를 모델 컨텍스트에 넣기 전에 프로그램 안에서 걸러낼 수 있다고 설명합니다. 자체 측정에서 BrowseComp·DeepSearchQA 벤치마크의 성능이 평균 11% 오르고 입력 토큰이 24% 줄었다는 수치도 적혀 있습니다. 벤치마크는 외부 것이지만 측정은 개발사가 한 것입니다. [5] 논문이 함께 인용한 2026년 8월의 독립 연구는 BFCL v4 벤치마크에서 14개 모델 중 11개에서 프로그램형 호출이 JSON 호출과 같거나 나았다고 보고했습니다. [6]

이 논문의 측정 결과를 보면, 프로그램형 도구 호출이 항상 더 낫다는 설명은 범위를 좁혀 읽어야 합니다. 타입 도구 단독과 비교하면 프로그램형 호출은 토큰을 확실히 아꼈습니다. 같은 과제·모델끼리 묶은 비교에서 캐시되지 않은 입력 토큰이 TheAgentCompany에서 과제당 97.6k, APEX-Agents에서 45.4k 줄었습니다. 그러나 점수는 TheAgentCompany에서만 올랐고(묶은 평균 +3.5%p, 신뢰구간 +0.8~+6.2), APEX-Agents에서는 −1.5%p로 구간이 0을 포함합니다. 그리고 두 벤치마크 모두에서 프로그램형 호출은 셸 단독보다 낮았습니다. 셸 단독 점수가 TheAgentCompany에서는 21.2%p, APEX-Agents에서는 7.7%p 더 높았습니다. [1]

논문 표 2에서 세 인터페이스만 옮겼습니다. 성공률은 호출이 성공을 보고한 비율이고, 반복률은 한 과제 안에서 도구와 인자가 완전히 같은 호출이 반복된 비율입니다.

프로그램형 호출의 도구 호출 성공률은 두 벤치마크 모두에서 가장 낮았습니다. TheAgentCompany에서 65.2%로, 다른 인터페이스의 90% 안팎과 차이가 큽니다. 논문은 생성된 프로그램 안에서 여러 호출을 조율하고 중간 실패를 처리하는 어려움이 더해진 것으로 봅니다. 실패 유형 분석에서도 프로그램형 호출은 최종 메시지가 잘리는 비율이 가장 높았습니다. 반대로 타입 도구 단독은 같은 호출을 반복하는 비율이 16.2%로 가장 높았습니다. 셸이나 프로그램은 반복 작업을 한 번의 호출에 묶을 수 있지만 타입 도구는 반복마다 호출이 나가기 때문이라는 해석입니다. [1]

논문의 권고를 그대로 옮기면 이렇습니다. 임의 실행을 격리할 수 있으면 셸 단독을, 보안·규정상 승인된 도구 목록으로 행동을 제한해야 하면 프로그램형 도구 호출을 택하라는 것입니다. 후자는 점수에서 셸에 밀리고 비용 대비 점수에서도 밀리지만(원시 비용만 보면 TheAgentCompany의 GPT-5.5에서 $0.54 대 $0.56으로 근소하게 낮은 조합이 하나 있습니다), 에이전트가 할 수 있는 행동을 승인된 도구 목록 안으로 제한할 수 있다는 통제 이점이 있습니다. [1]

7. 왜 차이가 났는가 — 실패 유형과 셸 사용 패턴

논문은 실패한 실행 기록을 LLM 기반 채점기로 14가지 원인에 분류했습니다. 실패 유형은 인터페이스보다 벤치마크에 따라 더 크게 달랐습니다. APEX-Agents의 실패는 다섯 인터페이스 모두에서 요구 사항 누락, 분야 규칙·정의의 잘못된 적용, 숫자·형식 오류에 몰렸습니다. TheAgentCompany에서는 인터페이스별 차이가 보였습니다. 타입 도구 단독은 결과물을 끝내지 못하거나 환경·접근 오류로 실패하는 경우가 가장 많았고, 셸 기반 인터페이스는 검증 없이 완료를 선언하는 실패가 가장 많았습니다. [1]

셸을 어떻게 썼는지도 기록돼 있습니다. 두 벤치마크에서 셸의 쓰임이 달랐습니다.

논문 표 3의 Bash 행입니다. 명령 수는 내장 코드와 반복 횟수를 제외한 정적 명령 개수입니다.

TheAgentCompany에서는 짧은 호출에 여러 명령을 이어 붙였고 텍스트 유틸리티와 HTTP 클라이언트(curl 등)가 많았습니다. APEX-Agents에서는 열두 줄짜리 내장 프로그램, 대개 Python을 셸 안에서 실행했습니다. 논문은 이를 "셸은 유틸리티 기반 워크플로와 파일 분석을 모두 지원할 수 있다"고 정리합니다. 모델에 따라 문법도 달랐습니다. GPT-5.5는 여러 줄 입력에 heredoc을 훨씬 많이 썼고(APEX-Agents Bash 단독에서 82.7% 대 Opus-4.8 16.8%), Opus-4.8은 &&·|| 연결을 더 썼습니다. [1]

정리하면, 이 논문에서 셸이 앞선 이유는 "모델이 bash를 잘 안다"보다 구체적입니다. 반복 작업을 한 호출에 묶고, 중간 결과를 컨텍스트에 넣지 않고 처리하고, 실패하면 같은 명령을 바로 고쳐 다시 시도하는 행동이 셸 인터페이스에서 자연스럽게 나왔습니다. 타입 도구는 이 세 가지를 각각 별도 호출과 별도 모델 왕복으로 만듭니다. 이것이 토큰 차이의 기계적 원인이고, 컨텍스트가 짧게 유지되는 것이 점수 차이의 한 경로일 수 있습니다. 마지막 문장은 이 글의 추론이며 논문은 인과를 확정하지 않았습니다.

8. MCP 서버는 현장에서 얼마나 살아 있는가

타입 도구 논쟁의 다른 한쪽에는 "MCP 서버가 실제로 얼마나 쓸 만한가"라는 질문이 있습니다. 같은 주에 공개된 별도의 측정이 있습니다. 독립 연구자 한 명이 쓴 프리프린트라는 점을 먼저 적습니다. [2]

이 연구는 MCP 레지스트리 24,135개 서버를 전수 조사한 뒤, npm으로 배포되고 표준 입출력으로 통신하는 서버 중 400개를 공개된 시드로 무작위 추출해 각각 한 번씩 접속을 시도했습니다. 고치지도 않고 자격 증명도 넣지 않은 상태 그대로입니다. 결과는 아래와 같습니다.

절반(51.2%)이 초기화 핸드셰이크를 마치지 못했고, 그 원인은 흔히 생각하는 자격 증명 부족(13.3%)이 아니라 서버가 아예 뜨지 않는 것(37.5%)이 세 배 가까이 많았습니다. 논문의 표현으로는 "공개된 항목 다섯 중 둘 정도가 작동하지 않는 상태"입니다. 같은 도구로 참조 서버와 인기 서버 24개를 골라 잰 선별 표본에서는 66.7%가 시작했습니다. 저자는 이 17.9%p 차이를 "선별이 만드는 효과의 크기"라고 부릅니다. 시작한 195개 서버가 내보낸 2,766개 도구에서 JSON 스키마의 치명적 위반은 하나도 없었지만, 도구가 읽기 전용인지 파괴적인지 알려 주는 선택적 안전 주석은 58.8%의 도구에 없었습니다. 서버 단위로는 전부 달거나 전부 안 다는 양극이었습니다. [2]

이 측정의 범위도 좁습니다. npm·표준 입출력 서버만 봤고 이는 레지스트리의 30.7%입니다. 원격 서버와 PyPI·컨테이너 패키지는 표본에 없습니다. 접속은 재시도 없이 한 번이라 일시 장애도 실패로 셌고, 저자 스스로 48.8%를 "시작할 수 있는 서버 비율의 하한"이라고 적었습니다. 그래도 방향은 분명합니다. 레지스트리에서 서버를 골라 붙이는 일은 고르는 사람의 선별 작업이 결과를 좌우하며, 붙인 도구가 안전한지는 절반 이상에서 도구 자체가 알려 주지 않습니다. [2]

7절의 결과와 이어 읽으면, 타입 도구를 붙이는 일에는 두 종류의 비용이 따로 있습니다. 붙였을 때 점수가 오르지 않는 비용(이 논문의 측정)과, 붙일 만한 것을 고르고 검증하는 비용(레지스트리 측정)입니다. MCP의 보안 통제 문제는 코딩 에이전트 보안 리포트에서 따로 다뤘습니다.

9. 오늘 적용할 체크리스트

• 붙여 둔 타입 도구 중 셸로도 할 수 있는 것을 셉니다. 파일 읽기·쓰기, HTTP API 호출, 텍스트 검색처럼 curl·jq·Python으로 대체되는 도구가 그 대상입니다. 이 논문의 도구 목록은 이런 종류로 구성돼 있었고 그 목록을 통째로 더했을 때 점수 이득이 없었습니다. 도구 종류별 효과는 따로 측정되지 않았습니다.
• 셸에서 닿을 수 없는 도구만 남깁니다. 인증 토큰을 에이전트에 줄 수 없는 사내 시스템, 셸이 없는 실행 환경, 승인된 행동만 허용해야 하는 작업입니다. 이 경우는 논문의 실험 범위 밖이므로 결과를 적용하지 않습니다.
• 셸을 주기로 했으면 격리부터 갖춥니다. 논문의 셸도 파일 시스템 제한·환경변수 제거·실행 제한이 걸린 것이었고, 개발 중에 채점 스크립트를 읽는 보상 해킹이 있었습니다. 격리 방식은 샌드박스 리포트에서 다뤘습니다.
• 승인 목록이 정책상 필요하면 프로그램형 도구 호출을 먼저 시험합니다. 타입 도구 단독보다 토큰이 확실히 줄었습니다. 다만 호출 성공률이 가장 낮았으므로 프로그램 안의 실패 처리를 로그로 확인해야 합니다.
• 점수·토큰·시간을 따로 잽니다. GPT-5.5는 타입 도구 단독이 가장 빨랐습니다. 토큰이 줄었다고 지연도 줄었다고 가정하지 않습니다.
• 레지스트리에서 MCP 서버를 고를 때 세 가지를 확인합니다. 자격 증명 없이 실제로 시작하는가, 도구에 안전 주석(readOnlyHint·destructiveHint)이 달려 있는가, 그 도구가 셸로 대체되는 기능은 아닌가.
• "검증 없이 완료 선언"을 감시합니다. 셸 기반 인터페이스의 가장 흔한 실패 유형이었습니다. 결과물을 실제로 확인하는 단계를 프롬프트나 하네스에 둡니다.

10. 아직 결론이 아닌 것

• 개발사 소속 연구입니다. 저자 전원이 Microsoft 소속이고 Copilot Studio 팀의 지원을 받았으며, 논문 서론 자신이 Copilot Studio를 GitHub Copilot CLI·SDK를 쓰는 셸 기반 제품으로 분류합니다. 실험 하네스도 GitHub Copilot SDK입니다. 결과가 자사 제품 방향과 일치합니다. 데이터가 틀렸다는 뜻이 아니라, 독립 재현이 있기 전까지 그 사실을 함께 읽어야 한다는 뜻입니다.
• 동료 심사 전 프리프린트입니다. 2026년 9월 10일 공개, AAAI 2027 양식입니다.
• 모델은 두 종뿐입니다. Opus-4.8과 GPT-5.5, 기본 추론 강도입니다. 논문 자신도 "이후 릴리스에는 권고가 이어지지 않을 수 있다"고 적었습니다. 작은 모델이나 오픈 모델에서 셸 단독이 같은 결과를 내는지는 측정되지 않았습니다.
• TheAgentCompany의 타입 도구 60개는 저자들이 직접 만들었습니다. 벤치마크에 공식 목록이 없었기 때문입니다. 도구 설명과 스키마의 품질이 타입 도구 조건의 성적에 영향을 줄 수 있고, 이 영향의 크기는 측정되지 않았습니다.
• APEX-Agents의 셸은 MCP 서버였습니다. 벤치마크가 제공하는 코드 실행 서버를 셸로 썼습니다. 그래서 이 논문은 "MCP 대 bash"의 비교가 아니라 "셸 하나 대 타입 도구 목록"의 비교입니다. 셸을 MCP로 전달하는지 여부는 실험 변수가 아니었습니다.
• 절대 점수는 공개 리더보드와 비교할 수 없습니다. APEX-Agents 리더보드는 최대 추론 강도와 최신 서버 구성을 쓰고, 이 논문은 기본 추론 강도와 6월 5일 시점 구성을 썼습니다. TheAgentCompany는 동료 시뮬레이션의 결함을 저자들이 수정한 판입니다.
• 비용은 정가 추정입니다. GitHub Copilot 정가 기준 계산이며 실제 청구액이나 다른 제공자의 요금이 아닙니다.
• 과제 복잡도 분석은 근거가 약합니다. 논문 자신이 프로그램형 호출의 신뢰구간이 대부분 구간에서 0을 포함하고, 타입 도구 호출 수는 복잡도의 불완전한 대리 지표라고 한정했습니다.
• 7절 마지막 문단의 인과 설명은 이 글의 추론입니다. 논문은 토큰 차이의 기계적 원인은 설명하지만, 그것이 점수 차이의 원인이라고 확정하지 않았습니다.
• MCP 레지스트리 측정은 단독 저자 프리프린트이고 범위가 좁습니다. npm·표준 입출력 서버(레지스트리의 30.7%)만, 재시도 없이 한 번 접속한 결과입니다. 저자도 48.8%를 하한으로 적었습니다. 두 논문은 저자·방법·질문이 다르며, 이 글이 나란히 놓은 것입니다.
• 이 글은 자체 측정을 하지 않았습니다. 두 프리프린트의 LaTeX 원본과 개발사 문서를 대조한 정리입니다.

11. 참고자료

모두 2026-09-15 확인했습니다. [1]과 [2]는 arXiv의 LaTeX 원본을 받아 표와 부록을 직접 대조했습니다. 제품 문서와 개발사 블로그는 제공사의 설명이며 독립 실험이 아닙니다. [7]은 논쟁의 맥락을 보여 주는 2차 자료입니다. [8]은 참고자료 표 순서상 [7] 앞에 두었습니다.

편집 기준: 논문의 표에 인쇄된 값만 수치로 옮기고, 이 글이 나눈 절감 비율은 파생값으로 표시했습니다. 개발사 소속 연구라는 이해관계와 "셸이 MCP 서버로 전달됐다"는 구성 사실을 결론보다 먼저 독자가 볼 수 있게 두었습니다.