Cursor로 Django 개발하기: 몇 달 써보고 정리한 실전 워크플로

핵심 요약: Cursor는 Django 개발과 궁합이 좋습니다. 모델-시리얼라이저-뷰-테스트로 이어지는 Django 특유의 반복 구조를 Tab 자동완성이 잘 따라오고, Agent는 앱 단위 보일러플레이트 생성에 강합니다. 다만 그대로 쓰면 AI가 "뷰에 비즈니스 로직을 다 밀어넣는" Django 안티패턴을 자주 만들기 때문에, .cursor/rules에 프로젝트 규칙을 정의하는 것이 실질적인 성패를 가릅니다. 이 글은 실제 Django 프로젝트에 몇 달 적용하며 정리한 워크플로입니다.

이 글에서 다루는 내용: Django에서 잘 통하는 작업과 안 통하는 작업, Rules 설정 예시, 작업 유형별 워크플로, 몇 달간의 시행착오.

Cursor가 Django에서 특히 잘하는 것

연쇄 수정 자동완성. Django는 모델을 바꾸면 시리얼라이저, 뷰, admin, 테스트까지 따라 바뀌는 구조인데, Tab이 이 파급 경로를 잘 예측합니다. 모델에 필드 하나를 추가하면 시리얼라이저의 fields 목록, 팩토리의 기본값, 테스트의 assertion까지 수정 위치를 차례로 짚어줍니다. 체감 효율이 가장 큰 지점입니다.

보일러플레이트 생성. "이 모델에 대한 DRF CRUD 엔드포인트를 ViewSet + Router로 만들어줘" 같은 패턴화된 작업은 Agent가 거의 완성형으로 뽑아냅니다. admin 등록, URL 연결, 기본 테스트까지 한 번에 시키면 앱 하나의 뼈대가 몇 분 만에 나옵니다.

테스트 작성. 기존 테스트 파일의 스타일(pytest + factory_boy 등)을 파악해서 새 테스트를 같은 스타일로 만들어줍니다. 커버리지 채우기용 반복 작업에 특히 유용합니다.

주의: AI가 자주 만드는 Django 안티패턴

규칙 없이 쓰면 반복적으로 나오는 문제들이 있습니다. 가장 흔한 것이 "뷰가 곧 애플리케이션" 패턴입니다. 요청 파싱, 비즈니스 로직, 여러 모델 쓰기, 응답 렌더링을 전부 뷰 하나에 밀어넣은 코드를 만들어옵니다. 돌아는 가지만 Django의 "fat model, thin view" 관례와 어긋나서 유지보수가 어려워집니다. 그 외에도 N+1 쿼리(select_related/prefetch_related 누락), 필요 없는 곳에 signals 사용, 마이그레이션과 모델 상태 불일치가 단골입니다.

해결책: .cursor/rules에 Django 규칙 정의

프로젝트 루트의 규칙 파일에 팀 관례를 명시하면 위 문제가 대부분 사라집니다. 제가 실제로 쓰는 규칙의 핵심만 추리면 이렇습니다:

- 비즈니스 로직은 뷰가 아니라 모델 메서드 또는 services.py에 작성
- 관련 객체 조회 시 select_related / prefetch_related 필수
- API는 DRF ViewSet + Router 패턴 사용
- 테스트는 pytest + factory_boy, 모든 신규 엔드포인트에 테스트 포함
- signals 대신 명시적 메서드 호출 우선
- 마이그레이션 파일은 직접 수정하지 말고 makemigrations로 생성

GitHub의 awesome-cursorrules 저장소에 Django 베스트 프랙티스 규칙 전문이 공개되어 있으니, 그걸 가져와서 프로젝트에 맞게 줄이는 방식을 권합니다. 규칙을 넣기 전과 후의 Agent 결과물은 다른 사람이 짠 코드처럼 차이가 납니다.

작업 유형별 워크플로

새 기능(엔드포인트 추가): Agent에게 모델→시리얼라이저→뷰→URL→테스트를 한 번에 시키되, 요구사항을 명세처럼 구체적으로 적습니다. "주문 취소 API. 취소 가능 조건은 배송 전, 취소 시 재고 복구, 권한은 주문자 본인만"처럼요. 모호하게 시키면 뷰에 로직이 뭉칩니다.

버그 수정: 에러 트레이스백을 챗에 붙여넣고 관련 파일을 첨부하는 게 가장 빠릅니다. Django 트레이스백은 정보가 풍부해서 원인 특정 정확도가 높습니다.

마이그레이션: 모델 수정은 Cursor에 맡기되, makemigrations와 migrate는 제가 직접 돌리고 생성된 마이그레이션 파일을 눈으로 확인합니다. 데이터 손실 가능성이 있는 변경(필드 삭제, 타입 변경)은 AI에게 맡기지 않는 것이 원칙입니다.

대형 리팩토링: 뷰에 쌓인 로직을 서비스 레이어로 옮기는 수준의 덩어리 작업은 Cursor Agent보다 Claude Code에 맡기는 편입니다. 역할 분담은 Cursor vs Claude Code에서 다뤘습니다.

몇 달간의 시행착오에서 남은 것

초반 한 달은 규칙 없이 썼고, Agent가 만든 뷰 중심 코드가 쌓이면서 "AI가 만든 부채"를 리팩토링하는 데 주말 하나를 썼습니다. 그때 .cursor/rules를 제대로 정리했고, 이후로는 결과물 품질이 안정됐습니다. 두 번째 교훈은 쿼리 성능입니다. Agent가 만든 목록 API가 로컬에서는 멀쩡했는데 데이터가 쌓인 스테이징에서 N+1로 느려진 적이 있어서, 그 뒤로 규칙에 select_related 항목을 넣고 목록 API는 쿼리 수를 확인하는 습관이 생겼습니다. 마지막으로 마이그레이션은 한 번 꼬여본 뒤로 무조건 수동 확인입니다. AI는 코드를 잘 만들지만, DB에 되돌릴 수 없는 변경을 가하는 단계는 사람이 잡고 있어야 합니다.

자주 묻는 질문 (FAQ)

Q. Django 프로젝트에서 Cursor 무료 플랜으로 충분한가요?

A. 학습·토이 프로젝트라면 가능하지만, Agent를 쓰기 시작하면 한도가 금방 소진됩니다. 실무 프로젝트라면 Pro($20/월)를 전제하는 것이 현실적입니다.

Q. Django용 .cursorrules는 어디서 구할 수 있나요?

A. GitHub의 awesome-cursorrules 저장소와 cursor.directory에 Django 규칙 템플릿이 공개되어 있습니다. 그대로 쓰기보다 프로젝트 관례에 맞게 다듬는 것을 권합니다.

Q. 레거시 Django 프로젝트에도 효과가 있나요?

A. 오히려 레거시에서 체감이 큽니다. 코드베이스 인덱싱 덕분에 "이 함수 어디서 쓰이지?" 같은 탐색이 빨라집니다. 다만 프로젝트가 크면 .cursorignore로 인덱싱 대상을 정리해야 쾌적합니다.

Q. AI가 만든 코드를 그대로 배포해도 되나요?

A. 권장하지 않습니다. 특히 인증·권한·쿼리 성능·마이그레이션은 반드시 리뷰하세요. AI는 "동작하는 코드"와 "프로덕션에 안전한 코드"를 구분하지 못하는 경우가 있습니다.

한눈에 보는 요약

Cursor는 Django의 반복 구조와 잘 맞지만, 핵심은 도구가 아니라 규칙입니다. .cursor/rules에 fat model·쿼리 최적화·테스트 관례를 정의하고, 패턴화된 작업은 Agent에, 연쇄 수정은 Tab에, 마이그레이션 실행은 사람에게. 이 분담이 안정적으로 자리 잡으면 Django 개발 속도가 확실히 달라집니다.

함께 보면 좋은 글

Cursor 완전 정리: 기능, 요금, 비교까지 (2026년 기준)
Cursor vs Claude Code: 어떤 상황에 뭘 써야 할까?
Cursor가 느려질 때 해결 방법 7가지

참고 자료

awesome-cursorrules (GitHub)
Cursor Directory - Django Rules
Django 공식 문서