Entity Framework Core와 Cursor AI를 사용하는 방법 (데이터베이스를 망가뜨리지 않고)
요약
Cursor AI가 생성하는 Entity Framework Core 코드가 운영 환경에서 성능 문제를 일으키지 않도록 .mdc 규칙을 통해 제약 조건을 설정하는 방법을 설명합니다. AsNoTracking 사용 강제, Include 깊이 제한 등을 통해 AI의 비효율적인 쿼리 작성을 방지할 수 있습니다.
핵심 포인트
- Cursor AI의 학습 데이터는 단순화된 예제가 많아 운영 환경에 부적합할 수 있음
- .mdc 규칙을 사용하여 데이터 액세스 계층에 시스템 수준의 제약 조건 적용 가능
- AsNoTracking() 강제 및 Include 체인 깊이 제한으로 성능 최적화
- 디렉터리 범위 규칙 설정을 통해 불필요한 토큰 소모 방지
****Entity Framework Core와 Cursor AI를 사용하는 방법 (데이터베이스를 망가뜨리지 않고)
당신은 Cursor에게 간단한 API 엔드포인트를 추가해달라고 요청합니다. Cursor는 작동하는 컨트롤러를 생성합니다. 당신은 EF Core 코드를 훑어봅니다. .Include().ThenInclude().ThenInclude() — 3단계 깊이, AsNoTracking()은 없고, 50,000개의 행을 실체화(materialises)하는 ToListAsync()가 있습니다. 축하합니다: 당신의 AI 어시스턴트가 방금 운영 장애(production incident)를 일으킬 코드를 작성했습니다. 코드가 PR(Pull Request)에 도달하기 전에, 이를 영구적이고 자동적으로 중단하는 방법을 소개합니다.
##
...
이유는 간단합니다: Cursor의 학습 데이터에는 블로그 포스트, Stack Overflow 답변, GitHub 저장소에서 가져온 수백만 개의 EF Core 예제가 포함되어 있습니다. 그 예제들 대부분은 가독성을 위해 단순화된 것이지, 운영 환경 수준(production-grade)이 아닙니다. 간결함을 위해 AsNoTracking()을 생략합니다. 작성자가 .Include() 구문을 보여주고 싶어서 전체 객체 그래프를 즉시 로딩(eager-load)합니다. 예제가 10개 행뿐이었기 때문에 필터링 전에 .ToList()를 호출합니다.
...
csharp
// ❌ Cursor 생성: 메모리의 모든 엔티티를 추적(tracks)함
...
```csharp
// ❌ Cursor 생성: 데이터베이스 전체를 즉시 로딩(eager-loads)함
var orders = await _context.Orders
.Include(o => o.Customer)
...
csharp
// ❌ Cursor 생성: 깔끔해 보이지만, N+1 쿼리를 생성함
...
// ❌ Cursor 생성: 사용자 정의 메서드가 클라이언트 평가(client eval)를 유발함
var active = await _context.Users
...
- ****``Include 깊이 제한: 최대 2단계의 .Include() 체인을 강제합니다. 이보다 깊은 것은 반드시 .Select() 프로젝션(projections)을 사용해야 하며, 이는 어차피 더 효율적입니다.
- ****``루프 내 지연 로딩(lazy loading) 금지: 이 규칙은 엔티티 결과에 대한 모든 foreach를 위반 템플릿으로 표시합니다. 대신 Cursor는 프로젝션을 자동으로 제안합니다.
...
ef-core-reads.mdc 규칙은 디렉터리 범위(directory-scoped)로 지정됩니다. 이 규칙은 Cursor의 에이전트(agent)가 데이터 액세스(data-access) 프로젝트 내부에서 작업할 때만 활성화됩니다. 일반적으로 src/YourApp.Infrastructure/ 또는 DbContext와 리포지토리(repositories)가 위치한 디렉터리가 이에 해당합니다. 즉, 컨트롤러(controllers), 도메인 모델(domain models) 또는 단위 테스트(unit tests)를 편집할 때는 토큰을 소모하지 않습니다.
규칙이 활성화되면, Cursor의 컨텍스트 윈도우(context window)에 시스템 수준의 제약 조건(system-level constraint)으로 삽입됩니다. AI는 이를 '.cs 파일에서 Python을 생성하지 마세요'라는 지시와 마찬가지로 협상의 여지가 없는 명령으로 취급합니다. 규칙이 로드된 상태에서 2~3번의 프롬프트(prompts)를 거치고 나면, Cursor는 잘못된 패턴을 생성하는 것을 완전히 중단합니다. 이는 AI에게 근육 기억(muscle memory)처럼 자리 잡게 됩니다.
실제 결과: EF Core 규칙 적용 전과 후
| 지표 | 규칙 적용 전 | 규칙 적용 후 | 개선 사항 |
|---|---|---|---|
| AsNoTracking이 누락된 AI 생성 쿼리 | 78% | 4% | 95% 감소 |
| 3단계 이상의 Include 체인 | 쿼리의 42% | 0% | 제거됨 |
| 생성된 코드 내 N+1 패턴 | PR당 1~2개 | PR당 0개 | 제거됨 |
| 클라이언트 측 평가(Client-side eval) 발생 건수 | 월 약 2건 | 0건 | 개발 단계에서 포착됨 |
| 평균 PR 리뷰 시간 (데이터 레이어) | 약 25분 | 약 8분 | 68% 빨라짐 |
이 수치는 6개의 경계 컨텍스트(bounded contexts)에 걸쳐 약 80개의 엔티티(entity) 유형이 있는 프로덕션 .NET 9 솔루션에서 도출되었습니다. 팀은 임시적인(ad-hoc) Cursor 사용 방식에서 규칙 기반의 AI 페어 프로그래밍(AI pair programming) 방식으로 전환했습니다. 데이터 레이어의 PR 리뷰 시간 절감만으로도 첫날 오후에 키트 비용을 모두 회수했습니다.
60초 만에 EF Core 가드레일(guardrail) 설치하기
``
Agentic Architect 키트에는 즉시 사용 가능한 ef-core-reads.mdc 규칙이 포함되어 있습니다. 설치 흐름은 다음과 같습니다:
ef-core-reads.mdc 파일을 데이터 액세스(data-access) 하위 폴더 내의 .cursor/rules/ 디렉터리로 복사합니다.
...
- **``**di-scoping.mdc — 캡티브 종속성 (captive dependencies), 싱글톤 서비스가 스코프(scoped) 서비스를 보유하는 문제, 그리고 MediatR에 HttpClient를 주입하는 안티 패턴 (anti-pattern)을 포착합니다.
- **``**ef-core-reads.mdc — 위에서 설명한 데이터베이스 가드레일 (guardrail)입니다.
- **``**api-conventions.mdc — 일관된 컨트롤러 패턴, 상태 코드 (status codes), 그리고 ProblemDetails 응답을 강제합니다.
- **``**testing-patterns.mdc — AAA 구조, 테스트 데이터 빌더 (test-data builder) 사용, 그리고 실제 컨텍스트 통합 테스트 (real-context integration tests)를 보장합니다.
- **``**domain-model.mdc — 빈약한 도메인 모델 (anemic domain models)을 방지하고, 캡슐화 (encapsulation) 및 값 객체 (value-object) 사용을 강제합니다.
- **``**logging.mdc — 의미론적 이름 (semantic names)을 사용한 구조화된 로깅 (structured logging)을 수행하며, 로그 메시지에 문자열 보간 (string interpolation)을 사용하지 않습니다.
- **``**null-guard.mdc — Nullable 참조 형식 (nullable reference type) 규율 및 API 경계에서의 Null 가드 (null-guard)를 적용합니다.
- **``**performance.mdc — 전체 과정의 비동기화 (async-all-the-way), 핫 패스 (hot paths)를 위한 Span 사용, 벤치마크 (benchmark) 구조를 다룹니다.
## AI가 생성한 EF Core 코드에 대해 코드 리뷰보다 규칙이 더 효과적인 이유
본능적으로는 이러한 문제들을 코드 리뷰 (code review) 단계에서 잡아내려 할 것입니다. 하지만 그 접근 방식에는 두 가지 문제가 있습니다.
첫째, 속도입니다. 만약 Cursor가 한 세션에서 200줄의 데이터 액세스 (data-access) 코드를 생성했는데 쿼리의 78%에 `AsNoTracking()`이 누락되어 있다면, 여러분은 세션당 약 20개의 쿼리 지점에 수동으로 주석을 달아야 합니다. 이는 창의적인 작업이 아니라 리뷰 노동입니다.
둘째, 일관성입니다. 인간 리뷰어는 자신이 눈치챈 것만 잡아냅니다. 하지만 규칙은 프로그램된 대로 잡아냅니다 — 매번 말이죠. 피로도도 없고, 금요일 오후의 실수도 없으며, "이건 작은 엔드포인트니까 그냥 넘어가자"라는 식의 예외도 없습니다. 규칙은 균일합니다.
> "EF Core 규칙은 도입 후 첫 두 시간 만에 제 값을 했습니다. 더 이상 `AsNoTracking`을 직접 타이핑할 필요가 없습니다. 이제 Cursor가 알아서 해주니까요." — 12명 규모의 핀테크 팀, 시니어 .NET 개발자
## AI 페어 프로그래밍 (pair programming)에는 가이드라인이 아닌 가드레일이 필요합니다
[](https://agenticstandardcontact-byte.github.io/agentic-architect/blog/06-stop-cursor-ai-drift-dotnet.html)****
Cursor AI는 당신이 멘토링해야 할 주니어 개발자가 아닙니다. 그것은 지금까지 발표된 모든 나쁜 코드 예제에 접근할 수 있는 패턴 매칭 엔진 (pattern-matching engine)입니다. Cursor AI를 멘토링하는 것 — 즉, 세션마다 반복되는 동일한 실수를 바로잡는 것 — 은 우리가 Post 06에서 설명한 컨텍스트 비용 (Context Tax)입니다. 유일하게 지속 가능한 접근 방식은 나쁜 패턴이 당신의 화면에 도달하는 것 자체를 방지하는 규칙 기반의 가드레일 (rule-based guardrails)입니다.
EF Core는 단지 가장 비용이 많이 드는 사례일 뿐입니다. 동일한 원칙이 의존성 주입 (DI) 스코핑, 에러 핸들링 (error handling), API 컨벤션 (API conventions), 그리고 AI의 학습 데이터에 블로그 포스트용으로 단순화된 패턴이 포함된 모든 다른 영역에도 적용됩니다. 규칙을 한 번만 설치하십시오. AI가 인터넷의 기준이 아닌, 당신의 표준에 맞추도록 만드십시오.
---
*원문은 [https://agenticstandardcontact-byte.github.io/agentic-architect/blog/07-cursor-efcore-patterns.html](https://agenticstandardcontact-byte.github.io/agentic-architect/blog/07-cursor-efcore-patterns.html)에 게시되었습니다. 이 글은 Cursor + .NET을 위한 [Agentic Architect](https://agenticstandardcontact-byte.github.io/agentic-architect/) 지속성 키트 (persistence kit)의 일부입니다.*
```
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기