터미널 & CLI 사용 방법 : 뜻·역사·명령어·플러그인 총정리 | 바이브 코딩 필수 스킬, IDE vs 터미널

개발자가 키보드에서 손을 떼지 않고 일하는 습관, 서버에 SSH로 붙어 로그를 읽는 장면, Cursor나 VS Code 아래쪽에 까만 창을 띄워두는 화면. 이 모든 장면의 공통 인프라는 터미널과 CLI다. 바이브 코딩처럼 자연어로 AI에게 일을 맡기는 흐름이 커질수록, 명령줄을 모르는 비용도 커진다. 이 글은 터미널·셸·CLI가 뭔지부터 역사, OS 차이, 필수 명령, IDE와의 비교, AI 에이전트가 CLI를 선호하는 이유, 안전한 승인·컨텍스트 파일, 현대 도구·플러그인, 고수로 가는 연습법까지 한곳에 모은다.

1. 터미널·셸·CLI, 세 층을 먼저 구분한다

실무에서 「터미널」이라고 뭉뚱그려 부르는 말 안에는 서로 다른 층이 겹쳐 있다.

터미널은 그릇이고, 셸은 그 그릇 안의 일꾼이며, CLI는 「마우스 대신 문장으로 지시한다」는 약속이다. 이 구분이 잡히면 「PowerShell을 쓰는지 bash를 쓰는지」와 「Windows Terminal을 쓰는지」가 다른 질문이라는 점도이 보인다.

그림 1. 터미널(창) → 셸(해석기) → CLI(대화 방식) 세 층.

2. 터미널은 왜 생겼나 — 짧은 역사

터미널은 GUI보다 먼저 태어났다. GUI가 나온 뒤에도 사라지지 않고 개발·서버의 표준으로 남았다.

그림 2. 천공 카드에서 WSL까지 — GUI 이후에도 개발·서버 표준으로 남은 명령줄.

핵심은 단순하다. 텍스트로 명령을 주고 받는 방식은 자동화하기 쉽고, 스크립트로 재현하기 쉽고, 네트워크 너머에서도 가볍다. 그 세 가지가 반세기 넘게 CLI를 지탱한다.

3. 셸의 종류 — Cursor에서 보이는 선택 화면의 정체

IDE 하단 터미널에서 PowerShell / CMD / Git Bash를 고르는 화면은 「어떤 셸을 띄울지」를 고르는 것이다.

Windows만 쓴다면 PowerShell을 기본으로 두고, 서버·오픈소스 튜토리얼을 따를 때는 WSL이나 Git Bash를 병행하는 조합이 흔하다.

4. Windows 터미널 vs macOS·Linux 터미널

가장 큰 차이는 철학이다.

Unix 계열(bash/zsh)은 「모든 것은 텍스트」다. 한 명령의 stdout이 파이프(|)로 다음 명령의 stdin이 된다. 서버 대부분이 Linux라서 여기서 익힌 습관이 배포·운영으로 이어진다.

PowerShell은 「모든 것은 객체」에 가깝다. Get-Process의 결과는 문자열이 아니라 속성 있는 객체라서 필터·정렬이 깔끔하다. 대신 리눅스 책의 명령과 문법이 달라 처음엔 낯설다.

일상에서 자주 헷갈리는 대응표다.

Windows에서 리눅스 튜토리얼을 그대로 따라가려면 WSL을 쓰는 편이 마찰이 적다. PowerShell만으로도 충분히 강력하지만, 「인터넷에 나온 bash 한 줄」과의 호환성은 WSL이 앞선다.

그림 3. 텍스트 파이프(Unix)와 객체 파이프라인(PowerShell)의 결이 다르다.

5. 꼭 익힐 기본 명령어

암기가 목표가 아니다. 아래를 「손에 한 번씩 쳐본 적 있다」 수준으로 두면 된다. 모르면 명령 --help 또는 man 명령(Unix), Get-Help 명령(PowerShell)으로 그자리에서 묻는다.

5.1. 탐색·이동

• pwd — 지금 어디인지
• ls / ls -la — 목록, 숨김·권한까지
• cd 경로 · cd .. · cd ~ · cd - — 이동 / 상위 / 홈 / 직전
• tree — 폴더 구조 한눈에
• find . -name '*.py' 또는 fd .py — 이름으로 찾기

5.2. 파일 조작

• mkdir -p a/b/c — 중첩 폴더 한 번에
• touch 파일 — 빈 파일 만들기(Unix)
• cp / cp -r — 복사
• mv — 이동 또는 이름 변경
• rm / rm -rf — 삭제. -rf는 휴지통 없이 지운다. 실행 전 pwd로 위치 확인
• ln -s — 심볼릭 링크(짧은 호출 이름을 실제로 만들 때와 비슷한 발상)

5.3. 내용·검색

• cat · less · head · tail · tail -f — 보기 / 실시간 로그
• grep -rn '검색어' . — 폴더 재귀 검색
• rg '검색어' — ripgrep. .gitignore를 존중하고 빠르다

5.4. 연결·흐름 (CLI의 힘)

• 명령1 | 명령2 — 파이프
• 명령 > 파일 · 명령 >> 파일 — 덮어쓰기 / 이어붙이기
• 명령 2> 에러파일 — 표준 에러만 분리
• 명령1 && 명령2 — 앞이 성공하면 뒤
• 명령1 || 명령2 — 앞이 실패하면 뒤
• 명령 & — 백그라운드(셸·OS에 따라 다름)

한 줄 예: history | grep git | tail -5 — 기록에서 git만 골라 마지막 다섯 줄.

5.5. 프로세스·시스템·네트워크

• ps · top/htop · kill — 프로세스
• df -h · du -sh — 디스크
• chmod +x — 실행 권한(Unix)
• curl · ping · ssh user@host — HTTP / 연결 / 원격

5.6. Git (개발자면 매일)

• git status · git diff · git add · git commit -m '메시지'
• git push · git pull · git log --oneline
• git switch -c 브랜치 · git switch 브랜치

이 저장소처럼 PowerShell에서 &&를 쓰지 못하는 환경도 있다. 그때는 명령을 줄을 나눠 순차로 실행하거나 ;·별도 스크립트를 쓴다.

6. 단축키와 별칭 — 손이 마우스로 가지 않게

6.1. 키보드

Tab과 Ctrl+R만 몸에 익혀도 체감 속도가 달라진다.

6.2. 별칭(alias)과 PATH 심

긴 명령을 짧게 부르는 방법은 두 갈래다.

1. 셸 프로필 별칭 — zsh면 ~/.zshrc에 alias gs='git status', PowerShell이면 $PROFILE에 function gs { git status }. 셸 세션에 묶인다.
2. PATH에 실제 실행 파일(심·래퍼) — cs.cmd처럼 PATH 폴더에 파일을 두면 CMD·PowerShell·새 창에서도 같은 이름이 잡힌다. 전역 확실성이 높다.

Windows에서 AI CLI를 쓸 때 자주 나오는 이름 충돌이다

그림 4. 호출 이름을 정리할 때 PATH 심이 PowerShell alias보다 전역에 확실하다. cursor는 IDE와 충돌한다.

6.3. 약어 명령 설정 방법 — cursor-agent를 cs로도 부르기

「긴 공식 이름」과 「짧은 손 습관 이름」을 같이 쓰고 싶을 때다. Cursor Agent의 공식 호출이 cursor-agent라면, 같은 바이너리를 cs로도 열리게 만들 수 있다. 핵심은 이름을 새로 발명하는 게 아니라, 이미 PATH에 있는 실행 파일을 짧은 이름으로 한 번 더 가리키는 것이다.

권장 순서는 이렇다.

6.3.1. 방법 1 — PATH 심 (Windows에서 cs용으로 권장)

Cursor Agent 설치 폴더(보통 사용자 Local AppData 아래 cursor-agent)에는 agent.cmd, cursor-agent.cmd, agent.ps1 등이 있다. PATH에 이 폴더가 들어가 있으면 cursor-agent가 잡힌다.

같은 폴더에 cs.cmd(그리고 PowerShell용이면 cs.ps1)를 내용이 같은 복사본으로 두면, 셸은 cs를 실행 파일로 찾아 동일 스크립트를 돌린다.

PowerShell 예 (한 줄씩):

1. 설치 폴더로 이동: Set-Location $env:LOCALAPPDATA/cursor-agent
2. 복사: Copy-Item agent.cmd cs.cmd · Copy-Item agent.ps1 cs.ps1 (ps1이 있을 때)
3. 확인: Get-Command cs · cs --version

agent.cmd 내용이 PowerShell로 cursor-agent.ps1을 호출하는 래퍼라면, cs.cmd도 같은 래퍼라서 인자와 동작이 같다. 새 터미널을 열어도 PATH만 유지되면 cs가 바로 잡힌다.

에이전트를 업그레이드했는데 cs가 사라졌다면, 설치 스크립트가 심을 지우지 않았는지 보고 같은 복사를 한 번 더 하면 된다.

6.3.2. 방법 2 — PowerShell 프로필 함수 (셸만)

프로필 경로 확인: echo $PROFILE 없으면 만들고: New-Item -ItemType File -Force -Path $PROFILE 메모장으로 연 뒤 아래처럼 함수를 넣는다.

function cs { & cursor-agent @args } 또는 Local AppData의 cursor-agent/cursor-agent.ps1을 &로 직접 호출해도 된다.

저장 후 . $PROFILE 또는 새 PowerShell 창에서 cs --version으로 확인한다. CMD 창에서는 이 함수가 없다. IDE 통합 터미널이 CMD면 방법 1이 낫다.

6.3.3. 방법 3 — macOS / Linux / WSL (alias)

zsh면 ~/.zshrc, bash면 ~/.bashrc에 예: alias cs='cursor-agent' 적용: source ~/.zshrc 확인: type cs · cs --version

원본이 /usr/local/bin/cursor-agent처럼 실제 파일이면, ln -s로 ~/bin/cs를 만들고 ~/bin을 PATH에 넣는 방식도 PATH 심과 같다.

6.3.4. 방법 4 — 같은 패턴으로 anti · gs 만들기

하지 말 것: 짧은 이름을 cursor로 쓰기. Windows에 Cursor IDE 실행 명령이 이미 cursor인 경우가 많아, Agent와 IDE가 서로 덮어쓴다. cs / cagent / cursor-agent처럼 IDE와 안 겹치는 이름을 고른다.

6.3.5. 확인 체크리스트

• Get-Command cs (PowerShell) 또는 where.exe cs — 경로가 기대한 폴더인가
• cs --version — cursor-agent --version과 같은 버전 문자열인가
• 새 터미널에서도 되는가 — 안 되면 PATH·프로필 로드 문제
• 인자가 전달되는가 — cs --help가 Agent 도움말이 나오는가

이 네 가지가 맞으면 「약어 설정」은 끝이다. 별칭의 본질은 마법이 아니라 같은 프로그램에 두 개의 호출 이름을 붙여 두는 것이다.

7. 터미널이 IDE보다 가볍고 빠른 이유

구조적으로 당연하다.

• GUI를 거의 그리지 않는다. IDE는 파일 트리, 하이라이트, 진단, 확장 UI를 매 프레임 유지한다. Electron 기반 IDE는 사실상 브라우저급 무게다.
• 의존성과 시작 비용이 작다. 텍스트 I/O만 하면 된다.
• 원격에서 특히 유리하다. SSH로 GUI 데스크톱을 통째 그리면 느리고, 텍스트 스트림은 지연이 작다.

그림 5. UI·의존성·시작 시간·SSH — 터미널이 가벼운 네 가지 축.

그렇다고 IDE가 「틀린」 도구는 아니다. 시각적 디버깅, 다중 파일 탐색, 인라인 자동완성에서는 IDE가 여전히 편하다. 실전은 IDE 안에서 터미널을 여는 하이브리드가 기본이다.

8. 개발자가 CLI를 자주 잡는 이유

숙련될수록 CLI가 편해지는 이유는 생산성 루프에 있다.

• 손이 키보드를 유지한다. 메뉴를 찾아 클릭하는 왕복이 줄다.
• 반복을 스크립트·별칭으로 굳힌다. 100번 클릭이 한 줄이 된다.
• 작은 도구를 파이프로 조합한다. 「고정 앱」이 아니라 「조립 블록」이다.
• 재현 가능성이 높다. 같은 명령을 동료·CI에 그대로 넘긴다.

9. AI가 IDE보다 CLI를 잘 다루는 이유

바이브 코딩 시대에 질문이 하나 더 붙는다. 「왜 AI 코딩 에이전트는 IDE 채팅보다 터미널에 붙을까?」

짧은 답: IDE형 AI는 제안에 강하고, CLI형 에이전트는 위임에 강하다.

그림 6. 자동완성은 IDE, 리팩터·테스트·마이그레이션형 위임은 CLI.

9.1. 텍스트 스트림은 LLM의 모국어에 가깝다

Unix 파이프라인과 LLM이 다루는 입출력이 모두 텍스트다. 에이전트는 「버튼 좌표를 찍는」 대신 rg·sed·테스트 러너 명령을 조합해 작업을 이어간다. GUI 자동화보다 표현력이 넓고 실패 원인도 로그로 남는다.

9.2. 종료 코드가 자가 수정 루프를 만든다

명령은 성공 시 대체로 0, 실패 시 0이 아닌 값을 남긴다. CLI 에이전트는 대략 이런 루프를 돈다.

계획 → 파일 수정 → 테스트/린트 실행 → exit code 확인 → 실패면 stderr를 읽고 재수정 → 성공이면 다음 작업

사람이 에러 창을 복사해 채팅에 붙여 넣는 단계를 줄일 수 있다. 장시간 무인에 가까운 작업이 가능해지는 이유다.

그림 7. exit 0/1이 AI 에이전트의 ‘정답지’ 역할을 한다.

9.3. 파일시스템이 「현실」이다

디스크에 쓰였는지, 테스트가 통과했는지가 기준이다. 저장 안 된 탭·스크롤 위치 같은 에디터 내부 상태는 CLI 검증에서 뒤로 밀린다. cat·git diff로 확인하면 「고쳤다고 착각」하는 환각을 줄이는 데 도움된다.

9.4. 컨텍스트를 아껴 쓴다

긴 IDE 대화와 열린 탭 전부가 매 요청에 실리면 모델 컨텍스트가 쉽게 오염된다. 성숙한 CLI 에이전트는 필요할 때만 grep/rg로 조각을 읽고, 작업 단위로 세션을 자르는 편이다.

9.5. 스크립트·CI에 끼워 넣을 수 있다

사이드바 채팅은 파이프라인 스텝이 되기 어렵지만, CLI 바이너리는 GitHub Actions 등에 넣을 수 있다. PR 리뷰·요약·린트 수정 같은 헤드리스 작업을 「도구 체인 한 칸」으로 취급한다.

10. 그런데 왜 IDE 안에서도 터미널을 여나

CLI 에이전트의 약점은 「눈이 없다」는 쪽에 가깝다. UI 깨짐, 디자인 시안, 레이아웃은 터미널만으로 어렵다. IDE는 diff 하이라이트·파일 트리·미리보기에 강하다.

그래서 흔히:

• IDE = 보는 창(사람용 시각 맥락)
• 터미널 안의 CLI 에이전트 = 일하는 손(파일·테스트·깃 위임)

이 조합이 된다. 자동완성과 짧은 수정은 IDE, 여러 파일에 걸친 리팩터·마이그레이션·테스트 루프는 CLI로 나누는 식이다.

11. 바이브 코딩을 위해 CLI를 알아야 하는 이유

바이브 코딩은 「코드를 한 줄씩 직접 쓰기보다 자연어로 결과를 끌어내는」 방식에 가깝다. 그런데 강력한 위임형 도구가 CLI 기반이라 역설적으로 터미널 문해력이 필요하다.

• 설치·API 키·환경·권한 설정이 명령줄에서 이뤄진다.
• 에이전트가 제안한 위험한 명령(rm -rf, force push 등)을 사람이 읽고 승인하려면 명령의 뜻을 알아야 한다.
• 「테스트 돌려서 통과하면 커밋해」 같은 지시 자체가 git·테스트 개념을 전제로 한다.
• Skill(매뉴얼)과 CLI 에이전트(실행자)는 다르다. SKILL.md는 업무 규정이고, 에이전트는 그 규정을 읽고 셸과 파일을 만진다. 둘을 헷갈리면 「지식만 있고 손이 없거나」, 「손은 있는데 팀이 금지한 방식으로 작업」하게 된다.

개념은 사람이 쥐고, 반복 실행은 에이전트에 맡기고, 결과는 사람이 검증한다. CLI 문해력은 「AI를 부리는 비용」의 입장권에 가깝다.

12. AGENTS.md / CLAUDE.md — AI용 온보딩 문서

프로젝트 루트의 짧은 마크다운은 신입 온보딩 문서와 같다. 도구마다 파일명이 다르지만(Claude Code의 CLAUDE.md, 여러 도구가 읽는 AGENTS.md 등) 역할은 같다.

원칙은 「적을수록 좋다」다. 긴 규정집은 컨텍스트를 잡아먹고, 지시가 서로 충돌하기도 한다. AI가 추측하면 자주 틀리는 것만 적는다.

• 한 줄 프로젝트 성격
• 스택·버전
• 설치·테스트·린트·개발 서버 명령
• 「하지 말 것」(.env 수정 금지, main 직접 push 금지 등)

코드만 읽으면 알 수 있는 함수 설명은 굳이 넣지 않는다. AI가 같은 실수를 반복할 때마다 한 줄씩 추가하는 방식이 현실적이다.

13. 승인·샌드박스 — 최종 승인자는 사람

에이전트 사고 사례에는 악의보다 「과도한 의욕」이 많다. 원격 브랜치 삭제, 토큰 외부 전송, 프로덕션 마이그레이션 시도 같은 유형이다.

실무 감각으로는 상태를 바꾸지 않는 작업은 자동 허용하고, force-push·대량 삭제·비밀 유출·프로덕션 배포는 사람이 본다. 오래 돌릴 작업은 Dev Container·격리 워크트리처럼 사고를 가둘 공간을 만든다.

14. CI/CD에 CLI 에이전트 넣기

헤드리스 환경에서는 물어보는 UI가 없다. API 키는 Secrets로만 두고, main 직접 push는 막고, AI가 만든 PR은 사람이 머지 전에 읽는다. 「자고 있는 동안 리뷰 초안을 남긴다」 수준부터 시작하는 편이 안전하다.

15. 현대 CLI 도구·플러그인 지도

옛 grep/ls/cat/cd를 대체하는 Rust·Go 계열 도구가 많다. 한 번에 다 깔지 말고, 매일 쓰는 것부터 얹는다.

그림 8. 검색·보기·이동·Git·JSON·프롬프트 — 카테고리별로 고른다.

15.1. 검색·찾기

15.2. 보기·이동

15.3. Git

15.4. 데이터·HTTP

15.5. 프롬프트·셸 꾸미기

15.6. 세션·도움·기타

15.7. Windows에서 설치

• winget — OS 기본에 가깝다
• scoop — CLI 도구 PATH 관리가 개발자 친화적. scoop install ripgrep fd fzf bat eza zoxide처럼 묶기 쉽다
• chocolatey — 관리자 권한 기반의 오래된 선택지

rg, fd, fzf, bat, eza, zoxide, jq, delta, lazygit 대부분은 Windows에서도 동작한다.

우선순위 제안: 첫째 주 rg·fzf·bat·eza·zoxide → 프롬프트(starship 또는 oh-my-posh) → git을 많이 쓰면 lazygit·delta → API면 jq·httpie → 세션 관리가 필요해지면 tmux/zellij.

16. 터미널 고수가 되는 관념과 연습법

명령어 암기보다 사고방식이 앞선다.

1. 터미널은 외우는 곳이 아니라 물어보는 곳이다. --help, man, tldr, which/where.exe.
2. 두 번 하면 자동화한다. 별칭 → 스크립트 → 프로필.
3. 모든 것은 텍스트이고 조합 가능하다. 파이프를 「기능」이 아니라 「레고」로 본다.
4. 위험 명령 앞에서는 위치가 진실이다. rm -rf 전에 pwd.
5. 일상의 작은 일을 의식적으로 터미널로 옮긴다. 파일 탐색기 대신 cd/ls로 2~3주만 버틴다.

   

   그림 9. 탐색 → 파이프 → 자동화 → git·현대도구 → 멀티플렉서·CLI AI.

   단계 로드맵:

6. 탐색·파일 (cd, ls, cp, mv, rm)
7. 파이프·검색 (|, >, grep/rg)
8. 별칭·간단한 셸/PowerShell 스크립트
9. git · SSH · 현대 도구
10. tmux/zellij · CLI AI 에이전트 오케스트레이션

17. 상황별 선택

18. 마무리

앞에서 다룬 터미널·CLI의 핵심만 짧게 정리한다.

• 터미널(창)·셸(해석기)·CLI(방식)를 한 덩어리로 두지 않는다.
• 역사적으로 CLI는 GUI보다 먼저였고, 자동화·재현·원격 때문에 아직도 표준이다.
• Windows는 PowerShell+필요 시 WSL, macOS/Linux는 zsh/bash 습관이 서버와 이어진다.
• 명령은 외우기보다 --help로 묻고, 반복은 별칭·스크립트·PATH 심으로 굳힌다.
• IDE는 눈, CLI는 손. AI는 위임·종료 코드·파일시스템 검증에서 CLI와 궁합이 좋다.
• 바이브 코딩일수록 최소 CLI 문해력·승인 감각·짧은 컨텍스트 파일이 필요하다.
• 도구 버전·플래그·보안 정책은 자주 바뀐다. 프로덕션 명령은 실행 전 공식 문서와 현재 환경을 다시 확인한다.

「좋은 터미널 습관은 명령어 암기가 아니라, 반복을 자동화하고 작은 도구를 조합하며 위험한 줄은 위치부터 확인하는 태도다.」 그 태도 위에 CLI AI를 올리면 바이브 코딩이 「운」이 아니라 「위임 체계」가 된다.

자주 묻는 질문

• 터미널과 셸과 CLI는 같은 말인가요?

  아닙니다. 터미널은 명령을 치고 결과를 보는 창(에뮬레이터), 셸은 그 안에서 명령을 해석·실행하는 프로그램(bash, zsh, PowerShell 등), CLI는 명령어로 컴퓨터와 대화하는 방식 자체를 가리킵니다. 세 층을 구분해 두면 OS마다 다른 셸을 골라도 헷갈림이 줄어듭니다.

• Windows에서는 PowerShell과 WSL 중 무엇을 써야 하나요?

  Windows 자체 자동화·관리에는 PowerShell이 잘 맞습니다. 리눅스 서버·오픈소스 튜토리얼을 그대로 따르려면 WSL(또는 Git Bash)이 마찰이 적습니다. 둘을 목적별로 병행하는 경우가 많습니다.

• 왜 AI 코딩 에이전트는 IDE 채팅보다 CLI를 선호하나요?

  텍스트 입출력·파이프·종료 코드(exit code)가 자율 수정 루프를 만들기 쉽고, 파일시스템에 실제로 쓰였는지로 결과를 검증하기 쉽기 때문입니다. IDE AI는 제안·짝코딩에, CLI 에이전트는 여러 파일에 걸친 위임형 작업에 더 잘 맞습니다.

• Cursor Agent를 cursor 명령으로 실행해도 되나요?

  대개 비추천입니다. cursor는 Cursor IDE 실행 파일과 이름이 겹치기 쉽습니다. cursor-agent를 쓰거나, PATH에 cs 같은 별도 심을 두는 편이 안전합니다. Grok은 grok, Antigravity 계열은 agy처럼 고유 짧은 이름을 유지하세요.

• 별칭은 PowerShell alias로 만들면 충분한가요?

  셸 안에서만 쓰면 alias·함수로 충분합니다. CMD·새 창·다른 도구에서도 같은 이름을 쓰려면 PATH에 cmd/ps1 래퍼(심)를 두는 편이 확실합니다. Windows에서 cs.cmd처럼 Cursor Agent 폴더에 심을 두는 방식이 그 예입니다.

• fzf, ripgrep, bat 같은 도구를 전부 깔아야 하나요?

  아니요. 매일 쓰는 것부터 얹는 게 정착에 유리합니다. 우선 rg·fzf·bat·eza·zoxide, 다음으로 프롬프트(starship 또는 oh-my-posh), git을 많이 쓰면 lazygit·delta 순을 권합니다. Windows는 scoop이나 winget으로 설치하면 PATH 관리가 수월합니다.

• AGENTS.md나 CLAUDE.md에는 무엇을 넣어야 하나요?

  AI가 추측하면 자주 틀리는 최소 정보만 넣습니다. 스택·버전, 설치·테스트·린트·개발 서버 명령, 하지 말 것(.env 수정·main 직접 push 금지 등)이 핵심입니다. 긴 규정집은 컨텍스트를 잡아먹고 지시가 충돌할 수 있어, 짧을수록 결과가 좋아지는 경우가 많습니다.

• 바이브 코딩만 하는데도 CLI를 배워야 하나요?

  위임형 도구 설치·권한·환경 설정이 터미널에서 이뤄지고, 에이전트가 제안한 위험한 명령을 사람이 읽고 승인하려면 최소한의 명령 문해력이 필요합니다. git·테스트·경로 개념 없이 맡기면 결과 검증도 어렵습니다.

• rm -rf를 안전하게 쓰는 습관은 무엇인가요?

  실행 전에 pwd로 현재 위치를 확인하고, 경로를 다시 읽은 뒤 실행합니다. 가능하면 trash-cli처럼 휴지통으로 보내는 도구를 쓰고, AI 에이전트에게 대량 삭제를 맡길 때는 승인 프롬프트를 끄지 않는 편이 안전합니다.

• cursor-agent를 cs처럼 짧은 약어로 설정하는 방법은 뭔가요?

  Windows에서는 Cursor Agent가 설치된 PATH 폴더에 agent.cmd(또는 cursor-agent.cmd)를 cs.cmd로 복사하는 PATH 심이 가장 확실합니다. PowerShell만 쓴다면 $PROFILE에 function cs { & cursor-agent @args }를 넣어도 됩니다. macOS/Linux는 ~/.zshrc에 alias cs='cursor-agent' 또는 ln -s로 심볼릭 링크를 만듭니다. cursor라는 이름은 IDE와 충돌하기 쉬워 피합니다.

• 별칭을 만들었는데 새 터미널에서 cs가 안 잡혀요.

  PowerShell 프로필 함수는 그 셸에만 로드되고, CMD나 프로필이 로드되지 않은 창에는 없습니다. PATH 폴더의 cs.cmd 심이면 대부분 새 창에서도 잡힙니다. Get-Command cs와 where.exe cs로 경로를 확인하고, 심이 업그레이드로 지워졌으면 agent.cmd를 다시 복사하세요.