이 접근이 실제로 효과적인지 검증된 근거가 없음이라 느껴짐
에이전트가 JSON 스키마와 CLI 스킬을 조회하는 과정에서 토큰 낭비가 많아질 것 같음
인간보다 AI 에이전트 중심으로 설계하는 건 미래지향적이지 않다고 생각함. 세상 대부분은 여전히 인간 중심으로 설계되어 있고, 결국 에이전트 개발자들은 인간 설계에 적응하도록 만들 유인이 있음
또 이런 CLI 디자인은 LLM 학습 데이터에 익숙하지 않아, 오히려 더 많은 토큰을 써서 이해하려 할 것 같음
사람들은 LLM의 L이 Language라는 걸 종종 잊는 듯함. 인간 언어가 학습 데이터의 대부분을 차지하므로, 인간에게 잘 설계된 CLI는 에이전트에게도 잘 맞음
다만 불필요하게 긴 페이지를 덤프하지 않는 게 중요함. 사실 인간에게도 그런 건 좋지 않음
CLI 스킬이라 해봐야 일반적인 사용법과 도움말 시스템 설명 몇 줄이면 충분하다고 생각함
John Carmack이 1년 전에 비슷한 관찰을 했음 — 트윗 링크
모든 앱 기능을 텍스트 인터페이스로 접근 가능하게 만드는 게 중요하다고 했음. GUI를 LLM이 직접 조작할 수도 있지만, CLI를 감싼 형태로 만드는 게 훨씬 합리적이라고 함
Andrej Karpathy도 최근에 같은 의견을 냈음 — 트윗 링크
그는 CLI가 “레거시 기술이지만 AI가 자연스럽게 사용할 수 있는 인터페이스”라며 흥미롭다고 표현함
이런 아이디어는 흥미롭지만, 그래픽 편집 툴처럼 비정형 데이터를 다루는 도메인에서는 텍스트 기반 접근이 어렵다고 느낌
편집 대상의 기하학적 의미를 잃지 않고 텍스트로 표현하기 힘들기 때문임. 이런 영역에서는 멀티모달 모델이나 특화 데이터 학습이 필요할 것 같음
LLM이 텍스트 기반 도구를 제대로 쓰지 못해 도구 쪽을 바꿔야 한다는 점이, 얼마나 ‘인공적인 지능’ 인지 보여주는 사례 같음
기사 내용이 AI 생성된 허풍처럼 느껴짐. 예전 이미지 생성기 때처럼 복잡한 템플릿이 필요하다고 주장하지만, 최신 모델은 인간의 어수선한 입력도 잘 이해함
LLM도 기존 CLI를 충분히 사용할 수 있음. 다만 “사실 아무것도 바꿀 필요 없다”는 내용으로는 화제성 있는 글을 쓰기 어렵겠지
나는 지금 CLI를 직접 만들고 있음 docs 명령으로 문서 경로를 출력하고, --path 플래그로 특정 문서를 표시하도록 했음. 각 문서는 400줄 이하로 유지함
여기에 임베딩 기반 검색을 추가해 "how do I install x?" 같은 질문으로 문서를 찾을 수 있게 함
이 패턴이 정말 잘 작동했고, i18n 지원도 붙였음
이 구조가 마음에 듦. 특히 임베딩 검색이 인상적임. 그런데 모델과 임베딩이 바이너리 크기에 얼마나 영향을 주는지 궁금함
기사에서 에이전트가 문서화된 플래그보다 JSON 기반 CLI를 더 잘 다룬다고 주장하는데, 직관적으로 납득이 안 됨. 그 가정은 어떻게 검증된 걸까 궁금함
복잡한 JSON을 플래그로 쓰는 CLI를 직접 만들어보면 느낌이 올 것 같음 :)
CLI를 JSON으로 호출한다는 건 결국 RPC를 다시 만드는 것처럼 보임. 스키마는 LSP가 제공하는 기능과도 유사함
차라리 에이전트가 CLI를 감싸는 코드를 작성·실행하게 하는 게 낫지 않을까 생각함
PowerShell은 이미 구조화된 입력과 출력을 지원하지 않나?
“이번 주의 SOAP 에피소드 이후엔 혼란이 사라질 것”이라며 농담함 — SOAP 위키 링크
나는 이 의견에 강하게 반대함. CLI는 만들어야 하지만, 에이전트용으로 설계할 필요는 없음
인간을 위한 좋은 man 페이지나 --help 문서를 제공하면 충분함
진짜 AI라면 Unix 스타일 명령을 스스로 이해하고 사용할 수 있어야 함. 실제로 내 경험상 그렇게 작동함
인간이 -h 옵션으로 새 프로그램을 익히듯, 로봇도 그 정도는 해야 진짜 지능이라 생각함
다만 인간은 몇 번 쓰면 옵션을 기억하지만, AI는 매번 --help를 다시 호출해야 함
그래서 자주 쓰이는 gh 같은 도구는 이미 학습 데이터에 포함되어 있을 가능성이 높음
“에이전트가 인간보다 10배 빠르게 코드를 쓴다”면서도, 정작 CLI를 단순화해야 작동한다는 점이 아이러니하게 느껴짐