나의 AI 어시스턴트는 코딩은 할 수 있었지만, 내 데스크톱을 조작할 수는 없었다

대부분의 AI 코딩 에이전트(AI coding agents)는 작업이 터미널(terminal)을 벗어나기 전까지만 유능합니다.

그들은 파일을 수정할 수 있습니다. 테스트를 실행할 수 있습니다. 차이점(diff)을 설명할 수 있습니다. 그러다 작업이 데스크톱 앱, OAuth 승인 화면, 네이티브 설정 창, 또는 API 접근을 위해 설계되지 않은 웹 UI(web UI)에 부딪히게 됩니다. 갑자기 에이전트가 막히는 이유는 지능(intelligence) 때문이 아니라, 도달 범위(reach) 때문입니다.

그것이 제가 로컬 AI 설정을 구축하는 동안 계속 마주쳤던 격차였습니다. 저에게는 Claude Code, Codex CLI, Gemini CLI, 로컬 모델(local models), 프로바이더 키(provider keys), 그리고 계정 풀(account pools)이 있었습니다. 부족했던 조각은 또 다른 모델이 아니었습니다.

그것은 오퍼레이터(operator, 조작자)였습니다.

문제는 경계였다

저의 이전 워크플로우(workflow)에는 두 개의 분리된 세계가 있었습니다.

한 세계에서는 코딩 에이전트들이 터미널과 저장소(repos) 내부에서 살았습니다. 그들은 코드에 대해 추론하고, 명령을 실행하며, 세션(session)을 유지할 수 있었습니다.

다른 세계에서는 실제 작업이 여전히 데스크톱 앱, 대시보드(dashboards), 브라우저 창, 채팅 클라이언트(chat clients), 그리고 프로바이더 콘솔(provider consoles)을 통해 이루어졌습니다. 인간은 생각 없이도 그 세계들 사이를 넘나들 수 있습니다. 에이전트는 그럴 수 없었습니다.

그것은 어시스턴트를 마땅히 그래야 할 것보다 더 작게 느껴지게 만들었습니다:

버그를 수정할 수는 있지만, 설정을 항상 완료할 수는 없었습니다.
어디를 클릭해야 할지 알려줄 수는 있지만, 안전하게 클릭할 수는 없었습니다.
워크플로우를 생성할 수는 있지만, 그 워크플로우를 소유한 앱을 안정적으로 구동할 수는 없었습니다.
프로젝트 지식을 재사용할 수는 있지만, 제가 그것을 붙여넣는 것을 기억했을 때만 가능했습니다.

그래서 저는 CliGate에 대해 생각하는 방식을 바꾸었습니다.

CliGate는 더 이상 AI 도구들을 위한 단순한 로컬 API 게이트웨이(API gateway)가 아닙니다. 그것은 에이전트 작업을 위한 로컬 컨트롤 플레인(control plane)이 되어가고 있습니다.

CliGate가 현재 하는 일

CliGate는 여전히 AI 코딩 도구들을 위한 하나의 localhost 서비스로 시작합니다.

Claude Code, Codex CLI, Gemini CLI, 그리고 OpenClaw를 동일한 로컬 서버로 지정한 다음, 하나의 대시보드에서 프로바이더 키, 계정 풀, 라우팅(routing), 사용량, 로그, 그리고 로컬 런타임(local runtimes)을 관리할 수 있습니다.

하지만 더 새로운 어시스턴트 레이어(assistant layer)가 그 위에 자리 잡고 있습니다.

그것은 두 가지 모드를 가집니다:

Direct runtime (직접 런타임): 현재의 Codex 또는 Claude Code 세션과 계속 대화합니다.
Assistant collaboration (어시스턴트 협업): CliGate Assistant에게 상태를 검사하거나, 런타임을 선택하거나, 작업을 계속하거나, 차단된 실행을 처리하거나, 발생한 일을 요약하도록 요청합니다.

이러한 분리는 중요합니다. 저는 모든 일반적인 메시지가 영리한 감독관(supervisor)에 의해 가로채지는 것을 원하지 않습니다. 때로는 그저 현재의 런타임 세션을 계속 이어가고 싶을 뿐입니다. 또 다른 때에는 더 큰 그림을 볼 수 있는 어시스턴트를 원합니다.

어시스턴트는 Codex나 Claude Code를 대체하려는 것이 아닙니다. 그것들을 조정(coordinate)하는 것입니다.

기술(Skills)을 통해 덜 일반적인 형태로 진화하다

두 번째 요소는 기술(skills)입니다.

기술(skill)은 지침(instructions), 스크립트(scripts), 템플릿(templates) 및 참조(references)로 구성된 로컬 패키지입니다. 어시스턴트가 모든 세부 사항을 항상 컨텍스트(context)에 담아둘 필요는 없습니다. 먼저 짧은 설명을 확인한 다음, 작업이 일치할 때만 전체 SKILL.md를 읽을 수 있습니다.

예를 들어:

skills/
  devto-publisher/
    SKILL.md
...

이를 통해 어시스턴트는 "도구를 가진 일반적인 채팅창"에서 재사용 가능한 절차를 가진 팀원에 더 가까운 존재로 변모합니다.

하나의 기술은 Dev.to 기사를 게시하는 방법을 알 수 있습니다. 다른 기술은 스프레드시트를 만드는 방법을 알 수 있습니다. 또 다른 기술은 로컬 저장소(repo)의 컨벤션(conventions)을 알 수 있습니다. 핵심은 이것들이 로컬에 존재하며, 검사 가능하고, 에이전트(agent)의 나머지 부분과 동일한 권한 시스템을 통해 실행 가능하다는 점입니다.

이것은 마법이 아닙니다. 운영 지식(operational knowledge)을 하나의 거대한 프롬프트(prompt)에 몰아넣지 않기 위한 더 나은 방법일 뿐입니다.

데스크톱 제어가 핵심적인 돌파구이다

제가 가장 기대하는 부분은 데스크톱 제어(desktop control)입니다.

데스크톱 자동화의 첫 번째 순진한 버전은 대개 시각적입니다. 스크린샷을 찍고, 모델에게 어디를 클릭할지 묻고, 마우스를 움직이고, 이를 반복하는 방식입니다. 이는 데모용으로는 작동하지만 취약합니다. 작은 버튼, 포커스 변경, DPI 스케일링, 팝업 및 애니메이션 등이 이를 망가뜨릴 수 있습니다.

CliGate의 데스크톱 에이전트(desktop agent)는 Windows에서 다른 기본 경로를 택합니다. UI 자동화(UI Automation)를 우선시하고, 스크린샷을 그다음으로 둡니다.

픽셀을 추측하는 대신, 어시스턴트는 운영 체제에 UI 트리(UI tree)를 요청할 수 있습니다:

window 목록 나열 -> 앱 포커스 -> 입력창 찾기 -> 값 설정 -> Enter 전송 -> 텍스트 읽기

이는 어시스턴트가 컨트롤 유형 (control type)을 통해 텍스트 박스를 찾고, 접근성 API (accessibility API)를 통해 값을 설정하며, 버튼을 실행하고, 보이는 텍스트를 읽을 수 있음을 의미합니다. 앱이 유용한 접근성 메타데이터 (accessibility metadata)를 제공하지 않을 때만 스크린샷 방식에 의존하게 됩니다.

이것이 바로 제가 원했던 가교입니다. 리포지토리 (repos) 내에서 작업할 수 있으면서도, 리포지토리를 둘러싼 데스크톱 애플리케이션을 조작할 수 있는 코딩 어시스턴트 말입니다.

향후 방향

현재의 형태는 다음과 같습니다:

CliGate는 하나의 로컬 서버를 통해 AI 코딩 도구들을 라우팅 (route) 합니다.
런타임 세션 (Runtime sessions)은 Codex와 Claude Code의 작업 상태를 유지합니다.
어시스턴트는 관찰하고, 조정하며, 요약합니다.
스킬 (Skills)은 재사용 가능한 절차를 제공합니다.
데스크톱 제어 (Desktop control)는 네이티브 앱 및 GUI 워크플로 (workflows)로 나아가는 경로를 제공합니다.

이러한 조합은 제품의 성격을 "AI 도구를 위한 프록시 (proxy)"에서 "개발자 워크플로를 위한 로컬 운영자 (local operator)"로 변화시킵니다.

데스크톱 제어 레이어 (desktop-control layer)는 별도의 포스팅을 할 가치가 있다고 생각합니다. "AI는 운영 체제의 접근성 트리 (OS accessibility tree)를 통해 어떤 앱이든 조작할 수 있다"는 주제는 이곳에 다 담기에는 매우 깊은 주제이기 때문입니다.

프로젝트는 여기서 오픈 소스로 공개되어 있습니다: CliGate on GitHub

여러분은 코딩 에이전트 (coding agents)와 이들이 상호작용해야 하는 데스크톱 앱 사이의 경계를 어떻게 처리하고 계신가요?