에이전트 시대, 대화형 CLI를 설계하는 세 가지 열쇠

메타데이터

• 원본 제목: Burn Your Flags: Interactive CLIs for Agents — Mark Lummus & Navinkumar Patil, PayPal
• 한국어 제목: 에이전트를 위한 대화형 CLI: 플래그를 태워버리다
• 채널: aiDotEngineer (YouTube 표기: AI Engineer)
• URL: https://www.youtube.com/watch?v=aV_vgUSatqs
• video_id: aV_vgUSatqs
• 발행일: 2026-10-11
• 처리일: 2026-10-12
• 발표자: Mark Lummus, Navinkumar Patil (PayPal)
• 자막: 영어 자동 자막을 기준으로 번역·정리함

📌 핵심 질문 / 대화형 CLI가 에이전트에게 필요한 이유

==에이전트가 사람처럼 대화형 CLI(Command-Line Interface)를 사용하지 못한다고 해서 모든 입력을 독립적인 플래그(flag)로 펼치는 것은 해법이 아니다. CLI가 사람에게 제공하던 안내·선택지·보호 장치를 유지하면서, 에이전트가 읽고 행동할 수 있는 상태·구조화된 데이터·맥락을 함께 제공해야 한다.==

• 에이전트는 Bash와 비대화형 명령에는 강하지만, 화살표 키를 기다리는 프롬프트를 질문이 아니라 화면 재그리기(redraw)로 인식할 수 있다.
• 플래그는 흐름이 미리 정해지고 옵션이 서로 독립적인 작업에 적합하지만, 앞선 답변이나 API 응답에 따라 다음 질문이 바뀌는 흐름에는 급격히 복잡해진다.
• tmux 세션, IPC(Inter-Process Communication) 사이드 채널, JSON 상태, 컨텍스트 주입(context injection)은 에이전트에게 필요한 정보와 조작 경로를 제공한다.
• 에이전트가 사용할 CLI는 LLM의 비결정성에 기대지 않고, 작고 날카로우며 명령에 같은 결과를 돌려주는 결정적(deterministic) 도구여야 한다.

Mark Lummus는 PayPal 개발자 도구 부문을 이끌고, Navinkumar Patil은 개발자 도구 팀의 기술 리더로 일한다. 두 사람은 사람용 인터페이스와 에이전트용 인터페이스를 똑같이 취급하지 말고, 새로운 독자인 에이전트에 맞춘 접근성(accessibility) 설계를 시작점으로 삼자고 제안한다. 설명과 실습은 PayPal Cafe의 가상 커피 주문 CLI인 Barista 9000을 에이전트가 통과하도록 고치는 워크숍으로 이어진다.

1. CLI의 귀환과 사람-에이전트 인터페이스의 차이

1.1. 오래된 터미널이 다시 중요해진 배경

1. CLI의 역사적 경험

   1. 초기 개발 환경: Mark는 MS-DOS와 Windows 이전 시절을 회고하고, 졸업 직후 임베디드 시스템을 만들 때 직렬 포트(serial port)로 컴퓨터에 연결한 뒤 VT100 호환 터미널에서 명령을 입력했다고 설명한다.
   2. 개발 환경의 변화: Navinkumar는 Java 개발을 위해 Eclipse를 사용하다가 JetBrains IntelliJ로 이동했고, Microsoft VS Code가 등장하면서 개발 환경의 선택지가 크게 늘었다고 말한다.
   3. AI 개발 환경의 등장: Cursor와 Windsurf 같은 AI 기반 개발 환경이 생겼어도 CLI는 계속 남아 있었다. Mark는 CLI가 사라질 것이라 생각했던 시기가 있었지만, “돌아왔다(Hello, we’re back)”라는 영화 The Hangover의 대사를 빌려 AI 시대에 CLI가 귀환했다고 표현한다.

2. 클라우드와 에이전트가 만든 재부상

   1. 클라우드의 영향: 클라우드 컴퓨팅은 CLI를 다시 대중적인 도구로 만들었고, 사용자는 명령줄에서 클라우드 기능에 접근할 수 있게 됐다.
   2. 에이전트의 도구화: Codex와 같은 모델을 포함한 소프트웨어 에이전트는 원하는 기능을 노출하기 위해 CLI 도구를 계속 사용한다. 에이전트가 CLI를 새 사용자가 되면서, 사람에게만 맞춘 터미널 설계는 한계를 드러낸다.

1.2. 대화형 CLI의 조용한 실패

1. 사람이 보는 질문과 에이전트가 보는 출력의 불일치

   1. 화살표 키 프롬프트: 대화형 CLI는 다음 선택지를 화살표 키로 고르게 하고, 사람에게는 현재 선택과 가능한 옵션을 선명하게 보여준다.
   2. 재그리기 루프: 에이전트의 실행 환경은 프롬프트를 질문으로 해석하지 못하고 화면을 계속 다시 그리는 루프로 볼 수 있다. 에이전트는 어떤 키를 보내야 하는지 알지 못한 채 멈춘다.
   3. 오류 신호의 부재: 테스트 도구가 사용자 인터페이스의 상태만 확인하면 명령 자체의 오류가 나타나지 않는다. 실패는 예외도, 에러 메시지도 없이 조용히 끝나므로 호출자는 무엇이 잘못됐는지 알 수 없다.

2. 플래그가 유효한 범위와 무너지는 지점

   1. 플래그가 잘 맞는 작업: 흐름을 미리 알고 있고 한 번에 실행하며, 각 옵션이 다른 옵션과 독립적인 단순 작업은 --size, --milk 같은 플래그로 안정적으로 처리할 수 있다.
   2. 조합 폭발: 모든 가능한 흐름을 플래그로 미리 표현하려 하면 옵션 수가 곱셈처럼 늘어난다. 앞선 답변이 뒤의 질문을 바꾸는 순간, 독립적인 플래그라는 가정이 깨진다.
   3. 환경 의존성: CLI가 API를 호출하고 그 응답에 따라 새로운 질문을 띄우거나, 현재 재고와 정책에 따라 허용 옵션을 바꾸면 플래그만으로는 흐름을 표현하기 어렵다. 보호 장치와 승인 단계도 대화형 흐름에 포함될 수 있다.

1.3. 자동화 프로그램과 에이전트의 차이

1. 미리 결정된 자동화

   1. 자동화 프로그램은 정해진 입력과 순서를 그대로 실행하며, 스스로 질문하거나 방향을 바꾸지 않는다.
   2. 플래그 기반 호출은 이런 결정된 자동화에 적합하다. 모든 결정을 호출자 또는 사전에 작성된 스크립트가 내려야 한다.

2. 판단하는 에이전트

   1. 에이전트는 생각하고, 상호작용하고, 질문하고, 다시 시도하고, 필요하면 뒤로 물러날 수 있다.
   2. 에이전트는 안내된 의사결정 트리를 따라갈 수 있으므로, 모든 분기를 하나의 거대한 플래그 집합으로 납작하게 만들 필요가 없다.
   3. 사람과 에이전트 모두에게 안전장치와 guidance를 제공해야 하지만, 두 독자가 같은 능력을 가진다고 가정해서는 안 된다. Navinkumar는 이를 사람을 위한 접근성 설계와 같은 규율이지만 새로운 독자를 대상으로 하는 문제라고 설명한다.

2. Barista 9000 워크숍과 문제 정의

2.1. 실습 과제의 구성

1. 커피 주문 CLI

   1. Barista 9000은 커피 주문을 받는 대화형 CLI다. 에이전트가 프록시를 통해 실행하면 상호작용 처리 문제 때문에 실패하도록 설계됐다.
   2. PayPal Cafe 저장소에서 CLI를 내려받을 수 있고, get CLI 버튼과 PayPal Cafe/rules 경로에서 실행 규칙을 확인할 수 있다.
   3. 참가자는 초기 명령을 실행하고 init 명령으로 자신의 이름 또는 닉네임을 등록한 다음 커피를 주문한다.

2. 경쟁 방식

   1. 참가자는 CLI를 직접 고치고 에이전트 프록시를 통해 실행한다. 프록시는 결과 일부를 서버로 전송하며 서버가 리더보드(leaderboard)를 갱신한다.
   2. 최고 성적의 참가자에게 현장에서 가져갈 수 있는 Mac Mini를 준다. Mark는 Mac Mini를 준비하는 일 자체도 쉽지 않았다고 농담한다.
   3. 규칙에는 창의적인 구현을 막는 제한이 거의 없다. 주최자는 참가자들이 화면 파싱, 사이드 채널, 컨텍스트 주입 또는 에이전트 기반 자동 수정 등 어떤 방법도 시도하기를 원한다.

2.2. 워크숍 운영과 초기 실험

1. 단계적으로 제공되는 힌트

   1. 주최자는 모든 참가자가 저장소를 설치하고 원본 CLI를 실행할 때까지 힌트를 주지 않기로 했다.
   2. 충분한 사람이 시작하면 15~20분 간격으로 “좋은 아이디어”를 하나씩 공개한다. 두 발표자는 아직 에이전트용 CLI의 이상적인 실천법을 모르는 초기 단계이므로, 힌트를 완성된 표준이 아니라 탐색용 제안으로 규정한다.
   3. 발표 중 기술적 문제가 생겨 웹사이트 링크와 get CLI 위치를 다시 확인하고, 참가자에게 손을 들어 도움을 요청해 달라고 안내한다. 실제 진행 시간은 약 25~30분으로 잡았다.

2. 모델 선택과 비용

   1. 가장 강력한 최신 대형 언어 모델의 높은 사고 모드(thinking mode)를 쓰면 무차별 대입으로 문제를 통과할 가능성이 높다.
   2. 그러나 CLI 하나를 실행하는 데 고가의 고사고 모델과 많은 토큰을 쓰는 것은 효율적이지 않다. Mark는 Claude의 Haiku나 Sonnet처럼 더 빠르고 저렴한 중간급 모델로도 해결할 수 있는지를 진짜 과제로 제시한다.
   3. 문제의 핵심은 “통과할 수 있느냐” 하나가 아니라, 토큰 예산(token budget)을 낭비하지 않으면서 에이전트와 CLI를 설계할 수 있느냐에 있다.

3. 현장 대화와 분위기

   1. Navinkumar는 커피라는 주제에서 샌프란시스코의 베이커리가 미국에서 최고라는 이야기를 꺼내고, Mark에게 동네 베이커리 투어 경험을 묻는다.
   2. 참가자들은 Butter and Crumble을 좋아하는 베이커리로 언급하고, 특정 참가자 또는 팀의 점수가 리더보드 상단에 오르자 서로 따라잡으라고 농담한다.
   3. 이런 가벼운 대화 뒤에 init으로 이름을 등록하고 실습을 계속하라는 안내가 이어진다. 커피 주문이라는 친숙한 시나리오가 대화형 상태와 에이전트 제어 문제를 관찰하기 위한 테스트 하네스가 된다.

3. 에이전트가 대화형 CLI를 다루게 하는 세 가지 접근

3.1. 힌트 1 — tmux로 세션과 터미널 상태 보존

1. 기본 사용법

   1. 참가자는 먼저 tmux 세션을 시작하고 CLI의 help 명령을 입력해 가능한 동작을 확인한다. 도움말은 다른 명령을 시도하기 전에 에이전트가 사용할 수 있는 행동 공간을 알려주는 핵심 정보다.
   2. 에이전트는 키를 보내고 터미널 화면을 캡처해 현재 상태를 추정할 수 있다. 사람용 화면을 그대로 읽어야 한다는 비용은 남지만, 적어도 프로세스를 잃지 않고 대화형 세션을 유지할 수 있다.

2. 세션 격리와 장기 작업

   1. tmux는 여러 터미널 세션을 만들고 화면을 분할해 각각의 작업을 관리하게 한다.
   2. tmux -d 같은 분리(detach) 동작을 사용하면 CLI를 별도 세션에서 계속 실행한 채 호출자가 세션 밖으로 나올 수 있다.
   3. 여러 프록시를 동시에 돌릴 때 프록시마다 세션을 만들 수 있고, tmux가 작업 상태를 기록하므로 필요할 때 다시 붙어(resume) 확인할 수 있다.
   4. 장시간 걸리는 작업, 병렬 에이전트, 중단 후 재개가 필요한 작업에서 세션 보존이 특히 유용하다.

3.2. 힌트 2 — IPC 사이드 채널과 구조화된 JSON

1. 화면 파싱의 한계 보완

   1. tmux를 통한 화면 캡처는 사람에게 보이는 내용을 에이전트가 추론하게 하는 첫 단계다. 하지만 화면을 긁어오는(screen scraping) 방식은 재그리기와 레이아웃 변화에 취약하다.
   2. IPC(Inter-Process Communication) 사이드 채널은 현재 상태를 JSON으로 노출하고, 에이전트의 선택을 구조화된 입력으로 받는다.
   3. 사이드 채널은 화살표 키의 의미와 현재 선택지를 직접 알려주므로, 에이전트가 화면 픽셀이나 줄바꿈을 해석하는 부담을 줄인다.

2. REST API 비유

   1. Navinkumar는 사이드 채널을 웹 애플리케이션의 REST API에 비유한다. 웹 페이지는 사람이 보는 시각적 인터페이스이고, REST API는 기계가 읽는 구조화된 인터페이스다.
   2. 같은 CLI를 사람에게는 익숙한 화면으로 유지하면서, 에이전트에게는 현재 상태·가능한 명령·필요한 인수를 JSON으로 제공할 수 있다.
   3. CLI를 에이전트의 백그라운드에서 실행하고 상태를 읽으며 입력을 보내려면, 에이전트가 JSON 스키마와 각 필드의 의미를 알아야 한다.

3. Barista Pro 주문 데이터

   1. 예시 상태에는 Barista Pro Order와 같은 주문 정보가 나타나며, 커피 크기로 small, medium, large를 선택할 수 있다.
   2. 기본값은 large다. 이런 기본값과 허용 값은 사람이 화면을 보고 추론할 수도 있지만, 에이전트에게는 명시적인 구조화 데이터로 알려주는 편이 안전하다.
   3. 기계가 읽을 수 있는 입력 데이터와 상태 출력은 사람에게 보이는 안내를 대체하기보다, 같은 업무를 수행하는 두 독자에게 각각 적합한 읽기 경로를 제공한다.

3.3. 힌트 3 — 컨텍스트 주입과 에이전트용 guidance

1. 한 번에 제공하는 실행 맥락

   1. 사람은 CLI가 질문을 하나씩 보여줄 때마다 필요한 결정을 내리지만, 에이전트에게는 가능한 선택지·제약·질문 순서를 하나의 입력 파일이나 명시적인 컨텍스트로 제공할 수 있다.
   2. 에이전트는 컨텍스트를 바탕으로 어떤 질문을 사용자에게 다시 물어야 하는지, 어떤 선택이 금지됐는지, 언제 대안을 제시해야 하는지 판단한다.
   3. CLI는 사람용 대화 흐름을 유지하면서도, 에이전트가 의사결정 트리를 미리 이해할 수 있는 기술을 얻는다.

2. 오트밀크 재고 사례

   1. 매장에 오트밀크가 두 갤런만 남았다는 제약을 컨텍스트에 넣는다.
   2. 에이전트는 주문을 그대로 확정하지 않고, 두 갤런으로 충분한지 사용자에게 확인해야 한다.
   3. 충분하지 않다면 대체 재료를 고를지 물어야 한다. 재고 제약, 확인이 필요한 조건, 대안 질문을 컨텍스트로 주입하면 CLI가 모든 분기를 플래그로 노출하지 않아도 된다.

3. 세 접근의 관계

   1. 화면 파싱(screen scraping)은 구현 난도가 낮고 원본 CLI를 거의 건드리지 않는 출발점이다.
   2. 사이드 채널은 상태와 입력을 구조화해 피드백의 정확도를 높인다.
   3. 컨텍스트 또는 skill 주입은 에이전트가 어떤 시나리오와 제약을 고려해야 하는지 명시한다.
   4. 주최자의 최종 권고는 세 가지를 함께 사용하라는 것이다. 좋은 컨텍스트를 제공하고, 사이드 채널을 열고, tmux로 세션을 유지하면 에이전트가 대화형 CLI를 탐색할 출발점이 생긴다.

4. 리더보드가 드러낸 성능 지표의 한계

4.1. 정확도와 응답 시간의 점수 규칙

1. 동점 처리

   1. 여러 참가자가 5,000점을 얻으면 먼저 결과의 정확도를 비교하고, 동점일 때 걸린 시간을 비교한다.
   2. 즉, 우선순위는 정확한 결과이며, 같은 정확도라면 더 빠른 응답이 이긴다.
   3. 실제 리더보드에는 세 과제를 모두 0초에 끝낸 참가자들이 나타났다. 주최자는 원래 불가능하다고 생각했던 결과라며 시스템을 다시 확인해야 했다.

2. 현장 상태

   1. 많은 참가자가 4,000점에 도달했고, 5,000점에 접근한 참가자도 생겼다.
   2. 네트워크가 느려지거나 사이트가 잠시 내려가는 등 실제 실행 환경의 지연이 리더보드에 영향을 줬다.
   3. 최종적으로 Monk라는 참가자가 우승자로 불렸고, 주최자는 이미 결정을 내렸으니 마음을 바꾸지 않겠다고 농담했다.

4.2. 결정적 분석기와 벤치마크의 허점

1. 쉽게 조작되는 측정

   1. 한 참가자는 현재 지표가 단일 요청을 얼마나 짧은 시간에 실행했는지만 보므로 조작하기 쉽다고 지적한다.
   2. 서버와 가까운 곳에서 결정적 분석기(deterministic analyzer)를 실행하면 네트워크 왕복 시간을 줄일 수 있다.
   3. 반복적인 시행착오로 서버의 기대값을 알아내고, 실제 에이전트의 이해 과정 없이 정답을 반환하면 점수는 빨리 올라가지만 워크숍의 의도와는 멀어진다.

2. 그럼에도 결정적 CLI가 필요한 이유

   1. LLM은 비결정적(non-deterministic)인 판단을 내리는 계층이므로, 도구인 CLI는 반대로 결정적이어야 한다.
   2. 같은 명령을 받을 때 같은 결과를 내놓는 작고 날카로운 도구가 에이전트의 행동을 예측 가능하게 만든다.
   3. CLI 안에 또 다른 프록시를 넣고 그 프록시가 다시 에이전트에게 맡기면 결과의 변동성이 커진다. 어떤 응답을 받을지 알 수 없으므로, 명령줄 도구는 좁은 책임과 명확한 계약을 가져야 한다.

5. 참가자 구현과 질의응답

5.1. Bonc 프록시와 29밀리초 구현

1. 구현 방식

   1. Bonc라는 참가자 도구는 Claude Agent SDK 위에 만든 프록시이며, 참가자가 전체를 직접 구축했다고 설명한다.
   2. 참가자는 먼저 환경을 만들고 개선하는 “assessment testing” 스킬을 가지고 있었고, 그 스킬이 CLI 해결 도구를 자동으로 만들도록 발전했다.
   3. 도구는 tmux에서 실행되고 API 요청을 압축하거나 줄여 처리한다.

2. 모델과 운용

   1. 구현자는 Slack을 통해서만 도구를 관리한다고 답한다.
   2. CLI를 만든 모델로 Claude Agent SDK의 Opus 4.8을 사용했다고 말한다.
   3. 같은 지역에서 실행한 덕분인지 네트워크 지연이 약 29밀리초까지 내려갔다고 설명한다. 주최자는 다른 모델로도 시도했는지 묻지만, 구현자는 에이전트가 CLI를 만들고 tmux에서 실행하는 구조 자체가 핵심이라고 답한다.

5.2. 초보 프로그래머의 에이전트 기반 제작

1. 문제를 설명하고 수정시키기

   1. Danny라는 참가자는 프로그래밍을 거의 모르는 초보자라고 밝힌다.
   2. VS Code에서 Claude Code를 열고 “이 문제가 있다. 읽고 고쳐라”라고 요청하는 방식으로 여러 에이전트를 사용했다.
   3. CLI를 만들어 본 적은 없었지만, 대회 상품을 몇 시간 전에 보고 에이전트에게 문제를 다섯 살 아이에게 설명하듯 풀어 달라고 지시했다.

2. 속도 최적화 루프

   1. 첫 구현은 점수 49.98 정도를 기록했고, 참가자는 복사본을 만든 뒤 49.99까지 올릴 방법을 제안하라고 에이전트에게 맡겼다.
   2. 두 개의 스크립트를 실행하면서 에이전트가 문제를 찾아 수정하도록 했고, 시작점과 종료점만 알려 준 뒤 필요한 질문은 초기에 묻고 나머지는 자동으로 처리하라고 지시했다.
   3. 이 사례는 CLI 구현 자체를 사람이 직접 작성하지 않아도, 요구사항·성능 목표·종료 조건을 명확히 주면 에이전트가 설계와 개선을 이어갈 수 있음을 보여준다.

5.3. 주최자의 최종 정리

1. 에이전트에게 맡길 세 가지

   1. 에이전트에게 CLI를 만들게 하면서 빠르고(imperative), 결정적이며, 한 가지 책임에 집중하도록 요구한다.
   2. 충분한 컨텍스트를 제공해 사용자 질문과 정책·재고·안전 제약을 판단할 수 있게 한다.
   3. 상태와 선택지를 사이드 채널로 열고, tmux를 사용해 세션과 상호작용 상태를 유지한다.

2. 설계 원칙의 요지

   1. 사람용 화면을 억지로 에이전트에게 읽히는 방식은 첫 실험에는 쓸 수 있지만, 안정적인 통합을 위해서는 구조화된 상태와 명시적인 컨텍스트가 필요하다.
   2. 플래그는 모든 분기를 담는 거대한 API가 아니라, 독립적인 입력을 받는 단순한 작업에서만 사용한다.
   3. 대화형 흐름이 가진 guidance와 guardrail을 버리지 않고, 사람과 에이전트가 각자 읽을 수 있는 두 개의 접근 경로를 제공하는 것이 장기적인 해법이다.

주요 발언 모음

“플래그는 단순한 사용 사례와 미리 알려진 흐름에는 좋지만, 맥락이나 즉각적인 사건에 따라 답이 바뀌면 정말 어려워진다.” — Mark Lummus

“에이전트는 생각하고, 상호작용하고, 질문하고, 다시 시도하고, 뒤로 물러날 수 있다.” — Mark Lummus

“사람을 위해 하던 것과 에이전트에게 필요한 것을 연결하면 해법이 선명해진다. 같은 규율이지만 새로운 독자다.” — Mark Lummus

“사이드 채널은 웹 애플리케이션의 REST API와 같다. 웹사이트가 사람을 위한 시각적 인터페이스라면 API는 기계를 위한 구조화된 인터페이스다.” — Navinkumar Patil

“LLM은 여기서 비결정적인 쪽이고, CLI는 작고 날카로운 도구여야 한다.” — Mark Lummus

“좋은 컨텍스트, 사이드 채널, 그리고 tmux를 사용하라고 알려주는 것이 시작하기 좋은 세 가지다.” — PayPal 워크숍 정리

핵심 데이터 & 수치

• 영상 길이: 53분 42초
• YouTube 발행일: 2026-10-11
• 워크숍 진행 시간: CLI 실행 후 약 25~30분, 힌트는 대략 15~20분 간격으로 공개
• 상품: 최고 성적 참가자에게 Mac Mini 제공
• 리더보드 기준: 결과 정확도를 먼저 보고 동점이면 응답 시간을 비교
• 현장 점수: 4,000점대 참가자가 다수 등장했고 5,000점에 도달한 참가자들이 생김
• 이상 기록: 세 과제를 0초에 끝낸 기록이 여럿 나타나 벤치마크의 허점을 드러냄
• 오트밀크 사례: 재고가 두 갤런만 남으면 충분한지 확인하고 대안을 물어야 함
• 참가자 구현 지연: Claude Agent SDK 기반 도구가 약 29밀리초를 기록했다고 보고됨
• 모델 선택 논점: 최고급 사고 모델의 무차별 대입보다 Haiku·Sonnet 같은 빠르고 저렴한 모델의 실용성이 과제의 관심사

결론 및 시사점

1. 대화형 CLI는 앞선 답변과 외부 상태에 따라 다음 질문을 바꾸고, 사용자의 실수를 막는 보호 장치를 제공하므로 모든 기능을 독립적인 플래그로 바꾸면 가치와 안전성이 함께 사라진다.
2. 에이전트의 실패를 단순히 “모델이 약해서”라고 보지 말고, 사람이 보는 질문이 에이전트에게는 상태 없는 재그리기 루프로 보이는 인터페이스 불일치부터 점검해야 한다.
3. tmux는 세션을 보존하고 키 입력과 화면 상태를 연결하는 현실적인 첫 단계이며, 장기 실행·병렬 프록시·중단 후 재개에 특히 유용하다.
4. IPC 사이드 채널은 화면 파싱을 JSON 기반의 명시적 상태·입력 계약으로 바꾼다. 사람에게는 시각적 CLI를 제공하고 에이전트에게는 REST API와 같은 구조화된 경로를 제공하면 된다.
5. 컨텍스트 주입은 재고, 정책, 안전 제약, 대안 선택처럼 사람에게는 암묵적인 정보를 에이전트가 사용할 수 있는 guidance로 바꾼다.
6. LLM이 비결정적인 판단 계층을 맡을수록 CLI는 결정적이고 작고 명령형(imperative)이어야 한다. 같은 입력에 같은 결과를 주는 도구가 에이전트의 오류를 추적하고 재현하기 쉽다.
7. 정확도와 응답 시간만 측정하는 리더보드는 결정적 분석기·서버 근접 실행·시행착오로 쉽게 공략될 수 있으므로, 실제 에이전트의 이해·상호작용·토큰 비용을 함께 평가해야 한다.
8. 에이전트용 CLI의 실용적인 출발점은 tmux로 실행 상태를 붙잡고, 사이드 채널로 JSON 상태를 노출하며, 컨텍스트로 의사결정 규칙을 제공하는 세 요소의 결합이다.