팀에서 Cursor Rules가 망가지는 이유
솔로 개발자에게 Cursor Rules는 단순하다. .cursorrules 파일 하나, 취향 하나, 스타일 하나. 매 세션 동일하게 동작한다. 문제는 팀이다. dev.to의 Olivia Craft가 짚은 것처럼, 10명짜리 팀에서 Cursor Rules를 방치하면 React 18을 쓰는 개발자 옆에서 누군가 React 19 Suspense 패턴이 담긴 PR을 머지하고, 같은 레포 안에서 pytest와 unittest가 공존하고, 신입은 3주째 리뷰에서 튕겨나오는 코드를 계속 짠다. 규칙이 없어서가 아니라 규칙이 ~/.cursor/ 어딘가에 흩어져 있어서다.
핵심 진단은 명확하다. Cursor Rules는 솔로 워크플로우용으로 설계됐다. 팀에서 쓰려면 코드처럼 다뤄야 한다. 버전 관리되고, 리뷰를 거치고, 스코프가 정의되고, 상속되고, 강제된다. 이걸 하지 않으면 규칙은 존재하지만 작동하지 않는 상태가 된다. 더 나쁜 경우, 잘못된 컨텍스트에서 작동한다.
규칙을 코드처럼 관리하는 7가지 원칙
실전에서 팀이 맞닥뜨리는 실패 패턴과 그 수정 방향을 정리하면 이렇다.
1. 규칙은 레포 안에 산다. ~/.cursor/rules/는 개인 취향(말투, 단축키)만 넣는 곳이다. 코드 스타일이나 아키텍처 규칙이 거기 들어간 순간, 그 규칙은 팀에 존재하지 않는다. 모든 팀 규칙은 .cursor/rules/*.mdc로 커밋되고, 브랜치를 타고, PR 리뷰를 받는다.
2. 모노레포에서는 상속 구조를 명확히. 루트 .cursor/rules/에는 커밋 컨벤션, 보안 베이스라인처럼 전체에 적용되는 규칙만 둔다. 패키지별 규칙(테스트 프레임워크, UI 프레임워크)은 packages/<name>/.cursor/rules/ 아래에 두고 루트를 오버라이드한다. 루트 규칙을 패키지에서 복붙하는 순간 두 규칙은 드리프트를 시작한다.
3. 모든 규칙은 스코프를 선언한다. frontmatter에 globs가 없으면 전역 규칙이다. 전역이 의도적이라면 본문에 명시하고, 아니라면 반드시 적용 범위를 제한한다. globs 없는 규칙이 "왜 여기서 이런 제안이 나오지?" 불만의 1위 원인이다.
4. 규칙은 라이브러리 버전을 정확히 명시한다. "최신 React 훅을 써라"는 매달 다른 코드베이스를 만든다. "React 18.3 훅을 써라. React 19 기능(use, Actions, useOptimistic)은 쓰지 않는다"처럼 고정한다. 의존성을 업그레이드하는 PR에는 반드시 해당 .mdc 파일 수정이 함께 들어간다.
5. 온보딩 첫 PR은 Cursor Rule 수정이다. 4000자짜리 CONTRIBUTING.md는 이틀 뒤 아무도 기억 못한다. 신입에게는 Cursor로 전형적인 작업을 시키고, 생성된 코드에서 팀 컨벤션과 어긋난 부분을 찾아서 규칙을 수정하거나 추가하는 PR을 첫 기여로 내게 한다. 신입은 규칙 파일이 소스 오브 트루스라는 걸 몸으로 배우고, 팀은 매 온보딩마다 규칙 감사를 공짜로 얻는다.
6. 규칙과 코드는 같은 PR에서 변경된다. "axios 쓰지 마라" 규칙이 살아있는데 코드베이스는 6개월 전에 fetch로 마이그레이션된 상태—이 드리프트가 매 PR마다 5분씩 태운다. PR 템플릿에 "이 PR이 패턴을 바꾸는가? 해당 .mdc 파일을 업데이트했는가?" 체크리스트를 박는다.
7. 규칙은 린터로 강제된다. 강제되지 않는 규칙은 제안일 뿐이다. 코드 스타일 규칙마다 대응하는 린터/CI 체크를 붙인다. "pytest만 써라" → import unittest 금지 CI 검사. "console.log 금지" → ESLint 룰. Cursor는 넛지하고, CI가 검증한다.
하지만 규칙이 촘촘할수록 개발자는 탐구를 멈춘다
여기서 불편한 질문이 시작된다. dev.to의 Muhammad Niaz Ali가 석 달째 고민한 것이다. 그는 드래그앤드롭 파일 업로드 컴포넌트가 필요했고, Copilot이 즉시 완성된 코드를 내놨다. React, react-dropzone, Tailwind. 첫 시도에 동작했다. 그런데 그는 멈춰서 스스로에게 물었다. AI가 없었다면 나는 같은 방식으로 짰을까?
아니었다. 의존성을 줄이기 위해 바닐라 JavaScript를 고려했을 것이다. 크로스 프로젝트 재사용을 위해 웹 컴포넌트를 생각했을 것이다. 업로드 볼륨이 낮으니 서버사이드 핸들링도 옵션이었다. AI는 그 어떤 선택지도 보여주지 않았다. 훈련 데이터에서 가장 흔한 경로만 보여줬다.
이 문제는 Cursor Rules를 잘 설계할수록 더 강해진다. 규칙이 촘촘할수록 AI의 제안 범위는 더 좁아지고, 개발자가 "왜 이 선택인가"를 고민할 여지도 줄어든다. 팀 일관성을 얻는 대신 탐구의 마찰을 제거하는 셈이다. Muhammad가 지적한 세 가지 패턴이 여기서 나온다. 문서를 읽지 않고 AI에게 묻기, 에러 메시지를 분석하지 않고 붙여넣기, 그리고 PR이 점점 서로 닮아가는 것.
Martin Fowler의 프레임으로 말하면 이건 인지 부채(Cognitive Debt)다. 코드가 아니라 개발자에게 쌓이는 부채. 팀이 시스템을 변경하고 추론하는 능력이 AI가 채우는 속도보다 빠르게 약해지는 상태.
설계로 통제하되, 설계 안에 마찰을 남겨라
그래서 AI-First 팀이 Cursor Rules를 설계할 때 두 가지를 동시에 해야 한다.
첫째, 강제할 것은 철저히 강제한다. 보안 베이스라인, 커밋 컨벤션, 금지된 패키지—이건 Cursor가 넛지하고 CI가 차단한다. 개발자가 매번 판단해야 할 이유가 없는 영역이다.
둘째, 강제하지 말아야 할 영역을 설계에 명시한다. 아키텍처 결정, 새로운 패턴의 도입, 라이브러리 선택 근거—이것들은 의도적으로 AI 규칙 밖에 둔다. 개발자가 선택지를 비교하고, 문서를 읽고, 틀린 선택을 해봐야 하는 영역이다. Cursor Rules의 description에 "이 규칙은 X에 적용된다. Y에 대한 결정은 팀이 직접 내린다"고 명시하는 것만으로도 경계가 생긴다.
Muhammad가 제안하는 실천법은 간단하다. AI 없이 먼저 풀어보는 시간을 의도적으로 갖는다. 에러 메시지를 AI에 붙이기 전에 스택 트레이스를 10분 읽는다. 주간 코드 리뷰에서 "왜 이 패턴인가"를 팀이 소리 내어 묻는다. 규칙이 제시하는 경로가 최선인지 분기별로 함께 의심한다.
온보딩 PR 설계도 여기서 확장된다. 신입이 Cursor가 생성한 코드에서 팀 컨벤션과 맞지 않는 부분을 찾아 규칙을 수정하는 경험—이건 단순히 규칙 감사가 아니다. "AI가 왜 이렇게 제안했는가"를 추적하는 훈련이기도 하다. 그 추적 능력이 바로 AI-First 팀에서 시니어와 주니어를 가르는 기준이 된다.
전망: 규칙의 품질이 팀 역량의 천장이다
Cursor Rules를 코드처럼 관리하는 팀과 그렇지 않은 팀의 격차는 6개월 뒤에 드러난다. 전자는 AI가 팀 컨벤션에 맞는 코드를 일관되게 생성하고, 드리프트가 CI에서 잡히고, 신입이 2주 안에 팀 패턴을 체화한다. 후자는 PR마다 스타일 논쟁이 반복되고, 규칙이 코드보다 6개월 뒤처지고, 신입은 누구의 패턴을 따라야 할지 모른다.
하지만 규칙을 잘 설계한 팀도 다른 함정을 조심해야 한다. 규칙이 완벽할수록 개발자는 "규칙대로 했다"는 것으로 사고를 멈춘다. AI가 채운 공백에 개발자의 판단이 자리 잡아야 할 영역이 있다. 그 영역을 의도적으로 규칙 밖에 남겨두는 것—그것도 설계다.
AI-First 팀의 Cursor Rules는 결국 두 가지 질문에 답해야 한다. 무엇을 AI에게 위임할 것인가. 그리고 무엇을 개발자가 직접 판단해야 하는가. 그 경계를 명시하지 않은 규칙은 일관성은 주지만 역량은 가져간다.