포스터 문구를 바꾸고, 견적서 수량을 고치고, 3D 장면을 렌더링하는 일을 AI에게 맡긴다고 해보자. 화면의 버튼 위치를 매번 찾는 대신, 현재 상태를 읽고 정해진 명령을 실행할 수 있다면 작업을 연결하기 쉬워진다.
CLI-Anything은 기존 소프트웨어를 에이전트가 다룰 수 있는 명령줄 인터페이스로 연결하는 프로젝트다. ‘CLI Anything’이라는 이름만 보고 모든 앱이 한 번에 자동화된다고 기대하기보다는, 앱별 하네스와 실제 처리 엔진, 결과 검증을 나눠 이해하는 편이 좋다.
세 영상은 각각 설계 원칙, Inkscape·LibreOffice·Blender 실습, 설치·검증 구조를 다룬다. 공식 저장소와 방법론을 대조해 공통 원리와 적용 순서를 정리했다. 이 글에서 하네스를 새로 설치하거나 네이티브 앱의 전체 작업을 독립 재현한 것은 아니다.
CLI-Anything은 앱을 새로 복제하는 도구가 아니다
공식 저장소는 기존 소프트웨어와 에이전트 사이에 CLI 하네스를 두는 방식을 제안한다. 하네스는 명령을 해석하고 작업 상태를 관리하며, 필요한 기능을 앱의 API·스크립트·명령줄 도구나 파일 형식에 연결한다.
흐름은 사용자 요청 → 에이전트의 명령 선택 → 앱별 하네스 → 처리 결과와 상태 확인으로 볼 수 있다. 새 앱을 만드는 것과는 다른 접근이다. Craft Anything의 재구현 방식과도 목적을 구분해야 한다.
소프트웨어에 접근 가능한 API나 스크립팅 기능이 부족하면 연결할 수 있는 범위도 제한된다. 이미 준비된 하네스가 있더라도 앱 전체 기능을 모두 다룬다고 가정하지 말자. GUI를 없애는 선언보다는 반복 작업에 기계가 사용할 입구를 추가하는 방법에 가깝다.
하네스를 만드는 7단계는 구현보다 검증까지 포함한다
HARNESS.md는 다음 순서를 제시한다.
- 소스·구조 분석
- 명령 구조와 상태 모델 설계
- 하네스 구현
- 테스트 계획 작성
- 테스트 구현·실행
- 결과와 사용 방법 문서화
- 패키징과 설치·발견 가능성 확보
코딩 에이전트가 생성한다고 해서 테스트 단계가 생략되는 것은 아니다. 어떤 기능을 노출하고 무엇을 확인했는지 사용 설명과 함께 남겨야 다른 에이전트가 이어서 쓸 수 있다.
또한 이미 만들어진 하네스를 설치하는 일, 없는 하네스를 생성하는 일, 원래 앱을 설치하는 일은 구분해야 한다. CLI 도구를 설치했다고 LibreOffice의 변환 엔진이나 Blender의 렌더 엔진까지 준비됐다는 뜻은 아니다.
단테의 실습: 그림·계산·3D를 같은 요청 흐름으로 잇는다
단테 영상은 가상 커피 브랜드를 소재로 세 앱의 결과물을 보여준다. 제작자의 시연을 정리한 것이며 블로그의 독립 실행 결과는 아니다.
Inkscape: 이미지 한 장보다 수정할 수 있는 원본
포스터를 SVG·PDF로 내보내고 Inkscape에서 확인한다. 이후 문구를 MORNING에서 EVENING으로 바꾸는 작업도 소개한다. 반복 제작에서는 이런 편집 가능한 원본과 최종 배포 파일을 구분하는 것이 유용하다.
LibreOffice: 합계 숫자가 아니라 수량과 수식을 확인한다
견적서는 원두 수량을 20개에서 30개로 바꾸고 수식 결과가 따라가는지를 보여준다. 가상 예제의 합계는 520,000원에서 700,000원으로 바뀐다. 이 산술은 검산했지만 실제 Calc 재계산을 재현한 것은 아니다.
제작자는 사용 커밋과 함께 수식 처리를 위한 xmlns:of 선언을 추가했다고 명시한다. 따라서 영상 결과에는 로컬 수정이라는 조건이 있다. 무수정 설치가 항상 성공한다거나 모든 버전이 같은 문제를 갖는다고 일반화할 수는 없다.
Blender: 장면 데이터와 렌더 결과는 별개다
영상은 커피 컵 장면과 Blender에서 물체를 선택하는 모습을 보여준다. 장면 JSON이나 생성된 실행 스크립트가 있다는 사실만으로 렌더가 끝났다고 보지는 말자. 실제 엔진 실행과 이미지·프로젝트 확인이 필요하다.
에이전트용 CLI 설계에서 가져올 6가지 원칙
다음은 공식 방법론의 요구와 세 영상을 바탕으로 정리한 기준이다. 모든 기존 하네스가 이미 이 기준을 완벽하게 충족한다는 보증은 아니다.
1. 행동하기 전에 상태를 조회할 수 있어야 한다
문서·객체·시트·장면의 현재 상태를 먼저 확인하도록 명령을 설계한다. 에이전트가 기억이나 추측으로 객체 번호를 고르면 엉뚱한 대상을 바꿀 수 있다. info, list, status 같은 탐색 기능이 수정 명령만큼 중요하다.
2. 구조화된 출력과 실제 성공을 구분한다
JSON은 결과를 파싱하기 쉽게 만든다. 하지만 파싱되는 응답이라고 내용까지 올바른 것은 아니다. 입력, 처리 상태, 산출물 위치와 실패 이유가 명확해야 다음 행동을 판단할 수 있다.
방법론은 --json 지원을 요구한다. 실제 설치된 하네스의 옵션 위치와 출력 구조는 해당 도움말에서 확인하자. 앱마다 명령 이름과 지원 범위가 같지는 않다.
3. 중간 파일과 실제 앱 엔진의 출력을 나눈다
SVG·ODF·장면 JSON 같은 중간 표현을 구성하는 단계와 PDF·Office 형식 변환·3D 렌더링은 다르다. 앱별 문서도 이 차이를 보여준다. 일부 편집은 앱 본체 없이 가능하지만 최종 변환이나 렌더링에는 해당 엔진이 필요하다.
HARNESS.md는 렌더링·내보내기에 실제 소프트웨어를 사용하도록 요구한다. 비슷한 이미지를 따로 만들어 성공한 것처럼 대신하는 방식은 이 목적과 맞지 않는다. 결과가 어떤 처리 경로로 만들어졌는지를 남겨두자.
4. 상태 저장과 반복 실행을 안전하게 설계한다
여러 명령을 따로 실행해도 작업을 이어갈 수 있어야 한다. 저장된 상태, 원본 파일, 내보낸 결과가 각각 무엇인지 구분하자. 되돌리기와 재시도도 실제 지원되는 범위를 확인해야 한다.
명령이 재전송되면 같은 도형이나 행이 중복 추가될 수도 있다. 읽기·생성·수정·삭제의 성격에 맞춰 재실행 규칙을 정하는 편이 좋다. 상태 파일의 동시 쓰기나 충돌도 별도로 다뤄야 한다.
5. 실패를 설명하고 결과 파일을 직접 검사한다
종료 코드 0은 프로세스가 정상 종료됐다는 신호이지 결과 내용의 완성 판정이 아니다. 공식 방법론은 파일 형식, 압축 구조, 픽셀·오디오·길이 등 산출물에 맞는 검사를 요구한다. 실제 프로그램이 없으면 성공으로 꾸미거나 조용히 건너뛰지 않도록 한다.
견적서라면 수식과 계산값을, PDF라면 페이지와 글자·도형을, 렌더 이미지라면 실제 출력과 장면 조건을 확인해야 한다. 마지막에 원래 앱으로 다시 열어보는 과정도 유용하다.
6. 개발 코드와 설치된 실행 파일을 따로 검증한다
소스 디렉터리에서 모듈을 실행한 결과와 에이전트가 PATH에서 찾는 명령의 결과는 다를 수 있다. 공식 빠른 시작 문서는 CLI_ANYTHING_FORCE_INSTALLED=1을 사용하는 테스트 방법을 안내한다.
이 변수를 해석하는 테스트 헬퍼는 설치된 명령을 요구하고 개발용 모듈 실행으로의 대체를 막는다. 시스템 전역에 설치해야 한다는 뜻은 아니며, 변수 하나가 모든 테스트를 자동으로 바꾸는 것도 아니다.
설치 명령을 검증했다는 사실도 운영 환경 전체의 안정성 증명은 아니다. 실제 앱 버전, 글꼴, 파일 권한, 경로와 입력 자료에 따른 확인은 여전히 필요하다.
CLI-Hub로 시작할 때는 설치할 대상을 먼저 살핀다
CLI-Hub 안내는 하네스를 찾아보고 설치·관리하는 경로를 제공한다. 다만 목록에 있다는 사실만으로 같은 수준의 유지보수·검증·안전성을 갖췄다고 보지는 말자.
이미 해당 명령이 설치된 환경이라면 아래와 같은 조회부터 시작할 수 있다. 설치·실행 결과를 이 글에서 재현한 명령은 아니다.
cli-hub info inkscape
cli-anything-inkscape --help
설치할 때는 패키지 출처, 원래 앱의 요구사항, 지원 기능과 변경 권한을 확인하자. 외부 스킬 문서를 읽는 것과 그 문서가 지시하는 설치·명령 실행을 승인하는 것도 별개다. 작은 시험 환경에서 필요한 범위부터 검토하는 편이 낫다.
플러그인 생성 명령과 일반 셸 명령도 혼동하지 말자. 문서에 나온 예제 경로를 그대로 복사하기보다 자신이 설치한 코딩 에이전트와 하네스의 현재 안내를 기준으로 해야 한다. Windows 역시 쉘·앱·하네스별 조건을 확인할 문제이지, 한 영상의 환경을 모든 설치에 그대로 적용할 수는 없다.
첫 자동화 요청에는 수정 범위와 확인 방법을 함께 쓴다
처음에는 반복 작업 하나를 고르고 원본의 사본으로 시험해 보자. 아래는 세 영상의 공통 원칙을 반영한 요청 예시다.
설치된 CLI-Anything 하네스의 도움말과 현재 프로젝트 상태를 먼저 확인해라.
지원되지 않는 명령이나 앱 기능을 추측해서 사용하지 마라.
원본은 보존하고 사본에서 지정한 문구와 수량만 수정해라.
표의 수식을 유지하고 계산 결과를 확인해라.
필요한 변환·렌더 엔진이 없으면 대체 결과를 만들지 말고 보고해라.
중간 상태 파일, 편집 가능한 원본, 최종 내보내기 파일을 구분해라.
실행 로그와 실제 결과물 검사 내용을 함께 보고해라.
확인하지 못한 항목은 미확인으로 남겨라.
외부 설치·삭제·배포·공유 설정 변경은 먼저 승인을 받아라.
포스터라면 텍스트와 도형이 편집 가능한지, 견적서라면 수식과 합계가 맞는지, 3D 작업이라면 장면과 렌더 파일이 열리는지 확인한다. 명령 실행 기록과 최종 산출물을 함께 남겨야 다음 수정도 이어가기 쉽다.
모든 앱의 GUI를 대체한다는 기대는 내려놓는다
기술보고서는 구조화 명령·명시적 상태·예측 가능한 피드백이라는 상호작용 방식을 제안한다. 이것을 모든 앱에서 화면 자동화보다 일정 비율 빠르거나 저렴하다는 보편적 성능 보장으로 읽지는 말자.
첫 영상은 제작자가 AI 생성 요약이며 직접 실행하지 않았다고 밝힌 자료다. Alex Hitt 영상의 명령·JSON·검증 그림도 여기서는 구조 설명으로 사용했지 독립 실행 로그로 평가하지 않았다. 단테 실습은 편집과 결과 확인의 사례지만 특정 버전과 수정 조건이 있다.
실무에서는 하네스가 지원하는 반복 동작은 명령으로 연결하고, 시각적 품질 판단이나 아직 노출되지 않은 기능은 앱에서 확인하는 혼합 방식으로 시작해 볼 수 있다. 자동화의 가치는 화면을 안 열었다는 사실보다, 의도한 변경과 검증 가능한 결과물을 남겼는지에서 판단하는 편이 좋다.
함께 읽을 글
참고자료
- AI-Native Software Engineer, 에이전트용 CLI 설계 규칙
- 단테, Inkscape·LibreOffice·Blender 실습
- Alex Hitt, CLI-Anything 구조와 검증 개요
- CLI-Anything 공식 저장소
- 하네스 설계·테스트 방법론
- CLI-Hub 사용 안내
- CLI-Anything 기술보고서
확인 기준일은 2026년 11월 12일이다. 단테가 명시한 커밋은 34f519533bc175d2fe287ab8316b0dd99bb9cc43이며, 조회한 main도 같은 커밋이었다. 다만 영상의 LibreOffice 로컬 수정까지 그 커밋에 포함됐다는 뜻은 아니다. 캡처는 설명·비평을 위한 원영상 인용이다. 가상 견적의 산술 검산과 실제 앱의 재계산·렌더 시험은 구분했으며, 후자는 블로그에서 재현하지 않았다.
FAQ
CLI-Anything을 설치하면 앱 본체 없이 모든 작업을 할 수 있나요?
아니다. 중간 상태나 파일 내용을 구성할 수 있는 단계와 실제 앱 엔진이 필요한 변환·렌더 단계가 다르다. 앱별 요구사항과 지원 명령을 확인해야 한다.
JSON 응답이나 종료 코드 0이면 완료로 봐도 되나요?
그것만으로는 부족하다. 명령의 상태와 산출물의 형식·내용·계산·렌더 결과를 나눠 검사해야 한다. 결과 파일이 존재해도 의도한 내용이 맞는지는 별도다.
CLI-Hub와 CLI 하네스 생성은 같은 기능인가요?
CLI-Hub는 제공되는 도구를 발견하고 설치·관리하는 경로이고, 하네스 생성은 대상 소프트웨어의 기능을 명령으로 연결하는 개발 과정이다. 여기에 원래 앱의 설치까지 별도로 필요할 수 있다.
기존 GUI 작업을 모두 버려야 하나요?
그럴 필요는 없다. 지원되는 반복 작업은 CLI로 연결하고, 시각적 품질이나 미지원 기능은 앱에서 확인할 수 있다. 범위를 좁혀 검증한 뒤 확장하는 편이 현실적이다.