요약: AI 전성시대, 맥미니 열풍과 CLI 회귀 속에서 윈도우 사용자는 소외되고 있다. 이 글에서는 직접 만든 윈도우 데스크톱 자동화 도구 AgentZero를 소개하고, GUI→TUI→CLI로 전환하는 생산성 도구의 흐름 속에서 미래의 업무 도구가 어떤 모습일지 탐구한다.

대상 독자: IT 개발자, AI 도구에 관심 있는 직장인 | 작성 기준: 2026-04

1. AI 전성 툴시대와 맥미니 열풍

2025년 하반기부터 개발자 커뮤니티에 묘한 바람이 불기 시작했다. 맥미니를 사는 개발자가 폭발적으로 늘어난 것이다. M4 Pro의 통합 메모리 64GB, Neural Engine 38 TOPS(초당 38조 연산)라는 스펙 때문만은 아니었다. 진짜 이유는 “딸각 한 번이면 끝나는 툴 설치”에 있었다.

brew install ollama    # 로컬 LLM 엔진
brew install claude    # Claude Code CLI
brew install python    # 파이썬 환경

Homebrew 한 줄이면 끝이다. 리눅스와의 호환성도 뛰어나서, macOS에서 만든 스크립트가 서버에서도 그대로 돌아간다. Ollama 위에 Llama 3.1 70B를 올리면 M4 Pro 64GB에서 초당 10~15 토큰으로 로컬 AI 비서가 완성된다. Apple의 MLX 프레임워크는 Metal GPU 가속까지 네이티브로 지원한다.

여기에 Claude Code의 등장이 결정타였다. Anthropic이 2025년 2월 공개한 이 터미널 기반 AI 코딩 에이전트는, 파일 시스템에 직접 접근하고 git과 통합되며, MCP(Model Context Protocol, LLM이 외부 도구와 데이터에 연결하는 오픈 표준 프로토콜)로 온갖 외부 도구와 연결된다. GitHub 데이터에 따르면 Claude Code 관련 커밋은 13개월 만에 42,896% 증가했다. IDE를 열 필요 없이 터미널 하나면 코딩이 끝나는 시대가 온 것이다.

MCP는 Anthropic이 2024년 11월 공개한 오픈 표준 프로토콜로, LLM이 외부 도구와 데이터에 연결하는 “USB-C”에 비유된다. 2025년 3월 기준 공식/커뮤니티 MCP 서버가 1,000개를 넘었고, OpenAI까지 MCP 지원을 발표하면서 사실상 업계 표준이 되었다. 이 모든 것이 CLI, 텍스트 기반 인터페이스 위에서 돌아간다.


2. 나는 윈도우 사용자인데... 소외받았나?

맥 사용자들이 brew install 딸각으로 환경을 구축하는 동안, 윈도우 사용자는 복잡한 현실과 마주한다.

윈도우 터미널 생태계의 복잡성은 상상을 초월한다.

Homebrew는 macOS + Linux를 하나로 잇는다. 윈도우에는 그런 게 없다. winget install이 Homebrew를 따라가려 하지만, 개발자 도구 생태계의 깊이에서 아직 격차가 크다.

Claude Code도 윈도우 네이티브보다는 WSL2 위에서 돌리는 것을 권장한다. 윈도우 사용자는 “리눅스 안에서 돌리는 맥 스타일 도구”를 쓰는 이상한 상황에 놓인다. 게다가 Anthropic의 Computer Use 기능은 스크린샷 기반이라 응답이 느리고, 윈도우 네이티브 앱을 제어하기에는 한계가 뚜렷하다.

그리고 이것만이 아니다. AI CLI 도구로 파일 분석, Python 스크립트, Node.js 스크립트를 실행하다 보면, 일관적이지 않은 윈도우의 터미널 환경 때문에 Claude Code가 적어도 2번 이상은 실패한다. WSL 안이라고 알려주면 CMD 명령을 돌리고, 윈도우 터미널이라고 하면 Linux Bash 문법에서 막히고. 맥이라면 어디서든 동일한 Unix 셸이 돌아가지만, 윈도우에서는 “지금 내가 WSL 안에 있는지, 네이티브 PowerShell인지, CMD인지”를 AI가 매번 헷갈린다.


윈도우 개발자의 현실

단지 AI CLI 도구가 현재 터미널 환경을 제대로 인식하지 못한다는 이유만으로, WSL과 윈도우 네이티브 터미널 사이를 수시로 전환해야 하는 경우가 상당하다. pip install은 WSL에서, dotnet build는 네이티브에서, npm install은 둘 다 되지만 경로 구분자(/ vs \)가 달라서 스크립트가 깨진다 — 이런 일이 매일 반복된다.

그뿐만이 아니다. 개행 문자가 다르다(LF vs CRLF). 파일명 대소문자 규칙이 다르다 — Linux는 Config.jsonconfig.json을 다른 파일로 보지만, 윈도우는 구분하지 않는다. AI가 생성한 스크립트가 이런 차이를 모르면 “분명히 맞는 코드인데 왜 안 되지?”가 반복된다.

Anthropic은 왜 이런 환경 차이를 고려해서 도구 스크립트를 작성해주지 않는가? 결과적으로 동일한 프로젝트에서 어느 날은 CMD로, 어느 날은 WSL로, 또 어떤 날은 PowerShell로 들어갈 수밖에 없는 상황이 생긴다.

게다가 PowerShell 5.1은 지원 중단 수순에 들어갔으니 PowerShell 7을 사용해야 하는데, 이 둘은 프로파일 경로부터 다르다 — 5.1은 $HOME\Documents\WindowsPowerShell, 7은 $HOME\Documents\PowerShell. 윈도우에서 CLI를 쓴다는 것은 평행 우주 안에서 동일한 바이너리를 실행하는 것과 다름없다.


3. 그래서 변종을 만들었다 — AgentZero

윈도우 진영에 OS 자동화 도구가 없는 건 아니다. AutoIt, AutoHotkey, Power Automate... 전통적인 자동화 도구는 많다. 하지만 이들은 AI 에이전트 시대에 맞지 않는다.

구분

AutoIt / AHK

Anthropic Computer Use

AgentZero

방식

사전 정의 스크립트

스크린샷 기반 AI

Win32 네이티브 API + AI

속도

빠름 (ms 단위)

느림 (수 초/액션)

빠름 (ms 단위)

AI 연동

없음

내장

Claude Code MCP 연동

크로스 앱

윈도우만

OS 무관

윈도우 네이티브 특화

텍스트 캡처

제한적

OCR 의존

UI Automation 4단계 폴백

AgentZero(GitHub)는 .NET 10 기반 WPF 애플리케이션으로, AI 에이전트가 윈도우 데스크톱을 직접 제어할 수 있도록 설계했다. 핵심은 두 가지다.

3.1 네이티브(Win32)든 하이브리드든, 다 캡처한다

AgentZero의 텍스트 캡처 엔진은 4단계 폴백 전략을 사용한다.

Strategy 0: KakaoTalk    → 클립보드 기반 캡처
Strategy 1: TextPattern  → UI Automation (WPF TextBox, RichTextBox)
Strategy 2: Chromium     → Enhanced UIA + ScrollPattern (Chrome, Edge, Teams)
Strategy 3: ScrollPattern → TreeWalker (ListView, DataGrid)
Strategy 4: WM_VSCROLL   → 레거시 Win32 (Notepad, Notepad++)

네이티브 Win32 앱이든 Electron 기반 하이브리드 앱이든, Chromium 브라우저든 상관없이 텍스트를 캡처한다. Anthropic의 Window MCP가 스크린샷을 찍고 OCR로 텍스트를 인식하는 동안, AgentZero는 UI Automation API로 직접 텍스트를 가져온다. 속도 차이는 100배 이상이다.

Teams 메시지의 무한 스크롤도 처리한다. 날짜 필터링까지 지원해서 “2026년 3월 1일부터 3월 15일까지의 대화만 추출”하는 것도 가능하다.

3.2 멀티 TUI — 멀티 AI를 동시에 갈구는 시대

이제는 “멀티 에이전트”가 아니라 “멀티 AI” 시대다. OpenAI, Claude, QWEN, Gemma — 각각의 LLM이 잘하는 영역이 다르다.

모델

강점

Claude Sonnet/Opus

코딩, 장문 분석, Computer Use

GPT-4o / o3

범용 추론, 멀티모달

QWEN 2.5

오픈소스 최강급, 다국어

Gemma 3/4

경량 온디바이스, 로컬 추론

DeepSeek-R1

추론 특화, 비용 효율

AgentZero는 ConPTY 기반 다중 터미널을 내장하고 있다. PowerShell 5, PowerShell 7, CMD, WSL — 어떤 셸이든 탭으로 열 수 있다. 여기에 각각 다른 AI 프로필을 설정하면?

# PowerShell 프로필에 등록
function claude-pel3 { $env:CLAUDE_CONFIG_DIR="$env:USERPROFILE\.claude-pel3"; claude @args }
function claude-gpt4 { $env:CLAUDE_CONFIG_DIR="$env:USERPROFILE\.claude-gpt4"; claude @args }
function claude-qwen { $env:CLAUDE_CONFIG_DIR="$env:USERPROFILE\.claude-qwen"; claude @args }

탭 1에서는 Claude가 코드를 짜고, 탭 2에서는 GPT-4가 리뷰하고, 탭 3에서는 QWEN이 번역한다. 하나의 앱에서 여러 AI를 동시에 굴리는 TUI 환경이다.

CLI가 대세가 되면서, 이 CLI들을 메뉴처럼 관리하는 TUI(Text User Interface) 환경이 자연스럽게 부상하고 있다. tmux, zellij 같은 터미널 멀티플렉서가 개발자의 필수 도구가 된 것도 같은 맥락이다. Zellij(Rust 기반)는 GitHub 스타 20,000+를 넘기며, Ghostty(Mitchell Hashimoto 개발)는 공개 24시간 만에 10,000+ 스타를 달성했다.

3.3 AgentBot — AI가 AI를 제어한다

AgentZero의 AgentBot은 터미널에서 발생하는 승인 프롬프트를 자동 감지한다. Claude Code가 파일을 수정하겠다고 물으면, AgentBot이 이를 감지하고 사용자 대신 자동 승인할 수 있다. 터미널 출력에서 “Do you want to proceed?”나 “requires approval” 같은 패턴을 500ms 간격으로 스캔한다.

또한 Skill Sync 기능으로 Claude Code의 슬래시 명령(/commit, /review 등)을 AgentBot UI에 자동 동기화하여, 챗봇 인터페이스에서 클릭 한 번으로 명령을 실행할 수 있다.

3.4 파일뷰어와 마크다운 렌더링

AgentZero에는 내장 파일 트리 네비게이터와 마크다운 뷰어가 있다. 프로젝트의 SKILL.md나 README.md를 앱 안에서 바로 렌더링해서 볼 수 있다. MdXaml 라이브러리를 사용해 WPF 네이티브로 마크다운을 렌더링하며, Mermaid 다이어그램까지 오프라인으로 표시한다.


4. GUI가 TUI로, MCP가 CLI로 — 왜 거꾸로 가는가?

흥미로운 역설이 있다. 기술은 항상 더 편한 방향으로 진화한다고 믿어왔다. CLI에서 GUI로, 텍스트에서 그래픽으로. 그런데 지금 일어나는 일은 정반대다.

GUI → TUI로의 회귀에는 명확한 이유가 있다.

첫째, LLM은 텍스트를 가장 잘 다룬다. GUI의 버튼과 드래그앤드롭은 사람에게는 편하지만, AI 에이전트에게는 접근하기 어렵다. 반면 CLI 명령은 텍스트 그 자체다. LLM이 git commit -m "fix bug"를 생성하는 것은 자연스럽지만, GUI에서 커밋 버튼을 찾아 클릭하는 것은 스크린샷 분석이 필요하다.

둘째, MCP가 CLI를 선택한 이유도 같은 맥락이다. “MCP는 모든 도구 스펙을 상시 보유해야 해서 컨텍스트 비용이 발생하지만, CLI는 --help로 필요할 때만 조회하면 된다.” 텍스트 기반 인터페이스가 LLM에게는 가장 효율적인 의사소통 방식인 것이다.

셋째, 자동화와 재현 가능성. CLI 명령은 스크립트로 조합할 수 있다. 파이프라인을 만들고, 반복하고, 버전 관리할 수 있다. dotfiles로 환경 전체를 Git에 저장할 수 있다. GUI에서는 불가능한 일이다.

Neovim은 0.10 릴리스로 LSP 네이티브 지원이 성숙하면서, LazyVim, NvChad 같은 배포판과 AI 플러그인(copilot.vim, avante.nvim) 생태계가 폭발적으로 성장했다. Helix 에디터는 GitHub 스타 35,000+를 넘기며 TUI 에디터의 부활을 상징한다.

그렇다면 GUI 기반 IDE는 TUI로 전환할 것인가? 아직은 아니다. Cursor는 VS Code를 포크한 AI 네이티브 IDE로 시리즈 B $60M 투자를 유치했고, JetBrains도 AI Assistant를 통합했다. GUI와 TUI는 대체 관계가 아니라 공존의 길을 가고 있다. 다만, AI 에이전트의 “작업 인터페이스”로서 CLI/TUI의 비중이 급격히 커지고 있는 것은 분명하다.


5. 마치며 — 도구가 단순해진 것이 아니라, 더 늘어났다

CLI로 우리의 도구 사용이 단순해지는 것처럼 보인다. brew install 한 줄, claude code 한 줄. 하지만 현실은 다르다.

엑셀은 여전히 유효하다. 재무 모델링을 CLI로 하는 사람은 없다. IDE도 집중 모드에서는 여전히 중요하다. 디버거를 TUI로 돌리는 것보다 Visual Studio의 브레이크포인트가 효율적인 경우가 분명히 있다. 단순해진 게 아니라, 사용해야 할 도구가 더 늘어난 것이다.

여기서 근본적인 질문이 떠오른다.

편집에 특화된 도구는 누구를 위한 것이었나?

아래한글, MS Office, Google Docs — 이 도구들은 사람이 직접 편집하기 위해 만들어졌다. 리본 메뉴, 드래그앤드롭, WYSIWYG 에디터. 모두 사람의 손과 눈을 위한 인터페이스다.

그런데 AI가 글을 쓰는 시대가 왔다. AI에게 가장 자연스러운 문서 포맷은? 마크다운이다. .md 파일은 플레인 텍스트고, Git으로 버전 관리가 되고, LLM이 읽고 쓰기에 최적화되어 있다. docx나 hwp는 바이너리 포맷이라 AI가 직접 다루기 어렵다.

그러면 모든 문서를 마크다운으로 돌아가면 되는 것인가? 우리가 직접 편집할 거 아니니까?

아직은 아니다. 법적 문서, 관공서 서류, 인쇄물은 여전히 WYSIWYG 편집기를 요구한다. 하지만 개발 문서, 기술 블로그, 내부 위키 — 이런 영역에서는 이미 마크다운이 표준이 되었다.

미래의 생산성 도구는 어떤 모습일까?

아마 두 갈래로 나뉠 것이다. 하나는 사람이 정교하게 편집하는 도구 — 디자인 소프트웨어, 스프레드시트, 프레젠테이션. 다른 하나는 AI가 빠르게 생성하고 사람이 검수하는 도구 — 마크다운 에디터, CLI 기반 작업 도구, 에이전트 오케스트레이터.

이 두 세계가 어떻게 합쳐질지, 아니면 영원히 병렬로 달릴지. 아직 답은 없다. 확실한 것은 하나다 — 우리가 익숙했던 “하나의 도구로 모든 것을 하던 시대”는 끝났다. AgentZero를 만들면서 느낀 것도 그것이다. 맥이 좋고 윈도우가 나쁜 게 아니라, 각 환경에 맞는 도구를 직접 만들어야 하는 시대가 온 것이다.

도구의 미래는 “더 단순하게”가 아니라, “더 다양하게, 그리고 AI가 조율하게”일지도 모른다.


참고 자료

  1. AgentZero GitHub — Windows 데스크톱 자동화 도구

  2. Anthropic Computer Use — 2024.10

  3. Microsoft UFO — UI-Focused Agent for Windows OS, GitHub Stars 20,000+

  4. Claude Code 공식 — 터미널 기반 AI 코딩 에이전트, 2025.02

  5. MCP 공식 사이트 — Model Context Protocol 오픈 표준, 2024.11

  6. Ghostty — Mitchell Hashimoto의 GPU 가속 터미널, 2024.12 공개

  7. Zellij — Rust 기반 차세대 터미널 멀티플렉서, GitHub Stars 20,000+

  8. Apple M4 Mac mini — M4 Pro 64GB, Neural Engine 38 TOPS


부록 - AgentZero

여기서 잠깐 소개되는 AgentZero는 실제작동하는 변종툴로 자세한 기능소개는 아래 따로 설명