26장 — CLI의 AI 에이전트

25장이 코드 없는 콘솔 화면이었다면, 이 장은 정반대 방향입니다. 개발자가 가장 오래 머무는 곳, 터미널로 에이전트가 들어옵니다.

개발자의 명령행은 오랫동안 정확하고 엄격한 명령어가 쓰이는 영역이었지만, 지금은 큰 변화를 맞고 있다. 단순한 셸에서 지능적이고 협업이 이루어지는 작업 공간으로 발전하고 있으며, 이 변화를 이끄는 것이 새로운 부류의 도구인 AI 에이전트 명령행 인터페이스(CLI) 다.

이러한 에이전트는 단순히 명령을 실행하는 데서 그치지 않습니다. 자연어를 이해하고, 코드베이스 전체의 맥락을 유지하며, 복잡한 다단계 작업까지 수행해 개발 수명 주기의 상당 부분을 자동화합니다.

이 장은 대표 도구 네 가지의 고유한 강점, 잘 맞는 사용 사례, 서로 다른 철학을 짚어 봅니다. 다만 책도 미리 짚어 두듯, 특정 도구의 사용 예로 든 것들 가운데 상당수는 다른 에이전트로도 해낼 수 있습니다. 이들 도구를 가르는 핵심은 같은 작업을 처리할 때 결과의 품질과 효율, 그리고 세부 결에서 드러나는 경우가 많고, 이런 역량을 측정하기 위한 전용 벤치마크도 있습니다(마지막 절에서 다룹니다).

클로드 CLI(Claude Code)

앤스로픽의 클로드 CLI는 프로젝트 구조 전반을 깊이 파악하도록 설계된 고수준 코딩 에이전트입니다. 가장 큰 강점은 ‘에이전틱’한 성격입니다. 복잡한 다단계 작업이 주어지면 저장소 전체에 대한 멘탈 모델을 스스로 만들어 냅니다.

사용자와 주고받는 방식도 자연스러운 대화에 가깝고, 실행에 앞서 자기 계획부터 풀어 보이는 모습은 마치 짝 프로그래밍을 함께하는 듯합니다. 그래서 전문 개발자에게 잘 맞습니다. 대규모 리팩터링이나 아키텍처 전반에 영향이 큰 기능을 구현해야 하는 상황일수록 그 진가가 드러납니다.

(옮긴이) 짝 프로그래밍(pair programming) 은 두 개발자가 한 작업을 함께 진행하는 작업 방식을 말한다. 여기서는 AI가 개발자의 옆에서 코드를 함께 읽고, 고치고, 검토하는 협업자처럼 동작한다는 의미다.

사용 사례

  1. 대규모 리팩터링: “현재 사용자 인증은 세션 쿠키에 의존한다. 로그인/로그아웃 엔드포인트, 미들웨어, 프런트엔드의 토큰 처리 로직까지 모두 바꿔서 코드베이스 전체를 무상태 JWT 방식으로 리팩터링해 줘.” 그러면 클로드는 관련 파일을 모두 읽어 들여, 서로 맞물린 변경을 한꺼번에 수행한다.
  2. API 통합: 새로운 날씨 서비스의 OpenAPI 명세를 제공한 뒤, “이 새로운 날씨 API를 통합해 줘. API 호출을 처리할 서비스 모듈을 만들고, 날씨를 표시할 새 컴포넌트를 추가한 뒤, 메인 대시보드에도 포함해 줘.”
  3. 문서 생성: 문서가 거의 없는 복잡한 모듈을 짚어 주며 “./src/utils/data_processing.js 파일을 분석해 줘. 함수마다 목적, 매개변수, 반환값을 설명하는 포괄적인 TSDoc 주석을 생성해 줘.”

클로드 CLI는 특화된 코딩 도우미 역할을 하며, 파일을 읽어 들이고 코드 구조를 분석하고 편집 내용을 생성하는 등 핵심 개발 작업에 필요한 도구를 처음부터 갖추고 있습니다. Git과도 깊이 맞물려 있어 브랜치와 커밋을 직접 관리하기 수월합니다. 또한 MCP로 확장할 수 있어서, 사용자가 직접 작성한 도구도 통합해 쓸 수 있습니다. 덕분에 비공개 API와 상호작용하거나 데이터베이스에 질의하고, 프로젝트별 스크립트도 실행할 수 있습니다. 이런 구조에서 개발자는 에이전트의 기능 범위를 결정하는 주체가 됩니다.

결국 클로드 CLI는 사용자가 정의한 다양한 도구로 확장된 추론 엔진에 가깝다.

세 사용 사례의 공통점은 여러 파일에 걸쳐 서로 맞물린 변경입니다. 인증 방식을 바꾸면 백엔드 엔드포인트, 미들웨어, 프런트엔드 토큰 처리가 동시에 바뀌어야 하고, 하나라도 빠지면 시스템이 깨집니다. 6장의 계획 수립이 “실행에 앞서 계획을 풀어 보이는” 방식으로, 10장의 MCP가 “사용자 정의 도구 확장”으로 들어가 있습니다.

제미나이 CLI

구글의 제미나이 CLI는 성능과 접근성을 모두 겨냥해 설계된 오픈소스 AI 에이전트로, 활용 범위가 넓습니다.

특징 내용
고급 모델 고급 모델인 제미나이 2.5 Pro와 방대한 컨텍스트 윈도를 사용
멀티모달 이미지와 텍스트를 함께 처리하는 멀티모달 기능이 두드러짐
무료 사용량 오픈소스라는 점, 넉넉한 무료 사용량
ReAct 루프 ‘Reason and Act’ 루프 덕분에 작동 방식이 투명하고 제어하기도 쉬움
Google Cloud 생태계 취미 개발자부터 기업 개발자, 특히 Google Cloud 생태계에서 일하는 개발자까지 두루 잘 맞음

사용 사례

  1. 멀티모달 개발: 디자인 파일에서 웹 컴포넌트 스크린샷을 하나 제공한 뒤(gemini describe component.png), “이와 똑같이 생긴 React 컴포넌트를 만드는 HTML과 CSS 코드를 작성해 줘. 반응형으로 동작하게 해 줘.”
  2. 클라우드 리소스 관리: 내장된 Google Cloud 통합 기능을 사용해 “프로덕션 프로젝트에서 1.28 이전 버전을 사용 중인 GKE 클러스터를 모두 찾아, 하나씩 업그레이드하는 gcloud 명령어를 생성해 줘.”
  3. 기업 도구 통합(MCP 활용): 개발자가 직접 작성한 get-employee-details라는 도구를 제미나이에게 제공한다고 하자. 이 도구는 회사 내부 HR API에 연결된다. 그러면 다음과 같은 프롬프트를 줄 수 있다. “신규 입사자를 위한 온보딩 문서를 작성해 줘. 먼저 get-employee-details --id=E90210 도구로 이름과 팀을 가져오고, 그 정보를 welcome_template.md에 채워 넣어 줘.”
  4. 대규모 리팩터링: 개발자가 더 이상 권장되지 않는 로깅 라이브러리를 새로운 구조화 로깅 프레임워크로 바꾸기 위해, 대규모 자바 코드베이스를 리팩터링해야 한다고 하자. 이때 제미나이에게 다음과 같이 지시할 수 있다. “src/main/java 디렉터리의 모든 *.java 파일을 읽어. 각 파일에서 org.apache.log4j import와 Logger 클래스를 모두 org.slf4j.LoggerLoggerFactory로 바꾸고, 로거 초기화 코드와 .info(), .debug(), .error() 호출도 키-값 쌍을 사용하는 새로운 구조화 형식에 맞게 다시 작성해 줘.”

제미나이 CLI는 주변 환경과 상호작용할 수 있도록 여러 내장 도구를 갖추고 있습니다. 파일 시스템을 읽고 쓰는 도구, 명령을 실행하는 셸 도구, 그리고 웹 페이지를 가져오거나 검색해 인터넷에 접근하는 도구가 여기에 해당합니다. 더 넓은 맥락을 파악할 때는 여러 파일을 한꺼번에 읽는 전용 도구와, 이후 세션에서 쓸 수 있도록 정보를 저장해 두는 기억 도구도 사용합니다. 이 모든 기능은 안전한 기반 위에 세워져 있습니다. 기반 중 하나인 샌드박싱은 모델의 작업을 격리해 위험을 막고, MCP 서버는 다리 역할을 하며 제미나이가 로컬 환경이나 다른 API에 안전하게 연결되도록 합니다.

네 번째 사용 사례의 요점은 “모든 *.java 파일을 읽어”입니다. 수백 개 파일을 한꺼번에 읽어도 담을 수 있는 방대한 컨텍스트 윈도가 있기에 가능한 지시입니다. 또 샌드박싱은 18장의 가드레일이 CLI 환경에서 구현된 모습입니다. 셸 명령을 실행할 수 있는 에이전트라면 rm -rf 한 줄이 곧 사고이기 때문입니다.

Aider

Aider는 파일을 직접 수정하고 변경 사항을 Git에 커밋하면서, 진짜 짝 프로그래머처럼 동작하는 오픈소스 AI 코딩 도우미입니다. 가장 두드러진 특징은 곧장 실행에 옮긴다는 점입니다.

  • 변경을 즉시 적용하고, 테스트를 돌려 검증한 뒤, 성공한 변경은 모두 자동으로 커밋한다.
  • 특정 모델에 묶이지 않아서 비용과 기능을 사용자가 직접 다룰 수 있다.
  • Git 중심으로 흘러가는 워크플로 덕분에, 효율과 직접 다루는 자유, 그리고 코드 변경 내역을 모두 투명하게 따라갈 수 있는 환경을 중시하는 개발자에게 잘 맞는다.

사용 사례

  1. 테스트 주도 개발(TDD): “숫자의 팩토리얼을 계산하는 함수를 만들 건데, 먼저 실패하는 테스트 파일을 작성해 줘.” Aider가 테스트를 작성한 뒤 그 테스트가 실패하면, 이어서 이렇게 지시하면 된다. “이제 테스트가 통과하도록 코드를 작성해 줘.” 그러면 Aider는 함수를 구현하고 테스트를 다시 실행해 통과 여부를 확인한다.
  2. 정밀한 버그 수정: 버그 리포트가 들어왔다고 하자. 그러면 Aider에게 다음과 같이 지시할 수 있다. “billing.pycalculate_total 함수가 윤년에 실패하네. 이 파일을 컨텍스트에 추가하고 버그를 수정한 뒤, 기존 테스트 스위트로 수정이 올바른지 검증해 줘.”
  3. 의존성 업데이트: 다음과 같이 지시할 수도 있다. “우리 프로젝트는 requests 라이브러리의 오래된 버전을 쓰고 있어. 모든 파이썬 파일을 살펴보면서 import 문과 더 이상 권장되지 않는 함수 호출을 최신 버전에 맞게 바꾼 뒤, requirements.txt도 업데이트해 줘.”

모든 성공한 변경이 곧 커밋이라는 설계가 Aider의 철학을 보여 줍니다. 에이전트가 실수하더라도 git log에 한 단계씩 남아 있으니 언제든 되돌릴 수 있습니다. TDD 사례는 4장의 리플렉션 루프를 그대로 옮긴 것인데, 비평 에이전트 대신 테스트 러너가 객관적인 비평자 역할을 합니다. LLM의 자기 평가보다 훨씬 믿을 만한 신호입니다.

GitHub Copilot CLI

GitHub Copilot CLI는 널리 쓰이는 AI 짝 프로그래머를 터미널로 확장한 도구입니다. 가장 큰 장점은 GitHub 생태계와 처음부터 깊이 맞물려 있다는 점입니다. 이 도구는 GitHub 안에서 프로젝트 맥락을 이해합니다. 또한 에이전트 기능 덕분에 GitHub 이슈를 할당받아 수정 작업을 진행하고, 사람이 검토할 수 있도록 pull request를 제출합니다.

사용 사례

  1. 이슈 자동 해결: 관리자가 버그 티켓을 Copilot 에이전트에게 할당한다고 하자. 예를 들어 “이슈 #123: 페이지네이션의 off-by-one 오류 수정” 같은 식이다. 그러면 에이전트는 새 브랜치를 체크아웃하고 코드를 작성한 뒤, 해당 이슈를 참조하는 pull request를 제출한다. 이 모든 과정에 개발자가 직접 손댈 필요가 없다.
  2. 저장소 맥락 기반 질의응답: 팀에 새로 합류한 개발자는 다음과 같이 물을 수 있다. “이 저장소에서 데이터베이스 연결 로직은 어디에 정의되어 있고, 어떤 환경 변수가 필요한가?” 그러면 Copilot CLI는 저장소 전체를 파악하고 있어, 파일 경로까지 짚어 가며 정확한 답을 내놓는다.
  3. 셸 명령어 도우미: 복잡한 셸 명령어가 헷갈릴 때, 사용자는 다음과 같이 물을 수 있다. gh? find all files larger than 50 MB, compress them, and place them in an archive folder. 그러면 Copilot은 해당 작업에 필요한 정확한 셸 명령어를 만들어 준다.

첫 번째 사례에서 “개발자가 직접 손댈 필요가 없다”는 말에는 단서가 붙어 있습니다. 결과물이 곧바로 머지되는 것이 아니라 pull request로 올라온다는 점입니다. 13장의 휴먼 인 더 루프를 새로 만들지 않고, 개발팀이 이미 쓰고 있는 코드 리뷰 절차를 승인 게이트로 그대로 재사용한 셈입니다.

네 도구 비교

  클로드 CLI 제미나이 CLI Aider GitHub Copilot CLI
만든 곳 앤스로픽 구글 (오픈소스) 오픈소스 GitHub
책이 꼽은 강점 프로젝트 전체의 멘탈 모델, 계획을 먼저 풀어 보이는 대화 방대한 컨텍스트, 멀티모달, 무료 사용량, 투명한 ReAct 루프 즉시 실행·테스트·자동 커밋, 모델 선택 자유 GitHub 이슈 → 브랜치 → PR
확장 방식 MCP로 사용자 정의 도구 MCP 서버, 내장 도구(파일·셸·웹·기억) 모델 교체 GitHub 생태계
안전장치 Git 브랜치·커밋 관리 샌드박싱 모든 변경이 커밋 → 되돌리기 쉬움 PR 리뷰
어울리는 사용자 대규모 리팩터링·아키텍처 변경을 하는 전문 개발자 취미~기업 개발자, Google Cloud 사용자 효율·통제·투명성을 중시하는 개발자 GitHub 중심으로 협업하는 팀

Terminal-Bench — 명령행 인터페이스용 AI 에이전트 벤치마크

Terminal-Bench는 명령행 인터페이스 안에서 AI 에이전트가 복잡한 작업을 얼마나 잘 해내는지 가늠하기 위한 새로운 프레임워크입니다. 터미널은 텍스트 기반이며 샌드박스로 격리되어 있어, AI 에이전트가 동작하기에 가장 적합한 환경으로 꼽힙니다.

  • 첫 공개 버전인 Terminal-Bench-Core-v0는 과학 워크플로와 데이터 분석 같은 영역을 아우르는 80개 작업으로 이루어져 있으며, 모두 사람이 직접 골라냈다.
  • 공정한 비교를 위해 최소 기능만 갖춘 단순 에이전트 Terminus도 함께 개발되었다. Terminus는 다양한 언어 모델을 같은 조건에서 시험할 수 있는 표준 테스트베드 역할을 한다.
  • 이 프레임워크는 컨테이너화나 직접 연결 방식으로 다양한 에이전트를 통합할 수 있도록 확장성을 갖추었다.
  • 앞으로는 대규모 병렬 평가를 지원하고, 이미 널리 쓰이는 벤치마크도 포함할 예정이다.
  • 이 프로젝트는 다른 오픈소스 프로젝트처럼 외부 개발자들의 평가 과제를 확충하고 프레임워크를 함께 개선하기 위한 기여를 환영한다.

Terminus의 존재 이유가 중요합니다. 앞의 네 도구를 그대로 비교하면 모델 성능과 도구(하네스) 설계의 효과가 뒤섞입니다. 같은 모델이라도 어떤 도구를 주고 어떤 루프를 돌리느냐에 따라 결과가 크게 달라지기 때문입니다. Terminus처럼 최소한의 에이전트를 고정해 두면 모델만의 차이를 볼 수 있고, 반대로 모델을 고정하면 하네스의 차이를 볼 수 있습니다. 19장의 평가 원칙 — 변수를 통제하고 같은 조건에서 비교하라 — 이 에이전트 벤치마크에서도 그대로 적용됩니다.

정리

이처럼 강력한 AI 명령행 에이전트가 등장하면서 소프트웨어 개발의 밑바탕이 흔들리고 있고, 터미널도 활기차고 협업이 이루어지는 환경으로 탈바꿈하고 있습니다. 지금까지 살펴봤듯이 단 하나의 ‘최고’ 도구가 있는 것은 아닙니다. 대신 각 에이전트가 저마다의 강점을 내세우는 활기찬 생태계가 만들어지고 있습니다.

어떤 도구가 가장 적합한지는 오로지 개발자의 필요에 달려 있습니다.

작업의 성격 잘 맞는 도구
복잡한 아키텍처 작업 클로드
다방면의 멀티모달 문제 제미나이
Git 중심으로 코드를 직접 다루는 작업 Aider
GitHub 워크플로에 매끄럽게 녹아드는 작업 GitHub Copilot

이러한 도구가 계속 발전할수록, 이를 능숙하게 다루는 일은 반드시 갖춰야 할 역량이 되고, 개발자가 소프트웨어를 만들고 디버깅하고 관리하는 방식도 밑바닥부터 달라질 것이다.

마치며

책의 흐름 속에서 이 장을 다시 보면, 네 도구는 모두 앞선 장들의 패턴을 터미널이라는 한 환경에 한꺼번에 모아 둔 결과물입니다. 파일을 읽고 셸을 실행하는 것은 5장의 도구 사용이고, 계획을 먼저 보여 주는 것은 6장의 계획 수립이며, 테스트를 돌려 스스로 고치는 것은 4장의 리플렉션입니다. 세션을 넘어 선호를 기억하는 것은 8장의 기억 관리이고, 샌드박스와 PR 리뷰는 18장과 13장의 가드레일·휴먼 인 더 루프입니다.

터미널이 에이전트에게 유리한 이유도 분명합니다. 모든 입출력이 텍스트라서 23장의 GUI 에이전트처럼 픽셀을 해석할 필요가 없고, 명령의 결과(종료 코드, 테스트 통과 여부, 컴파일 오류)가 객관적인 피드백으로 곧바로 돌아옵니다. 에이전트의 루프가 가장 짧고 정확하게 닫히는 환경인 셈입니다.

다만 셸을 실행할 수 있다는 것은 곧 시스템을 망가뜨릴 수 있다는 뜻이기도 합니다. 그래서 이 장의 도구들이 저마다 내세우는 안전장치 — 샌드박스, 모든 변경의 커밋, PR 리뷰, 실행 전 계획 확인 — 는 부가 기능이 아니라 에이전트에게 터미널을 맡기기 위한 전제 조건입니다.

참고 문헌