인공지능 시대에 가장 오래된 형태의 상호작용이 다시 주목받는 이유는 무엇일까요?

이 기사는 기계로 번역되었습니다
원문 표시
명령줄 인터페이스는 AI 에이전트에게 가장 사용자 친화적인 인터페이스일 수 있습니다.

기사 작성자 및 출처: 마이너리티 리포트

2025년과 2026년 사이에 주요 AI 기업들은 차례로 CLI 기반 에이전트 도구라는 제품을 출시했습니다.

앤트로픽은 터미널에서 실행되는 AI 프로그래밍 도우미인 클로드 코드(Claude Code)를 출시했고, 오픈아이디(OpenAI)는 코덱스 CLI(Codex CLI)를, 구글은 제미니 CLI(Gemini CLI)를 출시했습니다. 이 시기에 거의 모든 주요 AI 기업들이 명령줄 환경에 집중했습니다.

이는 직관에 반하는 현상입니다. 명령줄 인터페이스는 1970년대의 산물이고, GUI는 컴퓨터를 대중화했으며, 이제 모바일 인터넷 시대에는 터치스크린이 기본으로 자리 잡았습니다. 논리적으로 볼 때 기술은 점점 더 "시각적"이고 "사용하기 쉬운" 방향으로 나아가야 합니다. 그런데 왜 인공지능 시대에 가장 오래된 형태의 상호작용 방식이 다시 주목받고 있는 것일까요?

해답은 감정이 아니라 공학적 논리입니다.

GUI는 AI 친화적이지 않습니다.

GUI는 인간의 시각적 탐색을 위해 설계되었습니다. 버튼, 팝업, 드래그 앤 드롭, 마우스 오버 효과와 같은 상호작용 방식은 인간의 시각적 직관에 기반합니다. 사람들은 인터페이스를 훑어보고 버튼 위치를 파악하여 직관적으로 다음 동작을 결정합니다. 이러한 메커니즘은 인간에게 매우 자연스러워서 거의 학습 곡선이 필요하지 않습니다.

하지만 LLM은 전혀 그런 식으로 작동하지 않습니다. LLM은 토큰을 입력으로 받고 토큰을 출력으로 내보냅니다. LLM의 "사고"는 픽셀 공간이 아닌 언어 공간에서 일어납니다.

인공지능이 GUI를 제어하도록 한다는 것은 엄청난 난관을 극복해야 한다는 것을 의미합니다.

인터페이스를 이해하는 데 드는 비용은 매우 높습니다. AI는 어떤 버튼을 클릭할 수 있는지, 어떤 입력 상자가 어디에 있는지, 현재 팝업 창이 무엇을 의미하는지 등을 "이해"하기 위해 컴퓨터 비전이나 접근성 트리에 의존해야 합니다. 이는 AI의 강점이 아니라 오히려 추가적인 부담입니다.

상태는 암묵적이고 예측 불가능합니다. 같은 버튼이라도 오늘은 클릭 가능하지만, 내일은 특정 조건 때문에 비활성화될 수 있습니다. 이러한 암묵적인 상태는 인간에게는 "맥락"이지만, 인공지능에게는 불확실성을 의미합니다. 인공지능은 "어떤 조건에서 이 작업이 가능한지"를 확실하게 추론할 수 없습니다.

작업은 결합할 수 없습니다. 두 개의 GUI 작업을 파이프라인 방식으로 연결할 방법이 없습니다. "검색 결과 → 필터 → 내보내기"는 GUI에서 세 번의 클릭이 필요한 작업이며, 전체를 하나의 작업으로 묶어서 전달, 재사용 또는 자동화할 수 없습니다.

테스트 및 검증이 어렵습니다. AI가 GUI 작업을 성공적으로 수행했는지 어떻게 확인할 수 있을까요? 스크린샷을 찍고 인터페이스 상태를 분석해야 하는데, 전체 피드백 과정이 느리고 불안정합니다.

반면, CLI의 모든 기능은 인공지능을 위해 특별히 설계된 것처럼 보입니다.

AI 에이전트를 위한 CLI의 세 가지 주요 장점: 구성 가능성

유닉스 철학의 핵심은 "각 프로그램은 한 가지 일만 잘 수행하며, 프로그램들은 서로 협력할 수 있다"는 것입니다.

수십 년 전의 이러한 설계 원칙은 인공지능 시대에 새로운 의미를 갖게 되었습니다.

CLI 도구는 표준 입력 및 출력 체인을 사용합니다. `linkly search "React performance optimization" | head -5`는 검색 결과를 다음 명령으로 전달합니다. `linkly search "architecture design" --json | jq '.results[].doc_id'`는 나중에 처리할 수 있도록 모든 문서 ID를 클레임.

AI 에이전트에게 있어 조합 가능성이란 여러 명령어를 연결하여 복잡한 다단계 워크플로우를 구성할 수 있고, 각 단계의 출력은 다음 단계에서 사용할 수 있는 구조화된 텍스트라는 것을 의미합니다. GUI 기반의 "클릭 → 대기 → 스크린샷 → 파싱"과 같은 반복적인 과정이 필요 없고, 깔끔한 입력과 출력만 존재합니다.

예측 가능성

각 명령어의 동작은 전적으로 매개변수에 의해 결정됩니다. 예를 들어 `--limit 10` 옵션을 사용하여 "데이터베이스"를 검색하면 (데이터베이스가 변경되지 않았다고 가정할 때) 오늘과 내일 모두 동일한 결과가 나옵니다. 암묵적인 상태 정보가 없으므로, 특정 기능이 이전에는 작동했지만 지금은 작동하지 않는 이유에 대한 혼란이 발생하지 않습니다.

이는 인공지능에 있어 매우 중요합니다. 인공지능이 도구에 대해 추론할 때, 도구의 입력값, 출력값, 그리고 부작용은 무엇인지에 대한 정신적 모델을 구축해야 합니다. GUI의 암묵적인 상태 정보는 이러한 정신적 모델을 불확실하게 만듭니다. 반면 CLI의 명시적인 매개변수는 이 정신적 모델을 신뢰할 수 있고 정확하게 만들어 줍니다.

`linkly read 42 --offset 80 --limit 100` 명령어는 해당 명령어의 의미가 전적으로 매개변수에 의해 결정됨을 의미합니다. 인공지능은 암묵적인 맥락을 추측할 필요 없이 그 동작을 정확하게 추론할 수 있습니다.

감사

모든 CLI 작업은 기록 가능한 텍스트 시퀀스입니다. AI가 실행하는 명령과 받는 출력은 모두 사람이 읽을 수 있는 텍스트입니다.

이러한 투명성에는 두 가지 장점이 있습니다.

AI 자체적으로는 자가 점검을 수행할 수 있습니다. "이전 linkly 검색에서 'contract template'을 검색한 결과 0건이 나왔는데, 이는 키워드가 잘못되었음을 나타냅니다. 'contract template'을 대신 사용해 보세요." 이러한 텍스트 기반 자가 수정 기능은 AI 에이전트의 안정적인 작동을 위한 기반입니다.

사람의 경우, 구현 후 검토가 가능합니다. AI가 실행한 명령, 각 단계의 입력 및 출력, 전체 추론 과정을 한눈에 확인할 수 있습니다. GUI 작업의 "클릭"은 추적하기 어렵지만, CLI 작업 로그는 자연스럽게 감사 기록으로 활용될 수 있습니다.

Linkly AI CLI 설계 사례

LinklyAI는 당사에서 자체 개발한 검색 엔진 및 지식 기반 구축 소프트웨어입니다. LinklyAI의 CLI 도구를 설계할 당시부터 AI 에이전트를 주요 사용자 중 하나로 고려했습니다.

세심하게 설계된 4가지 핵심 명령

Linkly AI CLI에는 핵심 명령어가 네 개뿐입니다.

이 네 가지 명령어는 유닉스 철학에 완벽하게 부합합니다. 각각은 단 하나의 기능만 수행하며 명확한 입력-출력 계약을 가지고 있습니다. AI 에이전트는 이 명령어들을 임의로 조합하여 복잡한 검색 프로세스를 구성할 수 있습니다.

일반적인 상담원 워크플로는 다음과 같습니다.

각 단계의 출력은 AI가 직접 소비하고 추론할 수 있는 구조화된 텍스트입니다. 사용자 인터페이스(GUI) 조작이 필요 없고 시각적 구문 분석에 대한 부담도 없습니다.

파이프 등과 결합됨

CLI의 또 다른 장점은 시스템 내의 다른 명령어와 자유롭게 조합하여 단일 도구의 한계를 뛰어넘는 새로운 기능을 구현할 수 있다는 점입니다.

필터링 및 클레임 : JSON 출력은 jQuery를 사용하여 필드를 직접 클레임 데 사용할 수 있으며, 추출된 결과는 다음 도구로 전달할 수 있습니다.

  • # 문서를 검색하고, doc_id 목록만 가져온 다음, 개요를 일괄적으로 검색합니다.
  • Linkly 검색 "데이터베이스 설계" --json | jq -r '.results[].doc_id' | xargs -I{} linkly 개요 {}

grep과 결합하여 2차 필터링을 수행하는 방법 : 먼저 의미 검색을 사용하여 범위를 좁힌 다음, 정확한 키워드를 사용하여 필터링합니다.

  • Linkly 검색 "아키텍처 설계" | grep -i "마이크로서비스|분산"

통계 및 분석 : wc, sort, uniq 등의 도구를 사용하여 문서 통계를 수행합니다.

  • # 통계 지식 기반에는 PDF 파일이 몇 개 있습니까?
  • linkly search "" --json | jq '.results[].type' | sort | uniq -c

스크립트와의 통합 : 셸 스크립트 내에서 반복적인 작업의 일괄 처리 및 자동화:

GUI 도구는 이러한 조합에 참여할 수 없습니다. CLI 도구는 텍스트 스트림을 출력하며, 이는 다른 모든 도구에서 사용할 수 있으므로 전체 시스템은 개별 도구의 단순한 합보다 훨씬 강력해집니다.

CLI는 MCP 브리징 방법 중 가장 간단한 방법이기도 합니다.

CLI와 MCP는 상호 배타적이지 않습니다. `linkly mcp` 명령 하나만으로 CLI를 MCP를 지원하는 모든 AI 클라이언트에서 사용할 수 있는 stdio MCP 서버로 전환할 수 있습니다.

JSON:

이는 HTTP MCP 서버를 직접 구성하는 것보다 훨씬 간단합니다. 사용자는 포트 번호를 알 필요도 없고, JSON에 URL을 수동으로 입력할 필요도 없으며, AI 클라이언트에게 "이 명령을 실행하세요"라고만 말하면 됩니다.

CLI는 MCP 생태계로 진입하는 관문이 되었으며, 사용자에게 거의 아무런 설정 과정도 요구하지 않습니다.

보다 광범위한 추세

Claude Code가 IDE 플러그인보다 CLI 형식을 우선시하기로 한 결정은 명확한 엔지니어링 논리에 기반합니다. IDE 플러그인은 호스트 환경에 제약을 받는 반면, CLI 도구는 터미널만 있으면 어디서든 실행할 수 있고, 어떤 에이전트에서든 호출할 수 있으며, 다른 어떤 도구와도 결합할 수 있기 때문입니다.

이는 보다 근본적인 원칙을 드러냅니다. AI 에이전트가 도구를 호출하는 본질은 명령을 실행하는 것입니다. 도구 호출(함수 호출/도구 사용)은 의미론적으로 CLI(명령줄 인터페이스)와 같습니다. 즉, 이름과 매개변수를 받으면 결과를 반환합니다. CLI 도구는 에이전트가 호출할 수 있는 자연스러운 함수이며, 변환 계층이 필요하지 않습니다.

"터미널을 새로운 IDE로"라는 표현은 AI 시대가 도래하기 훨씬 전부터 존재했지만, AI 시대에 들어서면서 완전히 새로운 의미를 갖게 되었습니다. 이는 단순히 "터미널에서 코드를 작성하는 것"을 넘어, "에이전트가 터미널을 통해 세상과 상호작용하는 것"을 의미합니다.

과거에는 CLI가 기술자 전용 도구였습니다. 하지만 미래에는 CLI가 에이전트의 보편적인 언어가 될 수 있습니다. 인간은 자연어를 통해 에이전트와 소통하고, 에이전트는 CLI를 통해 시스템과 상호작용하게 될 것입니다.

요약

GUI의 위상은 크게 영향을 받지 않을 것입니다. GUI는 여전히 사람이 컴퓨터를 직접 조작하는 데 가장 적합한 인터페이스이기 때문입니다. 하지만 AI 도구가 다른 도구를 호출해야 할 경우 CLI가 가장 자연스러운 연결 고리가 되며, 앞으로 더 많은 소프트웨어 개발사들이 에이전트의 사용 습관에 맞춰 CLI 도구를 출시할 것입니다.

터미널에서 문서를 검색해보고 싶으신가요? 다음 두 기사를 확인해 보세요. 터미널을 나가지 않고 AI로 문서를 검색하는 방법과 단 하나의 명령으로 30개 이상의 AI 도구가 로컬 파일을 읽는 방법을 소개합니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트