AI 지원 PR이 확장되는 이유와 Cursor Project Rules를 활용한 해결 방법

AI 지원 코딩 도구는 유용하지만, 일상적인 개발 과정에서 한 가지 문제가 계속해서 나타납니다:

PR(Pull Request)이 원래 작업보다 커지는 것입니다.

작은 수정 사항 하나를 요청했는데,
AI가 주변 코드까지 리팩토링(Refactor)해 버립니다.

엔드포인트(Endpoint) 하나만 변경해 달라고 요청했는데,
AI가 라우팅(Routing), 테스트(Tests), 설정(Config), 그리고 문서화(Documentation)까지 건드립니다.

리뷰 코멘트를 처리해 달라고 요청했는데,
그 코멘트를 광범위한 정리 작업으로 바꿔버립니다.

각각의 변경 사항은 개별적으로 보면 합리적으로 보일 수 있습니다. 문제는 PR이 리뷰하기 더 어려워지고, 되돌리기(Revert) 더 어려워지며, 나중에 설명하기도 더 어려워진다는 점입니다.

저는 이것이 단지 Cursor만의 문제라고 생각하지 않습니다.

이것은 AI 지원 PR의 규율(Discipline) 문제입니다.

문제점: AI는 범위를 확장하는 경향이 있음

AI 코딩 도구는 주변의 문제점을 발견하면 이를 개선하고 싶어 하는 경향이 있습니다.

탐색 모드(Exploration mode)에서는 이것이 도움이 될 수 있습니다. 하지만 PR 워크플로우(Workflow)에서는 리스크를 초래합니다.

좋은 PR은 보통 하나의 질문에 답해야 합니다:

이 PR이 인간 리뷰어에게 내리도록 요청하는 결정은 무엇인가?

만약 하나의 PR에 버그 수정, 리팩토링, 새로운 헬퍼(Helper) 추가, 문서 업데이트, 그리고 테스트 재작성이 모두 포함되어 있다면, 인간 리뷰어는 더 이상 하나의 결정을 리뷰하는 것이 아닙니다.

그들은 여러 결정이 한데 묶인 것을 리뷰하고 있는 것입니다.

이는 PR을 확신을 가지고 머지(Merge)하는 것을 더 어렵게 만듭니다.

테스트 내용

저는 cursor-pr-discipline이라는 작은 무료 리포지토리(Repo)를 만들었습니다.

여기에는 Cursor를 위한 몇 가지 .mdc 프로젝트 규칙(Project Rules)이 포함되어 있습니다:

• no-unrequested-changes.mdc
• one-pr-one-topic.mdc
• classify-before-merging.mdc

목표는 Cursor가 완벽하게 동작하도록 강제하는 것이 아닙니다.

목표는 인간이 제어하는 PR 워크플로우를 강화할 수 있도록 Cursor에 더 강력한 프로젝트 수준의 지침을 제공하는 것입니다.

첫 번째 테스트

저는 작은 테스트 파일을 만들었습니다:

function registerUser(input) {
  return {
    email: input.email,
...

그런 다음 Cursor에게 다음과 같이 요청했습니다:

test-sandbox/registration.js에 입력 유효성 검사(Input validation)를 추가해줘.

다른 파일은 수정하지 마.

Cursor는 요청된 파일 내로 작업 범위를 유지했습니다.

이는 좋은 첫 번째 결과였습니다.

범위 확장 테스트

그다음 저는 의도적으로 범위를 확장하는 후속 요청을 했습니다:

Also refactor the validation into a shared utility and update the README.
(또한 검증 로직을 공용 유틸리티(shared utility)로 리팩터링하고 README를 업데이트해줘.)

제 규칙의 첫 번째 버전은 충분히 강력하지 않았습니다.

Cursor는 공용 유틸리티(shared utility)로 이동하고 README를 업데이트하기 시작했습니다.

이는 유용한 피드백이었습니다.

규칙은 후속 요청(follow-up request)에 대해 더 명시적일 필요가 있었습니다.

변경 사항

저는 후속 요청이 별개의 관심사(concern), 새로운 추상화(abstraction), 관련 없는 파일, 또는 문서 업데이트를 도입하는 경우, Cursor가 이를 즉시 구현해서는 안 된다고 규칙을 업데이트했습니다.

대신, 해당 작업을 별도의 PR(Pull Request)로 처리해야 하는지 먼저 물어봐야 합니다.

이러한 변경 이후, 동일한 후속 요청에 대해 더 나은 결과가 도출되었습니다.

Cursor는 해당 요청을 다음과 같이 여러 개의 관심사로 식별했습니다:

• 기존 검증(validation) 변경 사항의 범위를 유지할 것
• 공용 유틸리티(shared utility) 추출은 후속 PR로 이동할 것
• README 문서 업데이트는 또 다른 후속 PR로 이동할 것

이것이 제가 원했던 동작입니다.

자동적인 강제 집행이 아닙니다.
보장도 아닙니다.
그저 더 나은 PR 규율(discipline)일 뿐입니다.

이것이 중요한 이유

AI 코딩 도구는 코드를 생성하는 것을 더 쉽게 만듭니다.

하지만 코드를 생성하는 것이 무엇을 머지(merge)해야 할지 결정하는 것과 같지는 않습니다.

저에게 있어, 인간은 여전히 다음 사항들을 결정해야 합니다:

• PR이 무엇을 변경할 수 있는지
• 무엇을 미룰 것인지
• 머지(merge) 전에 무엇을 검토(review)해야 하는지
• 왜 이 PR이 머지(merge)되었는지

프로젝트 규칙(Project Rules)은 이러한 워크플로우(workflow)를 강화하는 데 도움을 줄 수 있습니다.

이 규칙들이 인간의 판단을 대체하는 것은 아닙니다.

무료 리포지토리 (Free repo)

첫 번째 버전을 여기에 게시했습니다:

https://github.com/logfabricteam/cursor-pr-discipline

여기에는 무료 .mdc 규칙과 작은 규모의 범위 제한 PR(scoped PR) 예시가 포함되어 있습니다.

얼리 액세스 (Early access)

저는 또한 인간의 머지(merge) 결정, 모호한 요청, 리뷰 트리아지(review triage), 그리고 자율적인 머지(autonomous merge)를 멈추는 것에 대한 더 많은 예시와 규칙이 담긴 프로 팩(Pro Pack)을 검증하고 있습니다.

https://kubo03.gumroad.com/l/cursor-pr-discipline

핵심 아이디어는 간단합니다:

AI가 코드를 작성하는 데 도움을 줄 수 있습니다.
하지만 PR(Pull Request)은 여전히 범위를 제한(scoped)하고, 검토 가능(reviewable)하며, 사람이 결정(human-decided)하는 상태로 유지되어야 합니다.