AI 에이전트가 할 수 있는 일은 매일 늘어나고 있습니다. 근데 에이전트가 실제로 기존 소프트웨어를 조작하려고 하면, 이야기가 달라집니다.
Photoshop에서 레이어를 합치고, Blender에서 렌더링을 걸고, LibreOffice에서 PDF를 뽑는 작업 — 사람은 마우스 몇 번이면 되지만, AI 에이전트에게는 넘기 어려운 벽이에요. GUI를 스크린샷으로 읽고, 좌표를 계산해서 클릭하는 방식? 느리고 부서지기 쉽습니다.
CLI-Anything은 이 문제에 대한 답을 하나 내놨습니다. 기존 소프트웨어를 통째로 다시 만들지 않고, CLI 레이어를 덧입혀서 에이전트가 다룰 수 있게 하자. 새로운 AI 앱을 만드는 게 아니라, 이미 있는 앱을 에이전트 언어로 번역하자는 겁니다.
Agent-Software Gap — 에이전트는 왜 기존 프로그램을 못 쓸까?
AI 에이전트는 추론은 잘합니다. 근데 실제 프로페셔널 소프트웨어를 쓰는 건 못합니다. CLI-Anything의 GitHub README는 이걸 **”Agent-Software Gap”**이라고 부릅니다.
현재 이 격차를 메우는 방법은 세 가지인데, 전부 한계가 있어요.
| 접근 방식 | 설명 | 한계 |
|---|---|---|
| GUI 자동화 | 스크린샷 + 좌표 클릭 | 느리고 불안정, UI 변경에 취약 |
| API 연동 | 소프트웨어 공식 API 호출 | API가 없거나 기능의 10%만 커버 |
| 재구현 | AI용으로 기능을 새로 만듦 | 원본 기능의 대부분을 놓침 |
GUI 자동화는 대표적으로 Anthropic의 Computer Use 같은 접근입니다. 에이전트가 화면을 보고, 마우스를 움직이고, 클릭합니다. 사람처럼요. 근데 문제가 있습니다. 화면이 바뀌면 깨집니다. 버튼 위치가 달라지거나, 팝업이 뜨거나, 해상도가 바뀌면 동작이 멈춰요. 멀티스텝에서 에러가 누적되면 성공률이 급격히 떨어집니다.
API 연동은 안정적이지만, 대부분의 데스크톱 소프트웨어는 API를 제공하지 않습니다. 제공하더라도 전체 기능의 일부만 접근 가능합니다. Premiere Pro의 영상 편집 기능 중 API로 쓸 수 있는 게 얼마나 될까요?
재구현은 가장 비용이 큽니다. 원본 소프트웨어의 기능을 AI 친화적으로 다시 만드는 건, 결국 소프트웨어를 두 벌 유지하겠다는 얘기입니다.
CLI-Anything의 접근은 이 세 가지 모두와 다릅니다. 원본 소프트웨어는 그대로 두고, CLI 레이어만 얹는 겁니다.
CLI가 답인 이유 — 에이전트에게 가장 자연스러운 인터페이스
CLI-Anything이 GUI가 아닌 CLI를 선택한 이유는 분명합니다. 에이전트 입장에서 CLI가 훨씬 다루기 쉽기 때문이에요.
| CLI 장점 | 설명 |
|---|---|
| 구조적 입출력 | 텍스트 명령 + JSON 응답 → LLM이 바로 읽고 쓸 수 있음 |
| 자기 문서화 | --help 플래그로 에이전트가 스스로 기능을 탐색 |
| 결정론적 동작 | 같은 명령 → 같은 결과. 예측 가능한 행동 |
| 조합 가능 | Unix 철학처럼 파이프로 명령을 연결 |
| 경량 | 의존성 없이 모든 시스템에서 동작 |
제가 이 리스트를 보면서 떠올린 건 Claude Code였습니다. Claude Code는 매일 수천 개의 실제 워크플로를 CLI를 통해 처리합니다. 파일을 읽고, 코드를 수정하고, 테스트를 돌리고, 커밋을 합니다. 이 모든 게 CLI 기반이에요. Claude Code가 VS Code 화면을 스크린샷 찍어서 코딩하는 게 아니잖아요.
LLM은 근본적으로 텍스트 모델입니다. 텍스트 입력을 받아서 텍스트를 출력합니다. CLI는 텍스트 인터페이스입니다. 이 둘의 궁합이 좋은 건 우연이 아닙니다. 에이전트에게 GUI를 쓰라고 하는 건, 텍스트 모델에게 비전 모델 역할을 시키는 것과 비슷해요.
CLI-Anything은 실제로 어떻게 동작하는가?
CLI-Anything은 Claude Code 플러그인 마켓플레이스에서 배포됩니다. 사용 흐름은 이렇습니다.
1. 소프트웨어 경로나 리포지토리를 지정 /cli-anything <software-path-or-repo> 2. 7단계 자동 파이프라인 실행 코드 분석 → 아키텍처 설계 → CLI 구현 → 테스트 계획 → 테스트 작성 → 문서화 → 배포 3. 생성된 CLI 사용 pip install -e . cli-anything-gimp render --input photo.xcf --output photo.png --json
핵심은 7단계 파이프라인이 완전 자동화돼 있다는 점입니다. 소프트웨어 소스코드를 분석해서 CLI 하네스를 생성하고, 테스트까지 돌리고, 문서까지 만들어줍니다.
주목할 설계 원칙 5가지
CLI-Anything의 아키텍처 문서를 읽으면서, 이 프로젝트가 단순한 래퍼가 아니라 실제 프로덕션을 고려했다는 걸 느낄 수 있었습니다.
| 원칙 | 핵심 내용 |
|---|---|
| Authentic Integration | 원본 소프트웨어에 실제로 위임. 대체품이 아님 |
| Dual Mode | REPL(대화형) + Subcommand(스크립트) 동시 지원 |
| Agent-Native | 모든 명령에 --json 플래그. 기계용 구조화 출력 |
| Zero Compromise | 백엔드 누락 시 skip이 아니라 fail. 진짜 동작만 허용 |
| 일관된 UX | 모든 생성 CLI가 같은 REPL 인터페이스(repl_skin.py) 공유 |
특히 “Zero Compromise” 원칙이 인상적이었습니다. 테스트에서 백엔드 소프트웨어가 없으면 건너뛰는 게 아니라 실패 처리합니다. 진짜 소프트웨어와 진짜 연동이 되는지를 검증하겠다는 의지예요. 토이 구현을 용납하지 않겠다는 겁니다.
GUI 에이전트 vs CLI 에이전트 — 데이터로 보는 신뢰성 차이
“GUI가 더 직관적이니까 에이전트도 GUI를 쓰면 되지 않나?” 이런 질문이 나올 수 있습니다. 실제로 많은 GUI 에이전트 프로젝트가 있고, Computer Use 같은 접근도 발전하고 있으니까요.
근데 자동화의 신뢰성 기준으로 보면, CLI가 구조적으로 유리합니다.
CLI 에이전트의 구조적 장점: 1. 결정론적 피드백 루프 명령 → 실행 → exit code 0(성공) or >0(실패) → 에이전트가 즉시 재시도 판단 가능 2. 텍스트 기반 조합 output | grep | awk | xargs → 파이프라인으로 복잡한 작업 구성 → LLM의 네이티브 포맷과 일치 3. 컨텍스트 오염 최소화 명시적으로 요청한 파일만 로드 → GUI 에이전트의 "열린 파일 전체 전송" 문제 없음 4. 상태 관리 명확 파일시스템이 곧 상태 → 변경사항이 디스크에 있는지 cat/ls로 바로 확인
GUI 에이전트가 유용한 상황도 있습니다. 시각적 검증이 필요하거나, API도 CLI도 없는 레거시 시스템을 다룰 때요. 근데 프로그래머블한 자동화가 목적이라면, CLI가 맞습니다. CLI-Anything이 이 판단을 프로젝트 레벨에서 실행한 거예요.
MCP, Tool Use, 그리고 CLI — 에이전트 인터페이스의 큰 그림
CLI-Anything을 더 큰 맥락에서 보면, 지금 AI 에이전트 생태계에서 **”에이전트가 외부 세계와 어떻게 소통하느냐”**라는 문제를 풀려는 여러 시도 중 하나입니다.
| 접근 | 대표 사례 | 방식 |
|---|---|---|
| MCP | Anthropic이 제안, Linux Foundation 기부 | 표준 프로토콜로 도구/데이터 접근 |
| Tool Use | OpenAI Function Calling, Claude Tool Use | 모델이 직접 함수 호출 |
| CLI 레이어 | CLI-Anything | 기존 소프트웨어에 CLI 덧입힘 |
| GUI 에이전트 | Computer Use, GUI Agent | 화면을 보고 클릭 |
MCP(Model Context Protocol)는 Anthropic이 2024년 11월에 공개하고 Linux Foundation에 기부한 오픈 표준입니다. AI 모델이 외부 도구, 데이터 소스, API와 표준화된 방식으로 소통할 수 있게 해줍니다. TCP/IP가 인터넷 통신을 표준화한 것처럼, MCP는 에이전트-도구 통신을 표준화하려는 겁니다.
CLI-Anything과 MCP는 경쟁이 아니라 상호 보완입니다. MCP가 “에이전트와 도구 사이의 프로토콜”이라면, CLI-Anything은 “기존 소프트웨어를 도구로 만드는 변환기”입니다. MCP 서버로 CLI-Anything이 생성한 CLI를 감싸면, 어떤 에이전트든 어떤 소프트웨어든 연결할 수 있는 그림이 나옵니다.
에이전트 생태계 레이어 구조: ┌─────────────────────────────────┐ │ AI 에이전트 │ │ (Claude, GPT, Cursor 등) │ ├─────────────────────────────────┤ │ 프로토콜 레이어 │ │ (MCP, Tool Use, Function Call) │ ├─────────────────────────────────┤ │ 인터페이스 변환 레이어 │ │ (CLI-Anything, API Gateway) │ ├─────────────────────────────────┤ │ 기존 소프트웨어 │ │ (Blender, GIMP, LibreOffice) │ └─────────────────────────────────┘
이 구조에서 CLI-Anything이 채우는 빈칸은 **”인터페이스 변환 레이어”**입니다. 기존 소프트웨어를 에이전트가 이해할 수 있는 형태로 변환하는 역할이에요. 위에 MCP 같은 프로토콜이 있고, 아래에 실제 소프트웨어가 있는데, 그 사이를 이어주는 겁니다.
실제 적용 전에 확인해야 할 것들
CLI-Anything의 방향이 맞다고 해서, 지금 당장 모든 소프트웨어에 적용할 수 있다는 뜻은 아닙니다. 몇 가지 체크할 게 있어요.
보안과 권한
에이전트가 CLI를 통해 소프트웨어를 조작할 수 있다는 건, 그만큼 권한 범위가 넓어진다는 뜻입니다. Threads 원문에서도 민감 파일 로컬 처리를 언급했는데, 이건 현실적인 우려예요.
적용 전 보안 체크리스트: [ ] 에이전트에게 열려줄 명령의 범위를 제한했는가? [ ] 삭제/덮어쓰기 같은 파괴적 명령에 승인 절차가 있는가? [ ] 민감 데이터가 포함된 파일에 접근 정책을 정했는가? [ ] 에이전트의 CLI 호출 로그를 기록하고 있는가? [ ] 네트워크로 데이터가 나가는 경로를 차단했는가?
유지보수
CLI-Anything이 생성하는 CLI 하네스는 원본 소프트웨어의 구조를 분석해서 만듭니다. 원본이 업데이트되면 CLI 하네스도 갱신해야 합니다. 소프트웨어 버전 A에서 생성한 CLI가 버전 B에서도 동작한다는 보장은 없어요.
확인 가능한 범위
공식 README에서 확인되는 데모 대상은 GIMP, Blender, Shotcut, LibreOffice, Audacity(sox 경유) 등 오픈소스 소프트웨어입니다. Threads 원문에 나온 Premiere, Photoshop 같은 상용 소프트웨어 예시는 공식 문서에서 직접 확인되지 않습니다. 가능성으론 열려 있지만, 검증된 사례와 가능한 사례를 나눠서 보는 게 안전합니다.
내가 생각하는 교훈 — “새로 만들지 말고, 번역해라”
이 프로젝트를 보면서 가장 크게 느낀 건, **”기존 것을 버리지 않는 전략”**의 가치입니다.
AI 에이전트 시대가 오면 모든 소프트웨어가 새로 만들어져야 한다고 생각하기 쉽습니다. “AI 네이티브”라고 하면, 처음부터 AI를 위해 설계된 걸 떠올리잖아요. 근데 현실에는 이미 수십 년 동안 사람이 쓰도록 만들어진 소프트웨어가 산더미처럼 쌓여 있습니다.
CLI-Anything은 이 현실을 인정합니다. “소프트웨어를 바꾸지 말고, 인터페이스만 번역하자.” 이 접근이 현실적인 이유는 세 가지예요.
- 비용: GIMP를 AI용으로 다시 만드는 비용 vs CLI 레이어를 씌우는 비용
- 기능 보존: 원본의 모든 기능을 그대로 유지
- 속도: 소스코드를 던져주면 자동으로 CLI 생성
저도 에이전트 파이프라인을 운영하면서 비슷한 경험을 했습니다. Obsidian 노트를 에이전트가 다루게 만들 때, Obsidian 전용 AI 앱을 새로 만들자는 게 아니라, 파일시스템 기반 읽기/쓰기로 연결했어요. 기존 구조를 그대로 두고, 에이전트가 접근할 수 있는 인터페이스만 열어준 거죠. CLI-Anything은 이 아이디어를 소프트웨어 전체에 적용한 프로젝트입니다.
앞으로 주목할 맥락
CLI-Anything + MCP 조합 시나리오: 1. CLI-Anything으로 GIMP, Blender, LibreOffice의 CLI 하네스 생성 2. 각 CLI를 MCP 서버로 감싸기 3. Claude Code에서 MCP 클라이언트로 연결 4. "이 사진 배경 제거하고, 3D 장면에 삽입하고, 보고서 PDF로 변환해줘" → 에이전트가 3개 소프트웨어를 CLI로 연속 호출
이게 아직 완성된 건 아닙니다. 근데 방향은 보이잖아요. 에이전트가 사람처럼 GUI를 흉내 내는 시대에서, 기계답게 CLI로 명령하는 시대로 넘어가는 겁니다. CLI-Anything은 그 전환의 구체적인 도구를 제시한 프로젝트입니다.
FAQ
Q1. CLI-Anything은 무엇이고, 누가 만들었나요?
홍콩대학교 HKUDS 연구팀이 만든 오픈소스 프로젝트입니다. 기존 소프트웨어를 분석해서 CLI(명령줄 인터페이스)를 자동 생성하고, 이를 통해 AI 에이전트가 해당 소프트웨어를 조작할 수 있게 합니다. Claude Code 플러그인 마켓플레이스로 배포됩니다.
Q2. GUI 에이전트와 비교했을 때 CLI 에이전트의 장점은?
CLI 에이전트는 결정론적(같은 입력 → 같은 출력), 텍스트 기반(LLM과 궁합이 좋음), 조합 가능(파이프라인 연결)하다는 구조적 장점이 있습니다. GUI 에이전트는 스크린샷 인식에 의존하기 때문에, UI 변경이나 멀티스텝에서 에러가 누적되면 신뢰성이 떨어집니다.
Q3. CLI-Anything은 어떤 소프트웨어에 적용할 수 있나요?
공식 README 기준으로 GIMP, Blender, Shotcut, LibreOffice, Audacity(sox 경유) 등 오픈소스 소프트웨어에 대한 데모가 확인됩니다. 소스코드가 있으면 분석할 수 있으므로, 이론적으로는 오픈소스 대안이 있는 거의 모든 소프트웨어에 적용 가능합니다.
Q4. MCP와 CLI-Anything의 관계는?
경쟁이 아니라 상호 보완입니다. MCP가 에이전트-도구 간 통신 프로토콜이라면, CLI-Anything은 기존 소프트웨어를 에이전트가 다룰 수 있는 도구로 변환하는 역할입니다. CLI-Anything이 생성한 CLI를 MCP 서버로 감싸면, 표준화된 방식으로 어떤 에이전트든 연결할 수 있습니다.
Q5. 프로덕션에 적용할 때 주의할 점은?
세 가지를 확인하세요. 첫째, 에이전트에게 열어줄 명령의 범위와 권한 정책. 둘째, 민감 데이터 접근과 로그 정책. 셋째, 원본 소프트웨어 업데이트 시 CLI 하네스 갱신 계획. 검증된 사례(오픈소스)와 가능한 사례(상용 소프트웨어)를 나눠서 판단하는 게 안전합니다.
Q6. 지금 바로 써볼 수 있나요?
네. Claude Code에서 플러그인 마켓플레이스를 추가하고, /cli-anything <software-path-or-repo> 명령으로 실행할 수 있습니다. 생성된 CLI는 pip install -e .로 설치하면 바로 사용 가능합니다. 오픈소스 소프트웨어부터 시작하는 걸 추천합니다.
결론 — 에이전트 시대의 인터페이스는 “번역”이다
AI 에이전트가 세상의 모든 소프트웨어를 다루게 만드는 방법은 두 가지입니다. 모든 소프트웨어를 AI용으로 다시 만들거나, 기존 소프트웨어에 에이전트가 이해하는 인터페이스를 덧입히거나.
CLI-Anything은 후자를 선택했습니다. 새로 만들지 않고 번역하겠다는 겁니다. 그리고 그 번역의 매개체로 CLI를 선택한 이유도 납득이 됩니다. 에이전트에게 가장 자연스러운 소통 방식은 텍스트 명령이니까요.
이 프로젝트가 모든 문제를 풀었다고 말할 수는 없습니다. 보안, 유지보수, 상용 소프트웨어 적용 같은 과제가 남아 있어요. 근데 **”기존 소프트웨어를 에이전트 네이티브로 만든다”**는 프레이밍 자체가 의미 있습니다. 새 앱을 만드는 것만이 AI 시대의 전략이 아니에요.
여러분이 매일 쓰는 GUI 프로그램 중에, 에이전트가 CLI로 다뤄서 자동화하면 좋겠다 싶은 게 하나쯤은 있을 겁니다. 그 하나부터 시작해 보세요.
📚 참고 자료
- CLI-Anything GitHub 리포지토리 — HKUDS (2026)
- CLI-Anything 소개 — @choi.openai Threads (2026.03)
- Model Context Protocol 공식 문서 — Anthropic (2024~)
- CLI Agents vs GUI Agents — Firecrawl (2025)
- GUI Agent 신뢰성 분석 — arXiv (2025)
ℹ️ 이 글은 CLI-Anything 공식 GitHub README, Threads 원문, 그리고 GUI/CLI 에이전트 비교 연구를 바탕으로 작성했습니다. Threads에 나온 일부 활용 사례(Premiere, Photoshop 등)는 공식 README에서 직접 확인되지 않아 가능성과 검증 사례를 구분했습니다. (2026.03.10)