콘텐츠로 이동

커서(Cursor) 대신 클로드 코드를 쓰는 이유: 여섯 저장소의 설정 파일과 커밋 기록으로 본 선택

"커서와 클로드 코드 중 무엇이 더 좋은가요?"라는 질문을 받으면 기능표로 답하고 싶어집니다. 그런데 2026년 10월 기준 두 도구의 공식 문서를 나란히 펴 보면, 규칙 파일·서브에이전트·훅·터미널 실행처럼 에이전트 작업에 필요한 기능은 양쪽에 거의 다 있습니다. 그래서 이 글은 기능 우열 대신 다른 질문에 답합니다. 지금 내 저장소에 클로드 코드가 무엇을 남겼는가. 블로그 자동화, 개인 위키, 앱 두 개, 정책 정보 서비스까지 직접 운영하는 여섯 저장소의 설정 파일과 커밋 기록을 근거로 정리했습니다.

이 글의 기준

2025년 12월에 올린 같은 주제의 글은 유튜브 영상 한 편의 감상이었습니다. 2026-10-24에 직접 운영 중인 저장소의 기록으로 전면 다시 썼습니다. 커서에 대한 내용은 커서 공식 문서에서 확인한 기능만 적었고, 커서를 오래 써 본 사용자로서의 평가는 하지 않습니다. 커밋 수는 2026-10-24에 각 저장소에서 직접 센 값입니다.

1. 공식 문서로 맞대 본 기능: 차이는 생각보다 작다

먼저 두 도구가 같은 일을 어떤 파일로 하는지 공식 문서 기준으로 정리합니다.

하는 일 클로드 코드 커서
프로젝트 규칙 CLAUDE.md (저장소의 AGENTS.md도 읽음) .cursor/rules/*.mdc, AGENTS.md 지원
서브에이전트 .claude/agents/*.md .cursor/agents/ (호환용으로 .claude/agents/도 읽음)
훅 .claude/settings.json의 PreToolUse·PostToolUse 등 .cursor/hooks.json의 preToolUse·afterFileEdit 등
비대화형 실행 claude -p "…" agent -p "…" (Cursor CLI)
편집기 안 자동 완성 공식 문서에서 같은 기능을 찾지 못함 Tab: 입력 중 여러 줄 제안, 다음 수정 위치로 이동

표에서 눈에 띄는 줄은 서브에이전트입니다. 커서는 .claude/agents/에 둔 정의도 읽는다고 공식 문서에 적혀 있습니다. 클로드 코드용으로 만든 자산이 커서로 옮겨 갈 길이 열려 있다는 뜻입니다. 반대로 편집기 안에서 타이핑을 따라오는 자동 완성은 커서 쪽 고유 기능입니다.

교훈: 기능 체크리스트로는 두 도구를 가르기 어렵습니다. 고르는 기준은 "어디서 일하는가"와 "무엇을 파일로 남기는가"가 됩니다.

2. 근거 1 — 커밋 기록이 보여 주는 사용량

클로드 코드는 기본 설정에서 자신이 만든 커밋 메시지 끝에 Co-Authored-By: Claude … 줄을 붙입니다. 이 줄을 세면 도구가 실제로 얼마나 일했는지 숫자로 나옵니다.

저장소 성격 전체 커밋 Claude 공동 작성 첫 공동 작성
blogger-daemon 블로그 자동화 706 513 2025-07-29
on-pocket-news 정책 정보 수집 서비스 571 417 2026-02-20
my-wiki 개인 위키 230 224 2026-04-18
trendcompass-mkdocs 이 블로그 76 75 2026-06-27
workout-history 운동 기록 앱 729 710 2026-07-19
morningbrief 모닝 브리핑 앱 36 36 2026-10-05

가장 오래된 blogger-daemon의 공동 작성 줄을 모델 이름별로 나눠 보면, 2025-07-29의 이름 없는 Claude에서 시작해 Sonnet 4.5(2025-12), Opus 4.5·4.6·4.7·4.8을 거쳐 Fable 5(2026-07)까지 이어집니다. 모델은 계속 바뀌었지만 도구와 저장소의 규칙 파일은 그대로 이어졌습니다. 뒤에 시작한 저장소일수록 공동 작성 비율이 100%에 가깝다는 점도 보입니다.

교훈: 도구 선택의 근거는 인상보다 기록이 낫습니다. git log --grep으로 셀 수 있는 형태로 남겨 두면 나중에 판단을 다시 검토할 수 있습니다.

3. 근거 2 — CLAUDE.md가 규칙의 정본이 되었다

여섯 저장소 모두 루트에 CLAUDE.md가 있습니다. 개인 위키의 CLAUDE.md는 디렉터리 구조, 페이지 frontmatter, 원본 불변 규칙, 작성 후 셀프 체크까지 담은 스키마 문서입니다. 사용자 홈의 ~/.claude/CLAUDE.md에는 모든 프로젝트에 공통인 규칙(앱 번들 ID 형식, 릴리스 빌드가 끝나면 결과 폴더 열기 같은 것)을 둡니다.

다만 공식 문서는 분명히 선을 긋습니다. CLAUDE.md는 강제되는 설정이 아니라 맥락으로 다뤄지고, 어떤 행동을 반드시 막아야 한다면 PreToolUse 훅을 쓰라고 안내합니다. 그래서 규칙 파일은 "에이전트가 알아야 할 것", 훅과 검사 스크립트는 "어겨서는 안 되는 것"으로 나눠 씁니다.

교훈: 규칙 파일은 대화가 바뀌어도 남는 기억입니다. 다만 기억은 지켜질 확률을 높일 뿐이므로, 꼭 지켜야 하는 것은 실행되는 검사로 옮깁니다.

4. 근거 3 — 서브에이전트로 판단과 구현을 나눴다

이 블로그 저장소의 .claude/agents/에는 일곱 역할이 정의되어 있습니다. advisor, worker, reviewer, fact-checker, searcher, originality-guard, image-worker입니다. 운동 기록 앱에는 advisor, app-developer, ui-developer, tester, qa-reviewer, release-manager 여섯 역할이 있습니다.

역할 분리를 실제로 강제하는 장치는 frontmatter의 tools 줄입니다.

# trendcompass-mkdocs/.claude/agents/worker.md (frontmatter)
name: worker
tools: Read, Write, Edit, Bash, Glob, Grep    # 웹 검색 도구 없음

# trendcompass-mkdocs/.claude/agents/originality-guard.md (frontmatter)
name: originality-guard
tools: Read, Glob, Grep, WebFetch             # 쓰기 도구 없음

worker에게는 웹 검색 도구가 없어서 외부 사실이 필요하면 추측하지 않고 막힌 지점으로 보고해야 합니다. originality-guard는 글이 원본 영상의 구성과 표현을 따라가는지 검사하지만, 쓰기 도구가 없어 글을 직접 고칠 수 없습니다.

교훈: 역할 설명은 부탁이고 도구 목록은 구조입니다. 에이전트가 해서는 안 되는 일은 설명에 쓰기보다 도구를 빼서 막습니다.

5. 근거 4 — 훅으로 사람이 잊는 일을 맡겼다

정책 정보 서비스(on-pocket-news)의 .claude/settings.json에는 PostToolUse 훅이 하나 있습니다. Write 또는 Edit 도구가 끝날 때마다 실행되고, 수정된 파일이 BACKLOG.md이면 자동으로 커밋합니다.

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "… BACKLOG.md가 바뀌었으면 git add·commit·push …",
        "statusMessage": "BACKLOG.md 변경 감지 → 자동 커밋 push 중..."
      }]
    }]
  }
}

공식 문서에 따르면 PostToolUse는 도구가 이미 실행된 뒤라 그 호출을 막지 못합니다. 이 훅은 막는 장치가 아니라 백로그 기록을 잊지 않게 하는 장치입니다. 막아야 하는 일에는 PreToolUse 훅이 종료 코드 2로 도구 호출을 차단하는 방식을 씁니다.

교훈: 훅은 "언제 실행되느냐"로 용도가 갈립니다. 실행 전 훅은 차단에, 실행 후 훅은 기록과 검사에 씁니다.

6. 근거 5 — 터미널 한 줄이 루프의 부품이 된다

개인 위키의 루프 엔지니어링 실습은 테스트가 실패하면 실패 기록을 claude -p에 넘기고, 테스트가 통과할 때까지 반복합니다. 2026-10-04 실측에서는 두 번째 사이클에 통과했고, 호출 한 번에 약 $0.05(API 종량제 환산)가 들었습니다. --allowedTools에 Write가 빠지면 파일을 다시 쓰지 못해 같은 실패를 반복한다는 함정도 그때 확인했습니다.

node test.js > test.log 2>&1 || \
  cat test.log | claude -p "solution.js가 아래 테스트에서 실패한다. solution.js만 고쳐라." \
    --allowedTools "Read,Edit,Write"

공식 문서에 따르면 claude -p는 성공하면 종료 코드 0, 실패하면 0이 아닌 값을 돌려주므로 스크립트가 결과로 분기할 수 있습니다. 위키의 /ingest, /lint, /deploy 같은 작업도 .claude/commands/의 명령 파일로 두어 같은 절차를 매번 같은 방식으로 실행합니다. 커서도 agent -p로 같은 구성이 가능하지만, 지금까지 쌓인 스크립트와 명령 파일이 클로드 코드 기준으로 만들어져 있습니다.

교훈: 에이전트를 셸 명령 하나로 부를 수 있으면 테스트·빌드·배포 스크립트 사이에 끼워 넣을 수 있습니다. 이 성질이 편집기 안 경험보다 운영에서 더 크게 작용했습니다.

💡 원스의 인사이트: 도구보다 오래 남는 것은 저장소의 파일이다

이 글을 쓰며 확인한 사실은 두 도구의 기능 차이가 계속 줄어든다는 것입니다. 커서는 .claude/agents/까지 읽고, 클로드 코드는 AGENTS.md를 읽습니다. 그렇다면 도구 선택은 언젠가 다시 할 수 있는 결정이고, 다시 해도 잃지 않을 것을 쌓는 편이 낫습니다.

제가 클로드 코드를 계속 쓰는 이유는 결국 이 저장소들에 쌓인 파일입니다. 규칙은 CLAUDE.md에, 역할과 권한은 .claude/agents/에, 잊으면 안 되는 일은 훅에, 반복 절차는 명령 파일과 claude -p 스크립트에 있습니다. 편집기 안에서 한 줄씩 코드를 받아 쓰는 일이 많다면 커서의 Tab이 더 맞을 수 있습니다. 판단 기준은 도구의 평판이 아니라 내 작업이 어디서 일어나고 무엇을 파일로 남기는지입니다.

체크리스트 — 도구를 고르기 전에 확인할 것

  • [ ] 반복해서 말하는 규칙이 CLAUDE.md·AGENTS.md 같은 파일에 있다
  • [ ] 에이전트 역할마다 쓸 수 있는 도구 목록이 정해져 있다
  • [ ] 반드시 막아야 하는 행동은 규칙 파일이 아니라 실행 전 훅이나 검사로 막는다
  • [ ] 에이전트를 셸 한 줄로 불러 테스트·빌드 스크립트에 넣을 수 있다
  • [ ] 커밋 기록에서 도구의 실제 사용량을 셀 수 있다
  • [ ] 도구를 바꿔도 옮겨 갈 수 있는 형식(Markdown 규칙·에이전트 정의)으로 자산을 쌓는다

참고 자료 및 출처