Claude Code CLI 효율적으로 쓰기: 7가지 팁과 자동화 실전

터미널 창에서 열여덟 번째로 실패한 테스트가 막 끝났습니다. /clear라는 명령을 조금만 더 일찍 알았더라면 이 시간까지 버티지 않아도 됐을 겁니다.

공식 데이터에 따르면 Claude Code는 SWE-bench 테스트에서 코드 문제의 80.9%를 스스로 해결할 수 있습니다. 하지만 문제는 이것입니다. 여러분은 정말 그 핵심 능력을 쓰고 있나요? 대부분의 사람은 Claude Code를 실행한 뒤 claude 명령으로 몇 마디 나누고, 코드를 조금 고친 다음 끝냅니다. 50개가 넘는 명령 중 3-5개만 쓰며 효율 잠재력의 90%를 놓치고 있습니다.

이 글에서는 7가지 CLI 팁과 3가지 자동화 실전 사례를 공유합니다. 기본 명령부터 컨텍스트 관리, Hooks 설정, CI/CD 통합까지 상황별로 정리한 체계적인 방법입니다. 읽고 나면 “쓸 줄 아는” 수준에서 “정말 효율적으로 쓰는” 수준으로 올라갈 수 있습니다.

1장: CLI 기본 3종 세트 - 실행, 모드, 명령

먼저 기본기를 단단히 잡아야 뒤의 고급 팁도 의미가 있습니다.

1.1 세 가지 실행 방식, 각각의 용도

claude              # 현재 디렉터리에서 대화형 인터페이스 실행
claude -c           # 가장 최근 세션 이어가기
claude --print "이 함수의 타입 정의를 확인해 줘"  # 일회성 질의 후 종료

많은 사람이 첫 번째 방식만 압니다. 사실 두 번째 -c가 특히 실용적입니다. 방금 세션을 닫았는데 아직 해결하지 못한 문제가 떠올랐다면 claude -c만 실행하면 이전 컨텍스트를 바로 이어갈 수 있습니다. 프로젝트 배경을 처음부터 다시 설명할 필요가 없습니다.

세 번째 --print는 빠른 조회에 씁니다. 예를 들어 타입 정의가 맞는지 확인하고 싶을 때 명령 하나로 끝낼 수 있고, 전체 대화형 모드에 들어갈 필요가 없습니다. 시간이 절약됩니다.

1.2 세 가지 작업 모드, 상황에 맞게 전환하기

이것은 공식 문서의 핵심 개념이며, Alibaba Cloud의 심층 글에서도 별도로 다룬 내용입니다.

Default 모드에서는 파일을 수정하거나 명령을 실행할 때마다 수동 확인이 필요합니다. 번거롭지만 안전합니다. 낯선 프로젝트를 파악할 때 적합합니다.

Auto-Accept 모드는 파일 수정을 자동으로 실행하고, shell 명령은 여전히 확인을 요구합니다. 본인 프로젝트에서 대량 리팩터링을 할 때 이 모드를 쓰면 Claude가 한 번에 수정하고, 마지막에 여러분이 한꺼번에 검토하면 됩니다. 효율이 크게 올라갑니다.

Plan 모드는 복잡한 문제를 분석할 때 즐겨 씁니다. Claude가 먼저 전체 프로젝트를 읽고 상세한 실행 계획을 출력하게 합니다. 이 단계에서는 아무것도 수정하지 않고 계획만 세웁니다. 계획이 믿을 만하다고 판단되면 Auto-Accept 모드로 전환해 실행합니다.

1.3 꼭 기억해야 할 세 가지 slash 명령

공식 명령은 50개가 넘지만, 대부분은 10%도 쓰지 않습니다. 제가 가장 자주 쓰는 세 가지는 이것입니다.

/init     # 프로젝트를 스캔해 CLAUDE.md 설정 파일 생성
/clear    # 세션 기록 비우기
/compact  # 컨텍스트를 압축해 token 절약

/init은 새 프로젝트에서 처음 실행할 때 씁니다. Claude가 전체 코드베이스를 스캔해 설정 파일을 만들고, 프로젝트 구조와 의존성, 규칙을 알려 줍니다. 이후 모든 작업은 이 설정을 참고합니다.

/clear는 뒤에서 따로 다루겠습니다. 제가 발견한 가장 큰 효율 향상 포인트입니다.

/compact는 컨텍스트에 대화 기록이 너무 많이 쌓였을 때 씁니다. Claude가 핵심 정보만 남기고 중복 대화를 삭제해 token 소비를 줄입니다. 한 세션 안에서 여러 차례 수정을 반복했을 때 적합합니다.

2장: 컨텍스트 관리의 기술 - 비우기, 압축하기, 병렬화하기

이 부분은 Builder.io의 실전 글에서 힌트를 얻었습니다. 그들은 /clear를 “가장 큰 생산성 향상 포인트”라고 말했습니다. 일주일 동안 직접 써 보니 정말 그랬습니다.

2.1 /clear의 올바른 사용법

언제 세션을 비워야 할까요?

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

작업을 전환할 때입니다.

예를 들어 방금 버그 하나를 고치며 Claude와 스무 차례 대화했고, 문제 위치도 찾았습니다. 그런데 갑자기 다른 긴급 issue를 처리하라는 요청이 들어왔습니다. 많은 사람은 같은 세션에서 그대로 주제를 바꿉니다.

잘못된 방식입니다.

이때는 먼저 /clear를 실행해 방금까지의 대화 기록을 모두 지워야 합니다. 왜일까요? 그 대화 기록은 token을 차지하고, 새 작업과는 전혀 관련이 없기 때문입니다. Claude는 이전 컨텍스트에 “오염”되어 새 문제를 이해하는 품질이 떨어질 수 있습니다.

제 습관은 간단합니다. 한 작업에서 다른 작업으로 넘어갈 때 먼저 /clear를 실행하고, 새 작업의 배경을 짧게 설명합니다. 오래된 세션에서 계속 대화하는 것보다 훨씬 결과가 좋습니다.

2.2 /compact는 언제 쓸까

같은 작업 안에서 여러 차례 수정을 반복했다고 해 봅시다. 파일을 십여 개 고치고, 메시지가 30개를 넘었습니다. 이때 컨텍스트는 이미 꽤 길어져 있습니다.

/compact는 이런 기록을 압축합니다. 수정한 파일과 중요한 결정 같은 핵심 정보는 남기고, 중복 대화는 삭제합니다.

언제 실행하면 좋을까요? 저는 대략적인 규칙을 정했습니다. 대화가 30개를 넘으면 한 번 compact합니다. 너무 정확할 필요는 없습니다. “좀 길어졌네”라는 느낌이 들면 한 번 눌러 주면 됩니다.

2.3 병렬 세션 전략

이 팁은 Claude 공식 Help Center에서 가져왔습니다. 동시에 3-5개의 세션을 실행하고, 각 세션은 서로 다른 git worktree에서 코드베이스의 다른 부분을 처리합니다.

git worktree란 무엇일까요? 간단히 말해 같은 저장소에서 여러 작업 디렉터리를 만드는 기능입니다. 각 디렉터리는 서로 다른 브랜치를 사용할 수 있습니다.

# worktree 생성
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# 서로 다른 worktree에서 Claude 실행
cd ../feature-A && claude
cd ../feature-B && claude

이렇게 하면 두 개의 터미널 창에서 동시에 일할 수 있습니다. 하나는 Claude에게 feature-A 코드를 쓰게 하고, 다른 하나는 feature-B를 처리하게 합니다. 두 세션은 서로 간섭하지 않고, 컨텍스트도 각각 독립적입니다.

또 하나 실용적인 터미널 팁이 있습니다. Ctrl+B를 누르면 오래 실행되는 bash 명령을 백그라운드로 보낼 수 있습니다. Claude가 npm install이나 긴 테스트 같은 시간이 걸리는 작업을 실행할 때 세션 화면이 막히지 않아 편합니다.

3장: 자동화 3종 세트 - Hooks, Routines, CI/CD

앞에서 다룬 팁은 모두 수동 작업에 가깝습니다. 이제부터는 자동화입니다. Claude가 여러분이 일하는 동안 반복 작업까지 함께 처리하게 만드는 방법입니다.

3.1 Hooks 메커니즘: 작업 트리거

Hooks는 Claude Code 자동화의 핵심입니다. 주요 유형은 세 가지입니다.

가장 실용적인 것은 PostToolUse입니다. Claude가 코드를 수정할 때마다 자동으로 테스트를 실행하는 hook을 설정할 수 있습니다.

// settings.json 설정 예시
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

이 설정의 효과는 단순합니다. Claude가 Write 도구로 파일을 수정한 뒤 자동으로 npm test를 실행합니다. 테스트가 실패하면 Claude가 출력 내용을 보고 스스로 문제를 고칩니다.

3.2 Routines: 반복 흐름 정의하기

Routines는 반복적으로 등장하는 작업 흐름을 정의하는 데 적합합니다.

공식 문서의 예시는 이렇습니다. Claude가 특정 조건, 예를 들어 어떤 파일이 존재한다는 사실을 감지하면 미리 정해 둔 명령들을 자동으로 실행합니다.

구체적인 설정은 조금 복잡해서 저는 아직 운영 환경에서 대규모로 사용해 보지는 못했습니다. 하지만 방향성은 충분히 탐색할 만합니다. “매번 해야 하는 검사”를 고정된 흐름으로 만들어 두면 매번 Claude에게 수동으로 알려 줄 필요가 없습니다.

3.3 CI/CD 통합: GitHub Actions 실전

이것은 공식이 제공하는 headless 모드, 즉 claude -p입니다.

GitHub Actions에서 사용하면 Claude가 PR review, issue 구현, 보안 감사를 자동으로 처리하게 할 수 있습니다.

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

GitLab의 공식 블로그에서는 세 가지 워크플로를 소개했습니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

1. issue에서 MR 생성
2. 성능 회귀 분석
3. 기능을 직접 구현하고 CI로 검증

이 방향은 아직 연구 중이지만 잠재력은 이미 보입니다. Claude Code를 전체 개발 흐름에 끼워 넣어 CI/CD 파이프라인의 일부로 만드는 것입니다.

4장: 실전 사례 - 설정에서 자동화까지

원리를 살펴봤으니 이제 실제로 어떻게 쓰는지 보겠습니다.

사례 1: 한 문장으로 git commit 끝내기

제가 가장 자주 쓰는 장면입니다.

전통적인 방식은 git add, git status, commit message 작성, git commit입니다. 한 번에 몇 분은 걸립니다.

Claude Code를 쓰면 이렇게 됩니다.

claude
> commit these changes

한 문장입니다. Claude가 현재 변경 사항을 자동으로 읽고 적절한 commit message를 만든 뒤 제출합니다. 변경 내용을 분석하고 이번 수정의 핵심 의도를 이해해 의미 있는 message를 작성합니다.

직접 써 보니 생성되는 message 품질이 제가 직접 쓰는 것보다 좋을 때도 많았습니다. 정말 diff 내용을 읽고 쓰기 때문입니다. 대충 적는 것이 아닙니다.

사례 2: PostToolUse Hook으로 테스트 자동 실행하기

아까 본 hook 설정으로 돌아가겠습니다. 전체 버전은 이렇게 쓸 수 있습니다.

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write"는 Write 도구, 즉 파일 수정을 감시한다는 뜻입니다. npm run test:related는 제가 직접 정의한 명령으로, 수정한 파일과 관련된 테스트만 실행합니다. 전체 테스트가 아니어서 훨씬 빠릅니다.

효과는 분명합니다. Claude가 코드를 고칠 때마다 30초 안에 테스트 결과를 볼 수 있습니다. 실패하면 Claude가 출력 내용을 받고 자동으로 수정합니다.

제가 한 번 겪은 문제도 있습니다. 처음에는 전체 테스트인 npm test를 설정했는데 너무 느려 자주 timeout이 났습니다. 관련 파일만 테스트하도록 바꾸자 문제가 해결됐습니다.

사례 3: GitHub Actions로 PR Review 자동화하기

이 설정은 공식 문서에서 가져온 것입니다.

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

이 workflow는 PR이 생성되거나 업데이트될 때 실행되어 Claude가 자동으로 코드를 review하고 PR에 댓글을 남기게 합니다. 코드 품질, 잠재적 bug, 보안 취약점, 성능 문제를 확인할 수 있습니다.

한 달 동안 써 보니 직접 review할 때보다 더 많은 bug를 잡아냈습니다. Claude는 게으름을 피우지 않고 모든 파일을 꼼꼼히 보기 때문입니다.

5장: 생산성을 배로 올리는 팁 - 설정 단순화와 도구 체인 통합

마지막 몇 가지 팁은 Marmelab과 Builder.io의 글에서 배웠습니다. 전체 workflow를 더 매끄럽게 만드는 방법에 관한 내용입니다.

5.1 CLAUDE.md를 짧게 쓰는 철학

많은 사람이 CLAUDE.md 설정 파일을 아주 자세히 씁니다. 프로젝트 배경, 기술 스택 규칙, 코드 스타일, 금지 사항까지 몇천 자로 길게 적습니다.

Marmelab의 조언은 반대입니다. CLAUDE.md를 가능한 한 짧게 유지하세요.

왜일까요? 설정이 길수록 Claude가 “과도하게 따르기” 쉬워집니다. 매번 작업할 때 설정을 되짚어 보느라 오히려 유연성이 떨어집니다. 긴 설정 자체도 token을 소비합니다.

그들이 권장하는 방식은 가장 핵심적인 3-5개 규칙만 쓰고, 설정을 “코드베이스를 단순화하는 강제 함수”처럼 다루는 것입니다. 예를 들면 이렇게요.

# CLAUDE.md
- TypeScript 엄격 모드, 모든 변수에 타입 지정
- 컴포넌트 파일은 src/components/에 배치
- 테스트 파일은 소스 파일과 같은 디렉터리에 배치
- var를 쓰지 말고 const와 let만 사용

이 정도면 충분합니다.

5.2 Bash Wrapper 전략

Builder.io의 글에서 특히 인상 깊었던 관점이 있습니다. 긴 문서 설명을 쓰지 말고 bash wrapper 스크립트를 쓰라는 것입니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

예를 들어 팀원이 프로젝트를 빠르게 실행하게 하고 싶다면, “먼저 npm install을 하고, 환경 변수를 설정한 다음 dev server를 실행하세요” 같은 복잡한 README를 쓰기보다 스크립트 하나를 만드는 편이 낫습니다.

#!/bin/bash
# dev.sh - 개발 환경 빠른 실행

npm install
source .env.local
npm run dev

그러면 Claude Code에서는 “run dev.sh”라고 말하기만 하면 됩니다. 단순하고 머리를 덜 씁니다.

이 사고방식은 Claude 자체에도 적용할 수 있습니다. 자주 쓰는 명령 조합을 alias나 script로 감싸 두면 매번 긴 명령을 입력하지 않아도 됩니다.

5.3 MCP Server 통합: 보안 검사와 출력 필터링

마지막은 MCP(Model Context Protocol) 관련 도구 통합입니다.

실용적인 예시는 두 가지입니다.

Snyk MCP Server: Claude가 코드를 작성할 때 보안 취약점과 의존성 문제를 자동으로 검사하게 합니다. 직접 알려 주지 않아도 새 의존성을 도입할 때마다 보안 스캔을 실행할 수 있습니다.

rtk 도구: 명령 출력을 필터링하고 압축합니다. GitHub에도 이와 관련한 전용 팁이 있습니다. 많은 CLI 명령의 출력은 매우 깁니다. 예를 들어 npm install 로그는 token을 많이 차지합니다. rtk는 이런 출력을 압축해 핵심 정보만 남길 수 있습니다.

이 두 도구를 아직 완전히 통합하지는 못했지만 방향은 분명합니다. Claude Code를 단순한 코드 작성 도구가 아니라 보안 검사와 의존성 관리까지 포함한 전체 도구 체인에 연결하는 것입니다.

정리

길게 이야기했지만 핵심은 몇 가지입니다.

기본 명령을 탄탄히 익히세요. 세 가지 실행 방식과 세 가지 작업 모드를 상황에 맞게 전환해야 합니다. 가장 단순한 방식 하나만 쓰지 마세요.

컨텍스트 관리를 귀찮아하지 마세요. 작업을 바꿀 때는 /clear, 대화가 너무 길어지면 /compact를 쓰세요. 이 두 습관만으로도 많은 token 낭비를 줄일 수 있습니다.

자동화에는 투자할 가치가 있습니다. Hooks 설정과 GitHub Actions 통합은 초반에 조금 배워야 하지만, 이후 절약되는 시간은 몇 배로 돌아옵니다.

설정은 간결하게 유지하세요. CLAUDE.md는 짧게 쓰고, 복잡한 절차는 스크립트로 감싸세요. 문서가 길다고 항상 좋은 것은 아닙니다.

제 제안은 이렇습니다.

1. 오늘 바로 시도하기: 현재 세션에서 /clear를 입력해 비운 뒤의 가벼움을 느껴 보세요
2. 이번 주 과제: PostToolUse hook을 하나 설정해 Claude가 코드를 수정할 때마다 테스트를 자동 실행하게 하세요
3. 장기 목표: Claude Code를 CI/CD 흐름에 넣어 팀의 표준 도구로 만드세요

Claude Code 설정 최적화를 더 깊이 알고 싶다면 이 시리즈의 첫 번째 글인 “Claude가 코드를 제멋대로 쓰게 두지 마세요! 설정 파일 하나로 AI 정확도를 10% 높이는 법”을 참고하세요. Subagent 메커니즘이 궁금하다면 두 번째 글인 “Claude 답변이 너무 장황한가요? Subagent로 나만의 AI 팀 만들기”를 보세요. 이 글은 시리즈의 일곱 번째 글이며 CLI 명령줄 팁에 집중했습니다.

이 팁들은 모두 제가 시행착오를 겪은 뒤에야 배운 것들입니다. 이 글을 읽고 여러분은 시행착오를 조금 줄이고, 더 빨리 효율을 끌어올릴 수 있기를 바랍니다.