개발자를 위한 AI 빌드 코스 (Cursor와 Claude Code, 3배 증폭기로 쓰는 법)

AI는 개발자를 대체하지 않는다, 잘 쓰는 개발자가 못 쓰는 개발자를 대체한다.

"AI가 개발자를 대체한다"는 헤드라인의 거짓

작년 이맘때 LinkedIn과 뉴스레터를 도배한 문구를 기억하시나요. "LLM이 시니어 개발자 일자리를 없앤다", "Cursor 하나면 팀 전체가 필요 없다." 그 기사들은 두 가지를 놓쳤어요.

첫째, 그 헤드라인을 쓴 사람들은 대부분 AI 도구를 제대로 써본 개발자가 아니었습니다. 둘째, 정말로 사라진 건 개발 일자리가 아니라 부실한 개발자들이에요. Cursor 쓰는 주니어와 쓰지 않는 주니어 사이의 생산성 차이는 지금 2배에서 5배까지 벌어졌습니다.

Slack이나 GitHub 같은 한국 스타트업 개발팀에서 이미 벌어지고 있는 일이에요. 당신이 망설이는 동안, 옆 팀의 개발자는 이미 Claude Code로 모노레포 리팩터링을 자동화했어요. 문제는 AI가 아니라 "얼마나 잘 쓰느냐"입니다.

잘 쓰는 개발자의 3가지 능력

AI 도구가 보편화될수록 개발자 간 격차는 역설적으로 더 커집니다. 스킬이 아니라 사고방식의 차이 때문이에요.

1. 컨텍스트 설계

Cursor에 한 줄 던져도, 당신이 프로젝트 구조와 코딩 규칙을 제대로 이해하고 있지 않다면 AI 코드는 쓸모없어요. 컨텍스트 설계란 AI가 "당신의 프로젝트를 이해할 수 있도록" 명시적으로 정보를 구조화하는 능력입니다. .cursorrules에 팀 컨벤션, CLAUDE.md에 프로젝트 규칙을 적어두면 매번 같은 설명을 반복할 필요가 없어요. 30%의 토큰 절감 효과까지 있습니다.

2. 검증 감각

AI가 생성한 코드를 받고 "이게 맞나?"라고 의심하는 개발자와 "좋네, 머지하자"는 개발자는 완전히 다릅니다. 좋은 개발자는 먼저 논리 흐름을 읽고, 타입 체크하고, 엣지 케이스를 생각해요. "이 함수가 null을 받으면?" "동시성 문제는?" 이런 질문을 AI 생성 코드에도 적용합니다.

3. 디버깅 능력

"이 코드가 왜 안 되지?"라고 물을 때, 잘 쓰는 개발자는 로그, 에러 메시지, 스택 트레이스를 읽고 문제를 AI에게 설명할 수 있어요. "Cannot read property 'map' of undefined"라는 에러 메시지만 주면 AI도 초점을 잃습니다. "Line 45에서 user.orders가 undefined인데, 여기선 API가 항상 배열을 반환해야 해"라고 맥락까지 주면 Claude Code는 원인을 5초 안에 찾아요.

Cursor와 Claude Code, 두 도구 두 철학

"Cursor vs Claude Code" 논쟁의 정답은 둘 다 써야 한다예요. 다만 언제 어느 걸 쓸지 알아야 합니다.

Cursor는 페어 프로그래머. IDE의 모든 곳에서 AI가 함께해요. 탭 자동완성, 인플레이스 편집(Ctrl+K), Chat, Composer까지. 한 파일을 빠르게 수정할 때, 엣지 케이스 한두 개 처리할 때는 Cursor가 최고예요. IDE 내에서 완결된 경험이라 문맥을 놓칠 일이 거의 없습니다.

Claude Code는 감독. "이 모노레포에서 결제 관련 타입을 전부 찾아서 Stripe v3 스키마로 리팩터링해"라고 하면, 계획을 세우고 스캔하고 여러 파일을 동시에 수정합니다. 복잡한 리팩터링, 여러 모듈 걸친 기능 추가에는 Claude Code가 효율적이에요. 팀 모두가 Claude를 쓴다면 CLAUDE.md를 공유해서 컨텍스트를 일관되게 유지할 수 있고요.

한국 스타트업 사례에서 Team-Attention의 정구봉 개발자는 "Cursor는 5분 짜리 작업, Claude Code는 30분 이상 걸릴 복잡한 작업에 쓴다"고 했어요. Sionic AI팀의 박진형은 "멀티 LLM 워크플로우"를 언급했고요. Claude가 다른 도구들(코드리뷰, 빌드 검증)을 MCP로 엮으면, 한 번의 명령으로 분석→가설→구현→검증까지 자동화됩니다.

선택 기준: 파일 1~3개, 5분 이내 작업이면 Cursor. 모듈 전체, 설계 필요한 작업이면 Claude Code.

좋은 프롬프트 패턴 7종

패턴 1. Plan → Execute 분리

이 기능 구현 전에 먼저 계획을 세워줄래?
- 변경할 파일
- 각 파일의 주요 변경점
- 예상 위험 요소
그 다음에 코드를 작성해.

AI가 성급하게 코딩하는 걸 방지합니다. 계획 단계에서 "DB 마이그레이션도 필요하네"라고 지적하면, 코드를 다시 쓸 필요가 없어요.

패턴 2. Spec-driven (명세 먼저)

다음 TypeScript 인터페이스를 만족하는 함수를 작성해줄래?

interface UserCreateRequest {
  email: string;
  age: number;
  // ...
}

에러 케이스는 InvalidInputError를 throw 하도록.

명세 먼저 제시하면 AI 생성 방향이 명확해집니다.

패턴 3. Example-driven (예제 3~5개)

// 프롬프트: 이 패턴대로 validation 함수를 작성
validateEmail('test@example.com') // true
validateEmail('invalid.email')    // false
validateEmail('a@b.c')            // true
validateEmail('')                 // false

예제는 천 마디 설명보다 효과적이에요. AI가 패턴을 학습해 엣지 케이스까지 자동 처리합니다.

패턴 4. Constraint-first (제약 조건 명시)

다음 제약 아래 구현:
- 동기 함수만
- 의존성 추가 금지
- 함수 크기 20줄 이하
- 정규식 금지

제약이 있으면 오버 엔지니어링을 막아요.

패턴 5. Diff-based (이전 코드 비교)

아래 코드에서만 변경해줄래?
전체 함수를 새로 쓰지 말고, 최소 변경만.

리팩터링 시 유용합니다.

패턴 6. Review-first (리뷰 기준 먼저)

이 코드를 리뷰해줄 때 특히 다음을 봐줘:
- 반복 코드
- null 체크
- N+1 문제
- 누락된 에러 처리

그 다음에 수정 제안을 줄래?

시니어 리뷰어 역할을 AI에게 미리 정의하는 패턴.

패턴 7. Iterative refinement (반복 개선)

먼저 기본 구현을 해줘.
그 다음에 성능을 10배 개선해줄래?

한 번에 모든 걸 요구하면 일관성이 떨어져요. 단계별로 개선하면 각 단계마다 최적화된 결과를 얻습니다.

AI를 시니어 코드리뷰어로 만드는 법

"코드 리뷰"는 개발자가 가장 싫어하면서도 가장 중요한 일이에요. Claude Code의 Code Review 기능은 이를 위해 설계됐지만, 그냥 쓰면 소용없어요. 좋은 리뷰는 당신 팀의 기준을 반영해야 합니다.

먼저 .cursorrules 또는 CLAUDE.md에 리뷰 기준을 적어둡니다.

# Code Review 기준

1. 타입 안전성
   - TypeScript strict mode
   - 모든 함수 입출력 타입 명시
   - any 금지

2. 에러 처리
   - 모든 Promise에 catch
   - API 호출은 에러 메시지와 함께 로깅

3. 성능
   - DB 쿼리 N+1 체크
   - 컴포넌트 memo/useMemo 최적화
   - 번들 +10KB 시 거부

4. 보안
   - SQL injection, XSS
   - 민감 데이터 .env 격리

이제 PR마다 "코드 리뷰 시작"만 하면, Claude Code가 당신의 기준에 맞춰 리뷰합니다. 시니어 개발자와 비슷한 속도, 편파성 없음, 피로 인한 품질 저하 없음.

한국 Corca팀 배휘동 개발자는 "레거시 코드베이스에 AI를 도입했을 때, 처음엔 너무 엄격해서 팀이 반발했다. 그래서 CLAUDE.md에 '이 레거시 섹션은 예외'라고 적었다. 그 순간부터 AI는 팀에 맞게 리뷰했다"고 했어요.

실전 예제, .cursorrules와 CLAUDE.md

.cursorrules 예제 (Next.js + TypeScript)

# .cursorrules

코딩 스타일
- 함수 최대 30줄
- 변수명 camelCase
- 상수 UPPER_SNAKE_CASE
- 컴포넌트는 FC<Props>

에러 처리
- try-catch는 Server Action에서만
- 항상 console.error + UI 피드백

성능
- 이미지는 next/image
- 번들 크기 변화 빌드 로그에 표시

CLAUDE.md 예제

# CLAUDE.md

기술 스택
- Node.js + Express + TypeScript
- PostgreSQL (Supabase)
- React 18 + Tailwind
- Vercel

필수 규칙
- 모든 API 엔드포인트는 /api/v1
- DB 쿼리는 Prisma ORM만
- 환경 변수는 .env.example 정의 후

컨벤션
- Error는 AppError 상속
- Middleware는 /middlewares만
- 타입은 /types 중앙화

마지막 성공 패턴
- API 응답: { success, data, error }
- 비동기는 Bull Queue
- 검증은 zod + class-validator

새 기능 구현 프롬프트 템플릿

[기능명] 구현.

요구사항: [명세]

제약:
- TypeScript strict
- 테스트 커버리지 70%+
- 1000개 데이터 처리 < 500ms

먼저 계획을 세운 후 테스트부터 작성해줄래?

마무리

AI는 개발자를 대체하지 않습니다. 대신 잘 쓰는 개발자가 못 쓰는 개발자를 대체해요. 이게 이 글의 핵심입니다.

다음 편에서는 AI에게 맡기면 안 되는 것을 배웁니다. Cursor가 최강이어도 아키텍처 결정은 당신이 해야 해요. 보안 결정도. 비즈니스 핵심 로직도. 그 경계를 정확히 아는 순간, 당신은 AI 시대의 진정한 개발자가 됩니다.

참고 자료

1. Team-Attention (2026), "Claude Code와 함께 만드는 AI 워크플로우, 개발부터 의사결정까지", Claude Code Meetup Seoul. luma.com/bukeklzx
2. Corca (2026), "레거시 코드베이스에서 에이전트와 사람을 함께 일잘러로 만드는 환경 구축", Claude Code Meetup Seoul
3. SLEXN (2025), "AI-IDE의 Context (문맥) 관리: Cursor, Windsurf, Qodo의 코드 이해 방식 비교"
4. SK DevOcean (2025), "나의 새로운 주니어 개발자는 AI? LLM을 활용한 코드 리뷰 자동화"
5. Claude Code Documentation (2026), "Code Review Guide"
6. Cursor Documentation (2026), "컨텍스트 활용하기"

이전 편: 비개발자도 1주일이면 앱을 만든다 (5분 SaaS의 진실)
다음 편: 100만 원짜리 실수, AI에게 절대 맡기면 안 되는 것

김민철, 프리아이브 CEO, 페일스쿨