유닉스 명령어를 사용하는 단일 run() 도구가 AI 에이전트에 함수 호출보다 우수한 이유

2년간 AI 에이전트를 구축한 경험을 가진 개발자—처음에는 Manus의 백엔드 리드로, 이후 오픈소스 프로젝트 Pinix와 agent-clip에서—는 유닉스 스타일 명령어를 사용하는 단일 run(command="...") 도구가 전통적인 함수 호출 접근법보다 더 잘 작동한다고 결론지었습니다.

유닉스-LLM 융합

핵심 통찰은 유닉스의 50년 된 설계 결정—모든 것이 텍스트 스트림이라는 점—이 LLM의 텍스트 기반 본질과 완벽하게 일치한다는 것입니다. 유닉스 프로그램은 텍스트 파이프를 통해 통신하고, --help를 사용해 자기 설명을 제공하며, 종료 코드로 성공/실패를 보고하고, stderr를 통해 오류를 전달합니다. LLM 역시 텍스트 토큰만 이해합니다. 이는 유닉스의 텍스트 기반 인터페이스를 LLM에 자연스럽게 맞추어 주며, LLM은 본질적으로 학습 데이터에서 셸 명령어에 광범위하게 노출된 터미널 운영자 역할을 합니다.

단일 도구 접근법

대부분의 에이전트 프레임워크는 LLM에 [search_web, read_file, write_file, run_code, send_email, ...]와 같은 독립적인 도구 카탈로그를 제공하여, LLM이 각 호출 전에 도구 선택 결정을 내리도록 요구합니다. 더 많은 도구가 추가될수록, 인지 부하가 "무엇을 달성해야 하는가?"에서 "어떤 도구를 사용해야 하는가?"로 이동하면서 선택 정확도가 떨어집니다.

대안적 접근법은 모든 기능을 CLI 명령어로 노출하는 하나의 run(command="...") 도구를 사용합니다:

run(command="cat notes.md")
run(command="cat log.txt | grep ERROR | wc -l")
run(command="see screenshot.png")
run(command="memory search 'deployment issue'")
run(command="clip sandbox bash 'python3 analyze.py'")

명령어 선택은 관련 없는 API 간의 컨텍스트 전환이 아닌, 통합된 네임스페이스 내의 문자열 구성이 됩니다.

CLI 명령어가 더 잘 작동하는 이유

CLI 명령어는 LLM 학습 데이터에서 가장 밀도 높은 도구 사용 패턴으로, GitHub의 수십억 줄의 코드(README 설치 지침, CI/CD 빌드 스크립트, Stack Overflow 솔루션)에 나타납니다. 개발자는 "LLM에게 CLI 사용법을 가르칠 필요가 없습니다—이미 알고 있기 때문입니다"라고 언급합니다.

동일한 작업에 대한 접근법을 비교해 보세요:

작업: 로그 파일을 읽고 오류 줄 수 세기

함수 호출 접근법 (3번의 도구 호출):
1. read_file(path="/var/log/app.log") → 전체 파일 반환
2. search_text(text=<전체 파일>, pattern="ERROR") → 일치하는 줄 반환
3. count_lines(text=<일치하는 줄>) → 숫자 반환

CLI 접근법 (1번의 도구 호출):
run(command="cat /var/log/app.log | grep ERROR | wc -l") → "42"

유닉스 파이프가 기본적으로 구성을 지원하기 때문에 한 번의 호출이 세 번을 대체합니다. 개발자는 이것이 특별한 최적화가 아니라 유닉스의 기존 설계를 활용하는 것임을 강조합니다.