클로드 코드 CLI 명령어 정리: 실무에서 실제로 쓰는 것만

클로드 코드 CLI란?
앤트로픽이 만든 터미널 기반 AI 코딩 에이전트로, 셸에서 claude 명령을 실행해 코드베이스를 읽고 파일을 수정하며 셸 명령까지 대신 실행하는 도구다.

명령어를 다 외운다고 잘 쓰게 되지 않는다

클로드 코드 CLI 관련 글 대부분이 명령어 40~50개를 나열한다. 그 목록을 다 외운 사람과 다섯 개만 쓰는 사람의 산출물 차이는 크지 않다. 실제로 손이 가는 명령은 열 개 안팎이고, 나머지는 필요한 순간에 /help로 찾아도 늦지 않다.

그래서 이 글은 전체 레퍼런스가 아니다. 하루 단위로 반복해서 치게 되는 것만 골라 정리하고, 나머지는 왜 굳이 외울 필요가 없는지까지 적는다. 기준 시점은 2026년 8월이다.

터미널에서 치는 명령

이 중 실무 빈도가 압도적인 건 앞의 다섯 개다. -p는 성격이 좀 다르다. 대화가 아니라 함수처럼 쓰는 모드라서, 커밋 메시지 자동 생성이나 로그 요약 같은 반복 작업을 셸 스크립트에 넣을 때 진가가 나온다.

권한 관련 플래그는 신중하게

승인 절차를 건너뛰는 --dangerously-skip-permissions 류의 옵션은 이름 그대로 위험하다. 컨테이너나 일회용 워크트리처럼 망가져도 되는 환경이 아니면 쓰지 않는 쪽이 맞다. 에이전트가 파일을 지우거나 원격에 푸시하는 판단을 사람 확인 없이 내리게 되는데, 이 판단이 틀렸을 때 복구 비용은 절약한 클릭 수보다 훨씬 크다.

세션 안에서 치는 슬래시 명령

여기서 하나만 고르라면 /clear다. 앞선 대화가 길게 남아 있으면 모델이 지금 질문과 무관한 파일을 계속 참조하고, 답의 품질이 조용히 떨어진다. 세션을 오래 끌수록 좋아진다는 감각은 사실과 다르다.

키 입력이 명령어보다 자주 쓰인다

• @ 파일 경로 자동완성. 맥락 지정의 기본기
• ! 셸 명령 직접 실행. 결과가 대화 맥락에 들어간다
• # 프로젝트 규칙 파일에 기억 추가
• Esc 진행 중인 작업 중단. 엉뚱한 방향으로 갈 때 즉시 누른다
• Shift+Tab 승인 모드 전환

실측 없이 말하기 조심스럽지만, 하루 작업에서 타이핑 빈도만 놓고 보면 슬래시 명령보다 @와 Esc가 훨씬 앞선다. 좋은 결과는 긴 프롬프트가 아니라 정확한 파일 지정에서 나온다.

위 목록은 2026년 8월 기준이다. 클로드 코드는 릴리스 주기가 짧아 플래그 이름과 기본값이 바뀐다. 세션에서 /help를 치면 설치된 버전이 실제 지원하는 목록이 나오고, 어떤 블로그 글보다 그쪽이 정확하다.

근거: 대규모 도입에서 실제로 관찰된 것

명령어 숙련도가 도입 성패를 가른다는 통념은 검증된 적이 없다. 오히려 조직 단위 데이터는 다른 이야기를 한다.

마이크로소프트 연구진이 2026년 초 사내 롤아웃을 분석한 논문에 따르면, 수만 명 규모 엔지니어를 관찰한 결과 첫 사용은 주로 사회적 네트워크를 타고 번졌고, 계속 쓰는지 여부는 인구통계 속성보다 그 사람의 코딩 활동량과 더 관련이 있었다. 조직 단위로 보면 토큰 지출이 연간 수백만 달러에 이를 수 있다는 점도 함께 짚었다.

SOURCE · CLI 코딩 에이전트 도입 연구 | arXiv (2026.07) ↗ 원문

해석은 갈릴 수 있으나 실무자 입장에서 읽어낼 지점은 분명하다. 도구를 붙잡고 있는 사람은 원래 코드를 많이 쓰던 사람이고, 확산은 교육 자료가 아니라 옆자리 동료에게서 일어난다. 사내에 명령어 위키를 만드는 일보다, 이미 잘 쓰는 사람이 화면을 공유하는 30분이 효과가 크다는 뜻이다.

한 가지 더. 이 연구는 마이크로소프트가 자사 롤아웃을 분석한 결과라 도구 판매자의 홍보 자료보다는 신뢰도가 높지만, 코파일럿 CLI를 만든 회사이기도 하다. 수치를 그대로 자기 조직에 대입하기보다 패턴만 참고하는 편이 안전하다.

비용은 명령어 습관에서 갈린다

토큰 지출이 문제가 되는 지점은 대체로 정교한 사용이 아니라 방치된 세션이다. 맥락이 부풀어 오른 상태로 질문을 이어가면 매 턴마다 같은 파일을 다시 읽는다. 여기서 /clear와 /compact가 비용 도구가 된다.

1. 작업 단위가 끝나면 /clear
2. 맥락이 필요한데 길어졌으면 /compact
3. 주 1회 /cost로 실제 사용량 확인
4. 탐색과 질의응답은 가벼운 모델, 구현은 무거운 모델로 /model 전환

구독 요금제와 API 종량 과금은 비용 구조가 다르고, 플랜별 사용량 한도는 자주 바뀐다. 금액 판단이 필요하면 앤트로픽 공식 요금 페이지를 그 시점에 직접 확인하는 편이 맞다.

도구 단위의 효율이 조직 단위 수익으로 이어지는지는 별개 문제다. 이 계산은 AI 전환 ROI: 기업이 알아야 할 경제학에서 따로 다뤘다.

3주 안에 손에 붙이는 순서

한 번에 다 익히려는 시도는 거의 실패한다. 순서를 나누는 쪽이 낫다.

3주차가 진짜 분기점이다. 대화형으로 쓰는 단계까지는 편의 도구에 가깝고, -p로 스크립트에 넣기 시작하면 업무 흐름 자체가 바뀐다. 다만 자동 실행 범위를 넓히는 만큼 검토 부담도 함께 늘어난다는 점은 감수해야 한다.

더 읽어보기

• AI 전환 ROI: 기업이 알아야 할 경제학

자주 묻는 질문

명령어를 다 외워야 하나?

아니다. 세션에서 /만 눌러도 사용 가능한 목록이 뜨고 /help가 설명을 준다. 외울 가치가 있는 건 @, Esc, /clear 정도이고 나머지는 필요할 때 찾아 쓰는 편이 효율적이다. 목록 암기에 쓴 시간이 결과물로 돌아온다는 근거는 없다.

IDE 확장이나 다른 CLI 도구와 뭐가 다른가?

가장 큰 차이는 셸 접근이다. 에디터 안에서 코드를 제안하는 방식과 달리, CLI 에이전트는 테스트를 돌리고 로그를 읽고 다시 고치는 반복을 스스로 한다. 대신 실행 권한을 넘기는 구조라 승인 정책을 짜는 일이 필수가 된다. 편의성과 통제를 맞바꾸는 선택이지 일방적 상위 호환은 아니다.

팀에 도입하면 생산성이 바로 오르나?

단정하기 어렵다. 앞서 인용한 마이크로소프트 연구에서도 도입과 유지, 산출에 미치는 영향은 각각 다른 요인이 좌우했다. 코드 작성 비중이 높은 인원부터 붙는 경향이 보였으니, 전사 일괄 배포보다 활동량이 많은 소수에게 먼저 붙이고 확산 경로를 만드는 방식이 현실적이다.

도구보다 판단이 먼저다

명령어 정리는 출발점이지 목적지가 아니다. 어떤 작업을 에이전트에 넘기고 어떤 판단을 사람이 붙들지 정하지 않으면, 손에 익은 명령어가 늘수록 검토하지 않은 코드도 같이 늘어난다. AI 전환을 조직 단위로 검토 중이라면 Nitrox 블로그에서 관련 가이드를 더 볼 수 있다.