Claude Code와 Cursor를 3개월간 병용하며 깨달은 점은, "어느 쪽이 우수한가"가 아니라 "어느 공정에서 전환할 것인가"가 생산성의 분수령이라는 것이었습니다.

이 기사에서는 설계·구현·리팩터링(Refactoring)·디버깅(Debugging)·리뷰(Review)의 5개 공정에서 두 도구를 검증한 결과와, 팀에 도입할 때의 판단 기준을 전달합니다.

Claude Code는 "터미널에 거주하는 AI 엔지니어"입니다. 파일 조작·명령어 실행·Git 조작까지 일관되게 수행하며, 프로젝트 전체를 조망하는 큰 작업을 잘합니다. CLAUDE.md로 프로젝트 규칙을 정의하고, CLI에서 자율적으로 태스크를 수행합니다.

Cursor는 "에디터에 녹아든 AI 부조종사"입니다. 열려 있는 파일의 컨텍스트(Context)를 깊이 이해하며, 인라인 편집이나 채팅 기반의 대화로 세밀한 수정을 빠르게 처리할 수 있습니다. .cursorrules로 프로젝트 고유의 규칙을 부여할 수 있습니다.

한쪽만으로 모든 공정을 커버하려고 하면, 각자의 약한 영역에서 시간을 낭비하게 됩니다. 저희 팀에서도 처음 한 달은 "Claude Code 단일화"를 시도했지만, 세밀한 UI 조정에서 작업이 왔다 갔다 하는 일이 늘어나 오히려 생산성이 떨어졌습니다.

3개월간의 검증을 통해 다음과 같은 매트릭스로 결론을 내렸습니다.

어떤 프로젝트에서 "사용자 대시보드에 알림 기능을 추가한다"는 태스크가 있었습니다.

claude "알림 기능을 구현해줘. 요구사항은 다음과 같아:
- API 엔드포인트: GET /api/notifications, PATCH /api/notifications/:id/read
- DB 스키마: notifications 테이블 (Prisma)
...

Claude Code는 CLAUDE.md에 작성된 프로젝트 규약(디렉터리 구성, 명명 규칙, 사용 라이브러리)을 읽어 들여, 7개 파일을 일괄 생성했습니다. Prisma 스키마 업데이트, API 루트 생성, 컴포넌트 스캐폴딩(Scaffolding)까지 약 2분이 소요되었습니다.

생성된 컴포넌트를 Cursor로 열어 다음과 같이 대화형으로 수정했습니다.

• 드롭다운 애니메이션 조정
• 기존 디자인 시스템과의 스타일 통합
• 엣지 케이스(알림 0건일 때의 표시) 추가

이 "Claude Code로 크게 만들고 Cursor로 다듬는" 패턴을 통해, 기존의 수동 구현과 비교하여 약 65%의 시간 단축을 실현할 수 있었습니다.

기존 인증 모듈(약 800행의 단일 파일)을 책임에 따라 4개 파일로 분할하는 태스크가 있었습니다.

Claude Code에 "이 파일을 책임별로 분할해줘"라고 요청하자, 분할 자체는 이루어졌으나 파일 간의 의존 관계로 인해 타입 에러(Type Error)가 몇 군데 발생했습니다. Claude Code는 자율적으로 에러 수정을 시도했지만, 수정→새로운 에러→수정의 루프가 3번 정도 이어졌습니다.

Cursor에서는 대상 파일을 열어둔 상태에서 단계적으로 리팩터링을 지시했습니다.

• "먼저 인증 로직 부분만 auth-core.ts로 추출해줘" - "다음으로 토큰 관리를 token-manager.ts로 옮겨줘" - "남은 유틸리티를 auth-utils.ts로 분리해줘"

각 단계에서 에디터 상의 diff를 실시간으로 확인할 수 있었고, 타입 에러가 발생하는 즉시 그 자리에서 수정을 요청할 수 있었습니다. 결과적으로 수정 루프 없이 약 15분 만에 완료했습니다.

이러한 차이가 발생한 이유는 Cursor가 편집 중인 파일의 변경 차분(diff)을 실시간으로 파악하고 있다는 점에 있습니다. 단계적인 변경 사항이 "지금 어디까지 바뀌었는지"를 정확하게 트래킹할 수 있기 때문에, 리팩터링 (Refactoring)과 같은 점진적인 작업에 강합니다.

테스트 생성에 대해서는 Claude Code가 우세한 경우가 많았습니다.

claude "src/services/notification.ts 의 유닛 테스트를 작성해줘.
Jest + ts-jest를 사용하고, 모킹 (Mocking)은 PrismaClient를 사용해.
정상 케이스 3가지 패턴, 이상 케이스 2가지 패턴을 포함해서"

Claude Code의 강점은 다음과 같습니다.

• 테스트 대상 파일뿐만 아니라, 의존하는 모듈도 자동으로 읽어옴
• 테스트 파일 작성뿐만 아니라, npm test까지 실행하여 통과하는지 확인해줌
• 실패한 테스트를 자동으로 수정하는 루프 (Loop)가 내장되어 있음

반면, Cursor로 테스트를 작성할 경우에는 테스트 대상 파일과 의존 파일을 수동으로 열거나 컨텍스트 (Context)에 추가해야 합니다. 단일 유틸리티 함수의 테스트라면 Cursor로도 충분하지만, 서비스 계층 (Service Layer)처럼 의존성이 복잡한 테스트에서는 Claude Code가 효율적이었습니다.

병용 시 가장 까다로웠던 점은 프로젝트 규칙의 이중 관리 문제였습니다.

• CLAUDE.md에는 "컴포넌트는 named export를 사용한다"라고 기재
• .cursorrules에는 "default export를 권장"한다고 기재 (초기 설정의 잔재)
• 결과적으로 Claude Code가 만든 파일을 Cursor로 편집하면, export 방식을 멋대로 바꿔버림

저희 팀은 다음과 같은 운영 규칙으로 결론을 내렸습니다.

Single Source of Truth (CONVENTIONS.md)를 하나 만들고, 거기서 CLAUDE.md와 .cursorrules를 생성하는 방식입니다.

# generate-ai-rules.sh 예시
#!/bin/bash
node scripts/generate-claude-md.js > CLAUDE.md
...

이를 통해 규약의 변경은 CONVENTIONS.md 한 곳에서만 이루어지며, 두 도구 간의 모순을 방지할 수 있습니다.

3개월간의 검증을 통해 얻은 가장 중요한 배움은, 도구의 사용법을 개인의 취향에 맡기면 팀 전체의 생산성이 올라가지 않는다는 것입니다.

다음과 같은 "도구 선택 정책 (Tool Selection Policy)"을 팀 문서에 추가할 것을 강력히 권장합니다.

## AI 도구 선택 정책 (예시)
### Claude Code를 사용하는 상황
- 신규 파일 일괄 생성 (3개 이상의 파일에 걸친 변경)
...

• Claude Code는 "크게 만들기·전체 보기", Cursor는 "세밀하게 고치기·깊게 이해하기"가 기본 활용법입니다. 설계·신규 구현·테스트 생성·리뷰는 Claude Code가, 리팩터링·부분 수정·UI 조정은 Cursor가 효율적이었습니다.
• CLAUDE.md와 .cursorrules의 이중 관리는 가장 큰 함정입니다. Single Source of Truth가 되는 규약 파일을 하나 만들고, 거기서 양쪽을 모두 생성하는 메커니즘을 도입하세요.
• 팀 단위로 사용한다면 "도구 선택 정책"의 문서화가 필수입니다. 개인의 취향에 맡기지 않고 공정별 가이드라인을 명문화함으로써 팀 전체의 생산성을 안정화할 수 있습니다.